NVIDIA 的 GitHub 帳號上有一個 repo，到今天為止，簡介欄還是空的。點進去卻有 213 個 commit、35 個 issue、39 個 pull request，還有一份寫得非常完整的說明書。它叫 Switchyard，做的事情是：讓 Claude Code 改用開源模型。
一句話結論：NVIDIA Switchyard 是一個 Rust 寫的 LLM 代理，靠協定翻譯讓 Claude Code、Codex 這類工具繼續講原本的 API，背後卻改由 vLLM、NVIDIA NIM 或 Ollama 上的開源模型回應；它提供 4 種路由算法，但官方明確標註 pre-alpha、不可用於生產環境。
本文資料查核時間：2026 年 8 月 13 日。Switchyard 屬快速迭代中的早期專案，數字與功能可能在你讀到時已經改變。
Switchyard 到底是什麼？
它是一個放在你的 AI 工具和模型中間的中轉站。
問題出在一件很無聊的事：不同廠商的 API 格式不一樣。Claude Code 講的是 Anthropic Messages 格式，Codex 那邊是 OpenAI 的格式，而你自己架在機器上的開源模型，往往只認 OpenAI Chat Completions。三種格式互不相通，所以你想把 Claude Code 接去別的模型，通常就是卡在這裡。
Switchyard 的做法是當翻譯員。官方 README 的原句是：讓 agent 繼續講它的母語 API，而請求由 vLLM、NVIDIA NIM、Ollama 或任何 OpenAI 相容端點來服務。你不用改 Claude Code，也不用改模型，中間那層幫你把話翻過去、再把答案翻回來。
它支援的三種格式是 OpenAI Chat Completions、OpenAI Responses、Anthropic Messages。啟動器目前點名支援三個工具：Claude Code、Codex CLI，以及 OpenClaw。
| 項目 | 實際查核結果 |
|---|---|
| 開發方 | NVIDIA（NVIDIA-NeMo 官方組織帳號） |
| 語言 | Rust（代理與函式庫本體）＋ Python CLI 封裝 |
| 授權 | Apache 2.0 |
| 成熟度 | 官方自述 pre-alpha，標明「實驗性軟體，不供生產環境使用」 |
| 倉庫活躍度 | 213 commits、35 issues、39 pull requests、51 forks |
| 倉庫簡介欄 | 仍是空的（About 顯示 No description, website, or topics provided） |
為什麼是 NVIDIA 來做這件事？
這是整件事最值得想一下的地方。NVIDIA 不賣模型訂閱，也不靠 API 抽成，那它為什麼要花力氣做一個「幫你離開 Claude 模型」的工具？
把 README 支援的後端名單念一次就清楚了：vLLM、NVIDIA NIM、Ollama、任何 OpenAI 相容端點。這幾樣東西的共同點是，它們全部跑在 GPU 上，而且多數是 NVIDIA 的 GPU。NIM 更直接是 NVIDIA 自家的推理服務。
當模型層變成可替換零件，零件之間就會鬥價；而不管哪個零件贏，算力都還是要買。
所以 Switchyard 對 NVIDIA 的價值不在工具本身，而在它降低了「換模型」的摩擦力。今天你被綁在某一家的 API 上，是因為換掉的成本太高；當協定翻譯變成一個裝好就能用的代理，綁定就鬆了。閉源模型的議價能力下降，開源權重的使用門檻下降，兩邊的差距被推向算力這一層。
這條線跟 Meta 開源 Muse Glimmer、阿里 Qwen3.8-Max 承諾放權重 是同一個方向的三件事：模型愈開放，愈需要有人把管道鋪好。NVIDIA 這次自己下場鋪管道。
順帶一提，這個 repo 根目錄裡有 CLAUDE.md、AGENTS.md 和一個 .claude 資料夾。NVIDIA 用 Claude Code 來寫這個讓你可以不用 Claude 模型的工具。
四種路由算法差在哪？
翻譯只是入場券。Switchyard 真正花力氣的地方是路由：同一個代理後面可以掛好幾個模型，由算法決定這一輪該送去哪個。README 列了四種，並且很難得地寫了「什麼時候該用」。
| 算法 | 怎麼決定 | 官方建議使用時機 |
|---|---|---|
| LLM Classifier | 先讓一個模型讀請求內容，判斷該用弱檔還是強檔 | 希望由請求內容本身決定強弱層級 |
| Stage Router | 讀對話裡已經存在的信號，例如工具執行結果、錯誤訊息 | 希望多數輪次不必額外呼叫模型就能分流 |
| Escalation Router | 每一輪都先跑弱檔，再由一個裁判讀那個答案，決定要不要把同一個請求送去強檔 | 希望先用便宜的試，不夠好才升級 |
| Random | 按固定機率分流，不看內容 | 做 A/B 測試、跑基準線、做成本實驗 |
另外還有一個 passthrough 模式：一個模型對一個 ID，不做任何路由判斷。想單純借用翻譯功能、不要分流的話，用這個。
「routing overhead」為什麼值得單獨拿出來看？
這是我認為整份 README 最有價值的一行，而且它藏在功能清單裡，很容易被跳過。
Switchyard 輸出的 Prometheus 指標有五項：請求數、錯誤數、延遲、token 數，還有 routing overhead——路由本身的開銷。
NVIDIA 特地做一個指標去量它，等於承認一件事：決定要用哪個模型，這個決定本身也要花錢和時間。把四種算法放回這個框架看，差別立刻變得很清楚。
- Random：不看內容，路由開銷接近零，但也完全不管這一輪難不難。
- Stage Router：用對話裡本來就有的信號，不必額外呼叫模型，開銷同樣很低。
- LLM Classifier：每一輪多一次模型呼叫。分流準了，但這次呼叫的錢和延遲要從省下來的裡面扣。
- Escalation Router：弱檔一定會先跑一次，加上裁判判斷；命中就很省，沒命中就是弱檔＋裁判＋強檔三段成本，比直接用強檔還慢。
可以帶走的規則：挑分流機制之前，先問「這個分流決定本身，要不要再呼叫一次模型」。省下來的錢必須先扣掉路由自己的成本，剩下的才是真的省到。
這條規則跟 Switchyard 沒有綁定。你在用任何一種模型分流方案、任何 AI gateway，甚至自己在程式裡寫 if-else 判斷該叫哪個模型，都適用。愈聰明的分流器，它自己愈貴——這件事在多數工具的宣傳裡不會出現，因為省下來的數字比較好看。
怎麼估自己的路由帳？
下面這個試算機把上面那條規則變成數字。輸入你自己的實際單價與流量，它會把四種策略的每日成本並排算出來，並且把路由本身吃掉的比例單獨標示。
把弱模型足夠應付的比例往下調到 40％ 左右，你會看到 Escalation 的優勢很快消失——因為沒命中的那些要付三段錢。這就是為什麼官方把「什麼時候該用」寫進表格，而不是叫你全部都選最聰明那個。
三條上手路徑該選哪一條？
README 給了三條路，對應三種完全不同的使用者。先看清楚自己是哪一種，再動手。
路徑一：啟動器（想直接讓 Claude Code 換模型）
最短的一條。先裝 uv，再裝 Switchyard 的 CLI 工具，然後用 switchyard launch claude 這類指令把 coding agent 起起來。要注意的是，你想啟動的那個 agent 本身必須先裝好、而且在 PATH 裡；這條路徑不會幫你裝獨立的伺服器執行檔。
路徑二：獨立伺服器（想給整個團隊或多個工具共用）
裝 Rust 與 Cargo，安裝 switchyard-server，寫一份路由設定檔，先用 dry-run 驗設定，再正式啟動並綁定連接埠。任何講 OpenAI Chat Completions、OpenAI Responses 或 Anthropic Messages 的用戶端都可以連上來。啟動後可以打健康檢查端點確認活著。
路徑三：函式庫（想把路由邏輯嵌進自己的程式）
這條最容易被誤解，但設計得相當克制：switchyard-libsy 自己從不呼叫模型。算法只負責決定該用哪個目標，然後把每一次模型呼叫交還給你。所以它可以塞進你已經有的代理、閘道或 agent runtime，不必接管 HTTP 這一層。
對已經自己寫了一套 agent 執行內核 的人來說，第三條路才是重點：你可以只拿走分流算法，不必為了一個路由決策換掉整個架構。
跟 OmniRoute、pxpipe 這些省錢工具差在哪？
這一類工具站內寫過幾個，很容易混在一起。它們解決的其實不是同一個問題。
| 工具 | 主要解決 | 手段 | 誰做的 |
|---|---|---|---|
| OmniRoute | 帳單太貴 | 聚合免費額度的 AI gateway | 社群專案 |
| pxpipe | token 用太兇 | 壓縮送出去的內容 | 社群專案 |
| Switchyard | 被綁在單一 API 上 | 協定翻譯＋可程式化路由算法 | NVIDIA 官方 |
差別講白一點：前兩者是在同一條路上想辦法少付錢，Switchyard 是把路口打開，讓你可以換一條路走。省錢是換路之後可能拿到的結果，不是它的設計目標——它的三大功能列表裡，一個字都沒提省錢，反而花很多篇幅在講路由算法怎麼組合。
另一個實際差別是身分。社群專案倒了就倒了，但一個由 GPU 廠商掛名、用 Apache 2.0 放出來的協定層，它的存續動機跟你的省錢動機不完全一致——這對你是好事還是壞事，取決於你打算把它放在多關鍵的位置上。
它現在能用嗎？
官方的答案是不能。README 有一個獨立的 Maturity 章節，寫得毫不含糊：pre-alpha 軟體，快速演進中，API 和算法在 v1.0 之前預期會有重大改變，並附一個警告框寫「實驗性軟體，不供生產環境使用」。
我在查核過程中也親眼看到這個「快速演進」的證據。README 主表列的四種算法叫 LLM Classifier、Stage Router、Escalation Router、Random；但 docs 目錄下的入門文件，同一批東西的名字是 Random Routing、LLM Classifier Routing、Cascade Routing，還多出一個 Sticky Routing。連設定檔格式在兩份文件裡都不一樣。
這不是文件寫錯，而是專案正在改名和重構的過程被我抓到了中間態。對讀者的實際意義是：照著任何一篇中文轉述去設定，大機率會失敗。要動手就以 repo 當下的 README 為準，而且預期下個月要重來一次。
關於星數，我這次刻意不寫
這個 repo 這兩天出現在 GitHub trending 上，中文圈開始有人轉述它的星數。我查的時候發現數字對不上：repo 主頁顯示 342 顆星，但有一份同時抓到的頁面顯示 49 顆，而流傳的「單日新增 370 顆」比主頁的總數還大——單日新增不可能超過總量。
三個數字至少有兩個是錯的，我沒辦法在出稿前確定是哪兩個，所以這篇文章不把星數當賣點。真正撐得住的活躍度證據是另外那組：213 個 commit、35 個 issue、39 個 pull request、51 個 fork。這些數字不需要靠榜單快取，也更能說明有人在認真維護。
誰該現在就試，誰該再等？
現在就值得花一小時的人：
- 手上有自架模型（vLLM、NIM、Ollama、LM Studio），一直想接進 Claude Code 但卡在格式。
- 想量化「強弱模型分流到底省多少」，需要 Random 這種固定比例來跑對照組。
- 自己在寫 agent 框架，想直接拿走路由算法，不想連 HTTP 層一起接管。
- 單純想知道 GPU 廠商對這一層的想法——讀 README 就有收穫，不必安裝。
應該再等的人：
- 要放進生產環境。官方自己說了不要，這句話不是客套。
- 只想省錢、不想碰設定檔。那 pxpipe 那類工具的投入產出比高得多。
- 沒有可用的開源模型後端。翻譯層翻好了，另一頭要有東西接。可以先從 在本地跑起一個模型 開始。
- 需要文件穩定。這個階段的文件，這個月抄的設定下個月可能就不對。
常見問題
Switchyard 是免費的嗎？
程式本身是 Apache 2.0 授權的開源軟體，可以免費使用與商用。但它只是中間層，你仍然要為背後實際回應的模型付費——不管那是雲端 API，還是你自己機器上的電費和 GPU。
用了它，Claude Code 就會變便宜嗎？
不一定。它讓你「可以」改接更便宜的模型，省不省取決於你換去哪裡、以及選了哪種路由算法。用 LLM Classifier 這種每輪多呼叫一次的方案，省下來的要先扣掉路由自己的開銷，上面的試算機就是用來算這筆帳的。
它跟一般的 AI gateway 有什麼不同？
多數 gateway 的重點是聚合帳號、統一計費、控管額度。Switchyard 的重點在協定翻譯和可替換的路由算法，而且提供一個純函式庫模式，讓你只拿走決策邏輯、自己保留呼叫模型的動作。
支援哪些 coding agent？
README 的啟動器指令目前點名三個：Claude Code、Codex CLI、OpenClaw。除此之外，任何能講 OpenAI Chat Completions、OpenAI Responses 或 Anthropic Messages 的用戶端，都可以用獨立伺服器模式連上去。
為什麼用 Rust 寫？
它坐在每一個請求的路徑上。代理多花的每一毫秒，使用者都會感覺到。Rust 在這種常駐、高吞吐、延遲敏感的中間層上有優勢，這也是 近年不少 AI 基礎設施改用 Rust 重寫 的原因。
結論
Switchyard 現在還不能拿去幹正事，這點官方講得比誰都清楚。但它值得看，因為它透露了一個不常被明說的判斷：NVIDIA 認為模型層應該是可替換的，並且願意自己出手把替換的成本壓下去。
就算你今天不裝，那條規則也帶得走——挑分流機制之前，先問這個決定本身要不要再呼叫一次模型。NVIDIA 專門做了個指標去量它，這件事本身就說明了答案不會是零。
延伸閱讀：為什麼 AI 畫的圖一看就知道是 AI 畫的、14MB 的模型能做到什麼程度、NVIDIA NOOA 用一個 Python class 當 agent、2.6GB 的手機 agent 實測。
官方資料：Switchyard GitHub repo、官方入門文件、NVIDIA-NeMo 組織帳號。
本文資料查核於 2026 年 8 月 13 日，取自 Switchyard 官方 GitHub repo 與 README。該專案為 pre-alpha 階段，官方明確標示不供生產環境使用，且 API 與算法命名在 v1.0 前預期會有重大變動；文中設定與功能描述可能於你閱讀時已經失效，動手前請以 repo 當下版本為準。試算機為成本結構示意工具，所有數值由使用者自行輸入，不代表任何廠商報價，亦未計入延遲、快取與重試成本。本文不構成投資或採購建議。
發表迴響