Nanbeige4.3-33B : 33B dense, contexte 512K, poids sous Apache 2.0, des benchmarks maison en conflit avec les fiches officielles
Selon MarkTechPost, le 25 octobre 2026, Nanbeige LLM Lab (présenté comme rattaché à la plateforme de recrutement BOSS Zhipin) a publié sur Hugging Face, sous licence Apache 2.0, le modèle dense Nanbeige4.3-33B ainsi qu'une version Base destinée au post-entraînement personnalisé, avec un contexte de 524 288 tokens ; le tableau maison annonce une avance sur 17 des 20 benchmarks, mais certaines valeurs de concurrents diffèrent de leurs fiches officielles.
Ce qui change
Selon l'article du journaliste Asif Razzaq publié par MarkTechPost le 25 octobre 2026, Nanbeige LLM Lab (décrit comme rattaché à la plateforme de recrutement BOSS Zhipin) a publié sur Hugging Face, sous licence Apache 2.0, Nanbeige4.3-33B, accompagné de Nanbeige4.3-33B-Base destiné au post-entraînement personnalisé. L'article indique qu'il s'agit d'un modèle de langage dense de 33B (et non MoE), dont le config.json cité déclare l'architecture standard LlamaForCausalLM : 52 couches, dimension cachée de 7 168, 56 têtes de requête et 8 têtes clé-valeur (attention par requêtes groupées), dimension intermédiaire FFN de 22 016, vocabulaire de 166 912 tokens, RoPE theta de 120 000 000, jusqu'à 524 288 positions (contexte 512K), modalité d'entrée texte uniquement ; l'article mentionne aussi qu'une version quantifiée communautaire figure sur la fiche du modèle. Il indique que le template de chat expose trois contrôles : enable_thinking (activé par défaut), preserve_thinking et tools, et que Nanbeige recommande d'activer preserve_thinking pour l'usage d'outils multi-tours et les agents de code, le format XML étant recommandé pour les appels d'outils. Le laboratoire positionne Nanbeige4.3-33B comme modèle « enseignant » de la série, avec un projet de distillation des capacités d'agent vers des modèles plus petits, à commencer par Nanbeige4.3-3B. Côté benchmarks, selon l'article, dans le tableau comparatif de Nanbeige le modèle devance Qwen3.8-27B, Muse-Glimmer-30B et Gemma4-31B sur 17 des 20 épreuves : Terminal-Bench 2.1 à 80,9 (contre 73,0 pour Qwen3.8-27B) et DeepSWE à 65,5 contre 42,5 ; Terminal-Bench 4.0 à 23,8 (le score le plus bas du modèle selon l'article) ; SWE-Bench Pro à 60,3, derrière les 61,7 de Qwen3.8-27B. L'article souligne que plusieurs valeurs de concurrents du tableau Nanbeige contredisent les fiches officielles : Meta rapporte Muse-Glimmer-30B à 51,2 sur SWE-Bench Pro et Gemma4-31B à 36,9, alors que Nanbeige affiche l'inverse ; Google indique 84,3 pour Gemma 4 31B sur GPQA Diamond, là où le tableau Nanbeige affiche 91,3 ; Meta rapporte 51,7 pour Muse-Glimmer-30B sur Terminal-Bench 2.1, Nanbeige mesurant 61,8. L'article estime que des harnais de test différents peuvent expliquer une partie des écarts, mais que la paire SWE-Bench Pro semble inversée, et que ces lignes doivent être considérées comme provisoires jusqu'à une reproduction indépendante. Côté déploiement, la fiche fournirait des recettes Transformers, SGLang et vLLM, l'exemple serveur utilisant un parallélisme tensoriel sur 4 voies avec les parseurs d'inférence et d'appel d'outils de Qwen3 ; d'après le config.json, l'article estime environ 66 Go pour les poids en BF16, un cache KV d'environ 208 Kio par token en BF16 et environ 112 Go pour une séquence complète de 524 288 tokens ; à la date de l'article, aucun fournisseur d'inférence Hugging Face n'hébergerait le modèle. Ces benchmarks sont des chiffres auto-déclarés par le fabricant ou relayés par le média, et les chiffres de poids et de cache KV sont des estimations de l'article, non des informations officielles ; notre rédaction n'a réalisé aucun test ni vérifié de façon indépendante les fichiers de configuration et de licence du dépôt du modèle.
Conséquences pour les développeurs
La contrainte la plus directe pour les développeurs concerne la forme du déploiement. La recette officielle décrite repose sur un serveur multi-GPU en parallélisme tensoriel sur 4 voies, et non sur une station mono-GPU ; l'article avance en outre une estimation d'environ 66 Go pour les poids en BF16, ce qui implique un environnement multi-cartes ou multi-machines pour faire tourner le service, même sans quantification : dans un plan d'évaluation, la question matérielle se pose donc avant celle de la qualité du modèle. Cette partie relève d'une analyse conditionnelle : la consommation mémoire réelle varie selon le framework d'inférence, la taille de lot et la concurrence, et doit être mesurée sur sa propre machine. Deuxième point, le coût réel du contexte long. L'article estime un cache KV d'environ 208 Kio par token en BF16 et environ 112 Go pour une séquence complète de 524 288 tokens, du même ordre que les poids eux-mêmes. Le 512K ressemble donc davantage à une capacité à activer à la demande qu'à une configuration par défaut : si les requêtes longues sont rares, abaisser la limite de contexte change nettement le budget mémoire et la concurrence ; si l'on veut réellement exploiter toute la longueur, le cache KV devient le principal poste de coût, que la quantification des poids ne résout pas directement et qui exige une quantification KV ou une stratégie de pagination distincte. Troisième point, l'intégration et l'adaptation au framework. L'article indique que le format XML est recommandé pour les appels d'outils et que l'exemple serveur s'appuie sur les parseurs d'inférence et d'appel d'outils de Qwen3. Pour les équipes ayant bâti leur boucle d'agent sur un protocole d'appel de fonctions de style OpenAI, cela implique généralement de modifier la couche de parsing et le template de prompt, et pas seulement l'adresse d'accès. Le enable_thinking activé par défaut et preserve_thinking, qui conserve le raisonnement des tours précédents, modifient aussi la composition en tokens de chaque requête et le coût multi-tours ; si le framework tronque ou réordonne l'historique, il faut d'abord vérifier le comportement réel de ces contrôles. Quatrième point, la méthode d'évaluation. Le tableau auto-déclaré de Nanbeige entre en conflit avec les fiches officielles de Meta et Google sur plusieurs lignes, dont une ligne SWE-Bench Pro probablement inversée : aucune conclusion transversale du type « meilleur de tant qu'un modèle proche de 30B » ne tient donc avant reproduction indépendante. On peut en revanche retenir une information structurelle interne au même tableau : l'avance auto-déclarée sur Terminal-Bench 2.1 contraste avec un score absolu de seulement 23,8 sur Terminal-Bench 4.0, ce qui suggère une forte sensibilité des capacités à la tâche et au harnais de test ; le choix devrait se fonder sur une reproduction sur ses propres tâches. Cinquième point, modalité et licence. Le modèle est à entrée texte uniquement : il ne traite pas directement captures d'écran, graphiques ou vidéos et ne remplace donc pas les modèles requis pour les flux visuels. Côté licence, il faut distinguer poids ouverts et conditions de licence : l'article indique une publication sous Apache 2.0, plus permissive qu'une simple ouverture de poids, mais c'est le fichier de licence joint au dépôt qui fait foi, et la seule possibilité de télécharger les poids ne permet pas d'en déduire les conditions d'usage commercial et de redistribution. Selon le catalogue KimiSeek actuel, Nanbeige4.3-33B et Nanbeige4.3-33B-Base ne figurent pas parmi les modèles référencés ; la distribution évoquée dans l'article renvoie au téléchargement des poids sur Hugging Face, et, s'il s'agit d'une API hébergée, aux canaux propres du fabricant.
Intégration et évaluation
Ce qui suit relève de recommandations ou d'analyses conditionnelles, et non de conclusions factuelles de l'article. Décision 1 (choix de la pile d'inférence) : la fiche fournirait à la fois des recettes SGLang et vLLM, l'exemple serveur utilisant un parallélisme tensoriel sur 4 voies et les parseurs d'inférence et d'appel d'outils de Qwen3. Il s'agit de choisir entre maintenir une seule pile ou deux en parallèle. La condition est la dépendance aux appels d'outils : si le flux d'agent exige un parsing stable des appels de fonctions, le couplage aux parseurs décrit implique qu'un changement de pile peut modifier le comportement de parsing, et c'est alors seulement que le coût de deux piles se justifie ; pour de l'inférence texte pure, une seule pile est plus économique. Critère mesurable : préparer 20 à 50 tâches avec appels d'outils et compter, sur chaque pile, le taux d'erreurs de format et les échecs de parsing ; si l'écart reste acceptable, converger vers une seule pile. Décision 2 (limite de contexte et budget mémoire) : l'article estime environ 66 Go de poids en BF16, environ 208 Kio de cache KV par token et environ 112 Go pour une séquence complète. Il s'agit de fixer la longueur maximale de contexte et la limite de concurrence du service. La condition dépend de la distribution réelle des contextes : si l'immense majorité des requêtes tient sous 32K, plafonner bien en dessous de 512K libère beaucoup de mémoire pour la concurrence, en réservant le 512K à quelques tâches longues. Critère mesurable : relever les quantiles de longueur de contexte des requêtes de production ou de charge, puis mesurer le pic mémoire et la latence P95 du premier token sous la limite choisie, en vérifiant que les deux restent dans la marge matérielle ; sinon, abaisser la limite ou passer à la version quantifiée communautaire (une est mentionnée sur la fiche, dont l'impact sur la qualité reste à mesurer soi-même). Décision 3 (priorité et ordre des évaluations) : l'article signale des conflits entre le tableau auto-déclaré et les fiches officielles sur SWE-Bench Pro, GPQA Diamond, Terminal-Bench 2.1 notamment, avec une ligne SWE-Bench Pro probablement inversée. Il s'agit de choisir entre continuer à débattre des classements publics ou consacrer le budget à une reproduction sur ses propres tâches. La condition est le lien entre votre charge de travail et le codage agentique ou la collaboration bureautique : si le lien est fort, vos dépôts et vos tâches réelles valent plus que les classements. Critère mesurable : avec le même script d'évaluation, mesurer sur votre jeu de tâches un taux de réussite ou d'exécution et le comparer, dans ce même script, à une référence de taille similaire ; seuls les écarts obtenus dans un même harnais de test sont exploitables pour le choix. Décision 4 (composition en tokens des agents multi-tours) : enable_thinking est activé par défaut, preserve_thinking conserve le raisonnement des tours précédents, et l'usage est recommandé pour les outils multi-tours et les agents de code. Il s'agit de choisir entre conserver le raisonnement par défaut ou le tronquer tour par tour. La condition est le nombre de tours : plus il augmente, plus la conservation du raisonnement amplifie le contexte et le coût. Critère mesurable : sur un même lot de tâches multi-tours, comparer les deux réglages en taux de réussite, consommation totale de tokens et latence du premier token ; ne retenir la troncature pour maîtriser les coûts que si la réussite ne baisse pas nettement.
Limites et points à confirmer
À préciser : selon le catalogue KimiSeek actuel, Nanbeige4.3-33B et Nanbeige4.3-33B-Base n'apparaissent pas dans la liste des modèles référencés ; cette version n'est pas proposée sur KimiSeek, et la distribution et la disponibilité évoquées dans l'article renvoient au téléchargement des poids sur Hugging Face, ou, pour une API hébergée, aux canaux propres du fabricant. L'article confirme seulement qu'aucun fournisseur d'inférence Hugging Face n'hébergeait le modèle à sa date de publication, sans affirmer qu'aucun autre canal d'hébergement ne le propose : la disponibilité ailleurs doit être vérifiée séparément ; notre rédaction n'a pas contrôlé de façon indépendante le dépôt du modèle, ses fichiers de configuration ou le fichier de licence joint. Les paramètres d'architecture, les contrôles et la description de licence rapportés ici proviennent de la retranscription par l'article de la fiche du modèle et du config.json. Tous les scores de benchmark sont auto-déclarés par Nanbeige ou relayés par le média, sans reproduction indépendante à ce jour, et l'article lui-même signale des conflits entre plusieurs valeurs de concurrents et les fiches officielles de Meta et Google, dont une ligne SWE-Bench Pro probablement inversée : ces lignes doivent être tenues pour provisoires avant reproduction indépendante. Les estimations d'environ 66 Go de poids, d'environ 208 Kio de cache KV par token, d'environ 112 Go de cache KV pour une séquence complète et le parallélisme tensoriel sur 4 voies sont des calculs de l'article à partir du config.json ou des reprises de la fiche du modèle, et non des informations officielles ni des mesures de notre rédaction ; la consommation mémoire réelle dépend du framework d'inférence, de la taille de lot, de la concurrence et de la distribution des contextes, et doit être mesurée sur votre propre matériel. Apache 2.0 est la licence telle que rapportée par l'article ; la possibilité de télécharger les poids ne vaut pas conditions de licence, et les modalités d'usage commercial et de redistribution doivent se fonder sur le fichier de licence joint au dépôt du modèle. Le format XML recommandé pour les appels d'outils, l'association aux parseurs Qwen3, l'activation par défaut de enable_thinking et les autres comportements proviennent de la description de la fiche et du template de chat par l'article, et peuvent évoluer avec les versions. Le projet de distillation de Nanbeige4.3-3B est une annonce du fabricant, sans poids ni données de capacités publics à ce jour, et ne doit pas être considéré comme une capacité livrée.