Qwen3.5-0.8B : une IA a modifié 0,016 % de ses poids, et les boucles de réflexion sont passées de 93 % à environ 32 %

Une autre IA a changé 64 colonnes de nombres à deux endroits de Qwen3.5-0.8B, un petit modèle de raisonnement ouvert, et elle l'a fait sans le moindre entraînement. Nous avons fait tourner le modèle modifié et l'original côte à côte sur une RTX 4090 de notre cloud, sur les mêmes 50 problèmes de maths avec les mêmes réglages. Le modèle modifié a eu 62 % de bonnes réponses. L'original, 8 %, parce que 96 % de ses réponses ne se terminaient jamais : il tournait en rond dans sa réflexion jusqu'à la limite de 32 768 tokens (des morceaux de mots). Si vous servez de petits modèles de raisonnement sur vos propres GPU, c'est une histoire de coût autant que de précision. Une réponse qui ne finit jamais occupe une place sur votre carte jusqu'à ce que la limite la coupe, et le plus souvent elle ne donne aucune réponse. Le fichier modifié se charge et se sert avec la même commande que le modèle de base. Nous n'avons vérifié que les maths, avec la réflexion activée.

La question de l'image est simple : combien de diviseurs a 196 ? La réponse est 9. Le modèle modifié l'a trouvée et s'est arrêté. Le modèle de base s'est mis à énumérer des nombres au-delà de 3 300, un par un, et continuait encore quand la limite l'a coupé.

Un modèle qui ne trouve pas la fin, et une modification qui la lui donne

La modification fait une seule chose : elle supprime l'habitude qui faisait boucler le modèle. Les maths que le modèle réussit, il les savait déjà.

Qwen3.5-0.8B fait partie de la famille Qwen3.5, avec environ 0,8 milliard de nombres appris (les poids). Avant de répondre, un modèle de raisonnement écrit un brouillon : il réfléchit à voix haute, puis donne le résultat. La propre page du modèle chez Qwen prévient que cette taille est "more prone to entering thinking loops" que ses grands frères. Imaginez un groupe qui n'arrive pas à trouver la fin d'un morceau. Tout le monde joue encore juste, mais l'outro tourne en boucle jusqu'à ce que l'ingé son coupe le courant. Sur un GPU, l'ingé son, c'est la limite de tokens, et chaque token que le modèle écrit prend du temps sur la carte.

Le 2 novembre 2026, une équipe du MIT CSAIL a publié un billet de blog sur ce qu'elle appelle la programmation dans l'espace des poids. Dans une de leurs expériences, un grand modèle qu'ils appellent GPT-6 Astra reçoit un outil pour inspecter et modifier les nombres du petit modèle. Il reçoit aussi des problèmes d'entraînement, aucun tiré du test sur lequel il est noté. Son budget est un nombre d'exécutions d'essai du petit modèle : 10, 25 ou 50. Astra observe ce que fait le modèle, lit ses rouages internes et modifie directement les nombres. Aucun entraînement d'aucune sorte.

Sur les 96 premières réponses d'essai du modèle de base, 85 sont allées jusqu'à la limite de 32 768 tokens. Avec 50 exécutions, Astra a trouvé le motif derrière les boucles à deux endroits du modèle, et l'a effacé de 64 colonnes de nombres à chacun. Cela fait 131 072 poids sur l'ensemble du modèle : 0,016 %. Sur MATH-500, un jeu standard de 500 problèmes de maths de compétition, les auteurs annoncent un bond de 7,9 % à 48,1 % de bonnes réponses. La part de réponses coupées à la limite est tombée de 93 % à 33,1 %. Ils annoncent des bonds similaires sur deux autres tests, que nous n'avons pas refaits (voir l'annexe).

Les auteurs ont publié la modification exacte et un script qui la reconstruit. L'utilisateur Hugging Face akhaliq a reconstruit le fichier du modèle modifié, l'a relancé sur les 500 problèmes et a mis en ligne une démo publique. Sa réexécution a obtenu 51,0 % de bonnes réponses, avec 31,6 % des réponses coupées à la limite. Nous avons repéré l'histoire dans la vidéo d'actualité d'AI Search du 8 novembre.

62 % de bonnes réponses contre 8 % sur une RTX 4090, et les boucles tombent de 96 % à 20 %

Avec les réglages d'évaluation des auteurs, le fichier modifié a arrêté la plupart de ses boucles sur notre matériel et a eu presque huit fois plus de bonnes réponses.

Les deux modèles ont tourné côte à côte sur une seule RTX 4090 de 24 GB de notre cloud, chacun derrière son propre endpoint d'API. Les deux utilisaient vLLM, le moteur de service open source utilisé par la réexécution d'akhaliq, avec le brouillon de réflexion activé et les réglages d'aléatoire des auteurs.

Les questions étaient les 50 premiers problèmes de MATH-500 dans l'ordre de la réexécution d'akhaliq, un essai chacun, jusqu'à 32 768 tokens par réponse. Les 50 tournaient en même temps pour chaque modèle, et les deux modèles en même temps. Nous les avons notées avec le propre script de notation des auteurs.

Nos 62 % sont au-dessus des deux chiffres publiés. C'est la petite taille de l'échantillon qui parle : sur ces 50 problèmes, la réexécution d'akhaliq faisait 54 % en moyenne, et nos réponses concordaient avec son résultat habituel sur 42 des 50. Les 8 % et 96 % du modèle de base tombent pile sur les chiffres des auteurs.

Les deux fois où le modèle de base a terminé une réponse, elle était juste. Ses 2 autres bonnes réponses venaient de boucles qui avaient écrit le bon nombre avant que la limite les coupe.

L'économie : 1,02 million de tokens au lieu de 1,59 million pour les mêmes 50 problèmes

Sur les mêmes 50 problèmes, le modèle modifié a fait en moyenne 20 444 tokens par réponse et le modèle de base 31 832, et 20 % des réponses modifiées ont été coupées à la limite contre 96 %. Par bonne réponse : environ 5 minutes de temps de batch contre 32 secondes (398 000 tokens contre 33 000). Cet écart repose sur seulement 4 bonnes réponses du modèle de base, donc prenez-le comme un ordre de grandeur.

Un GPU sert un nombre fixe de réponses à la fois. Avec le modèle de base, presque chacune de ces places restait coincée dans une boucle, jusqu'à 12,6 minutes sur la question des diviseurs. Le modèle modifié écrit toujours de longues réponses, mais la plupart se terminent avec un résultat.

Pourquoi ne pas simplement baisser la limite, ou surveiller le flux et arrêter une boucle, comme le suggère la page de Qwen ? Cela fait échouer une boucle plus tôt et économise du temps de carte. Nous ne l'avons pas essayé, pas plus que la réflexion désactivée, sur le modèle de base, donc testez cela avant de changer de fichier.

Là où ça s'arrête : ça supprime les boucles, ça n'ajoute pas de compétence

La modification a corrigé une mauvaise habitude. Elle n'a pas rendu le modèle plus intelligent, et les auteurs le disent eux-mêmes.

Ils ont essayé la même approche sur Gemma 3 270M, un modèle qui boucle rarement : seulement 8,5 % de ses réponses atteignent la limite. Astra n'a pas réussi à l'améliorer. Il est resté entre 6,8 % et 7,7 % sur MATH-500 quel que soit le budget. Dans leurs mots : "Editing weights could remove an obstacle that hid an ability, but it could not add an ability the model lacked." N'attendez donc pas que cela marche sur un modèle dont le problème n'est pas les boucles.

Même modifié, un cinquième de nos réponses bouclait encore, et 3 autres se sont terminées sans réponse finale. Les réponses sont longues, donc une seule réponse prend environ une minute à elle seule. Et le bond n'est venu qu'avec le plus gros budget : avec 10 ou 25 exécutions, les modifications d'Astra laissaient le modèle à 12,3 % et 14,1 %.

La vidéo d'AI Search met aussi en garde contre l'emballement, et mentionne une analyse qui aurait amené le modèle non modifié à environ 44 % sur MATH-500 rien qu'en changeant les réglages. La vidéo ne cite aucune source, et nous ne l'avons pas vérifié.

Nous n'avons testé que les maths avec la réflexion activée. Nous n'avons pas vérifié la conversation générale, le suivi d'instructions, la réflexion désactivée ni les images sur le fichier modifié. La page de Qwen indique que le modèle 0.8B tourne par défaut avec la réflexion désactivée.

Quel GPU : le modèle modifié a terminé sous un plafond mémoire émulé de 6 GB

Cette vérification montre que le modèle démarre et termine de longues réponses sous chaque plafond. Nous avons utilisé cinq problèmes qu'il avait déjà résolus dans le batch, et il a donné les mêmes cinq bonnes réponses sous 6 GB que sous 8 GB, dans le même temps. À 5 GB, il n'est passé qu'après avoir réduit de 256 à 32 la place réservée aux conversations en parallèle. À 4 GB, il n'a pas démarré.

Chaque plafond sous 24 GB était une limite que nous avons fixée sur la 4090. Nous n'avons pas fait tourner de vraie carte de 6 ou 8 GB. Une vraie petite carte a aussi une mémoire plus lente, donc attendez-vous à ce qu'elle soit plus lente que ceci. Nous n'avons pas essayé le plafond de 4 GB avec une limite de réponse plus courte, ni une version compressée du modèle.

Sur InferenceKey : la base et son jumeau modifié sur une carte de 24 GB, prêts en 7 minutes

Une seule carte de 24 GB a accueilli la base et son jumeau modifié en même temps, chacun avec un peu moins de la moitié de la carte, avec 16,9 GiB utilisés au pic. Les deux étaient prêts 418 secondes après que nous les avons demandés, depuis une machine froide. Environ trois minutes sont parties dans l'installation de vLLM, et environ trois de plus dans le préchauffage du moteur lui-même. Une fois cette installation présente sur la machine, un nouveau moteur était prêt en environ une minute.

Notre API ne permet pas encore de changer certains réglages par requête, comme l'interrupteur de réflexion, donc nous les avons fixés sur le serveur pour tous les appelants.

Un problème que vous rencontrerez : une réponse du modèle de base diffusée en streaming à travers l'endpoint s'est arrêtée au bout de 152 secondes, sans erreur visible par notre client et sans marqueur de fin. Pour un client, une réponse coupée ressemble à une réponse terminée. Nous soupçonnons le délai de silence de deux minutes de la plateforme, qui enverrait une erreur que notre script d'exemple ignore, mais la cause n'est pas confirmée. D'ici là, vérifiez que chaque réponse en streaming indique qu'elle s'est bien terminée avant de vous y fier.

Faut-il l'utiliser ? Essayez-le si vous servez Qwen3.5-0.8B avec la réflexion activée

• Si vous servez déjà Qwen3.5-0.8B avec la réflexion activée et lui envoyez des maths : essayez le remplacement. Même taille, même licence, et il tourne sur le même moteur.
• Si vous voulez les meilleures maths d'un tout petit modèle : voyez-le comme une correction, pas comme une amélioration. Il fait ressortir ce que le modèle savait déjà, et il écrit toujours de longues réponses.
• Si vous dimensionnez un GPU : le résultat à 6 GB a été émulé sur une carte de 24 GB, pas sur une vraie carte de 6 GB ; voir la section sur la mémoire.
• Si vous faites tourner un autre petit modèle qui boucle : c'est une méthode publiée avec ses logs, pas un produit. Le résultat sur Gemma dit qu'elle n'aide que quand les boucles sont le problème.

Pour faire la même comparaison sur votre propre machine GPU, utilisez l'exemple du SDK pour la modification des poids de Qwen3.5-0.8B avec IK_WITH_BASELINE=1. Il lui faut une machine NVIDIA enregistrée (un worker) avec une carte de 24 GB et environ 15 GB de disque libre. Les clés d'accès et la build locale du SDK sont dans le pas à pas ci-dessous. Il supprime les deux workloads quand il a terminé.

vllm serve <model> --dtype bfloat16 --max-model-len 34816 \
  --gpu-memory-utilization 0.45 \
  --default-chat-template-kwargs '{"enable_thinking": true}' \
  --override-generation-config '{"temperature": 0.6, "top_p": 0.95, "top_k": 20, "presence_penalty": 1.5}'