CPU 基准测试将智能体工具执行与模型推理解耦
Tom's Hardware 概述了其首个面向智能体 AI 的 CPU 基准测试：在发布经验证的处理器排名前，先将主机端工作负载与模型推理解耦。Tom's Hardware CPU 基准测试聚焦于一个具体问题：当 AI 智能体争夺本地资源时，处理器能够处理多少工作？这种方法清晰地区分了衡量硬件容量与预测实际用户等待时间这两件事。
AI 智能体是一种软件，它使用模型来选择行动、执行工具并评估结果。这些行动产生的工作不止于生成文本。模型决定下一步操作时，处理器可能需要运行测试、搜索文档或协调任务。
核心矛盾在于受控测量与真实执行之间。MLCommons 已在其个人电脑基准测试 MLPerf Client 中纳入智能体工作负载，测量范围覆盖模型执行和工具操作。隔离主机端能够提供另一种视角，但买家在将智能体基准测试作为购买依据前，仍需同时参考两种视角。
Tom's Hardware CPU 基准测试究竟引入了什么
在 10 月 29 日的一篇专题文章中，分析师 Jake Roach 介绍了一种原型方案：记录模型交互，再在工具本地执行时重放响应。该媒体表示其设计已确定，但结果仍需审查。因此，其 智能体 CPU 基准测试 引入的是一种测试方法，而非已尘埃落定的处理器排行榜。
真正重要的变化，是在考察计算机执行周边工作时，使模型行为保持稳定的方法。
推理，即生成模型响应的计算过程，会为硬件测试引入另一种变化来源。即使运行条件看似相同，智能体也可能在不同轮次中选择不同的行动。如果其决策和执行速度同时变化，就更难识别原因。
记录下来的响应为工作负载提供了一条固定路径。在这种安排下，更短的完成时间可以对应更一致的行动序列来解读。这使实验更易于审视，但也缩窄了结果所代表的范围。
以一个示例性的编程任务为例。智能体搜索项目、打开源文件、应用修改并运行测试。下一次尝试时，实时模型可能选择另一种搜索方式，或要求进行额外测试。比较这两次尝试，便会将硬件差异与所执行工作本身的差异混在一起。
受控序列能够减少这种模糊性。实验可以考察不同系统执行可比工作时的效率，而不是比较其智能体是否恰好选择了同样高效的方法。只要目标是比较硬件，这一区别就很重要。
这也限定了标题结论的范围。移除实时决策意味着，该测量无法证明模型在某款处理器上推理得更好。更短的重放时间同样不能证明生产环境中的智能体一定会更快完成任务。
这则消息值得关注，因为它明确了测量边界。智能体性能并非完全归属于模型、处理器或应用程序的单一属性。每一层都作出贡献，也都需要与其角色相匹配的证据。
因此，有价值的解读应当具体且有限。这一原型探索的是受控智能体工作负载下的主机端容量。该容量能否预测更好的应用性能，仍是一个独立问题，需要与实时执行进行比较。
无论结果最终以何种形式出现，这一边界都应保持清晰。否则，经过严格限制的实验可能会演变成过度宽泛的营销宣传。
硬件买家需要的不只是更快的模型
直接承受压力的是硬件供应商和买家：他们需要将 AI 性能主张与具体工作负载联系起来。
计算机在回答问题时与执行软件修复时，所做的工作并不相同。后者可能涉及本地程序、文件和验证。仅评估模型，会使这些依赖关系游离于测量之外。
对开发者而言，实际问题在于执行发生在哪里。远程托管的模型仍可指挥本地机器完成工作。如果测试在本地运行，提升远程服务并不一定会缩短测试阶段。
反过来也同样重要。如果本地工作只占任务时长的一小部分，购买更快的处理器或许几乎不会改变使用体验。有价值的基准测试必须揭示这种可能性，而不是假定每种智能体工作流都需要更高的主机端性能。
这为处理器供应商带来了不同的举证负担。关于适合智能体的笼统主张，应说明哪些工作会得到改善、在何种条件下改善，以及会带来什么应用收益。单独的容量测量无法回答所有问题。
计算机制造商面临相关问题。他们必须决定为目标用户提供多少处理器性能、内存和其他资源。当基准测试有助于区分这些需求，而不是为同一配置再贴一个标签时，它才有价值。
对企业买家而言，并发工作带来了另一个维度。并发意味着多个任务在重叠时段内保持活跃。一个系统单独处理任务时表现轻松，但当同事或后台作业争夺资源时，行为可能截然不同。
吞吐量，即单位时间内完成的工作量，反映了这种差异的一部分。延迟，即单个任务所需的时间，反映了另一部分。一台机器可以提供更多总工作量，同时让特定用户等待更久。
一个示例性的共享开发主机可以清晰说明这种区别。多个智能体可能分别运行测试套件，同时开发者发起交互式搜索。最大化完成的测试数量，并不一定能保持搜索体验的响应速度。
这就是为什么智能体 AI 吞吐量需要明确服务要求。若不定义可接受的等待时间，最高完成率可能会奖励一种让用户感觉负载过重的配置。
知识工作流同样提出了时间耗费在哪里的问题。构建 可搜索知识库 的团队，应在将延迟归因于硬件之前，区分文档处理、检索和答案生成。
这些示例描述的是采购问题，而非该原型的实测发现。它们的价值在于说明未来结果必须解释什么。买家需要能够将受控分数与他们实际执行的工作联系起来的证据。
因此，重点并不在于立即宣布哪款处理器获胜，而在于要求更清楚地说明智能体性能主张究竟承诺了什么。
移除推理使主机端更易测量
该原型的并发扫描会增加活跃工作线程数，并报告完成的会话数。它将峰值吞吐量与受较慢会话限制的运行点区分开来。在冻结重放期间，记录的模型响应无需经历 GPU 推理延迟便会到达，使主机端在没有这种节奏控制的情况下承接工作。
移除推理提高了隔离程度，但也改变了工作抵达处理器的方式。
这种权衡直接源于设计本身。当模型花时间生成响应时，主机端可能有机会完成其他工作。立即返回响应会改变下一步行动何时就绪。
由此产生的工作负载可以揭示较慢的实时模型永远不会提出的容量需求。这并不使测量失去意义，而是使它成为对特定工作供给条件下性能的测量。
可以将其类比为测试一间厨房，而员工已提前拿到订单。该测试能够揭示厨房可以产出多少食物，却不能独立证明在点餐和配送引入额外延迟时，顾客能多快收到餐点。
对于智能体软件而言，缺失的节奏控制很重要，因为行动依赖于先前的结果。测试必须先完成，其输出才能为下一项决策提供信息。文档必须先处理，智能体才能使用其内容。
固定这些决策有助于比较，但时间假设仍需解读。买家应询问，基准测试是否接近其预期负载，还是有意施压测试超出该负载的边界。
操作系统也提供了另一个理由，说明不能只看完成数量。Linux 记录了 资源压力 测量指标，用于跟踪与受限处理器、内存及输入输出资源相关的停滞。其文档将资源争用与延迟尖峰和吞吐量损失联系起来。
这些测量可提供有用的诊断背景。如果智能体工作负载变慢，辅助证据可以帮助区分是处理器时间竞争，还是在等待内存或存储。单一的标题分数无法作出这种区分。
这是一项分析建议，并非声称该原型已报告所有诊断指标。更广泛的要点是，主机端容量仍是一项系统属性。处理器与内存、存储、软件库和操作系统策略共同运行。
因此，公平的硬件比较需要配置透明度。否则，读者无法判断看似存在的处理器优势是否依赖于其他组件或软件设置。
同样的谨慎也适用于基于处理器规格的解释。更多核心意味着并行工作的潜力更大，但规格本身并不能证明某一特定工作负载如何扩展。测量必须弥合这一差距。
Tom's Hardware CPU 基准测试最适合作为审视这一问题的受控视角。它可以支持有关主机端极限的问题，同时将实时应用时序留给互补实验。
这种划分让评测者拥有更精确的表达方式。他们可以将执行容量与模型造成的延迟分开讨论，而不是将两者压缩为一个未加区分的 AI 分数。
MLPerf 与智能体基准测试回答的是不同问题
重要的比较在于测量目标，而不是争论哪项基准测试应取代其他测试。
MLCommons 表示，MLPerf Client 的智能体测试涵盖软件工程和数据分析。其文档报告总任务时长，包括模型推理和工具执行，并对这两个阶段进行拆分。
这种方法衡量的是完整配置系统的使用体验。受控的主机端重放则回答一个更狭窄的组件问题。这些方法在主题上有所重叠，但其分数不应被视为可以互换。
系统测试可以显示某种配置更早完成，但未必能完整解释原因。组件测试可以厘清某一项优势来源，却无法确立最终应用收益。两者结合使用，能让硬件评测更具参考价值。
MLCommons 还区分基础、扩展和实验性组件。这些标签很重要，因为某项功能的存在并不会自动赋予每种配置或结果同等地位。读者应查看特定工作负载所附的状态。
Agent 能力基准引入了另一条维度。SWE-bench 通过应用生成的补丁并运行代码仓库测试，来评估软件改动。其补丁评估文档介绍了旨在支持一致性评估的容器化执行方式。
因此，SWE-bench 提供了一个有益的对照：完成一段执行流程，不等于解决一个软件问题。快速的系统仍需给出有效结果，而能力出色的 Agent 仍需要一个可执行其工作的环境。
对开发自动化感兴趣的买家，不应以一种指标替代另一种。能力与执行性能相互作用，但任何一方都不能代表两者。
可靠性又带来了另一项区分。最初的工具交互基准 tau-bench，用于评估 Agent 使用领域工具并遵循策略要求时的表现。其作者将最终数据库状态与预期结果进行比较，并考察重复试验之间的一致性。
这项研究提供的是方法论上的提醒，而非对该原型的直接批评。Agent 服务必须反复执行正确的操作。重放一条固定路径，无法独立证明在线模型会可靠地选择该路径。
这些方法构成了一组有益的互补问题。Agent 能否解决任务？能否稳定地做到？配置后的系统执行工作有多快，又是哪一组件构成限制？
任何一种方法都不需要否定其他方法。错误在于把它们的答案压缩成一种普遍论断，即某台机器在 Agent 任务上就是更快。
对评测者而言，机会在于解释不同测量结果之间的分歧。一台机器可能有闲置的主机容量，却仍受其他环节限制。另一台机器可能很快完成受控工作负载，但面对不同的任务组合几乎没有优势。
只要测量边界保持清晰，这些都是可解释的结果。只有当不同测试被表述得仿佛在衡量同一件事时，它们才会令人困惑。
受控重放仍需接受现实检验
Tom's Hardware 的 CPU 基准测试仍处于原型阶段，其受控条件值得仔细审视。该媒体也承认其在更广泛的平台覆盖、对话式工作负载和框架方面存在局限。
可重复执行对于硬件比较是必要条件，但仅有可重复性，并不能证明某项工作负载代表生产环境使用。
最值得质疑的问题在于所选路径。记录好的序列为每个系统提供了可比较的工作，但其相关性取决于该序列在多大程度上反映目标应用。再高的一致性，也无法弥补工作负载本身不合适的问题。
一个示例性的文档任务就能说明这一问题。从干净文档中提取文本，与处理需要光学字符识别的扫描件并不相同；后者是将图像中的文字转换为机器可读字符。偏重其中任一情形的基准，都可能呈现不同的主机资源需求图景。
同样的原则也适用于软件任务。搜索一个小型项目与构建一个更大的代码库，对机器提出的要求不同。笼统的 Agent 标签并不会让这些要求变得等同。
因此，读者在解读总体分数前应先查看任务构成。综合结果需要提供足够细节，说明其构成因素。否则，工作负载组合就会成为一种隐形的购买假设。
正确性同样需要得到重视。如果在线工具产生意外结果，基准必须区分有效执行与虽快但无效的执行。在不作说明的情况下排除无效运行，也可能掩盖实际问题。
一份有价值的报告应在成功测量结果之外，同时披露未成功的运行。它应解释故障是源于任务行为、配置、资源限制，还是测试系统本身。这些背景决定了剩余分数是否代表正常运行。
重复测量还需要明确的初始状态。先前工作遗留的文件和其他数据，可能改变后续运行必须完成的工作。基准应说明其衡量的是全新执行、重复执行，还是特定组合。
这些是评估要求，并非证明该原型未能妥善处理它们。其目的是明确读者在使用已发布数据选择硬件前应提出的要求。
“CPU 基准测试”这一说法还有另一层限制。工具执行可能依赖存储和其他系统资源。如果这些依赖因素会影响分数，读者就需要获得足够信息，避免把所有差异都归因于处理器。
同样，相对响应性阈值也需要语境。一套系统可以保持其自身基线行为，同时在绝对时间上仍比另一套系统耗时更长。基线表现与负载下表现都很重要。
这正是谨慎报道应有价值的地方。来源中没有经过验证的排名表明，某个特定处理器家族在各类 Agent 工作负载中胜出。可以站得住脚的结论，关乎所提出的方法以及仍需补充的证据。
当重放的范围、有效性及其与在线工作负载的关系可见时，它才会成为购买依据。在此之前，它最有价值的贡献，是让一个困难的测量问题变得更具体。
关注复现、在线对比与更广泛的工作负载
下一个里程碑应是能够将受控主机测量与可被独立理解的应用行为联系起来的证据。
未来几个月，第一个值得关注的信号，是可复现的工作负载包，或达到同等程度的方法披露。读者需要任务定义、软件版本、配置细节、有效性规则，以及分数计算方式的清晰说明。
这是一项观察标准，而非已公布的发布计划。如果另一团队能在等效条件下复现这种行为，对该测量的信心就会增强。如果结果依赖未披露的选择，其实用性仍然有限。
复现还应意味着理解结果的形态。独立运行在不同硬件条件下不必得出完全相同的数字，但应提供足够证据来解释一致、差异或失败。
第二个信号，是冻结重放与在线推理之间的直接比较。这将显示，当模型重新承担工作节奏控制角色时，测得的主机容量会在多大程度上影响完成时间。
如果重放优势延续到可比较的在线工作负载中，就会增强其对该应用的相关性。如果这种优势大多消失，重放对容量分析仍有价值，但对升级决策的支持会更弱。
这些测量之间的差异本身也具有信息价值。它可能表明应用将时间耗在其他地方，或表明时序变化会改变资源争用。无论哪种结果，都比假设组件分数能预测一切更有用。
第三个信号，是任务、框架和系统配置范围的扩大。更有力的证据会展示结论在哪些情况下成立，以及在哪些情况下变化。与其宣称存在通用赢家，不如清晰解释工作负载敏感性，这更具参考价值。
如果相关变化下的排名保持相似，人们对其更广泛适用性的信心就会提高。如果排名发生变化，读者就有理由让硬件选择更贴合他们计划运行的工作。
买家应将这种敏感性视为信息，而非基准测试的失败。Agent 软件覆盖不同活动，而这些活动未必偏好同一台机器。
目前，合理的应对方式是改进附着在性能主张上的问题。问清哪些工作在本地运行、哪些内容保持固定、如何处理无效运行，以及计时是否包含模型。
在将 Tom's Hardware 的 CPU 基准测试视为购买指南之前，先找出限制自己工作流程的阶段。记录时间是花在模型响应、文档处理、搜索、构建还是验证上。然后将未来结果与该工作负载对照，而不是与其 Agent 标签对照。要求同时提供成功完成情况，以及在预期负载下的等待时间。受控重放可以揭示有用的容量，而在线对比则表明这种容量是否真正惠及用户。随着这些测量结果的发展持续关注证据，并围绕系统必须完成的工作做出购买决定。更快的处理器究竟能缩短哪个阶段？
