將 LLM API 成本減半：2026 年生產環境工作負載的模型路由指南

隱藏在你的帳單中的成本問題

看看你線上環境程式碼中的 model 參數。對大多數已從原型跨入真實流量的 LLM 工作負載團隊來說，該參數在上線時通常只設一次（通常設為當時能用到的最強模型），之後再也不改。不論複雜度如何，每個查詢都打到同一個模型。這就是無聲成本超支藏身之處。

在任何非簡單的生產級工作負載中，查詢的難度並不均一。客服助理可能有 80% 的查詢是簡單的查找、分類或簡短追問，另有 20% 真的需要前沿推理。程式碼助理可能處理穩定流量的小型重構，外加長尾的多檔案架構調整。內容管線可能每處理數百個摘要任務，才有一個需要結構化創意寫作。工作的形態不均勻，但到模型的路由卻不是。

如果你現在每月在 GPT-5.5 上跑 100M tokens，而其中 70% 的查詢其實用更便宜的模型也能答得一樣好，那你大約每月在為用不到的能力多付 $600。更高量級時同樣的模式會線性複利：每 1B tokens，未路由與已路由之間的差距每月就是數千美元。

路由是對這種不對稱性的工程解法。原則很簡單：把每個查詢送到能處理它的最便宜模型，只有需要時才升級到更強的模型。實作才是取捨所在，而多數既有指南對此處理得並不好。本文涵蓋實際在生產可行的三種模式、支持這個論點的成本數學、會絆倒你的失敗模式，以及一份從單一模型遷移到路由化而不必重寫應用的遷移手冊。

本文依據的定價資料來自配套文章（2026 LLM API 定價比較），其中建立了全文引用的各模型費率。凡文中引用成本數字，均源自該資料。

生產環境中可行的三種路由模式

有三種既有的 LLM 流量路由模式。它們在實作複雜度、延遲開銷與可解鎖的成本節省類型上有所不同。大多數生產系統最終會組合使用這三種；理解各自的長處有助於你安排落地順序。

模式 1：靜態規則

最簡單的模式。你根據請求可觀察的屬性寫規則，將查詢路由到不同模型：輸入長度、使用者等級、查詢類型（如果你已有分類器）、API 端點或業務邏輯。短查詢走便宜模型；長查詢走更強的模型。免費用戶用較便宜的模型，付費用戶用較貴的。程式碼生成請求走針對程式碼調優的模型；其他走通用模型。

靜態路由可預測、可偵錯，幾乎不增加延遲：路由決策是幾行在本地執行的程式碼。上限也較低：你只能根據模型執行前能觀察到的屬性來路由，這意味著你不能基於「查詢實際有多難」來路由，因為你尚未知曉。對於輸入屬性與難度相關性好的工作負載（長文件通常更難；程式碼通常不同於散文；付費用戶通常提出更高要求），靜態規則幾乎不需工程投入就能捕捉 30–50% 的可得節省。

模式 2：級聯（Cascade）

最具普適性的模式。你先把查詢送到較便宜的模型；若回應達到品質門檻就直接返回；不達標就升級到更強的模型並使用其回應。成本節省來自於：對於較便宜模型能處理的查詢，你只需支付較便宜模型的費用。

級聯的區別在於路由決策由模型的輸出而非僅輸入來告知：你讓較便宜模型先嘗試，然後判斷是否足夠好。判斷可以多種方式實作：模型自身的信心分數、結構化輸出驗證（回應是否能按預期的 schema 解析？）、自我評估提示（讓小模型判斷回應是否回答了問題），或下游行為訊號（使用者是否接受答案，或改寫後再問？）。

級聯是多數生產系統最終採用的模式，因為它能捕捉靜態規則無法獲得的成本節省。取捨在於：在會升級的查詢上，你要支付較便宜模型與旗艦模型兩次呼叫，因此節省幅度取決於有多少比例的查詢能在較便宜模型層級成功。本文稍後將詳細推導。

模式 3：基於分類器的路由

天花板最高、工程投入也最大。使用一個小而快的模型（通常是經微調的次前沿模型，或專用分類器）來觀察每個進來的查詢，並預測該由哪個下游模型處理。分類器可以根據查詢類型決策（「這看起來是程式碼生成；路由到針對程式碼調優的模型」）、難度估計（「這看起來是困難的推理；路由到 GPT-5.5」），或基於歷史流量與結果訓練出的路由策略。

基於分類器的路由可能勝過級聯，因為決策發生在任何昂貴模型執行之前，所以你不會在本就需要旗艦模型的查詢上支付較便宜模型的「稅」。代價是建置、訓練並維護分類器本身的工程工作，以及路由呼叫帶來的一點延遲開銷。對非常高流量的工作負載，這樣的取捨是划算的；對小流量，通常不划算。

從哪個模式開始： 如果你的工作負載有明顯的路由訊號（輸入長度、用戶等級、端點），先上靜態規則。若沒有，或當你已用盡明顯的靜態規則後，就上級聯。只有在靜態與級聯都到位，且流量規模足以支撐工程投入時，才上基於分類器的路由。直接跳到分類器是典型的過度工程化陷阱，多數團隊都會後悔。

開始路由之前要量測什麼

你無法優化未被量測的東西。在將任何路由邏輯引入生產系統前，先對目前的單模型工作負載做儀表化，如此才有基準可對照。儀表化不必繁複：對每個請求記錄一小組欄位的基本日誌即可起步。

最小可用的儀表化：

• Per-request： 使用的模型、輸入 token 數、輸出 token 數、成本（由 token 數與價目表計算）、端到端延遲、回應狀態（成功 / 錯誤 / 部分），以及若有的話，一個查詢類型標籤。
• Per-conversation 或 per-user： 會話長度、重試次數（暗示使用者不接受第一次答案）、追問率（暗示答案需要澄清）。
• 保留的評估集： 100–500 個具有代表性的查詢，可在任一模型上重跑，且有你信任的參考輸出。這就是你衡量候選便宜模型在你的工作負載上是否產生可接受品質的方式。沒有它，每個路由決策都是在猜。

評估集是多數團隊投入不足之處，卻是任何路由專案槓桿最高的基礎設施。像 Promptfoo 或 Helicone evals 這樣的輕量工具能快速搭建；對早期工作負載，一組手工篩選、包含 50 個查詢且手動評分的集合就足夠起步。

完成儀表化後，讓工作負載按現狀運行至少一週，以建立基線。資料的形狀（輸入長度分布有多偏、多少比例是短且簡單的查詢、多少比例看起來很難）會告訴你該從哪種路由模式開始。

深入解析級聯模式與成本計算

級聯值得最多篇幅，因為它最通用，且是多數團隊會先或次先實作的模式。數學也讓路由的價值更為具體。

考慮一個現在跑在 Claude Sonnet 4.6 的代表性生產工作負載：100 million tokens per month，80% 輸入、20% 輸出，按標價每月 $475。假設我們在前面加一個級聯：查詢先打到 Claude Haiku 4.5，只有在 Haiku 的回應未通過品質檢查時才升級到 Sonnet 4.6。Haiku 4.5 的標價是每百萬 token 輸入 $1.00、輸出 $5.00，約為 Sonnet 費率的三分之一。

成本數學取決於兩個參數：有多少百分比的查詢在 Haiku 層級成功（稱為成功率），以及成功與升級的查詢之間輸入/輸出比的差異。為簡化，假設兩者的輸入/輸出比相同，且成功率為 70%，意即 Haiku 在 70% 的查詢上給出足夠好的回應，30% 會升級到 Sonnet。

這告訴你什麼。 即使在中等的 70% 成功率（意即 Haiku 10 次裡對 7 次），級聯也能把帳單砍半。原因在於：較便宜模型的呼叫遠比旗艦模型便宜得多，所以在那 30% 會升級的查詢上同時支付兩次呼叫費，仍遠低於每個查詢都打旗艦模型。損益平衡點（級聯成本等於單模型成本）大約在 33% 成功率。低於此值，直連比較好；高於此值，級聯就開始勝出。

最小可行的級聯實作

以下是該模式的最簡版本，以 Python 與相容 OpenAI 的用戶端表達（可對接任何提供相容 OpenAI 端點的供應商，包括透過 Anthropic 的相容層使用 Claude、Gemini，以及 CometAPI 的統一端點）。結構刻意保持精簡；生產實作需補上可觀測性、錯誤處理與更成熟的品質檢查。

from openai import OpenAI
import json

client = OpenAI(
    api_key="YOUR_API_KEY",
    base_url="https://api.cometapi.com/v1",  # or your provider of choice
)

CHEAP_MODEL = "claude-haiku-4-5"
FLAGSHIP_MODEL = "claude-sonnet-4-6"


def cascade(messages, output_schema=None):
    """
    Run a query through a cascade.
    Returns (response, model_used, escalated).
    """

    # Step 1: try the cheap model
    cheap_response = client.chat.completions.create(
        model=CHEAP_MODEL,
        messages=messages,
        response_format=output_schema,
    )

    cheap_text = cheap_response.choices[0].message.content

    # Step 2: judge whether the cheap response is good enough
    if is_acceptable(cheap_text, output_schema):
        return cheap_text, CHEAP_MODEL, False

    # Step 3: escalate to the flagship
    flagship_response = client.chat.completions.create(
        model=FLAGSHIP_MODEL,
        messages=messages,
        response_format=output_schema,
    )

    flagship_text = flagship_response.choices[0].message.content

    return flagship_text, FLAGSHIP_MODEL, True


def is_acceptable(response_text, output_schema=None):
    """
    Quality gate.
    Returns True if the cheap model's output is good enough.
    """

    if not response_text or len(response_text.strip()) < 10:
        return False

    if output_schema:
        # Structured output: it has to parse against the schema
        try:
            parsed = json.loads(response_text)
            return validate_schema(parsed, output_schema)

        except (json.JSONDecodeError, ValueError):
            return False

    # For free-form responses, plug in your own quality signal:
    # - confidence score from the model
    # - self-evaluation prompt to a small model
    # - rules-based checks (length, format, refusal patterns)

    return True

這只是起點，不是完整實作。生產環境你至少要加上三件事：

• 真正的品質門檻。 上面的 is_acceptable 函數刻意極簡。實務上，門檻是級聯中最重要的一環：太寬鬆會出貨低品質答案；太嚴格會過於頻繁升級而失去節省。多數生產級聯會結合結構化輸出驗證、拒答偵測（較便宜模型表示「我無法回答」）與由小模型進行的自我評估打分。
• 逐請求可觀測性。 記錄使用了哪個模型、是否發生升級、各層級的延遲與成本。這能讓你在級聯運行一週後確認成功率是否如你假設。
• 評估用的金絲雀路徑。 即使級聯在較便宜層級判定成功，也讓一小部分流量（例如 5%）同時走旗艦模型。把兩個回應拿去做保留集的評分比較。這是攔截無聲品質劣化的方法；下一節詳述。

路由失效的地方

上述節省的數學是真實的，但同時也是樂觀情況。有三種失敗模式最容易絆倒團隊，老實點出它們，才能讓路由層持續創造價值，而不是悄悄拖垮產品。

升級請求的延遲開銷

當查詢升級時，你會先支付較便宜模型的時間，然後旗艦模型才開始。如果較便宜模型花 800ms、旗艦花 1.5s，那升級的查詢端到端就是 2.3s。對延遲敏感的工作負載，這很重要。緩解方式是選擇足夠快的較便宜模型（Haiku 4.5 與 Gemini 3 Flash 就是為此設計）、對較便宜呼叫設置積極的逾時計時，並考慮對高概率會升級的查詢採用並行呼叫。有些團隊接受延遲成本，因為金錢節省很大；另一些則用靜態規則避免讓顯而易見的困難查詢走級聯。

無聲的品質劣化

最陰險的失敗模式。較便宜模型產生的回應能通過你的品質門檻，但微妙地比旗艦更差：稍微不那麼準確、稍微不那麼有幫助、稍微更容易漏掉邊角情況。使用者不會立刻抱怨；你監控的指標（回應延遲、錯誤率、門檻通過率）看起來都正常；但下游指標（留存、轉化、客服升級）開始漂移。等你注意到時，已經出貨了數週的品質劣化。

防線就是上面提到的金絲雀路徑：一個與級聯門檻無關、保留百分比的流量同時走旗艦，並用評分標準打分兩個回應。評分可以由模型本身完成（LLM-as-judge），或抽樣人工審核。重點是保有一個獨立於級聯門檻的連續品質訊號，如此劣化會作為該訊號的飄移浮現，而不是成為下游的意外。

程式碼與可觀測性的複雜度成本

路由圖中的每增加一個模型，就多一個要評估、監控，且在供應商釋出新版時要更新的對象。兩層級聯尚可管理；一個含五個模型、針對程式碼、RAG、聊天、代理與邊緣案例的分路的分類器路由，複雜度就遠高於它取代的單一模型。當工作負載的規模足以支撐，這種複雜度值得；低於該規模，維護路由層花的工程時間可能超過它帶來的節省。務必如實評估你的量級門檻。

聚合器在哪些方面有幫助（以及在哪些方面沒有）

LLM 聚合器（把多個模型包在一個相容 OpenAI API 背後的服務）以兩種方式影響路由。兩者都值得理解，因為「我要不要在路由堆疊裡用聚合器？」的答案取決於你在意哪一種作用。

真正的幫助：移除整合成本

基於供應商原生 API 構建級聯或分類器路由意味著管理多個 SDK、多組金鑰、多個結算面，還有多家供應商各自的細節（逾時行為、錯誤格式、限流語意）。對多模型路由而言，這個負擔是真實存在的。像 CometAPI 這樣的聚合器把所有模型都暴露在一個相容 OpenAI 的端點後面，意味著實作路由只需改 model 參數，不用切換供應商、不用分別的金鑰、不用額外的可觀測層。對那些路由的主要障礙在於整合成本而非品質評估成本的團隊，這是決定性因素。

需要注意的地方：內建路由層

有些聚合器提供「智慧路由」或「模型優化器」功能，會根據查詢替你選模型。這對原型設計有用，但通常不是生產的正確預設。原因是路由決策是你堆疊裡最依賴工作負載特性的事情之一：什麼才算「難到需要升級」，取決於你的評估標準、延遲預算、品質底線與成本上限。通用的路由層不可能知悉這些。大多數生產系統更適合使用薄而透明的聚合器（暴露你本來可直接存取的同款模型，用一組憑證與一張帳單），再在其上方實作自己的路由邏輯，而不是使用無法調校的黑箱式路由層。

遷移作戰手冊

從單一模型的生產工作負載安全地一步步走到路由化。貫穿全程的原則是：每次做可單獨回退的改動，且在下一步前先量測每一步的影響。

• 為現有工作負載加上儀表化。 記錄每個請求的模型、輸入/輸出 token、成本、延遲與查詢類型標籤。至少跑一週以建立基線。沒有這些，後續每一步都是在猜。
• 建立評估集。 蒐集 100–500 個具代表性的查詢及你信任的參考輸出。這是你在每一步把級聯與單一模型基線比較的保留集。
• 找出量體最大的查詢類型。 從儀表化資料找出流量占比最高的類別。這會是你試點級聯的地方。不必是最簡單的類別，只要是量體最大的，因為節省集中於此。
• 為該單一查詢類型做級聯原型。 兩層：先較便宜模型，如果未通過品質門檻再走旗艦。先在評估集上跑。把成本與品質與單模型基線比較。若品質維持且成本下降，往下進；若品質下滑，收緊門檻再試。
• 以流量百分比灰度釋出。 先對該類型的 5–10% 生產流量上線。至少跑一週。監控級聯的升級率、每請求成本、各層延遲，以及金絲雀路徑的品質比較。若指標符合原型預測，擴至 25%，再 50%，最後 100%。
• 對下一個查詢類型重複上述流程。 當第一個類型完全遷移且節省落袋後，再移至下個量體最大的類別。每個級聯都是獨立決策；不要假設對某一類有效的模式對另一類也有效。
• 加入持續的品質金絲雀。 當多個類型都跑在級聯上後，永久維持保留的金絲雀路徑，以 5% 流量走旗艦做評分。這是你攔截無聲劣化的預警系統，也是讓路由層在模型更新時仍可信的關鍵。

什麼情況下不值得做路由

誠實面對。有些工作負載的路由工程投入不會回本，及早辨識能省時間：

• 單模型工作負載且確實一個模型對所有需求都是正解。 如果評估集顯示在較便宜層級全域都有顯著的品質下滑，級聯就無從節省。被推理能力綁住的程式碼生成就是例子：Haiku 太常過不了門檻，級聯無法省錢。
• 極低流量。 當 LLM 花費每月大約低於 $200 時，建置與維護路由層的工程時間通常超過節省。門檻因工作負載而異，但確實存在。務必如實判斷你的支出是否足以支撐這些工作。
• 受監管環境且供應商記錄（vendor-of-record）很重要。 如果你的合規要求是所有生產流量必須走某一特定供應商關係，多模型路由會讓溝通複雜。仍可能有同供應商內的路由選項（在 Anthropic 內 Sonnet → Opus；在 OpenAI 內 GPT-5 nano → GPT-5.5），但跨供應商的路由會更難正當化。

誠實的定調：當你的工作負載量體高、查詢難度不均、且你有評估基礎設施能辨識級聯何時產生可接受品質時，路由會回本。大多數有一定規模的生產工作負載都符合這個描述；也有一些不符合，改以單一模型出貨更快。兩種選擇都可被證成。

接下來要看什麼： 如果你還沒讀過本文所依賴的各模型價目表，配套文章 2026 LLM API 定價比較：GPT-5.5、Claude Sonnet 4.6、Gemini 3.5 Flash 與 DeepSeek V4 是基礎。那裡的定價資料能讓本指南中的成本計算在你的特定工作負載上變得具體可操作。