Microsoft Foundry 的 Quota Tiers

有一次收到 Azure 的通知邮件，大体内容如下：

Important update: Eligibility for Quota Tier upgrade

We are pleased to inform you that, based on your recent usage and account standing, your subscription is now eligible for an upgrade from your current Tier (Free Tier) to the next Tier (Tier 1) within our AI Services platform.

我就去翻了翻 Microsoft Foundry 关于配额等级（Quota tiers）的文档，把这次邮件里真正发生的变化记下来，也顺便把几组常用模型的数字放在一起。

本文整理自 Microsoft Learn 的 Quotas and limits 文档。该页面显示的更新时间是 2026 年 7 月 29 日；配额表还会调整，部署前最好再看一眼 Foundry 门户里的实时值。

这封邮件到底在说什么

我一开始把邮件里的 Tier upgrade 理解成“Azure 给订阅加了一笔额度”。查完文档后，意思更准确：当前订阅在 Microsoft Foundry Models 中的默认 Quota tier 从 Free Tier（文档配额表中标为 Tier 0）变成了 Tier 1。 它影响模型部署能承受的吞吐上限，最直接的两个指标是：

• RPM（Requests Per Minute）：每分钟请求数。
• TPM（Tokens Per Minute）：每分钟 token 数。

模型价格仍按原来的计费规则走。Tier 变高只会改变符合条件的订阅可以承载的请求和 token 吞吐，不会自动产生免费 token。

Quota tiers 是什么

Microsoft 现在为 Foundry Models 提供七个配额等级：

读这张表时有一个容易踩的坑：等级是订阅层面的，但具体数值还要看 模型、模型版本和部署类型。Tier 1 并不是 Tier 0 的统一倍数，有些模型甚至只从 Tier 1 开始出现在配额表中。

为什么会自动升级

文档没有公布“消费达到某个数字就升级”的固定公式。它提到的参考因素包括一段时间内对 Foundry Models 的消费趋势、当前 tier 是否已经卡住了工作负载、与 Microsoft 的商业关系（例如 EA 或 MCA-E），以及付款记录和订阅状态。

这也解释了为什么不同订阅收到通知的时间可能不同。邮件里的 account standing，指的就是这类综合判断。

此前批准的额外配额不会因为引入 Quota tiers 而被收回。需要更多配额时，仍然可以通过 quota request form 申请；申请获批后，当前 tier 可以保持不变，只增加分配给订阅的配额。

配额到底作用在哪一层

文档明确说明，配额和限制不会在 tenant 层统一执行，最高级别的配额范围是 Azure subscription。所以，即使创建了多个 Foundry 或 Azure OpenAI resource，也不能假定每个 resource 都有一份完全独立的额度。

从 2026 年 5 月 7 日之后，Microsoft Foundry 开始引入订阅级配额管理。文档说明，这一机制从 Realtime Translate 和 Realtime Whisper 开始，并逐步扩展到更多模型。对于已经采用该机制的模型，配额池大致可以这样理解：

所以，把 Global Standard 的部署从 Region A 扩到 Region B，不等于拿到了两份额度；Data Zone Standard 还要按数据区分别计算。做容量规划时，我会先把同一订阅下同一模型版本的部署放在一起看。

用一张图表示：

st=>start: 请求进入 Microsoft Foundry
model=>operation: 匹配模型、版本和部署类型
global=>operation: Global Standard：订阅内共享同一模型版本的配额池
zone=>operation: Data Zone Standard：按数据区共享同一模型版本的配额池
standard=>operation: Standard：使用该部署类型对应的配额记录
limit=>end: RPM / TPM 限制生效

st->model->global
model->zone
model->standard
global->limit
zone->limit
standard->limit

Tier 0 和 Tier 1 的常用模型对比

先看文档 Tier 0 和 Tier 1 都列出的四个常用模型。为了让数字可以直接比较，表格只取 Global Standard，格式统一为 RPM / TPM。

这里最直观的是两件事：

• Tier 的提升并不意味着所有模型按同一比例增加。gpt-4.1-mini 的 TPM 从 200,000 增加到 5,000,000，而 text-embedding-3-small 在这两档的 TPM 相同。
• RPM 和 TPM 要同时看。比如 embedding 模型的 RPM 写成 1,000 / 10s，表示文档采用 10 秒窗口展示限制，不能在不看时间窗口的情况下与普通的每分钟 RPM 直接横向比较。

七个等级放在一张表里

如果只看 Tier 0 和 Tier 1，很容易低估后面几档的差距。下面把文档中的几个常用模型放在同一张表里，统一取 Global Standard，单元格格式为 RPM / TPM。这里的数字是官方配额表的上限，不是吞吐保证。

下面把每个模型的 TPM 在不同 tier 中的变化画成点线图。纵轴采用对数刻度，单位是百万 token/min，这样既能看清 Tier 0 的小配额，也能看清 Tier 6 的大配额；没有 Tier 0 数据的模型从 Tier 1 开始绘制。

图表只比较 TPM，因此没有 TPM 配额的图像模型（例如 gpt-image-1 和 gpt-image-1.5）不在点线图中；它们的 RPM 已在后面的图像模型表列出。数值完全重合的模型会在图例中合并标注，但模型本身没有省略。

表格里的 - 表示该模型没有出现在 Tier 0 的这张配额表中，不等同于该模型在所有场景都不可用。

Tier 1 的几组参考值

下面只摘出文本生成、推理、嵌入和图像模型的几行。数值仍然是 RPM / TPM；- 表示该行没有列出 TPM，不代表可以无限请求。

文本和推理模型

Tier 1 里，gpt-5 的 Global Standard 是 10,000 RPM 和 1,000,000 TPM，Data Zone Standard 则是 3,000 RPM 和 300,000 TPM。部署类型会直接改变可用配额，所以选模型时不能只看模型名称，还要把数据驻留和延迟要求一起放进来。

Embedding 和图像模型

图像模型主要按请求数限制，和文本模型的 TPM 不是一类数字。实际部署还要查看目标区域是否有容量、版本是否仍在支持期，以及是否有单独的服务限制。

不要把 Quota tier 和 Usage tier 混为一谈

文档还列出了 Usage tiers。它和本文讨论的 Quota tiers 说的是两件事：

所以，提升 Quota tier 不会自动带来固定延迟。文档提醒，高需求、持续高流量或突发流量下，超过 Usage tier 后延迟可能明显增加；即使监控里的 token 指标低于某个配额，也可能收到 429 Too Many Requests。

如何查看当前订阅的 tier

查看订阅 tier，可以调用 Microsoft Learn 给出的 control plane API。下面使用的 API 版本是 2025-10-01-preview，管理平面 token 由 Azure CLI 获取：

 1
 2
 3
 4
 5
 6
 7
 8
 9
10

SUBSCRIPTION_ID="<your-subscription-id>"
TOKEN=$(az account get-access-token \
	--resource https://management.azure.com \
	--query accessToken -o tsv)

curl -X GET \
	"https://management.azure.com/subscriptions/${SUBSCRIPTION_ID}\
/providers/Microsoft.CognitiveServices/quotaTiers?api-version=2025-10-01-preview" \
	-H "Authorization: Bearer ${TOKEN}" \
	-H "Content-Type: application/json"

返回结果中的 currentTierName 是当前等级，assignmentDate 是分配时间，tierUpgradePolicy 则表示自动升级策略。示例结果可能类似：

1
2
3
4
5
6
7

{
	"properties": {
		"currentTierName": "Tier 1",
		"assignmentDate": "2025-10-18T05:09:05.6334222Z",
		"tierUpgradePolicy": "OnceUpgradeIsAvailable"
	}
}

是否可以关闭自动升级

可以。文档提供了 NoAutoUpgrade 策略，用于让订阅保持在当前 tier。这个选项目前仍是预览功能，可能发生变化或被移除：

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14

TOKEN=$(az account get-access-token \
	--resource https://management.azure.com \
	--query accessToken -o tsv)

curl -X PATCH \
	"https://management.azure.com/subscriptions/${SUBSCRIPTION_ID}\
/providers/Microsoft.CognitiveServices/quotaTiers/default?api-version=2025-10-01-preview" \
	-H "Authorization: Bearer ${TOKEN}" \
	-H "Content-Type: application/json" \
	-d '{
		"properties": {
			"tierUpgradePolicy": "NoAutoUpgrade"
		}
	}'

关闭自动升级适合需要严格控制配额边界的场景，但 Quota tier 不适合拿来管账单。费用交给 Azure Cost Management；如果业务需要稳定的高吞吐和延迟，再评估 PTU。

实际使用时的建议

1. 按模型和部署类型监控，不要只盯着订阅总量。Global Standard、Data Zone Standard 和 Standard 最好分开看。
2. 给突发流量留缓冲。客户端实现指数退避和重试，429 后不要立刻把请求全部打回来。
3. 逐步增加负载，观察 RPM、TPM、延迟和 429，再决定是否继续扩容。
4. 如果某个部署长期闲置，可以把配额移给真正承载流量的部署。
5. 现有配额已经被持续使用时，再通过 quota request form 申请额外配额更合适。
6. 对高流量、低延迟业务评估 PTU。Quota tier 管的是上限，不能替代专用吞吐。

回到开头那封邮件，我会把它理解成“订阅的默认吞吐档位变高了”。真正上线前，还要确认当前 tier、模型和版本、部署类型、数据区或区域、RPM/TPM 的时间窗口，以及目标区域的实时容量。邮件本身不会替我们完成这部分容量规划。

参考资料

• Azure OpenAI in Microsoft Foundry Models quotas and limits：Tier 0
• Azure OpenAI in Microsoft Foundry Models quotas and limits：Tier 1 与 subscription-level quota management