Limitare l'utilizzo dei token API del modello linguistico di grandi dimensioni

SI APPLICA A: Sviluppatore | Basic | Basic v2 | Standard | Standard v2 | Premium | Premium v2

I llm-token-limit criteri impediscono picchi di utilizzo delle API LLM (Large Language Model) per ogni chiave limitando il consumo di token del modello linguistico a una frequenza specificata (numero al minuto), una quota in un periodo specificato o entrambi. Quando viene superato un limite di frequenza di token specificato, il chiamante riceve un 429 Too Many Requests codice di stato della risposta. Quando viene superata una quota specificata, il chiamante riceve un 403 Forbidden codice di stato della risposta.

API del modello supportate

Questo criterio funziona con le API LLM aggiunte a Gestione API conformi a uno degli schemi API seguenti:

• OpenAI Chat Completions or Responses API
• API messaggi Anthropic (attualmente supportata nei livelli di Gestione API v2)

Istruzione del criterio

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

Attributi

Utilizzo

• Sezioni del criterio: inbound
• Ambiti del criterio: globale, area di lavoro, prodotto, API, operazione
• Gateway: classico, v2, self-hosted, area di lavoro

Note sull'utilizzo

• Questi criteri possono essere usato più volte per ogni definizione di criteri.
• Questa policy può essere configurata opzionalmente quando si aggiunge un'API LLM tramite il portale.
• Il valore di remaining-quota-tokens-variable-name o remaining-quota-tokens-header-name è una stima e può essere maggiore del previsto in base all'effettivo consumo di token. Per altre informazioni, vedere Considerazioni sui conteggi e la stima dei token.
• Gestione API usa un singolo contatore per ogni valore counter-key specificato nei criteri. Il contatore viene aggiornato in tutti gli ambiti in cui il criterio è configurato con tale valore della chiave. Se si vogliono configurare contatori separati in ambiti diversi, ad esempio, un'API o un prodotto specifico, specificare valori di chiave diversi nei diversi ambiti. Ad esempio, aggiungere una stringa che identifica l'ambito alla fine del valore di un'espressione.
• I livelli v2 usano un algoritmo di bucket di token per la limitazione della frequenza, che differisce dall'algoritmo finestra scorrevole nei livelli classici. A causa di questa differenza di implementazione, quando si configurano i limiti dei token nei livelli v2 a più ambiti usando lo stesso counter-key, assicurarsi che il tokens-per-minute valore sia coerente su tutte le istanze della policy. Valori incoerenti possono causare comportamenti imprevedibili. Per altre informazioni, vedere Advanced request throttling with Gestione API di Azure
• Questo criterio tiene traccia dell'utilizzo dei token in modo indipendente in ogni gateway in cui viene applicato, inclusi i gateway dell'area di lavoro e i gateway a livello di area in una distribuzione in più aree. Non aggrega i conteggi dei token nell'intera istanza.

Considerazioni sul numero di token e sulla stima

I criteri monitorano e applicano i limiti dei token usando i dati di utilizzo effettivi dei token restituiti dall'endpoint LLM. Facoltativamente, è possibile abilitare la stima del token di richiesta per ridurre le richieste back-end non necessarie. Si applicano le considerazioni seguenti.

• Tipi di token: il criterio attualmente conta solo i token di richiesta e di completamento.
• Senza richiedere la stima del token (estimate-prompt-tokens="false"): il criterio usa i valori effettivi di utilizzo dei token nella usage sezione della risposta dell'API LLM. Le richieste possono essere inviate al back-end anche quando viene superato il limite; questo viene rilevato dalla risposta, dopo il quale le richieste successive vengono bloccate fino a quando il limite non viene reimpostato.
• Con la stima del token di richiesta (estimate-prompt-tokens="true"): le stime dei criteri richiedono token dallo schema del prompt nella definizione dell'API prima di inviare la richiesta. Ciò può ridurre le richieste back-end non necessarie quando il limite è già superato, ma può ridurre le prestazioni.
• Streaming: quando lo streaming è abilitato nella richiesta API (stream: true), i token di richiesta vengono sempre stimati indipendentemente dall'impostazione estimate-prompt-tokens . I token di completamento vengono stimati anche quando vengono trasmessi le risposte.
• Input immagine: per i modelli che accettano l'input dell'immagine, i token di immagine vengono in genere conteggiati dall'LLM back-end e inclusi nei calcoli di limiti e quote. Tuttavia, quando lo streaming è abilitato o estimate-prompt-tokens è impostato su true, i criteri conteggia ogni immagine come massimo di 1200 token.
• Concorrenza: poiché il numero esatto di token utilizzati non può essere determinato fino a quando le risposte non vengono ricevute dal back-end, le richieste simultanee o quasi simultanee possono superare temporaneamente il limite di token configurato. Una volta elaborate le risposte e il limite viene superato, le richieste successive vengono bloccate fino a quando il limite non viene reimpostato.
• Accuratezza della quota rimanente: la quota di token rimanente stimata restituita in remaining-quota-tokens-variable-name o remaining-quota-tokens-header-name può essere maggiore del previsto in base all'effettivo consumo di token e diventa più accurata man mano che si avvicina la quota.

Esempi

Limite di frequenza dei token

Nell'esempio seguente il limite di frequenza dei token di 5000 al minuto viene inserito nella chiave dall'indirizzo IP del chiamante. Il criterio non stima il numero di token necessari per una richiesta. Dopo ogni esecuzione dei criteri, i token rimanenti consentiti per tale indirizzo IP chiamante nel periodo di tempo vengono archiviati nella variabile 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>

Quota token

Nell'esempio seguente la quota di token di 10000 viene chiaveta dall'ID sottoscrizione e reimposta ogni mese. Dopo ogni esecuzione dei criteri, il numero di token rimanenti consentiti per tale ID sottoscrizione nel periodo di tempo viene archiviato nella variabile 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>

Criteri correlati

• Limitazione della frequenza e quote
• Criteri llm-emit-token-metric

Contenuto correlato

Per ulteriori informazioni sull'utilizzo dei criteri, vedere:

• Esercitazione: trasformare e proteggere l'API
• Informazioni di riferimento sui criteri per un elenco completo delle istruzioni dei criteri e delle relative impostazioni
• Espressioni di criteri
• Impostare o modificare criteri
• Riutilizzare le configurazioni dei criteri
• repository dei frammenti di codice Criteri di criteri
• repository di esempi Policy
• Toolkit dei criteri di Gestione API di Azure
• Introduzione Copilot per creare, spiegare e risolvere i problemi dei criteri