AI API 可靠路由、備援與請求診斷

可靠的 AI API 路由，不等於替同一筆請求加上無限重試。每把 API 金鑰都需要明確的主要群組、依序排列的備援群組、可用模型能力與請求限制；同時，請求變慢或失敗時，也要留下使用者看得懂的證據。

良好的路由設計能解釋結果，並避免切換群組時悄悄改變指定模型或計費政策。

從明確的金鑰政策開始

Modelflare 提供兩種路由方式：

• 一般 API 金鑰使用一個明確的主要群組，以及依優先順序排列的備援群組。
• 智慧 API 金鑰會評估帳戶目前可用的群組，並依策略繼續嘗試符合條件的候選群組。

備援順序不是流量分配，而是優先序。主要群組不可用時，請求才會依設定順序往後嘗試。

不同應用程式與環境應使用不同金鑰。這樣比所有工作共用一把金鑰更容易釐清群組權限、額度、有效期限與用量。

備援群組必須維持請求契約

加入備援清單前，請確認該群組：

1. 提供請求所指定的模型；
2. 支援相同端點與串流行為；
3. 允許必要的 Service Tier 或供應商專屬欄位；
4. 用量倍率與請求速率限制都在可接受範圍；
5. 已對該帳戶實際解鎖。

備援不是任意替換模型的許可。指定模型與協定仍然定義傳輸契約。

理解群組請求限制

請求速率限制會依帳戶與實際處理請求的群組套用。拆分 API 金鑰有助於分析用量，但不會自動繞過帳戶或群組限制。

目前群組達到限制時，具有備援群組的金鑰可以繼續嘗試下一個可用群組。若沒有備援，請求會收到 429。用戶端重試應採有限次數與退避等待，不要立刻製造另一波突發流量。

使用單筆請求效能指標

用量記錄提供判斷請求狀況所需的產品層指標：

指標	可協助判斷的問題
總回應時間	從送出請求到完成所花的時間
第一個回應	第一個有效文字、推理或工具事件出現前的時間
第一段可見文字	預期輸出文字時，畫面開始顯示文字前的時間
可見輸出速度	可見文字開始後的生成速度
輸出 Token	該請求產生的輸出量

第一個回應很慢，通常代表生成開始前的等待較長；若很快開始回應，但後續輸出速度低，問題較可能出在生成階段。請搭配狀態、模型、群組與時間範圍，判斷是單次延遲還是持續性異常。

只包含工具呼叫的回應可能沒有可見文字，因此對 Responses 流量而言，「第一個回應」比「第一段可見文字」更適合作為首個有效輸出的指標。

保留安全而有效的證據

Modelflare 的時間資料不包含 Prompt、回應文字、原始請求本文、API 金鑰、電子郵件或明文 IP 位址。營運記錄仍可協助診斷，但不會變成第二套內容儲存空間。

處理事件時，建議記錄：

• 請求 ID 與時間；
• 指定模型與實際群組；
• 端點與串流模式；
• 用戶端收到的狀態；
• 總回應時間與第一個回應時間；
• 用戶端是否在請求完成前取消。

這些資料足以協助支援人員核對群組切換、模型生成偏慢與用戶端取消，又不必在一般記錄中暴露內部拓撲。

正式環境可靠性檢查表

• 每個應用程式使用獨立 API 金鑰。
• 有意識地設定主要群組與備援順序。
• 在每個候選群組確認模型與協定支援。
• 用戶端逾時符合真實工作負載。
• 對可重試錯誤採有限次數、含隨機抖動的退避。
• 驗證、額度或模型權限錯誤不可當成暫時故障反覆重試。
• 同時測試非串流與串流請求。
• 監控 429、第一個回應、輸出速度與取消。
• 將備援視為等價選項前，先檢查群組價格。

可靠性來自維持請求契約，並在失敗時留下足以說明原因的資料。依序備援可降低對單一群組的依賴，效能與用量記錄則讓剩餘問題可以被解釋。