MTP 加速推理最佳实践：在亚马逊云科技中国区使用 llama.cpp 部署 Qwen3.6 的实测指南
内容提要
本文在AWS中国区实测llama.cpp部署Qwen3.6模型，对比Graviton4、Intel CPU和A10G GPU的MTP加速效果。GPU上MTP提升83%性能，CPU上反而降低18-40%。最佳实践：GPU用27B Dense+MTP，CPU用35B MoE关闭MTP，后者成本仅为GPU的26%，性能达82%。
延伸解读
MTP 加速并非万能：CPU 上反而拖慢性能
实测数据显示，MTP 在 GPU 上带来 83% 的显著加速，但在 Graviton4 和 Intel CPU 上，尽管 draft 接受率高达 80% 以上，性能反而下降 18% 至 40%。原因在于 CPU 串行验证 draft token 的开销抵消了收益。因此，在 CPU 部署时应关闭 MTP，直接裸跑反而更快。
MoE 架构是 CPU 部署的关键选择
在 CPU 上，35B-A3B MoE 模型（激活参数约 3B）比 27B Dense 模型快 3.7 至 4.6 倍。这表明 CPU 方案应优先选择 MoE 模型，而非追求更大的 Dense 模型。通过 MoE 架构，可以在低成本 CPU 实例上获得接近大模型的能力，实现性价比最大化。
成本与性能的权衡：CPU 方案性价比突出
以 1 年 RI 定价计算，Graviton4 搭配 35B MoE 的月成本约 756 元，单位 token 成本仅 7.41 元/百万，而 GPU 方案（g5.xlarge + 27B Dense + MTP）月成本约 2852 元，单位成本 22.98 元/百万。CPU 方案以 GPU 26% 的成本实现了 82% 的性能，适合对成本敏感且无 GPU 配额的用户。
Q&A
在AWS中国区使用llama.cpp部署Qwen3.6模型时，MTP加速在GPU和CPU上的效果有何不同？
在GPU（A10G）上，MTP加速效果显著，性能提升83%；但在CPU（Graviton4和Intel）上，MTP反而导致性能下降18%至40%。
在AWS中国区，使用llama.cpp部署Qwen3.6模型的最佳实践是什么？
最佳实践是：GPU场景使用g5.xlarge + Qwen3.6-27B Dense + 开启MTP，性能可达48 tok/s；CPU场景推荐c8g.4xlarge + Qwen3.6-35B-A3B MoE + 关闭MTP，性能为39 tok/s，成本仅为GPU方案的26%。
为什么在CPU上开启MTP反而会降低推理性能？
因为CPU串行执行每个draft token的验证，验证开销较大，抵消了draft acceptance带来的节省，导致性能下降。
在AWS中国区，使用Graviton4和Intel x86 CPU部署Qwen3.6模型时，性能差异如何？
Graviton4比Intel x86快1.86倍到2.34倍，因为LLM推理是内存带宽密集型任务，Graviton4的DDR5-5600和ARM SVE/MMLA指令优化优势明显。
在CPU上部署Qwen3.6模型时，为什么选择MoE模型而不是Dense模型？
因为MoE模型（如35B-A3B）激活参数仅约3B，在CPU上比27B Dense模型快3.7倍到4.6倍，能以更低成本获得接近大模型的能力。
在AWS中国区，使用llama.cpp部署Qwen3.6模型时，CPU方案相比GPU方案的成本和性能如何？
CPU方案（c8g.4xlarge + 35B MoE）性能为39 tok/s，月成本约¥756，单位token成本¥7.41/百万；GPU方案（g5.xlarge + 27B Dense + MTP）性能为48 tok/s，月成本约¥2,852，单位token成本¥22.98/百万。CPU方案成本仅为GPU的26%，性能达到82%。
在llama.cpp中，MTP参数--spec-draft-n-max设置为多少合适？为什么？
设置为2。实测发现该参数大于2时，draft acceptance rate下降明显（低于70%），反而拖慢整体性能，因此选择2作为最优平衡点。
