Ir al contenido

Ejecutores de IA local: cuál elegir

Lo más importante que hay que saber: **Ollama, LM Studio, Jan, KoboldCpp y Docker Model Runner usan todos el mismo motor** — llama.cpp, y MLX en Mac. No se diferencian en velocidad, sino en el envoltorio y en los **valores por defecto**. Y justo ahí está la trampa: Ollama **corta a 4.096 tokens** de fábrica, aunque el modelo pudiera con 256 mil.
13 de septiembre de 2026 por
Ejecutores de IA local: cuál elegir
Krisztian Eyssen, Krisztian Eyssen

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:

  1. 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.
  2. llamafile ya no está en Mozilla, sino en la organización mozilla.ai desde octubre de 2025. Para los usuarios existentes no cambió nada.
  3. 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.

Ejecutores de IA local: cuál elegir
Krisztian Eyssen, Krisztian Eyssen 13 de septiembre de 2026
Compartir esta publicación
Archivar