Google Gemma 4, iPhone에서 완전 오프라인 AI 추론 네이티브 실행
Google Gemma 4 Runs Natively on iPhone with Full Offline AI Inference
TL;DR Highlight
Google의 오픈소스 모델 Gemma 4가 iPhone에서 클라우드 없이 완전 로컬 추론으로 실행되어 온디바이스 AI가 실험 단계를 벗어나 실용화 단계에 진입했다.
Who Should Read
모바일 앱에 AI 기능을 추가하거나 프라이버시·오프라인 요구사항이 있는 엣지 AI 솔루션을 검토 중인 iOS/Android 개발자.
Core Mechanics
- Google의 오픈소스 모델 패밀리인 Gemma 4가 iPhone에서 완전 로컬, 완전 오프라인으로 추론을 실행할 수 있게 됐다. API 호출이나 클라우드 의존성이 전혀 없다.
- 모델 라인업 중 플래그십 31B 변형은 Qwen 3.5의 27B 모델과 벤치마크에서 비슷한 성능을 보였다. 파라미터 수는 Gemma가 약 40억 개 더 많다.
- 모바일 배포를 위해 특별히 설계된 E2B(20억 파라미터)와 E4B(40억 파라미터) 경량 변형이 있으며, Google 앱 자체도 E2B를 기본 추천한다. 메모리와 발열 한계를 고려한 선택이다.
- 시작 방법은 App Store에서 'Google AI Edge Gallery' 앱을 내려받고 원하는 모델 변형을 선택하면 끝이다. 별도 설정이나 계정 없이 바로 로컬 추론이 가능하다.
- Google AI Edge Gallery는 단순 텍스트 인터페이스가 아니라 이미지 인식, 음성 상호작용, 확장 가능한 Skills 프레임워크까지 포함한 플랫폼 성격이다. 개발자가 온디바이스 AI 실험의 기반으로 활용하도록 포지셔닝됐다.
- 추론은 iPhone의 GPU(Metal)를 통해 실행되며, 실제 응답 지연이 눈에 띄게 낮다고 보고됐다. 실제 벤치마크 수치로는 iPhone 16 Pro에서 Prefill 속도 231 t/s, Decode 속도 16 t/s, 첫 토큰까지의 시간 1.16초가 측정됐다.
- 오프라인 동작 가능성은 현장 업무, 의료 환경, 데이터 프라이버시 규정상 클라우드 처리가 불가능한 엔터프라이즈 사용 사례에서 실질적인 가치가 있다.
- Android에서도 AI Core 또는 llama.cpp를 통해 동일하게 실행 가능하다고 커뮤니티에서 언급됐다.
Evidence
- GPU(Metal)를 사용하는 것에 대해 비판적인 시각이 있었다. 한 댓글에서 'Apple의 전용 NPU인 ANE(Apple Neural Engine)용 커스텀 어텐션 커널 컴파일을 포기하고 Metal로 우회한 것 같다'며, Metal은 포팅이 쉽지만 전용 NPU 대비 배터리 소모가 훨씬 크다고 지적했다. ANE 백엔드를 재작성하기 전까지는 화려한 기술 데모일 뿐 프로덕션 도구로 보기 어렵다는 평가였다.
- 한 개발자가 Gemma 4를 사용해 iPhone에서 동작하는 오프라인 코드 생성 앱 'pucky'를 직접 만들어 GitHub에 공개했다(https://github.com/blixt/pucky). 4B 모델도 기술적으로 실행되지만 메모리 제약으로 2B로 자동 전환되며, TypeScript 단일 파일을 생성하고 oxc로 컴파일하는 방식이다. App Store 심사를 통과하기 어려워 Xcode에서 직접 빌드해야 한다고 밝혔다.
- App Store에서 로컬 LLM을 포함한 앱 배포를 시도했다가 Apple의 가이드라인 2.5.2 조항에 막혔다는 경험담이 공유됐다. Apple이 앱 스토어 내 LLM 활용을 막고 있다는 지적으로, 온디바이스 AI 앱의 배포 경로가 제한될 수 있다는 실질적인 우려다.
- Gemma 4의 모델 구조 특성에 대한 비판도 있었다. 'Gemma 4는 거의 모든 가중치를 활성화하는 경향이 있어 전력 소모가 크다'며, MoE(Mixture of Experts, 전체 파라미터 중 일부만 선택적으로 활성화하는 구조) 방식으로 한 번에 약 30억 파라미터만 쓰는 Qwen3-coder에 비해 효율이 떨어진다는 의견이 나왔다. 아직 테이블에 남겨진 성능 여지가 많다는 평가다.
- 소형 모델의 신뢰성에 대한 경고도 있었다. '개한테 아보카도를 줘도 되나요?'라고 물었더니 '네, 됩니다'라고 자신 있게 틀린 답변을 했다는 경험이 공유됐다. 소형 온디바이스 모델을 의료나 안전 관련 판단에 그대로 사용하는 것은 위험하다는 점을 상기시켜주는 사례다.
How to Apply
- 데이터 프라이버시 규정 때문에 클라우드 AI API를 사용하지 못하는 의료, 금융, 군사 등 엔터프라이즈 현장 앱을 개발하는 경우, Google AI Edge Gallery와 Gemma 4 E2B/E4B 변형을 온디바이스 추론 기반으로 채택하면 규정 준수와 AI 기능을 동시에 충족할 수 있다.
- iOS 앱에 AI 기능을 내장하려는 경우, App Store 배포 시 Apple의 가이드라인 2.5.2 조항에 막힐 수 있으니 사전에 TestFlight 또는 엔터프라이즈 배포 경로를 검토해두는 것이 좋다. 커뮤니티 개발자 사례처럼 Xcode 직접 빌드 및 사이드로딩 방식도 대안이 될 수 있다.
- 모바일 앱에 LLM을 연동할 때 모델 크기 선택이 중요한데, 메모리와 발열을 고려하면 E4B보다 E2B가 현실적이다. 실제로 4B를 시도해도 메모리 제약으로 자동으로 2B로 폴백되는 경우가 있으니, 처음부터 E2B를 기준으로 UX를 설계하는 것이 안전하다.
- Gemma 4 기반 온디바이스 추론의 배터리 소모가 우려된다면, 현재 GPU(Metal) 기반 백엔드 대신 ANE(Apple Neural Engine) 지원이 추가될 때까지 배터리 민감 시나리오에서는 사용 빈도 제한 로직(예: 백그라운드 처리 최소화, 짧은 컨텍스트 유지)을 추가로 구현해두는 것이 좋다.
Terminology
관련 논문
Claude Code는 프롬프트 읽기 전에 33k 토큰을 전송한다; OpenCode는 7k
동일한 모델과 작업 환경에서 Claude Code와 OpenCode의 실제 토큰 사용량을 API 레벨에서 측정한 결과, Claude Code가 시스템 프롬프트 오버헤드만으로 OpenCode 대비 4.7배 더 많은 토큰을 소비한다는 것을 확인했다.
Mesh LLM: iroh 기반 분산 AI 컴퓨팅
사무실, 집, 클라우드에 흩어진 GPU들을 하나의 OpenAI 호환 API로 묶어주는 분산 LLM 실행 시스템으로, 비싼 API 비용 없이 큰 모델을 직접 운영할 수 있다.
Frugon – LLM API 호출 로그를 분석해서 더 싼 모델로 대체 가능한 구간을 찾아주는 로컬 도구
내 LLM API 비용이 어디서 새는지 로컬에서 분석해주는 오픈소스 CLI 도구로, 비싼 모델 대신 저렴한 모델로 전환 가능한 호출을 골라낸다.
로컬에서 SOTA LLM 실행하기 완전 가이드 (하드웨어부터 설정까지)
2천 달러짜리 RTX 3090 한 장부터 4만 달러짜리 RTX PRO 6000 4장 셋업까지, 로컬에서 최신 LLM을 직접 돌리는 방법을 하드웨어 선택·구성·실행 설정까지 통째로 정리한 실전 가이드다.
Manticore Search에서 ONNX 경로를 재설계해 임베딩 속도를 14배 높인 방법
Manticore Search가 기존 SentenceTransformers/Candle 백엔드를 ONNX Runtime으로 교체해 텍스트 임베딩 생성 속도를 평균 14배 향상시켰다. 별도 모델 서비스 없이 DB 내부에서 직접 임베딩을 처리하는 구조에서 INSERT 속도가 곧 임베딩 속도이기 때문에 이 개선은 실질적인 ingest 처리량 향상으로 직결된다.
Asymmetric Quantization: 97% 스토리지 절감으로 Late Interaction 검색 품질 유지하기
멀티벡터 검색 모델의 문서 벡터를 1비트 이진값으로 압축하고 쿼리 벡터만 int8로 유지하는 비대칭 양자화 기법으로, 스토리지를 97% 줄이면서 검색 품질 손실을 0.61점(NDCG@10 기준)에 그치게 만든 실제 프로덕션 적용 사례다.