# Azure OpenAI TPM 限流排查：用量没满，为什么仍报 429？

> Azure OpenAI 的 TPM 限流按请求到达时的估算量判断，监控中的实际令牌用量不能直接证明还有额度。排查时先确认 429 来自哪里，再对照部署分配、响应头和短时间内的请求量；增加配额、跨区域部署与重试分别只解决其中一部分问题。

- URL: https://blog.laozhang.ai/zh/posts/azure-openai-tpm-rate-limit
- Published: 2026-09-05
- Updated: 2026-09-05
- Author: LaoZhang AI Team (https://blog.laozhang.ai/zh/about)
- Topic: API 接入指南
- Tags: Azure OpenAI, TPM, 429, 限流, 配额管理

---
Azure OpenAI 报出 `429 Too Many Requests` 时，先不要根据 Azure Monitor 的令牌用量判断“配额还没用完”。**限流判断发生在请求到达时，使用的是预计处理量；监控中的令牌用量反映成功处理后计费的消耗。** 输出上限过大、请求集中到达，甚至部分随后被拒绝的请求，都可能让这两个数相差很大。[Microsoft 的解释](https://learn.microsoft.com/en-us/azure/foundry/openai/how-to/quota#why-you-might-see-429s-even-when-token-usage-metrics-are-below-quota)

最有效的起点是保留一次失败请求及其前后成功请求的状态码、错误正文、响应头、时间和部署名称，再确认它们经过了哪些服务。这样才能判断该降低请求速率、调整输出上限、重新分配 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 策略说明](https://learn.microsoft.com/en-us/azure/api-management/llm-token-limit-policy)

排查记录至少应能把以下信息连在一起：

- **请求身份：** 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` 字段，应保留原值并按实际接口文档解析，不要直接套用其他服务的单位假设。[限流响应头](https://learn.microsoft.com/en-us/azure/foundry/openai/how-to/quota#rate-limit-response-headers)

把连续请求的响应头与配置放在一起，比单个失败样本更容易判断：

| 看到的现象 | 优先核对什么 | 对应动作 |
| --- | --- | --- |
| `x-ratelimit-remaining-tokens` 快速下降，计费用量仍很低 | 输入大小、输出上限、失败尝试数量 | 降低不必要的预留输出，缩短输入，减少重复发送 |
| `x-ratelimit-remaining-requests` 接近耗尽，令牌仍有余量 | 每秒和每 10 秒的请求数 | 在发送入口排队并均匀放行 |
| 订阅还有大量可分配 TPM，但目标部署分配很小 | 实际接收流量的部署名称与分配值 | 把可用配额分配给该部署 |
| `x-ratelimit-limit-tokens` 低于部署配置值 | 是否拿到了真实后端头、近期是否改过配置、错误正文是否提示容量压力 | 排除网关改写和配置传播后，按临时有效限额降低流量并观察 |
| 错误提示服务暂时无法处理或需求过高 | 后端容量状态和持续时间 | 按服务端等待提示退避；持续发生时提交支持请求 |
| APIM 跟踪显示策略直接拒绝 | 对应策略、计数键及周期 | 在网关管理范围内处理策略或业务用量 |

这些是排查方向，不是仅凭一个字段就能完成的归因。例如，`x-ratelimit-limit-tokens` 低于配置值是临时有效限额调整的信号，但先要确认比较的是同一部署，而且响应头没有被中间服务替换。Standard 部署共享后端容量，容量压力导致的 429 与配置配额耗尽需要分别处理。[429 类型与处置](https://learn.microsoft.com/en-us/azure/foundry/openai/how-to/quota#understanding-429-throttling-errors-and-what-to-do)

## 为什么只返回短答案，也能很快耗尽 TPM

TPM 是每分钟令牌数，RPM 是每分钟请求数。Azure 为部署分配 TPM 时，还会按模型对应的容量比例设置 RPM；**不存在适用于所有模型的“每 1,000 TPM 对应 6 RPM”规则**。拿到一个 TPM 值后，要再确认该模型与部署实际对应的 RPM。[配额与容量比例](https://learn.microsoft.com/en-us/azure/foundry/openai/how-to/quota#introduction-to-quota)

令牌限流也不是简单累计返回内容。Microsoft 文档说明，到达时的估算考虑输入文本、`max_tokens`，以及支持相关参数的 API 中的 `best_of`；其计算部分依赖字符数，与计费使用的精确令牌计算不同。因此，本地分词器适合帮助估算负载，不能精确预测服务端何时拒绝请求。[TPM 估算机制](https://learn.microsoft.com/en-us/azure/foundry/openai/how-to/quota#understanding-rate-limits)

### 用一个算例找到最值得调整的参数

假设部署分配为 **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 次/分钟 |

![输入估计为 1,000 个令牌时，输出上限 4,000 与 500 对应的简化预算分别为 5,000 与 1,500，算术吞吐仍受 RPM 约束](https://blog.laozhang.ai/posts/zh/azure-openai-tpm-rate-limit/img/output-budget.webp)

这不是 Azure 的精确内部公式，也不是实测吞吐提升。它说明：若预期答案很短，过高的输出上限可能是比实际输出量更值得检查的参数。真正调整时，应根据代表性输出和截断情况留出合理余量；降低到 500 后若答案经常不完整，这个设置就不适合该业务。

在应用自己的简化预算中，还要同时受 RPM 约束。例如，若实际部署 RPM 只有 60，那么第二行即使算出 80 次，计划发送量仍应按最多 60 次/分钟继续设计，并为估算误差、突发和其他调用方留出余量。不要把该示例的 TPM 与 RPM 组合当作某个模型的公开规格。

新模型或不同 API 可能使用其他输出上限参数。先核对你实际调用的接口，不要把 `max_tokens` 或 `best_of` 机械复制到所有模型。尤其是推理模型，不能仅根据用户可见答案长度推断所需输出预算。

### 每分钟只发几十次，也可能在第一秒被限流

RPM 的检查可能使用 1 秒或 10 秒等短窗口，要求请求在一分钟内相对均匀地到达。官方示例中，600 RPM 若按 1 秒窗口检查，对应每秒 10 次；把 60 个请求同时发出，即使这一分钟之后完全空闲，也可能触发限流。[短窗口说明](https://learn.microsoft.com/en-us/azure/foundry/openai/how-to/quota#understanding-rate-limits)

因此，控制并发数只是其中一步。10 个并发槽位如果很快完成请求，仍能在一秒内发出远超 10 次调用。发送端需要同时约束请求到达速率和预计令牌需求；多实例应用还需要共享同一部署的预算，否则每个实例都按完整额度发送，总量会相加。离线任务可进入队列，交互任务则需要明确排队期限，避免把 429 换成无限等待。

## 调高 TPM 前，先核对部署分配和 Scope

订阅获批的配额决定可分配总量，部署分配决定接收请求的部署能使用多少。假设某个配额池共有 300,000 TPM，但生产部署只分到 30,000 TPM，应用不能因为池中还有空闲就自动使用剩余部分。此时应先检查分配，未必需要申请提高总额度。

另一个会影响扩容判断的变化是共享范围。Microsoft 从 **2026 年 5 月 7 日之后**开始逐步引入订阅级配额管理。对于已接入新管理方式的模型，同一订阅内，同模型、同版本的 Global Standard 部署跨区域共享一个池；Data Zone Standard 在同一数据区域内共享。是否适用，要看 Foundry 的 **Scope** 列，不能假定所有模型都已迁移。[如何确认配额范围](https://learn.microsoft.com/en-us/azure/foundry/foundry-models/quotas-limits#check-quota-management-scope)

- **Global：** 按该订阅的全局共享范围核对相关部署；新建另一区域部署不会自然多出一份独立额度。
- **Data Zone：** 核对该数据区域内的相关部署；区域名称不同不等于配额池不同。
- **具体区域名：** 该订阅、模型仍按界面所示区域管理，再依据此范围检查可用配额。

![Foundry 的 Scope 显示 Global、Data Zone 或具体区域名时，分别应如何判断部署之间的配额共享范围](https://blog.laozhang.ai/posts/zh/azure-openai-tpm-rate-limit/img/quota-scope.webp)

多部署可以重新分配流量，但能否增加总处理空间，取决于配额范围、部署分配与实际可用容量。不要把“换一个区域”当成必然翻倍的扩容方法。

### 在当前 Foundry 界面中调整

在新版 Microsoft Foundry 中打开 **New Foundry**，进入 **Manage → Quota → Token per minute**，找到实际接收请求的部署并打开详情。检查 **Affiliated deployments using shared quota** 中共享配额的部署，再通过相应行的铅笔按钮调整分配；需要增加总额度时使用 **Request quota**。[官方操作步骤](https://learn.microsoft.com/en-us/azure/foundry/openai/how-to/quota#view-and-request-quotas-in-foundry-portal)

分配更新后按文档预留最多 15 分钟的传播时间，刷新页面核对，再对照实际响应头验证。这是配置传播指导，不是提额申请会在 15 分钟内获批的承诺。查看订阅配额所需的最小只读角色可使用订阅级 **Cognitive Services Usages Reader**；能查看并不表示有权修改部署。

如果用管理 API 做检查，也要分清返回数据的含义：**Usages API 的 `currentValue` 表示部署已经占用的配额分配，不是这一分钟实际消耗的推理令牌。** 保留返回的模型、部署类型和单位再比较 `currentValue` 与 `limit`；检查某模型能在哪里创建或扩展部署，则使用 Model Capacities API。[两类管理 API 的区别](https://learn.microsoft.com/en-us/azure/foundry/openai/how-to/quota#programmatically-check-quota-and-capacity)

## 给重试设置等待时间和总期限

偶发 429 可以恢复，但持续立即重发会增加请求压力。Microsoft 明确提醒失败请求也可能计入速率限制，并建议遵守 `retry-after-ms`，没有有效服务端提示时采用带随机抖动的指数退避。[重试建议](https://learn.microsoft.com/en-us/azure/foundry/openai/how-to/quota#implement-retry-logic-with-exponential-backoff)

实现时把以下行为写清楚：

1. **先判断是否值得重试。** 对临时限流处理 429；参数错误、身份验证失败或明确的策略周期配额问题应交给对应处理流程。
2. **读取服务端等待提示。** `retry-after-ms: 2000` 表示等待 2 秒；如果调用链使用 `Retry-After`，按该接口的格式处理，不能沿用毫秒单位。有效等待时间超过业务剩余期限时，结束当前等待或转入允许的异步处理，不缩短提示后继续冲击服务。
3. **只保留一个重试负责方。** 使用 SDK 内置重试时，不再叠加未经协调的外层循环；由业务层统一重试时，关闭 SDK 自动重试，并记录每一次实际发送。
4. **限制尝试次数和总耗时。** 无服务端提示时使用有上限、带抖动的退避；停止条件同时覆盖总次数、截止时间和用户取消。

一个容易漏掉的算术关系：外层最多尝试 3 次，SDK 每次允许额外重试 2 次，最坏情况就是 **3 × (1 + 2) = 9 次实际请求**。指标如果只记录外层的 3 次，就会低估部署收到的压力。具体业务还需要切换备用模型时，可以继续阅读[重试与备用模型切换的选择方法](https://blog.laozhang.ai/zh/posts/llm-api-retry-vs-fallback-model)。

## 怎样证明修复有效，什么时候需要支持介入

完成调整后，不要只以“下一次调用成功”结案。用有代表性的同一组输入，在可接受的测试范围内逐步恢复流量，并按相同时间窗口比较以下结果：

| 验证目标 | 应记录的结果 | 能说明什么 |
| --- | --- | --- |
| 修改已作用于正确部署 | 部署配置、模型版本、响应头中的有效上限 | 排除改错部署或配置尚未传播 |
| 限流压力下降 | 首次尝试的 429 比例、包含重试的总发送数、每秒与每 10 秒峰值 | 区分真正改善与重试掩盖失败 |
| 业务完成情况改善 | 成功任务数、最终失败数、排队时间和端到端延迟 | 避免用更长等待换取表面成功率 |
| 输出仍满足任务 | 被截断的回答、缺失字段、代表性长答案 | 防止输出上限调得过低 |

如果部署分配正确、发送已经平滑，仍持续出现低于配置的有效限额或后端容量类 429，应整理时间范围、部署与模型信息、请求 ID、错误正文、响应头和调整前后的流量记录，提交 Azure 支持请求。不要仅附一张按分钟汇总的令牌用量截图。[何时升级支持](https://learn.microsoft.com/en-us/azure/foundry/openai/how-to/quota#when-to-retry-vs-when-to-escalate)

对持续高负载、需要更可预测吞吐的业务，可以评估预配吞吐量 PTU。它预留模型处理容量，但配额获批不代表目标模型容量一定可部署，已部署容量耗尽仍可能返回 429。选型应按模型、输入输出比例和工作负载估算，没有通用的 PTU 到 TPM 固定换算。[预配吞吐量说明](https://learn.microsoft.com/en-us/azure/foundry/openai/concepts/provisioned-throughput)

## 两个容易混淆的边界

**提高 TPM 能让单次请求放入更多文本吗？** 不能。TPM 控制一段时间内的处理速率，模型的单次输入或上下文上限是另一项限制；超出上下文需要缩短、分段或换用适合的模型。[模型限制与 TPM 的关系](https://learn.microsoft.com/en-us/azure/foundry/openai/how-to/quota#model-specific-settings)

**能直接照搬 OpenAI 官网 API 的提额办法吗？** 应先区分接入方式。本文的部署分配、Foundry 配额范围和 Azure 管理角色针对 Azure OpenAI；使用 OpenAI 官方 API 的应用，可查看[OpenAI API 限流指南](https://blog.laozhang.ai/zh/posts/openai-api-rate-limit)，不要把两边的配额管理方式混用。

## 参考来源

本文引用的外部页面，按正文出现顺序排列。最后更新于 2026-09-05。

- [Microsoft 的解释](https://learn.microsoft.com/en-us/azure/foundry/openai/how-to/quota) (learn.microsoft.com)
- [APIM 策略说明](https://learn.microsoft.com/en-us/azure/api-management/llm-token-limit-policy) (learn.microsoft.com)
- [如何确认配额范围](https://learn.microsoft.com/en-us/azure/foundry/foundry-models/quotas-limits) (learn.microsoft.com)
- [预配吞吐量说明](https://learn.microsoft.com/en-us/azure/foundry/openai/concepts/provisioned-throughput) (learn.microsoft.com)