Comparativa de motores de serving LLM en frontera de Pareto: vLLM, SGLang, TRT-LLM y Dynamo

Notación: importes en euros (N €), decimales con coma. No se usa el símbolo de dólar (en este sitio es delimitador de fórmula). Hardware de referencia: configuración genérica 4×H100 SXM 80 GB; las cifras son ilustrativas para comparar motores, no métricas de producción de ninguna infraestructura real.

TL;DR

Cuatro motores OSS dominan el serving LLM on-premise en 2026: vLLM, SGLang, NVIDIA TensorRT-LLM y NVIDIA Dynamo. Ninguno es superior en todos los ejes. En throughput bruto con prompt compartido, SGLang supera a vLLM en un 29 % en Llama-3.3-70B FP8 sobre H100 (16.200 vs 12.500 tok/s). En latencia de decode, TRT-LLM mantiene ITL más estable a alta concurrencia (9–12 ms P50 frente a 18–22 ms de vLLM). Dynamo no es un motor de inferencia: es la capa de orquestación sobre los tres anteriores para clústeres multi-nodo, y reporta hasta 7× de throughput adicional en serving desagregado sobre Blackwell. La elección correcta depende de tres variables: patrón de carga (batch/interactivo), escala del despliegue (nodo único/multi-nodo) y restricciones operativas (madurez OSS, facilidad de operación). La tabla de decisión Pareto está al final del artículo.

Marco del artículo: qué es y qué no es este B8

Este artículo (B8 del pilar benchmarking) da por sentadas las métricas de la introducción al benchmarking y el catálogo de herramientas de la ficha a ficha. Aplica esos conceptos a la elección de motor. El protocolo de GuideLLM para validación de SLO y AIPerf a fondo detallan cómo ejecutar el harness; aquí se usa el resultado. Los fundamentos de continuous batching, serving desagregado, el backend de atención y quantización se asumen conocidos.

Ficha de cada motor

vLLM

Origen: PagedAttention (Kwon et al., 2023). Primera implementación de continuous batching con KV cache paginado. En 2026 es el motor más desplegado en entornos OSS y el que más integraciones acumula (Ray Serve, Kubernetes, llm-d, Dynamo).

SGLang

Origen: paper SGLang 2024 (Zheng et al.). Introduce RadixAttention como generalización de prefix caching: árbol radix de bloques KV con política LRU compartida entre todas las peticiones en vuelo. Ventaja estructural en workloads con prefijos compartidos (system prompts largos, few-shot, RAG).

NVIDIA TensorRT-LLM (TRT-LLM)

Motor de más bajo nivel: compila grafos de inferencia con TensorRT, aplica fusión de kernels y genera engines binarios específicos por modelo + hardware + precisión. Máximo rendimiento en NVIDIA, sin portabilidad a otro hardware. Requiere recompilación al cambiar modelo o configuración; tiempo de build de minutos a horas según el modelo.

NVIDIA Dynamo

Dynamo no ejecuta la inferencia directamente: es el planificador y enrutador que coordina pools de workers (vLLM, SGLang, TRT-LLM) en multi-nodo. Implementado en Rust (rendimiento) + Python (extensibilidad). Añade: serving desagregado prefill/decode entre nodos, enrutamiento KV-aware (evita recomputar prefill si otro worker ya tiene el KV en cache), escalado automático por SLA, KV Block Manager (KVBM) con offload a CPU/SSD/remoto y transferencia via NIXL sobre NVLink/InfiniBand.

Menciones: LMDeploy y HF TGI

LMDeploy (OpenMMLab/InternLM, Apache 2.0): motor con dos backends —TurboMind (C++, máximo rendimiento en NVIDIA) y PyTorch (flexibilidad)—. Bloqueo de KV cache y persistent batching; 4-bit inferencia hasta 2,4× más rápida que FP16 en su propio benchmark. Ecosistema más estrecho; sin soporte AMD.

HF TGI (Hugging Face, Apache 2.0): motor de referencia para el ecosistema HuggingFace. TGI v3.0 reduce latencia hasta 13× en prompts largos vs versiones anteriores; integra FlashAttention + PagedAttention. Punto de entrada habitual para equipos que ya operan el stack HF; no es el más eficiente en throughput a máxima carga.

Matriz de capacidades

La tabla usa la notación: Si = soportado y estable, Beta = disponible pero no recomendado para producción, No = no disponible o solo con workaround manual.

Fuentes de la matriz: docs.vllm.ai, docs.sglang.io, nvidia.github.io/TensorRT-LLM, docs.nvidia.com/dynamo, github.com/ai-dynamo/dynamo (feature matrix, junio 2026).

Por qué no se comparan a la ligera: las variables que rompen una comparación

Antes de la tabla de cifras, las cuatro decisiones que invalidan cualquier benchmark cruzado:

1. Harness distinto. Un benchmark con el micro-bench nativo de cada motor (vllm bench serve vs SGLang bench) mide el cliente, no el motor. La discrepancia puede ser hasta 7,2× a alta concurrencia. Protocolo correcto: un único generador de carga (AIPerf o GuideLLM) contra todos los endpoints. El motor es la variable, la herramienta es la constante.

2. ISL/OSL distintas. Input Sequence Length y Output Sequence Length determinan la ratio prefill/decode y por tanto qué motor se favorece. Un benchmark con ISL baja (64 tokens) favorece a motores con decode rápido; con ISL alta (2.048 tokens) y prefijos compartidos, favorece a SGLang (RadixAttention). Fijar ISL y OSL es obligatorio para que la comparación sea válida.

3. Precisión distinta. FP16 y FP8 no son comparables: FP8 da entre 1,5× y 2× más throughput en Hopper. Comparar vLLM FP16 con TRT-LLM FP8 no dice nada del motor.

4. No reportar P99. El throughput máximo se alcanza en el punto donde el P99 de TTFT ya viola el SLO. El número defendible es el goodput —throughput bajo el SLO—, no el máximo bruto. La fórmula de la latencia de extremo a extremo:

$$\text{latencia}{e2e} \approx \text{TTFT} + (N{\text{out}} - 1) \times \text{TPOT}$$

donde (N_{\text{out}}) es el número de tokens de salida, deja ver que un TTFT alto con TPOT bajo tiene el mismo efecto que el caso inverso solo para una (N_{\text{out}}) concreta: hay que reportar ambos por separado.

El protocolo completo de comparación justa está en el artículo de herramientas.

Rendimiento en frontera de Pareto: cifras ilustrativas

Configuración de referencia para todas las filas: 4×H100 SXM 80 GB NVLink, modelo Llama-3.1-70B-Instruct FP8, harness AIPerf (ex genai-perf, sucesor multi-proceso), dataset ShareGPT (distribución realista de longitudes), ISL media ~512 tok, OSL media ~256 tok, SLO TTFT P99 < 500 ms. Las cifras son ilustrativas y representativas de benchmarks publicados por la comunidad (Cerebrium, LMSYS, Spheron, Red Hat MLPerf v5.1); no son mediciones de ninguna infraestructura real. Las cifras exactas varían con versiones de motor, flags de compilación y distribución de carga.

Throughput vs latencia: tabla de Pareto

Notas de lectura:

• “Desag. P/D 2+2” = 2 GPUs prefill + 2 GPUs decode (mismo presupuesto de 4×H100).
• El goodput cae respecto al throughput bruto cuando la cola de latencia supera el SLO de 500 ms P99. TRT-LLM sin Dynamo tiene el ITL más bajo pero el TTFT más alto a alta concurrencia, lo que lleva su goodput a ~93 % en este SLO.
• Dynamo añade ~30–40 % de throughput efectivo sobre 4 GPUs gracias al serving desagregado y el enrutamiento KV-aware, en el escenario con prefijos reutilizables (ShareGPT).
• En workloads sin prefijos compartidos (ISL corta, prompts únicos), la ventaja de Dynamo se reduce al ~10–15 % sobre el motor base.

Punto de saturación (sweep de concurrencia, vLLM FP8, 4×H100)

El codo está entre 32 y 48: el throughput sube solo un 10 % (12.500 → 13.800) pero el TTFT P99 ya viola el SLO de 500 ms y el goodput cae a la mitad. La capacidad operativa defendible es la de concurrencia 32 (12.200 tok/s útiles). Reportar 14.100 tok/s (concurrencia 64) sería el throughput máximo con goodput del 15 %.

Metodología de comparación justa: el harness como constante

El protocolo que hace comparables los números entre motores distintos. El motor es la única variable; todo lo demás es constante y se pinea en el JSON de salida.

Variables que se fijan (constantes del experimento)

Pasos del harness

1. Desplegar el motor con la config exacta (flags pineados, versión fijada).
2. Warm-up: 200 peticiones; descartar resultados.
3. Sweep de concurrencia: aiperf profile --concurrency-range 1:64:step con AIPerf.
4. Extender el sweep más allá del codo (hasta que el goodput caiga por debajo del 50 %).
5. Recoger JSON: TTFT P50/P99, ITL P50, throughput bruto, goodput.
6. Cambiar solo el motor; repetir pasos 1–5.
7. Comparar la columna goodput entre filas.

El sweep con GuideLLM es equivalente para validación de SLO; AIPerf es preferible para comparativas de motores porque su estimatedCapacity automático normaliza el punto de saturación. Los dos pueden usarse: GuideLLM para el SLO operativo, AIPerf para la capacidad de referencia.

Formato de salida reproducible

{
  "harness": "aiperf", "harness_version": "2.x",
  "model": "Llama-3.1-70B-Instruct", "precision": "FP8",
  "hardware": "4xH100_SXM_80GB_NVLink",
  "dataset": "sharegpt",
  "slo": {"ttft_p99_ms": 500, "itl_p50_ms": 30},
  "motor": "vllm", "motor_version": "0.9.x",
  "concurrency_sweep": [8, 16, 32, 48, 64],
  "results_at_knee": {
    "concurrency": 32,
    "ttft_p50_ms": 210, "ttft_p99_ms": 420,
    "itl_p50_ms": 18, "throughput_tok_s": 12500,
    "goodput_tok_s": 12200
  }
}

Este JSON versionado es el dato auditable: cualquiera reproduce la cifra con la misma herramienta, versión, modelo, hardware y carga.

Estado del arte 2026: madurez relativa

Tabla de decisión Pareto: cuándo elegir cada motor

Sin prosa; la decisión como tabla de criterios y resultado.

Quantización: efecto en throughput y calidad

Las cuatro opciones principales en orden de velocidad decreciente y calidad creciente:

FP8 es el estándar de facto en Hopper para producción: throughput 1,7× con degradación inferior al 1 %. El artículo de cuantización en profundidad desarrolla el trade-off calidad/velocidad por formato y arquitectura de modelo.

Disaggregated serving: cuándo el overhead vale la pena

La separación prefill/decode en pools independientes introduce latencia de transferencia de KV tensors entre nodos (NIXL sobre NVLink o InfiniBand). El overhead es rentable cuando:

Dynamo cuantifica el punto de break-even: el serving desagregado es rentable cuando el tiempo de transferencia de KV tensors (función del ISL y el ancho de banda NVLink/IB) es inferior al tiempo que el decode-worker esperaría al prefill-worker en modo agregado. En 4×H100 con ISL de 512 tok, el break-even ocurre con ratio prefill/decode > 2,5:1. El artículo de serving desagregado desarrolla la fórmula completa.

MLPerf Inference v5.1: cifras de referencia cross-vendor

MLPerf Inference v5.1 (septiembre 2025) es el patrón de comparabilidad inter-fabricante. Escenario Server (Llama-3.1-70B, tokens/s):

Las cifras de MLPerf no son directamente comparables con los benchmarks internos anteriores (harness diferente, escenario Server de MLPerf con distribución Poisson y SLO fijos). Son útiles para comparar fabricantes bajo las mismas reglas; no para dimensionar un caso concreto. Para eso, el sweep propio con AIPerf/GuideLLM sobre el endpoint objetivo.

Variables que el benchmark no captura

Fuentes

• vLLM · documentación oficial — https://docs.vllm.ai/en/latest/
• vLLM · blog de rendimiento (v0.6.0, 2,7× throughput) — https://blog.vllm.ai/2024/09/05/perf-update.html
• vLLM · disaggregated prefill (experimental) — https://docs.vllm.ai/en/latest/features/disagg_prefill/
• SGLang · documentación oficial — https://docs.sglang.io/
• SGLang · paper RadixAttention (LMSYS, 2024) — https://arxiv.org/pdf/2312.07104
• SGLang · blog LMSYS sobre Llama-3 serving — https://www.lmsys.org/blog/2024-07-25-sglang-llama3/
• NVIDIA TensorRT-LLM · GitHub — https://github.com/NVIDIA/TensorRT-LLM
• NVIDIA TensorRT-LLM · overview y release notes — https://nvidia.github.io/TensorRT-LLM/overview.html
• NVIDIA TensorRT-LLM · quantización — https://nvidia.github.io/TensorRT-LLM/features/quantization.html
• NVIDIA Dynamo · GitHub (ai-dynamo/dynamo) — https://github.com/ai-dynamo/dynamo
• NVIDIA Dynamo · documentación oficial — https://docs.nvidia.com/dynamo/latest
• NVIDIA Dynamo · disaggregated serving — https://docs.dynamo.nvidia.com/dynamo/design-docs/disaggregated-serving
• Cerebrium · benchmark vLLM vs SGLang vs TRT-LLM (Llama 3.1-70B) — https://cerebrium.ai/blog/benchmarking-vllm-sglang-tensorrt-for-llama-3-1-api
• Spheron · vLLM vs TRT-LLM vs SGLang H100 benchmarks 2026 — https://www.spheron.network/blog/vllm-vs-tensorrt-llm-vs-sglang-benchmarks/
• MLCommons · MLPerf Inference v5.1 results — https://mlcommons.org/2025/09/mlperf-inference-v5-1-results/
• Red Hat · MLPerf Inference v5.1 con vLLM — https://www.redhat.com/en/blog/efficient-and-reproducible-llm-inference-red-hat-mlperf-inference-v51-results
• arXiv 2605.24217 · sesgo sistemático en benchmarks de inferencia LLM — https://arxiv.org/html/2605.24217
• IETF Draft · LLM Benchmarking Methodology (enero 2026) — https://www.ietf.org/archive/id/draft-gaikwad-llm-benchmarking-methodology-00.html