El ecosistema local de LLM no necesita Ollama

• Ollama fue una herramienta temprana que simplificó la ejecución local de LLM, pero después perdió la confianza por ocultar sus fuentes y girar hacia un enfoque centrado en la nube
• Minimiza el mérito del motor principal, llama.cpp, y al cambiar a un backend propio basado en ggml provocó caídas de rendimiento y reintroducción de errores
• La comunidad sigue criticando aspectos como nombres de modelos engañosos, distribución de una app GUI cerrada y una estructura de Modelfile ineficiente
• Cuellos de botella en el registro de modelos, vulnerabilidades de seguridad y una arquitectura de vendor lock-in chocan con la filosofía local-first
• Alternativas open source como llama.cpp, LM Studio y Jan ya ofrecen mayor rendimiento y transparencia y se han consolidado como el centro del ecosistema local de LLM

---

Problemas de Ollama y alternativas en el ecosistema local de LLM

• Origen de Ollama y su rol inicial

  • Ollama llamó la atención como el primer wrapper de llama.cpp que simplificó la ejecución local de LLM
    • Permitía ejecutar modelos sin que el usuario tuviera que compilar C++ manualmente ni configurar un servidor
  • Después ocultó el origen, indujo a error a los usuarios y, alejándose de una filosofía centrada en lo local, se movió hacia una estructura enfocada en la nube respaldada por capital de riesgo
  • Sus fundadores son Jeffrey Morgan y Michael Chiang, quienes previamente desarrollaron Kitematic, una GUI para Docker que fue adquirida por Docker Inc.
  • Surgió de Y Combinator (W21), tuvo su lanzamiento público en 2023 y se presentó como “Docker para LLMs”

• Créditos inapropiados a llama.cpp

  • La capacidad de inferencia de Ollama depende por completo de llama.cpp de Georgi Gerganov
  • Durante más de un año no hubo mención de llama.cpp en el README, el sitio web ni el material de marketing, y ni siquiera se incluyó el aviso de licencia MIT
  • El issue de la comunidad pidiendo cumplimiento de licencia (#3185) estuvo más de 400 días sin respuesta
  • Después, un cofundador solo añadió al final del README una línea: “llama.cpp project founded by Georgi Gerganov”
  • Desde Ollama dijeron que “estamos haciendo muchos parches y gradualmente migraremos a nuestro propio motor”, con lo que restaron crédito de forma deliberada

Migración a un backend propio y caída de rendimiento

• Introducción de un backend custom basado en ggml

  • A mediados de 2025, Ollama cambió de llama.cpp a una implementación propia basada en ggml
  • Lo presentó como una medida por estabilidad, pero en la práctica reintrodujo errores ya resueltos
  • Aparecieron múltiples problemas, como errores en salidas estructuradas, fallas en modelos de visión y choques por assertions de GGML
  • Modelos recientes como GPT-OSS 20B no funcionaban o presentaban problemas de tipos de tensor no soportados
  • Gerganov señaló directamente que Ollama hizo un fork incorrecto de ggml

• Resultados de comparación de rendimiento

  • En benchmarks de la comunidad, llama.cpp fue 1.8 veces más rápido que Ollama (161 vs 89 tokens/s)
  • También en CPU hubo diferencias de rendimiento de 30~50%
  • En pruebas con Qwen-3 Coder 32B, llama.cpp mostró un throughput 70% mayor
  • Las causas apuntadas son la arquitectura de demonio de Ollama, el offloading ineficiente a GPU y un backend desactualizado

Nombres de modelos engañosos

• Caso DeepSeek-R1

  • Ollama etiquetó modelos reducidos como DeepSeek-R1-Distill-Qwen-32B simplemente como “DeepSeek-R1”
  • Aunque no se trata del modelo real de 671B parámetros, usó el mismo nombre
  • Eso hizo que usuarios creyeran que habían “ejecutado DeepSeek-R1 en local”, con el consiguiente daño a la reputación de DeepSeek
  • Los issues relacionados en GitHub (#8557, #8698) fueron marcados como duplicados y siguen sin resolverse
  • Incluso ahora, ollama run deepseek-r1 ejecuta un modelo reducido

Lanzamiento de una app cerrada

• Distribución privada de la app GUI

  • En julio de 2025 se publicó la app GUI de Ollama para macOS y Windows
  • Fue desarrollada en un repositorio privado y distribuida sin licencia, sin publicar el código fuente
  • Para un proyecto que mantenía una imagen open source, fue un giro brusco hacia el cierre
  • La comunidad planteó dudas sobre posibles dependencias AGPL-3.0 y riesgos de incumplimiento de licencia
  • El sitio web colocó un botón de descarga junto al enlace a GitHub, dando la impresión de que era open source
  • Tras meses de silencio, recién en noviembre de 2025 se integró al repositorio principal
  • XDA criticó que “un proyecto que se presenta como open source debe dejar claro qué es público y qué no”

Ineficiencia de Modelfile

• Duplicación respecto al formato GGUF

  • El formato GGUF incluye en un solo archivo toda la información necesaria para ejecutar un modelo
  • Ollama agrega además un archivo de configuración separado llamado Modelfile, con una estructura parecida a Dockerfile
  • Esto redefine información que ya existe en GGUF y genera complejidad innecesaria
  • Ollama solo reconoce automáticamente una lista hardcodeada de templates, e ignora templates nuevos
  • Como resultado, se rompe el formato de instrucciones del modelo y el usuario debe convertirlo manualmente

• Modificación ineficiente de parámetros

  • Para cambiar parámetros, hace falta extraerlos con ollama show --modelfile, modificarlos y recrear el modelo con ollama create
  • En ese proceso se copia el modelo completo de 30~60 GB
  • La comunidad lo criticó como una “duplicación ineficiente e innecesaria”
  • En llama.cpp, los parámetros pueden ajustarse simplemente con argumentos de línea de comandos

• Problemas de compatibilidad de templates

  • Ollama usa sintaxis de templates de Go, distinta de los templates Jinja que usan los creadores de modelos
  • LM Studio y llama.cpp soportan Jinja de forma directa, pero en Ollama hay que convertirlos
  • Se han reportado numerosos problemas de formatos de conversación rotos por errores de conversión

Cuello de botella del registro de modelos

• Demora en registrar modelos

  • Aunque un modelo nuevo se publique en Hugging Face, en Ollama solo puede usarse después de que se empaquete y registre manualmente
  • Los formatos de cuantización soportados también son limitados, como Q4_K_M y Q8_0
  • En consecuencia, hay demoras entre el lanzamiento de un modelo y su disponibilidad en Ollama
  • En la comunidad se difundieron publicaciones PSA diciendo: “para probar modelos nuevos, usa llama.cpp o vLLM”

• Restricciones de cuantización

  • Ollama no soporta las familias Q5, Q6 e IQ
  • Incluso cuando los usuarios lo piden, la respuesta es “usa otra herramienta”
  • Se añadió la opción de llamar directamente a Hugging Face con ollama run hf.co/{repo}:{quant}, pero aun así se copia a un almacenamiento interno con hash y no puede compartirse, y además persisten los problemas de templates

Giro hacia la nube y problemas de seguridad

• Incorporación de modelos en la nube

  • A finales de 2025, Ollama añadió modelos alojados en la nube
  • A pesar de ser una herramienta orientada a lo local, algunos modelos envían prompts a servidores externos
  • Al usar modelos de terceros como MiniMax, los datos pueden terminar en sistemas externos
  • Ollama especificó que “no guarda logs”, pero las políticas de terceros no están claras
  • En el caso de modelos basados en Alibaba Cloud, no hay garantía de retención de datos

• Vulnerabilidades de seguridad

  • CVE-2025-51471: una vulnerabilidad por la que un servidor de registro malicioso podía robar tokens de autenticación
  • Existía un PR de corrección, pero no se aplicó durante meses
  • Para una herramienta que presentaba la privacidad local como valor central, esto supone un problema estructural grave

Estructura centrada en capital de riesgo

• Un patrón repetido

  • Envolver un proyecto open source para conseguir base de usuarios → captar inversión → pasar a monetización
  • El recorrido de Ollama por etapas
    • Comenzó como open source, construido sobre llama.cpp
    • Restó visibilidad a su origen y se empaquetó como si fuera un producto independiente
    • Impulsó lock-in mediante un registro y formato de modelos propios
    • Lanzó una GUI cerrada
    • Introdujo servicios en la nube para monetizar

• Arquitectura de vendor lock-in

  • Ollama guarda los modelos con nombres de archivo hasheados, lo que dificulta su compatibilidad con otras herramientas
  • Puede importar GGUF, pero exportarlo está diseñado de forma incómoda
  • La estructura hace que el usuario quede atado al ecosistema de Ollama

Herramientas alternativas

• llama.cpp

  • Ofrece servidor API compatible con OpenAI (llama-server), interfaz web, control detallado de parámetros y alto throughput
  • En febrero de 2026, ggml.ai se unió a Hugging Face, reforzando su sostenibilidad
  • Se basa en licencia MIT y cuenta con más de 450 contribuyentes

• Otras alternativas

  • llama-swap: soporta carga de múltiples modelos y hot swap
  • LiteLLM: ofrece un proxy compatible con OpenAI entre varios backends
  • LM Studio: GUI, usa llama.cpp y es totalmente compatible con GGUF
  • Jan, Msty: apps de escritorio open source con diseño local-first
  • koboldcpp, Red Hat ramalama: ejecución de modelos basada en contenedores, con atribución de origen clara

Conclusión: hacia dónde va el ecosistema local de LLM

• llama.cpp de Georgi Gerganov es la base de la innovación en IA local
  • Gracias a la colaboración de la comunidad, permite ejecutar modelos potentes incluso en hardware de consumo
• Ollama creció sobre esa base, pero perdió la confianza por ocultar el origen, bajar la calidad, cerrarse y girar hacia la nube
• Lo que necesita el ecosistema local de LLM no es Ollama, sino llama.cpp
  • La verdadera apertura y el rendimiento ya los ofrecen herramientas impulsadas por la comunidad

[shblue21]

Estoy de acuerdo hasta cierto punto, y me parece que para usarlo bien en local, LM Studio es una mejor opción.

[kirinonakar]

Yo también empecé con Ollama al principio, pero hace tiempo que me cambié a LM Studio.

[GN⁺]

Comentarios de Hacker News

• La mayoría de los usuarios de LLM locales cree que Ollama resolvió los problemas de UX
  Permite ejecutar modelos con un solo comando y también maneja automáticamente los drivers ROCm
  En cambio, llama.cpp suena desde el nombre como una librería de C++, así que para el usuario común resulta menos accesible
  Yo simplemente no quiero compilar programas por mi cuenta; solo quiero probarlos y divertirme

  • Ahora llama.cpp incluye una GUI por defecto. Antes no la tenía, pero los tiempos cambiaron
  • Hay muchas alternativas como “LM Studio, Jan, Msty, koboldcpp…”, pero me pregunto cuál sería realmente el sucesor capaz de reemplazar a Ollama
    Uso una Mac Mini, aunque una herramienta CLI también me sirve. La fortaleza de Ollama era la facilidad de instalación y descarga de modelos, así que esperaría un nivel de comodidad similar en una alternativa
  • Sugieren kobold.cpp o LM Studio. LM Studio no es open source, pero le da el crédito correspondiente a llama.cpp
    Pienso que el control de calidad es importante para evitar integraciones con soporte roto de modelos o subidas incorrectas de GGUF
  • De acuerdo. Es una situación parecida a Docker
    Claro, uno podría usar runc directamente, pero la mayoría elige docker run
    La UX es un factor clave para la adopción tecnológica, y si un proyecto no construye bien la interfaz, no hay nada de malo en hacer un wrapper
  • Que Ollama haya resuelto los problemas de UX no lo exonera de violar la licencia

• Me cansé de repetir el mismo argumento, así que reuní de una vez la línea de tiempo y las fuentes que conozco

  • Agradecen que se haya escrito este artículo. Yo también participé un poco en llama.cpp, y la conducta de los fundadores de Ollama fue realmente decepcionante
    Como alternativa recomiendan llama-file. llamafile de Mozilla AI funciona como un solo ejecutable sin importar el sistema operativo y es completamente open source
    Está basado en CosmopolitanC, creado por Justine Tunney, y usa oficialmente llama.cpp
  • Como alguien que valora el espíritu FOSS, dicen que fue un texto muy educativo
  • Dicen que había muchos hechos que no conocían
  • Evalúan que el resumen y la línea de tiempo son excelentes

• Pienso que Ollama es 1000 veces mejor en facilidad de uso
  llama.cpp es excelente, pero no es amigable para usuarios comunes
  Yo empecé con Ollama, pero me pasé a llama.cpp por los cambios más recientes
  Aun así, sigo usando Ollama para gestionar modelos. Es tan conveniente que hasta hice scripts para manejar el directorio de caché

  • En la entrada del blog dijeron que las alternativas eran intuitivas, pero en la práctica no lo son
    Tal vez para una simple app de chat sí, pero si necesitas una API compatible con OpenAI y gestión de modelos, la accesibilidad cae muchísimo
  • Había muchas quejas de que el context size por defecto de Ollama era demasiado pequeño y volvía tonto al modelo
    Para cambiarlo de forma persistente había que crear un archivo de modelo nuevo, y eso era todavía más complejo
    Creo que el enfoque estilo Docker resulta incómodo para el usuario común, y que para usuarios avanzados llama.cpp es mejor
  • Como referencia, ahora llama.cpp agregó un modo router que permite cambiar de modelo en tiempo real
  • Las versiones recientes se volvieron mucho más potentes. Puede verse en llama.cpp tools/serv
  • Llevo 3 años usando LM Studio, y aun en ese entonces ya era mucho mejor que Ollama

• Resumen de dos posturas sobre la licencia MIT

  1. “Con una sola línea de crédito, se puede hacer cualquier cosa”
  2. “Legalmente es libre, pero existe una responsabilidad moral con la comunidad”
     El creador de llama.cpp, Georgi Gerganov, solo expresó molestia por la falta de atribución. Es decir, actuó más cerca de la primera interpretación
  • Creo que la segunda interpretación no tiene sentido. Si quieres obligaciones de tipo GPL, entonces usa GPL
    MIT es un documento legal, no una guía moral
    Personalmente creo que conviene usar GPL para software orientado a usuarios
    Es contradictorio usar MIT y luego quejarse de que una empresa toma el código
    Creo que las empresas no tienen moral; solo las personas la tienen
  • Si Georgi hubiera querido, podía haber cambiado a GPL en cualquier momento. Pero no lo hizo
    Al final ambos proyectos siguieron avanzando y los usuarios terminaron con más opciones

• Antes era incómodo porque no se podía cambiar la carpeta de modelos por defecto
  Para registrar un modelo había que pasar por un proceso parecido a un Dockerfile, y el modelo se copiaba a un almacenamiento hash, así que no se podía mover de ubicación
  Por eso me cambié a LM Studio. No es completamente open source, pero exponía la carpeta de modelos y estaba integrado con Hugging Face

  • Ahora sí se puede. Puedes indicar la ruta con la variable de entorno OLLAMA_MODELS en el archivo de configuración del servidor
  • Yo también sufrí con ese problema. Quise comparar LM Studio antes y después de actualizar el SSD, pero encontrar y ordenar la ubicación de los modelos fue un proceso demasiado complejo y dolorosamente innecesario

• Por la estructura en la que Ollama copia los archivos de modelo a un almacenamiento hash de blobs, no se pueden compartir con otras herramientas
  Probablemente sea un diseño pensado para deduplicación, pero al final dificulta probar otras herramientas
  Como los archivos de modelo son tan grandes, el almacenamiento y las descargas se vuelven una carga importante

• En Arch Linux, pacman -Ss ollama devuelve 16 resultados, pero llama.cpp o lmstudio devuelven 0
  Ojalá eso cambie algún día

  • llama.cpp se actualiza demasiado rápido, así que es difícil empaquetarlo como paquete estable; en cambio sí puede instalarse desde AUR
    Hay soporte para versiones Vulkan, ROCm y CUDA
  • En cambio, en openSUSE puedes encontrar llamacpp con zypper
    Como las versiones y el soporte cambian según la distro, al final ahí está una de las razones por las que existen tantas distribuciones de Linux
  • Yo lo instalé en CachyOS con yay -S llama.cpp, y fue mucho más rápido y mejor que Ollama

• El nombre “llama.cpp” ahora ya no suena amigable
  Antes se refería al modelo Llama de Meta, pero ahora hay modelos open source más potentes

  • Pero “Ollama” tiene el mismo problema
    Ahora el nombre “Local LLaMA” se usa casi como un término genérico para ejecutar modelos locales
  • Si miras la lista de marcas genéricas de Wikipedia, verás que este fenómeno es común

• Evité Ollama desde el principio porque me daba la impresión de que quería controlar todo el flujo de trabajo
  Al final creo que fue una buena decisión

• La estructura de almacenamiento hash de blobs de Ollama es la peor trampa
  Si llevas meses descargando modelos, al cambiarte a otra herramienta tienes que bajarlos todos otra vez
  La mayoría de los usuarios solo se da cuenta de esto después de haber invertido mucho, y entonces siente muy fuerte el costo de salida