在2026年8月4日，DeepSeek的官方狀態頁面記錄了兩起API性能下降事件。
第一次事件持續了1小時18分鐘，從02:02到03:20 UTC，影響了DeepSeek V4 Flash、V4 Pro和專家模式。第二次事件持續了36分鐘，從03:43到04:20 UTC，影響了DeepSeek V4 Flash API。
這兩起事件目前已經解決。OpenCode還報告了DeepSeek Flash因前所未有的需求而出現的容量問題。然而，DeepSeek的官方狀態頁面僅確認了性能下降，並未公布根本原因。
摘要
- DeepSeek的官方狀態頁面在2026年8月4日記錄了兩起影響V4 Flash的性能下降事件。
- 直接的供應商整合創造了一個單一故障點，即使同一模型在其他地方可用。
- AIHubMix可以在上游路由返回可重試錯誤時，通過多個供應商通道重試相同的模型。
- 如果主要模型的所有供應商通道都失敗，關鍵級模型回退可以將請求切換到配置的備用模型。
- 多供應商路由減少了對單一端點的依賴，但無法消除相關故障或網關級風險。
這類事件突顯了一個重要的基礎設施原則：
如果通過單一供應商端點訪問，可靠的模型是不夠的。
一個模型不必意味著一個供應商
當應用程序直接連接到一個供應商時，該端點成為單一故障點。
如果供應商發生故障、達到其速率限制或遭受延遲峰值，應用程序就沒有其他地方可以發送請求。即使同一模型在其他基礎設施供應商中仍然可用，用戶也會看到超時和錯誤。
AIHubMix將模型與提供該模型的供應商分開。
例如，DeepSeek V4 Flash可以通過AIHubMix的多個供應商獲得，包括DeepSeek、百度、DeepInfra和阿里雲。應用程序繼續使用一個兼容OpenAI的API端點，而AIHubMix管理可用的上游路由。
這創造了兩個不同的可靠性層。
層級1：供應商故障轉移
供應商故障轉移在切換其背後的基礎設施供應商時保持請求的模型不變。
當對DeepSeek V4 Flash的請求到達AIHubMix時，網關選擇一個合格的供應商通道。如果該通道在響應開始之前返回可重試錯誤，AIHubMix可以嘗試另一個可用通道以獲取相同的模型。
請求路徑可能如下所示：
- 通過供應商A嘗試DeepSeek V4 Flash。
- 供應商A返回超時、5xx錯誤或可重試的容量錯誤。
- 通過供應商B嘗試相同的DeepSeek V4 Flash模型。
- 繼續直到請求成功或所有合格通道耗盡。
客戶端不需要整合多個供應商SDK、管理單獨的API密鑰或實現自己的重試邏輯。
這是供應商級故障轉移：供應商改變，但請求的模型保持不變。
層級2：模型回退
如果主要模型的每個可用供應商都不可用，供應商故障轉移將無法幫助。
因此，AIHubMix支持第二個可靠性層：模型回退。
用戶可以為每個API密鑰配置一個有序的備用模型列表。在每個主要模型的合格通道返回可重試失敗後，AIHubMix將轉向回退列表中的下一個模型。
例如：
- 主要模型：
deepseek-v4-flash - 第一次回退：
gpt-5.4 - 第二次回退：
gemini-3.1-pro-preview
回退是在AIHubMix網關內執行的。現有應用程序不需要發送額外的路由參數或更改其客戶端代碼。
計費基於最終返回成功響應的模型。開發者可以通過響應標頭驗證回退行為：
X-Aihubmix-Fallback: trueX-Aihubmix-Model: <final-model>
完整的配置和觸發規則記錄在AIHubMix模型映射和回退中。
自動故障轉移可以處理什麼
供應商故障轉移旨在從上游基礎設施問題中恢復，例如：
- 供應商超時
- 連接失敗
- 可重試的5xx響應
- 供應商速率限制和容量錯誤
- 上游通道的暫時不可用
當這些故障在響應開始之前發生時，AIHubMix可以透明地嘗試另一條路徑。
故障轉移無法解決的問題
多供應商路由提高了可用性，但並不使網關無懈可擊。
當以下情況發生時，不會觸發回退：
- 用戶的AIHubMix API密鑰無效、過期或超出配額
- 請求本身無效
- 客戶端斷開連接或達到自己的超時
- 流式響應已經開始
- 明確選擇了特定的供應商通道
- 故障影響每個供應商或網關本身
供應商故障也可能是相關的。多個供應商可能依賴於相同的基礎設施、模型版本或區域網絡。因此，多供應商的可用性應該通過實際流量來衡量，而不是僅僅根據供應商的數量來假設。
為什麼聚合器比直接端點更可靠
直接調用官方API為應用程序提供了一條通往模型的路徑。
多供應商網關則提供了多條路徑。
如果這些供應商路徑獨立失敗，網關可以繞過性能下降的端點，而不將故障暴露給應用程序。這減少了對任何單一供應商的依賴，並且可以提供比直接單一供應商整合更高的可用性。
這種差異在於架構：
- 直接API：一個模型、一個供應商、一個故障域
- AIHubMix：一個模型、多個供應商、自動故障轉移
- AIHubMix與模型回退：多個供應商加備用模型
目標不是預測哪個供應商將會下次故障，而是使上游事件成為內部路由事件，而不是面向客戶的故障。
為下一次供應商事件做好準備
DeepSeek V4 Flash已經恢復，但暫時的容量限制、速率限制和上游故障是生產AI基礎設施的正常部分。
應用程序不應每次供應商不穩定時都需要更改代碼。
通過AIHubMix，開發者可以通過一個API訪問多個供應商，自動在可用通道之間重試相同的模型，並為額外的保護層配置備用模型。
在aihubmix.com/models上探索可用的模型和供應商。
常見問題
什麼是多供應商故障轉移？
當當前路徑返回可重試失敗時，它會自動通過另一個合格的供應商重試相同的模型。
模型回退有何不同？
供應商故障轉移保持模型不變。模型回退僅在所有主要模型的合格通道失敗後切換到配置的備用模型。
哪些故障可以觸發故障轉移？
典型的觸發因素包括超時、連接失敗、可重試的5xx響應、速率限制和在響應開始之前的暫時容量錯誤。
故障轉移是否保證零停機時間？
不。相關的供應商故障、網關級事件、不可重試的錯誤以及流式開始後的故障仍然可能影響客戶。
我需要更改我的應用程序代碼嗎？
不需要額外的路由邏輯。應用程序繼續使用AIHubMix兼容OpenAI的端點，而備用模型可以在API密鑰級別配置。