Confronto tra criteri di limitazione di frequenza

Questa pagina si applica ad Apigee e Apigee hybrid.

Visualizza la documentazione di Apigee Edge.

Punto chiave:

I criteri Quota, SpikeArrest, PromptTokenLimit e LLMTokenQuota vengono utilizzati per limitazione di frequenza, ma hanno scopi diversi e operano su metriche diverse. Mentre le norme Quota e SpikeArrest si concentrano sui conteggi delle richieste, le norme PromptTokenLimit e LLMTokenQuota gestiscono e controllano il consumo in base ai token, il che è fondamentale per i carichi di lavoro di AI e Large Language Model (LLM).

Sebbene SpikeArrest e PromptTokenLimit mantengano i conteggi con un'affidabilità elevata, sono progettati per utilizzare una cache Redis best-effort per archiviare i conteggi. Poiché la cache non viene replicata, in alcuni casi i conteggi potrebbero andare persi, ad esempio in caso di riavvio dei server della cache o in altri rari casi.

Per questi motivi, sconsigliamo di utilizzare SpikeArrest o PromptTokenLimit per i casi d'uso che richiedono un conteggio accurato. Solo il criterio Quota sincrona o LLMTokenQuota offre un conteggio accurato in tutte le regioni in un determinato periodo di tempo.

Utilizza il grafico di confronto riportato di seguito per decidere quale policy utilizzare per il tuo caso d'uso di limitazione della frequenza:

	Quota	SpikeArrest	LLMTokenQuota	PromptTokenLimit
Utilizzalo per:	Limita il numero di chiamate proxy API che un'app per sviluppatori o uno sviluppatore può effettuare in un determinato periodo di tempo. È ideale per limitazione di frequenza su intervalli di tempo più lunghi, come giorni, settimane o mesi, soprattutto quando il conteggio accurato è un requisito.	Limita il numero di chiamate API che possono essere effettuate a un proxy API in tutti i consumer in un breve periodo di tempo, ad esempio secondi o minuti.	Gestisci e limita il consumo totale di token per le chiamate API LLM in un periodo di tempo specificato (minuto, ora, giorno, settimana o mese). In questo modo puoi controllare le spese per i LLM e applicare una gestione granulare delle quote in base ai prodotti API.	Proteggi il backend di destinazione del proxy API da abusi di token, prompt massicci e potenziali tentativi di denial of service limitando la velocità dei token inviati nell'input limitando le richieste in base al numero di token nel messaggio del prompt dell'utente. È un paradigma comparativo per l'arresto dei picchi per il traffico API, ma per i token.
Non utilizzarlo per:	Proteggi il backend di destinazione del proxy API dai picchi di traffico. Utilizza SpikeArrest o PromptTokenLimit per questo scopo.	Conta e limita il numero di connessioni che le app possono effettuare al backend di destinazione del proxy API in un periodo di tempo specifico, soprattutto quando è necessario un conteggio accurato.	Proteggi il backend di destinazione del proxy API dall'utilizzo illecito dei token. Utilizza PromptTokenLimit per questo scopo.	Conteggia e limita con precisione il numero totale di token consumati per la fatturazione o la gestione delle quote a lungo termine. Utilizza la norma LLMTokenQuota per questo scopo.
Memorizza un conteggio?	Sì	No	Sì, mantiene i contatori che monitorano il numero di token consumati dalle risposte LLM.	Conta i token per applicare un limite di frequenza, ma non memorizza un conteggio persistente a lungo termine come il criterio LLMTokenQuota.
Best practice per l'allegato della norma:	Allegalo a ProxyEndpoint Request PreFlow, in genere dopo l'autenticazione dell'utente. In questo modo, la policy può controllare il contatore delle quote nel punto di ingresso del proxy API.	Collegalo al pre-flusso della richiesta ProxyEndpoint, in genere all'inizio del flusso. In questo modo, la protezione dai picchi viene fornita nel punto di ingresso del proxy API.	Applica le norme di applicazione (EnforceOnly) nel flusso di richiesta e le norme di conteggio (CountOnly) nel flusso di risposta. Per le risposte dinamiche, collega la policy di conteggio a un EventFlow.	Allegalo a ProxyEndpoint Request PreFlow, all'inizio del flusso, per proteggere il backend da prompt di dimensioni eccessive.
Codice di stato HTTP quando è stato raggiunto il limite:	429 (Servizio non disponibile)	429 (Servizio non disponibile)	429 (Servizio non disponibile)	429 (Servizio non disponibile)
Informazioni utili:	Il contatore della quota è memorizzato in Cassandra. Puoi configurare la policy per sincronizzare il contatore in modo asincrono per risparmiare risorse, ma ciò potrebbe consentire chiamate leggermente superiori al limite.	Consente di scegliere tra un algoritmo di smoothing o un algoritmo di conteggio efficace. Il primo uniforma il numero di richieste che possono verificarsi in un periodo di tempo specificato, mentre il secondo limita il numero totale di richieste che possono verificarsi in un periodo di tempo specificato, indipendentemente dalla rapidità con cui vengono inviate in successione. Il livellamento non è coordinato tra i processori di messaggi.	Può essere configurato come CountOnly per monitorare l'utilizzo dei token o EnforceOnly per rifiutare le richieste che superano la quota. Funziona con i prodotti API per consentire configurazioni granulari delle quote in base all'app, allo sviluppatore, al modello o a un insieme specifico di operazioni LLM. Utilizza <LLMTokenUsageSource> per estrarre il conteggio dei token dalla risposta LLM e <LLMModelSource> per identificare il modello utilizzato.	Il calcolo dei token potrebbe differire leggermente da quello utilizzato dal LLM. L'elemento <UserPromptSource> specifica la posizione del prompt utente nel messaggio di richiesta.
Maggiori dettagli:	Criteri per le quote	Norme SpikeArrest	LLMTokenQuota policy	PromptTokenLimit policy

Suggerimento: puoi anche utilizzare quanto segue per proteggere i backend lenti/pigri senza influire sulle prestazioni delle API:

• Creazione di flussi condivisi riutilizzabili: combina criteri e risorse in un flusso condiviso che puoi utilizzare da più proxy API e persino da altri flussi condivisi.
• Concatenamento di proxy API: specifica che un proxy è l'endpoint di destinazione di un altro, collegando di fatto i due proxy in una catena di proxy. Il concatenamento dei proxy in questo modo può aiutarti a evitare un hop di rete e quindi a migliorare le prestazioni complessive.