智能体推理
智能体推理采用多轮交互模式，具有序列长度变化大、上下文长、工具调用存在延迟、子智能体活动呈突发性等特点。
工作负载
数据中心 / 云
AI 智能体
行业
所有行业
业务目标
创新
概览
什么是智能体推理？
智能体推理是指大语言模型 (LLM) 以不同程度的自主性执行多步骤任务的过程，包括调用外部工具、检索数据，以及在多个推理周期中自我纠正输出。与传统的单次推理不同，智能体推理会让模型根据自身工具调用的输出反复运行，直至实现目标，从而改变会话时长和成本特征。
传统推理很简单：您发送提示词，模型返回文本。智能体推理在此基础上增加了一个循环：
- 观察：模型接收目标和相关上下文，例如可用工具、当前环境状态等。
- 思考：推理下一步应采取什么行动。
- 行动：调用工具或采取行动。
- 更新：将行动的结果以新的上下文形式反馈。
- 重复：这个过程持续执行，直到目标实现或模型判断任务已完成。
智能体推理的工作负载特征与 AI 聊天机器人、智能助手、内容生成或翻译应用有本质区别。智能体 AI 和长期运行的自主智能体 —— 例如使用 Hermes Agents、LangChain Deep Agents 或 OpenClaw 等工具构建的智能体 —— 在推理时生成的 Token 数量可达 15 倍，因此要求 AI 基础设施尽可能降低 Token 生成成本。为无状态、亚秒级请求设计的基础设施，无法高效支持智能体会话：KV 缓存会被占满，GPU 利用率在等待工具调用期间骤降，而以每秒请求数为依据的传统规划方法，则会严重低估实际智能体集群所需的 GPU 数量。
传统的推理规划容量依赖三项参数：每次请求的平均 Token 数量、平均延迟目标和峰值每秒请求数。对于长期运行的自主智能体框架，这些指标已无法有效支撑容量规划。单个智能体任务可能涉及 50–500 次按顺序执行的模型调用，上下文长度也会随着每一步执行不断增长。智能体在等待工具调用完成时会阻塞，造成不规律的 GPU 空闲时段，浪费计算资源。推测性推理循环可能使 Token 生成速率骤增至 5 倍，随后回落至基线水平。
请参阅以下示例，了解智能体推理用例的实际应用及其技术实现。
智能体推理与常规推理对比表
| 维度 | 常规推理 | 智能体推理 |
|---|---|---|
| 会话时长 | 单次请求，毫秒级 | 数分钟至数小时，数十至数百次模型调用 |
| 上下文窗口 | 输入固定，返回一次结果 | 随每轮迭代不断增长；3 万至 12 万以上 Token 很常见 |
| 计算模式 | 每秒请求数较为稳定 | 突发计算与空闲交替 (等待工具调用返回) |
| GPU 显存 | 可预测 | 由会话 KV 缓存占用；易发生 OOM |
| 容量规划 | 平均 Token 数 × QPS | 按倍数估算 (多智能体为 5 – 15 倍) |
| NVIDIA 推荐技术栈 | NIM 端点 | NIM + NVIDIA Dynamo + NVIDIA NemoClaw™ + NeMo™ Guardrails |
智能体推理示例
了解各行业的企业组织如今如何将智能体推理应用于生产环境。
软件工程智能体
编程助手是长时间运行的自主 AI 智能体最成熟的应用形式，凸显了智能体推理的重要性。智能体可以根据 GitHub Issue、浏览代码库、编写修复代码、运行测试并发起拉取请求，整个过程无需在人工介入。Claude Code、Devin 和 GitHub Copilot Workspace 等工具就是以这种方式运行的。关键在于，智能体能够反复迭代：如果测试失败，它会读取错误信息并再次尝试。
数据分析与数据流水线智能体
这类智能体会针对数据源 (数据库、数据湖或 API) 进行推理，再决定调用哪些工具，编写和执行 SQL 或 Python 代码来处理实时数据。它们会检查结果、识别异常，并生成可视化图表、摘要和书面报告。随后，它们还可以根据分析结果，通过推理调整下游数据管道。
安全和威胁检测智能体
这类 AI 智能体会监控系统、调查告警、调取日志、关联分析不同来源的事件，并判断是否存在真实的威胁。随后，它们可自动处置问题，或将问题连同完整摘要一并上报。大型企业正在将各类安全智能体纳入其安全规程。
客户支持和运营智能体
试想一下处理支持工单的 AI 智能体，全程负责从客户首次提交问题直至问题解决的整个流程。它们能够理解客户问题、在 CRM 中查询客户账户信息、在后端系统中核查订单状态、起草回复并关闭工单。与聊天机器人不同，这些智能体不仅生成文本，还能跨多个系统执行操作。
AI 智能体的实际应用
技术实施
如何实现智能体推理
智能体的核心是一个简单的循环，但生产系统需要分层构建：以真实数据为依据、协调多个智能体、增加安全防护，并实现高效的大规模推理服务。大多数团队按照以下顺序构建。
1. 从循环开始：
智能体会反复执行一个循环：围绕目标进行推理、调用工具、读取结果，并持续执行直到任务完成。搭建这样的智能体需要三个部分：负责推理的模型、以 JSON Schema 描述的一组工具，以及运行循环的编排代码。
选择专为多步骤推理打造的模型，而非聊天模型；NVIDIA Nemotron™ 模型专为此类任务设计，并以托管 NVIDIA NIM 端点的形式运行，您无需先部署任何基础设施即可调用。对于循环本身，请使用现有智能体框架，而不是构建您自己的框架：开源 NVIDIA NeMo Agent Toolkit 负责各组件之间的连接与集成，并与 LangChain、CrewAI 和 LlamaIndex 等框架协同工作。
2. 以您的数据为依据：
智能体本身仅掌握其模型在训练中学到的知识。开放模型可以使用 NVIDIA NeMo 等训练工具，利用领域数据进行后训练，从而更好地处理特定任务的领域术语、响应格式、工作流和工具使用模式。后训练可以改善模型行为，但无法替代将智能体接入企业最新信息的工作。通过检索增强生成 (RAG) 工作流将智能体式系统连接到您的文档、数据库和 API，有助于它基于企业特有信息进行推理。
在 RAG 中，数据源被分块、嵌入，并存储在向量数据库中，智能体在每一步都会搜索该数据库。由于智能体只检索每一步所需的信息，这也有助于控制上下文窗口的大小。NVIDIA NeMo Retriever 和 GPU 加速向量搜索 (cuVS) 可处理大规模检索，而 Build an Enterprise RAG Pipeline blueprint 提供了一个可供参考的工作流，您可以直接在此基础上进行构建。
3. 发展为多智能体：
大多数实际任务会超出单个智能体的能力范围。常见的模式是由主管智能体将目标拆分为子任务，再将每项子任务分配给专用智能体 —— 分别负责搜索、编写代码和起草摘要 —— 最后汇总各方结果。
系统能力增强的同时，并发会话的数量及其背后的计算资源需求也会随之增加。NeMo Agent Toolkit 专为这种组合而构建，而 Build an AI Agent for Enterprise Research (AI-Q) Blueprint 则提供了一个开放的多智能体参考方案，您可根据自身需求进行调整。
4. 使其可用于生产：
从演示原型走向可部署系统，还需要补齐三项能力。防护机制可阻止智能体自行采取有害或不可逆的操作。NVIDIA NeMo Guardrails 支持您定义这些规则，并将高风险操作交由人工审批。可观测性会追踪每一步推理、每次工具调用和每个 Token，帮助您了解延迟和成本累积发生在哪些环节；NeMo Agent Toolkit 已内置这一能力。评估会基于已知任务为智能体评分，以便及早发现性能退化。这三项能力从一开始就纳入设计，远比事后补建容易。
5. 了解底层运行机制：
您构建的智能体，与支撑它运行的推理服务栈，是两个不同的层面。代码负责发送请求，服务层则在 GPU 上处理请求并生成 Token。聊天机器人通常只发起一个简短的请求，而智能体在单个会话中可能发起数十次甚至数百次请求。随着交互轮次增加，上下文不断累积；等待工具调用返回时，GPU 又可能处于空闲状态。传统推理服务器并非针对这种负载模式设计，而大部分成本恰恰产生于这一层。NVIDIA Dynamo 是专为此场景设计的开源服务框架：它可复用每个会话的计算上下文 (KV 缓存)，在等待工具调用返回期间保留缓存，并让并行子智能体共享相同的上下文内容。构建第一个原型时您无需使用它，但在早期规划时，应将其纳入基础设施决策的考量。
开始构建：
- 构建用于企业研究的 AI 智能体 (AI-Q)：可供您在此基础上开始构建的完整多智能体系统。
- 大语言模型 —— RAG 智能体入门：一门免费的在线自主培训课程。
常见问题解答
智能体推理与常规推理在会话时长、上下文大小和计算模式方面存在差异。常规推理在毫秒级时间内处理一个请求后即告结束。智能体推理的会话可持续数分钟至数小时，上下文窗口可能增长至数百万个 Token，推理循环或子智能体创建还会带来难以预测的突发计算需求。在 GPU 模型调用的间隙，智能体 harness 负责协调路由、工具使用、数据访问和状态管理，并为下一步准备结果，其中大部分工作在独立 CPU 上执行。基础设施的需求在本质上有所不同，需要会话感知路由、分布式 KV 缓存管理以及工具调用感知调度，而传统推理服务器在设计时并未考虑提供这些能力。
NVIDIA Dynamo 是一款面向大规模部署的开源分布式推理服务框架，对智能体应用案例提供广泛支持。NVIDIA Dynamo 通过三种核心机制提升推理效率：(1) 将预填充和解码计算分离，分别交由专用 GPU 池执行；(2) 将 KV 缓存作为集群级共享资源管理，支持在 GPU HBM、CPU DRAM 和 NVMe SSD 之间进行多层卸载；(3) 根据缓存亲和性路由智能体请求，使后续步骤复用已计算的上下文，在智能体工作负载上实现高达 97% 的缓存命中率。这些能力协同作用，将智能体集群的 GPU 利用率从 40–55% 提升至 75–85%，使每个 GPU 节点可支持的并发会话数增至 2–3 倍。
智能体推理需要能够支持 30K–120K+ 个 Token 的多轮上下文窗口，并在工具调用暂停期间保留 KV 缓存的硬件。NVIDIA Grace Blackwell 机架级扩展系统配备 72 个通过 NVIDIA NVLink™ 互连的 NVIDIA Blackwell Ultra GPU，每个 GPU 均具有 288 GB HBM3e 显存，带宽为 8 TB/s；同时通过 NVLink-C2C 提供统一的 CPU-GPU 内存空间，将多轮推理速度最高提升至 2 倍。独立 Vera CPU 通过处理外围编排、工具执行和数据搬运来支持这一循环，帮助智能体会话保持快速响应，使 GPU 高效运行。NVIDIA CMX™ 将上下文内存扩展至 NVMe SSD，以支持超出 GPU 和 CPU 内存容量的工作负载；NVIDIA Dynamo 则负责全栈编排，包括分离预填充与解码、跨内存层级管理 KV 缓存，以及根据缓存亲和性进行路由，在智能体工作负载上实现高达 97% 的命中率。
核心指标是每百万 Token 的成本，但智能体工作负载让成本难以预测：用户的单次操作就可能触发级联工具调用和推理循环，使 Token 消耗量增加数个数量级。越来越多的企业组织在追踪每 Token 指标的同时，也在追踪每项成功完成任务的成本，因为模型精度和完成率最终决定了智能体是否具有成本效益。NVIDIA DCGM 和 NVIDIA Dynamo 指标 API 提供所需的会话级遥测，以大规模准确计算这一指标。
单智能体系统向一个模型实例发送一个顺序请求链；多智能体系统涉及一个编排器和多个并发运行的子智能体。从基础设施角度看，多智能体系统使挑战成倍增加：编排器创建 10 个并发子智能体，就会产生 11 个同时长时间运行的会话，每个会话都累积 KV 缓存并产生突发计算需求。规划多智能体部署时，应按同等单智能体系统 5–15 倍的 GPU 开销进行估算，并采用 NVIDIA Dynamo 这类方案在集群范围内管理 KV 缓存。
KV 缓存 (键值缓存) 是一种 GPU 显存结构，用于存储 LLM 处理输入上下文时产生的中间计算结果，使模型无需从头处理整个上下文即可生成 Token。对于智能体推理，KV 缓存管理是核心基础设施挑战：智能体的上下文随推理步骤不断增长，KV 缓存也按比例增大，占用越来越多的 GPU HBM。对于 70B 模型，128K 个 Token 的上下文需要约 16–32 GB 的 KV 缓存，这意味着单个长时间运行的智能体在执行任务期间，就可能独占整个 GPU 的内存。NVIDIA Dynamo 的分布式 KV 缓存分层机制将非活动会话的缓存卸载到 NVMe，并按需重新加载，无需按比例增加硬件即可实现高并发。
入门
通过极端协同设计构建智能体系统
了解智能体如何消耗 Token、传统推理服务模式为何难以保证智能体的成本效益，以及专为智能体打造的基础设施应具备哪些特征。
