[한영자막] 왜 자꾸 더 작은 AI 모델을 만들까?

URL: https://www.youtube.com/watch?v=JOZNhRO04eQ 날짜: 2026-07-28 채널: Tech Bridge (원본 발표: Google Edge AI 팀 엔지니어, 영어 컨퍼런스 강연 한영자막 클립) 영상 길이: 21:18 처리일: 2026-07-28

⚠️ 이 영상은 자동 생성(auto-sub) 한국어 자막을 기반으로 작성되었으며, 자막 품질이 다소 거칠어(직역/어순 오류 다수) 문맥으로 재구성한 내용이 포함되어 있음을 밝힌다. 핵심 수치와 논지는 원문 맥락을 최대한 보존해 정리했다.

---

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

Google에서 온디바이스(엣지) AI를 개발하는 팀의 엔지니어가 ==왜 업계가 계속 "더 작은" AI 모델을 만드는가==를 실전 사례와 벤치마크 수치로 설명하는 컨퍼런스 강연이다.

• 클라우드 LLM은 지연시간·프라이버시·오프라인 신뢰성·비용 문제에서 한계가 있고, 작은 모델은 이 문제들을 구조적으로 해결한다
• Google은 로봇, 안드로이드 폰, 브라우저, IoT/사물인터넷, 자동차 등 "엣지 디바이스"에 AI를 배포하기 위해 Gemma 계열의 초소형·소형 모델과 LiteRT·MediaPipe라는 오픈소스 런타임 툴체인을 함께 개발한다
• 작은 모델은 크기가 작을수록 저사양 기기, 저가 부품에서도 실시간으로 동작해 "AI가 도달할 수 있는 기기와 사람의 수"를 극적으로 넓힌다

발표자는 결국 "작은 모델을 잘 만드는 것"은 단순한 다운사이징이 아니라, 좋은 합성 데이터셋 투자와 목적에 맞춘 파인튜닝을 통해 특정 작업(함수 호출, 음성인식, 요약 등)에서는 큰 모델과 동등하거나 그 이상의 신뢰도를 훨씬 적은 자원으로 달성할 수 있는 전략이라고 강조한다.

---

1. 왜 엣지(온디바이스) AI를 만드는가

발표자는 Google에서 AI 팀의 기술 리더로 일하며, 팀은 LiteRT 및 MediaPipe와 같은 오픈소스 도구로 AI를 엣지 디바이스(로봇, 폰, 브라우저, IoT)에 배포하는 일을 한다.

1.1. 발표자 및 팀 소개

1. 소속과 역할

   1. Google AI 팀 기술 리더: 발표자는 인공지능 분야에서 오랫동안 일해왔으며 현재 Google에서 AI 팀의 기술 리더를 맡고 있다
   2. 엣지 AI 전담: 팀의 핵심 업무는 코드 프로젝트 개발과 함께 LiteRT·MediaPipe 같은 오픈소스 툴을 통해 AI 배포를 용이하게 하는 것

2. Gemma 팀과의 협업

   1. 모델 개발 협업: Gemma 팀과 협업하여 다양한 기기에서 잘 작동하는 작고 아담한 모델을 만드는 데 주력한다
   2. 오픈소스 전략: 내부용으로 먼저 개발하고, 그 다음 오픈소스 패키지로 공개해 세상의 다른 개발자들도 비슷한 유형의 것들을 만들 수 있도록 한다

1.2. 클라우드가 아닌 엣지를 선택하는 4가지 이유

1. 지연시간(latency)

   1. 빠르고 일정한 속도: 클라우드 호출 없이 기기에서 바로 추론하므로 응답 속도가 빠르고 일정하다

2. 프라이버시

   1. 데이터 온디바이스 보관: 개인정보 보호를 위해 데이터가 기기 밖으로 나가지 않고 안전하게 보관된다

3. 오프라인 신뢰성

   1. 신호 없는 환경에서도 동작: 네트워크 신호가 없을 때도 모바일 기기가 계속 작동할 수 있다

4. 비용

   1. 대규모 사용자 기반의 함정: 클라우드에서 더 구체적인 모델을 호출하면 토큰 자체는 상대적으로 저렴해 보이지만, 모바일 앱처럼 사용자 기반이 대규모일 경우 그 저렴한 토큰 비용도 큰 수로 곱해지면 요금이 순식간에 치솟는다
   2. 온디바이스 비용 구조: 반면 온디바이스 추론은 한 번 배포하면 추가 클라우드 비용이 발생하지 않는다

---

2. 엣지 AI 배포의 주요 과제

2.1. 하드웨어 제약: RAM이 핵심 병목

1. RAM은 가장 중요한 제약 조건

   1. 가격·용량의 변동성: RAM 메모리는 매우 중요한 제약 사항이며, 휴대폰 제조사들은 해마다 RAM 탑재량을 줄이거나 늘리는 등 변동이 있다. 발표자는 라즈베리파이를 예로 들며 출시 이후 기가바이트당 용량이 약 2.5배 증가했지만 그만큼 가격이 유리해지는 것은 아니라는 점을 지적한다
   2. 가격 프리미엄: 이런 수준의 모델을 탑재하려면 그만큼 기기 구매 비용(부품 명세서, BOM)이 올라가는데, 이는 노트북·고급 휴대폰처럼 이미 고가인 제품에는 적용 가능하지만, 저사양 웹 브라우저나 광범위한 IoT/소비자 로봇공학 시장에는 제한을 둔다

2. 더 넓은 대상 기기, 더 적은 연구

   1. 다양한 타겟 기기 문제: 엣지 AI는 다양한 하드웨어 스펙(저사양 IoT 보드부터 고급 안드로이드 폰까지)을 동시에 커버해야 하는 구조적 어려움이 있다
   2. 연구 불균형: 오늘날 LLM 연구의 상당 부분은 더 크고 강력한 모델을 지향하며, 상대적으로 LLM 스펙트럼의 하단(작은 모델)은 연구가 훨씬 덜 되어 있다는 것이 배포 시 직면하는 근본적인 어려움이다

---

3. "작은 모델"이란 무엇인가 — 크기별 계층 구조

발표자가 말하는 "작다"는 것은 일반적인 sLLM보다도 훨씬 작은 수준이다.

3.1. 소형 모델(1B~4B 파라미터)

1. 정의와 위치
   1. 파라미터 범위: 보통 10억(1B)~40억(4B) 사이의 파라미터를 가진 모델을 지칭하며, 이미 오늘날 여러 시스템에 통합되어 운영되고 있다
   2. 실제 탑재 사례: AI 기능이 탑재된 고급 안드로이드 폰, 애플의 Apple Intelligence 등이 이 크기대 모델을 사용한다
   3. 필요 자원: 이 수준의 모델을 온디바이스에서 실행하려면 대략 4~8GB RAM이 필요하며, 이는 노트북·고급 휴대폰 같은 고가 제품군에 적합하다

3.2. 초소형("tiny") 모델(약 5천만~5억 파라미터)

1. 정의와 특징

   1. 파라미터 범위: 약 5천만(50M) 개에서 최대 5억(500M) 개 파라미터 규모의 아주 작은 모델
   2. 네이티브 배포 용이성: 별도 서버·클라우드 연동 없이 애플리케이션에 네이티브로 손쉽게 내장 배포할 수 있다
   3. 낮은 자원 요구: 2GB 이하의 RAM으로도 매우 빠르게 동작한다

2. 적합한 용도

   1. 고정 작업(fixed-task) 특화: 범용 대화보다는 ASR(음성인식), 비전(vision) 분류, 텍스트 임베딩/매칭 같은 좁고 정해진 작업에 최적화되어 있다
   2. 바로 쓸 수 있는 기성 모델: 특정 작업용으로 이미 잘 훈련된 기성 모델을 그대로 쓰거나, 필요시 미세 조정(튜닝)해서 쓸 수 있다

---

4. 실측 벤치마크 — 하드웨어별 처리 속도

발표자는 Gemma 계열 2B 모델을 여러 하드웨어에 직접 올려 측정한 수치를 공개했다.

4.1. 저사양 기기: 라즈베리파이

1. 텍스트 디코딩 속도
   1. 초당 약 7.6토큰: 20억(2B) 파라미터 모델을 라즈베리파이에서 실행할 때 초당 약 7.6개 토큰 디코딩 속도가 나온다 (MTP, Multi-Token Prediction 미적용 기준)
   2. MTP 적용 시 약 2배: 멀티토큰 예측(MTP) 기능을 활성화하면 작업에 따라 대략 2배 더 빠른 속도를 낼 수 있다

4.2. 중급 엣지 디바이스: NVIDIA Jetson Orin Nano

1. 한 단계 높은 성능
   1. 초당 최대 24토큰: Jetson Orin Nano 같은 상위 엣지 기기에서는 초당 최대 24개 토큰 디코딩까지 도달 가능하며, NVIDIA 자체 툴체인을 사용하면 그 이상도 가능하다

4.3. NPU 탑재 기기: Qualcomm

1. 로봇/IoT에서 인기 있는 선택지
   1. 높은 프리필(prefill) 속도: Qualcomm NPU에서는 한 번에 거의 4,000개 토큰을 프리필 단계에서 처리할 수 있다
   2. 디코딩 속도: 디코딩 단계에서는 초당 약 31토큰을 낼 수 있어, 거의 모든 응용 분야에서 실시간(real-time)으로 쓸 수 있는 수준이라고 평가한다

4.4. 비전(멀티모달) 모델 처리량

1. 해상도별 토큰 수

   1. 중간 해상도: 약 500토큰
   2. 고해상도: 약 1,120토큰

2. 프레임 처리 속도

   1. 초당 약 3프레임: 고해상도 이미지 토큰 기준으로 이 모델을 통해 초당 약 3프레임 처리가 가능하며, 디코딩 속도도 꽤 준수한 수준이라고 설명한다

---

5. 모델을 작게 만드는 기법 — 메모리 최적화

5.1. 양자화(Quantization)와 레이어 트릭

1. 혼합 비트 양자화

   1. 2/4/8비트 조합: 2비트, 4비트, 8비트 양자화를 조합해 사용하여 평균 비트 수를 약 2.9비트/가중치 수준까지 줄인다
   2. 레이어별 임베딩(inlay) 기법: 레이어별로 임베딩을 압축하는 별도 기법도 추가로 적용한다 (세부 구현은 발표에서 생략, 자료 참고 안내)

2. 결과 수치

   1. 텍스트 모델 가중치: 약 841MB: 가중치 저장만을 위한 메모리가 약 841메가바이트 수준까지 줄어든다
   2. 실행 시 활성 RAM: 최대 약 2GB: 실행 및 KV 캐시 사용량까지 더하면 모델을 실제로 구동하는 데 최대 2GB 정도의 활성 RAM이 필요할 수 있다
   3. 실무 권장 기준: 4GB 이상: 운영체제와 다른 실행 중인 프로세스까지 고려하면, 온디바이스 구현을 위해서는 일반적으로 4GB 이상의 RAM을 권장한다는 것이 팀의 경험칙이다

---

6. 실제 제품·데모 사례

6.1. AI Edge Gallery 앱 — 누구나 체험 가능한 데모

1. iOS/안드로이드 무료 앱
   1. 직접 체험: 여러 소형 모델을 휴대폰에서 직접 실행해보고 얼마나 빠르게 동작하는지 확인할 수 있는 앱을 iOS·안드로이드 양쪽에 제공한다
   2. 완전 오픈소스: 앱 전체와 이 모델들을 동작시키는 런타임 코드까지 모두 오픈소스로 공개되어 있어, 비슷한 것을 직접 만들어보거나 작동 원리를 살펴볼 수 있는 좋은 출발점이라고 소개한다

6.2. 오픈소스 로봇 데모 — Open Dot Mini v2

1. DeepMind 엔지니어의 사이드 프로젝트

   1. 개발자: DeepMind 소속 엔지니어 Xavier(자비에르)가 취미로 개발한 오픈소스 로봇
   2. 두 가지 하드웨어 버전: 한 대는 Jetson Nano, 다른 한 대는 라즈베리파이를 탑재해 비교 시연한다

2. 로봇의 기능과 성능 차이

   1. 인터랙션 기능: 신호를 읽고 사물에 반응하며, 고개를 움직이고 음성·오디오 입력을 받을 수 있다
   2. Jetson Nano 버전: 실시간 상호작용이 매우 자연스럽게 이루어진다
   3. 라즈베리파이 버전: 동작은 하지만 훨씬 느리다. 발표자는 이를 통해 "오늘날 최고 수준의 소형 모델로도 특정 실시간 상호작용 요구사항은 아직 충족하지 못하는 경우가 있다"는 현실을 인정하면서도, 영상 자체는 매우 인상적이었다고 평가한다

6.3. 함수 호출(Function Calling) 특화 소형 모델

1. Function Gemma / Mobile Action 모델

   1. Gemma 3 대비 특화 사전학습: Gemma 3가 범용 모델이라면, Function Gemma는 함수 호출 패턴에 대한 추가 사전학습을 거친 버전이다. 2억 7천만(270M) 파라미터급부터 시작한다
   2. 속도 개선: 라즈베리파이 기준 일반 Gemma 모델이 초당 몇 토큰 수준이었다면, 이 함수 호출 특화 모델은 매번 메모리에서 읽어와야 하는 양이 줄어들어 초당 약 45토큰까지 속도가 올라간다
   3. 모바일 액션(Mobile Action) 모델: 약 10가지 서로 다른 출력 함수(캘린더 예약, 와이파이 켜기/끄기 등)를 알고 있으며, 텍스트 기반으로 86% 이상의 신뢰도로 적절한 함수를 호출한다. 자유 텍스트 입력을 임의로 만들어 이를 정형화된 "함수 호출"로 변환하는 역할을 한다

2. 음성 + 함수 호출 결합 데모

   1. ASR을 앞단에 배치: 시연을 위해 음성인식(ASR) 모델을 함수 호출 모델 앞에 배치해, 음성으로 직접 기기 기능을 호출하는 것을 보여준다
   2. IoT·엣지 기기에서의 필요성: 소형 기기는 종종 별도 설정 메뉴나 복잡한 인터페이스가 사용자에게 큰 진입장벽이 되므로, "그냥 말을 걸어서 원하는 결과를 얻는" 음성-함수 변환 능력이 핵심 역량이라고 강조한다. 작고 압축된 모델로도 이 기능을 상당히 신뢰성 있게 구현할 수 있다고 밝힌다

6.4. 온디바이스 음성 받아쓰기(dictation) 앱

1. 구독료 없는 완전 오프라인 음성 받아쓰기

   1. 로컬 처리: 음성 받아쓰기 전체가 기기 내부에서 완결되며, 구독료 없이 사용 가능하다
   2. 부가 기능: 단순 받아쓰기 외에도 군더더기 말(filler words) 제거, 텍스트 수정, 사용자 본인과 관련된 이름 등 특정 단어의 우선순위를 높이는 개인화 기능까지 포함한다

2. 아키텍처: 이중 타이니 모델

   1. ASR 엔진 + 텍스트 정책 엔진: 두 개의 초소형(tiny) 모델로 구성되며, 둘 다 Gemma 계열에서 축소·증류된 모델이다
   2. 의미: 원래는 서버가 필요한 유료 구독형 서비스였을 기능을 완전히 오프라인에서, 매우 높은 정확도로 제공할 수 있게 되었다. iOS에서 바로 사용해볼 수 있다고 소개한다

3. Chrome 브라우저 통합 사례

   1. Chrome 개발자 프리뷰 API: 요약(Summarize)·수정(Rewrite) API 등 통합 텍스트 기능도 이런 타이니 모델을 기반으로 제공되며, 이를 통해 Chrome 팀이 서버 없이는 불가능했을 기능을 훨씬 더 많은 사용자에게 제공할 수 있게 되었다

---

7. 소형 모델을 특정 작업에 맞게 튜닝하는 전략

7.1. 베이스 모델 선택 기준

1. 성능 대 메모리 트레이드오프
   1. 기본 원칙: 원하는 성능 수준과 사용 가능한 메모리 범위를 먼저 정하고, 그 안에서 베이스 모델(예: Gemma 3, Function Gemma)을 선택한다
   2. 작업별 모델 크기 권장: 요약이나 텍스트 교정처럼 조금 더 복잡한 작업에는 20억~40억(2B~4B) 파라미터 모델이 상당히 신뢰할 만한 선택지라고 언급한다

7.2. 합성 데이터 생성 — 가장 어렵지만 가장 중요한 단계

1. 핵심 병목: 좋은 데이터

   1. 가장 효과적인 방법: 팀이 찾은 가장 효과적인 접근은 합성 데이터를 직접 생성해 해당 모델을 튜닝하는 것이다
   2. 공개 데이터셋: 함수 호출 튜닝을 재현하고 싶은 개발자를 위해 "Mobile Action"이라는 데이터셋을 Hugging Face에 공개했다

2. 필요한 데이터 규모

   1. 1만~100만 샘플: 일반적으로 1만(10,000)에서 최대 100만(1,000,000) 개의 합성 데이터 샘플이면 작은 크기에서도 높은 신뢰도의 모델을 튜닝하기에 충분하다는 것이 팀의 경험이다
   2. 시간·자원 투자의 보상: 합성 데이터셋 생성에 시간과 에너지를 투자할 의향이 있다면, 결과 모델은 원본의 더 큰 모델과 동등하거나 그 이상의 품질을 내면서도 훨씬 작고, 더 다양한 기기에서, 훨씬 더 빠르게 동작한다. 발표자는 이를 "대규모 구현을 위한 아주 좋은 전략"이라고 평가한다

---

8. 소형 모델의 위치 — 시스템의 "주연"이 아닌 "부품"

1. 작은 모델이 필요한 진짜 이유

   1. 주요 기능이 아닌 보조 부품: 실제 프로덕션에서는 실행하려는 모델이 애플리케이션의 주요 기능이 아니라, 시스템 전체가 원활히 작동하도록 돕는 "작은 부품(코너 케이스)" 역할을 하는 경우가 흔하다
   2. 시스템 건전성 목적: 이런 경우 시스템의 전반적인 건전성(health)을 위해 별도로 더 작은 모델이 필요해지는 것이 반복되는 패턴이라고 설명한다

2. 오래된 기기·저사양 소비자 기기 포용

   1. 경계선 확장: 지금 존재하는 소형 모델들도 여전히 오래된 노트북이나 저사양 소비자 기기에는 닿지 못하는 경우가 있으며, 그 경계를 계속 넓혀 나가는 것이 팀의 목표라고 밝힌다

---

9. Q&A 세션

1. 질문: 음성 중심 접근에서 시각(비전) 입력으로도 확장할 계획이 있는가?

   1. 답변 요지: 함수 호출을 더 일반화하고, 갈 수 있는 범위(야망)를 넓히는 것이 목표다. 음성은 핵심 사용 사례인데, 많은 사람들에게 진입장벽이 가장 낮은 입력 방식이기 때문이다. 에이전트가 스스로 합성 데이터를 생성하는 방법을 찾아낼 수 있다면, 오늘보다 훨씬 더 많은 사람들에게 도달할 수 있을 것으로 본다
   2. 시각 입력에 대한 입장: 시각 입력 역시 다루고 싶지만 아직 시간이 더 걸리는 영역이며, 더 완벽한 세분화(segmentation) 등 광범위한 기능을 지원하는 더 빠른 모델을 위한 여지가 충분히 있다고 밝힌다

2. 세션 마무리

   1. 추가 질문 안내: 시간 제약으로 공식 Q&A는 여기서 마무리하지만, 세션 이후에도 남아서 추가 질문을 받겠다고 안내
   2. 부스 안내: 오후 4시경 아래층 부스(DeepMind 관련 부스로 추정)에서도 만날 수 있다고 언급하며 마무리

---

주요 발언 모음

"매우 작은. 그리고 이 강연은 바로 이것에 관한 것입니다. 모델의 최첨단 기술, 지금은 아주 작습니다."

"단순히 만드는 대신, 가장자리(엣지)를 만드는 것. 모든 것이 클라우드에 있습니다. 아시다시피, 그건 당연하죠, 하지만 어쨌든 리뷰를 해볼게요."

"작다는 뜻입니다. 여기서 작다는 것은 정말 작다는 의미입니다. 저는 보통 10억에서 40억 사이의 매개변수를 지칭할 때 이렇게 말합니다."

"실행하려는 모델은 애플리케이션의 주요 기능이 아니라 마치 작은 부품 같아요. 시스템의 나머지 모든 것이 잘 작동하도록 돕는 코너의 존재죠."

"제로샷 프롬프팅이 있어야만 괜찮은 결과물을 얻을 수 있는 특정 작업을 위해서는, 저희는 최적화를 위해 열심히 노력했습니다."

"우리가 얻고 있는 결과가 바로 이런 겁니다 — 지금 보면 단일 작업을 위해 모델을 조정하는 것만으로도, 정말로 대규모 구현을 위한 아주 좋은 전략이라고 생각합니다."

---

핵심 데이터 & 수치

• 소형 모델 정의: 10억(1B)~40억(4B) 파라미터, 필요 RAM 약 4~8GB
• 초소형(tiny) 모델 정의: 5천만(50M)~5억(500M) 파라미터, 필요 RAM 2GB 이하
• 텍스트 모델 가중치 크기: 양자화(2.9비트/가중치 평균) 적용 후 약 841MB
• 실행 시 활성 RAM: KV 캐시 포함 최대 약 2GB, 실무 권장 기준 4GB 이상
• 라즈베리파이 디코딩 속도: 2B 모델 기준 초당 약 7.6토큰(MTP 미적용), MTP 적용 시 약 2배
• Jetson Orin Nano 디코딩 속도: 초당 최대 24토큰 (NVIDIA 툴체인 사용 시 그 이상)
• Qualcomm NPU 성능: 프리필 약 4,000토큰/1회, 디코딩 초당 약 31토큰
• 함수 호출 특화 모델(Function Gemma) 라즈베리파이 속도: 초당 약 45토큰
• Mobile Action 모델 신뢰도: 약 10개 함수 중 86% 이상 확률로 올바른 함수 호출
• 비전 모델 토큰 수: 중간 해상도 약 500토큰, 고해상도 약 1,120토큰, 초당 약 3프레임 처리
• 합성 데이터 필요 규모: 파인튜닝에 약 1만~100만 개 샘플
• Fast VLM(애플) 비교 사례: 0.5B(5억) 파라미터로 안드로이드에서 하드웨어 가속 활용해 매우 빠르게 동작

결론 및 시사점

1. 엣지 AI는 클라우드의 대안이 아니라 클라우드가 못 하는 것을 하는 영역이다: 지연시간, 프라이버시, 오프라인 신뢰성, 대규모 사용자 기반에서의 비용 절감이라는 4가지 축에서 온디바이스 소형 모델이 구조적 우위를 가진다.
2. "작은 모델"은 하나의 카테고리가 아니라 계층 구조다: 5천만~5억 파라미터의 초소형(tiny) 모델은 고정 작업(ASR·비전·임베딩)에, 10억~40억 파라미터의 소형 모델은 좀 더 범용적인 추론과 함수 호출에 각각 적합하며, RAM·속도 요구사항이 크게 다르다.
3. NPU 탑재 기기에서는 이미 실시간 수준의 성능이 나온다: Qualcomm NPU 기준 디코딩 초당 31토큰, 프리필 4,000토큰은 대부분의 실용적 엣지 애플리케이션에 충분한 속도다.
4. 함수 호출·음성 인터페이스가 IoT/엣지의 킬러 유즈케이스다: 복잡한 설정 UI 없이 "말을 걸어 원하는 결과를 얻는" 것이 소형 모델의 가장 즉각적인 가치이며, Mobile Action 같은 특화 모델이 86% 이상의 신뢰도로 이를 구현하고 있다.
5. 소형 모델 성공의 진짜 열쇠는 합성 데이터 투자다: 좋은 베이스 모델을 고르는 것보다, 목표 작업에 맞는 1만~100만 개 규모의 합성 데이터셋을 정성껏 만드는 것이 더 큰 모델과 동등한 품질을 훨씬 작은 크기로 얻는 지름길이다.
6. 소형 모델은 종종 "주인공"이 아니라 "시스템을 지탱하는 부품"이다: 프로덕션에서는 눈에 띄는 메인 기능이 아니라, 오래된 기기·저사양 환경까지 시스템이 안정적으로 동작하도록 만드는 보조 역할로 더 자주 쓰인다.
7. 직접 체험 가능: AI Edge Gallery 앱(iOS/안드로이드, 오픈소스)과 Open Dot Mini v2 로봇 데모, Mobile Action 데이터셋(Hugging Face)이 모두 공개되어 있어 개발자가 직접 재현·실험할 수 있다.