온디바이스 AI — 폰에서 도는 소형 LLM의 실전화(지연·프라이버시·비용을 뒤집다)

왜 지금 온디바이스인가

클라우드 LLM은 강력하지만, 모든 요청을 서버로 보내는 구조에는 네 가지 구조적 비용이 따라붙는다. 지연(latency), 프라이버시, 과금, 그리고 오프라인 불가다. 온디바이스 추론은 이 네 축을 한꺼번에 뒤집는다.

지연부터 보자. 클라우드 호출은 네트워크 왕복이 최소 수백 밀리초, 셀룰러 환경에선 초 단위로 튄다. 반면 온디바이스는 첫 토큰까지의 시간(TTFT)이 모델 로딩만 끝나면 수십 밀리초 수준이다. 자동완성, 실시간 요약, 키보드 예측처럼 사용자가 타이핑 속도로 반응을 기대하는 기능에서는 이 차이가 UX 자체를 가른다.

프라이버시는 규제와 맞물린다. 건강 기록, 사진 속 얼굴, 메시지 내용을 서버로 전송하지 않고 기기 안에서 처리하면 데이터가 기기를 떠나지 않는다는 강력한 보장을 만들 수 있다. GDPR·의료·금융 앱에서 이는 컴플라이언스 부담을 근본적으로 줄인다.

비용도 무시할 수 없다. 무료 티어 사용자 수백만 명에게 매 요청마다 토큰 과금을 물리면 단가는 금세 수익성을 잠식한다. 흔한 짧은 작업(분류, 태깅, 짧은 재작성)을 기기로 내리면 서버 비용은 그만큼 0으로 수렴한다.

소형 모델(SLM)의 부상

온디바이스를 실전화한 진짜 동력은 하드웨어가 아니라 모델이 작아졌다는 사실이다. 2023년만 해도 쓸만한 성능은 70B급에서 시작했지만, 2025~2026년의 1B~8B 소형 모델(Small Language Model)은 몇 년 전의 훨씬 큰 모델을 특정 과업에서 따라잡거나 넘어선다. 데이터 품질, 학습 레시피, 증류(distillation) 기법이 발전한 결과다.

핵심은 "범용 지능"을 포기하는 대신 내가 필요한 좁은 과업에서만 잘하면 된다는 관점 전환이다. 요약, 분류, 개체 추출, 문법 교정, 간단한 대화 라우팅 같은 작업은 3B 모델로도 충분히 실용적인 품질이 나온다. 반대로 복잡한 다단계 추론, 방대한 세계 지식, 긴 코드 생성은 여전히 대형 클라우드 모델의 영역이다.

• 1B 이하 — 키보드 예측, 텍스트 분류, 초경량 태깅. 거의 모든 최신 폰에서 실시간.
• 3B~4B — 요약·재작성·간단한 Q&A의 실전 스윗스팟. 4비트로 2~3GB 안쪽.
• 7B~8B — 품질 상한선. 플래그십에서만 쾌적, 중급기에선 발열·속도 타협 필요.

모델을 폰에 욱여넣는 기술: 양자화·증류·LoRA

7B 모델을 FP16으로 로드하면 14GB가 넘는다. 폰에 들어갈 리 없다. 이걸 실용 영역으로 끌어내리는 3대 압축·적응 기법이 있다.

양자화(Quantization)는 가중치의 정밀도를 낮추는 것이다. FP16(16비트)을 4비트 정수로 줄이면 메모리가 대략 1/4로 준다. GGUF는 llama.cpp 진영의 사실상 표준 포맷으로, Q4_K_M 같은 혼합 정밀도 방식이 품질과 크기의 균형점으로 널리 쓰인다. 4비트에서도 대부분의 과업은 품질 저하가 체감상 작지만, 3비트 이하로 내려가면 급격히 무너진다.

증류(Distillation)는 큰 "교사" 모델의 출력을 작은 "학생" 모델이 흉내 내도록 학습시키는 방법이다. 파라미터 수는 훨씬 적으면서도 교사의 행동 패턴을 상당 부분 물려받는다. 최근 강력한 소형 모델 상당수가 대형 모델로부터 증류된 결과물이다.

LoRA(Low-Rank Adaptation)는 베이스 모델을 통째로 재학습하지 않고, 작은 어댑터 행렬만 얹어 특정 과업에 적응시키는 기법이다. 어댑터는 보통 수 MB에 불과해 하나의 베이스 모델 위에 여러 개를 교체해 끼울 수 있다. Apple의 온디바이스 전략처럼 "하나의 베이스 + 과업별 어댑터" 구조가 앱에서 특히 매력적인 이유다.

하드웨어: NPU가 판을 바꿨다

모델이 작아진 만큼 하드웨어도 마중 나왔다. 요즘 모바일 SoC에는 GPU와 별개로 NPU(Neural Processing Unit)가 들어간다. 애플의 Neural Engine, 퀄컴 스냅드래곤의 Hexagon NPU, 구글 텐서의 TPU 계열이 대표적이다. NPU는 행렬 곱·합성곱 같은 신경망 연산에 특화되어 전력당 성능(TOPS/W)이 CPU·GPU보다 훨씬 좋다. 즉 같은 배터리로 더 오래, 덜 뜨겁게 추론할 수 있다.

다만 함정이 있다. NPU는 특정 연산·데이터 타입에만 최적화돼 있어, 임의의 LLM 그래프가 항상 NPU에서 완전 가속되는 건 아니다. 많은 런타임이 실제로는 GPU(Metal, Vulkan, OpenCL)에서 돌거나 CPU로 폴백한다. "NPU 지원"이라는 문구가 곧 "이 모델이 NPU에서 최대 속도로 돈다"를 뜻하지는 않는다는 점을 개발자는 반드시 검증해야 한다.

런타임 지형도

같은 모델도 어떤 추론 엔진으로 돌리느냐에 따라 이식성·속도·통합 난이도가 크게 갈린다. 주요 선택지를 정리하면 다음과 같다.

실무에서 가장 흔한 출발점은 llama.cpp다. GGUF 생태계가 크고, 거의 모든 플랫폼에 붙일 수 있으며, 양자화 옵션이 풍부하다. iOS·macOS 전용 앱이라면 MLX나 Core ML이 애플 하드웨어를 더 알뜰하게 쓴다. 안드로이드에서 빠르게 프로토타이핑하려면 MediaPipe의 LLM Inference API가 진입 장벽이 낮다.

# llama.cpp로 GGUF 모델을 로컬에서 돌려보기 (데스크톱 검증용)
# 4비트 양자화된 소형 모델을 받아 대화형으로 실행
./llama-cli \
  -m ./models/slm-3b-instruct-q4_k_m.gguf \
  -p "다음 문단을 한 문장으로 요약해줘:" \
  -n 128 \        # 최대 생성 토큰 수 제한(발열·지연 관리)
  -c 2048 \       # 컨텍스트 길이(메모리와 직결)
  -ngl 99         # 가능한 레이어를 GPU/Metal로 오프로딩

하이브리드 라우팅: 온디바이스와 클라우드의 분업

성숙한 제품은 "전부 온디바이스" 또는 "전부 클라우드"로 가지 않는다. 대신 요청의 성격에 따라 어디서 처리할지 라우팅한다. 쉽고 프라이버시가 민감하고 지연이 중요한 작업은 기기에서, 어렵고 방대한 지식이 필요한 작업은 클라우드로 보낸다. 애플 인텔리전스가 온디바이스 모델과 프라이빗 클라우드 컴퓨트를 나눠 쓰는 구조가 대표적인 사례다.

라우팅 판단 기준은 대개 이렇게 조합된다: 입력 길이/복잡도, 필요한 지식의 범위, 네트워크 가용성, 배터리 상태, 프라이버시 등급. 아래는 개념을 단순화한 의사코드다.

// 온디바이스 우선, 필요 시 클라우드로 승격하는 라우터
async function route(task) {
  // 1) 오프라인이거나 민감 데이터면 무조건 로컬
  if (!navigator.onLine || task.isSensitive) {
    return runOnDevice(task);
  }
  // 2) 간단한 작업은 로컬로 먼저 시도
  if (task.complexity < THRESHOLD) {
    const local = await runOnDevice(task);
    // 3) 로컬 신뢰도가 낮으면 클라우드로 승격
    if (local.confidence >= 0.7) return local;
  }
  // 4) 그 외에는 대형 클라우드 모델
  return runOnCloud(task);
}

이 패턴의 장점은 대부분의 트래픽을 기기에서 흡수해 서버 비용을 낮추면서도, 어려운 소수 요청에서는 대형 모델의 품질을 확보한다는 것이다. 단점은 두 개의 코드 경로와 두 가지 품질 특성을 동시에 관리해야 한다는 복잡성이다.

앱 개발자 관점: 무엇을 결정해야 하나

온디바이스를 도입할지 말지는 기능 단위로 판단하는 게 좋다. 다음 질문에 대부분 "예"라면 온디바이스가 유리하다: 작업이 짧고 반복적인가? 데이터가 민감한가? 오프라인에서도 동작해야 하는가? 무료 사용자 규모가 커서 서버 과금이 부담인가?

반대로 다음이라면 클라우드가 낫다: 최고 수준의 추론 품질이 필요한가? 자주 바뀌는 최신 지식을 다루는가? 저사양 기기 사용자 비중이 높은가? 앱 용량에 수 GB를 더 얹기 어려운가?

• 배포 크기 — 모델을 앱에 번들할지, 첫 실행 시 다운로드할지 결정. 앱스토어 용량 제한과 사용자 이탈을 저울질하라.
• 기기 티어링 — RAM·NPU 세대에 따라 온디바이스/클라우드를 자동 분기. 구형 기기엔 아예 서버 경로만 열어라.
• 발열·배터리 예산 — 생성 토큰 수 상한, 백그라운드 실행 금지, 연속 요청 쓰로틀링을 설계 초기에 넣어라.

한계와 냉정한 현실

과장을 걷어내면 온디바이스에는 분명한 천장이 있다. 첫째, 품질이다. 3B 모델은 좁은 과업에선 훌륭하지만 복잡한 다단계 추론, 정확한 사실 회상, 긴 문서 이해에서는 대형 모델에 크게 못 미친다. 환각(hallucination)도 소형 모델에서 더 두드러진다.

둘째, 메모리와 발열이다. 앞서 강조했듯 RAM은 냉정한 상한이고, 지속 추론은 폰을 뜨겁게 만들어 성능을 스로틀링시킨다. 셋째, 파편화다. 안드로이드 진영은 SoC·NPU·드라이버가 제각각이라 "모든 기기에서 동일한 속도"를 보장하기가 매우 어렵다. iOS는 상대적으로 균일하지만 그만큼 애플 생태계에 묶인다.

그래서 2026년 현재의 현실적 결론은 대체가 아니라 분업이다. 온디바이스는 클라우드를 몰아내는 게 아니라, 흔하고 가볍고 민감한 작업을 흡수해 클라우드가 정말 필요한 곳에 집중하도록 만드는 계층이다.

2026년 동향

몇 가지 흐름이 뚜렷하다. (1) 소형 모델의 품질 곡선이 계속 가팔라지며, 작년의 7B급 품질을 올해의 3B급이 근접해 온다. (2) NPU 활용도가 올라가며 런타임들이 실제로 NPU 경로를 안정화하고 있다. (3) LoRA 어댑터 스와핑으로 "하나의 베이스 + 과업별 개성"을 구현하는 앱이 늘고 있다. (4) OS 차원에서 시스템 제공 온디바이스 모델(플랫폼 기본 SLM)에 앱이 API로 접근하는 방식이 표준화되며, 개별 앱이 모델을 번들할 필요가 줄어든다.

정리하면, 온디바이스 AI는 "가능한가?"의 단계를 지나 "어떤 작업을 어디서 처리할 것인가?"라는 아키텍처 설계의 문제로 넘어왔다. 이 질문에 대한 답을 지금 준비해두는 팀이 다음 세대 모바일 경험의 지연·비용·프라이버시에서 우위를 가져간다.

자주 묻는 질문

온디바이스 LLM은 ChatGPT 같은 클라우드 모델을 대체하나요?

아니요. 대체가 아니라 분업입니다. 소형 온디바이스 모델은 요약·분류·재작성처럼 흔하고 가벼운 작업, 그리고 프라이버시·오프라인이 중요한 상황에 강합니다. 반면 복잡한 추론이나 방대한 최신 지식이 필요한 작업은 여전히 대형 클라우드 모델이 우위입니다. 성숙한 제품은 요청 성격에 따라 두 경로를 라우팅합니다.

7B 모델을 폰에서 돌리려면 RAM이 얼마나 필요한가요?

4비트(Q4_K_M) 양자화 기준으로 모델 자체가 대략 4GB를 차지하고, 여기에 KV 캐시와 런타임 오버헤드가 더해집니다. 따라서 8GB RAM 기기에서는 빠듯하고 12GB 이상이 쾌적합니다. RAM은 코어 수보다 냉정한 상한이며, 부족하면 OS가 앱을 메모리 압박으로 종료시킬 수 있습니다.

양자화하면 품질이 많이 떨어지나요?

4비트까지는 대부분의 실용 과업에서 체감 저하가 작습니다. Q4_K_M 같은 혼합 정밀도 방식이 크기와 품질의 균형점으로 널리 쓰입니다. 다만 3비트 이하로 내려가면 품질이 급격히 무너지므로, 극단적 메모리 제약이 아니라면 권장하지 않습니다.

NPU를 쓰면 항상 더 빠른가요?

반드시 그렇지는 않습니다. NPU는 전력당 성능이 뛰어나 발열·배터리에 유리하지만, 특정 연산·데이터 타입에만 최적화돼 있어 임의의 LLM 그래프가 항상 완전 가속되지는 않습니다. 많은 런타임이 실제로는 GPU에서 돌거나 CPU로 폴백합니다. "NPU 지원"이라는 표기는 반드시 실제 기기에서 벤치마크로 검증해야 합니다.

어떤 런타임으로 시작하는 게 좋나요?

크로스 플랫폼과 방대한 GGUF 생태계가 필요하면 llama.cpp가 무난한 출발점입니다. iOS·macOS 전용이면 MLX나 Core ML이 애플 하드웨어를 더 알뜰하게 씁니다. 안드로이드에서 빠르게 프로토타이핑하려면 구글의 MediaPipe LLM Inference API가 진입 장벽이 낮습니다.

온디바이스 추론이 정말 "무료"인가요?

서버 토큰 과금이 없다는 의미에서만 무료입니다. 추론은 사용자 기기의 배터리와 발열이라는 실물 자원을 소모하므로 비용이 사라지는 게 아니라 사용자에게 이전됩니다. 따라서 생성 토큰 수 상한, 연속 요청 쓰로틀링, 백그라운드 실행 제한을 설계 초기에 반영해야 합니다.