跳轉到主要內容
一個 model=auto,把「選哪個模型」交給閘道。
智慧路由(Auto Router) 會依請求內容,從平台數百個模型即時優選最合適的那一個。你只需把 model 填成 auto——不用挑模型、不用比價、不用追蹤模型迭代。
實際命中的模型計費,無附加費,用戶端程式碼零改動。命中了哪個模型寫在回應標頭與回應主體裡(見 如何確認實際命中的模型),完全可追溯。

適用場景

  • 通用應用:當你不確定使用者會發來什麼類型的請求時,交給 auto 依內容分發。
  • 成本最佳化:讓簡單任務自動落到更便宜、更快的模型(auto 預設成本優先)。
  • 品質最佳化:確保複雜請求被路由到能力更強的模型(auto:quality_first)。
  • 低延遲場景:即時語音、agent 多輪迴圈優先選回應最快的模型(auto:latency_critical)。
  • 統一入口、免選型:不同類型的請求自動分發到各自最適的模型——不必維護「任務 → 模型」對應表,也不必持續追蹤模型迭代、手動比價換名。

快速開始

model 設為 auto,其餘請求主體和正常呼叫完全一致。base_url 使用 https://aihubmix.com/v1
curl https://aihubmix.com/v1/chat/completions \
  -H "Authorization: Bearer <AIHUBMIX_API_KEY>" \
  -H "Content-Type: application/json" \
  -d '{
    "model": "auto",
    "messages": [
      { "role": "user", "content": "What is the meaning of life?" }
    ]
  }'
智慧路由在請求進入上游之前完成解析,對串流(stream: true)與非串流請求一視同仁,無需額外參數;整個決策僅增加約 1ms 開銷,對端到端延遲幾乎無感。

如何確認實際命中的模型

這是智慧路由的信任錨點:你永遠知道這次請求最終用了哪個模型。
  • 回應主體的 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):
curl -i https://aihubmix.com/v1/chat/completions \
  -H "Authorization: Bearer <AIHUBMIX_API_KEY>" \
  -H "Content-Type: application/json" \
  -d '{
    "model": "auto",
    "messages": [
      { "role": "user", "content": "What is the meaning of life?" }
    ]
  }' | grep -i "^x-aihubmix-router"
curl 實際輸出(生產環境,命中模型隨線上 catalog 變化):
x-aihubmix-router-decision-id: 05dbad09-33c5-42de-85b5-559fdb73eb4c
x-aihubmix-router-dimension: text.overall
x-aihubmix-router-policy: cost_optimized
x-aihubmix-router-reason: policy=cost_optimized dim=text.overall top=0.182 survivors=20/33
x-aihubmix-router-resolved-model: xiaomi-mimo-v2.5-pro
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 上:
# 品質優先 + 程式碼任務
curl -i https://aihubmix.com/v1/chat/completions \
  -H "Authorization: Bearer <AIHUBMIX_API_KEY>" \
  -H "Content-Type: application/json" \
  -d '{
    "model": "auto:quality_first",
    "messages": [
      { "role": "user", "content": "Write a Python function to reverse a linked list." }
    ]
  }' | grep -i "^x-aihubmix-router"
同一請求、不同策略 → 不同命中(生產實測,同一句 What is the meaning of life?,都落 text.overall 維度):
策略命中模型top 得分
auto(= cost_optimizedxiaomi-mimo-v2.5-pro0.182
auto:balancedclaude-opus-4-6-think0.488
auto:latency_criticalclaude-opus-4-60.646
auto:quality_firstclaude-opus-4-6-think0.758
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-opus-4-6-think15042201963ms0.758
claude-opus-4-61498220822ms0.721
claude-fable-5151048411130ms0.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
維度辨識採用保守比對(高精度、低誤判):長尾、模糊的請求會落到更通用的維度(如 text.overall / 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。)

可靠性與容錯

智慧路由內建多重容錯,保證 auto 路徑永不無故失敗
閘道對每個模型維護一個滑動視窗的失敗率統計。當某模型在視窗內失敗次數足夠多、且失敗率超過閾值時,會被臨時摘除出候選池,冷卻一段時間後自動恢復——避免把後續請求繼續送給正在抽風的模型。失敗訊號來自上游對該請求回傳的錯誤;閘道自身的「無可用渠道」不計入(那不是模型本身的問題)。
萬一硬過濾把所有候選都排除了(例如某種模態組合暫時沒有可用模型),閘道不會直接報錯,而是依輸出類型分配一個兜底模型保證有回應,並在回應標頭加上 X-Aihubmix-Router-Fallback: true 讓你知曉。
如果你的 Key 限定了可用模型範圍,智慧路由(含兜底)選出的模型始終在該範圍內。若範圍內確實沒有任何模型能服務這次請求,會明確回傳 403,而不是靜默使用範圍外(可能更貴)的模型。

計費說明

依實際命中的模型原價計費,智慧路由本身不收取任何附加費。 最終由哪個模型回應,就依那個模型的價格、能力和上下文限制計算——這個模型就是回應標頭 X-Aihubmix-Router-Resolved-Model 和回應主體 model 欄位裡的值。換句話說,智慧路由不會「偷偷用貴模型」:每一次命中都寫在回應裡,可逐條對帳。

限制

  • 智慧路由目前面向對話補全介面 /v1/chat/completions(詳見 FAQ:支援哪些介面)。
  • ?router=off 或請求標頭 X-Router-Off 會讓 model=auto 直接回傳 400——這是明確拒絕「既要 auto 又要關掉路由」的歧義用法,而不是靜默忽略:
    curl -i "https://aihubmix.com/v1/chat/completions?router=off" \
      -H "Authorization: Bearer <AIHUBMIX_API_KEY>" \
      -H "Content-Type: application/json" \
      -d '{"model":"auto","messages":[{"role":"user","content":"hi"}]}'
    # → HTTP/1.1 400 Bad Request
    # {"error":{"message":"auto requires router enabled; remove ?router=off / X-Router-Off", ...}}
    
  • 候選集合隨平台 catalog 動態變化:同一個 auto 在不同時間可能命中不同模型(這是設計使然,可透過回應標頭複盤)。

和 OpenRouter / LiteLLM 的區別

「自動選模型」並非 AIHubMix 獨有,OpenRouter 與 LiteLLM 都提供類似能力。差異主要在接入成本託管方式
差異點OpenRouterLiteLLMAIHubMix
依請求內容自動選模
零設定、開箱即用(無需編寫路由規則 / 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:三個手段疊加——① 預設 autocost_optimized)就是成本優先;② 用 Key 的可用模型範圍把候選鎖定在你接受的價位內,相當於給成本設上界;③ 每次命中依回應標頭 Resolved-Model 的模型原價計費,可逐條對帳。需要更強能力時再顯式用 auto:quality_first Q:auto 和「模型對應 / 回退」有什麼區別? A:模型對應 / 回退Key 級固定別名 + 失敗時的有序兜底(每次都同一個目標);智慧路由是依每次請求內容動態選模。前者解決「用戶端只認某個名字 / 主模型掛了切備用」,後者解決「我不在乎是哪個,給我最合適的」。 Q:能不能限定智慧路由只在某幾個模型裡選? A:可以——透過 Key 的可用模型範圍約束:智慧路由只會在該 Key 允許的模型裡選,越權模型不會被命中。 Q:串流請求支援嗎? A:支援。路由在請求進入上游前完成,對串流 / 非串流一視同仁。 Q:為什麼同一句話兩次呼叫命中了不同模型? A:候選集合與價格隨平台 catalog 動態變化,這是設計使然。用回應標頭裡的 Decision-IdResolved-Model 即可複盤每一次決策。 Q:怎麼讓請求穩定命中同一個模型(比如想複用 prompt 快取)? A:auto 是依目前 catalog 動態選模,不保證確定性。如果你需要穩定命中同一模型(例如依賴上游的 prompt 快取、或要嚴格重現),請直接指定具體模型名,或用 Key 把可用範圍限定到單一模型——這兩種方式下命中是確定的。

相關資源