Los motores de la IA explicados con autos (y los números de mi máquina)

Esta mañana medí un modelo nuevo en mi máquina y me dio 3,70 tokens por segundo. Un número ridículo. El modelo era Muse Glimmer, el que Meta acaba de liberar, y sus resultados publicados decían otra cosa. Le dije al agente que ese número contradecía todo lo demás y que volviéramos a medir.

Volvimos a medir preguntando distinto. Mismo modelo, misma máquina, mismo día: 180 tokens por segundo.

Si “tokens por segundo” no te dice nada, es simple: un token es un pedacito de palabra, y esa cifra es la velocidad a la que la IA te escribe la respuesta en pantalla. De 20 para arriba va más rápido de lo que alcanzas a leer. Con 3,70 te quedas mirando el cursor.

No cambió el modelo. Cambió cómo le preguntamos. Y esa es toda la historia de este post, porque hay una pieza en el medio que casi nadie explica y que decide si tu IA vuela o se arrastra: el motor.

El modelo no es el auto

Empecemos por lo básico, porque acá se confunde todo el mundo.

Un modelo de IA es un mapa gigante. Miles de millones de coordenadas guardadas en un archivo. Cuando descargas “Qwen 3.6” o “Llama”, eso es lo que baja a tu disco: un archivo. Puede pesar 20 GB o 200 GB.

Y como todo mapa guardado en un cajón, no hace nada solo. No responde, no piensa, no se ejecuta. Necesitas un programa que lo abra, lo cargue en memoria y sepa consultarlo.

Ese programa es el motor.

En los artículos técnicos vas a verlo escrito como motor de inferencia, y ahí se pierde medio mundo. “Inferencia” es solo la palabra elegante para el momento en que el modelo responde. Cada vez que la leas, cámbiala mentalmente por “responder” y no pierdes nada: motor de inferencia es el programa que hace responder al modelo. Nada más.

Pieza del auto	Pieza en IA	Qué es en concreto
Mapa de rutas	El modelo	El archivo que descargaste (Qwen, Llama, Gemma)
Motor	El motor de inferencia	vLLM, llama.cpp, MLX, TensorRT-LLM, SGLang
Chasis y carrocería	El harness del agente	Lo que conecta el modelo con herramientas y memoria
Tablero	La interfaz	Tu chat, tu app, tu bot de Telegram
Bencina	Los datos que le pasas	Tu pregunta, tus documentos, el contexto

La regla para no perderse: si cambias el mapa, es otro auto. Si cambias el motor, es el mismo auto andando distinto. Un mismo modelo con dos motores responde lo mismo, pero uno tarda el doble o se come el triple de memoria.

Por eso existen varios motores. Todos abren el mismo tipo de archivo. Cada uno lo hace a su manera.

Los motores que importan en 2026

vLLM, el estándar de la industria

Está afinado para atender muchas peticiones a la vez sin que nadie espere de más. Si una startup tiene un chatbot con diez mil clientes, lo más probable es que corra vLLM por debajo.

Funciona solo con tarjetas NVIDIA. Es open source y es lo que uso yo en producción.

TensorRT-LLM, el traje a medida

Es de NVIDIA, y también es open source (Apache 2.0, en GitHub). Su gracia es que compila el modelo a la medida exacta de tu tarjeta antes de correrlo. El resultado puede ser la versión más rápida posible, pero queda amarrado a ese hardware: si cambias de tarjeta, recompilas.

Acá va la primera corrección a lo que yo mismo creía, y viene con número más abajo: TensorRT-LLM brilla en las tarjetas de centro de datos para las que fue afinado. En hardware de escritorio puede quedar bastante atrás.

llama.cpp, el que corre donde sea

Un motor que funciona con casi cualquier combustible: Mac, Windows, Linux, una laptop sin tarjeta dedicada, un celular, una Raspberry Pi. Nació como el proyecto de una persona sola, el búlgaro Georgi Gerganov, y hoy es la puerta de entrada de la mayoría de la gente a la IA local.

Corre en Mac sin problema, porque CUDA, la tecnología que usan vLLM y TensorRT-LLM, no existe en Apple Silicon. Pero si tu máquina es un Mac, no es tu mejor opción. Para eso está el siguiente.

MLX, el que le saca partido al Mac

Apple hizo su propio motor para sus propios chips, y en Mac le gana a llama.cpp por bastante.

La razón es de diseño. En un Mac, procesador y tarjeta gráfica comparten la misma memoria, y MLX se construyó sobre esa idea: lee el modelo sin andar copiándolo de un lado a otro. llama.cpp llegó a Mac adaptando un diseño pensado para tarjetas NVIDIA, y esa herencia se paga.

Los números de 2026 no son sutiles. En un Mac mini M4 Pro, el mismo modelo dio 130 tokens por segundo con MLX contra 43 con llama.cpp. Tres veces. La ventaja se achica en modelos grandes, donde el cuello vuelve a ser la velocidad de la memoria y los dos se emparejan.

La señal de que esto va en serio: Ollama, que es como la mayoría de la gente corre modelos en su computador, cambió su motor de llama.cpp a MLX en marzo de 2026 y reportó casi el doble de velocidad en todos los Mac. Si usas Ollama en un Mac y lo tienes actualizado, ya estás corriendo MLX aunque no lo supieras.

SGLang, el de las conversaciones largas

Viene del grupo LMSYS, los mismos de Chatbot Arena. Su especialidad es reutilizar el trabajo ya hecho cuando muchas peticiones comparten el mismo comienzo, algo típico en agentes que repiten las mismas instrucciones en cada turno.

Contra vLLM, las mediciones públicas de 2026 los dejan dentro de un 10 a 20% uno del otro. SGLang saca ventaja clara cuando ese comienzo repetido existe; cuando cada consulta llega distinta, quedan casi empatados. No hay ganador universal, hay trabajos distintos.

NVIDIA NIM, que no es un motor

Este es el que estaba mal en mi cabeza hasta hoy.

NIM no es un motor: es un envoltorio. Por dentro trae uno de los motores anteriores. Lo comprobé revisando los que probé: el NIM de Nemotron trae SGLang, 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. Te ahorra la tarde de configurarlo. Si tu motor te da 75 tokens por segundo, el envoltorio te va a seguir dando 75.

Dicho eso, esa tarde vale plata. Hoy bajé el modelo nuevo de Meta con su NIM y quedó andando en cinco minutos, con herramientas y visión funcionando de entrada. La alternativa era compilar una versión especial a mano: una o dos horas, con todo lo que puede salir mal en el camino. Mi regla quedó así: si existe el NIM oficial, parto por ahí; si me estorba, me bajo al motor directo.

Lo que pasó cuando los probé en mi máquina

Todo lo anterior lo puedes leer en cualquier parte. Esto no.

Corro un DGX Spark, la caja chica de NVIDIA con 128 GB de memoria unificada. Estos son números medidos ahí, con el mismo prompt y el mismo script:

Modelo	Motor	Tokens por segundo
Qwen 3.6 35B-A3B (NVFP4)	vLLM	76
Gemma 4 26B-A4B	vLLM	49,5
Qwen 3.6 35B-A3B (NVFP4)	TensorRT-LLM	34,5
Nemotron-3-Super 120B	TensorRT-LLM	14,7
Gemma 4 31B (denso)	vLLM	6,7

Dos cosas saltan de esa tabla.

La primera: el mismo modelo, en la misma máquina, corrió a menos de la mitad de velocidad con TensorRT-LLM que con vLLM. 34,5 contra 76. Yo llegué a ese experimento convencido de lo contrario, porque el discurso general dice que TensorRT-LLM es el más rápido.

La segunda: Gemma 4 31B corre a 6,7 tokens por segundo y Qwen 3.6 35B corre a 76. El de 35B es más grande y va once veces más rápido. Eso parece un error de tipeo y no lo es.

Por qué el modelo más grande fue once veces más rápido

Acá está el concepto que más rinde entender, y se explica solo con el mapa.

Primero, una palabra que vas a leer en todas partes: parámetros. Son las coordenadas de ese mapa. Cuando alguien dice que un modelo “es de 31B”, quiere decir que tiene 31 mil millones de coordenadas guardadas.

Gemma 4 31B es un modelo denso: consulta esas 31 mil millones de coordenadas en cada palabra que escribe. El mapa entero, siempre.

Qwen 3.6 35B-A3B es lo que se llama mixture-of-experts, o MoE por sus siglas. Tiene 35 mil millones guardadas, pero solo usa 3 mil millones en cada palabra. Es como llevar ocho guías de viaje en la guantera y abrir solo la que corresponde al tramo que vas manejando.

Y ahí está el truco para leer esos nombres que parecen patente de auto. En 35B-A3B, el primer número es lo que el modelo ocupa y el segundo, el que va después de la A, es lo que de verdad trabaja en cada palabra. La A es de activos. Si ves esa segunda cifra, es un MoE; si no aparece, es denso.

En una máquina como la mía, donde el cuello de botella es la velocidad a la que se mueven los datos desde la memoria, eso lo decide todo. Menos coordenadas activas significa menos datos que mover por palabra. De ahí salen los 76 contra 6,7.

Regla práctica para elegir modelo local: mira el segundo número, no el primero. Un “35B” que solo activa 3B te va a volar; un “31B” denso te va a arrastrar.

Y no es un caso aislado. Junté todo lo que llevo medido en esta máquina y el patrón no tiene excepciones:

Modelo	Tipo	Tokens por segundo
Gemma 4 31B	Denso	6,7
Muse Glimmer 30B	Denso	11,3
Nemotron 3 Nano 30B-A3B	MoE	~72
Qwen 3.6 35B-A3B	MoE	77,8
Nemotron 3.5 Lightning 30B-A3B	MoE	77,9

Densos entre 7 y 11. Mixture-of-experts entre 72 y 78. Siete veces de diferencia, con modelos del mismo tamaño nominal.

Para esta máquina la conclusión ya no es una sospecha: los modelos densos no le sirven, los MoE sí. Si tienes hardware parecido, esa sola decisión te va a rendir más que cualquier optimización de configuración que hagas después.

Por qué mi chip nuevo pierde contra uno viejo de centro de datos

Volvamos al TensorRT-LLM que rindió la mitad. La explicación no es que el motor sea malo.

Mi Spark usa un chip GB10, de la generación Blackwell, o sea de lo más nuevo que hay. Pero no tiene cálculo FP4 nativo. FP4 es un formato para guardar el modelo comprimido, y las rutas más rápidas de NVIDIA asumen que el chip sabe operar directo en ese formato. El mío no sabe: descomprime a un formato más gordo en tiempo real y recién ahí calcula.

Los chips de centro de datos como el B200 sí lo hacen nativo. Por eso circulan números de 218 tokens por segundo para el mismo modelo que a mí me da 76. Mismo modelo, misma familia de arquitectura, otro mundo.

La lección general, que sirve para cualquiera que compre hardware para IA: un chip más nuevo no es automáticamente más rápido para tu caso. Lo que importa es qué operaciones sabe hacer nativas y a qué velocidad mueve datos desde la memoria.

El error de medición que me costó la mañana

Ahora sí, los 3,70 tokens por segundo del principio.

Ese número salió de medir el modelo de a una petición. Muse Glimmer es un modelo pensado para agentes que disparan muchas cosas en paralelo, y medirlo así es como cronometrar un bus en el estacionamiento y concluir que es lento.

Al medirlo con peticiones concurrentes, la foto cambió:

Peticiones a la vez	Total agregado	Lo que recibe cada una
1	11,3 tok/s	11,3
4	40,0 tok/s	10,0
8	73,0 tok/s	9,1
16	128,8 tok/s	8,0
32	179,9 tok/s	5,6

Mira bien las dos últimas columnas, porque acá está la trampa que se comen casi todos los titulares.

El total sube y lo que recibe cada uno baja. Con 32 peticiones simultáneas la máquina mueve 180 tokens por segundo en total, pero cada usuario recibe 5,6. Un bus lleno mueve más gente por hora que un deportivo, y aun así el deportivo te lleva más rápido a ti.

Entonces hay dos preguntas distintas y hay que saber cuál estás haciendo:

• ¿Qué tan rápido me responde a mí? Es lo que importa cuando estás tú solo escribiendo en un chat. En la jerga se llama latencia.
• ¿Cuánto trabajo total mueve la máquina en una hora? Es lo que importa cuando le sirves a mucha gente a la vez. En la jerga se llama throughput.

Un motor puede ganar una y perder la otra. Y sí: el número que impresiona en los benchmarks casi siempre es el segundo.

Con esto en la mano, la decisión para mi caso se cayó sola. Mi agente corre hasta tres tareas en paralelo, no treinta y dos. A esa concurrencia, Glimmer me entrega unos 10 tokens por segundo por petición y Qwen me entrega 76.

Y cuando fui a comparar de igual a igual, con las mismas 32 peticiones simultáneas, el remate: Qwen mueve unos 250 tokens por segundo agregados contra los 180 de Glimmer. Gana en los dos regímenes. El modelo que brillaba en la tabla espectacular no me sirve ni cuando lo mido en su mejor escenario.

Eso deja una idea que no es obvia: los 180 no eran un techo de la máquina, eran un techo de ese modelo. Si quiero exprimir la caja, el camino no es cambiar de modelo, es darle trabajo en paralelo al que ya tengo. Pasar de 77 a 250 tokens por segundo es triplicar el trabajo por hora sin comprar nada, y el precio es que cada respuesta individual llega un poco más lenta. Para tareas de fondo, donde nadie está mirando la pantalla esperando, es un cambio gratis.

Lo que de verdad te llena la memoria no es el modelo

Otro hallazgo de hoy que va contra la intuición de todos.

Revisé en qué se me estaban yendo los 112 GB que ocupaba mi setup:

Componente	Tamaño
El modelo	20 GB
La memoria de la conversación	82 GB
Todo lo demás	10 GB

El modelo ocupa 20 GB. Lo que se come 82 GB es lo que el motor guarda para no recalcular la conversación en cada palabra. Mientras más largo el contexto que le permites, más crece esa mochila.

Bajé el contexto máximo de 256 mil tokens a 64 mil y le puse un tope a esa mochila. Resultado: pasé de 112 GB a 44 GB, y la velocidad quedó en 75,3 tokens por segundo contra 75,4 de antes. Sesenta por ciento de memoria liberada, cero costo en velocidad.

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.

El chasis: la pieza de la que nadie habla

Un motor suelto no te lleva a ninguna parte. Le falta transmisión, frenos, volante, asientos.

En IA eso se llama harness del agente, y es lo que:

1. Conecta el modelo con herramientas de verdad: buscar en la web, leer tu base de datos, ejecutar código, mandar un correo.
2. Administra la memoria de la conversación: qué recordar, qué botar, cuánto cuesta cada turno.
3. Decide qué hacer cuando el modelo se equivoca: reintentar, pedir aclaración, avisarte a ti.
4. Pone los límites: qué información puede salir y qué no.

Acá va la parte que más se subestima. Cuando alguien dice “uso Claude” o “uso ChatGPT”, no está eligiendo solo un modelo: está eligiendo el chasis completo que viene armado alrededor. Cuando corres un modelo en tu propia máquina, ese chasis lo pones tú.

Y ahí es donde se gana o se pierde el producto. Un modelo excelente con un chasis pobre entrega respuestas pobres. He visto proyectos persiguiendo dos puntos más en un benchmark de modelos cuando lo que les fallaba era que el agente no sabía reintentar una herramienta caída.

Cuál usar: la respuesta corta

Tu situación	Motor
Tienes GPU NVIDIA y quieres el camino probado	vLLM
Tienes un Mac con chip M	MLX (y llama.cpp como segunda opción)
Tienes PC, laptop sin tarjeta o solo procesador	llama.cpp
Sirves a muchos usuarios con instrucciones repetidas	SGLang (compara contra vLLM con tu carga)
Necesitas soporte oficial y no quieres configurar nada	NIM (recuerda: es envoltorio, no velocidad)
Un modelo que no arranca en vLLM por memoria	TensorRT-LLM, que a veces es la única vía

Ese último caso me pasó: el Nemotron de 120B solo levantó estable con TensorRT-LLM. En vLLM se quedaba sin memoria. El motor “más lento” de mi tabla fue el único que pudo correr ese modelo.

Y aun así, hoy estoy cambiando de modelo

Termino con la decisión que tomé mientras escribía esto, porque contradice a medias todo lo anterior y ahí está la gracia.

Qwen 3.6 35B es el modelo que mueve mi agente hace meses. Es rápido, ve imágenes, usa herramientas sin que haya que arreglarle nada. En la tabla de arriba es el ganador.

Y me estoy cambiando a Nemotron 3.5 Lightning, otro MoE de 30B con 3B activos.

No por velocidad. Los medí a los dos hoy y van iguales, entre 77 y 78 tokens por segundo cada uno. Si me hubiera guiado por el número, no habría movido nada.

Me cambio porque orquesta mejor. Cuando le pido a un agente que encadene varios pasos, decida cuál herramienta usar, revise el resultado y siga, Nemotron se equivoca menos. Eso no aparece en los tokens por segundo, y es justo el trabajo que le doy todos los días.

Y viene con su peaje, que es lo honesto de contar: tarda tres veces más en soltar la primera palabra (0,68 segundos contra 0,22 de Qwen), no ve imágenes, y para que las herramientas le funcionaran hubo que bajar la plantilla oficial de NVIDIA porque la genérica no servía. Tres cosas que pierdo a cambio de una que gano.

La lección de la que menos hablo y más me ha servido: 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, la respuesta se da vuelta.

Cuatro cosas que aprendí a los golpes

1. Cambiar de motor no cambia lo que el modelo responde. Cambia velocidad y memoria. Si buscas mejores respuestas, cambia de modelo o mejora el chasis; el motor no es ahí.

2. Los benchmarks publicados no son tu máquina. Los 218 tokens por segundo que leí eran de otro chip. Mide con tus prompts, en tu hardware, con tu nivel de concurrencia real. Es una tarde de trabajo y te ahorra decisiones caras.

3. Desconfía del número que te muestran. Pregunta siempre si es velocidad por petición o total agregado. Si no lo dice, asume que eligieron el que se ve mejor.

4. Casi siempre el error está en la configuración, no en el motor. Yo estuve por descartar vLLM entero cuando el problema real era una pieza interna que venía activada por defecto y no le calzaba a mi chip. Cambiar esa sola opción dejó de tumbarme el servidor y no me costó ni un punto de velocidad. Antes de cambiar de herramienta, revisa cómo la estás llamando.

Lo que viene

Habrás notado que aparecieron por ahí unas siglas: NVFP4, FP8, cuantizado. Es el otro tema grande de correr IA en tu propia máquina: cómo se comprime un modelo para que quepa, y qué pierdes en el camino. Es lo que hace que un modelo de 70 GB entre en 20 GB.

Eso da para su propio post y lo voy a escribir, porque también tiene su sorpresa: en mi máquina el modelo comprimido no fue más rápido que el sin comprimir, por la misma razón del chip que conté más arriba.

Mientras tanto, si vas a correr algo local, quédate con esto: elige el modelo por parámetros activos, elige el motor por tu hardware, y mide tú mismo antes de creerle a nadie. Incluido yo.

Y si mides algo, cuéntalo donde otro lo pueda aprovechar. Cinco personas midiendo en cinco máquinas distintas cubren mucho más terreno del que cubro yo solo con la mía.

Los scripts, las configuraciones exactas y las tablas completas de todo lo que medí están abiertos en local-llm-agentic-workflows.