Este artículo usa nombres de producto
El blog no suele nombrar fabricantes, pero este post es expresamente una comparación de herramientas, y ahí el nombre es la información. Todos los estados son del 13 de septiembre de 2026, verificados.
Quién vive y quién ha muerto
| Ejecutor | Versión / estado | Licencia |
|---|---|---|
| llama.cpp | b10456 (2026-08-17), varias publicaciones al día | MIT |
| Ollama | v0.34.0 (2026-09-05) | MIT (núcleo) |
| LM Studio | 0.4.24 — se parte en varios productos | cerrado, pero gratis en el trabajo |
| vLLM | v0.28.0 | Apache 2.0 |
| MLX / mlx-lm | 0.32.x, Apple | MIT |
| Jan | v0.8.4 | abierto |
| llamafile | v0.10.5 (2026-08-05) — cambió de dueño | Apache 2.0 |
| KoboldCpp | v1.120 (2026-08-29) | AGPL |
| text-generation-webui | v4.9 (2026-05-20) | AGPL |
| Docker Model Runner | GA desde 2025-09-18 | abierto |
| GPT4All | v3.10.0 (2025-02-25) | MIT |
El final de esa lista es lo más importante: GPT4All lleva 19 meses sin publicar una versión. Un informe de error de agosto de 2025, todavía sin respuesta, dice literalmente que no hay soporte para los modelos más nuevos. Si en 2026 alguien te recomienda GPT4All, esa guía también es vieja.
Tres cambios de nombre que conviene conocer:
- LM Studio se ha partido. Hoy «LM Studio» es la aplicación de escritorio; el servicio de fondo sin interfaz es llmster; la herramienta de línea de comandos es lms; y hay además un agent llamado Bionic. Quien escriba sobre «LM Studio» en 2026 tiene que decir de cuál habla.
- llamafile ya no está en Mozilla, sino en la organización mozilla.ai desde octubre de 2025. Para los usuarios existentes no cambió nada.
- Ollama ya no es solo local. En julio de 2026 recibió una inversión de 65 millones de dólares (88 millones en total), tiene servicio en la nube con precios por tiempo de GPU y, según ellos mismos, atiende a 8,9 millones de desarrolladores al mes. En 2026 el nombre significa dos cosas, y solo una es local.
En qué se diferencian de verdad
| Ollama | LM Studio | llama.cpp | vLLM | Jan | Docker Model Runner | |
|---|---|---|---|---|---|---|
| Instalación | un comando | instalador con GUI | compilar o binario | Docker / Python | instalador | docker model run |
| Interfaz | CLI + app | GUI + CLI + sin interfaz | CLI + interfaz web | solo API | GUI | CLI + interfaz de Docker |
| Formato | GGUF, en Mac también MLX | GGUF + MLX | GGUF | nativo de HF, GGUF, FP8 | GGUF + nube | GGUF como imagen de contenedor |
| Paralelismo | débil | medio | bueno | excelente | débil | como llama.cpp |
| Licencia | MIT | cerrado | MIT | Apache 2.0 | abierto | abierto |
| Para quién | «que funcione y ya» | GUI y Mac | todos los interruptores | das servicio a otros | local y nube en una app | ya usas contenedores |
vLLM es el único arquitectónicamente distinto — y el único pensado para servir a muchos usuarios. El resto es el mismo motor con otro envoltorio.
Los valores por defecto que te pillan
Esta es la parte más útil del artículo. Todo sale de documentación primaria.
Ollama:
| Ajuste | Valor por defecto | Cómo lo sobrescribes |
|---|---|---|
| Ventana de contexto | 4.096 tokens | OLLAMA_CONTEXT_LENGTH, o num_ctx |
| Mantener el modelo en memoria | 5 minutos | keep_alive |
| Enlace de red | 127.0.0.1:11434 | OLLAMA_HOST |
| Tipo de KV cache | f16 |
OLLAMA_KV_CACHE_TYPE |
| Quantization propia | solo 3 tipos de los 30 | — |
El servidor de llama.cpp: la ventana de contexto vale por defecto 0, que significa «cargada del modelo».
Aquí está el mejor contraste de todo el artículo:
OLLAMA CORTA por defecto a 4096 tokens,
aunque el modelo pudiera con 256k.
-> Tu texto se pierde EN SILENCIO.
LLAMA.CPP intenta reservar por defecto TODO el
contexto anunciado del modelo.
-> Si no hay memoria, revienta A GRITOS.
Dos valores por defecto opuestos,
dos modos de fallo opuestos.
El silencioso es el más traicionero: el modelo no da error, simplemente deja de acordarse de golpe de lo que había tres pasos antes. Y uno culpa al modelo, no al ajuste.
LM Studio: el servidor escucha en el puerto 1234; el modelo cargado se queda 60 minutos en memoria; y «Auto-Evict» viene activado de fábrica, así que hay como mucho un modelo cargado a la vez. Para uso comercial no hace falta licencia desde julio de 2025.
text-generation-webui: según las notas de la versión de mayo de 2026, el acceso desde el navegador queda restringido «a partir de ahora, por defecto, solo al equipo local». O sea que hasta entonces no era así: quien ejecute una versión anterior puede haber tenido la API accesible desde cualquier página web.
¿Hay diferencia de velocidad medida?
Sí, pero no donde se busca.
Con un solo usuario, apenas. En una comparación, sobre el mismo hardware y con el mismo modelo, vLLM alcanzó 793 tokens por segundo y Ollama 41 — pero exclusivamente bajo carga en paralelo. En modo de un solo usuario ambos rondaban los 130-180 tokens/s, prácticamente igual. La brecha de diecinueve veces sale del batching continuo, no del motor: con peticiones en paralelo, el ejecutor sin batching las pone en cola y su rendimiento total se reparte entre los usuarios.
En Mac sí hay una brecha real, y viene de una medición académica. Un estudio de 2026 sobre una máquina de unified memory, con modelos de cuatro bits:
| Modelo | Ejecutor basado en MLX | llama.cpp | Aceleración |
|---|---|---|---|
| 0,6 mil millones de parámetros | 525,5 | 281,5 | 1,87× |
| 8 mil millones | 93,3 | 76,9 | 1,21× |
| 30 mil millones | 121,8 | 85,1 | 1,43× |
En Mac, los ejecutores basados en MLX son un 20-90 % más rápidos — la brecha no es uniforme: la mayor se dio en el modelo más pequeño. La explicación está en el manejo nativo de la unified memory y en las operaciones con tensores sin copia.
Y la biblioteca de fondo también cuenta. Sobre hardware de otro fabricante, en la misma máquina y con el mismo modelo, entre las dos bibliotecas de fondo disponibles hubo 2,6 veces de diferencia en el procesado del prompt — y con un contexto de ocho mil tokens se dio la vuelta el orden en la generación.
Así que la pregunta «qué ejecutor es más rápido» muchas veces significa en realidad: «qué biblioteca de fondo le compilaron dentro».
De lo que menos se habla: la seguridad
Elegir ejecutor tiene una dimensión de la que no se habla.
- Todo ejecutor basado en llama.cpp hereda los fallos del analizador del formato de modelo. En 2024, 2025 y 2026 se encontraron vulnerabilidades graves, incluidas algunas que pueden llevar a ejecución de código.
- La imagen de contenedor de Ollama escucha de fábrica en todas las interfaces de red, a diferencia de la instalación nativa, accesible solo desde el propio equipo. En una vulnerabilidad de 2024 esa fue justo la circunstancia agravante, y se encontraron más de mil instancias expuestas.
- El archivo de modelo es código, no datos. A principios de 2025 se encontraron dos modelos maliciosos en un sitio de intercambio muy usado, sorteando el escáner de seguridad.
- La pregunta pública sobre la telemetría de Ollama lleva abierta sin respuesta desde febrero de 2024. La documentación dice solo que no ven los prompts, que no es lo mismo que no enviar nada.
De eso habla con más detalle el post IA privada , con los casos.
¿Cuál eliges?
"QUE SIMPLEMENTE FUNCIONE"
-> Ollama. Un comando y arranca.
Lo primero: cambia la ventana de contexto.
QUIERES GUI Y ESTÁS EN UN MAC
-> LM Studio. Con soporte MLX, que en Mac
es más rápido de forma medible.
QUIERES TOCAR TODOS LOS INTERRUPTORES
-> llama.cpp. El motor en sí, directamente.
DAS SERVICIO A OTROS (varios usuarios)
-> vLLM. Con carga en paralelo, 19 veces de
diferencia: es el único hecho para eso.
LOCAL Y NUBE EN UNA SOLA APP
-> Jan.
YA TRABAJAS CON CONTENEDORES
-> Docker Model Runner.
La lista de comprobación inicial
Seis puntos, todos deducidos de documentación primaria:
1. CONFIGURA LA VENTANA DE CONTEXTO
El valor por defecto es demasiado pequeño
(4096) o demasiado grande ("del modelo").
2. KV CACHE A 8 BITS SI EL CONTEXTO ES LARGO
La mitad de memoria, pérdida inmedible.
3. MIRA A QUÉ SE ENLAZA EL SERVIDOR
La instalación nativa, a loopback; la imagen
de contenedor, a TODAS las interfaces.
4. MIRA CUÁNTO SE QUEDA EL MODELO EN MEMORIA
5 minutos o 60 minutos. Eso decide si la
primera petición será lenta.
5. ACTUALIZA EL EJECUTOR
El analizador del formato de modelo tuvo
varias vulnerabilidades graves de 2024 a 2026.
6. DESCARGA MODELOS SOLO DE FUENTES FIABLES
Un archivo de modelo puede contener código.
El primer punto son cinco segundos, y evita la decepción más frecuente.
Malentendidos habituales
- «El ejecutor X es más rápido que el Y.» Con un solo usuario, la mayoría ejecuta el mismo motor y en las mediciones rinden prácticamente igual. La diferencia aparece con carga en paralelo y en Mac.
- «GPT4All es un buen comienzo.» No publica versión desde febrero de 2025 y no da soporte a los modelos más nuevos.
- «Ollama es local, así que es privado.» En 2026 el nombre designa un ejecutor local y también un servicio en la nube. Solo uno de los dos es local.
- «Con la configuración de fábrica irá bien.» Un ejecutor corta a 4.096 tokens y el otro reservaría el contexto entero. Ninguno de los dos es lo que quieres.
- «El tamaño de la ventana de contexto depende del modelo.» La capacidad del modelo, sí. Lo que usas de verdad lo decide el ajuste del ejecutor.
- «El modelo descargado son solo datos.» Según un caso documentado, puede contener código ejecutable que se lanza al cargarlo.
Lo que conviene llevarse
Elegir ejecutor no es una decisión de velocidad, porque gran parte del campo usa el mismo motor. Es una decisión de envoltorio, valores por defecto y estilo de trabajo.
Tres cosas que sí cuentan: en Mac, el ejecutor basado en MLX es medible más rápido (un 20-90 %); para varios usuarios hace falta otro software (diecinueve veces de diferencia con carga en paralelo); y el valor por defecto de la ventana de contexto está mal en todas partes: o demasiado pequeño, o demasiado grande.
Si vas a hacer una sola cosa después de instalar: configura la ventana de contexto. Esos cinco segundos valen más que la elección entre ejecutores. Del dimensionamiento se ocupa el post hardware para local LLM , y de la quantization, el post quantization , con las mediciones.