TensorRT-LLM: aceleración extrema en GPUs NVIDIA para LLM

Actualizado: 2026-05-03

TensorRT-LLM^[1] es la apuesta de NVIDIA por extraer el último porcentaje de rendimiento de sus GPUs para inferencia de modelos de lenguaje. Donde vLLM optimiza el uso de memoria y el scheduling de peticiones, TensorRT-LLM desciende un nivel más: kernels CUDA escritos a mano para cada operación crítica, cuantización avanzada nativa de FP8 e INT4, y orquestación multi-GPU sofisticada que exprime la interconexión NVLink entre H100. El precio es una complejidad de build y despliegue muy superior. La pregunta relevante no es si es más rápido —generalmente lo es, entre 2x y 3x en casos óptimos— sino cuándo esa diferencia justifica el coste operativo.

Puntos clave

• TensorRT-LLM compila el modelo en un motor optimizado específico para el GPU y el batch size objetivo; no sirve pesos crudos.
• Los kernels CUDA custom para operaciones de atención, feed-forward y norm son la principal fuente de ventaja sobre vLLM.
• FP8 nativo en H100 es la ganancia más grande: 2x el throughput teórico de BF16 con pérdida mínima de calidad.
• El proceso de build puede tardar 30-90 minutos y el motor resultante está ligado al hardware exacto donde se compiló.
• La ventaja se reduce con modelos pequeños o hardware no-H100; en A100 con BF16, la diferencia con vLLM es menor.

Qué hace diferente a TensorRT-LLM

vLLM y TGI optimizan en la capa de software: cómo gestionar memoria, cómo hacer scheduling de peticiones, cómo minimizar el tiempo de GPU ociosa. TensorRT-LLM opera en una capa más baja: cómo se ejecuta cada operación matemática en el silicio.

Las diferencias concretas:

• Kernels de atención: NVIDIA ha escrito implementaciones FlashAttention-2 y FlashMHA optimizadas para cada arquitectura de GPU. No son los kernels genéricos de PyTorch —son código CUDA específico para cada operación y cada tamaño de tensor.
• Cuantización FP8 nativa: las H100 tienen unidades de hardware específicas para aritmética FP8. TensorRT-LLM las usa directamente; otros frameworks hacen emulación software.
• Fusión de kernels: operaciones que normalmente generan dos o tres lanzamientos de kernel separados (norm + multiplicación + activación) se fusionan en un solo kernel, eliminando overhead de sincronización y reduciendo movimientos de memoria.
• Calibración del plan de ejecución: a diferencia de vLLM, que decide dinámicamente cómo servir cada petición, TensorRT-LLM compila el modelo contra un perfil de uso específico (batch size máximo, longitud máxima de secuencia), lo que permite optimizaciones imposibles en tiempo de ejecución dinámico.

El proceso de build

El build de TensorRT-LLM tiene tres etapas que diferencian su uso del de vLLM:

1. Conversión de pesos: los pesos del modelo en formato HuggingFace se convierten al formato interno de TensorRT-LLM, aplicando cuantización si es necesario.

python convert_checkpoint.py 
  --model_dir /models/llama-3-8b 
  --output_dir /checkpoints/llama-3-8b-fp8 
  --dtype float16 
  --use_fp8 
  --fp8_kv_cache

2. Compilación del motor: TensorRT compila el grafo de operaciones contra el hardware específico. Este paso puede tardar entre 30 y 90 minutos para modelos grandes.

trtllm-build 
  --checkpoint_dir /checkpoints/llama-3-8b-fp8 
  --output_dir /engines/llama-3-8b-h100 
  --gemm_plugin float16 
  --gpt_attention_plugin float16 
  --max_batch_size 64 
  --max_input_len 4096 
  --max_output_len 2048 
  --tp_size 2

3. Servicio: el motor compilado se sirve con Triton Inference Server o con el servidor nativo de TensorRT-LLM.

El motor resultante está ligado al hardware exacto donde se compiló: un motor compilado para H100 no corre en A100, y un motor compilado para batch size 64 no funciona bien para batch size 128. Esto significa que el proceso de build debe repetirse para cada configuración de hardware y carga.

Rendimiento real: cuándo compensa

Las diferencias de rendimiento dependen fuertemente del hardware y del modelo. Los escenarios donde TensorRT-LLM gana más:

• H100 con FP8: el caso óptimo. Las unidades FP8 de H100 doblan el throughput teórico de BF16. Con TensorRT-LLM compilado para FP8, los resultados pueden ser 2x-3x superiores a vLLM en BF16.
• Modelos grandes en multi-GPU: para modelos de 70B+ en configuraciones de 4-8 H100 con NVLink, la optimización del tráfico entre GPUs es significativa.
• Batch sizes fijos conocidos: si tu carga tiene distribuciones de longitud y batch size predecibles, compilar el motor contra esos perfiles específicos extrae más rendimiento.

Los escenarios donde la ventaja se reduce:

• A100 con BF16: sin FP8 hardware nativo, la diferencia con vLLM cae a 1,2x-1,5x —a menudo no justifica el coste operativo.
• Modelos pequeños (≤7B): los kernels custom de TensorRT-LLM dan menos ventaja cuando los modelos caben fácilmente en la memoria.
• Distribución de longitud variable: si las peticiones varían mucho en longitud, el motor compilado para un perfil específico no exprime el hardware tanto como en el caso fijo.

TensorRT-LLM frente a vLLM: la decisión práctica

La decisión entre TensorRT-LLM y vLLM es fundamentalmente una decisión sobre dónde está el cuello de botella en tu sistema y cuánto puedes invertir en operaciones:

La recomendación práctica: empieza con vLLM. Si el rendimiento de vLLM en tu hardware específico no es suficiente —porque has medido que el coste por token es demasiado alto o que la latencia no cumple el SLA— evalúa TensorRT-LLM para tu modelo y hardware concreto. No asumas que la diferencia será 2x-3x; mide con tu tráfico real y tu modelo específico.

Para el fine-tuning eficiente de los modelos antes de servirlos con TensorRT-LLM, los adaptadores LoRA y QLoRA funcionan bien: TensorRT-LLM soporta fusión de adaptadores LoRA en el motor compilado.

Integración con Triton Inference Server

Para equipos con stacks empresariales, TensorRT-LLM se integra de forma natural con Triton Inference Server de NVIDIA. La ventaja de este stack:

• Multi-modelo: Triton puede servir varios modelos sobre el mismo hardware, con scheduling de GPU compartido.
• gRPC y HTTP/REST: protocolos estándar de inferencia enterprise.
• Métricas nativas: integración con Prometheus sin configuración adicional.
• Dynamic batching: Triton puede agregar peticiones concurrentes antes de enviarlas al motor.

El stack Triton + TensorRT-LLM es la elección estándar en despliegues enterprise donde el hardware son racks de H100 y el equipo de ML Ops tiene capacidad para mantener el pipeline de compilación.

Conclusión

TensorRT-LLM es la opción correcta cuando el rendimiento en GPU NVIDIA es el factor limitante y el equipo tiene la capacidad operativa para gestionar el ciclo de compilación. Para la mayoría de equipos que empiezan a servir LLMs propios, vLLM ofrece el 70-80 % del rendimiento con el 10 % de la complejidad. El caso de uso de TensorRT-LLM es el equipo que ya tiene vLLM en producción, ha medido que el costo por token no cumple el objetivo financiero y tiene hardware H100 donde FP8 puede marcar la diferencia.

1. TensorRT-LLM