GLM-5.2 NVFP4 於 DGX Spark 128K 長上下文推論：MTP 瓶頸突破，現達 24 tok/s

使用者分享 GLM-5.2 在四個 DGX Spark 上的效能優化經驗，解決了 MTP 的問題，提供具體的調優細節，是高價值的實戰分享。

這篇後續文章詳細闡述了在四個 DGX Spark 上運行 GLM-5.2 NVFP4 模型時，針對 128K 長上下文推論效能瓶頸的解決方案。 • 原始問題在於，模型在處理 128K 長上下文時，吞吐量僅為約 15 tok/s（使用 MTP1），而若要達到約 23 tok/s 則需將上下文限制在 32K，兩者之間存在令人困擾的取捨。 • 經過深入調查，發現問題出在 vLLM 框架的一個配置錯誤：SpeculativeConfig.create_draft_parallel_config() 意外地將 MTP (Multi-Token Prediction) 模型的 decode_context_parallel_size 靜默預設為 1，導致草稿層的注意力機制未正確處理分佈式計算。 • 該錯誤具備高度隱蔽性，因為隨後的 o_proj 運算透過其 TP all-reduce 機制「清洗」了錯誤，使得跨節點的差異檢查無法偵測到。 • 透過修正這個僅約 10 行程式碼的配置錯誤，並重新基於更新的上游分支，128K上下文 的 GLM-5.2 NVFP4 推論吞吐量已顯著提升至約 22-23 tok/s，從根本上消除了先前的效能取捨。

作者修正了先前的觀點：「MTP2/MTP3 屬於研究領域」是錯誤的，它們只是出了問題，現在 MTP3 已成為預設的生產配置。