Gemma 4 추론 3배 빨라진다는 발표, 한 번 뜯어봤음

Gemma 4 풀린 지 한 달도 안 됐는데 추론 속도를 최대 3배까지 끌어올린다는 MTP 드래프터가 또 발표됐어요. 그것도 모델 품질은 그대로라는 단서를 달고. 처음에는 "또 좋은 케이스만 골라서 보여주겠지" 싶었는데, 작동 방식 따라가다 보니 단순한 마케팅 수치만은 아닌 것 같음.

본문 들어가기 전에 짚고 가는 용어 몇 개.

• MTP (Multi-Token Prediction): 한 번에 토큰 하나씩 뱉는 일반적인 자동회귀 방식 대신, 여러 토큰을 한꺼번에 예측하는 기법
• Speculative decoding: 작은 모델이 미리 토큰을 "추측"해두고 큰 모델이 한꺼번에 검증·승인하는 방식
• Drafter: 위에서 말한 그 "추측 담당" 작은 모델. 이번에 따로 풀린 게 이거임
• KV cache: 트랜스포머가 이전 토큰 처리할 때 만든 key/value 텐서를 들고 있는 메모리 영역. 재활용하려고 캐싱해두는 것

일단 왜 빠른가#

LLM 추론은 compute-bound가 아니라 memory-bandwidth-bound임. 풀어 쓰면, GPU가 실제로 곱셈·덧셈 하느라 바쁜 게 아니라 수십억 개 파라미터를 VRAM에서 컴퓨트 유닛으로 옮기는 데 시간을 다 쓴다는 얘기. 토큰 하나 뱉을 때마다 모델 전체를 한 번씩 훑어야 하니까 자연스러운 귀결임.

여기서 빈틈이 생김. GPU 컴퓨트 자체는 노는 시간이 꽤 있음. Speculative decoding은 그 노는 시간을 작은 드래프터가 미리 토큰 몇 개 추측하는 데 씀. 그러면 큰 타겟 모델은 그 추측들을 forward pass 한 번에 묶어서 검증함. 통과하면 한꺼번에 여러 토큰이 빠져나오는 구조.

검증에서 떨어지면 그 지점부터 다시 일반 방식으로 진행. 그래서 출력 품질은 이론상 100% 동일하게 유지됨. 이 부분은 메커니즘 자체가 맞아서 의심할 여지가 거의 없음.

발표 수치, 액면 그대로 받지 말 것#

Google 공식 발표에 따르면 LiteRT-LM, MLX, Hugging Face Transformers, vLLM 같은 주요 프레임워크에서 모두 속도 향상이 있다고 함. 26B MoE 모델을 NVIDIA RTX PRO 6000에서 돌렸을 때 토큰/초가 대략 2배 가까이 나오는 그래프도 같이 올라왔고요.

근데 이거 그대로 받으면 안 됨. 자기네 발표니까 가장 잘 돌아가는 환경, 잘 맞는 batch size를 골라서 보여주는 게 당연함. 본문에서도 슬쩍 언급되는 부분이 있는데, 26B MoE는 Apple Silicon에서 batch size 1일 때는 라우팅 문제 때문에 별로 안 빠르고, batch 4~8 정도 가야 약 2.2x 정도 나온다고 함. NVIDIA A100도 비슷한 패턴이라고 명시됨.

즉 "최대 3배" 헤드라인은 조건부임. 적절한 하드웨어 + 적절한 batch + 입력 분포가 드래프터 prediction에 잘 맞을 때. 특히 batch size 부분은 1인 개발자에게 좀 애매함. 로컬에서 돌릴 땐 보통 batch 1로 쓰니까. 내 IDE에 띄워놓고 쓰는 코딩 어시스턴트라면 batch 1이 디폴트인데, 발표 수치는 batch 4~8 환경에서 나온 거라 그대로 적용되긴 어려움.

컨슈머 GPU 환경에선 어디까지 가나#

내 환경이 RTX 3090이라 31B Dense가 메인 관심사임. 양자화하면 어찌어찌 돌긴 도는 사이즈인데 latency가 늘 아쉬웠음.

드래프터 붙이면 실제로 어떻게 될지는 안 돌려봐서 정확한 건 모름. 다만 메커니즘상 이 정도는 예상 가능함. batch 1 환경에서도 속도 향상은 분명히 있을 것임 — KV cache 공유 때문에 컨텍스트 재처리 비용이 거의 사라지니까. 다만 발표된 "3배"는 안 나올 가능성이 큼. 직관적으로는 1.5~2배 정도가 현실적이지 않을까 싶은데, 안 잰 거니까 어디까지나 추정임.

후기들 보면 다들 어떻다고 하던데 — 솔직히 출시 직후라 실사용 후기가 거의 없음. Hugging Face discussion이나 r/LocalLLaMA에서 며칠 더 지나야 감이 올 듯. 발표 다음 날 글 올라온 사이트들이 있긴 한데, 대부분은 실측 안 하고 발표 자료 그대로 옮긴 수준이라 별로 신뢰도가 없음.

아키텍처 디테일이 더 흥미로움#

이 발표에서 진짜 흥미로웠던 건 속도 자체보다 디테일 쪽이었음. 드래프터가 타겟 모델의 activation이랑 KV cache를 공유한다는 부분. 보통 드래프터를 따로 돌리면 같은 컨텍스트를 두 번 처리하는 셈인데, 캐시 공유로 그 중복을 거의 다 없앴다는 얘기.

엣지용 E2B/E4B 모델에는 임베더에 클러스터링 기법까지 따로 넣었다고 함. 모바일 추론에서 final logit 계산이 병목이 되는 걸 줄이려는 시도. 안 돌려봐서 효과는 모르겠는데, 모바일에서 의미 있는 차이를 만들려면 이 정도 디테일까지는 들어가야 했을 듯.

여기까진 공식 발표 내용이고 — 내 생각엔, "드래프터를 따로 푼다"는 접근 자체가 좀 영리함. 큰 모델은 그대로 두고 보조만 따로 받게 했으니, 기존에 31B나 26B 받아서 쓰던 사람들이 드래프터만 추가로 받아 붙이면 끝이거든요. 모델 교체 없이도 속도만 챙길 수 있는 구조.

걸리는 부분 몇 개#

"zero quality degradation" 주장이 깔끔하긴 한데, speculative decoding 메커니즘 특성상 이론적으로는 동일한 게 맞음. 다만 드래프터의 prediction 정확도가 너무 낮으면 오히려 더 느려지는 케이스가 생김. 검증 실패가 잦을수록 재시도 비용이 누적되니까. 이 부분은 입력 분포에 따라 결과가 꽤 갈릴 가능성이 있음.

발표에서 안 다룬 부분도 하나 있음. 메모리 사용량은 분명히 늘어남. 드래프터도 VRAM에 같이 띄워야 하니까. 31B 가까스로 돌리는 환경이라면 드래프터 추가가 OOM을 부를 수도 있을 듯. 발표에 드래프터 사이즈가 명확히 안 적혀 있는데, 현실적으로 1~3B 수준일 거라 추측됨. 그 정도면 RTX 3090 24GB에서 31B 양자화본 + 드래프터 같이 띄우는 건 빡빡할 가능성이 있음.

라이선스는 Apache 2.0 그대로 풀린 게 좋음. 다만 드래프터가 어떻게 학습됐는지, 어떤 데이터를 썼는지에 대한 정보는 발표에 거의 없음. 이건 모델 카드에서 더 풀리지 않을까 싶네요.

잡담 — 효율 기법이 화제가 되는 시기#

올해 들어 로컬 LLM 진영에서 "더 큰 모델"보다 "같은 모델 더 빠르게"가 더 자주 화제가 되는 게 느껴짐. 작년만 해도 405B니 671B니 사이즈 경쟁이 분위기였는데, 올해는 양자화·증류·이번 같은 speculative decoding 같은 효율 기법이 첫 페이지에 더 자주 올라옴.

뭐 당연한 흐름이긴 함. 모델 사이즈가 한 임계점을 넘으면 그다음은 같은 능력을 어떻게 더 싸게 돌리느냐 싸움이 되니까. 컨슈머 GPU 사용자 입장에선 이 흐름이 훨씬 반가움. 700B짜리 새 모델 나와봐야 어차피 못 돌리거든요.

마무리#

정리하면 — speculative decoding 자체는 새 기술이 아니고 2022~2023년에 Google 페이퍼("Fast Inference from Transformers via Speculative Decoding")로 이미 정리된 내용. 이번 발표의 핵심은 "Gemma 4 가족 전용으로 최적화된 드래프터를 따로 풀었다"는 점이고, 발표된 3배 수치는 best case이며 환경·batch·입력 분포에 따라 1.5~3배 사이로 갈릴 듯. 컨슈머 GPU 1인 환경에선 속도 향상은 분명히 있겠지만 헤드라인만큼은 아닐 가능성이 큼.

Hugging Face에 가중치는 이미 풀려 있으니까, vLLM 환경에서 RTX 3090에 batch 1로 직접 돌려볼 가치는 충분히 있어 보임. 다음 글에서 31B + 드래프터 조합으로 batch 1 기준 실제 토큰/초가 어떻게 나오는지 정리해볼 예정. OOM 안 나기를 빌면서.

공식 발표 원문은 Google Developers Blog에서 확인 가능.