我对 llama.cpp 进行了修补，以提高 20% 的提示处理 TPS。请帮我提交一个 PR。
我在本地使用 llama.cpp 运行 Qwen3.6-35B-A3B 时，注意到在 MTP 下提示处理的吞吐量变得非常低。我被这个问题深深吸引。
最开始的好奇心变成了为期两周的实验探索，最终得到了一个能够在 GPU 上完全恢复 MTP PP 开销的概念验证，超出了我所有的预期。
简而言之：这个概念验证并不是对整个批次的最后一层 MoE FFN（通常是 512-2048 个标记）进行处理，而是仅处理输出行（通常在预填充时为 1 个标记）。结果是，PP TPS 恢复到了与禁用 MTP 时相同的水平，同时保留了 MTP 对 TG TPS 的大部分好处，尽管在某些基准测试中草稿接受率略有下降。
我不会向 llama.cpp 提交 PR，因为这是 AI 生成的代码，这违反了他们的贡献政策，我对此表示支持。如果你了解 C++ 和 llama.cpp 的内部结构，我邀请你与我合作，提交一个更成熟的实现的 PR。
查看原文
I've been running Qwen3.6-35B-A3B locally on llama.cpp and noticed that prompt processing throughput gets too low with MTP. I got nerd-sniped.<p>What started as curiosity turned into a two-week rabbit hole of experiments and ended with a PoC that fully recovers the MTP PP overhead on GPU, above any expectation I had.<p>TL;DR: instead of processing the last layer MoE FFN for the entire ubatch tokens (usually 512-2048 tokens), this PoC processes only the output row (usually 1 token during prefill). The result is PP TPS is back to the same as with MTP disabled, keeping most of MTP's benefits to TG TPS, even with a slight drop in draft acceptance rate in one of the benchs.<p>I'm not opening a PR to llama.cpp because this is AI-generated code, which goes against their contribution policy, which I support. If you know C++ and llama.cpp internals, I invite to work together with me to open a PR with a more mature implementation.