How to Handle API Failover and High Concurrency?
正確的分類：①401/403——這家上游的金鑰被拒，換家且冷卻；②404——這家沒這個模型，換家不冷卻；③429——限流，冷卻並換家；④5xx——上游故障，冷卻換家；⑤逾時／連線錯——冷卻換家。400/422 這類參數問題各家行為不同，穩妥做法也是先換一家試，全部拒絕才回真實 4xx。
OlithmRouter 的實作：所有 4xx／5xx／逾時都會換下一家，全部拒絕才把真實狀態碼回給客戶端（SDK 才能正確分類「請求錯了」還是「服務掛了」）；冷卻以（上游×模型）為鍵、指數退避，冷卻中的上游排到候選尾端但仍保留——避免「全冷卻時直接全滅」。
上游逾時要涵蓋「連線＋回應頭＋首字」，而不是只看 body。設太長（如 300 秒）：一個假死的上游會吃掉整個重試預算；設太短：慢模型會被誤殺。建議按模型等級區分，並確保「逾時也算失敗、觸發換家」。
串流請求要注意：換家只能在「還沒向客戶端吐出任何位元組」之前進行；已經開始輸出後上游斷流，只能中止並由客戶端重試——這是所有閘道的物理限制。
①配置刷新單飛：金鑰／上游清單不能每個請求都拉一次，要用定期快取＋單飛刷新，否則高併發時配置端點會被打爆。②冷卻不擋路：故障上游進冷卻後仍保留在候選尾端，全冷卻時照樣服務而不是 503。③併發分攤：請求量超過閾值時把輪轉起點平移到其他上游，避免全部壓在第一家。
OlithmRouter 另有會話黏性（同一對話黏同一家上游）——讓上游的 prompt 快取持續命中，多輪對話的成本直接下降，且黏性只是「偏好」不是「鎖定」，上游故障時照樣換家。
閘道做得再好，客戶端也要守基本禮儀：指數退避重試、尊重 429 的 Retry-After、以及把 request_id 寫進自己的日誌以便對帳。兩邊配合，上游故障才能真正「使用者無感」。