Ollama v0.40.12 cible la vitesse des prompts et les détails des petites images

Ollama a publié le candidat à la sortie Ollama v0.40.12, avec quatre changements visant les performances des modèles locaux, le traitement des images et les dépendances logicielles sous-jacentes. Cette distinction compte : les améliorations du traitement des prompts et celles de la génération proviennent de changements distincts, avec des limites différentes.

L’enjeu central réside dans l’écart entre la prise en charge d’un modèle et son exécution efficace. Un modèle peut se charger correctement tout en traitant les documents de manière inefficace ou en perdant des détails visuels utiles. Cette version s’attaque à des exemples précis de cet écart, plutôt que d’annoncer une nouvelle famille de modèles.

La comparaison dépasse également Ollama lui-même. MLX, le framework de tableaux pour l’apprentissage automatique d’Apple, offre aux chercheurs qui travaillent sur ses opérations sous-jacentes une voie de développement plus directe. Le rôle d’Ollama consiste à intégrer ces capacités dans un runtime de modèles, le logiciel qui exécute les modèles. Pour les développeurs d’applications, cette intégration détermine quelles améliorations en amont atteignent réellement leurs charges de travail.

Ce que Ollama v0.40.12 modifie réellement

Il s’agit d’une mise à jour ciblée du runtime, et l’artefact publié reste un candidat à la sortie.

Le candidat à la sortie porte le tag v0.40.12-rc0, bien que son titre d’affichage indique v0.40.12. GitHub le marque comme une préversion et le date du 27 octobre 2026. Sa comparaison part de v0.40.11.

Cette différence de nom mérite attention, car un simple titre d’affichage ne suffit pas à établir qu’une version stable a été publiée. Les lecteurs qui évaluent une mise à niveau doivent distinguer le candidat publié de tout artefact stable ultérieur. Les constats concernant cette build doivent conserver son tag complet.

Les changements répertoriés couvrent la gestion des images compactes de Gemma 4, les mises à jour de dépendances MLX, la prise en charge de DFlash2 et une mise à jour de dépendance llama.cpp. Les quatre entrées créditent le contributeur dhiltgen. Ensemble, elles décrivent une maintenance sur plusieurs chemins d’exécution plutôt qu’une fonctionnalité d’accélération universelle.

Cette portée rend la version pertinente pour différents groupes, pour des raisons différentes. Les développeurs utilisant les modèles d’images concernés font face à une question de correction. Ceux qui attendent le traitement des prompts ont une question de réactivité. Ceux qui testent l’accélération de génération prise en charge ont une autre question de performances.

Ces questions doivent rester distinctes lors de l’interprétation de l’annonce. Un traitement plus rapide des documents ne signifie pas automatiquement une génération de réponses plus rapide. Préserver les détails d’une image ne démontre pas une meilleure précision pour toutes les tâches visuelles. Mettre à jour une dépendance ne précise pas le bénéfice pour chaque appareil pris en charge.

Le cadrage utile est donc spécifique à la charge de travail. Quelle opération a changé, quel modèle l’utilise et quelle partie d’une application dépend de cette opération ? Ces questions offrent une lecture plus exploitable que de considérer chaque entrée du changelog comme la preuve d’une IA locale globalement plus rapide.

Pour un assistant documentaire, l’amélioration la plus pertinente peut intervenir avant même qu’une réponse apparaisse. Pour un assistant de captures d’écran, elle peut concerner les informations conservées depuis l’entrée. Pour une application générant des réponses plus longues, le chemin de génération peut mériter un examen plus approfondi.

Il s’agit d’exemples analytiques, et non de déploiements clients rapportés. Ils illustrent pourquoi une même version peut compter différemment selon les applications utilisant une interface identique. Le produit visible peut rester familier tandis que le travail effectué en dessous change.

La mise à jour incite également les responsables d’applications à revoir leurs anciennes hypothèses. Une comparaison antérieure peut refléter un chemin d’exécution plus ancien plutôt qu’une limitation durable du modèle. À l’inverse, un nouveau benchmark ne devrait pas effacer les données d’une charge de travail en production sans une autre comparaison.

C’est là l’importance pratique d’une version de maintenance comme celle-ci. Elle crée des raisons précises de réévaluer les comportements existants tout en laissant ouvertes les affirmations plus générales sur la qualité des modèles et leur adéquation au déploiement.

Les petites images révèlent l’écart entre charger et voir

Le changement lié aux images traite une perte d’informations avant que le modèle ne produise une réponse.

La correction de vision compacte concerne les tours de vision compactes de Gemma 4, les composants qui convertissent les images en entrées pour le modèle. Selon la pull request, le dimensionnement dynamique pouvait arrondir la plus petite grille d’image en dessous de son budget prévu de 70 tokens.

Ici, les tokens sont les unités utilisées pour représenter les informations visuelles lors du traitement par le modèle. Le changement arrondit cette grille vers le haut pour la tour compacte, avec un plafond au budget pris en charge suivant. Le responsable indique que les budgets explicites et le dimensionnement existant pour les tours plus grandes et unifiées restent inchangés.

Il s’agit d’une correction étroite aux implications utiles. Lorsqu’une entrée perd des détails pendant sa préparation, le raisonnement ultérieur ne peut pas récupérer de façon fiable les informations manquantes. Un modèle capable dépend toujours de ce que le runtime lui transmet.

Prenons une application qui pose des questions sur une petite capture d’écran contenant une étiquette d’état. Si la préparation supprime des détails pertinents, modifier la formulation de la question ne résoudra peut-être pas le problème sous-jacent. L’application doit conserver les éléments visuels suffisamment longtemps pour permettre leur interprétation.

Ce scénario explique pourquoi le traitement des images a sa place dans une discussion sur les performances. Les utilisateurs jugent la tâche achevée, notamment selon que le système lit correctement l’entrée. Une réponse qui arrive vite mais ignore l’étiquette pertinente engendre du travail supplémentaire.

Toutefois, cette correction ne doit pas devenir l’affirmation que les modèles compacts traitent désormais avec précision toutes les petites images. La source identifie un comportement de dimensionnement et une correction limitée. Elle n’établit pas un résultat général pour les captures d’écran, les documents numérisés, les diagrammes ou les photographies.

Les dimensions de l’image ne donnent également qu’une description incomplète de la difficulté. Une petite image contenant un symbole bien visible pose un défi différent d’une image contenant un texte dense. Une évaluation devrait refléter les informations qu’une application réelle doit extraire.

La comparaison la plus claire conserverait l’image et la question d’origine d’une build à l’autre. Redimensionner l’image différemment pendant une évaluation introduirait une autre explication à toute réponse modifiée. L’objectif est d’isoler le comportement du runtime examiné.

Pour les responsables de maintenance, cela modifie la manière dont les échecs doivent être étudiés. Une mauvaise réponse visuelle ne provient pas nécessairement des capacités apprises du modèle. La préparation de l’entrée est une autre couche plausible, et ce patch fournit un exemple concret.

Cela modifie aussi l’interprétation de résultats négatifs antérieurs. Si une configuration concernée écartait des informations utiles, un ancien test pourrait sous-estimer ce que cette configuration peut fournir après correction. Cette possibilité justifie un nouveau test, pas la réécriture des résultats précédents comme étant invalides.

La leçon plus large concerne les frontières des comparaisons de modèles. Le seul nom d’un modèle ne décrit pas l’ensemble du système évalué. La préparation des images, le logiciel d’exécution et le comportement de l’application contribuent tous à déterminer la réponse qui atteint l’utilisateur.

Les performances MLX d’Ollama s’améliorent avant que la réponse ne commence

Le changement de vitesse des prompts accélère la lecture de la requête, tandis que le responsable indique explicitement que la vitesse de décodage reste inchangée.

La mise à jour du traitement des prompts met à jour MLX et MLX-C, son interface en langage C. Elle utilise une attention native à fenêtre glissante, qui limite les opérations d’attention pertinentes à une fenêtre mobile d’entrées du modèle.

Le responsable rapporte des améliorations de prefill sur un Apple M5 Max. Le prefill est la phase qui traite l’entrée avant de générer une nouvelle sortie. Avec un prompt de 2 048 tokens, le débit rapporté augmente de 9,2 % pour Gemma, 14,5 % pour Flint et 24,1 % pour Laguna.

Avec un prompt de 6 144 tokens, les gains rapportés correspondants sont de 7,5 %, 14,3 % et 27,0 %. Il s’agit de mesures du responsable pour des configurations de modèles spécifiées. La pull request précise que la vitesse de décodage, c’est-à-dire le rythme de génération de la sortie, reste inchangée.

Cette précision définit la portée de l’affirmation relative aux performances MLX d’Ollama. Un utilisateur qui attend la lecture d’un long document rencontre un goulot d’étranglement différent de celui qui attend une longue réponse. Améliorer le premier ne démontre pas une amélioration du second.

C’est particulièrement pertinent lorsqu’une requête comprend un volume important de documents d’appui et demande une réponse brève. Dans cette charge de travail hypothétique, le traitement de l’entrée peut constituer une part importante de l’expérience. Une préparation plus rapide peut compter même lorsque la sortie suivante arrive au même rythme.

La situation inverse exige une interprétation différente. Une application avec une requête courte et une sortie générée abondante peut consacrer relativement peu de temps au traitement des prompts. Son expérience globale ne devrait pas être prédite à partir du seul débit de prefill.

Les pourcentages décrivent également un débit plutôt qu’une réduction universelle du temps d’attente. La latence de bout en bout, soit le temps écoulé pour la requête complète, comprend davantage que la phase de traitement mesurée. Le chargement, la surcharge de l’application et d’autres opérations compliquent toute transposition directe.

Cette distinction évite une erreur de reporting familière : présenter une amélioration d’un composant comme une amélioration équivalente de la tâche achevée. Un benchmark peut décrire avec exactitude le composant tout en laissant ouverte l’issue au niveau de l’application.

La version donne aux développeurs une raison plus précise d’étudier les charges de travail comportant de longues entrées. Elle ne les oblige pas à conclure que leur application est devenue plus rapide avant de l’avoir mesurée. Ce sont deux niveaux de preuve distincts.

Pour les équipes qui assemblent du contexte documentaire, les implications s’étendent également à la conception des évaluations. Les entrées mises en cache, qui réutilisent un travail déjà calculé, doivent être distinguées des entrées nouvelles. Sinon, des requêtes répétées peuvent masquer le travail de traitement affecté par la mise à jour.

Une comparaison d’application crédible devrait donc décrire ce que l’utilisateur a soumis et ce que le système a réutilisé. Sans cette distinction, une différence apparemment faible peut masquer une amélioration, ou une différence apparemment importante peut avoir une autre cause.

Les performances MLX d’Ollama sont surtout utiles comme affirmation d’ingénierie précise. La phase concernée, la configuration du modèle, le matériel et la longueur de l’entrée donnent aux lecteurs un élément à tester. Retirer ces limites rendrait l’affirmation plus large, mais moins informative.

La prise en charge de DFlash2 dans Ollama cible un goulot d’étranglement différent

DFlash2 concerne la génération des réponses ; ses résultats doivent donc rester distincts des améliorations du traitement des prompts.

L’implémentation de DFlash2 ajoute une approche de génération spéculative, dans laquelle la sortie proposée est vérifiée par le modèle cible. Le responsable décrit un sélecteur de candidats qui conditionne les choix successifs aux sélections précédentes.

Selon les notes d’implémentation, une session ébauche sept tokens par cycle et les vérifie via le mécanisme de rollback existant. Le contributeur affirme que la vérification préserve la distribution de sortie du modèle cible. Il s’agit d’une affirmation d’implémentation plutôt que d’une validation indépendante présentée ici.

La pull request compare DFlash2 à une tête intégrée de prédiction de plusieurs tokens, un mécanisme qui propose plusieurs tokens futurs. Pour qwen3.8:27b, avec la configuration à précision réduite indiquée, le responsable rapporte des gains de génération sur des systèmes M5 Max, M5 Pro et M2 Ultra.

Sur M5 Max, le débit de génération rapporté passe de 57,0 à 71,0 jetons par seconde avec le prompt testé plus court. La comparaison a utilisé la même build, plutôt que de mesurer la version précédente face à ce candidat.

Cette dernière distinction est importante. Ces résultats comparent des méthodes de génération au sein d’une même build. Ils ne doivent pas être présentés comme un gain de mise à niveau mesuré pour chaque utilisateur passant depuis la version précédente.

La prise en charge de DFlash2 par Ollama ajoute donc une voie d’évaluation supplémentaire, plutôt que de fournir une promesse globale de vitesse. Une configuration prise en charge permet de comparer les comportements. Elle n’indique pas à chaque application quelle méthode de génération produira le meilleur résultat.

Le compromis général de la génération spéculative est simple. Les propositions sont utiles lorsqu’un nombre suffisant d’entre elles l’est pour justifier le travail nécessaire à leur production et à leur vérification. Évaluer uniquement l’étape de proposition manquerait le coût de la vérification.

Pour un développeur d’applications, le résultat final importe davantage que le nombre de jetons candidats proposés en interne. Une méthode qui génère des brouillons de manière agressive doit toujours produire efficacement une sortie acceptée. Le résultat pertinent est une génération utile dans les conditions réelles de l’application.

Le comportement de sortie mérite d’être examiné au même titre que la vitesse. Les équipes utilisant des réponses structurées doivent vérifier que l’application reçoit toujours le format attendu. Les équipes évaluant des réponses factuelles doivent conserver leurs contrôles de correction existants lorsqu’elles introduisent une autre voie d’exécution.

Il s’agit de priorités d’évaluation, et non d’éléments prouvant que cette implémentation provoque des problèmes de format ou de qualité. La source décrit des garde-fous destinés à préserver le comportement. Des tests indépendants de l’application permettent à une équipe de déterminer si ses propres exigences continuent d’être satisfaites.

Il existe également une distinction à faire entre prise en charge et comportement par défaut. Une note de version annonçant une capacité n’établit pas, à elle seule, que chaque modèle installé l’utilise. Les lecteurs doivent identifier la configuration réelle derrière tout résultat observé.

Ce point relie cette fonctionnalité au reste de la version. Les améliorations d’exécution deviennent utiles grâce à une chaîne de décisions de compatibilité et d’intégration. L’utilisateur voit une réponse, mais le modèle choisi et la méthode d’exécution déterminent les changements qui y ont contribué.

Pour les charges de travail produisant de longues réponses, le mécanisme de génération mérite une attention propre. Combiner ses gains rapportés avec des pourcentages non liés de traitement des prompts créerait une estimation non étayée. Chaque amélioration nécessite une charge de travail correspondante avant de pouvoir appuyer une conclusion au niveau de l’application.

La mise à jour de dépendance maintient les comparaisons ancrées dans les faits

Une dépendance plus récente indique une fondation modifiée, mais n’établit pas un résultat de performance universel.

La mise à jour de llama.cpp fait passer la dépendance d’Ollama de la build b11845 à b11901. llama.cpp est un moteur d’inférence, un logiciel qui exécute des modèles entraînés pour produire des sorties. La pull request a été fusionnée le 26 octobre.

La pull request visible renvoie vers la comparaison en amont sans présenter de benchmark applicatif équivalent. Cela permet de rapporter le changement de version. Cela ne permet pas d’attribuer une amélioration précise de vitesse ou de qualité à chaque charge de travail utilisant cette voie.

Cela importe parce que les mises à jour de dépendances peuvent être facilement surinterprétées. Un numéro de build plus récent décrit la lignée logicielle. Il n’identifie pas les opérations qui ont changé pour une application donnée, ni n’établit si son goulot d’étranglement existant a évolué.

La comparaison avec l’utilisation directe du framework aide à clarifier la position d’Ollama. Le framework MLX expose directement aux développeurs des interfaces de programmation et des opérations de machine learning. Ollama intègre les capacités sous-jacentes dans un environnement d’exécution de modèles.

Ces approches répondent à des besoins qui se chevauchent, avec des niveaux de responsabilité différents. Un chercheur travaillant directement avec les opérations du framework peut étudier de près les choix d’implémentation. Une équipe applicative utilisant un runtime intégré s’appuie sur les voies d’exécution prises en charge par ce runtime.

Aucune de ces approches ne l’emporte par définition dans toutes les comparaisons. L’accès direct offre du contrôle, tandis que l’intégration peut réduire le travail nécessaire pour exploiter un modèle pris en charge. Une évaluation équitable doit demander quelles responsabilités l’équipe applicative souhaite assumer.

Ce candidat illustre aussi pourquoi les résultats en amont et en aval doivent rester distincts. Une capacité du framework nécessite une intégration appropriée avant qu’une application puisse en bénéficier. À l’inverse, une amélioration intégrée ne doit pas être attribuée à un nouveau modèle lorsque le modèle lui-même n’a pas changé.

Cette distinction affecte les affirmations concurrentielles. Un résultat provenant d’un modèle, d’un appareil et d’une voie d’exécution ne démontre pas qu’Ollama surpasse les runtimes alternatifs en général. Il établit un résultat pour le système testé, avec les limites de ce système incluses.

Les éléments disponibles proviennent principalement des responsables du projet. Ils confirment l’existence des changements et leurs mesures rapportées. Ils ne fournissent pas de consensus indépendant sur l’adoption en production, la fiabilité ou la supériorité selon les options de déploiement.

Il n’est pas nécessaire de fabriquer une controverse publique pour donner du sens à ces éléments. La question non résolue est pratique : les changements apportent-ils des gains utiles dans des applications au-delà des mesures des responsables ? Cette question est suffisamment importante sans inventer de partisans ou de critiques.

Pour les acheteurs en entreprise, la pression appropriée porte sur la qualité des preuves. Une vaste démonstration d’IA locale est moins utile que des résultats correspondant à la tâche visée. Les décisions d’achat exigent que le modèle, le matériel, la charge de travail et les exigences opérationnelles soient alignés.

Les développeurs gagnent également à conserver le contexte derrière leurs comparaisons. Les équipes documentant leurs évaluations peuvent utiliser une base de connaissances consultable pour préserver les conclusions avec les configurations et les exemples. Le dossier utile inclut les échecs et les limites, pas seulement l’exécution la plus rapide.

Trois signaux montreront l’importance de ce candidat

Les prochaines preuves significatives seront, dans cet ordre, la progression de la version, des mesures reproductibles et un comportement de tâche vérifié.

Premièrement, observez ce qui arrive au candidat publié. Un artefact stable, un candidat de suivi ou une version corrective clarifierait le logiciel disponible pour une adoption plus large. Ces événements n’établiraient pas automatiquement la qualité applicative, mais ils résoudraient une partie de la question du statut de la version.

La progression la plus informative conserverait des liens clairs entre les tags et les changements. Cela permettrait aux développeurs d’identifier si un résultat ultérieur concerne ce candidat ou une build modifiée. Sans cette continuité, les discussions peuvent mêler des résultats issus de logiciels différents sous le même nom de version abrégé.

Une correction ultérieure n’invaliderait pas automatiquement le travail décrit ici. Son importance dépendrait du comportement affecté. Les lecteurs doivent rechercher une relation concrète entre tout problème signalé, son périmètre et la configuration qu’ils utilisent.

Deuxièmement, recherchez des mesures applicatives reproductibles qui séparent le traitement des entrées de la génération des sorties. Cela permettrait de vérifier si les améliorations rapportées des composants résistent en dehors des conditions de mesure d’origine. Les résultats doivent identifier la configuration réelle du modèle et le matériel.

Des éléments issus d’une charge de travail correspondante renforceraient l’argument en faveur de l’adoption du changement pertinent. Une comparaison montrant peu de bénéfice de bout en bout réduirait cet argument sans nécessairement contredire le benchmark de composant. L’application pourrait simplement consacrer son temps ailleurs.

Les rapports de temps deviennent plus informatifs lorsqu’ils décrivent à la fois les entrées nouvelles et réutilisées. Ils doivent également distinguer un modèle déjà chargé d’une requête qui doit le charger. Ces conditions répondent à différentes questions sur l’usage quotidien.

Troisièmement, recherchez des contrôles au niveau des tâches concernant le traitement des images et la génération accélérée. La correction d’image nécessite des exemples qui testent la conservation des informations visuelles. La voie de génération nécessite des contrôles de sortie en plus des mesures de temps, particulièrement lorsque les applications dépendent d’une structure prévisible.

Les rapports utiles incluraient l’entrée d’origine, le comportement attendu et le résultat de chaque configuration comparée. Cela permettrait à d’autres d’examiner l’affirmation plutôt que de s’appuyer sur une déclaration selon laquelle une réponse semblait meilleure.

Pour les tâches d’image, une réponse correcte sur un exemple facile fournirait des éléments limités concernant les entrées difficiles. Pour les tâches de génération, une réponse rapide fournirait des éléments limités concernant la compatibilité applicative. La force de chaque résultat dépend de ce qu’il teste réellement.

Ces signaux doivent être lus ensemble sans les réduire à un score unique. La progression de la version concerne l’artefact. Les mesures de temps concernent l’exécution. Les contrôles de tâches concernent la capacité de l’application à accomplir correctement un travail utile.

Au cours des prochains mois, le suivi le plus précieux reliera ces niveaux. Un résultat reproductible associé à une version précise et à une tâche représentative renforcerait l’argument pratique. Des généralisations non étayées attireraient l’attention sans résoudre la question du déploiement.

Pour les lecteurs évaluant Ollama v0.40.12, commencez par la charge de travail qui compte déjà pour vous. Conservez son entrée, la configuration du modèle et la sortie attendue avant de comparer les builds. Consignez séparément le temps passé à traiter la requête et celui consacré à générer la réponse. Si les images importent, conservez les fichiers d’origine et examinez les détails dont votre application a besoin. Si la génération accélérée importe, vérifiez les réponses terminées en parallèle de la vitesse. Conservez le tag complet du candidat avec vos résultats afin que les comparaisons ultérieures restent interprétables. Prenez ensuite la décision de mise à niveau autour d’un résultat concret : la voie d’exécution modifiée a-t-elle amélioré la tâche que vos utilisateurs accomplissent réellement, dans les conditions auxquelles votre application est réellement confrontée ?