2026 年 9 月 16 日，MLCommons 發佈了 MLPerf 推理 v6.1 結果，新增了端到端檢索增強生成及邊緣代理推理測試。[1] 對私有 AI 買家而言，有用的發展是更廣泛的測量單位：關於工作流程的證據能回答短暫模型回應測試無法解答的問題。我們建議利用這些結果來塑造試點，然後另行測量實際部署。
本文反映截至 9 月 26 日可用的資料，並未報告 Software Tailor 的基準測試提交，亦不聲稱任何 AI Server 部署 會重現已發佈的結果。
在比較分數前先了解工作負載
本次發佈描述了涵蓋檢索與生成的 RAG 工作，以及具有重複回合和增長歷史的邊緣代理工作負載。[1] 這些對買家而言是有用的區分。文件助理與編碼工作流程可能都會調用語言模型，但其周邊工作值得分別調查。
從考慮中的業務操作開始比較。說明輸入、預期輸出及操作完成的時點。文件答案可能只有在其引用段落可開啟時才算完成。代理任務可能需要經過驗證的工具結果，答案才可用。這些是建議的接受界限，非 MLPerf 強加的額外要求。
將基準測試的界限置於該描述旁。標示結果涵蓋的每個階段及建議應用所屬的每個階段。明顯的差距很有用：它指出試點必須測量的工作。將差距隱藏於單一總分中，則失去進行比較的意義。
將語料準備與回答問題分開
MLCommons 8 月對 RAG 基準的介紹區分了建立向量資料庫的攝取管線與在其上運作的問答管線。後者可跨多跳重複檢索與推理。[2] 這使準備工作與回答工作並列可見。
對評估自身文件集合的組織，我們建議的試點有兩個記錄。一個描述準備定義集合以供使用，另一個描述針對該集合回答固定問題集。兩者均保留文件版本與準備設定，以便答案可追溯至相同起點。
然後加入受控的文件更新。觀察變更何時可供問答路徑使用，以及用戶在過渡期間看到的情況。將此視為具有自身結果的應用測試。外部基準的攝取結果不代表對不同文件庫的更新承諾。
當採購要求單一回應時間承諾時，此區分尤其有用。團隊可指定承諾是從已準備好的集合開始，還是包含使新文件可搜尋。 容量規劃文章 將該區別發展為商業決策。
將代理序列視為一個序列
一個快速的初步答案是不完整的應用接受標準，該應用將反覆檢查證據並調用工具。我們建議的評估保持完整任務的可見性。記錄連續的請求、允許的操作和最終結果，然後檢查應用在哪裡等待或需要介入。
在添加開放式工作之前，使用具有已知結果的任務。一個小型的虛構庫存足以確定代理是否請求了預期的項目，是否收到正確結果，並將其帶入下一次回應。 AI Server 整合程序 使用該範例將連接檢查與工具執行分開。
有意識地添加較長的輸入和後續回合。在報告中保持這些案例的命名，而非混入未解釋的平均值中。如果測試提前結束，記錄停止原因及未完成的部分。當評估者能區分已完成任務與偶然快速到達的部分答案時，結果更易於解讀。
保持比較條件的附加
MLCommons 區分封閉和開放部門，以及系統可用性類別。其結果頁面亦連結變更日誌，因為已發佈結果可能隨後被修改或失效。[3] 因此，採購記錄應保存所查閱的精確結果及檢查日期。
我們建議的候選清單表格包括基準版本、工作負載、場景、系統配置及報告指標。添加部門和可用性類別。如果兩個候選結果在這些欄位有所不同，請在排名前描述差異。這是解讀證據的紀律，而非聲稱不同系統永不可比較。
保持一欄獨立記錄預期安裝。應描述組織預期使用的模型、部署拓撲及應用工作負載。若已發佈配置無法在建議預算或運行環境內重現，請明確標示。結果仍可用於調查，但不應默默成為接受目標。
將基準轉化為試點簡報
實際產出是一個有界實驗。選擇一個可檢查正確性的任務，定義工作負載階段並說明時間界限。詢問候選供應商已發佈證據涵蓋提議路徑的哪些部分。將剩餘問題分配給具名接受標準的本地試點。
對 Software Tailor 而言，有用的 部署討論 從該簡報和預期數據邊界開始。帶來可依組織規則共享的代表性輸入，或行使相同工作流程的虛構等效品。保持業務接受、安全檢查及測量性能為獨立發現。
基準應讓買家對所提議安裝產生更好的問題。最終採購決策需要該安裝的答案。
參考資料
[1] MLCommons。 MLPerf 推理 v6.1 結果公告. 發佈日期 2026-09-16。存取日期 2026-09-26。
[2] MLCommons。 介紹 MLPerf 端對端 RAG 推理基準測試. 發佈日期 2026-08-26。存取日期 2026-09-26。
[3] MLCommons。 MLPerf 推理：數據中心. 當前結果及方法概述。存取日期 2026-09-26。
相關文章
- 連接代理至 AI Server
- 於業務截止日期前購買私有 AI 容量
- 每個已接受任務的私有 AI 成本
