← 返回AI变现
🌐 其他

NVIDIA NeMo Switchyard 与智能模型路由趋势下,如何统一管理多供应商 API 与协议转换

来源:掘金 · 发布于 2026-08-20 17:15:53
NVIDIA NeMo Swi
好消息好消息,NVIDIA 开源了 NeMo Switchyard,一个用 Rust 编写的 LLM 流量代理和路由库。Switchyard 提出,并非每个请求都需要调用顶尖模型

NVIDIA NeMo Switchyard 与智能模型路由趋势下,如何统一管理多供应商 API 与协议转换

ServBay 2026-08-20 0 阅读14分钟

好消息好消息,NVIDIA 开源了 NeMo Switchyard,一个用 Rust 编写的 LLM 流量代理和路由库。Switchyard 提出,并非每个请求都需要调用顶尖模型,通过智能模型路由(Intelligent Model Routing)在多个模型之间按需分配流量,可以在保持效果的同时降低调用成本。

NVIDIA NeMo Switchyard

随着 AI 发展越来越快,大模型市场高度碎片化,OpenAI、Anthropic、Google Gemini、DeepSeek、智谱 GLM、通义千问等数十家供应商各有所长,开发团队很少只依赖单一供应商。多模型并行带来的密钥管理混乱、成本不透明、供应商切换困难和单点故障风险,已演变为绑在一起的系统性工程问题。

NeMo Switchyard 选择用开源代理与路由算法库的方式解决模型选择和协议翻译问题。ServBay AI Gateway 则在更完整的维度上给出了自己的方案,覆盖渠道接入、流量调度、虚拟密钥、模型映射、协议转换和用量统计的全链路。

本文从 NeMo Switchyard 的技术设计出发,梳理智能模型路由涉及的关键能力维度,再逐项展开 ServBay AI Gateway 如何在实际场景中落地这些能力。

AI Gateway是什么

NVIDIA NeMo Switchyard 做了什么?

NeMo Switchyard 基于 Apache 2.0 协议开源,定位为 LLM 流量的代理和路由库,目前处于 pre-alpha 阶段。它把 LLM 请求的选路问题拆成三个独立的技术模块。

协议翻译

Switchyard 支持在 OpenAI Chat Completions、Anthropic Messages 和 OpenAI Responses 三种 API 格式之间双向转换。官方文档中举了一个典型用法:把 Claude Code(原生使用 Anthropic 格式)指向 Switchyard,再由 Switchyard 转发到 vLLM 或 Ollama 上部署的开源模型。Claude Code 继续用自己的原生 API 格式发请求,Switchyard 在中间完成格式转换,工具侧不需要做任何适配。

路由算法

Switchyard 内置了四种路由策略:

  • Random:在候选模型之间随机分配,适合 A/B 测试

  • LLM Classifier:用一个 LLM 对请求做分类,根据分类结果路由到对应模型

  • Stage Router:根据请求的复杂度信号做分级,简单请求走轻量模型,复杂请求走旗舰模型

  • Escalation Router:LLM Classifier 的升级模式,低置信度的请求自动升级到更高能力的模型

其中 Stage Router 是最受关注的算法。在一组基准测试中,通过调整 Stage Router 的置信阈值从 0.3 提高到 0.5,旗舰模型(Claude Opus 4.8)的调用比例从 85% 降到了 17%,轻量模型(GLM-5.2)承接了大部分流量。最终单任务成本下降了 43.7%,任务完成率保持稳定。

运维指标

Switchyard 暴露 Prometheus 格式的指标数据,覆盖请求数、错误率、延迟、Token 消耗和路由决策的额外开销。

不过 Switchyard 的使用门槛不低。安装需要 Rust 编译环境或 Python uv 工具链,配置通过 TOML 文件完成,目前没有图形化管理界面。官方也明确标注为实验性软件,不建议直接用于生产环境。

从 Switchyard 的能力框架看 AI 网关需要解决的问题

NeMo Switchyard 的设计虽然聚焦在路由和协议翻译上,但它也说明了一个问题,那就是完整的 AI 流量管理方案,至少需要覆盖以下几个能力维度:

  1. 多供应商渠道接入:能接多少家供应商,是否支持自定义后端

  2. 流量调度:请求如何在多个渠道之间分配,故障时如何自动回退

  3. 凭证安全:API Key 如何存储和管理,如何避免泄露

  4. 模型映射:应用层的模型标识是否可以与实际后端模型解耦

  5. 协议转换:不同供应商的 API 格式差异如何屏蔽

  6. 用量统计:Token 消耗、成本花费、性能数据是否可追踪

Switchyard 在协议翻译和路由算法上做得很深,但在凭证管理、用量统计、渠道健康管理等方面留给了使用者自行解决。这源于 Switchyard 的定位是路由库,不是完整的网关产品。

而 ServBay AI Gateway 的定位是一个全功能的 AI 网关,覆盖上述六个维度的完整实现。

渠道管理:从官方 API 到中转站的全面覆盖

ServBay AI Gateway 预置了近 20 家供应商的接入模板,在同类产品中属于覆盖范围较广的一档:

  • 国际主流:OpenAI、Anthropic、Google Gemini、Azure OpenAI、AWS Bedrock、OpenRouter

  • 国内供应商:DeepSeek、通义千问、智谱 GLM、Kimi(月之暗面)、豆包(火山引擎)、文心一言、混元、MiniMax、零一万物、阶跃星辰

  • 开源模型:Ollama、LM Studio

  • 自定义:任何兼容 OpenAI 协议的第三方服务

自定义类型值得单独说明。开发者常用的各类 API 中转站,只要提供兼容 OpenAI Chat Completions 格式的接口,都可以通过 OpenAI Compatible 渠道类型接入网关。填入中转站的 Base URL 和 Key 即可,与接入官方 API 的操作完全一致。

同一家供应商可以添加多个渠道实例。例如 DeepSeek 同时配置官方直连和两个不同的中转站,三个渠道共同为 DeepSeek 系列模型的请求提供服务,结合后续的流量调度规则形成优先级梯度和冗余保障。

与 Switchyard 需要手写 TOML 配置文件不同,ServBay AI Gateway 的渠道管理在图形界面中完成。选择供应商类型、粘贴 API Key、保存即上线,全程不需要接触命令行或配置文件。

流量调度:优先级、故障转移与热切换

NeMo Switchyard 的流量调度侧重于选哪个模型,通过 Stage Router 的复杂度评估或 LLM Classifier 的分类判断,在不同能力级别的模型之间做选择。

ServBay AI Gateway 的流量调度侧重于走哪条通路。当同一个模型配置了多个渠道(官方 API、中转站、不同区域的订阅账号等)时,确定每次请求走哪个渠道,以及某个渠道出问题时如何自动切换。

ServBay AI Gateway

渠道优先级

每个渠道可以设定优先级权重。网关优先将请求送往高优先级渠道,例如将官方直连 API 设为最高优先级、中转站设为备用、第二中转站设为兜底。

自动故障转移

当某个渠道返回 429(限速)、500(服务错误)或响应超时,网关自动将请求重试到下一个可用渠道。网关内部维护渠道健康状态(正常、降级、不可用),连续异常的渠道被临时移出可用池,恢复后自动重新加入。

整个切换过程对 Claude Code、Cursor 等下游工具完全透明。

渠道热切换

在管理界面中随时启用、禁用渠道或调整优先级,变更实时生效,不需要重启网关服务或修改下游应用配置。

一个实际场景:Anthropic 官方 API 突然限速,在管理界面中把某个 Anthropic 中转站的优先级提到最高,点击保存,所有请求立刻切过去。整个操作耗时较短,Claude Code 那边完全无感知。

虚拟密钥:密钥安全与多项目隔离

Switchyard 通过环境变量传递 API Key,没有提供独立的凭证管理机制。在多项目并行的场景下,密钥如何安全存储、如何按项目隔离使用量,需要自行解决。

ServBay AI Gateway 的虚拟密钥(Virtual Key)就是解决这个问题的:

  • 真实的供应商 API Key 加密存储,不会出现在任何下游工具的配置中

  • 网关为不同项目或工具签发虚拟密钥,每个密钥可绑定独立的权限(可访问哪些模型、可使用哪些渠道)

  • 每个虚拟密钥的调用量、Token 消耗、成本独立统计

# 项目 A 的 Claude Code
export ANTHROPIC_API_KEY="vk-project-a-xxxx"
export ANTHROPIC_BASE_URL="http://127.0.0.1:11580"

# 项目 B 的 Cursor
# API Key: vk-project-b-yyyy
# Base URL: http://127.0.0.1:11580

# 项目 C 的自研应用
# API Key: vk-project-c-zzzz
# Base URL: http://127.0.0.1:11580

虚拟密钥的安全优势在于故障隔离。某个虚拟密钥不慎泄露到 Git 仓库或日志文件中,只需在管理界面吊销该密钥并重新签发,真实的供应商 API Key 完全不受影响,其他项目也不受干扰。

AI Gateway的作用

对于自由职业者或工作室同时服务多个客户的场景,虚拟密钥还解决了成本核算问题,每个客户项目使用独立的虚拟密钥,月底在仪表盘中导出各密钥的用量数据即可。

模型映射:解耦应用层与实际模型

NeMo Switchyard 的路由配置中,一个 Route 注册一个 Model ID,通过路由算法映射到不同的 Target。在其基准测试中,efficient tier 使用 GLM-5.2、frontier tier capacity 使用 Claude Opus 4.8,Stage Router 根据复杂度信号在两者之间分配。

ServBay AI Gateway 的模型映射(Model Mapping)提供了灵活的名称解耦能力,适用面也更广:

模型映射示例:
claude-opus-5   →   glm-5.2
gpt-4o          →   deepseek-v4-pro
my-default      →   claude-sonnet-4
team-fast       →   deepseek-v4-lite
team-strong     →   claude-opus-5

例如在上层应用中指定使用 claude-opus-5,网关在转发时自动将其映射并替换为底层的 glm-5.2。上层应用只管发起请求,代码不改一行,底层模型随时可换。

ServBay AI Gateway的使用方法

那就可以:

  • 模型评测与 A/B 对比:评估 DeepSeek V4 Pro 能否替代 GPT-4o 时,在网关层修改映射目标,用同一套测试用例分别跑两个模型,对比延迟、输出质量和成本。这与 Switchyard 文档中提到的 A/B benchmarking 场景一致。

  • 成本分级:Switchyard 的 Stage Router 通过自动化的复杂度评估实现请求分级。如果不需要自动判断,可以在 ServBay AI Gateway 中通过模型映射手动实现类似效果,为不同任务定义不同的模型标识符,分别映射到不同价位的模型。

  • 团队命名规范:定义 team-fast、team-strong 等内部名称,通过映射关系对应到具体供应商模型。底层模型更替时只需修改映射配置,所有项目代码自动跟随,不需要逐个修改。

协议转换:屏蔽供应商的格式差异

协议翻译是 NeMo Switchyard 的三大核心特性之一。Switchyard 支持 OpenAI Chat Completions、Anthropic Messages 和 OpenAI Responses 之间的互转,使得编程工具可以用自己的原生格式调用任意后端。

AI Gateway的使用方法

ServBay AI Gateway 在协议转换上的覆盖面更广,全面支持了 OpenAI、Anthropic 和 Gemini 三种主流格式的底层转换。

在实际使用中,不论上层协议是 OpenAI、Anthropic 还是 Gemini,下层的应用程序只需无脑调用,完全不需要考虑复杂的协议适配:

  • Claude Code(原生 Anthropic Messages 协议)可以通过网关无缝调用 DeepSeek 或智谱 GLM 的 OpenAI 兼容接口

  • 只支持 OpenAI 协议的工具可以通过网关访问 Anthropic Claude 系列模型

  • Gemini 协议的请求可以被路由到任意 OpenAI 或 Anthropic 后端

开发者和下游应用不需要关心目标供应商用的是哪种协议,网关在中间层自动完成请求体和响应体的格式转换。切换供应商时不需要改动已有代码或工具配置。

用量统计与成本分析

NeMo Switchyard 暴露 Prometheus 指标,需要搭配 Grafana 等外部工具才能实现可视化监控。

ServBay AI Gateway 把统计能力内置在可视化仪表盘中,开箱可用:

指标类别具体内容
请求维度总请求数、成功率、错误分类(路由成功、故障切换、失败)
Token 维度输入 Token、输出 Token、总消耗
成本维度按模型、按渠道、按虚拟密钥分别统计的花费
性能维度平均响应延迟、首 Token 延迟(TTFT)
多模态维度图片生成次数、语音输入与输出消耗

数据支持多维度分组,按日期观察趋势、按模型比较消耗、按虚拟密钥追踪项目级支出。对有预算管控需求的场景,还可以设置预算上限和告警阈值,花费接近上限时自动触发通知。

这些数据便于开发者解答一组具体的问题:上个月在 Anthropic API 上总共花了多少钱?项目 B 比项目 A 多用了多少 Token?哪个模型的首 Token 延迟最低?中转站渠道被故障转移触发了多少次?

能力维度对比:NeMo Switchyard 与 ServBay AI Gateway

能力维度NeMo SwitchyardServBay AI Gateway
协议转换OpenAI / Anthropic / Responses 互转OpenAI / Anthropic / Gemini 互转
路由算法Random / LLM Classifier / Stage Router / Escalation渠道优先级 + 自动故障转移 + 热切换
凭证管理环境变量加密存储 + 虚拟密钥隔离
模型映射Route → Target 配置图形界面直接配置映射关系
用量统计Prometheus 指标(需外部工具)内置可视化仪表盘
供应商覆盖需手动配置 TOML预置近 20 家 + 自定义中转站
操作方式命令行 + TOML 配置文件图形界面
成熟度Pre-alpha(实验性软件)已发布

两者的侧重点不同。Switchyard 的侧重点在于路由算法的深度,Stage Router 的复杂度评估、LLM Classifier 的自动分类,这些能力在 ServBay AI Gateway 中没有直接对应。反过来,ServBay AI Gateway 在渠道管理的广度(预置近 20 家供应商与中转站)、凭证安全(虚拟密钥)、可视化统计等维度上提供了更完整的工程覆盖。

两者不是互斥的选择。对路由算法有深度定制需求的团队可以使用 Switchyard 的路由能力,同时通过 ServBay AI Gateway 完成渠道管理、密钥安全和成本统计等基础设施层面的工作。

典型使用场景

场景一:多工具共享多供应商 API

日常开发中同时使用 Claude Code、Cursor 和 Gemini CLI。不用网关时,三个工具需要分别配置各供应商的 API Key,密钥散落三处。接入 ServBay AI Gateway 后,三个工具都指向同一个端点,各自使用独立的虚拟密钥,真实密钥集中管理,用量分别统计,切换供应商时只需在网关侧操作。

场景二:供应商故障的自动回退

以 DeepSeek API 作为主渠道,同时配置一个 DeepSeek 中转站和一个 OpenAI 兼容渠道作为备用。当 DeepSeek 官方 API 遇到限速或维护时,网关自动将请求切换到中转站渠道,开发工作不中断。

场景三:模型替换评测

团队正在评估用 DeepSeek V4 Pro 替代 GPT-4o 来降低调用成本。在网关中将 gpt-4o 映射到 deepseek-v4-pro,用同一套代码和测试用例跑一周,在仪表盘中对比两个模型在延迟、输出质量、Token 消耗上的差异,评估完毕后决定是否正式切换。

场景四:多客户项目的成本核算

自由职业者同时为三个客户做项目。为每个客户项目创建一个虚拟密钥,月底在仪表盘中导出各密钥的调用量和成本数据,直接作为客户对账的依据。

小结

NVIDIA NeMo Switchyard 的开源把智能模型路由从概念推向了可触摸的工程实践,Stage Router 的复杂度分级路由和协议翻译能力为整个 AI 网关领域提供了有价值的技术参照。

在更完整的工程覆盖维度上,ServBay AI Gateway 给出了相应的答案。渠道管理覆盖近 20 家供应商和各类中转站,流量调度支持优先级、自动故障转移和热切换,虚拟密钥实现了密钥安全与多项目隔离,模型映射让底层模型切换对应用层透明,协议转换屏蔽了 OpenAI、Anthropic、Gemini 之间的格式差异,用量统计提供了按模型、按渠道、按项目的多维度成本追踪。

对于正在面对多供应商 AI API 管理挑战的开发者和团队,这两个项目分别从不同角度提供了解决思路,都值得关注。