簡短回答： 在應用程式內進行路由，然後使用單一 CometAPI 金鑰與相容 OpenAI 的基底 URL https://api.cometapi.com/v1 來呼叫所選模型。將重複、易於驗證的工作送到低成本層；將對延遲敏感的客戶互動送到快速層；將模糊或高影響的工作送到高準確度層。把這些標籤作為你自己的策略，而不是通用的模型排名，並在相同的測試集上衡量每個層級。
本指南使用精簡的 Python 範例、受限的備援，以及會計入重試與被拒輸出的成本模型，來建立該三層路由器。範例使用 CometAPI 目錄中的當前模型 ID，但路由邏輯與模型解耦，因此更換模型時無需重寫應用程式。
什麼是 LLM 路由？
LLM 路由是將每個請求發送到最符合其任務、延遲目標、品質要求與預算的模型或服務層的過程。
應該如何依任務路由 LLM 請求？
截至 2026 年 8 月 20 日，下列模型 ID 與目錄定價欄位可透過公開的 CometAPI Models API 取得。以下估計的消費者費率，係依據目錄當前的 ratio 值套用至其輸入與輸出基準價格，並遵循 CometAPI pricing guide。在生產環境使用前，請確認你帳戶顯示的最終費率。
| 路由 | 適用情境 | 範例模型 | 預估 USD / 每 1M tokens | 第一備援 |
|---|---|---|---|---|
| 低價 | 標註、擷取、去重 | deepseek-v4-flash | $0.176 輸入 / $0.528 輸出 | 快速 |
| 快速 | 客戶回覆、摘要、即時助理 | gemini-3.7-flash | $0.60 輸入 / $3.00 輸出 | 低價，然後高準確 |
| 高準確 | 政策審查、複雜推理、高影響草稿 | claude-opus-5 | $4.00 輸入 / $20.00 輸出 | 快速 |
「快速」表示該路由有延遲目標；「高準確」表示其有更嚴格的品質目標。這兩個標籤都不代表某個模型永遠最快或最準確。請在你的實際流量上，對 p50 與 p95 延遲、任務通過率，以及每個被接受輸出的成本進行基準測試，再將對應關係固定化。
如何為 LLM 路由設定 CometAPI？
你需要一把 CometAPI API 金鑰、Python 3.10 或更新版本，以及 OpenAI Python 套件。請將金鑰儲存在伺服器端，而非原始碼中。
pip install openaiexport COMETAPI_KEY="your-key-here"
此範例使用 POST /v1/chat/completions。CometAPI 將其記錄為跨多家供應商的共用介面，但參數行為仍可能因模型而異。新增供應商特定欄位前，請檢查當前的模型條目與 Chat Completions reference。
建立 LLM 路由器需要什麼？
- 將穩定的任務對映到服務層。除非單靠應用程式訊號不足，否則不要讓另一個 LLM 來分類每個請求。支援標籤通常可預測地屬於低成本層；即時回覆對延遲敏感；政策審查應置於最嚴格的品質門檻之後。
- 驗證輸出。HTTP 成功狀態不代表結果可用。為路由器提供任務特定的驗證器。分類驗證器可以檢查允許的標籤；客戶回覆驗證器可強制長度與禁止的聲明；結構化流程可驗證 JSON 結構描述。
- 窄幅備援。在逾時、
408、429、暫時性5xx，或有限度的品質門檻失敗時才嘗試下一個核准路由。不要用另一個模型來掩蓋畸形輸入、無效金鑰或不支援的參數。
如何用 Python 建立 LLM 路由器？
import osimport timefrom openai import APIError, OpenAIclient = OpenAI( api_key=os.environ["COMETAPI_KEY"], base_url="https://api.cometapi.com/v1", max_retries=0, timeout=20,)MODELS = { "cheap": "deepseek-v4-flash", "fast": "gemini-3.7-flash", "accurate": "claude-opus-5",}# Put the preferred tier first; later tiers are fallbacks.ROUTES = { "tag": ["cheap", "fast", "accurate"], "reply": ["fast", "cheap", "accurate"], "policy_review": ["accurate", "fast", "cheap"],}def retryable(error): status = getattr(error, "status_code", None) return status is None or status in {408, 429} or (status and status >= 500)def route(task, prompt, validate=lambda text: True): attempts = [] for tier in ROUTES.get(task, ROUTES["reply"]): model = MODELS[tier] started = time.perf_counter() try: response = client.chat.completions.create( model=model, messages=[{"role": "user", "content": prompt}], max_tokens=400, ) text = response.choices[0].message.content or "" attempts.append({ "tier": tier, "model": model, "latency_ms": round((time.perf_counter() - started) * 1000), "accepted": validate(text), }) if attempts[-1]["accepted"]: return { "text": text, "route": tier, "model": model, "usage": response.usage.model_dump() if response.usage else None, "attempts": attempts, } except APIError as error: attempts.append({"tier": tier, "model": model, "status": error.status_code}) if not retryable(error): raise raise RuntimeError(f"No route passed: {attempts}")if __name__ == "__main__": result = route( "reply", "Reply to a customer asking when their refund will arrive. Do not promise a date.", validate=lambda text: 30 <= len(text) <= 600 and "guarantee" not in text.lower(), ) print(result)
如何在備援前限制重試次數？
將 SDK 重試設為 0，並以明確的限制包裹每次模型呼叫。下方的輔助函式僅對可重試的 API 失敗重試一次，之後丟出錯誤，方便外層路由移至下一個核准層級。
MAX_ATTEMPTS_PER_MODEL = 2def call_model(model, prompt): for attempt in range(1, MAX_ATTEMPTS_PER_MODEL + 1): try: return client.chat.completions.create( model=model, messages=[{"role": "user", "content": prompt}], max_tokens=400, ) except APIError as error: if not retryable(error) or attempt == MAX_ATTEMPTS_PER_MODEL: raise time.sleep(min(0.5 * (2 ** (attempt - 1)), 2.0))
在 route() 中，以 call_model(model, prompt) 取代直接呼叫 client.chat.completions.create(...)。在三層架構下，一個請求最多會停止於六次供應商呼叫；品質驗證失敗仍僅在每個層級升級一次，而不是對同一輸出重試。
以 python3 llm_task_router.py 執行。之後若要更換供應商或模型世代，更新 MODELS 即可；任務策略與回應合約維持在同一處。
範例只使用所選模型的共通參數。檢查模型相容性後，再透過轉接層新增模型特定的 token 控制。
如何測試 LLM 路由策略？
先驗證決定性策略會選到預期的主要層級。這些是路由預期，而非供應商效能結果：
| 測試請求 | Task 值 | 預期主要路由 |
|---|---|---|
| 指派一個支援分類 | tag | 低價 |
| 起草一則對客戶的回覆 | reply | 快速 |
| 審查一份模糊的退款政策 | policy_review | 高準確 |
成功的即時試跑會回傳答案及所選層級、模型 ID、token 使用量與所有嘗試。實際 token 與延遲值會有所差異：
{ "text": "...", "route": "fast", "model": "gemini-3.7-flash", "usage": { "prompt_tokens": "measured value", "completion_tokens": "measured value" }, "attempts": [ { "tier": "fast", "model": "gemini-3.7-flash", "latency_ms": "measured value", "accepted": true } ]}
若要進行真正的比較，請用相同的標註請求同時測三個模型。記錄任務通過率、p50 與 p95 延遲、錯誤率、輸入與輸出 tokens、備援率，以及人工審查率。通常最重要的指標是「每個被接受輸出的成本」，而不是每次 API 呼叫的成本。
多模型路由要花多少錢？
為公平比較，使用同一種工作負載形狀。假設總計 100 萬 tokens：80 萬輸入、20 萬輸出。以 2026 年 8 月 20 日檢查的目錄導出費率估算：
| 路由 | 計算式 | 預估成本 |
|---|---|---|
| 低價 | 0.8 × $0.176 + 0.2 × $0.528 | $0.25 |
| 快速 | 0.8 × $0.60 + 0.2 × $3.00 | $1.08 |
| 高準確 | 0.8 × $4.00 + 0.2 × $20.00 | $7.20 |
若流量為 60% 低價、30% 快速、10% 高準確，預估的混合 token 成本約為每 100 萬總 tokens $1.19。若把相同組合全部送到高準確路由，則約為 $7.20（基於上述假設）。這是定價計算，並不代表混合策略能達到你的品質目標。
重試與拒絕會改變結果。一次性 5% 重試率會把 $1.19 提升到約 $1.25。若低成本輸出未通過驗證而整個請求改在高準確層重送，請同時計入兩次呼叫。請追蹤被接受的輸出，以免表面上的便宜模型掩蓋審查或重生產成本。
最常見的 LLM 路由失敗為何？
| 訊號 | 如何處理 |
|---|---|
| 400 或無效請求 | 修正負載。不要備援。 |
| 401 | 重新載入或輪替 API 金鑰。不要重試。 |
| 403 | 檢查模型權限與不支援的欄位。 |
| 429 | 帶抖動退避、降低並發，若策略允許再使用核准的備援路由。 |
| 暫時性 5xx 或逾時 | 嘗試下一個相容路由並保留請求 ID。 |
| 品質門檻未通過 | 升級一次、記錄原因，並在設定的路由清單結束後停止。 |
錯誤與重試指南 建議對速率限制與暫時性平台失敗採用帶抖動的退避重試，而對畸形請求與驗證失敗則應修正。 備援指南 同樣強調有序且明確的模型備援。
應用程式路由 vs. CometAPI Auto：該用哪一個？
- 當你更在乎控制與重現性時，使用應用程式路由。當任務穩定且你需要固定的模型身分、每層預算、自訂驗證器與可稽核的備援順序時，將決策放在程式碼裡。此外，這也便於跨版本比較相同的模型對映。
- 當降低路由維運成本更重要時，使用 CometAPI Auto。將
model=auto設為平衡的預設，或在品質優先時使用model=auto-high。CometAPI 會依請求特徵與當前路由池動態選擇合格模型，因此底層模型可能變動；當每次執行都必須使用相同模型或模型特定參數時，Auto 的適用性較低。
如何在生產環境執行 LLM 路由？
- 重新整理模型登錄。部署或啟動時呼叫
GEThttps://api.cometapi.com/api/models，若配置的 ID 或所需端點缺失則使發布失敗。模型 ID、價格與能力可能變動。 - 將供應商特定選項留在路由器之外。共用的 Chat Completions 介面不代表每個參數都相同。例如，對
logprobs、推理控制或多候選的支援可能不同。請把這些差異放在經過測試的轉接層中。 - 對流量與輸出設限。請在請求離開應用程式前限制並發、對
429採用帶抖動的指數退避，並設定輸出 token 上限。CometAPI 的 速率限制指南 也建議相同的應用程式端控制。 - 記錄決策。記錄任務類型、策略版本、所選層級、模型 ID、延遲、token 使用量、驗證結果、重試次數、備援原因與成本估計。避免記錄機密或不必要的客戶內容。
- 以證據推進路由。為每個任務保留一組帶標註的評估集。逐步推出對映變更、與先前策略比較，並保留快速回滾路徑。
常見問答
CometAPI 會自動決定哪些模型是低價、快速或高準確嗎？
本教學將該策略放在應用程式碼中。CometAPI 提供共用金鑰、基底 URL、模型目錄、Chat Completions 介面與已文件化的備援構件。你的團隊定義各層的含義與通過測試的模型。
一把 CometAPI 金鑰可以呼叫不同供應商的模型嗎？
可以。對相容 OpenAI 的文字路由，使用 https://api.cometapi.com/v1 並變更 model 值。部署前應檢查當前目錄。
為什麼不把所有請求都送到最便宜的模型？
最低的 token 費率可能因輸出未通過驗證、需要重試或導致人工審查而變得昂貴。請比較每個被接受結果的成本，並將高影響任務置於更嚴格的品質門檻之後。
品質失敗是否應觸發備援？
僅在失敗可由機器偵測且升級是受限的情況下。結構描述錯誤、缺少必要欄位或違反禁止承諾可正當化一次升級。模糊的不滿應成為評估資料，而不是無限制的重試迴圈。
模型對映應該多久更換一次？
當當前目錄資料與可重複的評估顯示更好的權衡時再更換。不要只因為目錄出現新名稱就輪換模型。
我可以之後加入 OpenAI 的模型嗎？
可以。將當前相容 OpenAI 的模型 ID 加入 MODELS，用相同的請求與回應合約測試，並將其置於路由順序。客戶端、金鑰與基底 URL 保持不變。
如何維持 LLM 路由策略的可維護性？
最簡單的多供應商路由器不是自動的黑盒，而是一份簡短、具版本的任務策略，後盾是共用 API 存取、最新模型中繼資料、品質驗證器與窄幅的備援鏈。CometAPI 將連線工作簡化為一把金鑰與一個相容 OpenAI 的基底 URL；你的應用程式則掌控成本、延遲與品質決策。