用 NVIDIA NeMo、Amazon Bedrock AgentCore 与 Strands Agents 构建并部署可扩展的 AI 智能体
用 Strands、NeMo Agent Toolkit 与 AgentCore 走完评测、画像、超参数寻优和 GPU 测算，并给出部署到 Runtime 的路径。
目录
#用 NVIDIA NeMo、Amazon Bedrock AgentCore 与 Strands Agents 构建并部署可扩展的 AI 智能体
这篇文章与来自 NVIDIA 的 Ranjit Rajan、Abdullahi Olaoye 和 Abhishek Sawarkar 共同撰写。
AI 的下一道前沿不只是更聪明的聊天式助手，而是能跨整个系统推理、规划和执行的自主智能体。但要做到这一点，企业开发者需要从原型走到可以安全扩展的生产级 AI 智能体。随着企业问题变得更复杂，这个挑战会变大，需要由多个专门智能体协作来完成精细任务的架构。
在开发中构建 AI 智能体，与大规模部署它们有根本差别。开发者面对原型与生产之间的鸿沟，苦于性能优化、资源扩展、安全实现和运维监控。典型做法让团队同时摆弄多套互不连通的工具和框架，难以在从开发到部署的过程中保持一致并达到最优性能。这正是 Strands Agents、Amazon Bedrock AgentCore 和 NVIDIA NeMo Agent Toolkit 这一组合发挥作用的地方。你可以一起使用这些工具，设计精细的多智能体系统，编排它们，并在生产中安全地扩展，同时带有内建的可观测性、智能体评测（evaluation）、画像（profiling）和性能优化。这篇文章演示如何使用这套集成方案，在 Amazon Web Services（AWS）上从最初开发一直到生产部署，构建、评测、优化并部署 AI 智能体。
企业级智能体的基础
开源的 Strands Agents 框架通过模型驱动的方法简化 AI 智能体开发。开发者用三个组件创建智能体：
- 基础模型（foundation model，FM），例如 Amazon Nova、Anthropic 的 Claude，以及 Meta 的 Llama
- 工具（超过 20 个内建工具，外加使用 Python 装饰器的自定义工具）
- 引导智能体行为的提示词。
该框架包含与 AWS 服务的内建集成，例如 Amazon Bedrock 和 Amazon Simple Storage Service（Amazon S3），以及本地测试支持、持续集成和持续开发（CI/CD）工作流、多种部署选项，以及 OpenTelemetry 可观测性。
Amazon Bedrock AgentCore 是一个智能体平台，用于安全地大规模构建、部署和运行有效的智能体。它有可组合的、完全托管的服务：
- 用于安全、无服务器智能体部署的运行时（Runtime）
- 用于短期和长期上下文保留的记忆（Memory）
- 网关（Gateway），通过把 API 和 AWS Lambda 函数转换成智能体可用的工具，并连接到已有的模型上下文协议（Model Context Protocol，MCP）服务器，以实现安全的工具访问
- 用于安全的智能体身份与访问管理的身份（Identity）
- 用于在沙箱环境中安全执行代码的代码解释器（Code Interpreter）
- 用于快速、安全网页交互的浏览器（Browser）
- 可观测性（Observability），提供全面的运维洞察，以追踪、调试和监控智能体性能
- 评测（Evaluations），基于真实世界行为持续检查智能体质量
- 策略（Policy），把智能体保持在已定义的边界内
这些服务被设计为可以独立或一起工作，在与开源框架或模型配合并交付企业级安全与可靠性的同时，把构建、部署和运行精细智能体的复杂性抽象掉。
用 NeMo Agent Toolkit 做智能体评测、画像和优化
NVIDIA NeMo Agent Toolkit 是一个开源框架，旨在帮助开发者构建、画像和优化 AI 智能体，而不论其底层框架是什么。它与框架无关的方法意味着它可以与 Strands Agents、LangChain、LlamaIndex、CrewAI 以及自定义企业框架无缝工作。此外，当不同框架在 NeMo Agent Toolkit 中被连接起来时，它们可以互操作。
该工具包的画像器提供完整的智能体工作流分析，跟踪令牌用量、计时、特定于工作流的延迟、吞吐，以及单个智能体和工具的运行时间，从而能够做有针对性的性能改进。它建立在该工具包的评测约束层之上，包含检索增强生成（Retrieval Augmented Generation，RAG）专用评测器（例如答案准确度、上下文相关性、响应有据性和智能体轨迹），并支持用于专门用例的自定义评测器，从而实现有针对性的性能优化。自动化超参数优化器会画像并系统性地发现温度（temperature）、top_p 和 max_tokens 等参数的最优设置，同时最大化准确度、有据性、上下文相关性，并最小化令牌用量和延迟，也针对其他自定义指标做优化。这种自动化方法会画像你的完整智能体工作流，识别瓶颈，并找出手工调参可能错过的最优参数组合。该工具包的智能 GPU 规模计算器通过模拟智能体延迟和并发场景，并预测生产部署所需的精确 GPU 基础设施，来减轻猜测。
该工具包的可观测性集成连接到常见监控服务，包括 Arize Phoenix、Weights & Biases Weave、Langfuse，以及受支持的 OpenTelemetry 系统，例如 Amazon Bedrock AgentCore Observability，从而为持续优化和维护建立连续反馈回路。
真实实现
这个示例演示一个基于知识的智能体，它从网页 URL 检索并综合信息，以回答用户查询。该方案使用 Strands Agents 构建，并集成 NeMo Agent Toolkit，被容器化以便在 Amazon Bedrock AgentCore Runtime 中快速部署，并利用 Bedrock AgentCore 服务，例如 AgentCore Observability。此外，开发者可以灵活地与 Amazon Bedrock 中的完全托管模型、托管在 Amazon SageMaker AI 中的模型、Amazon Elastic Kubernetes Service（Amazon EKS）中的容器化模型，或其他模型 API 端点集成。整体架构为一条精简工作流而设计，从智能体定义和优化走到容器化和可扩展部署。
下面的架构图说明一个用 Strands Agents 构建、集成 NeMo Agent Toolkit、并部署在 Amazon Bedrock AgentCore 中的智能体。
智能体开发与评测
先在 Strands Agents 中定义你的智能体和工作流，再用 NeMo Agent Toolkit 包装它，以配置诸如用于推理的大语言模型（large language model，LLM）和工具等组件。详细设置指南参见 GitHub 上的 Strands Agents 与 NeMo Agent Toolkit 集成示例。配置环境之后，用一条示例提示从命令行运行单个工作流，以验证智能体逻辑：
nat run --config_file examples/frameworks/strands_demo/configs/config.yml --input "How do I use the Strands Agents API?"下面是截断后的终端输出：
Workflow Result:
['The Strands Agents API is a flexible system for managing prompts, including both
system prompts and user messages. System prompts provide high-level instructions to
the model about its role, capabilities, and constraints, while user messages are your
queries or requests to the agent. The API supports multiple techniques for prompting,
including text prompts, multi-modal prompts, and direct tool calls. For guidance on
how to write safe and responsible prompts, please refer to the Safety & Security -
Prompt Engineering documentation.']为了模拟真实场景，而不是执行一次工作流就退出，你可以用 serve 命令拉起一个能够处理并发请求的长期运行 API 服务器：
nat serve --config_file examples/frameworks/strands_demo/configs/config.yml下面是截断后的终端输出：
INFO: Application startup complete.
INFO: Uvicorn running on http://localhost:8000 (Press CTRL+C to quit)智能体现在本地的 8000 端口上运行。要与智能体交互，打开一个新终端并执行下面的 cURL 命令。这会生成与前面 nat run 步骤相似的输出，但智能体作为持久服务持续运行，而不是执行一次就退出。这模拟了生产环境：Amazon Bedrock AgentCore 会把智能体作为容器化服务来运行：
curl -X 'POST' 'http://localhost:8000/generate' -H 'accept: application/json' -H 'Content-Type: application/json' -d '{"inputs" : "How do I use the Strands Agents API?"}'下面是截断后的终端输出：
{"value":"The Strands Agents API provides a flexible system for managing prompts,
including both system prompts and user messages. System prompts provide high-level
instructions to the model about its role, capabilities, and constraints, while user
messages are your queries or requests to the agent. The SDK supports multiple techniques
for prompting, including text prompts, multi-modal prompts, and direct tool calls.
For guidance on how to write safe and responsible prompts, please refer to the
Safety & Security - Prompt Engineering documentation."}智能体画像与工作流性能监控
智能体跑起来之后，下一步是建立性能基线。为了说明可用洞察的深度，在这个示例中，我们在由 NVIDIA A100 Tensor Core GPU（8 张 A100 80 GB GPU）驱动、运行于 Amazon EKS 上的 Amazon Elastic Compute Cloud（Amazon EC2）P4de.24xlarge 实例上，使用自管理的 Llama 3.3 70B Instruct NIM。我们用 nat eval 命令评测智能体并生成分析：
nat eval --config_file examples/frameworks/strands_demo/configs/eval_config.yml下面是截断后的终端输出：
Evaluating Trajectory: 100%|████████████████████████████████████████████████████████████████████| 10/10 [00:10<00:00, 1.00s/it]
2025-11-24 16:59:18 - INFO - nat.profiler.profile_runner:127 - Wrote combined data to: .tmp/nat/examples/frameworks/strands_demo/eval/all_requests_profiler_traces.json
2025-11-24 16:59:18 - INFO - nat.profiler.profile_runner:146 - Wrote merged standardized DataFrame to .tmp/nat/examples/frameworks/strands_demo/eval/standardized_data_all.csv
2025-11-24 16:59:18 - INFO - nat.profiler.profile_runner:200 - Wrote inference optimization results to: .tmp/nat/examples/frameworks/strands_demo/eval/inference_optimization.json
2025-11-24 16:59:28 - INFO - nat.profiler.profile_runner:224 - Nested stack analysis complete
2025-11-24 16:59:28 - INFO - nat.profiler.profile_runner:235 - Concurrency spike analysis complete
2025-11-24 16:59:28 - INFO - nat.profiler.profile_runner:264 - Wrote workflow profiling report to: .tmp/nat/examples/frameworks/strands_demo/eval/workflow_profiling_report.txt
2025-11-24 16:59:28 - INFO - nat.profiler.profile_runner:271 - Wrote workflow profiling metrics to: .tmp/nat/examples/frameworks/strands_demo/eval/workflow_profiling_metrics.json
2025-11-24 16:59:28 - INFO - nat.eval.evaluate:345 - Workflow output written to .tmp/nat/examples/frameworks/strands_demo/eval/workflow_output.json
2025-11-24 16:59:28 - INFO - nat.eval.evaluate:356 - Evaluation results written to .tmp/nat/examples/frameworks/strands_demo/eval/rag_relevance_output.json
2025-11-24 16:59:28 - INFO - nat.eval.evaluate:356 - Evaluation results written to .tmp/nat/examples/frameworks/strands_demo/eval/rag_groundedness_output.json
2025-11-24 16:59:28 - INFO - nat.eval.evaluate:356 - Evaluation results written to .tmp/nat/examples/frameworks/strands_demo/eval/rag_accuracy_output.json
2025-11-24 16:59:28 - INFO - nat.eval.evaluate:356 - Evaluation results written to .tmp/nat/examples/frameworks/strands_demo/eval/trajectory_accuracy_output.json
2025-11-24 16:59:28 - INFO - nat.eval.utils.output_uploader:62 - No S3 config provided; skipping upload.该命令生成详细产物，其中包括按评测指标划分的 JSON 文件（例如准确度、有据性、相关性和轨迹准确度），显示从 0 到 1 的分数、推理轨迹、检索到的上下文，以及汇总平均值。生成的产物中的其他信息包括工作流输出、标准化表格、画像轨迹，以及延迟和令牌效率的紧凑摘要。这种多指标扫查提供智能体质量与行为的整体视图。评测突出显示：虽然智能体取得了稳定的有据性分数——意味着答案可靠地由来源支持——检索相关性仍有改进空间。画像轨迹输出包含特定于工作流的延迟、吞吐，以及 90%、95% 和 99% 置信区间上的运行时间。该命令生成智能体流程的甘特图和嵌套栈分析，以精确指出瓶颈在哪里，如下图所示。它也报告并发尖峰和令牌效率，使你能准确理解扩展如何影响提示和补全的用量。
在画像期间，nat 拉起八个并发智能体工作流（图中以橙色条显示），这是评测期间的默认并发配置。所示工作流的 p90 延迟大约是 58.9 秒。关键的是，数据确认响应生成是主要瓶颈，最长的 LLM 片段大约花 61.4 秒。与此同时，非 LLM 开销保持很小。HTTP 请求平均只有 0.7–1.2 秒，知识库访问可以忽略。利用这一粒度，你现在可以识别并优化智能体工作流中的特定瓶颈。
智能体性能优化
画像之后，细化智能体的参数，以平衡质量、性能和成本。手工调节 temperature 和 top_p 这类 LLM 设置，常常是一场猜测。NeMo Agent Toolkit 把它变成数据驱动的方法。你可以用内建优化器，在参数搜索空间上做系统性扫查：
nat optimize --config_file examples/frameworks/strands_demo/configs/optimizer_config.yml下面是截断后的终端输出：
Evaluating Trajectory: 100%|██████████████████████████████████████████████████████████████| 10/10 [00:10<00:00, 1.00it/s]
2025-10-31 16:50:41 - INFO - nat.profiler.profile_runner:127 - Wrote combined data to: ./tmp/nat/strands_demo/eval/all_requests_profiler_traces.json
2025-10-31 16:50:41 - INFO - nat.profiler.profile_runner:146 - Wrote merged standardized DataFrame to: ./tmp/nat/strands_demo/eval/standardized_data_all.csv
2025-10-31 16:50:41 - INFO - nat.profiler.profile_runner:208 - Wrote inference optimization results to: ./tmp/nat/strands_demo/eval/inference_optimization.json
2025-10-31 16:50:41 - INFO - nat.eval.evaluate:337 - Workflow output written to ./tmp/nat/strands_demo/eval/workflow_output.json
2025-10-31 16:50:41 - INFO - nat.eval.evaluate:348 - Evaluation results written to ./tmp/nat/strands_demo/eval/token_efficiency_output.json
2025-10-31 16:50:41 - INFO - nat.eval.evaluate:348 - Evaluation results written to ./tmp/nat/strands_demo/eval/llm_latency_output.json
2025-10-31 16:50:41 - INFO - nat.eval.evaluate:348 - Evaluation results written to ./tmp/nat/strands_demo/eval/rag_relevance_output.json
2025-10-31 16:50:41 - INFO - nat.eval.evaluate:348 - Evaluation results written to ./tmp/nat/strands_demo/eval/rag_groundedness_output.json
2025-10-31 16:50:41 - INFO - nat.eval.evaluate:348 - Evaluation results written to ./tmp/nat/strands_demo/eval/rag_accuracy_output.json
2025-10-31 16:50:41 - INFO - nat.eval.evaluate:348 - Evaluation results written to ./tmp/nat/strands_demo/eval/trajectory_accuracy_output.json
2025-10-31 16:50:41 - INFO - nat.eval.utils.output_uploader:61 - No S3 config provided; skipping upload.
Evaluating Regex-Ex_Accuracy: 100%|████████████████████████████████████████████████████████| 10/10 [00:21<00:00, 2.15s/it]
2025-10-31 16:50:44 - INFO - nat.profiler.profile_runner:127 - Wrote combined data to: ./tmp/nat/strands_demo/eval/all_requests_profiler_traces.json
2025-10-31 16:50:44 - INFO - nat.profiler.profile_runner:146 - Wrote merged standardized DataFrame to: ./tmp/nat/strands_demo/eval/standardized_data_all.csv
2025-10-31 16:50:45 - INFO - nat.profiler.profile_runner:208 - Wrote inference optimization results to: ./tmp/nat/strands_demo/eval/inference_optimization.json
2025-10-31 16:50:46 - INFO - nat.eval.evaluate:337 - Workflow output written to ./tmp/nat/strands_demo/eval/workflow_output.json
2025-10-31 16:50:47 - INFO - nat.eval.evaluate:348 - Evaluation results written to ./tmp/nat/strands_demo/eval/token_efficiency_output.json
2025-10-31 16:50:48 - INFO - nat.eval.evaluate:348 - Evaluation results written to ./tmp/nat/strands_demo/eval/llm_latency_output.json
2025-10-31 16:50:49 - INFO - nat.eval.evaluate:348 - Evaluation results written to ./tmp/nat/strands_demo/eval/rag_relevance_output.json
2025-10-31 16:50:50 - INFO - nat.eval.evaluate:348 - Evaluation results written to ./tmp/nat/strands_demo/eval/rag_groundedness_output.json
2025-10-31 16:50:51 - INFO - nat.eval.evaluate:348 - Evaluation results written to ./tmp/nat/strands_demo/eval/trajectory_accuracy_output.json
2025-10-31 16:50:52 - INFO - nat.eval.evaluate:348 - Evaluation results written to ./tmp/nat/strands_demo/eval/rag_accuracy_output.json
2025-10-31 16:50:53 - INFO - nat.eval.utils.output_uploader:61 - No S3 config provided; skipping upload.
[I 2025-10-31 16:50:53,361] Trial 19 finished with values: [0.6616666666666667, 1.0, 0.38000000000000007, 0.26800000000000006, 2.1433333333333333, 2578.222222222222] and parameters: {'llm_sim_llm.top_p': 0.8999999999999999, 'llm_sim_llm.temperature': 0.38000000000000006, 'llm_sim_llm.max_tokens': 5632}.
2025-10-31 16:50:53 - INFO - nat.profiler.parameter_optimization.parameter_optimizer:120 - Numeric optimization finished
2025-10-31 16:50:53 - INFO - nat.profiler.parameter_optimization.parameter_optimizer:162 - Generating Pareto front visualizations...
2025-10-31 16:50:53 - INFO - nat.profiler.parameter_optimization.pareto_visualizer:320 - Creating Pareto front visualizations...
2025-10-31 16:50:53 - INFO - nat.profiler.parameter_optimization.pareto_visualizer:330 - Total trials: 20
2025-10-31 16:50:53 - INFO - nat.profiler.parameter_optimization.pareto_visualizer:331 - Pareto optimal trials: 14
2025-10-31 16:50:54 - INFO - nat.profiler.parameter_optimization.pareto_visualizer:345 - Parallel coordinates plot saved to: ./tmp/nat/strands_demo/optimizer/plots/pareto_parallel_coordinates.png
2025-10-31 16:50:56 - INFO - nat.profiler.parameter_optimization.pareto_visualizer:374 - Pairwise matrix plot saved to: ./tmp/nat/strands_demo/optimizer/plots/pareto_pairwise_matrix.png
2025-10-31 16:50:56 - INFO - nat.profiler.parameter_optimization.pareto_visualizer:387 - Visualization complete!
2025-10-31 16:50:56 - INFO - nat.profiler.parameter_optimization.pareto_visualizer:389 - Plots saved to: ./tmp/nat/strands_demo/optimizer/plots
2025-10-31 16:50:56 - INFO - nat.profiler.parameter_optimization.parameter_optimizer:171 - Pareto visualizations saved to: ./tmp/nat/strands_demo/optimizer/plots
2025-10-31 16:50:56 - INFO - nat.profiler.parameter_optimization.optimizer_runtime:88 - All optimization phases complete.这条命令按配置（本例中是 optimizer_config.yml）搜索空间的定义，对 temperature、top_p 和 max_tokens 等关键 LLM 参数启动一次自动化扫查。优化器运行 20 次试验，每次三次重复，使用加权评测指标自动发现最优模型设置。优化器跑完 20 次试验可能需要最多 15–20 分钟。
该工具包对照一个加权多目标分数评估每一组参数，目标是最大化质量（例如准确度、有据性或工具使用），同时最小化令牌成本和延迟。完成后，它生成详细的性能产物和汇总表，使你可以快速识别并选择用于生产的最优配置。下面是超参数优化器配置：
llms:
nim_llm:
_type: nim
model_name: meta/llama-3.3-70b-instruct
temperature: 0.5
top_p: 0.9
max_tokens: 4096
# Enable optimization for these parameters
optimizable_params:
- temperature
- top_p
- max_tokens
# Define search spaces
search_space:
temperature:
low: 0.1
high: 0.7
step: 0.2 # Tests: 0.1, 0.3, 0.5, 0.7
top_p:
low: 0.7
high: 1.0
step: 0.1 # Tests: 0.7, 0.8, 0.9, 1.0
max_tokens:
low: 4096
high: 8192
step: 512 # Tests: 4096, 4608, 5120, 5632, 6144, 6656, 7168, 7680, 8192在这个示例中，NeMo Agent Toolkit Optimize 系统性地评估了参数配置，并把 temperature ≈ 0.7、top_p ≈ 1.0 和 max_tokens ≈ 6k（6144）识别为在 20 次试验中产生最高准确度的最优配置。这一配置相对基线带来 35% 的准确度提升，同时相对 8192 的 max_tokens 设置取得 20% 的令牌效率增益——为这些生产部署同时最大化性能和成本效率。
优化器绘制成对帕累托曲线，如下面的成对矩阵比较图所示，以分析不同参数之间的权衡。紧随矩阵比较图之后的平行坐标图显示，最优试验（红线）在准确度、有据性和相关性上取得高分（0.8–1.0），同时在效率上有所权衡，令牌用量和延迟在归一化刻度上落到 0.6–0.8。成对矩阵确认质量指标之间有强相关，并显示所有试验的实际令牌消耗紧密聚集在 2,500–3,100 个令牌左右。这些结果表明，通过提示词工程，准确度和令牌效率仍可能进一步提高。这是开发团队可以使用 NeMo Agent Toolkit 的提示词优化能力做到的事，有助于在最大化性能的同时降低成本。
下面的图像显示成对矩阵比较。
下面的图像显示平行坐标图。
为生产 GPU 基础设施确定合适规模
在智能体已经优化、并且你已经敲定运行时或推理配置之后，可以把注意力转到评估模型部署基础设施。如果你在一批由 GPU 驱动的 EC2 实例上自管理模型部署，那么把智能体搬到生产时最难的方面之一，就是精确预测支持目标用例和并发用户需要哪些计算资源，而不超出预算或造成超时。NeMo Agent Toolkit 的 GPU 规模计算器通过使用智能体的实际性能画像，为特定服务级别目标（service level objective，SLO）确定最优集群规模，从而应对这一挑战，使合适规模能够减轻性能与成本之间的权衡。要生成规模画像，你在一系列并发水平上运行规模计算器（例如 1–32 个同时用户）：
nat sizing calc --config_file examples/frameworks/strands_demo/configs/sizing_config.yml --calc_output_dir /tmp/strands_demo/sizing_calc_run1/ --concurrencies 1,2,4,8,12,20,24,28,32 --num_passes 2在我们的参考环境上执行这一步——由 NVIDIA A100 Tensor Core GPU 驱动、运行于 Amazon EKS 的 EC2 P4de.24xlarge 实例，模型为 Llama 3.3 70B Instruct NIM——产生下面的容量分析：
Per concurrency results:
Alerts!: W = Workflow interrupted, L = LLM latency outlier, R = Workflow runtime outlier
| Alerts | Concurrency | p95 LLM Latency | p95 WF Runtime | Total Runtime |
|--------|--------------|-----------------|----------------|---------------|
| | 1 | 11.8317 | 21.3647 | 33.2416 |
| | 2 | 19.3583 | 26.2694 | 36.931 |
| | 4 | 25.728 | 32.4711 | 61.13 |
| | 8 | 38.314 | 57.1838 | 89.8716 |
| | 12 | 55.1766 | 72.0581 | 130.691 |
| | 20 | 103.68 | 131.003 | 202.791 |
| !R | 24 | 135.785 | 189.656 | 221.721 |
| !R | 28 | 125.729 | 146.322 | 245.654 |
| | 32 | 169.057 | 233.785 | 293.562 |如下图所示，计算出的并发几乎与延迟和端到端运行时间线性缩放，P95 LLM 延迟和工作流运行时间显示出近乎完美的趋势拟合（R² ≈ 0.977/0.983）。每一个额外的并发请求引入可预测的延迟惩罚，表明系统运行在一个线性容量区间内，吞吐可以通过调整延迟容忍度来优化。
拿到规模指标之后，你可以为特定并发和延迟估算 GPU 集群规模。例如，要支持 25 个并发用户、目标工作流运行时间为 50 秒，可以运行计算器：
nat sizing calc --offline_mode --calc_output_dir /tmp/strands_demo/sizing_calc_run1/ --test_gpu_count 8 --target_workflow_runtime 50 --target_users 25这个工作流分析当前性能指标并生成资源建议。在我们的示例场景中，该工具计算出：要为 25 个同时用户满足严格的延迟要求，大约需要 30 张 GPU，依据下面的公式：
gpu_estimate = (target_users / calculated_concurrency) * test_gpu_count
calculated_concurrency = (target_time_metric - intercept) / slope下面是规模估算的输出：
Targets: LLM Latency ≤ 0.0s, Workflow Runtime ≤ 50.0s, Users = 25
Test parameters: GPUs = 8
Per concurrency results:
Alerts!: W = Workflow interrupted, L = LLM latency outlier, R = Workflow runtime outlier
| Alerts | Concurrency | p95 LLM Latency | p95 WF Runtime | Total Runtime | GPUs (WF Runtime, Rough) |
|--------|-------------|-----------------|----------------|---------------|--------------------------|
| | 1 | 11.8317 | 21.3647 | 33.2416 | 85.4587 |
| | 2 | 19.3583 | 26.2694 | 36.931 | 52.5388 |
| | 4 | 25.728 | 32.4711 | 61.13 | 32.4711 |
| | 8 | 38.314 | 57.1838 | 89.8716 | |
| | 12 | 55.1766 | 72.0581 | 130.691 | |
| | 20 | 103.68 | 131.003 | 202.791 | |
| !R | 24 | 135.785 | 189.656 | 221.721 | |
| !R | 28 | 125.729 | 146.322 | 245.654 | |
| | 32 | 169.057 | 233.785 | 293.562 | |
=== GPU ESTIMATES ===
Estimated GPU count (Workflow Runtime): 30.5把生产智能体部署到 Amazon Bedrock AgentCore
在评测、画像和优化智能体之后，把它部署到生产。虽然在本地运行智能体足以测试，企业部署需要一个智能体运行时，在不承担管理基础设施开销的情况下帮助提供安全、可扩展性和稳健的记忆管理。这正是 Amazon Bedrock AgentCore Runtime 突出的地方——提供企业级无服务器智能体运行时，而没有基础设施开销。逐步部署指南参见 NeMo Agent Toolkit 仓库。通过把优化后的智能体打包进容器并部署到无服务器的 Bedrock AgentCore Runtime，你把原型智能体提升为一个能应对长时间任务和并发用户请求的有弹性应用。部署智能体之后，可见性变得关键。这一集成创造统一的可观测性体验，把不透明的黑盒执行变成深度可见。你获得生产中每一次交互的精确追踪、跨度（span）和延迟分解，并通过 OpenTelemetry 集成到 Bedrock AgentCore Observability。
下面的截图显示 Amazon CloudWatch 仪表盘，其中展示 Amazon Bedrock AgentCore 的追踪和跨度，可视化已部署 Strands 智能体的执行路径和延迟。
Amazon Bedrock AgentCore 服务远不止智能体运行时管理和可观测性。你部署的智能体可以无缝使用额外的 Bedrock AgentCore 服务，包括用于认证和授权的 Amazon Bedrock AgentCore Identity、用于工具访问的 Amazon Bedrock AgentCore Gateway、用于上下文感知的 Amazon Bedrock AgentCore Memory、用于安全代码执行的 Amazon Bedrock AgentCore Code Interpreter，以及用于网页交互的 Amazon Bedrock AgentCore Browser，以创建企业级智能体。
结论
生产级 AI 智能体需要性能可见性、优化和可靠基础设施。对这个示例用例，这一集成在三个方面都交付了结果：取得 20% 的令牌效率增益、对该示例用例 35% 的准确度提升，以及按目标并发校准的、经过性能调优的 GPU 基础设施。通过把 Strands Agents 用于基础的智能体开发和编排，把 NVIDIA NeMo Agent Toolkit 用于深度智能体画像、优化和生产 GPU 基础设施的合适规模，并把 Amazon Bedrock AgentCore 用于安全、可扩展的智能体基础设施，开发者可以拥有一套有助于提供可预测结果的端到端方案。你现在可以用这套集成方案，在 AWS 上大规模构建、评测、优化和部署智能体。要开始，请查看 Strands Agents 与 NeMo Agent Toolkit 集成示例，以及把 Strands Agents 和 NeMo Agent Toolkit 部署到 Amazon Bedrock AgentCore Runtime。
PRIMARY_SOURCE: https://aws.amazon.com/blogs/machine-learning/build-and-deploy-scalable-ai-agents-with-nvidia-nemo-amazon-bedrock-agentcore-and-strands-agents
- #NeMo
- #AgentCore
- #Strands
- #评测优化
- #GPU规模
