為什麼 routing 應該放在 model serving 的中心

Routing 應該是 model serving 的單一入口，因為它能加快模型迭代，也能把服務層變成產品能力的一部分。

我主張把 routing 放在 model serving 的中心，而不是把它當成附屬功能。原因很直接：當模型數量、實驗數量和產品線一起增加時，真正決定團隊速度的不是模型本身，而是流量如何被分配、切換與回收。

Netflix 對內部 ML serving 平台的描述提供了很強的現實證據。它們把單一 API 當成入口後，新版本迭代更快，也更容易支援全新的 ML 產品，這代表 routing 不只是傳輸請求，而是把變更吸收進平台的控制面。

第一個論點：routing 不是細節，而是迭代速度的控制面

只要團隊要做 rollout、rollback、canary 或 A/B test，routing 就會直接影響交付速度。若每個模型或每條產品線都有自己的 serving 路徑，工程師就得重複實作流量規則，版本一多，維護成本會快速上升。

以推薦、搜尋、個人化三條常見路徑為例，很多公司一開始都各自接不同的 serving endpoint。到了需要同時支援新模型與舊模型共存時，問題就不是算力，而是協調成本，因為每次改版都要跨多個服務、監控和回滾機制同步更新。

中央 routing 的價值就在於把這些共通動作收斂成一個入口。當流量決策集中在同一層，模型作者就不必重新處理分流邏輯，PM 也能更清楚地定義實驗邊界，整個團隊的變更節奏會明顯變快。

第一個論點：routing 讓平台從「管線」變成「產品表面」

很多人把 model serving 想成後端基礎設施，但一旦模型數量超過幾個，serving 就會變成產品能力的一部分。Netflix 提到單一 API 讓新版本和新產品都更容易推出，這說明 routing 已經不只是把 request 送到某個模型，而是在定義產品如何被組裝。

這種差異在規模化後尤其明顯。當一個平台同時服務多個團隊時，若沒有統一入口，每個團隊都會建立自己的規則、自己的例外處理、自己的監控方式，最後形成一張難以理解的網狀結構，任何改動都需要跨團隊協商。

相反地，若 routing 是中心，平台就能提供一致的契約。這不只降低錯誤率，也讓新功能更容易被產品化，因為新的模型、策略或 ensemble 可以透過同一條路徑接入，而不是再開一個新的服務面。

第二個論點：單一入口不只更快，還能打開新的產品設計空間

routing 真正的戰略價值，不只是部署更安全，而是它能根據上下文做決策。像是使用者分群、裝置類型、地區、語言、實驗狀態，甚至風險等級，都可以成為選擇模型或策略的條件，這讓 serving 從靜態轉成動態。

這種能力會直接影響產品形態。舉例來說，同一個推薦請求可以在新用戶、老用戶、高價值用戶之間走不同模型，或者在低延遲場景下走簡化版本，在高精度場景下走更重的 ensemble。這些不是純工程問題，而是產品設計問題。

從組織角度看，這也會改變團隊分工。當 routing 能承載 business logic、experiment logic 與 model selection logic，產品團隊就不必每次都等底層重構才能驗證新想法。平台因此不只是供應模型，而是放大了實驗密度與功能創新速度。

第二個論點：沒有中心 routing，平台會在規模下碎裂

分散式 serving 的短期好處是自由，長期代價是碎片化。當每個團隊都用自己的 endpoint 和自己的 traffic policy，最後會出現同一種請求在不同產品裡有不同語意，監控也難以對齊，出了問題更難追查。

這種碎裂會直接拖慢組織效率。工程師花在對齊規則、修補差異、補寫轉接層的時間，往往比真正提升模型品質的時間更多。若一家公司每個月都在上新模型，這種重複成本會像利息一樣持續累積，最後反噬交付速度。

因此，routing 居中不是為了集權，而是為了減少重複。把共通邏輯放回平台層，才能讓各產品線保留差異化，同時避免每條路徑都重新發明一次 serving 系統。

反方可能怎麼說：中心 routing 會變成瓶頸

最強的反對意見是，單一入口很容易變成單一瓶頸。若 routing 層被過度治理、過度抽象，或被某個平台團隊鎖死，其他團隊就會卡在排程、權限和流程上，整個系統看起來雖然整齊，實際上卻更慢。

另一個合理擔憂是 failure domain。當所有流量都依賴同一層 routing，這一層一旦出錯，影響面會比單點模型服務更大。對高流量產品來說，這種集中化風險不能被輕描淡寫，尤其在多租戶或跨團隊環境裡更是如此。

但這些問題不否定中心 routing，反而定義了它應該怎麼做。正確做法不是做一個萬能 monolith，而是把 routing 限定在流量控制與模型選擇這些共通職責上，同時保留清楚的逃生通道與可觀測性。中心化的目標是標準化，不是把所有事情都塞進同一個黑盒。

你能做什麼

如果你是工程師，先盤點哪些 serving 邏輯其實只是重複的流量規則，能收斂就不要再開新 endpoint。如果你是 PM，把 routing 視為產品架構的一部分，因為它會直接影響實驗速度、功能上線方式與回滾成本。如果你是創辦人，應該在模型平台還不複雜時就先建立單一入口，否則等到每個團隊都各自長出一套 serving 路徑，再重構只會更痛。