LLM routing:把簡單 query 送到便宜模型

如果你每個使用者 query 都用前沿模型(Claude 4.7 Opus、GPT-5),你超付了 5-10 倍。絕大部分 query —— 「天氣怎樣」「摘要這封信」「謝啦」—— 根本是 trivial 的,在 Haiku、GPT-5 mini、Gemini Flash 上跑得超好,成本只要 1/10。

LLM routing 是「每個 query 挑對模型」的紀律。做得好,你的帳單砍 60-80%,品質損失感覺不出來。做得差,把難問題送到弱模型,使用者討厭你的產品。

這篇是務實 playbook。

成本階梯

2026 年前沿 API 定價大致分層:

前沿 reasoning(GPT-5、Claude 4.7 Opus):$15-25/M input,$75-90/M output。
前沿一般(Claude Sonnet 4.7、Gemini 3 Pro):$3-5/M input,$15-20/M output。
中階(Claude Haiku 4.7、GPT-5 mini、Gemini Flash 3):$0.25-1/M input,$1-5/M output。
小模型(自架 Llama 3.2 3B、Phi-5、Qwen 2.5 7B):規模化自架基本上 $0/M。

中階到前沿大約 10× 差距。小模型到前沿 50-100× 差距。

你能辨認哪些 query 屬哪個 tier,省錢就大規模。

routing 策略分類

2026 年四種主流做法,複雜度遞增:

1. 手動規則(無聊解)

寫 if-statement。不同工作流送不同模型:

客服 FAQ → Haiku。
困難 reasoning / 寫程式 → Opus。
文件摘要 → Sonnet。
垃圾訊息 / 語言偵測 → 自架小分類器。

這 5% 工程努力換 70% routing 收益。別為了花俏方法跳過這個。

2. Cascade(升級)

先試便宜模型。它說信心低或沒過品質檢查,就升級。

def answer(query):
    cheap_response = haiku.answer(query)
    if cheap_response.confidence > 0.8 and passes_check(cheap_response):
        return cheap_response
    return opus.answer(query)

「檢查」可以是:

另一個便宜模型快速 LLM-as-judge。
啟發式(「回應實際有 code block 嗎?」)。
使用者踩號回溯觸發 Opus 重跑。

大部分 query 在便宜 tier 成功時很好用。成本負擔:升級時你付兩次呼叫。

3. Classifier-based routing

訓練(或 prompt)一個小模型把每個 query 分到難度 tier,送對應模型。

class = classifier.classify(query)  # "easy" / "medium" / "hard"
model = MODEL_BY_CLASS[class]
return model.answer(query)

分類器通常是:

帶 few-shot prompt 的小 LLM。
微調的 BERT 風分類器。
用標記 example 跑 embedding-based 最近鄰。

比 cascade 快(沒有兩次呼叫),但需要先標難度 example。

4. 學習型 routing(RouteLLM、LLM-Blender 等)

RouteLLM(LMSYS, 2024)等框架在 Chatbot Arena 配對資料上訓練 router 模型。給 query,它預測強模型贏弱模型的機率,根據機率 route。

比 classifier-based 準,但需要:

用預訓練 router(對通用聊天有效)或...
用你領域資料自己訓練(貴,只在規模化時值得)。

2026 年高量流量的認真團隊在用,大部分團隊還不該用。

一個具體起手實作

2026 年最簡單能贏大部分精緻方案的 router:

def route(query: str, conversation_history: list) -> str:
    # 困難情況:總用強模型
    if any(kw in query.lower() for kw in ["code", "debug", "why doesn't", "prove"]):
        return "opus"
    if len(query) > 1000:
        return "opus"  # 大概率複雜或重文件
    
    # 便宜情況:簡單閒聊或一句話問
    if len(query) < 50 and not any(c in query for c in "?:;"):
        return "haiku"
    
    # 預設中間
    return "sonnet"

給你 60% 成本節省,難 case 上有 Sonnet+ 品質。也只有五行而且完全好懂。

迭代:記錄哪些 query 路到哪個模型、哪些拿到使用者踩號,調整規則。

陷阱:難 case 路錯

router 最大失敗模式是把難 case 誤判成簡單。便宜模型自信地給錯答案,使用者收到垃圾。

緩解:

偏向升級。 不確定時用強模型。罕見難 query 多 10× 成本遠便宜過使用者流失。
加逃生口。 讓便宜模型可以說「我不確定,可以說明清楚嗎?」而不是瞎掰。System prompt:「如果你不能高信心回答,回 [ESCALATE]。」
品質打分 A/B 測試。 5% 路過流量同時送兩個模型比較。品質掉 > 3% 代表 router 太激進。
新使用者用更強模型。 新使用者對爛答案零耐心,他們前 10+ 訊息偏向 Opus。

2026 年有用的兩個 pattern

Pattern A:多 tier + 升級

User query →
  小分類器(Phi-5、3B)決定 easy/medium/hard。
  Easy → Haiku、Medium → Sonnet、Hard → Opus。
  之後:簡單 LLM judge 檢查輸出品質。
  Judge 說「低品質」就靜默用上一 tier 重跑。

成本跟可靠性平衡好。~70% query 落在 Haiku/Sonnet,~30% 在 Opus。總成本約純 Opus 基線的 25%。

Pattern B:每任務類型專門模型

User query →
  意圖分類器分類:閒聊、程式、搜尋、數學、圖片生成等。
  每個意圖手挑最佳成本模型:
    閒聊 → Haiku
    程式 → Sonnet
    難數學 → o3 / Opus reasoning
    圖片生成 → Flux / Imagen,不是 LLM

產品結構性多模態(聊天助理 + 寫程式助理 + 圖片生成)時有用。純文字問答比較沒用。

工具跟框架

2026 年不用從零自蓋。選項:

OpenRouter。 託管多廠商 gateway 內建 routing,單一 API,根據價格 / 可用性動態選廠商。入門首選。
Portkey / TrueFoundry。 企業級 gateway,有 policy-based routing 跟 observability。
RouteLLM(開源)。 LMSYS 的預訓練 router,免費。
Langchain Router / LlamaIndex Router。 框架層 routing component,已經在那些 stack 上的話好用。
客製 proxy。 很多團隊寫 200 行 Python proxy 跑手動規則,有用。

什麼時候不要 routing

低流量(<1000 請求/天)。 複雜度不值得省的錢。
每個爛答案都是流失風險的高端產品。 黏 Opus,直到你有資料證明安全降級路徑。
你還沒量品質。 沒 eval set 你永遠不知道 router 有沒有傷害使用者,routing 決策變迷信。

該量什麼

router 裡每個模型:

路過流量比例。 多少 % 的 query 去了每個模型?
每 query 成本(跟總成本)。
品質分數(LLM-as-judge 或抽樣人工 review)。
延遲。 小模型通常快,確認對的取捨。
升級率。 便宜模型多常失敗讓我們用貴的重跑?

升級率 > 30% 代表便宜 tier 太弱或分類器太積極。

下一步

RouteLLM: Learning to Route LLMs with Preference Data(LMSYS, 2024)。
LLM-Blender(Jiang et al, 2023)—— 配對 routing 方法。
OpenRouter 文件。
查這些詞:cascade inference、model gateway、prompt classification、LLM-as-judge。