模型呼叫報錯怎麼排查？

​

簡短回答

• 400、401、403、引數不支援、安全攔截和分組不匹配，通常需要修改請求或配置，重複重試不會解決問題。
• 429、503、部分 504 和 Upstream model timed out 可能與上游負載、資源或長請求有關，應先檢查日誌，再使用有限次數的指數退避重試。
• 如果只有某個模型或分組異常，可以測試該模型的兜底分組；如果多個模型同時異常，應優先檢查 API Key、Base URL 和網路鏈路。

​

先記錄完整錯誤資訊

​

按錯誤型別排查

​

標準排查步驟

​

最小請求測試示例

curl https://api.apiyi.com/v1/chat/completions \
  -H "Authorization: Bearer YOUR_API_KEY" \
  -H "Content-Type: application/json" \
  -d '{
    "model": "YOUR_MODEL",
    "messages": [
      {"role": "user", "content": "請回復：測試成功"}
    ]
  }'

​

如何避免重複報錯

• 先用最小請求跑通，再逐項加入 stop、工具呼叫、推理強度、圖片和其他可選引數。
• 為不同模型維護引數兼容表，不要假設所有模型都支援同一組引數。
• 遇到 429 不要立即併發重發，使用指數退避並控制單模型併發。
• 圖片和推理請求使用足夠大的 timeout；SDK 自帶重試時，避免與業務層重試疊加。
• 為重要模型配置經過實際驗證的兜底分組，並定期用真實業務引數測試。

​

常見問題

​

仍然無法解決？聯絡我們

• 模型名稱、令牌分組和 Base URL
• 完整錯誤訊息、HTTP 狀態碼和 request ID
• 問題發生時間（請註明 UTC+8）
• 最小化後的請求示例或脫敏後的請求體
• 呼叫日誌中是否存在消費記錄

企業微信客服

掃碼新增，或點選本卡片直接聯絡客服。模型報錯、超時、分組和計費排查

郵件諮詢

客服郵箱：[email protected]郵件標題建議包含「模型報錯 + 模型名稱」。

​

相關文件