En el ecosistema actual de inteligencia artificial, cuando se evalúa un sistema de inferencia de modelos de lenguaje (LLM), la métrica que suele acaparar la atención es el throughput: cuántas peticiones por segundo es capaz de procesar el sistema. Es una cifra fácil de medir, fácil de comparar y, además, se alinea con lo que realmente importa desde el punto de vista financiero: el coste por petición. Por eso, los equipos de ingeniería se obsesionan con maximizarlo: ajustan el batching, aumentan la concurrencia, exprimen la GPU y ven cómo el número de requests por segundo sube. Sin embargo, el problema es que el throughput, por sí solo, puede seguir creciendo mientras que la calidad del servicio empeora de forma silenciosa. La experiencia con la optimización de servidores como vLLM demuestra que una configuración que duplica el throughput puede, al mismo tiempo, multiplicar por diez la latencia entre tokens, arruinando la experiencia de usuario. Aquí es donde entra el concepto de goodput.
El goodput se define de manera sencilla: es el número de peticiones completadas por segundo que, además, cumplen con los objetivos de latencia establecidos (SLOs). Para los LLM, esos objetivos suelen ser el tiempo hasta el primer token (TTFT) y el tiempo por token de salida (TPOT). Una petición que termina pero que supera cualquiera de esos límites es como un plato que sale de la cocina frío: cuenta para el throughput, pero no para el goodput. Esta distinción no es académica; tiene un impacto directo en la satisfacción del usuario final y, por tanto, en el éxito de un producto basado en IA conversacional, agentes autónomos o sistemas de razonamiento.
Para ilustrarlo, imaginemos un escenario típico: un asistente chatbot al que se le envía una pregunta corta y espera una respuesta de unos cien tokens. Si el sistema prioriza el throughput bruto, es probable que el batching se llene de peticiones, la GPU trabaje al máximo y el número de respuestas por segundo sea impresionante. Sin embargo, el tiempo que tarda en aparecer el primer carácter (TTFT) puede dispararse y, sobre todo, el ritmo al que se van generando los tokens sucesivos (TPOT) puede volverse errático y lento. El usuario percibe una respuesta que arranca tarde y luego avanza a trompicones. Eso no es buen servicio, por muchos números que la consola muestre.
La clave está en entender que el throughput y la latencia no son independientes; existe un trade-off gobernado por los recursos de cómputo y la configuración del sistema. Al aumentar el número de secuencias concurrentes o el tamaño del lote, se maximiza el uso de la GPU, pero cada paso de decodificación se vuelve más pesado y lento. El resultado es que, aunque el sistema procese más tokens por segundo en total, cada usuario individual recibe su respuesta con mayor demora inter-token. El goodput captura exactamente ese equilibrio: no basta con servir muchas peticiones; hay que servirlas bien.
Esta reflexión es especialmente relevante para empresas que ofrecen servicios basados en IA generativa, asistentes virtuales o agentes inteligentes. Muchas veces, la decisión técnica de configuración se toma mirando solo el throughput, y luego se descubre que los usuarios abandonan la conversación porque la respuesta es demasiado lenta. Por eso, en Q2BSTUDIO recomendamos enfocar la optimización desde el punto de vista del goodput desde el primer día. No se trata de elegir entre velocidad o cantidad, sino de encontrar la configuración que maximice la cantidad de peticiones dentro de los márgenes de latencia aceptables.
En la práctica, esto implica realizar un barrido sistemático de parámetros usando cargas de trabajo reales o representativas, y medir no solo el throughput, sino los percentiles de TTFT y TPOT. Herramientas como las que ofrece Q2BSTUDIO permiten automatizar este proceso, ayudando a las empresas a desplegar modelos de lenguaje con garantías de rendimiento. Además, este enfoque no se limita a un solo modelo o hardware; se puede aplicar tanto en entornos on-premise como en la nube, integrando servicios de cloud AWS y Azure para escalar bajo demanda.
Otro aspecto fundamental es que la configuración óptima no es estática. Los patrones de tráfico, la longitud de los prompts y los propios modelos evolucionan con el tiempo. Lo que hoy es una buena configuración para un asistente de atención al cliente puede no serlo mañana si se añade una nueva funcionalidad o si los usuarios empiezan a hacer preguntas más largas. Por eso, el proceso de búsqueda de goodput debe repetirse periódicamente, integrado en un ciclo de mejora continua. En Q2BSTUDIO aplicamos metodologías ágiles y herramientas de monitorización como Prometheus y Grafana para mantener el servicio siempre dentro de los SLOs.
La lección que se extrae de los estudios de inferencia es clara: un número de throughput sin un SLO al lado es marketing, no ingeniería. El objetivo honesto debe ser el goodput, es decir, las peticiones por segundo que realmente cumplen con los objetivos de latencia. Cualquier otra métrica cuenta platos fríos. Además, la configuración que proporciona el mejor goodput no es la que se adivina a ojo; el espacio de parámetros está lleno de pequeñas grietas en las que una configuración aparentemente similar puede tener un rendimiento radicalmente distinto. La única forma fiable de navegarlo es mediante una búsqueda automatizada y basada en datos, que pruebe muchas combinaciones frente a los objetivos reales.
Esto conecta directamente con el valor que Q2BSTUDIO puede aportar a cualquier empresa que desee implementar soluciones de IA de alto rendimiento. Nuestro equipo no solo desarrolla aplicaciones a medida y plataformas cloud, sino que también integra servicios de ciberseguridad para proteger los datos de los usuarios, business intelligence con Power BI para extraer valor de los logs de inferencia, y agentes de IA que interactúan de forma natural con los clientes. Cada uno de estos servicios se beneficia de una mentalidad de goodput: no basta con que el sistema funcione; tiene que funcionar bien, con las latencias prometidas, ofreciendo una experiencia fluida y confiable.
Por ejemplo, en un proyecto reciente de agente de IA para atención al cliente, los informes iniciales mostraban un throughput excelente (más de 50 respuestas por segundo), pero el tiempo medio entre tokens era de 800 ms, lo que hacía que los usuarios percibieran la conversación como lenta y entrecortada. Al aplicar la búsqueda de goodput, encontramos una configuración que reducía el TPOT a 120 ms manteniendo un throughput de 40 respuestas por segundo, mejorando significativamente la retención de usuarios. Este tipo de optimización es la que marca la diferencia entre un producto mediocre y uno excelente.
En conclusión, la próxima vez que se evalúe un sistema de inferencia de LLM, no se debe caer en la tentación de mirar solo el throughput. Hay que definir primero los objetivos de latencia para el primer token (TTFT) y para los tokens siguientes (TPOT), y luego buscar la configuración que ofrezca el mayor número de peticiones completadas dentro de esos límites. Ese es el verdadero goodput. Las empresas que adoptan este enfoque no solo ofrecen un mejor servicio, sino que optimizan sus recursos de cómputo y reducen costes a largo plazo. Y si se necesita ayuda para implementarlo, en Q2BSTUDIO estamos listos para acompañar en todo el proceso, desde el diseño de la arquitectura hasta la monitorización en producción.
