你当前正在访问 Microsoft Azure Global Edition 技术文档网站。 如果需要访问由世纪互联运营的 Microsoft Azure 中国技术文档网站，请访问 https://docs.azure.cn。

在 Microsoft Foundry 模型配额中管理 Azure OpenAI （经典）

当前查看：Foundry（经典）门户版本 - 切换到 Foundry 门户新版本

注意

本文中的链接可能会打开新 Microsoft Foundry 文档中的内容，而不是你现在正在查看的 Foundry （经典）文档。

配额使你可以灵活、主动地管理订阅中不同部署之间速率限制的分配。 本文逐步讲解如何管理 Azure OpenAI 配额。

先决条件

重要

对于需要查看可用配额的任何任务，我们建议使用 认知服务使用情况读取者 角色。 此角色提供查看Azure订阅中的配额使用情况所需的最小访问权限。 若要详细了解此角色以及 Azure访问 OpenAI 所需的其他角色，请参阅我们的 Azure 基于角色的访问控制指南。

可在 Azure 门户的 订阅>访问控制 (IAM)>添加角色分配> 中找到此角色，搜索 Cognitive Services Usages Reader。 此角色 必须在订阅级别应用，资源级别不存在该角色。

如果不想使用此角色，订阅读者角色可提供等效的访问权限，但授予的读取访问权限也会超出查看配额和模型部署所需的范围。

配额简介

Azure OpenAI 的配额功能允许为部署分配速率上限，最多可达到全局上限，即所谓的“配额”。 配额是按区域、模型、部署类型以每分钟令牌 (TPM) 为单位分配给订阅。 将订阅加入到 Azure OpenAI 时，会收到大多数可用模型的默认配额。 然后，你在创建每个部署时将 TPM 分配给它们，并且该模型的可用配额随之减少该数量。 你可以继续创建部署并为其分配 TPM，直到达到配额上限。 一旦发生这种情况，您只能通过减少分配给同一模型的其他部署的 TPM（从而释放出可用的 TPM），或者在所需地区请求并获得批准以增加模型配额，来创建该模型的新部署。

注意

对于美国东地区的 GPT-4o，配额为240,000 TPM，客户可以创建一个240,000 TPM的单个部署，或两个120,000 TPM的部署，或者在一个或多个 Azure OpenAI 资源中进行任意数量的部署，只要其在该区域内的 TPM 总数不超过240,000即可。

创建部署时，分配的 TPM 将直接映射到在其推理请求上强制实施的每分钟令牌数速率限制。 还强制执行 每分钟请求数（RPM） 速率限制，其值根据 TPM 分配按比例设置，具体使用以下比率：

重要

配额每分钟请求数 (RPM) 与每分钟令牌数 (TPM) 的比率可能会因模型而异。 以编程方式部署模型或 请求增加配额 时，不会将 TPM 和 RPM 的精细控制作为独立值。 配额按容量单位分配，其中包含对应的 RPM 和 TPM 数量：

模型 能力 每分钟请求数 （RPM） 每分钟标记数 (TPM)
较旧的聊天模型 1 个单位 6 转/分钟 每分钟千次（TPM）
o1 和 o1-preview 1 个单位 1 转速 (RPM) 6,000 每分钟交易量（TPM）
o3 1 个单位 1 转速 (RPM) 每分钟千次（TPM）
o4-mini 1 个单位 1 转速 (RPM) 每分钟千次（TPM）
o3-mini 1 个单位 1 转速 (RPM) 一万 TPM
o1-mini 1 个单位 1 转速 (RPM) 一万 TPM
o3-pro 1 个单位 1 转速 (RPM) 一万 TPM

这对于编程模型部署尤其重要，因为 RPM/TPM 比率的更改可能会导致意外分配配额。

在订阅和区域内全局分配 TPM 的灵活性允许Azure OpenAI 放宽其他限制：

  • 每个区域的最大资源数增加到 30。
  • 消除了在一个资源中只能为同一模型创建一个部署的限制。

请求更多配额

提交配额增加申请表，为Azure 销售的 Foundry 模型、Azure OpenAI 模型和 Anthropic 模型申请增加配额。 除了Anthropic模型，来自合作伙伴和社区的模型都不支持增加配额。

配额增加请求按照收到的顺序进行处理，优先考虑那些积极使用现有配额分配的客户。 不符合此条件的请求可能会被拒绝。

特定模型的设置

不同的模型部署，也称为模型类具有唯一的最大 TPM 值，你现在可以控制这些值。 这表示在给定区域内可以分配给该类型模型部署的最大 TPM 量。

所有其他模型类都具有通用的最大 TPM 值。

注意

配额“每分钟令牌数 (TPM)”的分配与模型的最大输入令牌限制无关。 模型输入令牌限制在 模型表中 定义，不受对 TPM 所做的更改的影响。

分配配额

创建模型部署时，可以选择将 Token-Per-Minute （TPM） 分配给该部署。 TPM 可以按 1,000 为增量进行修改，它会映射到部署中强制执行的 TPM 和 RPM 速率限制，如上所述。

若要从 Microsoft Foundry 门户创建新部署请选择 Deployments>Deploy model>Deploy 基础模型>Select Model>Confirm。

部署后，可以通过从 Foundry 门户中的“部署”页选择和编辑模型来调整 TPM 分配。 还可以从 “管理>模型配额 ”页修改此设置。

重要

配额和限制可能会更改。 有关最新的信息，请参阅我们的配额和限制文章。

查看和请求配额

要查看特定区域中跨部署的配额分配的全貌，请在Foundry 门户中选择>和“配额”。

  • 部署：按模型类别划分的模型部署。
  • 配额类型：每个模型类型每个区域都有一个配额值。 配额涵盖该模型的所有版本。
  • 配额分配：对于配额名称，这显示了部署所使用的配额，以及该订阅和区域已批准的配额总量。 此使用的配额量也在条形图中表示。
  • 请求配额：图标导航到可提交增加配额的请求 的此窗体 。

迁移现有部署

在过渡到新的配额系统和基于 TPM 的分配过程中，所有现有的 Azure OpenAI 模型部署都已自动迁移到使用配额。 在现有 TPM/RPM 的分配由于之前自定义的速率限制增加而超过默认值的情况下，将等效的 TPM 分配给受影响的部署。

了解速率限制

将 TPM 分配给部署后，将为部署设置每分钟标记数 (TPM) 和每分钟请求数 (RPM) 的速率上限，如上所述。 TPM 速率限制基于在收到请求时，请求估计可处理的最大标记数。 它与用于计费的令牌计数不同，该计数是在完成所有处理后计算的。

收到每个请求时，Azure OpenAI 会计算一个预计的最大处理令牌数，其中包括以下内容：

  • 提示文本和计数
  • max_tokens 参数设置
  • best_of参数设置

当请求进入部署终结点时，估计的最大标记处理数将添加到每分钟重置的所有请求的运行标记数。 如果在该分钟中的任何时间达到 TPM 速率限制值，则进一步的请求将收到 429 响应代码，直到计数器重置。

重要

速率限制计算中使用的令牌计数是一个部分基于 API 请求的字符计数的估算值。 速率限制令牌估算与用于计费或确定请求是否低于模型输入令牌限制的令牌计算不同。 由于速率限制令牌计算具有近似性质，因此与对每个请求进行精确令牌计数的度量相比，速率限制可以在预期的时间之前触发，这是预期的行为。

RPM 速率限制基于一段时间内收到的请求数。 速率限制要求请求在一分钟内均匀分布。 如果未保持此平均流量， 则请求可能会返回 429 状态码，即使在一分钟内测量时未超出限制。 若要实现此行为，Azure OpenAI 会评估传入请求的速率（通常为 1 或 10 秒）。 如果在此期间收到的请求数超出了设定 RPM 限制的预期，则新请求将接收 429 响应代码，直到下一个评估期。 例如，如果 Azure OpenAI 正在监视 1 秒间隔的请求速率，则在每 1 秒期间收到 10 个以上的请求（每分钟 600 个请求 = 每秒 10 个请求）时，600-RPM 部署会发生速率限制。

注意

如果使用预配的吞吐量单位（PTU），则系统以不同的方式计算速率限制。 请参阅 Foundry 模型的预配吞吐量是什么？的基于利用率的请求评估部分，了解详细信息。

限速响应标头

Azure OpenAI 在每个 API 调用的 HTTP 响应标头中包含速率限制信息。 使用这些标头以编程方式监视使用情况，并主动避免 429 错误。

标题 示例值 描述
x-ratelimit-limit-requests 60 此部署每分钟允许的最大请求数量。
x-ratelimit-limit-tokens 150000 此部署每分钟允许的最大令牌数。
x-ratelimit-remaining-requests 59 在达到速率限制之前剩余的请求。
x-ratelimit-remaining-tokens 149984 达到速率限制前的剩余词元数。
x-ratelimit-reset-requests 10 请求速率限制重置前的时间。
x-ratelimit-reset-tokens 300 基于令牌的速率限制重置前的剩余时间。
retry-after-ms 2000 包含在 429 个响应中。 重试前建议的等待时间（以毫秒为单位）。

提示

在应用程序中监视 x-ratelimit-remaining-requests 和 x-ratelimit-remaining-tokens，以检测何时接近限制，并在收到 429 之前主动限制请求。

速率限制最佳做法

若要最大程度地减少与速率限制相关的问题，请使用以下技术：

优化请求

  • 设置 max_tokens 为满足您需求的最低值。 速率限制词元估算包含 max_tokens，即使实际响应要短得多。 例如，如果预期响应大约为 200 个令牌，则请勿将 max_tokens 设置为 4,000。
  • 设置 best_of 为 1 除非你特别需要多次完成。 best_of 每增加一个单位，都会使词元计数乘以你的速率限制。
  • 尽可能减小提示大小。 较短的提示会减少对速率限制的词元消耗。

实现带指数退避的重试逻辑

收到 429 响应时自动重试请求。 如果存在，请使用 retry-after-ms 标头值；否则，使用带有随机抖动的指数退避：

  1. 在第一次失败后等待短暂的随机延迟。
  2. 如果重试失败，则加倍延迟（指数退避）。
  3. 添加随机抖动以防止所有客户端在同一时刻重试。
  4. 设置最大重试次数（例如 5-10），以避免无限循环。

重要

失败的请求仍计入每分钟速率限制。 无退避地持续重新发送请求会使限制问题恶化。

选项 1：使用 SDK 的内置重试（最简单的 - 建议）

Azure OpenAI Python SDK（openai v1.0+）具有内置自动重试功能，并针对 429 和暂时性错误采用指数退避策略。 默认值为两次重试。 你可以增加它。

from openai import AzureOpenAI

# Set max_retries globally on the client (default is 2)
client = AzureOpenAI(
    azure_endpoint="https://<your-resource>.openai.azure.com/",
    api_key="<your-api-key>",
    api_version="2024-10-21",
    max_retries=5  # up to 5 retries with automatic exponential backoff
)

# All calls through this client automatically retry on 429
response = client.chat.completions.create(
    model="gpt-4o",  # deployment name
    messages=[{"role": "user", "content": "Hello"}]
)

# Or override per-request:
response = client.with_options(max_retries=8).chat.completions.create(
    model="gpt-4o",
    messages=[{"role": "user", "content": "Hello"}]
)

注意

SDK 会自动尊重 retry-after 标头，并利用使用抖动的指数退避。 对于大多数应用程序，客户端上配置 max_retries 已足够 - 不需要第三方重试库。

选项 2：使用 tenacity 库进行自定义重试（高级）

当您需要更全面地控制重试行为（例如，自定义日志记录、选择性异常处理、熔断器）时，请使用此选项：

import openai
from openai import AzureOpenAI
from tenacity import (
    retry,
    retry_if_exception_type,
    stop_after_attempt,
    wait_random_exponential,
)

client = AzureOpenAI(
    azure_endpoint="https://<your-resource>.openai.azure.com/",
    api_key="<your-api-key>",
    api_version="2024-10-21",
    max_retries=0  # disable SDK built-in retry to avoid double-retrying
)

@retry(
    wait=wait_random_exponential(min=1, max=60),
    stop=stop_after_attempt(6),
    retry=retry_if_exception_type(openai.RateLimitError),  # only retry on 429
    reraise=True
)
def chat_completion_with_backoff(**kwargs):
    return client.chat.completions.create(**kwargs)

response = chat_completion_with_backoff(
    model="gpt-4o",
    messages=[{"role": "user", "content": "Hello"}]
)

重要

使用自定义重试库时，在 SDK 客户端上设置 max_retries=0 以禁用其内置重试。 否则，tenacity 的每次尝试本身可能会最多触发两次附加 SDK 重试，导致请求数远超预期。

选项 3：手动实现（无第三方库）

import time
import random
import openai
from openai import AzureOpenAI

client = AzureOpenAI(
    azure_endpoint="https://<your-resource>.openai.azure.com/",
    api_key="<your-api-key>",
    api_version="2024-10-21",
    max_retries=0  # disable SDK built-in retry
)

def retry_with_exponential_backoff(
    func,
    initial_delay: float = 1,
    exponential_base: float = 2,
    jitter: bool = True,
    max_retries: int = 10,
    errors: tuple = (openai.RateLimitError,),
):
    """Retry a function with exponential backoff."""
    def wrapper(*args, **kwargs):
        num_retries = 0
        delay = initial_delay
        while True:
            try:
                return func(*args, **kwargs)
            except errors as e:
                num_retries += 1
                if num_retries > max_retries:
                    raise Exception(
                        f"Maximum number of retries ({max_retries}) exceeded."
                    ) from e
                delay *= exponential_base * (1 + jitter * random.random())
                time.sleep(delay)
            except Exception as e:
                raise e
    return wrapper

@retry_with_exponential_backoff
def chat_completion_with_backoff(**kwargs):
    return client.chat.completions.create(**kwargs)

使用 Polly 的 C# 示例（v7）：

using Azure;
using Azure.AI.OpenAI;
using Polly;

var retryPolicy = Policy
    .Handle<RequestFailedException>(ex => ex.Status == 429)
    .WaitAndRetryAsync(
        retryCount: 6,
        sleepDurationProvider: (retryAttempt, exception, context) =>
        {
            // Use retry-after-ms header if available
            if (exception is RequestFailedException rfEx)
            {
                var raw = rfEx.GetRawResponse();
                if (raw != null && raw.Headers.TryGetValue("retry-after-ms", out string value)
                    && int.TryParse(value, out int ms))
                {
                    return TimeSpan.FromMilliseconds(ms);
                }
            }
            // Otherwise, exponential backoff with jitter
            return TimeSpan.FromSeconds(Math.Pow(2, retryAttempt))
                + TimeSpan.FromMilliseconds(Random.Shared.Next(0, 1000));
        },
        onRetry: (exception, timespan, retryCount, context) =>
        {
            Console.WriteLine($"Retry {retryCount} after {timespan.TotalSeconds:F1}s due to: {exception.Message}");
        }
    );

// Usage
var endpoint = new Uri("https://<your-resource>.openai.azure.com/");
var credential = new AzureKeyCredential("<your-api-key>");
var client = new AzureOpenAIClient(endpoint, credential);

await retryPolicy.ExecuteAsync(async () =>
{
    var response = await client.GetChatClient("gpt-4o")
        .CompleteChatAsync([new UserChatMessage("Hello")]);
    Console.WriteLine(response.Value.Content[0].Text);
});

注意

.NET的Azure SDK还具有内置的重试支持。 构造 AzureOpenAIClientOptions 时，可以配置 options.Retry.MaxRetries 和 options.Retry.Mode = RetryMode.Exponential，而不是使用 Polly。 如果需要更高级的模式（断路器、舱头等），请使用 Polly。

监视和管理部署级使用情况

  • 检查每个部署 TPM 分配，而不仅仅是订阅级配额。 你可能已在订阅级别获得批准的配额，但由于配额未分配给接收流量的特定部署而遇到 429。
  • 在部署之间根据观察到的使用情况重新平衡配额。 使用 Azure Monitor 指标查看 24 小时和七天的使用趋势，并检测突发模式。
  • 使用 Foundry 门户中的配额管理功能来增加高流量部署的 TPM，并减少低利用率部署的 TPM。

均匀分配流量

  • 避免工作负荷出现尖锐峰值。 请求速率限制要求请求在每分钟内均匀分布。 即使请求总数低于每分钟限制，1 秒或 10 秒时段内的突发也会触发 429。
  • 载入新工作负载或增加负载时，逐渐增加流量。
  • 如果工作负荷需要比单个部署支持的吞吐量更高的吞吐量，请将请求分散到多个部署或区域中。

尽可能使用异步/批处理

如果用例不需要即时响应，请考虑使用异步模式：

  • 将请求排队并以受控速率处理。
  • 使用多次部署进行并行处理，以避免超过单次部署的速率限制。

了解 429 限制错误及其应对方法

429 错误（“请求过多”）表示系统因超出速率限制或系统目前无法处理请求而拒绝你的请求。 并非所有 429 错误都有相同的根本原因，正确的操作取决于发生 429 的原因。

429 错误的类型

场景 错误消息指示器 根源 建议的操作
超出速率限制 “请求 ... 已被限制”或“已超出速率限制” 你的请求超过了部署分配限额中的 TPM 或 RPM 速率限制。 增加部署的 TPM 分配、跨部署重新平衡配额或 请求增加配额。
系统容量限制 “服务暂时无法处理你的请求”或“系统遇到高需求” 后端容量受到限制。 这种情况通常是暂时性的。 retry-after-ms 延迟后重试。 如果持续，请考虑升级到 预配的吞吐量（PTU）， 以获取保证的容量。
临时速率限制调整 出现 429 响应，但已配置配额未改变；响应标头中的 x-ratelimit-limit-tokens 低于部署配置的 TPM 标准（即用即付）部署共享一个资源池。 当需求接近容量限制时，系统会暂时降低部署的有效速率限制，以保持所有客户的可靠性。 这种减少是保护性的和暂时性的。 使用 retry-after-ms 退避重试。 调整通常在几个小时内解决。 对于需要一致吞吐量的工作负荷，请考虑预配吞吐量（PTU）。
请求参数超出词元预算 速率限制已触发，但令牌使用量指标显示偏低 速率限制计算包含 max_tokens 和提示估算，而不仅仅是已计费的词元。 即使实际响应较小，具有高 max_tokens 值的请求也能消耗速率限制预算。 减少 max_tokens 以匹配预期响应大小。

重要

许多客户误解与容量相关的 429 状态码为配额问题，从而采取了不正确的补救措施（例如，当问题是暂时性的容量压力时请求增加配额）。 在采取行动之前，请始终检查错误消息和响应标头，以识别根本原因。

为什么即使词元使用指标低于配额，你也可能看到 429

Azure OpenAI rate limiting 和 usage metrics不同：

  • Azure Monitor 中的词元使用指标显示来自成功处理请求的计费令牌。
  • 速率限制 适用于 收到 API 请求时，包括以后拒绝或从未计费的请求。

由于这种差异，即使令牌使用指标远远低于配额，也可以获得 429 个响应。 常见原因包括：

  • max_tokens 过度估计：使用 估计的最大 令牌计数（提示 + max_tokens），而不是生成的实际令牌来计算速率限制。
  • 已拒绝的请求：由于输入长度限制（HTTP 400）而拒绝的请求可能仍计入速率限制，但不会显示在计费令牌指标中。
  • 突发模式：RPM 强制在小时间窗口（1-10 秒）内评估请求。 即使每分钟总计在限制范围内，短期时段内的请求突发也会触发限流。
  • 为服务可靠性临时调整速率限制：标准（即用即付）部署跨客户共享公共资源池。 为了保持服务可靠且公平，系统会持续监视此共享池的需求。 当部署需求接近或超出容量限制时，系统可能会暂时降低该部署 的有效速率限制 。 在此调整期间，正常情况下接受的请求将返回 429 个响应，即使配置的配额没有更改。 此保护措施可防止共享资源池的所有客户的服务降级。 调整是 暂时的 ，一旦流量稳定下来，通常会在几个小时内解决。 可以通过检查有效速率限制（在响应标头中 x-ratelimit-limit-tokens 可见）是否低于您所配置的 TPM 分配来监控此情况。
  • 分布式强制：跨分布式基础结构执行速率限制可能并非完全精确或立即反映在聚合指标中。

提示

如果在临时速率限制调整期间看到 429 个响应：

  1. 使用退避重试 - 遵循 retry-after-ms 标头。 调整是暂时的，随着需求稳定，将得到解决。
  2. 分散流量 - 如果可能，请在多个部署或区域之间分配请求。
  3. 检查你的流量模式 — 持续的高突发是最常见的触发因素。 逐渐增加工作负荷可降低调整的可能性。
  4. 考虑预配吞吐量 （PTU） - 对于需要一致吞吐量且不具有共享池可变性的生产工作负荷， 预配吞吐量 提供具有保证速率限制的专用容量。

要依赖的内容：

  • 使用令牌使用情况指标了解计费消耗量。
  • 使用 HTTP 响应代码（429） 和 响应标头 （x-ratelimit-remaining-*， x-ratelimit-limit-*）实时检测和应对速率限制措施。
  • 将响应标头中的 x-ratelimit-limit-tokens 与您配置的 TPM 进行比对，以检测临时调整是否正在进行中。

何时重试与何时升级

情况 行动
偶尔会出现 429 错误，使用 retry-after-ms 退避后即可解决 重试 - 此行为是正常的，对于共享的（标准）部署而言是正常的。
在开发或测试期间多次出现 429 通常可以接受 - 非生产期间出现 429 可能是有意的成本防护措施。
生产中持续出现 429，且低于批准的配额 升级 - 提出 支持请求 以进行工程调查。
速率限制提高未反映在有效限制中 升级 - 首先验证部署级别的配额分配，然后在问题仍然存在时升级。
对延迟敏感或任务关键型的生产工作负载频繁出现 429 升级 - 考虑 预配吞吐量（PTU）， 以确保容量和延迟 SLA。

注意

标准（即用即付）部署使用共享资源池。 节流保护所有用户的整体服务可靠性。 偶尔出现的暂时性 HTTP 错误代码 429 是预期行为，而不是服务缺陷。 对于需要可预测的延迟和保证吞吐量的工作负荷，建议使用预配吞吐量（PTU）。

通过编程检查配额和容量

除了 Foundry 门户之外，还可以使用两个Azure 资源管理器 REST API 以编程方式检查订阅的配额消耗和可用模型容量。

选择正确的 API

使用情况 API 模型容量 API
它回答的问题 我已消耗的配额占限额的多少？ 特定模型可以使用多少可部署容量？
Scope 订阅 + 位置 订阅（同时订阅所有地点）
输入 仅限位置信息 模型名称、版本和格式
返回 该区域内每个配额条目的当前用量和限额 一个模型按位置和部署类型划分的可用容量
典型用例 监视消耗量，在接近限制时触发警报 在创建或缩放部署之前预先检查容量
API 参考 用法 - 列表 模型容量 - 列表

需要账本视图来查看已使用的内容以及剩余内容时，请使用 使用情况 API 。 如果想要了解可在何处部署模型以及每个位置的可用容量，请使用模型容量 API。

注意

这两个 API 都会返回与订阅关联的所有模型的信息，包括不再可用于新部署的 已停用模型 。

使用情况 API

使用情况 API 返回给定区域的每个配额行，包括当前消耗量（currentValue）和分配的限制。

请求：

GET https://management.azure.com/subscriptions/{subscriptionId}/providers/Microsoft.CognitiveServices/locations/{location}/usages?api-version=2024-10-01

示例 - 检查美国东部的配额使用情况：

import requests
import json
from azure.identity import DefaultAzureCredential

subscription_id = "<your-subscription-id>"
location = "eastus"

credential = DefaultAzureCredential()
token = credential.get_token("https://management.azure.com/.default")
headers = {"Authorization": f"Bearer {token.token}"}

url = (
    f"https://management.azure.com/subscriptions/{subscription_id}"
    f"/providers/Microsoft.CognitiveServices/locations/{location}/usages"
    f"?api-version=2024-10-01"
)

response = requests.get(url, headers=headers)
usages = response.json()

# Show quota lines that have a non-zero limit
for item in usages["value"]:
    if item["limit"] > 0:
        print(f"{item['name']['localizedValue']}: {item['currentValue']}/{item['limit']}")

关键字段：

领域 描述
name.value 格式为 {Provider}.{DeploymentType}.{Model} 的配额名称
name.localizedValue 便于人类阅读的描述，包括单位
currentValue 当前部署已消耗了该配额的多少
limit 您订阅中此模型和部署类型的配额限制

模型容量 API

模型容量 API 返回订阅中所有位置和部署类型的特定模型的可用部署容量。

请求：

GET https://management.azure.com/subscriptions/{subscriptionId}/providers/Microsoft.CognitiveServices/modelCapacities?api-version=2024-10-01&modelFormat={format}&modelName={name}&modelVersion={version}

示例 - 检查 gpt-4o 容量是否可用：

import requests
import json
from azure.identity import DefaultAzureCredential

subscription_id = "<your-subscription-id>"
model_name = "gpt-4o"
model_version = "2024-08-06"

credential = DefaultAzureCredential()
token = credential.get_token("https://management.azure.com/.default")
headers = {"Authorization": f"Bearer {token.token}"}

url = (
    f"https://management.azure.com/subscriptions/{subscription_id}"
    f"/providers/Microsoft.CognitiveServices/modelCapacities"
    f"?api-version=2024-10-01"
    f"&modelFormat=OpenAI&modelName={model_name}&modelVersion={model_version}"
)

response = requests.get(url, headers=headers)
capacities = response.json()

# Show locations with available capacity for Standard deployments
for item in capacities["value"]:
    props = item["properties"]
    if props["availableCapacity"] > 0 and "Standard" in props["skuName"]:
        print(f"{item['location']} ({props['skuName']}): {props['availableCapacity']} available")

关键字段：

领域 描述
location Azure 区域
properties.skuName 部署类型（Standard、GlobalStandard、DataZoneStandard、ProvisionedManaged 等）
properties.availableCapacity 此模型、位置和部署类型的订阅中可用的容量单位
properties.availableFinetuneCapacity 可用的微调容量（如果适用）

自动部署

若要使用 REST、Azure CLI、Azure PowerShell、ARM、Bicep 或 Terraform 通过编程方式创建 Azure OpenAI 部署并分配每分钟令牌数 (TPM) 配额，请参阅 在 Microsoft Foundry 中使用配额自动执行 Azure OpenAI 部署。

资源删除

当尝试从 Azure 门户中删除 Azure OpenAI 资源时，如果仍有部署存在，则删除将被阻止，直到关联的部署被删除为止。 先删除部署可以正确释放配额分配，以便将其用于新的部署。

但是，如果使用 REST API 或其他一些编程方法删除资源，则无需先删除部署。 发生这种情况时，关联的配额分配将在清除资源前的 48 小时内保持不可用，无法分配给新的部署。 若要触发已删除资源的立即清除以释放配额，请按照 清除已删除的资源说明进行操作。

后续步骤

  • Last updated on