AesCode-32B : le discret modèle 33B de Microsoft qui écrit des présentations en HTML modifiable

Les horodatages d'AesCode-32B ne concordent pas entre eux, et cette discordance constitue l'essentiel de ce qu'il y a à signaler. Le dépôt Hugging Face microsoft/AesCode-32B a été créé le 29 septembre 2026, mais tout ce qu'il contient est arrivé dans un seul commit daté du 7 octobre 2026, dont le message est simplement « Release AesCode-32B » — et la pile d'entraînement qui rend le résultat reproductible a été poussée vers github.com/microsoft/AesCode le 8 octobre. Microsoft n'a rien annoncé : aucun billet de blog, aucune prépublication arXiv, aucune soumission à un classement, aucune page de modèle sur son propre site. Ce qui existe, c'est un modèle vision-langage de 33 milliards de paramètres qui prend une invite et produit un document HTML complet et autonome — une diapositive, une affiche, un tableau de bord — ainsi qu'un compagnon plus petit, microsoft/AesCode-8B. Les deux sont affinés à partir de modèles vision Qwen3-VL — Qwen3-VL-32B-Instruct et Qwen3-VL-8B-Instruct respectivement — les deux sont sous Apache 2.0, et les deux sont téléchargeables dès aujourd'hui.

L'identifiant du dépôt est microsoft/AesCode-32Bet la carte s'ouvre sur l'astuce : AesCode associe votre invite à une image générée à partir de cette même invite, utilise l'image comme référence esthétique et suit le texte pour le contenu réel. Les générateurs d'images composent une belle page et rendent mal les chiffres qui s'y trouvent ; les modèles de code obtiennent les bons chiffres et ne peuvent pas voir à quoi ressemble la page. AesCode est une tentative de réunir les deux, et le résumé honnête à son sujet, à la date du 11 octobre 2026, est que les poids sont réels et vérifiables, que les chiffres du benchmark sont ceux du laboratoire, obtenus sur un harnais que le laboratoire a écrit, et que personne en dehors de Microsoft n'a encore publié de chiffre à son sujet. Cet article garde ces trois catégories distinctes de bout en bout.

Que contient réellement le dépôt, octet par octet ?

Commencez par ce que vous pouvez vérifier sans faire confiance à un seul mot de la fiche du modèle. Le dépôt 32B contient quatorze fragments safetensors totalisant 66 714 912 704 octets, ce qui, en BF16, représente environ 33,4 milliards de paramètres — cohérent avec les « 33B params » de la fiche et son avertissement selon lequel les poids seuls nécessitent environ 65 Go de mémoire d'accélérateur. La configuration déclare Qwen3VLForConditionalGeneration comme architecture et qwen3_vl comme type de modèle, il ne s'agit donc pas d'une nouvelle architecture, et aucune n'est nécessaire : le modèle se charge avec transformers>=4.57, et la fiche fournit une commande vLLM qui le sert sur quatre rangs de parallélisme tensoriel avec deux images autorisées par prompt et un plafond de 24 576 jetons.

Les compteurs d'engagement sont la partie la plus discrète de la publication. Deux téléchargements et un like sur le dépôt 32B au moment de la rédaction. Il n'y a aucune entrée dans le mapping des fournisseurs d'inférence de Hugging Face, ce qui signifie qu'aucun point de terminaison hébergé n'est raccordé derrière la page du dépôt, et aucune build GGUF, MLX ou llama.cpp n'est annoncée nulle part. Pour un modèle portant le nom de Microsoft et affichant des résultats qui surpassent GPT-5.5 dans le tableau du fournisseur lui-même, c'est une empreinte étonnamment réduite — et c'est la preuve la plus solide dont on dispose que cette mise en ligne s'est faite sans lancement derrière.

Le dépôt de code compagnon complète l'autre moitié de la chronologie, et c'est là que la question de la date de publication devient véritablement ambiguë. microsoft/AesCode a été créé le 23 juillet 2026 — dix semaines avant les poids — et contient quatorze commits, tous ayant le même auteur et tous horodatés à moins de vingt secondes les uns des autres le 8 octobre 2026, entre 23:14:04 et 23:14:24 UTC. Ils incluent la spécification pour générer des prompts et des exigences vérifiables, le pipeline de données qui construit des graphes de conception et des questions de rubrique, une étape SFT à démarrage à froid, la boucle d'apprentissage par renforcement GDPO, un vérificateur de rendu basé sur Playwright, des tests, et le README qui documente tout cela. Il n'y a ni releases ni tags, la description du dépôt est vide, et il a une étoile.

Alors, quelle est la date de sortie ? Le registre du dépôt indique le 29 septembre. Le commit qui porte le modèle indique le 7 octobre. Le code qui explique comment le modèle a été créé indique le 8 octobre. Trois horodatages dans une seule fenêtre de deux semaines, aucun d’entre eux accompagné d’une phrase de Microsoft disant « nous livrons ceci ». Considérez le 7–8 octobre comme la date effective pour les artefacts que la plupart des gens téléchargeront réellement, et le 29 septembre comme la date à laquelle le dépôt a été réservé. Quiconque vous dit qu’AesCode-32B a « été lancé » un jour précis choisit l’un de ces horodatages à votre place.

Le mécanisme : une image comme guide esthétique, un graphe comme récompense

L'affirmation technique de la fiche est étroite et précise, ce qui est un point en sa faveur. Le modèle est entraîné par fine-tuning supervisé à démarrage à froid sur 3 000 démonstrations avec un taux d'apprentissage de 1e-5, puis avec GDPO — une variante d'optimisation de politique relative au groupe — sur 7 408 prompts pendant 520 étapes. Le modèle 8B a utilisé la même recette et s'est arrêté à 400 étapes. L'exécution RL a utilisé le moteur hybride FSDP-vLLM de verl sans critique ni modèle de récompense entraîné séparément, AdamW à 5e-6 constant sans warmup, 128 prompts par étape avec huit rollouts chacun, et le prompt et la réponse limités chacun à 8 192 tokens.

Ce qui rend la récompense inhabituelle, c'est qu'il ne s'agit pas d'un scalaire unique. Chaque cible d'entraînement est décrite comme un graphe de conception couvrant l'ensemble du canevas, de sorte que les propriétés individuelles puissent être attribuées séparément. De ce graphe découlent sept canaux — exécution, texte, frontière, tablechart, mise en page, espace blanc et design — chacun normalisé au sein de son groupe de rollout avant agrégation afin qu'un signal dominant ne puisse pas noyer les autres. Les vérificateurs déterministes évaluent ce qui peut être analysé à partir du code et de son rendu ; un juge vision-langage évalue ce qui ne peut pas l'être, en utilisant une grille d'évaluation liée aux éléments et relations propres au graphe. Le HTML candidat est évalué en le rendant dans un navigateur Playwright en bac à sable avec les requêtes externes bloquées, ce qui exporte le DOM, les styles calculés, les boîtes englobantes, l'état de la console et une capture d'écran.

La conséquence d'ingénierie mérite d'être signalée, car elle apparaît dans la sortie que vous recevez : le modèle est entraîné à émettre des tableaux sous forme de véritables structures de tableaux HTML et des graphiques sous forme de spécifications ECharts, de sorte que les deux sont directement inspectables plutôt que figés dans des pixels. C'est la différence entre une présentation que vous pouvez confier à un designer et une présentation que vous pouvez confier à un linter. Les exigences de reproduction sont d'autant plus lourdes — le README demande Python 3.10, CUDA 12.6 et un nœud de huit GPU B200, épingle un commit verl spécifique et indique clairement qu'un correctif sur celui-ci est nécessaire, car la version standard de verl ne prend pas en charge Qwen3-VL, et avertit que sans les bibliothèques système Playwright le navigateur échoue au lancement et que les pages obtiennent un score nul, et que sans la pile OCR épinglée le canal de récompense correspondant renvoie zéro au lieu de s'abstenir et corrompt silencieusement le signal.

Le tableau de référence, et les quatre raisons de ne pas s’y accrocher.

Les chiffres phares d'AesCode-32B proviennent de 300 échantillons d'infographies, avec trois générations par prompt à une température de 0,8 et un top-p de 0,95, soit 12 000 jetons de sortie chacune, sans aucune sélection parmi les générations. Les scores sont exprimés en pourcentages. En conditionnement par référence, le modèle 32B rapporte Texte 95,34, Limites 97,27, Tableau/Graphique 90,37, et une moyenne des Règles de 94,33 ; côté visuel, Contenu 85,76, Mise en page 90,58, Style 55,99, pour une moyenne Visuelle de 77,44 et un score Global de 85,89. Dans le même tableau, GPT-5.5 avec une référence obtient un score Global de 81,28 et Claude Opus 4.8 avec une référence obtient 80,39, tandis que le backbone Qwen3-VL-32B-Instruct à partir duquel le modèle a été entraîné obtient 61,10.

Quatre réserves doivent être formulées dans le même souffle que ces chiffres, et aucune d'elles ne jette le discrédit sur le travail. Premièrement, chaque ligne, y compris celles de GPT-5.5 et de Claude Opus 4.8, a été exécutée par Microsoft, sur le harnais de Microsoft, avec la grille d'évaluation de Microsoft — ce ne sont pas les chiffres des autres laboratoires, ce sont les mesures par Microsoft des modèles de concurrents, et la fiche elle-même qualifie la grille d'« spécifique à l'échantillon » pour chaque graphe de conception. Deuxièmement, la grille d'évaluation est produite par le même pipeline que celui qui a généré les données d'entraînement, ce qui est exactement la configuration dans laquelle un benchmark peut dériver vers les points forts d'un modèle ; la fiche est franche sur les limites de cette grille — Style, qui exige qu'un design n'ait besoin d'aucune révision visuelle supplémentaire avant livraison, est qualifié de « plafond partagé par tous les systèmes » et aucun modèle du tableau ne dépasse 60. Troisièmement, il n'existe nulle part de mesure indépendante de ce modèle : aucune entrée dans un classement tiers, aucune reproduction, et vu les deux téléchargements, presque certainement personne en dehors du laboratoire ne l'exécute encore. Quatrièmement, la comparaison est subtilement asymétrique d'une manière qui mérite d'être relevée — les lignes d'AesCode-32B sont toutes conditionnées par une référence, de sorte que le modèle est mesuré dans la configuration pour laquelle il a été entraîné, ce que la fiche reconnaît en montrant que la qualité reste la plus élevée lorsqu'une référence est fournie.

Le seul résultat du tableau qui tient mieux que le résultat phare est une affirmation de robustesse plutôt qu'une affirmation de qualité. Priver AesCode-8B de l'image de référence à l'inférence ne lui coûte que 1,00 point Visuel, contre 19,55 pour son backbone Qwen3-VL-8B-Instruct et 10,04 pour GPT-5.5. L'argument de la fiche est que l'entraînement conditionné par référence internalise la planification visuelle dans la politique plutôt que d'apprendre au modèle à copier ce qu'il voit. C'est une affirmation rapportée par le fournisseur et non reproduite, et c'est aussi le genre d'affirmation qu'une seule exécution indépendante suffirait à trancher — et le genre qui compte le plus en production, où vous n'aurez pas toujours une image de référence sous la main.

Combien coûte son fonctionnement, et ce que cela implique pour la comparaison

Rien dans ce modèle n’est bon marché à auto-héberger. Dix à douze mille jetons de sortie constituent la taille de travail d’un seul artefact, et un document HTML complet accompagné d’une spécification ECharts se situe plus près du haut de cette fourchette que du bas, si bien que chaque génération correspond à un long décodage. La recette de service propre à la fiche du modèle exige quatre GPU en parallélisme tensoriel pour contenir environ 65 Go de paramètres BF16, et la recette d’entraînement exige huit B200. C’est une vraie machine, pas un déploiement amateur, et cela fixe les termes de la comparaison : les modèles auxquels AesCode-32B est comparé se louent au jeton, et le modèle lui-même se loue à l’heure-GPU, que vous possédiez le matériel ou non.

La forme concrète de cette comparaison est précisément la raison d'être d'une couche de routage, et il vaut la peine d'être exact sur ce que nous hébergeons et ce que nous n'hébergeons pas. AesCode-32B ne figure pas au catalogue d'OrcaRouter et nous ne le servons pas — il n'existe aucun point de terminaison hébergé pour ce modèle, où que je puisse le vérifier, y compris chez Microsoft. Ce qui figure au catalogue, c'est l'autre côté de la table : les modèles hébergés auxquels vous compareriez un générateur d'artefacts auto-hébergé, notamment GPT-5.5 et les modèles de vision Qwen3-VL plus petits, accessibles avec une seule clé API au prix catalogue du fournisseur, avec 0 % de marge, ce qui signifie queun changement de prix du fournisseur est répercuté chez nous le jour même. Comparer un point de terminaison loué à un modèle que vous exécutez vous-même ne nécessite ni un second contrat ni un second SDK, et un DSL de routage permet de placer un appel auto-hébergé à côté d'appels hébergés derrière un point de terminaison unique. Si AesCode-32B s'avère bon dans la seule chose que sa fiche revendique, le coût pour le vérifier se résume à une facture de GPU, et le coût des alternatives auxquelles vous le comparez se résume à une clé que vous possédez probablement déjà.

Ce que vous pouvez en faire aujourd’hui, et ce qui n’existe pas

• Téléchargez-le et exécutez-le — les poids sont sous licence Apache 2.0, suivant le backbone Qwen3-VL, avec quatorze shards BF16 et un chemin fonctionnel de transformers au-dessus de la version 4.7, ainsi qu’une recette vLLM dans la fiche.

• Reproduisez l’entraînement — le code est sous licence MIT et suffisamment complet pour être significatif : le vérificateur de récompense, le constructeur de rubriques, les étapes SFT et GDPO, un commit verl épinglé ainsi que le patch qui ajoute la prise en charge de Qwen3-VL, et un README qui répertorie les modes de défaillance plutôt que de les cacher.

• L'évaluer sans référence — le modèle accepte des prompts avec ou sans l'image de référence, et l'affirmation la plus vérifiable de la fiche réside précisément dans cette configuration.

• Obtenir une API pour cela — impossible. Il n’existe aucun point de terminaison hébergé, aucun mappage de fournisseur d’inférence sur le dépôt, et aucun build GGUF ou MLX ; l’exécuter revient à faire tourner le matériel.

• Lisez l’article — vous ne pouvez pas encore. La fiche renvoie à un article intitulé AesCode: Aesthetic Code Generation with Decoupled Cross-Modal Rewards, et sa propre entrée BibTeX indique comme lieu de publication « Under review » et comme année 2027. Une recherche sur arXiv ne renvoie aucun article portant ce titre. Il existe un autre article Microsoft, antérieur, au nom presque identique — Code Aesthetics with Agentic Reward Feedback d’octobre 2025, qui a publié un modèle AesCoder-4B et un jeu de données AesCode-358K — et rien dans la fiche AesCode-32B ne le cite ni n’indique de relation avec lui. Si vous partez chercher des lectures de contexte et tombez sur celui-là à la place, vous lisez au sujet d’un modèle différent construit par des auteurs en partie communs.

• Le comparer sur un classement public — pas encore. Aucun index tiers ne semble l’avoir évalué, ce qui n’a rien d’étonnant pour un dépôt comptant deux téléchargements.

Qui devrait s'en soucier, et qui devrait attendre

Le public visé ici est plus étroit que ne le suggère le tableau de tête, et plus spécifique que « quiconque construit avec des modèles ». Si votre produit transforme des prompts en présentations, affiches, rapports ou tableaux de bord que quelqu'un doit ensuite modifier, vous avez déjà découvert le choix auquel ce modèle s'adresse : la génération d'images vous donne un beau rectangle que vous ne pouvez pas changer, et la génération de code vous donne quelque chose de modifiable qui ressemble à ce qu'un compilateur aurait assemblé. Un modèle open-weights de 33B qui produit un document HTML complet avec de vrais tableaux et des spécifications ECharts, qui reste à environ un point de sa qualité conditionnée par une référence lorsque vous n'avez aucune référence à lui fournir, et que vous pouvez affiner sur votre propre style maison sous Apache 2.0, est une chose réellement utile à voir exister. Aucun autre modèle ne fait exactement ce travail à cette taille avec ces conditions.

En contrepartie : tout ce que vous savez sur la qualité vient d'un tableau construit par le fournisseur, la grille d'évaluation qui le sous-tend a été produite par le même pipeline que celui qui a fabriqué les données d'entraînement, et le seul plafond que la fiche reconnaît — Style inférieur à 60 pour chaque système testé — est précisément la dimension qui importerait le plus à un produit sensible au design. Une équipe ayant une raison de conformité de garder la génération en interne et un nœud de huit GPU en réserve a de quoi commencer dès aujourd'hui. Une équipe qui choisit un modèle pour la production la semaine prochaine n'a aucun chiffre indépendant sur lequel fonder son choix, et ne devrait pas interpréter le 85,89 face au 81,28 comme un résultat définitif.

Qu'est-ce qui transformerait ceci en une histoire

Quatre choses, dont aucune n'existe encore. Une annonce — Microsoft n'a rien dit, et l'article auquel la fiche fait référence est explicitement en cours d'évaluation, donc un rapport technique avec des détails d'entraînement au-delà du résumé de la fiche pourrait apparaître à tout moment. Une exécution indépendante — l'affirmation de robustesse sans référence et le score Boundary, dont la fiche indique qu'il tombe à un échec sévère sur 4,3 % des échantillons contre 34,7 % pour GPT-5.5, sont tous deux peu coûteux à tester et tous deux valent la peine d'être testés. Une prise en charge du serving en dehors de la recette du fournisseur — une compilation GGUF ou une entrée dans un runtime grand public changerait davantage la donne côté matériel que ne le ferait n'importe quel benchmark. Et un second point de données sur la question de la taille : un modèle 8B obtenant 82,94 Overall contre 85,89 pour le 32B dans le même tableau représente un écart de deux points pour un quart des paramètres, le genre de chose qui, soit finit par être reproduite, soit cesse discrètement d'être mentionnée.

Tant que l’un de ces éléments ne se concrétise pas, la description exacte d’AesCode-32B est la suivante : de vrais poids sous une licence permissive, une pile d’entraînement suffisamment détaillée pour être reproduite par un laboratoire bien équipé, un tableau de benchmarks qui est la mesure, par une entreprise, de son propre modèle et de deux modèles concurrents, et un historique de dépôt qui ne vous permettra pas de désigner un seul jour comme date de lancement. C’est un artefact plus intéressant que ne le suggère son compteur de deux téléchargements, et moins prouvé que ne le laisse entendre son 85.89. Les deux moitiés de cette phrase constituent la lecture honnête au 11 octobre 2026.