8.0
热点
AI SCORE
技术实践2026-10-19 17:46
AI 接口上线必备：限流、重试与降级
dev.to · AI#接口可靠性#限流重试#降级
Editor brief · 编辑速览
文章针对 429、超时、流中断和突发流量，提出错误分类、耗时与次数双重限制、任务分流、并发控制及预设降级模式。还提醒配额可能同时约束请求数和令牌量，不能只按请求频率设计限流。
一次成功的模型请求，只能证明这次请求成功了。在生产环境中，集成方案必须能承受 429 响应、服务商过载、网络超时、流式传输中断和流量突增，避免把临时故障演变成重试风暴。下面的实用方法是：对错误分类，同时限制总耗时和尝试次数，区分工作负载类型，控制并发，并提前定义降级模式。
原型通常只有一个用户，上下文很短，几乎没有请求竞争。而在生产产品中，多种情况会叠加出现：一个用户上传了大型文档，调度器启动了批处理任务，聊天服务维持着数十个流式连接，短暂故障后，所有客户端又同时发起重试。
AI API 的配额往往是多维度的。服务商不仅可能限制请求数量，还可能限制输入或输出 token 的数量。例如，Gemini API 的限流文档就介绍了基于请求数和输入 token 数的限制，任何一个维度超限，都足以触发错误。具体数值取决于模型、项目、用量等级和可用容量，因此，一张通用配额表很快就会过时。
这里所说的可靠性，并不是承诺永远不出错，而是系统能够控制故障的影响范围、保住重要功能，并在恢复过程中避免制造额外负载。
仅看 HTTP 状态码还不够。客户端应该检查响应体中机器可读的错误代码、相关响应头，以及服务商的具体规则。同样是 429 状态，可能代表临时限流、每日配额耗尽，也可能代表触及费用上限。并非所有情况都适合立即重试。
这份处理矩阵必须根据具体操作调整。重复生成草稿，通常不会改变外部状态；但重复执行一个发送邮件、发布记录或发起付款的 Agent 调用，就可能把操作执行两遍。这类操作需要幂等键、结果日志，并在实际产生副作用的边界执行去重。
AI Feed 编辑建议：该表中的处理动作、尝试次数上限、数值示例和 fallback 选择，都是实用的编辑建议，并非经过受控研究验证的阈值。团队应结合服务商合同、产品要求和故障测试加以验证。
单次 HTTP 调用的 timeout，并不能限制用户的总等待时间。每次尝试 20 秒，尝试三次，再加上中间的等待，整个过程可能远超一分钟，而用户早已离开页面。因此，每个请求都应该有一个绝对 deadline：到达这个时间点后，不再开始新的尝试，队列不再为已关闭的连接等待响应，并取消子操作。
可以区分以下概念：
AI Feed 编辑示例，并非经过研究验证的阈值：一个交互式助手可以设置 12 秒的总 deadline，只允许针对临时错误额外尝试一次，并至少预留两秒生成 fallback。后台文档分类可以等得更久，但任务仍然必须设置过期时间：已经失去时效性的工作应该删除，而不是一天之后再执行。
一些官方 SDK 会自动重试部分 429 和 5xx 响应，具体行为取决于版本和配置。如果外层服务尝试三次，而 SDK 在每次尝试内部又尝试三次，那么一次用户操作最多会产生九次 API 调用。这只是用算术说明嵌套重试如何相乘，并不是推荐的尝试次数，也不是经过验证的阈值。
OpenAI 的限流指南建议，同时限制尝试次数和重试总耗时，并将 SDK 内置的重试计算在内。实用原则是：由一个组件统一负责重试策略。应用要么禁用 SDK 的自动重试，要么把它们纳入共享的尝试计数器和 operation deadline。
如果服务器提供了有效的 Retry-After 值，客户端就不应该在指定时间间隔结束前再次调用服务。再增加一小段随机等待，可以降低数千个客户端同时唤醒的概率。如果该响应头缺失或无效，就使用带抖动、设有上限的指数退避：每次失败后延长等待时间，但不超过上限。
算法应在等待前后检查：距离 deadline 是否还有剩余时间，是否还允许再次尝试，熔断器是否处于闭合状态，以及用户是否已经取消操作。无限重试不可接受。失败的请求本身也可能消耗每分钟限额，因此，频繁重新提交可能让过载持续得更久。
重试可以帮助系统从一次孤立的临时故障中恢复，却无法调节工作流量。应该在 AI API 前设置舱壁隔离机制，限制同时执行的调用数量。这对扇出工作流尤其重要：上传一个文件，就可能产生数百个分块请求。这里的“数百个”只是对潜在扇出规模的架构示例，并非通用或经过验证的阈值。
不仅要控制每秒请求数，还要控制并发数、预估 token 吞吐量，以及单个客户端带来的负载。应为交互操作预留一部分可用容量，避免批量索引挤占聊天流量。对于机密数据处理或离线工作负载，团队可以单独评估本地 AI 模型指南中介绍的场景，但本地处理同样需要资源管理。
当某个依赖持续出现一连串故障时，熔断器会暂时停止对它的调用，给它留出恢复空间。不过，恢复流量也要谨慎：如果熔断器闭合后立即释放整个队列，就可能再次制造流量尖峰。
AI Feed 编辑说明：这些策略和数值属于实用建议，并非经过研究验证的阈值。生产环境中的取值，应结合负载测试、成本约束、用户预期和服务商的具体行为进行校准。
队列应该存储任务标识符、deadline、尝试次数、优先级类别、去重键，以及指向输入数据的安全引用。死信队列有助于调查问题，但不应该变成一个让错误任务永远重试的存档库。队列会引入状态、延迟和存储需求；它是一项有意识的取舍，并不是免费获得的可靠性。
使用流式 API 时，错误可能发生在已经显示了几段内容之后。自动重放可能导致文本重复、输出变化，或再次调用工具。OpenAI 和 Gemini API 的错误文档都讨论了在流内部返回错误的情况。
客户端应该保留流的状态，区分“尚未显示任何内容”和“部分结果已经被使用”这两种情况。对于后一种情况，更稳妥的做法是将响应标记为未完成，并向用户提供继续生成的选项。如果模型会调用工具，就应该单独记录已经完成的调用，未经检查，不应再次执行。
fallback 不一定意味着切换到另一个模型。可选方案包括：不做额外分析，给出更短的回答；返回缓存结果，并说明其时效性；将任务放入队列；禁用非必要的 AI 功能；或者如实显示错误消息。
切换模型或服务商，会改变结果的格式、质量、延迟、成本和安全属性。因此，应该把它作为一条独立的产品分支进行测试。AI API 定价参考资料可以帮助评估成本上的取舍，但价格不能代替兼容性测试。
观察结论：服务商文档将临时限制和过载视为 API 正常运行中会遇到的情况。预测范围说明：这些事件在某个具体产品中会发生多频繁，只有负载测试和生产运行提供证据后才能知道。这种技术层面的故障暴露，也不意味着人们会“失业”：一个流程会受到 AI 组件故障的影响，描述的是系统依赖关系，而不是就业预测。分析 AI 对任务和职业的影响，需要另一套方法，例如 AI Jobs Impact Map。
p50、p95 和 p99 这些百分位标签是可观测性指标类别，并不是目标值或经过验证的阈值。应将内部 operation_id、尝试标识符，以及服务商提供的请求 ID 贯穿整个调用链。默认不要在日志中记录密钥或完整的用户输入。
分析日期：2026 年 10 月 19 日。本文基于截至该日期可获取的 OpenAI、Google 和 Microsoft 官方文档。文中的建议描述的是机制，而非固定配额。
AI Feed 编辑实用检查清单——并非经过验证的研究方案或阈值集合：
只有设置了明确的支出上限，才应对生产 API 运行负载测试，因为测试本身就可能耗尽配额。上述检查清单和所有实用数值，都是 AI Feed 的编辑建议，并非经过研究验证的阈值。团队应根据自身架构、服务商条款、风险状况和事故历史进行调整。
没有通用次数。上限取决于 operation deadline、成本、重试是否安全，以及工作负载类别。交互式工作流通常只需要很小的 retry budget；后台任务可以等得更久，但同样必须有有限的生命周期。本文中的任何次数示例，都是 AI Feed 编辑建议或算术示例，并非经过研究验证的阈值。
不应该。要先确定机器可读的错误代码和根本原因。临时限制可能允许延迟重试，而每日配额耗尽、计费问题或硬性预算上限，则需要等待或人工介入。
缓存可以降低平均负载，但不能代替流量控制。缓存尚未预热，或请求内容发生变化时，命中率可能大幅下降，因此系统必须能承受大量缓存未命中的情况。
如果结果不必在当前 HTTP 会话内返回、工作可以安全重试，而且允许延迟，那么队列就适用。对于交互式响应，快速降级往往比排队更合适。
AI Feed 编辑建议的实现顺序是：先建立错误处理矩阵、总 deadline、一个共享 retry budget，以及并发上限。然后区分工作负载类别，为可延后执行的工作增加队列，实现可观测性和熔断器，并测试降级模式。这个顺序属于实用的编辑建议，并非经过研究验证的实施顺序。
速率限制——OpenAI API
速率限制——Gemini API
API 错误——Gemini API
通过流量控制提高韧性——Microsoft Azure Well-Architected Framework
本文由 AI 辅助撰写，并已对照上述一手资料核查。
最初发表于 AI Feed：《如何构建有韧性的 AI API 集成：超时、重试、队列与优雅降级》。
如需进一步处理，你可以考虑屏蔽此人和／或举报滥用行为。