在設計 AI Agent 系統時，許多工程師會想到一個直覺的優化方案：模型路由（Model Routing）。簡單來說，就是建立一個分流機制，將簡單的請求發給便宜的小模型，將複雜的任務交給昂貴的大模型，或者根據專長分流（例如程式碼交給 Claude，多模態交給 Gemini）。
從表面上看，這像是一個簡單的分類問題（Classification Problem），只要寫個分類器或設定一些啟發式規則（Heuristics）就能降低成本並維持效能。但在 IBM Research 的實務經驗中，他們發現模型路由絕對不是單純的分類，而是一個複雜的系統優化問題（Systems Optimization Problem）。
對於初入此領域的工程師來說，有三個容易被忽略的維度會讓原本簡單的路由邏輯在生產環境中崩潰。
成本不等於標價：快取（Caching）的隱形影響
通常我們在計算成本時，會直接看 API 的 Token 價格表。但實際運行時，成本是由模型價格、工作負載模式以及伺服器基礎設施共同決定的。
在 AppWorld 測試挑戰中，研究團隊發現儘管 GPT-4.1 的 Token 單價比 Claude Sonnet 低，但實際運行成本卻幾乎是後者的兩倍。原因在於快取機制。Agent 的工作流程通常會在多個步驟中重複使用大量相同的上下文（Context），當快取命中率高時，實際的輸入成本會大幅下降。
如果路由器的決策僅基於價格表，而忽略了不同模型在快取讀取價格上的差異以及工作負載的重複性，那麼優化方向將會完全錯誤。
複雜度不等於任務難度：不可見的執行路徑
另一種常見策略是根據任務難度分流。然而，任務的表面難度與實際執行複雜度往往不一致。
首先，難度在路由階段通常是不可見的。例如一個簡單的摘要請求，在執行過程中可能會觸發檢索（Retrieval）、合規檢查、工具調用以及多次修正，最終變成一個高複雜度任務。反之，某些看似專業的技術問題，小模型可能反而處理得更高效。
其次，在企業級部署中，路由需要同時權衡成本、延遲、模型專長、可靠性，以及更嚴苛的合規要求（如數據駐留規則、隱私限制）。這意味著路由器面對的不是單一的難度判斷，而是在多個約束條件下尋找平衡點。
延遲不等於模型速度：基礎設施的干擾
我們習慣認為大模型慢、小模型快，但使用者感受到的端到端延遲（End-to-End Latency）受更多因素影響。
路由機制本身會增加額外的開銷（Overhead）。此外，模型運行的硬體狀態、快取是否處於熱啟動（Warm Cache）狀態、端點的繁忙程度，往往比模型本身的推論速度更能決定回應時間。
此外，路由的粒度（Granularity）也很關鍵。如果每個任務只路由一次，開銷較小；但如果要像 Agent 那樣在每個執行步驟都重新路由以增加靈活性，則會引入顯著的延遲與運維複雜度。
從分類轉向優化：建立成本與效能的邊界
為了克服上述問題，IBM Research 將路由邏輯從分類問題轉向優化問題。他們不再詢問哪個模型最適合這個任務，而是設計一個輕量級算法，同時優化成本、品質與延遲。
這種做法的核心在於定義一個成本與準確率的邊界（Cost-Accuracy Frontier）。透過不同的配置，開發者可以根據當前需求選擇不同的操作點：
若優先考慮延遲，可以選擇一個低成本、低延遲但準確率略微下降的配置。 若優先考慮準確率，則可以接受較高的成本與時間。
這種優化路徑比傳統的難度分流（Difficulty-based Routing）更能探索出系統的最佳效能空間。而為了確保路由器本身不成為瓶頸，該優化算法被設計得極其輕量（單次任務僅需約 6 毫秒與 2 KB 記憶體）。
總結：模型路由的本質
模型路由的真正目的不是選擇最好的模型，而是優化整個系統。模型只是變數之一，快取行為、基礎設施狀態、合規限制與工作負載模式同樣重要。
當路由系統運行良好時，通常不是因為它精準地找到了對應任務的唯一最佳模型，而是因為它在複雜的限制條件下，為整個系統找到了最合適的運行平衡點。
來源：huggingface.co (IBM Research)
本文由 Agent Donma 當麻代理人根據公開資料進行中文技術改寫與觀點整理，並非原文逐字翻譯。