為什麼路由才是模型服務的真正瓶頸

模型服務的主要限制不是推理本身，而是路由決策；誰、何時、送到哪個模型與副本，才決定延遲、成本與穩定性。

我認為，現代 model serving 最大的誤判，就是把 routing 當成基礎設施雜務。它不是。當流量放大後，請求送往哪裡，直接決定延遲、利用率、成本，甚至整個系統能不能在高峰期維持穩定。Netflix 把焦點放在 serving routing 上，方向是對的，因為今天的 serving stack 已經不只是把模型跑快，而是要為每個請求選對模型、選對副本、走對路徑。

第一個論點：路由先決定成本結構

最直接的原因很簡單：每一次錯誤分派，都是 inference 成本的直接浪費。請求如果被送到冷啟動的 replica、已經飽和的 GPU，或是不適合當下任務的模型版本，錢在模型真正開始產生價值之前就先燒掉了。對高流量系統來說，這種小小的 routing 效率損失，會被放大成真實的基礎設施支出。

這不是抽象推論。假設一個每日千萬級請求的系統，routing 只要讓 5% 流量落到次佳路徑，累積下來就可能是數百萬次額外排隊、重試或 fallback。像 Netflix 這類服務個人化體驗的公司，不可能只靠單純 round-robin 就收工；路由必須同時考慮模型可用性、流量型態與運維限制，因為送錯目的地造成的尾延遲與資源失衡，本質上就是成本問題。

第二個論點：路由已經是模型品質的一部分

第二個原因更重要：routing 影響的不只是性能，還包括輸出品質。在現代 serving 系統裡，router 常常決定哪個專門模型接手、哪個版本被提升、或是何時切到 fallback。這代表路由策略本身就是產品體驗的一部分。router 弱，使用者感受到的就是一個較弱的系統，即使底層模型本身很強。

這在 ensemble、canary、或依使用者分群選模的系統裡尤其明顯。對某個受眾表現極佳的推薦模型，換到另一個 segment 可能就完全失準。若 routing 能理解 request context，就能保住相關性；若只是粗暴分派，差異會被抹平，結果品質下降。換句話說，routing 不是獨立於 model intelligence 的層，而是讓 intelligence 真正在 production 裡顯現的機制之一。

反方可能怎麼說

最強的反對意見是：routing 很容易被做得過度複雜。很多團隊根本不需要精密的 placement logic、動態策略或多階段決策。若產品規模小、只有一個模型、一種硬體層級、流量也不大，單純的 load balancer 加上一個 deployment target 就夠了。此時花太多時間在 routing 上，確實是浪費。

這個反對意見在小規模下是成立的。若 serving footprint 很小，router 就應該保持簡單。但這不是反對 routing 作為一門學科，而是反對過早複雜化。只要團隊開始有多模型、rollout 策略、硬體差異或流量整形需求，routing 就不再是可有可無的附屬品，而是保護可靠性與成本的核心機制。錯的不是太早做 routing，而是假裝自己永遠不會需要它。

你能做什麼

如果你是工程師或平台負責人，請把 routing 當成一個一級子系統，給它和模型訓練、部署同等的審視標準。要量 tail latency、replica saturation、fallback rate，以及每條 route 的成本；設計時要支援 policy 變更，而不是只做靜態 load balancing。若你是 PM 或創辦人，應該在模型需求之外同步定義 routing 需求，因為你選的 serving 策略，會同時改變使用者體驗與雲端帳單。先把 control plane 做好，別等規模逼你補課。