為什麼單一 Routing API 才是模型服務的正解

單一 routing API 應該是模型服務平台的預設做法，因為它能降低變更成本、加快迭代，並把實驗能力變成可重用的平台資產。

我主張，模型服務平台的預設設計應該只有一個 routing API，而不是為不同模型、不同團隊各自長出一套入口。Netflix 的經驗很直接：他們表示，單一 API 進入 ML serving 平台，明顯提升了迭代既有 ML 體驗新版本，以及推出全新 ML 產品體驗的速度。這不是介面整併的小優化，而是平台能不能持續擴張的分水嶺。

第一個論點

單一入口先砍掉的是變更成本。每多一個 serving 介面，工程團隊就多一份學習成本：不同 request shape、不同部署規則、不同觀測指標、不同失敗模式。平台一旦把入口標準化，底層怎麼演進都不必逼每個產品團隊重學一次契約。Netflix 的案例就是最強證據，他們明確指出，這個單一 API 加速了既有 ML 體驗新版本的迭代。

模型服務不是一次上線就結束，而是持續替換的工作。模型會漂移，特徵會改，延遲預算會收緊，排序邏輯也會重寫。單一 routing layer 讓團隊能切流量、換版本、做驗證，而不必每次都重建整個整合面。對平台來說，這代表它是控制平面，不是一堆一次性 pipeline 的拼裝場。

第二個論點

第二個關鍵是，單一 routing API 會把產品實驗集中成可重用能力。當每個新點子都要走一條客製化的生產路徑，創新就會卡住。統一入口把 routing 本身變成平台資產，產品團隊只要把流量送到同一個地方，就能在同一套版本選擇、政策控制與觀測機制下運作。這樣新 ML 功能才有機會更快進入 production。

Netflix 的另一個結果更能說明問題：這個單一 API 不只幫既有功能升級，也支援了全新的 ML 產品體驗。這才是平台價值，不是省幾行設定，而是把「試一個想法」的門檻壓低。門檻越低，能活下來的實驗就越多；能活下來的實驗越多，平台的回報就越高。

反方可能怎麼說

最有力的反對意見是，單一 routing API 會變成瓶頸。不同模型類型有不同需求：推薦系統、影像模型、LLM，在延遲、payload、rollout 上都不一樣。中央入口看起來像一刀切的治理，而治理常常意味著速度變慢。更現實的擔憂是耦合：如果 routing layer 出問題，所有服務都會一起受影響。

這些擔憂不是空穴來風。若平台把單一 API 做成巨石式 workflow engine，確實會拖慢團隊，也會把風險集中到單點上。

但這不是否定單一 API 的理由，而是要求它被設計成薄而穩定的契約，而不是厚重的流程引擎。正確做法是集中 routing，分散 execution；入口統一，底層保留足夠的 policy 與 metadata 來適配不同模型需求。問題不在單一 API，本質上是不要把它做成 monolith。

你能做什麼

如果你是工程師或平台負責人，先停止為每個模型類型複製一條 serving 路徑，除非你真的有硬性的技術理由。先做一個 routing surface，把 versioning、traffic splitting、observability 都納入契約；如果你是 PM 或創辦人，請優先選擇能讓新 ML 體驗更快上線的平台，而不是看起來最「彈性」的架構圖。模型服務的競爭力，來自入口標準化、內部自由化。