AesCode 32B vs North Mini Code : Le fichier de poids n'est pas l'engagement

Ces deux modèles sont sous Apache 2.0, tous deux téléchargeables, et tous deux conçus pour une tâche étroite — et c’est là que la ressemblance cesse d’être utile. AesCode 32B est le checkpoint de recherche de Microsoft pour générer du HTML et du CSS éditables : diapositives, affiches, tableaux de bord et rapports. Son dépôt Hugging Face a été créé le 29 septembre 2026 et le commit intitulé « Release AesCode-32B » a été intégré le 7 octobre 2026 ; Microsoft n’a publié aucune annonce, et la fiche du modèle ne comporte pas la moindre date de sortie. North Mini Code est le modèle de codage agentique à poids ouverts de Cohere, un mélange d’experts de 30B avec 3B de paramètres actifs, publié en juin 2026, destiné à l’ingénierie logicielle et au travail en terminal. La façon évidente de les comparer est de s’appuyer sur les benchmarks, et cela ne fonctionne pas, parce que les deux n’ont jamais été mesurés sur la même tâche et un seul d’entre eux a été mesuré par quelqu’un extérieur à son propre laboratoire. La comparaison qui fonctionne — celle qui détermine si vous pouvez réellement exécuter l’un ou l’autre — est le fichier de poids.

Deux points de contrôle, deux factures différentes

C'est la dimension que la plupart des comparaisons négligent, et pour deux modèles auto-hébergés, c'est l'axe qui compte le plus.

• Paramètres — AesCode 32B : 33B, dense. North Mini Code : 30B au total, 3B actifs, mélange d'experts.

• Mémoire nécessaire à l’exécution — AesCode 32B : la fiche conseille de prévoir environ 65 Go de mémoire d’accélérateur pour les seuls paramètres bf16. North Mini Code : quantifié, environ 20–24 Go suffisent, et les déploiements de référence incluent un Mac Studio.

• Forme de service — AesCode 32B : un modèle vision-langage, donc le chemin de service transporte des images ainsi que du texte, et son propre exemple utilise un parallélisme tensoriel à quatre voies. North Mini Code : texte en entrée, texte en sortie ; les benchmarks ont utilisé un seul outil de terminal.

• Licence — les deux sous Apache 2.0, poids inclus. Cette ligne est à égalité et ne constitue pas le facteur différenciant que les gens imaginent.

• Contexte — AesCode 32B : 24 576 jetons dans la configuration rapportée, avec des invites et des réponses au moment de l’entraînement plafonnées à 8 192. North Mini Code : 256 K en entrée, 64 K en sortie.

• Ce qu'il émet — AesCode 32B : un document HTML complet, les tableaux sous forme de tableaux HTML et les graphiques sous forme de spécifications ECharts. North Mini Code : le texte ou l'appel d'outil que le harnais a demandé.

• Évaluation indépendante — AesCode 32B : aucune publiée ; tous les chiffres proviennent de Microsoft. North Mini Code : évalué sur Artificial Analysis, qui a également signalé sa verbosité.

Lisez la deuxième ligne deux fois. Un modèle vision-langage dense de 32B qui réclame 65 Go et un parallélisme à quatre voies constitue une décision d'achat différente de celle d'un MoE à 3B de paramètres actifs qui, une fois quantifié, tient dans une station de travail. Si votre raison d'envisager des poids ouverts était « nous voulons cela sur notre propre matériel », cette ligne représente l'essentiel de la réponse avant même d'exécuter un seul prompt.

La licence n'est pas la raison de choisir l'un ou l'autre.

Presque toutes les comparaisons de modèles à poids ouverts commencent par la question des licences, et ici c’est un cul-de-sac : les deux sont sous Apache 2.0, les deux fournissent les poids complets, et aucun ne comporte de restriction d’utilisation qui empêcherait un déploiement commercial. Il n’y a pas de clause de partage de données à mettre en balance avec une réduction, pas de palier de contributeur, pas d’exception de domaine d’utilisation. Quel que soit le critère sur lequel vous choisissez entre ces deux-là, ce n’est pas une question d’autorisation.

Ce qui reste une fois la question des licences écartée, c’est ce pour quoi le modèle a été entraîné — et ces deux-là ont été entraînés dans des directions opposées.

L'un a été entraîné sur un terminal, l'autre sur un canevas.

La fiche modèle de North Mini Code annonce clairement sa cible : la génération de code, l’ingénierie logicielle agentique et les tâches en terminal. Cohere l’a entraîné sur plusieurs harnais d’agents — SWE-Agent, mini-SWE-Agent, OpenCode, Terminus 2 — précisément pour qu’il fonctionne dans celui que vous utilisez déjà, et l’a évalué sur SWE-Bench Verified, SWE-Bench Pro, Terminal-Bench v2 et Terminal-Bench Hard. Sa faiblesse publiée est bien réelle et a été découverte par un évaluateur externe plutôt que révélée volontairement par le fournisseur : il émet environ trois fois plus de tokens de sortie que la médiane de sa classe de taille. Les modèles verbeux écrivent de longues trajectoires d’agent, et les longues trajectoires sont ce que vous payez une fois la tarification promotionnelle terminée.

AesCode 32B a été entraîné sur quelque chose de totalement différent, et la fiche indique de façon inhabituellement claire que la cible est l'artefact. Tout l'intérêt de cette conception est qu'un modèle de code ne peut pas voir comment la mise en page, la hiérarchie et la couleur s'articulent sur un canevas ; c'est pourquoi AesCode utilise une image générée à partir du même prompt comme référence esthétique, tout en conservant le prompt comme source de vérité pour le contenu. La supervision est un « graphe de conception » composé de nœuds et d'arêtes, avec sept canaux de récompense — exécution, texte, frontières, tableau/graphique, mise en page, espaces blancs, design — dont six vérificateurs déterministes et un juge vision-langage travaillant à partir d'une grille d'évaluation propre à chaque échantillon. Les candidats sont rendus dans un navigateur Playwright isolé, avec les requêtes externes bloquées, et évalués à partir du DOM, des styles calculés, des cadres englobants et d'une capture d'écran.

Ce mécanisme existe pour rendre une chose vraie : la sortie est une page rendue qu’un humain ouvrira et modifiera, et non un patch appliqué à un dépôt. AesCode 32B n’a jamais été entraîné à utiliser un shell, et rien dans la conception des récompenses ne le récompenserait s’il essayait.

L’asymétrie des preuves, énoncée honnêtement

North Mini Code a été exécuté par un tiers. Artificial Analysis lui attribue un score de 33,4 sur son Coding Index et de 27,6 sur son Intelligence Index, et publie le constat sur la verbosité. Le chiffre phare de Cohere lui-même — 61,0 % pass@1 sur SWE-Bench Verified — est rapporté par le fournisseur, mais vérifiable sur un modèle que n’importe qui peut télécharger, et la fiche est franche au sujet de ses choix de harnais, allant jusqu’à noter que pour Terminal-Bench Hard, elle a suivi la méthodologie propre à Artificial Analysis afin de préserver l’équité de la comparaison.

AesCode 32B n'a pas d'équivalent. Son évaluation infographique sur 300 échantillons, trois générations par prompt sans sélection, produit un score global de 85,89 contre 81,28 pour GPT-5.5 et 80,39 pour Claude Opus 4.8 — toutes mesurées à l'intérieur du harnais de Microsoft, sur les échantillons de Microsoft, avec les canaux de notation sur lesquels Microsoft a entraîné le modèle. Il y a une réelle possibilité que les chiffres soient équitables ; la conception est plus transparente que la plupart des tableaux de fournisseurs, la pile de vérification et le générateur de grilles d'évaluation sont open source, et la fiche rend public le fait qu'aucun modèle de la comparaison ne franchit la barre des 60 sur sa dimension de style. Mais aucun laboratoire externe n'en a reproduit quoi que ce soit, et il n'existe aucun référencement dans une arène, aucune position dans un classement et aucun test de débit indépendant. Si un benchmark de fournisseur qui se trouve favoriser le propre benchmark du fournisseur — une tâche d'infographie — pèse lourd dans votre décision, on vous demande d'adopter la seule lecture disponible.

Remarquez ce que cela signifie spécifiquement pour cette confrontation : il n’existe aucun nombre commun. Aucun. Un modèle est évalué sur la réussite de tâches d’ingénierie logicielle, l’autre sur la lisibilité du texte et le fait que la mise en page ne déborde pas du canevas. Toute page qui place 33,4 à côté de 85,89 compare un Coding Index à un score global d’infographie, et aucun des deux modèles ne sait sur quoi l’autre a été testé.

Ni l’un ni l’autre n’est un modèle polyvalent, et c’est là le véritable coût.

Voici le piège dans les deux moitiés de cette comparaison. Adopter l'un ou l'autre modèle signifie maintenir une voie de service auto-hébergée pour un spécialiste : 65 GB de VRAM et une pile multimodale pour celui qui effectue le rendu des pages ; un emplacement pour un MoE à 3B de paramètres actifs pour celui qui gère les tâches de terminal. Les deux sont bons dans leur domaine et aucun ne peut faire le travail de l'autre, ce qui signifie qu'une équipe qui veut les deux capacités fait désormais tourner deux déploiements d'inférence — et pour tout ce qui se trouve entre les deux, le modèle qui n'est ni un moteur de rendu de pages ni un agent de terminal, elle en fait tourner un troisième.

C'est le cas où une couche de routage mérite sa place plutôt que d'être ajoutée après coup. Une clé pour plus de 200 modèles au prix catalogue des fournisseurs, sans marge, signifie que le travail spécialisé reste sur votre propre matériel, là où l'économie et le traitement des données ont du sens, et que le travail de routine va au modèle hébergé qui est le meilleur pour cela cette semaine-là. La famille de socles Qwen3-VL illustre bien à quel point la frontière est mince : Microsoft a construit AesCode 32B sur Qwen3-VL-32B-Instruct, et les membres vision-langage de cette famille sont appelables sur le catalogue OrcaRouter — Qwen3-VL 235B A22B Instruct à 0,40 $ par million de tokens en entrée et 1,60 $ en sortie, ou le plus petit Qwen3-VL 8B Instruct à 0,18 $ et 0,70 $. Aucun de ceux-là n'est AesCode 32B : le fine-tune appartient à Microsoft et aucun fournisseur ne le fournit. Mais si ce que vous vouliez d'AesCode 32B était un modèle qui lit une capture d'écran et écrit du code, et que vous n'aviez pas spécifiquement besoin du fine-tune de design esthétique, l'option appelable existe et coûte une fraction du GPU. Le basculement automatique sous le même point de terminaison fait la différence entre essayer cela et parier un chemin de production dessus.

Comment décider concrètement

Écartons d'abord la licence, car c'est une égalité et cela ne décidera rien.

Ensuite, demandez-vous ce que vous voulez obtenir en sortie. Si la réponse est une page rendue et modifiable — une présentation, un rapport, un tableau de bord — North Mini Code ne peut pas vous aider et AesCode 32B est le seul des deux à être orienté vers ce problème. Lancez-vous en toute connaissance de cause concernant les 65 GB, le contexte de 24K, l'absence d'évaluation indépendante et le fait qu'il s'agit d'un modèle non annoncé avec un nombre de téléchargements à deux chiffres. C'est une version de recherche, et les versions de recherche récompensent les équipes qui peuvent se permettre d'être curieuses.

Si la réponse est une modification à apporter à un dépôt — une migration, un correctif, une tâche de terminal en plusieurs étapes —, North Mini Code est celui qui dispose de l'entraînement sur harness, de la fenêtre 256K, du déploiement à 3B de paramètres actifs et d'une mesure externe de sa qualité comme de sa verbosité. Prévoyez le budget d'après le nombre de tokens, pas d'après le tarif affiché.

Et si votre liste de choses à faire ce trimestre contient à la fois un artefact de conception et une migration de dépôt, ne considérez pas cela comme une décision à deux modèles alors qu'il s'agit en réalité d'une décision à six modèles. Faites appel au spécialiste là où c'est rentable, aiguillez le reste.

Le problème du modèle non annoncé

Une dernière chose sépare ces deux-là, et elle n’est pas technique. North Mini Code a un fournisseur derrière lui qui a publié une fiche de modèle, un article de blog, un Hugging Face Space pour l’essayer, et une documentation sur la méthodologie d’évaluation que l’on peut contester. AesCode 32B a un dépôt, un README et une ligne de citation qui indique « Under review, 2027 ». Microsoft n’a pas dit qu’il existait.

Cela change à partir du moment où vous pouvez l'adopter. Avec North Mini Code, la question ouverte est de savoir si sa verbosité le rend non économique à grande échelle — une question à laquelle vous pouvez répondre en l'exécutant. Avec AesCode 32B, la question ouverte est de savoir ce que Microsoft compte en faire : s'il s'agit d'un artefact de recherche, de la première version d'une gamme de produits, ou de quelque chose qui sera discrètement remplacé par une version 70B dans six semaines. Rien dans le dépôt ne répond à cela, et aucune lecture de la fiche du modèle, aussi attentive soit-elle, n'y répondra. Surveillez trois signaux — une annonce officielle, une reproduction indépendante du 85,89, ou un fournisseur d'inférence qui reprend le checkpoint — et considérez l'absence des trois comme l'état actuel des preuves plutôt que comme une raison de trouver le modèle sans intérêt.