下週要向主管說明 AI API 帳單為什麼翻倍時，最危險的回答是「換成便宜模型就好」。一個客服 agent 看起來只是回覆一句話，背後可能先分類、查知識庫、產生草稿、檢查格式、重試兩次，再把結果交給高階模型覆核。若每一步都走最貴模型，毛利會被 token 吃掉；若所有步驟都改走低價模型，資料流向、品質與責任又可能失控。
Coinbase CEO Brian Armstrong 在 2026 年 6 月 28 日公開說，Coinbase 正在用更好的預設模型、任務路由與快取，讓 token 使用持續成長時，AI 支出接近減半。他提到的重點包括：預設導向 GLM 5.2、Kimi 2.7 等開權重模型、依任務與價格路由請求、把 LibreChat 的快取命中率從 5% 拉到 60%，以及讓工程師看得見自己的 AI 使用量。
這則消息更適合被讀成 AI 成本治理案例，而非「現在都該改用某個中國模型」。團隊可以把成本管理拆成一條可檢查的路徑：哪些任務可以便宜化、哪些任務需要高階模型、哪些資料不能送到特定 provider、哪些結果必須保留人工覆核。若目前只是偶爾用聊天工具，可以先整理常用模板與成本試算；若產品已經把 AI 放進客服、銷售、文件、程式碼或內部 agent，就該把模型路由當成營運問題處理。
Coinbase 這次提供了什麼新訊號
Armstrong 的公開貼文屬於公司高層的第一手說法，能用來判斷 Coinbase 正在怎麼管理內部 AI 成本，但不能直接當成每家公司都能複製的績效保證。他說 Coinbase 沒有靠使用上限和花費警示壓低支出，而是調整預設、路由、快取與可見度。
預設模型的部分，Coinbase 仍允許工程師選擇合適模型，但正在實驗把預設導向 GLM 5.2、Kimi 2.7 等開權重模型。Armstrong 也說，91% 員工原本沒有碰到舊的使用上限，因此與其降低 caps 製造更多警示，不如把大量低風險請求導向更便宜的預設。
路由的部分，Coinbase 在自家 harness 裡預處理 prompts，依任務、快取命中機會與模型價格選擇模型。相較於單純「多接幾家 API」，這種做法把模型選擇集中到 gateway 或 routing layer。若某個步驟只需要格式整理，沒有必要用最高階 reasoning model；若某個步驟涉及規劃、程式碼 review 或金流風險，就不能只看單次呼叫價格。
快取和上下文管理則是很多團隊漏掉的成本來源。Armstrong 提到 Coinbase 的 LibreChat 在正確實作後，快取命中率從 5% 提高到 60%。他也提醒工程師切換任務時開新 session、縮小檔案 context、移除不用的工具。這些做法聽起來不像新模型新聞，卻常比換模型更快影響帳單。
模型路由的核心是取捨管理
OpenRouter 會在 2026 年受到投資人與開發者注意，原因就在這裡。Business Insider 先前報導，OpenRouter、Concentrate AI 這類 AI routing startup 正被用來處理 sky-high AI bills。OpenRouter 官方首頁也把自己定位成「The Unified Interface For LLMs」，主打單一 API、數百個模型、多家 providers、價格、uptime 與 OpenAI-compatible API。
模型路由的真正任務，是把每個 AI 請求放回成本、品質、延遲、資料政策與可用性的取捨裡。它可以透過 OpenRouter、Vercel AI Gateway、Cloudflare AI Gateway 這類平台完成，也可以先由團隊自建一層簡單 wrapper。工具只是實作方式，核心在於避免產品裡每個 endpoint 各自決定模型。
如果產品還在 demo 階段，直接呼叫單一模型最快。進入 production 後，成本會從幾個方向放大：agent step 增加、重試增加、長上下文變多、使用者把同一任務反覆提交、客服或內容工作流進入大量使用。這時若沒有 routing 和 logging，團隊很難知道是哪個功能吃掉成本，也很難判斷降級後品質有沒有變差。
可以把模型路由想成 AI 產品的成本調度層。雲端工程不會把所有 workload 都丟到最貴機器；AI 產品也不該把分類、格式整理、摘要、草稿、深度推理和高風險決策都丟給同一個模型。
先做任務風險分級，再談模型品牌
模型品牌很容易吸引注意，但落地時更該先拆任務。以下分級可以先用在客服、內部文件、研究、程式碼或銷售 agent：
| 任務層級 | 適合的模型策略 | 必須保留的檢查 |
|---|---|---|
| 低風險大量任務 | 便宜快速模型或快取優先 | 抽樣檢查、格式驗證、成本上限 |
| 中風險可修正任務 | 中階模型，必要時升級高階模型 | 來源引用、輸出一致性、使用者回報 |
| 高風險決策任務 | 高階模型加驗證，必要時人工覆核 | audit log、資料政策、責任人 |
| 敏感資料任務 | 只允許符合政策的 provider 或私有部署 | provider allowlist、區域限制、存取紀錄 |
這張表用來建立共同語言，不必把所有任務永久固定在某個模型。客服分類、標籤整理、短摘要可以便宜化；報價承諾、法務文字、資安分析、財務解讀、程式碼部署建議就需要更保守的策略。若產品支援中國模型、開權重模型或低價 provider，也要把資料政策、客戶合約與 fallback 行為寫清楚。
GLM-5.2 這類長上下文開權重模型，確實會讓成本與任務分配出現更多選項；但模型來源、部署方式、資料保留政策與品質波動，都應該和價格一起評估。低價模型能處理部分工作，仍要搭配任務邊界與覆核規則。
若把 GLM 5.2、Kimi 2.7 這類開權重模型放進預設路由，不能只看單次 API 價格；至少要檢查參數或 active parameters、授權與商用限制、部署位置、資料保留政策、context window 與品質評估。這些條件會決定它適合當大量草稿模型、內部 routing 候選，還是只能放在小流量試點裡。
快取、上下文瘦身與可見度要一起做
很多團隊把模型路由想成一個演算法：輸入請求，輸出最佳模型。實務上，成本常常先被上下文和快取打爆。把整個 repo、整份合約或整段聊天歷史塞進每一次請求，會讓再便宜的模型也變貴；快取沒有命中，則會讓重複工作一再付費。
比較可靠的最小版本，是先把模型呼叫集中到一個 wrapper，至少記錄模型、功能、使用者或客戶、輸入輸出 tokens、估算成本、延遲、錯誤碼、fallback 次數與快取命中。這些資料不用一開始就做成華麗儀表板，但要能回答兩個問題：哪個功能最貴？哪個功能降級後品質還能接受？
接著再把 prompt 和 context 改成可管理資產。固定模板可以快取；跨任務切換時不要沿用舊 session；檔案 context 只放需要的片段；工具權限不用就關掉。這些做法不會出現在模型排行榜上，卻會直接影響每月帳單。
若團隊還沒有成本基準，可以先用 AI API 月費試算器 把呼叫量、平均輸入輸出長度、快取折扣與模型價格放進同一張表。試算提供討論基準，能避免在沒有數字的情況下爭論「該不該換模型」。
什麼時候需要 OpenRouter、AI Gateway 或自建路由
多數團隊不必立刻導入完整 LLM gateway。若產品只有少量內部使用，先集中 API wrapper、記錄成本、建立任務分級就夠。當以下情況出現時，再評估平台化路由：每月 API 費用開始影響毛利、同一產品要支援多家模型、客戶要求資料流向說明、供應商限流會影響 SLA、或 agent 開始連續執行多步任務。
OpenRouter 適合想快速接觸大量模型、比較價格與 provider 的團隊；Vercel AI Gateway 適合已經在 Vercel 與 AI SDK 生態裡的產品；Cloudflare AI Gateway 更適合把網路層、觀測、成本與企業治理放在一起考慮的架構。若公司有嚴格資料政策或特殊模型部署需求，自建 routing layer 也可能是必要選項。
選型時除了模型數量，更該問的是：是否能記錄每次請求送到哪裡？是否支援 provider allowlist？fallback 會不會改變品質或資料政策？成本是否能切到功能、客戶或 agent step？模型切換後有沒有 eval set 可以驗證？這些問題會決定 routing 是省錢工具，還是新的黑盒子。
省下成本後，責任仍要留在流程裡
模型路由最容易犯的錯，是把「更便宜」誤當成「更成熟」。如果客服 agent 為了省錢把敏感客訴送到不合政策的 provider，帳單可能下降，風險卻轉成合規與信任成本。如果程式碼 review 因為降級漏掉高風險 diff，真正的成本會出現在事故之後。
比較健康的做法，是把每一次 routing 決策都留下一點可追蹤資料：為什麼選這個模型、是否觸發 fallback、是否命中快取、輸出是否通過驗證、誰負責最後決定。高風險任務可以用抽樣、閾值或人工覆核控管；團隊仍需要知道 AI 的建議從哪裡來，以及哪些步驟不能自動降級。
這也是 企業 AI ROI 與 token 成本 要一起看的原因。AI 支出下降如果靠的是降低品質、遮蔽資料流向或把覆核責任推給使用者，ROI 只是延後爆雷。成本治理的目標，是讓便宜模型做適合它的工作，讓高階模型留給值得付費的工作，並讓責任鏈保持可見。
這週可以先做的三個動作
先把所有模型呼叫集中管理。即使暫時還是單一 provider，也不要讓各功能直接散接官方 SDK。集中 wrapper 後，模型、成本、延遲、錯誤與 fallback 才能被觀測。
接著挑出前 10 個最常用或最貴的 AI 任務，標成低風險、中風險、高風險與敏感資料。這一步會讓團隊看見哪些地方能先用便宜模型或快取，哪些地方必須維持高階模型與人工覆核。
最後建立一組小型 eval set。每次更換預設模型、加入新 provider 或調整 routing 規則，都用固定題目檢查品質、格式、引用、錯誤率與延遲。若沒有 eval，降成本很容易變成看不見的品質折損。
低使用量團隊可以先整理常用 prompt、模板、文件片段與成本試算。已經把 AI 放進產品流程的團隊，則應該把模型路由視為產品營運的一部分，避免只靠工程師臨時調參。
什麼時候該從單一 API 改成模型路由？
模型路由不是每個團隊都需要。它真正有價值的時刻，是你的 AI 成本、穩定性或合規要求已經不能靠「換一個模型名稱」解決。
同一產品開始同時使用 GPT、Claude、Gemini 或開源模型時，先建立任務分類與 fallback 規則，再看 Cloudflare AI Gateway REST API 這類統一路由方案。若是 token 成本已經影響毛利，先搭配 AI 成本最佳化 或 AI API 月費試算器 算出最貴的功能，再決定哪些任務適合便宜模型。
如果團隊不能隨意使用未核准 provider，重點會轉成 provider policy，可以延伸看 Vercel AI Gateway Provider Allowlist。若 agent 已經會連 SaaS、資料庫或內部 API，風險會同時落在模型、工具資料流與可追蹤性，這時再看 MCP Gateway 與 Deep Message Inspection 會更接近實際問題。
小團隊可以先從三件事開始：記錄每個任務的模型、token、成功率；把高價模型留給高難度任務；為 outage 和限流準備一個可接受的 fallback。等這些指標穩定後，再考慮更完整的 gateway。
FAQ
模型路由和 OpenRouter 是同一件事嗎？
模型路由是一種架構做法：依任務、成本、延遲、資料政策與可用性選擇模型。OpenRouter 是可以實作這件事的平台之一。團隊也可以用 Vercel AI Gateway、Cloudflare AI Gateway 或自建 wrapper 先做基本 routing。
Coinbase 使用 GLM 5.2、Kimi 2.7，代表大家都該換中國模型嗎？
這樣解讀會過度。Armstrong 的說法能證明 Coinbase 正在實驗這些開權重模型作為預設，但不同公司有不同資料政策、客戶合約、品質門檻與風險承擔能力。更安全的讀法，是把它當成模型路由與成本治理案例，不要當成供應商更換指令。
導入模型路由會不會降低輸出品質？
做得不好會。若只用價格排序，把高風險任務也丟給低價模型，品質和責任都會出問題。做得好時，routing 會讓簡單任務省成本、困難任務保留高階模型、敏感資料遵守政策，並用 eval set 與 audit log 追蹤結果。
小團隊該從哪裡開始？
先不要急著買完整平台。把模型呼叫集中到一個 wrapper，記錄 token、成本、延遲與錯誤；再把常見任務分級，決定哪些可以便宜化、哪些需要人工覆核。等到成本、供應商數量或客戶資料政策變複雜，再評估 OpenRouter、Vercel、Cloudflare 或自建 gateway。
參考來源
- Brian Armstrong on X：How to keep AI spend flat while token usage grows exponentially
- The Decoder：Coinbase joins the rush to Chinese AI models as Western labs face a pricing stress test
- Business Insider：The startups trying to save you from sky-high AI bills are getting showered with cash
- OpenRouter 官方首頁：The Unified Interface For LLMs
- arXiv：SEAR: Schema-Based Evaluation and Routing for LLM Gateways
- arXiv：Continual Model Routing in Evolving Model Hubs