LLM Router:請求分流,成本砍 60% [2026]

LLM Router:請求分流,成本砍 60% [2026]

LLM router 是介於你的應用程式與多個語言模型之間的輕量層,負責決定每個請求由哪個模型處理。它檢查請求(任務類型、複雜度、token 預算),轉發給最適合的模型,並在該模型出錯時切換到備援。目標很簡單:用最少的 token 成本,換到剛好夠用的答案。

花 frontier 模型的錢回答「你們的退款政策是什麼?」,帳單就是這樣爆掉的。AWS 在 2025 年 4 月量過替代方案的代價:分類器 router 增加 0.53 秒延遲,語義 router 增加 0.10 秒,單一模型家族內路由最多可省 30% 帳單。用 2026 年 7 月的牌價跨供應商重算(如下文),降幅可達 70%。大部分省下的錢,來自一個在產生任何 token 之前就已做出的決定。

重點整理

• LLM router 依據任務類型、成本或實測品質,決定每個請求由哪個模型處理。
• 共有五種策略:規則型、成本感知、延遲感知、語義(embedding)與 LLM 分類器路由。
• 規則路由每個請求增加約 0 ms 與 0 美元;分類器路由增加 300-800 ms,外加分類器的 token 成本。
• 當多數簡單流量轉往便宜 10-20 倍的模型時,路由最多可砍掉 60% 的 token 支出。
• 單一供應商、每天不到 1 萬請求、沒有成本壓力?跳過 router 吧,普通 fallback 就夠了。

LLM Router 到底做了什麼?

LLM router 在每次模型呼叫前執行一個小型決策步驟:讀取請求、依路由規則評分、挑選模型、發送呼叫,並在第一個模型出錯時改用備援重試。應用程式的其他部分完全不用動。你一樣發一個請求,拿回一個回應。

請求的生命週期,依序為:

1. 請求送達 router 端點,與送到模型 API 完全相同。
2. 分析。 Router 檢查 prompt:關鍵字、token 數、embedding 或分類器分數。
3. 挑選。 路由策略將該訊號對應到一個模型層級(便宜、中階、frontier 或本機)。
4. 轉發。 呼叫透過 OpenAI 相容 API 送到選定的模型。
5. 備援。 遇到逾時、速率限制或錯誤時,請求在鏈中的下一個層級重試。

有人搜尋「llm gateway vs router」,是因為供應商文件把兩個詞混著用。一句話就能釐清:gateway 是管線,router 是決策。它們是不同層,不是對手,而且多數 gateway 內部就嵌了 router。

根據 LiteLLM 文件,保管虛擬金鑰的同一個 proxy 也同時執行 router。想專門比較管線層工具?我們的最佳 LLM gateway 工具評比了十款。

你真的需要 LLM Router 嗎?

多數小型應用程式不需要。Router 要發揮價值,流量必須明顯分成不同任務類型、token 帳單必須是你最大的基礎設施成本,或者你經營多個供應商而需要故障轉移。低於這些門檻,普通重試加一個備援模型就能買到可靠性,不必多出活動件。

我們直說,因為這領域沒人願意直說:如果你只用一個供應商、每天不到 1 萬請求,router 就是你不需要的大腦。普通 fallback 贏。

為什麼這麼直白?每一條路由都是一個主張(「這類任務用便宜模型很安全」),而它會隨模型、價格與產品變遷而過期。只有當省下的錢明顯超過維護成本時,才值得買單。

五種 LLM 路由策略(以及各自的使用時機)

每種 LLM 路由策略都在回答同一個問題:你信任哪個訊號,足以用它挑模型?規則信任關鍵字。成本路由信任 token 預算。延遲路由信任計時器。語義路由信任 embedding。分類器路由信任另一個 LLM。取捨的形狀永遠一樣:訊號品質越高,每個請求增加的延遲與成本就越多。

自動完成會浮現「llm routing strategies」「llm task routing」「llm intent routing」「llm dynamic routing」這些詞。它們對應到五種模式:

有一種模式貫穿全部五種:cascade,也稱模型分層。從便宜的開始,只在失敗或信心不足時升級。支援機器人用每百萬 token 0.25 美元的模型回答;信心低於 0.7 時,同一個請求在 frontier 模型重試。你只在便宜層承認自己卡住時,才為智慧付費。

想深入研究,ulab-uiuc 的 LLMRouter 函式庫收錄了 16 種以上的研究級路由演算法(KNN、SVM、MLP、矩陣分解、Elo、圖、BERT 類)。如果語義路由是你的選擇,範例 embedding 幾乎決定了一切;我們的最佳 embedding 模型指南說明哪些在真實語料庫上站得住腳。

如何用 Python 打造 LLM Router?

只要對著任何 OpenAI 相容端點寫大約 80 行純 Python,就能打造一個。不需要框架。下面四個 router 逐步升級:關鍵字規則、成本門檻、embedding 相似度,以及具備故障轉移的分類器模型。每個都會印出所選模型,讓你看見決策發生的瞬間。

如果你搜過「how to build an llm router」,卻只找到 AWS CDK 堆疊與學術 repo,這一節就是直球答案。AWS 的參考實作很扎實,但焊死在 Bedrock、Lambda 與 CDK 上。我們的版本能跑在任何 OpenAI client 指向的地方:OpenAI、透過 proxy 的 Anthropic、筆電上的 Ollama、GPU 機器上的 vLLM。以下是我們最先畫給客戶的 router。

步驟 1:規則型 router(關鍵字對模型)

零延遲的基準線。由正則表決定;所有未符合的都送到 frontier 層。

import re
from openai import OpenAI

client = OpenAI()  # works with OpenAI, Ollama, vLLM, or a LiteLLM proxy

def ask(model: str, prompt: str) -> str:
    r = client.chat.completions.create(
        model=model,
        messages=[{"role": "user", "content": prompt}],
    )
    return r.choices[0].message.content

ROUTES = [
    (re.compile(r"\b(refund|cancel|invoice|password|hours)\b", re.I), "gpt-5-mini"),
    (re.compile(r"\b(summarize|translate|rewrite)\b", re.I), "gpt-5-mini"),
]
FRONTIER = "gpt-5"

def rule_router(prompt: str) -> str:
    for pattern, model in ROUTES:
        if pattern.search(prompt):
            return model
    return FRONTIER

prompt = "How do I cancel my subscription?"
model = rule_router(prompt)
print(model)  # gpt-5-mini: regex hit on "cancel"
print(ask(model, prompt))

輸入:一個支援問題。決策:正則命中「cancel」。選定模型:gpt-5-mini。路由不需要任何 API 呼叫,這就是它維持預設地位的原因。

步驟 2:成本感知 router(token 預算門檻)

同樣的概念,但訊號是請求大小而非關鍵字。短 prompt 搭配小輸出預算走便宜;其餘走 frontier。

def cost_router(prompt: str, max_output_tokens: int = 500) -> str:
    word_count = len(prompt.split())
    if word_count < 60 and max_output_tokens <= 300:
        return "gpt-5-mini"  # $0.25 in / $2 out per M tokens
    return "gpt-5"           # $1.25 in / $10 out per M tokens

prompt = "Write a two-line product description for a ceramic mug."
model = cost_router(prompt, max_output_tokens=120)
print(model)  # gpt-5-mini: short prompt, small output budget

粗糙嗎?是。有效嗎?也是,因為 token 量與任務大小的相關性比多數人預期的高。這就是好幾個付費「cheap llm router」產品的全部策略。

步驟 3:語義 router(embedding 對範例)

對於躲開關鍵字的模糊使用者輸入,將 prompt 轉成 embedding,與嵌入後的範例 prompt 比對。距離最近的群叢擁有該請求。

import numpy as np

EXEMPLARS = {
    "gpt-5-mini": [
        "classify this support ticket into a category",
        "extract the shipping address from this email",
    ],
    "gpt-5": [
        "debug this race condition in our worker pool",
        "design a multi-tenant billing schema",
    ],
}

def embed(texts: list[str]) -> np.ndarray:
    r = client.embeddings.create(model="text-embedding-3-small", input=texts)
    return np.array([d.embedding for d in r.data])

CENTROIDS = {m: embed(xs).mean(axis=0) for m, xs in EXEMPLARS.items()}

def semantic_router(prompt: str) -> str:
    v = embed([prompt])[0]
    scores = {
        m: float(np.dot(v, c) / (np.linalg.norm(v) * np.linalg.norm(c)))
        for m, c in CENTROIDS.items()
    }
    return max(scores, key=scores.get)

print(semantic_router("pull the tracking number out of this message"))
# gpt-5-mini: closest to the extraction exemplars

路由呼叫的成本是一次 embedding(幾百個 token)與 50-150 ms。在啟動時預先計算質心,不要每個請求都算。

步驟 4:具備 fallback 的 LLM 分類器 router

最強的訊號:用便宜模型讀取 prompt 並評分難度。這就是 AWS 量出增加 0.53 秒延遲的策略,所以我們用 fallback 鏈包住它。

def classify_router(prompt: str) -> str:
    verdict = client.chat.completions.create(
        model="gpt-5-mini",
        messages=[{"role": "user", "content":
            "Reply HARD or EASY only. Task: " + prompt}],
        max_tokens=5,
    ).choices[0].message.content.strip().upper()
    return "gpt-5" if verdict.startswith("HARD") else "gpt-5-mini"

def route_and_call(prompt: str) -> str:
    model = classify_router(prompt)
    try:
        return ask(model, prompt)
    except Exception:
        backup = "gpt-5-mini" if model == "gpt-5" else "gpt-5"
        return ask(backup, prompt)  # fallback tier catches the failure

print(route_and_call("Prove this greedy algorithm is optimal."))
# classifier says HARD, so gpt-5 answers

整個 llm router 範例就是這樣:四個函式、一個 client,除了你既有的基礎設施之外什麼都不需要。生產環境的強化是下一節。

LLM 路由實際能省多少?

AWS 量出 router 的開銷約為每個月每 10 萬個問題 107.90-188.90 美元,其中分類器路由每個請求增加 0.53 秒,語義路由增加 0.10 秒。節省的那一面遠大於這筆開銷。下方根據 2026 年 7 月牌價的試算範例,落在 70.7% 的支出削減。陷阱在流量組成:你需要多數請求符合便宜層的資格。

兩張表。第一張:router 本身每 1,000 個請求讓你付出多少:

AWS 2025 年 4 月的文章是這個領域唯一獨立公開的量測數據集,所以我們以它為錨,並將自己的延伸標註為估算,而非我們跑出的數字。根據 AWS,Bedrock Intelligent Prompt Routing 在家族內最多可省 30% 成本。

第二張:支撐標題的節省試算範例:

假設,已標註:每月 10 萬個請求;每個請求平均 800 輸入加 200 輸出 token;80% 簡單/20% 複雜的分布;牌價取自 Anthropic 定價頁與 OpenAI 定價頁(2026 年 7 月),完整費率表在我們的 LLM API 定價比較。每請求計算:Sonnet 4 成本 800 x $3/M + 200 x $15/M = $0.0054;GPT-5 mini 成本 800 x $0.25/M + 200 x $2/M = $0.0006。

結果是 70.7% 的削減,這就是標題中 60% 的由來,還留有餘裕。誠實的但書:這是試算範例,不是我們跑出的基準。它假設你的便宜層便宜 10-20 倍,且 80% 流量真的符合資格。家族內路由(AWS 的情境)維持在 30% 附近。而路由只是眾多槓桿之一;prompt 快取與修剪往往回收更快,我們的降低 LLM API 成本指南替十二種方法排了名。

生產環境的路由模式

玩具 router 挑模型。生產 router 還要重試、平衡負載、快取重複請求,並為每個團隊隔離 API 金鑰。每天超過幾千個請求後,就別再手刻這些,改跑內建 router 的 gateway。

四個重要的模式:

• Fallback 鏈。 先走便宜層,錯誤或逾時時用 frontier。單一最高價值的模式;你的可靠性大半來自這一招。
• 負載平衡。 將呼叫分散到重複的部署或 API 金鑰,避開單一金鑰的速率限制。
• 回應快取。 相同 prompt 回傳快取答案。支援流量的重複程度超乎想像;10-30% 的命中率很常見。
• 虛擬金鑰與預算。 為各團隊核發帶月度上限的金鑰,一個失控迴圈就不會燒掉整張帳單。

這接近我們在 staging agent 堆疊上跑的設定(檔案:litellm-router.yaml,掛進 LiteLLM proxy 容器):

model_list:
  - model_name: cheap
    litellm_params:
      model: openai/gpt-5-mini
  - model_name: frontier
    litellm_params:
      model: anthropic/claude-opus-5

router_settings:
  routing_strategy: simple-shuffle
  fallbacks: [{"cheap": ["frontier"]}]
  num_retries: 2
  timeout: 30

各工具的定位,附上我們的看法:

• LiteLLM。 想要自架、開源,而且已經在跑 Docker,就選它。我們的 LiteLLM proxy 建置指南走完整個部署,含金鑰與預算。
• OpenRouter。 想要一個金鑰後面幾百個模型、零維運,就選它。他們的排名頁同時是吞吐量數據。
• Portkey。 由企業需求(SSO、稽核紀錄、合規報告)驅動決策時,就選它。
• 本文的自訂程式碼。 每天約 5 萬請求以下、想要零新基礎設施,就選它。

無論選哪個,LLM gateway 工具評比把十款兩兩對決。

能在本機模型與託管 API 之間路由嗎?

能,而且 token 帳很誘人:本機模型每 token 收 0 美元,所以 Ollama 或 vLLM 每回答一個請求都是純節省。代價是每瓦的延遲與品質。本機適合在你既有硬體上跑大量簡單任務;託管 API 接住一切需要 frontier 腦力的請求。

機制平淡無奇,這正是重點。Ollama 在 localhost:11434/v1 暴露 OpenAI 相容端點,vLLM 提供同樣的形狀。所以上面每個 router 都不用改:把 base_url 指向本機伺服器,把 qwen3:8b 放進便宜槽,gpt-5 留作備援層。想自架 router 機器,LiteLLM 有 Docker 映像檔,正是大家搜的「llm router docker」設定。

兩點誠實提醒。單張 A100 上的 70B 模型大約每秒 30-40 token;託管 API 在突發吞吐量上贏過它,所以本機路由更適合穩定的背景流量,而非尖峰的使用者端聊天。而且本機 8B 模型在多步驟工具呼叫上容易失手,把困難路由留給雲端。如果你在挑選服務引擎本身,vLLM vs SGLang對兩者做了基準測試。

路由也驅動多模型 coding agent 設定。LiteLLM 風格的 proxy 讓 Claude Code 透過單一端點與本機及託管模型對話;確切接線方式見在 Claude Code 中使用不同模型。

如何知道路由有沒有發揮作用?

要嘛量測,要嘛只是在猜。記錄每個請求由哪個模型回答,對一批輸出樣本依評分表打分,再把分數回饋進路由規則。跳過這一步的團隊,最後會拿到一份靜態設定,在模型與價格不斷變動之下悄悄腐壞。

升級弧線依序是規則、成本,然後是實測品質:

1. 記錄路由。 將所選模型、延遲與 token 數,作為既有 trace 中的一欄,逐請求儲存。
2. 每週為輸出評分。 LLM 評審或人工抽樣,每個請求類別給通過/失敗。每類五十分評分輸出,就足以作為指引。
3. 重新調校。 如果便宜層在某類通過率達 95% 以上,放寬它的規則以接住更多該類流量。如果跌破 90%,收緊。

這是我們反覆對客戶說的一句話:從不重新調校的 router,只是多了額外延遲的靜態設定。記錄所選模型、為輸出評分、把分數回饋回去。

這個迴路就是應用在路由上的 eval 加可觀測性。我們的 LLM eval 指南涵蓋評分表;AI 可觀測性指南涵蓋 trace 放在哪裡。

LLM 路由研究正往哪裡走?

學術界把路由視為學習問題,而不是設定檔。ulab-uiuc 的 LLMRouter在這個關鍵字排名第一,實作 16 種以上演算法(KNN、SVM、MLP、矩陣分解、Elo、圖、BERT 與 RL router),並在 11 個資料集上跑基準管線。近期引用最多的論文 RouteLLM(Ong 等人,arXiv:2406.18665)用人類偏好資料訓練 router,回報在 MMLU 與 MT-Bench 上成本降低超過 2 倍且不損品質。最新的花樣:prefill 活化 router,也就是「prefill is all you need」路線,在 prefill 期間讀取模型內部活化,在生成開始前預測難度。發展方向是能從你的 eval 資料自我訓練的 router,這正是上一節的那個回饋迴路。

Techsy 的做法: 我們為 B2B 客戶交付的 agent 堆疊正是跑這個模式:成本層級 router,將 fallback 鏈接進 gateway,加上 eval 驅動的重新調校。如果你在評估路由是否適合你的堆疊,預約免費諮詢,我們陪你一起畫出流量組成。

關於作者

Mert Batur 是 Techsy.io 的共同創辦人,團隊為 B2B 客戶交付 AI agent、自動化系統與語音/SDR 管線。他寫的文章主題,都是 Techsy 團隊在生產環境實際使用的 LLM 工具堆疊。LinkedIn 上聯繫。

常見問題

什麼是 LLM router?

LLM router 是介於你的應用程式與多個語言模型之間的層,負責決定每個請求由哪個模型處理。它檢查請求的任務類型、大小或難度,然後轉發給最適合的模型,並在該模型失敗時備援。可以把它想成模型 API 呼叫的流量管制員。

LLM 路由如何運作?

LLM 路由分五步:請求送達,router 檢查(關鍵字、token 數或 embedding),策略挑選模型層級,呼叫被轉發,備援模型接住任何失敗。整個決策發生在生成開始之前,所以增加的是毫秒,不是秒,除非由分類器模型評分。

LLM router 和 LLM gateway 是一樣的嗎?

不是。Gateway 是管線:API 金鑰、速率限制、預算與紀錄。Router 是決策:由哪個模型回答。它們是層,不是對手,而且多數 gateway(LiteLLM、Portkey、OpenRouter)內部都嵌了 router。你可以只跑 router 不跑 gateway,但在生產環境通常兩者都要。

模型路由真的省錢嗎?

真的,前提是多數流量符合便宜許多的層級資格。我們的試算範例把 80% 請求從每百萬 token 3/15 美元的模型,轉往 0.25/2 美元的模型,帳單砍了 70.7%。AWS 回報家族內路由最多省 30%。如果你的流量一律複雜,節省就趨近於零。

最好的開源 LLM router 是什麼?

生產環境選 LiteLLM:自架、積極維護,gateway 與 router 合一。研究級演算法則選 ulab-uiuc 的 LLMRouter,實作文獻中 16 種以上路由策略。RouteLLM 是以偏好資料訓練、每美元品質最強的 router。多數團隊應從 LiteLLM 開始,只有需要自訂評分時才動用研究函式庫。

如何用 Python 打造 LLM router?

從 OpenAI client 與大約 80 行程式碼開始:關鍵字對模型的規則表、token 數的成本門檻、對範例 prompt 的 embedding 相似度,或用便宜分類器模型評分難度。四種模式都在上面的建置章節,不用修改就能對 OpenAI、Ollama 或 vLLM 執行。

能在本機模型與雲端 API 之間路由嗎?

能。Ollama(localhost:11434/v1)與 vLLM 都暴露 OpenAI 相容端點,所以同一份 router 程式碼能將便宜流量指向本機模型、困難流量指向託管 API。本機 token 成本 0 美元,但硬體與延遲由你承擔。多數多模型 Claude Code 設定背後就是這個模式。

什麼是語義路由?

語義路由將每個進入的 prompt 轉成 embedding,與嵌入後的範例 prompt 比對,把請求送給擁有最近範例群叢的模型。它處理關鍵字規則漏掉的模糊、改寫過的使用者輸入,代價是每個請求 50-150 ms 加 embedding token。AWS 量出它增加 0.10 秒延遲。

LLM 分類器 router 增加多少延遲?

AWS 量出 LLM 輔助分類增加 0.53 秒延遲,語義路由則是 0.10 秒。規則型與成本感知路由增加約等於零,因為它們是純程式碼路徑。如果你的產品有緊迫的回應時間 SLA,優先選規則、成本門檻或 embedding,把分類器留給離線或佇列工作負載。

參考來源

• Seifi, N. and Chugh, M. (2025-04-09). "Multi-LLM routing strategies for generative AI applications on AWS." AWS Machine Learning Blog. https://aws.amazon.com/blogs/machine-learning/multi-llm-routing-strategies-for-generative-ai-applications-on-aws/ (2026 年 7 月 30 日存取)
• AWS sample code: sample-multi-llm-dynamic-prompt-routing. https://github.com/aws-samples/sample-multi-llm-dynamic-prompt-routing (2026 年 7 月 30 日存取)
• LiteLLM documentation. https://docs.litellm.ai (2026 年 7 月 30 日存取)
• Anthropic pricing. https://www.anthropic.com/pricing (2026 年 7 月 30 日存取)
• OpenAI API pricing. https://openai.com/api/pricing (2026 年 7 月 30 日存取)
• ulab-uiuc LLMRouter. https://github.com/ulab-uiuc/LLMRouter (2026 年 7 月 30 日存取)
• Ong, I. et al. (2024). "RouteLLM: Learning to Route LLMs with Preference Data." arXiv:2406.18665. https://arxiv.org/abs/2406.18665 (2026 年 7 月 30 日存取)
• OpenRouter rankings. https://openrouter.ai/rankings (2026 年 7 月 30 日存取)