AesCode-8B släpptes i tysthet: Microsofts 8B-modell skriver presentationer och dashboards som HTML

Det mest intressanta talet i Microsofts nya lansering är 1,00. Utelämna referensbilden från AesCode-8B – en modell med 8 miljarder parametrar som skriver presentationsbilder, affischer och dashboards som redigerbar HTML och CSS – och dess visuella poäng sjunker med en poäng av hundra. Utelämna samma referens från Qwen3-VL-8B-Instruct, öppenviktsmodellen som AesCode-8B finjusterades från, och nedgången är 19,55 poäng. Från GPT-5.5 är den 10,04. Den jämförelsen är där det faktiska forskningsresultatet ligger, och den finns under en rubrik som Microsoft också publicerade: på sin egen bedömningsmatris med 300 exempel har AesCode-8B en totalpoäng på 82,94 som snäppet överträffar referenskonditionerade GPT-5.5 på 81,28 och Claude Opus 4.8 på 80,39, med en större syskonmodell, AesCode-32B, på 85,89.

Ingenting om detta släpp tillkännagavs. Microsoft committade vikterna på Hugging Face 2026-10-07 under Apache 2.0 — AesCode-8B plus en 32B-kompanjon byggd på samma sätt från Qwen3-VL-32B-Instruct — och pushade tränings- och utvärderingskoden till GitHub dagen därpå. Det finns inget blogginlägg från Microsoft Research, inget utgivningsmeddelande, ingen produktsida och inget preprint: referensen i modellkortet lyder "Under review", år 2027, vilket är en platshållare snarare än ett datum. Per 2026-10-11 visar 8B-repositoriet två nedladdningar och en like; GitHub-repositoriet visar en stjärna. Allt nedan som innehåller en siffra är antingen en tidsstämpel du själv kan verifiera eller ett värde som Microsoft rapporterat om sin egen utvärderingsuppsättning — och den distinktionen spelar större roll än vanligt här, eftersom ingen del av den här modellen har mätts av någon annan.

Vad som levererades, och vad som inte finns i lådan

Tre datum definierar denna utgåva, och de är de enda datumen i den. Hugging Face-repositoriet för microsoft/AesCode-8B skapades den 2026-09-29, vikterna committades med meddelandet "Release AesCode-8B" kl. 03:35 UTC den 2026-10-07, och microsoft/AesCode-kodrepositoriet blev offentligt dagen därpå, 2026-10-08 kl. 23:14 UTC. 32B-vikterna landade i samma commitfönster. Ingenting däremellan tillkännagavs någonstans.

• Vikter — fyra safetensors-delar med totalt 17 543 339 408 byte, vilket motsvarar ungefär 8,8 miljarder bf16-parametrar. Microsoft anger modellen som 8B; Hugging Faces storleksfält avrundar storleken till 9B. Det är avrundning, inte en avvikelse.

• Arkitektur — en direkt finjustering av Qwen3-VL-receptet: Qwen3VLForConditionalGeneration, 36 dolda lager, dold storlek 4 096, 32 uppmärksamhetshuvuden med 8 nyckel-värde-huvuden, en ordlista på 151 936 token och interfolierade mrope-positioner. Den behöver transformers 4.57 eller senare.

• Kontext och utdata — de rapporterade körningarna använde en kontext på 24 576 token med upp till 12 000 utdatatoken, genererade vid temperatur 0,8 och top-p 0,95 över tre rollouts per prompt utan selektion. vLLM-serveringskommandot tillåter två bilder per prompt: referensen, och inget annat, eftersom utdata är text.

• Licens — Apache 2.0, beskrivs följa Qwen3-VL-stommen. Helt tillåtande, ingen åtkomstbegränsning, inget tillägg om godtagbar användning.

• Ingår inte — tränings- och utvärderingsdata. Repositoriet levererar pipelinen och dokumenterar förväntade indata och utdata, och nämner de split-filer den förväntar sig, men ingen datasetutgåva listas på varken modellkortet eller kodrepot. Du får receptet, inte ingredienserna.

• Inte heller i lådan — någon hostad slutpunkt. Vi kunde inte hitta något API som serverar AesCode-8B någonstans, och den finns inte i vår egen katalog. Tills en leverantör plockar upp den innebär utvärdering av den att ladda in vikterna på dina egna GPU:er.

Den formulering Microsoft använder är värd att citera eftersom den utgör hela designbriefen: kodmodeller ”kan inte se hur layout, hierarki och färg samverkar på canvasen”, medan bildgeneratorer ”komponerar visuellt övertygande sidor men återger ofta text, siffror och logiska samband felaktigt”. AesCode är försöket att ta kompositionskänslan från den ena och verifierbarheten från den andra.

Resultatet på 1,00 poäng, förklarat

Här är mekanismen bakom siffran i första stycket. Under träning paras varje prompt med en referensbild som genereras från samma prompt – Microsofts egna körningar använde GPT-Image-2 för bilden och GPT-5.5 för att expandera en kort idé till den detaljerade innehållsprompten. Referensen har ingen innehållsauktoritet; textprompten förblir sanningens källa. Det referensen tillhandahåller är layout och stil, och belöningsfunktionen är byggd för att hålla dessa två saker åtskilda.

Konsekvensen är att den visuella priorn hamnar i policyn i stället för i indatan. AesCode-8B förlorar 1,00 Visual-poäng när referensen tas bort vid inferens. Dess egen backbone, utvärderad referenskonditionerad på 44,72 Visual, förlorar 19,55 poäng utan en. GPT-5.5 förlorar 10,04. Den destillerade versionen av det: modellen slutade behöva bilden.

Den andra hälften av resultatet är den som är lätt att missa. Microsoft rapporterar att referensbaserade belöningar höjde Visual med enbart prompt från 25,17 till 69,71 – modellen som aldrig ser en referens vid inferenstid har fortfarande nytta av att ha tränats mot dem. Om du planerade att hoppa över referensgenereringssteget i din egen pipeline, är det siffran som säger att du inte heller bör besvära dig med att hoppa över det i träningen.

Det ärliga förbehållet för allt detta: detta är Microsofts bedömningsschema, på Microsofts 300 infografikexempel, poängsatt tre gånger per prompt utan att välja ut de bästa resultaten. Hälften av poängen kommer från deterministiska verifierare, som vem som helst skulle kunna reproducera; den andra halvan, checklistdimensionerna, bedöms av en bild- och språkmodell vars identitet dokumentationen inte namnger. Du kan inte reproducera den andra halvan utan att veta vilken domare som producerade den.

Där smaken kommer in i vikterna

Träningsmetoden är den del av den här utgåvan som har de mest överförbara idéerna, och den är mer mekanisk än resultatet antyder.

• Allt är en graf först. Varje mål representeras som en designgraf: noder för text, diagram, tabeller, kort, regioner och bildplatser, och kanter för inneslutning, justering, ordning och koppling. Poängen med grafen är attribution – varje egenskap på arbetsytan tillhör ett namngivet element, så varje egenskap kan poängsättas var för sig.

• Sju belöningskanaler. Sex deterministiska verifierare kontrollerar det som kan parsas — exekvering, exakt text, gränser, tabell- och diagramdata, semantisk layout, blanksteg — och en samplespecifik Visual Graph Rubric, uppbyggd som grafbundna ja/nej-frågor om geometri och placering, poängsätter resten. Kanalerna är exekvering, text, gräns, tabell+diagram, layout, blanksteg och design.

• Kanalerna normaliseras innan de kombineras. GDPO normaliserar varje kanal inom sin rollout-grupp, så att en tät regelbaserad signal inte kan dränka den glesa visuella signalen. Microsoft mäter detta till 5,12 Visual-poäng jämfört med vanlig skalär GRPO med samma upplägg – leverantörsrapporterat, men en konkret ablation snarare än ett påstående.

• Bedömning sker genom rendering.Kandidat-HTML renderas i en sandlådad Playwright-webbläsare med externa förfrågningar blockerade, och testramverket läser tillbaka DOM, beräknade stilar, avgränsningsrutor, konsolstatus och en skärmbild. Tabeller måste vara HTML-tabeller; diagram måste vara ECharts-specifikationer. Den begränsningen gör verkligt arbete – den tvingar utdata till en form som en verifierare kan tolka.

• Själva receptet. Kallstartad övervakad finjustering på 3 000 demonstrationer med en inlärningshastighet på 1e-5, sedan GDPO över 7 408 promptar under 400 steg på verls FSDP-vLLM-hybridmotor, utan kritiker och utan separat tränad belöningsmodell. AdamW vid en konstant 5e-6, ingen uppvärmning, viktnedgång 0,01, 128 promptar per steg med 8 utrullningar vardera, KL- och entropikoefficienter båda 0,001, prompt och svar vardera begränsade till 8 192 tokens. De släppta körningarna använde en enda nod med åtta NVIDIA B200. AesCode-32B använder samma recept i 520 steg.

Läst i sin helhet är detta en artikel om belöningsdesign som bär ett modellsläpp som kostym – och det ligger i linje med att citeringen anger "Under review" snarare än att peka på en preprint.

Resultattavlan, och vem som går i god för den

Allt följande är Microsofts egen utvärdering, rapporterad i modellkortet, på 300 infografikprover. Rule är medelvärdet av de programmatiska kontrollerna Text, Bound och Chart; Visual är medelvärdet av checklistdimensionerna Content, Layout och Style; Overall är medelvärdet av de två. Poängen är procenttal som genomsnittats över tre generationer per prompt utan selektion. "Ref." markerar om modellen fick en genererad referens tillsammans med prompten.

• AesCode-8B med referens — Text 94,06, Gräns 88,36, Diagram 87,79, Regel 90,07; Innehåll 86,41, Layout 87,80, Stil 53,21, Visuell 75,80; Totalt 82,94.

• Mot sin egen basmodell — referensbetingad Qwen3-VL-8B-Instruct får Visual 44,72 och Overall 51,93. Det är en ökning på 31,1 poäng för Visual och 31,0 poäng för Overall, och det är den minst överraskande jämförelsen i tabellen, eftersom hela poängen med träningen är den visuella halvan.

• Jämfört med GPT-5.5, referensbetingad — Totalt 81,28, Innehåll 82,44, Layout 89,93 och Stil 57,91.

• Mot Claude Opus 4.8, referensbetingad — Totalt 80,39, Innehåll 86,42, Layout 89,76.

• AesCode-32B, referenskonditionerad — Text 95,34, Bound 97,27, Chart 90,37, Rule 94,33, Layout 90,58, Visual 77,44, Overall 85,89. Tjugotvå komma fyra poäng Visual över dess egen 32B-backbone.

• Style-taket — ingen modell i tabellen passerar 60, och GPT-5.5:s 57,91 är bäst av dem. AesCode-8B ligger på 53,21. Microsofts egen definition är obeveklig: Style ger en design poäng först när den inte kräver ytterligare visuella revideringar före leverans. Så på den enda dimension som mäter huruvida en människa faktiskt skulle leverera sidan oredigerad, är 8B-modellen inte ledaren.

• Gränsfel — ett allvarligt canvas-överflödesfel återkommer i 4,3 % av de 300 samplen, jämfört med 34,7 % för GPT-5.5. Överflöd är det felmönster som gör genererad HTML oanvändbar i stället för bara ful.

Nu till den del som är lika viktig som tabellen. Varje siffra ovan är leverantörsrapporterad och inte reproducerad. AesCode-8B finns inte med på någon oberoende resultattavla som vi kunde hitta, och jämförelsen mot GPT-5.5 och Claude Opus 4.8 körs enligt Microsofts bedömningsmall, på en uppgift som dessa modeller inte var finjusterade för, med en definition av "Layout" som belönar att över huvud taget producera en sida. En Text-poäng på 94,06 betyder inte att den här modellen slår GPT-5.5 i text. Det betyder att den placerar etiketter utan att motsäga prompten på infografiska sidor, vilket är ett mycket mindre påstående. Style-resultatet är det som avslöjar att bedömningsmallen inte är riggad till AesCode:s fördel – den största vinsten på resultattavlan kommer med den största ofördelaktiga siffran alldeles intill.

Vad är bekräftat, och vad är inte

Eftersom detta släpptes i tysthet är det värt att explicit skilja de två åt.

• Bekräftat — vikterna finns och går att ladda ner under Apache 2.0; de två tidsstämplarna för släppen finns i repon; arkitekturen, parameterantalet, kontextlängden och samplingsinställningarna finns alla i den publicerade configen och modellkortet; träningsreceptet och belöningsdesignen är dokumenterade i tillräcklig detalj för att kunna argumentera emot; koden, verifieringsstacken och rubric-byggaren är offentliga; det finns en 32B-kompanjon.

• Ej bekräftat — några av benchmark-siffrorna, av någon annan än leverantören. Artikeln, som dokumentationen själv beskriver som under granskning. Identiteten hos vision-language-bedömaren bakom den visuella halvan av poängen. Huruvida någon leverantör kommer att hosta den. Huruvida kontextfönstret på 24 576 token håller måttet på riktiga bildspel med flera slides, eftersom den rapporterade utvärderingen gäller enskilda infografiska sidor. Och överhuvudtaget något om beteende utanför engelska — modellkortets språktagg är enbart "en".

Om du vill köra det, och vad det kostar

Qwen3-VL-8B-Instruct – modellen som AesCode-8B finjusterades från, och den starkaste enskilda jämförelsen som finns tillgänglig tills någon publicerar ett oberoende AesCode-resultat – är en annan sak:

Serveringsvägen för AesCode-8B i sig är kort, och modellkortet anger den direkt: vllm serve microsoft/AesCode-8B --limit-mm-per-prompt image=2 --max-model-len 24576, med transformers 4.57 eller nyare för icke-vLLM-vägen, och ett Python-kodavsnitt som accepterar en valfri referensbild före textprompten.

Aritmetiken du själv måste sköta är minnet. 17,5 GB bf16-vikter måste rymmas tillsammans med en KV-cache för en kontext på 24 576 token och upp till två bilder, så ett enda 24 GB-kort räcker tekniskt sett för vikterna men är obehagligt trångt för allt annat; 40–48 GB, eller två 24 GB-kort, är den realistiska lägstanivån. 32B-följeslagaren är ett problem av en annan storleksordning – dess shards uppgår sammanlagt till 66,7 GB, så den kräver tensorparallellism och en multi-GPU-nod. Räkna även med en renderare: modellen genererar ett komplett HTML-dokument, och varje kvalitetsomdöme om det görs genom att rendera dokumentet, så att poängsätta dina egna utdata innebär att sätta upp Playwright med externa förfrågningar blockerade.

Du behöver inte generera en referensbild vid inferens — det är precis vad resultatet på 1,00 poäng ger dig — men dokumentationen är tydlig med att kvaliteten fortfarande är högst när en sådan tillhandahålls, så det ärliga upplägget är referensvalfritt snarare än referensfritt.

AesCode-8B är inte något som OrcaRouter routar, och vi kunde inte hitta det hostat någon annanstans heller, så en utvärdering innebär för närvarande vikter på din egen hårdvara. Dess ryggrad är en annan historia. Qwen3-VL-8B-Instruct kan routas via OrcaRouter idag för $0,18 per miljon indatatokens och $0,70 per miljon utdatatokens, med en kontext på 131 072 tokens — vilket gör det till det billiga sättet att se vad den ofinjusterade versionen av den här arkitekturen gör med dina egna infografikpromptar innan du lägger en GPU-vecka på att reproducera någon annans recept. OrcaRouter förmedlar leverantörens listpris vidare med 0 % påslag och växlar automatiskt över mellan leverantörer, så den jämförelsen kostar en nyckel och inget andra avtal; om AesCode-8B någonsin hamnar hos en leverantör som vi routar, finns det i katalogen samma dag. Och om du självhostar det, modellerna du skulle falla tillbaka på i produktion är de som redan ligger bakom den där enda slutpunkten — vilket är den rimliga hållningen för en tyst lanserad modell med noll oberoende utvärdering.

Vad du ska titta på

Två saker, och ingen av dem är ännu en benchmark-tabell.

Det första är artikeln. "AesCode: Aesthetic Code Generation with Decoupled Cross-Modal Rewards" anges som under granskning för 2027, vilket framstår som en platshållare inskriven i en BibTeX-post snarare än ett schema. Tills en preprint eller en camera-ready-version dyker upp är förklaringen av belöningskanalen ovan en sammanfattning av ett abstract som ingen utanför labbet kan läsa — och de intressanta frågorna, som hur Visual Graph Rubric hanterar en designgraf som i sig är fel, besvaras bara i fulltexten.

Det andra är hosting. En 8,8B Apache-2.0-modell som genererar strukturerad, verifierbar HTML är precis den form som en plattform plockar upp, eftersom utdata går att granska på ett sätt som en JPEG inte gör. I samma stund som någon servar den upphör detta att vara ett beslut om egen hosting och blir ett routingbeslut — och kostnadsjämförelsen handlar inte längre om GPU-timmar.

Det man inte ska förvänta sig är en entydig dom. Style är taket för varje system i den tabellen, inklusive detta, och Style är den enda dimensionen som ställer frågan om en människa skulle släppa sidan som den är. Den försvarbara tolkningen av AesCode-8B är snäv och verklig: den är mycket bra på de delar av visuell design som kan kontrolleras av en maskin, den är medelmåttig på den del som inte kan det, och den är den första modellen med öppna vikter i den här nischen där gapet mellan dessa två saker är själva poängen med släppet snarare än en tillfällighet.