본문 바로가기
AI Agent/Patterns

온디바이스 SLM 에이전트

by AteN 2026. 8. 12.

온디바이스 SLM 에이전트

온디바이스 SLM 에이전트는 비교적 작은 언어모델을 사용자 기기에서 실행해 도구 선택과 여러 단계의 작업을 처리하는 구조입니다. 장점은 네트워크 왕복을 줄이고, 민감한 데이터를 로컬에 남기며, 오프라인에서도 동작할 수 있다는 점입니다. 반대로 메모리 대역폭, 가속기 지원 연산, 모델 용량이라는 제약을 동시에 받습니다.

작은 모델에서 실패가 자주 드러나는 곳은 구조화된 tool call, 긴 multi-step 계획, 모호한 요청의 판단입니다. 그러나 이 문제를 단순히 “SLM은 에이전트를 못 한다”로 묶으면 설계 여지가 사라집니다. constrained decoding, 작은 도구 집합, 명시적 state machine, prefix/cache 재사용, 선택적 cloud escalation처럼 모델이 해야 할 판단의 범위를 줄이는 시스템 설계가 성능에 큰 영향을 줍니다.

실무에서 자주 검토되는 형태는 local-first와 cloud escalation의 조합입니다. 다만 이것이 업계의 단일 표준이라는 뜻은 아니며, 개인정보·지연·비용·오프라인 요구와 로컬 모델의 성공률을 함께 재서 어디까지 기기에서 처리할지 정해야 합니다.


1장. 굳이 기기 위에서 돌리는 이유

클라우드에는 네 가지 세금이 붙습니다.

지연
   매 스텝 서버를 왕복한다
   도구를 여러 번 부르면 왕복이 쌓여 체감이 굼떠진다

프라이버시
   내 사진과 문서와 연락처를 밖으로 보내야 한다

비용
   에이전트는 한 요청에 모델을 수십 번 부른다
   토큰 과금이 빠르게 불어난다

오프라인
   지하철, 기내, 산간에서 아예 동작하지 않는다

클라우드를 없애는 것이 아니라 기본은 로컬로 두고 어려운 순간만 클라우드로 넘기는 구조입니다.

동네 만능 일꾼과 전문가 전화로 보면 이해가 쉽습니다. 대부분은 옆에 있는 빠른 일꾼이 처리하고 막히는 순간에만 멀리 있는 전문가에게 그 한 건만 전화로 물어봅니다. 전화를 아낄수록 빠르고 싸집니다.

챗봇은 요청당 모델 호출이 한 번이지만 에이전트는 수십 번입니다. 그래서 왕복 절감의 효과가 훨씬 크고, 도구가 기기의 데이터를 만지는 경우가 많아 프라이버시 이득도 큽니다.


2장. 작은 모델이 무너지는 지점

소형 모델은 모델·학습 데이터에 따라 structured tool call 정확도가 크게 갈립니다. JSON syntax, schema field, tool selection 중 어느 지점이 약한지 분리해서 봐야 하며 constrained decoding은 syntax/schema 오류를 줄이지만 잘못된 도구 선택까지 해결하지는 않습니다.

전형적인 형태는 JSON에 후행 쉼표를 넣거나, 따옴표를 빠뜨리거나, 설명 문장을 JSON 앞뒤에 붙이거나, 중첩 구조를 평평하게 만드는 것입니다.

인자를 채우는 것은 곧잘 해도 한 요청을 여러 단계로 쪼개는 계획 능력에서 무너지고 스텝 수가 늘수록 급격히 나빠집니다.

도구 하나 부르기와 도구 다섯 개를 순서대로 부르기는 난이도가 선형이 아닙니다. 앞 단계 결과를 다음 단계에 넘기는 것이 특히 어렵습니다.

모바일 NPU/GPU는 지원 precision과 kernel, memory bandwidth, shared-memory 구조가 서버 GPU와 다릅니다. 짧은 context·batch 1에서는 model weight가 메모리의 큰 비중을 차지하기 쉽지만, 긴 context나 hybrid/multimodal model에서는 KV cache와 activation도 중요한 제약이 됩니다. 짧은 컨텍스트에서는 KV 캐시가 아니라 가중치가 지배하므로 메모리 관건은 KV 압축이 아니라 가중치 절감입니다.

마지막이 클라우드 추론 최적화와 정반대라 자주 틀리는 지점입니다.

서버에서는
   배치가 크고 컨텍스트가 길어 KV 캐시가 메모리를 먹는다

온디바이스에서는
   배치 1 이고 컨텍스트가 짧아 가중치가 메모리의 큰 비중을 차지하기 쉽다

   7B fp16 = 14GB
   같은 조건 4k 컨텍스트 KV = 수백 MB

   양자화와 증류가 훨씬 큰 레버다

3장. 격차를 메우는 다섯 갈래

소형 모델일수록 native function calling의 편차가 큽니다. 그래서 모델이 곧장 도구를 부르게 두지 말고 먼저 JSON 계획을 세우게 한 뒤 실행하는 편이 견고합니다.

나쁨   SLM 에게 곧장 native tool call 을 시킨다
       모델이 형식을 못 맞추면 그대로 실패

좋음   ① SLM 이 도구와 순서와 인자를 JSON 계획으로 낸다
       ② 실행기가 그 계획대로 도구를 호출한다
       ③ native 호출은 계획이 실패했을 때의 폴백으로 둔다

여기에 Constrained Decoding을 얹으면 형식 신뢰성이 더 오릅니다.

계획을 먼저 세우는 편이 나은 이유는 한 번에 전체를 내면 형식 오류가 한 곳에 몰려서 실행기가 검증하고 고칠 수 있기 때문입니다. 반면 매 스텝 즉석 생성은 실패가 실행 도중에 흩어져 나옵니다.

플래너가 계획을 세우고 native를 폴백으로 두는 하이브리드가 여러 온디바이스 구현에서 반복 관찰되는 원리입니다.

범용 지능은 작아도 도구 호출이라는 좁은 능력만 집중적으로 학습시키면 놀랄 만큼 세집니다.

한 연구는 겨우 350M 파라미터짜리 모델을 도구 호출용으로 파인튜닝해 ToolBench 통과율 77.55%를 얻었습니다. 같은 벤치에서 ChatGPT-CoT는 26%, ToolLLaMA-DFS는 30.18%였습니다.

읽는 법이 중요합니다. 작은 모델이 더 낫다가 아니라 태스크를 좁히면 크기 요구가 급감한다는 뜻입니다.

증류 쪽은 큰 모델의 추론 흔적을 작은 모델에 옮깁니다. R1을 1.5B 학생으로 증류한 모델이 MATH-500에서 83.9%를 냈습니다. 최근에는 학생이 교사를 수동으로 흉내 내는 대신 규칙 검증기의 보상으로 가중치를 준 증류로 더 끌어올립니다.

도구 결과와 대화 히스토리가 쌓이면 SLM의 짧은 컨텍스트를 금방 넘칩니다. 한 온디바이스 연구는 도구 스키마 최소 직렬화와 필요할 때만 로드하는 just-in-time 방식과 동적 메모리의 LoRA 어댑터 부착을 조합했습니다.

결과로 초기 시스템 프롬프트를 6배 이상 축소하고 컨텍스트 증가율을 10배에서 25배 축소하면서 성능은 기존 베이스라인 이상으로 유지했습니다.

증가율을 줄인 것이 초기 크기를 줄인 것보다 중요합니다. 에이전트는 턴이 쌓이는 구조라 증가율이 실제 한계를 결정하고, 초기 크기를 반으로 줄여도 증가율이 그대로면 몇 턴 뒤 똑같이 넘칩니다.

핵심 패턴입니다. 매 스텝을 로컬에서 실행하되 경량 라우터가 저신뢰나 스키마 위반이나 파싱 실패를 감지하면 그 턴만 클라우드로 넘기고 결과를 다시 로컬 루프로 되돌립니다.

라우팅 단위를 질문 전체가 아니라 subtask로 내리면 더 아낄 수 있습니다. 한 질문 안에서도 부분마다 난이도가 다르기 때문입니다.

Division-of-Thoughts가 이 아이디어의 대표입니다. 질문을 독립 subtask로 쪼개 난이도를 채점하고 그 경계를 사람 주석 없이 자기강화로 학습합니다. subtask의 86%를 로컬로 처리하면서 시간 66%와 API 비용 84%를 줄였습니다. 다만 정확도는 과제별 편차가 커서 최대 두 자릿수 %p 손실도 납니다.

라우팅을 처음부터 학습할 필요는 없습니다. task type, 예상 step 수, tool 위험도, local confidence 같은 값싼 신호로 heuristic baseline을 만든 뒤 실제 성공률과 escalation 비용을 보며 classifier나 learned router가 필요한지 판단할 수 있습니다. 특정 3단계 같은 임계값은 workload별 tuning 값입니다.

speculative decoding은 작은 draft로 여러 토큰을 미리 던지고 본 모델이 한 번에 검증합니다. self-speculative에 4-bit 계층 양자화 KV 캐시를 결합한 QuantSpec 연구는 해당 모델·기기 조건에서 수용률 90% 이상과 최대 약 2.5배 가속, 약 1.3배 메모리 절감을 보고했습니다. 별도 draft model을 두지 않는 다른 접근도 있으며, 한 연구는 프리픽스 캐시에 맞춘 프롬프트 재작성과 결합해 자사 실험 조건에서 엔드투엔드 1.61배 가속을 보고했습니다. 이 수치는 모두 논문별 장치·모델·workload 조건에 묶여 있습니다.

프롬프트 캐시는 프리픽스 KV를 재사용하는 기법입니다. 에이전트는 같은 시스템 프롬프트와 도구 스키마를 매 턴 반복하므로 이 프리픽스의 KV를 재사용하면 TTFT를 크게 줄입니다. 온디바이스에서 특히 효과가 큰데 prefill이 상대적으로 비싸기 때문입니다.

양자화는 메모리와 속도의 근본 레버로 INT4나 FP8을 씁니다. 다만 2-bit급으로 내려가면 인자 채우기와 생성이 붕괴해서 라우팅에는 몰라도 추출과 대화에는 부적합합니다.

NPU 저비트 추론 연구인 T-MAN은 역양자화 일부를 테이블 조회로 바꾸는 설계를 제안했고, 저자 실험 환경에서 prefill 1.4배, decode 3.1배 가속과 최대 84% 에너지 절감을 보고했습니다. 실제 효과는 NPU 연산 지원과 모델·정밀도에 따라 달라집니다.


4장. SLM-first 루프

전체 구조입니다.

사용자 요청
   │
   ▼
① 계획 (SLM)   도구와 순서와 인자를 JSON 계획으로
   │
   ▼
② 라우터   이 스텝, 로컬로 충분한가
           신뢰도와 스키마와 파싱을 점검
   │
   ├─ 충분 (대부분) ──► ③ 로컬 SLM 실행   도구 호출과 관찰
   │                        │
   ├─ 저신뢰나 실패 ──► ③' 클라우드 LLM   그 스텝만 위임
   │                        │
   │                        ▼
   └──────────────────► ④ 결과 통합
                            │
                            ├─ 남은 스텝 있음 ──► ② 라우터로
                            │
                            └─ 완료 ──► 최종 응답

대부분의 스텝은 로컬에서 끝나고 라우터가 위험을 감지한 스텝만 클라우드로 새어 나갑니다.

라우터가 보는 신호입니다.

신호 판정
스키마 검증 실패 확실하다
파싱 실패 확실하다
출력 길이가 비정상 간단하다
계획 단계 수 간단하다
모델의 로그확률 중간
별도 분류기 비싸지만 정확

앞의 두 개만으로도 상당 부분 잡힙니다. 학습된 라우터는 그다음입니다.


5장. 구체 시나리오

이번 주 회의록 3개를 요약해서 공유 폴더에 정리해달라는 요청입니다.

스텝 난이도 처리 위치
1. 이번 주 회의록 파일 3개 찾기 쉬움 로컬 파일 검색은 값싼 도구 호출. 문서가 기기를 떠날 필요 없음
2. 각 문서에서 핵심 논지와 결정사항 추출 어려움 클라우드 긴 문서의 정교한 요약은 소형 모델의 약점. 라우터가 저신뢰 감지
3. 세 요약을 하나의 표로 병합 쉬움 로컬 정해진 포맷으로 합치는 정형 작업
4. 공유 폴더에 저장 쉬움 로컬 파일 쓰기 도구 호출 하나

네 스텝 중 셋이 로컬에서 끝나고 정말 어려운 요약 한 건만 클라우드로 나갑니다. 지연, 비용, 프라이버시가 대부분의 스텝에서 지켜지고 정확도가 중요한 한 곳에만 프런티어의 힘을 빌립니다.

프라이버시가 부분적으로만 지켜집니다. 2번 스텝에서 문서 내용이 밖으로 나갑니다. 온디바이스라 안전하다는 말은 어느 스텝이 나가는지를 밝히지 않으면 과장입니다.

그래서 설계할 때 어떤 데이터가 어느 경우에 나가는지를 명시하고 사용자에게 알려야 합니다. 민감 데이터는 아예 클라우드 경로를 막는 정책도 필요합니다.


6장. 온디바이스 지형의 3층 구조

1층은 모델을 로컬에서 굴리는 런타임 백본입니다. Ollama, llama.cpp, Apple MLX와 Metal, Android LiteRT-LM이 여기 속합니다.

2층은 엔진 위에 얹은 완성형 채팅과 에이전트 앱인 로컬 비서 앱입니다.

3층은 툴과 메모리와 자율 루프를 갖춘 개인 에이전트 프레임워크입니다.

같은 모델인데 왜 빠르냐는 질문의 답 대부분은 1층에 있습니다. 엔진과 프리픽스 KV 캐시입니다. Apple Silicon의 통합메모리로 소형 모델이 유독 빠른 것도 여기서 나옵니다.

온디바이스 음성 에이전트에서는 ASR → LLM/agent → TTS처럼 기능을 분리한 파이프라인이 흔한 선택지입니다. end-to-end speech model이나 cloud hybrid도 있어 단일 표준은 아닙니다.

Whisper (또는 faster-whisper) STT
   ▼
로컬 LLM
   ▼
Piper 또는 Kokoro TTS

   여기에 wake-word 를 붙인다

수십 개의 오프라인 음성 비서가 하나같이 이 3단 레시피를 씁니다. 레시피화되어 진입장벽이 낮아졌다는 신호입니다.


7장. 한계

하이브리드 라우팅은 비용과 시간을 크게 아끼지만 과제에 따라 정확도가 두 자릿수 %p까지 떨어질 수 있습니다. 로컬로 다 된다는 맹신은 금물입니다.

한 실측 벤치는 4-bit Qwen2.5-1.5B를 여러 기기에서 돌렸는데 엣지 NPU는 2W 미만에서 6.9 tok/s에 그쳤습니다. 발열과 분산은 매우 안정적이었지만 처리량은 GPU의 19분의 1이었습니다.

NPU는 에너지 효율과 안정성이 좋지만 인터랙티브 속도는 낮을 수 있습니다. 모델과 연산자 커버리지에 따라 CPU나 GPU가 더 나은 경우도 많고, 모바일에서는 peak 연산량보다 발열 관리가 더 큰 제약이 되기도 합니다.

subtask 분해와 난이도 채점이 도메인마다 프롬프트 손질을 요구해 이식에 품이 듭니다.

SLM은 컨텍스트 창이 짧아서 긴 문서를 다루는 과제에 근본적으로 불리합니다. 앞서 본 컨텍스트 압축으로도 한계가 있습니다.


8장. 실무 감각

활성 연산이 가벼운 effective-parameter 구조, 함수 호출과 JSON에 강한 소형 모델, 소형 계열의 최신 버전이 후보입니다.

파라미터 수보다 함수 호출 안정성을 먼저 재는 편이 실용적입니다. 대표 도구 스키마로 100번 호출시켜 파싱 성공률을 재면 파라미터 수보다 훨씬 예측력이 높습니다.

한국어처럼 도구 사용 데이터가 적은 언어에서는 역할을 쪼개는 접근이 유효합니다. Planner, Caller, Generator를 역할별 소형 모델로 분리하고, 한국어 설정에서 잦은 한영 코드스위칭으로 인한 실행 실패를 줄이는 값 정책을 둡니다.

2-bit급 초저비트 양자화는 추출과 대화를 붕괴시킵니다.

NPU decode가 느려 CPU나 GPU가 더 빠를 수 있습니다.

짧은 context와 batch 1에서는 weight quantization이 메모리 절감에 더 크게 기여하는 경우가 많습니다. context가 길어지거나 동시 sequence가 늘면 KV cache 비중이 커져 GQA/MLA/KV quantization의 중요도도 함께 올라갑니다.

시작 순서입니다.

① 프리픽스 KV 캐시부터 켠다
   가장 싸고 체감이 크다

② 구조화 플래닝 + Constrained Decoding
   구조화 출력과 잘못된 도구 노출에서 오는 실패를 크게 줄일 수 있다

③ 라우터를 규칙 기반으로 붙인다
   스키마 실패와 파싱 실패만 감지해도 충분히 유용하다

④ 양자화 수준을 실측으로 정한다
   4-bit 부터 시작해 품질을 본다

⑤ 필요하면 도구용 파인튜닝

9장. 발전사

시기별 흐름입니다.

시기 흐름
2024 이전 소형 모델 도구사용 파인튜닝과 증류 시작
2025 SLM-first 하이브리드 패턴 정립, subtask 단위 라우팅, 도구용 SLM이 대형 상회 보고
2025에서 2026 저자원 언어 도구사용 SLM, 온디바이스 파이프라인 전체 가속
2026 엣지 NPU 실측 벤치, 저비트 NPU 추론

10장. 정리

온디바이스 SLM 에이전트의 요지는 대체가 아니라 분업입니다. local-by-default, cloud-on-escalation입니다.

작은 모델은 구조화 출력과 멀티스텝 분해에서 무너집니다. 구조화 플래닝과 Constrained Decoding이 그 둘을 정면으로 겨냥합니다.

온디바이스 메모리 최적화는 클라우드와 정반대입니다. KV 압축이 아니라 가중치 절감이 레버입니다.

핵심은 작은 모델이 안정적으로 수행할 범위를 명시하고, 그 밖의 작업을 더 강한 모델·결정적 코드·사람 승인으로 넘기는 것입니다. 어디에 경계를 둘지는 모델 성능뿐 아니라 지연, 개인정보, 비용, 오프라인 요구가 함께 결정합니다.


용어 정리

용어 한 줄 뜻
SLM 상대적으로 작은 언어모델을 가리키는 실무적 표현. 파라미터 경계는 고정되어 있지 않음
local-by-default, cloud-on-escalation 로컬 우선 실행에 저신뢰 턴만 클라우드로 넘기는 하이브리드 패턴
구조화 플래닝 실행 전 도구와 순서와 인자를 JSON 계획으로 세우는 방식
Constrained Decoding 문법과 스키마로 출력 형식을 강제해 형식 오류를 막는 기법
증류 큰 모델의 능력을 작은 모델로 옮겨 담는 학습
effective parameter 지식은 크되 활성 연산은 가벼운 아키텍처
speculative decoding draft로 여러 토큰을 미리 던지고 본 모델이 한 번에 검증해 가속
프리픽스 KV 재사용 반복되는 시스템 프롬프트의 KV를 캐시해 TTFT를 줄이는 기법
에스컬레이션 로컬 모델이 어려운 턴을 클라우드로 넘기는 것
subtask 라우팅 질문 전체가 아니라 부분 작업 단위로 로컬과 클라우드를 가르는 방식
컨텍스트 증가율 턴이 쌓일 때 컨텍스트가 커지는 속도. 초기 크기보다 중요

참고자료

댓글