AI Agent推理机制解析：工作原理与基准测试

当AI从简单的问答机器人演变为能自主规划、调用工具、反复迭代的智能体，底层的计算负载和性能评估逻辑也随之被彻底改写。

从问答到执行：Agentic推理的本质差异

传统推理像一场简单的接球游戏——一个prompt输入，一个答案输出。但Agent完全不同：它会推理、规划、调用工具、运行代码，然后解读结果并反复迭代，直到任务完成。这种自主性带来了全新的计算负载和性能挑战。

从trace层面看，普通聊天机器人的调用轨迹像节拍器一样规律：用户说话，模型回答，循环往复。而Agentic trace则是混乱的——模型调用、工具调用、工具响应、更多推理、再触发新的工具调用。这条链可以很长、有状态、且不可预测。

更关键的是规模差异。据OpenRouter在百万亿级token的真实使用数据中发现，单个Agent请求消耗的时间大约是普通聊天请求的15倍。

Agent推理过程示意

Trace（调用轨迹） 是理解Agent推理负载的关键概念。一次trace指从用户发起请求到任务完成的完整调用链路记录，包含每一次模型推理、工具调用、工具返回结果以及中间产生的推理步骤。在传统聊天场景中，trace的结构高度规律：一次模型前向传播即完成一轮交互，链路短且无状态。而在Agent场景中，trace呈树状或图状展开——主Agent可能依次调用搜索工具、代码执行沙箱、文件读取接口，每次工具返回后还要重新进入模型推理，并根据结果决定是否发起下一轮调用。这种trace的长度可能达到数十甚至上百步，且每一步都携带并累积历史上下文，使KV cache持续占用显存，直接决定了服务的显存容量规划、批处理策略与调度复杂度。

多Agent协作：上下文膨胀的挑战

现代Agent并不单独工作。主Agent充当编排者，携带对话历史、计划和已学到的信息。当遇到子任务——比如搜索代码库、运行测试、检查文档——它会启动独立的子Agent来完成，然后汇报结果。

在一个真实的编码会话案例中，主Agent的上下文从约6万token一路增长到40万token，因为每一轮新交互都在向前携带历史。

用可视化来理解：标准聊天推理像是在二维平面上不断延伸的面积，而Agentic AI则是增加了一个全新维度——我们面对的不再是面积，而是体积。

MoE（混合专家，Mixture of Experts） 是当前超大参数模型的主流架构。其核心思想是将单个稠密前馈网络拆分为多个“专家”子网络，每次前向传播时通过路由机制只激活其中少数专家，从而在总参数量达到数万亿的同时保持每次计算的激活参数量可控。在Agent场景下，MoE的优势尤为明显：由于Agent的输入上下文极长、输出多样，模型需要广泛的知识覆盖，而MoE可以在不显著增加单次推理FLOPs的前提下扩展容量。但代价是显存占用巨大——全部专家权重都必须常驻或高效换入，这对GPU互联带宽和显存池化提出了极高要求。这也是文章中NVLink将72块GPU连成统一scale-up域、以及Dynamo分离pre-fill与decode的重要原因：只有系统级协同才能让数万亿参数MoE模型在Agent负载下保持高吞吐与低延迟。

Agentic基准测试：为什么传统方法失效

传统基准测试相对简单：发送8000 token输入，要求1000 token输出，报告每秒token数（TPS）。这对于理解干净的单轮交互很有用，但对Agent工作负载几乎毫无参考价值。

Agentic基准测试采用完全不同的方法：

重放真实生产trace：回放真实的编码Agent轨迹，捕获新数据并报告TPS
保留增长上下文：维持可变输入长度、可变输出，以及原始工具调用间隙。这些间隙很重要——Agent可能在等待，但其上下文仍占用KV cache
统一流量：每个系统接收完全相同的录制流量，差异只来自硬件和服务栈，而非特调的benchmark prompt

KV cache（键值缓存） 是大模型推理中的核心优化机制。在自回归生成过程中，每一层注意力都需要用到此前所有token的Key和Value向量；若每生成一个新token都重新计算全部历史，计算量将随序列长度平方增长。KV cache的做法是把已计算的Key和Value缓存下来，后续token只需计算当前步并与缓存拼接，从而将每步复杂度降为线性。其代价是显存占用随上下文长度线性增长，且每个并发请求都要维护独立缓存。在Agent负载中，上下文从6万膨胀到40万token，意味着一路会话的KV cache可能占用数十GB显存；同时工具调用间隙期间请求虽在等待，缓存却不能释放，进一步压低了有效批处理规模。因此Agentic推理的显存管理、缓存复用与调度策略，远比传统单轮问答复杂。

真正重要的指标：吞吐、交互性与并发

对AI工厂而言，核心数字是每兆瓦吞吐量——固定功耗预算下能产出多少有用的Agent工作。

但效率本身可能掩盖糟糕的用户体验。需要将其与交互性交叉评估：每个用户实际看到的TPS、端到端延迟、首token时间。同时还要纳入并发维度——增加更多Agent时，每个都会变慢；但服务太少，机器又处于低利用率状态。

最优系统不是单纯吞吐数字最大的那个，而是在满足Agent所需响应性的前提下，每兆瓦吞吐量最高的那个。

系统级协同设计：性能提升的真正来源

性能增益并非来自单一芯片的某种技巧，而是全系统协同设计的结果：

NVLink将72块GPU连接为一个高带宽scale-up域，让数万亿参数的MoE模型像一台协调的机器运行
Dynamo将pre-fill与decode分离，独立扩展每个池，实现上下文复用而非重算
TensorRT-LLM加入NVFP4精度和宽专家并行，在数千Agent同时运行时保持Tensor core繁忙

每一层消除不同的瓶颈，但最终效果只有在整个系统协同工作时才会显现。

性能数据：从GB300到Vera Rubin

在Agentic工作负载中，GB300-NVL72实现了高达15倍的吞吐量提升，转化为每百万token成本降低最多10倍。

Vera Rubin再次推动曲线。在DeepSeek^广告 V4 Pro工作负载上，以每用户160 token/秒的交互目标，Vera Rubin-NVL72的每兆瓦AI工厂吞吐量比GB300-NVL72高出最多30倍。

差距在更大模型上更加明显。在2.8万亿参数的KimiK3上，GB300-NVL72的每兆瓦吞吐量约为H200的80倍，同时将交互性推至约215 token/秒/用户——这已超出上一代系统所能达到的范围。

关键结论不是简单的柱状图高低对比，而是新系统扩展了性能曲线的可用区间——让超大模型也能保持交互性。

Agent即工作负载：系统级问题需要系统级解答

Agent已经成为主流工作负载，且将持续存在。但服务好它们是一个系统级问题——需要从芯片互联、推理调度到精度优化的全栈协同。单纯堆砌算力或优化单点，都无法应对Agentic推理带来的状态性、不可预测性和规模膨胀挑战。