模型调用报错怎么排查？

​

简短回答

• 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]邮件标题建议包含「模型报错 + 模型名称」。

​

相关文档