大模型推理的瓶颈从来不是算力不够，而是逐令牌串行生成这一固有约束——每吐出一个 token 都要等上一轮前向传播完成。Gemma 4 引入的多令牌预测（Multi-Token Prediction, MTP）起草器，配合投机解码（speculative decoding），把这条串行链路变成了并行流水线：起草器一口气猜出多个 token，主模型一次前向传播全部验证，合格则批量接受，不合格则回退到第一个出错的位置。结果是推理速度提升约 3 倍，输出质量不变。
投机解码的工作原理
传统自回归解码每步只生成 1 个 token，计算利用率极低——GPU 大部分时间在等内存搬运，而不是在做数学运算。投机解码的核心思路是：
- 起草：用一个更小、更快的模型（或主模型自身的 MTP 头）并行预测接下来的 k 个 token。
- 验证：主模型对这 k 个候选 token 做一次前向传播，同时得到每个位置的概率分布。
- 接受或拒绝：逐个比对候选 token 与主模型概率，匹配则接受，遇到第一个不匹配则拒绝并回退，同时用主模型在该位置的采样结果修正。
关键洞察：验证步骤的成本和正常生成 1 个 token 几乎一样，因为前向传播本身就要跑一遍。如果 k 个候选全部命中，相当于 1 次前向传播产出了 k 个 token——吞吐量直接乘 k。
MTP 起草器：不用额外小模型
经典投机解码需要单独训练一个 draft model（比如用 7B 模型给 70B 模型当起草器）。MTP 的做法更优雅：在主模型上附加多个预测头，每个头负责预测当前位置之后的第 n 个 token（n = 1, 2, …, k）。这些头共享主模型的表征，训练时联合优化，推理时直接复用主模型的一次前向传播结果来生成候选序列。
这样做的好处：
- 零额外模型加载成本：不需要下载、部署、管理一个独立的 draft model。
- 候选分布与主模型更对齐：共享表征意味着起草器的"语感"和主模型天然接近，接受率更高。
- 内存占用更可控：MTP 头只是几层轻量线性层，参数量远小于一个完整小模型。
Gemma 4 的 MTP 起草器正是沿这条路线实现，实测在多种任务上接受率表现稳定，才得以把理论加速比压到接近 3 倍。
实际加速效果从哪来
3 倍加速不是魔法数字，它取决于两个核心参数：
| 参数 | 含义 | 对加速的影响 |
|---|---|---|
| k（候选长度） | 起草器每次预测多少个后续 token | k 越大，理论上限越高，但接受率会递减 |
| 接受率 α | 每个候选 token 被主模型验证通过的概率 | α 高时实际加速比趋近 k；α 低时回退频繁，加速打折 |
粗略估算公式：期望每步产出令牌数 ≈ 1 + α + α² + … + α^(k-1) = (1 - α^k) / (1 - α)。当 α = 0.8、k = 5 时，期望产出约 3.5 个 token/步，即 3.5 倍加速。Gemma 4 官方给出的约 3 倍数据，说明其 MTP 起草器在典型场景下维持了较高的接受率。
需要注意：3 倍是吞吐量（tokens/second）的提升，不是延迟（首 token 时间）的改善。首 token 响应时间基本不变，但后续流式输出的速度显著加快——这对长文本生成场景（文档摘要、代码补全、多轮对话）最有价值。
用 vLLM 跑 Gemma 4 投机解码
下面给出一个可直接运行的部署示例，使用 vLLM 的 speculative decoding 功能配合 Gemma 4 的 MTP 起草器。前提条件：
- GPU：至少 1 张 A100（80GB）或等效显卡
- CUDA 12.1+
- Python 3.10+
# 安装 vLLM（建议用最新稳定版，MTP 支持在 v0.6+ 引入）
pip install vllm>=0.6.0
# 启动 OpenAI 兼容 API 服务，启用投机解码
# --speculative-config 指定 MTP 起草器参数
# num_speculative_tokens 即候选长度 k
# model 为 Gemma 4 主模型
python -m vllm.entrypoints.openai.api_server \
--model google/gemma-4-27b-it \
--speculative-config \
'{"model":"google/gemma-4-27b-it-mtp-draft",
"num_speculative_tokens":5,
"speculative_max_model_len":2048}' \
--gpu-memory-utilization 0.9 \
--port 8000
启动后用 Python 调用：
from openai import OpenAI
client = OpenAI(base_url="http://localhost:8000/v1", api_key="empty")
# 长文本生成——最能体现投机解码优势的场景
response = client.chat.completions.create(
model="google/gemma-4-27b-it",
messages=[
{"role": "user", "content": "用 500 字总结量子计算对密码学的影响，包括具体算法和迁移时间线。"}
],
max_tokens=600,
temperature=0.7,
stream=True,
)
token_count = 0
for chunk in response:
if chunk.choices[0].delta.content:
token_count += 1
print(chunk.choices[0].delta.content, end="", flush=True)
print(f"\n--- 共输出约 {token_count} 个 token ---")
如果想对比速度，关掉投机解码再跑一次：
# 不带 --speculative-config 启动，即纯自回归模式
python -m vllm.entrypoints.openai.api_server \
--model google/gemma-4-27b-it \
--gpu-memory-utilization 0.9 \
--port 8001
同一请求分别打到 8000 和 8001，计时对比 tokens/second，差异应该明显。
什么时候该用，什么时候不该用
适合的场景：
- 长文本生成（>200 tokens），吞吐量收益最显著
- 对流式输出速度敏感的对话式应用
- GPU 内存带宽是瓶颈而非算力瓶颈的部署环境（大多数消费级和数据中心 GPU 都是这种情况）
需要谨慎的场景：
- 极短输出（<30 tokens），投机解码的起草开销可能抵消收益
- 高温度采样（temperature > 1.0），主模型分布变平坦，起草器对齐度下降，接受率降低
- 对首 token 延迟极其敏感的实时系统——投机解码不改善首 token 时间
部署检查清单：
- 确认 vLLM 版本支持 Gemma 4 的 MTP draft model 名称
- GPU 内存需同时容纳主模型 + MTP 头（额外开销通常 <5%）
- 先用纯自回归模式跑基准，再开投机解码对比，避免"感觉快了但没数据"
- 监控接受率指标（vLLM 日志中会输出
spec_accept_rate），低于 0.6 时考虑减小 k 或检查 prompt 质量 - 对延迟敏感的业务，单独测量首 token 时间和平均每 token 时间，两者优化方向不同
投机解码不是万能加速器，但在 Gemma 4 的 MTP 实现里，它做到了一件难得的事：不换硬件、不降质量、不加额外模型，只靠更聪明的解码调度就把吞吐量推到近 3 倍。对于已经在跑 Gemma 4 的团队，这是一个值得当天就试的配置变更。