Ollama v0.40.12 apunta a la velocidad de los prompts y al detalle de imágenes pequeñas

Ollama ha publicado la candidata a lanzamiento Ollama v0.40.12 con cuatro cambios orientados al rendimiento de modelos locales, el manejo de imágenes y las dependencias de software subyacentes. La distinción importa: sus mejoras en el procesamiento de prompts y en la generación proceden de cambios separados, con límites diferentes.

La historia central es la distancia entre admitir un modelo y ejecutarlo bien. Un modelo puede cargarse correctamente mientras procesa documentos de forma ineficiente o pierde detalles útiles de una imagen. Este lanzamiento aborda ejemplos concretos de esa brecha, en vez de anunciar una nueva familia de modelos.

La comparación también va más allá de Ollama. MLX, el framework de arrays de aprendizaje automático de Apple, ofrece una vía de desarrollo más directa para investigadores que trabajan con sus operaciones subyacentes. El papel de Ollama es integrar esas capacidades en un runtime de modelos, el software que ejecuta modelos. Para los desarrolladores de aplicaciones, esa integración determina qué mejoras upstream llegan realmente a sus cargas de trabajo.

Lo que realmente cambia en Ollama v0.40.12

Esta es una actualización específica del runtime, y el artefacto publicado sigue siendo una candidata a lanzamiento.

La candidata a lanzamiento lleva la etiqueta v0.40.12-rc0, aunque su título de visualización dice v0.40.12. GitHub la marca como una preversión y la fecha el 27 de octubre de 2026. Su comparación parte de v0.40.11.

Esa diferencia de nomenclatura merece atención porque un título de visualización por sí solo no establece que se haya publicado una versión estable. Los lectores que evalúen una actualización deben distinguir la candidata publicada de cualquier artefacto estable posterior. Las conclusiones sobre esta compilación deben conservar su etiqueta completa.

Los cambios enumerados cubren el manejo de imágenes de Gemma 4 compacta, actualizaciones de dependencias de MLX, soporte para DFlash2 y una actualización de dependencia de llama.cpp. Las cuatro entradas atribuyen el trabajo al colaborador dhiltgen. En conjunto, describen mantenimiento en varias rutas de ejecución, en lugar de una única función de aceleración universal.

Ese alcance hace que el lanzamiento sea relevante para distintos grupos por razones diferentes. Los desarrolladores que usan los modelos de imagen afectados tienen una cuestión de corrección. Los desarrolladores que esperan el procesamiento de prompts tienen una cuestión de capacidad de respuesta. Los desarrolladores que prueban la aceleración de generación compatible tienen otra cuestión de rendimiento.

Estas preguntas deben mantenerse separadas al interpretar el anuncio. Un procesamiento de documentos más rápido no implica automáticamente una generación de respuestas más rápida. Preservar el detalle de imágenes no demuestra una mayor precisión en todas las tareas visuales. Actualizar una dependencia no especifica el beneficio para cada dispositivo compatible.

Por tanto, el enfoque útil depende de la carga de trabajo. ¿Qué operación cambió, qué modelo la utiliza y qué parte de una aplicación depende de esa operación? Estas preguntas ofrecen una lectura más práctica que tratar cada entrada del registro de cambios como evidencia de una IA local ampliamente más rápida.

Para un asistente de documentos, la mejora más relevante podría producirse antes de que aparezca cualquier respuesta. Para un asistente de capturas de pantalla, podría referirse a la información conservada en la entrada. Para una aplicación que genera respuestas más largas, la ruta de generación podría merecer un examen más detenido.

Estos son ejemplos analíticos, no implementaciones de clientes documentadas. Ilustran por qué el mismo lanzamiento puede importar de forma distinta en aplicaciones que utilizan una interfaz idéntica. El producto visible puede seguir siendo familiar mientras cambia el trabajo realizado internamente.

La actualización también presiona a los responsables de mantenimiento de aplicaciones a revisar viejas suposiciones. Una comparación previa podría reflejar una ruta de ejecución anterior, más que una limitación duradera del modelo. A la inversa, un nuevo benchmark no debería borrar la evidencia de una carga de trabajo de producción sin otra comparación.

Esa es la importancia práctica de una actualización de mantenimiento como esta. Crea razones específicas para reevaluar el comportamiento existente, mientras deja sin resolver afirmaciones más amplias sobre la calidad del modelo y la idoneidad de su despliegue.

Las imágenes pequeñas exponen la brecha entre cargar y ver

El cambio de imagen aborda la pérdida de información antes de que el modelo produzca una respuesta.

La corrección de visión compacta se refiere a las torres de visión compactas de Gemma 4, los componentes que convierten imágenes en entradas para el modelo. Según la solicitud de extracción, el tamaño dinámico podía redondear la cuadrícula de imagen más pequeña por debajo de su presupuesto previsto de 70 tokens.

Aquí, los tokens son las unidades utilizadas para representar información de imagen durante el procesamiento del modelo. El cambio redondea esa cuadrícula hacia arriba para la torre compacta, con un límite en el siguiente presupuesto compatible. El responsable del mantenimiento afirma que los presupuestos explícitos y el tamaño existente para torres más grandes y unificadas no cambian.

Es una corrección acotada con una implicación útil. Cuando una entrada pierde detalle durante su preparación, el razonamiento posterior no puede recuperar de forma fiable la información perdida. Un modelo capaz sigue dependiendo de lo que el runtime le transmite.

Pensemos en una aplicación que responde preguntas sobre una pequeña captura de pantalla que contiene una etiqueta de estado. Si la preparación elimina detalles relevantes, cambiar la redacción de la pregunta podría no resolver el problema subyacente. La aplicación necesita que la evidencia visual sobreviva el tiempo suficiente para ser interpretada.

Ese escenario explica por qué el manejo de imágenes forma parte de una discusión sobre rendimiento. Los usuarios juzgan la tarea completada, incluido si el sistema lee correctamente la entrada. Una respuesta que llega rápido pero no detecta la etiqueta relevante genera trabajo adicional.

Sin embargo, la corrección no debe convertirse en la afirmación de que los modelos compactos ahora manejan con precisión toda imagen pequeña. La fuente identifica un comportamiento de dimensionamiento y una corrección limitada. No demuestra un resultado general para capturas de pantalla, documentos escaneados, diagramas o fotografías.

Las dimensiones de imagen también ofrecen una descripción incompleta de la dificultad. Una imagen pequeña que contiene un símbolo destacado plantea un reto diferente de otra con texto denso. Una evaluación debe reflejar la información que una aplicación real espera extraer.

La comparación más clara conservaría la imagen y la pregunta originales entre compilaciones. Redimensionar la imagen de forma distinta durante una evaluación introduciría otra explicación para cualquier cambio en la respuesta. El objetivo es aislar el comportamiento del runtime que se examina.

Para los responsables de mantenimiento, esto cambia la forma de investigar fallos. Una respuesta visual incorrecta no procede necesariamente de las capacidades aprendidas del modelo. La preparación de entrada es otra capa plausible, y este parche aporta un ejemplo concreto.

También cambia la interpretación de resultados negativos anteriores. Si una configuración afectada descartaba información útil, una prueba antigua podría subestimar lo que esa configuración puede ofrecer después de la corrección. Esa posibilidad justifica volver a probar, no reescribir los resultados anteriores como inválidos.

La lección más amplia trata sobre los límites de las comparaciones de modelos. El nombre de un modelo por sí solo no describe el sistema completo que se evalúa. La preparación de imágenes, el software de ejecución y el comportamiento de la aplicación ayudan a determinar la respuesta que llega al usuario.

El rendimiento de Ollama MLX mejora antes de que empiece la respuesta

El cambio de velocidad de prompts acelera la lectura de la solicitud, mientras el responsable del mantenimiento informa explícitamente que la velocidad de decodificación no cambia.

La actualización del procesamiento de prompts actualiza MLX y MLX-C, su interfaz en lenguaje C. Utiliza atención nativa de ventana deslizante, que limita las operaciones de atención relevantes a una ventana móvil de entradas del modelo.

El responsable del mantenimiento informa mejoras de prefill en un Apple M5 Max. Prefill es la fase que procesa la entrada antes de generar una nueva salida. Con un prompt de 2.048 tokens, el rendimiento informado aumenta un 9,2% para Gemma, un 14,5% para Flint y un 24,1% para Laguna.

Con un prompt de 6.144 tokens, las ganancias correspondientes informadas son del 7,5%, 14,3% y 27,0%. Estas son mediciones del responsable del mantenimiento para configuraciones de modelo específicas. La solicitud de extracción indica que la velocidad de decodificación, la tasa de generación de salida, permanece sin cambios.

Esa salvedad define el alcance de la afirmación sobre el rendimiento de Ollama MLX. Un usuario que espera a que se lea un documento largo tiene un cuello de botella distinto de quien espera una respuesta larga. Mejorar lo primero no demuestra una mejora en lo segundo.

Esto es especialmente relevante cuando una solicitud incluye abundante material de apoyo y pide una respuesta breve. En esa carga de trabajo hipotética, procesar la entrada puede ser una parte significativa de la experiencia. Una preparación más rápida puede importar incluso cuando la salida posterior llega al mismo ritmo.

La situación inversa exige una interpretación diferente. Una aplicación con una solicitud corta y una extensa salida generada podría dedicar relativamente poco tiempo al procesamiento de prompts. Su experiencia general no debería predecirse únicamente a partir del rendimiento de prefill.

Los porcentajes también describen rendimiento, no una reducción universal del tiempo de espera. La latencia de extremo a extremo, el tiempo transcurrido para la solicitud completa, incluye más que la fase de procesamiento medida. La carga, la sobrecarga de la aplicación y otros trabajos complican cualquier traducción directa.

Esa distinción evita un error habitual de cobertura: presentar una mejora en un componente como una mejora equivalente en la tarea completada. Un benchmark puede describir con precisión el componente y dejar abierto el resultado de la aplicación.

El lanzamiento da a los desarrolladores una razón más específica para investigar cargas de trabajo con entradas largas. No les exige concluir que su aplicación se ha vuelto más rápida antes de medirla. Son estándares de evidencia diferentes.

Para los equipos que ensamblan contexto documental, las implicaciones también se extienden al diseño de la evaluación. Las entradas en caché, que reutilizan trabajo calculado previamente, deben distinguirse de las entradas nuevas. De otro modo, las solicitudes repetidas pueden ocultar qué trabajo de procesamiento afecta la actualización.

Por tanto, una comparación de aplicaciones creíble debería describir qué envió el usuario y qué reutilizó el sistema. Sin esa distinción, una diferencia aparentemente pequeña podría ocultar una mejora, o una diferencia aparentemente grande podría tener otra causa.

El rendimiento de Ollama MLX es más útil como una afirmación de ingeniería precisa. La fase afectada, la configuración del modelo, el hardware y la longitud de entrada ofrecen a los lectores algo que probar. Eliminar esos límites haría la afirmación más amplia, pero menos informativa.

El soporte de Ollama DFlash2 apunta a un cuello de botella diferente

DFlash2 se refiere a la generación de respuestas, por lo que sus resultados deben mantenerse separados de las mejoras de procesamiento de prompts.

La implementación de DFlash2 añade un enfoque de generación especulativa, en el que la salida propuesta es comprobada por el modelo objetivo. El responsable del mantenimiento describe un selector de candidatos que condiciona las elecciones sucesivas a selecciones anteriores.

Según las notas de implementación, una sesión redacta siete tokens por ronda y los verifica mediante el mecanismo de reversión existente. El colaborador afirma que la verificación preserva la distribución de salida objetivo. Se trata de una afirmación de implementación, no de una validación independiente presentada aquí.

La solicitud de extracción compara DFlash2 con un cabezal integrado de predicción de múltiples tokens, un mecanismo que propone varios tokens futuros. Para qwen3.8:27b, utilizando la configuración de precisión reducida indicada, el responsable del mantenimiento informa ganancias de generación en sistemas M5 Max, M5 Pro y M2 Ultra.

En M5 Max, el rendimiento de generación reportado aumenta de 57,0 a 71,0 tokens por segundo con el prompt probado más corto. La comparación utilizó la misma compilación, en lugar de medir la versión anterior frente a esta candidata.

Esa distinción final es importante. Estos resultados comparan métodos de generación dentro de una misma compilación. No deberían presentarse como una ganancia de actualización medida para cada usuario que pase desde la versión anterior.

Por lo tanto, la compatibilidad con Ollama DFlash2 añade otra vía de evaluación, en lugar de ofrecer una promesa general de velocidad. Una configuración compatible crea la oportunidad de comparar comportamientos. No indica a cada aplicación qué método de generación ofrecerá el mejor resultado.

La contraprestación general de la generación especulativa es sencilla. Las propuestas ayudan cuando suficientes de ellas son útiles como para justificar el trabajo de producirlas y verificarlas. Evaluar únicamente la etapa de propuestas pasaría por alto el coste de verificación.

Para un desarrollador de aplicaciones, el resultado completado importa más que la cantidad de tokens candidatos propuestos internamente. Un método que genera borradores de forma agresiva aún debe producir resultados aceptados con eficiencia. El resultado relevante es una generación útil bajo las condiciones reales de la aplicación.

El comportamiento de salida merece un examen junto con la velocidad. Los equipos que usan respuestas estructuradas deberían comprobar si la aplicación sigue recibiendo el formato esperado. Los equipos que evalúan respuestas factuales deberían conservar sus comprobaciones de corrección existentes al introducir otra ruta de ejecución.

Estas son prioridades de evaluación, no pruebas de que esta implementación cause problemas de formato o calidad. La fuente describe salvaguardas destinadas a preservar el comportamiento. Las pruebas independientes de la aplicación son la manera en que un equipo determina si sus propios requisitos siguen cumpliéndose.

También existe una distinción informativa entre compatibilidad y comportamiento predeterminado. Una nota de lanzamiento que anuncia una capacidad no establece, por sí sola, que cada modelo instalado la utilice. Los lectores deben identificar la configuración real detrás de cualquier resultado observado.

Ese punto conecta esta función con el resto de la versión. Las mejoras del tiempo de ejecución se vuelven útiles a través de una cadena de decisiones de compatibilidad e integración. El usuario ve una respuesta, pero el modelo elegido y el método de ejecución determinan qué cambios contribuyeron.

Para cargas de trabajo con respuestas largas, el mecanismo de generación merece atención por sus propios méritos. Combinar sus ganancias reportadas con porcentajes no relacionados de procesamiento de prompts crearía una estimación sin sustento. Cada mejora necesita una carga de trabajo correspondiente antes de poder respaldar una conclusión a nivel de aplicación.

La actualización de dependencias mantiene las comparaciones bien fundamentadas

Una dependencia más reciente identifica una base modificada, pero no establece un resultado de rendimiento universal.

La actualización de llama.cpp mueve la dependencia de Ollama de la compilación b11845 a b11901. llama.cpp es un motor de inferencia, software que ejecuta modelos entrenados para producir resultados. El pull request se fusionó el 26 de octubre.

El pull request visible enlaza la comparación ascendente sin presentar un benchmark de aplicación equivalente. Eso respalda informar del cambio de versión. No respalda asignar una mejora específica de velocidad o calidad a cada carga de trabajo que utiliza esa ruta.

Esto importa porque las actualizaciones de dependencias pueden ser fáciles de sobreinterpretar. Un número de compilación más reciente describe el linaje del software. No identifica qué operaciones cambiaron para una aplicación concreta ni establece si se movió su cuello de botella existente.

La comparación con el uso directo del framework ayuda a aclarar la posición de Ollama. El framework MLX expone directamente a los desarrolladores interfaces de programación y operaciones de aprendizaje automático. Ollama integra capacidades subyacentes en un entorno de ejecución de modelos.

Estos enfoques cubren necesidades superpuestas con distintos niveles de responsabilidad. Un investigador que trabaja directamente con las operaciones del framework puede examinar de cerca las decisiones de implementación. Un equipo de aplicaciones que utiliza un tiempo de ejecución integrado depende de las rutas de ejecución compatibles del runtime.

Ninguno de los enfoques gana todas las comparaciones por definición. El acceso directo ofrece control, mientras que la integración puede reducir el trabajo necesario para operar un modelo compatible. Una evaluación justa debería preguntar qué responsabilidades quiere asumir el equipo de aplicación.

La candidata también ilustra por qué los resultados ascendentes y descendentes deben mantenerse diferenciados. Una capacidad del framework necesita una integración adecuada antes de que una aplicación se beneficie de ella. A la inversa, una mejora integrada no debería atribuirse a un modelo nuevo cuando el modelo en sí no cambió.

Esa distinción afecta a las afirmaciones competitivas. Un resultado de un modelo, dispositivo y ruta de ejecución no establece que Ollama supere a los runtimes alternativos en general. Establece un resultado para el sistema probado, con los límites de ese sistema incluidos.

La evidencia disponible procede principalmente de los mantenedores del proyecto. Respalda la existencia de los cambios y sus mediciones reportadas. No proporciona un consenso independiente sobre adopción en producción, fiabilidad o superioridad entre opciones de despliegue.

No hace falta fabricar una controversia pública para que esta evidencia sea significativa. La cuestión sin resolver es práctica: si los cambios ofrecen ganancias útiles en aplicaciones fuera de las mediciones de los mantenedores. Esa pregunta es suficientemente relevante sin inventar partidarios ni críticos.

Para los compradores empresariales, la presión adecuada recae en la calidad de la evidencia. Una demostración amplia de IA local es menos útil que resultados que correspondan a la tarea prevista. Las decisiones de adquisición necesitan que el modelo, el hardware, la carga de trabajo y los requisitos operativos estén alineados.

Los desarrolladores también se benefician de conservar el contexto detrás de sus comparaciones. Los equipos que documentan evaluaciones pueden utilizar una base de conocimientos con búsqueda para preservar hallazgos junto con configuraciones y ejemplos. El registro útil incluye fallos y limitaciones, no solo la ejecución más rápida.

Tres señales mostrarán cuánto importa esta candidata

La siguiente evidencia significativa es la progresión del lanzamiento, los tiempos reproducibles y el comportamiento verificado de las tareas, en ese orden.

Primero, observe qué sucede con la candidata publicada. Un artefacto estable, una candidata posterior o una versión correctiva aclararían el software disponible para una adopción más amplia. Esos eventos no establecerían automáticamente la calidad de la aplicación, pero resolverían parte de la cuestión sobre el estado de la versión.

La progresión más informativa mantendría conexiones claras entre etiquetas y cambios. Eso permitiría a los desarrolladores identificar si un resultado posterior se refiere a esta candidata o a una compilación modificada. Sin esa continuidad, los debates pueden combinar hallazgos de software diferente bajo el mismo nombre de versión abreviado.

Una corrección posterior no invalidaría automáticamente el trabajo descrito aquí. Su importancia dependería del comportamiento afectado. Los lectores deberían buscar una relación concreta entre cualquier problema reportado, su alcance y la configuración que utilizan.

Segundo, busque tiempos reproducibles de aplicaciones que separen el procesamiento de entrada de la generación de salida. Esto probaría si las mejoras de componentes reportadas se mantienen fuera de las condiciones de medición originales. Los resultados deberían identificar la configuración real del modelo y el hardware.

La evidencia de una carga de trabajo equivalente reforzaría el argumento para adoptar el cambio pertinente. Una comparación que mostrara poco beneficio de extremo a extremo limitaría ese argumento sin contradecir necesariamente el benchmark del componente. La aplicación podría simplemente dedicar su tiempo a otra parte.

Los informes de tiempos se vuelven más informativos cuando describen tanto entradas nuevas como reutilizadas. También deberían distinguir entre un modelo que ya está cargado y una solicitud que debe cargarlo. Esas condiciones responden a preguntas diferentes sobre el uso cotidiano.

Tercero, busque comprobaciones a nivel de tarea del manejo de imágenes y la generación acelerada. La corrección de imágenes necesita ejemplos que prueben la información visual conservada. La ruta de generación necesita comprobaciones de salida junto con los tiempos, especialmente cuando las aplicaciones dependen de una estructura predecible.

Los informes útiles incluirían la entrada original, el comportamiento esperado y el resultado de cada configuración comparada. Eso permitiría a otros examinar la afirmación en lugar de confiar en una declaración de que una respuesta parecía mejor.

Para tareas de imagen, una respuesta correcta en un ejemplo sencillo aportaría evidencia limitada sobre entradas difíciles. Para tareas de generación, una respuesta rápida aportaría evidencia limitada sobre la compatibilidad de la aplicación. La solidez de cualquiera de los resultados depende de lo que realmente pruebe.

Estas señales deberían leerse juntas sin reducirlas a una única puntuación. La progresión del lanzamiento se refiere al artefacto. Los tiempos se refieren a la ejecución. Las comprobaciones de tareas se refieren a si la aplicación completa correctamente un trabajo útil.

Durante los próximos meses, el seguimiento más valioso conectará esas capas. Un resultado reproducible vinculado a una versión específica y a una tarea representativa reforzaría el argumento práctico. Las generalizaciones sin respaldo atraerían atención sin resolver la cuestión del despliegue.

Para los lectores que evalúan Ollama v0.40.12, comiencen con la carga de trabajo que ya les importa. Conserven su entrada, la configuración del modelo y el resultado esperado antes de comparar compilaciones. Registren por separado el tiempo dedicado a procesar la solicitud y el tiempo dedicado a generar la respuesta. Si las imágenes importan, conserven los archivos originales e inspeccionen los detalles que necesita su aplicación. Si la generación acelerada importa, comprueben las respuestas completadas junto con la velocidad. Guarden la etiqueta completa de la candidata con sus hallazgos para que las comparaciones posteriores sigan siendo interpretables. Después, tomen la decisión de actualización en torno a un resultado concreto: ¿la ruta de ejecución modificada mejoró la tarea que sus usuarios realmente realizan, bajo las condiciones a las que su aplicación realmente se enfrenta?