구글 Gemma 4가 한 번에 토큰 여러 개를? 추론 속도 3배의 비밀, MTP 드래프터

요즘 LLM 시장의 진짜 전쟁터는 모델 크기가 아니라 추론 속도입니다. 구글이 내놓은 Gemma 4가 “한 번에 토큰 여러 개를 예측한다"는 얄궂은 기술로 기존 대비 3배 빠른 속도를 찍었다는 이야기가 도는데요. 오늘은 이 멀티 토큰 프리딕션(MTP) 드래프터가 도대체 뭔지, 왜 이게 게임 체인저인지 풀어보겠습니다.

LLM이 느린 진짜 이유: “한 글자씩” 토해내기 때문

대형 언어 모델이 텍스트를 생성하는 방식을 알면 왜 느린지 단번에 이해됩니다. 모델은 한 번에 토큰 하나만 예측합니다. “안녕하세요"를 만들려면 “안” → “녕” → “하” → “세” → “요” 순서로 다섯 번을 도는 거죠.

문제는 GPU 입장에서 이게 너무 비효율적이라는 점인데요. 매 토큰마다 수십~수백억 개의 파라미터를 모두 한 번씩 메모리에서 불러와야 합니다. 정작 계산은 금방 끝나는데, 메모리에서 가중치를 읽어오는 시간이 병목입니다. 업계에서 흔히 “memory-bound"라고 부르는 그 문제죠.

스페큘러티브 디코딩: 작은 모델이 미리 찍고, 큰 모델이 검증

이 병목을 우회하기 위해 등장한 게 스페큘러티브 디코딩(speculative decoding)입니다. 아이디어는 의외로 단순합니다.

작고 빠른 “드래프트 모델"이 다음에 올 토큰 5~10개를 미리 추측합니다. 그러면 본체인 큰 모델은 그걸 한 번에 받아서 “맞다/틀리다"를 검증만 하면 됩니다. 검증은 한 번의 forward pass로 가능하기 때문에, 5개가 다 맞으면 한 번의 큰 모델 호출로 5개 토큰을 얻는 셈입니다.

다만 이 방식엔 함정이 있습니다. 드래프트 모델을 따로 학습하고 띄워야 한다는 것입니다. 메모리도 더 먹고, 큰 모델과 토크나이저가 안 맞으면 정확도가 흔들립니다.

Gemma 4의 한 수: MTP 드래프터를 모델 안에 박아넣기

Gemma 4가 들고 나온 카드는 멀티 토큰 프리딕션(Multi-Token Prediction, MTP)을 모델 자체에 내재화한 방식입니다. 별도의 작은 드래프트 모델을 띄울 필요 없이, Gemma 4 본체에 여러 개의 “예측 헤드"가 달려 있어서 한 번의 forward pass에 다음 토큰 여러 개를 동시에 뽑아냅니다.

이 헤드들이 만든 후보를 본체가 곧바로 검증하는 구조이기 때문에, 별도 드래프트 모델의 단점이 사라집니다. 토크나이저 불일치도 없고, 추가 메모리 부담도 적죠. 유튜브 채널 Compile Future가 5월 6일 공개한 영상에서 Claude Code 환경에 이 MTP 드래프터를 적용해 본 결과 3배 빠른 속도가 나왔다고 보고했습니다. 게시 하루도 안 돼 1,400회 넘게 재생되며 95개의 좋아요를 받았는데, 댓글 반응에서도 “로컬 추론에서 체감이 다르다"는 평이 이어졌습니다.

야코비 반복부터 MTP까지: 병렬 디코딩의 큰 그림

사실 MTP는 갑자기 튀어나온 기술이 아닙니다. 4월 26일 Byte Goose AI 채널이 올린 “Parallel Decoding: New Standard for Fast LLM Inference"라는 영상은 이 흐름을 잘 정리하는데요. 1,600회 이상 재생되며 학계에서 거론되던 야코비 반복(Jacobi iteration), Lookahead 디코딩, Medusa, EAGLE 같은 기법들을 함께 다룹니다.

핵심 메시지는 명확합니다. “토큰을 하나씩 뽑는 시대는 끝났다"는 겁니다. Meta가 지난해 Llama 학습에 MTP 손실을 도입했고, DeepSeek도 비슷한 방향을 채택했습니다. 구글이 Gemma 4에 이를 정식 탑재하면서, 이제는 오픈웨이트 모델의 표준 옵션이 되어가는 분위기입니다.

개발자에게 이게 왜 중요한가

추론이 빨라진다는 건 단순히 “응답이 빨리 온다"는 차원을 넘어섭니다. 같은 GPU로 더 많은 사용자를 받을 수 있고, 토큰당 비용이 떨어집니다. 에이전트처럼 모델이 수십 번 호출되는 워크로드에서는 체감이 더 크죠. 한 번 호출에 0.5초 줄이는 게, 50번 도는 에이전트에서는 25초 단축으로 돌아옵니다.

특히 코드 생성처럼 패턴이 반복되는 작업은 MTP의 적중률이 높습니다. 드래프트가 잘 맞을수록 속도 이득이 커지는 구조라서, Claude Code 같은 코딩 에이전트에서 가장 먼저 효과가 드러나는 것도 우연이 아닙니다.

마무리: 모델 크기보다 “속도 아키텍처"가 차별점이 되는 시대

이제 LLM 경쟁의 축은 “얼마나 큰가"에서 “얼마나 빠르게, 얼마나 싸게 굴리는가"로 빠르게 옮겨가고 있습니다. Gemma 4의 MTP 드래프터는 그 방향성을 가장 노골적으로 보여주는 사례입니다.

여러분이라면 같은 품질에 3배 빠른 모델과, 살짝 더 똑똑하지만 느린 모델 중 무엇을 고르시겠습니까? 적어도 에이전트와 실시간 서비스를 만드는 입장에서는 답이 점점 명확해지고 있는 것 같습니다.