Dela via

Begränsa användningen av API-token för stora språkmodeller

GÄLLER FÖR: Utvecklare | Grundläggande | Basic v2 | Standard | Standard v2 | Premium | Premium v2

Principen llm-token-limit förhindrar att användningen av API:et för stor språkmodell (LLM) ökar per nyckel genom att begränsa förbrukningen av språkmodelltoken till antingen en angiven hastighet (antal per minut), en kvot under en angiven period eller båda. När en angiven gräns för tokenfrekvens överskrids får anroparen en 429 Too Many Requests svarsstatuskod. När en angiven kvot överskrids får anroparen en 403 Forbidden svarsstatuskod.

Genom att förlita sig på tokenanvändningsmått som returneras från LLM-endpointen övervakar policyn och upprätthåller begränsningar baserat på faktisk tokenförbrukning. Policyn möjliggör också uppskattning av prompt-tokens i förväg av API Management, vilket minimerar onödiga förfrågningar till LLM-backend om gränsen redan överskrids. Eftersom det faktiska antalet tokens som konsumeras beror på både promptstorleken och fullbordandets storlek (som varierar beroende på begäran), kan policyn inte förutsäga total tokenförbrukning i förväg. Denna design skulle kunna tillåta att tokengränser överskrids tillfälligt när flera förfrågningar behandlas samtidigt.

Kommentar

Ange principens element och underordnade element i den ordning som anges i principbeskrivningen. Läs mer om hur du anger eller redigerar API Management-principer.

Modeller som stöds

Använd principen med LLM-API:er som lagts till i Azure API Management som är tillgängliga via Azure AI Model Inference API eller med OpenAI-kompatibla modeller som hanteras via tredjeparts slutsatsdragningsproviders.

Principuttryck

<llm-token-limit counter-key="key value"
        tokens-per-minute="number"
        token-quota="number"
        token-quota-period="Hourly | Daily | Weekly | Monthly | Yearly"
        estimate-prompt-tokens="true | false"    
        retry-after-header-name="custom header name, replaces default 'Retry-After'" 
        retry-after-variable-name="policy expression variable name"
        remaining-quota-tokens-header-name="header name"  
        remaining-quota-tokens-variable-name="policy expression variable name"
        remaining-tokens-header-name="header name"  
        remaining-tokens-variable-name="policy expression variable name"
        tokens-consumed-header-name="header name"
        tokens-consumed-variable-name="policy expression variable name" />

Attribut

Attribut beskrivning Obligatoriskt Standardvärde
counter-key Nyckeln som ska användas för tokengränsprincipen. För varje nyckelvärde används en enskild räknare för alla omfång där principen har konfigurerats. Principuttryck tillåts. Ja Ej tillämpligt
tokens per minut Det maximala antalet token som förbrukas av prompt och slutförande per minut. Antingen måste en hastighetsgräns (tokens-per-minute), en kvot (token-quota över en token-quota-period) eller båda anges. Ej tillämpligt
token-quota Det maximala antalet token som tillåts under tidsintervallet som anges i token-quota-period. Principuttryck tillåts inte. Antingen måste en hastighetsgräns (tokens-per-minute), en kvot (token-quota över en token-quota-period) eller båda anges. Ej tillämpligt
token-quota-period Längden på det fasta fönstret varefter token-quota återställs. Värdet måste vara något av följande: Hourly,Daily, Weekly, Monthly, . Yearly Starttiden för en kvotperiod beräknas som UTC-tidsstämpeln trunkerad till den enhet (timme, dag osv.) som används för perioden. Antingen måste en hastighetsgräns (tokens-per-minute), en kvot (token-quota över en token-quota-period) eller båda anges. Ej tillämpligt
estimate-prompt-tokens Booleskt värde som avgör om du vill uppskatta antalet token som krävs för en fråga:
- true: beräkna antalet token baserat på promptschemat i API; kan minska prestandan.
- false: beräkna inte prompttoken.

När de är inställda falsepå beräknas de återstående token per counter-key med den faktiska tokenanvändningen från modellens svar. Detta kan leda till att prompter skickas till modellen som överskrider tokengränsen. I sådana fall kommer detta att upptäckas i svaret, och alla efterföljande förfrågningar blockeras av policyn tills tokengränsen återställs.		 Ja Ej tillämpligt
retry-after-header-name Namnet på en anpassad svarsrubrik vars värde är det rekommenderade återförsöksintervallet i sekunder efter den angivna tokens-per-minute eller token-quota överskridna. Principuttryck tillåts inte. Nej Retry-After
retry-after-variable-name Namnet på en variabel som lagrar det rekommenderade återförsöksintervallet i sekunder efter att den angivna tokens-per-minute eller token-quota har överskridits. Principuttryck tillåts inte. Nej Ej tillämpligt
remaining-quota-tokens-header-name Namnet på en svarsrubrik vars värde efter varje principkörning är det uppskattade antalet återstående token som motsvarar token-quota tillåtet för token-quota-period. Principuttryck tillåts inte. Nej Ej tillämpligt
remaining-quota-tokens-variable-name Namnet på en variabel som efter varje principkörning lagrar det uppskattade antalet återstående token som motsvarar token-quota tillåtet för token-quota-period. Principuttryck tillåts inte. Nej Ej tillämpligt
remaining-tokens-header-name Namnet på ett svarshuvud vars värde efter varje principkörning är antalet återstående token som motsvarar tokens-per-minute tillåtet för tidsintervallet. Principuttryck tillåts inte. Nej Ej tillämpligt
remaining-tokens-variable-name Namnet på en variabel som efter varje principkörning lagrar antalet återstående token som motsvarar tokens-per-minute tillåtna för tidsintervallet. Principuttryck tillåts inte. Nej Ej tillämpligt
tokens-consumed-header-name Namnet på en svarsrubrik vars värde är antalet token som förbrukas av både prompt och slutförande. Huvudet läggs till i svaret först när svaret har tagits emot från serverdelen. Principuttryck tillåts inte. Nej Ej tillämpligt
tokens-consumed-variable-name Namnet på en variabel som initierats till det uppskattade antalet token i prompten i backend avsnittet av pipelinen om estimate-prompt-tokens är true och noll annars. Variabeln uppdateras med det rapporterade antalet när svaret tas emot i outbound avsnittet. Nej Ej tillämpligt

Förbrukning

Användningsanteckningar

  • Den här principen kan användas flera gånger per principdefinition.
  • Denna policy kan valfritt konfigureras när man lägger till ett LLM-API via portalen.
  • Om tillgängligt när estimate-prompt-tokens är inställt på falseanvänds värden i användningsavsnittet i svaret från LLM-API:et för att fastställa tokenanvändning.
  • När flera förfrågningar skickas samtidigt eller med små fördröjningar kan policyn tillåta tokenförbrukning som överskrider den konfigurerade gränsen. Detta händer eftersom policyn inte kan bestämma exakt hur många tokens som används förrän svar tas emot från backend. När svaren har bearbetats och tokengränserna överskridits, blockeras efterföljande förfrågningar tills gränsen återställs.
  • Vissa LLM-slutpunkter stöder strömning av svar. När stream anges till true i API-begäran för att aktivera strömning beräknas alltid prompttoken, oavsett värdet för estimate-prompt-tokens attributet.
  • Värdet för remaining-quota-tokens-variable-name eller remaining-quota-tokens-header-name är en uppskattning i informationssyfte men kan vara större än förväntat baserat på faktisk tokenförbrukning. Värdet är mer exakt när kvoten närmar sig.
  • För modeller som accepterar bildindata räknas bildtoken vanligtvis av serverdelsspråkmodellen och ingår i gräns- och kvotberäkningar. Men när direktuppspelning används eller estimate-prompt-tokens är inställd på trueöverberäkning av principen för närvarande varje bild som ett maximalt antal 1 200 token.
  • API Management använder en enskild räknare för varje counter-key värde som du anger i principen. Räknaren uppdateras i alla omfång där principen har konfigurerats med det nyckelvärdet. Om du vill konfigurera separata räknare i olika omfång (till exempel ett specifikt API eller en specifik produkt) anger du olika nyckelvärden i de olika omfången. Du kan till exempel lägga till en sträng som identifierar omfånget till värdet för ett uttryck.
  • V2-nivåerna använder en token-hinkalgoritm för hastighetsbegränsning, vilket skiljer sig från sliding window-algoritmen i klassiska tiers. På grund av denna implementeringsskillnad, när du konfigurerar tokengränser i v2-nivåerna vid flera scopes genom att använda samma, counter-keyse till att tokens-per-minute värdet är konsekvent över alla policyinstanser. Oöverensstämmande värden kan orsaka oförutsägbart beteende.
  • Den här principen spårar tokenanvändningen oberoende av varje gateway där den tillämpas, inklusive arbetsytegatewayer och regionala gatewayer i en distribution i flera regioner. Den aggregerar inte antalet token i hela instansen.

Exempel

Gräns för tokenfrekvens

I följande exempel styrs gränsen för tokenfrekvens på 5 000 per minut av anroparens IP-adress. Principen uppskattar inte antalet token som krävs för en fråga. Efter varje principkörning lagras de återstående token som tillåts för anroparens IP-adress under tidsperioden i variabeln remainingTokens.

<policies>
    <inbound>
        <base />
        <llm-token-limit
            counter-key="@(context.Request.IpAddress)"
            tokens-per-minute="5000" estimate-prompt-tokens="false" remaining-tokens-variable-name="remainingTokens" />
    </inbound>
    <outbound>
        <base />
    </outbound>
</policies>

Tokenkvot

I följande exempel styrs tokenkvoten på 1 0000 av prenumerations-ID:t och återställs varje månad. Efter varje principkörning lagras antalet återstående token som tillåts för prenumerations-ID:t under tidsperioden i variabeln remainingQuotaTokens.

<policies>
    <inbound>
        <base />
        <llm-token-limit
            counter-key="@(context.Subscription.Id)"
            token-quota="100000" token-quota-period="Monthly" remaining-quota-tokens-variable-name="remainingQuotaTokens" />
    </inbound>
    <outbound>
        <base />
    </outbound>
</policies>

Relaterat innehåll

Mer information om hur du arbetar med principer finns i:

  • Last updated on