花了两天调优单张 Tesla P40：35B MoE，完整 262k 上下文，短上下文约 60 token/秒，深入到 100k 上下文时约 30 token/秒。未使用低于 Q4 的量化。

这周我有点迷上了折腾我的 P40，想在权重不低于 Q4、KV 缓存不低于 q8 的前提下，把 Ornith 1.5 35B-A3B（qwen3.5 MoE 架构）的速度拉满。为了跑分而降低量化精度，对我来说并没有多大实际用处，所以我想找一个合理、同时依然“够快”的折中点。配置：一张 Tesla P40 24GB，走 PCIe x1（没错，x1），Windows，以及我自己的 llama.cpp 分支。用官方 BF16 制作的 Q4_0，MTP 草稿预测（n=2），完整 262k 上下文，q8_0 KV。真正有效的改动：- 关闭 ECC：多出 1.5 GB 显存，解码速度提升约 9%。- KV 用 q8_0，不用 q4_0。在 Pascal 上，q4 KV 的性能会随着上下文深度增加而大幅下滑（32k 时为 30.6 对 42.2 token/秒）。- 检查你的 MTP 头。这个模型最初上传的版本，以及基于它制作的量化版本，带有未经训练的 MTP 头。`blk.40.nextn.shared_head_norm` 的均值约为 1.02 = 未训练，约为 2.93 = 已训练。草稿接受率从约 45% 提升到了 60–85%。- 在 flash-attention 分块内核的 KQ 部分使用 int8 dp4a。Pascal 没有 Tensor Core，fp16 性能也受到严重限制，但 dp4a 很快。32k 时预填充速度提升 26%，100k 时提升 41%。- MTP 预填充窗口。MTP 头是一个全注意力层，因此在长提示词上会带来约 13% 的预填充开销。让它只读取提示词最后 8k 的内容，就能把这部分性能拿回来（121k 提示词：327 -> 373 token/秒）。输出不变，主模型仍然会验证每一份草稿。没有奏效的尝试：f16 KV（在 llama-bench 中更快，但在实际服务器中启用 MTP 后，速度更慢，能容纳的上下文也更短）、在内核中对 V 进行反量化（-5%）、官方 Q4_K_M（质量评分和我的 Q4_0 相同，但更慢，能容纳的上下文更短）。llama-bench，不启用 MTP，每项跑 2 次：上下文深度 预填充 token/秒 解码 token/秒 0 1104 60.8 8k 880 57.0 32k 552 46.0 64k 366 35.8 100k 265 29.1 190k - 18.8 启用 MTP 的实际服务器：短提示词下为 65–74 token/秒。101k token 的提示词读取速度约为 415 token/秒，生成速度为 35–39 token/秒。我没找到其他人发布 P40 在不同上下文深度下的数据，希望这条曲线能帮到一些人。如果你想在自己的 Pascal 显卡上试试，我很乐意分享这些补丁。