文小言如何写小说？大纲到正文创作全流程
2026-07-13 3396373
2026-07-13 0
把大模型API集成到生产系统，可不是调通一次对话就万事大吉了。上线之前，你得一项一项确认鉴权配置、超时策略、限速方案和监控体系是不是都到位了。漏掉任何一条，轻则接口偶尔抽风，重则服务雪崩、Token泄露，后果挺严重的。我这里整理了一份可以直接对照执行的检查清单，总共42个关键排查点，希望能帮你把风险都堵在部署之前。
鉴权失败通常不会触发重试机制——401和403压根就不该重试。一旦配置错了，所有请求瞬间全挂。上线前，下面这几项必须逐一确认。
现在主流大模型API主流有三种鉴权方式：Bearer Token、API Key（一般放在Header的Authorization或者自定义Header里）、JWT。你得确认自己用的鉴权方式和平台要求一致。这里头有个常见坑：腾讯云用的是x-api-key，阿里云百炼是Authorization: Bearer ，金山云则是X-Api-Key——Header名称大小写敏感，拼写错误是我见过最频繁的故障原因，没有之一。
逐字符检查请求Header的拼写、大小写，还有有没有多余空格。比如Authorization: Bearer 里“Bearer”首字母大写，后面跟一个空格；你要写成bearer或者少了空格，服务器直接拒绝。最保险的办法：写一个独立测试用例，用curl直接验证Header没问题了再走代码逻辑。
要明确区分哪些错误码不可重试：401（未授权）、403（禁止访问）、AI_MODEL_DISABLED（模型被停用）等等。这些错误不应该触发重试，而是应该走报警流程。我建议你建一个错误码映射表，标明哪些该重试、哪些该抛出异常、哪些需要人工介入。比如腾讯云文档里列出的EXCEED_CONCURRENT_REQUEST_LIMIT属于限流类，可以重试；而AI_MODEL_CONFIG_MISSING就需要你去检查控制台配置，重试一万次也没用。
超时设置不合理，会导致客户端大量线程挂起、连接池耗尽、整个系统响应变慢。上线前必须分别配好连接超时和读取超时，还得考虑流式场景的特殊性。
建议值：5到10秒。连接超时指的是从客户端发起TCP三次握手到收到SYN-ACK的等待时间。如果目标网络延迟高或者端口没开放，设得太短（比如1秒）可能误判，设得太长（比如30秒）又会让客户端线程长时间被阻塞。合理的默认值是8秒，你可以根据实际网络环境微调。
读取超时指的是从发送完请求到收到第一个字节（或者流式场景下两个chunk之间）的最大等待时间。大模型API响应时间波动非常大——受模型大小、输入长度、并发负载影响。我建议设60到120秒。固定30秒在大多数商业API场景下太激进了——模型正在生成内容，客户端突然关闭连接，不仅浪费服务端算力，还会让用户看到不完整的半截回答。
设了重试策略之后，有可能某次请求在超时前失败了，然后重试又超时，多次重试累计的总等待时间很可能超出用户体验忍耐极限。解决方案：引入总截止时间（Deadline），比如单次请求最多允许300秒，不管重试几次，累计时间超过300秒就直接返回失败。这需要客户端支持超时传播（比如gRPC的Context超时），HTTP场景下可以用urllib3的total_timeout或者自定义计时器。
AI_MODEL_CONFIG_MISSING（配置问题）。重试策略推荐指数退避加抖动（Jitter）：首次延迟500ms，每次翻倍，最大延迟5秒，总重试次数3到5次。注意避免同时发起大量重试造成“惊群效应”。
限速这件事不能光靠服务端，客户端也得主动控制请求速率，否则很容易被服务端拒绝甚至封禁。上线前需要搞定下面这些检查项。
大多数商业API以RPM（每分钟请求数）和TPM（每分钟Token数）作为限流单位。你需要根据业务数据估算基线值：
最低RPM = 日均调用量 ÷ (24×60) × 高峰倍率（通常取2到5倍）
最低TPM = 日均消耗Token数 ÷ (24×60) × 高峰倍率
举个例子，日均调用10万次，高峰倍率取4，那最低RPM大概是277。不过要注意，部分平台TPM包含输入和输出Token的总和，得分别估算。如果业务有秒杀或者活动，倍率要根据历史峰值调整。上线前先申请比估算值略高的额度，运行一周后根据监控数据再调整。
golang.org/x/time/rate或者Python的ratelimiter），别自己手写——手写很容易因为时间和并发问题产生误差。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——批量调用可以大幅提高吞吐量，但需要等待响应，适合延迟不敏感的场景，比如数据批处理。
没有监控，所有配置都是盲猜。上线前必须建立至少三个维度的监控：调用量、错误率、延迟分布。
推荐用Prometheus加Grafana，或者云厂商自带的监控平台。关键点：所有API调用必须埋点上报，包括耗时、状态码、请求ID（如果服务端返回的话）。上线前测试一下，看看能不能通过日志查看到每一次调用的完整链路。
单独监控“客户端被限流次数”和“服务端返回429次数”。如果客户端自己做了限速，但仍然频繁收到429，说明客户端速率估算偏低了，需要调整令牌桶参数。同时监控队列等待时间，如果等待时间过长（比如超过10秒），就得考虑扩容或者降级了。
当监控发现服务端持续异常（比如连续5分钟错误率超过10%），应该触发降级逻辑：切换到备用模型或者备用API服务商（如果有的话）；如果没有备选，就直接返回静态回复或者缓存结果。熔断器（比如Hystrix或者Sentinel）可以自动切断故障调用，避免级联失败。上线前一定要模拟一次故障注入，测试降级方案是否真的生效。
为了方便团队执行，我把上面提到的要点整理成了可打印的勾选项（节选核心项）。建议每完成一项就打√并签名确认。
大模型API接入可不是一次配置就能终身使用的。业务增长、模型迭代、平台规则变化，都会让这份清单里的某些项失效。我建议每季度，或者每次模型版本更新时，重新跑一遍这份检查清单。把鉴权、超时、限速、监控这四个维度纳入上线标准流程，你才能从“调通接口”升级为“可靠服务”。如果你正在规划上线一个AI功能，不妨直接打印本清单，逐条过目——它能帮你堵住绝大多数早期故障。