Gestire la quota dei modelli di Microsoft Foundry per Azure OpenAI (classico)

Attualmente visualizzando:Portale Foundry (versione classica) - Passare alla versione del nuovo portale Foundry

La quota offre la flessibilità necessaria per gestire attivamente l'allocazione dei limiti di capacità tra le distribuzioni all'interno della sottoscrizione. Questo articolo illustra il processo di gestione della quota Azure OpenAI.

Prerequisiti

Introduzione alla quota

La funzionalità di quota di Azure OpenAI consente l'assegnazione di limiti di frequenza alle distribuzioni, fino a un limite globale denominato quota. La quota viene assegnata alla sottoscrizione su base per regione, per modello, per tipo di distribuzione in unità di Token-per-Minuto (TPM). Quando si esegue l'onboarding di una sottoscrizione per Azure OpenAI, si riceve la quota predefinita per la maggior parte dei modelli disponibili. Quindi, si assegna TPM a ogni distribuzione durante la creazione e la quota disponibile per tale modello viene ridotta di tale importo. È possibile continuare a creare distribuzioni e assegnare loro TPM fino a raggiungere il limite di quota. In questo caso, è possibile creare solo nuove distribuzioni di tale modello riducendo il TPM assegnato ad altre distribuzioni dello stesso modello (liberando così TPM per l'uso) oppure richiedendo e approvando l'aumento della quota del modello nell'area desiderata.

Quando viene creata una distribuzione, il TPM assegnato è direttamente collegato al limite di frequenza di token per minuto applicato alle richieste di inferenza. Viene applicato anche un limite di frequenza Requests-Per-Minute (RPM), il cui valore viene impostato proporzionalmente all'assegnazione TPM usando il rapporto seguente:

La flessibilità di distribuire TPM a livello globale all'interno di una sottoscrizione e di un'area ha consentito Azure OpenAI per allentare altre restrizioni:

• Le risorse massime per area vengono aumentate a 30.
• Il limite alla creazione di non più di una distribuzione dello stesso modello in una risorsa è stato rimosso.

Richiedere più quota

Invia il modulo di richiesta di aumento della quota per richiedere aumenti della quota per i Modelli Foundry venduti da Azure, i modelli Azure OpenAI e i modelli Anthropic. Ad eccezione dei modelli Anthropic, i Modelli di partner e della community non supportano gli aumenti della quota.

Le richieste di aumento della quota vengono elaborate nell'ordine in cui vengono ricevute e la priorità passa ai clienti che usano attivamente l'allocazione di quote esistente. Le richieste che non soddisfano questa condizione potrebbero essere negate.

Impostazioni specifiche del modello

Distribuzioni di modelli diverse, dette anche classi di modelli, hanno valori TPM massimi univoci che è ora possibile controllare. Rappresenta la quantità massima di TPM che può essere allocata a quel tipo di distribuzione del modello in una determinata area.

Tutte le altre classi del modello hanno un valore TPM massimo comune.

Assegnare la quota

Quando si crea una distribuzione di modello, è possibile assegnare tokenPer-Minute (TPM) a tale distribuzione. TPM può essere modificato in incrementi di 1.000 e si assocerà ai limiti di frequenza TPM e RPM applicati alla distribuzione, come illustrato in precedenza.

Per creare una nuova distribuzione dal portale Microsoft Foundry selezionare Deployments>Distribuisci Modello>Distribuisci Modello Base>Seleziona Modello>Confirm.

Dopo la distribuzione, è possibile modificare l'allocazione TPM selezionando e modificando il modello dalla pagina Distribuzioni nel portale di Foundry. È anche possibile modificare questa impostazione dalla paginaQuota del modello di >.

Visualizzare e richiedere la quota

Per una visione completa delle allocazioni delle quote tra le distribuzioni in una determinata regione, selezionare Gestione>Quota nel Portale Foundry:

• Distribuzione: distribuzioni di modelli divise per classe modello.
• Tipo di quota: esiste un valore di quota per area per ogni tipo di modello. La quota copre tutte le versioni del modello.
• Allocazione quota: per quanto riguarda il nome della quota, viene mostrata la quota usata dalle distribuzioni e la quota totale approvata per questa sottoscrizione e area. Questa quantità di quota usata è rappresentata anche nel grafico a barre.
• Richiesta quota: l'icona passa a questo modulo in cui è possibile inviare richieste di aumento della quota.

Migrazione delle distribuzioni esistenti

Nell'ambito della transizione al nuovo sistema di quota e all'allocazione basata su TPM, tutte le distribuzioni di Azure modelli OpenAI esistenti sono state automaticamente migrate per usare la quota. Nei casi in cui l'allocazione TPM/RPM esistente supera i valori predefiniti dovuti all'aumento del limite di velocità personalizzato precedente, il TPM equivalente è stato assegnato alle distribuzioni interessate.

Informazioni sui limiti di frequenza

L'assegnazione di TPM a una distribuzione imposta i limiti di frequenza dei token al minuto (TPM) e delle richieste al minuto (RPM) per la distribuzione, come descritto in precedenza. I limiti di frequenza TPM si basano sul numero massimo di token stimati per essere elaborati da una richiesta al momento della ricezione della stessa. Non è uguale al numero di token usato per la fatturazione, che viene calcolato dopo il completamento di tutte le elaborazioni.

Quando ogni richiesta viene ricevuta, Azure OpenAI calcola un numero massimo stimato di token elaborati che include quanto segue:

• Testo del prompt e conteggio
• Impostazione del parametro max_tokens
• Impostazione del parametro best_of

Quando le richieste arrivano all'endpoint di distribuzione, il conteggio massimo stimato di token elaborati viene aggiunto a un conteggio in esecuzione di tutti i token delle richieste, reimpostato ogni minuto. Se in qualsiasi momento durante quel minuto, viene raggiunto il valore limite di velocità TPM, altre richieste riceveranno un codice di risposta 429 fino a quando il contatore non viene reimpostato.

I limiti di velocità RPM si basano sul numero di richieste ricevute nel tempo. Il limite di velocità prevede che le richieste vengano distribuite uniformemente in un periodo di un minuto. Se questo flusso medio non viene mantenuto, le richieste potrebbero ricevere una risposta 429 anche se il limite non viene soddisfatto quando misurato nel corso di un minuto. Per implementare questo comportamento, Azure OpenAI valuta la frequenza delle richieste in ingresso in un breve periodo di tempo, in genere 1 o 10 secondi. Se il numero di richieste ricevute durante tale periodo supera quello previsto al limite RPM impostato, le nuove richieste ricevono un codice di risposta 429 fino al periodo di valutazione successivo. Ad esempio, se Azure OpenAI sta monitorando la frequenza delle richieste su intervalli di 1 secondo, la limitazione della frequenza si verifica per una distribuzione di 600 RPM se vengono ricevute più di 10 richieste durante ogni periodo di 1 secondo (600 richieste al minuto = 10 richieste al secondo).

Intestazioni di risposta di limitazione della frequenza

Azure OpenAI include informazioni sul limite di velocità nelle intestazioni di risposta HTTP di ogni chiamata API. Utilizzare queste intestazioni per monitorare l'utilizzo programmaticamente ed evitare in modo proattivo gli errori HTTP 429.

Procedure consigliate per il limite di velocità

Per ridurre al minimo i problemi relativi ai limiti di frequenza, usare le tecniche seguenti:

Ottimizzare le richieste

• Impostare max_tokens sul valore minimo che serve lo scenario. La stima del token del limite di frequenza include max_tokens, anche se la risposta effettiva è molto più breve. Ad esempio, se si prevedono risposte di circa 200 token, non impostare max_tokens su 4.000.
• Impostare best_of su 1 a meno che non siano necessari più completamenti specifici. Ogni incremento di best_of moltiplica il conteggio dei token rispetto al tuo limite di velocità.
• Ridurre le dimensioni del prompt , se possibile. Le richieste più brevi usano meno token per il limite di velocità.

Implementare la logica di retry con backoff esponenziale

Ripetere automaticamente le richieste quando si riceve una risposta 429. Usare il valore dell'intestazione retry-after-ms se presente; in caso contrario, usare il backoff esponenziale con jitter casuali:

1. Attendere un breve ritardo casuale dopo il primo errore.
2. Se il tentativo di nuovo fallisce, raddoppia il ritardo (backoff esponenziale).
3. Aggiungere un jitter casuale per impedire a tutti i client di riprovare nello stesso istante.
4. Impostare un numero massimo di tentativi (ad esempio 5-10) per evitare cicli infiniti.

Opzione 1: usare il tentativo integrato dell'SDK (più semplice - consigliato)

L'SDK Azure OpenAI Python (openai v1.0+) include tentativi automatici con backoff esponenziale per errori 429 e temporanei. Il valore predefinito è di due tentativi. È possibile 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"}]
)

Opzione 2: Riprova personalizzata con la tenacity libreria (avanzata)

Usare questa opzione quando è necessario un maggiore controllo sul comportamento di ripetizione dei tentativi, ad esempio la registrazione personalizzata, la gestione selettiva delle eccezioni, gli interruttori di circuito:

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

Opzione 3: Implementazione manuale (nessuna libreria di terze parti)

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)

Esempio 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);
});

Monitorare e gestire l'utilizzo a livello di distribuzione

• Controllare l'allocazione TPM per distribuzione, non solo la quota a livello di sottoscrizione. È possibile che sia stata approvata la quota a livello di sottoscrizione ma sia stato ricevuto un errore 429 perché la quota non è allocata alla distribuzione specifica che riceve traffico.
• Ribilanciare la quota tra le distribuzioni in base all'utilizzo osservato. Usare le metriche di Monitoraggio di Azure per esaminare le tendenze di utilizzo di 24 ore e sette giorni e rilevare modelli impulsivi.
• Usare la gestione delle quote nel portale Foundry per aumentare il TPM nelle distribuzioni a traffico elevato e ridurre il TPM nelle distribuzioni meno utilizzate.

Distribuire il traffico in modo uniforme

• Evitare picchi bruschi nel carico di lavoro. I limiti di velocità RPM prevedono che le richieste vengano distribuite uniformemente ogni minuto. Anche se le richieste totali sono inferiori al limite al minuto, un burst in una finestra di 1 secondo o 10 secondi può attivare un 429.
• Aumentare gradualmente il traffico durante l'introduzione di nuovi carichi di lavoro o l'incremento del carico.
• Distribuire le richieste tra più distribuzioni o regioni se il carico di lavoro richiede una velocità effettiva maggiore di quella che una singola distribuzione può supportare.

Usare l'elaborazione asincrona/batch laddove possibile

Se il caso d'uso non richiede risposte immediate, è consigliabile usare modelli asincroni:

• Eseguire l'accodamento delle richieste e processarle a un ritmo controllato.
• Usare più distribuzioni per parallelizzare l'elaborazione senza superare il limite di frequenza di una singola distribuzione.

Informazioni sugli errori di limitazione 429 e su cosa fare

Un errore 429 ("Troppe richieste") indica che il sistema ha rifiutato la richiesta perché è stato superato un limite di velocità o il sistema non è in grado di elaborare la richiesta in questo momento. Non tutti gli errori 429 hanno la stessa causa radice e l'azione corretta dipende dal motivo per cui si è verificato il 429.

Tipo di errore 429

Perché potresti vedere i codici 429 anche quando le metriche di utilizzo dei token sono inferiori alla quota

Azure limitazione della velocità di OpenAI e metriche di utilizzo non sono la stessa cosa:

• Metriche di utilizzo dei token in Monitoraggio di Azure visualizzano i token fatturati dalle richieste elaborate correttamente.
• La limitazione della frequenza si applica alle richieste API al momento della ricezione, incluse le richieste che vengono rifiutate o mai fatturate in seguito.

A causa di questa differenza, è possibile ottenere 429 risposte anche quando le metriche di utilizzo dei token hanno un aspetto ben inferiore alla quota. I motivi comuni includono:

• < c1> sovrastima: I limiti di velocità vengono calcolati usando il numero massimo stimato di token (con il prompt + ), ma non quelli realmente generati.
• Richieste rifiutate: le richieste rifiutate a causa dei limiti di lunghezza di input (HTTP 400) potrebbero comunque essere conteggiate per limitare la velocità, ma non verranno visualizzate nelle metriche dei token fatturate.
• Modelli di burst: l'applicazione RPM valuta le richieste in piccole finestre temporali (1-10 secondi). Un'ondata di richieste in una breve finestra temporale attiva la limitazione anche se il totale al minuto rientra nei limiti.
• Aggiustamento temporaneo del limite di richiesta per l'affidabilità del servizio: le implementazioni standard (pagamento a consumo) condividono un pool di risorse comune tra i clienti. Per mantenere affidabile e equo il servizio, il sistema monitora continuamente la domanda in questo pool condiviso. Quando la domanda di una distribuzione si avvicina o supera i limiti di capacità, il sistema potrebbe ridurre temporaneamente il limite effettivo di richiesta per quella distribuzione. Durante questo periodo di rettifica, le richieste che sarebbero state accettate in condizioni normali restituiscono 429 risposte, anche se la quota configurata non è cambiata. Questa misura protettiva impedisce il degrado del servizio per tutti i clienti che condividono il pool di risorse. La regolazione è temporanea e in genere risolve entro poche ore una volta stabilizzato il traffico. È possibile monitorare questa condizione controllando se il limite di velocità effettivo (visibile nelle x-ratelimit-limit-tokens intestazioni di risposta) è inferiore all'allocazione TPM configurata.
• Imposizione distribuita: l'imposizione del limite di velocità nell'infrastruttura distribuita potrebbe non essere perfettamente precisa o immediatamente riflessa nelle metriche aggregate.

Cosa fare affidamento su:

• Usare le metriche di utilizzo dei token per comprendere il consumo fatturato.
• Usare i codici di risposta HTTP (429) e le intestazioni di risposta (x-ratelimit-remaining-*, x-ratelimit-limit-*) per rilevare e rispondere all'imposizione del limite di velocità in tempo reale.
• Confrontare x-ratelimit-limit-tokens nelle intestazioni di risposta con il TPM configurato per rilevare se è attiva una regolazione temporanea.

Quando riprovare e quando eseguire l'escalation

Controllare a livello di programma la quota e la capacità

Oltre al portale Foundry, è possibile usare due API REST Azure Resource Manager per controllare a livello di codice il consumo di quota della sottoscrizione e la capacità del modello disponibile.

Scegliere l'API corretta

Usa l'API Usages quando hai bisogno di una vista contabile di ciò che hai consumato e di ciò che resta. Usare l'API Capacità modello quando si vuole sapere dove distribuire un modello e la quantità di capacità disponibile in ogni posizione.

API di utilizzo

L'API Usages restituisce ogni riga di quota per una determinata area, incluso il consumo corrente (currentValue) e il limite assegnato.

Richiesta:

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

Esempio: controllare l'utilizzo della quota negli Stati Uniti orientali:

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

Campi chiave:

API delle capacità del modello

L'API delle capacità del modello restituisce la capacità di distribuzione disponibile per un modello specifico in tutte le località e per tutti i tipi di distribuzione della tua sottoscrizione.

Richiesta:

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

Esempio: controllare dove è disponibile la capacità 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
      }
    }
  ]
}

Campi chiave:

Automatizzare la distribuzione

Per creare distribuzioni di Azure OpenAI a livello di codice e assegnare una quota di token al minuto (TPM) usando REST, interfaccia della riga di comando di Azure, Azure PowerShell, ARM, Bicep o Terraform, vedi Automatizzare le distribuzioni di Azure OpenAI con quota in Microsoft Foundry.

Eliminazione delle risorse

Quando si tenta di eliminare una risorsa di Azure OpenAI dal portale di Azure, se sono ancora presenti delle distribuzioni, l'eliminazione viene bloccata finché non vengono eliminate le distribuzioni associate. L'eliminazione delle distribuzioni consente innanzitutto di liberare correttamente le allocazioni delle quote in modo che possano essere usate nelle nuove distribuzioni.

Tuttavia, se si elimina una risorsa usando l'API REST o un altro metodo programmatico, questa operazione ignora innanzitutto la necessità di eliminare le distribuzioni. In questo caso, l'allocazione della quota associata rimarrà non disponibile per l'assegnazione a una nuova distribuzione per 48 ore fino a quando la risorsa non viene ripulita. Per attivare un'eliminazione immediata di una risorsa eliminata per liberare la quota, seguire le istruzioni per eliminare una risorsa eliminata.

Passaggi successivi

• Per esaminare le impostazioni predefinite delle quote per Azure OpenAI, vedere l'articolo quotas & limits