Azure OpenAI kezelése a Microsoft Foundry Models kvótájában (klasszikus)

Jelenleg megtekintés:Foundry (klasszikus) portálverzió - Váltás az új Foundry portál verziójára

Megjegyzés

A cikkben szereplő hivatkozások megnyithatják a tartalmat az új Microsoft Foundry-dokumentációban a most megtekintett Foundry (klasszikus) dokumentáció helyett.

A kvóta lehetővé teszi, hogy aktívan kezelje a forgalmi korlátok kiosztását az előfizetésen belüli implementációk között. Ez a cikk végigvezeti a Azure OpenAI-kvóta kezelésének folyamatán.

Előfeltételek

Fontos

Az elérhető kvóta megtekintését igénylő feladatokhoz használja a Cognitive Services Használati adatok olvasó szerepkörét . Ez a szerepkör minimális hozzáférést biztosít a kvótahasználat megtekintéséhez egy Azure-előfizetésben. További információ: Hozzáférési kvóta és használati adatok.

A Azure portálon nyissa meg az Előfizetések>hozzáférés-vezérlése (IAM)>Szerepkör-hozzárendelés hozzáadása lehetőséget, és keresse meg a Cognitive Services Használati adatok olvasóját. Rendelje hozzá a szerepkört az előfizetés hatóköréhez. Egy erőforráscsoport vagy erőforrásszintű hozzárendelés nem engedélyezi az előfizetés hatókörű Használati API-hoz való hozzáférést.

Az előfizetés-olvasó szerepkör hozzáférést is biztosít, de olvasási hozzáférést biztosít a kvóta- és modelltelepítések megtekintéséhez szükségesen túl.

Bevezetés a kvóta használatába

Azure OpenAI kvótafunkciója lehetővé teszi a sebességkorlátok hozzárendelését az üzemelő példányokhoz, egészen a kvóta nevű globális korlátig. A kvóta régiónkénti, modellenkénti, üzembehelyezési típusú alapon van hozzárendelve az előfizetéshez a Tokens-per-Minute (TPM) egységekben. Amikor regisztrál az Azure OpenAI-előfizetéshez, a legtöbb elérhető modell számára alapértelmezett kvótát kap. Ezután minden egyes üzembe helyezéshez hozzárendeli a TPM-et a létrehozás pillanatában, és az adott modellre rendelkezésre álló kvótát ennyivel csökkenti. Továbbra is létrehozhat üzembe helyezéseket, és hozzárendelheti azokat a TPM-hez, amíg el nem éri a kvótakorlátot. Ha ez megtörténik, a modell új üzembe helyezését csak úgy hozhatja létre, ha csökkenti az ugyanazon modell más üzemelő példányaihoz rendelt TPM-et (így felszabadítja a TPM-et használat céljából), vagy a kívánt régióban a modellkvóta növelésének kérelmezésével és jóváhagyásával.

Megjegyzés

Az USA keleti régiójában a GPT-4o esetében 240 000 TPM-es kvótával az ügyfelek egyetlen, 240 K TPM-es üzembe helyezést, egyenként 2 120 K TPM-es üzembe helyezést, vagy egy vagy több Azure OpenAI-erőforráson belüli üzembe helyezést hozhatnak létre, feltéve, hogy a TPM-jük összesen kevesebb mint 240 K-t ad hozzá az adott régióban.

Az üzembe helyezés létrehozásakor a hozzárendelt TPM közvetlenül összefüggésben áll a következtetésekre vonatkozó, percenkénti átviteli korláttal. A kérések –Per-Minute (RPM) sebességkorlát is érvényesítve van, amelynek értéke a TPM-hozzárendeléssel arányosan van beállítva a következő arány használatával:

Fontos

A percenkénti kérelmek (RPM) és a percenkénti tokenek (TPM) aránya modellenként változhat. Amikor programozott módon helyez üzembe egy modellt, vagy kvótanövelést kér , nincs részletes vezérlése a TPM és az RPM felett független értékekként. A kvóta kapacitásegységekben van lefoglalva, amelyek megfelelő mennyiségű RPM > TPM-et tartalmaznak:

Modell Kapacitás Kérések percenként (RPM) Tokenek percenként (TPM)
Régebbi csevegési modellek 1 egység 6 fordulat/perc 1 000 TPM
o1 &o1-preview 1 egység 1 fordulat/perc 6 000 TPM
o3 1 egység 1 fordulat/perc 1 000 TPM
o4-mini 1 egység 1 fordulat/perc 1 000 TPM
o3-mini 1 egység 1 fordulat/perc 10 000 TPM
o1-mini 1 egység 1 fordulat/perc 10 000 TPM
o3-pro 1 egység 1 fordulat/perc 10 000 TPM

Ez különösen fontos a programozott modellek üzembe helyezése szempontjából, mivel az RPM/TPM arány változása a kvóta véletlen helytelen áthelyezését eredményezheti.

A TPM globális elosztásának rugalmassága egy előfizetésen és régión belül lehetővé tette Azure OpenAI számára, hogy enyhítse az egyéb korlátozásokat:

  • A régiónkénti erőforrások maximális száma 30-ra nő.
  • Az erőforrásban lévő ugyanazon modell egynél több üzembe helyezésének létrehozására vonatkozó korlát el lett távolítva.

További kvóta kérése

Nyújtsa be a kvótanövelési kéreleműrlapot a Azure által értékesített Foundry-modellek, az Azure OpenAI-modellek és az Anthropic modellek kvótanövelésének igényléséhez. A Anthropic modellek kivételével a partnerek és a közösség modelljei nem támogatják a kvótanövelést.

A kvótanövelési kérelmek feldolgozása a beérkezésük sorrendjében történik, és a prioritás azoknak az ügyfeleknek szól, akik aktívan használják a meglévő kvótafoglalásukat. A feltételnek nem megfelelő kérések megtagadhatók.

Modellspecifikus beállítások

A különböző modelltelepítések, más néven modellosztályok egyedi maximális TPM-értékekkel rendelkeznek, amelyeket most már szabályozhat. Ez az adott régióban az adott modelltelepítéshez lefoglalható maximális TPM-mennyiséget jelenti.

Minden más modellosztály közös maximális TPM-értékkel rendelkezik.

Megjegyzés

Kvóta Tokens-Per-Minute (TPM) kiosztása nem kapcsolódik a modell maximális bemeneti tokenkorlátjához. A modell bemeneti jogkivonatának korlátai a modelltáblában vannak meghatározva, és nem érintik a TPM módosításai.

Kvóta hozzárendelése

Modelltelepítés létrehozásakor lehetősége van Tokens-Per-Minute (TPM) értéket rendelni az adott telepítéshez. A TPM 1000 növekményesen módosítható, és megfelelteti az üzembe helyezéskor érvényes TPM- és RPM-sebességkorlátoknak, ahogy azt fentebb említettük.

Új üzembe helyezés létrehozásához az Microsoft Foundry portálon válassza a Deployments>Deploy model>Deploy base model>Select Model>Confirm.

Az üzembe helyezés után módosíthatja a TPM-foglalást, ha kiválasztja és szerkeszti a modellt az Foundry portálÜzembe helyezések lapján. Ezt a beállítást a Felügyeleti>modell kvóta lapján is módosíthatja.

Fontos

A kvóták és a korlátok változhatnak. A legfrissebb információkért tekintse meg a kvótákat és korlátokat ismertető cikket.

Kvóta megtekintése és kérése

Ha egy adott régióban lévő telepítések kvótaelosztásait szeretné áttekinteni, válassza a Management>Quota (Felügyeletikvóta) lehetőséget a Foundry portálon:

  • Üzembe helyezés: Modelltelepítések modellosztály szerint osztva.
  • Kvótatípus: Minden modelltípushoz régiónként egy kvótaérték tartozik. A kvóta a modell összes verzióját lefedi.
  • Kvótakiosztás: A kvótanév esetén ez azt mutatja, hogy az üzemelő példányok mennyi kvótát használnak fel, valamint mennyi a jóváhagyott teljes kvóta az adott előfizetés és régió számára. Ez a felhasznált kvótamennyiség a sávdiagramon is megjelenik.
  • Kérelemkvóta: Az ikon erre az űrlapra lép, ahol a kvótanövelési kérelmek elküldhetők.

Meglévő telepítések migrációja

Az új kvótarendszerre és a TPM-alapú foglalásra való áttérés részeként az összes meglévő Azure OpenAI-modell üzembe helyezése automatikusan át lett migrálva a kvóta használatára. Azokban az esetekben, amikor a meglévő TPM/RPM-foglalás túllépi az alapértelmezett értékeket a korábbi egyéni sebességkorlát-növekedések miatt, a rendszer egyenértékű TPM-et rendelt az érintett üzemelő példányokhoz.

A sebességkorlátok ismertetése

A TPM üzembe helyezéshez való hozzárendelése beállítja a Tokens-Per-Minute (TPM) és a Requests -Per-Minute (RPM) sebességkorlátokat az üzembe helyezéshez a fent leírtak szerint. A TPM-sebességkorlátok azon jogkivonatok maximális számán alapulnak, amelyeket egy kérés a kérés beérkezésének időpontjában feldolgozni fog. Ez nem ugyanaz, mint a számlázáshoz használt tokenek száma, amelyet az összes feldolgozás befejezése után számítanak ki.

Az egyes kérések érkeztével Azure OpenAI kiszámítja a feldolgozott tokenek becsült maximális számát, amely a következőket tartalmazza:

  • Szöveg és darabszám kérése
  • A max_tokens paraméterbeállítás
  • A best_of paraméter beállítása

Amikor a kérések bekerülnek az üzembehelyezési végpontba, a becsült maximálisan feldolgozott tokenek száma hozzá lesz adva az összes kérés futó token számlálójához, amely percenként alaphelyzetbe áll. Ha ebben a percben bármikor eléri a TPM sebességkorlátját, a további kérések 429-es válaszkódot kapnak, amíg a számláló alaphelyzetbe nem áll.

Fontos

A sebességkorlát kiszámításához használt jogkivonatok száma részben az API-kérés karakterszámán alapuló becslés. A művelet-korlát becslése nem ugyanaz, mint a számlázásra használt jogkivonat-számítás, valamint annak meghatározása, hogy egy kérés a modell bemeneti jogkivonat-korlátja alatt van-e. A sebességkorlát token számításának hozzávetőleges jellege miatt várható, hogy a sebességkorlát az egyes kérések pontos tokenszámával való összehasonlításhoz képest a vártnál korábban léphet életbe.

Az RPM sebességkorlátjai az idő múlásával fogadott kérések számán alapulnak. A sebességkorlát arra számít, hogy a kérések egyenletesen oszlanak el egyperces időszak alatt. Ha ez az átlagos áramlás nincs fenntartva, akkor a kérések 429 választ kaphatnak annak ellenére, hogy nem éri el a korlátot, egy perces méréssel. Ennek a viselkedésnek a megvalósítása érdekében Azure OpenAI kiértékeli a bejövő kérések sebességét kis idő alatt, általában 1 vagy 10 másodperc alatt. Ha az adott időszakban beérkezett kérelmek száma meghaladja a megadott RPM-korlátnál elvárt értéket, akkor az új kérések a következő értékelési időszakig 429 válaszkódot kapnak. Ha például Azure OpenAI 1 másodperces időközönként figyeli a kérelmek sebességét, akkor a sebességkorlátozás 600 RPM-alapú üzemelő példány esetén történik, ha minden 1 másodperces időszakban több mint 10 kérés érkezik (percenként 600 kérelem = 10 kérés másodpercenként).

Megjegyzés

Ha kiosztott átviteli egységeket (PTU) használ, a rendszer másképp számítja ki a sebességkorlátokat. További részletekért tekintse meg a kihasználtságalapú kérés értékelése szakaszt a Foundry-modellek kiosztott átviteli sebessége című dokumentumban.

Sebességkorlátozás válaszfejlécei

Azure Az OpenAI minden API-hívás HTTP-válaszfejlécében tartalmazza a sebességkorlátot. Ezekkel a fejlécekkel programozott módon monitorozhatja a használatot, és proaktív módon elkerülheti a 429-et.

Fejléc Példaérték Leírás
x-ratelimit-limit-requests 60 A telepítéshez percenként engedélyezett kérelmek maximális száma.
x-ratelimit-limit-tokens 150000 A telepítéshez percenként engedélyezett tokenek maximális száma.
x-ratelimit-remaining-requests 59 A hátralévő kérések mielőtt elérjük a sebességkorlátot.
x-ratelimit-remaining-tokens 149984 Megmaradó tokenek száma a kvóta elérése előtt.
x-ratelimit-reset-requests 10 A kérelemalapú sebességkorlát alaphelyzetbe állításáig eltelt idő.
x-ratelimit-reset-tokens 300 Az idő hátravan a token alapú sebességkorlát alaphelyzetbe állításáig.
retry-after-ms 2000 Benne van a 429 válaszban. Az újrapróbálkozás előtt javasolt várakozási idő (ezredmásodpercben).

Tipp

A 429-hez való hozzáférés előtt figyelje x-ratelimit-remaining-requests és x-ratelimit-remaining-tokens figyelje meg az alkalmazásban, hogy észlelje, mikor közeledik a korlátokhoz, és proaktív módon szabályozza a kéréseket.

Sebességkorlátozási legjobb gyakorlatok

A sebességkorlátokkal kapcsolatos problémák minimalizálásához használja az alábbi technikákat:

A kérések optimalizálása

  • Állítsa be max_tokens a forgatókönyvet kiszolgáló minimális értéket. A sebességkorlát token becslése tartalmazza max_tokens, még akkor is, ha a tényleges válasz sokkal rövidebb. Ha például körülbelül 200 token válaszokat vár, ne állítsa max_tokens értékét 4000-re.
  • Állítsa best_of 1 értékre , kivéve, ha kifejezetten több befejezésre van szüksége. Minden egyes best_of növekedés megszorozza a tokenek számát, befolyásolva a sebességkorlátot.
  • Lehetőség szerint csökkentse a kérés méretét . Rövidebb kérések kevesebb tokeneket használnak fel a korlátozás szempontjából.

Újrapróbálkozási logika implementálása exponenciális visszalépéssel

Automatikusan próbálkozzon újra a kérésekkel, amikor 429-választ kap. Használja a retry-after-ms fejléc értékét, ha van, ellenkező esetben használja az exponenciális visszalépést véletlenszerű jitterrel:

  1. Várjon egy rövid, véletlenszerű késleltetést az első hiba után.
  2. Ha az újrapróbálkozás sikertelen, duplázza meg a késleltetést (exponenciális visszatartás).
  3. Véletlenszerű késleltetés hozzáadásával megakadályozhatja, hogy az összes ügyfél egyszerre próbálkozzon újra.
  4. Állítsa be az újrapróbálkozások maximális számát (például 5–10) a végtelen ciklusok elkerülése érdekében.

Fontos

A sikertelen kérések továbbra is beleszámítanak a percenkénti sebességkorlátba. A kérések folyamatos újraküldése biztonsági mentés nélkül rosszabbá teszi a szabályozást.

1. lehetőség: Az SDK beépített újrapróbálkozása (a legegyszerűbb – ajánlott)

Az Azure OpenAI Python SDK (openai v1.0+) beépített automatikus újrapróbálkozást végez exponenciális visszatéréses késleltetéssel a 429-es és az átmeneti hibák esetén. Az alapértelmezett érték két újrapróbálkozás. Növelheti azt:

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

Megjegyzés

Az SDK automatikusan tiszteletben tartja a retry-after fejléceket, és exponenciális visszalépést használ a jitter használatával. A legtöbb alkalmazás esetében az ügyfélen való konfigurálás max_retries elegendő – nincs szükség harmadik féltől származó újrapróbálkozási kódtárra.

2. lehetőség: Egyéni újrapróbálkozás a tenacity tárral (speciális)

Ezt akkor használja, ha nagyobb mértékben kell szabályoznia az újrapróbálkozások viselkedését (például egyéni naplózás, szelektív kivételkezelés, megszakítók):

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

Fontos

Az SDK-ügyfél beépített újrapróbálkozásának letiltásához állítsa be a max_retries=0 értéket, amikor egyéni újrapróbálkozás-kódtárat használ. Ellenkező esetben a kitartás minden egyes kísérlete akár két további SDK-újrapróbálkozási kísérletet is elindíthat, ami a vártnál sokkal több kérést eredményez.

3. lehetőség: Manuális implementálás (nincs külső kódtár)

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# példa a Polly (v7) használatával:

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

Megjegyzés

A .NET Azure SDK beépített újrapróbálkozás-támogatással is rendelkezik. A AzureOpenAIClientOptions megépítésekor konfigurálhatja a options.Retry.MaxRetries és a options.Retry.Mode = RetryMode.Exponential anélkül, hogy Pollyt használná. Használja a Pollyt, ha speciálisabb mintákra (megszakítókra, válaszfalakra stb.) van szüksége.

Üzembehelyezési szintű használat figyelése és kezelése

  • Ellenőrizze az üzemelő példányonkénti TPM-kiosztást, nem csak az előfizetési szintű kvótát. Előfordulhat, hogy az előfizetés szintjén jóváhagyott kvótával rendelkezik, de 429-es hibába ütközik, mert a kvóta nincs hozzárendelve a forgalmat fogadó konkrét üzemelő példányhoz.
  • Kvóták újraegyensúlyozása az üzemelő példányok között a megfigyelt használat alapján. A Azure Monitor metrikák használatával áttekintheti a 24 órás és a hétnapos használati trendeket, és észlelheti a kiugró mintázatokat.
  • A Foundry portál kvótakezelésével növelheti a TPM-et a nagy forgalmú telepítéseken, és csökkentheti a TPM-et az alulhasznált telepítéseken.

Forgalom egyenletes elosztása

  • Kerülje a számítási feladatok éles kiugrását. Az RPM sebességkorlátjai arra számítanak, hogy a kérések egyenletesen oszlanak el minden percben. Még akkor is, ha az összes kérés a percenkénti korlát alatt van, egy 1 másodperces vagy 10 másodperces ablakban történő kirobbanás 429-et aktiválhat.
  • Az új számítási feladatok előkészítésekor vagy a terhelés növelésekor fokozatosan növelje a forgalmat.
  • Ha a számítási feladat nagyobb átviteli sebességet igényel, mint amennyit egyetlen üzembe helyezés támogat, eloszthatja a kérelmeket több üzemelő példány vagy régió között.

Lehetőség szerint aszinkron/kötegelt feldolgozás használata

Ha a használati eset nem igényel azonnali választ, fontolja meg az aszinkron minták használatát:

  • Várólista-kérelmek és azok feldolgozása szabályozott sebességgel.
  • Több üzemeltetés használatával párhuzamosíthatja a feldolgozást anélkül, hogy bármelyik üzemeltetés sebességkorlátját túllépi.

429 túlterhelési hibák megértése és megoldási lehetőségek

A 429-s hiba ("Túl sok kérelem") azt jelenti, hogy a rendszer elutasította a kérést, mert túllépték a sebességkorlátot, vagy a rendszer jelenleg nem tudja feldolgozni a kérést. Nem minden 429 hiba ugyanazzal a kiváltó okokkal rendelkezik, és a helyes művelet attól függ, hogy miért történt a 429.

A 429-hibák típusai

Forgatókönyv Hibaüzenet-jelző Kiváltó ok Javasolt művelet
Túllépte a sebességkorlátot Kérések... korlátozott" vagy "A sebességkorlát túllépve" A kérések túllépték az üzembe helyezés lefoglalt kvótájára vonatkozó TPM- vagy RPM-sebességkorlátot. Növelje az üzembe helyezéshez rendelt TPM-kiosztást, egyensúlyozza újra a kvótát az üzembe helyezések között, vagy kérjen kvótanövelést.
Rendszerkapacitás szabályozása "A szolgáltatás átmenetileg nem tudja feldolgozni a kérést" vagy "A rendszer nagy terhelést tapasztal" A háttérkapacitás korlátozott. Ez a feltétel gyakran átmeneti. Próbálkozzon újra a retry-after-ms késés után. Ha állandó, fontolja meg a kiépített átviteli sebességre (PTU) való frissítést a garantált kapacitás érdekében.
Ideiglenes sebességkorlát módosítása 429 válasz történik, de a konfigurált kvóta nem változott; x-ratelimit-limit-tokens a válaszfejlécek kisebbek, mint az üzembe helyezés által konfigurált TPM A standard (használatalapú fizetéses) telepítések közös erőforráskészletet használnak. Amikor az igény megközelíti a kapacitáskorlátokat, a rendszer ideiglenesen csökkenti az üzembe helyezés tényleges sebességkorlátját, hogy minden ügyfél számára fenntartsa a megbízhatóságot. Ez a csökkentés védő jellegű és átmeneti. Próbálkozzon újra a visszatartási stratégiával retry-after-ms. A módosítás általában néhány órán belül megszűnik. A konzisztens átviteli sebességet igénylő számítási feladatok esetében fontolja meg a kiosztott átviteli sebesség (PTU) használatát.
A kérelem paraméterei túllépték a token kvótáját A sebességkorlát aktiválva van, de a tokenhasználati metrikák alacsonynak tűnnek A sebességkorlát számítása magában foglalja max_tokens és a kérés becslését, nem csak a számlázott tokeneket. A nagy max_tokens értékű kérelmek akkor is felhasználhatják a sebességkorlát költségvetését, ha a tényleges válasz kicsi. Csökkentse max_tokens a várt válaszméretre.

Fontos

Sok ügyfél tévesen értelmezi a kapacitással kapcsolatos 429-et kvótaproblémákként, ami helytelen szervizeléshez vezet (például kvótanövelés kérése átmeneti kapacitásterhelés esetén). A művelet végrehajtása előtt mindig ellenőrizze a hibaüzenetek és a válaszfejléceket a kiváltó ok azonosításához.

Miért láthat 429-et akkor is, ha a tokenhasználati metrikák a kvóta alatt vannak?

Azure OpenAI sebességkorlátozás és használati mutatók nem ugyanaz:

  • Token használati metrikák az Azure Monitorban mutatják a számlázott tokeneket a sikeresen feldolgozott kérelmek alapján.
  • A sebességkorlátozás a beérkezéskor érvényes API-kérelmekre vonatkozik, beleértve a később elutasított vagy soha nem számlázott kérelmeket is.

A különbség miatt 429 választ kaphat akkor is, ha a tokenhasználati metrikák jóval a kvóta alatt jelennek meg. Gyakori okok a következők:

  • max_tokenstúlbecslés: A mértékhatárok kiszámítása a becsült maximális jogkivonatszámon (felszólítás + max_tokens) alapul, nem pedig a ténylegesen létrehozott jogkivonatszámon.
  • Elutasított kérelmek: Előfordulhat, hogy a bemeneti hosszkorlátok (HTTP 400) miatt elutasított kérelmek továbbra is beleszámítanak a sebességkorlátozásba, de nem jelennek meg a számlázott jogkivonat-metrikákban.
  • Kipukkadási minták: Az RPM érvényesítés kis időablakokban (1–10 másodperc) a kérések értékelését végzi. A kérések rövid ablakban történő sorozata akkor is szabályozást vált ki, ha a percenkénti összeg a korlátokon belül van.
  • A szolgáltatás megbízhatóságának ideiglenes sebességkorlát-módosítása: A standard (használatalapú fizetéses) üzemelő példányok közös erőforráskészletet használnak az ügyfelek között. A szolgáltatás megbízhatóságának és tisztességes állapotának megőrzése érdekében a rendszer folyamatosan figyeli a megosztott készletre vonatkozó igényeket. Ha az üzembe helyezési igények megközelítik vagy túllépik a kapacitáskorlátokat, a rendszer ideiglenesen csökkentheti az üzembe helyezés tényleges sebességkorlátját . Ebben a kiigazítási időszakban a normál feltételek mellett elfogadott kérések 429 választ adnak vissza , annak ellenére, hogy a konfigurált kvóta nem változott. Ez a védelmi intézkedés megakadályozza az erőforráskészletet megosztó összes ügyfél szolgáltatáscsökkenését. A beállítás ideiglenes , és általában néhány órán belül megoldódik, amint a forgalom stabilizálódik. Ennek a feltételnek a figyeléséhez ellenőrizze, hogy a tényleges sebességkorlát (a válaszfejlécekben x-ratelimit-limit-tokens látható) alacsonyabb-e a konfigurált TPM-foglalásnál.
  • Elosztott kényszerítés: Előfordulhat, hogy az elosztott infrastruktúra sebességkorlát-kényszerítése nem teljesen pontos vagy azonnal tükröződik az összesített metrikákban.

Tipp

Ha 429 válasz jelenik meg egy ideiglenes sebességkorlát-kiigazítási időszakban:

  1. Próbálkozzon újra a visszalépéssel – tisztelje meg a fejlécet retry-after-ms . A kiigazítás ideiglenes, és a kereslet stabilizálása során megoldódik.
  2. Forgalom elosztása – ha lehetséges, a kérések elosztása több üzembe helyezés vagy régió között.
  3. Tekintse át a forgalmi mintázatot – a leggyakoribb kiváltó okok a tartós erős kitörések. A számítási feladatok fokozatos felfutása csökkenti a kiigazítások valószínűségét.
  4. Fontolja meg a kiosztott átviteli sebességet (PTU) – a megosztott készlet variabilitása nélküli konzisztens átviteli sebességet igénylő éles számítási feladatok esetében a kiosztott átviteli sebesség garantált sebességkorlátokkal rendelkező dedikált kapacitást biztosít.

Mire kell támaszkodni:

  • Tokenhasználati metrikák használatával megismerheti a számlázott felhasználást.
  • HTTP-válaszkódok (429) és válaszfejlécek (x-ratelimit-remaining-*, x-ratelimit-limit-*) használatával valós időben észlelhet és válaszolhat a sebességkorlát-kényszerítésekre.
  • Hasonlítsa össze x-ratelimit-limit-tokens a válaszfejlécekben a konfigurált TPM-mel annak észlelésére, hogy egy ideiglenes módosítás aktív-e.

Mikor kell újrapróbálkoznia és mikor kell eszkalálnia?

Helyzet Akció
Esetenkénti 429-es hibák, amelyek késleltetéssel oldódnak meg retry-after-ms Újrapróbálkozás – ez a viselkedés normál és elvárt a megosztott (Standard) üzemelő példányok esetében.
429-es hibák a fejlesztés vagy tesztelés során Gyakran elfogadható – a teszt környezeti 429-es kódok szándékos költségkorlátok lehetnek.
Tartósan 429-et gyártottak, a jóváhagyott kvóta alatt Eszkalálás — támogatási igény benyújtása mérnöki vizsgálatra.
A sebességkorlátozások növekedése nem tükröződik a tényleges korlátokban Eszkalálás – először ellenőrizze a kvótakiosztást az üzembe helyezés szintjén, majd eszkalálja, ha a probléma továbbra is fennáll.
Alacsony késleltetésre érzékeny vagy kritikus éles üzemeltetési feladatok gyakori 429-es hibakódot tapasztalnak. Frissítés – fontolja meg a kiosztott átviteli sebességet (PTU) a garantált kapacitás és a késési SLA érdekében.

Megjegyzés

A standard (fizetés per használatú) telepítések megosztott erőforráskészletet használnak. A korlátozás az összes felhasználó számára a szolgáltatás általános megbízhatóságát védi. Az átmeneti 429-et a várt viselkedés, nem pedig a szolgáltatás hibája jelzi. A kiszámítható késést és garantált átviteli sebességet igénylő számítási feladatok esetében a kiépített átviteli sebesség (PTU) az ajánlott üzembehelyezési típus.

A kvóta és a kapacitás programozott ellenőrzése

A Foundry portál mellett két Azure Resource Manager REST API-t is használhat az előfizetés kvótahasználatának és a modell rendelkezésre álló kapacitásának programozott ellenőrzéséhez.

Válassza ki a megfelelő API-t

Usages API Modellkapacitások API
A kérdés, amelyre választ ad A kvótám mekkora részét használtam fel a korlátomhoz képest? Mennyi üzembe helyezhető kapacitás érhető el egy adott modellhez?
Scope Előfizetés + hely Előfizetés (az összes helyszín egyszerre)
Input Csak helyadat Modell neve, verziója és formátuma
Visszatérési érték Az adott régió összes kvótasora – aktuális használat és korlát Rendelkezésre álló kapacitás helyenként és üzembe helyezési típusonként egy modellhez
Tipikus használati eset A fogyasztás figyelése, riasztások aktiválása a korlátok közeledésekor Kapacitás előzetes ellenőrzése üzembe helyezés létrehozása vagy skálázása előtt
API-referencia Felhasználások – Lista Modellkapacitások – Lista

Használja a Usages API-t , ha szüksége van egy főkönyvnézetre a felhasznált adatokról és a maradékokról. A Model Capacityes API-t akkor használja, ha tudni szeretné, hogy hol helyezhet üzembe egy modellt, és mennyi kapacitás érhető el az egyes helyeken.

Megjegyzés

Mindkét API az előfizetéshez társított összes modell adatait adja vissza, beleértve az új üzembe helyezésekhez már nem elérhető kivont modelleket is.

Használati adatok API-ja

A Usages API egy adott régió összes kvótasorát visszaadja, beleértve az aktuális felhasználást (currentValue) és a hozzárendelt korlátot.

kérelem:

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

Példa – kvótahasználat ellenőrzése az USA keleti régiójában:

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

Kulcsmezők:

Field Leírás
name.value A kvóta neve a következő formátumban: {Provider}.{DeploymentType}.{Model}
name.localizedValue ember által olvasható leírás, beleértve a mértékegységet is
currentValue Mennyit használnak fel jelenleg ebből a kvótából a telepítések
limit Az előfizetés kvótakorlátja ehhez a modellhez és üzembe helyezési típushoz

Modellkapacitás API

A Model Capacityes API egy adott modell rendelkezésre álló üzembehelyezési kapacitását adja vissza az előfizetésben lévő összes helyen és üzembe helyezési típusban.

kérelem:

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

Példa – ellenőrizze, hogy hol érhető el a gpt-4o kapacitás:

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

Kulcsmezők:

Field Leírás
location Azure-régió
properties.skuName Üzembe helyezés típusa (Standard, GlobalStandard, DataZoneStandard, ProvisionedManaged stb.)
properties.availableCapacity Az előfizetésben elérhető kapacitásegységek ehhez a modellhez, helyhez és üzembe helyezési típushoz
properties.availableFinetuneCapacity Rendelkezésre álló finomhangolási kapacitás (ha van)

Üzembe helyezés automatizálása

Az Azure OpenAI-telepítések programozott létrehozásáról és a percenkénti tokenkvóta (TPM) REST, Azure CLI, Azure PowerShell, ARM, Bicep vagy Terraform használatával történő hozzárendeléséről a Azure OpenAI-telepítések automatizálása kvótával a Microsoft Foundryban című cikkben olvashat.

Erőforrás törlése

Ha egy Azure OpenAI-erőforrás törlésére tett kísérlet történik az Azure portálról, a törlés blokkolva van, amíg a társított üzemelő példányok jelen vannak. A telepítések először történő törlése lehetővé teszi a kvótalefoglalások megfelelő felszabadítását, így azok felhasználhatók új telepítéseknél.

Ha azonban a REST API-val vagy más programozott módszerrel töröl egy erőforrást, akkor ez előbb átmegy az üzembe helyezések törlésének szükségességén. Amikor ez megtörténik, a hozzárendelt kvóta nem lesz elérhető új telepítéshez 48 órán keresztül, amíg az erőforrás meg nem tisztul. Ha egy törölt erőforrás azonnali kiürítését szeretné aktiválni a kvóta felszabadításához, kövesse a törölt erőforrás-utasítások törlését.

Következő lépések

  • Az OpenAI-Azure kvóta alapértelmezett értékének áttekintéséhez tekintse át a quotas & korlátokról szóló cikket
  • Utolsó frissítés időpontja: