Správa Azure OpenAI v kvótě Microsoft Foundry Models (classic)

Aktuálně zobrazeno:Verze portálu Foundry (klasická) - Přechod na verzi nového portálu Foundry

Poznámka

Odkazy v tomto článku můžou otevírat obsah v nové dokumentaci Microsoft Foundry místo dokumentace Foundry (classic), kterou si právě prohlížíte.

Kvóty poskytují flexibilitu při aktivní správě přidělování rychlostních limitů napříč různými nasazeními v rámci vašeho předplatného. Tento článek vás provede procesem správy Azure kvóty OpenAI.

Požadavky

Důležité

Pro všechny úlohy, které vyžadují zobrazení dostupné kvóty, doporučujeme použít roli Čtenář využití služeb Cognitive Services . Tato role poskytuje minimální přístup potřebný k zobrazení využití kvóty v rámci Azure předplatného. Další informace o této roli a dalších rolích, které potřebujete pro přístup k Azure OpenAI, najdete v našem průvodci řízením přístupu na základě rolí Azure průvodce řízením přístupu na základě role.

Tuto roli najdete na portálu Azure pod Subscriptions>Řízení přístupu (IAM)>Přidat přiřazení role> vyhledejte čtečka využití služeb Cognitive Services. Tato role se musí použít na úrovni předplatného, ale na úrovni prostředku neexistuje.

Pokud tuto roli nechcete používat, role Čtenář předplatného poskytuje ekvivalentní přístup, ale také uděluje přístup pro čtení nad rámec toho, co je potřeba pro zobrazení kvóty a nasazení modelu.

Úvod do kvót

Funkce kvóty Azure OpenAI umožňuje přiřazování omezení rychlosti pro vaše nasazení, až po globální limit označovaný jako quota. Kvóta se přiřadí k vašemu předplatnému v jednotlivých oblastech, podle modelu a typu nasazení v jednotkách tokenů za minutu (TPM). Když nasadíte předplatné Azure OpenAI, dostanete výchozí kvótu pro většinu dostupných modelů. Pak přiřadíte každému nasazení modul důvěryhodné platformy (TPM) během jeho vytvoření a dostupná kvóta pro tento model nasazení se sníží o dané množství. Můžete dál vytvářet nasazení a přiřazovat je TPM, dokud nedosáhnete limitu kvóty. Jakmile k tomu dojde, můžete vytvořit pouze nová nasazení tohoto modelu tím, že omezíte čip TPM přiřazený k jiným nasazením stejného modelu (čímž se čip TPM uvolní pro použití) nebo vyžádáním a schválením navýšení kvóty modelu v požadované oblasti.

Poznámka

S kvótou 240 000 TPM pro GPT-4o v oblasti východního USA může zákazník vytvořit jedno nasazení 240 tisíc TPM, dvě nasazení po 120 tisících TPM nebo libovolný počet nasazení v jednom nebo několika prostředcích Azure OpenAI, pokud jejich celkový počet TPM v dané oblasti nepřesáhne 240 tisíc.

Po vytvoření nasazení se přiřazený limit tokenů za minutu (TPM) přímo mapuje na omezení počtu tokenů za minutu, které je vynucováno u žádostí o inferenci. Vynucuje se také omezení rychlosti požadavků za minutu (RPM), jejíž hodnota je nastavena úměrně k úkolování TPM pomocí následujícího poměru:

Důležité

Poměr požadavků za minutu (RPM) a tokenů za minutu (TPM) pro kvótu se může lišit podle modelu. Pokud nasadíte model programově nebo požádáte o navýšení kvóty, nemáte podrobnou kontrolu nad čipem TPM a RPM jakožto nezávislými hodnotami. Kvóta se přiděluje z hlediska jednotek kapacity, které mají odpovídající množství RPM a TPM:

Model Kapacita Žádosti za minutu (RPM) Tokeny za minutu (TPM)
Starší modely chatu 1 Jednotka 6 ot/min 1 000 TPM
o1 & o1-preview 1 Jednotka 1 ot/min 6 000 TPM
o3 1 Jednotka 1 ot/min 1 000 TPM
o4-mini 1 Jednotka 1 ot/min 1 000 TPM
o3-mini 1 Jednotka 1 ot/min 10 000 TPM
o1-mini 1 Jednotka 1 ot/min 10 000 TPM
o3-pro 1 Jednotka 1 ot/min 10 000 TPM

To je zvlášť důležité pro programové nasazení modelu, protože změny v poměru RPM/TPM můžou vést k náhodnému chybnému umístění kvóty.

Flexibilita globální distribuce čipu TPM v rámci předplatného a oblasti umožňuje Azure OpenAI uvolnit další omezení:

  • Maximální počet prostředků na oblast se zvýší na 30.
  • Bylo odstraněno omezení, které bránilo vytvoření více než jednoho nasazení stejného modelu v jednom prostředku.

Žádost o další kvótu

Odešlete formulář žádosti o navýšení kvóty a požádejte o navýšení kvót pro modely Foundry prodávané společností Azure, modely Azure OpenAI a modely Anthropic. S výjimkou modelů Anthropic modely od partnerů a komunity nepodporují zvýšení kvóty.

Žádosti o navýšení kvóty se zpracovávají v pořadí, v jakém jsou přijaty, a priorita přechází na zákazníky, kteří aktivně používají jejich stávající přidělení kvóty. Žádosti, které nesplňují tuto podmínku, můžou být odepřeny.

Nastavení specifická pro model

Různá nasazení modelů, označovaná také jako třídy modelů, mají jedinečné maximální hodnoty TPM, které teď můžete řídit. Toto představuje maximální množství TPM, které lze přidělit danému typu nasazení modelu v dané oblasti.

Všechny ostatní třídy modelu mají společnou maximální hodnotu TPM.

Poznámka

Přidělení tokenů za minutu (TPM) není spojeno s maximálním limitem vstupních tokenů modelu. Omezení vstupního tokenu modelu jsou definována v tabulce modelů a nejsou ovlivněna změnami čipu TPM.

Přiřaďte kvótu

Při vytváření nasazení modelu máte možnost přiřadit tokeny za minutu (TPM) k danému nasazení. TPM lze upravovat v přírůstcích po 1 000 a odpovídá limitům rychlosti TPM a RPM, které jsou aplikovány na vaše nasazení, jak je uvedeno výše.

Pokud chcete vytvořit nové nasazení z portálu Microsoft Foundry portal, vyberte Nasazení>Nasadit model>Nasadit základní model>Vybrat model>Potvrdit.

Po nasazení můžete upravit nastavení přidělení TPM výběrem a úpravou modelu na stránce Nasazení v portálu Foundry. Toto nastavení můžete také upravit na stránce Správa>kvót modelu.

Důležité

Kvóty a limity se můžou změnit. Pro nejaktuálnější informace si přečtěte náš článek o kvótách a omezeních.

Zobrazení a vyžádání kvóty

Pokud chcete zobrazit všechna vaše přiřazení kvót napříč všemi nasazeními v dané oblasti, vyberte Správa>kvót na portálu Foundry:

  • Nasazení: Nasazení modelu rozdělená podle třídy modelu.
  • Typ kvóty: Pro každý typ modelu existuje jedna hodnota kvóty pro každou oblast. Kvóta zahrnuje všechny verze tohoto modelu.
  • Přidělení kvóty: U názvu kvóty se zobrazí, kolik kvót využívají nasazení, a celková kvóta schválená pro toto předplatné a oblast. Toto množství využité kvóty je znázorněno také v pruhovém grafu.
  • Kvóta žádosti: Ikona přejde na tento formulář , kde lze odeslat žádosti o navýšení kvóty.

Migrace existujících nasazení

V rámci přechodu na nový systém kvót a přidělování založené na TPM byla všechna existující nasazení modelů Azure OpenAI automaticky migrována k používání kvót. V případech, kdy stávající přidělení TPM/RPM překračuje výchozí hodnoty z důvodu předchozího zvýšení vlastního limitu rychlosti, byl ekvivalentní počet TPM přiřazen postiženým nasazením.

Principy limitů rychlosti

Přiřazení hodnoty TPM k nasazení nastaví limity pro Tokens-Per-Minute (TPM) a Requests-Per-Minute (RPM), jak je popsáno výše. Omezení rychlosti TPM jsou založená na maximálním počtu tokenů, které je požadavek schopen zpracovat v době, kdy je požadavek přijímán. Není to stejné jako počet tokenů použitých pro fakturaci, který se vypočítá po dokončení veškerého zpracování.

Při přijetí každého požadavku Azure OpenAI vypočítá odhadovaný maximální počet zpracovaných tokenů, který zahrnuje následující:

  • Výzva k zadání textu a počtu
  • Nastavení parametru max_tokens
  • Nastavení parametru best_of

Při vstupu požadavků do koncového bodu nasazení se odhadovaný maximální počet zpracovaných tokenů přidá do počtu spuštěných tokenů všech požadavků, které se resetují každou minutu. Pokud během této minuty dojde k dosažení hodnoty limitu rychlosti TPM, další požadavky obdrží kód odpovědi 429, dokud se čítač resetuje.

Důležité

Počet tokenů použitý při výpočtu limitu rychlosti je odhad založený na počtu znaků požadavku rozhraní API. Odhad počtu tokenů pro limit rychlosti není totéž jako výpočet tokenů, který se používá k fakturaci a určení, zda požadavek nepřesahuje vstupní limit tokenů modelu. Vzhledem k přibližné povaze výpočtu počtu tokenů pro limit rychlosti je běžné, že se limit rychlosti může spustit dříve než něco, co lze očekávat ve srovnání s přesným měřením počtu tokenů pro každý požadavek.

Limity rychlosti RPM jsou založeny na počtu přijatých požadavků v průběhu času. Limit rychlosti požadavků očekává, že požadavky budou rovnoměrně rozložené během jedné minuty. Pokud tento průměrný tok není zachován, můžou žádosti obdržet odpověď 429, i když se limit nedodrží při měření v průběhu minuty. K implementaci tohoto chování Azure OpenAI vyhodnocuje míru příchozích požadavků během malého časového období, obvykle 1 nebo 10 sekund. Pokud počet přijatých požadavků během této doby překročí to, co by se očekávalo při nastaveném limitu RPM, nové požadavky obdrží kód odpovědi 429 až do dalšího zkušebního období. Pokud například Azure OpenAI monitoruje frekvenci požadavků v 1sekundových intervalech, dojde k omezení rychlosti pro nasazení o 600 RPM, pokud se během každého 1sekundového období přijímá více než 10 požadavků (600 požadavků za minutu = 10 požadavků za sekundu).

Poznámka

Pokud používáte zřízené jednotky propustnosti (PTU), systém vypočítá omezení rychlosti odlišně. Podrobnosti najdete v části Vyhodnocení požadavků na základě využití v části Co je zřízená propustnost pro modely Foundry?.

Hlavičky odpovědi omezení rychlosti

Azure OpenAI obsahuje informace o limitu rychlosti v hlavičce odpovědi HTTP každého volání rozhraní API. Pomocí těchto hlaviček můžete programově monitorovat využití a aktivně se vyhnout chybám 429.

Záhlaví Příklad hodnoty Popis
x-ratelimit-limit-requests 60 Maximální počet požadavků povolených za minutu pro toto nasazení
x-ratelimit-limit-tokens 150000 Maximální počet tokenů povolených za minutu pro toto nasazení
x-ratelimit-remaining-requests 59 Zbývající požadavky před dosažením limitu rychlosti
x-ratelimit-remaining-tokens 149984 Zbývající tokeny před dosažením limitu rychlosti
x-ratelimit-reset-requests 10 Doba, než se limit rychlosti na základě požadavků resetuje.
x-ratelimit-reset-tokens 300 Doba, než se limit rychlosti na základě tokenu resetuje.
retry-after-ms 2000 Zahrnuto v 429 odpovědích. Doporučená doba čekání (v milisekundách) před opakováním.

Tip

Monitorujte x-ratelimit-remaining-requests a x-ratelimit-remaining-tokens ve vaší aplikaci, abyste zjistili, kdy se blížíte k limitům, a aktivně omezovali požadavky, než obdržíte kód 429.

Osvědčené postupy pro omezení rychlosti

Pokud chcete minimalizovat problémy související s limity rychlosti, použijte následující techniky:

Optimalizace požadavků

  • Nastavte max_tokens minimální hodnotu, která slouží vašemu scénáři. Odhad tokenu limitu rychlosti zahrnuje max_tokensi v případě, že je vaše skutečná odpověď mnohem kratší. Pokud například očekáváte odpovědi o délce přibližně 200 tokenů, nenastavujte max_tokens hodnotu na 4 000.
  • Pokud nepotřebujete více dokončení, nastavte best_of na hodnotu 1. Každý přírůstek best_of vynásobí počet tokenů oproti limitu rychlosti.
  • Pokud je to možné, zmenšete velikost výzvy. Kratší výzvy používají k dosažení limitu rychlosti méně tokenů.

Implementace logiky opakování s exponenciálním zpožděním

Automaticky zopakujte žádosti, když obdržíte odpověď 429. Pokud je k dispozici, použijte hodnotu hlavičky retry-after-ms. V opačném případě použijte exponenciální zpoždění s náhodnými výkyvy.

  1. Počkejte krátkou náhodnou prodlevu po prvním selhání.
  2. Pokud se opakování nezdaří, zdvojnásobte zpoždění (exponenciální zpomalování).
  3. Přidejte náhodné zpoždění, aby se všichni klienti nepokoušeli znovu připojit ve stejnou chvíli.
  4. Nastavte maximální počet opakování (například 5–10), abyste se vyhnuli nekonečným smyčkám.

Důležité

Neúspěšné žádosti se stále započítávají do limitu přenosové rychlosti za minutu. Neustálé opětovné odesílání žádosti bez omezení způsobí zhoršení omezení.

Možnost 1: Použití integrovaného opakování sady SDK (nejjednodušší – doporučeno)

Sada Azure OpenAI Python SDK (openai v1.0+) má vestavěné automatické opakování s exponenciálním zpožděním pro chyby 429 a přechodné chyby. Výchozí hodnota je dvě opakování. Můžete ho zvýšit:

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

Poznámka

SDK automaticky respektuje retry-after hlavičky a používá exponenciální zpoždění s jitterem. U většiny aplikací stačí nakonfigurovat max_retries na straně klienta – nepotřebujete knihovnu pro opakování pokusů třetí strany.

Možnost 2: Vlastní opakování s knihovnou tenacity (pokročilé)

Tuto možnost použijte, když potřebujete větší kontrolu nad chováním opakování (například vlastní protokolování, selektivní zpracování výjimek, obvodové jističe):

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

Důležité

Pokud používáte vlastní knihovnu pro opětovné pokusy, nastavte max_retries=0 na klientovi sady SDK, aby bylo jeho vestavěné opakování vypnuto. V opačném případě může každý pokus z vytrvalosti sám o sobě spustit až dva další pokusy ze sady SDK, což vede k mnohem většímu počtu požadavků, než se očekávalo.

Možnost 3: Ruční implementace (bez knihovny třetích stran)

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)

Příklad jazyka C# pomocí 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);
});

Poznámka

Azure SDK pro .NET má také integrovanou podporu opakování. Při vytváření AzureOpenAIClientOptionsmůžete nakonfigurovat options.Retry.MaxRetries a options.Retry.Mode = RetryMode.Exponential namísto použití Polly. Polly použijte, když potřebujete pokročilejší vzory (jističe, přepážky atd.).

Monitorování a správa využití na úrovni nasazení

  • Zkontrolujte přidělení TPM na úrovni jednotlivých nasazení, nejen kvótu na úrovni předplatného. Možná jste kvótu schválili na úrovni předplatného, ale můžete narazit na chyby 429, protože kvóta není přidělená konkrétnímu nasazení, které přijímá provoz.
  • Přerozdělení kvóty mezi nasazeními na základě pozorovaného využití. Pomocí metrik Azure Monitor můžete zkontrolovat trendy využití za posledních 24 hodin a sedm dní a zjišťovat výkyvy.
  • Pomocí správy kvót na portálu Foundry zvyšte TPM u nasazení s vysokým provozem a snižte TPM na nevyužitých.

Rovnoměrné distribuce provozu

  • Vyhněte se ostrým špičkám v pracovní zátěži. Omezení rychlosti RPM vyžadují, aby byly požadavky rovnoměrně rozloženy po každou minutu. I když jsou vaše celkové požadavky pod limitem za minutu, může nárazové zvýšení během 1sekundového nebo 10sekundového intervalu aktivovat kód 429.
  • Postupné navyšování provozu při nasazování nových úloh nebo zvyšování zatížení.
  • Pokud vaše úloha vyžaduje vyšší propustnost, než podporuje jedno nasazení, rozložte požadavky napříč několika nasazeními nebo oblastmi.

Pokud je to možné, použijte asynchronní a dávkové zpracování.

Pokud váš případ použití nevyžaduje okamžité odpovědi, zvažte použití asynchronních vzorů:

  • Řaďte požadavky do fronty a zpracovávejte je řízenou rychlostí.
  • Použití více nasazení k paralelizaci zpracování bez překročení limitu rychlosti jednoho nasazení.

Pochopení chyb omezování 429 a co dělat

Chyba 429 (Příliš mnoho požadavků) znamená, že systém odmítl vaši žádost, protože došlo k překročení limitu rychlosti nebo systém nemůže vaši žádost zpracovat v tuto chvíli. Ne všechny chyby 429 mají stejnou původní příčinu a správná akce závisí na tom, proč došlo k chybě 429.

Typy chyb 429

Scénář Indikátor chybové zprávy Základní příčina Doporučená akce
Překročení limitu rychlosti "Žádosti o ... byly omezené" nebo "Překročení limitu rychlosti" Vaše požadavky překročily limit rychlosti TPM nebo RPM pro přidělenou kvótu vašeho nasazení. Zvyšte přidělení TPM pro nasazení, přebalancujte kvótu mezi nasazeními nebo požádejte o navýšení kvóty.
Omezování kapacity systému "Služba dočasně nemůže zpracovat vaši žádost" nebo "Systém má vysokou poptávku" Kapacita back-endu je omezená. Tato podmínka je často přechodná. Zkuste to znovu po retry-after-ms zpoždění. Pokud je trvalá, zvažte upgrade na zřízenou propustnost (PTU) pro zaručenou kapacitu.
Dočasná úprava limitu rychlosti Došlo k 429 odpovědím, ale nakonfigurovaná kvóta se nezměnila; x-ratelimit-limit-tokens v hlavičkách odpovědi je nižší než nakonfigurované TPM vašeho nasazení. Nasazení úrovně Standard (průběžné) sdílejí společný fond zdrojů. Když poptávka přistupuje k limitům kapacity, systém dočasně sníží efektivní limit rychlosti vašeho nasazení, aby se zachovala spolehlivost pro všechny zákazníky. Toto snížení je ochranné a dočasné. Zkuste to znovu s backoffem retry-after-ms . Úprava se obvykle vyřeší během několika hodin. U úloh vyžadujících konzistentní propustnost zvažte zřízenou propustnost (PTU).
Rozpočet tokenů překročený parametry požadavku Aktivované omezení rychlosti, ale metriky využití tokenů se zobrazují jako nízké Výpočet omezení rychlosti zahrnuje max_tokens a odhad podnětu, nejen fakturované tokeny. Požadavek s vysokou max_tokens hodnotou může, i když je skutečná odpověď malá, spotřebovávat rozpočet pro limit rychlosti. Zmenšete max_tokens tak, aby odpovídala očekávané velikosti odpovědi.

Důležité

Řada zákazníků chybně interpretuje chybový kód 429 související s kapacitou jako problémy s přidělenými kvótami, což vede k nesprávným opatřením (například při žádosti o navýšení kvóty při přechodném tlaku na kapacitu). Před provedením akce vždy zkontrolujte chybovou zprávu a hlavičky odpovědi a určete původní příčinu.

Proč se může zobrazit 429, i když jsou metriky využití tokenů nižší než kvóta

Azure OpenAI omezení rychlosti a metriky použití nejsou stejné.

  • Metriky používání tokenů v Azure Monitor ukazují zpoplatněné tokeny z úspěšně zpracovaných požadavků.
  • Omezení rychlosti se vztahuje na požadavky rozhraní API v době jejich přijetí, včetně žádostí, které se později zamítnou nebo se nikdy neúčtují.

Z tohoto rozdílu můžete získat 429 odpovědí, i když metriky využití tokenů vypadají dobře pod kvótou. Mezi běžné důvody patří:

  • max_tokens overestimation: Limity rychlosti se počítají pomocí odhadovaného maximálního počtu tokenů (prompt + max_tokens), nikoli generovaných skutečných tokenů.
  • Odmítnuté požadavky: Žádosti odmítnuté kvůli limitům délky vstupu (HTTP 400) se můžou stále počítat do omezování rychlosti, ale nezobrazí se v fakturovaných metrikách tokenů.
  • Vzory přetížení: RPM pravidla vyhodnocují požadavky v malých časových oknech (1–10 sekund). Nárůst požadavků v krátkém okně aktivuje omezování, i když je celková hodnota za minutu v mezích limitů.
  • Dočasná úprava omezení rychlosti pro spolehlivost služeb: Standardní nasazení (model průběžných plateb) sdílejí společný zásobník zdrojů mezi zákazníky. Aby byl servis spolehlivý a spravedlivý, systém nepřetržitě monitoruje poptávku v rámci tohoto sdíleného fondu. Když poptávka od nasazení dosáhne nebo překročí limity kapacity, může systém dočasně snížit efektivní limit rychlosti pro dané nasazení. Během tohoto období úpravy se žádosti, které by za normálních podmínek byly přijaty, vrací odpovědi typu 429 – i když se nakonfigurovaná kvóta nezměnila. Toto ochranné opatření brání snížení služeb pro všechny zákazníky sdílející fond zdrojů. Úprava je dočasná a obvykle se vyřeší během několika hodin po stabilizaci provozu. Tuto podmínku můžete monitorovat tak, že zkontrolujete, jestli je váš efektivní limit rychlosti (viditelný v x-ratelimit-limit-tokens hlavičce odpovědi) nižší než nakonfigurované přidělení čipu TPM.
  • Distribuované vynucování: Vymáhání limitu rychlosti napříč distribuovanou infrastrukturou nemusí být zcela přesné nebo se nemusí okamžitě projevit v agregovaných metrikách.

Tip

Pokud se během dočasného období úpravy limitu rychlosti zobrazí 429 odpovědí:

  1. Zkuste to znovu s backoffem – respektujte hlavičku retry-after-ms . Úprava je dočasná a vyřeší se, jak se poptávka stabilizuje.
  2. Rozprostřete provoz – pokud je to možné, distribuujte požadavky napříč několika nasazeními nebo oblastmi.
  3. Zkontrolujte své dopravní vzory – trvalé silné výkyvy jsou nejčastějším spouštěčem. Postupné zužování úloh snižuje pravděpodobnost úprav.
  4. Zvažte zřízenou propustnost (PTU) – pro produkční úlohy, které potřebují konzistentní propustnost bez proměnlivosti sdílených fondů, poskytuje zřízená propustnost vyhrazenou kapacitu s garantovanými limity rychlosti.

Na co se spoléhat:

  • K pochopení fakturované spotřeby použijte metriky využití tokenů .
  • Pomocí kódů odpovědí HTTP (429) a hlaviček odpovědí (x-ratelimit-remaining-*, x-ratelimit-limit-*) můžete zjistit a reagovat na vynucení omezení rychlosti v reálném čase.
  • Porovnejte x-ratelimit-limit-tokens v hlavičkách odpovědí s nakonfigurovaným TPM modulem, abyste zjistili, jestli je aktivní dočasná úprava.

Kdy opakovat vs. kdy eskalovat

Situaci Akce
Občasné chyby 429, které se vyřeší s opotřebováním retry-after-ms Opakování – toto chování je normální a očekáváno pro sdílená nasazení (Standard).
Chyba 429 během vývoje nebo testování Často přijatelné – chybové kódy 429 v neprodukčním prostředí mohou být úmyslná omezení nákladů.
Trvalo 429 v produkčním prostředí, pod schválenou kvótou Eskalace – otevření žádosti o podporu pro technické šetření
Zvýšení limitu rychlosti se neprojeví v efektivních limitech Eskalujte – nejprve ověřte přidělení kvóty na úrovni nasazení a pak eskalujte, pokud problém přetrvává.
Úlohy citlivé na latenci nebo kritické produkční úlohy, u kterých dochází k častému 429 Upgrade – zvažte zřízenou propustnost (PTU) pro garantovanou kapacitu a úroveň zpoždění SLA.

Poznámka

Standardní nasazení (průběžné platby) používají sdílený fond zdrojů. Omezování chrání celkovou spolehlivost služeb pro všechny uživatele. Občasné přechodné 429 kódy jsou považovány za očekávané chování, nikoli za chybu služby. U úloh, které vyžadují předvídatelnou latenci a zaručenou propustnost, je doporučeným typem nasazení zřízená propustnost (PTU).

Programová kontrola kvóty a kapacity

Kromě portálu Foundry můžete pomocí dvou rozhraní REST API Azure Resource Manager programově zkontrolovat využití kvóty předplatného a dostupnou kapacitu modelu.

Volba správného rozhraní API

API využití API kapacit modelů
Otázka, na kterou odpovídá Kolik kvóty jsem spotřeboval(a) vs. můj limit? Kolik nasaditelné kapacity je k dispozici pro konkrétní model?
Scope Předplatné + poloha Předplatné (všechny lokality najednou)
Vstup Pouze umístění Název, verze a formát modelu
Vrácení Každý řádek kvóty v této oblasti – aktuální využití a limit Dostupná kapacita na umístění a typ nasazení pro jeden model
Typický případ použití Monitorování spotřeby, aktivace upozornění při přístupu k limitům Předběžná kontrola kapacity před vytvořením nebo škálováním nasazení
Referenční materiály k rozhraní API Využití – seznam Kapacity modelu – seznam

Rozhraní API usages použijte, když potřebujete zobrazení registru o tom, co jste spotřebovali a co zbývá. Rozhraní API kapacit modelů použijte, když chcete zjistit, kde můžete model nasadit a kolik kapacity je dostupné v jednotlivých umístěních.

Poznámka

Obě rozhraní API vrací informace pro všechny modely přidružené k vašemu předplatnému, včetně vyřazených modelů , které už nejsou k dispozici pro nová nasazení.

API využití

Rozhraní API Usages vrací všechny řádky kvót pro daný region, včetně vašeho aktuálního čerpání (currentValue) a přiřazeného limitu.

Žádost:

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

Příklad – kontrola využití kvóty v oblasti USA – východ:

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

Klíčová pole:

Obor Popis
name.value Název kvóty ve formátu {Provider}.{DeploymentType}.{Model}
name.localizedValue Popis včetně jednotky ve formátu čitelném pro člověka
currentValue Kolik z této kvóty aktuálně využívají nasazení
limit Limit kvóty vašeho předplatného pro tento model a typ nasazení

API kapacit modelů

Rozhraní API Model Capacities vrací dostupnou kapacitu nasazení pro konkrétní model ve všech umístěních a typech nasazení ve vašem předplatném.

Žádost:

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

Příklad – kontrola dostupnosti kapacity 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")

Klíčová pole:

Obor Popis
location oblast Azure
properties.skuName Typ nasazení (Standard, GlobalStandard, DataZoneStandard, ProvisionedManaged atd.)
properties.availableCapacity Jednotky kapacity dostupné v rámci vašeho předplatného pro tento model, lokalitu a typ nasazení
properties.availableFinetuneCapacity K dispozici je kapacita pro jemné doladění (pokud je to relevantní)

Automatizace nasazení

Pokud chcete programově vytvořit nasazení služby Azure OpenAI a přiřadit kvótu počtu tokenů za minutu (TPM) pomocí rozhraní REST, Azure CLI, Azure PowerShell, ARM, Bicep nebo Terraform, přečtěte si článek Automatizace nasazení služby Azure OpenAI s kvótou v Microsoft Foundry.

Odstranění prostředku

Při pokusu o odstranění prostředku Azure OpenAI z portálu Azure, pokud jsou stále přítomna nějaká nasazení, se odstranění zablokuje, dokud nebudou přidružená nasazení odstraněna. Odstranění nasazení jako první umožňuje správné uvolnění přidělených kvót a umožní jejich použití v nových nasazeních.

Pokud však odstraníte prostředek pomocí rozhraní REST API nebo jiné programové metody, obejde se potřeba nejprve odstranit nasazení. Pokud k tomu dojde, přidružené přidělení kvóty zůstane nedostupné pro přiřazení k novému nasazení po dobu 48 hodin, dokud se prostředek nevyprázdní. Pokud chcete aktivovat okamžité vymazání odstraněného prostředku, aby se uvolnila kvóta, postupujte podle pokynů k vyprázdnění odstraněného prostředku.

Další kroky

  • Pokud chcete zkontrolovat výchozí kvóty pro Azure OpenAI, projděte si článek quotas a omezení
  • Last updated on