OpenAI API 延遲唔止 ChatGPT 慢：香港 AI 流程點樣避開誤判

圖：Android Authority．原文連結

如果你今日覺得 ChatGPT 或接駁 OpenAI API 嘅工具突然慢咗，第一步唔應該係即刻重開 router、改程式，或者懷疑同事又改壞咗 key。今次重點唔係單純「ChatGPT 開唔到」，而係 OpenAI 官方確認 API 有延遲同錯誤，對用 API 做內容生成、客服 automation、內部知識庫搜尋、語音轉文字，甚至 Codex 類開發工具嘅團隊都可能有影響。最麻煩嘅位係，AI 服務一慢，前線通常只會見到轉圈、timeout、bot 無回覆，好容易誤判成公司連線、程式 bug 或權限問題。呢類事故要處理得好，靠嘅唔係不停撳重試，而係一套清楚嘅確認、暫停同降級做法。

Android Authority 最初報道時，OpenAI Status 顯示 API 正出現 elevated latency and errors，當時仍係 investigating。之後官方 incident 更新已推進到 monitoring：截至 OpenAI RSS feed 香港時間 5 月 28 日凌晨約 12:50 顯示，OpenAI 已套用 mitigation，並正監察恢復情況。受影響組件寫明係 Chat Completions、Audio、Embeddings，incident 最早由 5 月 27 日 22:47（香港時間）開始記錄，23:59 更新為 monitoring。換句話講，呢件事最應該被理解為 API 層面嘅效能同錯誤率事故，而唔係籠統講成所有 ChatGPT 用家全面停擺。

同一時間，OpenAI Status 亦列出另一宗 Android ChatGPT Business 用家切換 workspace 有困難嘅 incident，影響 Login 組件，狀態係 investigating；另外較早前 FedRAMP 用戶登出後登入問題就已標示 resolved。呢幾件事擺埋一齊，正好提醒大家：ChatGPT app、ChatGPT Business、OpenAI API、Codex、不同模型同不同組件，未必同一時間受同一個原因影響。公司 IT team 做初步排查時，應該先分清自己出事嘅係網頁對話、Android app workspace、API 呼叫，定係後台批量任務。標題講 ChatGPT 慢可以方便理解，但技術上要避免將 API incident 寫成整個 ChatGPT 平台死機。

唔係每個錯都係你個 app

OpenAI API 依家已經唔只係工程師試 prompt 嘅工具，而係好多產品同日常流程入面嘅隱形基建。內容團隊可能用 Chat Completions 出初稿同改標題，電商或 SaaS 會用 embeddings 做搜尋同推薦，客服 bot 會接住 CRM 同 ticket system，自動把客戶問題分類，再交畀模型寫回覆。當 Chat Completions 慢咗，客服前台可能只見到一句「請稍等」卡住；當 Embeddings 出錯，知識庫搜尋可能搵唔到相關文件；當 Audio 組件降級，會議紀錄或語音客服轉寫就會拖慢。呢啲表徵好似分散，但源頭可以係同一個 API 層面事故。

OpenAI Status 頁有一個重要細節：可用率指標係按 tier、model 同錯誤類型做 aggregate，單一客戶實際情況會因訂閱層級、使用模型同 API 功能而異。即係就算 status 顯示某組件 degraded，唔代表每個請求都會失敗；相反，就算大圖看似恢復，某個模型、某個功能或某條路徑仍然可以對你特別慢。香港公司如果只靠同事口頭回報「我得你唔得」，好容易浪費時間。比較穩陣嘅做法係有自己嘅 synthetic check，例如由香港辦公室、雲端 server 同 CI 環境各自定時打一個低成本測試 request，分開記錄 latency、HTTP status、模型名、request id 同錯誤類型。

排查時可以用一個短 checklist，唔好一見 timeout 就大規模重試：

• 先開 OpenAI Status 同 RSS，確認有冇同你用緊組件相符嘅 incident。
• 分開睇 APIConnectionError、APITimeoutError、InternalServerError、RateLimitError，唔好將全部寫成同一個「OpenAI 壞咗」。
• 暫停非即時批量任務，例如 overnight summarization、SEO 文案重寫、embedding rebuild，避免恢復時撞爆自己 quota。
• 對可重試錯誤用 exponential backoff 加 jitter，並尊重 response header；對 4xx 權限或格式錯誤就唔好盲重試。
• 記低 x-request-id，必要時加自己嘅 X-Client-Request-Id，等之後同供應商或內部 log 對得返。

跌一跌唔應該拖垮成條鏈

一個成熟嘅 AI 產品唔應該將 OpenAI API 當成永遠即時可用嘅同步函式。客服 automation 應該有 queue、timeout、重試上限同人手接管；內容工具應該將 job 標成 pending 或 delayed，而唔係直接當 failed；需要產生 invoice、合約摘要或合規文件嘅流程，更要有 idempotency，避免同一個 request 重試幾次後產生幾份結果。對用家嚟講，最差體驗未必係等多一陣，而係系統一邊慢、一邊重複發送、一邊無解釋。工程上要處理嘅係背壓同狀態，而唔只係把 timeout 由 30 秒改到 120 秒。

內容團隊同開發者亦要有自己嘅降級習慣。編輯台如果靠 AI 幫手整理外電、改標題或生產摘要，API 出問題時應該切回人工筆記同原始來源，未核實內容唔好硬推上線；教學用途可以先保留 prompt 同素材，等服務穩定再跑；Codex 或其他 coding agent 卡住時，就先停大型重構同自動修復，避免重複開 task 令狀態更亂。對客服 bot，最實際係預備幾句有範圍嘅 fallback 回覆，例如確認已收到、轉交人手、稍後補覆，而唔係叫模型在不穩定狀態下繼續即場編答案。AI 可以加速，但出事時要收窄動作，唔係加大動作。

香港場景：影響多數係間接

今次未見有香港專屬 outage 數據，所以唔應該寫成「香港大停擺」。不過本地公司一樣可能間接受影響：有公司用海外 workspace、外判開發團隊、第三方 SaaS、客服平台、會議紀錄工具或內容管理工具，而背後可能接駁 OpenAI API。OpenAI 亦有官方 API 支援地區清單同 ChatGPT 支援地區清單，清單會更新；本地公司如果係用官方 API 做產品，應該自己確認帳戶、付款、地區同合規安排，唔好單靠某個 SaaS 可以用就當等於所有官方服務都適用。呢篇亦冇港行、港版價或本地售價角度，因為今次係雲端服務可用性問題，唔係硬件或零售供應問題。

香港金融業同企業界近年明顯加快試 GenAI，金管局轄下 HKIMR 已就金融服務採用生成式 AI 發表研究，監管機構同數碼港亦推出 GenA.I. Sandbox++ 去推動金融服務場景測試。呢個背景令 API outage 更值得重視：銀行、保險、券商、fintech、教育機構同內容公司未必全部直接買 OpenAI API，但只要上游工具鏈有一格用到 OpenAI，延遲就可以變成前線 SLA 問題。香港公司最需要補嘅唔係再多一個 AI demo，而係供應商清單、資料流向、fallback 流程同 incident owner。當客戶問點解 bot 無反應，前線要知道係轉人工、延後處理，定係通知工程 team 查 log。

行業角度唔係換供應商咁簡單

有團隊會話：OpenAI 慢就切去其他模型。概念上合理，但實作上唔係一個 toggle。不同供應商嘅 prompt 行為、tool calling 格式、內容安全策略、embedding 維度、成本、資料保留安排同區域合規都可能不同；如果你即時把客服、法律摘要或財務分析切去另一個模型，輸出風格同風險都會變。雲端供應商例如 Azure 亦有自己 Service Health 同 status 機制，公開頁面同個別客戶資源通知嘅粒度未必一樣。真正有用嘅多供應商策略，係預先把任務分成可替代、需人工覆核、不可降級三類，而唔係出事先臨急改 endpoint。

今次 OpenAI API 事故未必會拖好耐，但它反映咗一個更長期嘅問題：AI 已經由「好用工具」變成產品依賴，出事時就要用產品同 SRE 思維處理。對香港公司嚟講，今晚要做嘅唔係驚慌，而係先睇官方狀態、暫停低優先級重試、保留 trace、通知受影響 team，再等 monitoring 走到 resolved 後慢慢恢復批量工作。下次再遇到 ChatGPT 慢或 API timeout，最有價值嘅問題唔係「OpenAI 係咪又壞」，而係「我哋有冇辦法知道邊度壞、停邊啲 job、保住邊啲用戶體驗」。

參考來源

• Android Authority — ChatGPT feeling slow for you today? OpenAI confirms issues — original report
• OpenAI Status — 官方即時狀態頁，用嚟核對現時有 API 同 ChatGPT 相關 incident。
• OpenAI Status: Elevated Latency and Errors on API — 官方 API incident，列明 monitoring、mitigation 同受影響組件。
• OpenAI API Docs: Error codes — 參考官方 API 錯誤分類、timeout、server error、rate limit 同重試建議。
• OpenAI API Reference: Supplying your own request ID — 參考 request id / client request id 對 debug timeout 同支援查詢嘅用途。
• OpenAI Help Center: OpenAI API supported countries and territories — 補充香港公司採用官方 API 前要核對地區同帳戶安排。
• HKMA: Financial Services in the Era of Generative AI — 香港金融業 GenAI 採用背景，支持本地企業流程受 AI 供應鏈影響嘅脈絡。
• Microsoft Learn: Azure status overview — 補充雲端供應商 status / Service Health 監察粒度，作行業對照。

本文根據原文及公開資料整理；資料有出入時，以原文及官方資料為準。