單一模型的陷阱
每一家大型人工智慧供應商都希望你相信，它的旗艦模型是任何問題的正確答案。這個信念對它在商業上很方便，對你在技術上卻是錯的。
在長脈絡法律推理上出色的模型，並不適合寫一句十個字的圖說。具備最前沿視覺的模型，用在把結構化 JSON 重排格式的批次處理上是殺雞用牛刀，而且多半太貴。為吞吐量調好價格的模型，在你需要兩秒內得到回覆時，可能是想得到的最差選擇。
當你在一個模型之上建構時，你選的不是最好的工具。你選的是人為限制之內最好的工具。日子久了，這道限制會累積：簡單工作上多付錢，複雜工作上搆不著，而當那家供應商出故障或漲價時，你整個產品都停擺。
是能力，不是名字
有用的抽象不是「哪個模型」，而是「這次請求需要哪些能力」。這個問題有精確的答案。
附了螢幕擷圖的對話訊息需要視覺。呼叫外部 API 的工作流程步驟需要工具。要核驗自身輸出的程式碼助理需要程式碼執行。不必求快的夜間摘要流程可以用批次價格；產品內有人等著的助理則不能。
當你先把能力要求列清楚，模型選擇就成了一件篩選與排序的事。給定一組要求——例如文字、視覺與結構化輸出——你找出同時支援這三項的所有模型，再依目前請求情境的品質與價格為它們排序。這個排序會因人而異、因事而異，取決於那個人在做什麼、資金狀況如何。
這正是 ToRun 的分派流程所做的事。模式（對話、程式碼、影像、研究等）對應到一組能力。這組能力篩過模型目錄。價格與品質的排序挑出勝者。結果是：你可以用 DeepSeek 做大量的結構化擷取，用 Claude 或 GPT-4 級模型做細緻的推理，用 Google Gemini 做長脈絡的文件工作，用專門的影像模型做生成——全在同一個產品面上，而不必自己寫派送邏輯。
備援不是錦上添花
供應商故障並非罕見的邊角情形。它們在整個產業裡每月發生數次。若你的產品依賴單一供應商，而其 API 劣化，你的產品便隨之劣化。
備援鏈是維運的底線：當主模型對某次請求回傳暫時性錯誤時，平台在下一個最合適的模型上重試。這以分派層已經知道哪些模型合適為前提——而這恰是依能力分派所提供的。
備援還有一個不那麼明顯的好處：讓你的計費表現保持可預期。若首選模型暫時超出使用上限，繞到下一個合適的模型能把成本留在區間內，而不必向人展示錯誤。
實務上的結論
衡量人工智慧平台時，請問兩個問題：它如何為每次請求挑選模型；以及當那個模型無法使用或變得太貴時會發生什麼。
若任一問題的答案是「它總是用模型 X」，那就是架構上的異味。今天可用的模型不會是半年後最好的模型。新的供應商會出現，價格會變動，能力的邊界會挪移。把模型選擇當作分派問題而非設定決定的架構，老得更好，長期花費更少，在壓力下也劣化得更從容。
一個模型是起點。分派層才是真正的地基。