TensorRT-LLM vs vLLM: Comparativa de Rendimiento, Latencia y Throughput en Producción

1. La Batalla por la Eficiencia en el Servidor de Inferencia

Servir modelos de lenguaje a gran escala en centros de datos implica resolver dos problemas simultáneos: reducir la latencia de respuesta para el usuario final (Time-to-First-Token y latencia por token) y maximizar la cantidad total de tokens procesados por segundo (throughput) para rentabilizar las costosas tarjetas gráficas empresariales. En este escenario compiten dos filosofías arquitectónicas profundamente diferenciadas: la agilidad dinámica basada en Python/C++ de vLLM y la compilación estática de bajo nivel en silicio de TensorRT-LLM.

2. Arquitectura de vLLM: PagedAttention y Flexibilidad Dinámica

vLLM revolucionó el sector de la inferencia al abordar el problema del desperdicio de memoria en el Key-Value (KV) Cache. En sistemas tradicionales, se reservaban bloques contiguos de memoria de vídeo correspondientes al tamaño máximo posible de la secuencia (por ejemplo, 8.192 tokens). Si la respuesta del modelo terminaba tras generar solo 300 tokens, el resto de la memoria quedaba cautiva e inutilizable.

vLLM resolvió este dilema inspirándose en la paginación de memoria virtual de los sistemas operativos modernos:

• PagedAttention: Divide el KV Cache en bloques discretos no contiguos (típicamente de 16 tokens). A medida que la secuencia se expande, se asignan nuevas páginas físicas bajo demanda.
• Continuous Batching (In-Flight Batching): En lugar de esperar a que termine la secuencia más larga de un lote para introducir nuevas peticiones, vLLM incorpora y retira peticiones a nivel de token en cada iteración del bucle de inferencia.
• Integración Abierta: Cualquier modelo compatible con Hugging Face Transformers puede servirse en segundos sin pasos previos de conversión ni compilación offline.

3. Arquitectura de TensorRT-LLM: Fusión Extrema y Grafo Estático

TensorRT-LLM es el motor nativo desarrollado por los propios ingenieros de arquitectura de procesadores de NVIDIA. En lugar de limitarse a cargar pesos en tiempo de ejecución, TensorRT-LLM realiza un proceso de compilación completo que transforma el modelo en un motor binario (engine) optimizado milimétricamente para la microarquitectura de la GPU anfitriona (Ada Lovelace, Hopper, Blackwell).

Entre sus optimizaciones exclusivas destacan:

• Fusión de Kernels Deeply-Fused: Agrupa operaciones que normalmente requerirían múltiples accesos a la memoria global (como RMSNorm + SwiGLU + GEMM) en una única instrucción unificada de CUDA, reduciendo el tráfico en el bus HBM3 al mínimo teórico.
• Planificador en C++ de Ultra Baja Latencia: El bucle de ejecución principal y la orquestación de lotes se ejecutan completamente en C++ nativo, eliminando cualquier jitter o retardo provocado por el Global Interpreter Lock (GIL) de Python.
• Aceleración Nativa FP8 / FP4: Aprovecha de manera directa los núcleos Tensor de cuarta y quinta generación con calibración de cuantización avanzada (SmoothQuant, FP8 E4M3).

4. Comparativa Técnica y Especificaciones

5. Benchmarks en Escenarios de Producción Reales

Pruebas de estrés realizadas en un nodo de 4x NVIDIA H100 80GB SXM5 sirviendo Meta-Llama-3.1-70B-Instruct en precisión FP8 nativa. La carga simuló 120 peticiones concurrentes continuas con prompts de 1.000 tokens y respuestas de 500 tokens:

6. Guía de Despliegue Comparativo

Opción A: Despliegue Inmediato con vLLM

# Servir modelo Llama-3 70B FP8 en 4 GPUs con vLLM
vllm serve neuralmagic/Meta-Llama-3.1-70B-Instruct-FP8 \
  --tensor-parallel-size 4 \
  --max-model-len 8192 \
  --gpu-memory-utilization 0.92 \
  --port 8000

Opción B: Flujo Completo con TensorRT-LLM

# Paso 1: Convertir checkpoint
python3 /app/tensorrt_llm/examples/llama/convert_checkpoint.py \
  --model_dir /models/Llama-3.1-70B-Instruct \
  --output_dir /engines/llama_70b_fp8 \
  --dtype fp8 \
  --tp_size 4

# Paso 2: Compilar el motor optimizado
trtllm-build \
  --checkpoint_dir /engines/llama_70b_fp8 \
  --output_dir /engines/llama_70b_compiled \
  --gemm_plugin fp8 \
  --max_batch_size 128 \
  --max_num_tokens 8192

# Paso 3: Lanzar servidor
python3 -m tensorrt_llm.serve --model /engines/llama_70b_compiled --port 8000

7. Solución de Errores Críticos y Gotchas en Producción

Error 1: 'CUDA driver version is insufficient for CUDA runtime version' al compilar engines

TensorRT-LLM es sumamente estricto con los controladores del host y el toolkit de CUDA. Si el host ejecuta drivers antiguos (e.g. 535.x) e intentas compilar un engine para CUDA 12.4 en un contenedor Docker, la compilación fallará silenciosamente o emitirá errores de símbolos no resueltos en tiempo de carga.

Solución: Asegúrate de que el host disponga de controladores 550.54.14+ para CUDA 12.4 o 560.x+ para CUDA 12.6. Verifica siempre con nvidia-smi que la versión de driver soporte la versión del runtime en el contenedor.

Error 2: 'Out of memory during TensorRT build phase'

El compilador trtllm-build analiza miles de combinaciones de kernels GEMM durante la fase de auto-tuning, requiriendo hasta 64 GB de memoria RAM del sistema además de la VRAM de la GPU. Si la máquina se queda sin memoria durante la construcción, el proceso morirá abruptamente por el OOM Killer del kernel de Linux.

Solución: Añade un archivo de swap temporal de al menos 32 GB antes de compilar modelos de más de 30B parámetros: sudo fallocate -l 32G /swapfile && sudo chmod 600 /swapfile && sudo mkswap /swapfile && sudo swapon /swapfile.

Error 3: Desajuste de topología NVLink en vLLM multi-GPU

Si vLLM se lanza con --tensor-parallel-size 4 en una placa base donde dos de las cuatro tarjetas gráficas no están directamente interconectadas por puentes NVLink físicos, la inicialización de NCCL fallará con NCCL error: unhandled system error / ring exchange timeout.

Solución: Inspecciona la topología exacta con nvidia-smi topo -m. Si hay conexiones de tipo SYS o NODE, fuerza a NCCL a utilizar canales compartidos en memoria PCIe con export NCCL_P2P_LEVEL=NVL o ajusta el tensor parallelism a múltiplos de GPUs adyacentes interconectadas.

8. Checklist de Despliegue Empresarial

• Configura probes de salud de Kubernetes (Liveness y Readiness) apuntando al endpoint /health expuesto tanto en vLLM como en el servidor C++ de TensorRT-LLM.
• Habilita métricas de Prometheus para supervisar el ratio de utilización de KV Cache (vllm:gpu_cache_usage_factor) y el tiempo medio en cola de espera (vllm:avg_waiting_time_seconds).
• Establece políticas de auto-escalado horizontal de pods (HPA) basadas en la profundidad de la cola de inferencia y no en el consumo de CPU o memoria estática.

9. Conclusiones y Cuadro de Mando de Decisión

• Para startups, proyectos ágiles y entornos donde los modelos evolucionan semanalmente, vLLM es indiscutiblemente la mejor elección global por su equilibrio entre rendimiento y facilidad operativa.
• Para gigantes tecnológicos o empresas con productos de inferencia a escala masiva donde la factura mensual de AWS o Lambda Labs supera los 50.000 dólares, la inversión en TensorRT-LLM se amortiza en cuestión de semanas.

8. Optimización del Asignador de Memoria y Ajuste Fino de VRAM

Uno de los mayores desafíos al llevar tanto TensorRT-LLM como vLLM a servidores de alta densidad es el ajuste del asignador de memoria virtual de la GPU. En vLLM, el parámetro --gpu-memory-utilization define la fracción exacta de memoria física que el runtime reserva para alojar tanto los pesos estáticos del modelo como el pool de páginas de PagedAttention:

# Configuración recomendada para exprimir una GPU de 80GB sin colisiones
vllm serve meta-llama/Meta-Llama-3.1-70B-Instruct \
  --tensor-parallel-size 4 \
  --gpu-memory-utilization 0.94 \
  --max-model-len 16384 \
  --enforce-eager \
  --disable-log-stats

El uso de --enforce-eager puede ser necesario en servidores donde CUDA Graphs consume una cantidad desproporcionada de memoria intermedia durante la inicialización, liberando hasta 4 GB adicionales para peticiones concurrentes.

9. Integración con Triton Inference Server para Despliegues de Nivel Enterprise

En infraestructuras corporativas con orquestación mediante Kubernetes y balanceadores de carga gRPC, la forma estándar de desplegar TensorRT-LLM es empaquetarlo dentro del contenedor de Triton Inference Server de NVIDIA. Esto aporta:

• Endpoints HTTP/REST y gRPC de ultra baja latencia con multiplexación HTTP/2 nativa.
• Soporte de Dynamic Batching multinivel coordinado a nivel de hardware.
• Integración directa con el operador de GPU de NVIDIA (NVIDIA GPU Operator) en OpenShift y Amazon EKS.