一個 model=auto,把「選哪個模型」交給閘道。
智慧路由(Auto Router) 會依請求內容,從平台數百個模型中即時優選最合適的那一個。你只需把 model 填成 auto——不用挑模型、不用比價、不用追蹤模型迭代。
依實際命中的模型計費,無附加費,用戶端程式碼零改動。命中了哪個模型寫在回應標頭與回應主體裡(見 如何確認實際命中的模型),完全可追溯。
適用場景
- 通用應用:當你不確定使用者會發來什麼類型的請求時,交給
auto依內容分發。 - 成本最佳化:讓簡單任務自動落到更便宜、更快的模型(
auto預設成本優先)。 - 品質最佳化:確保複雜請求被路由到能力更強的模型(
auto:quality_first)。 - 低延遲場景:即時語音、agent 多輪迴圈優先選回應最快的模型(
auto:latency_critical)。 - 統一入口、免選型:不同類型的請求自動分發到各自最適的模型——不必維護「任務 → 模型」對應表,也不必持續追蹤模型迭代、手動比價換名。
快速開始
把model 設為 auto,其餘請求主體和正常呼叫完全一致。base_url 使用 https://aihubmix.com/v1。
如何確認實際命中的模型
這是智慧路由的信任錨點:你永遠知道這次請求最終用了哪個模型。- 回應主體的
model欄位回填的是真實命中模型(如mimo-v2.5-pro),而不是auto。 - 回應標頭給出完整的決策資訊:
| 回應標頭 | 含義 | 範例值 |
|---|---|---|
X-Aihubmix-Router-Resolved-Model | 實際命中、並據此計費的模型 | xiaomi-mimo-v2.5-pro |
X-Aihubmix-Router-Policy | 本次使用的策略 | cost_optimized |
X-Aihubmix-Router-Dimension | 辨識出的任務維度 | text.overall |
X-Aihubmix-Router-Decision-Id | 本次決策的唯一 ID,便於排查 | 05dbad09-33c5-42de-… |
X-Aihubmix-Router-Reason | 決策簡要說明(策略 / 維度 / 最高分 / 候選數) | policy=cost_optimized dim=text.overall top=0.182 survivors=20/33 |
X-Aihubmix-Router-Fallback | 僅當觸發無候選兜底時出現 | true |
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(= auto:cost_optimized) | 成本優先:能力達標就選最便宜 | 批量任務、對成本敏感 |
auto:balanced | 均衡:能力 / 成本 / 延遲兼顧 | 通用,不確定時的穩妥選擇 |
auto:quality_first | 品質優先:優先選能力最強 | 複雜推理、關鍵輸出 |
auto:latency_critical | 低延遲優先:優先選回應最快 | 即時語音、agent 迴圈 |
model 上:
What is the meaning of life?,都落 text.overall 維度):
| 策略 | 命中模型 | top 得分 |
|---|---|---|
auto(= cost_optimized) | xiaomi-mimo-v2.5-pro | 0.182 |
auto:balanced | claude-opus-4-6-think | 0.488 |
auto:latency_critical | claude-opus-4-6 | 0.646 |
auto:quality_first | claude-opus-4-6-think | 0.758 |
latency_critical選了非-think版本——thinking 變體推理延遲更高,低延遲策略會主動避開它。可見策略權重真實作用於「能力 / 成本 / 延遲」的權衡,而不是只看能力。
內容也會改變結果:把同樣的auto:quality_first用在程式碼任務上(上面範例的請求),維度會從text.overall變為text.coding、實測命中claude-opus-4-6-think——策略與請求內容共同決定最終模型。
未知的策略後綴(如
auto:fast)會回退到預設策略 cost_optimized,不會報錯。工作原理
收到model=auto 後,閘道分三步把「意圖」變成「具體模型」:
擷取請求特徵
分析這次請求的輸入 / 輸出模態(文字、圖片、檔案)、內容意圖(程式碼、數學、OCR、圖表、語言、是否聯網搜尋等)、以及請求規模(預估輸入 / 輸出 token),歸一為一個任務維度。例如:含程式碼的提問 →
text.coding;帶圖片並要求 OCR → vision.ocr;普通文字 → text.overall。硬過濾候選
把不滿足硬性約束的模型直接排除:不支援所需輸入 / 輸出模態、上下文視窗裝不下、被熔斷摘除(見可靠性與容錯)、或不在你這把 Key 的可用模型範圍內。
quality_first 策略下,同一候選池的 top 3,資料取自生產決策日誌):
| 候選模型 | 能力分 | 相對成本 | 延遲 | 綜合得分 |
|---|---|---|---|---|
claude-opus-4-6-think | 1504 | 220 | 1963ms | 0.758 |
claude-opus-4-6 | 1498 | 220 | 822ms | 0.721 |
claude-fable-5 | 1510 | 484 | 11130ms | 0.600 |
注意 claude-fable-5 的能力分最高(1510),卻因成本更高、延遲更大被綜合得分壓到第三。這正是加權評分的意義:不是「唯能力論」,而是依策略在能力 / 成本 / 延遲之間權衡。
維度辨識是自動的——智慧路由內建 30+ 細分任務維度(程式碼 / 數學 / OCR / 圖表 / 長文 / 中文 / 聯網…),遠比「依模型族粗分流」精細。同樣填 auto,不同內容會路由到不同維度:
| 你的請求 | 辨識維度 |
|---|---|
| 普通文字提問 | text.overall |
| 含程式碼、要求寫 / 偵錯程式 | text.coding |
| 數學證明 / 求解 | text.math |
| 很長的提問(約 500+ token) | text.longer_query |
| 中文提問 | text.language.chinese |
| 圖片輸入 + “What is in this image?” | vision.overall |
| 圖片輸入 + “OCR…” / “辨識文字” | vision.ocr |
| 圖片輸入 + 圖表 / 流程圖 | vision.diagram |
| 開啟聯網搜尋 | search.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。)可靠性與容錯
智慧路由內建多重容錯,保證auto 路徑永不無故失敗:
熔斷:自動摘除故障模型
熔斷:自動摘除故障模型
閘道對每個模型維護一個滑動視窗的失敗率統計。當某模型在視窗內失敗次數足夠多、且失敗率超過閾值時,會被臨時摘除出候選池,冷卻一段時間後自動恢復——避免把後續請求繼續送給正在抽風的模型。失敗訊號來自上游對該請求回傳的錯誤;閘道自身的「無可用渠道」不計入(那不是模型本身的問題)。
無候選兜底:永不在 auto 上報 400
無候選兜底:永不在 auto 上報 400
萬一硬過濾把所有候選都排除了(例如某種模態組合暫時沒有可用模型),閘道不會直接報錯,而是依輸出類型分配一個兜底模型保證有回應,並在回應標頭加上
X-Aihubmix-Router-Fallback: true 讓你知曉。越權防線:受限 Key 不會被兜底繞過
越權防線:受限 Key 不會被兜底繞過
如果你的 Key 限定了可用模型範圍,智慧路由(含兜底)選出的模型始終在該範圍內。若範圍內確實沒有任何模型能服務這次請求,會明確回傳 403,而不是靜默使用範圍外(可能更貴)的模型。
計費說明
依實際命中的模型原價計費,智慧路由本身不收取任何附加費。 最終由哪個模型回應,就依那個模型的價格、能力和上下文限制計算——這個模型就是回應標頭X-Aihubmix-Router-Resolved-Model 和回應主體 model 欄位裡的值。換句話說,智慧路由不會「偷偷用貴模型」:每一次命中都寫在回應裡,可逐條對帳。
限制
-
智慧路由目前面向對話補全介面
/v1/chat/completions(詳見 FAQ:支援哪些介面)。 -
?router=off或請求標頭X-Router-Off會讓model=auto直接回傳 400——這是明確拒絕「既要 auto 又要關掉路由」的歧義用法,而不是靜默忽略: -
候選集合隨平台 catalog 動態變化:同一個
auto在不同時間可能命中不同模型(這是設計使然,可透過回應標頭複盤)。
和 OpenRouter / LiteLLM 的區別
「自動選模型」並非 AIHubMix 獨有,OpenRouter 與 LiteLLM 都提供類似能力。差異主要在接入成本與託管方式:| 差異點 | OpenRouter | LiteLLM | AIHubMix |
|---|---|---|---|
| 依請求內容自動選模 | ✅ | ✅ | ✅ |
| 零設定、開箱即用(無需編寫路由規則 / utterances) | ✅ | ❌ | ✅ |
| 平台託管,無需自建 / 自部署 proxy | ✅ | ❌ | ✅ |
| 成本 / 品質 / 延遲多策略,一個參數切換 | ❌ | ❌ | ✅ |
| 命中決策可追溯(回應標頭含 dimension / policy / reason) | ❌ | ❌ | ✅ |
| 依最終命中模型計費 | ✅ | ❌ | ✅ |
常見問題 FAQ
Q:智慧路由支援哪些介面? A:目前model=auto 支援 OpenAI 相容的對話補全介面 /v1/chat/completions。圖像生成 / 編輯(/v1/images/*)、音訊、/v1/embeddings、/v1/rerank 等介面暫不支援 auto,請直接指定具體模型。
Q:智慧路由支援圖片輸入嗎?
A:支援。在 /v1/chat/completions 裡帶圖片(image_url)提問屬於圖片理解,會依圖片任務路由到視覺能力強的模型(vision.ocr / vision.diagram / vision.overall 等)。注意區分:圖片生成走 /v1/images/* 介面,暫不支援 auto。
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:auto 是依目前 catalog 動態選模,不保證確定性。如果你需要穩定命中同一模型(例如依賴上游的 prompt 快取、或要嚴格重現),請直接指定具體模型名,或用 Key 把可用範圍限定到單一模型——這兩種方式下命中是確定的。
相關資源
- 模型對應與回退:Key 級固定別名 + 失敗兜底,與智慧路由互補。
- 統一推理參數:跨模型一致的請求參數。
- AIHubMix 模型頁:查詢模型名稱、價格與
Input Modalities。