Por Qué Dejé Ollama: El Coste Oculto de la Facilidad en LLMs Locales

Ollama sigue siendo la puerta de entrada por defecto para ejecutar modelos de IA en tu propio hardware. Si has buscado tutoriales de LLMs locales, has encontrado Ollama. Es la recomendación por defecto en foros, el primer paso en guías de self-hosting y, para muchos, sinónimo de "IA local". Y no es difícil entender por qué: instalar un modelo es tan sencillo como ollama run modelo. Es el Docker de los LLMs locales, y esa comparación no es casualidad: parte del equipo detrás de Ollama viene del mundo Docker.

Pero la conveniencia tiene un coste. Y una vez entiendes qué está pasando bajo el capó, resulta difícil justificar seguir usando Ollama frente a las alternativas. Es más lento de lo necesario, toma decisiones que no puedes anular fácilmente y el proyecto se ha movido en una dirección que debería preocupar a quienes valoran el software libre y la soberanía tecnológica.

El problema del rendimiento: más lento que las herramientas que abstrae

El problema más inmediato de Ollama es el rendimiento. Múltiples benchmarks comunitarios y reportes de desarrolladores muestran que ejecutar el mismo modelo a través de Ollama produce menos tokens por segundo que ejecutarlo directamente con llama.cpp. Y no es una diferencia marginal: en algunos casos es lo suficientemente grande como para notarla cuando esperas una respuesta.

Parte del problema viene de los valores por defecto. La ventana de contexto, por ejemplo, se establece en 4.096 tokens para la mayoría de usuarios. Ollama ajusta dinámicamente esta cifra según la VRAM disponible, pero esos ajustes solo se activan en GPUs con más de 24GB. La propia documentación de Ollama recomienda 64.000 tokens como mínimo para tareas que requieren contexto largo: búsqueda web, agentes y herramientas de código.

Esto es ridículamente bajo cuando modelos modernos como Gemma 4 soportan hasta 128K o 256K de contexto, y nuevas arquitecturas reducen la carga de memoria del KV cache hasta el punto de que 4K por defecto se siente completamente desfasado. Si no configuras manualmente num_ctx mediante variables de entorno, comandos o la API, Ollama se convierte en un cuello de botella para cargas de trabajo con contexto largo.

Además, la capa de abstracción de Ollama introduce overhead que llama.cpp no tiene. El equipo de nullmirror documentó su migración de Ollama a llama.cpp y encontró mejoras consistentes de throughput en todos los modelos probados, sin pérdida de calidad. Su conclusión fue directa: "el throughput y el control importan más que la conveniencia que ofrece Ollama".

El problema de confianza: decisiones que erosionan la credibilidad

El rendimiento es un trade-off que puedes aceptar. La confianza, no. Y Ollama ha ido perdiéndola con decisiones que priorizan las métricas de usuario sobre la claridad.

Ollama es una startup respaldada por Y Combinator con financiación de venture capital. Nada de eso es inherentemente malo, pero significa que los incentivos del proyecto no son puramente comunitarios. La app de escritorio con lanzamiento confuso, el registro de modelos con fricción y la migración lejos de llama.cpp apuntan en la misma dirección.

Las alternativas son más fáciles de lo que crees

Las herramientas sobre las que se construyó Ollama son directamente accesibles, y en la mayoría de casos no son mucho más difíciles de configurar.

Ninguna de estas herramientas requiere más de unos minutos para configurarse. La idea de que Ollama es la única opción amigable para principiantes no se sostiene una vez has probado las alternativas, que muchas han alcanzado la facilidad de uso que Ollama pionerizó.

Cuándo tiene sentido migrar

No estoy diciendo que Ollama no tenga lugar. Si estás empezando, quieres probar un modelo en cinco minutos y no te importa sacrificar un 20% de rendimiento, Ollama cumple. Pero hay puntos de inflexión donde la migración se impone:

En mi caso, la migración fue progresiva. Empecé con Ollama porque era lo que todos recomendaban. Cuando empecé a usar modelos para tareas agentic con contexto largo, la diferencia de rendimiento se hizo insostenible. El último empujón fue intentar usar modelos destilados para tareas que requerían el modelo completo, y darme cuenta de que la abstracción estaba ocultando información crítica.

La conclusión: conveniencia versus control

Ollama cumplió un propósito cuando los LLMs locales eran novedosos y el tooling era tosco. Ese tiempo ya pasó. Las alternativas son más rápidas, más transparentes y vienen sin el equipaje de una empresa que toma decisiones de producto priorizando cada vez más el control y el empaquetado sobre la claridad y la interoperabilidad que hicieron popular al proyecto.

Si aún usas Ollama por inercia, quizá sea hora de reconsiderar. El coste de la "facilidad" es más alto de lo que parece.