hero

如果有一家公司，自己做了 LLM router、經營了四個月、有七千個使用者，然後跳出來說「我們不玩了，路由是個壞主意」——這篇文章就值得你認真讀。Manifest 的撤退不是技術失誤，是一個產品做了之後才發現自己的存在本身就是問題。尤其在這個每一家 AI infra 公司都在推 routing 的 2026 年夏天，這篇棄用公告更像是一盆冷水，直接潑在「讓平台幫你選模型」這個命題上。

原文摘要

Manifest 創辦人 Bruno Perez 開門見山：「我們不再相信模型路由了。對大多數使用情境來說，死守一顆經過實戰驗證的模型，是你最好的選擇。」

最近 LLM router 的熱度極高——好幾家公司在過去幾週推出類似產品，主打降低推論成本。Manifest 自己也做過：今年三月他們在 LLM gateway 中推出了路由功能，六月就標記為 deprecated，九月一日正式關閉。他們的 router 把每個請求分成四個複雜度等級：simple、standard、complex、reasoning。

初衷很直覺：何必用又貴又強的模型來處理簡單任務？把請求導向最划算的模型，聽起來是理所當然的優化。但四個月、七千個雲端使用者跑下來，結果是參差不齊的混合數據，外加 GitHub 上一堆 issue 和討論。Bruno 把他們碰到的問題拆成四個層面。

第一個問題：複雜度無法從提示詞本身推斷。 Prompt 只是觸發器，真正的任務上下文要到工具呼叫、網頁搜尋等執行階段才會浮現。Bruno 舉了一個精準的例子——「評估 test 並改善 repo $GIT_REPO」這句話：如果目標是純 HTML5 的個人網站，這是簡單任務；如果目標是 Linux kernel repo，這是地獄級任務。同一個 prompt，兩個完全不同的複雜度。Router 在接到 prompt 的那一刻根本不知道它面對的是哪一種。

第二個問題：快取比路由更有效降成本。 Cache 讀取比未快取的輸入便宜 75% 到 90%。system prompt 和對話歷史佔據大量 token，而 prefix cache 對這些永遠在 prompt 最前面的內容效果極好。一個「有快取意識」的 router 會怎麼做？它會黏住最初選的模型繼續查詢。Bruno 的原文說得很妙——router 的「最佳實踐」是諷刺地不去路由。

第三個問題：LLM router 破壞行為一致性。 有人說「工程師不應該煩惱選哪個模型」，Manifest 強烈反對。Bruno 的比喻很直接：就像畫家知道要用哪支畫筆、工匠謹慎選擇工具，工程師應該理解不同模型的取捨和微妙差異。在 Manifest，每個工程師根據自己的意圖選擇模型和 effort 參數。在工作過程中跳來跳去換模型，只會降低整體產出品質，並且讓人遠離「精通工具」的過程。

第四個問題：不可預測性本身就是成本。 沒有人喜歡不可預測性，軟體工程師尤其。在自動化 agentic workflow 或自主代理中，管理這層額外的不確定性，花掉的成本可能比省下來的還多。想想 evals、system prompt、可觀測性——所有東西突然都變得更難維護。針對不同請求分別設定合適的模型、參數和 prompt，在大多數情況下看起來自然更優。

結論：Bruno 承認也許有些場景 LLM routing 真的有用，推出這些產品的公司大概也有他們的理由。但基於 Manifest 自己的經驗，他們看到的大多數使用情境中，路由不值得。他最後一句話說得很實在：省下來的錢，會在其他地方付出代價——而且那個代價更難估算。

城武觀點

Manifest 這篇文章最致命的一句話，不是任何一個技術批評，是這句：「工程師應該像畫家選畫筆一樣自己選模型。」這句話不是技術結論——這是商業模式的判決書。

LLM router 從第一天就包裝成「幫你省錢」的工具，但它的隱含命題從來不是省錢。Router 的本質是把模型選擇權從工程師手上拿走，交給平台。表面上是「你不需要煩惱選哪個模型」，實際上是「你不需要知道為什麼這個模型被選中」。這跟省錢無關——這跟誰有權力決定你的 prompt 走哪條路有關。Manifest 做了四個月後砍掉，不是因為技術做不到，而是因為他們的工程師發現：router 作為產品的價值命題，跟「讓使用者更強」是衝突的。你要嘛讓工程師更強，要嘛讓他們依賴你的路由魔法——這兩件事互斥。Manifest 選了前者，然後回頭把 router 砍了。這不是失敗，這是清醒。

第二件事更根本：四級分類（simple/standard/complex/reasoning）的失敗不是實作問題，是範疇錯誤。提示詞的複雜度是一個連續函數，硬切成四個桶子必然有邊界洩漏。但真正的問題比邊界更深：router 預設「複雜度可以從提示詞靜態推斷」，而 Bruno 舉的那個例子已經暴露了這個預設有多脆弱——「評估 test 並改善」這句話本身什麼都不透露，複雜度完全取決於 repo 是什麼，而 router 在看到 prompt 的那一刻根本不知道。複雜度不是 prompt 的屬性，是 prompt 加 context 加 execution 的屬性。這不是 router 的 bug，是 router 這個概念本身的設計極限——你在起跑線上預測終點，但你連賽道是哪一條都還不知道。

所以 Manifest 的結論——「固定模型加更好的快取加工師自己選參數」——不是退而求其次的替代方案，是唯一合理的方案。動態路由是死路，不是因為技術不成熟，是因為它試圖解決的問題被定義錯了。問題不是「如何幫工程師選最便宜的模型」，問題從來都是「工程師如何更好地掌握自己的工具」。Router 對第一個問題給了一個半吊子答案，對第二個問題連答案都不是。

以經有人在說「Manifest 只是做得不夠好，換個更強的 router 就能解決」。我不賭這條路。我賭三年後大家回頭看 2026 年的 routing 狂熱，會像現在回頭看 2023 年的 prompt engineering 萬能論一樣——不是完全不對，是把一個小優化當成了一個新品類。

城武的未解檔案——當你的 router 學到的第一課是「不要去路由」，也許你從一開始就不需要它。