AesCode-8B est sorti discrètement : le modèle 8B de Microsoft écrit des diapositives et des tableaux de bord en HTML

Le nombre le plus intéressant de la nouvelle version de Microsoft est 1,00. Retirez l'image de référence à AesCode-8B — un modèle de 8 milliards de paramètres qui produit des diapositives, des affiches et des tableaux de bord en HTML et CSS modifiables — et son score visuel chute d'un point sur cent. Retirez la même référence à Qwen3-VL-8B-Instruct, le modèle à poids ouverts à partir duquel AesCode-8B a été affiné, et la baisse est de 19,55 points. Pour GPT-5.5, elle est de 10,04. C'est dans cette seule comparaison que réside le véritable résultat de recherche, et elle se trouve sous un titre que Microsoft a également publié : sur son propre barème de 300 échantillons, le score global de 82,94 d'AesCode-8B dépasse de justesse celui de GPT-5.5 conditionné par référence à 81,28 et celui de Claude Opus 4.8 à 80,39, avec un grand frère, AesCode-32B, à 85,89.

Rien n'a été annoncé au sujet de cette sortie. Microsoft a déposé les poids sur Hugging Face le 2026-10-07 sous licence Apache 2.0 — AesCode-8B ainsi qu'un compagnon 32B construit de la même manière à partir de Qwen3-VL-32B-Instruct — et a publié le code d'entraînement et d'évaluation sur GitHub le lendemain. Il n'y a pas d'article de blog Microsoft Research, pas de note de version, pas de page produit et pas de prépublication : la citation dans la fiche du modèle indique « Under review », année 2027, ce qui est un espace réservé plutôt qu'une date. Au 2026-10-11, le dépôt 8B affiche deux téléchargements et un like ; le dépôt GitHub affiche une étoile. Tout ce qui suit et qui porte un chiffre est soit un horodatage que vous pouvez vérifier vous-même, soit une donnée que Microsoft a rapportée au sujet de son propre ensemble d'évaluation — et cette distinction compte plus que d'habitude ici, car aucune partie de ce modèle n'a été mesurée par quelqu'un d'autre.

Ce qui est livré, et ce qui n'est pas dans la boîte

Trois dates définissent cette version, et ce sont les seules dates qu’elle contient. Le dépôt Hugging Face pour microsoft/AesCode-8B a été créé le 2026-09-29, les poids ont été commités avec le message « Release AesCode-8B » à 03:35 UTC le 2026-10-07, et le dépôt de code microsoft/AesCode est devenu public le lendemain, le 2026-10-08 à 23:14 UTC. Les poids 32B sont arrivés dans la même fenêtre de commit. Rien entre-temps n’a été annoncé nulle part.

• Poids — quatre shards safetensors totalisant 17 543 339 408 octets, ce qui équivaut à environ 8,8 milliards de paramètres bf16. Microsoft étiquette le modèle comme 8B ; le champ de taille de Hugging Face l'arrondit à 9B. C'est un arrondi, pas une divergence.

• Architecture — un fine-tuning direct de la recette Qwen3-VL : Qwen3VLForConditionalGeneration, 36 couches cachées, une taille cachée de 4 096, 32 têtes d’attention avec 8 têtes clé-valeur, un vocabulaire de 151 936 tokens et des positions mrope entrelacées. Il nécessite transformers 4.57 ou version ultérieure.

• Contexte et sortie — les exécutions rapportées ont utilisé un contexte de 24 576 jetons avec jusqu’à 12 000 jetons de sortie, générés à une température de 0,8 et top-p de 0,95 sur trois rollouts par invite sans sélection. La commande de service vLLM autorise deux images par invite : la référence, et rien d’autre, car la sortie est du texte.

• Licence — Apache 2.0, présentée comme reposant sur l'architecture Qwen3-VL. Entièrement permissive, sans contrôle d'accès, sans annexe sur l'usage acceptable.

• Non inclus — les données d'entraînement et d'évaluation. Le dépôt fournit le pipeline et documente les entrées et sorties attendues, et mentionne les fichiers de découpage qu'il attend, mais aucune publication de jeu de données n'est répertoriée ni sur la fiche du modèle ni sur le dépôt de code. Vous obtenez la recette, pas les ingrédients.

• Également absent de la boîte — aucun point de terminaison hébergé. Nous n’avons trouvé nulle part d’API servant AesCode-8B, et il ne figure pas dans notre propre catalogue. Tant qu’un fournisseur ne l’adopte pas, l’évaluer implique de charger les poids sur vos propres GPU.

Le cadrage utilisé par Microsoft mérite d'être cité, car il constitue tout le cahier des charges de la conception : 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 chiffres et les relations logiques ». AesCode est la tentative de prendre le sens de la composition chez l'un et la vérifiabilité chez l'autre.

Le résultat de 1,00 point, expliqué

Voici le mécanisme qui se cache derrière le nombre du premier paragraphe. Pendant l’entraînement, chaque prompt est associé à une image de référence générée à partir de ce même prompt — les propres exécutions de Microsoft ont utilisé GPT-Image-2 pour l’image et GPT-5.5 pour développer une idée courte en un prompt de contenu détaillé. La référence n’a aucune autorité sur le contenu ; le prompt textuel reste la source de vérité. Ce que la référence fournit, c’est la mise en page et le style, et la fonction de récompense est conçue pour garder ces deux choses séparées.

La conséquence est que le prior visuel finit dans la politique plutôt que dans l’entrée. AesCode-8B perd 1,00 point visuel lorsque la référence est retirée à l’inférence. Son propre backbone, évalué en conditionnement de référence à 44,72 en visuel, perd 19,55 points sans référence. GPT-5.5 en perd 10,04. La version distillée de cela : le modèle a cessé d’avoir besoin de l’image.

La seconde moitié du résultat est celle qu'il est facile de manquer. Microsoft rapporte que les récompenses basées sur des références ont fait passer Visual en mode prompt-only de 25,17 à 69,71 — le modèle qui ne voit jamais de référence au moment de l'inférence bénéficie tout de même d'avoir été entraîné avec de telles références. Si vous comptiez sauter l'étape de génération de références dans votre propre pipeline, c'est le chiffre qui dit que vous ne devriez pas non plus vous embêter à la sauter pendant l'entraînement.

La mise en garde honnête sur tout cela : il s'agit de la grille d'évaluation de Microsoft, appliquée aux 300 échantillons d'infographies de Microsoft, avec trois notations par invite et sans tri sélectif. La moitié du score provient de vérificateurs déterministes, que n'importe qui pourrait reproduire ; l'autre moitié, les dimensions de la liste de contrôle, est jugée par un modèle vision-langage dont la documentation ne nomme pas l'identité. Vous ne pouvez pas reproduire la seconde moitié sans savoir quel juge l'a produite.

Là où le goût s’infiltre dans les poids

La méthode d'entraînement est la partie de cette version qui contient les idées les plus transférables, et elle est plus mécanique que ne le suggère le résultat.

• Tout est d’abord un graphe.Chaque cible est représentée sous forme de graphe de conception : des nœuds pour le texte, les graphiques, les tableaux, les cartes, les régions et les emplacements d’image, et des arêtes pour la contenance, l’alignement, l’ordre et la connexion. L’intérêt du graphe est l’attribution — chaque propriété du canevas appartient à un élément nommé, de sorte que chaque propriété peut être évaluée individuellement.

• Sept canaux de récompense. Six vérificateurs déterministes contrôlent tout ce qui est analysable — exécution, texte exact, limites, données de tableaux et de graphiques, mise en page sémantique, espaces blancs — et une grille d'évaluation visuelle propre à chaque échantillon, la Visual Graph Rubric, construite sous forme de questions fermées oui/non liées au graphe portant sur la géométrie et le placement, note le reste. Les canaux sont execution, text, boundary, tablechart, layout, whitespace et design.

• Les canaux sont normalisés avant d'être combinés.GDPO normalise chaque canal au sein de son groupe de rollout, de sorte qu'un signal dense fondé sur des règles ne puisse pas noyer le signal visuel clairsemé. Microsoft mesure cela à 5,12 points Visual au-dessus du GRPO scalaire simple avec la même configuration — rapporté par le fournisseur, mais une ablation concrète plutôt qu'une affirmation.

• L'évaluation se fait par rendu.Le HTML candidat est rendu dans un navigateur Playwright en bac à sable, avec les requêtes externes bloquées, et le harnais relit le DOM, les styles calculés, les boîtes englobantes, l'état de la console et une capture d'écran. Les tableaux doivent être des tableaux HTML ; les graphiques doivent être des spécifications ECharts. Cette contrainte fait un vrai travail — elle force la sortie dans une forme qu'un vérificateur peut analyser.

• La recette elle-même. Fine-tuning supervisé à démarrage à froid sur 3 000 démonstrations avec un taux d’apprentissage de 1e-5, puis GDPO sur 7 408 prompts pendant 400 étapes sur le moteur hybride FSDP-vLLM de verl, sans critique et sans modèle de récompense entraîné séparément. AdamW à 5e-6 constant, sans warmup, weight decay 0,01, 128 prompts par étape avec 8 rollouts chacun, coefficients KL et d’entropie tous deux à 0,001, prompt et réponse plafonnés chacun à 8 192 tokens. Les exécutions publiées ont utilisé un seul nœud avec huit NVIDIA B200. AesCode-32B utilise la même recette pendant 520 étapes.

Lu dans son ensemble, il s’agit d’un article sur la conception de récompenses déguisé en annonce de sortie de modèle — ce qui est cohérent avec la citation indiquant « Under review » plutôt que de pointer vers une prépublication.

Le tableau des scores, et qui s'en porte garant

Tout ce qui suit constitue l’évaluation de Microsoft, rapportée dans la fiche du modèle, sur 300 échantillons d’infographies. Règle fait la moyenne des contrôles programmatiques Texte, Limites et Graphique ; Visuel fait la moyenne des dimensions de la liste de contrôle Contenu, Mise en page et Style ; Global est la moyenne des deux. Les scores sont des pourcentages moyennés sur trois générations par invite, sans sélection. « Réf. » indique si le modèle a reçu une référence générée en même temps que l’invite.

• AesCode-8B avec référence — Texte 94,06, Limite 88,36, Graphique 87,79, Règle 90,07 ; Contenu 86,41, Mise en page 87,80, Style 53,21, Visuel 75,80 ; Global 82,94.

• Par rapport à son propre backbone — Qwen3-VL-8B-Instruct conditionné par référence obtient 44,72 en Visual et 51,93 en Overall. Cela représente un gain de 31,1 points en Visual et de 31,0 points en Overall, et c’est la comparaison la moins surprenante du tableau, puisque tout l’intérêt de l’entraînement réside dans la moitié visuelle.

• Face à GPT-5.5, conditionné par référence — Global 81,28, Contenu 82,44, Mise en page 89,93 et Style 57,91.

• Face à Claude Opus 4.8, conditionné par référence — Global 80,39, Contenu 86,42, Mise en page 89,76.

• AesCode-32B, conditionné par référence — Texte 95,34, Limite 97,27, Graphique 90,37, Règle 94,33, Mise en page 90,58, Visuel 77,44, Global 85,89. Vingt-deux virgule quatre points de plus en Visuel que son propre backbone 32B.

• Le plafond du Style — aucun modèle du tableau ne dépasse 60, et le score de 57,91 de GPT-5.5 est le meilleur d'entre eux. AesCode-8B se situe à 53,21. La définition de Microsoft elle-même est impitoyable : le Style ne crédite un design que lorsqu'il ne nécessite aucune révision visuelle supplémentaire avant livraison. Donc, sur la seule dimension qui mesure si un humain livrerait réellement la page sans la modifier, le modèle 8B n'est pas le leader.

• Défaillances de limites — une grave défaillance de débordement de canvas se reproduit sur 4,3 % des 300 échantillons, contre 34,7 % pour GPT-5.5. Le débordement est le mode de défaillance qui rend le HTML généré inutilisable, et non simplement laid.

Maintenant, la partie qui compte autant que le tableau. Chaque chiffre ci-dessus est déclaré par le fournisseur et non reproduit. AesCode-8B n'apparaît sur aucun classement indépendant que nous ayons pu trouver, et la comparaison avec GPT-5.5 et Claude Opus 4.8 est menée selon la grille d'évaluation de Microsoft, sur une tâche pour laquelle ces modèles n'ont pas été ajustés, avec une définition de « Layout » qui récompense le simple fait de produire une page. Un score Text de 94,06 ne signifie pas que ce modèle bat GPT-5.5 en texte. Cela signifie qu'il place des étiquettes sans contredire le prompt sur des pages infographiques, ce qui est une affirmation bien plus modeste. Le résultat Style est ce qui révèle que la grille n'est pas truquée en faveur d'AesCode — la plus grande victoire au tableau de scores s'accompagne du plus grand chiffre peu flatteur juste à côté.

Ce qui est confirmé, et ce qui ne l'est pas

Comme cela a été livré discrètement, il vaut la peine de distinguer explicitement les deux.

• Confirmé — les poids existent et sont téléchargeables sous Apache 2.0 ; les deux horodatages de publication figurent dans les dépôts ; l’architecture, le nombre de paramètres, la longueur de contexte et les paramètres d’échantillonnage sont tous dans la configuration publiée et la fiche de modèle ; la recette d’entraînement et la conception de la récompense sont documentées avec assez de détails pour qu’on puisse en débattre ; le code, la pile de vérificateurs et le générateur de rubriques sont publics ; un compagnon 32B existe.

• Non confirmé — aucun des chiffres de benchmark, par quiconque d'autre que le fournisseur. L'article, que la documentation elle-même décrit comme en cours de révision. L'identité du juge vision-langage derrière la moitié visuelle des scores. Si un fournisseur quelconque l'hébergera. Si le contexte de 24 576 tokens tient le coup sur de vraies présentations multi-diapositives, étant donné que l'évaluation rapportée porte sur des pages d'infographie uniques. Et quoi que ce soit sur le comportement hors anglais — l'étiquette de langue de la fiche du modèle est « en » uniquement.

Si vous voulez l'exécuter, et combien cela coûte

Qwen3-VL-8B-Instruct — le modèle à partir duquel AesCode-8B a été fine-tuné, et la comparaison individuelle la plus solide disponible jusqu'à ce que quelqu'un publie un résultat AesCode indépendant — est une autre question :

Le chemin de service pour AesCode-8B lui-même est court, et la fiche du modèle le donne directement : 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, et un extrait Python qui accepte une image de référence facultative avant le prompt textuel.

L'arithmétique que vous devez faire vous-même, c'est la mémoire. 17,5 Go de poids bf16 doivent tenir aux côtés d'un cache KV pour un contexte de 24 576 jetons et jusqu'à deux images : une seule carte de 24 Go suffit donc techniquement pour les poids, mais s'avère inconfortablement juste pour tout le reste ; 40-48 Go, ou deux cartes de 24 Go, constituent le plancher réaliste. Le compagnon 32B relève d'un tout autre ordre de problème — ses shards totalisent 66,7 Go, il exige donc du parallélisme tensoriel et un nœud multi-GPU. Prévoyez aussi un moteur de rendu : le modèle émet un document HTML complet, et toute affirmation de qualité à son sujet passe par le rendu de ce document, si bien qu'évaluer vos propres sorties implique de monter Playwright avec les requêtes externes bloquées.

Vous n'avez pas besoin de générer une image de référence au moment de l'inférence — c'est exactement ce que vous rapporte le résultat à 1,00 point —, mais la documentation est claire : la qualité reste meilleure lorsqu'une image de référence est fournie, de sorte que la configuration honnête consiste à rendre la référence facultative plutôt qu'à s'en passer entièrement.

AesCode-8B n'est pas un modèle qu'OrcaRouter route, et nous n'avons pas pu le trouver hébergé ailleurs non plus, donc une évaluation signifie actuellement des poids sur votre propre matériel. Son modèle de base, en revanche, c'est une autre histoire. Qwen3-VL-8B-Instruct est routable via OrcaRouter dès aujourd'hui à 0,18 $ par million de tokens en entrée et 0,70 $ par million en sortie, avec un contexte de 131 072 tokens — ce qui en fait le moyen le moins cher de voir ce que fait la version non affinée de cette architecture sur vos propres prompts d'infographie avant de passer une semaine de GPU à reproduire la recette de quelqu'un d'autre. OrcaRouter répercute le prix catalogue du fournisseur avec 0 % de marge et bascule automatiquement d'un fournisseur à l'autre en cas de défaillance, de sorte que cette comparaison coûte une seule clé et aucun second contrat ; si AesCode-8B finit un jour chez un fournisseur que nous routons, il sera au catalogue le jour même. Et si vous l'hébergez vous-même, les modèles vers lesquels vous vous replieriez en production sont ceux qui se trouvent déjà derrière ce point de terminaison — ce qui est la posture raisonnable pour un modèle publié discrètement sans aucune évaluation indépendante.

Que regarder

Deux choses, et aucune des deux n'est un nouveau tableau de benchmarks.

Le premier est l'article. "AesCode: Aesthetic Code Generation with Decoupled Cross-Modal Rewards" est cité comme étant en cours d'évaluation pour 2027, ce qui ressemble à un espace réservé saisi dans une entrée BibTeX plutôt qu'à un calendrier. Tant qu'une prépublication ou une version camera-ready n'apparaît pas, l'explication du canal de récompense ci-dessus est une synthèse d'un résumé que personne en dehors du laboratoire ne peut lire — et les questions intéressantes, comme la manière dont le Visual Graph Rubric gère un graphe de conception qui est lui-même erroné, ne trouvent de réponse que dans le texte intégral.

Le second point, c'est l'hébergement. Un modèle de 8,8 milliards de paramètres sous Apache-2.0 qui génère du HTML structuré et vérifiable a exactement le profil qu'une plateforme adopte, parce que sa sortie est inspectable d'une manière qu'un JPEG ne l'est pas. Dès l'instant où quelqu'un le met en service, cela cesse d'être une décision d'auto-hébergement pour devenir une décision de routage — et la comparaison des coûts cesse de porter sur les heures de GPU.

Ce qu'il ne faut pas attendre, c'est un verdict net. Style est le plafond pour chaque système de ce tableau, y compris celui-ci, et Style est la seule dimension qui demande si un humain livrerait la page telle quelle. La lecture défendable d'AesCode-8B est étroite et réelle : il est très bon sur les aspects du design visuel qui peuvent être vérifiés par une machine, il est moyen sur l'aspect qui ne le peut pas, et c'est le premier modèle à poids ouverts de cette niche où l'écart entre ces deux choses est le point de la publication plutôt qu'un accident de celle-ci.