AI 平台/部署

如何将生产环境中的 LangGraph 智能体从单个用户扩展到 1000 名同事

您已经成功构建了一个功能强大的 AI 智能体,并准备与同事分享,但您有一个重要的顾虑:如果同时有 10 位、100 位甚至 1000 位同事尝试使用它,该代理是否仍能正常运行?回答这一关键问题,是将 AI 智能体投入生产环境的核心环节。我们最近在内部部署基于 LangGraph 构建的代理式应用 AI-Q NVIDIA Blueprint 的深度研究智能体时,就曾面临这一挑战。

本文将介绍在 NVIDIA NeMo Agent 工具套件 中用于部署 代理式 AI 应用并将其扩展至生产环境的工具与技术。

如何构建安全、可扩展的 deep-researcher

深度研究类应用程序的使用已无处不在,许多人经常使用 Perplexity、ChatGPT 或 Gemini 等工具。然而,与许多组织一样,将这些深度研究工具与 NVIDIA 的机密信息结合使用可能面临诸多挑战。为此,NVIDIA 今年早些时候发布了一个开源蓝图,用于构建可本地部署的深度研究应用程序。这一蓝图正是我们在内部生产环境中部署深度研究助手的起点。

架构 

AI-Q 研究智能体支持用户上传文档以提取元数据、访问内部数据源,并通过网络搜索生成研究报告。该蓝图基于 NeMo Agent 工具包实现,采用多种 NVIDIA NeMo 检索器 模型完成文档信息提取与检索,并调用大语言模型 LLM 进行内容生成。

我们的生产环境部署在内部的 OpenShift 集群(AI 工厂参考架构)上,可访问本地部署的 NVIDIA NIM 微服务以及第三方可观察性工具。当前面临的挑战在于,需要明确系统中哪些组件需要扩展,以支持向数百名来自不同 NVIDIA 团队的用户进行推广。

A diagram of an agentic system showing a user prompt going to an agent, which coordinates reasoning, report generation, web search, and enterprise file retrieval using NVIDIA Llama Nemotron reasoning, NeMo Retriever, and LLM NIM microservices.
图 1。AI-Q 研究智能体蓝图架构图

为应对这一挑战,我们在每个阶段均采用 NeMo Agent 工具套件中的工具,分三个步骤执行操作。

  1. 将应用程序分析为单个用户以识别瓶颈。
  2. 运行负载测试以收集数据并估算数百名用户所需的架构。
  3. 在分阶段推出期间监控应用程序。

第 1 步:如何分析和优化单个代理式应用?

将代理式应用引入生产环境面临的一个挑战在于,每个代理式应用都各不相同,因此很难制定诸如“每 100 位用户需要一块 GPU”这样的通用准则。相反,扩展应用的第一步是深入理解应用在单个用户场景下的运行方式。通过 NeMo Agent 工具套件提供评估和分析系统,可以轻松收集数据并对应用行为进行量化分析。<!–

使用 NeMo Agent 工具包 profiler

要使用评估和分析工具,只需在应用程序的配置文件中添加评估部分即可。评估配置包含一个数据集,其中收录了应用的示例用户输入。由于代理式应用并非确定性系统,因此通过分析多种输入来了解应用在用户可能提供的各种情况下的表现,具有重要意义。

eval:
  general:
    output_dir: single_run_result
    dataset:
      _type: json
      file_path: example_inputs.json
    profiler:
      # Compute inter query token uniqueness
      token_uniqueness_forecast: true
      # Compute expected workflow runtime
      workflow_runtime_forecast: true
      # Compute inference optimization metrics
      compute_llm_metrics: true
      # Compute bottleneck metrics
      bottleneck_analysis:
        enable_nested_stack: true
      concurrency_spike_analysis:
        enable: true
        spike_threshold: 7


AI-Q 研究智能体是 使用 NeMo Agent Toolkit 函数包装器的 LangGraph 应用。通过使用这些封装器,分析器能够自动捕捉应用程序各个部分的计时信息和令牌使用情况。此外,我们还可以通过在关注的函数上添加简单的修饰器,来跟踪应用程序中的子步骤。

from aiq.profiler.decorators.function_tracking import track_function

@track_function(metadata={"source": "custom_function"})
def my_custom_function(a, b):
  return a + b

eval 命令可在跨输入数据集时运行工作流程,并收集和计算各种有用的指标。

aiq eval --config_file configs/eval_config.yml

一个可用的输出示例是甘特图(或瀑布图),该图表展示了用户会话各个阶段中正在执行的函数。这些信息有助于识别应用程序中可能成为瓶颈的部分。对于 AI-Q 研究智能体而言,主要瓶颈在于对 NVIDIA Llama Nemotron Super 49B 推理 LLM 的调用。在明确瓶颈后,我们可以集中精力复制并扩展该 LLM 的 NVIDIA NIM 部署。

Gantt chart showing the sequence and overlap of steps in a report writing process, including planning, parallel search, section writing, reflections, and final summary. Tasks are color coded and labeled with brief descriptions.
图 2。NeMo Agent 工具包中的甘特图,显示时间和瓶颈

评估准确率 

除了记录时间和 token 使用情况外,评估与分析工具还能够计算各类评估指标。在我们的场景中,构建一个响应迅速且能服务大量用户的应用至关重要,同时该应用还需能够生成有价值的报告。为此,我们针对深度研究用例设计了自定义指标,并利用分析与评估工具对不同版本的应用代码进行基准测试。这一基准测试确保我们在进行任何性能优化时,不会牺牲报告的质量。该工具包支持以多种格式输出指标,其中一种特别实用的功能是将指标导出至 Weights and Biases 等平台,以便对实验结果进行长期跟踪与可视化分析。

A dashboard compares two machine learning models using bar and radar charts for metrics like accuracy, recall, and precision. Feature importances are listed below.
图 3。两个不同特征分支之间的指标比较

第 2 步:您的架构可以处理 200 位用户吗?估算您的需求 

在完成对单个用户应用程序性能的了解与优化后,我们准备进入下一阶段:针对多个用户开展负载测试。负载测试的目标包括:(a) 以更高的并发量运行应用程序,(b) 发现并修复潜在故障,以及 (c) 收集数据以指导最终部署的资源配置需求。

为了确定哪种架构能够支持 200 个并发用户,我们利用现有硬件对 10、20、30、40 和 50 个并发用户进行了负载测试,并基于测试过程中收集的数据,预测了完整部署所需的硬件资源。

为进行负载测试,我们使用了 NeMo Agent Toolkit 大小计算器

捕获并发数据 

工具包大小计算器使用相同的分析和评估工具来运行模拟工作流,但会在不同的并发级别上并行执行。

aiq sizing calc 
 --calc_output_dir $CALC_OUTPUT_DIR 
 --concurrencies 1,2,4,8,16,32
 --num_passes 2

该计算器在负载测试期间会捕获多项指标,包括每次 LLM 调用的 p95 延迟以及整个工作流程的 p95 延迟。* 请注意,下方显示的输出仅用于工具放示例,不代表内部深度研究智能体负载测试的实际数据。

Line graph showing the relationship between concurrency and p95 LLM latency and workflow runtime; as concurrency increases, both latency and runtime increase, with workflow runtime rising more steeply.
图 4。NeMo Agent Toolkit 大小计算器捕获的计时数据

规模输出预测

在以不同并发方式采集数据后,我们可以评估现有架构和硬件所能支持的用户数量。例如,在以下输出中,假设我们在单个 GPU 上运行负载测试,结果显示,在满足可接受延迟范围的前提下,单个 GPU 可支持 10 个并发用户。基于这一信息,我们可以推断,支持 100 个并发用户需要 10 个 GPU。

Two scatter plots comparing "Concurrency vs P95 LLM Latency" (left) and "Concurrency vs P95 Workflow Runtime" (right). Both show increasing trends, with one outlier removed in the left plot. The axes indicate concurrency (x-axes) and latency/runtime in seconds (y-axes). Legends and trend lines are included in both plots.
图 5。通过 NeMo Agent Toolkit 配置计算器预测硬件需求

其他学习 

执行负载测试的另一个好处是,它有助于发现应用程序中在单个用户运行时可能不明显的瓶颈或错误。例如,在 AI-Q 研究智能体的初始负载测试中,我们发现并修复了两个问题。

在进行负载测试期间,我们监控了硬件指标,发现其中一个 NVIDIA NIM 微服务占用了 100% 分配的 CPU。该发现帮助我们定位到根本原因,即 Helm Chart 中存在错误配置,导致部署的 NIM 所分配的 CPU 资源少于预期。

  1.  
Line graph showing total CPU percentage utilization over time, with a sharp rise and brief fluctuations before stabilizing at around 100%.
图 6。压力测试期间 CPU 资源不足

我们发现,当 LLM 调用超时时,应用程序在许多情况下会出现故障。通过添加重试机制和更完善的错误处理,我们实现了更平滑的降级,避免了间歇性故障对整体用户体验造成影响。

try: 
async with asyncio.timeout(ASYNC_TIMEOUT):
  async for chunk in chain.astream(input, stream_usage=True):
    answer_agg += chunk.content
      if "</think>" in chunk.content:
        stop = True
      if not stop:
       writer({"generating_questions": chunk.content})

except asyncio.TimeoutError as e: 
writer({"generating_questions": "Timeout error from reasoning LLM, please try again"})
return {"queries": []}

第 3 步:在扩展到生产时,如何监控、追踪和优化研究智能体的性能

掌握这些信息后,我们便能在各类系统组件中部署具备适当副本数量的 AI-Q 研究智能体。作为最后一步,我们采用分阶段扩展策略,从小规模团队起步,逐步增加更多用户。在上线过程中,密切监控应用性能至关重要。我们通过 NeMo Agent Toolkit OpenTelemetry (OTEL) 收集器 和 Datadog 来采集日志、性能数据以及 LLM 追踪信息。

general:
  telemetry:
    tracing:
   otelcollector:
     _type: otelcollector
       # Your otel collector endpoint
       endpoint: http://0.0.0.0:4318/v1/traces
       project: your_project_name

借助 OTEL 收集器集成,我们能够查看单个用户会话的特定追踪,从而更好地了解应用性能和 LLM 的行为。

A performance trace dashboard showing a timeline of tasks, including "generate_summary" and "search_msg," with bars indicating their execution times and overlaps.
图 7。Datadog 火焰图形,显示真实用户会话的计时

我们还可以聚合不同追踪的性能数据,以全面了解应用程序的运行状况。下图展示了具有异常性能的平均延迟及用户会话情况。

A dashboard screenshot showing high latency span analysis, with graphs and data tables breaking down unusual and typical latency by resource name, span kind, input mime type, and input value.
图 8。Datadog 延迟分析显示单个追踪函数的 p95 倍和异常值。

总结 

通过将 NeMo Agent Toolkit 与多家 AI 工厂参考合作伙伴集成,我们成功部署了 AI-Q NVIDIA Blueprint 的内部版本,并能够自信地构建研究智能体。

亲自详细了解 使用 NeMo Agent 工具套件进行构建试用 AI-Q NVIDIA 研究智能体蓝图 的相关信息。

 

标签