El servicio de LLM de producción es ahora un problema del sistema, no un bucle generate(). Para cargas de trabajo reales, la elección de la pila de inferencia impulsa los tokens por segundo, la latencia de cola y, en última instancia, el costo por millón de tokens en una flota de GPU determinada.
Esta comparación se centra en 4 pilas ampliamente utilizadas:
vLLM NVIDIA TensorRT-LLM Inferencia de generación de texto de cara abrazada (TGI v3) LMDeploy
1. vLLM, PagedAttention como línea de base abierta
idea central
vLLM se basa en PagedAttention, una implementación de atención que trata la caché KV como una memoria virtual paginada en lugar de un único búfer contiguo por secuencia.
En lugar de asignar una región KV grande por solicitud, vLLM:
Divide la caché KV en bloques de tamaño fijo Mantiene una tabla de bloques que asigna tokens lógicos a bloques físicos Comparte bloques entre secuencias dondequiera que los prefijos se superpongan
Esto reduce la fragmentación externa y permite que el programador empaquete muchas más secuencias simultáneas en la misma VRAM.
Rendimiento y latencia
vLLM mejora el rendimiento entre 2 y 4 veces con respecto a sistemas como FasterTransformer y Orca con una latencia similar, con mayores ganancias para secuencias más largas.
Propiedades clave para los operadores:
El procesamiento por lotes continuo (también llamado procesamiento por lotes en vuelo) fusiona las solicitudes entrantes en lotes de GPU existentes en lugar de esperar ventanas de lotes fijas. En cargas de trabajo de chat típicas, el rendimiento aumenta casi linealmente con la simultaneidad hasta que la memoria KV o el cálculo se saturan. La latencia de P50 sigue siendo baja para una simultaneidad moderada, pero P99 puede degradarse una vez que las colas son largas o la memoria KV es escasa, especialmente para consultas pesadas de llenado previo.
vLLM expone una API HTTP compatible con OpenAI y se integra bien con Ray Serve y otros orquestadores, por lo que se utiliza ampliamente como base abierta.
KV y multiinquilino
PagedAttention ofrece un desperdicio de KV casi nulo y un uso compartido flexible de prefijos dentro y entre solicitudes. Cada proceso vLLM sirve a un modelo, las configuraciones de múltiples inquilinos y múltiples modelos generalmente se crean con un enrutador externo o una puerta de enlace API que se distribuye en múltiples instancias de vLLM.
2. TensorRT-LLM, máximo de hardware en las GPU NVIDIA
idea central
TensorRT-LLM es la biblioteca de inferencia optimizada de NVIDIA para sus GPU. La biblioteca proporciona núcleos de atención personalizados, procesamiento por lotes en vuelo, almacenamiento en caché de KV paginado, cuantificación hasta FP4 e INT4 y decodificación especulativa.
Está estrechamente acoplado al hardware de NVIDIA, incluidos los núcleos tensores FP8 en Hopper y Blackwell.
Rendimiento medido
La evaluación de NVIDIA H100 vs A100 es la referencia pública más concreta:
En H100 con FP8, TensorRT-LLM alcanza más de 10 000 tokens de salida/s con un rendimiento máximo para 64 solicitudes simultáneas, con un tiempo de ~100 ms hasta el primer token. H100 FP8 logra un rendimiento máximo hasta 4,6 veces mayor y una latencia del primer token 4,4 veces más rápida que el A100 en los mismos modelos.
Para modos sensibles a la latencia:
TensorRT-LLM en H100 puede controlar TTFT por debajo de 10 ms en configuraciones del lote 1, a costa de un menor rendimiento general.
Estos números son específicos del modelo y la forma, pero dan una escala realista.
Precarga vs decodificación
TensorRT-LLM optimiza ambas fases:
El precarga se beneficia de los núcleos de atención de alto rendimiento del FP8 y el paralelismo tensorial. La decodificación se beneficia de los gráficos CUDA, la decodificación especulativa, los pesos cuantificados y KV, y la fusión del núcleo.
El resultado son tokens/s muy altos en una amplia gama de longitudes de entrada y salida, especialmente cuando el motor está ajustado para ese modelo y perfil de lote.
KV y multiinquilino
TensorRT-LLM proporciona:
Caché KV paginado con diseño configurable Soporte para secuencias largas, reutilización y descarga de KV Procesamiento por lotes en vuelo y primitivas de programación con reconocimiento de prioridades
NVIDIA combina esto con patrones de orquestación basados en Ray o Triton para clústeres de múltiples inquilinos. La compatibilidad con múltiples modelos se realiza a nivel del orquestador, no dentro de una única instancia del motor TensorRT-LLM.
3. Hugging Face TGI v3, especialista en avisos prolongados y puerta de enlace multibackend
idea central
Text Generation Inference (TGI) es una pila de servicio basada en Rust y Python que agrega:
API HTTP y gRPC Programador de procesamiento por lotes continuo Ganchos de observabilidad y escalado automático Backends conectables, incluidos motores de estilo vLLM, TensorRT-LLM y otros tiempos de ejecución
La versión 3 se centra en el procesamiento de mensajes prolongados mediante fragmentación y almacenamiento en caché de prefijos.
Comparativa rápida larga frente a vLLM
Los documentos TGI v3 brindan un punto de referencia claro:
En mensajes largos con más de 200.000 tokens, una respuesta de conversación que tarda 27,5 s en vLLM se puede entregar en aproximadamente 2 s en TGI v3. Esto se informa como una aceleración de 13 veces en esa carga de trabajo. TGI v3 es capaz de procesar aproximadamente 3 veces más tokens en la misma memoria de GPU al reducir su huella de memoria y explotar la fragmentación y el almacenamiento en caché.
El mecanismo es:
TGI mantiene el contexto de la conversación original en un caché de prefijo, por lo que los turnos posteriores solo pagan por tokens incrementales. La sobrecarga de búsqueda de caché es del orden de microsegundos, insignificante en relación con el cálculo previo al llenado.
Esta es una optimización específica para cargas de trabajo donde las indicaciones son extremadamente largas y se reutilizan en todos los turnos, por ejemplo, canalizaciones RAG y resúmenes analíticos.
Arquitectura y comportamiento de latencia.
Componentes clave:
Fragmentación, las indicaciones muy largas se dividen en segmentos manejables para KV y programación Almacenamiento en caché de prefijos, estructura de datos para compartir contexto largo entre turnos Procesamiento por lotes continuo, las solicitudes entrantes unen lotes de secuencias ya en ejecución PagedAttention y núcleos fusionados en los backends de la GPU
Para cargas de trabajo de estilo chat corto, el rendimiento y la latencia están en el mismo nivel que vLLM. Para contextos prolongados que se pueden almacenar en caché, la latencia P50 y P99 mejoran en un orden de magnitud porque el motor evita el llenado previo repetido.
Multi backend y multi modelo
TGI está diseñado como una arquitectura de servidor modelo enrutador más. Puede:
Enrute solicitudes a través de muchos modelos y réplicas. Diríjase a diferentes backends, por ejemplo, TensorRT-LLM en H100 plus CPU o GPU más pequeñas para tráfico de baja prioridad.
Esto lo hace adecuado como nivel de servicio central en entornos de múltiples inquilinos.
4. LMDeploy, TurboMind con KV bloqueado y cuantificación agresiva
idea central
LMDeploy del ecosistema InternLM es un conjunto de herramientas para comprimir y servir LLM, centrado en el motor TurboMind. Se centra en:
Servicio de solicitudes de alto rendimiento Caché KV bloqueado Loteo persistente (lotes continuos) Cuantización de pesos y caché KV
Rendimiento relativo frente a vLLM
El proyecto establece:
‘LMDeploy ofrece un rendimiento de solicitudes hasta 1,8 veces mayor que vLLM’, con el soporte de lotes persistentes, KV bloqueado, división y fusión dinámica, paralelismo tensorial y núcleos CUDA optimizados.
KV, cuantificación y latencia.
LMDeploy incluye:
Caché KV bloqueado, similar al KV paginado, que ayuda a empaquetar muchas secuencias en VRAM Soporte para cuantificación de caché KV, generalmente int8 o int4, para reducir la memoria y el ancho de banda de KV Rutas de cuantificación de solo peso, como AWQ de 4 bits Un arnés de evaluación comparativa que informa el rendimiento del token, el rendimiento de la solicitud y la latencia del primer token
Esto hace que LMDeploy sea atractivo cuando desea ejecutar modelos abiertos más grandes como InternLM o Qwen en GPU de rango medio con una compresión agresiva y al mismo tiempo mantener buenos tokens.
Implementaciones de múltiples modelos
LMDeploy proporciona un servidor proxy capaz de manejar:
Implementaciones de múltiples modelos Configuraciones de múltiples máquinas y múltiples GPU Lógica de enrutamiento para seleccionar modelos según los metadatos de la solicitud
Por lo tanto, arquitectónicamente se encuentra más cerca de TGI que de un solo motor.
¿Qué usar y cuándo?
Si desea un rendimiento máximo y un TTFT muy bajo en las GPU NVIDIA, TensorRT-LLM es la opción principal. Utiliza FP8 y menor precisión, kernels personalizados y decodificación especulativa para impulsar tokens y mantener TTFT por debajo de 100 ms con alta concurrencia y por debajo de 10 ms con baja concurrencia. Si está dominado por mensajes largos con reutilización, como RAG en contextos grandes, TGI v3 es un fuerte valor predeterminado. Su caché de prefijo y fragmentación dan hasta Capacidad de token 3 veces y latencia 13 veces menor que vLLM en pruebas comparativas rápidas publicadas, sin configuración adicional. Si desea un motor simple y abierto con un rendimiento básico sólido y una API de estilo OpenAI, vLLM sigue siendo la línea base estándar. PagedAttention y el procesamiento por lotes continuo lo hacen entre 2 y 4 veces más rápido que las pilas más antiguas con latencia similar y se integra limpiamente con Ray y K8. Si apunta a modelos abiertos como InternLM o Qwen y valora la cuantificación agresiva con servicio de múltiples modelos. LMDeploy es una buena opción. La caché KV bloqueada, el procesamiento por lotes persistente y la cuantificación KV int8 o int4 brindan un rendimiento de solicitudes hasta 1,8 veces mayor que vLLM en los modelos compatibles, con una capa de enrutador incluida.
En la práctica, muchos equipos de desarrollo combinan estos sistemas, por ejemplo, utilizando TensorRT-LLM para chat propietario de gran volumen, TGI v3 para análisis de contexto prolongado, vLLM o LMDeploy para cargas de trabajo experimentales y de modelos abiertos. La clave es alinear el rendimiento, las colas de latencia y el comportamiento de KV con las distribuciones reales de tokens en su tráfico y luego calcular el costo por millón de tokens a partir de los tokens medidos en su propio hardware.
Referencias
Descripción general y rendimiento de vLLM / PagedAttention TensorRT-LLM Inferencia de generación de texto HF (TGI v3) Comportamiento de aviso prolongado LMDeploy / TurboMind
Michal Sutter es un profesional de la ciencia de datos con una Maestría en Ciencias de Datos de la Universidad de Padua. Con una base sólida en análisis estadístico, aprendizaje automático e ingeniería de datos, Michal se destaca en transformar conjuntos de datos complejos en conocimientos prácticos.
🙌 Siga MARKTECHPOST: agréguenos como fuente preferida en Google.