AWS用NeMo Switchyard按任务阶段路由Bedrock编码模型

摘要：AWS发布了一套可复现的工程实践：利用AWS CDK将LiteLLM与NVIDIA NeMo Switchyard路由插件部署到Amazon ECS Fargate，并通过Amazon Bedrock接入Claude Opus 5.5与NVIDIA Nemotron 3 Super 120B。Stage路由读取近期工具执行结果，在默认走低成本模型、发现失败信号后升级到高能力模型；Random路由则用于加权A/B测试。方案提供成本/已解决任务基准，但样例任务规模较小，且切换与集成仍属实验性配置。

---

路由目标从“单次调用”转向“已解决任务”

AWS给出的方案将LiteLLM与NVIDIA NeMo Switchyard组合为模型网关：客户端继续使用OpenAI兼容接口，并把模型名设为switchyard；LiteLLM接收请求后调用Switchyard插件，再通过Amazon Bedrock的Converse或ConverseStream API访问候选模型。

对于编码智能体，单Token价格不能代表任务成本。完整任务成本可近似写为：

[ C_{task}=\sum_{i=1}^{N}(C_{in,i}+C_{out,i}+C_{retry,i}) ]

其中，N不仅取决于任务难度，还受到智能体轮数、上下文历史重放、失败修复和重试的影响。评测路由效果时，更合理的指标是：

[ CostPerSolvedTask=\frac{\sum C_{run}}{#{runs\mid tests\ pass}} ]

这意味着一个便宜模型即使显著降低平均单次调用成本，只要失败或重试过多，其“每个已解决任务”的总成本仍可能高于直接使用高能力模型。

Stage路由如何利用工具执行信号

Switchyard的Stage策略面向恰好两个候选模型。候选顺序承担角色定义：第一个是capable model，第二个是efficient model。路由器读取请求历史中的工具调用与执行结果，提取失败、测试不通过等执行信号：

• 新请求没有工具结果，信号不充分，默认路由至低成本模型；
• 近期工具结果反复显示失败时，路由至高能力模型；
• confidence_threshold控制执行信号置信阈值；
• recent_window限定检查最近多少条工具结果；
• only_on_wrong_signal_escalation控制何时附加升级提示。

这种机制没有再调用一个裁判模型，额外路由推理开销主要来自读取历史和规则化信号处理。但它依赖客户端回传完整且结构受支持的历史，上游适配器仅覆盖文本消息、函数工具调用和文本工具结果；其他消息形态会在推理前失败。

Random策略则按配置权重随机选择候选，适合流量分配与A/B测试，但不会根据任务状态主动升降级。需要分类模型参与决策的Task、Composite等策略不在当前LiteLLM集成范围内。

AWS参考架构与请求路径

示例通过AWS CDK部署以下链路：

1. 编码智能体向Application Load Balancer发送OpenAI兼容请求；
2. Route 53与AWS Certificate Manager提供HTTPS域名和证书；
3. AWS WAF执行IP信誉、已知恶意输入和单IP限流检查；
4. 负载均衡器只放行/v1/chat/completions、/v1/models和/health/liveliness；
5. 私有子网中的ECS Fargate容器运行LiteLLM与Switchyard插件；
6. ECS任务角色通过Amazon Bedrock Runtime接口调用模型；
7. 响应中的x-litellm-model-name暴露实际服务模型，响应体的model仍为switchyard。

这种设计将管理界面、API文档和密钥管理路径挡在负载均衡器之外，容器安全组也只允许负载均衡器访问。网关密钥保存在AWS Secrets Manager，AWS凭证由IAM任务角色提供，避免在模型配置中明文写入长期密钥。

不过，安全边界仍取决于配置。示例要求使用受限IPv4 /32访问范围，并允许临时启用明文HTTP测试；后者会暴露Authorization头、代码、提示词和模型响应，只能用于短期非敏感验证。global. Bedrock推理配置还可能在多个支持区域处理请求，数据驻留敏感场景应改用区域模型或地理推理配置。

成本与质量如何进入同一个评测闭环

AWS样例提供bench/run.py和bench/multiturn.py两类评测器。前者让编码智能体读取文件、修改源码并运行单元测试，以测试通过定义任务完成；后者执行多轮编码对话，并在每一轮回放完整历史。

每轮成本依据实际服务模型和返回Token用量计算。若缓存输入缺少价格、模型未配置价格条目，或响应缺少模型头及Token统计，该轮会被标记为未计价，而不是错误地按零成本处理。这种处理避免了因数据缺失而系统性低估成本。

结果至少应同时观察：

• SOLVED：成功解决数量；
• COST/TASK：所有尝试的平均成本；
• COST/SOLVED：按成功任务归一化后的成本；
• 错误率、实际模型分布与任务级差异；
• 上下文截断、输出上限和重试造成的成本变化。

官方明确提醒，示例只含少量小型任务，不能据此得出成本或质量结论。模型输出具有随机性，差异只有一两个成功任务时可能只是噪声；正式决策应增加重复次数，并可用Fisher精确检验比较成功率。

工程权衡：节省成本可能推迟失败

Stage路由的核心矛盾是“延迟升级”。先让便宜模型尝试，可以减少普通任务的调用成本，但失败后再升级时，系统必须重放此前的完整历史。这意味着恢复成本可能高于一开始就让强模型处理。

若少量困难任务主导总成本，更合理的策略可能是：

• 将已知困难任务放入专用模型组；
• 提高efficient model本身的解决率；
• 在进入路由层前使用项目类型、仓库特征等确定性规则分流；
• 单独评估硬任务，而不是只看聚合平均值。

此外，评测中的max_tokens截断会缩短后续需要重放的历史，并可能低估真实成本；Prompt Cache、Batch Inference及AWS价格调整也会使离线估算偏离实际账单。最终仍需用AWS Cost and Usage Reports核账。

开发者落地建议

1. 在独立非生产账户中部署，先运行本地Docker Compose烟雾测试，再通过AWS CDK创建ECS、Fargate、负载均衡器、WAF和Bedrock权限；
2. 始终从同一组代码任务比较路由组与单模型基线，并增加重复次数；
3. 使用生产同构的Agent框架、轮数上限、工具集合和提示词，否则结论难以迁移；
4. 优先记录实际服务模型、Token、缓存命中、重试原因和测试结果，避免只汇总Token价格；
5. 对历史中的源代码、工具输出和模型生成代码执行沙箱隔离；示例测试进程并非操作系统级沙箱，可读取当前用户有权访问的文件并访问网络；
6. 切换模型、路由阈值或工具行为后重新跑基准，避免把旧配置下的结果外推到新工作负载。

该方案的核心价值不在于提出新的基础模型，而在于提供一条可审计的模型路由工程路径：以任务结果而非Token单价定价模型选择，并让路由策略能够通过统一网关和回归评测持续迭代。不过，Switchyard的LiteLLM集成目前为实验性质，switchyard-server 0.3.0也仅被定位为演示与评测组件，因此更适合作为企业构建编码智能体模型路由层的起点，而非直接投入生产。

---

消息来源：AWS Machine Learning Blog (2026-11-13)

—— 完 ——

主题标签： #NeMo Switchyard 关注 #编码智能体 关注 #模型路由 关注 #Amazon Bedrock 关注 #成本优化 关注