모바일 온디바이스 AI 최적화: Android·iOS에서 7B 모델을 다루는 현실적인 기준

스마트폰에서 7B(70억 파라미터) 언어 모델을 돌릴 수 있느냐는 질문에는 기종명만으로 답할 수 없습니다. 같은 모델도 가중치 정밀도, 문맥 길이, 런타임, 연산자 지원, 기기의 사용 가능한 메모리와 열 상태에 따라 실행 가능 여부와 체감 속도가 달라집니다.

따라서 목표를 “7B를 무조건 NPU에 올리기”로 잡기보다, 사용자가 원하는 작업을 가장 작은 모델로 해결하고 실제 기기에서 지속 가능한 성능을 확인하는 순서가 안전합니다. 이 글은 그 판단 과정을 Android와 Apple 플랫폼의 공식 도구에 맞춰 설명합니다.

먼저 결정할 것: 정말 생성형 모델이 필요한가

온디바이스 AI의 장점은 오프라인 동작, 짧은 네트워크 왕복 시간, 서버 추론료 절감 가능성입니다. 다만 “온디바이스”라는 말만으로 프라이버시가 보장되지는 않습니다. 입력, 로그, 분석 SDK, 오류 보고, 클라우드 폴백까지 외부 전송이 없는지 제품 전체의 데이터 흐름을 확인해야 합니다.

기능별 출발점은 다음과 같습니다.

요구사항	먼저 검토할 선택	이유
OCR, 바코드, 분류, 객체 탐지	플랫폼의 사전 구축 API 또는 작은 전용 모델	생성형 LLM보다 메모리와 전력 부담이 작고 결과를 검증하기 쉽습니다.
짧은 요약, 재작성, 제한된 질의	OS가 제공하는 온디바이스 생성 API	모델 배포와 기기별 가속기 차이를 플랫폼이 더 많이 처리합니다.
고유한 도메인·모델·출력 형식	사용자 모델 + 플랫폼 런타임	모델과 디코딩을 직접 통제할 수 있지만 지원 기기와 품질 검증 책임도 커집니다.
긴 문서, 최신 지식, 복잡한 추론	하이브리드 또는 클라우드 폴백	긴 문맥과 큰 모델이 요구하는 메모리를 모바일에 고정 배정하지 않아도 됩니다.

Android 공식 가이드도 생성형 작업과 전통적 ML을 구분합니다. Gemini Nano 기반 기능에는 ML Kit GenAI API를, 사용자 정의 분류·탐지 모델에는 LiteRT를 우선 경로로 안내하며, 큰 문서나 추가 지식이 필요한 경우에는 하이브리드 구성을 고려하라고 설명합니다(Android AI/ML 솔루션 가이드).

7B 4비트 모델이 차지하는 메모리

가중치만 놓고 보면 필요한 바이트는 대략 다음과 같이 계산할 수 있습니다.

파라미터 수 × 가중치 비트 수 ÷ 8

7B 모델의 이론적 가중치 크기는 FP16 약 14GB, INT8 약 7GB, 4비트 약 3.5GB입니다. 그러나 3.5GB는 실행 메모리가 아니라 가중치의 하한 추정치입니다. 실제로는 그룹별 scale과 zero point 같은 양자화 메타데이터, 토크나이저와 런타임, 중간 활성값, 입력·출력 버퍼, KV 캐시, 앱 UI가 같은 메모리 예산을 나눠 씁니다.

특히 KV 캐시는 대화가 길어질수록 커집니다. KV 캐시 2비트 양자화를 연구한 KIVI도 메모리 절감과 함께 key와 value에 서로 다른 양자화 축이 필요하다는 결과를 보고했습니다. 이는 “캐시도 낮은 비트로 바꾸면 끝”이 아니라 런타임 구현과 품질 확인이 필요하다는 뜻입니다(KIVI 논문).

실무에서는 다음 순서로 예산을 잡는 편이 낫습니다.

지원해야 할 기기군의 사용 가능한 메모리 하한을 정합니다.
앱 기본 사용량과 OS 여유분을 먼저 제외합니다.
남은 예산으로 가중치, 최대 문맥 길이, KV 캐시 정밀도를 함께 정합니다.
여유가 없으면 문맥을 줄이고, 더 작은 모델을 선택한 뒤, 마지막에 공격적인 양자화를 검토합니다.

이 계산만으로 실행을 보장할 수는 없지만, 맞지 않는 7B 후보를 기기 통합 전에 빠르게 제외할 수 있습니다.

4비트 양자화: 기본 후보이지 무료 성능 향상은 아니다

양자화는 FP16·FP32 가중치를 더 적은 비트로 표현해 저장 공간과 메모리 이동량을 줄입니다. 3~~8비트 모델을 비교한 1차 연구에서는 총 비트 예산 대비 정확도 관점에서 4비트가 강한 선택이었고, 작은 양자화 블록이 3~~5비트 구간의 품질에 영향을 주었습니다(The case for 4-bit precision). GPTQ 연구는 보정 데이터를 활용하는 사후 양자화로 대형 Transformer의 3·4비트 가중치 압축 가능성을 보였습니다(GPTQ 논문).

하지만 논문의 GPU 결과나 다른 모델의 정확도 저하 폭을 모바일 앱에 그대로 옮기면 안 됩니다. 실제 이점은 런타임에 해당 정밀도의 최적화 커널이 있는지, 일부 연산이 CPU로 폴백되는지, 역양자화 비용이 얼마나 드는지에 달려 있습니다.

그래서 양자화 후보는 최소한 다음 세 가지를 함께 비교해야 합니다.

기준 모델과 8비트·4비트 모델의 실제 업무 품질
모델 로드 시간, 첫 토큰 지연(TTFT), 이후 생성 속도(tokens/s)
최대 메모리, 작업당 에너지, 반복 실행 시 온도와 성능 하락

정확도 하락이 크면 QAT(양자화 인식 학습)나 보정 데이터 기반 PTQ를 검토할 수 있습니다. 단, “4비트”라는 이름만 같아도 그룹 크기, 가중치·활성값 정밀도, 파일 형식이 다르면 품질과 가속기 호환성이 달라집니다.

Android: API 선택과 가속기 폴백을 분리해서 본다

Android에서는 하나의 NPU API가 모든 기기에서 같은 성능을 제공한다고 가정하면 안 됩니다. 공식 문서는 다음 두 경로를 구분합니다.

Gemini Nano 기반 기능: ML Kit GenAI API

요약, 재작성, 이미지 이해처럼 제공되는 작업 범위와 토큰 제한 안에서 해결되는 기능이라면 ML Kit GenAI API가 우선 후보입니다. 이 API는 Gemini Nano와 AICore를 기반으로 하지만, 앱이 저수준 AICore 통합을 직접 관리하는 경로보다 상위 API를 통해 호환성과 배포를 다루는 방식입니다. 지원 기기와 입력 제한은 기능별 문서에서 확인해야 합니다(Android AI/ML 솔루션 가이드).

사용자 정의 모델: LiteRT

직접 학습하거나 변환한 모델에는 Android의 공식 ML 추론 런타임인 LiteRT를 사용할 수 있습니다. LiteRT는 Google Play services를 통한 런타임과 GPU·NPU delegate를 제공하지만, 실제 가속은 모델 연산자와 기기 delegate 지원에 따라 달라집니다(Android의 LiteRT 안내). Qualcomm AI Engine Direct delegate처럼 칩 공급사별 경로도 있으므로 CPU, GPU, NPU 후보를 각각 벤치마크해야 합니다(LiteRT NPU delegate).

Android 장기 실행 테스트에서는 최고 속도 한 번보다 지속 성능이 중요합니다. 기기는 열 한계에 도달하면 성능을 낮출 수 있으며, Android Thermal API는 현재 상태와 thermal headroom을 확인할 수 있는 수단을 제공합니다(Android Thermal API).

Apple 플랫폼: Core AI와 Core ML의 역할을 구분한다

Apple은 2026년 사용자 모델을 기기에 가져오는 새 프레임워크로 Core AI를 공개했습니다. Core AI는 모델 변환·최적화, Swift 추론 API, Xcode 프로파일링, 기기별 specialization과 ahead-of-time 컴파일 흐름을 제공합니다(Meet Core AI, Core AI 통합 가이드). 최신 SDK를 대상으로 생성형 사용자 모델을 새로 통합한다면 먼저 검토할 경로입니다.

기존 앱과 전통적 ML 모델에는 Core ML이 여전히 중요한 기반입니다. Core ML은 CPU, GPU, Neural Engine을 활용하며, Core ML Tools는 pruning, palettization, INT4·INT8 가중치 양자화를 지원합니다(Core ML, Core ML Tools 최적화 개요). 다만 Apple 문서도 압축 가중치의 해제 전략과 실행 장치가 조합마다 달라 특정 모델과 Apple silicon에서 직접 시험하라고 권고합니다.

메모리가 부족할 때 flash 저장소에서 필요한 가중치만 읽는 방법도 연구되고 있습니다. Apple의 LLM in a Flash 논문은 DRAM보다 큰 모델을 다루는 windowing과 row-column bundling을 제안했지만, 이는 연구 결과이지 모든 iPhone 앱이 자동으로 얻는 Core ML/Core AI 기능이나 보장된 배수 성능은 아닙니다(Apple Machine Learning Research).

Qualcomm 기기: 칩 홍보 수치보다 대상 모델 프로파일을 본다

NPU의 TOPS는 정밀도와 측정 조건을 생략하면 앱 성능을 예측하기 어렵습니다. 같은 칩에서도 모델의 연산자 지원과 CPU·GPU·NPU 분할, 메모리 대역폭, 열 상태에 따라 결과가 달라집니다.

Snapdragon 기기를 목표로 한다면 Qualcomm AI Hub Workbench에서 PyTorch·ONNX 모델을 대상 런타임용으로 변환하고, 양자화한 뒤, 호스팅된 실제 기기에서 지연·최대 메모리·연산 장치 사용률과 수치 출력을 확인할 수 있습니다(Qualcomm AI Hub, AI Hub FAQ). 이 결과도 최종 앱의 토큰화, 디코딩 루프, UI, 발열을 포함하지는 않으므로 실제 앱과 보유 기기 테스트를 대체하지 않습니다.

실기기 합격 기준: 평균 하나로 끝내지 않는다

아래 기준을 기능 요구사항과 함께 먼저 고정하면 “실행됨”을 “출시 가능함”으로 오해하는 일을 줄일 수 있습니다.

축	기록할 값	판단 포인트
품질	대표 한국어 입력 세트의 성공률·오류 유형	양자화 전 기준 모델과 같은 채점 규칙을 사용합니다.
응답성	모델 로드, TTFT, p50·p95 tokens/s	첫 실행과 warm 실행을 분리합니다.
메모리	로드 후·prefill 후·최대 문맥의 peak	메모리 경고와 앱 종료 여부도 기록합니다.
지속 성능	1회, 5분, 10분 반복 실행	속도 하락과 thermal 상태를 함께 봅니다.
제품 영향	배터리, 설치·다운로드 크기, 오프라인 성공률	모델 파일 전달 실패와 저장 공간 부족도 포함합니다.

테스트 기기군은 최고 사양 한 대가 아니라 최소 지원 기기, 주력 기기, 최신 기기를 포함해야 합니다. Android는 SoC와 delegate 조합별로, Apple은 지원 OS와 silicon 세대별로 결과를 나눠 보관합니다.

결론: 7B는 목표가 아니라 예산 항목이다

모바일 온디바이스 AI 최적화의 핵심은 가장 큰 모델을 스마트폰에 넣는 일이 아닙니다. 사용자 작업을 만족하는 최소 모델을 고르고, 가중치와 KV 캐시가 차지할 메모리를 계산하며, 플랫폼 공식 런타임에서 품질·지연·전력·발열을 함께 검증하는 일입니다.

7B 4비트 모델은 일부 기기와 짧은 문맥에서 현실적인 후보가 될 수 있지만 모든 Android와 iPhone에서 “끊김 없이” 동작한다는 보장은 아닙니다. 지원 범위를 넓혀야 한다면 더 작은 전용 모델, OS 제공 모델, 하이브리드 폴백이 종종 더 좋은 제품 결정입니다.