AesCode-8B vs Qwen3-8B : ils ressemblent à un parent et à son enfant, alors qu’ils ne le sont pas

Les noms invitent à une erreur. AesCode-8B est un modèle 8B avec un socle Qwen3-VL-8B-Instruct, Qwen3-8B est le modèle 8B du fournisseur, et la lecture évidente est que le premier est un fine-tuning du second. Ce n'est pas le cas. La configuration publiée d'AesCode-8B déclare Qwen3-VL-8B-Instruct comme base — l'homologue vision-langage, un checkpoint différent avec un rôle différent — et les métadonnées Hugging Face le listent comme un fine-tuning de ce modèle, et non du Qwen3-8B purement textuel. Les deux modèles AesCode de cette classe de poids sont des cousins plutôt qu'un parent et un enfant, et cette distinction est toute la raison d'être de cette page : elle vous indique ce que Microsoft a acheté lorsqu'il est parti d'un checkpoint vision-langage, ce que cela a coûté du côté texte, et pourquoi une comparaison avec le généraliste 8B ordinaire de la famille finit par mesurer un fork plutôt qu'une mise à niveau.

Les deux sont sous Apache 2.0 et tous deux sont téléchargeables, mais leurs historiques de publication ne pourraient pas être plus différents. Qwen3-8B est sorti en avril 2025 dans le cadre de la gamme Qwen3 du fournisseur, avec à son actif de la documentation, une intégration à l’écosystème et dix-huit mois de déploiements par d’autres. AesCode-8B ne porte aucune date de publication où que ce soit dans ses fichiers. Microsoft a créé le dépôt Hugging Face le 2026-09-29, a committé les poids avec le message « Release AesCode-8B » à 03:35 UTC le 2026-10-07, et a mis le code d’entraînement sur GitHub le lendemain. Il n’y a aucun billet de Microsoft Research, aucune note de version, aucune page produit et aucun article scientifique — la citation de la fiche du modèle indique « Under review » avec l’année fictive 2027, et le dépôt affichait deux téléchargements au moment de la rédaction. Tout ce qui est quantitatif concernant AesCode-8B ci-dessous provient de Microsoft lui-même et n’a été reproduit par personne.

L'arbre généalogique que les noms cachent

La gamme Qwen3 contient plusieurs checkpoints de classe 8B qui partagent une lignée et pas grand-chose d'autre. Qwen3-8B est le généraliste texte uniquement : environ 8,2 milliards de paramètres au total, dont environ 7 milliards hors embeddings, une attention à requêtes groupées, un contexte natif de 32 000 tokens extensible jusqu'à 131 000 via YaRN, et un entraînement sur 119 langues et dialectes. Il raisonne, dialogue, écrit du code et appelle des outils, et c'est précisément pour ces raisons l'un des modèles 8B les plus largement auto-hébergés de l'écosystème ouvert. Qwen3-VL-8B-Instruct en est le membre multimodal : la même génération de la famille, une tour de vision dédiée en plus, image et texte en entrée, texte en sortie.

Microsoft est parti du deuxième. La configuration AesCode-8B indique Qwen3VLForConditionalGeneration, avec 36 couches cachées, une taille cachée de 4 096, 32 têtes d'attention et 8 têtes clé-valeur, un vocabulaire de 151 936 tokens et des positions mrope entrelacées, et il nécessite transformers 4.57 ou version ultérieure. Les shards totalisent 17 543 339 408 octets, soit environ 8,8 milliards de paramètres bf16, ce qui explique pourquoi le champ de taille arrondi de Hugging Face indique 9B alors que le fournisseur indique 8B. C'est un arrondi plutôt qu'un écart, et le nombre de paramètres n'est pas la différence qui compte — ce sont la modalité d'entrée et le contexte de service de 24 576 tokens.

Donc, la formulation honnête n’est pas « un généraliste contre son fine-tune ». C’est : un généraliste du texte avec un long contexte et dix-huit mois d’historique de production, face à un checkpoint de recherche multimodal qui produit un document et n’a jamais été évalué de manière indépendante.

À quoi Microsoft a consacré le budget de formation

Le brief de conception est cité sur la fiche du modèle et il explique la scission : les modèles de code « ne peuvent pas voir comment la mise en page, la hiérarchie et la couleur s’articulent sur le canevas », tandis que les générateurs d’images « composent des pages visuellement convaincantes mais reproduisent souvent mal le texte, les nombres et les relations logiques ». AesCode est la tentative de prendre le sens de la composition à l’un et la vérifiabilité à l’autre, et la recette est inhabituelle d’une manière bien précise.

Chaque prompt d'entraînement est associé à une image de référence générée à partir de ce même prompt — les propres exécutions de Microsoft utilisaient GPT-Image-2 pour l'image et GPT-5.5 pour développer un court brief en un prompt de contenu détaillé. La référence ne porte que la mise en page et le style ; le prompt textuel reste l'autorité en matière de contenu. Ensuite, à l'inférence, le modèle n'en a presque plus besoin : si l'on prive AesCode-8B de la référence, son score Visual chute de 1,00 point sur cent, contre 19,55 pour le backbone et 10,04 pour GPT-5.5. Un résultat connexe est que les récompenses fondées sur la référence ont fait passer le Visual en mode prompt seul de 25,17 à 69,71, de sorte que le prior visuel s'est déplacé dans les poids au lieu de rester dans l'entrée.

Le reste est une histoire de conception de récompense. La supervision est un « graphe de conception » de nœuds et d'arêtes — texte, graphiques, tableaux, cartes, régions, emplacements d'images, avec l'inclusion, l'alignement, l'ordre et la connexion comme arêtes — choisi de sorte que chaque propriété sur le canevas appartienne à un élément nommé et puisse donc être évaluée séparément. Sept canaux évaluent le résultat : six vérificateurs déterministes pour l'exécution, le texte, les limites, les données de tableau et de graphique, la disposition sémantique et les espaces blancs, plus une Visual Graph Rubric spécifique à l'échantillon, jugée par un modèle vision-langage. Les candidats sont rendus dans un navigateur Playwright en sandbox avec les requêtes externes bloquées, et le harnais relit le DOM, les styles calculés, les boîtes englobantes et une capture d'écran, c'est pourquoi les tableaux doivent être des tableaux HTML et les graphiques doivent être des spécifications ECharts. L'entraînement a consisté en un affinage supervisé à démarrage à froid sur 3 000 démonstrations, puis en GDPO sur 7 408 prompts pendant 400 étapes sur un seul nœud de huit NVIDIA B200, avec chaque canal de récompense normalisé au sein de son groupe de rollout afin qu'un signal dense basé sur des règles ne puisse pas noyer le signal visuel clairsemé. Microsoft mesure cette normalisation à 5,12 points Visual par rapport au GRPO scalaire simple.

Aucun de ces mécanismes n’existe pour faire d’AesCode-8B un meilleur assistant généraliste. Ils existent pour rendre la sortie vérifiable, et c’est pourquoi le contexte du modèle est ce qu’il est.

Côte à côte, avec les numéros étiquetés

• Base — AesCode-8B : Qwen3-VL-8B-Instruct, un checkpoint vision-langage. Qwen3-8B : le généraliste purement textuel de la même génération.

• Paramètres — AesCode-8B : environ 8,8 Md en bf16 répartis sur quatre fragments. Qwen3-8B : environ 8,2 Md au total, dont à peu près 7 Md hors embeddings.

• Entrées — AesCode-8B : texte ainsi qu'une image de référence facultative. Qwen3-8B : texte.

• Sortie — AesCode-8B : un document HTML et CSS complet. Qwen3-8B : texte, appels d’outils, code.

• Contexte — AesCode-8B : 24 576 tokens dans la configuration rapportée. Qwen3-8B : 32 K natif, 131 K étendu via YaRN.

• Langues — AesCode-8B : l'étiquette de la fiche est uniquement « en ». Qwen3-8B : 119 langues et dialectes.

• Preuves — AesCode-8B : la grille d'évaluation d'infographies de Microsoft, avec 300 échantillons, trois générations par invite, sans reproduction externe. Qwen3-8B : dix-huit mois de benchmarks indépendants, de travaux de quantification et de déploiement en production.

• Licence — Apache 2.0 dans les deux cas, sans restriction d'accès. Une égalité, et ce n'est pas le facteur différenciant que les gens imaginent.

Le déficit de preuves constitue la véritable comparaison

Microsoft rapporte qu'AesCode-8B obtient 82,94 Overall sur son barème, devant GPT-5.5 conditionné par référence à 81,28 et Claude Opus 4.8 à 80,39, et 31,1 points Visual d'avance sur son propre modèle de base conditionné par référence. Trois chiffres de ce tableau valent plus que le titre. Le premier est Style, où AesCode-8B se situe à 53,21 et aucun modèle de la comparaison ne dépasse 60 — et la définition de Style selon Microsoft est une conception qui ne nécessite aucune révision visuelle supplémentaire avant livraison, donc sur la seule dimension qui demande si un humain livrerait la page sans la modifier, le modèle n'est pas le leader. Le deuxième est la défaillance aux limites : un grave débordement de canevas réapparaît sur 4,3 % des 300 échantillons, contre 34,7 % pour GPT-5.5. Le troisième est que la moitié visuelle du score provient d'un juge vision-langage non nommé, ce qui signifie que la moitié déterministe est reproductible par un tiers et que l'autre moitié ne l'est pas.

Les chiffres de Qwen3-8B proviennent d’une tout autre source, et cela compte plus que de savoir quel ensemble est le plus élevé. Dix-huit mois d’évaluation indépendante, de quantifications communautaires, de benchmarks de serving et de déploiements en production constituent un autre type de preuve : ce n’est pas une affirmation, c’est un historique de résultats. Vous pouvez découvrir comment Qwen3-8B se comporte sous quantification en quatre bits sur une carte donnée parce que quelqu’un l’a publié. Vous ne pouvez pas faire cela pour AesCode-8B, car depuis cette semaine, personne en dehors de Microsoft ne l’a exécuté sur quoi que ce soit.

Et il n'existe aucune métrique commune entre les deux tableaux. Qwen3-8B n'a pas de score de mise en page d'infographie ; AesCode-8B n'a aucun benchmark de raisonnement général publié. La comparaison n'est pas serrée, ni même serrée — elle est indisponible.

Ce que l’exécution de chacun demande réellement

Qwen3-8B est le plus simple. Un modèle texte de 8,2 B se quantifie sur une seule carte grand public, bénéficie de dix-huit mois d’outillage derrière lui dans tous les frameworks de service et runtimes locaux, et se comporte de façon prévisible. L’extension de contexte à 131K est documentée plutôt que relevant du folklore, et la couverture de 119 langues est la raison pour laquelle il apparaît dans tant de pipelines multilingues.

AesCode-8B est un projet de serving. La commande de la fiche elle-même est vllm serve microsoft/AesCode-8B --limit-mm-per-prompt image=2 --max-model-len 24576, avec transformers 4.57 ou plus récent pour la voie non-vLLM. Les 17,5 Go de poids bf16 doivent tenir à côté d'un cache KV pour 24 576 tokens et jusqu'à deux images, donc une seule carte de 24 Go est techniquement suffisante et inconfortablement juste, et 40-48 Go ou deux cartes de 24 Go constituent le minimum réaliste. Prévoyez aussi un moteur de rendu, car chaque affirmation sur la qualité de ce modèle a été faite en rendant sa sortie HTML dans un navigateur sandboxé — si vous voulez savoir si vos propres sorties sont bonnes, c'est le harnais que vous devez mettre en place. Et notez que le contexte de 24 576 tokens a été exercé sur des pages d'infographie uniques, pas sur les diaporamas multi-diapositives pour lesquels le modèle est présenté, donc la pression sur le contexte avec un vrai diaporama est un territoire non testé.

La disponibilité est l’autre moitié du même point. AesCode-8B n’est pas un modèle qu’OrcaRouter route, et nous n’avons pas non plus trouvé qu’il soit servi ailleurs ; une évaluation aujourd’hui implique donc des poids sur votre propre matériel. Son ancêtre, lui, c’est une autre histoire — Qwen3-VL-8B-Instruct peut être appelé via OrcaRouter dès maintenant à 0,18 $ par million de tokens d’entrée et 0,70 $ par million de tokens de sortie sur un contexte de 131 072 tokens, ce qui en fait le moyen le moins cher de voir ce que la version non ajustée de cette architecture exacte produit sur vos propres prompts d’infographie. Plus haut dans la même gamme, Qwen3.8-27B est routable à 0,33 $ et 2,40 $. Le prix catalogue du fournisseur est répercuté sans marge ajoutée et le basculement entre fournisseurs est automatique, si bien que prototyper le prompt sur le backbone hébergé coûte une clé plutôt qu’une semaine de GPU, et seuls les prompts qui rendent réellement bien justifient le travail de reproduction.

Celui que vous voulez dépend de l’artefact.

Choisissez AesCode-8B lorsque le livrable est une page et qu’il doit être modifiable. Une sortie HTML structurée qui se prête aux diffs dans Git, des tableaux sous forme de vrais tableaux et des graphiques sous forme de spécifications ECharts, constitue un artefact réellement différent d’un paragraphe de texte, et aucune quantité de capacité générale ne peut le remplacer. Assumez ce compromis en connaissance de cause : un checkpoint de recherche non annoncé avec un nombre de téléchargements à deux chiffres, un contexte de 24 K, anglais uniquement, aucune évaluation indépendante, un plafond Style publié par son propre fournisseur, et une facture de service mesurée en dizaines de gigaoctets.

Choisissez Qwen3-8B pour tout le reste — ce qui, pour la plupart des équipes, représente tout. C’est le généraliste éprouvé à ce gabarit, il dispose d’un contexte plus long, il parle cent dix-neuf langues, il tourne sur du matériel que vous possédez déjà, et il a dix-huit mois d’expérience en production d’autres équipes derrière les décisions que vous vous apprêtez à prendre. Si vous n’avez pas de besoin précis de générer des pages rendues, cette comparaison n’a qu’une seule réponse.

L'argument en faveur de vouloir les deux est réel, et ce n'est pas un critère de départage. Un pipeline qui lit des documents et produit des présentations utilise deux modèles aux types de sortie réellement différents, et la posture utile consiste à garder le moteur de rendu de page sur du matériel capable de le supporter et à acheminer le travail de lecture et de raisonnement vers quelque chose hébergé derrière le même point de terminaison que tout le reste.

Qu'est-ce qui ferait de cette page une meilleure page de closing ?

Trois choses, et une seule d'entre elles concerne les benchmarks. Une reproduction indépendante de la baisse de référence de 82.94 et de 1.00 point ferait passer AesCode-8B de l'allégation du fournisseur au résultat, et permettrait de répondre à la question de la taille 8B contre 8B sur le fond. Un fournisseur qui reprendrait le checkpoint réduirait la colonne de déploiement et transformerait « une semaine de GPU » en « un appel API ». Et l'article que la fiche cite comme en cours d'évaluation — « AesCode : Génération de code esthétique avec récompenses intermodales découplées » — répondrait à la question à laquelle la fiche du modèle ne peut pas répondre : ce que fait la grille d'évaluation visuelle lorsque le graphe de conception par rapport auquel elle évalue est lui-même erroné.

Jusqu'à ce que l'un de ces éléments aboutisse, l'interprétation défendable est la plus restrictive. AesCode-8B est le plus intéressant de ces deux modèles et le moins utilisable. Il est très bon dans les aspects du design visuel qu'une machine peut vérifier, moyen dans la partie qui ne peut pas être automatisée, et il appartient à la même famille de génération Qwen3 que le modèle auquel il est comparé, sans pour autant en descendre. Qwen3-8B est celui que vous pouvez mettre dans un pipeline dès cet après-midi.