Ollama v0.34.2 vs v0.34.1: un fix puntual de MLX, no la misma regresión

Ollama publicó dos releases seguidos: v0.34.1 el 14 de septiembre y v0.34.2 el 15 de septiembre. Los dos changelogs tocan MLX y los dos mencionan memoria. Eso invita a leerlos como una corrección de emergencia sobre lo mismo. Los textos oficiales no dicen eso.

Qué cambió en cada versión

v0.34.1 (14 de septiembre), según su changelog oficial:

• ollama create con MLX safetensors deja de ser experimental. La creación de modelos GGUF pasa a requerir herramientas de llama.cpp para la conversión y cuantización.
• Mejora general de manejo de memoria MLX en Apple Silicon ("Improved MLX memory handling on Apple Silicon").
• La detección de repetición de tokens ahora exige 100 tokens repetidos antes de activarse, para reducir falsos positivos en casos como OCR.
• /api/tags reporta una mejora medida en librerías grandes de modelos: de 3.1 segundos a 294 ms en frío, según las pruebas incluidas en el propio changelog.
• Deprecación de typical_p: no se puede setear en modelos nuevos, pero los modelos GGUF existentes lo conservan.

v0.34.2 (15 de septiembre), un día después:

• Setup de primer uso al correr ollama, con opción de iniciar sesión o seguir localmente. Ese estado se comparte con la app de escritorio en macOS y Windows.
• Enlace ollama://apps para abrir directamente la página de Apps de la app de escritorio en macOS y Windows.
• Fix específico: "Fixed excessive memory growth during long generations with MLX speculative decoding".
• Actualización de llama.cpp (sin detalle de versión en el changelog).

Por qué no son el mismo fix

El punto de fricción está en la palabra compartida: "memoria" y "MLX" aparecen en las dos entradas. Pero el texto de cada changelog describe mecanismos distintos.

v0.34.1 habla de "Improved MLX memory handling" en términos generales, sin especificar bajo qué condición ocurría el problema ni qué parte del pipeline tocaba.

v0.34.2 apunta a un caso preciso: crecimiento de memoria durante generaciones largas cuando se usa decodificación especulativa MLX (MLX speculative decoding). Es un mecanismo de inferencia específico, no el manejo de memoria general que mencionó la versión anterior.

Ningún changelog dice que uno corrija lo que dejó roto el otro. No hay texto que vincule las dos entradas como la misma regresión, y tampoco hay confirmación de que sean completamente independientes. Los documentos simplemente no lo aclaran.

A quién le importa el fix de v0.34.2

El fix de memoria de v0.34.2 está acotado a un escenario: decodificación especulativa MLX en generaciones largas. Eso corre en Apple Silicon con el backend MLX.

Si el uso es con modelos GGUF sobre llama.cpp, ese fix no aplica según lo que dice el changelog: el problema descripto es específico de MLX speculative decoding, no del backend GGUF.

Qué no se puede concluir con esta evidencia

• No hay confirmación de si el crecimiento de memoria que corrige v0.34.2 fue introducido por los cambios de v0.34.1 o si ya existía antes.
• No se explica el mecanismo interno: el changelog dice que se "fixed", no por qué crecía la memoria en decodificación especulativa.
• No hay detalle de qué versión de llama.cpp se actualizó en v0.34.2 ni qué trae ese bump.
• Los números de /api/tags (3.1 s → 294 ms) vienen del propio changelog del proyecto, sin metodología de prueba descripta.

Quién necesita actualizar hoy

Con la información disponible: quienes corren modelos MLX en Apple Silicon con generaciones largas y usan decodificación especulativa tienen un fix concreto y documentado en v0.34.2. Para el resto de los cambios —safetensors estables, umbral de repetición, deprecación de typical_p, mejora de /api/tags— ya estaban en v0.34.1, y actualizar a v0.34.2 los incluye por arrastre, no porque v0.34.2 los repita o los corrija.

Fuente original:

• https://github.com/ollama/ollama/releases/tag/v0.34.2
• https://github.com/ollama/ollama/releases/tag/v0.34.1