Comparación de las políticas de límite de frecuencia

Esta página se aplica a Apigee y Apigee hybrid.

Consulta la documentación de Apigee Edge.

Punto clave:

Las políticas Quota, SpikeArrest, PromptTokenLimit y LLMTokenQuota se usan para limitar la frecuencia, pero tienen propósitos diferentes y operan con métricas distintas. Mientras que las políticas de cuota y SpikeArrest se centran en el número de solicitudes, las políticas PromptTokenLimit y LLMTokenQuota gestionan y controlan el consumo en función de los tokens, lo cual es fundamental para las cargas de trabajo de IA y de modelos de lenguaje extenso (LLM).

Aunque SpikeArrest y PromptTokenLimit mantienen los recuentos con una fiabilidad alta, se han diseñado para usar una caché de Redis con el mejor esfuerzo para almacenar sus recuentos. Como la caché no se replica, en algunos casos se pueden perder recuentos, como cuando se reinician los servidores de caché u otros casos poco frecuentes.

Por estos motivos, no recomendamos usar SpikeArrest ni PromptTokenLimit en casos prácticos que requieran un recuento preciso. Solo la política de cuota síncrona o LLMTokenQuota ofrece un recuento preciso en todas las regiones en un periodo determinado.

Consulta la tabla comparativa que aparece a continuación para decidir qué política debes usar en tu caso práctico de limitación de frecuencia:

	Cuota	SpikeArrest	LLMTokenQuota	PromptTokenLimit
Úsala para lo siguiente:	Limita el número de llamadas a proxies de API que puede hacer una aplicación o un desarrollador durante un periodo específico. Es la mejor opción para limitar la frecuencia en intervalos de tiempo más largos, como días, semanas o meses, sobre todo cuando se requiere un recuento preciso.	Limita el número de llamadas a la API que se pueden realizar en un proxy de API en todos los consumidores durante un breve periodo, como segundos o minutos.	Gestionar y limitar el consumo total de tokens de las llamadas a la API LLM durante un periodo especificado (minuto, hora, día, semana o mes). De esta forma, puedes controlar los gastos de LLM y aplicar una gestión de cuotas granular basada en productos de API.	Protege el backend de destino de tu proxy de API frente al abuso de tokens, las peticiones masivas y los posibles intentos de denegación de servicio limitando la tasa de tokens enviados en la entrada. Para ello, restringe las solicitudes en función del número de tokens del mensaje de petición del usuario. Es un paradigma comparativo de Spike Arrest para el tráfico de APIs, pero para tokens.
No la uses para lo siguiente:	Protege el backend de destino de tu proxy de API frente a picos de tráfico. Usa SpikeArrest o PromptTokenLimit para ello.	Cuenta y limita el número de conexiones que las aplicaciones pueden establecer con el backend de destino de tu proxy de API durante un periodo específico, sobre todo cuando se requiere un recuento preciso.	Protege el backend de destino de tu proxy de API frente al uso inadecuado de tokens. Para ello, usa PromptTokenLimit.	Contar y limitar con precisión el número total de tokens consumidos para la facturación o la gestión de cuotas a largo plazo. Usa la política LLMTokenQuota para eso.
¿Almacena un recuento?	Sí	No	Sí, mantiene contadores que registran el número de tokens consumidos por las respuestas de LLM.	Cuenta los tokens para aplicar un límite de frecuencia, pero no almacena un recuento persistente a largo plazo como la política LLMTokenQuota.
Prácticas recomendadas para adjuntar la política:	Adjúntalo al Request PreFlow de ProxyEndpoint, generalmente después de la autenticación del usuario. De esta forma, la política puede comprobar el contador de cuota en el punto de entrada de tu proxy de API.	Adjúntala al PreFlow de solicitud de ProxyEndpoint, normalmente al principio del flujo. De esta forma, se protege contra picos en el punto de entrada de tu proxy de API.	Aplica la política de cumplimiento (EnforceOnly) en el flujo de solicitud y la política de recuento (CountOnly) en el flujo de respuesta. En el caso de las respuestas graduales, adjunta la política de recuento a un EventFlow.	Adjúntalo al PreFlow de la solicitud ProxyEndpoint, al principio del flujo, para proteger tu backend de las peticiones de gran tamaño.
Código de estado HTTP cuando se ha alcanzado el límite:	429 (servicio no disponible)	429 (servicio no disponible)	429 (servicio no disponible)	429 (servicio no disponible)
Información útil:	El contador de cuota se almacena en Cassandra. Puedes configurar la política para sincronizar el contador de forma asíncrona y ahorrar recursos, pero esto puede permitir que se hagan llamadas que superen ligeramente el límite.	Te permite elegir entre un algoritmo de suavizado o un algoritmo de recuento eficaz. El primero suaviza el número de solicitudes que se pueden producir en un periodo de tiempo especificado, mientras que el segundo limita el número total de solicitudes que se pueden producir en un periodo de tiempo especificado, independientemente de la rapidez con la que se envíen sucesivamente. El suavizado no se coordina entre los procesadores de mensajes.	Se puede configurar como CountOnly para hacer un seguimiento del uso de tokens o como EnforceOnly para rechazar las solicitudes que superen la cuota. Funciona con productos de API para permitir configuraciones de cuota detalladas basadas en la aplicación, el desarrollador, el modelo o un conjunto de operaciones de LLM específico. Usa <LLMTokenUsageSource> para extraer el recuento de tokens de la respuesta del LLM y <LLMModelSource> para identificar el modelo usado.	El cálculo de tokens puede diferir ligeramente del que usa el LLM. El elemento <UserPromptSource> especifica la ubicación de la petición del usuario en el mensaje de solicitud.
Consulta más información:	Política de cuotas	Política SpikeArrest	Política LLMTokenQuota	Política PromptTokenLimit

Nota: También puedes usar lo siguiente para proteger los back-ends lentos o con problemas de rendimiento sin que afecte al rendimiento de las APIs:

• Crear flujos compartidos reutilizables: combina políticas y recursos en un flujo compartido que puedes usar en varios proxies de API e incluso en otros flujos compartidos.
• Crear cadenas entre proxies de APIs: especifica que un proxy es el endpoint de destino de otro, lo que conecta los dos proxies en una cadena de proxies. Encadenar proxies de esta forma puede ayudarte a evitar un salto de red y, por lo tanto, mejorar el rendimiento general.