Why Large? Tiny LMs & Agents on Edge/Robotics — Cormac Brick, Google

URL: https://www.youtube.com/watch?v=hacEQHHhu2Q 날짜: 2026-07-26 채널: AI Engineer (aiDotEngineer)

---

📌 핵심 질문 / 이 영상이 다루는 핵심 논점

지능을 값비싼 로봇 몇 대가 아니라 ==세상의 수많은 저가 디바이스에 확산시키려면, 1~4B 규모의 "스몰 모델"을 넘어 5천만~5억 파라미터급 "타이니 모델"까지 내려가야 한다==는 것이 이 발표의 핵심이다.

• DRAM 비용 상승이라는 하드웨어 제약이 이 방향 전환을 사실상 강제하고 있다
• 스몰 모델은 제로샷 프롬프팅만으로 쓸 수 있어 쉽지만, 4GB+ DRAM을 감당할 수 있는 고급 기기에서만 동작한다
• 타이니 모델은 합성 데이터 기반 파인튜닝이라는 더 복잡한 플레이북이 필요하지만, 음성-함수호출 같은 핵심 UX를 저가 IoT/로보틱스 기기에서도 실용 수준으로 구현할 수 있게 해준다

발표자 코맥 브릭(Google AI Edge 팀 테크리드)은 소형/초소형 모델의 현재 상태(state-of-the-art), 각 등급이 잘하는 것과 아직 못하는 것, 그리고 지금 당장 무엇을 만들 수 있는지를 자신의 팀과 Gemma 팀의 실제 프로덕션 사례를 통해 설명한다.

---

1. 배경: 발표자와 Google AI Edge 팀

Google에서 엣지 디바이스에 AI를 배포하는 오픈소스 툴체인과 자체 제품용 엣지 AI 기술을 함께 개발하는 팀이다.

1.1. 팀이 하는 일

1. 오픈소스 프로젝트 개발
   1. LiteRT, LiteRT-LM, MediaPipe: 엣지 디바이스에 AI를 배포하기 쉽게 만드는 오픈소스 프로젝트들
   2. Google 자체 제품 지원: 일부는 타이니 모델을 통해 Google 자사 제품에 엣지 AI 핵심 기술을 제공
2. Gemma 팀과의 협업
   1. 디바이스 호환성 보장: Gemma 모델이 다양한 기기에서 잘 동작하도록 지원하는 데 상당한 비중을 둠
   2. 초점 영역: 모바일 앱이나 브라우저 탑재처럼 정말 작아야 하는 상황에 쓰이는 스몰/타이니 모델에 집중

1.2. 개발 방식(playbook)

1. 선(先) 사내 적용, 후(後) 오픈소스
   1. 1차 목표: 사내(1st party) 사용을 위해 먼저 개발
   2. 2차 목표: 방법을 찾으면 오픈소스 패키지나 도구로 공개해 외부 생태계도 같은 것을 만들 수 있게 도움

---

2. 왜 엣지(온디바이스) AI인가

클라우드로 모든 걸 처리하는 대안과 비교했을 때 온디바이스가 갖는 이점을 설명한다.

2.1. 클라우드 대비 사용자 경험 이점

1. 속도와 프라이버시
   1. 지연시간(latency): 빠르고 일관된 속도
   2. 프라이버시: 데이터가 기기 밖으로 나가지 않음
2. 오프라인 신뢰성
   1. 네트워크 무관 동작: 전파가 안 터지는 상황에서도 모바일 기기의 해당 기능이 계속 동작
   2. 비용 절감: 클라우드의 더 빠른 모델을 호출하는 대안은 비용이 발생하며, 앱/브라우저처럼 사용자 상호작용 규모가 매우 클 때는 토큰 단가가 저렴해도 곱해지면 빠르게 누적됨

2.2. 엣지 배포의 핵심 과제

1. DRAM 비용 (가장 새롭고 심각한 제약)
   1. 제조사 트렌드: 일부 모바일 제조사가 올해 이전보다 더 적은 DRAM을 기기에 탑재
   2. 가격 급등: 라즈베리파이 기기의 메모리 가격이 출시 이후 약 2.5배 상승 — 이 제약이 발표 전체에 그림자를 드리우며, quantization과 "이 작업에 필요한 최소 모델 크기가 무엇인가"를 계속 고민해야 하는 이유가 됨
2. 기타 과제
   1. 디바이스 풀의 다양성: 타겟이 되는 디바이스 종류가 매우 폭넓음
   2. 연구 자원의 쏠림: LLM 연구 리소스 대부분이 훨씬 더 큰 모델에 집중되어, 스펙트럼 하위(작은 모델) 쪽은 상대적으로 연구가 덜 이뤄짐

---

3. 스몰 모델 (Small Models, 약 1~4B 파라미터)

3.1. 정의와 이미 탑재된 사례

1. OS 내장 사례
   1. Android: 고급형 폰의 AI Core에 이 크기의 모델 버전이 탑재됨
   2. Apple: Apple Intelligence에도 이 크기의 버전이 탑재됨
   3. 앱 벤더 탑재: 일부 앱 벤더가 자체 앱에 이 크기의 모델을 탑재하며, Google 팀도 이런 벤더 일부와 협업 중
2. IoT/로보틱스 요구 사항
   1. 필요 DRAM: 이 등급 모델을 구동하려면 보통 4~8GB DRAM이 필요하며, 이는 곧바로 기기 원가에 영향을 줌
   2. 시장 제약: 결과적으로 노트북·스마트폰·고급 전자기기로 적용 범위가 제한되고, 저가형 웹브라우저나 IoT·소비자 로보틱스 시장에서는 접근이 어려움

3.2. 스몰 모델 활용 플레이북

1. 풋프린트 최소화
   1. 양자화(quantization): 메모리 사용량을 최소화하기 위한 다양한 작업 수행
2. 적용 방식
   1. 제로샷 프롬프팅: 특정 기능을 구현하려 할 때 제로샷 프롬프팅만으로도 꽤 좋은 성능을 낼 수 있음
   2. LoRA 어댑터: LoRA 어댑터 활용도 가능
   3. 기능 강점: 함수 호출(function calling), 에이전트 스킬 수행에 비교적 강함

3.3. 사례: Gemma E2B

1. 추론 성능
   1. 성능 수준: E2B 모델이 약 12개월 전의 훨씬 더 큰 Gemma 3 모델과 맞먹는 추론 능력을 보여줌
   2. 손쉬운 활용: 제로샷 프롬프팅만으로 특정 과제에 대해 꽤 괜찮은 답변을 획득
2. 메모리 풋프린트 최적화
   1. 혼합 양자화: 2비트/4비트/8비트를 혼합 적용해 실제 가중치 기준 약 2.9비트/파라미터까지 축소
   2. 레이어별 임베딩: per-layer embeddings 등 세부 기법을 추가 적용 (발표에서 전부 다루진 않음)
   3. 최종 결과: 텍스트 전용 모델 가중치만 약 841MB, 런타임과 KV 캐시까지 포함하면 약 2GB의 활성 RAM 필요 → OS 등 다른 부담까지 감안해 "4GB+"라는 룰오브섬(rule of thumb) 도출
3. 디바이스별 디코드 속도
   1. 라즈베리파이: 초당 약 7.6 토큰 (MTP 미사용 시), MTP를 켜면 과제에 따라 최대 2배까지 빨라짐
   2. Jetson Orin Nano: 최대 초당 약 24토큰 (Google 자체 툴체인 기준, Nvidia 자체 툴체인 사용 시 더 빠를 수 있음)
   3. Qualcomm IoT 보드(NPU): 프리필(prefill) 약 4,000토큰/초, 디코드 약 31토큰/초 — 거의 실시간 수준의 애플리케이션에 유용
   4. 이미지 토큰 환산: Gemma 4 계열 기준 중간 해상도 이미지는 약 500토큰, 고해상도 이미지는 약 1,120토큰이 소요되며, 이 NPU 디코드 속도라면 고해상도 기준 초당 약 3프레임 처리가 가능한 수준
4. 커뮤니티 대안 모델
   1. 다양한 선택지: Google 툴체인 외에도 비슷한 크기의 커뮤니티 모델들이 존재하며 각자 강점을 가짐 (발표에서는 슬라이드로만 나열, 개별 모델명은 구두로 특정하지 않음)

3.4. 실습 도구: AI Edge Gallery 앱

1. 체험용 오픈소스 앱
   1. 플랫폼: iOS와 Android 모두 지원
   2. 용도: 스몰 모델이 실제 폰에서 얼마나 빠르게 동작하는지 바로 체험 가능
   3. 완전 오픈소스: 앱 자체와 이를 구동하는 오픈소스 런타임 코드까지 모두 공개되어 있어, 유사한 것을 직접 만들어보고 학습하기에 좋은 출발점

3.5. 사례: Open Duck Mini v2 로봇 (deepmind 엔지니어의 취미 프로젝트)

1. 로봇 구성
   1. 제작 배경: DeepMind 소속 엔지니어인 Xavier가 취미로 만든 오픈소스 로봇 프로젝트 (발표에서 유튜브 영상을 소개하며 직접 시청을 권함)
   2. 두 가지 버전: 한 대는 Jetson Nano 기반, 한 대는 라즈베리파이 기반으로 각각 제작
2. 기능과 성능 비교
   1. 입력/반응: 표지판을 읽고 반응하거나 고개를 끄덕이는 등 음성과 이미지 입력을 모두 처리
   2. Jetson Nano 버전: 실시간 상호작용 품질이 매우 우수
   3. 라즈베리파이 버전: 동작은 하지만 훨씬 느림 — 일부 상호작용 유형에서는 현재 최고 수준의 모델로도 사용자 상호작용 요구를 충족하지 못하는 사례로 제시됨

3.6. 스몰 모델의 한계

1. 스몰 모델로 충분한 경우
   1. 적용 조건: 제품이 4GB+ DRAM 제약을 감당할 수 있다면, 제로샷 프롬프팅만으로 충분히 좋은 결과를 얻을 수 있어 "이 시점에서 개발 여정이 끝날 수 있음"
2. 스몰 모델로 부족한 경우 (팀이 실제로 자주 마주치는 현실)
   1. 디바이스 제약: 구형 노트북이나 저가 소비자 엣지 기기에는 스몰 모델도 여전히 너무 큼
   2. 응답성 요구: 사용자 상호작용이 더 빠른 응답성을 요구하는 경우가 있음
   3. 보조 기능 시나리오: 원하는 모델이 애플리케이션의 메인 기능이 아니라, 시스템 전체가 돌아가는 동안 한쪽 구석에서 계속 돌아가야 하는 아주 작은 보조 기능(예: 시스템 헬스 모니터링)인 경우가 흔함 → 이럴 때 더 작은 모델이 필요

---

4. 타이니 모델 (Tiny Models, 약 5천만~5억 파라미터)

4.1. 정의와 특징

1. 규모와 구동 조건
   1. 파라미터 범위: 최소 약 5,000만 파라미터부터 실제 배포 사례 있는 최대 약 5억 파라미터까지
   2. 탑재 용이성: 애플리케이션에 네이티브로 쉽게 탑재 가능
   3. 저메모리·고속: 2GB 미만, 혹은 그보다 훨씬 적은 RAM으로도 구동 가능하며 매우 빠르게 동작
2. 배포 난이도
   1. 더 복잡한 플레이북: 스몰 모델보다 배포 과정이 더 복잡함
   2. 선택지 분기: 기성(off-the-shelf) 모델로 해결되는 경우도 있지만, 안 되면 목적에 맞춘 파인튜닝이 필요

4.2. 고정 과제(Fixed-task) 모델 — 이미 검증된 영역

1. ASR, 비전, 임베딩은 이미 잘 동작하는 표준 기능
   1. Apple FastVLM: 0.5B(5억) 파라미터 모델로, Android 기기에서 하드웨어 가속을 통해 매우 빠르게 동작 — 엣지/IoT 기기에 1차 수준의 시각 인지 능력을 더하기 좋은 선택지로 소개됨
   2. ASR: 이 영역에도 여러 강력한 모델이 존재한다고 언급 (슬라이드 나열, 발표 중 개별 모델명 구두 언급은 없음)
   3. 임베딩 모델: 텍스트 처리와 매칭에 뛰어난 텍스트 임베딩 모델도 이 범주에서 잘 동작

4.3. 파인튜닝이 필요한 경우

1. 시작점이 되는 Google 개발 모델
   1. Gemma 3: 2억7천만 파라미터부터 시작하는 버전이 있는 범용 목적 모델
   2. Function Gemma: function calling 패턴에 특화된 추가 사전학습을 거친 모델
2. 성능 향상
   1. 속도 개선: 앞서 스몰 모델(2B) 기준 라즈베리파이에서 한 자릿수 중반 토큰/초였던 디코드 속도가, 파라미터가 더 작은 모델에서는 초당 45토큰까지 상승 (매 스텝마다 메모리에서 읽어야 할 양이 줄어들기 때문)
3. 데모: 모바일 액션 모델 (Mobile Actions Model)
   1. 기능: 텍스트 입력 → 함수 호출(function calling) 출력을 수행
   2. 범위와 신뢰도: 약 10개의 서로 다른 출력 함수를 인식하고, 임의의 자유 텍스트 입력에 대해 86% 이상의 신뢰도로 정확히 호출
   3. 실제 예시: 캘린더 일정 등록, Wi-Fi 켜기/끄기 등 모바일 기기에서 흔한 작업들
   4. 음성 확장: 이 데모에서는 별도의 ASR 모델을 앞단에 붙여 "음성 → 함수 호출(voice-to-function-calling)"로 기능을 확장함
   5. 왜 중요한가: 음성-함수호출은 IoT·엣지 기기에 특히 핵심적인데, 화면이 작은 기기일수록 설정 메뉴 UI가 사용자에게 매우 불편하기 때문에 말로 원하는 결과를 요청할 수 있는 능력이 중요한 역량이 됨

4.4. 파인튜닝 플레이북

1. 절차
   1. 1단계: 베이스 모델을 고른다
   2. 2단계: 성능과 메모리 풋프린트가 원하는 범위 안에 들어오는지 확인한다
   3. 3단계 (가장 어려운 부분): 목표 모델을 파인튜닝하기 위한 합성(synthetic) 데이터를 생성한다
2. 데이터셋 규모와 오픈소스 자료
   1. 필요 샘플 수: 모델에 따라 다르지만, 대략 1만~1000만 개의 합성 생성 샘플이면 스몰 모델을 매우 높은 신뢰도로 파인튜닝하기에 충분한 경우가 많음
   2. 오픈소스 데이터셋 공개: "Mobile Actions"라는 데이터셋을 HuggingFace에 공개 — 위 모바일 액션 데모를 Function Gemma로 처음부터 직접 재현하고 싶다면 이 데이터셋을 활용 가능
3. 다른 과제로의 확장
   1. 적용 사례: 요약(summarization), 교정(proofreading) 같은 과제에도 동일한 플레이북 적용
   2. 효과: 2~4B 모델로도 충분히 신뢰성 있게 처리할 수 있는 작업을, 시간과 노력을 들여 합성 데이터셋을 만들고 파인튜닝하면 훨씬 더 작은 모델로 동일하거나 더 나은 품질을 얻을 수 있고, 더 넓은 디바이스 지원과 더 빠른 응답성까지 확보 가능

4.5. 프로덕션 사례: 구독 없는 온디바이스 음성 받아쓰기(dictation) 앱

1. 제공 기능
   1. 완전 로컬 처리: 모든 음성 받아쓰기가 기기 로컬에서 이뤄져 구독이 필요 없음
   2. 텍스트 클린업: 받아쓰기 외에 "음…", "어…" 같은 필러(filler)를 정리해주는 기능 제공
   3. 개인화: 사용자 개인과 관련된 이름·단어에 대한 바이어싱(biasing)도 지원
2. 아키텍처
   1. 구성 요소: ASR 엔진 + 텍스트 클린업(policing) 엔진, 두 구성 요소 모두 타이니 Gemma 모델의 파인튜닝 버전
   2. 가치 전환: 원래는 서버 전용(구독 필요)이었을 고정밀 음성 받아쓰기 기능을, 완전 오프라인으로 매우 좋은 품질을 유지하며 제공 가능하게 만듦
   3. 체험 방법: iOS에서 실제로 사용해볼 수 있는 앱으로 공개되어 있음
   4. 모델 규모: 앱의 백본은 파라미터 수 백만 단위(low single-digit hundreds of millions)의 파인튜닝된 두 개의 작은 Gemma 기반 모델

4.6. 프로덕션 사례: Chrome 내장 API

1. 개발자 프리뷰 기능
   1. 제공 기능: 요약(summarization)과 교정(proofreading) 기능이 Chrome에 내장 API 형태로 제공됨 (developer preview 단계)
   2. 타이니 모델의 역할: 이 기능들을 타이니 모델로 구현함으로써, Chrome 팀이 훨씬 더 넓은 사용자층에게 해당 기능을 배포할 수 있게 됨

---

5. 결론 및 Q&A

5.1. 발표자 정리 (마지막 슬라이드)

1. 소비자 기기·엔트리 레벨 로보틱스 관점 takeaway
   1. 스몰 LLM: 사용하기 쉽고, 특히 NPU에서는 매우 빠르게 동작
   2. 타이니 모델: 훨씬 더 많은 디바이스 풀에 도달(reach)할 수 있게 해줌
   3. 음성-함수호출: 이제 타이니 모델로도 견고하게 구현 가능하며, 적절한 합성 데이터셋에 충분한 샘플 수만 투자하면 파인튜닝으로 좋은 결과를 얻을 수 있음

5.2. Q&A (시간 부족으로 질문 1개만 진행)

1. 질문: 타이니 모델의 더 넓은(broader) 비전은 무엇인가?
2. 답변
   1. 핵심 목표 1: 음성-함수호출을 일반화하는 것 — 만약 "에이전트가 사람 대신 합성 데이터를 생성"하는 방법을 찾아낸다면, 지금보다 이 여정을 훨씬 쉽게 만들어 더 많은 사람에게 제공할 수 있음
   2. 핵심 목표 2: 시각 입력(visual input) 처리는 아직 시간이 좀 걸리는 영역 — 세그멘테이션(segmentation) 등 더 넓은 작업을 수행할 수 있는 더 빠른 모델의 여지가 분명히 있음
3. 세션 종료
   1. 시간 부족: 정식 Q&A 세션 시간이 부족해 사회자가 세션 종료 후 개별 질문을 받도록 안내
   2. 추가 접촉 방법: 코맥은 세션 직후에도 남아 있을 예정이며, 이후 4시~5시에는 DeepMind 부스에서도 만날 수 있다고 안내

---

주요 발언 모음

"If we want intelligence to get into lots and lots and lots of devices and not just really expensive robots, we are going to need tiny models."

"DRAM cost is really really significant... that then has a like casts a shadow over the rest of this talk."

"The playbook here is mostly prompting, right? If you want to deliver a particular feature using a smaller model, you can just kind of use zero shot prompting and get pretty good performance."

"This model knows about 10 different output functions and can call them at over 86% reliability from a given arbitrary text input."

"Small LLMs are easy to use... tiny models will enable reach to a much much larger pool of devices and voice-to-function calling can now be built to be robust using tiny models."

핵심 데이터 & 수치

• 스몰 모델 규모: 약 1~4B 파라미터, 구동에 보통 4~8GB DRAM 필요
• 라즈베리파이 DRAM 가격: 출시 이후 약 2.5배 상승 (엣지 배포의 핵심 제약)
• Gemma E2B 양자화: 2비트/4비트/8비트 혼합 적용, 실제 가중치 기준 약 2.9비트/파라미터
• Gemma E2B 메모리: 텍스트 전용 가중치 약 841MB, 런타임+KV 캐시 포함 활성 RAM 약 2GB, 룰오브섬 4GB+
• 디코드 속도(Gemma E2B, 2B급): 라즈베리파이 초당 7.6토큰(MTP 미사용, 사용 시 최대 2배) / Jetson Orin Nano 최대 초당 24토큰 / Qualcomm IoT 보드(NPU) prefill 약 4,000토큰/초·decode 약 31토큰/초
• Gemma 4 이미지 토큰: 중간 해상도 약 500토큰, 고해상도 약 1,120토큰 → NPU 기준 고해상도 초당 약 3프레임 처리 가능
• 타이니 모델 규모: 약 5천만~5억 파라미터, 2GB 미만 RAM으로 구동
• Apple FastVLM: 0.5B 파라미터, Android 하드웨어 가속으로 고속 동작
• Gemma 3 / Function Gemma: 2억7천만 파라미터부터 시작하는 버전 존재
• Function Gemma 디코드 속도: 라즈베리파이 기준 초당 45토큰 (2B 모델의 한 자릿수 중반 대비 대폭 향상)
• 모바일 액션 모델: 약 10개 함수, 86% 이상 신뢰도로 함수 호출
• 파인튜닝 합성 데이터 규모: 약 1만~1000만 샘플
• 음성 받아쓰기 앱 모델 규모: 수억(백만 단위) 파라미터급 파인튜닝 Gemma 모델 2개(ASR + 텍스트 클린업)

결론 및 시사점

1. 엣지에 지능을 확산시키려면 스몰 모델(1~4B)을 넘어 타이니 모델(50M~500M)까지 내려가야 하며, DRAM 비용 상승이라는 하드웨어 제약이 이 흐름을 사실상 강제하고 있다.
2. 스몰 모델은 제로샷 프롬프팅만으로 충분히 실용적인 결과를 낼 수 있어 진입장벽이 낮지만, 4GB+ DRAM을 감당할 수 있는 제품에만 적용 가능하다는 명확한 한계가 있다.
3. 타이니 모델은 기성 모델(ASR/비전/임베딩)로 해결되지 않으면 합성 데이터 기반 파인튜닝이 필수이며, 1만~1000만 샘플 규모의 합성 데이터로도 86% 이상의 높은 신뢰도를 달성할 수 있다.
4. 음성-함수호출(voice-to-function-calling)은 IoT/저가 디바이스에서 복잡한 설정 UI를 대체할 핵심 UX 패턴이며, 지금 당장 파인튜닝된 타이니 모델로 구현 가능한 수준에 도달했다.
5. 실제 프로덕션 사례(구독 없는 음성 받아쓰기 앱, Chrome 요약/교정 내장 API)가 이미 이 접근을 검증했다 — 서버 전용·구독 기반이었던 기능을 완전 오프라인 무료 기능으로 전환시킨 대표 사례다.
6. 다음 개선 방향으로는 (a) 합성 데이터 생성 자체를 에이전트가 자동화해 파인튜닝 진입장벽을 낮추는 것, (b) 시각 입력 처리 속도를 더 끌어올려 세그멘테이션 등 더 넓은 작업까지 커버하는 것이 제시됐다.