Verwalten des Azure OpenAI-Kontingents für Microsoft Foundry-Modelle (klassisch)

Zurzeit wird folgendes angezeigt:Foundry (klassische) Portalversion - Wechseln zur Version für das neue Foundry-Portal

Hinweis

Links in diesem Artikel können Inhalte in der neuen Microsoft Foundry-Dokumentation anstelle der jetzt angezeigten Foundry-Dokumentation (klassisch) öffnen.

Das Kontingent bietet die Flexibilität, die Zuordnung von Tarifgrenzwerten innerhalb der Bereitstellungen innerhalb Ihres Abonnements aktiv zu verwalten. In diesem Artikel wird der Prozess der Verwaltung Ihres Azure OpenAI-Kontingents erläutert.

Voraussetzungen

Wichtig

Für jede Aufgabe, die das Anzeigen des verfügbaren Kontingents erfordert, empfehlen wir, die Rolle Cognitive Services Usages Reader zu verwenden. Diese Rolle bietet den minimalen Zugriff, der erforderlich ist, um die Kontingentnutzung in einem Azure-Abonnement anzuzeigen. Weitere Informationen zu dieser Rolle und den anderen Rollen, die Sie für den Zugriff auf Azure OpenAI benötigen, finden Sie in unserem Azure rollenbasierten Zugriffssteuerungshandbuch.

Diese Rolle befindet sich im Azure Portal unter Abonnements>Zugangskontrolle (IAM)>Rollen zuweisen> suchen Sie nach Cognitive Services Usages Reader. Diese Rolle muss auf Abonnementebene angewendet werden, sie ist nicht auf Ressourcenebene vorhanden.

Wenn Sie diese Rolle nicht verwenden möchten, bietet die Abonnementlesefunktion einen gleichwertigen Zugriff, gewährt aber auch Lesezugriff, der über den Umfang hinausgeht, der für die Anzeige von Kontingenten und Modellbereitstellungen erforderlich ist.

Einführung in das Kontingent

Azure OpenAI-Kontingentfunktion ermöglicht die Zuweisung von Ratengrenzen für Ihre Bereitstellungen, bis zu einem globalen Limit, der als quota bezeichnet wird. Das Kontingent wird Ihrem Abonnement pro Region, pro Modell und pro Bereitstellungstyp in Einheiten von Token pro Minute (TPM) zugewiesen. Wenn Sie ein Abonnement für Azure OpenAI integrieren, erhalten Sie das Standardkontingent für die meisten verfügbaren Modelle. Anschließend weisen Sie jeder Bereitstellung TPM zu, während sie erstellt wird, und das verfügbare Kontingent für dieses Modell wird um diesen Betrag reduziert. Sie können weiterhin Bereitstellungen erstellen und ihnen TPM zuweisen, bis Sie Ihr Kontingentlimit erreicht haben. Sobald dies geschieht, können Sie nur neue Bereitstellungen dieses Modells erstellen, indem Sie das TPM reduzieren, das anderen Bereitstellungen desselben Modells zugewiesen ist (wodurch TPM zur Verwendung freigegeben wird), oder indem Sie eine Modellkontingenterhöhung in der gewünschten Region anfordern und genehmigt werden.

Hinweis

Mit einem Kontingent von 240.000 TPM für GPT-4o in der Region Ost-USA kann ein Kunde entweder eine einzelne Bereitstellung von 240 K TPM, zwei Bereitstellungen von jeweils 120 K TPM oder eine beliebige Anzahl von Bereitstellungen in einer oder mehreren Azure OpenAI-Ressourcen erstellen, solange ihre Gesamt-TPM in dieser Region 240 K nicht überschreiten.

Wenn eine Bereitstellung erstellt wird, ordnet das zugewiesene TPM direkt den Token-pro-Minute-Rate-Grenzwert zu, der für seine Ableitungsanforderungen erzwungen wird. Eine Anforderungs-Per-Minute (RPM) -Rate-Grenze wird ebenfalls erzwungen, deren Wert proportional zur TPM-Zuordnung mit dem folgenden Verhältnis festgelegt wird:

Wichtig

Das Verhältnis von Anforderungen pro Minute (RPM) zu Token pro Minute (TPM) für das Kontingent kann je nach Modell variieren. Wenn Sie ein Modell programmgesteuert bereitstellen oder eine Kontingenterhöhung anfordern , haben Sie keine präzise Kontrolle über TPM und RPM als unabhängige Werte. Das Kontingent wird in Bezug auf Kapazitätseinheiten zugeordnet, die entsprechende Mengen an RPM & TPM aufweisen:

Modell Kapazität Anforderungen pro Minute (RPM) Token pro Minute (TPM)
Ältere Chatmodelle 1 Einheit 6 U/MIN 1.000 TPM
o1 & o1-preview 1 Einheit 1 U/MIN 6 000 TPM
o3 1 Einheit 1 U/MIN 1.000 TPM
o4-mini 1 Einheit 1 U/MIN 1.000 TPM
o3-mini 1 Einheit 1 U/MIN 10.000 TPM
o1-mini 1 Einheit 1 U/MIN 10.000 TPM
o3-pro 1 Einheit 1 U/MIN 10.000 TPM

Dies ist besonders wichtig für die programmgesteuerte Modellbereitstellung, da Änderungen im RPM-/TPM-Verhältnis zu versehentlichen Fehlzuweisungen des Kontingents führen können.

Die Flexibilität, TPM global innerhalb eines Abonnements und einer Region zu verteilen, hat Azure OpenAI erlaubt, andere Einschränkungen zu lockern:

  • Die maximalen Ressourcen pro Region werden auf 30 erhöht.
  • Der Grenzwert für das Erstellen von nicht mehr als einer Bereitstellung desselben Modells in einer Ressource wurde entfernt.

Anfordern eines weiteren Kontingents

Übermitteln Sie das Anforderungsformular für Kontingenterhöhungen, um Kontingenterhöhungen für Foundry-Modelle, die direkt von Azure verkauft werden, Azure OpenAI-Modelle und Anthropic-Modelle anzufordern. Mit Ausnahme der Anthropic-Modelle unterstützen Modelle von Partnern und der Community keine Kontingenterhöhungen.

Kontingenterhöhungsanforderungen werden in der Reihenfolge verarbeitet, in der sie empfangen werden, und Priorität geht an Kunden, die ihre vorhandene Kontingentzuweisung aktiv verwenden. Anforderungen, die diese Bedingung nicht erfüllen, werden möglicherweise verweigert.

Modellspezifische Einstellungen

Verschiedene Modellbereitstellungen, auch als Modellklassen bezeichnet, weisen einzigartige maximale TPM-Werte auf, die Sie jetzt steuern können. Dies stellt die maximale Anzahl von TPM dar, die diesem Modellbereitstellungstyp in einer bestimmten Region zugeordnet werden kann.

Alle anderen Modellklassen weisen einen gemeinsamen maximalen TPM-Wert auf.

Hinweis

Kontingenttoken–Per-Minute (TPM)-Zuordnung ist nicht mit dem maximalen Eingabetokengrenzwert eines Modells verknüpft. Die Grenzwerte für Modelleingabetoken sind in der Modelltabelle definiert und wirken sich nicht auf Änderungen aus, die an TPM vorgenommen wurden.

Kontingent zuweisen

Wenn Sie eine Modellbereitstellung erstellen, haben Sie die Möglichkeit, Tokens-Per-Minute (TPM) dieser Bereitstellung zuzuweisen. TPM kann in Schritten von 1.000 geändert werden und entspricht den in Ihrer Bereitstellung erzwungenen TPM- und RPM-Rate-Grenzwerten, wie oben beschrieben.

Um eine neue Bereitstellung im Microsoft Foundry-Portal zu erstellen wählen Sie Deployments>Deploy model>Deploy base model>Select Model>Confirm.

Nach der Bereitstellung können Sie Ihre TPM-Zuordnung anpassen, indem Sie Ihr Modell auf der Seite "Bereitstellungen " im Foundry-Portal auswählen und bearbeiten. Sie können diese Einstellung auch auf der Seite Verwaltung>Modellkontingent ändern.

Wichtig

Kontingente und Grenzwerte können geändert werden. Für die aktuellsten Informationen konsultieren Sie unseren Artikel zu Quoten und Grenzwerten.

Anzeigen und Anfordern von Kontingenten

Wählen Sie für eine Gesamtansicht Ihrer Kontingentzuweisungen in > in einer bestimmten Region VerwaltungKontingent im Gießereiportal aus:

  • Bereitstellung: Modellbereitstellungen dividiert durch Modellklasse.
  • Kontingenttyp: Für jeden Modelltyp gibt es einen Kontingentwert pro Region. Das Kontingent deckt alle Versionen dieses Modells ab.
  • Kontingentzuweisung: Für den Kontingentnamen zeigt dies an, wie viel Kontingent von Bereitstellungen genutzt wird und welches Gesamtkontingent für dieses Abonnement und diese Region genehmigt ist. Diese Menge des verwendeten Kontingents wird auch im Balkendiagramm dargestellt.
  • Anforderungskontingent: Das Symbol navigiert zu diesem Formular , in dem Anforderungen zum Erhöhen des Kontingents übermittelt werden können.

Migrieren vorhandener Bereitstellungen

Im Rahmen des Übergangs zum neuen Kontingentsystem und der TPM-basierten Zuweisung wurden alle vorhandenen Azure OpenAI-Modellbereitstellungen automatisch migriert, um das Kontingent zu verwenden. In Fällen, in denen die vorhandene TPM/RPM-Zuweisung die Standardwerte aufgrund früherer Erhöhungen benutzerdefinierter Ratenbegrenzungen überschreitet, wurden den betroffenen Bereitstellungen äquivalente TPM zugewiesen.

Grundlegendes zu Geschwindigkeitsbeschränkungen

Durch die Zuweisung von TPM zu einer Bereitstellung werden die Grenzwerte für die Tokens-Per-Minute (TPM) und Anfragen-Per-Minute (RPM) für die Bereitstellung festgelegt, wie zuvor beschrieben. TPM-Ratenbegrenzungen basieren auf der geschätzten maximalen Anzahl von Token, die von einer Anfrage verarbeitet werden können, wenn diese empfangen wird. Es entspricht nicht der Tokenanzahl, die für die Abrechnung verwendet wird, die nach Abschluss der gesamten Verarbeitung berechnet wird.

Wenn jede Anforderung empfangen wird, berechnet Azure OpenAI eine geschätzte max. verarbeitete Tokenanzahl, die Folgendes enthält:

  • Eingabeaufforderungstext und Anzahl
  • Die Einstellung des Parameters "max_tokens"
  • Die Einstellung des best_of-Parameters

Wenn Anforderungen den Bereitstellungsendpunkt erreichen, wird die geschätzte Anzahl der maximal verarbeiteten Token zur laufenden Tokenanzahl aller Anforderungen hinzugefügt, die jede Minute zurückgesetzt wird. Wenn während dieser Minute der Grenzwert für die TPM-Rate erreicht ist, erhalten weitere Anforderungen einen Antwortcode von 429, bis der Zähler zurückgesetzt wird.

Wichtig

Die in der Berechnung des Zinslimits verwendete Tokenanzahl ist eine Schätzung, die teilweise auf der Zeichenanzahl der API-Anforderung basiert. Die Schätzung des Ratenlimittokens entspricht nicht der Tokenberechnung, die für die Abrechnung/Bestimmung verwendet wird, dass eine Anforderung unter dem Eingabetokenlimit eines Modells liegt. Aufgrund der ungefähren Art der Berechnung der Rate-Limit-Tokens ist es erwartetes Verhalten, dass ein Ratenlimit früher als bei einer exakten Tokenzählung für jede Anfrage ausgelöst werden kann.

Die Grenzwerte für die RPM basieren auf der Anzahl der Anforderungen, die über die Zeit empfangen werden. Die Ratenbegrenzung geht davon aus, dass die Anfragen gleichmäßig innerhalb eines Zeitraums von einer Minute verteilt werden. Wenn diese durchschnittliche Flussrate nicht aufrechterhalten wird, erhalten Anfragen möglicherweise eine 429-Antwort, obwohl das Limit nicht erreicht wird, wenn es über den Verlauf einer Minute gemessen wird. Um dieses Verhalten zu implementieren, wertet Azure OpenAI die Rate eingehender Anforderungen über einen kleinen Zeitraum aus, in der Regel 1 oder 10 Sekunden. Wenn die Anzahl der während dieses Zeitraums empfangenen Anforderungen überschreitet, was bei der festgelegten RPM-Grenze erwartet wird, erhalten neue Anforderungen bis zum nächsten Auswertungszeitraum einen Antwortcode von 429. Wenn z. B. Azure OpenAI die Anforderungsrate in 1-Sekunden-Intervallen überwacht, tritt die Ratebegrenzung für eine 600-RPM-Bereitstellung auf, wenn mehr als 10 Anforderungen während jedes 1-Sekunden-Zeitraums empfangen werden (600 Anforderungen pro Minute = 10 Anforderungen pro Sekunde).

Hinweis

Wenn Sie bereitgestellte Durchsatzeinheiten (PTU) verwenden, berechnet das System Die Ratelimits unterschiedlich. Ausführliche Informationen finden Sie im Abschnitt "Auslastungsbasierte Anforderungsauswertung" von "Was ist der bereitgestellte Durchsatz für Foundry Models?".

Antwortheader für Ratenbegrenzungen

Azure OpenAI enthält Informationen zum Ratelimit in den HTTP-Antwortheadern jedes API-Aufrufs. Verwenden Sie diese Header, um Ihre Verwendung programmgesteuert zu überwachen und proaktiv 429 Fehler zu vermeiden.

Kopfzeile Beispielwert Beschreibung
x-ratelimit-limit-requests 60 Maximale Anzahl von zulässigen Anfragen pro Minute für diese Bereitstellung.
x-ratelimit-limit-tokens 150000 Maximale Anzahl von Token, die pro Minute für diese Bereitstellung zulässig sind.
x-ratelimit-remaining-requests 59 Verbleibende Anfragen, bevor das Limit erreicht wird.
x-ratelimit-remaining-tokens 149984 Verbleibende Token, bevor sie das Ratelimit erreicht haben.
x-ratelimit-reset-requests 10 Zeit bis zum Zurücksetzen des anforderungsbasierten Ratelimits.
x-ratelimit-reset-tokens 300 Zeit bis zum Zurücksetzen des tokenbasierten Ratelimits.
retry-after-ms 2000 Enthalten in 429 Antworten. Die empfohlene Wartezeit (in Millisekunden) vor dem Wiederholen.

Tipp

überwachen x-ratelimit-remaining-requests und x-ratelimit-remaining-tokens in Ihrer Anwendung, um zu erkennen, wann Sie sich den Grenzen nähern und Anforderungen proaktiv drosseln, bevor Sie einen 429-Fehler erhalten.

Bewährte Methoden für Zinslimits

Verwenden Sie die folgenden Techniken, um Probleme im Zusammenhang mit Zinslimits zu minimieren:

Optimieren Ihrer Anforderungen

  • Legen Sie max_tokens den Minimalwert fest, der Ihrem Szenario entspricht. Die Schätzung des Rate-Limit-Tokens umfasst max_tokens, auch wenn Ihre tatsächliche Antwort viel kürzer ist. Wenn Sie beispielsweise Antworten von ca. 200 Token erwarten, setzen Sie max_tokens nicht auf 4.000.
  • Legen Sie best_of auf 1 fest, es sei denn, Sie benötigen mehrere Abschlüsse. Jedes Inkrement von best_of vervielfacht die Tokenanzahl in Bezug auf Ihr Ratenlimit.
  • Verringern Sie nach Möglichkeit die Größe der Eingabeaufforderung . Kürzere Eingabeaufforderungen verwenden weniger Token für Ihr Zinslimit.

Implementierung einer Wiederholungslogik mit exponentiellem Backoff

Wiederholen Sie Anfragen automatisch, wenn Sie eine 429-Antwort erhalten. Verwenden Sie den retry-after-ms-Headerwert, wenn vorhanden; ansonsten verwenden Sie ein exponentielles Backoff-Verfahren mit Zufallsjitter.

  1. Warten Sie nach dem ersten Fehler eine kurze, zufällig bestimmte Verzögerung.
  2. Wenn der Wiederholungsversuch fehlschlägt, verdoppeln Sie die Verzögerung (exponentielle Verzögerungserhöhung).
  3. Fügen Sie zufälligen Jitter hinzu, um zu verhindern, dass alle Clients sofort erneut versuchen.
  4. Legen Sie eine maximale Anzahl von Wiederholungen (z. B. 5 bis 10) fest, um endlose Schleifen zu vermeiden.

Wichtig

Erfolglose Anfragen werden dennoch auf Ihren Anfragerate-Grenzwert pro Minute angerechnet. Das fortlaufende erneute Senden einer Anforderung ohne Pause verschlimmert die Drosselung.

Option 1: Verwenden des integrierten Wiederholungsversuches des SDK (am einfachsten – empfohlen)

Das Azure OpenAI Python SDK (openai v1.0+) verfügt über eingebaute automatische Wiederholungsversuche mit exponentiellen Wartezeiten für 429 und temporäre Fehler. Der Standardwert ist zwei Versuche. Sie können dies erhöhen:

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

Hinweis

Das SDK berücksichtigt retry-after automatisch Header und verwendet exponentielle Backoffs mit Jitter. Für die meisten Anwendungen ist die Konfiguration max_retries auf dem Client ausreichend – Sie benötigen keine Wiederholungsbibliothek eines Drittanbieters.

Option 2: Benutzerdefinierter Wiederholungsversuch mit der tenacity Bibliothek (erweitert)

Verwenden Sie dies, wenn Sie mehr Kontrolle über das Wiederholungsverhalten benötigen (z. B. benutzerdefinierte Protokollierung, selektive Ausnahmebehandlung, Schaltschalter):

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

Wichtig

Wenn Sie eine benutzerdefinierte Wiederholungsbibliothek verwenden, legen Sie max_retries=0 im SDK-Client fest, um den integrierten Wiederholungsversuch zu deaktivieren. Andernfalls könnte jeder Versuch von Hartnäckigkeit selbst bis zu zwei zusätzliche SDK-Wiederholungen auslösen, was zu weitaus mehr Anforderungen als erwartet führen könnte.

Option 3: Manuelle Implementierung (keine Drittanbieterbibliothek)

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)

C#-Beispiel mit 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);
});

Hinweis

Die Azure SDK für .NET verfügt auch über integrierte Wiederholungsunterstützung. Beim Erstellen von AzureOpenAIClientOptions können Sie options.Retry.MaxRetries und options.Retry.Mode = RetryMode.Exponential konfigurieren, statt Polly zu verwenden. Verwenden Sie Polly, wenn Sie erweiterte Muster (Schaltkreisbrecher, Sperrköpfe usw.) benötigen.

Überwachen und Verwalten der Nutzung auf Bereitstellungsebene

  • Überprüfen Sie die TPM-Zuweisung pro Bereitstellung, nicht nur das Kontingent auf Abonnementebene. Möglicherweise haben Sie das Kontingent auf Abonnementebene genehmigt, aber 429s erreicht, da das Kontingent nicht dem spezifischen Bereitstellungsdatenverkehr zugeordnet ist.
  • Kontingent für alle Bereitstellungen basierend auf der beobachteten Verwendung neu ausbalancieren . Verwenden Sie Azure Monitor-Metriken, um 24-Stunden- und siebentägige Nutzungstrends zu überprüfen und auffällige Muster zu erkennen.
  • Verwenden Sie die Kontingentverwaltung im Foundry-Portal, um die Transaktionen pro Minute (TPM) bei Bereitstellungen mit hohem Datenverkehr zu erhöhen und TPM bei untergenutzten Bereitstellungen zu reduzieren.

Gleichmäßiges Verteilen des Datenverkehrs

  • Vermeiden Sie scharfe Spitzen bei der Arbeitsauslastung. RPM-Limits erwarten eine gleichmäßige Verteilung der Anforderungen über jede Minute. Auch wenn Ihre Gesamtanforderungen unter dem Grenzwert pro Minute liegen, kann ein Spitzenwert innerhalb eines 1-Sekunden- oder 10-Sekunden-Fensters einen HTTP-Statuscode 429 auslösen.
  • Erhöhen Sie den Traffic schrittweise bei der Integration neuer Workloads oder der Erhöhung der Last.
  • Verteilen Sie Anfragen über mehrere Bereitstellungen oder Regionen wenn Ihre Workload einen höheren Durchsatz erfordert, als eine einzelne Bereitstellung unterstützt.

Verwenden Sie nach Möglichkeit asynchrone/Batchverarbeitung

Wenn Ihr Anwendungsfall keine sofortigen Antworten erfordert, sollten Sie asynchrone Muster verwenden:

  • Anfragen in die Warteschlange stellen und in einer kontrollierten Geschwindigkeit verarbeiten.
  • Verwenden Sie mehrere Bereitstellungen, um die Verarbeitung zu parallelisieren, ohne die Häufigkeitsgrenze einer einzelnen Bereitstellung zu überschreiten.

Grundlegendes zu 429 Drosselungsfehlern und zur Vorgehensweise

Ein 429-Fehler ("Zu viele Anforderungen") bedeutet, dass das System Ihre Anforderung abgelehnt hat, da ein Satzlimit überschritten wurde oder das System Ihre Anforderung zu diesem Zeitpunkt nicht verarbeiten kann. Nicht alle 429 Fehler haben die gleiche Ursache, und die richtige Aktion hängt davon ab, warum die 429 aufgetreten ist.

Typen von 429 Fehlern

Szenario Fehlermeldungsindikator Ursache Empfohlene Aktion
Ratelimit überschritten Anfragen an ... "wurden begrenzt" oder "Ratenlimit überschritten" Ihre Anfragen haben die TPM- oder RPM-Ratenbegrenzung für das zugewiesene Kontingent Ihres Deployments überschritten. Erhöhen Sie die TPM-Zuweisung der Bereitstellung, gleichen Sie das Kontingent über die Bereitstellungen hinweg aus, oder fordern Sie eine Kontingenterhöhung an.
Systemkapazitätseinschränkung "Der Dienst kann Ihre Anforderung vorübergehend nicht verarbeiten" oder "Das System hat hohe Nachfrage" Die Back-End-Kapazität ist eingeschränkt. Diese Bedingung ist oft vorübergehend. Wiederholen Sie den Vorgang nach der retry-after-ms Verzögerung. Wenn das Problem weiterhin besteht, sollten Sie ein Upgrade auf den bereitgestellten Durchsatz (PTU), um die garantierte Kapazität sicherzustellen, in Betracht ziehen.
Anpassung des temporären Zinslimits 429 Antworten treten auf, aber Ihr konfiguriertes Kontingent wurde nicht geändert; x-ratelimit-limit-tokens in den Antwortkopfzeilen ist niedriger als das für Ihre Bereitstellung konfigurierte TPM. Standardbereitstellungen im Pay-as-you-go-Modell greifen auf denselben Ressourcenpool zu. Wenn der Bedarf die Kapazitätsgrenzen erreicht, reduziert das System automatisch vorübergehend die effektive Ratenbegrenzung Ihrer Bereitstellung, um die Zuverlässigkeit für alle Kunden aufrechtzuerhalten. Diese Reduzierung ist schutz- und vorübergehend. Wiederholen Sie den Vorgang mit retry-after-ms "Backoff". Die Anpassung wird in der Regel innerhalb weniger Stunden aufgelöst. Für Workloads, die einen konsistenten Durchsatz erfordern, sollten Sie den bereitgestellten Durchsatz (Provisioned Throughput, PTU) in Betracht ziehen.
Tokenbudget überschritten durch Anforderungsparameter Grenzwert erreicht, aber die Metriken zur Token-Nutzung erscheinen niedrig. Die Berechnung der Anfrageratenbegrenzung umfasst max_tokens und die Schätzung auf Grundlage des Prompts, nicht nur die abgerechneten Token. Eine Anforderung mit einem hohen max_tokens Wert kann das Rate-Limit-Budget selbst dann verbrauchen, wenn die tatsächliche Antwort gering ist. Verwenden Sie max_tokens, um die Größe Ihrer erwarteten Antwort anzupassen.

Wichtig

Viele Kunden interpretieren kapazitätsbezogene 429er als Quotenprobleme, was zu einer falschen Behebung führt (z. B. Kontingenterhöhungen anfordern, wenn das Problem lediglich vorübergehender Kapazitätsdruck ist). Überprüfen Sie immer die Fehlermeldungen und Antwortheader, um die Ursache zu identifizieren, bevor Sie eine Aktion ausführen.

Warum möglicherweise 429s angezeigt werden, auch wenn Tokenverwendungsmetriken unter dem Kontingent liegen

Azure OpenAI rate limiting and usage metrics sind nicht identisch:

  • Token-Nutzungsmetriken in Azure Monitor zeigen abgerechnete Token aus erfolgreich verarbeiteten Anforderungen.
  • Die Zinsbeschränkung gilt für API-Anforderungen zum Zeitpunkt des Empfanges, einschließlich Anforderungen, die später abgelehnt oder nie in Rechnung gestellt werden.

Aufgrund dieses Unterschieds können Sie 429 Antworten erhalten, auch wenn Ihre Token-Nutzungsmetriken deutlich unter dem Kontingent liegen. Häufige Gründe sind:

  • max_tokens Überschätzung: Zinslimits werden mithilfe der geschätzten maximalen Tokenanzahl (Prompt + max_tokens) und nicht mit den tatsächlich generierten Token berechnet.
  • Abgelehnte Anforderungen: Anforderungen, die aufgrund von Grenzwerten für die Eingabelänge (HTTP 400) abgelehnt wurden, zählen möglicherweise immer noch zur Begrenzung der Rate, werden aber nicht in den Tokenmetriken in Rechnung gestellt.
  • Burstmuster: Die RPM-Erzwingung wertet Anforderungen in kleinen Zeitfenstern (1 bis 10 Sekunden) aus. Ein Ansturm von Anfragen innerhalb eines kurzen Zeitfensters löst eine Drosselung aus, auch wenn die Gesamtanzahl pro Minute innerhalb der Grenzen liegt.
  • Anpassung des temporären Zinslimits für die Dienstzuverlässigkeit: Standardbereitstellungen (Pay-as-you-go) teilen einen gemeinsamen Ressourcenpool für alle Kunden. Um den Service zuverlässig und fair zu halten, überwacht das System kontinuierlich die Nachfrage in diesem gemeinsam genutzten Pool. Wenn die Nachfrage von einer Bereitstellung die Kapazitätsgrenzwerte annähert oder überschreitet, kann das System die effektive Rategrenze für diese Bereitstellung vorübergehend verringern. Während dieses Anpassungszeitraums geben Anforderungen, die unter normalen Bedingungen akzeptiert würden, 429 Antworten zurück , auch wenn Ihr konfiguriertes Kontingent nicht geändert wurde. Diese Schutzmaßnahme verhindert die Dienstbeeinträchtigung für alle Kunden, die den Ressourcenpool gemeinsam nutzen. Die Anpassung ist vorübergehend und wird in der Regel innerhalb weniger Stunden nach der Stabilisierung des Datenverkehrs aufgelöst. Sie können diese Bedingung überwachen, indem Sie überprüfen, ob Ihr effektives Ratelimit (sichtbar in x-ratelimit-limit-tokens Antwortheadern) niedriger als die konfigurierte TPM-Zuweisung ist.
  • Verteilte Erzwingung: Die Durchsetzung von Ratenlimits über verteilte Infrastruktur hinweg ist möglicherweise nicht perfekt präzise oder sofort in aggregierten Metriken widerzuspiegeln.

Tipp

Wenn während eines vorübergehenden Anpassungszeitraums für Zinslimits 429 Antworten angezeigt werden:

  1. Wiederholen Sie den Vorgang mit "Backoff" . Beachten Sie die retry-after-ms Kopfzeile. Die Anpassung ist vorübergehend und wird aufgelöst, wenn sich die Nachfrage stabilisiert.
  2. Verteilen von Datenverkehr – wenn möglich, verteilen Sie Anfragen über mehrere Bereitstellungen oder Regionen hinweg.
  3. Überprüfen Sie Ihr Verkehrsmuster – langanhaltende schwere Spitzen sind der häufigste Auslöser. Das schrittweise Steigern von Workloads verringert die Wahrscheinlichkeit von Änderungen.
  4. Erwägen Sie den bereitgestellten Durchsatz (PTU) – für Produktionsworkloads, die einen konsistenten Durchsatz ohne Streuung des freigegebenen Pools benötigen, bietet der bereitgestellte Durchsatz dedizierte Kapazität mit garantierten Ratengrenzwerten.

Worauf zu vertrauen ist:

  • Verwenden Sie Tokenverwendungsmetriken , um den abgerechneten Verbrauch zu verstehen.
  • Verwenden Sie HTTP-Antwortcodes (429) und Antwortheader (, x-ratelimit-remaining-*), um die Erzwingung von x-ratelimit-limit-* in Echtzeit zu erkennen und darauf zu reagieren.
  • Vergleichen Sie x-ratelimit-limit-tokens in Antwortheadern mit Ihrem konfigurierten TPM, um zu erkennen, ob eine temporäre Anpassung aktiv ist.

Wann erneut versucht werden soll und wann eskaliert werden muss

Situation Maßnahme
Gelegentliche 429s, die mit retry-after-ms Backoff aufgelöst werden Wiederholen : Dieses Verhalten ist normal und wird für freigegebene Bereitstellungen (Standard) erwartet.
429-Fehler während der Entwicklung oder des Testens Oft akzeptabel - 429s außerhalb der Produktion könnten absichtliche Kostenkontrollmaßnahmen sein.
Anhaltende 429 Produktionsmengen unter genehmigter Quote Eskalieren – Öffnen Sie eine Supportanfrage für technische Untersuchungen.
Zinslimiterhöhungen, die nicht in effektiven Grenzwerten widerspiegelt werden Eskalieren – Überprüfen Sie zuerst die Kontingentzuweisung auf Bereitstellungsebene, und eskalieren Sie dann, wenn das Problem weiterhin besteht.
Latenz-sensitive oder geschäftskritische Produktionsworkloads mit häufigen 429-Fehlermeldungen Upgrade – Erwägen Sie einen bereitgestellten Durchsatz (PTU) für garantierte Kapazität und Latenz-SLA.

Hinweis

Standardbereitstellungen (pay-as-you-go) verwenden einen freigegebenen Ressourcenpool. Die Drosselung schützt die allgemeine Dienstzuverlässigkeit für alle Benutzer. Gelegentliche vorübergehende 429-Fehler sind ein erwartetes Verhalten und kein Dienstfehler. Für Workloads, die vorhersehbare Latenz und garantierten Durchsatz erfordern, ist der bereitgestellte Durchsatz (PTU) der empfohlene Bereitstellungstyp.

Automatisieren der Bereitstellung

Dieser Abschnitt enthält kurze Beispielvorlagen, mit denen Sie mit dem programmgesteuerten Erstellen von Bereitstellungen beginnen können, die Kontingente zum Festlegen von TPM-Geschwindigkeitsgrenzwerten verwenden. Mit der Einführung des Kontingents müssen Sie die API-Version 2023-05-01 für aktivitäten im Zusammenhang mit der Ressourcenverwaltung verwenden. Diese API-Version dient nur zum Verwalten Ihrer Ressourcen und wirkt sich nicht auf die API-Version aus, die zum Ableiten von Aufrufen wie Abschluss, Chatabschluss, Einbettung, Bildgenerierung usw. verwendet wird.

Einsatz

PUT https://management.azure.com/subscriptions/{subscriptionId}/resourceGroups/{resourceGroupName}/providers/Microsoft.CognitiveServices/accounts/{accountName}/deployments/{deploymentName}?api-version=2023-05-01

Pfadparameter

Parameter Typ Erforderlich? Beschreibung
accountName Schnur Erforderlich Der Name Ihrer Azure OpenAI-Ressource.
deploymentName Schnur Erforderlich Der Bereitstellungsname, den Sie beim Bereitstellen eines vorhandenen Modells oder des Namens ausgewählt haben, den Sie für eine neue Modellbereitstellung verwenden möchten.
resourceGroupName Schnur Erforderlich Der Name der zugeordneten Ressourcengruppe für diese Modellbereitstellung.
subscriptionId Schnur Erforderlich Abonnement-ID für das zugeordnete Abonnement.
api-version Schnur Erforderlich Die API-Version, die für diesen Vorgang verwendet werden soll. Dies folgt dem Format YYYY-MM-DD.

Unterstützte Versionen

Anforderungstext

Dies ist nur eine Teilmenge der verfügbaren Anforderungstextparameter. Die vollständige Liste der Parameter finden Sie in der REST-API-Referenzdokumentation.

Parameter Typ Beschreibung
Sku Sku Die Definition des Ressourcenmodells, die die SKU repräsentiert.
Kapazität Ganzzahl Dies stellt die Menge des Kontingents dar, das Sie dieser Bereitstellung zuweisen. Der Wert 1 entspricht 1.000 Token pro Minute (TPM). Ein Wert von 10 entspricht 10k Token pro Minute (TPM).

Beispielanforderung

curl -X PUT https://management.azure.com/subscriptions/00000000-0000-0000-0000-000000000000/resourceGroups/resource-group-temp/providers/Microsoft.CognitiveServices/accounts/docs-openai-test-001/deployments/gpt-4o-test-deployment?api-version=2023-05-01 \
  -H "Content-Type: application/json" \
  -H 'Authorization: Bearer YOUR_AUTH_TOKEN' \
  -d '{"sku":{"name":"Standard","capacity":10},"properties": {"model": {"format": "OpenAI","name": "gpt-4o","version": "2024-11-20"}}}'

Hinweis

Es gibt mehrere Möglichkeiten zum Generieren eines Autorisierungstokens. Die einfachste Methode zum ersten Testen besteht darin, die Cloud Shell über das Azure-Portal zu starten. Führen Sie az account get-access-token dann aus. Sie können dieses Token als temporäres Autorisierungstoken für API-Tests verwenden.

Weitere Informationen finden Sie in der REST-API-Referenzdokumentation für Verwendungen und Bereitstellungen.

Verwendung

Um die Nutzung Ihres Kontingents in einer bestimmten Region für ein bestimmtes Abonnement abzufragen

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

Pfadparameter

Parameter Typ Erforderlich? Beschreibung
subscriptionId Schnur Erforderlich Abonnement-ID für das zugeordnete Abonnement.
location Schnur Erforderlich Ort zur Anzeige der Nutzung für z. B.: eastus
api-version Schnur Erforderlich Die API-Version, die für diesen Vorgang verwendet werden soll. Dies folgt dem Format YYYY-MM-DD.

Unterstützte Versionen

Beispielanforderung

curl -X GET https://management.azure.com/subscriptions/00000000-0000-0000-0000-000000000000/providers/Microsoft.CognitiveServices/locations/eastus/usages?api-version=2023-05-01 \
  -H "Content-Type: application/json" \
  -H 'Authorization: Bearer YOUR_AUTH_TOKEN'

Ressourcenlöschung

Wenn versucht wird, eine Azure OpenAI-Ressource über das Azure-Portal zu löschen und noch Bereitstellungen vorhanden sind, wird die Löschung blockiert, bis die zugehörigen Bereitstellungen gelöscht werden. Wenn Sie die Bereitstellungen zuerst löschen, können Kontingentzuweisungen ordnungsgemäß freigegeben werden, damit sie für neue Bereitstellungen verwendet werden können.

Wenn Sie jedoch eine Ressource mit der REST-API oder einer anderen programmgesteuerten Methode löschen, wird dadurch zuerst die Notwendigkeit umgangen, Bereitstellungen zu löschen. Wenn dies geschieht, bleibt das zugeordnete Kontingent 48 Stunden lang nicht verfügbar, um es einer neuen Bereitstellung zuzuweisen, bis die Ressource gelöscht wird. Wenn Sie eine sofortige Bereinigung für eine gelöschte Ressource auslösen möchten, um ein Kontingent freizugeben, folgen Sie der Bereinigung einer gelöschten Ressource.

Nächste Schritte

  • Informationen zum Überprüfen der Kontingentstandardeinstellungen für Azure OpenAI finden Sie im Artikel quotas & limits
  • Last updated on