HopBaseRespuesta corta: la alta concurrencia en las API de LLM no depende de lo rápido que un gateway reenvíe las solicitudes. Son tres restricciones superpuestas: cuotas escasas en los proveedores (límites estrictos de RPM/TPM), errores del lado del proveedor como condición rutinaria (los 429 y 5xx son el clima de cada día, no incidentes) y solicitudes de larga duración (los streams duran decenas de segundos y los trabajos de video, minutos). Por eso la disponibilidad nace de la planificación: capacidad redundante, failover que trata los errores como señales de planificación y afinidad que mantiene los aciertos de caché bajo carga. Un gateway que solo hace de proxy hereda cada una de esas restricciones y se las traslada directamente a su aplicación; un gateway que planifica —agregando capacidad entre rutas redundantes, reintentando los errores clasificables en otra ruta y fijando las sesiones para que las cachés de prompts sigan acertando— las absorbe. Los tres mecanismos pueden verificarse antes de registrarse; al final encontrará una lista de verificación reproducible.
La concurrencia en API de LLM no es la concurrencia clásica de API
- Las solicitudes duran mucho. Un chat en streaming mantiene una conexión durante decenas de segundos; un trabajo de generación de video se ejecuta durante minutos. La capacidad se consume por conexiones simultáneas en curso, no por QPS.
- La cuota del proveedor es el recurso escaso. Toda cuenta de API de modelos tiene topes estrictos de RPM/TPM. Ninguna cuenta individual resiste un pico de producción; la concurrencia real proviene de capacidad agregada y redundante.
- Los errores del lado del proveedor son normales. Los límites de tasa, los 5xx intermitentes y la congestión en hora punta existen en todas las API de LLM. Si el gateway no hace nada, cada cliente los recibe en bruto.
Los gateways clásicos compiten en rendimiento. Los gateways de LLM compiten en planificación. Evalúelos por su planificador.
Grupos redundantes: de dónde sale realmente la concurrencia
HopBase planifica por grupo: una API key se asigna a un grupo respaldado por capacidad redundante, de modo que el rendimiento es la suma de la capacidad del grupo, no el límite de una sola cuenta. En la práctica:
- separe los grupos por línea de negocio o equipo, para que los trabajos por lotes nunca dejen sin recursos al tráfico interactivo;
- asigne a las cargas de pico su propio grupo y escálelo de forma independiente;
- cambie modelos o enrutamiento en el lado del gateway sin modificar ni una línea de código del cliente.
El mismo mecanismo también reduce costos; consulte el enrutamiento por grupos.
Failover: los errores son señales de planificación, no su problema
La mayoría de los gateways devuelven los errores del proveedor tal cual y dejan los reintentos al cliente, lo que amplifica la inestabilidad del proveedor hacia cada cliente. Nuestro enfoque:
- los errores del proveedor entran primero en el veredicto de planificación: no solo los 5xx, sino que la mayoría de las respuestas 4xx clasificables también activan el failover automático a otra ruta;
- solo cuando se agotan los reintentos devolvemos la respuesta original del proveedor: los códigos de error nunca se ocultan ni se reescriben como timeouts, así que su propia lógica de backoff sigue funcionando;
- la facturación sigue a la salida real: una solicitud que falla sin producir salida no se cobra; una solicitud interrumpida después de generar salida (por ejemplo, si el cliente se desconecta) se cobra por el uso ya generado y se etiqueta línea por línea en la exportación de uso.
Sondas y flujos de eventos: detectar problemas antes que los usuarios
- Sondas de salud residentes prueban continuamente cada ruta;
- cada ruta emite un flujo de eventos de error y recuperación: las rutas degradadas pierden peso o se retiran automáticamente, y vuelven al servicio tras recuperarse;
- la disponibilidad se juzga con pruebas A/B directas con credenciales, no por intuición.
Afinidad de caché: la concurrencia no debería costarle la caché de prompts
Los aciertos de caché de prompts requieren que las solicitudes lleguen a la misma cuenta de backend. Un balanceo de carga ingenuo que reparte solicitudes entre muchas cuentas lleva la tasa de aciertos casi a cero: concurrencia y ahorro de caché se vuelven mutuamente excluyentes por diseño. La solución es la planificación por afinidad: una sesión se mantiene en una cuenta, la ventana de afinidad dura más que el TTL oficial de la caché y escalar nunca reorganiza las sesiones activas. Los aciertos rinden por partida doble: precio rebajado de lectura de caché y un tiempo hasta el primer token visiblemente menor. Detalles en nuestra guía de caché de prompts.
Cómo verificar un gateway bajo concurrencia (reproducible)
- Prueba de carga para ver la distribución: conjunto fijo de tareas, temperatura 0, N ejecuciones simultáneas; lea el P95/P99 del TTFT, no la media: una cola larga indica encolamiento.
- Tasa de truncamiento en salidas largas: solicite salidas largas y mida los cortes silenciosos a mitad del stream, el peor modo de fallo que existe.
- Transmisión de errores: provoque deliberadamente límites de tasa o parámetros no válidos y compare los códigos de error con el comportamiento oficial.
- Tasa de aciertos de caché: repita solicitudes con un mismo prompt de sistema largo y observe la proporción de lectura en caché en el uso.
- Repita las pruebas en distintas franjas horarias: en hora pico y valle, para detectar degradación según la hora del día.
Verificar la identidad y la calidad del modelo (frente a sustituciones y degradaciones silenciosas) es un método aparte: la prueba de fidelidad.
Preguntas frecuentes
¿Cuánta concurrencia admite HopBase?
La capacidad se dimensiona por carga de trabajo: los pipelines por lotes, los entornos de desarrollo compartidos y los picos de múltiples negocios son los objetivos de diseño. Hable con nosotros antes de la incorporación y dimensionaremos un grupo para su carga.
¿Por qué no publicar simplemente un porcentaje de disponibilidad?
Usted no puede verificar una cifra en una página de inicio. Preferimos métodos de verificación reproducibles y atributos de canal transparentes (indicados en nuestra página de precios) que puede probar usted mismo. Las condiciones contractuales de servicio se gestionan con nuestros asesores.
¿Qué ocurre si fallan todas las rutas?
La redundancia convierte los fallos de un único punto en una degradación parcial. En el caso extremo, una vez agotados los reintentos, el gateway devuelve el error original del proveedor: no se fabrica ningún éxito y los fallos que no produjeron salida no se cobran.
¿Escalar perjudica la tasa de aciertos de caché?
No. La afinidad fija las sesiones a cuentas; al escalar se añade capacidad para nuevas sesiones sin reorganizar las existentes.
Para la incorporación empresarial y el dimensionamiento de concurrencia, contáctenos; los detalles de integración están en la documentación.