Le traduzioni sono generate tramite traduzione automatica. In caso di conflitto tra il contenuto di una traduzione e la versione originale in Inglese, quest'ultima prevarrà.
Applicazione dei limiti tariffari
Questo argomento descrive come il gateway valuta e applica i limiti di velocità in fase di esecuzione, inclusa l'interazione con altre funzionalità del gateway, i formati di risposta limitati e l'osservabilità.
Interazione con le regole del gateway
Il gateway valuta i limiti di velocità prima delle regole del gateway. Se un limite di velocità limita una richiesta, la richiesta non raggiunge mai la fase di valutazione della regola.
Semantica di impilamento
Quando a una richiesta si applicano più limiti di velocità, il gateway utilizza la logica AND: tutti i limiti di velocità devono superare affinché la richiesta possa procedere. Se un limite di velocità singolo rifiuta la richiesta, il gateway la limita.
Corrispondenza e specificità degli ingressi
Quando un limite di velocità contiene più voci, il gateway seleziona la voce corrispondente più specifica per i valori delle dimensioni risolte:
-
Una corrispondenza esatta dei valori ha la precedenza su una
*voce. -
Il
*valore significa «applica questo tasso a tutti i valori di questa dimensione» e funge da voce predefinita. -
Per i limiti di velocità multidimensionali, il gateway utilizza il fallback finale progressivo: prima tenta una corrispondenza esatta completa, quindi sostituisce le dimensioni finali con
*una alla volta finché non viene trovata una corrispondenza.
L'esempio seguente mostra come vengono confrontate le voci relative a un limite di frequenza con dimensionKeys: ["targetName", "toolName"] i valori risolti: ["my-target", "readData"]
| Dimensioni di ingresso | Fiammiferi? | Perché |
|---|---|---|
|
|
Sì (controllato prima) |
Corrispondenza esatta su entrambe le dimensioni. La più specifica. |
|
|
Sì (selezionato in secondo luogo) |
Corrispondenza esatta sulla prima dimensione, |
|
|
Sì (controllato per ultimo) |
Voce predefinita. Meno specifico. |
La prima voce corrispondente vince. Se nessuna voce corrisponde (e non esiste un * valore predefinito), il limite di frequenza per quella richiesta viene saltato.
Ordine di valutazione
Il gateway valuta i limiti di velocità nel seguente ordine:
-
Il gateway valuta i limiti di velocità utilizzando innanzitutto più chiavi di dimensione (i limiti più specifici hanno la priorità).
-
A parità di dimensioni, il gateway valuta i limiti di velocità applicando innanzitutto tariffe più rigide (inferiori).
-
La valutazione va in cortocircuito al primo rifiuto: il gateway non valuta i limiti di velocità rimanenti.
Interazione con i limiti gestiti dal servizio
Il gateway applica sia i limiti tariffari definiti dal cliente sia i limiti gestiti dal servizio. La tariffa effettiva per ogni richiesta è il minimo di entrambi:
-
Il gateway valuta innanzitutto i limiti tariffari definiti dal cliente.
-
Se la richiesta supera i limiti del cliente, vengono valutati i limiti gestiti dal servizio.
-
Un rifiuto da una delle due fonti comporta una limitazione.
Risposte limitate
Quando una richiesta viene limitata, il gateway restituisce una risposta di errore specifica del protocollo contenente il valore nel corpo della retryAfter risposta.
Protocollo HTTP:
{ "error": "Rate limit exceeded", "success": false, "limitKey": "rl-abc123/targetName=my-target", "metric": "requests", "retryAfter": 1 }
Protocollo MCP (JSON-RPC):
{ "jsonrpc": "2.0", "id": "request-1", "error": { "code": -32003, "message": "Rate limit exceeded", "data": { "limitKey": "rl-abc123/targetName=my-target", "metric": "requests", "retryAfter": 1 } } }
OpenAI-compatible protocollo:
{ "error": { "message": "Rate limit exceeded", "type": "rate_limit_error", "code": "429", "limitKey": "rl-abc123/qualifiedModelId=anthropic.claude-3-sonnet", "metric": "tokens", "retryAfter": 60 } }
Anthropic-compatible protocollo:
{ "type": "error", "error": { "type": "rate_limit_error", "message": "Rate limit exceeded", "limitKey": "rl-abc123/qualifiedModelId=anthropic.claude-3-sonnet", "metric": "tokens", "retryAfter": 60 } }
Il retryAfter campo indica quanti secondi il chiamante deve attendere prima di riprovare. Utilizzate questo valore direttamente nella logica dei tentativi sul lato client.
Tempi di propagazione
Le modifiche ai limiti di velocità (creazione, aggiornamento, eliminazione) si propagano al piano dati entro 30 secondi. Durante la propagazione:
-
I nuovi limiti di velocità non vengono applicati fino al completamento della propagazione.
-
I limiti di velocità aggiornati continuano ad applicare la configurazione precedente fino alla propagazione dell'aggiornamento.
-
I limiti di velocità eliminati continuano ad essere applicati finché l'eliminazione non si propaga.
Accuratezza dell'applicazione ed eventuale coerenza
L'applicazione dei limiti tariffari è alla fine coerente piuttosto che esatta. La precisione dell'applicazione è approssimativa nei momenti in cui un limite inizia a ricevere traffico e migliora man mano che il traffico continua. La precisione osservata dipende quindi dall'andamento del traffico.
Sono previsti i seguenti comportamenti:
-
All'inizio i limiti freddi ammettono di essere eccessivi. Un limite freddo è un limite appena creato o che non ha avuto traffico recente. Per un breve periodo iniziale, il gateway potrebbe superare il limite di richieste (consentire un numero di richieste superiore alla tariffa configurata) prima che l'applicazione converga. Una volta raggiunto un limite di traffico continuo, la precisione migliora e la velocità di accelerazione osservata si assesta vicino alla velocità configurata.
-
Il traffico prolungato viene applicato in modo accurato, ma le brevi interruzioni potrebbero non esserlo. Una breve raffica contro un limite di freddo può passare senza essere rallentata. Viene applicata la stessa frequenza di invio del traffico prolungato, poiché la precisione migliora man mano che il limite si riscalda. Per osservarne o dimostrarne l'applicazione, invia il traffico prolungato al limite per diversi minuti anziché per una singola sequenza breve. Ad esempio, per un limite di 4 richieste al secondo, il gateway potrebbe non limitare la quinta richiesta nel primo secondo. Se invii 5 richieste al secondo in modo continuo, la richiesta aggiuntiva verrà costantemente ridotta una volta raggiunto il limite.
-
Le tariffe molto basse sono meno accurate. Le tariffe inferiori a circa 1 richiesta al secondo (ad esempio, un piccolo limite di richieste al minuto) sono più difficili da applicare con precisione e mostreranno una maggiore variabilità. Preferisci tassi più elevati laddove è importante un'applicazione precisa e considera i limiti molto bassi come approssimativi.
-
I limiti dei token convergono più lentamente. Token-per-minute i limiti aggiornano (riconciliano) il totale di utilizzo tracciato solo dopo la risposta del modello. Una richiesta che rimane in volo per diversi secondi o minuti mantiene solo il costo stimato rispetto al budget fino al completamento. Ciò estende la finestra durante la quale il gateway potrebbe accettare un numero eccessivo di richieste, rispetto ai limiti di richieste. Per ulteriori informazioni, consulta le domande frequenti sul limite di velocità dei token.
Definisci i tuoi limiti in base al fair use e alla protezione del backend. Ciò significa attenuare le esplosioni e proteggere i bersagli dai vicini rumorosi in una finestra prolungata, anziché bloccare un numero esatto di richieste nel momento in cui viene superata una soglia. I limiti di velocità non sono una soglia precisa e precisa in base alla richiesta. Inoltre, i limiti tariffari non sono un limite di sicurezza, come spiegato nella sezione seguente.
Fail-open comportamento
Il gateway utilizza la semantica fail-open per la valutazione dei limiti di velocità. La tabella seguente descrive il comportamento quando il sistema di limiti di velocità rileva errori:
| Scenario | Decisione | Rationale |
|---|---|---|
|
Timeout del servizio con limite di velocità |
Consenso |
La disponibilità ha la precedenza sull'applicazione. |
|
Chiave dimensionale irrisolvibile su richiesta |
Salta (consenti) |
Il limite di velocità non si applica a questo tipo di richiesta. |
|
Limite di velocità: errore di aggiornamento della cache |
Riprova con dati obsoleti |
L'ultima configurazione nota viene utilizzata fino al ripristino della cache. |
Importante
A causa del comportamento di fail-open, non affidatevi esclusivamente ai limiti di velocità come limite di sicurezza. Utilizza i limiti di velocità per la gestione del traffico e la qualità del servizio e utilizza le regole di autenticazione, autorizzazione e WAF per l'applicazione della sicurezza.
Tracciamento con intervalli OpenTelemetry
Il gateway emette attributi span OpenTelemetry (OTEL) sullo span del server per ogni richiesta in cui vengono valutati i limiti di frequenza dei clienti. Usa questi attributi per il debug e il monitoraggio.
| Attributo | Description | Esempio |
|---|---|---|
|
|
La decisione esecutiva per questa richiesta. |
|
|
|
Il limite |
|
|
|
Il tipo di metrica che era esaurito. Presente solo quando la decisione è presa. |
|
|
|
Comma-separated valori dimensionali risolti della voce che ha attivato l'acceleratore. Presente solo quando la decisione è presa |
|
|
|
Elenco ordinato di tutti i bucket con limite di tariffa controllati per questa richiesta. Ogni voce mostra l'ID del limite di velocità, la metrica e i valori delle dimensioni risolte. Presente sia per le decisioni che per |
|
L'evaluatedattributo è utile per capire quali limiti di frequenza si applicano a una richiesta, anche quando è stata consentita. Ogni voce dell'elenco segue il formato{rateLimitId}:{metric}:{resolvedDimVal1,dimVal2,…}.
