Ollama v0.32.10 réinitialise les valeurs par défaut, mais les modèles Alibaba sur GitHub bougent à peine

Ollama v0.32.10 modifie une valeur par défaut de génération restée à 1.1 pendant des années, mais l’histoire des modèles Alibaba sur GitHub comporte une exception importante. Qwen3, Qwen3.6 et Qwen3-Coder publient déjà leurs propres valeurs de pénalité de répétition. Ces modèles devraient donc éviter le changement de comportement le plus visible de cette version.

Cette exception illustre la tension plus large au cœur de cette mise à jour. Ollama abandonne un choix de réglage appliqué à l’ensemble de l’environnement d’exécution et redonne aux auteurs de modèles davantage de contrôle sur le comportement de génération. Ce changement rapproche Ollama des moteurs qui considèrent l’absence de pénalité de répétition comme le réglage neutre par défaut.

La version accélère également le traitement des prompts pour certains modèles NVFP4 sur le framework MLX d’Apple. Un correctif de sécurité distinct comble une faille de vérification des blobs liée aux digests dupliqués dans les manifestes OCI. Ensemble, ces changements rendent la v0.32.10 plus importante que ne le laisse entendre sa brève note de version.

Ollama v0.32.10 désactive un biais caché de génération

Le changement central supprime une intervention globale que de nombreux créateurs de modèles n’avaient jamais demandée.

Ollama attribuait auparavant une pénalité de répétition de 1.1 lorsqu’un modèle n’en définissait pas. Une pénalité de répétition réduit la probabilité des tokens apparus récemment dans le texte généré. Elle peut décourager les boucles, mais aussi pénaliser des répétitions nécessaires.

La version 0.32.10 fait passer la valeur de repli à 1.0, ce qui désactive la pénalité. Un modèle peut toujours définir une autre valeur via ses paramètres publiés. L’appelant peut également fournir une valeur dans les options de requête.

La distinction entre une valeur par défaut et un réglage explicite du modèle est importante. Ollama superpose les options de requête aux paramètres publiés du modèle et aux valeurs par défaut du serveur. L’ancienne valeur serveur pouvait donc s’appliquer à tout modèle local dont les paramètres laissaient ce champ non défini.

Selon les notes de version, le nouveau comportement correspond à celui d’autres moteurs d’inférence et améliore le décodage spéculatif. La version était toujours étiquetée comme préversion lors de sa publication sous le tag v0.32.10-rc1.

Le décodage spéculatif utilise un processus de brouillon plus rapide pour proposer plusieurs tokens avant qu’un modèle cible ne les vérifie. Les propositions acceptées réduisent le nombre d’étapes coûteuses du modèle cible. Les propositions rejetées annulent une partie de cet avantage.

Une pénalité cachée peut pousser le modèle cible à désapprouver des brouillons produits sans le même ajustement. Ce désaccord ne révèle pas nécessairement un brouillon médiocre. Il peut provenir d’une modification silencieuse de la distribution cible par l’environnement d’exécution.

L’analyse des commits fournit des mesures concrètes issues des tests d’Ollama. Sur Muse Glimmer 30B, l’ancienne valeur par défaut aurait réduit le débit spéculatif de bout en bout de 13 % à 16 %.

Les mêmes notes de test indiquent que l’acceptation en prose à une température de 0.8 est passée de 0.44 à 0.30 avec la pénalité. Sur Qwen3.6-35B, la longueur moyenne des brouillons acceptés aurait diminué de 4.3 tokens à 3.5 tokens.

Ces résultats proviennent des tests du projet, et non d’un benchmark indépendant. Le matériel, les prompts, les températures et les stratégies de brouillon peuvent modifier le résultat. Le mécanisme à l’origine du ralentissement reste toutefois techniquement simple.

L’ancienne valeur par défaut affectait aussi les sorties ordinaires. Le code, le JSON et les longues traces de raisonnement doivent souvent répéter de la ponctuation, des identifiants, des noms de champs ou des tokens structurels. Pénaliser ces tokens modifie le comportement même lorsque la répétition est correcte.

Ollama traite désormais 1.0 comme la position neutre. Les modèles qui bénéficient d’un contrôle de la répétition doivent l’indiquer explicitement. Cela transfère la responsabilité de la préférence historique de l’environnement d’exécution vers une configuration propre au modèle.

Cette approche a un coût de compatibilité. Certains anciens modèles pourraient se répéter davantage après une mise à niveau, car la pénalité précédente masquait leur comportement. Ollama conseille aux utilisateurs de définir un paramètre par modèle lorsque cela se produit.

Cette recommandation est plus précise que de rétablir le réglage globalement. Une valeur corrective peut rester attachée au modèle concerné. Les autres checkpoints n’héritent plus d’une intervention sans rapport.

La version modifie donc bien plus qu’un seul nombre. Elle clarifie qui contrôle le comportement d’échantillonnage et fait de l’absence de recommandation d’un modèle le synonyme de « désactivé ». Ce principe exerce une pression plus large sur les environnements locaux d’inférence.

Le lien avec Alibaba sur GitHub est une exception, pas le sujet principal

Les modèles Alibaba sur GitHub aident à expliquer le changement, mais les principales familles Qwen n’en sont pas les premières bénéficiaires.

Le mot-clé fourni renvoie au travail d’Alibaba sur les modèles ouverts dans GitHub. En pratique, le lien pertinent passe par Qwen, la famille de modèles d’Alibaba, et par la gestion des réglages de génération Qwen par Ollama. Il ne s’agit pas d’une version d’Ollama rédigée par Alibaba.

Les notes de modification d’Ollama indiquent que Qwen3 et Qwen3.6 fixent déjà une pénalité de répétition à 1.0. Qwen3-Coder utilise la valeur recommandée par Qwen, soit 1.05. Ces valeurs publiées priment sur la nouvelle valeur de repli d’Ollama.

Les utilisateurs de ces familles ne doivent pas supposer que la v0.32.10 modifie leur comportement de répétition. La valeur par défaut du serveur n’intervient que lorsque le modèle et la requête omettent le paramètre. Les valeurs explicites préservent le chemin existant.

Cette exception est utile, car elle démontre le modèle sous-jacent de cette version. L’environnement d’exécution fournit une base neutre, tandis que les éditeurs de modèles encodent les écarts justifiés par leurs checkpoints. Cette séparation facilite le raisonnement lors des mises à niveau.

Qwen2.5 présente le cas limite non résolu. L’analyse d’Ollama indique que cette famille recommande 1.05, mais est livrée sans la couche de paramètres correspondante. Elle passe donc de l’ancienne valeur de repli de 1.1 à la nouvelle valeur de 1.0.

Aucune de ces valeurs ne correspond à la recommandation indiquée. La version 0.32.10 supprime une valeur par défaut trop générale, mais ne complète pas automatiquement les métadonnées manquantes des modèles. Ce travail reste du ressort du processus de packaging des modèles.

Ce contraste évite également une conclusion trompeuse au sujet d’Alibaba et de GitHub. Il ne s’agit pas d’un affrontement dans lequel Ollama aurait modifié les réglages de Qwen contre la volonté d’Alibaba. Pour les principales familles Qwen actuelles, Ollama respecte les valeurs déjà attachées aux modèles.

D’autres familles sont plus directement exposées. Ollama cite Gemma, Muse Glimmer, Laguna, GPT-OSS, DeepSeek, Nemotron, Granite, Mistral, Llama, Phi, GLM, LLaVA et Devstral parmi les modèles locaux affectés.

L’impact exact variera selon les checkpoints. Un modèle qui revient rarement sur des tokens récents peut présenter peu de différence visible. Les sorties structurées, le codage et les longs raisonnements peuvent réagir plus nettement, car les répétitions légitimes y sont fréquentes.

Les modèles cloud échappent à ce chemin particulier de valeur par défaut du serveur, selon les notes de comparaison du projet. Cette distinction importe pour les utilisateurs qui combinent des modèles locaux et hébergés derrière une même application. Des requêtes identiques peuvent encore se heurter à une propriété différente des paramètres.

La pression s’exerce donc sur les responsables des environnements d’exécution et les packageurs de modèles, et non sur un seul fournisseur de modèles. Les environnements d’exécution ont besoin de valeurs par défaut neutres et documentées. Les éditeurs ont besoin de paramètres complets qui accompagnent leurs modèles.

Les développeurs d’applications doivent également cesser de considérer les paramètres d’échantillonnage comme des constantes universelles. Une valeur qui supprime les boucles dans un checkpoint peut réduire la fidélité dans un autre. La même valeur peut aussi perturber l’acceptation des brouillons lors du décodage spéculatif.

Les équipes devraient examiner leurs Modelfiles et leurs payloads de requête avant d’attribuer des changements de sortie à de nouveaux poids. Une application peut déjà remplacer le paramètre. Une configuration de modèle publiée peut faire de même.

Cette hiérarchie de configuration explique pourquoi de vastes affirmations de benchmark seraient prématurées. Deux utilisateurs peuvent installer la même version d’Ollama tout en utilisant des réglages effectifs différents. Leurs résultats dépendent du package du modèle et de la couche de requête.

La version rend cette hiérarchie moins surprenante, mais ne la supprime pas. La question pratique n’est plus de savoir si Ollama utilise 1.0. Elle est de savoir quelle couche fournit la valeur finale pour une requête d’inférence donnée.

Pour les utilisateurs de modèles Alibaba sur GitHub, c’est le point à retenir. Vérifiez la variante Qwen et ses paramètres publiés avant de modifier quoi que ce soit. N’ajoutez pas de pénalité simplement parce qu’une ancienne version d’Ollama en appliquait une silencieusement.

Un préremplissage NVFP4 plus rapide supprime un aller-retour mémoire supplémentaire

L’optimisation MLX fusionne deux opérations qui nécessitaient auparavant un travail GPU distinct.

La version 0.32.10 accélère le préremplissage des modèles NVFP4 MLX utilisant une échelle globale. Le préremplissage correspond au traitement initial des tokens du prompt avant que le modèle ne commence à générer une réponse. Un préremplissage plus rapide réduit l’attente avant le début de la sortie.

NVFP4 est un format à virgule flottante sur quatre bits conçu pour compresser les poids des modèles tout en conservant des informations d’échelle. Les checkpoints ModelOpt concernés appliquent une échelle globale float32 après une quantification par groupe. Cette échelle supplémentaire créait une surcharge évitable dans l’ancien chemin d’exécution d’Ollama.

Auparavant, MLX effectuait la multiplication et la conversion vers le type de données d’activation sous forme d’opérations eager distinctes. Cette approche nécessitait un lancement de noyau supplémentaire. Elle matérialisait également un résultat intermédiaire en mémoire.

Le nouveau chemin compile la multiplication et le cast dans un seul noyau. La fusion conserve le travail intermédiaire au sein d’une seule opération. Elle réduit la surcharge de lancement et évite un tenseur matérialisé distinct par projection.

Ollama rapporte que le débit médian de préremplissage sur un M5 Max est passé de 703 à 769 tokens par seconde pour Qwen3.6-27B. Cela représente une hausse rapportée de 7.9 %.

Muse Glimmer 30B serait passé de 790 à 843 tokens de préremplissage par seconde. Ollama calcule cette amélioration à 6.7 %. Le résumé de version arrondit le gain global à environ 7 % à 8 %.

Le projet indique avoir utilisé des exécutions A/B à ordre inversé par rapport à la branche principale. Les sorties gloutonnes sont restées identiques octet pour octet lors de ces tests. Ce détail suggère que l’optimisation a modifié l’efficacité d’exécution sans chercher à modifier les sorties numériques.

L’amélioration a un périmètre restreint. Elle ne s’applique qu’aux checkpoints NVFP4 dotés d’une échelle globale. Les checkpoints NVFP4 à échelle unique, MXFP8 et quantifiés affine continuent d’utiliser leurs chemins existants.

Le décodage spéculatif est également resté inchangé dans la marge de bruit des mesures pour ces modèles. Cela diffère de l’ajustement de la pénalité de répétition, qui affectait directement l’acceptation des brouillons. L’optimisation du préremplissage traite le travail effectué avant le début du décodage.

Les utilisateurs devraient donc observer le gain le plus visible avec de longs prompts. Un court message de chat passe moins de temps total en préremplissage, de sorte que l’intervalle économisé peut sembler modeste. Les documents volumineux et les historiques de conversation étendus fournissent davantage de tokens de prompt à traiter.

Un assistant de codage offre un exemple clair. Il peut envoyer des instructions de dépôt, plusieurs fichiers source, des résultats d’outils et l’historique de conversation avant de demander le token suivant. Le préremplissage détermine à quelle vitesse le modèle absorbe ce contexte assemblé.

Un flux de recherche local crée une charge similaire. Il peut combiner des notes, des passages extraits, des citations et une longue question dans une seule requête. Les équipes qui construisent une base de connaissances consultable devraient mesurer séparément le délai avant le premier token et la vitesse de génération.

Cette séparation des métriques évite une erreur fréquente de benchmarking. Le débit de préremplissage mesure l’ingestion du prompt, tandis que le débit de décodage mesure les tokens générés. Une première étape plus rapide ne garantit pas une sortie soutenue plus rapide.

La portée matérielle compte également. Les chiffres publiés par Ollama utilisent une M5 Max, et MLX cible les plateformes Apple. Les différences de bande passante mémoire, de conditions thermiques, de longueur des prompts et de formes de modèles peuvent modifier le gain réellement observé.

Le gain revendiqué doit donc être considéré comme un élément de preuve propre au projet, et non comme une promesse universelle. Les développeurs peuvent le valider en fixant le modèle, le prompt, la longueur de contexte et les paramètres de génération. Alterner l’ordre des tests aide à réduire les biais liés au cache chaud et aux conditions thermiques.

Même avec ces réserves, le mécanisme est crédible et précis. Éliminer un lancement et une allocation intermédiaire constitue un schéma d’optimisation bien connu. Il cible également un chemin que les modèles locaux quantifiés sollicitent de façon répétée.

L’enjeu plus large se situe dans l’évolution de la concurrence autour de l’inférence locale. La qualité des modèles continue d’attirer l’attention, mais l’efficacité d’exécution détermine si les grands contextes restent agréables à utiliser. De petites améliorations de noyau s’accumulent sur de nombreuses projections et requêtes.

Pour les utilisateurs de Qwen, cette optimisation est plus pertinente que le changement de pénalité par défaut. Les checkpoints Qwen3.6 NVFP4 compatibles peuvent bénéficier d’un préremplissage plus rapide même lorsque leur réglage explicite de répétition reste inchangé. Une même version peut préserver la politique de sortie tout en améliorant le traitement des prompts.

La correction OCI discrète comble une lacune persistante de vérification

La correction de sécurité garantit qu’un blob nouvellement téléchargé ne peut pas contourner la vérification via une collision de condensat dupliqué.

Ollama distribue les artefacts de modèles à l’aide de manifestes de type OCI. Un manifeste peut référencer un objet de configuration et une ou plusieurs couches par condensat. Le condensat identifie le contenu au moyen de son empreinte cryptographique.

Le bug apparaissait lorsque la configuration et une couche d’un manifeste partageaient le même condensat. Ollama suivait la possibilité d’ignorer la vérification dans une map indexée par ce condensat. Deux entrées associées à la même clé pouvaient s’écraser mutuellement.

Une configuration mise en cache pouvait définir la valeur de la map à true, indiquant que la vérification pouvait être ignorée. Une couche fraîchement téléchargée avec le même condensat devait, elle, être vérifiée. L’état de succès de cache de la configuration pouvait écraser la valeur false de la couche.

Cette collision permettait au nouveau blob d’atteindre le disque sans le contrôle de hachage attendu. La correction de vérification modifie la façon dont la map combine les états. Dès qu’un téléchargement associé à un condensat n’était pas un succès de cache, la vérification reste obligatoire.

L’implémentation utilise un ET logique lors de la mise à jour de la décision d’ignorer la vérification. Un condensat ne peut être éligible à une vérification ignorée que si chaque occurrence pertinente satisfait la condition de cache. Un seul téléchargement récent impose la vérification.

La pull request associée décrit un modèle de menace plus grave qu’une corruption accidentelle. Elle indique qu’un registre OCI malveillant pourrait construire un manifeste avec des condensats dupliqués. Le registre pourrait ensuite rediriger la récupération du blob vers un point de terminaison interne.

Ce schéma ressemble à une falsification de requête côté serveur, couramment abrégée SSRF. Un attaquant amène un serveur à demander un emplacement réseau qu’il ne peut pas atteindre directement. Les services internes sont des cibles fréquentes.

Selon l’analyse de la pull request, la réponse pourrait être écrite sur le disque comme blob. La collision de condensats pourrait alors supprimer la vérification du hachage. Le fichier pourrait persister malgré son incompatibilité avec l’identité de contenu déclarée.

La note de version emploie une formulation plus restreinte et indique que la vérification des blobs était ignorée dans la condition de condensat partagé. Les utilisateurs ne doivent pas considérer cette phrase comme la preuve d’une exploitation connue. Le contenu public décrit une voie plausible et une faille de code.

Aucun élément des notes de version examinées n’établit une exploitation à l’état sauvage. Elles ne quantifient pas non plus la fréquence à laquelle des registres tiers produisent de tels manifestes. Ces incertitudes comptent lors de l’évaluation du risque opérationnel.

La réponse prudente reste simple. Les utilisateurs qui récupèrent des modèles depuis des registres non fiables ou exploités en privé devraient prioriser la mise à jour. Les opérateurs devraient également restreindre, lorsque cela est possible, l’accès réseau sortant depuis l’infrastructure de service des modèles.

La vérification et les contrôles réseau résolvent des problèmes différents. La vérification des condensats détecte un contenu qui ne correspond pas au manifeste. Les restrictions de sortie réduisent les destinations internes qu’une récupération manipulée peut atteindre.

Les registres de confiance ne rendent pas le défaut de code sans importance. Les identifiants du registre, le comportement des redirections, les miroirs, les proxys ou une infrastructure compromise peuvent étendre la frontière de confiance effective. La vérification du contenu est censée résister à ces défaillances.

La correction illustre aussi pourquoi la distribution de modèles mérite le même examen que la distribution de paquets. Un modèle n’est pas un unique fichier inerte dans tous les flux de travail. Il peut arriver sous forme de manifestes, d’objets de configuration, de couches, de modèles, et de métadonnées d’exécution.

Chaque étape crée des hypothèses sur l’identité et la mise en cache. Une clé dupliquée peut transformer une optimisation locale sûre en contournement de vérification. La faiblesse ne nécessitait pas de défaillance de l’algorithme de hachage lui-même.

Le contributeur vigneshakaviki a soumis la correction via la pull request 15504, avec Patrick Devine indiqué comme co-auteur. Les notes de v0.32.10 identifient vigneshakaviki comme contributeur pour la première fois. Cette contribution est devenue l’un des trois changements majeurs de la version.

Pour les adopteurs en entreprise, cette correction peut l’emporter sur les travaux de performance. Une amélioration en pourcentage affecte la latence. Un contrôle d’intégrité ignoré affecte la fiabilité de l’artefact entrant dans un environnement d’inférence.

Les équipes devraient consigner l’origine du registre, le condensat du manifeste, les blobs résolus et la version d’Ollama dans les journaux de déploiement. Ces informations facilitent l’examen des incidents et la reproductibilité. Elles séparent également les enquêtes sur le comportement des modèles de celles sur la chaîne d’approvisionnement.

La mise à jour n’élimine pas tous les risques liés aux registres. Elle corrige une collision dans l’état de vérification. Les opérateurs ont toujours besoin de contrôles d’accès, de points de terminaison de confiance, d’un réseau contraint et d’un processus documenté de promotion des artefacts de modèles.

Le nouveau réglage par défaut privilégie la fidélité au modèle plutôt que la compatibilité

Le réglage par défaut plus propre d’Ollama est défendable, mais il peut révéler des répétitions que les utilisateurs n’avaient jamais vues auparavant.

Désactiver une pénalité ne garantit pas un meilleur texte. Cela supprime une intervention d’exécution. Le modèle sous-jacent, le prompt, le contexte, l’échantillonneur et les paramètres publiés déterminent toujours la sortie.

Les checkpoints plus anciens ou plus petits peuvent répéter des phrases lorsque la génération devient instable. L’ancienne valeur de 1.1 pouvait masquer une partie de ce comportement. Les utilisateurs passant directement de v0.32.8 pourraient donc remarquer des boucles sans modifier le code de leur application.

Ce résultat ne signifierait pas nécessairement que les poids du modèle ont changé. Il pourrait découler entièrement du nouveau repli. Comparer les options de requête effectives est essentiel avant d’ouvrir un bug de qualité de modèle.

Le remède doit rester spécifique au modèle. Un utilisateur peut ajouter une pénalité de répétition via un Modelfile ou les options de requête après avoir confirmé la régression. Appliquer 1.1 à chaque modèle recréerait le problème de compatibilité que cette version corrige.

Les développeurs devraient tester au moins trois classes de sortie. La prose naturelle révèle les boucles de phrases. Le code et le JSON montrent si la pénalité endommage la répétition structurelle requise.

Les longues traces de raisonnement méritent un test distinct. Leurs noms de variables, étiquettes et structures intermédiaires répétés peuvent interagir différemment avec les pénalités. Un seul benchmark de chat court ne capturera pas ce comportement.

Le décodage spéculatif ajoute une autre couche de mesure. Les équipes devraient enregistrer la longueur de brouillon acceptée, le taux d’acceptation et le débit de bout en bout. La vitesse brute de jetons du modèle cible ne peut pas révéler si le contrôleur a cessé de spéculer.

Les chiffres de Muse Glimmer publiés dans la version montrent pourquoi cela compte. Un paramètre qui semble être un ajustement mineur de qualité de texte a, selon les rapports, entraîné un coût de débit à deux chiffres. La politique d’échantillonnage est devenue une préoccupation de performance système.

Toutefois, les résultats de benchmark sur deux modèles nommés ne peuvent pas trancher pour chaque checkpoint. Les méthodes de brouillon diffèrent, et l’acceptation dépend de l’alignement entre les distributions du brouillon et de la cible. La température modifie également la comparaison.

L’interprétation correcte est conditionnelle. Retirer une pénalité non demandée élimine une source connue de désaccord entre brouillons. L’accélération réellement obtenue dépend du fait que le modèle concerné utilise le décodage spéculatif et de la proximité entre son chemin de brouillon et la cible.

Le résultat MLX présente des limites similaires. Qwen3.6-27B et Muse Glimmer 30B ont montré un préremplissage plus rapide sur une M5 Max. Les autres puces et les checkpoints à l’échelle mondiale nécessitent des tests directs.

Les utilisateurs doivent également distinguer les étiquettes de version. GitHub a publié l’artefact cité sous v0.32.10-rc1 et l’a marqué comme préversion. Les équipes de production peuvent exiger une version stable ou une qualification interne avant un déploiement étendu.

L’exposition de sécurité peut modifier ce calcul. Une équipe utilisant des registres non fiables pourrait prioriser la correction de vérification. Un ordinateur portable de développeur entièrement isolé utilisant des artefacts de confiance peut accepter un déploiement plus lent.

Ces décisions ne sont pas contradictoires. L’adoption d’une version combine la compatibilité comportementale, les performances et la posture de sécurité. Chaque environnement attribue des poids différents à ces dimensions.

L’adversaire principal dans cette version n’est donc pas Ollama contre Alibaba, MLX ou un autre runtime. Il s’agit d’un réglage historique à l’échelle du runtime face à une configuration rédigée par le modèle. La version 0.32.10 choisit cette dernière.

Ce choix aligne l’inférence locale sur un objectif d’interopérabilité plus large. Les modèles se comportent plus uniformément lorsque les moteurs partent d’un échantillonnage neutre. Les métadonnées explicites peuvent alors documenter les différences intentionnelles.

La cohérence reste incomplète tant que les paquets omettent les valeurs recommandées. Qwen2.5 démontre cette lacune. Un réglage serveur neutre par défaut ne peut pas remplacer un packaging de modèle précis.

Le test à long terme consiste à déterminer si les éditeurs ajoutent des métadonnées complètes de génération et si les runtimes exposent clairement la configuration effective. Sans visibilité, les utilisateurs continueront à diagnostiquer des couches de paramètres invisibles à travers les changements de sortie.

La mise à jour d’Ollama améliore la base, mais l’observabilité est la prochaine étape. Une trace de requête devrait permettre d’identifier facilement la pénalité de répétition finale. Les utilisateurs ne devraient pas avoir besoin d’archéologie de dépôt pour savoir quelle couche l’a fournie.

Ce que les développeurs doivent surveiller après v0.32.10

Trois signaux détermineront si cette version devient une correction durable ou un nouveau cycle temporaire d’ajustement.

Le premier signal concerne les rapports de répétitions observées dans le monde réel pour les modèles qui héritaient auparavant de 1.1. Les rapports devraient identifier le condensat du modèle, le prompt, les options effectives, la longueur de contexte et les réglages de l’échantillonneur. Sans ces détails, les comparaisons resteront peu fiables.

Un ensemble de régressions reproductibles affaiblirait l’argument selon lequel 1.0 suffit à lui seul. Il ne justifierait pas le rétablissement d’une pénalité universelle. Il montrerait que les paquets de modèles concernés nécessitent des paramètres explicites.

Le deuxième signal est la télémétrie de décodage spéculatif sur davantage de modèles et de matériel. Les chiffres publiés par Ollama pour Muse Glimmer et Qwen3.6 établissent un mécanisme et deux cas de test. Des résultats plus larges doivent montrer si les gains persistent avec différents brouillons, prompts et températures.

Des taux d’acceptation plus élevés avec une sortie stable renforceraient l’argument de performance de la version. Peu de changement hors de la configuration publiée en limiterait la portée. L’un ou l’autre résultat aiderait les équipes à choisir des réglages fondés sur des preuves.

Le troisième signal est l’adoption de la correction de vérification OCI dans les déploiements et les paquets dérivés. Les opérateurs devraient confirmer quelle version contient le correctif dans leur canal de distribution. Ils devraient également examiner si les registres de modèles peuvent rediriger les téléchargements vers des réseaux internes sensibles.

La divulgation publique d’une exploitation augmenterait fortement l’urgence de la mise à jour. L’absence persistante de telles preuves ne rendrait pas la faille inoffensive. Elle maintiendrait l’évaluation centrée sur le durcissement préventif plutôt que sur la réponse aux incidents.

L’optimisation NVFP4 mérite d’être surveillée dans la même fenêtre d’évaluation. Mesurez le délai avant le premier token avec des prompts longs et fixes sur du matériel Apple pris en charge. Gardez la vitesse de décodage distincte afin qu’un gain de préremplissage ne soit pas présenté à tort comme une accélération universelle.

Les utilisateurs des modèles Alibaba sur GitHub doivent accorder une attention particulière à la provenance de la configuration. Qwen3, Qwen3.6 et Qwen3-Coder définissent déjà des pénalités ; des remplacements inutiles peuvent donc annuler le bénéfice des réglages définis par les auteurs du modèle. Qwen2.5 exige une inspection plus attentive, car sa recommandation et sa solution de repli intégrée peuvent différer.

Avant la mise à niveau, constituez une petite suite de référence. Incluez du texte courant, des sorties structurées, du code, des prompts longs et tout mode spéculatif utilisé en production. Consignez l’empreinte du modèle ainsi que chaque option explicitement définie.

Après la mise à niveau, comparez les réglages effectifs avant d’évaluer la qualité du texte généré. Examinez ensuite la latence de préremplissage, le débit de décodage, l’acceptation des brouillons et le comportement en matière de répétitions. Cette séquence évite qu’une seule valeur par défaut modifiée ne se transforme en un diagnostic flou de la qualité du modèle.

Ollama v0.32.10 est, au fond, une version centrée sur les frontières de responsabilité. Les éditeurs de modèles sont responsables des recommandations de génération propres à chaque checkpoint. L’environnement d’exécution est responsable d’une exécution neutre, de kernels efficaces et d’une gestion vérifiée des artefacts.

L’action utile suivante consiste à tester ces frontières dans votre propre pile. Votre package de modèle définit-il la pénalité qu’il prévoit, et vos journaux peuvent-ils prouver quelle valeur a été utilisée ? Sinon, documentez cette configuration avant la prochaine mise à niveau et conservez les preuves avec vos artefacts de modèle.