Administrar la cuota de modelos de Azure OpenAI en Microsoft Foundry (clásico)

Visualización actual:Versión - Cambio a la versión del nuevo portal de Foundry

La cuota proporciona flexibilidad para administrar activamente la asignación de límites de velocidad en las implementaciones de la suscripción. En este artículo se explica el proceso de administración de la cuota de OpenAI de Azure.

Requisitos previos

Introducción a la cuota

La función de cuota de Azure OpenAI permite la asignación de límites de velocidad a tus despliegues, hasta un límite global denominado quota. La cuota se asigna a la suscripción por región, por modelo, por tipo de implementación en unidades de tokens por minuto (TPM). Al incorporar una suscripción a Azure OpenAI, obtiene la cuota predeterminada para la mayoría de los modelos disponibles. A continuación, asigna TPM a cada implementación a medida que se crean y la cuota disponible para ese modelo se reduce en esa cantidad. Puede seguir creando implementaciones y asignarlas a TPM hasta que alcance el límite de cuota. Una vez que esto suceda, solo puede crear nuevas implementaciones de ese modelo reduciendo el TPM asignado a otras implementaciones del mismo modelo, lo que libera TPM para su uso, o solicitando y obteniendo la aprobación para un aumento de cuota de modelo en la región deseada.

Cuando se crea una implementación, el TPM asignado se corresponde directamente con el límite de tokens por minuto que se aplica a sus solicitudes de inferencia. También se aplica un límite de velocidad requests-Per-Minute (RPM), cuyo valor se establece proporcionalmente a la asignación de TPM mediante la siguiente relación:

La flexibilidad para distribuir TPM globalmente dentro de una suscripción y región ha permitido que Azure OpenAI afloje otras restricciones:

• Los recursos máximos por región se incrementan a 30.
• Se ha quitado el límite de creación de más de una implementación del mismo modelo en un recurso.

Solicitar más cuota

Envíe el formulario de solicitud de aumento de cuota para solicitar aumentos de cuota para Foundry Models comercializados por Azure, modelos de Azure OpenAI y modelos de Anthropic. A excepción de los modelos de Anthropic, los modelos de socios y de la comunidad no admiten aumentos de cuota.

Las solicitudes de aumento de cuota se procesan en el orden en que se reciben y la prioridad va a los clientes que usan activamente su asignación de cuota existente. Es posible que se denieguen las solicitudes que no cumplen esta condición.

Configuración específica del modelo

Las distintas implementaciones de modelos, también denominadas clases de modelo, tienen valores de TPM máximo únicos que ahora puede controlar. Esto representa la cantidad máxima de TPM que se puede asignar a ese tipo de implementación de modelos en una región determinada.

Todas las demás clases de modelo tienen un valor máximo de TPM común.

Asignación de cuota

Al crear una implementación de modelo, tiene la opción de asignar Tokens-Per-Minute (TPM) a esa implementación. TPM se puede modificar en incrementos de 1000 y se asignará a los límites de velocidad de TPM y RPM aplicados en la implementación, como se ha descrito anteriormente.

Para crear una nueva implementación desde el portal de Microsoft Foundry seleccione Deployments>Deploy model>Deploy modelo base>Select Model>Confirm.

Después de la implementación, puede ajustar la asignación de TPM seleccionando y editando el modelo en la página Implementaciones del portal de Foundry. También puede modificar esta configuración desde la páginaCuota del modelo>.

Visualización y solicitud de cuota

Para ver todas las asignaciones de cuota en implementaciones de una región determinada, seleccione Administración>Cuota en el Portal de Foundry:

• Implementación: implementaciones de modelos divididas por clase de modelo.
• Tipo de cuota: hay un valor de cuota por región para cada tipo de modelo. La cuota cubre todas las versiones de ese modelo.
• Asignación de cuota: Para el nombre de la cuota, se muestra cuánto de la cuota es utilizada por las implementaciones y el total de cuota aprobada para esta suscripción y región. Esta cantidad de cuota usada también se representa en el gráfico de barras.
• Cuota de solicitud: el icono navega a este formulario donde se pueden enviar solicitudes para aumentar la cuota.

Migración de implementaciones existentes

Como parte de la transición al nuevo sistema de cuota y a la asignación basada en TPM, todas las implementaciones de modelos de OpenAI existentes Azure se han migrado automáticamente para usar la cuota. En los casos en los que la asignación de TPM/RPM existente supera los valores predeterminados debido a los aumentos de límite de velocidad personalizados anteriores, el TPM equivalente se asignó a las implementaciones afectadas.

Comprender los límites de tasa

La asignación de TPM a una implementación establece los límites de velocidad tokens por minuto (TPM) y solicitudes por minuto (RPM) para la implementación, como se ha descrito anteriormente. Los límites de velocidad de TPM se basan en el número máximo de tokens que se estima que se van a procesar mediante una solicitud en el momento en que se recibe la solicitud. No es lo mismo que el recuento de tokens usado para la facturación, que se calcula una vez completado todo el procesamiento.

A medida que se recibe cada solicitud, Azure OpenAI calcula un recuento máximo estimado de tokens procesados que incluye lo siguiente:

• Mensaje de texto y recuento
• Configuración del parámetro max_tokens
• Configuración del parámetro "best_of"

A medida que las solicitudes entran en el punto de conexión de implementación, el recuento de tokens máximos procesados estimado se agrega a un recuento de tokens en ejecución de todas las solicitudes que se restablecen cada minuto. Si en cualquier momento durante ese minuto, se alcanza el valor de límite de velocidad de TPM, las solicitudes adicionales recibirán un código de respuesta 429 hasta que se restablezca el contador.

Los límites de velocidad de RPM se basan en el número de solicitudes recibidas a lo largo del tiempo. El límite de velocidad espera que las solicitudes se distribuyan uniformemente durante un período de un minuto. Si no se mantiene este flujo medio, las solicitudes pueden recibir una respuesta 429 aunque no se cumpla el límite cuando se mida durante un minuto. Para implementar este comportamiento, Azure OpenAI evalúa la tasa de solicitudes entrantes durante un pequeño período de tiempo, normalmente 1 o 10 segundos. Si el número de solicitudes recibidas durante ese tiempo supera lo que se esperaría en el límite de RPM establecido, las nuevas solicitudes reciben un código de respuesta 429 hasta el siguiente período de evaluación. Por ejemplo, si Azure OpenAI supervisa la tasa de solicitudes en intervalos de 1 segundo, la limitación de velocidad se produce para una implementación de 600 RPM si se reciben más de 10 solicitudes durante cada período de 1 segundo (600 solicitudes por minuto = 10 solicitudes por segundo).

Encabezados de respuesta de límite de velocidad

Azure OpenAI incluye información de límite de velocidad en los encabezados de respuesta HTTP de cada llamada API. Use estos encabezados para supervisar mediante programación el uso y evitar proactivamente errores 429.

Procedimientos recomendados de límite de velocidad

Para minimizar los problemas relacionados con los límites de velocidad, use las técnicas siguientes:

Optimización de las solicitudes

• Establezca max_tokens en el valor mínimo que sirve a su escenario. La estimación del token de límite de velocidad incluye max_tokens, incluso si la respuesta real es mucho más corta. Por ejemplo, si espera respuestas de aproximadamente 200 tokens, no establezca max_tokens en 4000.
• Establézcalo best_of en 1 a menos que necesite específicamente varias finalizaciones. Cada incremento de best_of multiplica el recuento de tokens en relación con tu límite de velocidad.
• Reduzca el tamaño de la solicitud siempre que sea posible. Los avisos más cortos usan menos tokens hacia el límite de velocidad.

Implementación de la lógica de reintento con retroceso exponencial

Vuelva a intentar automáticamente las solicitudes cuando reciba una respuesta 429. Use el valor del retry-after-ms encabezado si está presente; de lo contrario, use retroceso exponencial con vibración aleatoria:

1. Espere un breve retraso aleatorio después del primer error.
2. Si se produce un error en el reintento, doble el retraso (retroceso exponencial).
3. Agregue vibración aleatoria para evitar que todos los clientes vuelvan a intentarlo al mismo instante.
4. Establezca un número máximo de reintentos (por ejemplo, de 5 a 10) para evitar bucles infinitos.

Opción 1: Usar el reintento integrado del SDK (el más sencillo - recomendado)

Azure SDK de Python de OpenAI (openai v1.0+) tiene reintento automático integrado con retroceso exponencial para errores 429 y transitorios. El valor predeterminado es de dos reintentos. Puede aumentarlo:

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"}]
)

Opción 2: Reintento personalizado con la tenacity biblioteca (avanzada)

Úselo cuando necesite más control sobre el comportamiento de reintento (por ejemplo, registro personalizado, control selectivo de excepciones, disyuntores):

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"}]
)

Opción 3: Implementación manual (sin biblioteca de terceros)

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)

Ejemplo de C# con Polly (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);
});

Supervisión y administración del uso en el nivel de implementación

• Compruebe la asignación de TPM por cada implementación, y no solo la cuota a nivel de suscripción. Es posible que haya aprobado la cuota en el nivel de suscripción, pero alcance los 429 porque la cuota no está asignada a la implementación específica que recibe tráfico.
• Reequilibrar la cuota entre implementaciones en función del uso observado. Utiliza métricas de Azure Monitor para revisar las tendencias de uso de 24 horas y siete días y detectar patrones irregulares.
• Utilice la administración de cuotas en el portal de Foundry para aumentar el TPM en implementaciones de alto tráfico y reducir el TPM en las infrautilizadas.

Distribuir el tráfico uniformemente

• Evite picos agudos en la carga de trabajo. Los límites de velocidad rpm esperan que las solicitudes se distribuyan uniformemente durante cada minuto. Incluso si las solicitudes totales están por debajo del límite por minuto, una ráfaga dentro de una ventana de 1 o 10 segundos puede desencadenar un 429.
• Aumente el tráfico gradualmente al incorporar nuevas cargas de trabajo o aumentar la carga.
• Distribuir solicitudes entre varias implementaciones o regiones si la carga de trabajo requiere un mayor rendimiento que admite una sola implementación.

Uso del procesamiento asincrónico o por lotes siempre que sea posible

Si el caso de uso no requiere respuestas inmediatas, considere la posibilidad de usar patrones asincrónicos:

• Coloque las solicitudes en cola y procéselas a una tasa controlada.
• Use varias implementaciones para paralelizar el procesamiento sin superar el límite de velocidad de una sola implementación.

Descripción de los errores de limitación 429 y qué hacer

Un error 429 ("Demasiadas solicitudes") significa que el sistema rechazó la solicitud porque se superó un límite de velocidad o el sistema no puede procesar la solicitud en este momento. No todos los errores 429 tienen la misma causa principal y la acción correcta depende de por qué se produjo el 429.

Tipos de errores 429

Por qué puede ver códigos de estado 429 incluso cuando las métricas de uso de tokens están por debajo del límite

Azure OpenAI limitación de tasa y métricas de uso no son lo mismo:

• Métricas de uso de tokens en Azure Monitor muestran tokens facturados de solicitudes procesadas con éxito.
• La limitación de velocidad se aplica a las solicitudes de API en el momento en que se reciben, incluidas las solicitudes que se rechazan más adelante o nunca se facturan.

Debido a esta diferencia, puede obtener 429 respuestas incluso cuando las métricas de uso de tokens se ven muy por debajo de la cuota. Entre las razones comunes se incluyen:

• max_tokens Sobreestimación: los límites de velocidad se calculan con el recuento máximo estimado de tokens (prompt + max_tokens), no con los tokens reales generados.
• Solicitudes rechazadas: las solicitudes rechazadas debido a los límites de longitud de entrada (HTTP 400) podrían seguir contando hacia la limitación de velocidad, pero no aparecerán en las métricas de token facturadas.
• Patrones de ráfaga: la aplicación de RPM evalúa las solicitudes en ventanas de tiempo pequeñas (de 1 a 10 segundos). Una ráfaga de solicitudes en una ventana corta desencadena la limitación incluso si el total por minuto está dentro de los límites.
• Ajuste temporal del límite de velocidad para la confiabilidad del servicio: las implementaciones estándar (de pago por uso) comparten un grupo de recursos común entre los clientes. Para mantener el servicio confiable y justo, el sistema supervisa continuamente la demanda en este grupo compartido. Cuando la demanda de una implementación se aproxima o supera los límites de capacidad, el sistema podría reducir temporalmente el límite de velocidad efectivo para esa implementación. Durante este período de ajuste, las solicitudes que se habrían aceptado en condiciones normales devuelven 429 respuestas, aunque la cuota configurada no haya cambiado. Esta medida de protección evita la degradación del servicio para todos los clientes que comparten el grupo de recursos. El ajuste es temporal y normalmente se resuelve en unas pocas horas una vez que se estabiliza el tráfico. Puede supervisar esta condición comprobando si el límite de velocidad efectivo (visible en x-ratelimit-limit-tokens los encabezados de respuesta) es inferior a la asignación de TPM configurada.
• Cumplimiento distribuido: la aplicación del límite de velocidad en toda la infraestructura distribuida podría no ser perfectamente precisa o reflejarse inmediatamente en las métricas agregadas.

Qué se debe confiar en:

• Use métricas de uso de tokens para comprender el consumo facturado.
• Use códigos de respuesta HTTP (429) y encabezados de respuesta (x-ratelimit-remaining-*, x-ratelimit-limit-*) para detectar y responder a la aplicación del límite de velocidad en tiempo real.
• Compare x-ratelimit-limit-tokens en encabezados de respuesta con el TPM configurado para detectar si un ajuste temporal está activo.

Cuándo reintentar o cuándo escalar

Comprobar la cuota y la capacidad mediante programación

Además de Foundry portal, puede utilizar dos API REST de Azure Resource Manager para comprobar mediante programación el consumo de la cuota de su suscripción y la capacidad de modelo disponible.

Elección de la API adecuada

Use la API de usos cuando necesite una vista del libro de contabilidad de lo que ha consumido y lo que queda. Use la API de capacidades del modelo cuando quiera saber dónde puede implementar un modelo y cuánta capacidad hay disponible en cada ubicación.

API de usos

La API Usages devuelve cada línea de cuota de una región determinada, incluido el consumo actual (currentValue) y el límite asignado.

Solicitud:

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

Ejemplo: comprobación del uso de cuotas en Este de EE. UU.

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']}")

SUBSCRIPTION_ID="<your-subscription-id>"
LOCATION="eastus"

az rest --method get \
  --url "https://management.azure.com/subscriptions/$SUBSCRIPTION_ID/providers/Microsoft.CognitiveServices/locations/$LOCATION/usages?api-version=2024-10-01"

{
  "value": [
    {
      "name": {
        "value": "OpenAI.Standard.gpt-4o",
        "localizedValue": "Tokens Per Minute (thousands) - gpt-4o"
      },
      "currentValue": 0,
      "limit": 150,
      "unit": "Count"
    }
  ]
}

Campos clave:

API de capacidades de modelos

Model Capacitys API devuelve la capacidad de implementación disponible para un modelo específico en todas las ubicaciones y tipos de implementación de la suscripción.

Solicitud:

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

Ejemplo: compruebe dónde está disponible la capacidad 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")

SUBSCRIPTION_ID="<your-subscription-id>"

az rest --method get \
  --url "https://management.azure.com/subscriptions/$SUBSCRIPTION_ID/providers/Microsoft.CognitiveServices/modelCapacities?api-version=2024-10-01&modelFormat=OpenAI&modelName=gpt-4o&modelVersion=2024-08-06"

{
  "value": [
    {
      "location": "eastus",
      "properties": {
        "model": {
          "name": "gpt-4o",
          "format": "OpenAI",
          "version": "2024-08-06"
        },
        "skuName": "Standard",
        "availableCapacity": 150,
        "availableFinetuneCapacity": 0
      }
    }
  ]
}

Campos clave:

Automatización de la implementación

Para crear mediante programación implementaciones de Azure OpenAI y asignar cuota de tokens por minuto (TPM) mediante REST, CLI de Azure, Azure PowerShell, ARM, Bicep o Terraform, consulte Automatización de implementaciones de Azure OpenAI con cuota en Microsoft Foundry.

Eliminación de recursos

Cuando se intenta eliminar un recurso de Azure OpenAI desde el portal de Azure, si existen implementaciones, la eliminación se bloquea hasta que se eliminen las implementaciones asociadas. La eliminación de las implementaciones en primer lugar permite liberar correctamente las asignaciones de cuota para que se puedan usar en nuevas implementaciones.

Sin embargo, si elimina un recurso mediante la API REST o algún otro método mediante programación, esto omite primero la necesidad de eliminar las implementaciones. Cuando esto ocurre, la asignación de cuota asociada seguirá sin estar disponible para asignarla a una nueva implementación durante 48 horas hasta que se purgue el recurso. Para desencadenar una purga inmediata para que un recurso eliminado libere la cuota, siga las instrucciones de purga de un recurso eliminado.

Pasos siguientes

• Para revisar los valores predeterminados de cuota para Azure OpenAI, consulte el artículo quotas y límites