推論系統
AMD 公開 MLPerf 推論最佳化，八卡 GPT-OSS 服務吞吐量提升約 38%
AMD 透過分拆注意力核心與調整排程，提高 MI355X 上的 GPT-OSS-120B 基準吞吐量。公開權重與操作指南提供重現起點，但環境設定及模型卡仍有待釐清之處。
AMD 於 9 月 17 日公開 MLPerf Inference 6.1 的工程解析，說明如何在同樣八張 MI355X 上改善 GPT-OSS-120B 推論。公司報告，Server 吞吐量由上一輪每秒約 8.21 萬 token 增至 11.32 萬，提升約 38%；這是特定基準下的整套系統結果。[技術解析](https://rocm.blogs.amd.com/artificial-intelligence/mlperf-inf-v6.1/README.html)
核心改動之一，是將原本共用的注意力核心拆成 prefill 與 decode 兩條路徑。前者處理成段輸入，偏向運算密集；後者逐步讀取分頁 KV 快取，更受記憶體頻寬限制。AMD 以 AITER 的可變長度注意力處理 prefill，另用 Gluon 撰寫 decode 核心，透過資料布局與載入重疊減少等待，宣稱注意力部分改善 25% 至 28%。[核心設計](https://rocm.blogs.amd.com/artificial-intelligence/mlperf-inf-v6.1/README.html)
排程器同時納入首 token 三秒、後續每 token 八十毫秒的服務目標，讓請求安排配合延遲限制。技術上的意義是，核心算得快之外，還要控制進入系統的工作量；局部核心改善與整體吞吐量使用不同分母，不能直接相加。[排程說明](https://rocm.blogs.amd.com/artificial-intelligence/mlperf-inf-v6.1/README.html)
量化配置也需要固定。重現指南連到 AMD 的公開權重，模型卡的量化腳本採用 MXFP4 權重、FP8 活化，並排除注意力、路由器及輸出層等部分。模型卡概覽對活化精度另有不同描述，因此重現者應比對實際模型設定、腳本及容器版本，不能只看模型名稱推定執行精度。[模型卡與腳本](https://huggingface.co/amd/gpt-oss-120b-w-mxfp4-a-fp8-Mlperf)
模型卡的品質數字使用低推理強度評估 AIME25 與 GPQA，不能直接代表更高推理預算或中文工作負載。依賴長篇程式生成、工具呼叫或中文問答的團隊，仍須另外確認量化後的錯誤型態與輸出品質，才能將基準成果用於容量規畫。[評測條件](https://huggingface.co/amd/gpt-oss-120b-w-mxfp4-a-fp8-Mlperf)
AMD 已列出容器與效能、品質測試命令，但指南仍留下 ROCm 版本占位符，多節點的互連規格與啟動器也未填妥。這表示已有可操作的起點，尚不能把公開文件視為完整、無歧義的重現配方。[重現指南](https://rocm.blogs.amd.com/artificial-intelligence/mlperf-inf_v6.1-repro/README.html)
MLCommons 的 Closed 組要求使用相同參考模型，仍容許在規則內最佳化；吞吐量也不能替代整機功耗量測。對部署者而言，下一步應在固定品質門檻下重跑自身輸入長度、併發與尾延遲，再判斷這些改動是否降低每次請求成本。[MLCommons 規則說明](https://mlcommons.org/benchmarks/inference-datacenter/)