❝芯动力AI实测：不只解释概念，也给出同一硬件配置下有/无 MTP 的对照数据，以及功能质量验证的边界。
本地化或者端侧部署大模型，常常问两个问题：量化后能力还剩多少？为什么有些模型生成特别快？
这次芯动力AI以 Gemma 4 12B 为例，把两个问题放在同一套实测里回答。测试硬件为 Intel Core i7-13620H、单张 Intel Arc Pro B60 24GB GPU 和 32GB 内存；模型使用 QAT 版本的 UD-Q4_K_XL GGUF，配合 MTP 草稿模型，通过 llama.cpp 的 SYCL 后端运行。
结果很直观：
短上下文约 52 tok/s；约 10.9K 上下文仍为 37 tok/s；约 30K 上下文时超过 30 tok/s。
这里的 tok/s 是生成阶段的 token 吞吐，不是首 token 延迟或完整请求的端到端耗时。
先给结论：QAT 的核心价值是让低比特模型在可用质量下更适合部署；MTP 才是本次对照中直接提升生成速度的技术。 两者叠加，才让 12B 模型在有限显存中保有较高的实际交互吞吐。
MTP：不是让模型“想得更少”，而是少等几轮
传统大模型是严格的自回归生成：先算出一个 token，再把它放回上下文，才能算下一个。无论 GPU 多快，这条链路都要求一步一步走。
MTP，Multi-Token Prediction，多 Token 预测，使用的是“草稿 + 核验”的投机解码思路。一个较小的草稿模型先预测接下来的几个 token，目标模型再一次性核验这些候选 token；命中的 token 可以一起提交，不匹配的位置则正常修正。
这套机制的关键在于：最终决定权仍在目标模型手中。 草稿模型不是另一个替代回答者，而是为了让目标模型有机会在一次前向计算中确认多个连续 token。
这套硬件配置启用 MTP 的核心参数如下：
-md /models/unsloth/gemma-4-12B-it-qat-GGUF/mtp-gemma-4-12B-it.gguf \
--spec-type draft-mtp \
--spec-draft-n-max 2
这里有一个很容易踩到的坑：只设置 -md 只是加载草稿模型，不代表 MTP 管线已经开启。必须有 --spec-type draft-mtp。本次测试选择每轮最多草拟 2 个 token；草拟数量更高不一定更快，还取决于候选命中率和目标模型的核验成本。
QAT：它不直接“倍速”，但决定了模型能否高效装进设备
QAT 是 Quantization-Aware Training，量化感知训练。简单说，模型在训练或后训练阶段提前感知低比特量化中的舍入和截断误差，并适应这些误差。这样在导出低比特权重后，通常更有机会保留可用能力。
需要准确地区分两件事：
-
QAT 不会改变“一个 token 接一个 token”这一自回归依赖，因此它不是 MTP 这种直接生成加速。 -
QAT 使低比特模型更可用。更小的权重减少显存与内存带宽压力，也让更多模型层能留在 GPU 上，从而为高吞吐推理创造条件。
本次 Gemma 4 12B 的 BF16 原始体量约为 23.8GB；部署使用的 UD-Q4_K_XL 主模型文件为 6.7GB，体积下降约 72%。运行时，主权重、MTP 草稿模型、两路 KV Cache 和计算缓冲合计约占 9.5GB 显存，在单张 B60 24GB GPU 上仍有余量。
因此，QAT 与 MTP 的分工可以概括为：QAT 解决“低比特后能否保持可用、装得下、搬得动”；MTP 解决“生成时能否少走几步”。
实测：长上下文下，MTP 的价值更突出
Gemma 4 使用混合注意力设计。滑动窗口注意力的计算较稳定，而全注意力层随着实际上下文增长，生成每个新 token 的成本会增加。这里要注意，影响速度的是实际已经积累的上下文，不是单纯把 --ctx-size 配得很大。
下图来自同一套硬件、同一模型与同类生成配置的有/无 MTP 对照。灰色是关闭 MTP，橙色是开启 MTP。
|
|
|
|
|
|---|---|---|---|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
这组数据说明，MTP 并不是在所有场景都提供一个固定倍率。上下文变长、目标模型每一步的计算更昂贵时，让一次核验接受多个候选 token 的收益会更明显。约 30K 上下文时，这张 B60 24GB GPU 上的吞吐从约 10 tok/s 提升到 30+ tok/s，已经从“等待感明显”回到可交互的速度范围。
MTP 不能消除全注意力的计算，也不能保证所有语言、提示词和采样设置都有同样加速比；它做的是减少目标模型必须串行等待的轮次。
快了，功能质量有没有明显牺牲？
对实际部署来说，“模型文件变小”和“tok/s 变高”都不是终点。我们还需要看它是否仍然完成日常工作。芯动力AI在上述 B60 24GB GPU 配置下，对 Gemma 4 12B QAT + MTP 做了如下功能验证。
已通过的测试包括：
-
多模态场景描述、OCR、图表分析和代码截图理解。 -
约 9K tokens 的大海捞针测试，4/4 精确提取隐藏告警。 -
16 轮对话后的记忆回忆，4/4 正确回忆初始事实。 -
多文档结构化提取、严格 JSON 输出、工具调用和多步指令。 -
约 30K 上下文下的长文本生成，启用 MTP 后仍保持 30+ tok/s。
这证明了该 QAT + MTP 配置在上述任务中保持了可用的功能质量，速度提升没有以明显的功能失败为代价。但也要明确边界：这些是功能验证，不是 BF16/FP16 或非 QAT 基线的标准精度差分评测。 若要量化“精度保持了多少”，仍需使用固定题集、固定采样设置和基线模型完成单独评测。
让结果成立的，不只有 QAT 和 MTP
这组吞吐不是一个单独参数创造的。以下部署条件共同保证了结果：
--model gemma-4-12B-it-qat-UD-Q4_K_XL.gguf \
--spec-type draft-mtp --spec-draft-n-max 2 \
--parallel 2 --ctx-size 262144 \
--n-gpu-layers 99 \
--batch-size 512 --ubatch-size 512 \
--flash-attn auto \
--cache-type-k q4_0 --cache-type-v q4_0
-
--n-gpu-layers 99：将模型层全部卸载到 GPU，避免 CPU/GPU 间频繁搬运。 -
双槽位与 256K 总上下文：提高服务容量，但实际速度仍由真实上下文长度决定。 -
Q4 KV Cache：降低长会话的显存压力。 -
Flash Attention 与合适的 batch/ubatch：减少注意力计算与批处理上的额外开销。 -
--reasoning off：该基准针对日常直接回答；开启思考模式后，生成 token 数和端到端耗时会显著增加，不应与此处数据混为一谈。
结语：本地推理优化，应该分清每项技术的职责
Gemma 4 12B 的实测，最值得复用的不是“52 tok/s”这个单点数字，而是优化方法：先用可用的低比特模型把权重、KV Cache 和计算缓冲稳定放进设备；再用 MTP 处理自回归解码的串行瓶颈；最后在真实上下文长度和真实任务上验证吞吐与功能表现。
QAT 让本地部署有更现实的质量与成本平衡，MTP 让生成速度在长上下文下仍然可用。对日常对话、RAG 回答、Agent 执行和多模态理解这类持续交互场景，这种组合带来的不是一张漂亮跑分表，而是用户能直接感受到的响应差异。
关注“芯动力AI”，持续分享国产与异构硬件上的大模型部署、推理优化和实际测试结果，关注真实任务中的速度、稳定性与可用性。
参考与数据来源
-
Unsloth Gemma 4 QAT 文档：https://unsloth.ai/docs/zh/mo-xing/gemma-4/qat -
Unsloth MTP 文档：https://unsloth.ai/docs/zh/mo-xing/mtp -
本地部署与测试记录： GEMMA4-12B-QAT-DEPLOYMENT.md