Si on voyait ça comme un match de boxe, l’issue aurait dû être évidente.
Dans un coin : BitNet-100B, le mastodonte de l’IA edge. Un modèle de 100 milliards de paramètres tournant localement sur CPU, porté par des idées vraiment intéressantes sur l’inférence native bas-bit.
Dans l’autre : Qwen3.5-9B q4, le concurrent plus petit et plus nerveux. Plus svelte, plus léger, quantifié en 4-bit, et sur le papier, pas celui qui devrait frapper le plus fort.
Si vous raisonnez comme une bonne partie de l’industrie actuellement, votre instinct vous dirait probablement que le plus gros modèle gagne ça les doigts dans le nez.
Ce n’est pas ce que j’ai vu.
J’ai lancé une évaluation de code en deux rounds comparant BitNet-100B et Qwen3.5-9B q4 sur un utilitaire Python simple : scanner un répertoire récursivement, hasher les fichiers par morceaux, grouper les doublons par SHA-256, ignorer les liens symboliques, sauter les fichiers illisibles et n’afficher que les groupes de doublons.
Le round 1 était l’implémentation initiale.
Le round 2 était une passe de révision basée sur des retours de QA cordiaux.
Ce qui fait en partie l’intérêt de BitNet, c’est que c’est bien plus qu’un « gros modèle sur CPU ». Microsoft présente BitNet b1.58 2B4T comme un grand modèle de langage conçu dès le départ pour le 1 bit et entraîné sur 4 000 milliards de tokens. Son dépôt d’inférence officiel met en avant l’exécution d’un modèle BitNet b1.58 à 100 milliards de paramètres sur un seul processeur. Il y a là une vraie innovation d’architecture, bien au-delà de la compression en force.
Les modes de défaillance
Ce qui a frappé, c’est le mode de défaillance.
BitNet-100B était poli et coopératif. Il acceptait bien les retours, adoptait la structure suggérée et semblait réactif au premier coup d’œil. Mais le code restait structurellement bancal : formes de données erronées, logique d’itération cassée, groupement incomplet et un code qui ne satisfaisait toujours pas les specs après révision. Il a mieux absorbé le vocabulaire de la tâche que sa mécanique.
Qwen3.5-9B q4 s’est comporté très différemment. Il était beaucoup plus concentré sur le boulot lui-même. Son premier passage était déjà nettement plus cohérent, et sa révision ressemblait à ce qu’on attend d’un ingénieur junior correct : préserver la structure qui marche, corriger les points faibles et avancer.
La différence de runtime
Une nuance : ce n’était pas un setup de runtime parfaitement comparable. Qwen tournait dans un harnais GPU llama.cpp custom utilisant le package neural-llama que Sam et moi avons construit, tandis que BitNet tournait sur le fork llama.cpp de BitNet sur CPU. Runtimes différents, fournisseurs différents, surfaces d’optimisation différentes.
Cela dit, les résultats concrets comptent toujours. Dans l’environnement testé, Qwen a produit un code substantiellement meilleur et l’a révisé plus efficacement, alors que BitNet restait structurellement faible.
Le point important, c’est que la performance en code ne vient pas du seul nombre de paramètres. Elle émerge de toute la pile : architecture, mix d’entraînement, post-entraînement, choix de quantification, et la qualité du runtime et du harnais qui servent réellement le modèle.
BitNet-100B reste fascinant comme jalon système. Mais dans cette évaluation de code, Qwen3.5-9B q4 a été le meilleur programmeur, et de loin.