La fiche de Nanbeige4.3-33B donne envie de lancer des tests. Le modèle texte dense, disponible et indiqué comme sous licence Apache-2.0, compte 33 milliards de paramètres. Son développeur annonce 80,9 contre 73,0 pour Qwen3.8-27B sur Terminal-Bench 2.1, et 65,5 contre 42,5 sur DeepSWE. Voilà une raison de l’évaluer, pas de remplacer immédiatement le modèle d’un agent en production. [1]

Le même tableau donne pourtant une petite avance à Qwen sur SWE-Bench Pro : 61,7 contre 60,3. Les tâches changent, le résultat aussi. Ces chiffres viennent du développeur ; je ne les ai ni mesurés ni vus reproduits indépendamment. La fiche indique que les paramètres d’inférence et le harnais sont identiques pour les modèles comparés au sein de chaque benchmark, mais que les benchmarks utilisent des harnais différents. Le Qwen3.8-27B de la comparaison n’est pas forcément votre modèle actuel. [1]

Les poids ne font pas tout l’agent

Pour les échanges avec outils sur plusieurs tours, la fiche recommande preserve_thinking=true, afin de conserver les raisonnements précédents. Elle privilégie le format XML pour les appels d’outils, tout en proposant JSON pour la compatibilité. Elle annonce jusqu’à 512K de contexte. Rien de cela ne prouve qu’un serveur donné sait interpréter ces appels avec une quantification donnée, ni que ce contexte soit utilisable dans un budget raisonnable de mémoire et de latence. Les poids, le gabarit de conversation, le parseur et le harnais forment ensemble le système réel. [1]

Beaucoup utiliseront un dérivé GGUF plutôt que les poids BF16 d’origine. AtomicChat en publie plusieurs, dont AD-Q4_K_M à 21,2 Go et Q8_0 à 35,2 Go selon sa fiche. Il s’agit de tailles de fichiers, pas de l’empreinte mémoire totale à l’exécution : cache KV, longueur du contexte et requêtes simultanées comptent aussi. Le producteur explique avoir retiré son ancien Q4_K_M simple après de meilleurs résultats pour ses variantes imatrix. Recommander encore précisément ce fichier dans ce dépôt, c’est ignorer l’état actuel du dépôt. [2]

La fidélité du prochain token ne garantit pas la tâche

Le producteur des quantifications compare, sur son propre banc multilingue, le prochain token prédit par chaque variante à celui de BF16. Il indique 89,9 % d’accord sur le token le plus probable (top-1) pour l’ancien Q4_K_M, 92,6 % pour AD-Q4_K_M et 98,0 % pour Q8_0. Sa fiche décrit le banc et renvoie aux journaux bruts. Ce sont des diagnostics de quantification publiés par leur auteur, pas des taux de réussite d’agents. Le 92,6 % ne signifie ni que 92,6 % des tâches réussissent, ni que le score de code original survit intact à la conversion. [2]

Un token différent peut changer un nom d’outil, un argument ou un séparateur ; il peut aussi ne rien changer au résultat. Le tableau de benchmarks du modèle initial et le tableau de fidélité des dérivés ne mesurent pas la même chose. Les fusionner mentalement en un classement d’agents serait une erreur de catégorie. [1][2]

Le test que je ferais

Je choisirais des tâches fixes et inoffensives : modifier un dépôt avec des tests, effectuer une recherche en plusieurs étapes avec vérification des sources, et appeler des outils avec des arguments difficiles à échapper. Tâches, outils, évaluateur et budget de relances doivent rester identiques entre configurations. Il faut consigner fichiers exacts, empreintes cryptographiques, gabarit, versions du serveur et du parseur, budget de contexte et température. On note l’état final observé, pas le résumé confiant du modèle.

Je publierais séparément la réussite au premier essai et après relances, avec latence, pic mémoire et échecs de format d’appel d’outil. Je vérifierais aussi que l’outil a réellement été appelé et que son résultat est revenu au modèle. Une promesse de long contexte doit être testée à la longueur annoncée, non après réduction silencieuse jusqu’au démarrage. Ce protocole reste une proposition : je n’ai pas testé Nanbeige et ne prétends à aucune mesure locale de vitesse ou de réussite.

L’assistance de sécurité légitime et la franchise factuelle doivent être évaluées séparément du refus des demandes nuisibles. Refuser moins n’est pas être plus compétent en sécurité autorisée. Ni les scores de code, ni la fidélité des tokens ne mesurent cela. [1][2]

Mon verdict : candidat, pas remplaçant. La disponibilité des poids et l’indication de licence permettent une expérience ; les résultats du développeur lui donnent de l’intérêt. Les mesures du dérivé aident à sélectionner des fichiers à tester, pas à désigner un gagnant pour la production. Pour affirmer qu’une version quantifiée dépasse un agent existant, il faut fournir le fichier, le gabarit, le parseur, les traces brutes et la référence comparée. Sinon, ce n’est qu’une hypothèse intéressante.

Sources

[1] https://huggingface.co/Nanbeige/Nanbeige4.3-33B [2] https://huggingface.co/AtomicChat/Nanbeige4.3-33B-GGUF