On-Device AI의 현실적 한계 — 스마트폰과 노트북이 LLM을 담기 위해 넘어야 할 벽

스마트폰에서 LLM이 돌아간다는 말은 이제 새롭지 않다. Qualcomm은 Snapdragon 8 Gen 3부터 온디바이스 AI를 마케팅 전면에 내세웠고, Apple은 iPhone 15 Pro 이후로 줄곧 “기기 내 AI 처리”를 강조하고 있다. 그런데 실제로 써보면 늘 뭔가 어설프다는 인상을 지우기 어렵다. 느리거나, 금방 뜨거워지거나, 모델 크기가 너무 작아서 쓸 만한 답변이 안 나오거나.

NPU는 GPU의 축소판이 아니다

NPU(Neural Processing Unit)를 GPU의 작은 버전이라고 이해하면 실망이 빠르다. 두 칩의 설계 철학은 근본부터 다르다. GPU는 범용 병렬 연산 엔진이다. 수천 개의 CUDA/셰이더 코어가 서로 다른 연산을 동시에 처리할 수 있고, 이것이 게임 렌더링과 딥러닝 학습 모두를 가능하게 한다. 반면 NPU는 처음부터 행렬 곱셈(GEMM)과 합성곱 연산에 특화된 가속기다. 연산 단위가 더 굵고, 메모리 접근 패턴이 정해져 있으며, 유연성 대신 특정 워크로드에서의 전력 효율을 택했다.

현재 스마트폰에 들어가는 NPU를 구체적으로 살펴보면 차이가 선명해진다. Qualcomm의 Hexagon NPU는 Snapdragon 8 Elite 기준 45 TOPS(초당 조 연산)를 제공한다. 내부적으로 Hexagon Tensor Processor라는 전용 연산 블록과 벡터 익스텐션으로 구성되며, QNN SDK를 통해 모델을 컴파일하면 이 하드웨어 경로를 직접 타게 된다. MediaTek의 APU(AI Processing Unit)는 Dimensity 9400 기준 50 TOPS를 주장하며, 삼성 Exynos 2500의 NPU는 약 34 TOPS 수준이다. 숫자만 보면 적지 않아 보인다.

TOPS가 속이는 이유

문제는 TOPS 숫자가 INT8 또는 INT4 연산 기준이라는 점이다. LLM 추론에서 가중치는 INT4나 INT8로 양자화할 수 있지만, 활성화 값(activation)과 어텐션 스코어는 더 높은 정밀도가 필요한 경우가 많다. 혼합 정밀도 연산에서 NPU의 실효 처리량은 최대 사양의 절반 이하로 떨어지기도 한다. 또한 TOPS는 순수 MAC(Multiply-Accumulate) 연산만 센다. 실제 LLM 추론에는 GEMM 외에도 소프트맥스, 레이어 정규화, 위치 인코딩 계산 등 NPU가 잘 가속하지 못하는 연산이 섞여 있다. 결국 벤치마크에서 보이는 TOPS와 실제 token/s 수치 사이에는 상당한 간극이 생긴다.

더 근본적인 병목은 메모리 대역폭이다. LLM의 디코딩(토큰 생성) 단계는 메모리 대역폭 바운드(memory bandwidth-bound) 연산이다. 각 토큰을 생성할 때마다 모델의 전체 가중치를 메모리에서 한 번씩 읽어야 하는데, 이 읽기 속도가 연산 속도보다 훨씬 느리다. 서버용 H100 GPU는 HBM3 메모리로 3.35TB/s의 대역폭을 제공한다. Snapdragon 8 Elite가 탑재한 LPDDR5X 메모리의 대역폭은 약 77GB/s다. 단순 수치로만 봐도 40배 이상 차이다. 이 격차가 온디바이스 LLM이 초당 수십 토큰을 넘기기 어려운 가장 큰 이유다.

4GB 미만 모델만 현실적인 이유

메모리 대역폭 외에 또 다른 벽은 물리적 DRAM 용량이다. 대부분의 스마트폰은 12~16GB의 통합 메모리를 운영체제, 앱, 카메라 버퍼 등과 공유한다. LLM에 할당 가능한 용량은 현실적으로 4~6GB 수준이다. 이 제약 안에 맞추려면 INT4 양자화가 사실상 필수다. Llama 3.2 3B를 INT4로 양자화하면 약 1.7GB, Qwen2.5 7B는 약 4.4GB다. 7B 이상 모델을 스마트폰에서 편안하게 돌리는 것은 여전히 무리다.

양자화는 공짜가 아니다. INT8 양자화는 성능 저하가 미미하지만, INT4로 내려오면 특히 reasoning이나 instruction-following 품질이 눈에 띄게 떨어진다. AWQ(Activation-aware Weight Quantization)나 GPTQ 같은 고급 양자화 기법을 쓰면 손실을 줄일 수 있지만, 이를 모바일 런타임에서 지원하는 파이프라인을 구축하는 것도 간단한 일이 아니다.

Prefill이 특히 느린 이유

LLM 추론에는 두 단계가 있다. 입력 프롬프트를 처음 처리하는 Prefill 단계와 토큰을 하나씩 생성하는 Decode 단계다. Prefill은 입력 시퀀스 전체를 병렬로 처리하기 때문에 GPU에서는 빠르다. 그런데 모바일 NPU에서 Prefill이 유독 느린 이유가 있다. NPU는 정해진 배치 크기와 시퀀스 길이를 기준으로 컴파일된 커널을 실행하는 방식이 많다. 실제 입력 길이가 고정 형태와 다르면 패딩이 발생하거나, 동적 형태를 처리하는 덜 최적화된 경로를 타게 된다. 긴 시스템 프롬프트나 RAG 컨텍스트가 있을 때 첫 응답이 특히 더디게 나오는 게 이 때문이다.

모바일 AI 처리 최적화와 배터리 제약

이미지 출처: Unsplash

런타임 생태계의 파편화

모델을 모바일에서 실행하는 런타임 선택지는 여러 개다. Meta의 ExecuTorch는 PyTorch 모델을 모바일에서 실행하기 위한 경량 런타임으로, Android와 iOS 모두를 지원한다. Apple CoreML은 iOS/macOS 전용으로 ANE를 가장 잘 활용하지만 Apple 생태계 밖에선 쓸 수 없다. ONNX Runtime은 크로스플랫폼을 지향하며 Qualcomm QNN, ARM NN 등 다양한 백엔드를 플러그인 방식으로 지원한다. Qualcomm의 QNN SDK는 Hexagon NPU를 직접 타는 가장 빠른 경로지만 Snapdragon 칩 전용이다.

문제는 이 런타임들이 지원하는 연산자(operator) 집합이 다르다는 점이다. 최신 LLM 아키텍처에 등장하는 Grouped Query Attention, SwiGLU 활성화 함수, 슬라이딩 윈도우 어텐션 등이 특정 런타임에서 지원되지 않으면 CPU 폴백이 일어나 속도가 급격히 떨어진다. 새 모델 아키텍처가 나오고 모바일 런타임이 이를 따라잡기까지 몇 달의 시차가 생기는 것도 일상적인 일이다.

발열과 배터리: 지속 추론이 불가능한 이유

스마트폰은 열 설계 전력(TDP)이 극도로 제한된 환경이다. 얇은 폼팩터와 수동 냉각(팬 없음) 구조에서 지속적으로 높은 전력을 소비하면 곧바로 열 제한(thermal throttling)이 걸린다. Snapdragon 8 Elite의 최대 전력은 약 10~12W 수준이지만, 지속 추론 시 발열 억제를 위해 클럭을 낮추면 실질 성능은 그 절반 이하가 된다. 3분 연속 추론 테스트에서 초당 토큰 수가 처음의 40% 수준으로 떨어지는 사례도 측정된 바 있다. 배터리 소모도 빠르다. LLM 추론은 SoC 전체를 높은 부하로 유지하기 때문에 배터리 집약도가 일반 앱 대비 5~10배 높다.

AI PC의 현실

노트북 쪽은 조금 다르다. “AI PC”로 분류되는 Qualcomm X Elite(Snapdragon X Elite), Intel Core Ultra(Meteor Lake/Lunar Lake), AMD Ryzen AI 300 시리즈는 각각 45~50 TOPS 내외의 NPU를 내장한다. Microsoft Copilot+ PC 인증 기준이 40 TOPS인 이유도 여기 있다. 열 제약이 스마트폰보다 덜 엄격하고, LPDDR5X 메모리를 32~64GB까지 탑재할 수 있어 7B~13B 모델을 비교적 안정적으로 돌릴 수 있다. Qualcomm X Elite의 경우 Llama 3 8B INT4 기준 약 20~30 token/s가 나온다는 측정치가 있다.

그러나 소프트웨어 지원이 아직 불균등하다. Windows Copilot Runtime과 WinML이 NPU를 활용하는 표준 경로를 제공하지만, 서드파티 앱이 이를 실제로 채용하기까지 시간이 걸린다. LM Studio, llama.cpp 같은 로컬 LLM 도구들은 ARM64 네이티브 컴파일을 지원하기 시작했지만 NPU를 직접 타는 경로는 여전히 개발 중이거나 제한적이다. 결국 현재 AI PC의 실용적 강점은 NPU보다 전력 효율 좋은 CPU+통합 메모리 조합에 더 가깝다.

클라우드와 기기의 분업

이 모든 제약을 고려하면 “온디바이스 전용”이나 “클라우드 전용”보다 Hybrid Inference 아키텍처가 현실적인 방향으로 보인다. 간단한 분류, 키워드 감지, 짧은 응답 생성은 기기에서 처리해 프라이버시를 지키고 오프라인에서도 작동하게 한다. 복잡한 추론, 긴 컨텍스트, 최신 모델이 필요한 작업은 클라우드로 넘긴다. Apple Intelligence가 이 구조를 가장 명시적으로 표방하고 있으며, Google의 Gemini Nano + Gemini Pro 분기 로직도 같은 맥락이다.

하드웨어가 빠르게 진화하는 것은 사실이다. 2~3년 후 스마트폰 NPU가 100 TOPS를 넘고 LPDDR6 메모리 대역폭이 두 배로 늘어난다면 지금 불가능한 모델 크기가 현실이 될 수 있다. 그러나 모델도 같이 커지고 있다. 결국 온디바이스 AI의 성숙은 하드웨어 스펙만이 아니라 더 작고 더 효율적인 모델 아키텍처, 런타임 소프트웨어 생태계의 성숙, 그리고 어떤 기능을 기기에서 처리할지에 대한 제품 설계 판단 세 가지가 동시에 갖춰질 때 이루어질 것이다. 지금은 그 중 어느 하나도 완성된 상태가 아니다.


출처

댓글 남기기