多模型路由怎麼做：按任務分流降低大模型成本，質量不明顯下滑
多模型路由的思路是按任務難度把請求分到不同檔位的模型：補全、分類這類短任務交給輕量檔，日常編碼用中檔，只有長鏈路 agent 和複雜重構才走旗艦檔。按 cdnping 在 2026-10-17 抓取的 OpenRouter 公開標價，輕量檔和旗艦檔的單價能差十倍以上。如果簡單任務佔了你大部分 token，把它們移走，賬單會降得比較多；分錯檔則會掉質量。下面講怎麼分、怎麼估算、怎麼驗證質量。
不同檔位的模型單價差多少
下表來自 cdnping 在 2026-10-17 對 OpenRouter 公開模型目錄的一次抓取（模型監測 /models 的資料來源），單位是美元 / 每百萬 token。這是 OpenRouter 自己的標價，不一定等於廠商直連價格，以各家官方價格頁為準。表裡按價格區間歸檔，不列具體型號；想看當前是哪些模型，直接開啟 /models。
| 檔位（按價格歸類） | 輸入單價 | 輸出單價 | 快照中的樣本 |
|---|---|---|---|
| 輕量檔 | 0.10 – 0.15 | 0.47 – 0.60 | 4 個模型 ID |
| 中檔 | 0.37 – 0.825 | 1.25 – 4.125 | 3 個模型 ID |
| 旗艦檔 | 2 – 4 | 6 – 12 | 8 個模型 ID |
| 特例 | 0.304 | 11.936 | 1 個模型 ID，輸入便宜、輸出很貴 |
從這張表能讀出兩點：
- 輕量檔和旗艦檔的輸入單價差約 13–40 倍，輸出單價差約 10–25 倍。如果某類任務在低檔上的評測透過率和旗艦檔相當，這部分差價就是可以省下的錢。
- 輸入和輸出要分開算。那個“特例”說明不能只看一個綜合價：如果你的任務輸出很長，它可能比旗艦檔還貴；如果主要是讀長文、輸出很短，它又很便宜。
快照只有一個時間點。cdnping 從 2026-10-17 開始採集，歷史很短，價格變化請以 /models 和 官網動態 /changes 的最新記錄為準。
哪類任務該用哪一檔模型
分流的前提是先把自己的請求分類。下面是一個起步用的對照表，你需要用自己的評測集去修正它。
| 任務型別 | 典型例子 | 輸入 / 輸出特徵 | 起步檔位 | 什麼情況下升檔 |
|---|---|---|---|---|
| 補全、分類、格式化 | 程式碼行補全、工單打標籤、JSON 修正、提取欄位 | 輸入短，輸出極短 | 輕量檔 | 分類準確率低於基線，或輸出格式錯誤率上升 |
| 日常編碼 | 單檔案修改、寫單測、程式碼審查、解釋報錯 | 輸入中等（幾千 token），輸出中等 | 中檔 | 跨檔案改動、需要理解專案結構 |
| 複雜 agent | 多步工具呼叫、跨模組重構、長鏈路排錯 | 輸入極長且多輪累積，輸出中等 | 旗艦檔 | 一般不降檔，可在子步驟裡呼叫低檔 |
| 中文長文字 | 合同、長文件摘要、批次改寫 | 輸入很長，輸出較短 | 中檔或國產模型 | 需要嚴格推理或事實核對時 |
幾條經驗規則：
- 按實際的請求數和 token 分佈來分，而不是按“重要程度”。編碼場景裡常見的情況是：補全和分類次數多但單次 token 少，agent 任務次數少但每次輸入 token 多。兩頭都要算。
- agent 內部也可以分流。一個 agent 任務裡，規劃和最終修改走旗艦檔，讀檔案後的摘要、日誌過濾、命令輸出解析可以交給輕量檔。
- 中文長文字先看輸入單價。這類任務輸出短、輸入長，費用主要由輸入單價決定。
怎麼按輸入、輸出 token 估算月成本
公式很簡單：
月成本 = Σ（該類任務月輸入 token ÷ 1,000,000 × 輸入單價
+ 該類任務月輸出 token ÷ 1,000,000 × 輸出單價）
下面用一個假設的月度工作量舉例（數字是示例，不代表任何真實團隊）：
| 任務型別 | 假設請求量 | 每次輸入 / 輸出 | 月輸入 | 月輸出 |
|---|---|---|---|---|
| 補全、分類 | 20,000 次 | 1,500 / 100 | 30M | 2M |
| 日常編碼 | 3,000 次 | 8,000 / 1,000 | 24M | 3M |
| 複雜 agent | 100 次 | 300,000 / 15,000 | 30M | 1.5M |
| 中文長文字 | 500 次 | 30,000 / 2,000 | 15M | 1M |
按上面快照裡的單價代入：
- 全部走旗艦檔（輸入 2、輸出 10）：99M × 2 + 7.5M × 10 = 198 + 75 = 約 273 美元。
- 分流後：補全分類走輕量檔（0.15 / 0.6）約 5.7 美元；日常編碼走中檔上沿（0.825 / 4.125）約 32.2 美元；複雜 agent 仍走旗艦檔（2 / 10）75 美元；中文長文字走中檔下沿（0.37 / 1.25）約 6.8 美元。合計約 119.7 美元，比全旗艦少約 56%。
這個例子裡，省下的錢主要來自兩塊：輸入量大的補全分類和中文長文字。agent 這一塊沒動，仍然是最大的單項支出。所以下一步最佳化通常是減少 agent 的輸入，比如裁剪上下文、利用供應商的快取計價（如果有）、把子步驟下放到低檔。
可以直接改數字用的指令碼：
# 單價：美元 / 每百萬 token。請替換為你查到的最新價格。
TIERS = {
"light": (0.15, 0.60),
"mid_low": (0.37, 1.25), # 中檔下沿
"mid": (0.825, 4.125), # 中檔上沿
"flagship": (2.0, 10.0),
}
# 每類任務：(月請求數, 每次輸入 token, 每次輸出 token, 分到的檔位)
WORKLOAD = {
"completion": (20000, 1500, 100, "light"),
"coding": (3000, 8000, 1000, "mid"),
"agent": (100, 300000, 15000, "flagship"),
"long_zh": (500, 30000, 2000, "mid_low"),
}
def cost(workload, override=None):
total = 0.0
for name, (n, tin, tout, tier) in workload.items():
tier = override or tier
pin, pout = TIERS[tier]
c = n * (tin * pin + tout * pout) / 1_000_000
print(f"{name:<12}{tier:<10}{c:>10.2f}")
total += c
print(f"{'total':<22}{total:>10.2f}\n")
return total
routed = cost(WORKLOAD)
baseline = cost(WORKLOAD, override="flagship")
print(f"節省比例: {1 - routed / baseline:.0%}")
請求量和 token 數不要拍腦袋，從你現有的請求日誌裡統計一週，按任務型別分組取中位數和 P90 就夠用。
怎麼確認質量沒有明顯下降
省錢的部分好算，降質的部分需要驗證。可以照下面的步驟做：
- 建一個小評測集。每類任務從真實請求裡抽 30–100 條，帶上你認可的參考答案或判定標準（單測是否透過、分類是否正確、格式是否合法）。
- 離線對比。同一批樣本分別跑當前模型和候選低檔模型，記錄透過率。設定可接受的差距，例如透過率下降不超過幾個百分點，這個閾值由你的業務決定。
- 影子流量。上線前把一小部分真實請求同時發給低檔模型，只記錄不返回，比較結果。
- 自動升檔。低檔輸出不合格時（JSON 解析失敗、單測不過、置信度低），自動用高一檔重試。記錄升檔率，升檔率過高說明這一類不該放在低檔。
- 持續監控。第三方推理供應商可能更換量化精度（如 fp8、fp4），同一個模型 ID 的表現會變。/models 會記錄各供應商的量化精度、可用率和下架、調價變化，可以作為一個外部訊號。
自建路由還是用聚合閘道器，怎麼選
| 維度 | 自建路由 | 聚合閘道器 |
|---|---|---|
| 分流規則 | 完全自定義，可以按業務欄位路由 | 通常由閘道器決定，或只能選能力組 |
| 接入成本 | 要分別對接各家 API、金鑰、計費 | 一個介面地址、一個金鑰 |
| 賬單 | 多家分別結算，可能需要海外支付方式 | 統一結算 |
| 故障切換 | 要自己寫重試、熔斷、備用供應商 | 閘道器處理，但你看不到全部細節 |
| 可觀測性 | 日誌都在自己手裡 | 依賴閘道器公開的資料 |
| 合規與資料 | 直接和廠商簽約 | 需要確認閘道器的資料處理方式和授權情況 |
一個粗略的判斷方法：如果你的請求量大、任務型別穩定、有人維護基礎設施，自建路由更可控；如果是小團隊，主要在 Claude Code、Codex 這類編碼工具裡用模型，不想維護多套金鑰和賬單，聚合閘道器的接入成本更低。無論哪種，都要遵守各模型服務的條款和當地法規，部分服務存在地區限制，以官方說明為準。
作為一種實現示例，AGI Plan（是 cdnping 的商業合作方）把模型分成四個能力組：前沿推理（長鏈路 agent、複雜重構）、均衡通用（日常編碼和程式碼審查）、國產旗艦（中文長文字、批次任務）、高速輕量（補全、分類、格式化），由排程層按任務難度把請求分到對應的組。這和上文的四層分法是對應的。它按 CU 計量，1 CU 等於基準模型 1,000 個輸出 token，也公開了逐小時、逐能力組的請求成功和失敗計數（https://agiplan.dev/api/status/requests?month=YYYY-MM），cdnping 的 /status/agiplan 會映象展示。站方說明自己不是官方授權渠道，選用前請看 官網說明 和 模型頁。
自建路由的最小配置怎麼寫
如果選擇自建，可以從一份簡單的規則檔案起步，先按任務型別硬編碼，跑穩之後再考慮用分類器自動判斷難度：
routes:
- match: { task: [completion, classify, format] }
tier: light
fallback: mid
- match: { task: [code_edit, code_review, unit_test] }
tier: mid
fallback: flagship
- match: { task: [agent, refactor] }
tier: flagship
fallback: flagship_backup # 另一家供應商的同檔模型
- match: { task: [long_zh, summarize] }
tier: mid
fallback: flagship
escalate_on: [json_parse_error, test_failed, empty_output]
max_retries: 1
上線前再過一遍這張檢查表：
- 每類任務都有評測集和透過率基線
- 每個檔位至少有一個備用供應商，並在 API 狀態 /status 上看過各入口近期的可用情況
- 在 線上測速 裡測過從你的網路到各 API 的首次連線和往返延遲，延遲高的入口不要放在補全這類對時延敏感的路徑上
- 日誌裡記錄了每次請求的檔位、token 數、是否升檔
- 訂閱了 /changes 或 /reports，調價、下架時能及時調整單價表
本週可以先做的三件事
- 從請求日誌匯出最近一週的資料，按上面四類統計請求數和 token 中位數。
- 把數字填進估算指令碼，看分流後能省多少，以及哪一類是最大支出。
- 先只把補全和分類這一類移到輕量檔，跑一週影子流量，確認透過率後再動下一類。