Runpod muestra cómo GuideLLM ayuda a exprimir al máximo vLLM

Runpod ha publicado en su blog una guía sobre la combinación de vLLM y GuideLLM. La idea es sencilla: antes de ofrecer un modelo a los usuarios, simula tráfico real y fíjate en tres cifras: el tiempo hasta el primer token, la latencia entre tokens y el rendimiento. Ellas determinan cuántas GPU necesitarás y cuánto pagarás por millón de tokens. La publicación original es breve y se parece más al anuncio de una guía práctica, así que no incluye benchmarks concretos con tarjetas. Aun así, la metodología merece un análisis.

Por qué «va rápido en mi portátil» no significa nada

vLLM se ha convertido desde hace tiempo en uno de los motores estándar para la inferencia de modelos abiertos. Usa batching continuo y PagedAttention para gestionar la KV-cache, y funciona muy bien con unas pocas solicitudes. Los problemas empiezan bajo carga. Cuando llegan a la vez decenas de solicitudes con prompts de distinta longitud, la caché se llena, la cola crece y la latencia del primer token puede multiplicarse varias veces.

Una sola solicitud no revela nada de esto. Hace falta un generador de carga que se comporte como los usuarios: las solicitudes no llegan de una en una, sino en oleadas, y los prompts y las respuestas tienen longitudes distintas. Para eso se creó GuideLLM, una herramienta abierta del ecosistema de vLLM. Se conecta a un endpoint compatible con OpenAI, envía solicitudes sintéticas o las que tú definas y recopila estadísticas.

Cómo es una ejecución

El esquema en Runpod es el habitual. Levantas un pod o un worker serverless con vLLM, obtienes la dirección del endpoint y lanzas GuideLLM desde ese mismo entorno o desde otra máquina. Después defines el perfil de carga: longitud de entrada y de salida en tokens, modo de envío de solicitudes y duración.

Normalmente están disponibles la tasa fija, el flujo de Poisson, el modo de máximo rendimiento y la ejecución secuencial, en la que el servidor no se sobrecarga. Para un primer reconocimiento resulta útil el modo sweep: recorre una carga creciente y muestra dónde se rompe la curva de latencia. Los nombres exactos de los flags cambian de una versión a otra, así que conviene contrastarlos con la documentación.

A la salida obtienes un informe con los siguientes indicadores:

• TTFT, tiempo hasta el primer token: determina lo ágil que parece el chat;
• ITL, latencia entre tokens: de ella depende la fluidez del streaming;
• latencia total de la solicitud completa, importante para las API y las cadenas de agentes;
• solicitudes por segundo que el servidor aguanta antes de degradarse;
• tokens por segundo por tarjeta, la cifra clave para calcular el coste;
• número de solicitudes simultáneas a partir del cual crecen las colas.

Lo importante es compararlos. Si el TTFT se mantiene dentro del valor objetivo con una carga determinada y después se dispara, ese es tu techo de trabajo con la configuración actual.

En la práctica: de las métricas a la factura de GPU

El orden de actuación es este.

1. Describe tu tráfico real: longitud media y máxima del prompt, longitud de la respuesta y carga pico. Si todavía no tienes logs, usa estimaciones prudentes y afínalas más adelante.

2. Fija los valores objetivo de TTFT e ITL. Serán distintos para una interfaz de chat y para el procesamiento por lotes de documentos.

3. Ejecuta sweep en varias configuraciones: distintas GPU, distinta cuantización y distintos valores de longitud máxima de contexto y de proporción de memoria destinada a la KV-cache. 4.

Para cada configuración, busca la carga máxima con la que se cumplen los objetivos y divide el precio por hora de la tarjeta entre el número de tokens obtenido. Ese es el precio real del token. 5.

En despliegues serverless, comprueba además el arranque en frío y el comportamiento ante un aumento brusco de la cola; un benchmark estático no los mostrará.

Hay una salvedad. La carga sintética sigue siendo un modelo, no la realidad. Si tus usuarios tienen prompts de sistema largos con un prefijo común, activar la caché de prefijos cambiará el panorama, y la prueba debe diseñarse teniéndolo en cuenta. Además, los resultados dependen de la versión de vLLM, de los drivers y de la tarjeta concreta, por lo que conviene repetir la ejecución tras las actualizaciones.

El principal valor de una guía así es la disciplina. Elegir GPU y configuración por intuición suele acabar en un sobrecoste por una reserva de capacidad que nadie usa. Media hora de pruebas de carga da cifras que se pueden poner sobre la mesa del responsable financiero.