▲

Gemma 4 가속하기 : 다중 토큰 예측 drafter로 더 빠른 추론

 (blog.google)
4P by GN⁺ 2시간전 | ★ favorite | 댓글 1개
  • Google은 Gemma 4 공개 후 몇 주 만에 다운로드 6,000만 회를 넘겼고, Gemma 4 제품군용 다중 토큰 예측(MTP) drafter를 공개함
  • MTP drafter는 특화된 추측 디코딩(speculative decoding) 아키텍처로 출력 품질이나 추론 로직 저하 없이 추론 속도를 최대 3배 높이며, LiteRT-LM, MLX, Hugging Face Transformers, vLLM 사용 하드웨어에서 테스트됨
  • 표준 LLM 추론은 단일 토큰 생성을 위해 수십억 개 매개변수를 VRAM에서 연산 유닛으로 옮기느라 메모리 대역폭 병목이 커지고, MTP는 가벼운 drafter가 여러 미래 토큰을 제안한 뒤 대상 모델이 병렬 검증하게 만듦
  • 대상 모델이 초안 토큰에 동의하면 전체 시퀀스를 단일 순전파에서 받아들이고 추가 토큰 하나도 생성해, 애플리케이션은 보통 단일 토큰 시간에 초안 시퀀스와 추가 토큰을 출력할 수 있음
  • MTP drafter는 대상 모델 활성값과 KV 캐시를 공유하고, E2B·E4B 엣지 모델에는 효율적인 임베더(embedder) 클러스터링을 적용하며, 가중치는 Hugging Face와 Kaggle에서 Apache 2.0 라이선스로 제공됨

추측 디코딩이 필요한 이유

  • 표준 LLM 추론은 메모리 대역폭에 묶여 있어 지연 병목이 커짐
  • 프로세서는 단일 토큰을 생성하기 위해 수십억 개의 매개변수를 VRAM에서 연산 유닛으로 옮기는 데 대부분의 시간을 쓰게 됨
  • 이 구조는 특히 소비자용 하드웨어에서 연산 자원을 충분히 활용하지 못하게 만들고 지연을 높임
  • 추측 디코딩은 토큰 생성과 검증을 분리함
  • 무거운 대상 모델, 예를 들어 Gemma 4 31B를 가벼운 drafter인 MTP 모델과 짝지어, 비어 있는 연산 자원으로 여러 미래 토큰을 한 번에 예측함
  • drafter는 대상 모델이 토큰 하나를 처리하는 데 걸리는 시간보다 짧은 시간에 여러 토큰을 제안하고, 대상 모델은 제안된 토큰을 병렬로 검증함

MTP가 동작하는 방식

  • 표준 대규모 언어 모델은 자기회귀 방식으로 텍스트를 생성하며, 한 번에 정확히 하나의 토큰만 만듦
  • 이 방식은 “Actions speak louder than…” 뒤에 “words”를 예측하는 쉬운 이어쓰기와 복잡한 논리 퍼즐 풀이에 같은 양의 연산을 투입함
  • MTP는 Google 연구자들이 Fast Inference from Transformers via Speculative Decoding에서 도입한 추측 디코딩으로 이런 비효율을 줄임
  • 대상 모델이 초안 토큰에 동의하면 전체 시퀀스를 단일 순전파에서 받아들이고, 대상 모델 자체도 추가 토큰 하나를 동시에 생성함
  • 애플리케이션은 보통 단일 토큰을 생성하는 데 걸리는 시간에 초안 시퀀스 전체와 추가 토큰 하나를 출력할 수 있음

개발자에게 주는 성능 효과

  • 개발자에게 추론 속도는 프로덕션 배포의 주요 병목이 되는 경우가 많음
  • 빠른 다단계 계획이 필요한 자율 에이전트, 코딩 어시스턴트, 온디바이스로 완전히 실행되는 반응형 모바일 애플리케이션에서는 밀리초 단위 지연도 중요함
  • Gemma 4 모델을 해당 drafter와 함께 사용하면 다음 효과를 얻을 수 있음

  • 응답성 개선

    • 거의 실시간 채팅, 몰입형 음성 애플리케이션, 에이전트형 워크플로의 지연을 크게 줄일 수 있음

  • 로컬 개발 가속

    • 개인 컴퓨터와 소비자용 GPU에서 26B MoE 및 31B Dense 모델을 빠르게 실행해 복잡한 오프라인 코딩과 에이전트형 워크플로를 지원함

  • 온디바이스 성능 향상

    • E2B 및 E4B 모델을 엣지 기기에서 더 빠르게 출력하도록 해 기기의 배터리 사용을 줄이는 데 도움이 됨

  • 품질 저하 없음

    • 기본 Gemma 4 모델이 최종 검증을 유지하므로 같은 수준의 추론과 정확도를 훨씬 빠르게 제공함
    • Gemma 4 26B를 NVIDIA RTX PRO 6000에서 실행한 예시는 표준 추론과 MTP drafter의 초당 토큰 수 차이를 비교하며, 같은 출력 품질에서 대기 시간이 절반 수준임을 보여줌
    • 비교 영상은 다운로드해 볼 수 있음

MTP drafter의 내부 최적화

  • MTP drafter를 빠르고 정확하게 만들기 위해 여러 아키텍처 개선이 적용됨
  • 초안 모델은 대상 모델의 활성값을 자연스럽게 활용하고 대상 모델의 KV 캐시를 공유함
  • KV 캐시 공유 덕분에 큰 모델이 이미 처리한 문맥을 다시 계산하는 데 시간을 낭비하지 않음
  • E2B와 E4B 엣지 모델에서는 최종 로짓 계산이 큰 병목이 되기 때문에, 임베더에 효율적인 클러스터링 기법을 구현해 생성을 더 빠르게 함
  • 하드웨어별 최적화도 분석됨
  • Apple Silicon에서 26B mixture-of-experts 모델은 배치 크기 1일 때 고유한 라우팅 과제가 있지만, 여러 요청을 동시에 처리하면 로컬에서 최대 약 2.2배 속도 향상을 얻음
  • 예시 배치 크기는 4~8이며, NVIDIA A100에서도 배치 크기를 늘릴 때 유사한 향상이 나타남
  • 시각적 아키텍처, KV 캐시 공유, 효율적인 임베더의 동작 방식은 심층 기술 설명에서 확인할 수 있음

사용 방법과 제공 위치

  • Gemma 4 제품군용 MTP drafter는 Gemma 4와 같은 오픈소스 Apache 2.0 라이선스로 제공됨
  • MTP를 Gemma 4와 함께 사용하는 방법은 문서에서 확인할 수 있음
  • 모델 가중치는 Hugging Face와 Kaggle에서 다운로드할 수 있음
  • 더 빠른 추론은 transformers, MLX, vLLM, SGLang, Ollama로 실험할 수 있음
  • Google AI Edge Gallery에서 Android 또는 iOS로 직접 사용해볼 수 있음
  • Google은 Gemma 생태계인 Gemmaverse에서 이 속도 향상이 개발을 가속하기를 기대함

함께 보면 좋은 글 β

▲
GN⁺ 2시간전  [-]
Hacker News 의견들

  • Gemma와 Gemini는 다른 모델보다 출력 토큰을 훨씬 적게 쓰면서도 최상위 벤치마크 성능에 꽤 근접해 있음
    Gemma와 Qwen을 비교하면 Qwen이 조금 더 잘하지만 작업에 22분을 쓰고, Gemma는 버튼 정렬을 틀리더라도 같은 프롬프트를 4분 만에 끝내는 경우가 흔함
    겉보기로는 Gemma가 선두 오픈 모델보다 5~10% 낮은 성능을 내지만, 시간은 1/10만 쓰는 셈임

    • 체감상 월 15달러짜리 Gemini 기본 플랜으로 하루 종일 코딩해도 한도에 걸리지 않음
      Claude나 Codex에서 다른 사람들이 월 100달러 플랜으로 올리는 것처럼 업그레이드할 필요도 못 느낌
      다만 Gemini는 지난 1년 동안 몇 번 성능이 낮아졌고, 속도 제한도 빡빡해졌기 때문에 앞으로도 이만큼 좋을지는 모름
    • Dwarkesh 팟캐스트에서 SemiAnalysis의 Dylan Patel이 Google은 훨씬 많은 연산 자원과 TPU 접근성 덕분에 경쟁사보다 큰 모델을 감당할 수 있다고 했음
      같은 지능 단위당 큰 모델이 보통 더 적은 토큰을 쓰므로, 토큰 사용량 차이를 설명할 수 있어 보임
    • Gemma가 빠르다 보니 원래는 크기가 부족한 GPU에서도 돌릴 수 있음
      4070에서 실행해 봤는데 출력이 엄청 빠르진 않아도 쓸 만했음
      아직 복잡한 작업에는 써보지 않았고, 그런 경우엔 다를 것 같음
    • 지금은 Claude가 매우 유행하지만, Gemini를 쓰면서 문제를 겪거나 갈아탈 필요를 느낀 적은 없음
      Google I/O 이후에는 더 많은 사람이 Gemini가 얼마나 좋은지 알게 될지도 모름
    • 맞는 말이지만 공정하게 보려면 누적 토큰 출력량을 합산해야 함
      정렬 문제가 생기면 이를 고치기 위해 입력·출력 토큰을 한 번 더 써야 함

  • llama.cpp에 MTP 지원이 추가되고 있고, 적어도 Qwen 모델용으로는 진행 중임(https://github.com/ggml-org/llama.cpp/pull/20533)
    Gemma 4도 곧 따라올 것 같음
    최근 몇 달 동안 로컬·자체 호스팅 모델의 품질과 속도 향상이 놀라울 정도임

    • 더 최신 PR이 있고 곧 병합될 것 같음: https://github.com/ggml-org/llama.cpp/pull/22673
    • 며칠 전 개인 용도로 Qwen3.6에서 Gemma 4로 다시 갈아탔는데, 후자의 26B 버전이 전자의 27B보다 평균적으로 더 나은 성능을 보여줬음
      오랫동안 로컬 모델을 돌려온 입장에서는 정말 흥미로운 시기임
    • DFlash 통합에도 관심이 커지고 있음: https://github.com/ggml-org/llama.cpp/issues/21978
      MTP와 비교하면 어떨지 빨리 보고 싶음
    • oMLX에서도 이걸 보고 싶음
      꽤 괜찮은 도구였음
    • MTP 추론이 추론 스택의 어디에 들어가는지는 정확히 모르겠지만, MLX 생태계에서 구현 가능한지 아는 사람이 있으면 궁금함

  • Google이 서구권 오픈소스 모델을 거의 혼자 떠받치고 있음
    Gemma 4 31B는 훌륭함
    다만 시각 기능과 곧 나올 드래프터까지 포함해 최상의 버전을 24GB VRAM에 맞추려면 꽤 고통스러움
    내 빌드는 GPU를 더 추가할 수 없고, 최고 성능을 내려면 4090을 하나 더 사야 할 것 같은데 너무 비싸거나, 아니면 아예 교체해야 할 듯함

    • llama.cpp에서 --no-mmproj-offload를 쓰면 멀티모달 프로젝터, 즉 오디오·이미지·PDF 이해 부분을 시스템 RAM에 둘 수 있음
      물론 그러면 GPU 가속은 안 되지만 VRAM은 절약됨
    • 그래도 Qwen이 Gemma보다 낫다고 봄
      작업별로 더 조정할 수도 있어서, 사고와 정확도를 우선할지 추론 속도를 우선할지 선택 가능함

  • 컴퓨터가 글을 쓰는 걸 보고 있으면 예전 BBS에 모뎀으로 접속하던 시절이 떠오름
    이건 300 보드에서 1200 보드로 올라간 것 같은 느낌이라 큰 개선이긴 하지만 여전히 꽤 느리고, 언젠가는 우리가 이걸 어떻게 참고 썼는지 의아해할 것 같음

    • 요즘 상태는 정말 전화 접속 시대 같고, 앞으로의 “광대역” 시대가 어떤 모습일지 계속 생각하게 됨
      토큰이 흘러나오는 걸 보는 건 JPEG가 픽셀 몇 줄씩 로드되는 걸 보는 느낌이고, 앱들이 속도가 충분히 빨라지기 전 각자 구현하던 여러 로딩·연결 애니메이션도 떠오름
      Cerebras나 Taalas가 하는 작업은 그런 방향에서 무엇이 가능할지 보여주는 흥미로운 단서임
      지금 최첨단 모델도 초당 백만 토큰을 아주 낮은 비용으로 쓸 수 있다면 무엇이 가능할지 상상해 보는 것도 재미있음
    • 전화 접속 시대를 떠올리게 한다는 건 맞지만, 300에서 1200이라기보다는 4800 보드에 더 가까워 보임
      Claude가 계산한 모뎀 대 Claude 비교는 이렇음: 2368자 기준 300은 1분 19초, 1200은 19.7초, 2400은 9.9초, 14.4K는 1.6초, 33.6K는 705ms, 56K는 447ms, Claude는 7.9초임
    • 여기 올라왔던 어떤 스타트업은 AI가 즉시 응답하게 하는 맞춤형 하드웨어를 만들었음
      초당 수천 토큰 수준이었음

  • Google의 전략은 다른 프런티어 제공자들과 조금 다른 것 같음
    순수 성능보다 연산 대비 성능 효율에 더 집중하는 듯하고, 그래서 Gemini가 겉보기에는 뒤처져 보이는 걸지도 모름
    다른 제공자들은 용량 한계에 부딪히고 추론 비용 보조에도 한계가 오는 중임
    Google의 전략은 이 모델들을 기존 수십억 사용자에게 확장하고 배포하는 쪽으로 보임

    • Gemini가 뒤처진다고 보지는 않음
      오히려 최신 GPT-5와 Claude 계열과는 다른 종류의 지능처럼 느껴짐
      후자는 점점 생산성과 업무 자동화에 집중하고, 길고 에이전트적인 자기수정 추론 루프에 최적화되어 있음
      Gemini는 훨씬 똑똑한 기본 모델 같고, 특히 Deep Think 모드에서는 직관이 훨씬 깊게 느껴지지만, 장거리 자기수정형 에이전트 루프는 그만큼 잘하지 못함
      몇 달 동안 내 작업 흐름은 창의적 도약과 통찰에는 Gemini를 쓰고, 반복적이거나 정밀한 작업에는 Codex, Claude, GPT-5.5 Pro를 선호하는 방식이었음
    • 그 방향으로 모두의 전략이 바뀌는 중 아닌가 싶음

  • 로컬 모델을 한동안 쉬다가 최근 26B A4B 모델을 RTX 3090에서 vLLM 4비트로 설정했는데, 1000달러 미만 투자로 얻을 수 있는 속도와 품질에 완전히 놀랐음
    처음엔 Qwen으로 해봤지만 불안정했고, 사고 흔적이 터무니없이 길었음

    • qwen3.6의 초기 양자화본 중 일부는 깨져 있었음
      아직도 까다롭긴 하지만 조금만 손봐주면 정말 대단함
      로컬 모델이 미래라서 멋짐
    • turboquant / Q4를 쓰면 3060에도 올라가고, 약 200달러 카드에서 괜찮은 속도인 40T/s가 나옴
    • A4B 모델은 엄청 빠르고 일반 질의에 매우 좋음
      코딩 작업에서는 Qwen 3.6보다 확실히 떨어지지만, 그건 오히려 Qwen 모델이 뛰어나다는 뜻에 가까움
    • 31B도 조밀 모델치고는 놀라울 만큼 빠름
      내 컴퓨터에서는 다른 30B 모델과 비교했을 때 tg가 기대보다 적어도 두 배 빠른데, 아마 하이브리드 어텐션 덕분인 듯함
      다만 입력 처리 쪽은 조금 더 느림

  • 이걸 LM Studio에서 동작시키는 데 성공한 사람이 있는지 궁금함
    UI에 옵션은 있는데 활성화가 되는 것 같지 않음

    • 아직 mlx[1]나 llama.cpp[2]에는 구현되지 않아서 시간이 좀 걸릴 수 있음
      [1] https://github.com/ml-explore/mlx-lm/pull/990
      [2] https://github.com/ggml-org/llama.cpp/pull/22673
    • 됨
      작은 모델이 없으니 Gemma 희소 모델을 쓰고 있지 않은지 확인해야 함
      그리고 작업 공간에서 이미지 모델을 전부 제거했음
    • 보통 LM Studio가 싫어하는 경우는 폴더 안에 mmproj 파일이 있을 때임
      가끔 이것들을 지우면 표시되기도 함
      이 파일들이 어떻게든 시각 기능과 연결되어 있고 추측 디코딩을 막는 듯한데, 이유는 묻지 말아 달라
      Gemma에서는 LM Studio보다 llama-server 경로로 추측 디코딩을 쓰는 쪽이 더 잘 됐음
    • 다른 모델로는 동작시킨 적 있음
      보통 제공자, 양자화 등에서 서로 완벽히 맞아야 함
      짝이 맞는 세트를 구하려면 시간이 좀 걸릴 수 있음

  • 내 테스트에서는 Gemma 4 31B 모델이 코딩 작업에서 Ollama의 MLX 러너를 쓸 때 가장 큰 속도 향상을 보였고, 대략 2배였음
    다만 양자화가 수락률을 크게 깎기 때문에 꽤 강력한 Mac이 필요함
    다른 세 개의 더 작은 모델은 드래프트 모델 검증 시간이 성능 향상을 대부분 먹어버려서 그만큼 좋지 않았음
    더 나은 성능을 낼 수 있는지 아직 조정 중임
    Ollama 0.23.1에서 ollama run gemma4:31b-coding-mtp-bf16를 실행해 시험해 볼 수 있음

  • llama.cpp에 병합되면 정말 빨리 써보고 싶음
    내 환경에서는 Gemma 4 26B-A4B가 Qwen3.6-35B-A3B보다 약 3배 빠르기 때문에, 여기에 1.5배 가속이 더해진다는 생각만 해도 끌림
    드래프트 모델도 시도했지만 성과는 제한적이었고, 더 작은 3B 드래프트 모델과 조밀 14B Ministral 모델도 이미 너무 많은 오버헤드를 만들었음

    • vLLM에서 5090을 쓰면 awq 4비트 양자화와 MTP 추측 디코딩으로 120~180TPS가 나옴
      Gemma4 26B는 같은 양자화에서 200TPS를 넘음
      Qwen은 추론 효율이 극도로 낮다는 점도 중요함
      사고 사슬이 평균적으로 Gemma보다 약 3배 김

  • 이건 운영체제의 분기 예측 같은 건가 싶음
    다만 확률이 모델 자체에 내장되어 있으니 훨씬 더 신뢰할 수 있는 형태임

    • 비슷한 발상이지만 실패 방식이 더 나음
      분기 예측 실패는 사이클을 태워버리지만, 여기서 나쁜 추측은 보통 보너스 토큰을 못 얻는 정도임
      https://arxiv.org/abs/2211.17192
답변달기