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成本
