Motores de inferencia comparados

El motor es el programa que convierte pesos en tokens: carga el archivo,
corre la pasada hacia adelante del transformer y habitualmente habla HTTP
encima. La buena noticia es que casi todo motor corre el mismo modelo más
o menos a la misma velocidad en el mismo hardware — la elección de motor
va de flujo de trabajo, soporte de formatos y concurrencia, no de tok/s
en bruto. La mala noticia es la misma: comprar benchmarks entre ellos es
mayormente esfuerzo desperdiciado.

El panorama

Una nota de linaje: Ollama y LM Studio corren ambos llama.cpp por
debajo. Compararlos con llama.cpp es comparar empaquetados, no
inferencia.

También conviene saber: llama.cpp distribuye más que un servidor —
herramientas de cuantización y conversión, un arnés de benchmark y
bindings para una docena de lenguajes.

Detalles en profundidad

vLLM nació de la idea de la atención paginada (véase
concurrencia): trata la memoria de GPU como un
sistema operativo trata la RAM, y caben muchas más peticiones. Es la
respuesta por omisión a «tengo un servidor con GPU y tráfico real».

SGLang cachea prefijos entre peticiones (RadixAttention): si 40
agentes comparten el mismo prompt de sistema de dos páginas, el prompt se
procesa una vez, no 40. También es conocido por su decodificación
restringida rápida — véase salida estructurada.

exllamav2 es el filo cortante para exactamente un nicho: un solo
usuario en una sola GPU NVIDIA que quiere el máximo tok/s por bit de
cuantización. La historia de servidor y la amplitud de hardware son
finas; el nicho es real.

MLX es el framework de ML de Apple, construido para memoria
unificada. A fecha de redacción mlx-lm a menudo supera al camino Metal
de llama.cpp en modelos grandes — lo bastante cerca de que en una Mac
valga la pena probar ambos (más en Apple silicon).

transformers es la referencia lenta y fiel: cuando un motor
cuantizado hace algo raro, correr el mismo modelo a través de él responde
«¿es el motor o el modelo?». Es también la fontanería bajo las
herramientas de ajuste fino (véase ajuste fino).

Elige por necesidad

Dos notas sobre la tabla:

• «Empieza con» no es «te conformas con» — todo motor de escritorio lee
  el mismo GGUF, así que probar un segundo cuesta cinco minutos, no una
  migración.
• Cuando compares, mantén todo constante: mismo modelo, misma
  cuantización, mismo prompt, modelo ya en caliente.

La división de formatos refleja la división escritorio/servidor

GGUF contra safetensors (véase formatos de modelo)
no es solo una preferencia de contenedor — decide tu motor. GGUF es el
formato de archivo único, pre-cuantizado, corre-donde-sea, y todo el
ecosistema de escritorio (llama.cpp, Ollama, LM Studio) está construido
sobre él. safetensors es el formato de tensores fragmentados del
ecosistema Hugging Face; los motores de servidor de alto rendimiento
(vLLM, SGLang, transformers) lo consumen, normalmente cuantizado al vuelo
(variantes AWQ/GPTQ) en vez de preempaquetado.

Así que el árbol de decisión real es corto: escritorio y un solo usuario
→ motores GGUF; servidor y concurrencia → motores safetensors. Todo lo
demás es detalle.

Cuando algo «no puede correr», comprueba primero el formato — la mitad de
«el motor X no puede correr el modelo Y» es un desajuste
GGUF/safetensors, no una brecha de capacidad.

La sobrecarga no es la historia

En hardware idéntico con cuantización idéntica, los motores quedan dentro
de un 10–20% entre sí en decodificación de flujo único — a menudo porque
comparten backend. Lo que de verdad mueve tu velocidad experimentada por
múltiplos, no por porcentajes:

• Si el modelo ya está cargado — una carga en frío cuesta de segundos a
  un minuto.
• Si toda la conversación se reenvía cada turno — coste de contexto,
  véase tokens.
• Si las peticiones se encolan unas detrás de otras — véase
  concurrencia.
• Si las capas están en la GPU — véase controles del motor.

Misma GPU, mismo 8B Q4_K_M, flujo único (ilustrativo, no especificaciones):
llama.cpp / Ollama / LM Studio    ~130–145 tok/s   (el mismo motor por debajo)
exllamav2 EXL2 ~4bpw              ~160–180 tok/s   (cargador afinado para decodificar)

Misma GPU, 8 flujos de chat concurrentes:
llama-server cola serial          cada flujo espera; rendimiento total plano
vLLM                              todos los flujos cerca de la velocidad de flujo único

Elige el motor que encaje con tu flujo de trabajo, y gasta tu energía en
patrones de E/S en vez de benchmarks de motores.

Un archivo, muchos motores

Un GGUF que descargaste para Ollama también corre en llama.cpp
directamente y en LM Studio — los motores no convierten ni re-descargan;
los apuntas al mismo archivo (Ollama puede importar una ruta local con
un Modelfile de una línea). Lo mismo vale del lado servidor con los
safetensors entre vLLM y SGLang. Consecuencia práctica: no hay
encasillamiento a nivel de archivo, y equivocarte de motor te cuesta
minutos.

Por eso esta página insiste en el flujo de trabajo sobre los benchmarks:
cuando tus necesidades cambian, los modelos que ya descargaste se mueven
contigo.

Cuándo migrar de Ollama

Los valores por omisión de Ollama son excelentes hasta que dejan de
serlo. Pasa a un motor de servicio cuando:

• Necesitas concurrencia sostenida más allá de un puñado de flujos
  (véase concurrencia).
• Quieres caché de prefijos entre muchos agentes que comparten un prompt
  de sistema (SGLang).
• Debes servir cuantizaciones safetensors AWQ/GPTQ directamente del
  ecosistema HF.
• Estás haciendo pruebas de carga de una funcionalidad de producto antes
  de enviarla.
• Necesitas paralelismo de tensores multi-GPU para repartir un modelo
  grande entre tarjetas.

Hasta que una de esas sea cierta, la comodidad vale más que el
rendimiento.

Relacionados: Formatos de modelo · Controles del motor · Servir un endpoint · Elegir un modelo