Stripe超過 70 億美元收購 OpenRouter，金融科技巨頭為何看中模型路由？

据彭博社報導，支付公司 Stripe 已就收購 AI 模型路由平台 OpenRouter 達成協議，交易金額超過 70 億美元。根據 TechCrunch 的跟進報導，兩家公司尚未公開確認，Stripe 表示不評論傳聞或猜測，OpenRouter 拒絕置評。

OpenRouter 的產品文件顯示，它不訓練自己的模型。它將不同模型接進同一個 API，讓開發者按任務切換，或者按價格、速度和可用性自動挑選。這個常被看作「中間層」的環節，如今被放上了一張極高的潛在價標。

問題也從這裡開始。如果只把 OpenRouter 看成一個模型目錄，報導中的價格下限很難解釋。一種可能的答案，在於它處於每一次調用發生之前的選擇環節。

一張價標，為什麼跳得這麼快

根據《紐約時報》此前報導，OpenRouter 在 B 轮融資後的估值約為 13 億美元。彭博社最新報導的交易價下限，則是超過 70 億美元。兩篇報導相隔不到三個月，且兩個口徑都來自媒體報導，不能直接當成融資回報或確定溢價。

即便只取報導中的下限，價格也已是先前估值的至少 5.4 倍。這為理解報導中的價格提供了一條線索，模型不會永遠按一家供應商、一個價目表被採購，模型之間可替換的能力本身，也可能被賦予了商業價值。

根據《華爾街日報》更早的談判報導，部分知情人士曾認為 OpenRouter 可能賣到約 100 億美元。那是談判階段的可能價格，不能和當前交易下限並排當成兩個確定答案。它留下的線索是，模型之間的可替換性，可能也被賦予了獨立的商業價值。

可以把這層能力類比為支付裡的路由。刷一筆卡時，商戶並不希望自己判斷該走哪家收單機構。它只在乎成功率、速度和成本。模型調用也有類似的選擇，只是被路由的對象從資金變成了 token。

管道裡到底有多少水

估值能講預期，周處理 token 量更接近一條真實的管道。OpenRouter 在 B 轮公告中稱，其周處理 token 量在約六個月內從 5 萬億升至 25 萬億。這個指標不是收入，也不是市場份額，卻能說明有多少 token 的實際負載經過這層基礎設施。

第二張圖並不能證明這筆交易的動機，卻展示了為什麼「模型可替換」可能不再只是開發者偏好。調用量小的時候，工程師手動換模型，麻煩但能忍。請求一旦持續湧進來，價格變動、供應商故障和新模型上線都會變成日常操作，手工維護很快就會變成一份全職工作。

同一份公告裡，OpenRouter 稱自己服務超過 800 萬名開發者，覆蓋 400 多個模型。公司披露的口徑需要保留，但這兩個數字放在一起，足以勾勒出它的位置。它不只是把模型擺在貨架上，也把模型的價格、可用性和替換成本放到了同一個入口前。

對企業來說，模型路由的價值也不在於每一單都選最便宜的模型。它更像採購部給不同任務設了不同預算。簡單的摘要、分類和客服回覆，可以先看成本。代碼、長推理和高風險輸出，再把要求抬高。路由層的工作，是讓這套選擇不必每次從頭做。

能力排序，不等於成本排序

這正是第三張圖要回答的問題。Artificial Analysis 在自己的 Intelligence Index 與任務加權成本口徑中，列出了圖中 7 款模型。它不是任何一家企業的真實帳單，卻足夠用來觀察指數與成本並不總是同步。

圖中被強調的 DeepSeek V4 Flash 與 Claude Sonnet 5，在 Artificial Analysis 的 Intelligence Index 中相差 3 分。這不等於它們在所有任務裡的能力只差 3 分。對需要穩定推理能力的團隊來說，最終選擇還會看可靠性、上下文長度和產品適配等圖外變量。

但在該平台的任務加權成本口徑中，兩者相差約 15.6 倍。這個差距並不代表任何企業的實際帳單，卻為路由層提供了能被量化的價值。模型調用不像買一台機器，它是持續發生的小額支出。每一次差一點，規模起來之後，才會變成一筆看得見的費用。

OpenRouter 的產品文件把這種選擇拆得很直接。用戶可以按價格、吞吐和延遲排序，也可以保留 fallback。換句話說，開發者不必賭一條模型路線永遠有效，而是可以把模型當成一組隨時調度的供給。

這提供了一種解釋，為什麼低價模型會成為這筆交易討論的一部分。它們不是為了證明高價模型不值得用。按任務匹配模型，可能讓路由層從方便開發的工具，變成幫助企業管理推理成本的入口。

Stripe 想接住的是什麼

Stripe 與 OpenRouter 並不是在傳出收購前才認識。據 Stripe 公告，今年年初，Stripe 已為 OpenRouter 提供用量計費、稅務和風控能力。OpenRouter 負責把模型接到一起，Stripe 已經在後面處理它如何被收費。

Stripe 在產品公告中披露，自己也有一套名為 Orchestration 的支付編排產品，用於幫助企業在多家支付服務商之間設置、管理和優化表現。它並沒有公開說會把這套產品接入 OpenRouter。第四張圖只是把兩邊已公開的產品邏輯放在一起看。

兩種產品可以放在同一類問題裡看。選擇變多以後，客戶不想替每個供應商維護一套規則。他們希望把複雜性放到一層接口後面，自己只保留結果。支付路由替商戶決定資金怎麼走，模型路由替應用決定請求怎麼走。

這筆報導真正把人拉回的問題，是誰在調用發生前擁有選擇權。模型路由的價值，或許就藏在這一步。

歡迎加入律動 BlockBeats 官方社群：

Telegram 訂閱群：https://t.me/theblockbeats

Telegram 交流群：https://t.me/BlockBeats_App

Twitter 官方帳號：https://twitter.com/BlockBeatsAsia