Ollama vs LM Studio vs llama.cpp vs vLLM vs Jan: comparativa completa de herramientas para ejecutar LLM en local 2026

A fecha de agosto de 2026, ejecutar un modelo de lenguaje grande en tu propio portátil o en tu propio servidor ha dejado de ser el experimento de un desarrollador aficionado. Empresas que no pueden subir su documentación interna a una API externa, desarrolladores en solitario que quieren recortar una factura de API de cientos de euros al mes e ingenieros que quieren usar su asistente de código incluso dentro de un avión: todos se enfrentan a la misma pregunta. «Vale, ¿y con qué lo ejecuto?» Esta guía de comparativa de herramientas para ejecutar LLM en local existe para responderla. Está escrita exclusivamente con datos verificados directamente en las páginas oficiales de releases y de precios de cada proyecto a 2 de agosto de 2026.

En esta categoría hay cinco opciones que realmente entran en la conversación: Ollama, LM Studio, llama.cpp, vLLM y Jan. Basta con mirar las estrellas de GitHub para ver que estas cinco se reparten el mercado. Consultando la API de GitHub el 2 de agosto de 2026 obtenemos: Ollama 177.543, llama.cpp 122.385, vLLM 87.913 y Jan 43.808. (LM Studio no puede compararse por estrellas, porque la aplicación en sí es de código cerrado. Lo único público son la CLI lms y el SDK, con 5.138 estrellas.)

Los tres cambios más importantes que ha vivido este mercado en la primera mitad de 2026 son estos. Primero, se ha roto la ecuación «solo local = totalmente gratis». Ollama opera suscripciones de pago Pro/Max/Team y LM Studio, créditos de nube con tarificación por tokens. Segundo, el backend MLX se ha convertido en el estándar de facto en Apple Silicon: lo han adoptado Ollama (desde 0.19), LM Studio y Jan (desde 0.7.7). Tercero, la agentización: Ollama 0.32.0 lanza un agente con solo escribir ollama, y LM Studio ha sacado un producto de agente independiente llamado «Bionic».

En esta guía repasamos, a lo largo de más de 10.000 caracteres, las últimas versiones y licencias de las cinco herramientas, los benchmarks medidos, los planes de precios, las limitaciones por hardware y la recomendación final según el perfil de usuario. En el capítulo 6 corregimos además seis afirmaciones que buena parte de los artículos que circulan siguen contando mal. Adelantando la conclusión: el 80 % de esta decisión se resuelve con una sola pregunta, «¿lo usas tú solo o se conectan varias personas a la vez?».

1. Resumen ejecutivo: las 5 grandes herramientas de LLM local de un vistazo (agosto 2026)

Para quien tenga prisa, hemos condensado en una sola tabla las especificaciones clave de las cinco herramientas. Todas las versiones, precios y licencias de la tabla se verificaron directamente en las fuentes oficiales el 2 de agosto de 2026.

📊 Tabla comparativa completa de las 5 herramientas para ejecutar LLM en local (agosto 2026)

Las tres filas de esta tabla que deberían saltarte a la vista antes que ninguna otra son capacidad de servicio concurrente, Apple Silicon / MLX y formatos de modelo soportados. Casi todos los desastres por elegir mal la herramienta nacen de empezar sin haber leído esas tres líneas. Los casos típicos: perder un día entero intentando instalar vLLM en un MacBook, o levantar un chatbot interno con la configuración por defecto de Ollama y luego preguntar por qué va tan lento cuando las peticiones concurrentes suben a varias decenas.

La fila de formatos de modelo soportados merece atención especial, porque es el mayor factor de dependencia (lock-in) de esta categoría y aun así falta en casi todas las comparativas. Ollama, LM Studio, llama.cpp y Jan comparten el ecosistema GGUF (+MLX), pero vLLM gira en torno a HF safetensors y derivados (FP8, AWQ, GPTQ), y su soporte de GGUF salió del núcleo hacia el plugin fuera del árbol vllm-gguf-plugin. La propia documentación de vLLM lo describe como «highly experimental and under-optimized» y recomienda tomar el tokenizador del modelo base en lugar del GGUF. En la práctica, las cuatro primeras herramientas se pasan los archivos de modelo entre ellas sin fricción, mientras que mudarse a vLLM obliga a reaprovisionar la biblioteca de modelos entera.

2. Comparativa de las 5 herramientas de LLM local: análisis a fondo de sus funciones clave

Entender «para qué se creó cada herramienta» hace que la elección sea mucho más sencilla. Las cinco, más que competir, ocupan capas distintas. De hecho, LM Studio y Jan usan llama.cpp internamente como motor, y Ollama también partió de tecnología de la familia llama.cpp.

🦙 1) Ollama: n.º 1 en lanzador de modelos locales con una línea de CLI

• Comodidad de despliegue abrumadora: con dos comandos, ollama pull y ollama run, pasas de la descarga del modelo a la conversación. Mantiene su propio registro de modelos, así que puedes traértelos por nombre igual que en Docker Hub, y soporta el formato GGUF. Con 177.543 estrellas en GitHub es la primera de las cinco, y ese tamaño de ecosistema es precisamente su mayor activo: casi cualquier herramienta de terceros trae integración con Ollama de serie.
• Llegada del agente conversacional (v0.32.0, 11 de julio de 2026): ahora basta con ejecutar el comando ollama para que aparezca un agente capaz de chatear, programar, buscar en la web y delegar tareas. Eso sí, conviene saber que el modelo por defecto es glm-5.2:cloud, es decir, un modelo en la nube. Es el punto exacto en el que su imagen de «herramienta solo local» empieza a divergir de su comportamiento real.
• Apple Silicon vía backend MLX (v0.19, 30 de marzo de 2026): el rendimiento en Apple Silicon mejoró de forma notable. Ahora bien, la condición que fija el blog oficial es para la release en preview de MLX: «Please make sure you have a Mac with more than 32GB of unified memory». Es un punto que se tergiversa con facilidad, así que conviene ser preciso: en un MacBook de 8 o 16 GB Ollama no deja de funcionar, simplemente no obtienes la aceleración MLX. Por debajo de ese umbral funciona con normalidad por la ruta Metal (llama.cpp) de siempre. Desconfía de cualquier artículo que lo reformule como «Ollama exige un Mac de 32 GB o más».
• Ajustes de peticiones concurrentes: según el FAQ oficial, OLLAMA_NUM_PARALLEL es «el número máximo de peticiones paralelas que cada modelo procesa a la vez, por defecto 1», y OLLAMA_MAX_LOADED_MODELS viene por defecto en «3 × el número de GPU». Es decir, Ollama sí expone la decodificación por slots paralelos de llama.cpp, pero al venir por defecto en 1, una instalación sin tocar serializa las peticiones en la práctica. Si tu chatbot interno va lento, la primera medida es esta variable de entorno, no cambiar de herramienta.
• Empiezan los avisos de fin de soporte para modelos antiguos (11 de julio de 2026): al ejecutar las etiquetas por defecto de CodeLlama, Qwen2.5 y Qwen2.5-coder, Llama 3.x, Mistral, StarCoder y DeepSeek-R1 aparece un aviso de obsolescencia. Traducido: si sigues al pie de la letra un tutorial escrito en 2024 o 2025 vas a ver ese aviso, así que si empiezas ahora, comprueba tú mismo cuáles son las etiquetas de modelo actuales.
• Mejoras constantes del motor: soporta modelos borrador para decodificación especulativa y se ha optimizado la decodificación de Qwen3 MoE. También se ha separado el caché de prompts del desplazamiento de contexto, lo que resuelve los problemas de coherencia en las respuestas. La v0.32.3 añadió soporte de CUDA para Windows ARM64 y la v0.32.5 corrigió un fallo de MLX Metal que degradaba la calidad de salida de los modelos NVFP4 (especialmente Laguna).

💠 2) LM Studio: n.º 1 en escritorio GUI todo en uno sin terminal

• Doble runtime integrado: incorpora los dos runtimes, llama.cpp y MLX, y cada modelo se carga en el motor que corresponde al formato que hayas descargado (GGUF o MLX). Es importante entender que no husmea tu hardware para cambiar de motor por su cuenta. En Mac tienes que descargar un modelo en formato MLX para acabar en el motor MLX; si en ese mismo Mac descargas un GGUF, se ejecuta por la ruta llama.cpp. Como el formato que elijas es el rendimiento que obtienes, merece la pena pensarlo una vez en el momento de la descarga.
• Elección visual del nivel de cuantización: en el navegador de modelos de la GUI puedes ver y elegir niveles como Q4_K_M o Q8 de un vistazo. Para el principiante que no tiene ni idea de qué versión encaja en su RAM o su VRAM, esta única pantalla es decisiva. En las demás herramientas toca deducirlo interpretando nombres de archivo.
• Peticiones paralelas con batching continuo (0.4.0, 28 de enero de 2026): fue una actualización mayor que trajo de golpe modo de despliegue como servidor, procesamiento de peticiones en paralelo, nuevos endpoints REST y un rediseño de la interfaz. Es la herramienta de escritorio con GUI más avanzada en concurrencia, lo que abre la puerta a usarla como servidor de un equipo pequeño.
• Demonio headless llmster: un componente que permite ejecutarla solo como servidor, sin GUI, con comandos de instalación para Mac, Linux y Windows. Habilita el flujo «configuro con la GUI y despliego como servidor».
• Bionic, su producto de agente (anunciado el 16 de julio de 2026): un agente de IA exclusivo para modelos abiertos, con vista previa inicial en macOS y Windows; el 27 de julio se añadió soporte para ejecutar Kimi K3 en Bionic. Eso sí, el precio del Bionic Pass sigue sin anunciarse: la página oficial solo dice «coming soon».
• Uso profesional gratuito (8 de julio de 2025): antes hacía falta una licencia comercial aparte para usarlo en una empresa; ahora se puede usar gratis en el trabajo sin rellenar formularios ni contactar con nadie. Es un dato que aún no se ha difundido bien.

⚙️ 3) llama.cpp: n.º 1 en motor de inferencia puro, base de todo lo demás

• El origen del formato GGUF: aquí nació todo el ecosistema de cuantizar pesos de 16 bits a 8, 6, 5, 4, 3 y 2 bits. Según algunos informes, ya han aparecido cuantizaciones de nivel 1 bit, lo que sigue ampliando el margen para equipos muy modestos. LM Studio, Jan y Ollama se apoyan todos en esta genealogía.
• Un proyecto sin números de versión: en lugar de versionado semántico usa etiquetas de compilación (bXXXXX). A 2 de agosto de 2026, 08:15 UTC, el build más reciente es b10226, pero las compilaciones se renuevan varias veces al día (solo entre el 1 y el 2 de agosto salieron b10218, b10219, b10221, b10223 y b10224). Notaciones como «llama.cpp versión 1.x» sencillamente no existen.
• La densidad funcional de llama-server: sirve una API compatible con OpenAI en el puerto 8080 por defecto y soporta los endpoints /v1/chat/completions, /v1/completions, /v1/embeddings y /v1/models. Con solo cambiar la base URL, tu código existente con el SDK de OpenAI funciona tal cual. El servidor de 2026 incluye además decodificación paralela (-np), rutas de chat con doble compatibilidad OpenAI + Anthropic, llamada a funciones, decodificación especulativa, entrada multimodal experimental, endpoints de embeddings y reranking, un modo router que gestiona el desalojo LRU de varios modelos y hasta ganchos MCP integrados en la interfaz web.
• Amplitud de backends aplastante: soporta CUDA, Metal, Vulkan, ROCm, SYCL y WebGPU, y funciona en macOS, Linux, Android y Windows. De las cinco herramientas, llama.cpp es primera indiscutible en cobertura de hardware. En abril de 2026 se incorporó soporte del NPU Hexagon de Qualcomm en Linux, lo que según los informes pone a su alcance portátiles Snapdragon y dispositivos edge.
• El flag --tools all: activarlo permite que el LLM acceda directamente al sistema de archivos local desde la interfaz web. Es tan potente como peligroso, así que no lo actives jamás en entornos donde manejes prompts que no sean de confianza.

🚀 4) vLLM: n.º 1 en rendimiento de servicio en producción multiusuario

• PagedAttention: en vez de reservar el caché KV como un bloque de memoria contiguo, lo asigna bajo demanda en bloques de tamaño fijo, igual que la paginación de un sistema operativo. Según la literatura derivada del artículo original, el desperdicio de memoria se reduce hasta 4 veces, lo que permite meter lotes mucho mayores en la GPU. Si te preguntas de dónde sale el rendimiento de vLLM, la respuesta está aquí.
• Batching continuo (continuous batching): en cuanto termina una secuencia del lote, su hueco se rellena de inmediato con una petición nueva. Contrasta con el batching estático tradicional, que arrastraba el problema de «la GPU se queda ociosa hasta que acaba la petición más larga». A esto se suman el prefill por fragmentos (chunked prefill) y Flash Attention.
• Un ritmo de releases brutal: publica cada 2 a 4 semanas. Tras la v0.22.0 del 29 de mayo de 2026 llegaron la 0.22.1 el 5 de junio, la 0.23.0 el 13 de junio, la 0.24.0 el 30 de junio, la 0.25.0 el 11 de julio, la 0.25.1 el 14 de julio y la v0.26.0 el 25 de julio: más de cinco releases menores en apenas dos meses. Lo que hay que tener presente es que en agosto de 2026 sigue en la rama 0.x. «vLLM 1.0» todavía no existe.
• Fronteras muy claras en el soporte de hardware: en GPU cubre NVIDIA CUDA, AMD ROCm e Intel XPU, y en CPU llega hasta x86, ARM AArch64, Apple Silicon e IBM Z (S390X). Sin embargo, la aceleración por GPU en Apple Silicon solo es posible mediante un proyecto aparte llamado vLLM-Metal, no está integrada en el núcleo. Y más importante todavía: Windows no figura en la lista oficial de soporte. Se dice que existen forks de la comunidad, pero no son oficiales.
• Prueba de su adopción empresarial: NVIDIA distribuye por separado notas de release de su propia versión optimizada de vLLM (RN-11517-001_v26.06, julio de 2026). Su arquitectura orientada a contenedores encaja muy bien con despliegues en clústeres de Kubernetes. Si te interesa esta parte, léelo junto al artículo Docker vs Kubernetes vs Podman: comparativa de herramientas de contenedores y el mapa de despliegue te quedará mucho más claro.

🟣 5) Jan: n.º 1 en GUI de código abierto + agente MCP

• Un escritorio completamente open source: aplicación para Windows, macOS y Linux con licencia Apache 2.0. Varias webs de reseñas la catalogan erróneamente como AGPLv3 o MIT, pero verificándolo directamente en el README del repositorio, la correcta es Apache 2.0. La desarrolla Menlo Research y acumula 43.808 estrellas. La mayor diferencia con LM Studio está justo aquí: si la aplicación en sí es de código abierto o no.
• El peculiar puerto 1337: sirve su API compatible con OpenAI en localhost:1337. Es fácil confundirlo con el 11434 de Ollama o el 8080 de llama.cpp, así que memorízalo bien cuando configures integraciones.
• Soporte de MCP (Model Context Protocol): ofrece una interfaz de aprobación de herramientas MCP en línea, de modo que el usuario aprueba sobre la marcha qué herramienta usa el agente y cuándo. Está entre las implementaciones más limpias de funciones de agente en GUI dentro del mundo open source.
• Seis meses de evolución acelerada: la v0.8.0 (22 de mayo) trajo predicción multitoken (MTP) e integración del proceso router de llama.cpp; la v0.8.1 (29 de mayo), proveedores personalizados compatibles con Anthropic y confianza TLS nativa del sistema; la v0.8.2 (1 de junio), backend AMD ROCm/HIP en Linux y pausa y reanudación de descargas; la v0.8.3 (24 de junio), navegación por versiones de mensajes, vista previa de artefactos HTML/SVG y entrada de vídeo; y la v0.8.4 (julio), herramientas nativas web_search y web_fetch y la migración del almacén de credenciales al backend.
• Libertad para conseguir modelos: descarga modelos GGUF directamente de HuggingFace (Llama, Gemma, Qwen, GPT-oss, etc.). Si lo necesitas, también puedes conectar APIs en la nube como OpenAI, Anthropic, Mistral, Groq o MiniMax, pero en ese caso la facturación va directamente al proveedor correspondiente y Jan no cobra nada por el camino.

3. Duelo de benchmarks: rendimiento, latencia y desempeño en Apple Silicon

Vamos con los números. Aquí lo importante no es «quién es más rápido», sino «en qué condiciones es más rápido». En el momento en que ordenas un ranking sin especificar las condiciones, ese benchmark se convierte en una mentira.

Por eso la tabla de estrellas que viene a continuación no son mediciones. Es una valoración cualitativa basada en la arquitectura de cada herramienta (si tiene o no PagedAttention, batching continuo y slots paralelos), y es un tipo de afirmación distinto de las tablas medidas que vienen después. No conviertas el número de estrellas en múltiplos de tok/s.

[Rendimiento total con peticiones concurrentes — valoración cualitativa por arquitectura]
vLLM              : ⭐⭐⭐⭐⭐ (tiene PagedAttention y batching continuo)
llama.cpp         : ⭐⭐⭐⭐☆ (slots paralelos -np + modo router; sin PagedAttention)
LM Studio         : ⭐⭐⭐☆☆ (batching continuo desde 0.4.0, 1.ª entre las GUI)
Ollama            : ⭐⭐⭐☆☆ (slots paralelos con OLLAMA_NUM_PARALLEL, pero por defecto 1)
Jan               : ⭐⭐☆☆☆ (optimizada para escritorio, una persona una petición)

※ La diferencia de estrellas entre Ollama y llama.cpp no es «tener o no la función».
   Viene del valor por defecto (Ollama trae 1 slot) y de la ausencia de PagedAttention.
   Ollama puede activar slots paralelos con una variable de entorno, pero sin caché KV
   paginada, añadir slots desperdicia caché y la curva se aplana antes.

[Velocidad de respuesta percibida en uso individual (lote 1) — valoración cualitativa]
Ollama            : ⭐⭐⭐⭐⭐ (sin sobrecarga de encolado del planificador, primera respuesta rápida)
llama.cpp         : ⭐⭐⭐⭐⭐ (con ajuste manual, el techo más alto de todos)
LM Studio         : ⭐⭐⭐⭐☆ (con modelos en formato MLX, especialmente ventajosa en Mac)
Jan               : ⭐⭐⭐⭐☆ (distancia reducida desde el soporte nativo de MLX)
vLLM              : ⭐⭐⭐☆☆ (sin ventaja en petición única; en TTFT incluso pierde)

📈 3-1. Apple Silicon: mediciones del backend MLX de Ollama (datos oficiales de primera mano)

Las cifras más fiables son los benchmarks de MLX publicados por el blog oficial de Ollama. Las condiciones son familia Apple M5 (M5 / M5 Pro / M5 Max, con aceleradores neuronales en GPU) y el modelo Qwen3.5-35B-A3B.

En decodificación hablamos de una mejora de entre 1,9 y 2,3 veces. Pero no leas esta tabla como «basta con actualizar Ollama para duplicar». Vuelve a mirar las cabeceras: la columna de 0.18 es Q4_K_M y las dos columnas de 0.19 son NVFP4 e int4. Es decir, estas cifras reflejan la subida de versión junto con el cambio a modelos cuantizados en NVFP4 e int4, y si sigues con tu GGUF Q4_K_M y solo actualizas Ollama, no vas a ver esto. El propio blog oficial detalla las condiciones: Qwen3.5-35B-A3B cuantizado a NVFP4 frente a la implementación anterior cuantizada a Q4_K_M en 0.18. Para ver de verdad esta mejora en un Mac necesitas la actualización de Ollama y el cambio de formato de cuantización a la vez, y el rango honesto es de entre 1,9 y 2,3 veces. Aparte, esta ruta MLX solo se abre en Macs con más de 32 GB de memoria unificada. Un MacBook Air de 16 GB no queda excluido de ejecutar Ollama: funciona por la ruta Metal de siempre, simplemente no obtiene las ganancias de esta tabla.

📈 3-2. vLLM vs Ollama: la brecha que abre la concurrencia

Según diversos materiales de benchmarking, al lanzar 128 peticiones concurrentes sobre una NVIDIA A100, vLLM registró unos 793 tok/s frente a los aproximadamente 41 tok/s de Ollama, y la latencia P99 fue de 80 ms en vLLM frente a 673 ms en Ollama. Con 8 peticiones concurrentes, 187 tok/s de vLLM frente a 82 tok/s de Ollama (unas 2,3 veces), y con 64 usuarios simultáneos se reporta una diferencia de rendimiento total de entre 8 y 9 veces.

Estas cifras no deben tratarse al mismo nivel que la tabla MLX de Ollama de más arriba. Son fuentes secundarias cuyos documentos de benchmark originales no hemos podido verificar y, además, ninguna de ellas indica el modelo, la cuantización, la longitud de contexto ni la configuración de slots paralelos de Ollama (OLLAMA_NUM_PARALLEL). Este capítulo abría diciendo que un ranking sin condiciones se convierte en una mentira, así que toca aplicar la misma vara aquí. En particular, si el lado de Ollama se midió con su valor por defecto de 1 slot, buena parte de esa brecha de 8-9 veces podría ser configuración y no arquitectura. No cites los múltiplos exactos: quédate solo con la tendencia. Si necesitas cifras reales para tu entorno, ejecutar vllm bench serve junto a una medición de Ollama en idénticas condiciones será más preciso que cualquier número citado en este artículo.

La tendencia en sí coincide entre múltiples fuentes y es técnicamente sólida. Resumida en tres frases:

1. Con tamaño de lote 1, es decir, en uso individual, los tok/s de Ollama y vLLM son prácticamente idénticos. La diferencia va de un dígito hasta un 20 %, y de hecho Ollama, al no tener sobrecarga de encolado del planificador, suele ser más rápida en latencia hasta el primer token (TTFT).
2. Al subir la concurrencia, vLLM escala su rendimiento de forma suave y ascendente mientras que Ollama se aplana relativamente pronto. Pero decir que «Ollama no tiene paralelismo» es sencillamente falso. Subir OLLAMA_NUM_PARALLEL activa los slots paralelos, y con solo salir del valor por defecto de 1 la curva cambia bastante. Lo que queda después viene de la ausencia de PagedAttention (caché KV paginada) y batching continuo, y esa parte no la cierra ninguna variable de entorno.
3. La conclusión, por tanto, es que «si lo usas tú solo no hay razón para usar vLLM, y en cuanto las peticiones concurrentes llegan a varias decenas no hay más respuesta que vLLM». En la franja intermedia, los slots paralelos de Ollama, el -np de llama.cpp o el batching continuo de LM Studio 0.4.0+ aguantan de sobra. Los umbrales concretos están en el consejo ⑧ del capítulo 6.

📈 3-3. MLX vs llama.cpp y la brecha entre generaciones de Mac

Para un usuario de Mac, elegir backend es elegir rendimiento. Según benchmarks de fuentes secundarias, MLX supera a llama.cpp entre un 20 % y un 87 %, y en rendimiento sostenido con contextos cortos se reportan unos 230 tok/s de MLX frente a unos 150 tok/s de llama.cpp. Hay otro dato que se cita a menudo. Ejecutando Qwen3-Coder-30B-A3B en un Mac mini M4 Pro (64 GB), MLX rindió unos 130 tok/s frente a los 43 tok/s de Ollama (backend llama.cpp): unas 3 veces de diferencia. Esas 3 veces no miden lo mismo que la banda del 20-87 % anterior. La banda compara MLX contra llama.cpp directamente; el caso de las 3 veces compara MLX contra «llama.cpp alcanzado a través del runtime de Ollama», así que es un dato aislado que suma la diferencia de backend y la sobrecarga del runtime de Ollama. Empalmar ambas cifras para afirmar «MLX es 3 veces más rápido» es exagerar.

Tampoco se puede ignorar el salto generacional de hardware. Según los datos agregados de llmcheck.net, el M5 Max entrega alrededor de un +28 % de tok/s respecto al M4 Max. Con Llama 3 8B Q4: 82 tok/s en M5 Max frente a 64 tok/s en M4 Max; con Qwen 3.5 30B-A3B Q4: 58 tok/s en M5 Max frente a 45 tok/s en M4 Max. Los modelos medianos (14-35B) se mueven entre 35 y 55 tok/s en un M4 Pro de 24 GB, y el ancho de banda de memoria del M5 Max de 128 GB ronda los 600 GB/s. Estas cifras dejan clarísimo que lo que determina el rendimiento en LLM local es el ancho de banda y la capacidad de memoria, no el número de núcleos de GPU.

De aquí sale una conclusión práctica: si usas Mac, elige una herramienta con soporte MLX (Ollama 0.19 o superior, LM Studio, Jan 0.7.7 o superior) y descarga modelos en formato MLX. Cambiando solo el backend en el mismo hardware la diferencia es de entre un 20 % y un 87 % (la mayoría de casos reportados caen en la franja del 30-50 %). Existen saltos mayores, como el caso de las 3 veces, pero ahí se suma la sobrecarga del runtime, así que ajusta tus expectativas a la banda y no al caso extremo. Por el contrario, en un servidor con GPU NVIDIA, MLX es irrelevante y basta con elegir entre Ollama y vLLM según tus necesidades de concurrencia.

4. Comparativa completa de precios: ¿hasta dónde llega lo gratis?

Este es el terreno donde más malentendidos hay en esta categoría en 2026. Adelantando la conclusión: la ejecución local es gratuita en las cinco herramientas y lo que se cobra son, en todos los casos, complementos de inferencia en la nube.

[Resumen de la estructura de precios de las herramientas de LLM local, agosto 2026]
- llama.cpp     : 0 $   (sin plan de pago, sin nube, sin suscripción. OSS puro)
- vLLM          : 0 $   (software gratis; el coste es enteramente tu infraestructura de GPU)
- Jan           : 0 $   (escritorio gratis y sin suscripción; las APIs externas las cobra su proveedor)
- LM Studio     : 0 $   (local y uso profesional gratis / la nube va por tokens consumidos)
- Ollama        : 0 $   (local ilimitado y gratis / nube Pro desde 20 $/mes)

💰 4-1. Tabla de precios oficial de Ollama

Llama la atención que el plan Max tenga bloqueadas las altas nuevas. Se lee como una señal de que no dan abasto con la demanda, y para quien empiece hoy las opciones reales son tres: Free, Pro y Team. Conviene saber además que no existe una lista de precios oficial en moneda local: en España pagarás la conversión de 20 $ (unos 18 € al cambio actual) más lo que aplique tu banco, así que confirma el importe real cargado con el tipo de cambio de tu tarjeta antes de suscribirte.

💰 4-2. Estructura de precios de LM Studio

Tarifas de la nube por consumo (por millón de tokens, USD)

Como la tarifa en caché baja hasta una décima parte de la de entrada, en cargas de trabajo que repiten el mismo prompt de sistema el coste real cambia radicalmente. Si quieres profundizar en la comparativa de tarifas de modelos en la nube, te recomendamos revisar la estructura de precios de los modelos frontera en el artículo ChatGPT vs Claude vs Gemini vs DeepSeek: comparativa de modelos de IA.

💰 4-3. El coste de verdad no está en la tabla de precios

Aquí está el meollo. El coste real de un LLM local no es el precio del software, sino el hardware, la electricidad y el tiempo de las personas.

Primero, el coste del hardware. Aquí se mezclan sistemáticamente dos cosas distintas, así que separémoslas. La aceleración MLX de Ollama exige más de 32 GB de memoria unificada, pero eso es una condición de acceso al backend MLX de Ollama, no un requisito de hardware de los modelos de clase 30B. Un modelo de 30B se mueve a 35-55 tok/s en un M4 Pro de 24 GB (ver 3-3). Un equipo por debajo de 32 GB no queda excluido de esta conversación de rendimiento: simplemente no usa la ruta MLX de Ollama y cae en la ruta Metal de siempre. Dicho eso, como el rendimiento en LLM local lo marcan el ancho de banda y la capacidad de memoria, mover modelos grandes con holgura sigue costando dinero: un Mac con memoria unificada generosa o una GPU NVIDIA con VRAM suficiente. Si compensa gastarse varios miles de euros en equipo para ahorrarte una suscripción de 20 $ al mes depende por completo de tu frecuencia de uso.

Hay otro coste que casi nunca aparece en las hojas de cálculo: la migración de formato de modelo. Ollama, LM Studio, llama.cpp y Jan reutilizan los mismos archivos GGUF, pero en cuanto te mudas a vLLM tu biblioteca GGUF no viaja contigo. El soporte de GGUF en vLLM salió del núcleo hacia un plugin fuera del árbol y sigue siendo experimental, así que en la práctica toca volver a descargar compilaciones HF safetensors (FP8/AWQ/GPTQ). Con modelos que van de unos pocos GB a decenas de GB, eso es tiempo de descarga nuevo, almacenamiento nuevo y tiempo de validación nuevo. Además, tendrás que apuntar el tokenizador al modelo base por separado. No se puede escribir sobre «costes que no están en la tabla de precios» y dejar fuera este.

Segundo, la estructura de costes de vLLM es especialmente fácil de malinterpretar. El software es totalmente gratuito bajo Apache-2.0, pero para que vLLM haga aquello para lo que existe hace falta una GPU de centro de datos. Es decir, el coste real de vLLM es la factura íntegra por hora de la instancia de GPU. Visto al revés: si ya tienes esa GPU y se te conectan varios usuarios, vLLM multiplica el rendimiento sobre el mismo hardware y se convierte en una herramienta para reducir el coste unitario por GPU.

Tercero, el coste de las horas de operación. llama.cpp cuesta cero euros en software, pero tienes que lidiar tú con las opciones de compilación y los flags, y como el build tag cambia varias veces al día, debes gestionar por tu cuenta «en qué build funcionaba bien». LM Studio, en cambio, se usa nada más instalarla. Si metes en la cuenta el coste por hora de un ingeniero, la herramienta gratuita no siempre es la más barata.

5. Guía de recomendación final por perfil de usuario

Con todos los datos anteriores sobre la mesa, resumimos la mejor elección para cada situación real. Con leer solo este capítulo ya tienes la conclusión.

🎯 1) Perfil no técnico, product manager o investigador que prueba un LLM local por primera vez

• Mejor elección: LM Studio
• Por qué: no necesitas abrir la terminal ni una sola vez y puedes ver y elegir el nivel de cuantización en el navegador de modelos de la GUI. Sobre todo, desde el 8 de julio de 2025 el uso profesional es totalmente gratuito, así que no hay problema de licencia por instalarla en el portátil de la empresa. Al llevar integrados los runtimes de llama.cpp y MLX, cada modelo se carga en el motor que corresponde a su formato; solo recuerda que en Mac tienes que elegir tú mismo un modelo en formato MLX para acabar en el motor MLX.

🎯 2) Desarrollador individual cómodo con la CLI que cambia de modelo constantemente

• Mejor elección: Ollama
• Por qué: te basta una línea de ollama run, y como delatan sus 177.543 estrellas de GitHub, su ecosistema de integraciones de terceros no tiene rival. Con tamaño de lote 1 su rendimiento es prácticamente igual al de vLLM y además suele ser más rápida en latencia hasta la primera respuesta. Eso sí, las etiquetas de modelo de los tutoriales de 2024 y 2025 (Llama 3.x, Qwen2.5, Mistral, etc.) están marcadas como obsoletas: usa las etiquetas actuales.

🎯 3) Equipo que debe operar un chatbot interno o una API de RAG por encima de 10 peticiones concurrentes

• Mejor elección: vLLM
• Por qué: a partir de esta franja las alternativas se agotan. Su arquitectura reduce el desperdicio del caché KV con PagedAttention y elimina el tiempo muerto de la GPU con batching continuo, así que el rendimiento crece a medida que suben las peticiones concurrentes. Ollama también puede activar slots paralelos con OLLAMA_NUM_PARALLEL, pero sin caché KV paginada, añadir slots desperdicia caché y la curva se aplana antes. Ahora bien, comprueba antes que nada las limitaciones: Windows no está soportado oficialmente, la GPU de Apple Silicon pasa por el proyecto aparte vLLM-Metal y tu biblioteca de modelos GGUF no se transfiere. Ten en cuenta además que un equipo de 10 personas rara vez tiene 10 peticiones simultáneas: mide sobre peticiones concurrentes en pico, no sobre número de empleados.

🎯 4) Ingeniero que necesita exprimir al máximo equipos modestos, dispositivos edge o sistemas embebidos

• Mejor elección: llama.cpp
• Por qué: su amplitud de backends es abrumadora frente a las otras cuatro. Soporta CUDA, Metal, Vulkan, ROCm, SYCL y WebGPU, y funciona en macOS, Linux, Android y Windows. Puedes elegir libremente cuantizaciones de 8/6/5/4/3/2 bits y, con el modo router de llama-server, mover varios modelos con desalojo LRU. En muchos casos es la única opción que funciona en hardware donde ninguna otra herramienta arranca.

🎯 5) Usuario que debe respetar principios de código abierto o quiere experimentar con agentes MCP

• Mejor elección: Jan
• Por qué: es la única herramienta con GUI cuya aplicación es de código abierto bajo Apache 2.0. LM Studio es de código cerrado, lo que complica su aprobación en organizaciones que exigen auditoría. Jan ofrece la interfaz de aprobación de herramientas MCP en línea y en la v0.8.4 ha sumado herramientas nativas web_search y web_fetch. También soporta el backend AMD ROCm en Linux (v0.8.2).

🎯 6) Desarrollador que quiere enchufar un asistente de código en un entorno sin conexión

• Mejor elección: Ollama o LM Studio
• Por qué: ambas tienen asegurada la vía de integración con herramientas de código externas. LM Studio permite usar sus modelos desde Claude Code desde el 30 de enero de 2026, y Ollama restauró en la v0.32.3 la integración con Claude Code Channels y ofrece también la integración con la app Codex (renombrada ChatGPT) mediante ollama launch chatgpt. Si te interesa la diferencia de rendimiento frente a los agentes de código en la nube, te recomendamos leer también Cursor vs GitHub Copilot vs Cline: comparativa de agentes de código con IA.

🎯 7) Casos en los que la política de seguridad corporativa prohíbe que los datos salgan del dispositivo

• Mejor elección: llama.cpp o Jan (alternativa: Ollama configurado solo en local)
• Por qué: las cinco herramientas pueden funcionar completamente offline, pero la única sin ningún componente de conexión a la nube es llama.cpp. Jan tampoco tiene suscripciones ni cargos en el escritorio y su diseño es local-first. Si usas Ollama, comprueba sin falta que el modelo por defecto del agente de la v0.32.0 es glm-5.2:cloud, es decir, un modelo en la nube, y especifica explícitamente un modelo local. Si contratas a nivel de equipo, el plan Team declara retención cero de datos y ausencia de logs.

6. Consejos prácticos y errores frecuentes (lo que se cuenta mal por ahí)

Este es el capítulo más útil del artículo. Recogemos seis afirmaciones que buena parte del material disponible da por buenas y son falsas, verificadas durante la investigación, junto con consejos de campo.

① «LM Studio necesita licencia comercial para usarse en una empresa» → falso. Desde el 8 de julio de 2025 se eliminó el requisito de licencia de uso comercial. Ahora se puede usar gratis en el trabajo sin rellenar formularios ni contactar con nadie. Sin embargo, muchísimos artículos siguen reproduciendo la política antigua, y por eso hay equipos que han descartado LM Studio sin motivo. Si estás evaluando su adopción interna, empieza por corregir este punto.

② «Jan es AGPLv3» → falso. Es Apache 2.0. Varias webs de reseñas la etiquetan como AGPLv3 o MIT, pero la licencia verificada directamente en el README del repositorio es Apache 2.0. La AGPL arrastra la obligación de publicar el código fuente al distribuir el software como servicio en red, y por eso suele bloquearse en las revisiones legales corporativas; Jan no está en ese caso. Si descartaste Jan por la licencia, merece la pena volver a evaluarla.

③ «Ya ha salido vLLM 1.0» → todavía no existe. A agosto de 2026 la última versión es la v0.26.0 y sigue en la rama 0.x. Al ser un proyecto que publica releases cada 2 a 4 semanas, fijar la versión (pinning) es prácticamente obligatorio. Si en tu requirements.txt solo pones vllm, en dos semanas el entorno de tu compañero y el tuyo ya no serán el mismo. Clava la versión exacta y, cuando subas, lee antes las notas de la release.

④ «Ollama es una herramienta totalmente gratuita y solo local» → en 2026 esto solo es medio cierto. La ejecución local sigue siendo ilimitada y gratuita, pero existen suscripciones de nube como Pro por 20 $/mes y el modelo de agente por defecto de la v0.32.0 es un modelo en la nube (glm-5.2:cloud). Es decir: si escribes ollama sin pensar y pegas datos internos de tu empresa, esos datos pueden salir al exterior. En entornos donde la seguridad importa, adquiere el hábito de especificar explícitamente un modelo local en la primera configuración.

⑤ «La última versión de llama.cpp es la 1.x» → ese esquema de versiones ni siquiera existe. llama.cpp no usa versionado semántico, solo etiquetas de compilación (bXXXXX). A 2 de agosto de 2026 es b10226, pero mañana será otra. El consejo práctico es anotar la etiqueta de build en la que has verificado que todo funciona y hacer checkout de esa etiqueta. Si tiras siempre de master, el flag que funcionaba ayer puede fallar hoy.

⑥ «Basta con activar MLX para ir el doble de rápido en Mac» → hay dos condiciones. Primera: el backend MLX en preview de Ollama presupone un Mac con más de 32 GB de memoria unificada. Pero reformularlo como «en un Mac de 16 GB no puedes usar Ollama» es un error: por debajo del umbral Ollama funciona con normalidad por la ruta Metal (llama.cpp) de siempre, solo que sin aceleración MLX. Segunda: las cifras de 1,9-2,3 veces del blog oficial no son el efecto de la subida de versión por sí sola, sino de cambiar a la vez a modelos cuantizados en NVFP4 e int4. Si sigues con Q4_K_M y solo subes la versión, no verás ese rango. Con 16 GB o menos, planifica sobre modelos de 7-8B con cuantización Q4 y cambia el tamaño y el formato del modelo antes que la herramienta.

⑦ Memorizar los números de puerto te ahorra la mitad de los quebraderos de cabeza al integrar. Ollama 11434, llama-server de llama.cpp 8080 y Jan 1337. Las tres ofrecen API compatible con OpenAI, así que con cambiar solo la base URL tu código actual con el SDK de OpenAI funciona tal cual. No hace falta escribir un cliente nuevo. llama.cpp añade además rutas de chat compatibles con Anthropic, de modo que también puedes reutilizar código basado en el SDK de Anthropic.

⑧ Responde primero «¿cuántas peticiones concurrentes hay en pico?» y luego elige la herramienta. (El umbral único de este artículo.) El error de diseño más común es hacerlo al revés. Se ven equipos que levantan Ollama para un servicio interno y, cuando se ralentiza, amplían la GPU. Pero la primera medida no es ni comprar GPU ni migrar a vLLM. Según el FAQ oficial de Ollama, OLLAMA_NUM_PARALLEL —el número máximo de peticiones paralelas que cada modelo procesa a la vez— viene por defecto en 1. Una instalación de Ollama sin tocar está serializando tus peticiones en la práctica, y esa lentitud es un problema de configuración, no de hardware. OLLAMA_MAX_LOADED_MODELS, con un valor por defecto de 3 × el número de GPU, conviene revisarlo al mismo tiempo.

Por eso la receta tiene dos pasos. (1) Sube primero OLLAMA_NUM_PARALLEL y (2) si aun así la curva no remonta, pásate a vLLM. Invertir el orden significa pagar una migración innecesaria más el coste de reaprovisionar todos los modelos. Lo que quede tras el paso 1 viene de la ausencia de PagedAttention y batching continuo, y eso no lo arregla el número de slots.

Este artículo aplica los umbrales de abajo de forma idéntica en todos los capítulos. La métrica son las peticiones concurrentes en pico, no los usuarios registrados.

[Umbral único de decisión, por número de peticiones concurrentes]
1-4 peticiones concurrentes   → Ollama (ajusta NUM_PARALLEL) · LM Studio · Jan
5-10 peticiones concurrentes  → llama.cpp -np · batching continuo de LM Studio 0.4.0+
Más de 10, o cualquier        → vLLM
servicio con SLA

⑨ No ignores los avisos de obsolescencia de las etiquetas de modelo. Desde el 11 de julio de 2026, Ollama muestra avisos de fin de soporte en las etiquetas por defecto de CodeLlama, Qwen2.5 y Qwen2.5-coder, Llama 3.x, Mistral, StarCoder y DeepSeek-R1. Si has copiado y pegado un tutorial y estás viendo ese aviso, es la señal de que ese tutorial tiene al menos un año. Lo más probable es que el resto del contenido también esté desfasado.

⑩ --tools all derriba la frontera de confianza. Al activar este flag de llama.cpp, el LLM accede directamente al sistema de archivos local desde la interfaz web. Para experimentar en solitario es potentísimo, pero en un pipeline que alimenta al modelo con documentos o páginas web de origen externo, una inyección de prompt se traduce directamente en acceso a archivos. No lo actives en entornos que procesen entradas externas.

⑪ Si vLLM está en tu hoja de ruta, presupuesta la reaprovisión de los modelos. «Todas son compatibles con OpenAI, así que es una línea de base URL» aplica solo al código cliente. Los activos de modelo no te siguen. Ollama, LM Studio, llama.cpp y Jan comparten el ecosistema GGUF (+MLX), pero vLLM gira en torno a HF safetensors (FP8/AWQ/GPTQ) y su soporte de GGUF salió del núcleo hacia el plugin fuera del árbol vllm-gguf-plugin. La documentación oficial lo llama «highly experimental and under-optimized», advierte de posibles incompatibilidades con otras funciones y recomienda tomar el tokenizador del modelo base en lugar del GGUF. Así que mete tres líneas en el plan de migración: (1) la lista de modelos a redescargar y su tamaño total, (2) el tiempo de descarga y validación, y (3) todo aquello cuya calidad haya que reverificar al cambiar el formato de cuantización. En la práctica, este es el mayor coste de cualquier cambio de herramienta.

7. Preguntas frecuentes (FAQ)

P. En una comparativa de herramientas para ejecutar LLM en local, ¿cuál gana al final?

No hay una ganadora absoluta, solo ganadoras por condición. Para el desarrollador que trabaja solo, Ollama; si necesitas GUI, LM Studio; para servicio multiusuario, vLLM; para exprimir hardware extremo, llama.cpp; y para principios open source y agentes MCP, Jan. Si hubiera que señalar «la más segura para todos los públicos», Ollama es una primera elección sin sobresaltos por combinar tamaño de ecosistema (177.543 estrellas en GitHub) y facilidad de uso.

P. ¿Qué es más rápido, Ollama o vLLM?

La respuesta se invierte según las condiciones. En uso individual con tamaño de lote 1, los tok/s de ambas son prácticamente idénticos y, de hecho, Ollama suele dar la primera respuesta antes porque no tiene sobrecarga de encolado del planificador. En cambio, cuando aumentan las peticiones concurrentes, vLLM sigue escalando su rendimiento mientras que Ollama se aplana relativamente pronto. Eso sí, no confundas esto con que «Ollama no tenga funciones de concurrencia»: el OLLAMA_NUM_PARALLEL del FAQ oficial fija el número de slots paralelos y viene por defecto en 1, así que buena parte de la lentitud percibida es simplemente no haber subido ese valor. Lo que queda después viene de la ausencia de PagedAttention y batching continuo. Antes de comparar hay que decidir si «rápido» significa rendimiento total o latencia de respuesta.

P. ¿Puedo usar LM Studio gratis en mi empresa?

Sí. Desde el 8 de julio de 2025 se eliminó el requisito de licencia de uso comercial, así que puedes usarla gratis en el trabajo sin rellenar formularios ni contactar con nadie. El plan gratuito incluye ejecución de LLM en local, transcripción de voz offline, el agente Bionic, los backends llama.cpp y MLX y LM Link para hasta 5 dispositivos. Si has visto un artículo que dice «para uso profesional hace falta licencia aparte», ese artículo está desactualizado.

P. Quiero usar LLM local en un MacBook, ¿qué herramienta elijo?

En Mac, la respuesta son las herramientas con soporte del backend MLX. Ollama (0.19 o superior), LM Studio y Jan (0.7.7 o superior) lo soportan todas. Ahora bien, el backend MLX en preview de Ollama exige más de 32 GB de memoria unificada. Aquí es donde se equivoca casi todo el mundo: en un Mac de 16 GB Ollama no deja de funcionar, simplemente no obtienes la aceleración MLX, y la ruta Metal (llama.cpp) de siempre funciona bien. LM Studio y Jan no publican una condición de memoria comparable para MLX, pero el techo de memoria se aplica igual uses la herramienta que uses. En un Mac de 16 GB, los modelos de 7-8B con cuantización Q4 son el límite realista con cualquier herramienta, y de 14B en adelante va justo incluso reduciendo el contexto. Dicho de otro modo, la pregunta real en un Mac de 16 GB no es «Ollama sí o no», sino qué tamaño y formato de modelo puedes cargar. vLLM no es recomendable en Mac: el soporte de GPU en Apple Silicon solo llega a través del proyecto aparte vLLM-Metal y no está integrado en el núcleo.

P. ¿Se puede usar vLLM en Windows?

Oficialmente no. Windows no aparece en la lista de hardware soportado de la documentación oficial de instalación de vLLM. Se dice que existen forks de la comunidad, pero al no ser soporte oficial es arriesgado llevarlos a producción. Si necesitas servicio multiusuario en Windows, aplica los mismos umbrales del consejo ⑧ del capítulo 6. Por encima de 10 peticiones concurrentes, lo realista es montar vLLM sobre WSL2 o sobre un servidor Linux. En la franja de 5 a 10, LM Studio 0.4.0 o superior con batching continuo o la decodificación paralela -np de llama.cpp lo resuelven perfectamente en el propio Windows. Entre 1 y 4, subir el OLLAMA_NUM_PARALLEL de Ollama suele bastar.

P. ¿Son todas las herramientas de LLM local gratuitas? ¿No hay costes ocultos?

La ejecución local sí es gratuita en las cinco. llama.cpp, vLLM y Jan no tienen ningún plan de pago, y Ollama y LM Studio solo cobran por los complementos de inferencia en la nube (Ollama Pro 20 $/mes, LM Studio por tokens consumidos). El coste real es el hardware, la electricidad, las horas de operación y la reaprovisión de modelos. La cifra de 32 GB se confunde constantemente, así que seamos precisos: más de 32 GB de memoria unificada es una condición del backend MLX de Ollama, no un requisito de los modelos de clase 30B. Un modelo de 30B se mueve a 35-55 tok/s en un M4 Pro de 24 GB. Mover modelos grandes con holgura sí cuesta dinero en capacidad y ancho de banda de memoria, claro, y en el caso de vLLM el coste es, en la práctica, íntegramente la factura de la GPU de centro de datos. Por último, como mudarse a vLLM no arrastra tu biblioteca de modelos GGUF, presupuesta el tiempo y el almacenamiento para volver a descargar decenas de gigas.

P. ¿En qué se diferencian LM Studio y Jan?

Ambas son herramientas de escritorio con GUI en primer plano, pero la diferencia decisiva es si son código abierto o no. La aplicación de LM Studio es de código cerrado y lo único publicado en GitHub son la CLI lms y el SDK. Jan, en cambio, es Apache 2.0 en su totalidad. En funciones, LM Studio va por delante en la interfaz de selección visual de cuantización y en peticiones paralelas con batching continuo; Jan destaca en el terreno de los agentes, con aprobación de herramientas MCP en línea y herramientas nativas web_search y web_fetch. Si tu organización necesita auditoría, Jan; si priorizas la comodidad, LM Studio.

P. ¿Cómo compruebo la versión de llama.cpp?

No tiene versionado semántico. En su lugar usa etiquetas de compilación con el formato bXXXXX. A 2 de agosto de 2026, 08:15 UTC, el build más reciente es b10226, pero se actualiza con tanta frecuencia que solo entre el 1 y el 2 de agosto salieron seguidos b10218, b10219, b10221, b10223 y b10224. En producción recomendamos anotar la etiqueta de build en la que has confirmado que todo funciona y fijarla.

P. ¿Puedo migrar mi código actual de la API de OpenAI a un modelo local tal cual?

Sí, en la mayoría de los casos. Las cinco herramientas ofrecen API compatible con OpenAI, así que basta con cambiar la base URL del SDK por la dirección local. Los puertos son Ollama 11434, llama-server de llama.cpp 8080 y Jan 1337; LM Studio y vLLM también ofrecen sus respectivos servidores compatibles. llama.cpp soporta /v1/chat/completions, /v1/completions, /v1/embeddings y /v1/models, y además dispone de rutas de chat compatibles con Anthropic, lo que la hace especialmente portable.

8. Conclusión: la comparativa de herramientas de LLM local en 2026 se reduce a dos preguntas

Hemos repasado versiones, licencias, rendimiento, precios y limitaciones de hardware de las cinco herramientas, pero la decisión real es asombrosamente simple. La primera pregunta es «¿cuántas peticiones concurrentes hay en pico?». Entre 1 y 4, elige a gusto entre Ollama (con OLLAMA_NUM_PARALLEL ajustado), LM Studio y Jan; entre 5 y 10, el -np de llama.cpp o el batching continuo de LM Studio están en su terreno; por encima de 10, o en cualquier servicio con SLA, vLLM. En esa última franja lo que queda es difícil de cerrar con variables de entorno, porque separa tener o no tener PagedAttention y batching continuo (aunque los límites exactos se mueven según tamaño de modelo, longitud de contexto y SLA: mídelo una vez en tu propio entorno). La segunda pregunta es «¿puedes abrir una terminal?». Si puedes, se te abren Ollama y llama.cpp; si no puedes o no quieres, te quedan LM Studio y Jan.

También hay señales claras de que esta categoría ha madurado durante la primera mitad de 2026. En Apple Silicon, MLX se ha consolidado como estándar y el rendimiento en decodificación ha subido con fuerza sobre el mismo hardware (según el benchmark oficial de Ollama, 58 tok/s en 0.18 con Q4_K_M → 134 tok/s en 0.19 con int4; eso sí, es el resultado de una subida de versión y un cambio de formato de cuantización a la vez), y las cinco herramientas ofrecen ya API compatible con OpenAI. Aquí hay una cosa que conviene decir con precisión. El código de llamada a la API se resuelve con una línea de base URL, pero tus activos de modelo no te siguen. Entre las cuatro primeras, los archivos GGUF se pasan sin fricción y cambiar sale realmente barato; pero una biblioteca GGUF no se traslada a vLLM (el soporte salió del núcleo a un plugin experimental fuera del árbol). Si vLLM está en tus planes, presupuesta desde el principio el tiempo y el almacenamiento de reaprovisionar los modelos.

Al mismo tiempo, ha aparecido una tendencia que conviene vigilar. La ecuación «herramienta local = totalmente gratis = los datos no salen jamás» ya no se cumple automáticamente. El modelo por defecto del agente de Ollama v0.32.0 es un modelo en la nube, y LM Studio también opera créditos de nube. Si adoptaste esto por privacidad, verifica sin falta que has especificado explícitamente un modelo local en la primera configuración; y a nivel organizativo, te recomendamos evaluar primero llama.cpp, que no tiene ningún componente de conexión a la nube, o Jan, que es una GUI de código abierto.

Resumen: la recomendación final según tu situación

┌─ ¿Más de 10 peticiones concurrentes en pico? (¿O un servicio con SLA?)
│   └─ SÍ → vLLM (v0.26.0)
│            ※ Windows sin soporte oficial; GPU de Mac vía vLLM-Metal aparte
│            ※ Software gratis; el coste es toda la infraestructura de GPU
│            ※ La biblioteca GGUF no se transfiere → presupuesta reaprovisionar modelos
│
├─ ¿Entre 5 y 10 peticiones concurrentes?
│   └─ SÍ → llama.cpp con decodificación paralela -np (b10226, MIT)
│            o batching continuo de LM Studio 0.4.0+ (0.4.20)
│            ※ Especialmente realista si necesitas multiusuario en Windows
│
└─ NO (1-4 peticiones concurrentes / en la práctica lo uso yo solo)
    │
    ├─ ¿Te manejas con la terminal?
    │   ├─ SÍ ──┬─ Primera opción segura   → Ollama (v0.32.5, MIT)
    │   │       │                            ※ Si va lento, sube OLLAMA_NUM_PARALLEL (por defecto 1)
    │   │       │                            ※ MLX en preview exige más de 32 GB unificados
    │   │       │                              (por debajo funciona la ruta Metal de siempre)
    │   │       │                            ※ Ojo: el modelo del agente es en la nube
    │   │       └─ Ajuste extremo de HW     → llama.cpp (b10226, MIT)
    │   │                                    ※ Más backends que nadie, cero de pago
    │   │
    │   └─ NO ──┬─ Comodidad ante todo      → LM Studio (0.4.20)
    │           │                            ※ Uso profesional gratis desde 08-07-2025
    │           │                            ※ En Mac, elige tú modelos en formato MLX
    │           │                            ※ Pero la app es de código cerrado
    │           └─ Open source y MCP         → Jan (v0.8.4, Apache 2.0)
    │                                        ※ Puerto de API 1337, totalmente gratis
    │
    └─ Si los datos no pueden salir bajo ningún concepto
        → llama.cpp (sin ningún componente de nube) o Jan
        → Con Ollama o LM Studio, especifica siempre un modelo local

[Chuleta de puertos] Ollama 11434 · llama.cpp 8080 · Jan 1337
[Chuleta de precios] En local todo 0 $ / Ollama Pro 20 $ · Team 25 $ (asiento)
                     La nube de LM Studio va por tokens consumidos
[Chuleta de formatos] Ollama · LM Studio · llama.cpp · Jan comparten GGUF (+MLX)
                      vLLM = HF safetensors · FP8 · AWQ · GPTQ (GGUF, plugin experimental)

El LLM local ya no es una cuestión de «¿se puede?», sino de «¿con qué y bajo qué condiciones lo ejecuto?». Toma la chuleta de arriba, elige una hoy mismo e instálala. Dentro del ecosistema GGUF (Ollama, LM Studio, llama.cpp, Jan) puedes cambiarte cuando quieras con una línea de base URL; solo mudarte a vLLM implica volver a aprovisionar los modelos. 🚀