Concurrencia en APIs de IA: cómo controlar colas, cuotas y latencia

Por qué una integración funcional puede saturarse

Una integración con un modelo puede funcionar correctamente durante el tráfico habitual y, aun así, degradarse cuando llegan muchas solicitudes a la vez. Si la aplicación envía cada petición de inmediato, sin controlar cuántas quedan en curso ni cuántas esperan, una ráfaga puede acumular trabajo más deprisa de lo que el servicio lo completa. El resultado visible puede ser más latencia, solicitudes que ya no son útiles cuando terminan, respuestas de límite alcanzado o una factura que se aparta de lo previsto.

La concurrencia importa porque una solicitud no ocupa recursos durante un instante fijo. La generación puede durar más o menos según la tarea, el tamaño de la entrada y la cantidad de salida solicitada. Por eso, contar únicamente las peticiones por segundo no describe por sí solo la presión que ejerce una integración. Dos cargas con la misma tasa de solicitudes pueden tener tiempos de servicio y consumo distintos.

El objetivo del control de carga no es mantener ocupada toda capacidad posible a cualquier precio. Es proteger los objetivos de la aplicación: completar trabajo útil, respetar prioridades, limitar esperas y evitar que una demanda temporalmente alta convierta el sistema en una cola sin salida. Las decisiones de diseño que siguen son recomendaciones generales; no describen un límite universal ni sustituyen las condiciones documentadas para cada API, modelo o canal de acceso.

Conviene separar dos problemas que suelen mezclarse. La admisión decide, antes de enviar una petición, si la aplicación acepta el trabajo, lo mantiene brevemente en espera o lo rechaza. La política de reintentos actúa después de un fallo o un resultado incierto. Esta guía se ocupa sobre todo de la primera decisión y de la espera controlada: reintentar automáticamente no corrige una admisión que deja entrar más trabajo del que el sistema puede procesar.

Qué medir antes de fijar límites

Empieza por observar una carga representativa, no por elegir una cifra de concurrencia a ojo. Registra la tasa de llegada y el número de solicitudes simultáneas, pero añade el tamaño de entrada y la salida producida cuando esté disponible. Para una decisión de admisión anterior al envío, la salida todavía no se conoce; puede medirse después para mejorar las estimaciones, no tratarse como un dato exacto del futuro.

Mide la latencia extremo a extremo y, si puedes instrumentar las fases por separado, distingue el tiempo en cola del tiempo desde el envío hasta la respuesta. En respuestas generadas progresivamente, registra también el tiempo hasta el primer fragmento y la duración total. Un buen tiempo hasta el primer fragmento no implica que la tarea completa haya terminado rápido; tampoco una duración total elevada demuestra por sí sola que la cola sea la causa.

Usa percentiles, como p95 y p99, junto con promedios. El promedio resume una tendencia, pero puede ocultar una minoría de solicitudes que espera mucho más. Acompaña estas medidas con solicitudes completadas, canceladas, expiradas y rechazadas; errores devueltos por el proveedor; uso de tokens cuando esté disponible, y coste por tarea completada si tu sistema puede calcularlo de forma fiable.

La relación de Little ofrece una forma de comprobar la coherencia entre la población media de un sistema, la tasa media de llegada y el tiempo medio que una unidad permanece en él: L = λW. Aplicada con cuidado, ayuda a entender por qué, si se mantiene una tasa de llegada y aumenta el tiempo de permanencia, también puede crecer el número medio de trabajos presentes. No es una fórmula para pronosticar por sí sola percentiles, picos, costes ni el límite de una API; describe una relación entre promedios bajo las condiciones pertinentes.

Segmenta las mediciones por modelo, endpoint, proveedor, región o proyecto cuando esas diferencias sean relevantes para tu configuración. No mezcles en una única serie tareas cortas y largas si eso oculta los problemas de una categoría. También separa la carga de producción de las pruebas, y anota cambios de configuración para poder relacionar una variación de latencia con una causa plausible.

No confundas tasa, concurrencia, tokens y capacidad propia

Un límite de tasa controla cuántas solicitudes o unidades contabilizadas pueden presentarse durante un periodo. Un límite de concurrencia restringe cuántas operaciones mantiene activas la aplicación al mismo tiempo. Un límite basado en tokens atiende al volumen de texto procesado o solicitado según las reglas del servicio. Un límite propio de la aplicación es una decisión adicional: por ejemplo, cuántos trabajos admite la cola local o cuánto tiempo permite esperar.

Estas restricciones resuelven problemas distintos. Un sistema puede respetar una tasa promedio y acumular una ráfaga breve; puede tener pocas solicitudes simultáneas pero de larga duración; o puede recibir pocas solicitudes que impliquen entradas extensas. La aplicación debe conocer las restricciones publicadas para el canal que usa y, además, fijar controles locales que protejan su experiencia de usuario.

Las cuotas no se deben trasladar de un producto a otro por analogía. La documentación de Vertex AI describe cuotas y límites cuyo ámbito puede depender del servicio, el proyecto y la región. La referencia de la API de OpenAI incluye encabezados de respuesta relacionados con límites de solicitudes y tokens. Estos ejemplos muestran por qué hay que revisar la documentación aplicable a la cuenta y configuración concretas; no establecen cifras compartidas ni una regla única para todos los endpoints.

Una respuesta 429 tampoco identifica siempre una única causa o solución. La documentación de Vertex AI distingue situaciones relacionadas con capacidad compartida y con capacidad aprovisionada. Por tanto, registra el tipo de respuesta y consulta la documentación correspondiente antes de decidir qué significa. En particular, no conviertas toda respuesta 429 en una orden de reintentar de inmediato: ese comportamiento pertenece a la gestión posterior al fallo y puede aumentar la presión si la admisión sigue abierta.

Diseña la admisión: aceptar, esperar o rechazar

Una política de admisión debe ofrecer tres resultados explícitos. Aceptar significa que la solicitud puede empezar según los límites locales y las cuotas conocidas. Esperar significa que se conserva temporalmente en una cola con capacidad y plazo definidos. Rechazar significa que el sistema no promete procesarla en ese momento y devuelve una respuesta que permite a la aplicación cliente decidir qué hacer.

Una cola sin límite no es una solución segura: puede convertir una saturación visible en esperas cada vez mayores y trabajo almacenado que llega demasiado tarde para ser útil. Define un máximo de elementos, un presupuesto de espera y una condición de caducidad. Si la cola alcanza su límite, rechaza el nuevo trabajo o aplica una regla de sustitución que esté justificada por el producto; no ocultes el problema añadiendo almacenamiento sin un límite operativo.

La respuesta de rechazo debe ser coherente con la interfaz de tu servicio. Explica que no se admitió la tarea o indica que la capacidad está temporalmente ocupada, sin afirmar que el modelo la procesó. Cuando la aplicación pueda intentarlo más tarde, proporciona una señal clara y documentada para que el cliente tome esa decisión. Evita prometer un tiempo de espera exacto si no puedes sostenerlo con mediciones.

La admisión puede combinar condiciones: capacidad de concurrencia disponible, cola por debajo del máximo, cuota por usuario y presupuesto de espera restante. Evalúa las condiciones antes de reservar recursos y libera la reserva al completar, cancelar o expirar la tarea. Si una solicitud se cancela en el cliente pero continúa ocupando un puesto local, la medición de concurrencia deja de representar el trabajo que realmente se mantiene activo.

Establece el orden de prioridad de manera explícita. Por ejemplo, puedes reservar una fracción de la capacidad para tareas interactivas y limitar las tareas por lotes, siempre que esas categorías existan en tu producto y que la política no deje indefinidamente sin servicio a la categoría de menor prioridad. El objetivo no es inventar una prioridad universal, sino reflejar el valor y el plazo de cada clase de trabajo.

Pondera el trabajo sin fingir que conoces el coste exacto

Contar solicitudes da una regla simple, pero trata del mismo modo tareas que pueden diferir mucho. Una alternativa es asignar un peso estimado a cada solicitud usando señales disponibles antes del envío: tokens de entrada estimados, longitud prevista de salida, clase de tarea o medidas históricas de duración para ese tipo de operación. El peso puede servir para priorizar, limitar presupuestos o decidir si la tarea cabe en la cola.

Una estimación no es una garantía. La respuesta generada puede ser más corta o más larga de lo esperado; la duración puede variar aunque las entradas tengan tamaños parecidos. Por ello, calibra la estimación comparándola con resultados observados, conserva márgenes y revisa los errores de predicción. Si la salida real se registra, úsala para mejorar políticas futuras, no para presentar como conocido un dato que no estaba disponible al admitir la solicitud.

Una opción práctica es asignar límites separados por clase o reservar una cantidad de trabajo prevista por ventana. Otra es usar un sistema de créditos internos donde cada solicitud consume un peso estimado y la capacidad se repone según la política local. En ambos casos, documenta cómo se calcula el peso, cómo se corrige y qué ocurre cuando una petición supera lo previsto. No presentes una contabilidad local de tokens como si fuera idéntica a la cuota del proveedor.

Compara las políticas con el mismo conjunto de solicitudes y la misma carga. Si una política ponderada reduce los picos de espera para trabajos pequeños, comprueba también qué pasa con las tareas grandes: podrían quedar desplazadas repetidamente. El criterio de éxito debe considerar el rendimiento agregado, la latencia por clase y la proporción de tareas que termina dentro del plazo, no solo una métrica favorable para las solicitudes más cortas.

Prioridad, equidad y protección frente al bloqueo

Una sola cola puede ser suficiente para un producto con tareas equivalentes, pero tiene riesgos cuando combina trabajos urgentes y tareas largas. Una tarea prolongada al principio puede hacer que otras esperen aunque sean breves. Además, si un cliente genera una parte desproporcionada de la demanda, puede consumir la capacidad compartida y perjudicar a los demás.

Puedes separar colas por clase de servicio, establecer cuotas por usuario o limitar el número de tareas simultáneas por cliente. También puedes reservar capacidad para el tráfico interactivo y procesar el trabajo por lotes con el margen restante. Estas son opciones de diseño, no una garantía de equidad: la prioridad, el tamaño de las reservas y la regla de selección deben probarse con los patrones reales de uso.

Define qué significa equidad en tu caso. Puede ser que cada cliente reciba una oportunidad de progreso, que las tareas interactivas cumplan un plazo o que ningún usuario consuma todo el presupuesto local. Una cuota muy estricta por usuario puede proteger contra el acaparamiento, pero también desaprovechar capacidad cuando otros usuarios no están activos. Una cuota demasiado flexible puede no proteger a los clientes pequeños durante una ráfaga.

Para evitar que una prioridad baja quede relegada indefinidamente, considera límites máximos de espera, envejecimiento de prioridad u oportunidades mínimas de servicio. Mide el tiempo en cola por clase y cliente, no solo el promedio global. Si las categorías tienen plazos distintos, registra cuántas completan a tiempo y cuántas caducan. Una política que mejora la latencia de una clase a costa de hacer inútil otra debe presentarse como una decisión explícita del producto.

Presupuestos de espera, cancelación y caducidad

Cada tarea debería tener un plazo útil definido por el producto, aunque ese plazo no se exponga directamente al usuario. Si una petición permanece en cola más allá del tiempo en el que aún puede aportar valor, conservarla solo acumula trabajo atrasado. Asigna un presupuesto de espera máximo y vuelve a comprobarlo antes de enviar la tarea al proveedor.

La caducidad en cola y la cancelación después del envío no son lo mismo. Antes del envío, retirar una tarea puede evitar iniciar trabajo que ya no se necesita. Después del envío, el efecto de cancelar depende de las capacidades de la integración y del comportamiento documentado del endpoint. No supongas que cerrar una conexión detiene el procesamiento remoto o revierte el consumo. Instrumenta lo que el sistema puede observar y describe las limitaciones.

Registra cuántas solicitudes vencen antes de empezar y cuántas se cancelan en curso. Si muchas expiran en cola, revisa el tamaño de la cola, la tasa de admisión y el presupuesto de espera. Si se cancelan después de enviarse, investiga si una política más temprana de caducidad o una interfaz que permita al usuario retirar el trabajo reduciría tareas inútiles. No deduzcas ahorro de coste sin una medición que respalde esa conclusión.

La caducidad también ayuda a controlar prioridades: una tarea urgente que ya perdió su plazo no debería seguir ocupando el primer lugar simplemente porque llegó antes. Sin embargo, descartar automáticamente trabajo puede tener consecuencias funcionales. Define si se informa del vencimiento, si se conserva para una ejecución posterior o si se elimina; el comportamiento debe ser previsible para quien integra el servicio.

Prueba de carga reproducible y operación

Prueba la política antes de aplicarla ampliamente. Construye un conjunto representativo de tareas que incluya entradas y salidas de diferentes longitudes y las clases de prioridad que realmente usará el producto. Ejecuta una carga base, después aumenta la concurrencia por etapas y añade ráfagas controladas. Mantén constante el conjunto de solicitudes al comparar variantes para que las diferencias no dependan de haber probado tareas distintas.

Define de antemano los criterios de parada y reversión. Por ejemplo, puedes detener el aumento si el p99 supera el objetivo acordado, si crecen las expiraciones o los errores, o si el tiempo en cola rebasa el presupuesto de producto. Los valores concretos deben proceder de tus objetivos, mediciones y condiciones de la API, no de una cifra universal. Registra configuración, fecha, versión de cliente y parámetros de la prueba para poder repetirla.

Descompón la latencia: tiempo de espera local, tiempo hasta la primera respuesta cuando sea relevante y duración completa. Compara también solicitudes completadas, respuestas de límite alcanzado, cancelaciones, percentiles por clase y coste por tarea completada. Si solo miras el rendimiento total, podrías pasar por alto que una clase está fallando; si solo miras una respuesta de error, podrías no detectar que el problema fue una cola local que empezó a crecer antes de llamar al proveedor.

En operación, revisa las cuotas publicadas para el canal concreto y vigila los encabezados o campos de respuesta documentados por ese servicio. Esas señales ayudan a reconocer límites y a informar al sistema de observabilidad, pero su disponibilidad y significado dependen de la API. No supongas que un encabezado existe en todas las respuestas ni que permanece invariable. Conserva la fecha de revisión de la documentación y verifica cambios antes de actualizar controles.

Un despliegue prudente comienza con límites locales conservadores, observabilidad y una forma de volver a la configuración anterior. Después se aumenta la admisión de manera gradual si los resultados sostienen esa decisión. Si las métricas empeoran, reduce la entrada, acorta la cola o ajusta las clases de trabajo; no respondas automáticamente a una latencia creciente ampliando la cola, porque eso puede esconder la saturación y alargar las esperas.

Límites del enfoque y criterios prácticos

No existe una cifra de concurrencia que pueda trasladarse con seguridad a todas las integraciones. Las cuotas y condiciones pueden variar por servicio, modelo, proyecto, región y canal. Además, las cuotas pueden cambiar y una respuesta observada en una prueba no demuestra que la misma capacidad estará disponible en otra configuración o momento. Consulta las fuentes oficiales aplicables y verifica los límites antes de convertirlos en reglas permanentes.

Tampoco hay una fórmula única que traduzca tokens o solicitudes por segundo en una latencia garantizada. La relación entre llegada, permanencia y población media ayuda a razonar sobre el crecimiento de una cola, pero no sustituye una prueba representativa ni predice cada respuesta. Los tamaños de salida y las duraciones observadas aportan información; las estimaciones previas sirven para admitir con prudencia, no para asegurar un resultado exacto.

Antes de aprobar una política, comprueba que sabes cuántas solicitudes están en curso y esperando; que la cola tiene un máximo y una caducidad; que la admisión considera los tamaños de trabajo relevantes; y que existe una respuesta clara cuando no se acepta una tarea. Asegúrate también de que las prioridades no dejan a una clase sin servicio, que las cancelaciones se miden en el estado correcto y que las métricas separan espera local y procesamiento remoto.

Por último, conserva la distinción entre control de carga y recuperación ante errores. La admisión decide cuánta demanda entra y cuánto trabajo espera. Los reintentos deciden cómo reaccionar después de un fallo o resultado ambiguo. Un sistema robusto necesita políticas compatibles para ambas fases, pero una no reemplaza a la otra: primero evita aceptar más trabajo del que puedes gestionar; después define, por separado, cómo responder a los fallos.

Continúa explorando

Correcciones y transparencia

Si detectas un dato incorrecto o desactualizado, puedes enviarnos una corrección indicando la página y la fuente que debemos revisar.