Azure OpenAI 报出 429 Too Many Requests 时，先不要根据 Azure Monitor 的令牌用量判断“配额还没用完”。限流判断发生在请求到达时，使用的是预计处理量；监控中的令牌用量反映成功处理后计费的消耗。 输出上限过大、请求集中到达，甚至部分随后被拒绝的请求，都可能让这两个数相差很大。Microsoft 的解释
最有效的起点是保留一次失败请求及其前后成功请求的状态码、错误正文、响应头、时间和部署名称，再确认它们经过了哪些服务。这样才能判断该降低请求速率、调整输出上限、重新分配 TPM，还是处理网关策略或后端容量问题。
下文适用于 Azure 全球版中的 Azure OpenAI，主要讨论 Standard 类部署；不据此推定世纪互联 Azure 中国的模型、配额或操作入口。文档与界面说明核对至 2026 年 9 月 5 日，实际数值以你的订阅和部署为准。
先确认 429 是谁返回的
同一个应用可能依次经过业务服务、Azure API Management（APIM）和 Azure OpenAI。客户端拿到 429，只能说明这条调用链拒绝了请求；它不能单独证明 Azure OpenAI 的部署 TPM 已经耗尽。
如果接入了 APIM，先用网关跟踪信息查看请求是否到达 Azure OpenAI，以及命中了哪条策略。APIM 的 llm-token-limit 有自己的 counter-key 和令牌计数：超出每分钟速率会返回 429，超出指定周期的令牌配额会返回 403。它与后端部署的 TPM 是两套限制；增加 Azure 配额不会自动提高网关限额。也不能反过来把所有 403 都归因于该策略。APIM 策略说明
排查记录至少应能把以下信息连在一起：
- 请求身份： UTC 时间、应用侧关联 ID、返回的服务请求 ID、部署名称、模型版本、部署类型和区域。
- 请求负载： 输入长度的本地估计、所用 API 的输出上限参数及其值、业务请求 ID、当前是第几次尝试。
- 失败内容： HTTP 状态码、错误码和错误正文，以及未经应用丢弃的限流响应头。
- 到达节奏： 同一部署在相邻 1 秒、10 秒和 60 秒内的实际发送次数，包含重试。
这些记录不需要保存密钥或完整用户内容。网关可能删除或改写响应头，缺失的字段应记为未知，再向网关日志补查，不能当成“剩余额度为零”。
用响应头决定下一步，而不是只看用量图
Azure OpenAI 文档列出了 x-ratelimit-limit-requests、x-ratelimit-limit-tokens、对应的 remaining 与 reset 字段，以及 429 时的 retry-after-ms。其中 retry-after-ms 的单位是毫秒；对于 reset 字段，应保留原值并按实际接口文档解析，不要直接套用其他服务的单位假设。限流响应头
把连续请求的响应头与配置放在一起，比单个失败样本更容易判断：
| 看到的现象 | 优先核对什么 | 对应动作 |
|---|---|---|
x-ratelimit-remaining-tokens 快速下降，计费用量仍很低 | 输入大小、输出上限、失败尝试数量 | 降低不必要的预留输出，缩短输入，减少重复发送 |
x-ratelimit-remaining-requests 接近耗尽，令牌仍有余量 | 每秒和每 10 秒的请求数 | 在发送入口排队并均匀放行 |
| 订阅还有大量可分配 TPM，但目标部署分配很小 | 实际接收流量的部署名称与分配值 | 把可用配额分配给该部署 |
x-ratelimit-limit-tokens 低于部署配置值 | 是否拿到了真实后端头、近期是否改过配置、错误正文是否提示容量压力 | 排除网关改写和配置传播后，按临时有效限额降低流量并观察 |
| 错误提示服务暂时无法处理或需求过高 | 后端容量状态和持续时间 | 按服务端等待提示退避；持续发生时提交支持请求 |
| APIM 跟踪显示策略直接拒绝 | 对应策略、计数键及周期 | 在网关管理范围内处理策略或业务用量 |
这些是排查方向，不是仅凭一个字段就能完成的归因。例如，x-ratelimit-limit-tokens 低于配置值是临时有效限额调整的信号，但先要确认比较的是同一部署，而且响应头没有被中间服务替换。Standard 部署共享后端容量，容量压力导致的 429 与配置配额耗尽需要分别处理。429 类型与处置
为什么只返回短答案，也能很快耗尽 TPM
TPM 是每分钟令牌数，RPM 是每分钟请求数。Azure 为部署分配 TPM 时，还会按模型对应的容量比例设置 RPM；不存在适用于所有模型的“每 1,000 TPM 对应 6 RPM”规则。拿到一个 TPM 值后，要再确认该模型与部署实际对应的 RPM。配额与容量比例
令牌限流也不是简单累计返回内容。Microsoft 文档说明，到达时的估算考虑输入文本、max_tokens，以及支持相关参数的 API 中的 best_of；其计算部分依赖字符数，与计费使用的精确令牌计算不同。因此，本地分词器适合帮助估算负载，不能精确预测服务端何时拒绝请求。TPM 估算机制
用一个算例找到最值得调整的参数
假设部署分配为 120,000 TPM，每次输入本地估算约 1,000 个令牌，业务只需要约 200 个令牌的短答案，却把支持 max_tokens 的接口设置为 4,000。
为了看清输出预留的影响，先用“输入估计 + 输出上限”建立一个简化预算模型：
| 设置 | 每次请求的简化预算 | 120,000 TPM 对应的算术结果 |
|---|---|---|
| 输出上限 4,000 | 1,000 + 4,000 = 5,000 | 120,000 ÷ 5,000 = 24 次/分钟 |
| 输出上限 500 | 1,000 + 500 = 1,500 | 120,000 ÷ 1,500 = 80 次/分钟 |
这不是 Azure 的精确内部公式，也不是实测吞吐提升。它说明：若预期答案很短，过高的输出上限可能是比实际输出量更值得检查的参数。真正调整时，应根据代表性输出和截断情况留出合理余量；降低到 500 后若答案经常不完整，这个设置就不适合该业务。
在应用自己的简化预算中，还要同时受 RPM 约束。例如，若实际部署 RPM 只有 60，那么第二行即使算出 80 次，计划发送量仍应按最多 60 次/分钟继续设计，并为估算误差、突发和其他调用方留出余量。不要把该示例的 TPM 与 RPM 组合当作某个模型的公开规格。
新模型或不同 API 可能使用其他输出上限参数。先核对你实际调用的接口，不要把 max_tokens 或 best_of 机械复制到所有模型。尤其是推理模型，不能仅根据用户可见答案长度推断所需输出预算。
每分钟只发几十次，也可能在第一秒被限流
RPM 的检查可能使用 1 秒或 10 秒等短窗口，要求请求在一分钟内相对均匀地到达。官方示例中，600 RPM 若按 1 秒窗口检查，对应每秒 10 次；把 60 个请求同时发出，即使这一分钟之后完全空闲，也可能触发限流。短窗口说明
因此，控制并发数只是其中一步。10 个并发槽位如果很快完成请求，仍能在一秒内发出远超 10 次调用。发送端需要同时约束请求到达速率和预计令牌需求；多实例应用还需要共享同一部署的预算，否则每个实例都按完整额度发送，总量会相加。离线任务可进入队列，交互任务则需要明确排队期限，避免把 429 换成无限等待。
调高 TPM 前，先核对部署分配和 Scope
订阅获批的配额决定可分配总量，部署分配决定接收请求的部署能使用多少。假设某个配额池共有 300,000 TPM，但生产部署只分到 30,000 TPM，应用不能因为池中还有空闲就自动使用剩余部分。此时应先检查分配，未必需要申请提高总额度。
另一个会影响扩容判断的变化是共享范围。Microsoft 从 2026 年 5 月 7 日之后开始逐步引入订阅级配额管理。对于已接入新管理方式的模型，同一订阅内，同模型、同版本的 Global Standard 部署跨区域共享一个池；Data Zone Standard 在同一数据区域内共享。是否适用，要看 Foundry 的 Scope 列，不能假定所有模型都已迁移。如何确认配额范围
- Global： 按该订阅的全局共享范围核对相关部署；新建另一区域部署不会自然多出一份独立额度。
- Data Zone： 核对该数据区域内的相关部署；区域名称不同不等于配额池不同。
- 具体区域名： 该订阅、模型仍按界面所示区域管理，再依据此范围检查可用配额。
多部署可以重新分配流量，但能否增加总处理空间，取决于配额范围、部署分配与实际可用容量。不要把“换一个区域”当成必然翻倍的扩容方法。
在当前 Foundry 界面中调整
在新版 Microsoft Foundry 中打开 New Foundry，进入 Manage → Quota → Token per minute，找到实际接收请求的部署并打开详情。检查 Affiliated deployments using shared quota 中共享配额的部署，再通过相应行的铅笔按钮调整分配；需要增加总额度时使用 Request quota。官方操作步骤
分配更新后按文档预留最多 15 分钟的传播时间，刷新页面核对，再对照实际响应头验证。这是配置传播指导，不是提额申请会在 15 分钟内获批的承诺。查看订阅配额所需的最小只读角色可使用订阅级 Cognitive Services Usages Reader；能查看并不表示有权修改部署。
如果用管理 API 做检查，也要分清返回数据的含义：Usages API 的 currentValue 表示部署已经占用的配额分配，不是这一分钟实际消耗的推理令牌。 保留返回的模型、部署类型和单位再比较 currentValue 与 limit；检查某模型能在哪里创建或扩展部署，则使用 Model Capacities API。两类管理 API 的区别
给重试设置等待时间和总期限
偶发 429 可以恢复，但持续立即重发会增加请求压力。Microsoft 明确提醒失败请求也可能计入速率限制，并建议遵守 retry-after-ms，没有有效服务端提示时采用带随机抖动的指数退避。重试建议
实现时把以下行为写清楚：
- 先判断是否值得重试。 对临时限流处理 429；参数错误、身份验证失败或明确的策略周期配额问题应交给对应处理流程。
- 读取服务端等待提示。
retry-after-ms: 2000表示等待 2 秒；如果调用链使用Retry-After，按该接口的格式处理，不能沿用毫秒单位。有效等待时间超过业务剩余期限时，结束当前等待或转入允许的异步处理，不缩短提示后继续冲击服务。 - 只保留一个重试负责方。 使用 SDK 内置重试时，不再叠加未经协调的外层循环；由业务层统一重试时，关闭 SDK 自动重试，并记录每一次实际发送。
- 限制尝试次数和总耗时。 无服务端提示时使用有上限、带抖动的退避；停止条件同时覆盖总次数、截止时间和用户取消。
一个容易漏掉的算术关系：外层最多尝试 3 次，SDK 每次允许额外重试 2 次，最坏情况就是 3 × (1 + 2) = 9 次实际请求。指标如果只记录外层的 3 次，就会低估部署收到的压力。具体业务还需要切换备用模型时，可以继续阅读重试与备用模型切换的选择方法。
怎样证明修复有效，什么时候需要支持介入
完成调整后，不要只以“下一次调用成功”结案。用有代表性的同一组输入，在可接受的测试范围内逐步恢复流量，并按相同时间窗口比较以下结果：
| 验证目标 | 应记录的结果 | 能说明什么 |
|---|---|---|
| 修改已作用于正确部署 | 部署配置、模型版本、响应头中的有效上限 | 排除改错部署或配置尚未传播 |
| 限流压力下降 | 首次尝试的 429 比例、包含重试的总发送数、每秒与每 10 秒峰值 | 区分真正改善与重试掩盖失败 |
| 业务完成情况改善 | 成功任务数、最终失败数、排队时间和端到端延迟 | 避免用更长等待换取表面成功率 |
| 输出仍满足任务 | 被截断的回答、缺失字段、代表性长答案 | 防止输出上限调得过低 |
如果部署分配正确、发送已经平滑，仍持续出现低于配置的有效限额或后端容量类 429，应整理时间范围、部署与模型信息、请求 ID、错误正文、响应头和调整前后的流量记录，提交 Azure 支持请求。不要仅附一张按分钟汇总的令牌用量截图。何时升级支持
对持续高负载、需要更可预测吞吐的业务，可以评估预配吞吐量 PTU。它预留模型处理容量，但配额获批不代表目标模型容量一定可部署，已部署容量耗尽仍可能返回 429。选型应按模型、输入输出比例和工作负载估算，没有通用的 PTU 到 TPM 固定换算。预配吞吐量说明
两个容易混淆的边界
提高 TPM 能让单次请求放入更多文本吗？ 不能。TPM 控制一段时间内的处理速率，模型的单次输入或上下文上限是另一项限制；超出上下文需要缩短、分段或换用适合的模型。模型限制与 TPM 的关系
能直接照搬 OpenAI 官网 API 的提额办法吗？ 应先区分接入方式。本文的部署分配、Foundry 配额范围和 Azure 管理角色针对 Azure OpenAI；使用 OpenAI 官方 API 的应用，可查看OpenAI API 限流指南，不要把两边的配额管理方式混用。
