【360회 측정】 Gemma 4 E4B의 출력 속도가 최대 2.19배로 향상된 이유와 MTP를 시도하는 두 가지 방법

LLM을 빠르게 만들기 위해, 먼저 GPU 교체를 고려하고 있다면 이 360회의 측정을 확인해 보시기 바랍니다.

24GB NVIDIA A10G에서 동일한 Gemma 4를 구동합니다. 변화시키는 것은 다음 토큰을 미리 예측하는 보조 모델(auxiliary model)을 사용할지 여부입니다.

• 예측 후보는 2토큰입니다.
• 비교한 것은 문장 생성, 추론 문제, 도구 호출의 3가지 종류, 총 360개 요청입니다.
• 9가지 전 프롬프트에서 출력 스루풋은 1.91~2.19배에 달합니다.

이것이 Suwesh Prasad Sah가 9월 28일에 공개한 Gemma 4의 MTP(Multi-Token Prediction) 실측 연구입니다. MTP는 Multi-Token Prediction의 약자입니다.

놀라운 점은 그 이유입니다. 대표적인 주요 GPU 커널의 소요 시간은, 일반 생성 시 2.78ms, MTP 사용 시 2.79ms로 큰 차이가 없습니다. 즉, 속도가 빨라진 것이 아닙니다.

논문의 요약에도 이렇게 적혀 있습니다.

The dominant MTP GEMM kernel was not faster than the dominant autoregressive GEMV kernel

한 번의 처리를 빠르게 하지 않아도, 같은 처리를 호출하는 횟수가 줄면 생성 속도는 빨라집니다.

1. 대응되는 Gemma 4를 사용한다면, 일반 생성과 MTP를 동일한 입력으로 비교해 보세요.

이 연구에서는 동일한 양자화된 타겟(target)에 보조 모델을 추가하여, 생성 중 스루풋이 약 2배가 되었습니다.

2. 속도가 빨라진 주원인은 주요 커널의 고속화가 아니라, 토큰당 반복 실행 횟수의 감소입니다.

프로파일링한 3가지 조합에서 선택된 반복 CUDA Graph의 실행 횟수가 출력 토큰당 56.4~78.1% 감소했습니다.

3. 360회의 측정은, 360종류의 문제이거나 동시 360개 요청을 의미하지 않습니다.

9가지 고정 프롬프트를 각 방식별로 20회씩, 동시 실행 수 1로 측정한 결과이므로, 실제 혼잡 상황에서의 성능은 별도로 측정해야 합니다.

후보를 미리 준비하고 무거운 검증 처리를 한 번에 통과시키는 구조를 나타낸 AI 생성 일러스트. 실험 장비나 성능 비율을 그린 것은 아닙니다.

정보 확인일은 2026년 10월 8일입니다. 성능 수치는 Sah가 9월 28일에 공개한 기술 보고서에서 인용 및 재집계된 값이며, 심사 전 자료입니다. 본 기사에서는 GPU 추론을 다시 실행하지 않았습니다. 실행한 것은 게재값의 산술 검토였으며, 후반부 추론 코드는 미실행입니다. 조작 예시와 방식 비교에는 Google과 vLLM의 공식 문서를 사용했습니다. Gemma 4 자체의 신제품 출시를 알리는 기사는 아닙니다.

먼저, 실험 조건과 결과를 확정합니다. 타겟(target)은 답변을 결정하는 본체이고, drafter는 후보를 제안하는 보조 모델입니다.

부록의 측정 프로토콜에서는 prefix caching을 활성화하면서, 입력 맨 앞에 고유 ID를 넣는 controlled-cold 조건을 사용했습니다. 대응하는 AR과 MTP에는 같은 ID가 포함된 입력을 전달했으며, 캐시가 데워진 조건의 비교는 나중으로 미뤘습니다.

첫 번째 출력까지 걸리는 시간은 TTFO(Time To First Output)입니다. 연구에서는 추론 내용, 답변 본문, 도구 호출 조각 중 어느 것이 도착한 시점을 기준으로 삼아, 메타데이터만 있는 이벤트는 제외했습니다.

즉, '약 2배'라는 것은 처음 한 글자가 나올 때까지의 대기 시간을 절반으로 줄였다는 의미가 아닙니다. 크게 바뀐 것은 그 이후의 생성 과정입니다.

여기까지는 출력 속도에 대한 이야기였습니다. 흥미로운 점은 그 다음입니다.

일반적인 자기회귀 생성(AR)에서는 확정된 문장을 사용하여 다음 1토큰을 결정합니다. MTP에서는 가벼운 drafter가 먼저 후보를 만들고, 타겟이 여러 위치를 모아서 검증합니다.

Google의 메커니즘 설명에 따르면, Gemma 4의 drafter는 타겟의 활성값이나 KV 캐시도 이용합니다. 단순히 작은 범용 모델을 옆에 두기만 한 구성과는 다릅니다.

후보가 2개일 경우, 첫 번째 후보에서 벗어나면 뒤의 후보도 모두 버린다. 왜냐하면 뒤의 후보는 '처음이 맞았다는 세계'를 전제로 만들어졌기 때문이다. 양쪽 모두 통과한다면, 타겟이 결정하는 추가적인 1개를 더해서 최대 3개까지 진행한다.

다음은 greedy 생성(greedy generation)을 설명하는 의사 코드/미실행이다. 확률적 샘플링에서는 별도로 수용 확률과 기각 시의 분포 보정이 필요하다.

후보 = drafter가 2개의 토큰을 제안 (확정된 열)
판단 = target이 후보 열의 각 위치를 종합적으로 계산
처음부터 일치하는 후보만 채택
...

빠른 보조 모델에 답변을 전적으로 맡긴 것이 아니다. 채택을 결정하는 것은 target이다.

연구 요약에는 다음과 같이 적혀 있다.

greater token progress reduced repeated GPU execution

GEMV는 행렬과 벡터, GEMM은 행렬 간의 곱셈이다. 여러 위치를 다루는 MTP에서는 주요 처리가 GEMV 중심에서 GEMM 중심으로 바뀌었다. 이것만으로 '텐서 코어(Tensor Core)가 작동해서 전부 빨라졌다'고 결론 내리고 싶어진다.

정말 그럴까?

Table 4, 5, 10을 비교해 보면 다른 설명이 나온다.

| 동일 트레이스의 반복 Graph 실행 횟수/출력 토큰 | 0.654 | 0.143 | MTP 쪽은 약 78.1% 적다 |

위의 두 줄은 추론 문제에서 선택한 대표 커널이며, 아래 두 줄은 도구 호출의 프로파일링이고, 측정 단위가 같지 않다. CUDA Graph 역시 알고리즘상의 검증 1회와 일대일 관계는 아니다.

19.4%는 12.399 / 10.383 - 1,
78.1%는 1 - 0.143 / 0.654
에서 본 기사에서 재계산한 수치이다. 게재된 값이 반올림되었기 때문에 결과도 대략적인 것이다.

MTP에서는 후보 생성, 샘플링, 후보 선택, 상태 업데이트라는 작업이 늘어난다. 그럼에도 불구하고 출력 1개의 토큰을 얻는 데까지 무거운 처리를 반복하는 횟수가 줄어든다면, 전체적으로 이득이다.

이 관계만을 추상화하면 볼 수 있는 양은 다음과 같다.

$$
ext{생성 효율} = rac{ ext{확정된 출력 토큰 수}}{ ext{후보 생성과 검증을 포함한 경과 시간}}
$$

분자만 보면 수용률 자랑이 된다. 분모의 일부만 보면 커널 자랑이 된다. 사용자가 기다리는 것은 이 둘을 합친 결과이다.

당신의 환경에서는 후보를 늘렸을 때 먼저 악화되는 것이 수용률인가, 검증 시간인가. 당신의 예상도 댓글로 알려주었으면 한다.

이 측정은 1모델 대・1GPU・동시 실행수 1에서의 실행 메커니즘을 설명하는 증거일 뿐이며, 다른 하드웨어나 고부하 시까지 같은 배율을 보장하지는 않는다.

'출력만 짧아진 것 아닌가?'라는 의심도 해소해 두자.

Table 1의 용도별 중앙값을 다시 읽고 배율을 계산한 것이 다음 표이다. 각 방식・각 용도는 60 요청이다.

| 용도 | AR → MTP 출력 속도 (tokens/s) | 본 기사에서 계산한 속도 비율 | AR → MTP 전체 시간 | 출력 길이 중앙값 |
|---|---|---|---|
| 문장 생성 | 97.46 → 192.80 | 1.98배 | 5.107 → 2.676초 | 491 → 499.5 |
| 추론 문제 | 96.61 → 204.70 | 2.12배 | 8.374 → 4.074초 | 802 → 811 |
| 도구 호출 | 97.26 → 204.98 | 2.11배 | 3.369 → 1.631초 | 321 → 321 |

이 표는 '용도별 중앙값 간의 비율'이며, 제목의 2.19배는 '동일 프롬프트 20회 중앙값 간의 비율'의 최대값이다. 집계 단위를 섞지 말 것.

특히 도구 호출은 출력 길이 중앙값이 두 방식 모두 321 토큰으로 일치한다. 연구에서는 세 가지 프롬프트 각각에서도 중앙값이 일치하고 있어, 단순히 짧은 답변으로 바뀐 것만으로는 설명하기 어렵다.

한편, 문장 생성의 일부에서는 출력 길이가 변했다. 따라서 전체 시간만 보고 '생성 능력이 2배'라고 읽는 것은 부주의하다.

다음 계산은 이미 실행된 것입니다. 재계산한 것은 논문에 게재된 값이며, 새로운 추론 벤치마크가 아닙니다.

rows = [("plain", 97.46, 192.80), ("reasoning", 96.61, 204.70), ...]

plain: 1.98x
reasoning: 2.12x
tool: 2.11x
...```

먼저 구조에 대해 설명하자면, Google의 공식 튜토리얼이 짧습니다. 아래는 E4B를 선택하고 비추론 모드와 최대 2개의 후보를 명시한 예입니다. 공식 예시의 `torch_dtype`은 해당 페이지의 사용 중단 경고에 따라 `dtype`으로 변경했습니다.

**미실행. CUDA 환경과, 비양자화 타겟 + 보조 모델이 수용 가능한 메모리를 전제로 합니다.** 논문의 4비트 구성과는 다르기 때문에, 24GB에서의 동작이나 동일한 속도 비율을 보여주는 코드는 아닙니다.

pip install torch accelerate transformers

import torch
from transformers import AutoProcessor, AutoModelForCausalLM
target_id = "google/gemma-4-E4B-it"
...

MTP를 활성화하는 핵심은 `assistant_model=assistant`입니다. 이 예는 출력 확인용이며, 시간 측정은 하지 않았습니다. 속도를 측정할 단계에서는 워밍업을 분리하고 GPU 동기화와 생성 토큰 수를 기록해야 합니다.

배포 측에서 시도하려면, vLLM의 Gemma 4용 MTP 설정을 사용합니다. 다음은 공식 시작 형식과 논문의 모델 쌍 및 주요 배포 조건에 맞춘 예입니다.

**미실행. Gemma 4 MTP 지원 vLLM 환경이 필요합니다.** 논문에서 사용된 버전은 0.24.0입니다. 아래는 시작 확인용이며, 논문의 독자적인 채팅 템플릿이나 360회의 측정 절차까지 재현하는 것은 아닙니다.

vllm serve google/gemma-4-E4B-it-qat-w4a16-ct
--host 127.0.0.1
--tensor-parallel-size 1
...

AR과 비교할 때는, 동일한 시작 명령어에서 `--speculative-config`만 제외한 서버를 다른 측정 회에 사용해야 합니다. 두 가지를 같은 GPU에 동시에 실행하여 비교해서는 안 됩니다.

입력, 출력 상한, 샘플링, 캐시 조건을 맞추고, AR과 MTP로 동일한 요청을 보냅니다. 기록할 것은 **첫 번째 출력 시간, 종료 시간, 출력 토큰 수, 출력의 타당성**입니다. 이 연구의 출력 속도는 `(출력 토큰 수 - 1) / (종료 시간 - 첫 번째 출력 시간)`으로 계산되었습니다.

vLLM 공식 주의사항에 따르면, Gemma 4 assistant는 전용 MTP 경로를 통과합니다. `model` 항목에 별도의 체크포인트를 전달하는 것처럼 보여도, 범용 드래프트 모델 취급이 아닙니다.

```json
{"method": "mtp", "model": "google/gemma-4-E4B-it-assistant"}

오래된 버전에서 SpeculativeConfig(method='draft_model', ...)으로 표시된 경우, Gemma 4의 지원 경로가 포함되어 있지 않아 초기화에 실패할 가능성이 있습니다.

대책: method를 mtp로 하고, Gemma 4 MTP 지원 버전으로 시작 로그를 확인해야 합니다.

Table 3의 도구 호출에서, 평균 수용 길이의 로그 창별 중앙값은 2.595입니다. 이는 타겟 유래의 1 토큰을 포함하며, 2 후보 설정에서는 1~3 범위에 속합니다.

하지만, 동일 용도의 프롬프트별 속도 비율 중앙값은 2.11배입니다. 후보를 만들고 선택하는 비용이 무료가 아니기 때문입니다. 게다가 수용 길이는 약 10초 간격의 집계 창에서 얻은 값이라, 각 요청의 속도와 직접적으로 대응되지 않습니다.

대책: 수용률을 판정 기준으로 삼지 말고, 출력 속도와 전체 시간을 동시에 측정해야 합니다.

출력 검증 내역은 AR이 177/180건, MTP가 172/180건입니다. 남은 11건은 추론 문제의 지정 답변과 불일치한 6건과, 길이 상한에 도달한 5건입니다.

연구는 이 11건을 버리지 않고 속도 집계에 포함하고 있습니다. 반면, 올바르게 완료된 출력만으로 한정해도 추론 문제의 약 2배 단축은 남아있었습니다.

이 적은 결과만으로 MTP의 품질 저하를 단정할 수는 없습니다. '투기적 생성은 이론상 lossless'와 '구현에서 항상 같은 문자열이 나온다'는 별개의 문제입니다. vLLM은 수치 정밀도나 배치 조건에 따른 차이를 명시하고 있습니다.

대책: 속도와 함께 정답, JSON 스키마, 종료 이유를 저장해야 한다. 실패한 시도를 성공 사례로 대체해서는 안 된다.

이 연구의 측정 절차는 일반적으로 벤치마크와 Nsight/PyTorch Profiler 실행을 분리하고 있다. 프로파일링은 각 용도 및 방식당 1개의 요청이며, 360건 전체 내부를 관찰한 것은 아니다.

커널 시간 합계, GPU 주석 구간, CUDA Graph 시작 간격, HTTP 응답 시간 등은 각각 다른 값이다. 서로 다른 시계를 더하면 존재하지 않는 내역을 만들게 된다.

대책: 속도에 대한 주장은 프로파일러가 없는 측정으로 하고, 이유 설명은 별도로 수집한 트레이스로 진행해야 한다.

보조 모델(補助モデル)을 두면 어떤 LLM이라도 같은 결과를 얻을 수 있을까. 여기는 방식을 나누어 선택해야 한다.

2026년 10월 8일에 확인된 vLLM의 방식 목록, MTP, EAGLE, N-gram, Draft Models를 바탕으로 도입 조건을 정리했다. 속도 순위가 아니다.

표에서 읽을 수 있는 것:

• Gemma 4 전용 어시스턴트를 사용할 수 있다면, 먼저 MTP를 AR과 비교할 이유가 있다.
• 추가 모델을 넣고 싶지 않다면, N-gram이 비교 후보가 된다. 다만, 일치 후보가 적은 입력에서 같은 효과를 기대할 근거는 없다.
• 대응 모델의 유무와 실측 결과는 별개다. 연구의 2.19배를 표의 다른 방식으로 옮겨서는 안 된다.

추가 모델이 없는 대조 실험에는 공식 N-gram 설정을 사용할 수 있다. 아래는 타겟을 이번 모델로 바꾼 미실행 비교 예시이다.

vllm serve google/gemma-4-E4B-it-qat-w4a16-ct \
--host 127.0.0.1 \
--max-model-len 8192 \
...

같은 2개의 후보라도, 후보를 만드는 비용도, 맞는 입력도 다르다. 그래서 비교할 의미가 있다.

✗

Draft Models / vLLM

EAGLE Draft Models / vLLM

**GPU를 늘리기 전 비교에 쓸 수 있다면, 좋아요와 저장 부탁드려요. LLM 배포를 담당하는 동료들에게도 이 '한 번의 속도'와 '호출 횟수' 차이를 공유해 주세요.**

댓글로 알려주세요.

**가장 먼저 시도할 것은 전용 MTP(Multi-Turn Prompting)인가요, 아니면 추가 모델이 필요 없는 N-gram 방식인가요?****사용 목적에 따라 어려운 점은 첫 출력까지의 대기 시간인가요, 아니면 생성 중의 느림인가요?****후보를 2개에서 늘리면 빨라질까요? 아니면 검증 비용이 먼저 문제일까요?