요약: Google이 Gemma 4 12B 개발자 가이드를 공개했습니다. 12B급 dense 멀티모달 모델이 로컬 실행, 음성 입력, 이미지·영상 처리, OpenAI 호환 로컬 API 서버까지 한 번에 다루기 시작했습니다. 클라우드 API만 쓰던 개발자도 이제 로컬 추론을 제품 설계 옵션으로 다시 봐야 합니다.
Google은 Gemma 4 12B를 dense multimodal model로 설명합니다. 눈에 띄는 지점은 세 가지입니다. 첫째, encoder-free 구조입니다. 전통적인 멀티모달 모델은 이미지와 오디오를 별도 encoder로 처리한 뒤 LLM에 넘깁니다. Gemma 4 12B는 이미지 패치와 오디오 프레임을 LLM backbone에 더 직접적으로 넣는 방식을 택했습니다. Google은 이 구조가 멀티모달 지연 시간을 줄이고 fine-tuning을 단순하게 만든다고 설명합니다.
둘째, 16GB VRAM 또는 unified memory급 장비에서 로컬 실행을 목표로 했다는 점입니다. 서버 GPU 없이도 개발자 노트북에서 실험할 수 있는 범위를 넓힙니다. 셋째, LiteRT-LM의 serve 명령으로 OpenAI 호환 로컬 API 서버를 띄울 수 있다는 점입니다. Continue, Aider, OpenCode 같은 도구가 로컬 endpoint에 붙을 수 있다는 뜻입니다.
Gemma 4 12B는 자동 음성 인식, diarization, 영상 이해, 코딩, agentic reasoning을 지원한다고 소개됐습니다. 예시로는 5분 영상에서 1FPS로 추출한 313개 프레임과 오디오를 함께 처리하는 사례가 공개됐습니다. 이 수치는 제품 수준 성능을 보장하지는 않지만, 로컬 멀티모달 agent 실험의 기준점이 바뀌고 있음을 보여줍니다.
로컬 모델은 한동안 '재미있는 데모'에 가까웠습니다. 작은 모델은 빠르지만 품질이 부족했고, 큰 모델은 돌리기 어렵거나 비용이 컸습니다. Gemma 4 12B가 중요한 이유는 중간 지점을 노린다는 데 있습니다.
예를 들어 사내 문서 검색, 로컬 코드 리뷰, 고객 음성 로그 요약, 이미지 기반 QA, 오프라인 field tool 같은 작업은 항상 클라우드 모델이 정답은 아닙니다. 데이터가 민감하거나, 네트워크가 불안정하거나, 요청량이 많아 비용이 부담될 때 로컬 실행은 강한 선택지가 됩니다.
또 하나는 개발 환경 통합입니다. OpenAI 호환 API 서버가 되면 기존 애플리케이션의 LLM adapter를 크게 바꾸지 않고도 로컬 모델을 끼워 넣을 수 있습니다. baseURL만 바꾸거나 provider 설정만 추가하는 수준으로 A/B 테스트를 시작할 수 있습니다.
모든 서비스가 로컬 모델을 써야 하는 것은 아닙니다. 다음 조건에 맞을수록 검토 가치가 큽니다.
반대로 최고 수준 reasoning, 매우 긴 context, 최신 지식, 안정적인 SLA가 필요하면 클라우드 모델이 여전히 유리합니다. 특히 고객 응대, 법률·의료 판단, 대규모 production traffic에는 로컬 모델만으로 운영하기 어렵습니다.
첫 번째는 메모리입니다. 16GB급에서 '동작'하는 것과 '제품에 쓸 만큼 빠르게 동작'하는 것은 다릅니다. 양자화 방식, batch size, context length, multimodal 입력 크기에 따라 체감 속도는 크게 달라집니다. 영상 313프레임을 넣는 실험은 인상적이지만, 실제 앱에서는 프레임 샘플링과 token budget을 직접 설계해야 합니다.
두 번째는 prefix caching입니다. LiteRT-LM은 stateless prefix caching in memory를 언급합니다. 로컬 coding agent나 사내 문서 챗봇에서는 고정 시스템 프롬프트와 반복되는 코드베이스 설명이 많습니다. caching이 잘 되면 prefill latency를 줄일 수 있습니다. 다만 프로세스 재시작, 여러 사용자 동시 접속, context invalidation 규칙을 따로 잡아야 합니다.
세 번째는 fine-tuning입니다. Google은 encoder-free 구조가 LoRA나 full tuning에서 멀티모달 loop를 한 번에 업데이트하기 좋다고 설명합니다. 그러나 fine-tuning은 데이터 품질이 낮으면 쉽게 망합니다. 사내 이미지, 음성, 문서 데이터를 쓸 때는 라벨링 기준과 검증셋부터 만들어야 합니다.
처음부터 제품에 넣지 말고, 2주짜리 내부 실험으로 시작하는 편이 안전합니다.
1주 차에는 로컬 서버를 띄우고 기존 LLM abstraction에 연결합니다. 예를 들어 LOCAL_GEMMA_BASE_URL=http://localhost:PORT/v1 형태로 provider를 추가합니다. 테스트 작업은 간단해야 합니다. README 요약, 작은 PR 설명 생성, 스크린샷 alt text 생성, 짧은 음성 메모 요약 정도가 좋습니다.
2주 차에는 비용과 품질을 비교합니다. 같은 task set을 클라우드 모델과 로컬 모델에 보내고, latency, 실패율, 사람이 수정한 비율, 개인정보 외부 전송 여부를 표로 남깁니다. 단순히 '답이 좋아 보인다'로 판단하면 안 됩니다.
평가표 예시는 다음과 같습니다.
| 항목 | 측정 방법 | 통과 기준 |
|---|---|---|
| 응답 지연 | p50, p95 latency | 내부 도구는 p95 10초 이하 |
| 품질 | 사람 수정 횟수 | 30개 샘플 중 24개 이상 사용 가능 |
| 비용 | 전력·장비·운영 시간 포함 | 월 API 비용 대비 의미 있는 절감 |
| 보안 | 외부 전송 데이터 | 민감 데이터 0건 |
| 안정성 | 24시간 재시작/메모리 누수 | 장애 없이 완료 |
출처: Google Developers Blog의 Gemma 4 12B 개발자 가이드와 LiteRT-LM 설명을 기준으로 정리했습니다.
