Qwen 27B + MTP 跑 262K context：那個 2.5x 先別急著抄

最近 r/LocalLLaMA 有一篇蠻熱的討論，有人在 M2 Max 96GB 上實測 Qwen3.6 27B + MTP，宣稱 28 tok/s、比原本快 2.5 倍。這個數字傳開之後，不少人在問「這個設定能照抄嗎」。

我試著從研究者的角度拆一下。

2.5x 是怎麼來的

MTP（Multi-Token Prediction）的邏輯跟 speculative decoding 有點像——模型預測 token 的同時，順便猜接下來幾個，猜對了就省一輪 forward pass。這個「加速」不是免費的，前提是預測準確率夠高，而且是在語言分佈比較穩定的任務上才穩得住。

實測 28 tok/s 的環境是 M2 Max 96GB，搭配 --spec-type mtp、--cache-type-k/v q4_0、-c 262144。這個環境條件蠻好的：記憶體夠大，不用太激進的量化，KV cache 壓到 q4_0 也不至於掉太多品質。但這三個條件同時達到的人有多少？

KV cache 壓縮這件事值得多說

把 KV cache 從 f16 壓到 q4_0，記憶體需求大概縮一半，代價是每個 attention head 的 key/value 用 4-bit 精度存。短 context 下幾乎感知不到差異。但如果你真的要用 262K context，後段資訊的品質全靠這個壓縮後的 cache 在撐——對話開頭的內容到尾端還能不能被正確召回，原帖沒有系統地測這個。

28 tok/s 的測試可能就跑了幾百個 token。速度和品質能不能在整個 262K 視窗維持，是另一個問題。

Vision + MTP 的 crash 是個紅旗

這個已知 bug 不能輕描淡寫帶過。MTP 的投機機制要對所有 token 類型做一致的預測，但視覺特徵的 token 分佈跟純文字差很多，硬塞進同一個預測框架就容易爆掉。

如果你的應用場景包含圖片輸入，現在就不要碰 MTP，等 llama.cpp 修好再說。不是「可能有問題」，是「已確認會 crash」，這個邊界很清楚。

可重現性的坑

本地推理的 benchmark 有個先天問題：硬體敏感度極高。跑 LLM 的速度很大程度是 memory bandwidth bound，不是純算力。M2 Max 和 M3 Max 的 unified memory bandwidth 就差了不少，同樣 96GB 機器跑出來可以差 20-30%。

量化版本也有差。IQ4_XS 和 Q4_K_M 在 262K 這個 context 長度下，記憶體用量和速度都不一樣。帖子裡有人整理了不同配置的對照（比如 32GB 建議跑 Q4_K_M 並把 context 限在 8K）——說實話，這個對照表比那個 2.5x 數字更實用，因為它告訴你在你自己的硬體上應該設什麼。