NVIDIA Nemotron 3.5 Lightning 现已通过 Amazon SageMaker JumpStart 提供。它面向高吞吐量的 Agentic 工作负载，采用 30B 参数的 Mixture-of-Experts 架构，但每次推理只有约 3B 参数处于激活状态。根据来源摘要，在适合的 always-on Agent 场景中，它最高可实现 4 倍吞吐量，并将任务完成时间缩短最多 30%。
这类模型的价值不只在于单次回答质量，还在于能否稳定处理持续到来的任务：规划、工具调用、状态更新和结果汇总往往会同时发生。JumpStart 则把模型部署、端点管理和 SageMaker 推理链路放进了 AWS 托管环境，降低了从模型到服务的落地成本。
为什么 MoE 适合常驻 Agent
传统稠密模型通常会在每个 token 上激活全部参数。MoE 模型则将参数划分为多个专家模块，并根据输入选择部分专家参与计算。Nemotron 3.5 Lightning 的模型规模为 30B，但摘要明确指出其激活参数量为 3B。
这意味着部署时仍然需要认真评估显存、并发数和上下文长度，不能简单地把它当成一个 3B 模型。不过，在硬件资源足够、请求可以批处理或并发执行的情况下，较低的激活参数量有机会改善单位时间内的处理能力。
对 Agent 服务而言，吞吐量通常比单次延迟更关键。一个 Agent 可能需要连续调用模型数次：
- 生成计划
- 选择工具
- 解释工具返回值
- 修正参数并重试
- 汇总最终结果
当这些请求持续运行时，端点的吞吐能力会直接影响队列长度和任务完成时间。来源摘要给出的最高 4 倍吞吐和最多 30% 的任务完成时间改善，应理解为特定工作负载和部署条件下的目标表现，而不是所有应用都能直接复现的固定结果。
JumpStart 部署时需要关注什么
JumpStart 可以简化模型发现和部署流程，但生产环境仍然需要完成几项工程判断。
端点规格与成本
30B MoE 的总参数规模并不等于每次推理的计算量。部署时需要综合考虑模型权重、KV cache、上下文窗口、并发请求数和批处理策略。具体实例类型应依据 JumpStart 当前支持的模型配置、区域可用性和压测结果选择。
建议先使用与生产请求相似的提示词长度和并发模式进行测试，记录以下指标：
- 首 token 延迟和完整响应延迟
- 每秒生成 token 数
- 端点吞吐量
- P95/P99 延迟
- 实例利用率和显存占用
- 单个 Agent 任务的端到端完成时间
请求协议与输出格式
模型端点的请求字段可能随 JumpStart 容器或模型版本变化。部署完成后，应以 SageMaker JumpStart 控制台、模型文档或端点契约为准确认 payload 格式。下面的示例使用常见的文本生成请求结构，实际接入前需要根据当前模型支持的 schema 调整。
Agent 调度方式
高吞吐模型并不意味着应该无限提高并发。Agent 框架仍需设置队列上限、超时、重试次数和幂等键。工具调用失败时，如果每个失败都触发多轮重试，流量可能迅速放大，反而抵消模型吞吐优势。
一个可改造的部署与调用示例
下面示例使用 SageMaker Python SDK 的 JumpStart 接口。运行前准备好 AWS 凭证、SageMaker 执行角色，以及当前区域可用的 Nemotron 3.5 Lightning JumpStart 模型 ID。由于模型 ID 和请求 schema 可能随发布版本变化，代码将它们放在环境变量中，便于替换。
安装依赖：
python -m pip install --upgrade sagemaker boto3
export AWS_REGION=us-east-1
export SAGEMAKER_ROLE_ARN=arn:aws:iam::123456789012:role/SageMakerExecutionRole
export JUMPSTART_MODEL_ID=<当前区域可用的-Nemotron-3.5-Lightning-模型ID>
创建端点并发送一次测试请求：
import json
import os
import boto3
import sagemaker
from sagemaker.jumpstart.model import JumpStartModel
region = os.environ.get("AWS_REGION", boto3.Session().region_name)
role = os.environ["SAGEMAKER_ROLE_ARN"]
model_id = os.environ["JUMPSTART_MODEL_ID"]
session = sagemaker.Session(boto3.Session(region_name=region))
model = JumpStartModel(
model_id=model_id,
role=role,
sagemaker_session=session,
)
# 端点规格必须根据当前 JumpStart 支持列表和压测结果选择。
predictor = model.deploy(
initial_instance_count=1,
instance_type="<替换为当前支持且经过压测的实例类型>",
)
try:
payload = {
"inputs": "Plan the steps needed to investigate a failed payment and summarize the required tool calls.",
"parameters": {
"max_new_tokens": 256,
"temperature": 0.2,
},
}
response = predictor.predict(payload)
print(json.dumps(response, ensure_ascii=False, indent=2, default=str))
finally:
# 测试完成后删除端点，避免持续产生实例费用。
predictor.delete_endpoint()
这段代码展示的是部署骨架，而不是对所有版本都适用的固定协议。使用前至少要替换两个占位符：JUMPSTART_MODEL_ID 和 instance_type。如果当前容器要求 JSON 字符串而不是 Python 字典，可以改为：
response = predictor.predict(
json.dumps(payload),
content_type="application/json",
)
生产环境通常不应在每次请求后删除端点，而是创建长期运行的端点，并通过 CloudWatch、SageMaker 指标和业务埋点观察效果。测试脚本中的 delete_endpoint() 只用于防止临时验证留下闲置资源。
如何验证 4 倍吞吐是否适用于你的 Agent
不要只比较模型单次生成的速度。更有价值的测试是复现真实 Agent 流程：同样的任务集合、相同的工具响应、相同的上下文长度，以及相同的并发增长曲线。
可以按下面的顺序建立基线：
- 记录现有模型在固定任务集上的端到端完成时间。
- 统计每个任务平均需要多少次模型调用和工具调用。
- 在相同并发下测试 Nemotron 3.5 Lightning 的 P50、P95 延迟和总吞吐。
- 逐步增加并发，观察队列等待时间、限流和错误率。
- 将模型成本、实例利用率和任务成功率一起纳入比较。
一个简单的压测记录表可以包含 request_id、agent_task_id、模型调用次数、输入 token、输出 token、首 token 延迟、总延迟和最终任务状态。这样才能判断性能收益究竟来自模型本身，还是来自批处理、提示词缩短或调度策略变化。
上线前检查清单
- 确认目标 AWS 区域支持该 JumpStart 模型和所选实例。
- 为 SageMaker 执行角色配置最小必要权限。
- 明确请求 payload、停止条件和输出解析规则。
- 为 Agent 设置超时、并发上限、重试次数和熔断策略。
- 使用真实上下文长度测试 KV cache 和显存占用。
- 通过 CloudWatch 和应用日志跟踪 P95/P99 延迟与任务成功率。
- 对工具调用、用户数据和模型输出执行必要的权限与安全检查。
- 临时端点验证结束后及时删除，生产端点则纳入成本和容量管理。
Nemotron 3.5 Lightning 的核心吸引力，是将较大的 MoE 模型规模与较低的激活参数量结合起来，并针对高容量 Agent 工作负载提供更高的处理效率。SageMaker JumpStart 让部署入口更直接，但最终是否能获得接近摘要中的吞吐和任务完成时间收益，仍取决于实例选择、请求分布、上下文长度和 Agent 调度方式。先做端到端基准测试，再决定是否扩大常驻容量，通常是更稳妥的采用路径。