OpenRouter：怎麼靠“模型中轉站”做到 10 億美元公司？

作者：張艾拉

今天來聊聊中轉站。

簡單來說，模型中轉站，就是把 OpenAI、Claude、Gemini、DeepSeek 等不同模型接到同一個入口後面，讓開發者用一套接口、一個賬號和統一賬單調用多個模型，並在不同模型或供應商之間做選擇、切換和備用。

當然，對於國內用戶來說，用中轉站更大的原因是想用海外模型，以及更便宜。

這個大家懂得都懂，國內的中轉站我們就不多說，今天主要介紹 OpenRouter。

到 2026 年，OpenRouter 已經融到 1.13 億美元 B 輪，估值已經接近 13 億美元。

也就是說，它已經是一家獨角獸公司。

我們就來分析下，一個“不造模型”的模型中轉站，為什麼能值這麼多錢？

OpenRouter 到底是做什麼？

OpenRouter 官方給自己的定位是：統一的大模型接口。

OpenRouter 現在支持 400 多個模型、70 多個模型供應商。

官網還披露，平臺月處理量已經達到 100 萬億 tokens，全球用戶超過 1000 萬。

在 2026 年 5 月的 B 輪融資公告裡也提到，過去 6 個月，OpenRouter 每週處理量從 5 萬億 tokens 增長到 25 萬億 tokens，並服務 800 多萬開發者。

這些數字說明一件事：

OpenRouter 已經不是一個小眾開發者工具，而是一個很大的 AI 調用入口。

開發者使用它的方式也很簡單。

原來你要分別接 OpenAI、Anthropic、Google、DeepSeek、Mistral、xAI 等模型。

每接一家，都要看文檔、申請 API key、綁定賬單、處理接口差異、看限流規則、做異常處理。

用 OpenRouter 後，開發者可以通過同一個接口調用不同模型。

很多時候，原來使用 OpenAI 接口的代碼，只需要改 base URL、換 API key，再指定模型名稱，就可以通過 OpenRouter 調用別的模型。

這也是它早期增長很快的原因之一：遷移成本低。

為什麼開發者不直接接模型公司？

看起來，開發者完全可以繞過 OpenRouter，直接去模型公司官網開通 API。

但在真實開發裡，這件事沒有那麼簡單。

如果一個 AI 產品只是 demo，只用一個模型就夠了。但只要進入真實業務，就很難只依賴一個模型。

比如一個 AI 寫作工具，可能有幾類不同任務：

• 生成標題，用便宜模型就夠了；
• 寫長文章，需要更強的文本能力；
• 分析資料，需要長上下文模型；
• 做內容審核，需要低成本、高穩定的分類能力；
• 企業客戶要求數據不被留存，就必須選擇符合數據政策的供應商；
• 高峰期模型被限流，還要自動切到備用模型。

這時候，問題就不只是“接一個 API”。

團隊要維護一套完整的模型調用系統：

哪個模型負責哪個任務，哪個模型更便宜，哪個供應商速度更快，哪個供應商失敗率更低，出了問題怎麼切換，賬單怎麼歸因，企業客戶的數據怎麼隔離。

更麻煩的是，模型市場變化太快。

今天 Claude 適合寫代碼，明天 Gemini 的長上下文更有優勢，後天 DeepSeek 或某個開源模型把價格打下來。

模型能力、價格、上下文長度、供應商政策，一直在變。

OpenRouter 的價值也就在這裡。

它不是替開發者寫 AI 應用，而是替開發者管理“用哪個模型、怎麼調用、怎麼兜底、怎麼控成本”這件事。

不只是模型超市，而是模型調度層

如果只把 OpenRouter 理解成“模型超市”，就會低估了它。

模型超市解決的是“這裡有很多模型，你可以挑”。

但 OpenRouter 真正重要的能力，是在模型和供應商之間做調度。

同一個模型，可能由不同供應商提供推理服務。

比如一個開源模型，可以由多家雲服務商或推理服務商託管。不同供應商的價格、速度、穩定性並不一樣。

OpenRouter 的文檔裡有一個能力叫 provider routing，也就是供應商路由。

開發者可以根據價格、延遲、吞吐、供應商順序等條件，讓請求自動走不同供應商。

它還支持 fallback，也就是某個模型或供應商失敗後，系統自動切到備用選項。

對開發者來說，OpenRouter 相當於把“模型選擇”和“故障處理”從業務代碼裡拆出來，交給一個專門的平臺處理。

企業為什麼會需要這層東西？

企業中上 AI，早期的問題通常是“能不能用”，但很快就會變成“怎麼管”。

一個公司內部可能有很多團隊都在用 AI。

市場團隊用來寫內容，客服團隊用來回複用戶，研發團隊用來寫代碼，運營團隊用來分析數據，法務團隊用來處理合同。

如果每個團隊都自己接模型，問題會越來越多：

• 賬單分不清；模型選擇不統一；
• 數據政策不透明；不同團隊重複接入；
• 出了問題沒人知道是哪一路調用；
• 模型供應商發生變化，系統很難統一調整。

OpenRouter 提供的工作區、預算控制、調用日誌、供應商策略、零數據留存路由，都是在解決這些問題。

比如零數據留存。

對很多企業來說，不是所有請求都能隨便發給任何模型供應商。客戶信息、合同內容、醫療數據、金融數據，都可能有嚴格要求。

OpenRouter 文檔裡支持 Zero Data Retention，也就是零數據留存。

開發者可以設置只把請求發給不存儲數據的供應商。這個策略可以按全局、模型組、安全規則或單次請求來執行。

再比如 prompt caching，也就是提示詞緩存。

很多 AI 應用會反覆使用很長的系統提示詞、知識庫內容或上下文。如果每次都重新計算，成本會很高。

OpenRouter 支持通過供應商粘性路由提高緩存命中率，儘量讓後續請求走同一個供應商端點，從而降低重複上下文的成本。

這類功能聽起來不性感，但非常實用，而且 AI 應用的規模越大，省下來的成本越明顯。

OpenRouter 怎麼賺錢？

OpenRouter 的商業模式很清楚：按使用量賺錢。

開發者先購買平臺額度，然後按實際調用的模型和 tokens 付費。

OpenRouter 官方寫得很清楚：

平臺在購買額度時收取 5.5% 的費用，最低 0.8 美元；底層模型供應商的價格按原價轉給用戶，不在模型推理價格上額外加價。

這是一門很典型的“流量過路費”生意。

這個模式的好處是，收入和使用量綁定。

開發者調用越多，平臺收入越高；AI 應用越多、tokens 消耗越大，OpenRouter 的生意就越大。

但它也有一個特點：單次抽成不高，所以必須靠規模。

這也是為什麼 tokens 處理量對 OpenRouter 很重要。

它的核心指標不是註冊用戶數，而是每週、每月有多少 tokens 從它這裡流過。

2025 年，OpenRouter 的年處理量從約 10 萬億 tokens 增長到 100 萬億 tokens 以上。

到了 2026 年，OpenRouter 已經達到約 1.5 千萬億 tokens 的年化處理量。

這就是這門生意的底層邏輯。

只要越來越多 AI 應用跑在多模型系統上，OpenRouter 就能從這些調用裡持續抽取服務費。

為什麼最近增長這麼快？

OpenRouter 的增長，總結下來是吃到了三個變化。

第一個變化，是模型越來越多。

過去做 AI 應用，很多團隊默認先用 OpenAI。現在不一樣了。

Claude、Gemini、DeepSeek、Qwen、Mistral、Llama、Grok，還有大量開源和開放權重模型，都在不同場景裡有優勢。

這不是一個“誰完全替代誰”的市場。

有的模型寫代碼好，有的模型便宜，有的模型長文本強，有的模型速度快，有的模型適合角色扮演，有的模型適合企業文檔，有的模型適合多模態。

模型越多，選擇成本越高；選擇成本越高，中間層就越有價值。

第二個變化，是 AI 應用開始關注成本。

很多產品早期用最強模型，因為先要把效果做出來。

但產品一旦有用戶，模型成本會很快變成問題。

一個客服機器人、AI 搜索產品、代碼助手、內容生成工具，如果所有請求都走最貴模型，毛利很容易被吃掉。

更成熟的做法是，把任務拆開：

• 簡單任務用便宜模型；
• 複雜任務用強模型；
• 高頻任務優先低延遲模型；
• 失敗後切備用模型；
• 涉及敏感數據時，只走符合數據政策的供應商。

這正是 OpenRouter 的使用場景。

它不一定幫你找到“最強模型”，但它可以幫你在效果、價格、速度和穩定性之間做平衡。

第三個變化，是 AI 應用從聊天框走向智能體。

智能體會調用工具、讀取文件、搜索網頁、執行任務，也會連續多輪調用模型。

相比普通聊天，智能體會消耗更多 tokens，也更依賴穩定性。

這對 OpenRouter 是利好。

因為調用次數越多、鏈路越長，開發者越需要路由、備用、日誌、成本控制和供應商管理。

這也是為什麼 OpenRouter 的融資公告裡強調，AI 正在從實驗走向關鍵生產應用和智能體場景。

它的增長，本質上來自 AI 調用量的上升。

這門生意也有風險

OpenRouter 的位置很好，但並不安全。

它夾在模型公司、雲廠商和應用開發者中間。這種位置既有價值，也容易被擠壓。

第一個風險，是大公司可能自建。

對小團隊來說，OpenRouter 很省事。

但對大企業來說，模型路由、權限、日誌、成本管理，也可以自己做，或者交給雲廠商做。

尤其是金融、醫療、政企客戶，可能更在意數據可控和私有化部署。

OpenRouter 要進入這些客戶，不能只靠“模型多”。它必須把權限、審計、數據政策、供應商管理和企業支持做得足夠深。

第二個風險，是雲廠商也會做模型網關。

AWS、Google Cloud、Azure 這些雲平臺，本來就有企業客戶、賬單系統、權限系統和合規能力。

它們完全可以把多模型調用、路由、監控和成本管理做成雲服務的一部分。

OpenRouter 的優勢是開放和中立，模型覆蓋更廣，接入更快。

但云廠商的優勢是客戶關係和企業採購流程，這是一場長期競爭。

第三個風險，是模型供應商關係。

OpenRouter 給模型公司帶來流量，但也讓模型公司離最終開發者遠了一層。

當平臺越來越大，它會掌握更多用戶關係和模型使用數據。

模型供應商既希望獲得分發，也會擔心議價權被削弱。

這類中間層平臺，早期通常被供給方歡迎；規模變大後，關係會更微妙。

第四個風險，是平臺費可能被壓低。

OpenRouter 收 5.5% 平臺費，現在看起來不高。

但如果類似服務越來越多，開發者會比較價格、穩定性、模型覆蓋和企業功能。

如果某些競品願意更低費率，或者雲廠商把這類能力打包進已有服務裡，OpenRouter 就需要證明自己不只是一個“請求轉發器”。

它必須持續提供更好的路由、更強的模型覆蓋、更透明的價格、更穩定的服務和更完整的企業控制。