NVIDIA用AgentX重算AI工厂效率

NVIDIA在8月24日给AI基础设施讨论加了一个新的计量入口：同样是推理，agent负载不再适合只看固定输入、固定输出、单次请求的吞吐。它发布的Vera Rubin NVL72数据称，在SemiAnalysis AgentX负载上，Vera Rubin NVL72相对NVIDIA GB300 NVL72可达到最高30倍每兆瓦吞吐，并带来最高35倍更低每百万tokens成本。

这不是一个已经完成第三方审查的公开榜单。NVIDIA自己的原文把它称为early results，并明确写着currently pending SemiAnalysis review；同时，这批结果还don’t yet reflect Vera CPU performance for tool calling。也就是说，它能说明NVIDIA想把AI工厂的主指标从“每秒能吐多少token”推向“每兆瓦能完成多少agent工作”，但还不能被当成全行业已验证的最终性能曲线。

这条新闻的价值在于口径变化。NVIDIA引用OpenRouter数据称，agentic AI workloads consume 15x more tokens than a simple chat request；技术博客又把AgentX描述为会回放真实coding agent会话的benchmark，保留长上下文prefill、KV-cache reuse、tool-call gaps和动态并发。这些词背后的意思很直接：agent请求的成本不只来自模型本身，还来自多轮推理、工具等待、上下文反复进入和缓存命中失败。

对读者来说，采购关注点正在从单张图的峰值转向AI工厂里的“有效产出”。如果企业未来采购的是持续运行的coding agent、research agent或客服agent，约束条件会从GPU小时数转成电力、缓存、路由、并发体验和每百万tokens边际成本的组合。

这次新增的事实

NVIDIA的普通博客和技术博客在同一天发布，内容相互配套。前者面向AI工厂经营口径，强调Vera Rubin NVL72在agent workload下的每瓦工作量和token成本；后者更具体地解释AgentX如何测量，为什么旧的固定8K输入、1K输出场景不足以代表生产里的agent流量。

几个数字需要拆开读。30倍指Vera Rubin NVL72相对GB300 NVL72，在AgentX负载上的最高每兆瓦吞吐差距；35倍指每百万tokens成本口径，不等于云API价格已经调整；15倍是NVIDIA引用OpenRouter对agent请求和普通聊天请求token消耗的比较；40%来自DSX MaxLPS同一兆瓦预算可配置更多GPU的功耗管理表述。所有这些数字都带有“up to”或厂商测量边界。

状态词同样重要。NVIDIA写的是Vera Rubin early results currently pending SemiAnalysis review，并且don’t yet reflect Vera CPU performance for tool calling。中文稿只能写成“仍待审查”和“尚未计入Vera CPU工具调用性能”，不能写成SemiAnalysis已经确认，也不能把当前GPU和机架级结果扩展为完整agent端到端性能。

指标	数值	适用范围
Vera Rubin每兆瓦吞吐	最高30倍	相对GB300 NVL72，AgentX负载，NVIDIA早期测量
Vera Rubin token成本	最高低35倍	相对GB300 NVL72，每百万tokens成本口径
Agent请求token消耗	15倍	NVIDIA转引OpenRouter对普通聊天请求的比较
DSX MaxLPS配置密度	最多多40%	同一兆瓦预算下的GPU配置能力表述

Technical Blog对AgentX的解释补了关键背景：AgentX是SemiAnalysis InferenceX套件里的agentic-coding benchmark，目标是评估AI基础设施如何服务真实coding agent产生的请求模式。它把预录的Claude Code会话逐轮回放，保留每一轮的上下文、输入输出长度、推理时间和工具调用延迟，而不是只运行一批互不相关的短prompt。

这使得AgentX对硬件和软件栈提出了不同问题。传统benchmark经常把输入长度、输出长度和并发设为较稳定的参数，例如技术博客提到的DeepSeek-R1-0528静态8K输入、1K输出场景。Agent会话则会在任务推进中累积上下文，已经处理过的token可能需要复用，也可能因为路由不当而被重复计算；模型调用之间还会被工具执行或子agent任务打断。NVIDIA在这组文章里要证明的是，机架级scale-up域、KV缓存、prefill与decode拆分、MoE expert并行和功耗调度一起作用时，agent会话的有效吞吐会显著改写。

AgentX改变了硬件叙事的单位

过去两年，推理性能讨论常以tokens per second、batch size、TTFT和固定序列长度成本展开。Agent工作流把这些指标变得不够独立：一个agent可能先读代码库，再调用shell，再把工具输出塞回上下文，随后继续推理；一条用户请求背后可能有几十次模型调用。若只测单次请求，系统可以在理想批处理下跑得很快，却无法解释缓存膨胀、工具等待和多用户会话交错时的效率损失。

Technical Blog给AgentX列了四个用户体验相关指标：E2E normalized interactivity、standard interactivity、E2E latency和TTFT。前两个看用户可感知的输出速度，后两个看请求从提交到首token、末token的等待。把这些指标放到“每兆瓦”分母下，NVIDIA实际在谈一个AI工厂经营问题：功耗被限制时，多少电能被转成了可交付的agent工作，而不是被长上下文重算、跨GPU通信等待或低命中缓存消耗掉。

Vera Rubin NVL72被放在这个叙事的前端。NVIDIA称，在AgentX DeepSeek V4 Pro模型上，Vera Rubin NVL72把相对GB300 NVL72的曲线推高到最高30倍每兆瓦吞吐。同一篇技术博客还写到，GB300 NVL72本身已经在DeepSeek V4 Pro 1.6T的AgentX负载上，相对H200 NVL8达到最高15倍AI-factory throughput per megawatt，并在Kimi K3 2.8T上呈现更大的代际优势。普通博客则用Hopper architecture概括这一代际比较。

这套表述里有两个层次。第一层是Blackwell到Hopper的代际收益，NVIDIA用GB300 NVL72说明NVL72 scale-up域和联合软件栈已经适合长上下文、MoE和高并发agent流量。第二层是Vera Rubin到GB300的预览收益，NVIDIA希望说明下一代平台进一步放大相同方向。两层都来自NVIDIA材料，且Vera Rubin数字仍在等待SemiAnalysis review；因此把它写成“已被独立benchmark证明的30倍提升”会过界。

关键不确定性

这次数据最重要的限制来自NVIDIA自己。普通博客说，Vera Rubin的early results measured using the SemiAnalysis AgentX workload and currently pending SemiAnalysis review。这意味着SemiAnalysis作为AgentX benchmark背后的机构还没有完成审查，外部读者目前看到的是NVIDIA测量结果，不是第三方最终发布结果。

第二个限制是Vera CPU未纳入当前工具调用表现。Technical Blog在展望段落里说，broader Vera Rubin platform会让Rubin GPUs处理大上下文和decode，让Vera CPUs处理tool execution和KV-cache offload。普通博客同时声明当前结果don’t yet reflect Vera CPU performance for tool calling。agent系统的端到端体验往往被工具执行、I/O、上下文整理和调度间隔拖慢；如果CPU侧还未计入，那么当前图表更接近GPU和机架级推理路径的预览，而不是完整agent产品运行报告。

第三个限制是“每百万tokens成本”不是通用价格。NVIDIA把最高35倍更低成本和AI factory revenue、profit margin联系起来，这是基础设施经营模型里的单位经济学。实际云端价格还会受采购周期、折旧、利用率、机房电价、网络和软件栈授权影响。对企业买方而言，它更像一个方向信号：如果agent负载持续拉长上下文并扩大token消耗，那么机架级能效会进入采购讨论；它不是明天所有agent API自动降价的承诺。

软件栈为什么和硬件一起被写进公告

NVIDIA没有只说新GPU。两篇文章反复出现的是“codesign”：硬件互连、Tensor Cores、Transformer Engine、低精度格式、推理runtime、serving框架和功耗管理一起被拿来解释AgentX结果。

在agent场景里，prefill和decode分工特别关键。长上下文输入会让prefill阶段更重，而多轮交互和持续输出又让decode阶段拉长。Dynamo这类serving stack把prefill和decode拆成可独立扩缩的worker pool，再用session-aware serving和KV-cache-aware routing把相关调用导向已有缓存的节点，目标是减少重复计算。NVIDIA还列出SGLang、TensorRT-LLM、vLLM、DeepGEMM、MXFP4、MXFP8、Wide Expert Parallelism、DeepEP和speculative decoding等组件，说明这套结果依赖MoE、KV缓存和通信重叠构成的机架级优化，不能简化为单个芯片峰值。

NVL72 scale-up域在这里承担基础结构角色。NVIDIA背景页把GB200 NVL72描述为面向可扩展LLM推理和数据中心需求的机架级系统，Blackwell架构页则把AI factory作为核心场景；当天博客进一步强调NVLink和NVLink Switch在scale-up域里给多GPU通信提供高带宽、低延迟连接。普通博客还给出一个具体说法：第六代NVLink互连和NVLink Switches相对现成以太网替代方案有10倍更高packet rate和3倍更低latency。这些背景不能替代当天发布，但能解释为什么NVIDIA把“每兆瓦”作为AI工厂指标，而不是只谈单卡算力。

DSX MaxLPS是另一个经营口径组件。NVIDIA称这项技术在GPU、rack和workload层面管理功耗，使同一兆瓦预算内最多可以配置40%更多GPU。这个数字不应和30倍吞吐混为一谈：前者是功耗预算和配置密度，后者是AgentX负载下相对GB300 NVL72的每兆瓦吞吐。二者共同指向同一个约束，也就是当电力成为AI工厂的硬边界时，调度和功耗管理会和模型服务性能一起决定收入上限。

对开发者和企业买方的含义

开发者层面，这组公告说明coding agent的性能瓶颈会更频繁地落在系统工程上。一个模型在短prompt上速度足够快，并不代表它在百万token级任务历史、频繁工具调用和多agent协作下仍然经济。服务团队需要关注上下文复用率、工具调用间隔、prefill队列、decode吞吐、KV-cache命中和路由策略。AgentX把这些因素打包成可比较轨迹，至少让“agent workload和普通chat不同”这件事有了更清楚的工程语言。

企业买方层面，NVIDIA的表述会推动采购问题从“买哪代GPU”转向“在固定电力和机房预算内，能支持多少可交互agent并发”。如果Agent请求确实消耗普通聊天15倍tokens，那么相同业务量会放大token成本、缓存占用和延迟波动。高并发客服、代码迁移、投研和合规审查场景都可能更关心每兆瓦有效工作，而不是峰值token吞吐。

模型和云厂商层面，AgentX可能让不同模型的系统友好度更显性。MoE模型、长上下文模型和工具调用密集型模型对cache、专家并行和通信拓扑的要求并不相同。NVIDIA把Kimi K3、MiniMax M3、GLM5.3、Qwen3.5和DeepSeek V4 Pro列入Blackwell平台的agentic models范围，说明它想把开源和闭源之外的变量拉到“AI factory workload portfolio”上。未来模型发布若只给静态benchmark分数，可能越来越难回答部署成本问题。

接下来最该看什么

SemiAnalysis复核。若后续公开结果保留相同量级，并给出测试配置、并发曲线、模型版本、功耗计量和交互指标，Vera Rubin NVL72的AgentX数据才更适合被行业横向引用。若复核后口径收窄，今天的30倍和35倍就应被重新标注为厂商预览峰值。

Vera CPU端到端测试。工具调用并不是小插曲，它会影响agent等待、状态同步、文件和网络I/O、KV-cache offload路径。NVIDIA已经说当前结果未反映Vera CPU工具调用性能；后续如果这部分被纳入，同一个agent任务的瓶颈可能从GPU吞吐转向CPU、存储、网络或调度。

云厂商指标迁移。每兆瓦吞吐、每百万tokens成本、E2E normalized interactivity和TTFT如果进入报价和SLA，agent服务的竞争会更接近数据中心运营，而不是单纯模型榜单。采购方也会要求看到与自身任务相近的会话轨迹，而不是只接受固定长度推理测试。

AgentX覆盖范围。当前叙述重心是coding agent会话，但agent负载还包括客服、投研、数据分析、浏览器操作、科学计算和企业流程自动化。不同任务的上下文增长速度、工具调用密度、输出长度和缓存复用率差异很大。只有当benchmark覆盖更多真实轨迹，AI工厂的每兆瓦指标才会从厂商展示变成工程决策工具。