一個 model=auto,把「選哪個模型」交給閘道。
智慧路由(LLM Router) 會依請求內容,從平台數百個模型中即時優選最合適的那一個。你只需把 model 填成 auto——不用挑模型、不用比價、不用追蹤模型迭代。
依實際命中的模型計費,無附加費,用戶端程式碼零改動。命中了哪個模型寫在回應標頭與回應主體裡(見 如何確認實際命中的模型),完全可追溯。
適用場景
- 按語境自動分發:根據使用者當下的語境,自動分配最合適的模型——尤其適合 agent / 應用裡需要多次呼叫模型、又難以預先為每一步寫死選型的場景。
- 成本最佳化:讓簡單任務自動落到更便宜、更快的模型(
auto預設成本優先)。 - 品質最佳化:確保複雜請求被路由到能力更強的模型(
auto:quality_first)。 - 低延遲場景:agent 多輪迴圈、對話即時互動等對回應速度敏感的場景,優先選回應最快的模型(
auto:latency_critical)。 - 統一入口、免選型:不同類型的請求自動分發到各自最適的模型——不必維護「任務 → 模型」對應表,也不必持續追蹤模型迭代、手動比價換名。
快速開始
把model 設為 auto,其餘請求主體和正常呼叫完全一致。base_url 使用 https://aihubmix.com/v1。
如何確認實際命中的模型
這是智慧路由的信任錨點:你永遠知道這次請求最終用了哪個模型。 方式一 · AIHubMix 控制台「日誌」:在 console.aihubmix.com/logs 裡,每條請求都能直接看到實際命中、並據此計費的真實模型名,無需寫任何程式碼,肉眼即可核對。 方式二 · 回應欄位(便於程式化讀取):- 回應主體的
model欄位回填的是真實命中模型(如mimo-v2.5-pro),而不是auto。 - 回應標頭給出完整的決策資訊:
HTTP 回應標頭大小寫不敏感:上表按慣例首字母大寫,實際 HTTP/2 回傳為小寫 x-aihubmix-router-*,兩者等價。
讀取路由決策(curl 看回應標頭;SDK 用原始回應物件取 header):
reason 怎麼讀:survivors=20/33 表示 33 個候選裡有 20 個通過硬過濾進入評分,top=0.182 是勝出模型在候選池內歸一化後的綜合得分(能力 / 成本 / 延遲依策略加權)。
範例中的
Resolved-Model 取決於線上 catalog 的目前候選與價格,會隨平台模型上下線而變化——這正是智慧路由的價值:你不必追蹤這些變化。要做到決策可複盤,請以回應標頭 / 回應主體裡的真實模型名為準,而不是假設它固定不變。路由策略
不帶後綴的auto 使用預設策略 cost_optimized。你可以用 auto:<策略> 顯式指定側重:
策略不是固定的「模型清單」,而是對 能力 / 成本 / 延遲 的不同權重取向。
auto 先按你這次請求的內容圈定任務維度,再在該維度下 平台數百個模型 的候選池裡,按所選策略即時擇優——所以同一個策略,面對不同內容會命中不同模型。目前在池模型與各維度評分可透過取得自動路由策略對應模型範圍介面查詢。下方「同一請求、不同策略 → 不同命中」實測表就是這一機制的直觀體現;每次到底花落誰家,以回應標頭 / 控制台日誌裡的真實模型名為準。
指定策略只需把後綴加到 model 上:
What is the meaning of life?,都落 text.overall 維度):
latency_critical選了非-think版本——thinking 變體推理延遲更高,低延遲策略會主動避開它。可見策略權重真實作用於「能力 / 成本 / 延遲」的權衡,而不是只看能力。
內容也會改變結果:把同樣的auto:quality_first用在程式碼任務上(上面範例的請求),維度會從text.overall變為text.coding、實測命中claude-opus-4-6-think——策略與請求內容共同決定最終模型。
未知的策略後綴(如
auto:fast)會回退到預設策略 cost_optimized,不會報錯。工作原理
收到model=auto 後,閘道分三步把「意圖」變成「具體模型」:
1
擷取請求特徵
分析這次請求的輸入 / 輸出模態(文字、圖片、檔案)、內容意圖(程式碼、數學、OCR、圖表、語言、是否聯網搜尋等)、以及請求規模(預估輸入 / 輸出 token),歸一為一個任務維度。例如:含程式碼的提問 →
text.coding;帶圖片並要求 OCR → vision.ocr;普通文字 → text.overall。2
硬過濾候選
把不滿足硬性約束的模型直接排除:不支援所需輸入 / 輸出模態、上下文視窗裝不下、被熔斷摘除(見可靠性與容錯)、或不在你這把 Key 的可用模型範圍內。
3
依策略加權評分
對通過過濾的候選,基於業界權威基準的模型能力評分、疊加即時價格與效能資料,依所選策略對「能力 / 成本 / 延遲」做三維加權評分,取得分最高的一個。最終模型名會寫回請求與回應標頭。
quality_first 策略下,同一候選池的 top 3,示例資料基於歷史生產決策日誌):
注意 claude-fable-5 的能力分最高(1510),卻因成本更高、延遲更大被綜合得分壓到第三。這正是加權評分的意義:不是「唯能力論」,而是依策略在能力 / 成本 / 延遲之間權衡。
claude-fable-5 為階段性發布的預覽基線模型(staged preview baseline),現已退役下線(deprecated)、不再對外提供服務;此處保留其歷史評分,僅用於演示加權打分機制,實際請求不會再命中該模型。auto,不同內容會路由到不同維度:
這些維度名來自業界權威評測榜單對模型 細分能力 的拆解,
auto 據此把每類請求送到該細分能力最強的模型。常見領域舉例:
- 文本(
text.coding=寫 / 調程式、text.math=數學求解、text.longer_query=長文處理、text.language.chinese=中文、text.occupational.legal/text.occupational.medicine=法律 / 醫療等職業場景) - 視覺(
vision.ocr=辨識圖片中的文字、vision.diagram=看懂圖表 / 流程圖、vision.overall=通用看圖理解)
圖片輸入也走智慧路由:在
/v1/chat/completions 裡帶圖片時,會依圖片任務路由到視覺能力強的模型。生產實測——「OCR this image」→ vision.ocr、命中 qwen3.5-397b-a17b;通用看圖「What is in this image?」→ vision.overall、命中 gpt-5.4-mini。(這裡指圖片理解;圖片生成 /v1/images/* 同樣支援 auto,見 FAQ。)快取支援
同一個會話會優先持續使用同一模型。這樣多輪對話的表現更一致,也能持續命中推理廠商的 prompt 快取,減少長上下文的重複計費並降低回應延遲。 無需額外改造:Claude Code、Codex、OpenCode 等主流 Agent 的會話標識會被自動識別。需要精確控制會話範圍時,可在請求中加入:X-Aihubmix-Router-Resolved-Model:本輪實際使用的模型X-Aihubmix-Router-Sticky: true:複用了該會話此前的模型X-Aihubmix-Router-Reason:本輪路由原因
評分排行榜與模型池
各維度的模型評分排行榜與目前在池模型,可在智慧路由介紹頁互動檢視,也可透過免登入開放介面直接取得:取得自動路由策略對應模型範圍、取得模型廠商圖示。排行榜展示口徑與路由候選一致:僅展示目前可被正常路由的模型,分數為各維度內正規化的 0–100 值,並隨模型池持續更新。可靠性與容錯
智慧路由內建多重容錯,保證auto 路徑永不無故失敗:
熔斷:自動摘除故障模型
熔斷:自動摘除故障模型
閘道對每個模型維護一個滑動視窗的失敗率統計。當某模型在視窗內失敗次數足夠多、且失敗率超過閾值時,會被臨時摘除出候選池,冷卻一段時間後自動恢復——避免把後續請求繼續送給正在抽風的模型。失敗訊號來自上游對該請求回傳的錯誤;閘道自身的「無可用渠道」不計入(那不是模型本身的問題)。
無候選兜底:永不在 auto 上報 400
無候選兜底:永不在 auto 上報 400
萬一硬過濾把所有候選都排除了(例如某種模態組合暫時沒有可用模型),閘道不會直接報錯,而是依輸出類型分配一個兜底模型保證有回應,並在回應標頭加上
X-Aihubmix-Router-Fallback: true 讓你知曉。越權防線:受限 Key 不會被兜底繞過
越權防線:受限 Key 不會被兜底繞過
如果你的 Key 限定了可用模型範圍,智慧路由(含兜底)選出的模型始終在該範圍內。若範圍內確實沒有任何模型能服務這次請求,會明確回傳 403,而不是靜默使用範圍外(可能更貴)的模型。
計費說明
依實際命中的模型原價計費,智慧路由本身不收取任何附加費。 最終由哪個模型回應,就依那個模型的價格、能力和上下文限制計算——這個模型就是回應標頭X-Aihubmix-Router-Resolved-Model 和回應主體 model 欄位裡的值。換句話說,智慧路由不會「偷偷用貴模型」:每一次命中都寫在回應裡,可逐條對帳。
限制
-
智慧路由目前面向對話補全
/v1/chat/completions與圖像生成 / 編輯/v1/images/*介面(詳見 FAQ:支援哪些介面)。 -
?router=off或請求標頭X-Router-Off會讓model=auto直接回傳 400——這是明確拒絕「既要 auto 又要關掉路由」的歧義用法,而不是靜默忽略: -
候選集合隨平台 catalog 動態變化:同一個
auto在不同時間可能命中不同模型(這是設計使然,可透過回應標頭複盤)。目前候選範圍可透過取得自動路由策略對應模型範圍介面查詢。
和 OpenRouter / LiteLLM 的區別
「自動選模型」並非 AIHubMix 獨有,OpenRouter 與 LiteLLM 都提供類似能力。差異主要在接入成本與託管方式:常見問題 FAQ
Q:智慧路由支援哪些介面? A:目前model=auto 支援 OpenAI 相容的對話補全介面 /v1/chat/completions,以及圖像生成 / 編輯介面(/v1/images/generations、/v1/images/edits)。音訊、/v1/embeddings、/v1/rerank 等介面暫不支援 auto,請直接指定具體模型。
Q:智慧路由支援圖片輸入嗎?
A:支援。在 /v1/chat/completions 裡帶圖片(image_url)提問屬於圖片理解,會依圖片任務路由到視覺能力強的模型(vision.ocr=辨識圖片中的文字、vision.diagram=看懂圖表 / 流程圖、vision.overall=通用看圖理解等)。圖片生成同樣支援 auto:在 /v1/images/* 介面把 model 填 auto,會依圖像生成維度(如 text_to_image.overall)選模。
Q:我怎麼知道這次請求到底用了哪個模型?
A:看回應標頭 X-Aihubmix-Router-Resolved-Model,或回應主體的 model 欄位——回填的都是真實模型名。見 如何確認實際命中的模型。
Q:智慧路由會不會偷偷用貴模型?
A:不會。預設策略 cost_optimized 是成本優先;而且每次命中的模型都寫在回應裡、依其原價計費,可逐條對帳。見計費說明。
Q:怎麼控制 / 預估成本?
A:三個手段疊加——① 預設 auto(cost_optimized)就是成本優先;② 用 Key 的可用模型範圍把候選鎖定在你接受的價位內,相當於給成本設上界;③ 每次命中依回應標頭 Resolved-Model 的模型原價計費,可逐條對帳。需要更強能力時再顯式用 auto:quality_first。
Q:auto 和「模型對應 / 回退」有什麼區別?
A:模型對應 / 回退是 Key 級固定別名 + 失敗時的有序兜底(每次都同一個目標);智慧路由是依每次請求內容動態選模。前者解決「用戶端只認某個名字 / 主模型掛了切備用」,後者解決「我不在乎是哪個,給我最合適的」。
Q:能不能限定智慧路由只在某幾個模型裡選?
A:可以——透過 Key 的可用模型範圍約束:智慧路由只會在該 Key 允許的模型裡選,越權模型不會被命中。
Q:串流請求支援嗎?
A:支援。路由在請求進入上游前完成,對串流 / 非串流一視同仁。
Q:為什麼同一句話兩次呼叫命中了不同模型?
A:候選集合與價格隨平台 catalog 動態變化,這是設計使然。用回應標頭裡的 Decision-Id 與 Resolved-Model 即可複盤每一次決策;目前候選範圍可透過取得自動路由策略對應模型範圍介面查詢。
Q:怎麼讓請求穩定命中同一個模型(比如想複用 prompt 快取)?
A:智慧路由自帶會話黏性:同一會話會優先持續使用同一模型,Claude Code、Codex、OpenCode 等主流 Agent 的會話標識會被自動識別,也可用請求標頭 X-Aihubmix-Session-Id 精確控制會話範圍(見快取支援)。注意這是「優先複用」而非永久鎖定——模型不支援本輪請求、需要更強能力或服務不可用時會自動切換。若要嚴格確定命中同一模型,請直接指定具體模型名,或用 Key 把可用範圍限定到單一模型。
相關資源
- 模型對應與回退:Key 級固定別名 + 失敗兜底,與智慧路由互補。
- 統一推理參數:跨模型一致的請求參數。
- AIHubMix 模型頁:查詢模型名稱、價格與
Input Modalities。 - 取得自動路由策略對應模型範圍:免登入查詢 30+ 路由維度中公開的 5 大類 23 個子維度評分與在池模型。