多供應商路由不是問題——它就是你的架構

利益揭露:我是 DigitalOcean 的 Solutions Architect,所以文中提到 DigitalOcean 產品時,是「業內人的觀點」而非中立第三方——這些地方我都會明確標示,其餘分析則盡量保持廠商中立。以下皆為個人觀點。

前言

每一家推論供應商的銷售劇本裡，都有一個段落在說明你為什麼應該把業務整合到他們身上。常見的賣點包括：擔心被競爭對手綁定（lock-in）、管理多組 API 金鑰所帶來的營運複雜度，以及單一帳務關係的便利性。

劇本沒說的是：最成熟的買家——那些大規模運行 AI 的團隊，那些真正懂行的人——幾乎清一色都是「刻意」採用多供應商設計。他們把批次工作導向最便宜的端點、把即時查詢導向最快的端點、把小眾模型導向擁有它的供應商，並把對合規敏感的工作負載導向具備認證的供應商。他們是刻意這麼做的，不是偶然。

面對這個現實，正確的回應不是去抗拒它，而是要在其中成為有用的一環。

本文涵蓋多供應商路由在 2026 年如何運作、團隊用來實作它的工具，以及推論供應商的第一方路由（first-party routing）在什麼地方改變了整個盤算。

重點摘要

• 對認真的團隊來說，多供應商路由是預設的架構——是要去設計的對象，而不是要去對抗的問題。
• 驅動因素是結構性的：沒有任何供應商擁有所有模型；API 正常運行時間（uptime，約 99.1–99.8%）低於傳統基礎設施的水準，因此故障轉移（failover）是必備的；同一個模型在不同供應商之間的價格最多相差 6×。
• 依約束條件路由：批次 → 最便宜、即時聊天 → 最低 TTFT、小眾 → 最廣的目錄、合規 → 具認證的地區，再加上一條後備路徑。
• 為 goodput（有效吞吐，按 SLO 完成且正確的請求） 進行最佳化——而不是為原始的 tokens/秒或最便宜的 token。
• 與 OpenAI 相容的 API 讓切換供應商只是改一個 base-URL，所以綁定效應很弱；第一方路由（DO Inference Router，「最高可達 67%」）的差異化在於營運層面，而不是把你困住。
• 對歐盟要誠實：今天所有供應商的無伺服器（serverless）推論都僅限美國，因此歐盟資料落地（data residency）目前意味著在歐盟 GPU 基礎設施上使用專用（dedicated）推論。

2026 年的現實：多供應商是預設值

在運行嚴肅正式環境工作負載的團隊之間，「全押在單一推論供應商上」愈來愈罕見。驅動因素是結構性的：

1. 沒有單一供應商擁有完整目錄

模型版圖已經碎片化。前沿封閉模型（Claude、GPT-5、Gemini）必須直接向各自的供應商取得。開放權重模型則跑在 Together、Fireworks、Groq、Replicate，或你自己的基礎設施上。特化模型——醫療編碼、法律推理、程式碼專用——往往落在精品型的供應商手上。沒有任何單一供應商能以最佳效能與價格同時提供以上全部。

2. 可用性缺口讓故障轉移有其正當性

傳統雲端基礎設施的 SLA 跑在 99.9% 以上。LLM API 的可用性達不到這個水準。某個第三方監測機構（TokenMix 的 30 天滾動數據）回報主要供應商落在約 99.1–99.8% 的區間，表現最差者約為 97.2%（大約每月 20 小時的停機時間）。請把任何單一這類數字當作方向性參考，而非權威結論——供應商會發佈自己的狀態頁，而你實際量測到的可用性取決於你的地區、模型與流量型態。但結構性的論點在每個來源都成立：正式環境的 LLM API 都低於你對成熟雲端基礎設施所期待的 99.9% 以上。對於 AI 層處於關鍵路徑上的應用而言，這就要求一套故障轉移策略——請對照每個候選供應商的狀態頁去驗證其真實數字，而不是依賴任何彙整平台的表格。

這不是針對任何特定供應商的批評——LLM 推論要做到可靠，本來就比一台靜態檔案伺服器難得多。這是這項技術在目前成熟度下的結構性特性。如果你的應用無法容忍單一供應商每月 5 小時的停機時間，你就需要不止一家。

3. 價差讓路由在經濟上合理

同一個模型在不同供應商之間，在 2026 年第二季價格最多相差 6×。Llama 4 70B 在 Together 批次層級是每百萬 token 0.65 美元，而在列出的最貴價格則是每百萬 token 4.20 美元。如果你在運行大量批次工作負載，卻不把它們導向最便宜的供應商，那麼停留在單一供應商就等於把真金白銀留在桌上。

而那還只是同一個模型在各供應商之間的差距。跨模型層級的價差遠大得多——這正是路由經濟學的另一半。以下是單一供應商上的即時價格階梯（DigitalOcean 無伺服器，每百萬 token，2026 年 6 月擷取）：

在最便宜與最昂貴的層級之間，這是輸入 60× 的價差、輸出超過 100× 的價差——還只是在一家供應商上，你甚至都還沒開始跨供應商比較。整個路由的理由就建立在這個落差上：一個 0.25 美元模型就能正確處理的任務，如果你反射性地把它送到最頂層，成本就會貴上 60×。路由不過就是「不去這麼做」的紀律。

路由分類法

並非所有推論流量都有相同的需求。一套理性的路由架構會依流量的實際約束條件加以分類，並據此進行路由：

把這想成一個貨運物流作業。一個經驗老到的貨主不會所有東西都用同一家承運商——他們用隔夜空運處理急件包裹、用陸路貨運處理大宗貨物、用區域型承運商處理最後一哩配送，並讓跨境的國際選項待命以因應跨國需求。智慧之處在於把貨物的需求對應到承運商的強項，而不是因為「比較簡單」就只用一家承運商。

那些把所有推論流量一視同仁的團隊——把每件事都透過單一供應商、單一層級導送——就等於是替所有東西都付隔夜空運的費率，連那些根本不急的貨物也一樣。

團隊早已在用的工具

在討論第一方路由之前，值得誠實面對生態系統已經提供了什麼。你的客戶知道這些工具，而且可能早就在用了。

LiteLLM 是一套開源的 Python 程式庫，也是可自行託管的代理伺服器（proxy），透過與 OpenAI 相容的介面對外提供 100 多家 LLM 供應商。它處理供應商抽象化、後備邏輯、成本追蹤與速率限制。取捨在於：它是自行託管（營運負擔），並會增加延遲開銷。2026 年 3 月的一起供應鏈事件引發了對相依套件安全性的疑慮。但對於擁有 Python 基礎設施、又有能力自行託管的團隊來說，它是一個經過驗證、社群龐大的選項。

OpenRouter 是一項受管理的路由服務，在單一 API 與統一帳務背後集合了來自數十家供應商的 300 多個模型。它接受一個依優先順序排列的模型陣列，並在主要模型失效、被速率限制或拒絕時自動嘗試下一個。它無法自行託管，但完全卸下了營運負擔。取捨在於：你在關鍵路徑上又多加了一個受管理的相依項，而且你對路由決策的可見度比自行託管的方案要低。

Portkey、Bifrost 與其他工具佔據著類似的位置——都是受管理的閘道（gateway），在可觀測性、成本追蹤與企業功能上各有偏重。

重點在於：**這些工具確實存在、確實能用，而且成熟的買家早已評估過它們。**對一個已經整合了 OpenRouter 的客戶說「你不需要 OpenRouter，因為你直接用我們就好」，並不是有說服力的論點。更好的對話是：第一方路由能提供第三方路由所沒有的什麼？

第一方路由：DigitalOcean Inference Router

DigitalOcean 的 Inference Router 是一個內建於推論平台本身的第一方路由層——不是一個連接到多家供應商的第三方閘道，而是一項原生能力。在受管理的推論平台之中，這種第一方路由仍不常見；如今大多數的多供應商路由都是透過疊加在上層的第三方閘道來完成。

這在實務上意味著：

• 沒有額外的延遲跳轉——路由決策發生在平台內部，而不是透過一個會多增加一次網路往返的外部代理
• 整合帳務——不需要與閘道供應商建立另一套帳務關係；路由是同一個帳戶的一部分
• 推論成本最高可降低 67%（根據 DigitalOcean），透過智慧的跨模型路由達成——路由器會在模型層級之間移動請求（例如，把簡單查詢導向較小、較便宜的模型，並把複雜查詢升級到較大的模型），全程自動，無需自訂路由程式碼。Workato 的 Research Lab 處理超過 1 兆筆自動化工作負載，回報首字元時間（TTFT）加快 77%、端到端延遲降低 79%、推論成本降低 67%
• 可觀測性集中在一處——路由決策、延遲、成本與快取命中率，都和你其餘的基礎設施顯示在同一個儀表板上

差異化並不在於 DO 路由比 LiteLLM 更會路由——兩者都會路由請求。差異化在於營運層面：第一方路由消除了一個相依項、縮小了整合面，並讓路由邏輯保留在推論實際運行的平台之內。

Goodput 框架：你真正在最佳化的是什麼

大多數團隊用每秒 token 數或每秒請求數來思考推論效能。這些指標很重要，但並不完整。

正確的指標是 goodput：在目標 SLO 內完成、且回傳正確、可用回應的請求。一個每秒處理 1,000 筆請求、卻有 15% 逾時、另有 10% 回傳幻覺的系統，其 goodput 是 750 筆「在 SLO 內且正確」的回應——而不是 1,000。

這個重新框定改變了你思考路由的方式：

• 原始吞吐量（tokens/秒）是供應商指標，對容量規劃有用
• TTFT 是使用者體驗指標，對同步應用至關重要
• 在目標延遲下每筆正確回應的成本才是商業指標

當你為 goodput 而路由時，決策矩陣看起來就不一樣了。Groq 的 LPU 在 Llama 4 70B 的輸出解碼上達到 750 tokens/秒——令人印象深刻的吞吐量數字。但如果你的 SLO 是端到端 500ms 延遲，而 Groq 的佇列深度偶爾造成 800ms 的回應，那麼 Groq 的吞吐量數字幫不了你。為 goodput 而路由，不要為原始規格而路由。

OpenAI 相容性因素：綁定效應比看起來更弱

多供應商路由在 2026 年之所以在結構上很容易，有一個原因：幾乎每一家推論供應商都對外提供與 OpenAI 相容的 API。在大多數情況下，切換供應商就是改一個 base URL 與一組 API 金鑰。就這樣。

這讓供應商綁定的論點比三年前弱了非常多。一個說「你加第二家供應商會有整合的痛苦」的供應商，描述的是一個自 2023 年以來就不再成立的現實。供應商之間的正面對決（bake-off）成本很低。遷移不是一個六個月的專案——而是一天的工作。

由此可得的推論是：唯一可持續的差異化形式，是在你「實際的」工作負載上可量測地更好的效能，而不是讓切換變痛苦的摩擦力。

EMEA 的機會

在主要的純推論（pure-play）供應商之中，存在一個有意義的地理缺口。**Together AI、Fireworks AI 與 Groq 都只從美國的資料中心運行無伺服器推論。**對於有 GDPR 要求的歐洲客戶來說，這不是偏好問題——而是合規的阻斷因素。在許多情境下，個人資料在法律上不得於歐盟／EEA 之外處理。

DigitalOcean 在阿姆斯特丹（Amsterdam）營運歐盟 GPU 基礎設施（NVIDIA 裸機 GPU），這讓「資料落地於歐盟」的推論今天就可透過在該基礎設施上進行專用／自行管理的部署來實現。

不過要對目前的狀態說清楚：**目前沒有任何供應商——包括 DigitalOcean——在歐盟地區提供無伺服器推論端點。**無伺服器推論目前全面都僅限美國。所以對於今天一個對 GDPR 敏感的歐洲工作負載而言，務實的路徑是在歐盟 GPU 基礎設施上做專用推論，而非無伺服器。「歐盟的無伺服器」這個缺口是一個尚無人填補的真實機會——值得誠實地把它點名為一個機會，而不是宣稱為一項已交付的能力。

這值得在歐洲企業的對話中明確點出。問題不是「你偏好歐盟資料落地嗎？」——而是「你的法務團隊能核准在歐盟之外處理資料嗎？」對相當一部分客戶而言，答案是不能，而能服務他們的供應商選項相當有限。

為韌性而設計：如果你需要 99.9% 以上

如果你的可用性要求超過任何單一推論供應商所能交付的水準——而 99.9% 以上高於大多數供應商正式環境 API 的量測表現——那麼後備架構就不是選配項。

一個最小化的韌性架構：

1. 主要供應商——你主力工作負載類別中表現最佳的選項
2. 次要供應商——相同模型或同等品質、不同供應商
3. 故障轉移邏輯——在主要供應商逾時、錯誤率達門檻或被速率限制時，自動路由到次要供應商
4. 斷路器（circuit breaker）——防止重試風暴放大局部的中斷
5. 可觀測性——觸發故障轉移時發出警報，並追蹤你已在次要供應商上運行多久

先前的路由分類法仍然適用：用主要供應商處理標準流量、用次要供應商作為故障轉移，並把不同類型的工作負載導向其適當的層級。架構不需要複雜——一個設定得當、含兩個供應商端點的 LiteLLM 或 Inference Router 配置，就能涵蓋大多數情況。

關鍵原則是：**幫客戶設計這套架構，而不是去反駁它。**一個建立了韌性多供應商架構、並把 DO 用作主力工作負載類別主要端點的客戶，會比一個在壓力下勉強採用單一供應商、出事時就流失的客戶，帶來更好的長期關係。

DO 在多供應商世界中的定位

策略定位很直接：

DO 想成為你的主要推論供應商與你的路由控制平面（control plane）——而不是你唯一的供應商。

DO 作為主要供應商的論據：

• 全端整合（推論 + 運算 + 向量資料庫 + 儲存），TCO 比多雲方案低 20–40%，根據 Deploy 2026 分析
• 第一方路由層，無須第三方相依即可處理模型的正確尺寸調整
• 透過在阿姆斯特丹 GPU 基礎設施上的專用推論，達成歐盟資料落地（包含 DO 在內，目前尚無任何供應商提供「歐盟的無伺服器」）
• 單一 VPC、單一帳務關係、整合的可觀測性

對 DO 並非完整答案之處的誠實承認：

• 需要在第零天就用上絕對最新前沿模型的團隊，會直接向 Anthropic／OpenAI／Google 取得
• 需要 Together AI 那種開源模型目錄深度的團隊，在 DO 上找不到同樣的廣度
• 微調（fine-tuning）與 LoRA 工作流需要不同的供應商（Together、Fireworks、Replicate）

路由架構是這樣的：DO 處理主力工作負載、批次處理與 EMEA 合規需求；專家型供應商則透過路由層處理它們各自的利基。這不是讓步——而是一套誠實的架構，它比一個不符合客戶實際需求的單一供應商強制令，更能服務客戶。

總結

多供應商路由不是對推論供應商的威脅——它是認真的團隊所建立的架構。原因是結構性的：沒有單一供應商擁有所有模型、可用性缺口要求故障轉移，而 6× 的價差讓路由在經濟上合理。

在實務上有效的路由分類法：

• 批次／離線 → 最便宜的供應商
• 即時聊天 → 最低 TTFT 的供應商
• 小眾模型 → 目錄最廣的供應商
• 對合規敏感 → 在正確地區具認證的供應商
• 後備 → 主要供應商失效時的次要供應商

工具早已存在（LiteLLM、OpenRouter、Portkey），成熟的買家也早已知道它們。第一方路由的差異化在於營運層面：沒有延遲跳轉、整合的帳務與可觀測性、路由邏輯就活在平台之內。

正確的框架是 goodput——在 SLO 內完成且輸出正確的請求——而不是原始的每秒 token 數。為「在目標延遲下每筆正確答案的成本」而路由，而不是為最便宜的 token。

EMEA 的定位是真實的：所有供應商的無伺服器推論都僅限美國，因此對 GDPR 敏感的歐洲客戶來說，今天的歐盟落地意味著在歐盟 GPU 基礎設施上的專用推論（DO 在阿姆斯特丹就有），而非無伺服器。「歐盟的無伺服器」這個缺口至今無人填補——這是一個值得誠實點名的機會，而不是一項可宣稱的能力。

目標是：成為主力工作負載類別的主要供應商、作為跨供應商路由的控制平面運作，並對哪些工作負載屬於別處保持誠實。那才是能長久的關係。

這是第 5 篇——5 篇系列文章「正式環境中的 LLM 推論」的最後一篇。第 1 篇 涵蓋 LLM API 成本的隱藏結構。第 2 篇 涵蓋模型選擇方法論。第 3 篇 深入探討提示快取（prompt caching）。第 4 篇 檢視完整 AI 技術堆疊的總體擁有成本。

參考資料

• 2026 年最佳 LLM API 供應商 — TokenMix
• AI 推論供應商：2026 年第二季定價矩陣 — Digital Applied
• DigitalOcean 推論定價 — DigitalOcean（模型層級價格階梯的來源）
• OpenRouter vs LiteLLM vs Portkey：2026 年最佳 LLM 閘道 — ToolHalla
• Groq vs Together AI vs Fireworks AI — ToolHalla
• 比較託管開源 LLM 的 API 供應商 — Medium
• LLM 推論的三難困境 — DigitalOcean
• AI 正常運行時間 SLA：為什麼你的業務需要多模型後備策略 — Universal.cloud

系列文章 — Inference in Production

• 系列前言 — Inference in Production：五篇實戰指南
• 第 1 篇 — 為什麼你的 LLM 帳單是預期的 3 倍
• 第 2 篇 — 為你的使用情境選擇正確的模型
• 第 3 篇 — 提示快取實戰——從 7% 到 74% 命中率
• 第 4 篇 — 全端 AI 應用程式的真實 TCO
• 第 5 篇 — 多供應商路由不是問題——它就是你的架構 （你正在這裡）