2026 年 10 月 20 日，Google Cloud 倫敦一個可用區停電近 8 小時；五天前，DeepSeek 也掉線了大半個上午。不少開發者在問，自己的 AI 應用下次會不會也跟着停。
上游說不定哪天會掉。只調模型 API 的人不必搬機房，但不能把業務只掛在一家模型上。
核心價值：讀完這篇，你能分清哪些情況要動手、哪些不用，並且知道怎麼給模型留好後路。
這周兩次中斷，各自掉了什麼
先說 Google Cloud。2026-10-20 北京時間 14:08 到 22:00，倫敦 europe-west2-b 這一個可用區因供電事件中斷，一共 7 小時 52 分。受影響的是部署在這個可用區裏的計算、存儲、數據庫和網絡；只遠程調用模型 API 的人，不在這次的直接影響範圍內。可如果你的服務恰好跑在這個區，那一下午，後臺任務、數據庫連接、對外接口都得停在那裏等，誰也沒法替它們提前把活幹完。
再說 DeepSeek。2026-10-15 北京時間 08:11 開始，網頁、對話和 V4 Pro、V4.1 Flash 的 API 部分中斷。官方狀態頁記錄持續 4 小時 52 分，當天 13:04 恢復。財新、南華早報說「將近 5 小時」，那是媒體說法，時長以官方記錄爲準。DeepSeek 後來把 10 月 8 日到 14 日的消耗退成了額度。原因官方沒有公佈，這裏不做猜測。對用戶來說，那個上午能不能用，取決於手上有沒有第二條路，而不是原因是什麼。
圖：DeepSeek 發給用戶的服務恢復及補償通知。北京時間 10 月 15 日 8:11 至 13:04 API 服務無法正常使用，按賬號 10 月 8 日到 14 日的消耗金額以贈金形式全額返還，自動到賬，API 扣費先從贈金賬戶扣除。
兩件事疼的地方一樣：模型是當天工作流裏的一環，接口一斷，寫代碼、查資料、跑批處理都會停在那裏。等上游修好，半天就過去了。退額度補的是賬單，補不回停掉的工作。一個團隊如果當天本來要交一批翻譯、跑一輪評測、趕一個上線，這些都不會因爲事後的補償自己完成，只會往後順延，連帶擠佔第二天的排期。
| 項目 | Google Cloud 事故已覈實的情況 |
|---|---|
| 事故編號 | Xs2XTHzAVC9YnafnPyzj |
| 影響範圍 | europe-west2 區域內的 europe-west2-b 可用區 |
| 原因 | 供電事件，官方沒有更多細節 |
| 開始時間 | 北京時間 2026-10-20 14:08 |
| 結束時間 | 北京時間 2026-10-20 22:00，持續 7 小時 52 分 |
| 不受影響 | Looker Studio |
可用區和區域，差在哪
很多人看到「倫敦停電」，第一反應是整個倫敦的 Google Cloud 都掛了，其實不是。區域（europe-west2）可以理解成 Google 在倫敦的一整片機房，可用區（europe-west2-a、b、c）是這片機房裏互相隔開的幾棟樓，設計上各自供電、各自聯網，就是爲了一棟出事時另外幾棟還能頂上。這次是三棟裏黑了一棟，另外兩棟照常在線。
所以真正受傷的，是把服務只放在 b 區的團隊。服務本來就分散在 a、c 區的，流量能被切到還亮着的那幾棟，影響會小很多。只遠程調用模型 API 的人，幾乎感覺不到這次停電。
兩次中斷放在一起看
| 對比項 | Google Cloud 倫敦 | DeepSeek |
|---|---|---|
| 時間（北京時間） | 2026-10-20 14:08 到 22:00 | 2026-10-15 08:11 到 13:04 |
| 持續時長 | 7 小時 52 分 | 4 小時 52 分 |
| 掉了什麼 | europe-west2-b 裏的計算、存儲、數據庫和網絡 | 網頁、對話，以及 V4 Pro、V4.1 Flash 的 API |
| 原因 | 供電事件，沒有更多細節 | 官方沒有公佈 |
| 事後處理 | 官方建議如可行，遷到其他可用區或區域 | 10 月 8 日到 14 日的消耗退成額度 |
| 只調模型 API 的人 | 不在直接影響範圍內 | 正中靶心，沒有備用就只能乾等 |
兩次放在一起看，差別就清楚了：Google 那次，疼的是把機器放在 b 區的人，解法是跨可用區部署；DeepSeek 那次，疼的是隻接了一家模型的人，解法是提前排好備用模型。前一種是機房的事，後一種是調用的事，下面講的都是後一種。
這次故障該吸取的教訓
一家會掉，所以要提前有第二條、第三條路，而且這幾條路最好不是同一家。在同一家裏換個便宜檔不算後路，整家出問題時，兩檔會一起倒。
什麼時候換也有講究：只有 429、500、502、503、504 和超時才換模型，這些是對方暫時扛不住，換個名字有機會成功。401、403 和內容安全拒絕不要換，那是 Key 或內容本身的問題，換十個模型也一樣被拒。還有一點要分清，自己部署在掉線可用區裏的數據庫和存儲，換模型救不了，那得評估跨可用區部署，模型兜底和機房容災是兩件事，別混着做。
兜底做好之後，也別在故障結束後拆掉。它平時不產生額外請求，主模型一次成功就用不上，但下一次出事時會自動生效，不用半夜起來改代碼。動手之前，先給每個模型單獨發一條最簡單的請求，確認名字沒寫錯、能正常返回，再去想怎麼把它們串起來。不同模型的回答風格會有差別，如果業務對輸出格式要求高，可以在 system 提示詞裏把格式寫死，減小換模型後的落差。
兜底鏈路的幾個設置怎麼定
光知道「失敗就換」還不夠，換得太急、太慢都會出問題。下面這幾項是最常被問到的，沒有標準答案，按自己的業務往裏套就行。
| 設置 | 建議 | 爲什麼 |
|---|---|---|
| 同一個模型重試幾次 | 最多 1 次，再失敗就換下一個 | 上游在出事時，連續重試同一個模型往往只是多排一輪隊 |
| 單次請求等多久 | 對話類短一些，長文生成類長一些 | 等得太久，用戶還沒等到切換就先關頁面了 |
| 遇到 429 怎麼辦 | 稍等一兩秒再換 | 限流有時只是瞬間高峯，過一下就好 |
| 整條鏈路最多等多久 | 三檔加起來，不超過用戶能接受的等待 | 防止三檔都慢的時候請求一直掛着 |
| 記什麼日誌 | 每次是哪一檔成功、哪一檔失敗、錯誤碼是多少 | 事後能看出是哪家在掉，要不要調整順序 |
| 什麼時候提醒人 | 備用檔被用上的比例突然升高時 | 兜底生效後用戶無感，團隊也可能無感，總得有人知道主模型在出問題 |
最後一項最容易被忽略。兜底做得越好，主模型出問題時越安靜，如果沒人看日誌，可能主模型已經掉了一整天，大家還以爲一切正常，賬單上卻多了一堆備用模型的調用。
換模型不必換一把 Key
兜底最怕改造太重。每個模型都要單獨申請賬號、換地址、改請求格式，多數團隊會拖到下次出事才動手。
APIYI 的做法是同一個地址 https://api.apiyi.com/v1/chat/completions，同一把 Key，請求體裏只改 model。主模型用 claude-opus-5-5，失敗後換 claude-sonnet-5-5，再失敗換 gemini-4-argon。前兩檔同屬一家，第三檔換到另一家，某一家整體出問題時還有路可走。這樣改造的量很小：業務代碼裏只多一個按順序嘗試的模型名列表，請求格式、鑑權方式和返回結構都不用動，測試起來也簡單。
| 順序 | 模型名 | 輸入價格 | 輸出價格 | 角色 |
|---|---|---|---|---|
| 1 | claude-opus-5-5 | 4 | 20 | 主模型 |
| 2 | claude-sonnet-5-5 | 2 | 10 | 第一備用，同家便宜檔 |
| 3 | gemini-4-argon | 2 | 10 | 第二備用，另一家供應商 |
| 可替換 | gpt-6-astra | 10 | 50 | 更貴的備用，只走 OpenAI 接口 |
| 可替換 | deepseek-v4.1-flash | 0.30 | 1.20 | 便宜備用 |
上表單位爲美元 / 百萬 tokens，按 2026-10-21 價格頁、倍率 1 整理，價格可能調整，以 api.apiyi.com 價格頁爲準。
三步接上兜底
第一步，拿 Key。 在 api.apiyi.com 註冊並創建一把 Key，按量計費，國內可以直連，不用綁海外信用卡。這一把 Key 就能調上表裏所有模型。
第二步，逐個跑通。 接口地址填 https://api.apiyi.com/v1，它和 OpenAI 的接口格式兼容，原來用 OpenAI 官方庫寫的代碼，換個地址和 Key 就能用。用同一段提示詞，把 claude-opus-5-5、claude-sonnet-5-5、gemini-4-argon 各跑一遍，確認都能正常返回、格式符合預期。
第三步，排好順序再演練一次。 把三個模型名按順序寫進配置，按上一節的規則決定什麼時候換。接好之後別急着上線，先把主模型的等待時間臨時調得很短，故意讓它超時，看請求是不是落到了第二檔，日誌裏有沒有記下來。演練通過了，這條後路纔算真的留好。具體參數可以查 docs.apiyi.com 的接入文檔。
不同業務怎麼排順序
本文默認的順序是質量優先，不是唯一答案。業務不同，打頭的模型也可以不同。
| 業務類型 | 參考順序 | 理由 |
|---|---|---|
| 寫代碼、複雜推理 | claude-opus-5-5 → claude-sonnet-5-5 → gemini-4-argon | 質量優先，就是本文的默認順序 |
| 客服、日常對話 | claude-sonnet-5-5 → gemini-4-argon → deepseek-v4.1-flash | 調用量大、單價敏感，主模型不必上最貴的 |
| 批量翻譯、摘要 | deepseek-v4.1-flash → gemini-4-argon → claude-sonnet-5-5 | 跑得多，便宜檔打頭，失敗再往上走 |
| 對格式要求嚴的輸出 | 同一家的兩檔在前，另一家放最後 | 同一家的模型風格通常更接近，換了落差小 |
排順序的原則就兩條：最後一檔儘量換一家；單價跟這件事值多少錢匹配。像批量翻譯這一行，正好也能看出兜底的價值，10 月 15 日那天如果打頭的 DeepSeek 掉了，請求會自動落到後面兩家，任務照樣跑完。
要說清楚的是，換模型解決的是「調用模型這一步不斷」，修不好機房停電。
上游會掉，提前留一條別的路
已公開的例子是 2026-10-15 的 DeepSeek 官方中斷：當時 APIYI 切到了火山引擎滿血版通道，模型名不用改，生產環境當時恢復正常。出處見 docs.apiyi.com 實時動態。
上游會掉，這不是誰的錯。提前留一條別的路，比干等半天有用。這件事平時幾乎不花錢，也不佔人力，只要在出事之前做完；出事之後再做，就只能一邊着急一邊改。
出事那天，先看哪幾個地方
請求突然大面積失敗時，先別急着改代碼，花兩分鐘看三個地方：一是 Google Cloud Service Health，看是不是機房層面出了事；二是對應模型廠商的官方狀態頁，比如這次的 DeepSeek 狀態頁；三是 docs.apiyi.com 的實時動態，APIYI 這邊上游路線有變動，會在這裏寫明。
三個地方都顯示正常，再回頭查自己：Key 有沒有過期、餘額夠不夠、網絡出口和 DNS 有沒有問題。順序反過來，很容易在自己代碼裏找半天，最後發現是上游的事。
今天就能做完的四件事
- 列出業務裏所有調用模型的地方，看哪些只接了一家。
- 給每個只接了一家的地方，補上至少一個另一家的備用模型。
- 按上文的規則，只在 429、5xx 和超時時切換，並把每次切換記進日誌。
- 故意讓主模型超時一次，確認請求真的落到了備用檔。
做完這四件事，下一次不管是機房停電還是模型廠商掉線，你的應用最多慢幾秒，而不是停半天。
常見問題
Q1：Google Cloud 倫敦停電後，要不要馬上遷出倫敦？
不一定。官方建議帶的是「如可行」，不是要求所有人立刻搬。工作負載在 europe-west2-b 的團隊，可以評估遷到別的可用區或區域；只調用模型 API 的團隊不用遷，先把模型兜底排好。
Q2：換模型會不會更貴？
按上面的順序反而更便宜。主模型 claude-opus-5-5 是輸入 4、輸出 20，兩個備用都是輸入 2、輸出 10。只有把 gpt-6-astra 這種輸入 10、輸出 50 的模型放進備用列表，成本纔會上去。
Q3：一把 Key 能不能同時調這幾家的模型？
可以。這幾個模型都走同一個 OpenAI 兼容地址，同一把 Key，只改 `model`。其中 gpt-6-astra 只走 OpenAI 接口，用的時候留意一下。
Q4：換到備用模型，回答質量會不會變差？
有可能會有差別，尤其是從最強的一檔換到便宜檔時。但對多數業務來說，慢一點、稍微差一點的回答，好過直接報錯。對格式要求高的場景，可以在 system 提示詞裏把輸出格式寫死，再用第二步的方法提前對比幾個模型的輸出，心裏有數再上線。
Q5：平時不出事，留着備用模型要多花錢嗎？
不用。按量計費只爲實際發出去的請求付錢，主模型一次成功，備用模型就不會被調用，也不產生費用。真正要花的只是接入時的那一點時間，以及演練時跑的幾次測試請求。
核心要點 Key Takeaways
- 兩次中斷：Google Cloud europe-west2-b 停電 7 小時 52 分；DeepSeek 官方記錄中斷 4 小時 52 分。
- 事實邊界：不是整個歐洲宕機，模型本身沒有因此下線；DeepSeek 的原因官方沒公佈。
- 何時換：只有 429、500、502、503、504 和超時才換，401、403 和內容安全拒絕不換。
- 做法：備用最好不是同一家；同一個地址、同一把 Key，只改
model。 - 驗收：接好後故意讓主模型超時一次，看請求是否落到備用檔，日誌裏有沒有記錄。
退額度補得了賬單，補不回停掉的工作。把模型順序提前排好，下次上游出問題，用戶最多感覺慢了幾秒。
參考資料
- Google Cloud Service Health：europe-west2 多項服務事故（Xs2XTHzAVC9YnafnPyzj），2026-10-20
- Google Cloud Service Health：Google SecOps europe-west2 安全產品事故（單獨記錄），2026-10-20
- BBC：英國銀行與公共服務受 Google Cloud 故障影響的報道，2026-10-20
- DeepSeek 官方狀態頁：2026-10-15 服務中斷記錄
- 官方文檔：docs.apiyi.com 實時動態
作者：APIYI 技術團隊
技術交流：如果你在做模型兜底時遇到問題，歡迎在評論區留言討論。
