量化当然重要，尤其是本地部署和消费级 GPU 场景。但 Google 刚发的 Gemma 4 多 token 预测（Multi-Token Prediction, MTP）让我更确信一件事：下一轮推理加速的主战场，不只是在“把模型压小”，而是在减少大模型被调用的次数。

Google 在官方博客里说，Gemma 4 通过 MTP drafters 在推理阶段最高可以做到 up to 3x faster。这个数字本身很抓眼球，但我更关心它背后的工程含义：如果草稿器能一次猜中多个后续 token，大模型就不必老老实实一个 token 一个 token 地跑完整前向传播。

说白了就是：以前是大模型每吐一个字都要“亲自审批”；现在是小模型先写一小段，大模型批量盖章。

为什么“一个 token 一次前向”这么浪费

自回归 LLM 的默认解码方式很朴素：给定上下文，预测下一个 token；把这个 token 拼回上下文，再预测下一个。这个循环看起来合理，但对硬件很不友好。

每生成一个 token，模型都要访问大量权重。对于 27B、70B 这种规模，瓶颈往往不是矩阵乘法算不动，而是显存带宽和调度开销被小步循环吃掉。你可以把它理解成：GPU 明明适合一次搬一大车货，结果我们让它每次只送一个快递。

这也是为什么我之前写 DFlash + DDTree 投机解码 时，最看重的不是某个 benchmark 数字，而是“平均接受长度”。只要一次验证能接受更多 token，大模型前向次数就会下降，吞吐自然上来。

Gemma 4 的 MTP 走的是同一条大方向，但实现路径更靠近模型训练本身。

传统 speculative decoding 通常需要一个独立的小 draft model。经典论文 Speculative Sampling 的思路就是：小模型先生成候选，大模型并行验证，最后用修正过的采样过程保证输出分布不变。这套方法很漂亮，但工程上有两个麻烦：你要维护两个模型，还要处理 tokenizer、KV cache、调度和显存布局。

MTP 的反直觉之处在于，它不一定非要靠“另一个完整小模型”来猜。Meta 的论文 Better & Faster Large Language Models via Multi-token Prediction 提出，在训练时让模型不只预测下一个 token，而是同时预测未来多个 token。技术上可以看成在共享 trunk 上接多个输出 head，训练目标从“只看一步”扩展到“顺手看几步”。

人话翻译：模型训练时被迫学习“接下来一小段会怎么走”，而不是只盯着下一个词。

Gemma 4 的关键变化：草稿器变成模型能力的一部分

Google 这次讲 Gemma 4 的重点，是把 MTP drafters 用在推理加速上。按照官方描述，Gemma 4 会用多 token 预测草稿器生成候选 token，然后由主模型验证，从而降低延迟、提高吞吐。Gemma 系列本身是 Google 面向开发者开放的轻量模型家族，相关文档可以在 Gemma 官方文档 里看到；如果你更关心本地 C++ 推理，Google 也维护了 gemma.cpp，这是一个专门服务 Gemma 模型的轻量推理引擎。

这里有个细节很重要：MTP 不只是“再外挂一个小模型”。如果训练阶段就把多步预测能力纳入目标函数，草稿器的命中率可能会比临时找一个小模型更稳定。命中率越高，大模型一次验证接受的 token 越多，加速越接近理论上限。

但我不会把它理解成“所有 LLM 推理都要马上换 MTP”。工程上至少有三件事要先问清楚。

第一，你的场景是 latency-bound 还是 throughput-bound。如果是单用户聊天，用户感知最明显的是首 token 延迟和流式输出节奏；MTP 可能让后续 token 更快，但未必显著改善 first token。如果是代码补全、批量生成、离线摘要，MTP 的收益通常更实在，因为这些任务可以吃到连续 token 的批量验证红利。

第二，你的输出是否足够可预测。代码、结构化文本、模板化报告通常更容易被草稿器猜中；开放式创意写作、强采样、多轮工具调用则不一定。草稿命中率一低，验证成本还在，加速就会打折。

第三，推理框架是否真的支持这套调度。很多人看到论文数字就想上线，但真正难的是 runtime：KV cache 怎么复用、draft tokens 怎么批量验证、失败回退怎么处理、batch 内不同请求的接受长度不同怎么办。Google 自家栈可以先做起来，不代表你今天拿 vLLM、llama.cpp 或自研服务就能无缝吃到同样收益。

这也是我对 Gemma 4 MTP 的判断：它是一个值得跟进的推理方向，但不是“替代量化”的银弹。

量化、投机解码、MTP 应该怎么选

如果你在做生产部署，我会按这个顺序考虑。

先做量化，因为它最确定。INT8、INT4、GGUF、AWQ、GPTQ 这些路线解决的是“能不能装下、能不能便宜跑”的问题。我之前在 本地 LLM 推理引擎对比 里也提过，本地推理首先要选对 runtime，否则模型再小也会被后端拖垮。

然后再看 speculative decoding 或 MTP，因为它解决的是“同样一次大模型计算，能不能多吐几个 token”。这类优化对服务端很诱人：吞吐上来，单位 token 成本下降；延迟下降，用户体验也更接近即时反馈。

但别跳过验证。至少要测四个指标：

• 平均接受长度：一次验证平均能保留多少 draft token
• 首 token 延迟：用户是不是更快看到第一个字
• 端到端 tokens/s：包含草稿、验证、回退后的真实吞吐
• 质量一致性：高温采样、代码生成、长上下文下是否偏离原模型

最后一个指标经常被忽略。Speculative Sampling 论文强调可以保持目标模型分布，这是理论上很强的保证；但到了具体工程实现，采样参数、数值精度、batch 调度都可能引入偏差。生产环境里，性能优化只要悄悄改变输出行为，就不是纯优化，而是一次模型行为变更。

我真正看好的是什么

我看好 MTP，不是因为“Gemma 4 快 3 倍”这个宣传数字，而是因为它把推理加速从外部 hack 推向了模型原生能力。

过去两年，LLM 基础设施的很多优化都是补丁式的：量化、PagedAttention、KV cache、FlashAttention、投机解码，各自解决一段瓶颈。MTP 的意义在于，训练目标本身开始为推理效率让路。模型不再只学“下一个 token”，而是学“未来一小段”。这听起来只是训练技巧，实际上会改变 runtime 的设计假设。

不过我也保留一点怀疑：Google 现在给出的还是官方博客级别的结果，真实开源权重、不同硬件、不同任务上的收益需要社区复现。尤其是中文、代码、长上下文和 agent 工具调用场景，接受长度可能差异很大。这里我也不敢拍胸脯说一定有效。

如果你今天要做决策，我的建议很简单：

• 本地/边缘部署：先关注量化和 runtime，MTP 等生态成熟
• 服务端高吞吐生成：尽快把 speculative decoding / MTP 纳入 benchmark
• 代码生成和结构化输出：优先测试，因为草稿命中率可能最高
• Agent 工具调用：谨慎，工具边界会打断连续生成，收益未必稳定

Gemma 4 这次提醒我们，LLM 推理优化不能只盯着“模型变小”。更大的机会可能在于：让大模型少干重复劳动，把它真正用在验证和决策上。

这条路才刚开始。