Motores IA 2026: vLLM vs TensorRT-LLM vs llama.cpp – Guía founder

Por qué el motor de inferencia es la pieza más infravalorada de tu IA local

Cuando Cristian Tala midió el modelo Muse Glimmer de Meta en su máquina, obtuvo primero 3,70 tokens por segundo — un número ridículo que haría que cualquier founder cerrara la pestaña. Pero al cambiar cómo le preguntó al modelo, la cifra saltó a 180 tokens por segundo. El modelo era el mismo. La máquina era la misma. Lo que cambió fue cómo el motor de inferencia procesó la solicitud.

Este descubrimiento resume por qué tantos emprendedores gastan miles en hardware sin ver los resultados esperados: están optimizando la pieza equivocada. Según las mediciones de Tala en su DGX Spark con 128 GB de memoria, el mismo modelo Qwen 3.6 35B-A3B corrió a 76 tokens por segundo con vLLM pero solo a 34,5 tokens por segundo con TensorRT-LLM — menos de la mitad de velocidad en el mismo hardware.

Los cinco motores que definen la inferencia local en 2026

vLLM: el estándar de la industria

vLLM es el motor más utilizado en producción, especialmente diseñado para atender muchas peticiones simultáneas sin hacer esperar a nadie. Según su documentación oficial, vLLM es "rápido, fácil de usar y barato para servir LLMs", con soporte para más de 200 arquitecturas de modelos en Hugging Face.

Su ventaja clave es el PagedAttention, una técnica que gestiona eficientemente la memoria de atención clave y valor, permitiendo un throughput de última generación. En benchmarks de terceros de 2026, vLLM alcanzó aproximadamente 1.850 tokens por segundo en un H100 SXM5 con 50 solicitudes concurrentes.

TensorRT-LLM: el traje a medida de NVIDIA

Desarrollado por NVIDIA, TensorRT-LLM compila el modelo específicamente para tu hardware antes de ejecutarlo. Esto puede resultar en la versión más rápida posible, pero con una trampa: queda amarrado a ese hardware específico. Según el análisis de benchmarks de 2026, TensorRT-LLM logró aproximadamente 2.100 tokens por segundo en las mismas condiciones, pero requiere unos 28 minutos de compilación por modelo antes de poder servir.

llama.cpp: el que corre donde sea

Nacido como proyecto individual de Georgi Gerganov, llama.cpp es la puerta de entrada para la mayoría de usuarios de IA local. Funciona en Mac, Windows, Linux, laptops sin GPU dedicada e incluso smartphones. Si tienes un Mac con chip M, esta es tu única opción realista, ya que CUDA (tecnología de NVIDIA) no existe en Apple Silicon.

SGLang: especialista en conversaciones largas

Desarrollado por el grupo LMSYS (los mismos de Chatbot Arena), SGLang brilla cuando muchas peticiones comparten el mismo comienzo — algo típico en agentes que repiten instrucciones en cada turno. Su RadixAttention almacena entradas de caché KV clave por hash de prefijo de prompt, permitiendo reutilización automática. En benchmarks de 2026, SGLang alcanzó aproximadamente 1.920 tokens por segundo y arranca en solo 58 segundos.

NVIDIA NIM: el envoltorio, no el motor

NIM no es un motor — es un envoltorio. Según la investigación de Tala, los NIM de Nemotron traen SGLang por dentro, y los de Qwen y Muse Glimmer traen vLLM. Lo que agrega NIM es contenedor listo, autenticación, telemetría y configuración validada por NVIDIA. Traducido: NIM no hace que tu modelo sea más rápido, pero te ahorra horas de configuración.

La diferencia que multiplica por 11: denso vs MoE

La medición más reveladora de Tala muestra por qué el tamaño nominal del modelo engaña: Gemma 4 31B (denso) corre a 6,7 tokens por segundo, mientras que Qwen 3.6 35B-A3B (MoE) corre a 76 tokens por segundo. El de 35B es más grande y va once veces más rápido.

La explicación está en la arquitectura:

• Modelos densos usan todos sus parámetros en cada palabra generada
• Modelos MoE (Mixture-of-Experts) solo activan un subconjunto de parámetros por palabra

En 35B-A3B, el primer número (35B) es lo que ocupa el modelo, y el segundo (3B) es lo que realmente trabaja en cada palabra. La regla práctica: mira el segundo número, no el primero. Un "35B" que solo activa 3B te volará; un "31B" denso te arrastrará.

El error que cuesta mañanas enteras: latencia vs throughput

El error inicial de Tala — medir de a una petición — revela la trampa que se comen casi todos los titulares. Al medir Muse Glimmer con diferentes niveles de concurrencia:

• 1 petición: 11,3 tokens/s por usuario
• 32 peticiones simultáneas: 179,9 tokens/s totales, pero solo 5,6 tokens/s por usuario

El total sube y lo que recibe cada uno baja. Hay dos preguntas distintas:

1. ¿Qué tan rápido me responde a mí? (latencia) — importa cuando estás solo en un chat
2. ¿Cuánto trabajo total mueve la máquina en una hora? (throughput) — importa cuando sirves a muchos usuarios

El número que impresiona en los benchmarks casi siempre es el segundo.

Lo que realmente llena tu memoria (y no es el modelo)

Otro hallazgo contraintuitivo: revisando los 112 GB que ocupaba su setup, Tala descubrió que:

• El modelo: 20 GB
• La memoria de la conversación: 82 GB
• Todo lo demás: 10 GB

Lo que se come 82 GB es lo que el motor guarda para no recalcular la conversación en cada palabra. Al bajar el contexto máximo de 256 mil tokens a 64 mil, pasó de 112 GB a 44 GB — 60% de memoria liberada, con velocidad prácticamente igual (75,3 vs 75,4 tokens/s).

Si alguna vez intentaste correr un modelo local y te dijo que no había memoria: probablemente el problema no era el modelo, era cuánto contexto le pediste.

¿Qué significa esto para tu startup?

1. Elige modelo por parámetros activos, no por tamaño total

Si tu hardware es limitado (como la mayoría de startups), prioriza modelos MoE sobre modelos densos. Un Qwen 3.6 35B-A3B (3B activos) entregará mejor experiencia que un Gemma 4 31B (31B activos) en el mismo hardware. La diferencia no es marginal: es de 6,7 vs 76 tokens por segundo en las mediciones de Tala.

Acción concreta: Antes de descargar un modelo, verifica si es denso o MoE. Busca la "A" en el nombre (ej: 35B-A3B) — ese segundo número después de la A son los parámetros activos.

2. Mide en tu hardware, con tu carga real

Los benchmarks publicados rara vez reflejan tu caso específico. Como muestra el análisis de benchmarks de 2026, TensorRT-LLM puede ser hasta 14% más rápido que vLLM en H100, pero requiere 28 minutos de compilación. SGLang brilla en cargas con prefijos compartidos, pero en tráfico mixto la diferencia con vLLM es de solo ~4%.

Acción concreta: Dedica una tarde a medir tus modelos candidatos en tu hardware, con tu nivel de concurrencia real. Usa scripts abiertos como los de local-llm-agentic-workflows para estandarizar las pruebas.

3. Optimiza memoria antes de optimizar velocidad

El mayor ahorro de recursos viene de gestionar el contexto, no de cambiar de motor. Reducir el contexto máximo de 256k a 64k tokens liberó 68 GB en el setup de Tala sin impacto en velocidad.

Acción concreta: Establece límites realistas de contexto según tu caso de uso. Para la mayoría de aplicaciones empresariales, 64k tokens es más que suficiente y reduce drásticamente los requisitos de memoria.

4. Elige motor según tu patrón de uso, no según benchmarks

• vLLM: Default para la mayoría — amplia compatibilidad, sin compilación, arranca en ~62 segundos
• SGLang: Ideal para RAG, chat multitud, agentes con instrucciones repetidas
• TensorRT-LLM: Solo si tu modelo es fijo por semanas y puedes pagar 28 minutos de compilación
• llama.cpp: Para Mac, laptops o hardware sin GPU NVIDIA

El chasis que nadie menciona: el harness del agente

Un motor suelto no te lleva a ninguna parte. Lo que conecta el modelo con herramientas reales (buscar en web, leer bases de datos, ejecutar código) es el harness del agente. Esta pieza:

1. Administra la memoria de la conversación
2. Decide qué hacer cuando el modelo se equivoca
3. Pone límites de seguridad e información

Cuando alguien dice "uso ChatGPT", no está eligiendo solo un modelo: está eligiendo el chasis completo que viene armado alrededor. En tu máquina, ese chasis lo pones tú — y ahí es donde se gana o pierde el producto.

Conclusión: elige por el trabajo, no por la tabla

La decisión final de Tala contradice sus propias mediciones: está cambiando de Qwen 3.6 35B (77,8 tokens/s) a Nemotron 3.5 Lightning (77,9 tokens/s) — velocidad prácticamente idéntica. ¿Por qué? Porque Nemotron orquesta mejor en tareas complejas que encadenan múltiples pasos.

La lección más valiosa: elige por el trabajo que le vas a dar, no por la tabla. Un modelo que orquesta bien y arranca lento le gana a uno veloz que se pierde al tercer paso, si lo tuyo son agentes. Si lo tuyo es chat simple, la respuesta se da vuelta.

Cuatro aprendizajes clave para cualquier founder:

1. Cambiar de motor no cambia lo que el modelo responde — cambia velocidad y memoria
2. Los benchmarks publicados no son tu máquina — mide con tus prompts, en tu hardware
3. Desconfía del número que te muestran — pregunta siempre si es velocidad por petición o total agregado
4. Casi siempre el error está en la configuración, no en el motor — antes de cambiar herramienta, revisa cómo la estás llamando

Fuentes

• Los motores de la IA explicados con autos (y los números de mi máquina)
• LLM Inference Engine Benchmarks 2026: vLLM, SGLang, TensorRT-LLM
• GitHub - vllm-project/vllm: A high-throughput and memory-efficient inference and serving engine for LLMs