Ajustar el servicio Flame para igualar el rendimiento de vLLM independiente

Los investigadores compararon el rendimiento de Flame, un framework de servicio basado en Python que integra vLLM, frente a instancias independientes de vLLM. Publicado el 24 de octubre de 2026, el estudio detalla cómo estrategias específicas de ajuste permitieron a Flame alcanzar casi la paridad con el motor de referencia en dos GPUs NVIDIA B200. Los resultados destacan la importancia del almacenamiento en caché de prefijos y la admisión asíncrona de solicitudes para minimizar la sobrecarga en los despliegues de modelos de lenguaje grandes.

Qué ocurrió

La evaluación se centró en dos cargas de trabajo distintas utilizando el modelo Llama 3.1 8B Instruct. La primera carga de trabajo involucró 64 solicitudes sin reutilización de documentos, mientras que la segunda involucró 256 solicitudes donde se hicieron cuatro preguntas sobre cada uno de cuatro documentos, lo que permitió la reutilización de prefijos. En ambos escenarios, el sistema procesó ráfagas cortas y finitas de tráfico en lugar de cargas sostenidas en estado estacionario. El objetivo era determinar si Flame podía mantener al menos el 99% del rendimiento logrado por una configuración cuidadosamente ajustada de vLLM independiente.

Las pruebas iniciales revelaron una brecha significativa al usar configuraciones predeterminadas. Sin embargo, después de implementar la colocación persistente de workers para mejorar la reutilización de la caché, los investigadores redujeron gran parte de la diferencia. Las optimizaciones adicionales incluyeron el aumento de los tamaños de lote, el cambio a la admisión asíncrona del motor y la aplicación de compresión sin pérdidas a las entradas. En la configuración final, el rendimiento mediano de finalización de Flame fue solo un 0,55% inferior al de vLLM independiente sin reutilización de documentos y un 0,86% inferior con reutilización de prefijos. Aunque dos de los cinco pares de ensayos no alcanzaron el estricto objetivo del 99% durante las pruebas de reutilización, la desviación en el peor de los casos fue de apenas un 2,03%.

Cómo funciona

El mecanismo central para mejorar el rendimiento en ambos sistemas fue la afinidad de prefijos. Cuando un asistente responde múltiples preguntas sobre el mismo documento, procesa repetidamente los mismos tokens iniciales. Al mantener ese prefijo en una sola GPU, el sistema evita reconstruir las claves y valores de atención desde cero. Los investigadores implementaron un mapa en el lado del cliente que aplica hash a bloques de tokens para asignar prefijos no vistos a la partición (shard) con la menor cantidad estimada de trabajo de prellenado (prefill). Esto aseguró que las preguntas posteriores sobre un documento específico siempre llegaran al mismo worker, permitiendo que vLLM reutilizara eficazmente los bloques KV residentes.

Más allá del almacenamiento en caché, el equipo abordó cómo se admitían las solicitudes al motor de inferencia. El adaptador original de Flame pasaba los lotes de forma síncrona, haciendo que las tareas posteriores esperaran a que se completaran las invocaciones actuales. La versión optimizada utilizó una API asíncrona que admitía todas las solicitudes de un lote concurrentemente. También empleó compresión zlib nivel 1 para reducir el tamaño de las entradas transmitidas, lo cual es particularmente efectivo para prompts con mucho texto. Finalmente, congelar el heap de inicio de Python redujo las pausas de recolección de basura durante la inferencia, estabilizando aún más el rendimiento.

Detalles clave

• Los experimentos utilizaron dos GPUs NVIDIA B200 ejecutando vLLM 0.28.0 y Torch 2.13.0+cu130.
• La afinidad de prefijos aumentó el rendimiento mediano en un 77,5% para vLLM independiente y en un 73,4% para Flame en escenarios de reutilización.
• El rendimiento mediano final de Flame fue de 7,586 solicitudes/s sin reutilización y de 28,350 solicitudes/s con reutilización.
• La compresión de entrada redujo el tamaño de la entrada codificada del servicio para la ráfaga de reutilización de más de 6 MB a aproximadamente 388 KB.
• Congelar el heap de inicio redujo las pausas máximas de recolección de basura por worker de 8,80 ms a 4,59 ms.
• El estudio no demostró una ventaja de rendimiento derivada del planificador consciente de datos de Flame en estas pruebas específicas.

Por qué importa

Para los ingenieros que construyen servicios LLM en producción, esta comparación aclara de dónde proviene realmente la sobrecarga en los frameworks de servicio envueltos. Muestra que la penalización por usar una capa de orquestación de alto nivel como Flame no es inherente a la arquitectura, sino que surge de los valores predeterminados subóptimos de agrupamiento (batching) y sincronización. Al comprender que la localidad de prefijos y la admisión asíncrona son críticas, los desarrolladores pueden ajustar sus propias stacks para minimizar los picos de latencia y maximizar la utilización de la GPU.

Los hallazgos también advierten contra asumir que las características del framework se traducen automáticamente en ganancias de rendimiento. El planificador consciente de datos en Flame no superó al mapeo explícito del cliente más simple utilizado en las pruebas. Esto sugiere que, para muchos casos de uso, las estrategias de enrutamiento directas combinadas con una gestión cuidadosa de recursos pueden ser más efectivas que los algoritmos de planificación complejos. Los equipos deben priorizar factores medibles como las tasas de aciertos de caché y la ocupación de lotes sobre las ventajas teóricas de planificación.

Qué puedes hacer

• Implementa la afinidad de prefijos en tu enrutamiento de cliente para asegurar que las solicitudes que comparten contexto lleguen a la misma réplica de GPU.
• Cambia a APIs asíncronas para la admisión al motor para evitar que el procesamiento de lotes bloquee nuevas solicitudes.
• Habilita la compresión sin pérdidas para entradas con mucho texto para reducir la sobrecarga de red y memoria durante la transferencia.
• Ajusta las ventanas y límites de formación de lotes para equilibrar entre latencia y rendimiento según tus patrones de tráfico.
• Monitorea las pausas de recolección de basura y considera congelar objetos de larga vida durante la inicialización del worker.
• Valida el rendimiento con pruebas de ráfagas finitas que imiten tus patrones de uso reales, incluyendo escenarios de reutilización de prefijos.