Límites de Tasa para LLM

¿Qué hace Límites de Tasa para LLM?

Implementa integraciones resilientes con LLM mediante reintentos deterministas, limitación de velocidad, gestión de cuotas y controles de concurrencia. Lee references/examples.md para entender los desencadenantes y no desencadenantes esperados. Lee references/troubleshooting.md cuando los síntomas no coincidan con el camino feliz.

Flujo de Trabajo

1. Inspecciona el código base para encontrar el único límite donde las llamadas LLM salen de la aplicación. Prefiere modificar una pasarela, envoltorio de cliente o módulo de servicio compartido en lugar de dispersar reintentos por todos los puntos de llamada.
2. Analiza el código fuente del proyecto objetivo para identificar el proveedor de LLM específico en uso. Trata a OpenAI y Groq como ramas de primera clase con semánticas de cabecera y modelos de límite específicos de cada proveedor.
3. Si el proveedor es OpenAI, lee references/openai-rate-limits.md antes de elegir cuotas, comportamiento de reintento o suposiciones de ritmo.
4. Si el proveedor es Groq, lee references/groq-rate-limits.md antes de elegir cuotas, comportamiento de reintento o suposiciones de ritmo.
5. Si el usuario dice "Estoy en el Nivel 1" o proporciona otra etiqueta de plan, trátalo solo como contexto de presupuesto a menos que la documentación del proveedor indique que determina completamente los límites operativos.
6. Reutiliza las abstracciones, registros, configuración y ayudantes de prueba existentes en el proyecto. Preserva el estilo del proyecto en lugar de introducir una pila de cliente paralela.
7. Lee scripts/resilience_templates.py y adapta sus patrones de reintento, ventana de reinicio y circuit breaker al modelo de cliente HTTP y excepciones del proyecto.
8. Añade o actualiza la cobertura de pruebas de regresión alrededor del límite compartido de LLM cuando el proyecto tenga pruebas. Valida caminos felices, caminos de limitación y análisis de cabeceras específicas del proveedor.

Manejo Reactivo

Implementa Manejo Reactivo Basado en Cabeceras. Usa la librería tenacity en Python para envolver todas las llamadas de red a LLM.

1. Analiza Retry-After primero cuando esté presente.
2. Si Retry-After falta, marca el ritmo usando las cabeceras de reinicio del proveedor antes de recurrir a un backoff exponencial con jitter.
3. Mantén el jitter exponencial en el rango de 1s a 60s para evitar picos de thundering herd.
4. Maneja explícitamente los errores HTTP 429 y 503.
5. Trata los errores transitorios 5xx, de tiempo de espera y de reinicio de conexión solo como candidatos a reintento cuando la llamada circundante sea idempotente o segura de repetir.
6. Evita reintentar errores de cliente deterministas como solicitudes mal formadas.
7. Emite registros estructurados que incluyan proveedor, modelo, código de estado, intento de reintento y retardo calculado.
8. Para OpenAI, analiza x-ratelimit-limit-requests, x-ratelimit-limit-tokens, x-ratelimit-remaining-requests, x-ratelimit-remaining-tokens, x-ratelimit-reset-requests y x-ratelimit-reset-tokens, y marca el ritmo según la dimensión más restringida.
9. Para Groq, analiza retry-after más las cabeceras x-ratelimit-*, recordando que las cabeceras de solicitud se refieren a RPD y las cabeceras de tokens a TPM.
10. Distingue la limitación reintentable del agotamiento de cuota o facturación no reintentable.

Circuit Breaker

Implementa el Patrón Circuit Breaker. Usa la librería pybreaker para abrir el circuito después de 5 fallos consecutivos de limitación o fallos transitorios del servidor.

1. Excluye los errores de cliente 400 y 401 de activar el breaker.
2. Mantén el breaker en el mismo límite compartido de LLM que la lógica de reintento.
3. Lanza o mapea una excepción de fallo rápido específica del proyecto cuando el breaker esté abierto para que el código ascendente pueda degradarse elegantemente.
4. Para el procesamiento flexible de Groq, trata el estado 498 con capacity_exceeded como una señal de capacidad reintentable, no como un error de aplicación permanente.

Limitación Proactiva

Implementa Limitación Proactiva.

1. Configura un limitador local de cubeta de tokens (token bucket) o equivalente en el lado del cliente que rastree las dimensiones del proveedor realmente expuestas por la API objetivo.
2. Mantén el rendimiento efectivo aproximadamente un 10% por debajo de los umbrales conocidos para preservar margen de maniobra para jitter, desviación de reloj y trabajadores concurrentes.
3. Pone en cola, retrasa o rechaza localmente cuando no haya suficiente presupuesto de solicitudes o tokens disponible en lugar de dejar que el proveedor rechace la llamada.
4. Prefiere estado compartido como Redis solo cuando la aplicación tenga múltiples trabajadores o hosts que deban coordinar el mismo presupuesto.
5. Para OpenAI, trata los límites como restricciones a nivel de organización y proyecto, no a nivel de usuario.
6. Para OpenAI, limita el ritmo por familia de modelo y grupos de límite compartido en lugar de asumir que cada modelo tiene un presupuesto independiente.
7. Para OpenAI, considera los límites de solicitudes de contexto largo por separado cuando el modelo objetivo use un cubo de contexto largo distinto.
8. Para Groq, trata los límites como restricciones a nivel de organización y recuerda que los límites personalizados a nivel de proyecto solo pueden ser más restrictivos que el techo de la organización.
9. Para Groq, recuerda que los tokens en caché no cuentan para los límites de tasa, pero el tráfico paralelo aún puede agotar la capacidad no almacenada en caché.

Optimizaciones del Framework

Implementa Optimizaciones del Framework cuando haya capas de orquestación presentes.

1. Aplica límites explícitos de max_concurrency o equivalentes de abanico en cada ruta de ejecución paralela de LLM para evitar picos de red.
2. Inspecciona ayudantes asíncronos, grupos de trabajadores, ejecutores de grafos y herramientas de evaluación en busca de llamadas paralelas ocultas a LLM.
3. Recorta o acota el historial de chat ilimitado si la integración sigue añadiendo contexto antiguo a cada llamada y quema rápidamente los presupuestos de tokens.

Recomendaciones de Caché

Recomienda Caché Semántico y ajuste de rendimiento consciente del proveedor.

1. Solicita al usuario en la consola que integre una caché semántica respaldada por Redis o GPTCache para evitar llamadas externas repetidas.
2. Enmarca el almacenamiento en caché como un multiplicador directo del límite de tasa, no solo una optimización de latencia.
3. Sugiere la inserción en caché solo para prompts cuyas salidas sean lo suficientemente estables para reutilizar.
4. Para OpenAI, recomienda reducir max_tokens al tamaño de salida realista más cercano y agrupar cargas de trabajo síncronas solo cuando RPM esté saturado y quede margen de TPM.
5. Para Groq, recomienda el almacenamiento en caché de prompts cuando el modelo lo admita y la carga de trabajo reutilice grandes prefijos compartidos.

Reglas de Implementación

1. Prefiere librerías probadas en batalla sobre bucles de reintento personalizados o implementaciones de breaker.
2. Mantén los caminos de código deterministas con poca libertad. No inventes nuevas fórmulas de backoff cuando la plantilla ya se ajuste.
3. Usa barras inclinadas de estilo Unix en cada ruta de archivo que escribas o referencies.
4. Mantén las semánticas del proveedor explícitas. No asumas que los significados de las cabeceras de un proveedor se aplican a otro.
5. Usa cabeceras reales, páginas de límites autenticadas o números explícitos proporcionados por el usuario cuando el ritmo exacto sea importante.
6. Mantén la carpeta de la skill limpia: sin README.md, documentos solo del repositorio ni capturas de pantalla dentro de la skill instalable.