Ollama, LM Studio, llama.cpp y Unsloth, cuál uso para cada cosa

Empecé con un programa para mover modelos en local y he acabado con cuatro. No por coleccionismo, sino porque cada uno me resolvió un problema que el anterior no resolvía. Aquí cuento para qué uso Ollama, LM Studio, llama.cpp y Unsloth, qué problemas reales me ha dado cada uno y cuál instalaría yo según lo que quieras hacer.

Los vídeos lo pintan fácil: «instala esto, descarga un modelo y ya tienes tu ChatGPT privado». Un programa, dos clics y a vivir. Yo también empecé así, con Ollama, en la primavera de 2024, en mi ordenador de trabajo de entonces (Windows y una gráfica de 4 GB), porque era el que salía en todos los tutoriales. Y durante un par de semanas fui feliz.

Luego quise probar modelos sin escribir órdenes, y apareció el segundo programa. Luego quise sacarle más velocidad a una gráfica justita, y apareció el tercero. Luego se me ocurrió afinar un modelo, y llegó el cuarto. Si esto sigue así, dentro de un año tendré once.

En Más de cincuenta modelos probados en casa hablé de los modelos: los ficheros que responden. Aquí hablo de los programas que los mueven, que es la pieza que casi todo el mundo confunde con el modelo.

Un modelo es un fichero grande lleno de números. Solo, no hace nada: no se abre con doble clic ni te saluda. Necesita un programa que lo cargue en memoria, lo ejecute y te deje escribirle. A ese programa se le llama runtime, o motor de inferencia, y cuando además atiende peticiones de otros programas, servidor de modelos.

No hay que confundirlo con un arnés, palabra que en este blog reservo para los agentes. Los arneses, como Claude Code, OpenClaw o DeepSeek Harness, no solo usan el modelo: le dan herramientas, memoria y permisos para que lea archivos, lance órdenes o navegue por internet. Se suele resumir así: un agente es un modelo más un arnés.

Tres de los programas de este artículo son runtimes: cargan el modelo y te dejan usarlo, algunos con una ventana bonita y otros desde la terminal (esa ventana negra donde se escriben órdenes). El cuarto, Unsloth, es sobre todo una herramienta para afinar. Lo que hagas después con el modelo ya es cosa tuya, y de eso va Lo que rodea al modelo para que sirva de algo.

LM Studio es una aplicación de escritorio para Windows, Mac y Linux con la que buscas, descargas y usas modelos sin tocar la terminal. Tiene un buscador que te orienta sobre si un modelo cabe en tu equipo, un chat parecido al de ChatGPT, la posibilidad de trabajar con documentos y un modo servidor para que otros programas se conecten a él.

Yo lo abro en el portátil de trabajo, un HP Omen con Windows y una gráfica de 8 GB, cuando quiero probar un modelo nuevo antes de decidir si merece un sitio en el servidor principal. Es mi sala de pruebas: descargo, pregunto, comparo dos modelos en un rato y, si alguno vale, lo paso al sitio donde va a trabajar de verdad.

El problema real que me dio: descargué varias versiones del mismo modelo desde su buscador y acabé con más de 100 GB duplicados en una carpeta que ni sabía dónde estaba. Tardé una tarde en darme cuenta de por qué el disco del sistema estaba lleno. Ahora tengo la carpeta de modelos movida a un disco aparte y la reviso de vez en cuando.

Y un recordatorio que me hago a mí mismo: una ventana cómoda no hace más listo al modelo. Si el modelo es flojo o no cabe en tu memoria, LM Studio te lo enseñará con una interfaz preciosa, pero flojo y lento igual.

Ollama nació para la terminal: escribes «ollama run» seguido del nombre del modelo y te pones a chatear. Hoy tiene también aplicación de escritorio, pero su punto fuerte sigue siendo otro: abre una puerta en tu ordenador, lo que los técnicos llaman una API, por la que otros programas le piden respuestas al modelo como si fuera un servicio en la nube.

Por eso es el que uso por debajo. En el servidor principal, Ollama sirve los modelos a una interfaz web, a unos scripts que clasifican y resumen documentos y a un par de herramientas de clientes que funcionan dentro de su red. Nadie lo ve, pero es el que carga con el trabajo diario.

El problema real: después de una actualización, un modelo empezó a responder mucho peor sin que yo tocara nada. Resultó que había cambiado la configuración por defecto de la memoria de contexto (cuánto texto recuerda el modelo en una conversación) y mis documentos largos se cortaban por la mitad. Tardé dos días en encontrarlo. Desde entonces fijo esos parámetros a mano.

Y un aviso de seguridad, porque esa puerta es una puerta de verdad. Por defecto Ollama solo escucha en el propio ordenador, pero en cuanto la abres a la red para que otras máquinas la usen, no pide usuario ni contraseña: quien llegue a ella puede usar tus modelos. En mis servidores solo es accesible desde la red interna, el cortafuegos corta el resto, la interfaz web va con usuarios y contraseña, y actualizo Ollama y la interfaz una vez al mes, leyendo antes qué cambia. Lo mismo vale para el modo servidor de LM Studio o de llama.cpp: nada de eso se deja abierto a internet.

Conviene decirlo claro porque es la confusión más común: Ollama no es una inteligencia artificial. Es el programa que carga y mueve los modelos. Si alguien te dice «uso la IA de Ollama», quiere decir que usa algún modelo, como Qwen, Gemma o Llama, a través de Ollama.

llama.cpp es el motor que hay debajo de varias de las herramientas cómodas. Trabaja con ficheros en formato GGUF, el más habitual para descargar modelos comprimidos, y se maneja sobre todo desde la línea de órdenes, aunque incluye un pequeño servidor. Lo que da a cambio de su cara poco amable es control: puedes decidir cómo se reparte el modelo entre la gráfica y la memoria normal del ordenador, y ajustar el rendimiento al detalle.

Lo prefiero cuando un modelo no cabe entero en la gráfica y hay que repartirlo con cuidado. En el servidor principal, el de la RTX 4070 de 12 GB y 64 GB de RAM, con un modelo de 32B en Q4_K_M y un contexto de 4.096 tokens, que las herramientas cómodas cargaban a algo más de 1 token por segundo (el token es el trozo de palabra con el que el modelo escribe), ajustando a mano cuántas capas iban a la gráfica llegué a unos 2, con el mismo modelo, el mismo contexto y la misma pregunta. Si cambias cualquiera de esas cosas, la cifra cambia, así que tómala como orientación. No es un milagro: sigue siendo lento, pero es el doble, y para tareas que no corren prisa se nota.

El problema real: la primera vez intenté compilarlo con soporte para la gráfica y me pasé una tarde entera peleándome con versiones de controladores. Al final usé una versión ya compilada, que es lo que debería haber hecho desde el principio. Y los parámetros: hay tantos que es fácil tocar uno que no entiendes y empeorar las cosas. Yo apunto qué cambio y qué resultado da cada vez.

Unsloth sirve sobre todo para afinar modelos, es decir, entrenarlos un poco más con tus propios ejemplos para que se adapten a una tarea, usando menos memoria y menos tiempo que los métodos habituales. Con eso se puede afinar un modelo pequeño o mediano con una sola tarjeta gráfica doméstica. Sus versiones recientes traen también una interfaz para ejecutar modelos, y publica versiones comprimidas de muchos modelos conocidos, que es por donde lo descubre mucha gente.

Una aclaración importante: afinar no es enseñarle tus documentos. Si quieres que el modelo consulte tu información, hay técnicas más sencillas, y las cuento en Lo que rodea al modelo para que sirva de algo. Afinar tiene sentido cuando quieres que responda siempre con un estilo, un formato o un criterio concretos.

Lo que yo afiné, y lo marco como experimental: un modelo pequeño de 3B para que clasificara correos de soporte de un cliente en siete categorías y devolviera siempre el mismo formato. Etiqueté a mano unos 600 ejemplos, entrené con 480 y aparté 120 que el modelo no vio nunca, para medir con ellos. Usé LoRA, que ajusta solo una pequeña parte del modelo, con tres pasadas por los datos. Sobre esos 120 correos apartados, el resultado fue un acierto de alrededor del 85 % (102 de 120), frente al 70 % del mismo modelo sin afinar y con buenas instrucciones. Los fallos se concentraban en dos categorías que hasta a mí me cuesta separar: incidencias técnicas y dudas de facturación. Mejoró, sí. Pero un modelo más grande sin afinar llegaba al 82 % en el mismo conjunto sin tanto trabajo, así que todavía no lo he puesto en producción. Los correos del cliente se quedaron en mi red, sin nombres ni datos de contacto.

El orden fue este: Ollama primero, en la primavera de 2024; LM Studio unos meses después, en ese mismo equipo, cuando me cansé de probar modelos desde la terminal; llama.cpp cuando quise mover modelos grandes en gráficas pequeñas; y Unsloth a principios de 2026, por curiosidad con el afinado. Cada salto vino de un problema que el anterior no resolvía, no de un vídeo nuevo.

Si empiezas y lo que quieres es probar, instala LM Studio. Es la puerta más amable y en una tarde tienes un modelo respondiendo. Si no te asusta la terminal, Ollama también vale como primer paso.

Si quieres conectar el modelo con otros programas, que tus scripts o tus herramientas le pidan cosas, Ollama. Es para lo que está hecho y es muy fácil de dejar funcionando en un servidor.

Si quieres rendimiento, exprimir una gráfica justa o repartir un modelo grande con cuidado, llama.cpp. Pero ven con paciencia.

Si quieres afinar, Unsloth. Aunque antes comprueba si un buen modelo con buenas instrucciones ya te resuelve la tarea. En mi caso casi lo hacía, y me habría ahorrado un fin de semana entero.

¿Qué hay de verdad en la promesa de un solo programa para todo? Para empezar, sí: con uno basta. Para trabajar, cada programa hace bien una cosa, y lo sensato es usar el que toca y no pelearse con el que no. En Lo que rodea al modelo para que sirva de algo cuento qué he montado alrededor para que todo esto sirva para algo más que charlar.