Problemas Técnicos y Controversia Comunitaria de Ollama

Tecnología Central de Ollama y Problemas de Atribución
Toda la capacidad de inferencia de Ollama originalmente provenía de llama.cpp, el motor de inferencia en C++ creado por Georgi Gerganov en marzo de 2023. Durante más de un año, el README de Ollama no contenía mención alguna de llama.cpp, y sus distribuciones binarias no incluían el aviso de licencia MIT requerido para el código de llama.cpp que estaban distribuyendo.
La comunidad abrió el issue #3185 en GitHub a principios de 2024 solicitando el cumplimiento de la licencia, el cual pasó más de 400 días sin respuesta de los mantenedores. Cuando se abrió el issue #3697 en abril de 2024 solicitando específicamente el reconocimiento de llama.cpp, el cofundador de Ollama, Michael Chiang, eventualmente agregó una sola línea al final del README: "Proyecto llama.cpp fundado por Georgi Gerganov."
Problemas Técnicos con el Backend Personalizado
A mediados de 2025, Ollama dejó de usar llama.cpp como su backend de inferencia y construyó una implementación personalizada directamente sobre ggml. Este backend personalizado reintrodujo errores que llama.cpp había resuelto años atrás, incluyendo:
- Soporte de salida estructurada roto
- Fallos en modelos de visión
- Caídas por aserciones GGML en múltiples versiones
- Modelos que funcionaban bien en el upstream de llama.cpp fallaban en Ollama
- Falta de soporte para tipos de tensores requeridos por nuevas versiones como GPT-OSS 20B
Georgi Gerganov identificó que Ollama había bifurcado y realizado malos cambios a GGML.
Benchmarks de Rendimiento
Múltiples pruebas de la comunidad muestran que llama.cpp funciona 1.8 veces más rápido que Ollama en el mismo hardware con el mismo modelo:
- 161 tokens por segundo versus 89 tokens por segundo
- En CPU, la brecha de rendimiento es del 30-50%
- Una comparación reciente en Qwen-3 Coder 32B mostró ~70% más de rendimiento con llama.cpp
La sobrecarga de rendimiento proviene de la capa daemon de Ollama, heurísticas deficientes de descarga de GPU y un backend vendido que va a la zaga del upstream.
Problemas con la Denominación de Modelos
Cuando DeepSeek lanzó su familia de modelos R1 en enero de 2025, Ollama listó las versiones destiladas más pequeñas (modelos como DeepSeek-R1-Distill-Qwen-32B) sin indicar claramente que eran destiladas en lugar de los modelos completos.
📖 Leer la fuente completa: HN LLM Tools
👀 Ver también

Servidor MCP GodotIQ otorga a los agentes de IA comprensión espacial de escenas de Godot
GodotIQ es un servidor MCP que proporciona a los agentes de codificación una comprensión real de las escenas 2D/3D, las señales y las dependencias de código en Godot. En una prueba, construyó de forma autónoma un juego de supervivientes de doble joystick en una hora a partir de activos y un prompt.

Pali v0.1: Infraestructura de Memoria de Código Abierto para LLMs con Puntos de Referencia Reproducibles
Pali es una infraestructura de memoria de código abierto para LLMs construida en Go como un binario único con APIs multiinquilino, recuperación híbrida y extensiones plug-and-play. La versión v0.1 incluye un conjunto de pruebas comparativas con resultados reproducibles que muestran métricas de rendimiento para diferentes configuraciones.

Codesight CLI reduce el uso de tokens de agentes de codificación con IA al escanear bases de código.
Codesight es una herramienta CLI sin dependencias que escanea proyectos de TypeScript, Python y Go para generar archivos de contexto compactos, reduciendo los tokens de exploración de Claude Code en 12.3× en promedio según benchmarks de codebases reales de producción.

Servidor MCP de Rust de Código Abierto Otorga a Claude Capacidades Completas de Gestión de Correo Electrónico
Un desarrollador construyó un servidor MCP basado en Rust que proporciona a Claude 25 herramientas para la gestión integral de correo electrónico, incluyendo búsqueda IMAP, envío SMTP, soporte para Microsoft Graph API y manejo de múltiples cuentas con autenticación OAuth2.