你当前正在访问 Microsoft Azure Global Edition 技术文档网站。 如果需要访问由世纪互联运营的 Microsoft Azure 中国技术文档网站,请访问 https://docs.azure.cn。
本文提供了直接由 Azure 销售的 Foundry 模型配额和限制的快速参考与详细说明。 有关 Foundry 模型中 Azure OpenAI 的特定配额和限制,请参阅 Azure OpenAI 中的配额和限制。
2026/05/07 之后配额管理的更新
Microsoft Foundry 引入了配额管理的更新,以保持一致性和可预测性,以便跨部署管理配额。 从 Realtime Translate 和 Realtime Whisper 开始,部署配额在订阅级别(在所有资源和区域之间共享)进行跟踪,而不是按资源或每个区域单独分配。
此更改将配额合并到共享池中:
- 全球标准:在同一订阅服务中,同一模型和版本的部署在所有区域共享一个配额池。
- 数据区域标准:同一模型和版本的部署每个数据区域共享一个配额池(例如美国或欧盟)。
对我来说有什么变化?
对于接入新配额管理系统的模型:
- 现在,在订阅下,相同型号和版本的所有全球标准部署都从所有区域的单个共享配额池中分配配额。
- 订阅下同一模型和版本的所有数据区域标准部署现在都来自每个数据区域中的共享配额池。
- 现有已批准的配额会保留,并在订阅级别自动应用 -- 无需执行任何操作。
这种整合允许Microsoft Foundry 在所有 Foundry 区域中一致地提供受支持的模型,无论配额如何分布于资源或区域。
重要
更新后的配额管理目前仅适用于实时翻译和实时耳语。 对于本文中涵盖的所有其他 Foundry 模型,配额和限制按区域、每个订阅和每个模型或部署类型进行管理。 将来,这些配额准则也将适用于某些现有模型以及新推出的 Foundry 模型。
配额和限制参考
以下部分提供了适用于 Foundry 模型的默认配额和限制的快速指南。 不会在租户级别强制执行配额和限制。 而是将配额限制的最高级别限定在Azure订阅级别。 每分钟的令牌数(TPM)和每分钟请求数限制(RPM)是根据每个区域、每个订阅以及每个模型或部署类型规定的。
资源限制(每个Azure订阅,每个区域)
| 限制名称 | 限制值 |
|---|---|
| 每个 Azure 订阅中每个区域的 Foundry 资源 | 100 |
| 每个资源的最大项目数 | 250 |
| 每个资源的最大部署次数(Foundry 资源中的模型部署) | 32 |
速率限制
下表列出了 Foundry 模型针对以下速率的限制:
- 每分钟令牌数
- 每分钟请求数
- 并发请求
| 模型 | 每分钟令牌数 | 每分钟请求数 | 并发请求 |
|---|---|---|---|
| Azure OpenAI 模型 | 根据模型和 SKU 而异。 请参阅 limits for Azure OpenAI。 | 根据模型和 SKU 而异。 请参阅 limits for Azure OpenAI。 | 不同。 请参阅 Azure OpenAI 限制。 |
| - DeepSeek-R1 - DeepSeek-V3-0324 |
5,000,000 | 5,000 | 300 |
| - Llama 3.3 70B 指令 - Llama-4-Maverick-17B-128E-Instruct-FP8 - Grok 3 - Grok 3 迷你 |
400,000 | 1,000 | 300 |
| - Flux.2-Pro | 不适用 | - 低(默认值):15 - 中等:30 - 高(企业):100 |
不适用 |
| - Flux-Pro 1.1 - Flux.1-Kontext Pro |
不适用 | 2 个容量单位(每分钟 6 个请求) | 不适用 |
| 其余模型 | 400,000 | 1,000 | 300 |
增加配额:
- 对于 Azure OpenAI,请使用 Foundry 服务:请求增加配额提交请求。
- 对于其他模型,请参阅 请求增加到默认限制。
由于需求较高,将单独评估限制增加请求。
其他限制
| 限制名称 | 限制值 |
|---|---|
| API 请求的最大自定义标头数1 | 10 |
1 个当前 API 最多允许 10 个自定义标头,管道会传递并返回这些标头。 如果超过此标头计数,则请求会导致 HTTP 431 错误。 若要解决此错误,请减少标头大小。 未来的 API 版本不会通过自定义标头。 不要依赖于将来的系统体系结构中的自定义标头。
使用级别
全局标准部署使用Azure的全局基础结构来动态将客户流量路由到数据中心,并为客户提供推理请求的最佳可用性。 此基础设施为流量低至中等级别的客户提供更为一致的延迟。 使用水平较高的客户可能会在响应延迟中看到更多变化。
使用限制确定的是一个使用量的阈值,超过此阈值后,客户可能会在响应延迟中看到更大的可变性。 客户使用情况按模型定义,是给定租户在所有区域的所有订阅中的所有部署中消耗的总词元。
提请求提高默认限制
提交 配额增加请求表单申请由 Azure 直接销售的 Foundry 模型、Azure OpenAI 模型和 Anthropic 模型的配额增加。 除了Anthropic模型,来自合作伙伴和社区的模型都不支持增加配额。
配额增加请求按照收到的顺序进行处理,优先考虑那些积极使用现有配额分配的客户。 不符合此条件的请求可能会被拒绝。
保持在速率限制范围内的一般最佳做法
若要最大程度地减少与速率限制相关的问题,请使用以下技术:
- 在应用程序中实现重试逻辑。
- 避免工作负荷发生急剧更改。 逐渐增加工作负荷。
- 测试不同的负载增加模式。
- 增加指定给您部署的配额。 如有必要,请从另一个部署移动配额。
设置客户端超时
根据以下指南明确设置客户端超时。
注意
如果没有明确设置,客户端超时将根据所使用的库而存在,并且可能与上述限制不同。
- 推理模型(在生成汇总响应之前生成中间推理令牌的模型):最多 29 分钟。
- 非推理模型:
- 流媒体最多 60 秒。
- 对于非流式处理请求,最多 29 分钟。
此处的 29 分钟并不意味着所有请求需要 29 分钟,而是根据上下文令牌、生成的令牌和缓存命中率,请求最多可能需要 29 分钟。
设置超时时间小于这些值,并根据您的流量模式进行调整。
对于包括流式处理请求在内的推理模型,首先生成所有推理令牌,然后在将第一个响应令牌发送回用户之前进行汇总。
可以修改 推理工作 参数来控制进程中生成的推理令牌数。
故障 排除
| 症状 | 原因 | 分辨率 |
|---|---|---|
| HTTP 429 请求过多 | 每分钟令牌数或请求数限制已被超出 | 使用指数退避实现重试逻辑。 使用 Retry-After 标头值。 |
| HTTP 431 请求标头字段太大 | 发送的自定义标头超过 10 个 | 将自定义标头减少到 10 或更少。 |
| “配额”页面显示可用数量为 0 | 订阅或区域配额已完全分配 | 从其他部署转移未使用的配额。 若要增加限制, 请请求增加配额。 |
| 该地区不提供此模型 | 所选区域中模型未部署或不受支持 | 检查 模型可用性 并选择可用区域。 |