AMD 公開 Kimi-K3 三引擎測試，重現須核對負載與映像版本

AMD 於 9 月 22 日刊出 Kimi-K3 在 vLLM、SGLang 與 ATOM 上的測試流程，整理八張 MI350X 的單機推論配置、容器版本與量測方法。文中數據採集於 7 月 29 日，屬當時軟體堆疊的紀錄；本次新聞點是方法與限制的公開說明。[AMD 技術文章](https://rocm.blogs.amd.com/artificial-intelligence/kimi-k3-mad/README.html)

流程以 MAD 的模型清單串接容器建置、啟動腳本及設定檔，再由 madengine 執行並產出共通格式的結果。madengine 儲存建置清單，也允許分開建置與執行，方便同一映像在不同節點重用。對工程團隊而言，這種結構有助把效能回歸追溯到配置及版本差異。[madengine 儲存庫](https://github.com/ROCm/madengine)

Kimi-K3 的整合透過新增模型項目、專用容器與各引擎腳本完成，採八路張量平行。儲存庫說明權重檔約占 1.56 TB，重驗前須預留模型快取空間；設定針對 MI350X／MI355X 所屬架構，但文章實測硬體只有 MI350X。[整合紀錄](https://github.com/ROCm/MAD/pull/186)、[指定提交文件](https://github.com/ROCm/MAD/blob/a20c885/benchmark/kimi_k3/README.md)

AMD 表示，本次負載為輸入 8,192、輸出 1,024 個 token，測量不同並行請求數，並關閉前綴快取。然而指定提交的 README 仍將 vLLM 範例列為輸入、輸出各 1,024，其他引擎列出的並行範圍也不同。這至少顯示文件尚未對齊，執行前應核對實際展開的命令，不能只複製入口指令便假定負載相同。[文章方法](https://rocm.blogs.amd.com/artificial-intelligence/kimi-k3-mad/README.html)、[README 範例](https://github.com/ROCm/MAD/blob/a20c885/benchmark/kimi_k3/README.md)

文章另記錄容器標籤在建置期間已指向不同雜湊，因此重現需固定映像摘要。每個測量點只執行一次，沒有暖機或變異估計；引擎的記憶體預算與 KV 快取精度亦未統一，測試未評估答案品質。[量測限制](https://rocm.blogs.amd.com/artificial-intelligence/kimi-k3-mad/README.html)

工程上，共通報表能降低整理成本，卻不會自動統一計時起訖、提示長度抽樣或停止條件。若把流程接入持續整合，應保存原始輸出與伺服器參數，以分辨程式退步和測試條件漂移。選擇正式服務引擎前，仍需補做重複測量，再以實際提示長度、延遲需求及品質檢查驗證；總 token 吞吐量也須與僅計生成 token 的速度分開解讀。