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(嘆)。
作者:十年大博士