Límites de velocidad y cuotas para las API de LLM

La limitación de velocidad basada en los tokens es fundamental para garantizar la confiabilidad, la estabilidad y el control de costos en las implementaciones de API de LLM. El tráfico de LLM es desigual. Un usuario envía un mensaje de 200 fichas; otro envía 20 000. Si solo limitas solicitudes por minuto, unas cuantas instrucciones pesadas pueden paralizar a todos los demás y arruinar tu presupuesto. Los límites basados en los tokens protegen la latencia y el costo sin perjudicar el uso normal.

Prueba Compute hoy: Pon tu modelo detrás de un VLLM punto final activado Calcular. Mantenga los límites ajustados, transmita tokens y aplique límites basados en los tokens en la puerta de enlace. Colócala cerca de los usuarios para evitar una latencia evitable.

Por qué fallan los límites de solicitudes simples para los LLM

• El trabajo varía según la solicitud. Un aviso corto con un límite pequeño cuesta unos centavos; un anuncio largo con un límite enorme cuesta muchas fichas y mucho tiempo.
• La transmisión oculta el trabajo. Una sola secuencia larga puede ocupar ranuras de decodificación durante decenas de segundos.
• La equidad sufre. Unos pocos trabajos grandes matan de hambre a muchos pequeños si empacas solo por recuento de solicitudes.

El significado de la limitación de tarifas basada en tokens para los LLM es garantizar una gestión de recursos justa y eficiente en las plataformas de IA de múltiples inquilinos, evitando la escasez de recursos y promoviendo un funcionamiento estable del sistema.

Patrones compatibles con los tokens que funcionan

Use límites que reflejen el costo real:

• Límites de tokens rápidos por minuto (protege la precarga y la memoria).
• Límites de token de salida por minuto (protege el rendimiento de decodificación).
• Límites totales de tokens por minuto/hora/día (es fácil razonar).
• Límites de concurrencia por clave/usuario (máximo de transmisiones activas a la vez).
• Tapas rígidas por solicitud (max_tokens, longitud del contexto) para limitar el costo en el peor de los casos.

Combinar por tecla límites (proteger la plataforma) con por ruta límites (proteja la experiencia de usuario para funciones específicas).

Siga las mejores prácticas para implementar y administrar patrones de limitación de velocidad basados en los tokens, como establecer reglas claras, monitorear el uso y revisar periódicamente las configuraciones para garantizar un uso justo y la eficiencia operativa.

Eligiendo tu unidad: solicitudes frente a fichas

• Solicitudes/minuto: fácil de implementar; injusto bajo cargas mixtas.
• Tokens/minuto (TPM): el mejor equilibrio entre costo y equidad.
• TPM rápido frente a TPM de salida: mandos separados si las entradas largas o las salidas largas dominan en su tienda.
• Concurrencia: respaldo necesario para las interfaces de usuario de streaming.

Al seleccionar la unidad adecuada para la limitación de velocidad en las API de LLM, los factores clave a tener en cuenta incluyen el control de solicitudes, la estabilidad del sistema, la escalabilidad y los patrones de uso específicos de su aplicación.

Jerarquías: por clave, por usuario, por aplicación

Establezca límites en varias capas:

• Clave → Usuario → Aplicación → Organización → Global. El límite aplicable más ajustado gana. Los límites a nivel de organización ayudan a garantizar un uso justo en varios equipos o departamentos, evitando que una sola organización monopolice los recursos.
• Ráfaga versus sostenida. Asigne un margen de ráfaga pequeño y, a continuación, vuelva a modelar hasta la velocidad sostenida.
• Niveles prioritarios. Las claves premium obtienen un TPM más alto y más concurrencia.

Límites de concurrencia y equidad

• Ranuras de decodificación activas por clave. Ejemplo: concurrency=2—4 para aplicaciones estándar y más de 8 para aplicaciones internas de confianza.
• Hacer cola de espera es justo. Admita una combinación de indicaciones cortas y largas en cada paso; evite morir de hambre.
• Límites por solicitud. Mantenga los max_tokens ajustados para evitar generaciones prolongadas y bloqueadoras.
• Cancelación rápida. La caché KV gratuita se bloquea inmediatamente al detener el usuario.

Los límites de concurrencia efectivos son esenciales para respaldar la escalabilidad y garantizar el rendimiento del sistema y la rentabilidad en las implementaciones de LLM a gran escala.

Desafíos comunes en la limitación de la velocidad de las API de LLM

La configuración de límites de velocidad para las API de LLM presenta desafíos que no encontrará con las API normales. El uso justo es importante: necesitas límites que protejan tu sistema contra el abuso y, al mismo tiempo, que sean justos para todos. Las cargas de trabajo de LLM cambian drásticamente en función del tamaño de las entradas, la complejidad del modelo y la cantidad de resultados que se generan. Esto hace que los enfoques estándar de limitación de la tasa no sean suficientes.

La aplicación de la ley en tiempo real crea otro obstáculo. Su API de LLM necesita detectar y detener el uso excesivo al instante. Los aumentos repentinos de tráfico pueden reducir el rendimiento o bloquear tu sistema si no estás preparado. Necesitas un equilibrio de carga y unos controles de acceso inteligentes que se adapten a los cambios en los patrones de uso. Realiza un seguimiento de las solicitudes y respuestas a medida que se producen para detectar posibles abusos y asegurarte de que tus límites se mantienen.

La comunicación clara también ayuda. Los desarrolladores necesitan políticas de limitación de velocidad predecibles para evitar errores inesperados o interrupciones en el servicio. Si estableces límites demasiado estrictos o si los explicas mal, frustrarás a los clientes que no puedan aprovechar todo el potencial de tu API. Si eres demasiado inflexible, estarás fomentando el abuso, lo que aumentará tus costos.

Una buena limitación de velocidad para las API de LLM significa encontrar el punto óptimo entre las necesidades de los clientes y la realidad de ejecutar modelos grandes. Tendrá que supervisar constantemente, ajustar la configuración y comunicar los cambios para mantener los límites justos, eficientes y alineados con sus objetivos empresariales y límites técnicos.

Algoritmos a implementar

• Cubo de fichas para TPM: cada clave tiene un saldo que se recarga a un ritmo constante; gaste en fichas de aviso/salida a medida que se procesan.
• Cubo que gotea para suavizar: la cola permite ráfagas pero se drena a un ritmo fijo.
• Ventana corredera para cuotas: realiza un seguimiento de los totales del último día/semana/mes sin restablecimientos bruscos.
• Costos ponderados: cobran más por ventanas de contexto prolongadas o por el uso de herramientas si agotan los recursos.

Diseñar 429 y volver a intentarlo

• Regreso HTTP 429 cuando una clave está fuera del presupuesto o la concurrencia.
• Incluir Volver a hacer después con una espera realista en segundos.
• Devuelve un cuerpo de error estructurado:

{
«error»: {
«tipo»: «rate_limit_exceeded»,
«message»: «La clave superó los 60 000 tokens/minuto. «,
«reintentar_después»: 8,
«request_id»: «...»
}
}


• Cuando se superen los límites de frecuencia, asegúrese de que la respuesta de la API comunique claramente el error y, si es posible, implemente estrategias alternativas para enrutar la respuesta u ofrecer un manejo alternativo para mantener la estabilidad de la aplicación.
• En los documentos, mostrar retroceso del cliente ejemplos de los SDK que admite.
• En el caso de la transmisión, envía un mensaje de fin de transmisión limpio cuando se alcance una cuota flexible a mitad de la solicitud; prefiera límites estrictos por solicitud para evitarlo.

Cuotas por día/semana/mes

• Cuotas mensuales facturación adecuada. Se restablece en un día natural o en un período continuo de 30 días.
• Cuotas diarias proteja el abuso repentino provocado por llaves nuevas.
• Exponer puntos finales de uso para que los clientes puedan ver el presupuesto restante y evitar sorpresas.
• Soporte advertencias suaves (encabezado HTTP 200 +) al 80% y al 95% de la cuota.
• Los mecanismos de gobierno, como las políticas de cuotas, ayudan a garantizar un uso justo y estable de las API de LLM al administrar la asignación de recursos y alinear el uso con las políticas de la organización.

Esquema de referencia de Gateway

• Delante todo con una puerta de enlace ligera (Nginx/Envoy/Traefik) y una pequeña servicio de límite de tarifa con Redis. Esta arquitectura de referencia está diseñada para admitir una variedad de aplicaciones, lo que garantiza que se aborden diferentes casos de uso y funcionalidades. La arquitectura permite el funcionamiento fiable y seguro de las API de LLM en entornos de producción al proporcionar una comunicación de servicios uniforme y de alta calidad y funciones de seguridad sólidas. La arquitectura de puerta de enlace define políticas de limitación de velocidad, autorización y protección contra el abuso, lo que ayuda a proteger las API de las amenazas malintencionadas y a garantizar el cumplimiento de los requisitos de la organización. El funcionamiento eficiente de la puerta de enlace es crucial para mantener el rendimiento y la seguridad a gran escala.
• Teclas:
• tpm_prompt, tpm_output, tpm_total
• concurrencia
• rpm alternativo para rutas que no son de streaming
• tokens diarios, tokens mensuales
• En el caso del SSE, desactive el almacenamiento en búfer del proxy y defina los tiempos de espera de mantenimiento de forma sensata.
• Emitir métricas para permite, niega, volver a intentarlo después, y % de uso%.

Prueba Compute hoy: Ejecute un VLLM punto final activado Calcular y coloca tu puerta de entrada al frente. Ten en cuenta los límites, haz streaming de forma predeterminada y coloca el nodo en una región para reducir la latencia.

Herramientas y tecnologías para limitar la velocidad

Dispone de muchas herramientas para ayudar a su organización a establecer un límite de velocidad sólido para las API de LLM. La pasarela de API es la base de la mayoría de las configuraciones modernas. Es su punto de control central. Aquí, administras las solicitudes de API, aplicas los límites de velocidad y obtienes funciones esenciales como el equilibrio de carga y el control de acceso. Puede configurar las pasarelas para aplicar cuotas y límites en función de diferentes criterios: por cliente, por servicio o por punto final. Esto protege sus servicios de backend contra el tráfico excesivo y los posibles abusos.

Más allá de las pasarelas de API, descubrirás que los algoritmos de limitación de velocidad, como token bucket y leaky bucket, funcionan bien para suavizar las ráfagas de tráfico. Mantienen un rendimiento constante. Estos algoritmos garantizan que sus solicitudes de API se procesen de manera eficiente. Evitan que los picos repentinos abrumen su sistema. Muchos proveedores de API de LLM también ofrecen capacidades integradas de limitación de velocidad. Puede establecer cuotas o límites en la cantidad de solicitudes o tokens consumidos durante un período de tiempo específico.

Puede administrar y configurar estos límites a través de API, herramientas de línea de comandos o paneles basados en la web. Esto les brinda a usted y a sus administradores la flexibilidad de ajustar la configuración según sea necesario. Por ejemplo, puede usar una puerta de enlace de API para imponer una cuota en las llamadas a la API. Esto permite que tu servicio de backend responda incluso cuando la demanda alcanza su punto máximo.

Cuando se utilizan estas herramientas y tecnologías juntas, se crean sistemas eficientes y escalables. Mantienen un uso justo y protegen contra el abuso. La limitación efectiva de la velocidad no solo protege el rendimiento y la confiabilidad de las API de LLM. También le ayuda a gestionar los costes y a ofrecer una mejor experiencia a todos los usuarios.

Monitorización y ajuste

Reloj:

• TTFT p95 y TPS p50/p95 con longitud de cola.
• Niega por la razón (tpm_prompt, tpm_output, simultaneidad).
• Teclas principales por uso de tokens y ráfaga.
• Precisión de reintento (¿tuvieron éxito los clientes en el siguiente intento?).
• Presupuesto erróneo para los 429: manténgalos raros para los clientes que se portan bien.

Melodía:

• La supervisión de estas métricas ayuda a determinar cuándo ajustar los límites de tasa o los límites de concurrencia.
• Elevar TPM cuando las colas son cortas y el espacio libre es saludable.
• Inferior concurrencia cuando las salidas largas provocan inanición.
• Ajustar límites por ruta para proteger las rutas sensibles a la latencia.

Implemente límites basados en los tokens sin dañar la experiencia de usuario

Proteja la plataforma con fichas por minuto, no solo solicitudes por minuto. Mantén límites por solicitud apretado, concurrencia razonable, y Reintentar‑después honesto. Pon una pasarela sencilla y un contador de Redis por delante, haz streaming de forma predeterminada y mide el TTFT/TPS para ver el efecto. Estos hábitos controlan el gasto y hacen que el rendimiento sea predecible. La implementación de estas prácticas de limitación de tarifas también ayuda a ahorrar recursos y a evitar costosas interrupciones del servicio.

PREGUNTAS MÁS FRECUENTES

¿Cuál es un límite predeterminado justo para las nuevas claves de API?

Empieza con entre 30 y 60 000 tokens/min, entre 2 y 4 transmisiones simultáneas y límites ajustados por solicitud. Aumenta los límites cuando veas un comportamiento estable.

Solicitudes/minuto o tokens/minuto: ¿qué debemos elegir?

Tokens/minuto. Realiza un seguimiento de los costos reales y protege la equidad. Mantén el RPM como una red de seguridad en las rutas que no sean de streaming.

¿Cómo limitamos la velocidad de las respuestas en streaming?

Cobra los tokens a medida que se generan y se detienen cuando se acaba el presupuesto, pero prefiere límites estrictos por solicitud para que las transmisiones finalicen sin problemas.

¿Cómo evitamos 429 tormentas?

Utilice el retardo fluctuante en los clientes, distribuya los restablecimientos con ventanas deslizantes y reserve una pequeña capacidad de búfer para los reintentos.

¿Podemos compartir los límites en varias regiones?

Sí: replique los contadores (por ejemplo, Redis/CRDT) o divida por base de usuarios. Mantén a los clientes fijos en una región para reducir la latencia.

¿Qué debemos registrar para las auditorías?

ID de clave, ruta, recuentos de tokens de solicitud/salida, decisión de permitir/denegar, retry_after seconds, request_id. Evite registrar texto sin procesar.

¿Los límites basados en los tokens ralentizan el sistema?

Los mostradores son baratos. La mayor ventaja es evitar que unos pocos trabajos importantes perjudiquen a todos los demás.

¿Cuáles son los casos de uso comunes para la limitación de velocidad en las API de LLM?

Los casos de uso comunes incluyen proteger los servicios de backend de la sobrecarga, administrar los costos operativos y garantizar un acceso justo para varios clientes. La limitación de velocidad también puede respaldar estrategias de despliegue, como las implementaciones tipo canario y azul-verde, ya que controla el tráfico y permite que las implementaciones sean seguras.

‍