AesCode-8B is geruisloos verschenen: het 8B-model van Microsoft schrijft slides en dashboards als HTML

Het interessantste getal in Microsofts nieuwe release is 1,00. Onthoud de referentieafbeelding aan AesCode-8B — een model met 8 miljard parameters dat dia's, posters en dashboards als bewerkbare HTML en CSS schrijft — en zijn visuele score daalt met één punt op de honderd. Onthoud dezelfde referentie aan Qwen3-VL-8B-Instruct, het open-weightmodel waarop AesCode-8B is fine-tuned, en de daling is 19,55 punten. Bij GPT-5.5 is die 10,04. In die ene vergelijking zit het eigenlijke onderzoeksresultaat, en het ligt onder een kop die Microsoft ook publiceerde: op zijn eigen rubric met 300 voorbeelden overtroeft de totale score van AesCode-8B van 82,94 nipt die van referentiegeconditioneerde GPT-5.5 met 81,28 en van Claude Opus 4.8 met 80,39, met een groter broertje, AesCode-32B, op 85,89.

Over deze release is niets aangekondigd. Microsoft heeft de gewichten op 2026-10-07 op Hugging Face onder Apache 2.0 gecommit — AesCode-8B plus een begeleidend 32B-model dat op dezelfde manier is gebouwd op basis van Qwen3-VL-32B-Instruct — en heeft de trainings- en evaluatiecode de volgende dag naar GitHub gepusht. Er is geen blogpost van Microsoft Research, geen release-opmerking, geen productpagina en geen preprint: de citatie in de modelkaart luidt "Under review", jaartal 2027, wat een plaatsaanduiding is en geen datum. Op 2026-10-11 toont de 8B-repository twee downloads en één like; de GitHub-repository toont één ster. Alles hieronder dat een getal bevat, is ofwel een tijdstempel die je zelf kunt verifiëren, ofwel een cijfer dat Microsoft over zijn eigen evaluatieset heeft gerapporteerd — en dat onderscheid is hier belangrijker dan gewoonlijk, omdat geen enkel deel van dit model door iemand anders is gemeten.

Wat is geleverd, en wat zit niet in de doos

Drie datums definiëren deze release, en het zijn de enige datums erin. De Hugging Face-repository voor microsoft/AesCode-8B is op 2026-09-29 aangemaakt, de gewichten zijn vastgelegd in een commit met het bericht "Release AesCode-8B" om 03:35 UTC op 2026-10-07, en de microsoft/AesCode code-repository werd de volgende dag openbaar, op 2026-10-08 om 23:14 UTC. De 32B-gewichten kwamen in hetzelfde commit-venster binnen. Niets daartussen werd ergens aangekondigd.

• Gewichten — vier safetensors-shards met in totaal 17.543.339.408 bytes, wat neerkomt op ongeveer 8,8 miljard bf16-parameters. Microsoft noemt het model 8B; het grootteveld van Hugging Face rondt het af naar 9B. Dat is afronding, geen discrepantie.

• Architectuur — een rechtstreekse fine-tune van het Qwen3-VL-recept: Qwen3VLForConditionalGeneration, 36 verborgen lagen, verborgen grootte 4.096, 32 aandachtshoofden met 8 key-value-hoofden, een vocabulaire van 151.936 tokens en interleaved mrope-posities. Het heeft transformers 4.57 of later nodig.

• Context en uitvoer — de gerapporteerde runs gebruikten een context van 24.576 tokens met maximaal 12.000 uitvoertokens, gegenereerd bij een temperatuur van 0,8 en top-p 0,95 over drie rollouts per prompt zonder selectie. Het vLLM-serveercommando staat twee afbeeldingen per prompt toe: de referentie, en niets anders, omdat de uitvoer tekst is.

• Licentie — Apache 2.0, naar verluidt volgens de Qwen3-VL-backbone. Volledig permissief, geen gating, geen addendum voor aanvaardbaar gebruik.

• Niet in de doos — de trainings- en evaluatiedata. De repository bevat de pipeline en documenteert de verwachte inputs en outputs, en vermeldt de splitbestanden die hij verwacht, maar er wordt geen datasetrelease genoemd, noch op de modelkaart, noch in de code-repo. Je krijgt het recept, niet de ingrediënten.

• Ook niet inbegrepen — geen enkele gehoste endpoint. We konden nergens een API vinden die AesCode-8B aanbiedt, en het staat niet in onze eigen catalogus. Totdat een aanbieder het oppikt, betekent het evalueren ervan dat je de gewichten op je eigen GPU's moet laden.

De framing die Microsoft gebruikt, is het citeren waard, want het is de hele ontwerpopdracht: codemodellen "kunnen niet zien hoe lay-out, hiërarchie en kleur samenkomen op het canvas", terwijl beeldgeneratoren "visueel aantrekkelijke pagina's samenstellen, maar tekst, cijfers en logische verbanden vaak verkeerd weergeven." AesCode is de poging om het compositiegevoel van de een en de verifieerbaarheid van de ander te nemen.

Het resultaat van 1,00 punt, uitgelegd

Hier is het mechanisme achter het getal in de eerste alinea. Tijdens de training wordt elke prompt gekoppeld aan een referentieafbeelding die op basis van diezelfde prompt is gegenereerd — Microsofts eigen runs gebruikten GPT-Image-2 voor de afbeelding en GPT-5.5 om een kort idee uit te breiden tot de gedetailleerde contentprompt. De referentie heeft geen inhoudelijke autoriteit; de tekstprompt blijft de bron van waarheid. Wat de referentie levert, zijn lay-out en stijl, en de beloningsfunctie is erop gebouwd om die twee zaken gescheiden te houden.

Het gevolg is dat de visuele prior in de policy terechtkomt in plaats van in de invoer. AesCode-8B verliest 1,00 Visual-punt wanneer de referentie bij inferentie wordt verwijderd. Zijn eigen backbone, geëvalueerd met referentieconditionering op 44,72 Visual, verliest 19,55 punten zonder referentie. GPT-5.5 verliest 10,04. De gedistilleerde versie daarvan: het model had het beeld niet meer nodig.

De tweede helft van het resultaat is juist het deel dat men gemakkelijk over het hoofd ziet. Microsoft meldt dat op referenties gebaseerde beloningen prompt-only Visual van 25,17 naar 69,71 hebben getild — het model dat tijdens de inferentie nooit een referentie te zien krijgt, profiteert er nog steeds van dat het ertegen is getraind. Als u van plan was de stap voor het genereren van referenties in uw eigen pipeline over te slaan, dan is dat het getal dat zegt dat u die in de training net zo goed niet kunt overslaan.

Het eerlijke voorbehoud bij dit alles: dit is Microsofts rubric, op Microsofts 300 infographic-voorbeelden, drie keer per prompt beoordeeld zonder cherry-picking. De helft van de score komt van deterministische verifieerders, die iedereen zou kunnen reproduceren; de andere helft, de checklist-dimensies, wordt beoordeeld door een vision-language model waarvan de documentatie de identiteit niet vermeldt. Je kunt de tweede helft niet reproduceren zonder te weten welke beoordelaar die heeft geproduceerd.

Waar de smaak in de gewichten komt

De trainingsmethode is het onderdeel van deze release met de meest overdraagbare ideeën, en ze is mechanischer dan de output doet vermoeden.

• Alles is in de eerste plaats een graaf. Elk doel wordt weergegeven als een ontwerpgraaf: knooppunten voor tekst, grafieken, tabellen, kaarten, regio's en afbeeldingsslots, en randen voor insluiting, uitlijning, volgorde en verbinding. Het doel van de graaf is attributie — elke eigenschap op het canvas behoort tot een benoemd element, zodat elke eigenschap afzonderlijk kan worden gescoord.

• Zeven beloningskanalen. Zes deterministische verifieerders controleren de parseerbare zaken — uitvoering, exacte tekst, grenzen, tabel- en grafiekgegevens, semantische lay-out, witruimte — en een samplespecifieke Visual Graph Rubric, opgebouwd als grafiekgebonden ja/nee-vragen over geometrie en plaatsing, beoordeelt de rest. De kanalen zijn uitvoering, tekst, grens, tabelgrafiek, lay-out, witruimte en ontwerp.

• De kanalen worden genormaliseerd voordat ze worden gecombineerd. GDPO normaliseert elk kanaal binnen zijn rolloutgroep, zodat een dicht, op regels gebaseerd signaal het sparse visuele signaal niet kan overstemmen. Microsoft meet dit op 5,12 Visual-punten bovenop gewone scalaire GRPO met dezelfde opzet — door de leverancier gerapporteerd, maar een concrete ablatie in plaats van een bewering.

• Beoordeling gebeurt door rendering.Kandidaat-HTML wordt gerenderd in een Playwright-browser in een sandbox met geblokkeerde externe verzoeken, en het testharnas leest de DOM, berekende stijlen, begrenzingsboxen, consolestatus en een schermafbeelding terug. Tabellen moeten HTML-tabellen zijn; grafieken moeten ECharts-specificaties zijn. Die beperking doet echt werk — ze dwingt de uitvoer in een vorm die een verificateur kan parsen.

• Het recept zelf. Supervised fine-tuning met een koude start op 3.000 demonstraties met een leersnelheid van 1e-5, daarna GDPO op 7.408 prompts gedurende 400 stappen op de FSDP-vLLM hybride engine van verl, zonder critic en zonder apart getraind beloningsmodel. AdamW met een constante 5e-6, geen warmup, weight decay 0,01, 128 prompts per stap met elk 8 rollouts, KL- en entropiecoëfficiënten beide 0,001, prompt en respons elk beperkt tot 8.192 tokens. De vrijgegeven runs gebruikten een enkele node met acht NVIDIA B200's. AesCode-32B gebruikt hetzelfde recept voor 520 stappen.

Als geheel gelezen is dit een paper over beloningsontwerp dat een modelrelease als kostuum draagt — en dat is consistent met het feit dat de citatie "Under review" luidt in plaats van naar een preprint te verwijzen.

Het scorebord, en wie ervoor instaat

Alles wat volgt is Microsofts eigen evaluatie, gerapporteerd in de modelkaart, op 300 infographic-voorbeelden. Regel berekent het gemiddelde van de programmatische controles op Tekst, Begrenzing en Grafiek; Visueel berekent het gemiddelde van de checklistdimensies Inhoud, Lay-out en Stijl; Totaal is het gemiddelde van de twee. Scores zijn percentages die zijn gemiddeld over drie generaties per prompt, zonder selectie. "Ref." geeft aan of het model een gegenereerde referentie naast de prompt kreeg.

• AesCode-8B met referentie — Tekst 94,06, Grens 88,36, Grafiek 87,79, Regel 90,07; Inhoud 86,41, Lay-out 87,80, Stijl 53,21, Visueel 75,80; Totaal 82,94.

• Tegen zijn eigen backbone — reference-conditioned Qwen3-VL-8B-Instruct scoort Visual 44.72 en Overall 51.93. Dat is een winst van 31.1 punten op Visual en 31.0 punten op Overall, en het is de minst verrassende vergelijking in de tabel, aangezien het hele doel van de training de visuele helft is.

• Tegen GPT-5.5, referentie-geconditioneerdTotaal 81.28, Inhoud 82.44, Lay-out 89.93 en Stijl 57.91.

• Tegen Claude Opus 4.8, referentie-geconditioneerd — Totaal 80,39, Inhoud 86,42, Lay-out 89,76.

• AesCode-32B, referentiegeconditioneerd — Tekst 95,34, Grens 97,27, Grafiek 90,37, Regel 94,33, Indeling 90,58, Visueel 77,44, Totaal 85,89. Tweeëntwintig komma vier punten Visueel boven zijn eigen 32B-backbone.

• Het stijlplafond — geen enkel model in de tabel komt boven de 60 uit, en de 57,91 van GPT-5.5 is de beste daarvan. AesCode-8B staat op 53,21. De eigen definitie van Microsoft is onverbiddelijk: Style kent een ontwerp alleen punten toe wanneer het geen verdere visuele revisie voor oplevering nodig heeft. Dus op de enige dimensie die meet of een mens de pagina daadwerkelijk ongewijzigd zou opleveren, is het 8B-model niet de koploper.

• Grensfouten — een ernstige fout door canvasoverloop duikt op bij 4,3% van de 300 samples, tegenover 34,7% bij GPT-5.5. Overloop is de foutmodus die gegenereerde HTML onbruikbaar maakt in plaats van alleen maar lelijk.

Nu het deel dat net zo belangrijk is als de tabel. Elk cijfer hierboven is door de leverancier opgegeven en niet gereproduceerd. AesCode-8B staat op geen enkele onafhankelijke ranglijst die wij konden vinden, en de vergelijking met GPT-5.5 en Claude Opus 4.8 wordt uitgevoerd volgens Microsofts beoordelingskader, op een taak waarvoor die modellen niet zijn afgestemd, met een definitie van "Layout" die beloont dat er überhaupt een pagina wordt geproduceerd. Een Text-score van 94,06 betekent niet dat dit model GPT-5.5 verslaat op tekst. Het betekent dat het labels plaatst zonder de prompt tegen te spreken op infographicpagina's, wat een veel kleinere claim is. Het Style-resultaat verraadt dat het beoordelingskader niet in het voordeel van AesCode is gemanipuleerd — de grootste scorebordoverwinning gaat gepaard met het meest onflatteuze cijfer dat er direct naast staat.

Wat is bevestigd, en wat niet

Omdat dit geruisloos is uitgebracht, is het de moeite waard om de twee expliciet te scheiden.

• Bevestigd — de gewichten bestaan en zijn downloadbaar onder Apache 2.0; de twee releasedatums staan in de repositories; de architectuur, het aantal parameters, de contextlengte en de sampling-instellingen staan allemaal in de gepubliceerde config en modelkaart; het trainingsrecept en het beloningsontwerp zijn gedocumenteerd in voldoende detail om mee in discussie te gaan; de code, verifier-stack en rubric-builder zijn openbaar; er bestaat een 32B-metgezel.

• Niet bevestigd — geen van de benchmarkcijfers, door iemand anders dan de leverancier. De paper, die in de documentatie zelf als under review wordt beschreven. De identiteit van de vision-language judge achter de visuele helft van de scores. Of een aanbieder het zal hosten. Of de context van 24.576 tokens standhoudt op echte presentaties met meerdere dia's, aangezien de gerapporteerde evaluatie op afzonderlijke infographicpagina's is. En überhaupt iets over gedrag buiten het Engels — de taaltag van de modelkaart is alleen "en".

Als je het wilt uitvoeren, en wat dat kost

Qwen3-VL-8B-Instruct — het model waarop AesCode-8B is gefinetuned, en de sterkste enkele vergelijking die beschikbaar is totdat iemand een onafhankelijk AesCode-resultaat publiceert — is een andere kwestie:

Het serverpad voor AesCode-8B zelf is kort, en de modelkaart geeft het direct weer: vllm serve microsoft/AesCode-8B --limit-mm-per-prompt image=2 --max-model-len 24576, met transformers 4.57 of nieuwer voor de niet-vLLM-route, en een Python-fragment dat een optionele referentieafbeelding vóór de tekstprompt accepteert.

Het rekenwerk dat je zelf moet doen, is geheugen. 17,5 GB aan bf16-gewichten moet samen met een KV-cache voor een context van 24.576 tokens en maximaal twee afbeeldingen passen, dus een enkele kaart van 24 GB is technisch genoeg voor de gewichten en onaangenaam krap voor al het overige; 40-48 GB, of twee kaarten van 24 GB, is de realistische ondergrens. Het bijbehorende 32B-model is een probleem van een andere orde — de shards ervan zijn samen 66,7 GB, dus het heeft tensor-parallelisme en een multi-GPU-node nodig. Reken ook op een renderer: het model levert een compleet HTML-document op, en elke kwaliteitsclaim erover wordt gemaakt door dat document te renderen, dus om je eigen outputs te scoren moet je Playwright opzetten met externe verzoeken geblokkeerd.

Je hoeft tijdens de inferentie geen referentieafbeelding te genereren — dat is precies wat het resultaat van 1,00 punt je oplevert — maar de documentatie is duidelijk dat de kwaliteit nog het hoogst is wanneer er een wordt aangeleverd, dus de eerlijke opzet is referentie-optioneel in plaats van referentievrij.

AesCode-8B is geen model dat OrcaRouter routeert, en we konden het ook nergens anders gehost vinden, dus een evaluatie betekent op dit moment gewichten op je eigen hardware. De backbone ervan is een ander verhaal. Qwen3-VL-8B-Instruct is vandaag routeerbaar via OrcaRouter voor $0,18 per miljoen invoertokens en $0,70 per miljoen uitvoertokens, met een context van 131.072 tokens — wat het de goedkope manier maakt om te zien wat de niet-afgestelde versie van deze architectuur doet met je eigen infographic-prompts, voordat je een GPU-week besteedt aan het reproduceren van andermans recept. OrcaRouter geeft de lijstprijs van de provider door met 0% markup en schakelt automatisch over tussen providers, dus die vergelijking kost één sleutel en geen tweede contract; als AesCode-8B ooit bij een provider terechtkomt die wij routeren, staat het dezelfde dag in de catalogus. En als je het zelf host, dan zijn de modellen waarop je in productie zou terugvallen de modellen die al achter dat ene endpoint zitten — wat de redelijke houding is voor een stil uitgebracht model zonder enige onafhankelijke evaluatie.

Wat te kijken

Twee dingen, en geen van beide is nog een benchmarktabel.

Het eerste is het artikel. "AesCode: Aesthetic Code Generation with Decoupled Cross-Modal Rewards" wordt geciteerd als zijnde under review voor 2027, wat leest als een placeholder die in een BibTeX-entry is getypt in plaats van een planning. Totdat er een preprint of een camera-ready verschijnt, is de hierboven gegeven uitleg over het beloningskanaal een samenvatting van een abstract dat niemand buiten het lab kan lezen — en de interessante vragen, zoals hoe de Visual Graph Rubric omgaat met een ontwerpgraph die zelf fout is, worden alleen in de volledige tekst beantwoord.

Het tweede is hosting. Een Apache-2.0-model van 8,8 miljard dat gestructureerde, verifieerbare HTML produceert, is precies de vorm die een platform oppikt, omdat de output inspecteerbaar is op een manier waarop een JPEG dat niet is. Zodra iemand het serveert, is dit niet langer een self-hostingbeslissing maar wordt het een routingbeslissing — en gaat de kostenvergelijking niet meer over GPU-uren.

Wat je niet moet verwachten, is een eenduidig oordeel. Stijl is het plafond voor elk systeem in die tabel, inclusief dit systeem, en Stijl is de enige dimensie die vraagt of een mens de pagina ongewijzigd zou opleveren. De verdedigbare lezing van AesCode-8B is beperkt en reëel: het is heel goed in de delen van visueel ontwerp die door een machine gecontroleerd kunnen worden, het is middelmatig in het deel dat niet door een machine kan worden gecontroleerd, en het is het eerste open-weight model in deze niche waarin de kloof tussen die twee dingen het punt van de release is in plaats van een toevalligheid ervan.