AWS发布示例方案：用NVIDIA NeMo Switchyard在Bedrock上按任务路由编程智能体请求
AWS机器学习教育博客介绍一套基于AWS CDK的非生产示例：LiteLLM网关加载NVIDIA NeMo Switchyard插件，在Claude Opus 5.5与Nemotron 3 Super 120B之间按请求历史选择模型，并用“每个已解决任务的成本”对比单模型基线。
AI解读：AWS作者Aswath Ram A Srinivasan在机器学习教育博客中发布示例，演示如何用AWS CDK部署LiteLLM网关并加载NVIDIA NeMo Switchyard路由插件，由后者在Amazon Bedrock上为编程智能体请求选择模型。
文章提出评估路由的指标是“每个已解决任务的成本”：整次运行的累计费用除以测试通过的任务数；原因是编程任务可能包含多次模型调用，token单价无法反映重试和未完成任务的支出。
示例支持两种路由策略：Stage策略读取近期工具调用结果，在两个候选模型间选择（先声明能力模型、后声明低成本模型）；Random策略按权重分流，可用于A/B测试。两种策略都不调用裁判模型。
默认配置把Claude Opus 5.5作为能力模型、NVIDIA Nemotron 3 Super 120B作为高效模型，并设置picker = efficient_first，即历史信号不足时先走高效模型；Stage要求恰好两个候选，分类器类策略（Task、Composite）不在该集成支持范围内。
作者明确标注这是非生产示例：switchyard-server 0.3.0被NVIDIA作为演示和评估组件记录，配置可能随版本变化；LiteLLM集成处于实验阶段，API与配置可能变动，部署前需由安全与法务团队审核，并在非生产账户测试。
示例还包含网络与访问限制：仅允许指定IPv4 CIDR访问，WAF对每IP限 2,000 请求/5 分钟，负载均衡只转发 /v1/chat/completions、/v1/models与 /health/liveliness，其余路径返回 404；可选的明文HTTP仅用于短时测试非敏感代码。
AWS机器学习教育博客发布一套示例方案，用AWS CDK在Amazon ECS on Fargate上部署LiteLLM网关，并加载NVIDIA NeMo Switchyard路由插件，让编程智能体的请求在Amazon Bedrock上的两个模型之间自动分流。文章作者是Aswath Ram A Srinivasan。
作者在文中把评估标准定为“每个已解决任务的成本”，即整次运行总费用除以测试通过的任务数，并称示例提供基准运行器，可在自建工作负载上对比路由模型组与单模型基线的这一指标。
路由策略与默认配置
示例在LiteLLM的模型组中把两个Bedrock模型登记在同一个公开模型名switchyard下：Claude Opus 5.5（通过global.anthropic.claude-opus-5-5）与NVIDIA Nemotron 3 Super 120B（nvidia.nemotron-super-3-120b）。客户端发送model为switchyard，由插件挑候选。
Stage策略读取请求历史中最近的工具调用活动与结果，在两个候选之间选择。示例默认picker = efficient_first，confidence_threshold = 0.5，recent_window = 3，即检查最近三条工具结果，信号不足时走高效模型。Stage要求恰好两个候选，并按声明顺序读取“能力模型/高效模型”角色。Random策略按权重从候选中挑选，示例权重为 [0.5, 0.5]，用于流量拆分和A/B对比。作者称两种策略都不调用裁判模型。
- Stage：读最近三条工具结果，按 0.5 置信阈值在两个模型间选择
- Random：按权重分流，示例为两个候选各 0.5
- 分类器类策略（Task、Composite）需额外模型调用，该集成不支持
部署形态与访问限制
示例把LiteLLM和Switchyard插件打包进一个容器镜像，运行在私有子网的ECS Fargate任务上，通过Amazon Bedrock Converse或ConverseStream API调用模型，凭据来自任务IAM角色，推理流量经VPC内的Bedrock Runtime接口端点发出。响应的x-litellm-model-name头标出实际作答的模型，响应体的model字段仍为switchyard。
访问控制方面，作者要求部署时提供allowedCidr，命令取当前公网IPv4的 /32；栈拒绝 0.0.0.0/0 或IPv6范围。负载均衡仅转发 /v1/chat/completions、/v1/models与 /health/liveliness，其余路径返回 404；WAF对每个IP限制 2,000 请求/5 分钟，并启用IP信誉与已知恶意输入规则。作者还说明，网关密钥、提示词、工具结果和模型响应在客户端与负载均衡之间以明文传输，只应在自己的 /32 上用非敏感代码做短暂测试，之后轮换密钥并销毁栈。
- 容器监听 4000 端口，仅接受负载均衡的流量
- LiteLLM请求超时 600 秒，与负载均衡 10 分钟空闲超时一致
- 日志写入 /litellm日志组，保留 30 天
适用范围与限制
作者明确这套代码是示例，非生产用途，并建议在非生产账户部署测试；switchyard-server 0.3.0被NVIDIA记录为演示与评估组件，其配置可能随版本变化；Switchyard的LiteLLM集成被标为实验性，配置和API可能变化。部署前需与组织安全和法务团队确认安全、监管与合规要求。
前置条件包括：可访问Claude Opus 5.5与Nemotron 3 Super 120B的非生产AWS账户（这一组合在弗吉尼亚北部测试过），AWS CLI v2、Node.js 20+、Docker BuildKit、Python 3.11+，以及自有域名和Route 53托管区或对应区域的ACM证书。使用global.前缀的跨区域推理配置时，Bedrock可能在支持范围内的多个商业区域处理请求；若在意处理位置，作者建议改用地理配置文件或区域内的模型ID。
- Stage路由仅在恰好两个候选时生效
- 示例不写入任何凭据，密钥由Secrets Manager生成并在启动时加sk-前缀