EAGLE3 才是 Kimi-K2.5 在 MI325X 上真正的加速器
我認為 Kimi-K2.5-W4A8 在 AMD MI325X 上變快，主因是 EAGLE3 的 speculative decoding，不是 kernel 微調；真正改變的是解碼幾何，而不是單一算子效率。
Kimi-K2.5-W4A8 在 AMD MI325X 上變快，主因是 EAGLE3 的 speculative decoding，不是 kernel 微調。
我認為，Kimi-K2.5-W4A8 在 AMD MI325X 上的主要加速來源是 EAGLE3，而不是 kernel tweaks。ROCm benchmark 已經把差異講得很清楚：在 8× MI325X、concurrency 40 的條件下，加入 EAGLE3 後，TPOT median 從 42.73 ms 降到 27.79 ms，吞吐從 672.30 tok/s 升到 872.58 tok/s；後面的 kernel patches 只是再補一小段。這代表瓶頸不在「算子還能不能再磨一點」，而在 decode 本身的序列化結構。
第一個論點
訂閱 AI 趨勢週報
每週精選模型發布、工具應用與深度分析，直送信箱。不定期，不騷擾。
不會寄垃圾信，隨時可取消。
先看最核心的事實：自回歸 decode 本來就是一個 token 接一個 token 地走。對 Kimi-K2.5 這類 MoE 模型來說，即使 W4A8 已經把權重與算力路徑壓得很緊，每生成一個 token 仍要付出一次完整 forward、KV cache 存取、路由與 sampling 的成本。這種成本不是靠再調一點 kernel tile 就能消掉的，因為它來自流程本身。
EAGLE3 改的是工作單位，不是單一算子。它讓 draft model 一次提出短鏈，target model 再在一個 pass 裡驗證整段序列。文中的設定是三個 speculative steps、四個 draft tokens，平均接受長度接近上限 3.93 / 4.0。這個數字很關鍵，因為它表示大部分 draft token 都能被接受，verify 的成本被攤平到多個 token 上，decode loop 也從逐 token 執行變成批次驗證。
第二個論點
最有說服力的證據，是 EAGLE3 在還沒加任何額外調整前，就已經帶來明顯提升。8× MI325X、concurrency 40 的 baseline 下，W4A8 without EAGLE3 的 TPOT median 是 42.73 ms、output throughput 是 672.30 tok/s；啟用 EAGLE3 baseline 後，TPOT median 降到 27.79 ms，throughput 升到 872.58 tok/s。這不是邊際改善，而是足以改變服務體感的幅度。
更重要的是，收益集中在使用者真正感受到的 decode 區段。ITL median 從 27.98 ms 降到 11.75 ms，而 TTFT 幾乎沒變，這正符合 speculative decoding 的特性：它不會改變 prefill，但會把輸出階段的等待時間壓下來。換句話說，如果你的痛點是「第一個 token 出來之後還是太慢」，那 EAGLE3 對症下藥；如果你只盯著 prefill，就會誤判這個方案的價值。
反方可能怎麼說
最強的反方論點不是說 EAGLE3 沒用，而是說它太複雜。你需要 draft model、需要額外的 serving 參數、需要調整 draft depth 和 width，還要管理 target 與 draft 的對應關係。對重視穩定與可維護性的團隊來說，單純的 W4A8 decode 路徑更容易部署，也更容易排障。若 draft 品質不好，還可能白白多做計算，反而吃掉收益。
另一個合理批評是可移植性有限。EAGLE3 的 draft 是針對特定 target 訓練的，不是拿來就能套到所有模型上。若你的產品線有很多不同模型，或你無法長期維持 draft-target 配對，這種方法的管理成本確實高於一般 kernel 優化。從平台視角看，這不是一個「到處都能複製」的技巧。
但這些限制並不能推翻結論，因為本文的問題本來就不是「哪個技巧最通用」，而是「Kimi-K2.5 在 MI325X 上的主加速來自哪裡」。數據已經說明，EAGLE3 單獨就能把 TPOT 壓低、把 throughput 拉高，而且沒有可觀 accuracy regression。kernel patches 只再帶來約 1% 到 2% 的 TPOT 改善與 2% 到 3% 的 throughput 增益，這表示它們是錦上添花，不是主因。當 decode 的瓶頸是序列化，改變 decode 幾何才是正解。
你能做什麼
如果你是工程師，先把 EAGLE3 當成第一優先級，確認 draft-target 配對、accept length、concurrency 與實際 throughput，再去做 Stage2 MoE tile、Stage1 scheduler-hint、bf16 round-to-zero 這類小幅優化；如果你是 PM 或創辦人，請把這件事當成一個訊號：模型服務性能常常不是靠「再磨 kernel」贏的，而是靠改變算法的工作單位。當 decode 佔主導時，優先驗證多個 token，而不是只把單 token 路徑磨得更漂亮。