代理模型成本與品質折衷框架
Cost vs. Quality Tradeoff Framework for Agent Models
代理模型成本與品質折衷框架 介紹一套三步驟流程,協助使用者根據任務品質門檻與實際成本,挑選最具成本效益的模型。
- 品質門檻設定:先決定任務對準確度的最低需求,低於門檻即使便宜亦不合格。
此框架幫助工程師用實際成本與質量分數挑選最具成本效益的代理模型,避免因排行榜高分而付高價,並可隨時重新評估模型與價格變動。
依照排行榜順位選擇代理模型會支付前沿價格,即使較便宜的模型在相同準確度下也能處理相同任務。需要回答的問題不是哪個模型得分最高,而是哪個模型在你面前的任務中既足夠好又最便宜。
本指南提供三步框架來做出此決策。你先設定任務所需的品質門檻,對自己的範例測量每點品質的成本,然後選擇能以最低成本通過門檻且有餘裕的模型。
TL;DR
- 在比較模型前先為每個任務設定品質門檻。低於門檻的模型即使再便宜也會被排除。
- 在 20 至 50 個自己的範例上分別跑一個便宜模型、一個中階模型和一個前沿模型,用同一套評分標準評分,將成本除以分數得到每點品質的成本。
- 挑選能以低於你觀察到的跑間分數波動多於門檻的最低成本模型。
- 從每個回覆的
usage.cost欄位讀取成本,而不是將列出的費率乘以估計的 token 數。 - 當候選模型或其價格變動時重新執行比較。
排行榜順位未告訴你的事
排行榜會平均一個模型在與你任務無關的多項任務上的結果。排名第一的模型在編碼任務上不一定在你結構化資料抽取任務上排名第一,而在推理基準上看似不起眼的中階模型,可能在你的 FAQ 流量上已足夠準確達到你的標準。
代理任務往往很窄,例如分類工單、擷取單一欄位,或在模型不確定時升級。較便宜的模型是否能在窄任務上達到前沿模型相同的準確度,這是一項測量,排行榜不會為你完成這項工作。
代理的成本不僅是一次提示和一次回覆。一次聊天完成只計費一次。代理需為每一次工具呼叫、每一步中間結果以及每一次重試付費。三步迴圈在回傳答案前至少會為每個 token 付費三次。若你僅依排行榜排名選擇模型,可能會為一個本可由較便宜模型以相同準確度處理的任務,支付前沿模型價格的三倍。
第一步:定義任務所需的品質門檻
在比較任何東西之前,先決定「足夠好」在此任務中的含義。每個工作都有不同的門檻,且它是所有後續步驟所經過的篩選條件。
若錯誤答案會帶來風險,例如合規、醫療或法律審查,請設定較高的門檻並接受較高的每次請求成本。若任務是高量級支援或聊天,整體結果比單一回覆更重要。能正確處理 90% 常規請求並順利升級剩餘 10% 的較便宜模型,可能對該任務是可接受的。你決定門檻位置,框架則根據此測量。
對延遲敏感的工作,例如詐騙偵測與即時聊天,會加入第三個限制。即使模型便宜且準確,但如果速度對任務而言太慢,也會在成本或準確度考量之前被淘汰。
速度、成本與準確度無法同時最大化。決定任務的限制條件,候選清單即可縮小。
若不確定任務的定位,起點可先用中階模型處理所有專案,然後依測量結果將任務分組。若中階模型的表現超過需求,則轉向更便宜的模型;若中階模型未達門檻,則升級。測量決定每個任務所需的層級,而非事先猜測。

第 2 步:測量您自己的範例中每個品質點的成本
擷取您的代理實際會看到的檔案、工單和提示。使用您自己的流量,而非公開資料集或基準範例。重點是測量您的任務。
執行一個便宜方案、一個中階方案以及一個前沿方案於上述範例。以一致的評分標準對它們進行評分。對於像分類這樣的確定性任務,使用與固定答案的完全匹配,適用於只有一個值正確的情況。對於開放式任務,使用 LLM 作為評審來評估品質。我們的LLM-as-a-judge guide說明如何設定。當每個候選項返回相同輸出結構時,評分更容易,這正是結構化輸出和 response_format的用途。
將模型每 1,000 次請求的成本除以其品質分數,即可得到可直接比較的每品質點成本,並可在不同規模的測試集之間比較。以簡短指令碼執行此操作,交換一個模型字串並從每個回應中的 usage 物件讀取每請求成本。我們在每個非串流回應以及每個串流回應的最後訊息中返回 usage 物件,無需任何額外請求引數,詳見usage accounting docs。usage.cost 為我們對該請求向您的帳戶收費的金額(USD)。OpenAI Python SDK 會保留它未定義的回應欄位,因此 r.usage.cost 可作為屬性使用。
import json
import os
from openai import OpenAI
client = OpenAI(
base_url="https://openrouter.ai/api/v1",
api_key=os.environ["OPENROUTER_API_KEY"],
)
ROUTING_PROMPT = open("routing_prompt.txt").read()
test_set = json.load(open("test_set.json")) # 20-50 of your own {"ticket": ..., "label": ...} examples
candidates = [
"openai/gpt-5.6-luna",
"google/gemini-3.7-flash",
"anthropic/claude-opus-5",
]
for model in candidates:
total_cost, correct = 0.0, 0
for ex in test_set:
r = client.chat.completions.create(
model=model,
messages=[
{"role": "system", "content": ROUTING_PROMPT},
{"role": "user", "content": ex["ticket"]},
],
)
total_cost += r.usage.cost
answer = (r.choices[0].message.content or "").strip()
correct += int(answer == ex["label"])
score = correct / len(test_set)
points = score * 100
cost_per_1k = total_cost / len(test_set) * 1000
cost_per_point = cost_per_1k / points if points else float("inf")
print(f"{model}: score={score:.0%} cost/1K=${cost_per_1k:.2f} cost/point=${cost_per_point:.4f}")一個回應可能沒有文字內容,例如模型拒絕時,指令碼將缺失內容視為空答案,將其算作錯誤,並將其成本計入總額。得分為零的模型每點成本為零,指令碼會為其輸出 inf 而非除以零。
以下是一個支援路由任務的實作範例。假設每個請求傳送約 700 個輸入 token(工單加一個簡短系統提示),並回傳約 150 個輸出 token。每 1,000 次請求成本為 (700 / 1M × input price) + (150 / 1M × output price),乘以 1,000。每品質點成本為該成本除以品質分數。
價格為我們 2026-09-18 在model catalog 上列出的費率,針對 GPT-5.6 Luna、Gemini 3.7 Flash 與 Claude Opus 5。它們是目錄列出的模型級別價格。單獨供應商端點及彈性與優先 service tiers 以各自的費率計費,且 GPT-5.6 Luna 在 272,000 或以上提示 token 的請求上收費更高。token 數量與品質分數僅為示例,您自己的執行將取代它們。
| 模型 | 價格(輸入/輸出,每 M tokens) | 成本 / 1K 請求 | 品質分數 | 成本 / 品質點 | 是否達到 85% 門檻? |
|---|---|---|---|---|---|
openai/gpt-5.6-luna | $0.20 / $1.20 | $0.32 | 82 | $0.0039 | 否(−3) |
google/gemini-3.7-flash | $0.75 / $3.75 | $1.09 | 89 | $0.0122 | 是(+4) |
anthropic/claude-opus-5 | $5.00 / $25.00 | $7.25 | 97 | $0.0747 | 是(+12) |
按框架執行的順序閱讀表格。先以門檻為門檻。以 85% 為例,GPT-5.6 Luna 在 82% 下被淘汰,其低每品質點成本不重要。低於門檻的模型無論每點成本多便宜都被取消資格。剩下的是 Gemini 3.7 Flash 與 Claude Opus 5。
在兩者中,選擇較便宜者。Gemini 3.7 Flash 每 1,000 請求費用 1.09 美元。Claude Opus 5 的費用為 7.25 美元,該任務並未需要此分數。Gemini 3.7 Flash 為首選,並以 4 分差達標。
改變情況,答案也會改變。若錯誤路由意味著 SLA 違約,您將門檻設為 95%,僅 Claude Opus 5 符合,您需支付 7.25 美元。目標不是挑選最高分數,而是瞭解哪個模型以最低成本通過您的門檻,並觀察超過門檻時所需支付的差額。
第 3 步:選擇最便宜且能以一定邊際超過門檻的模型
選擇最便宜且能以一定邊際超過門檻的模型,而非直接贏得最高分的模型。邊際重要,因為數值會變動。
模型評分會因供應商更新權重、你自己的流量隨時間變動,以及新版本改變情況而漂移。應以觀察值設定邊際,而非固定百分比。多次執行候選模型,或在全新流量切片上執行,記錄每次執行評分變動,並要求勝者的分數必須超過觀測到的波動幅度。
若模型僅在單一小樣本中達到門檻,則在投入使用前必須先超過更高的內部目標,以避免正常變異使其在實際環境中跌破門檻。
在幾個任務上應用,此框架如下所示。成本數字使用與上表相同的列價,並以每行所示的輸入與輸出 token 大小計算。品質門檻僅為示例,實際記錄的成本來自 usage.cost。
| 任務 | 品質門檻 | 能超過門檻的最便宜等級 | 成本 / 1K 次請求 |
|---|---|---|---|
| 支援篩檢(700 進 / 150 出 tokens) | 80% | 便宜,openai/gpt-5.6-luna | $0.32 |
| 程式碼審查(4,000 進 / 1,000 出 tokens) | 88% | 中階,google/gemini-3.7-flash | $6.75 |
| 合規審查(3,000 進 / 600 出 tokens) | 95% | 前沿,anthropic/claude-opus-5 | $30.00 |
方法在每一行相同,答案之所以不同是因為門檻不同。測量到的折衷在你測量的那一天是正確的。當發布新模型時請重新檢查,因為昨天能超過門檻的模型現在可能與僅略低於門檻的模型成本相同。
模型或價格變更時請重新檢查比較
新模型經常發布,且現有模型的價格亦會變動。2026 年 5 月至 9 月期間,我們的目錄新增了四個 Gemini Flash 版本:Gemini 3.5 Flash(2026‑05‑19)、Gemini 3.6 Flash(2026‑07‑21)、Gemini 3.7 Flash(2026‑08‑13)以及 Gemini 3.8 Flash(2026‑09‑02)。幾個月前執行的比較可能已過時,因此每當候選模型更新或價格變更時請重新執行。
重新執行成本低。 我們提供一個 OpenAI 相容的 API,切換模型只需改動設定。 基本 URL、金鑰與 SDK 不變。 只需將模型字串從 openai/gpt-5.6-luna 改為 anthropic/claude-opus-5,上述指令碼即可對新模型執行。
你不需要為每個想測試的供應商撰寫新的整合,這使得在新版本發布的同一週即可重新執行範例。這一行程式碼的切換正是 model routing 在多代理設定中所依賴的。
兩點確保框架以實際數字為基礎。 我們在你確認前於 model catalog 顯示每個模型的價格,讓比較的成本基於即時資料。 另外,因為每個回應都報告 usage.cost,你測量的支出即為我們實際收費,而非費率卡的估算。
常見問題
AI 模型的成本與品質折衷是什麼?
這是請求成本與模型在你任務上表現之間的折衷。速度是第三個限制。即使模型便宜且準確,但如果速度對任務而言過慢,仍不適合。選擇模型即是決定任務所需的品質並為此付費,而非僅為最高分付費。
哪一個模型最適合 AI 代理?
沒有唯一最優的模型。適合代理的最佳模型取決於其任務必須達到的品質門檻、必須在之內回應的延遲,以及必須處理的量。滿足合規審查門檻的模型成本高於像支援篩選這類任務,而足夠便宜以用於篩選的模型可能無法滿足合規審查的門檻。
AI 模型在代理工作負載中的定價方式是什麼?
我們目錄中的文本模型列出了每個 token 的提示費率和完成費率。部分端點還列出了快取輸入、推理 token、每次請求費用,以及靈活或優先服務等級的費率。代理工作負載在第一次請求之上增加了工具呼叫和重試,因此單個完成的 token 價格低估了單個任務的成本。請在整個代理執行期間衡量成本,並從每個回應中的 usage.cost 讀取。
多代理設計比單一代理更昂貴還是更便宜?
這取決於工作如何分配。多代理設計可以將路由和分類交給便宜的模型,僅在需要時才呼叫更昂貴的模型,這比將所有請求都送到昂貴模型更省錢。它還會增加請求數量,因此請衡量整個執行,而不是假設分割就能省錢。
結論
定義門檻,對自己的範例測試完整執行,並選擇成本最低、能夠超過你在執行間觀察到的波動的模型。保留指令碼和範例集,以便在模型、價格或流量變動時重新執行比較。
參考文獻
- 使用計費 用於每個回應中返回的
usage.cost欄位。 - 結構化輸出 用於
response_format及 JSON 模式回應。 - 服務等級 用於靈活與優先定價。
- 模型目錄 用於當前每模型價格。
- LLM-as-a-Judge: 自動評分 AI 代理輸出 用於評分開放式任務。
- OpenRouter 模型路由如何工作 用於模型之間的路由。
來源:openrouter blog · openrouter.ai