Optimización de TensorRT-LLM: Dominando el Stack de Inferencia de NVIDIA

Actualizado el 11 de diciembre de 2025

Actualización de diciembre 2025: TensorRT-LLM alcanza más de 10,000 tokens de salida/seg en H100 con FP8, TTFT inferior a 100ms. Despliegues en producción reportan 4x de rendimiento vs PyTorch nativo. Fusión de kernels combinando LayerNorm, matmuls y activaciones en kernels CUDA únicos. Inflight batching maximizando la utilización de GPU. Atención FP8 en Hopper/Blackwell ofreciendo aceleraciones adicionales.

TensorRT-LLM de NVIDIA ofrece un rendimiento de inferencia en bruto que las alternativas luchan por igualar. En GPUs H100 con precisión FP8, el framework alcanza más de 10,000 tokens de salida por segundo en rendimiento máximo con latencias de tiempo-hasta-primer-token por debajo de 100 milisegundos.¹ Los despliegues en producción reportan mejoras de rendimiento de hasta 4x sobre la inferencia nativa de PyTorch. El rendimiento tiene un costo: TensorRT-LLM requiere más experiencia en configuración y ciclos de optimización más largos que alternativas más amigables como vLLM.

Para organizaciones comprometidas con hardware NVIDIA y dispuestas a invertir tiempo de ingeniería en optimización, TensorRT-LLM extrae el máximo rendimiento de infraestructura GPU costosa. Comprender la arquitectura del framework, las opciones de cuantización y los parámetros de ajuste permite a los equipos construir sistemas de inferencia que justifican las inversiones en hardware premium a través de una economía de tokens superior.

Arquitectura y optimizaciones principales

TensorRT-LLM se construye sobre el optimizador de inferencia TensorRT de NVIDIA, extendiendo el framework de compilación con optimizaciones específicas para transformers. La biblioteca proporciona APIs de Python para la definición de modelos junto con componentes de runtime en C++ para despliegue en producción.

Fusión de kernels: TensorRT-LLM combina múltiples operaciones de transformer en kernels CUDA optimizados únicos. LayerNorm, multiplicaciones de matrices, adiciones de bias y funciones de activación se ejecutan juntas en lugar de requerir lanzamientos de kernel separados y transferencias de memoria. La fusión reduce la sobrecarga de lanzamiento de kernels y elimina la materialización de tensores intermedios.²

Kernels de atención personalizados: Implementaciones optimizadas a mano de atención multi-cabezal y grouped-query aprovechan las instrucciones de Tensor Core para máximo rendimiento. Las variantes de Flash Attention reducen los requisitos de ancho de banda de memoria mientras mantienen la precisión numérica. Los kernels de atención FP8 en GPUs Hopper y Blackwell proporcionan aceleraciones adicionales.

Inflight batching: El batching estático tradicional obliga a todas las solicitudes en un batch a esperar hasta que la secuencia más larga se complete. El inflight batching agrega nuevas solicitudes a batches en ejecución en cada paso de generación, procesando las fases de contexto y generación juntas.³ El enfoque maximiza la utilización de GPU manteniendo las unidades de cómputo ocupadas incluso cuando las solicitudes individuales se completan.

KV caching paginado: Inspirado en la memoria virtual de sistemas operativos, la atención paginada asigna el KV cache en bloques no contiguos en lugar de requerir regiones de memoria continuas.⁴ La asignación a nivel de bloque permite compartir el KV cache entre solicitudes con prefijos comunes y logra un desperdicio de memoria casi nulo por fragmentación interna.

Comparación de rendimiento: TensorRT-LLM vs vLLM

Ambos frameworks apuntan a la inferencia de LLM en producción, pero las diferencias arquitectónicas crean perfiles de rendimiento distintos:

TensorRT-LLM supera consistentemente a vLLM con configuraciones predeterminadas, entregando 1.34x mayor rendimiento en secuencias cortas y 2.72x mejor tiempo-por-token-de-salida en secuencias largas.⁵ En GPUs B200, la optimización más profunda de TensorRT-LLM para la arquitectura Blackwell extiende aún más la brecha de rendimiento.

vLLM ofrece ventajas en experiencia de desarrollador:⁶ - API compatible con OpenAI para reemplazo directo - Despliegue más simple sin paso de compilación - Optimización automática de modelos con valores predeterminados sensatos - Soporte de hardware más amplio más allá de GPUs NVIDIA

Recomendación: Despliega TensorRT-LLM cuando maximizar la eficiencia del hardware justifica la inversión en ingeniería. Elige vLLM para un tiempo-a-producción más rápido o cuando operas a menor escala donde el rendimiento absoluto importa menos que la velocidad de desarrollo.

Estrategias de cuantización

TensorRT-LLM soporta extensas opciones de cuantización para intercambiar precisión por rendimiento y eficiencia de memoria. Elegir el método de cuantización correcto depende del tamaño del batch, los requisitos de precisión y el hardware objetivo.

Cuantización FP8 (recomendada primero)

FP8 proporciona el mejor equilibrio de mejora de rendimiento con mínima degradación de precisión:⁷

python quantize.py \
    --model_dir $MODEL_PATH \
    --qformat fp8 \
    --kv_cache_dtype fp8 \
    --output_dir $OUTPUT_PATH

La cuantización FP8 requiere calibración para determinar factores de escala apropiados. El proceso de calibración ejecuta inferencia en muestras representativas para medir rangos de activación:

from tensorrt_llm.quantization import QuantConfig, CalibConfig

quant_config = QuantConfig(
    quant_algo="fp8",
    kv_cache_quant_algo="fp8"
)

calib_config = CalibConfig(
    calib_dataset="cnn_dailymail",
    calib_batch_size=8,
    calib_num_samples=512
)

FP8 ofrece mejora de rendimiento media con impacto de precisión muy bajo y requiere solo minutos para calibración. Las GPUs Hopper y Blackwell proporcionan soporte de hardware FP8; las GPUs Ada soportan FP8 con eficiencia reducida.

INT4 AWQ para despliegues con restricción de memoria

Cuando los límites de memoria restringen el tamaño del modelo, la Cuantización de Pesos Consciente de Activación (AWQ) INT4 comprime los pesos a 4 bits mientras mantiene una precisión aceptable:⁸

python quantize.py \
    --model_dir $MODEL_PATH \
    --qformat int4_awq \
    --awq_block_size 64 \
    --tp_size 4 \
    --output_dir $OUTPUT_PATH

INT4 AWQ sobresale en escenarios de batch pequeño (tamaño de batch ≤ 4) donde la inferencia se vuelve limitada por memoria. El tiempo de carga de pesos domina el cómputo, por lo que la compresión agresiva de pesos proporciona aceleraciones sustanciales. Para batches grandes, la ventaja de rendimiento de INT4 AWQ disminuye a medida que la densidad de cómputo aumenta.

INT8 SmoothQuant para optimización equilibrada

SmoothQuant migra la dificultad de cuantización de las activaciones a los pesos, permitiendo una cuantización INT8 efectiva sin pérdida significativa de precisión:

python quantize.py \
    --model_dir $MODEL_PATH \
    --qformat int8_sq \
    --kv_cache_dtype int8 \
    --output_dir $OUTPUT_PATH

INT8 SmoothQuant proporciona mejora de rendimiento media con impacto de precisión medio. Las organizaciones deberían probar FP8 primero, recurriendo a INT8 SQ si los resultados de FP8 no cumplen los requisitos.

Marco de selección de cuantización

NVIDIA recomienda el siguiente orden de prioridad:⁹

1. FP8 - Mejor equilibrio rendimiento/precisión, requiere Hopper/Blackwell
2. INT8 SmoothQuant - Buena alternativa para GPUs Ada o cuando la precisión de FP8 es insuficiente
3. INT4 AWQ/GPTQ - Máxima compresión para escenarios con restricción de memoria

Para el KV cache específicamente, se recomienda la cuantización FP8 sobre INT8 en GPUs Hopper y Ada debido al menor impacto de precisión en la mayoría de los casos.

Configuración de despliegue en producción

El despliegue óptimo de TensorRT-LLM requiere ajustar múltiples parámetros basados en las características de la carga de trabajo:

Configuración de compilación del engine

trtllm-build \
    --checkpoint_dir $CHECKPOINT_PATH \
    --output_dir $ENGINE_PATH \
    --max_batch_size 256 \
    --max_num_tokens 8192 \
    --max_input_len 4096 \
    --max_seq_len 8192 \
    --gemm_plugin auto \
    --use_paged_context_fmha enable \
    --workers 8

max_batch_size: Predeterminado 256 en versiones recientes. Los despliegues en producción que logran máximo rendimiento a menudo aumentan a 2048, aprovechando completamente las capacidades de inflight batching.¹⁰

max_num_tokens: Controla el total de tokens procesados por iteración de batch. El predeterminado 8192 equilibra rendimiento con consumo de memoria. Reduce para despliegues con restricción de memoria; aumenta con precaución y monitoreo.

use_paged_context_fmha: Habilita la atención paginada para gestión eficiente del KV cache. Requerido cuando se usa inflight batching. La implementación pre-asigna memoria de KV cache, requiriendo aproximadamente 60% más VRAM que solo los pesos del modelo.¹¹

Integración con Triton Inference Server

Los despliegues en producción típicamente usan NVIDIA Triton Inference Server con el backend de TensorRT-LLM:

model_repository/
└── llama-70b/
    ├── 1/
    │   └── model.py
    ├── config.pbtxt
    └── tensorrt_llm/
        └── 1/
            ├── config.json
            └── engine/

Triton proporciona orquestación multi-modelo, cola de solicitudes, recolección de métricas y escalado nativo de Kubernetes. El contenedor pre-construido de NGC incluye el backend de TensorRT-LLM con inflight batching y soporte de KV cache paginado habilitados.

Planificación de memoria

Estima los requisitos de memoria antes del despliegue:

VRAM Total = Pesos del Modelo + KV Cache + Memoria de Activación + Sobrecarga de Runtime

Pesos del Modelo (FP8): Parámetros × 1 byte
Pesos del Modelo (INT4): Parámetros × 0.5 bytes
KV Cache: batch_size × seq_len × num_layers × 2 × hidden_dim × precision_bytes

Un modelo de 70B parámetros en FP8 requiere aproximadamente: - Pesos: 70GB - KV Cache (batch 256, seq 8192): ~120GB - Activaciones + sobrecarga: ~30GB - Total: ~220GB (3x H100 80GB o 2x H200 141GB)

Flujo de trabajo de ajuste de rendimiento

La optimización sistemática extrae el máximo rendimiento de los despliegues de TensorRT-LLM:

Fase 1: Medición de línea base

Usa trtllm-bench para una evaluación rápida del rendimiento:

python -m tensorrt_llm.bench \
    --model_dir $ENGINE_PATH \
    --input_len 512 \
    --output_len 256 \
    --batch_size 32 \
    --num_requests 1000

La utilidad de benchmarking establece parámetros óptimos del engine automáticamente, proporcionando rendimiento de línea base sin la complejidad del despliegue completo de Triton.¹²

Fase 2: Selección de cuantización

Prueba FP8 primero contra los requisitos de precisión. Si la precisión se degrada más allá de umbrales aceptables, evalúa INT8 SQ o INT4 AWQ. Ejecuta benchmarks de evaluación en tareas representativas, no solo mediciones de perplejidad.

Fase 3: Optimización del tamaño de batch

Perfila el rendimiento a través de tamaños de batch desde 1 hasta max_batch_size. Identifica el punto de inflexión de la curva de rendimiento donde el batching adicional proporciona rendimientos decrecientes. Establece max_batch_size 20-30% por encima de este punto para acomodar picos de tráfico.

Fase 4: Ajuste del KV cache

Monitorea la utilización del KV cache durante cargas de trabajo de producción. Si la utilización consistentemente excede 80%, aumenta max_num_tokens o reduce max_batch_size. Si la utilización permanece por debajo del 50%, reduce la asignación para liberar memoria para batches más grandes.

Fase 5: Monitoreo continuo

Rastrea métricas clave en producción: - Tokens por segundo (rendimiento) - Tiempo-hasta-primer-token (latencia) - Profundidad de cola (capacidad) - Utilización de KV cache (memoria) - Utilización de GPU (eficiencia)

Optimizaciones avanzadas

Decodificación especulativa

TensorRT-LLM soporta decodificación especulativa usando modelos draft más pequeños para predecir múltiples tokens verificados por el modelo principal. La técnica proporciona aceleración de 1.5-2x para cargas de trabajo compatibles:

# Habilitar decodificación especulativa en la compilación del engine
trtllm-build \
    --speculative_decoding_mode draft_tokens_external \
    --max_draft_len 5 \
    ...

La decodificación especulativa beneficia aplicaciones sensibles a la latencia donde el tiempo-hasta-completar importa más que el rendimiento. La optimización requiere mantener tanto el modelo draft como el modelo objetivo en memoria.

Configuraciones multi-GPU

TensorRT-LLM soporta paralelismo de tensor (TP), paralelismo de pipeline (PP) y paralelismo de expertos (EP) para inferencia distribuida:

# Paralelismo de tensor de 4 vías
trtllm-build \
    --tp_size 4 \
    --pp_size 1 \
    ...

TP divide cada capa entre GPUs, requiriendo operaciones all-reduce en cada límite de capa. PP divide las capas entre GPUs en etapas de pipeline. Para inferencia, TP típicamente proporciona mejor latencia mientras PP permite

[Contenido truncado para traducción]