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 數字更實用，因為它告訴你在你自己的硬體上應該設什麼。
研究者怎麼看這種社群 benchmark
這類實測帖的價值不在那個加速比，在於它告訴你「這條路是通的」。MTP 在 llama.cpp 上能跑、KV 壓縮可以這樣用、262K context 在高 RAM 機器上有人跑過了——這些是有用的訊號。
但如果你要做技術選型，或者跟人說「我們可以在 48GB 機器上跑 262K context」，你需要在自己的硬體、自己的 workload 上重現。Benchmark 是別人家的實驗，不是你家的保證書。
論文的話，這種帖子大概算 anecdotal evidence，還差一個 ablation study 才能放進 related work（嘆）。
作者：十年大博士