NVIDIA Switchyard 让 Claude Code 和开源模型说同一种话
NVIDIA Switchyard：让 Claude Code 和开源模型说同一种话
你有一个 Claude Code 订阅，但你想用 vLLM 部署的开源模型。问题来了：Claude Code 说的是 Anthropic Messages 协议，vLLM 说的是 OpenAI Chat 协议。两个协议不兼容，你不能直接把 Claude Code 指向 vLLM。
传统解法是写一个适配层。但适配层只解决了一半问题——协议翻译了，路由呢？如果你有多个模型（强模型处理复杂推理、弱模型处理简单对话），怎么决定哪个请求给谁？
NVIDIA-NeMo/Switchyard 就是来填这个坑的。Rust 写的 LLM 流量代理，做两件事：协议翻译和多模型路由。NVIDIA 官方出品，昨天刚上 GitHub Trending，+370 stars。
三种协议，一个代理
Switchyard 的核心能力是三种 API 格式互转：
- OpenAI Chat（
/v1/chat/completions） - Anthropic Messages（
/v1/messages） - OpenAI Responses（新的 stateful API）
- Claude Code（说 Anthropic）可以指向 vLLM（说 OpenAI）
- Codex CLI（说 OpenAI Responses）可以指向 NVIDIA NIM
- OpenClaw 可以指向 Ollama
四种路由策略
协议翻译是基础，路由才是 Switchyard 的真正价值。四种策略：
1. Random Routing
随机分发。用于 A/B 测试——把流量均匀分到多个模型，比较指标。
2. LLM Classifier
用一个小模型当分类器，判断当前请求需要强模型还是弱模型。复杂推理给 Claude Opus，简单对话给 Qwen 7B。分类器本身也是一次 LLM 调用，但用最便宜的模型。
这和 Rebucca 的"小模型初筛 + 大模型复核"是同一个原则：分工比统一更有效。不是所有请求都需要最强模型，用便宜的模型做分流，贵的模型只处理真正复杂的请求。
3. Stage Router
最有趣的策略。不调用额外模型，而是从对话已有的信号里推断该用什么模型。
什么信号？
- 上一轮是 tool call → 可能需要强模型处理工具结果
- 上一轮出错了 → 升级到强模型重试
- 对话刚开始 → 用弱模型快速响应
- 用户明确要求复杂任务 → 升级
4. Custom Algorithm
Switchyard 是一个 Rust 库（switchyard-libsy），你可以写自己的路由算法。它不自己调用模型——算法决定路由后，把调用交回给你的代码。这意味着它可以嵌入到任何现有代理、网关、agent runtime 里，不需要接管 HTTP 栈。
三种使用方式
Switchyard 设计了三种部署路径：
Launcher Path（最简单）
uv tool install --python 3.10 "nemo-switchyard[cli]"
switchyard launch claude --model switchyard
switchyard launch codex --model switchyard
switchyard launch openclaw --model switchyard
一行命令启动 agent，自动走 Switchyard 路由。默认连 OpenRouter，也可以用自己的 TOML 配置。
Server Path（独立代理）
cargo install --locked switchyard-server
switchyard-server --config routes.toml --host 127.0.0.1 --port 4000
独立运行的 Rust 二进制，作为公司内部的 LLM 网关。Prometheus metrics 开箱即用，覆盖请求数、错误率、延迟、token 消耗、路由开销。
Library Path（嵌入式）
[dependencies]
switchyard-libsy = { git = "https://github.com/NVIDIA-NeMo/Switchyard.git" }
把路由算法嵌入到你自己的 Rust 应用里。适合已经有网关、只想加路由逻辑的场景。
为什么是 Rust
这个问题值得回答。LLM 代理是 I/O 密集型工作，按理说 Go 也很合适（Caddy、Traefik 都是 Go 写的）。Switchyard 选 Rust 有两个理由：
1. 延迟敏感：LLM 请求的端到端延迟本来就高（几秒到几十秒），代理层不能再加几百毫秒。Rust 的零成本抽象和异步运行时（tokio）能把代理开销压到最低。 2. 类型安全：协议翻译最容易出 bug——字段遗漏、类型不匹配、空值处理。Rust 的类型系统在编译期就能抓住这些问题。
Prometheus metrics 也是 Rust 生态的强项——prometheus crate 性能极好，高并发下不会成为瓶颈。
和 NVIDIA LLM Router 的关系
Switchyard 不是从零开始的。它是 NVIDIA 之前 LLM Router 项目的继任者。根据 NVIDIA 官方博客，主要改进：
- 从 Python 改写为 Rust（性能提升）
- 新增 Anthropic Messages 协议支持
- 新增 Stage Router 策略（旧版只有 LLM Classifier）
- 提供独立二进制 + 库两种部署方式
数据说话
- +370 stars today，GitHub Trending 上榜
- Rust 实现，tokio 异步运行时
- 3 种协议互转：OpenAI Chat / Anthropic Messages / OpenAI Responses
- 4 种路由策略：Random / LLM Classifier / Stage Router / Custom
- 3 种部署方式：Launcher / Server / Library
- Prometheus metrics 开箱即用
- pre-alpha，API 还在快速变化
一个更深的观察
Switchyard 解决的问题，本质是 AI 基础设施的"协议碎片化"。
过去一年，LLM API 生态分裂成了三个阵营：
- OpenAI 阵营：Chat Completions + 新的 Responses API
- Anthropic 阵营：Messages API
- 开源阵营：OpenAI-compatible（vLLM、Ollama、NIM 都兼容 OpenAI Chat）
Switchyard 做的是在协议碎片化之上加一个翻译层。这和互联网早期的 Babel Fish、Google Translate 做的事一样——大家语言不通，翻译官来搭桥。
但更深一层：Switchyard 不只是翻译，还做路由。这意味着它不只是"让 Claude Code 能用 vLLM"，是"让 Claude Code 在不同模型之间智能切换"。这是模型组合的基础设施——未来你不会只用一个模型，你会用一组模型，Switchyard 就是管理这组模型的调度器。
和 colibrì 的"1300 行 C 代码跑 7440 亿参数"是同一个精神：基础设施应该轻量、可组合、不锁死用户。NVIDIA 用 Rust 写这个代理，而不是用 Python 加一堆依赖，说明他们认真对待"基础设施"这四个字。
---
仓库：NVIDIA-NeMo/Switchyard NVIDIA 博客：Route AI Agent Workloads Across Models with NVIDIA NeMo Switchyard 语言：Rust 今日增长：+370 stars 状态：pre-alpha，API 可能变化