AesCode-32B: Microsofts tysta 33B-modell som skriver presentationer som redigerbar HTML

Tidsstämplarna för AesCode-32B stämmer inte överens med varandra, och oenigheten är det mesta av vad som finns att rapportera. Hugging Face-repositoriet microsoft/AesCode-32B skapades den 29 september 2026, men allt i det kom i en enda commit daterad den 7 oktober 2026 vars meddelande helt enkelt är "Release AesCode-32B" – och träningsstacken som gör resultatet reproducerbart pushades till github.com/microsoft/AesCode den 8 oktober. Microsoft har inte tillkännagett något: inget blogginlägg, ingen arXiv-förhandspublicering, ingen inlämning till resultattavlor, ingen modellsida på den egna webbplatsen. Det som finns är en syn-språkmodell med 33 miljarder parametrar som tar en prompt och genererar ett komplett, fristående HTML-dokument – en bild, en poster, en instrumentpanel – plus en mindre följeslagare, microsoft/AesCode-8B. Båda är finjusterade från Qwen3-VL-visionmodeller – Qwen3-VL-32B-Instruct respektive Qwen3-VL-8B-Instruct – båda är Apache 2.0, och båda går att ladda ner idag.

Repo-id:t lyder microsoft/AesCode-32B och modellkortet öppnar med tricket: AesCode parar ihop din prompt med en bild som genererats från samma prompt, använder bilden som estetisk referens och följer texten för själva innehållet. Bildgeneratorer komponerar en snygg sida och återger siffrorna på den fel; kodmodeller får siffrorna rätt och kan inte se hur sidan ser ut. AesCode är ett försök att få båda, och den ärliga sammanfattningen av det per den 11 oktober 2026 är att vikterna är verkliga och kontrollerbara, att benchmark-siffrorna är labbets egna på en harness som labbet själv skrev, och att ingen utanför Microsoft ännu har publicerat någon siffra för den. Den här artikeln håller de tre kategorierna åtskilda hela vägen ned.

Vad finns det faktiskt i repositoryt, byte för byte

Börja med det du kan verifiera utan att lita på ett enda ord i modellkortet. 32B-förrådet innehåller fjorton safetensors-shards med totalt 66 714 912 704 byte, vilket vid BF16 är ungefär 33,4 miljarder parametrar – förenligt med kortets "33B params" och dess varning att vikterna ensamma kräver cirka 65 GB accelerator-minne. Konfigurationen deklarerar Qwen3VLForConditionalGeneration som arkitektur och qwen3_vl som modelltyp, så detta är inte en ny arkitektur och behöver inte heller vara det: den laddas med transformers>=4.57, och kortet innehåller ett vLLM-kommando som serverar den över fyra tensor-parallella ranker med två bilder tillåtna per prompt och ett tak på 24 576 tokens.

Engagemangsräknarna är den tystaste delen av släppet. Två nedladdningar och en gillamarkering på 32B-repositoriet vid skrivandets stund. Det finns ingen post i Hugging Faces inferensleverantörsmappning, vilket innebär att ingen hostad slutpunkt är kopplad bakom reposidan, och inget GGUF-, MLX- eller llama.cpp-bygge finns. För en modell med Microsofts namn och resultat som slår GPT-5.5 i leverantörens egen tabell är det ett slående litet antal, och det är det starkaste tillgängliga beviset för att detta släpptes utan en lansering.

Det medföljande kodförrådet fyller i den andra halvan av tidslinjen, och det är där frågan om releasedatumet verkligen blir tvetydig. microsoft/AesCode skapades den 23 juli 2026 – tio veckor före vikterna – och innehåller fjorton commits, alla skapade av samma bidragsgivare och alla tidsstämplade inom tjugo sekunder från varandra den 8 oktober 2026, mellan 23:14:04 och 23:14:24 UTC. De inkluderar specifikationen för att generera promptar och verifierbara krav, datapipelinen som bygger designgrafer och bedömningsfrågor, ett kallstart-SFT-steg, GDPO-förstärkningsinlärningsloopen, en Playwright-baserad renderingsverifierare, tester och README som dokumenterar allt detta. Det finns inga releaser och inga taggar, beskrivningen av kodförrådet är tom, och det har en stjärna.

Så vilket datum är släppet? Repositoryposten säger 29 september. Commiten som innehåller modellen säger 7 oktober. Koden som förklarar hur modellen skapades säger 8 oktober. Tre tidsstämplar inom ett enda tvåveckorsfönster, ingen av dem åtföljs av en mening från Microsoft som säger "vi släpper detta". Betrakta 7–8 oktober som det gällande datumet för de artefakter som de flesta faktiskt kommer att ladda ner, och 29 september som datumet då repositoryt reserverades. Den som säger att AesCode-32B "lanserades" en specifik dag väljer en av dessa tidsstämplar åt dig.

Mekanismen: en bild som estetisk vägledning, en graf som belöning

Kortets tekniska påstående är snävt och specifikt, vilket är en fördel. Modellen tränas med kallstartad övervakad finjustering på 3 000 demonstrationer med en inlärningshastighet på 1e-5, därefter med GDPO – en grupprelativ variant av policyoptimering – över 7 408 prompter i 520 steg. 8B-modellen använde samma recept och stoppade vid 400 steg. RL-körningen använde verls FSDP-vLLM-hybridmotor utan kritiker och utan separat tränad belöningsmodell, AdamW vid en konstant 5e-6 utan warmup, 128 prompter per steg med åtta rollouts vardera, och både prompt och svar begränsades till 8 192 token vardera.

Det som gör belöningen ovanlig är att den inte är en enda skalär. Varje träningsmål beskrivs som en designgraf som täcker hela arbetsytan, så enskilda egenskaper kan attribueras separat. Från den grafen kommer sju kanaler – exekvering, text, gräns, tabell/diagram, layout, vitrymd och design – som var och en normaliseras inom sin rollout-grupp före aggregering så att en dominerande signal inte kan dränka de andra. Deterministiska verifierare poängsätter det som kan parsas från koden och dess rendering; en vision-språkdomare poängsätter det som inte kan parsas, med hjälp av en bedömningsmatris kopplad till grafens egna element och relationer. Kandidat-HTML poängsätts genom att renderas i en sandboxad Playwright-webbläsare med externa förfrågningar blockerade, vilket exporterar DOM, beräknade stilar, avgränsningsrutor, konsolstatus och en skärmbild.

Den tekniska konsekvensen är värd att nämna eftersom den syns i utdata du får: modellen är tränad att generera tabeller som riktiga HTML-tabellstrukturer och diagram som ECharts-specifikationer, så båda är direkt inspekterbara i stället för inbakade i pixlar. Det är skillnaden mellan en presentation du kan lämna till en designer och en presentation du kan lämna till en linter. Reproduktionskraven är motsvarande tunga — README begär Python 3.10, CUDA 12.6 och en nod med åtta B200-GPU:er, låser en specifik verl-commit och säger rent ut att en patch mot den krävs eftersom standardversionen av verl saknar stöd för Qwen3-VL, och varnar för att utan Playwrights systembibliotek misslyckas webbläsaren vid start och sidor får noll poäng, och att utan den låsta OCR-stacken returnerar motsvarande belöningskanal noll i stället för att avstå och i tysthet korrumperar signalen.

Benchmark-tabellen, och de fyra anledningarna att ta den med en nypa salt

AesCode-32B:s huvudsiffror kommer från 300 infografikexempel, tre genereringar per prompt vid temperatur 0,8 och top-p 0,95, upp till 12 000 utdatatokens vardera, utan något urval bland genereringarna. Poängen anges i procent. Med referensbetingning rapporterar 32B-modellen Text 95,34, Boundary 97,27, Tabell/Diagram 90,37 och ett regelgenomsnitt på 94,33; på den visuella sidan Innehåll 85,76, Layout 90,58, Stil 55,99, vilket ger ett visuellt genomsnitt på 77,44 och ett totalt resultat på 85,89. I samma tabell får GPT-5.5 med referens 81,28 totalt och Claude Opus 4.8 med referens 80,39, medan basmodellen Qwen3-VL-32B-Instruct som modellen tränades från får 61,10.

Fyra förbehåll hör i samma andetag som dessa siffror, och inget av dem är en smutskastning av arbetet. För det första kördes varje rad, inklusive raderna för GPT-5.5 och Claude Opus 4.8, av Microsoft i Microsofts testrigg med Microsofts bedömningsmall — dessa är inte de andra labbens siffror, de är Microsofts mätningar av konkurrerande modeller, och kortet självt kallar bedömningsmallen "provspecifik" för varje designgraf. För det andra produceras bedömningsmallen av samma pipeline som genererade träningsdatan, vilket är precis det upplägg där ett riktmärke kan glida mot en modells styrkor; kortet är ärligt om begränsningarna i den bedömningsmallen — Style, som kräver att en design inte behöver någon ytterligare visuell revidering före leverans, kallas "det gemensamma taket för varje system" och ingen modell i tabellen klarar 60. För det tredje finns det ingen oberoende mätning av denna modell någonstans: ingen tredjepartsnotering på resultattavla, ingen reproduktion, och med tanke på två nedladdningar, nästan säkert ingen utanför labbet som kör den ännu. För det fjärde är jämförelsen subtilt asymmetrisk på ett sätt som är värt att notera — AesCode-32B:s rader är alla referensbetingade, så modellen mäts i den konfiguration den tränades för, vilket kortet bekräftar genom att visa att kvaliteten fortfarande är högst när en referens tillhandahålls.

Det enda resultatet i tabellen som står sig bättre än rubriken är ett robusthetspåstående snarare än ett kvalitetspåstående. Att utelämna referensbilden vid inferens kostar AesCode-8B bara 1,00 visuell poäng, mot 19,55 för dess Qwen3-VL-8B-Instruct-backbone och 10,04 för GPT-5.5. Argumentet i kortet är att referensvillkorad träning internaliserar visuell planering i policyn i stället för att lära modellen att kopiera det den ser. Det är rapporterat av leverantören och inte reproducerat, och det är också den typ av påstående som en enda oberoende körning skulle avgöra — och den typ som spelar störst roll i produktion, där du inte alltid har en referensbild till hands.

Vad det kostar att driva, och vad det innebär för jämförelsen

Inget med den här modellen är billigt att självhosta. Tio till tolv tusen utdatatokens är arbetsstorleken för en enskild artefakt, och ett fullständigt HTML-dokument med en ECharts-specifikation ligger närmare den övre änden av det intervallet än den nedre, så varje generering är en lång avkodning. Kortets eget serveringsrecept kräver fyra GPU:er med tensor-parallellism för att rymma cirka 65 GB BF16-parametrar, och träningsreceptet kräver åtta B200:or. Det är en riktig maskin, inte en hobbyinstallation, och det sätter villkoren för jämförelsen: de modeller som AesCode-32B mäts mot hyrs per token, och modellen själv hyrs per GPU-timme, oavsett om du äger hårdvaran eller inte.

Den praktiska formen av den jämförelsen är själva poängen med ett routinglager, och det är värt att vara exakt om vad vi hostar och inte hostar. AesCode-32B finns inte i OrcaRouters katalog och vi servar det inte – det finns ingen hostad endpoint för det någonstans där jag kan verifiera, Microsofts inräknat. Det som finns i katalogen är den andra sidan av bordet: de hostade modellerna som du skulle benchmarka en självhostad artefaktgenerator mot, inklusive GPT-5.5 och de mindre Qwen3-VL-visionmodellerna, tillgängliga via en enda API-nyckel till leverantörens listpris med 0 % påslag, vilket innebär att en prisförändring från leverantören är live hos oss samma dag. Att jämföra en hyrd endpoint med en modell du kör själv kräver inte ett andra kontrakt eller ett andra SDK, och en routing-DSL låter ett självhostat anrop ligga bredvid hostade bakom en enda endpoint. Om AesCode-32B visar sig vara bra på det enda som dess kort påstår, är kostnaden för att ta reda på det en GPU-räkning, och kostnaden för alternativen du jämför det med är en nyckel du förmodligen redan har.

Vad du kan göra med det idag, och vad som inte finns

• Ladda ner och kör den — vikterna är Apache 2.0, som följer Qwen3-VL-stommen, med fjorton BF16-shards och en fungerande transformers-väg över version 4.57 och ett vLLM-recept i kortet.

• Reproducera träningen – koden är MIT-licensierad och tillräckligt komplett för att vara meningsfull: belöningsverifieraren, bedömningsmallsbyggaren, SFT- och GDPO-stegen, en pinnad verl-commit plus patchen som lägger till Qwen3-VL-stöd, och en README som listar fellägena i stället för att dölja dem.

• Utvärdera det referensfritt – modellen accepterar prompter med eller utan referensbilden, och kortets mest testbara påstående ligger i den konfigurationen.

• Skaffa ett API för det — det går inte. Det finns ingen hostad slutpunkt, ingen mappning av inferensleverantör i repositoriet och ingen GGUF- eller MLX-build; att köra detta innebär att köra hårdvaran.

• Läs artikeln – det kan du ännu inte. Kortet länkar en artikel med titeln AesCode: Aesthetic Code Generation with Decoupled Cross-Modal Rewards, och dess egen BibTeX-post anger platsen som "Under review" och året som 2027. En sökning på arXiv ger ingen artikel med den titeln. Det finns en annan, tidigare Microsoft-artikel med ett nästan identiskt namn – Code Aesthetics with Agentic Reward Feedback från oktober 2025, som släppte en AesCoder-4B-modell och ett AesCode-358K-dataset – och inget i AesCode-32B-kortet citerar den eller anger någon relation till den. Om du letar efter bakgrundsläsning och i stället hamnar på den, läser du om en annan modell byggd av överlappande författare.

• Jämför det på en offentlig resultattavla – ännu inte. Inget tredjepartsindex verkar ha utvärderat det, vilket inte är förvånande för ett arkiv med två nedladdningar.

Vem bör bry sig, och vem bör vänta

Målgruppen för detta är snävare än rubriktabellen antyder och mer specifik än "alla som bygger med modeller". Om din produkt förvandlar prompter till presentationer, affischer, rapporter eller dashboards som någon måste redigera efteråt, har du redan upptäckt det val som den här modellen är inriktad på: bildgenerering ger dig en vacker rektangel som du inte kan ändra, och kodgenerering ger dig något redigerbart som ser ut som om det satts ihop av en kompilator. En 33B-modell med öppna vikter som skickar ut ett komplett HTML-dokument med riktiga tabeller och ECharts-specifikationer, som håller sig inom ungefär en punkt från sin referensbetingade kvalitet när du inte har någon referens att ge den, och som du kan finjustera på din egen företagsstil under Apache 2.0, är en genuint användbar sak att den finns. Ingen annans modell gör exakt det jobbet i den här storleken med de här villkoren.

Mot det: allt du vet om kvaliteten kommer från en tabell som leverantören har byggt, bedömningsmallen bakom den togs fram av samma pipeline som skapade träningsdatan, och det enda tak som kortet erkänner – Style under 60 för varje testat system – är just den dimension som en designkänslig produkt skulle bry sig mest om. Ett team som av efterlevnadsskäl behöver hålla genereringen internt och har en ledig åtta-GPU-nod har tillräckligt för att komma igång i dag. Ett team som väljer en modell för produktion nästa vecka har inget oberoende siffra att välja utifrån, och bör inte läsa 85,89 mot 81,28 som ett avgjort resultat.

Vad skulle förvandla det här till en berättelse?

Fyra saker, ingen av dem finns ännu. Ett tillkännagivande – Microsoft har inte sagt något, och artikeln som kortet refererar till är uttryckligen under granskning, så en teknisk rapport med träningsdetaljer utöver kortets sammanfattning skulle kunna dyka upp när som helst. En oberoende körning – påståendet om referensfri robusthet och Boundary-poängen, som kortet säger faller till ett allvarligt fel på 4,3 % av proverna mot 34,7 % för GPT-5.5, är båda billiga att testa och båda värda att testa. Serveringsstöd utanför leverantörens recept – en GGUF-build eller en post i en etablerad runtime skulle förändra hårdvaruberättelsen mer än vad någon benchmark skulle göra. Och en andra datapunkt i storleksfrågan: en 8B-modell som får 82,94 Overall mot 32B:ns 85,89 i samma tabell är en tvåpunktsskillnad för en fjärdedel av parametrarna, vilket är den typ av sak som antingen reproduceras eller tyst slutar nämnas.

Tills något av detta landar är den korrekta beskrivningen av AesCode-32B denna: riktiga vikter under en tillåtande licens, en träningsstack som är tillräckligt detaljerad för att kunna reproduceras av ett välutrustat labb, en benchmarktabell som är ett företags mätning av sin egen modell och av två konkurrenters, och en repo-historik som inte låter dig kalla någon enskild dag för lanseringsdatum. Det är en mer intressant artefakt än vad dess nedladdningsräknare på två antyder, och en mindre bevisad sådan än vad dess 85,89 antyder. Båda halvorna av den meningen är den ärliga tolkningen den 11 oktober 2026.