llama.cpp 提交 CUDA PR：将 MoE 融合扩展至投机解码场景

llama.cpp 项目近期收到一项 CUDA 相关 PR，将原有的 MoE（Mixture of Experts）算子融合能力进一步扩展到投机解码（speculative decoding）流程中。在此之前，MoE 相关的 GLU 融合与 topk-router 融合仅支持单 token 路径，无法在投机解码的 draft 阶段复用；而本次改动尝试让这些融合 kernel 同样适用于多 token 的 draft 场景，从而减少 GPU 上的冗余访存与算子调度开销。

PR 的核心改动

PR 的主体工作是让 MoE 推理路径上的几个关键融合操作不再被「1 token」的限制绑住，主要包括：

• 在 MoE GLU 融合中加入对投机解码 draft token 序列的批处理支持；
• 调整 topk-router 融合 kernel，使其可以处理多 token 输入；
• 将这些改动接入 llama.cpp 的投机解码调度路径。

作者表示尚未做充分测试，但从初步结果看，该改动对 MoE 模型的 MTP（Multi-Token Prediction）加速效果在不同 draft 宽度下均有体现，尤其在 draft 宽度大于 1 时收益更明显。

为什么对推理生态有意义

MoE 架构目前已是多个主流开源大模型的标准配置，包括 DeepSeek、Qwen3、Mixtral、Llama 4 等系列。在推理侧，投机解码是降低生成延迟的常用手段，而 MoE 模型本身又对算子融合较为敏感——若路由、GLU 等步骤无法融合，就需要反复读写中间结果，对显存带宽和吞吐都是负担。

此次 PR 如果合并，理论上可以：

• 提升 llama.cpp 在 GPU 上运行 MoE 模型时的投机解码吞吐；
• 让本地部署 MoE 大模型的用户在长上下文、多并发场景下获得更可观的延迟改善；
• 为后续更大规模 MoE 模型的端侧推理优化打下基础。

当前状态与待观察点

需要注意的是，该 PR 目前仍处于「未充分测试」状态，benchmark 数字尚未在帖中详细披露。Reddit 网友主要基于已有的 llama.cpp CI benchmark 截图进行讨论，效果究竟如何需要等待：

• 在更多 GPU 架构（如 RTX 40 系列、Hopper）上的复现；
• 与现有 non-fused 投机解码路径的直接对比；
• 与主流 MoE 模型（如 DeepSeek-V3、Qwen3-MoE 等）端到端联调的结果。

总体来看，这是一项面向推理栈底层、面向开发者与本地部署玩家的务实优化，距离主线合并前，社区仍需补充更完整的测试用例和性能数据。