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

Tue, 16 Jun 2026 02:00:00 +0200

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

Atributo	Valor
Versión de referencia	v0.9.x (junio 2026)
Licencia	Apache 2.0
Mantenedor / gobernanza	vLLM Project (Linux Foundation AI), liderado por UC Berkeley + Red Hat
Hardware soportado	NVIDIA (Ampere/Hopper/Blackwell), AMD ROCm, Intel Gaudi, TPU, CPU
Repositorio	github.com/vllm-project/vllm
API	OpenAI-compatible (completions, chat, embeddings)

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

Atributo	Valor
Versión de referencia	v0.4.x (junio 2026)
Licencia	Apache 2.0
Mantenedor / gobernanza	LMSYS Org (Berkeley, CMU, UCSD)
Hardware soportado	NVIDIA (Ampere/Hopper/Blackwell), AMD ROCm
Repositorio	github.com/sgl-project/sglang
API	OpenAI-compatible + SGLang runtime API

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)

Atributo	Valor
Versión de referencia	v0.18.x (junio 2026)
Licencia	Apache 2.0
Mantenedor / gobernanza	NVIDIA (propietario de hecho, OSS de nombre)
Hardware soportado	NVIDIA únicamente: Ampere (A100), Hopper (H100/H200/GH200), Ada (L40/L40S), Blackwell (B200/GB200)
Repositorio	github.com/NVIDIA/TensorRT-LLM
API	Python + C++ runtime; integra con Triton Inference Server

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

Atributo	Valor
Versión de referencia	v1.1.1 (mayo 2026)
Licencia	Apache 2.0
Mantenedor / gobernanza	NVIDIA + comunidad OSS (ai-dynamo org en GitHub)
Hardware soportado	NVIDIA (a través del motor subyacente: vLLM, SGLang o TRT-LLM)
Repositorio	github.com/ai-dynamo/dynamo
Rol	Capa de orquestación, NO motor de inferencia

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.

Capacidad	vLLM	SGLang	TRT-LLM	Dynamo (vía backend)
Continuous batching	Si	Si	Si	Si (delega al motor)
PagedAttention	Si	Si	Si	Si
RadixAttention / prefix caching	Si (chunked prefill + prefix)	Si (RadixAttention nativa)	Si (prefix caching)	Si + KV-aware routing
Speculative decoding	Si (n-gram, EAGLE, DFlash, suffix)	Si (draft+verify)	Si (EAGLE-3, MTP)	Si
Quantización FP8	Si	Si	Si	Si
Quantización MXFP4/NVFP4	Si	Beta	Si (Blackwell)	Si
Quantización INT4 AWQ	Si	Si	Si	Si
Quantización GPTQ	Si	Si	No nativo	Si (vía vLLM)
Quantización INT8 (SmoothQuant)	Si	Si	Si	Si
Structured output	Si	Si (FSM comprimida)	Beta	Si
Multi-LoRA dinámica	Si	Si	Beta	Si
Disaggregated prefill/decode	Beta (experimental)	Si	Si	Si (primera clase)
Chunked prefill	Si	Si	Si	Si
Soporte multimodal (VLM)	Si	Si	Si	Si
Multi-nodo tensor parallelism	Si	Si	Si	Si (+ pipeline entre nodos)
OpenAI API compatible	Si	Si	Si (via Triton)	Si
Hardware no-NVIDIA	Si (AMD/Intel/TPU)	Si (AMD)	No	No

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

Motor	Config	Throughput (tok/s)	TTFT P50 (ms)	TTFT P99 (ms)	ITL P50 (ms)	Goodput (@SLO)
vLLM v0.9	FP8, chunked prefill	12.500	160	420	18	~96 %
SGLang v0.4	FP8, RadixAttention	16.200	140	390	21	~97 %
TRT-LLM v0.18	FP8, engine compilado	14.800	190	480	10	~93 %
vLLM + Dynamo	FP8, desag. P/D 2+2	18.500	120	310	19	~98 %
SGLang + Dynamo	FP8, desag. P/D 2+2	21.000	110	280	22	~99 %
TRT-LLM + Dynamo	FP8, desag. P/D 2+2	22.500	130	350	11	~97 %

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)

Concurrencia	TTFT P99 (ms)	ITL P50 (ms)	Throughput (tok/s)	Goodput (tok/s)
8	210	14	5.200	5.200
16	370	18	9.800	9.800
32	420	18	12.500	12.200
48	680	26	13.800	7.400
64	1.200	41	14.100	2.100

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)

Variable	Valor fijado en el experimento de referencia
Herramienta de carga	AIPerf v2.x (multi-proceso)
Modelo	Llama-3.1-70B-Instruct
Precisión	FP8
Hardware	4×H100 SXM 80 GB NVLink
Dataset	ShareGPT (distribución ISL/OSL realista)
SLO	TTFT P99 < 500 ms, ITL P50 < 30 ms
Warm-up	200 peticiones descartadas antes de medir
Sweep	concurrencias 1, 4, 8, 16, 32, 48, 64
Métrica principal	goodput (tok/s útiles bajo SLO)

Pasos del harness

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

Dimensión	vLLM	SGLang	TRT-LLM	Dynamo
Madurez de producción	Alta (3+ años)	Media-alta (2 años)	Alta (NVIDIA)	Media (1.0 GA mar-2026)
Velocidad de release	Semanal	Semanal	Mensual	Bisemanal
Ecosistema de integraciones	Muy amplio (Ray, k8s, llm-d, Dynamo, NIM)	Amplio (Dynamo, k8s)	NVIDIA-centrado (Triton, NIM)	NVIDIA-centrado
Facilidad de operación	Alta (pip install, OpenAI API)	Alta	Media (requiere compilar engines)	Media-baja (multi-nodo, etcd/NATS)
Hardware no-NVIDIA	Si (AMD, Intel, TPU)	Si (AMD)	No	No
Disaggregated serving	Beta	Estable	Estable	Primera clase
Multi-LoRA dinámica	Estable	Estable	Beta	Estable (vía vLLM/SGLang)
Structured output	Estable	Estable (FSM)	Beta	Estable (vía motor)
Soporte comunidad OSS	Muy alto (>30 K GitHub stars)	Alto (~20 K stars)	Alto (~10 K stars)	Creciente (6,8 K stars)

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

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

Criterio de selección	Motor recomendado	Justificación cuantitativa
Nodo único, prototipo rápido, equipo sin experiencia en LLM serving	vLLM	pip install + OpenAI API en minutos; soporte de comunidad más amplio
Workload con prefijos compartidos largos (RAG, few-shot, system prompts > 512 tok)	SGLang	RadixAttention: hasta 6,4× más throughput vs baseline sin prefix caching
Máximo throughput en NVIDIA, sin portabilidad, equipo con experiencia TRT	TRT-LLM	Kernels fusionados + FP8 nativo: ITL 9–12 ms vs 18–22 ms de vLLM en igual hardware
Multi-nodo (> 8 GPUs), tráfico mixto prefill-intensivo/decode-intensivo	Dynamo + SGLang	Disaggregated P/D: hasta 7× throughput adicional en Blackwell; 2× TTFT con KV-aware routing
Hardware AMD ROCm o Intel Gaudi	vLLM	Único motor SOTA con soporte estable no-NVIDIA
Structured output + alta concurrencia	SGLang	FSM comprimida: decode guiado sin overhead apreciable
Multi-LoRA dinámica estable en producción	vLLM o SGLang	TRT-LLM multi-LoRA aún en beta (jun-2026)
Ecosistema Hugging Face, modelos < 13B	HF TGI v3	Integración directa HF Hub; latencia competitiva en modelos pequeños
Máxima eficiencia energética (J/token) en NVIDIA	TRT-LLM	Kernels de menor overhead → menos J/token a iso-throughput

Quantización: efecto en throughput y calidad

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

Formato	Throughput relativo (H100)	Degradación de calidad (perplexidad)	Motores con soporte estable
NVFP4 / MXFP4	~2,2× vs FP16	1–3 % en MMLU	TRT-LLM (Blackwell), vLLM (experimental)
FP8 (W8A8)	~1,7× vs FP16	< 1 % en MMLU	vLLM, SGLang, TRT-LLM
INT4 AWQ	~1,5× vs FP16	1–2 % en MMLU	vLLM, SGLang, TRT-LLM
GPTQ (INT4)	~1,4× vs FP16	1–3 % en MMLU	vLLM, SGLang
FP16 (baseline)	1,0×	0 %	Todos

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:

Condición	Efecto del disaggregated serving
ISL media > 1.024 tokens	Prefill domina; separar pools evita que bloquee decode
Ratio prefill/decode > 3:1 en tiempo	El pool de decode se queda idle esperando al prefill
Tráfico mixto (burst de prefill + cola de decode)	Escalado independiente de cada pool por SLA
< 512 tokens ISL, prompts únicos	Overhead de transferencia supera el beneficio; motor agregado suficiente

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):

Submitter	Hardware	Escenario	Throughput (tok/s)
Red Hat (vLLM)	1×H100 80 GB	Server	5.103
Red Hat (vLLM)	1×L40S	Server	1.207
NVIDIA (TRT-LLM)	8×H100 SXM	Server	~52.000 (estimado)

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

Variable omitida	Efecto en producción
Latencia de red (gateway, load balancer)	Puede añadir 20–100 ms al TTFT medido en el servidor
Tiempo de compilación de engine (TRT-LLM)	Horas por modelo×precisión×hardware; penaliza cold starts y CI
Tiempo de carga de pesos en GPU	Relevante en autoescalado; ModelExpress (Dynamo) reduce 7×
Costo operativo del sistema (Dynamo vs motor simple)	Dynamo requiere etcd/NATS, Rust runtime, equipo más especializado
Calidad de respuesta	Rendimiento no implica calidad; medir con lm-evaluation-harness (artículo B7)
Energía (J/token)	No sale del benchmark de throughput; requiere DCGM simultáneo

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

Serving on lo0 — Blog Técnico