把大模型API集成到生产系统，可不是调通一次对话就万事大吉了。上线之前，你得一项一项确认鉴权配置、超时策略、限速方案和监控体系是不是都到位了。漏掉任何一条，轻则接口偶尔抽风，重则服务雪崩、Token泄露，后果挺严重的。我这里整理了一份可以直接对照执行的检查清单，总共42个关键排查点，希望能帮你把风险都堵在部署之前。

一、鉴权：第一道防线，也是最容易翻车的地方

鉴权失败通常不会触发重试机制——401和403压根就不该重试。一旦配置错了，所有请求瞬间全挂。上线前，下面这几项必须逐一确认。

鉴权方式确认

现在主流大模型API主流有三种鉴权方式：Bearer Token、API Key（一般放在Header的Authorization或者自定义Header里）、JWT。你得确认自己用的鉴权方式和平台要求一致。这里头有个常见坑：腾讯云用的是x-api-key，阿里云百炼是Authorization: Bearer <token>，金山云则是X-Api-Key——Header名称大小写敏感，拼写错误是我见过最频繁的故障原因，没有之一。

Token/Key生命周期管理

• 过期时间：Bearer Token通常有有效期，短的半小时，长的大几个小时，得配好自动刷新机制。API Key一般长期有效，但一旦泄露就得轮换。代码里一定要实现Token过期前就预刷新，别等返回401了再重新获取，那样太被动。
• 轮换策略：创建新的API Key后，旧Key得立刻停用。我建议在系统配置里支持多个Key轮换，避免单点失效。
• 安全存储：无论如何，别把Key硬编码在代码仓库里，那是作死。应该用环境变量、密钥管理服务（比如KMS）或者配置中心。上线前检查一下日志里会不会意外打印Key——开发阶段这种问题太常见了。

Header格式排查

逐字符检查请求Header的拼写、大小写，还有有没有多余空格。比如Authorization: Bearer <token>里“Bearer”首字母大写，后面跟一个空格；你要写成bearer或者少了空格，服务器直接拒绝。最保险的办法：写一个独立测试用例，用curl直接验证Header没问题了再走代码逻辑。

鉴权失败后的处理策略

要明确区分哪些错误码不可重试：401（未授权）、403（禁止访问）、AI_MODEL_DISABLED（模型被停用）等等。这些错误不应该触发重试，而是应该走报警流程。我建议你建一个错误码映射表，标明哪些该重试、哪些该抛出异常、哪些需要人工介入。比如腾讯云文档里列出的EXCEED_CONCURRENT_REQUEST_LIMIT属于限流类，可以重试；而AI_MODEL_CONFIG_MISSING就需要你去检查控制台配置，重试一万次也没用。

二、超时：防止线程饿死与雪崩的关键

超时设置不合理，会导致客户端大量线程挂起、连接池耗尽、整个系统响应变慢。上线前必须分别配好连接超时和读取超时，还得考虑流式场景的特殊性。

连接超时（Connect Timeout）

建议值：5到10秒。连接超时指的是从客户端发起TCP三次握手到收到SYN-ACK的等待时间。如果目标网络延迟高或者端口没开放，设得太短（比如1秒）可能误判，设得太长（比如30秒）又会让客户端线程长时间被阻塞。合理的默认值是8秒，你可以根据实际网络环境微调。

读取超时（Read Timeout）

读取超时指的是从发送完请求到收到第一个字节（或者流式场景下两个chunk之间）的最大等待时间。大模型API响应时间波动非常大——受模型大小、输入长度、并发负载影响。我建议设60到120秒。固定30秒在大多数商业API场景下太激进了——模型正在生成内容，客户端突然关闭连接，不仅浪费服务端算力，还会让用户看到不完整的半截回答。

• 非流式请求：读取超时要覆盖全部响应时间，值可以设为模型P99响应时间的1.5倍（通过监控数据测算）。一般建议起始值80秒。
• 流式请求（SSE）：和服务端保持长连接，每隔几百毫秒到几秒收到一个chunk。读取超时应覆盖两个chunk之间的最大间隔，而不是整个对话时间。常见错误：对整个SSE连接设置120秒超时，结果对话超过2分钟就被强制断开了。正确做法：采用逐行读取的超时检测，每行数据间隔建议设置30秒，如果30秒内没有新chunk就判定超时并断开重连。

超时与重试的联动陷阱

设了重试策略之后，有可能某次请求在超时前失败了，然后重试又超时，多次重试累计的总等待时间很可能超出用户体验忍耐极限。解决方案：引入总截止时间（Deadline），比如单次请求最多允许300秒，不管重试几次，累计时间超过300秒就直接返回失败。这需要客户端支持超时传播（比如gRPC的Context超时），HTTP场景下可以用urllib3的total_timeout或者自定义计时器。

什么情况下应该重试

• 应该重试：连接超时（网络抖动）、读取超时（服务端暂时过载）、5xx（服务端错误）、429（限流，需要配合退避）。
• 不应该重试：401/403（鉴权问题）、400（参数错误，需要检查请求体）、AI_MODEL_CONFIG_MISSING（配置问题）。

重试策略推荐指数退避加抖动（Jitter）：首次延迟500ms，每次翻倍，最大延迟5秒，总重试次数3到5次。注意避免同时发起大量重试造成“惊群效应”。

三、限速：客户端限流与服务端限速的双向协同

限速这件事不能光靠服务端，客户端也得主动控制请求速率，否则很容易被服务端拒绝甚至封禁。上线前需要搞定下面这些检查项。

预估业务所需的RPM/TPM

大多数商业API以RPM（每分钟请求数）和TPM（每分钟Token数）作为限流单位。你需要根据业务数据估算基线值：

最低RPM = 日均调用量 ÷ (24×60) × 高峰倍率（通常取2到5倍）
最低TPM = 日均消耗Token数 ÷ (24×60) × 高峰倍率

举个例子，日均调用10万次，高峰倍率取4，那最低RPM大概是277。不过要注意，部分平台TPM包含输入和输出Token的总和，得分别估算。如果业务有秒杀或者活动，倍率要根据历史峰值调整。上线前先申请比估算值略高的额度，运行一周后根据监控数据再调整。

客户端限速实现

• 令牌桶算法：最常用，固定速率产生令牌，每次请求消耗一个。我建议直接用现成库（比如Go的golang.org/x/time/rate或者Python的ratelimiter），别自己手写——手写很容易因为时间和并发问题产生误差。
• 排队加等待：当客户端达到速率上限时，不要直接拒绝，而是把请求放进队列等待可用令牌。队列长度得限制，防止内存溢出。等待超时也要设个上限（比如10秒），超时了就返回“服务繁忙”错误。
• 配合服务端等待参数：阿里云百炼提供了X-DashScope-Wait-Timeout这类排队参数，客户端可以设置最大等待秒数，让服务端把请求放进队列，而不是立即返回429。其他平台可能也有类似的x-queue-timeout参数，上线前得确认平台文档。

服务端限流响应处理

当收到429或者EXCEED_CONCURRENT_REQUEST_LIMIT时，检查响应Header里的Retry-After字段（单位秒），按指示延迟重试。如果没有这个字段，就用默认的指数退避（首次1秒，最多30秒）。注意：客户端限速配置不要低于服务端限制的70%，否则大量请求被本地拒绝，会影响可用性。

不同平台的限流差异

各大厂商的限流阈值差异挺大的：有的按RPM加TPM双维度控制，有的按并发数控制，还有的按模型分别限制（比如qwen3-235b-a22b的RPM/TPM和qwen-turbo就不一样）。建议在上线前梳理目标平台各模型的限流额度，列成对照表，并且确认是否支持Batch API——批量调用可以大幅提高吞吐量，但需要等待响应，适合延迟不敏感的场景，比如数据批处理。

四、监控：看不见的故障才是真麻烦

没有监控，所有配置都是盲猜。上线前必须建立至少三个维度的监控：调用量、错误率、延迟分布。

核心指标采集

• 调用量：按模型、API端点、状态码（2xx/4xx/5xx）分别统计。注意区分成功调用和部分成功——比如流式响应中间断开的情况。
• 错误率：总错误率加上各类错误码占比。重点监控429率（限流）、5xx率（服务端故障）、4xx率（参数/鉴权问题）。我建议设置告警：错误率超过5%且持续3分钟就触发。
• 延迟（Latency）：连接时间、首字节时间、完整响应时间（非流式）或完成时间（流式）。要记录P50/P95/P99，光看平均值没意义。P99延迟超过设定阈值时应触发告警。
• 失败原因分布：对超时、限流、参数错误等分类统计，这样能快速定位故障根因。

监控工具集成

推荐用Prometheus加Grafana，或者云厂商自带的监控平台。关键点：所有API调用必须埋点上报，包括耗时、状态码、请求ID（如果服务端返回的话）。上线前测试一下，看看能不能通过日志查看到每一次调用的完整链路。

• 日志级别：错误调用要打印request_id和错误详情，并且在日志里标为ERROR级别。
• 告警规则：比如连续5次调用失败、P99延迟超过120秒、429占比超过20%等等。注意告警要防抖动：间隔至少1分钟，避免告警风暴。

限流监控的特殊关注点

单独监控“客户端被限流次数”和“服务端返回429次数”。如果客户端自己做了限速，但仍然频繁收到429，说明客户端速率估算偏低了，需要调整令牌桶参数。同时监控队列等待时间，如果等待时间过长（比如超过10秒），就得考虑扩容或者降级了。

降级与熔断

当监控发现服务端持续异常（比如连续5分钟错误率超过10%），应该触发降级逻辑：切换到备用模型或者备用API服务商（如果有的话）；如果没有备选，就直接返回静态回复或者缓存结果。熔断器（比如Hystrix或者Sentinel）可以自动切断故障调用，避免级联失败。上线前一定要模拟一次故障注入，测试降级方案是否真的生效。

五、检查清单总表：42个必查项速览

为了方便团队执行，我把上面提到的要点整理成了可打印的勾选项（节选核心项）。建议每完成一项就打√并签名确认。

鉴权（10项）

• [ ] 鉴权方式与平台文档完全一致
• [ ] Header名称大小写、空格验证通过
• [ ] Token/Key未硬编码，已使用安全存储
• [ ] Token自动刷新机制已测试
• [ ] API Key轮换方案已落地
• [ ] 日志中无敏感信息泄露
• [ ] 401/403不触发重试
• [ ] 错误码映射表已建立
• [ ] 鉴权失败告警配置完成
• [ ] 用curl等工具独立验证鉴权通过

超时（10项）

• [ ] 连接超时≤10秒
• [ ] 读取超时（非流式）≥60秒
• [ ] 读取超时（流式）按chunk间隔设置
• [ ] 总截止时间（Deadline）已实现
• [ ] 重试次数≤5次
• [ ] 指数退避+抖动算法已启用
• [ ] 不该重试的情况已排除
• [ ] 超时日志包含请求ID
• [ ] 超时告警阈值合理
• [ ] 模拟网络抖动测试通过

限速（12项）

• [ ] 日均调用量/高峰倍率已估算
• [ ] 申请的RPM/TPM额度≥估算值
• [ ] 令牌桶客户端限速已实现
• [ ] 排队等待超时限制已设置
• [ ] 服务端排队参数已使用（如有）
• [ ] 429响应中Retry-After字段被解析
• [ ] 客户端限速≤服务端限制的70%
• [ ] 多模型限流额度对照表已整理
• [ ] Batch API已评估是否使用
• [ ] 熔断器配置完成
• [ ] 降级方案已编写并测试
• [ ] 压测中限流表现符合预期

监控（10项）

• [ ] 调用量/错误率/延迟埋点完成
• [ ] P99延迟已监控并设告警
• [ ] 各类错误码分布可查
• [ ] 客户端被限流次数可查
• [ ] 队列等待时间可查
• [ ] 日志包含request_id
• [ ] 告警规则无干扰性抖动
• [ ] 错误率超过阈值自动触发告警
• [ ] 故障注入测试通过
• [ ] 监控Dashboard已对团队可见

结语

大模型API接入可不是一次配置就能终身使用的。业务增长、模型迭代、平台规则变化，都会让这份清单里的某些项失效。我建议每季度，或者每次模型版本更新时，重新跑一遍这份检查清单。把鉴权、超时、限速、监控这四个维度纳入上线标准流程，你才能从“调通接口”升级为“可靠服务”。如果你正在规划上线一个AI功能，不妨直接打印本清单，逐条过目——它能帮你堵住绝大多数早期故障。