AesCode-8B vs Qwen3-8B: De ser ut som förälder och barn, men det är de inte

Namnen inbjuder till ett misstag. AesCode-8B är en 8B-modell med en Qwen3-VL-8B-Instruct-backbone, Qwen3-8B är leverantörens egen 8B-modell, och den självklara tolkningen är att den första är en finjustering av den andra. Det är den inte. AesCode-8B:s publicerade konfiguration anger Qwen3-VL-8B-Instruct som bas – syskonmodellen för vision och språk, en annan checkpoint med en annan uppgift – och Hugging Face-metadatan listar den som en finjustering av den modellen, inte av den textbaserade Qwen3-8B. De två AesCode-modellerna i den här viktklassen är kusiner snarare än förälder och barn, och den distinktionen är hela anledningen till att den här sidan är användbar: den berättar vad Microsoft köpte när de utgick från en checkpoint för vision och språk, vad det kostade på textsidan, och varför en jämförelse mot familjens vanliga 8B-generalist till slut mäter en fork snarare än en uppgradering.

Båda är Apache 2.0 och båda är nedladdningsbara, men deras publiceringshistorik skulle inte kunna vara mer olika. Qwen3-8B släpptes i april 2025 som en del av leverantörens Qwen3-generationslinje, med dokumentation, ekosystemintegration och arton månader av andras driftsättning bakom sig. AesCode-8B har inget releasedatum någonstans i sina filer. Microsoft skapade Hugging Face-arkivet den 29 september 2026, committade vikterna under meddelandet "Release AesCode-8B" kl. 03:35 UTC den 7 oktober 2026, och lade upp träningskoden på GitHub dagen därpå. Det finns inget inlägg från Microsoft Research, inget versionsmeddelande, ingen produktsida och ingen vetenskaplig artikel — modellkortets citering lyder "Under review" med platshållaråret 2027, och arkivet visade två nedladdningar vid skrivandets stund. Allt kvantitativt om AesCode-8B nedan är Microsofts eget och har inte reproducerats av någon.

Släktträdet som namnen döljer

Qwen3-generationslinjen innehåller flera checkpoints i 8B-klassen som delar ett släktskap och inte mycket annat. Qwen3-8B är generalisten för enbart text: ungefär 8,2 miljarder parametrar totalt, varav omkring 7 miljarder icke-embedding, grouped-query-attention, en inbyggd kontext på 32K tokens som kan utökas till 131K via YaRN, och träning över 119 språk och dialekter. Den resonerar, chattar, kodar och anropar verktyg, och det är en av de mest självhostade 8B-modellerna i det öppna ekosystemet, just av dessa skäl. Qwen3-VL-8B-Instruct är den multimodala medlemmen: samma generation i familjen, ett dedikerat visionstorn ovanpå, bild och text in, text ut.

Microsoft utgick från den andra. AesCode-8B-konfigurationen anger Qwen3VLForConditionalGeneration, med 36 dolda lager, dold storlek 4 096, 32 attention-huvuden och 8 key-value-huvuden, ett ordförråd på 151 936 token och interfolierade mrope-positioner, och den kräver transformers 4.57 eller nyare. Shardarna uppgår sammanlagt till 17 543 339 408 byte, cirka 8,8 miljarder bf16-parametrar, vilket är anledningen till att Hugging Faces avrundade storleksfält anger 9B medan leverantören anger 8B. Det är avrundning snarare än en avvikelse, och parameterantalet är inte den fork som spelar roll — indatamodaliteten och serveringskontexten på 24 576 token är det.

Så den ärliga formuleringen är inte "generalist kontra dess finjusterade version". Den är: en textgeneralist med en lång kontext och arton månaders produktionshistorik, mot en multimodal forskningscheckpoint som producerar ett dokument och aldrig har genomgått en oberoende utvärdering.

Vad Microsoft spenderade träningsbudgeten på

Designbriefen citeras på modellkortet och den förklarar förgreningen: kodmodeller "kan inte se hur layout, hierarki och färg samverkar på canvasen", medan bildgeneratorer "komponerar visuellt tilltalande sidor men återger ofta text, siffror och logiska relationer felaktigt." AesCode är försöket att ta kompositionssinne från den ena och verifierbarhet från den andra, och receptet är ovanligt på ett specifikt sätt.

Varje träningsprompt paras ihop med en referensbild som genererats 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 brief till en detaljerad innehållsprompt. Referensen bär endast layout och stil; textprompten förblir auktoritativ vad gäller innehållet. Sedan, vid inferens, behöver modellen den knappt: undanhåll referensen från AesCode-8B och dess Visual-poäng sjunker med 1,00 poäng av hundra, mot 19,55 för backbone och 10,04 för GPT-5.5. Ett relaterat resultat är att referensbaserade belöningar höjde prompt-only-Visual från 25,17 till 69,71, så den visuella priorn flyttade in i vikterna i stället för att stanna i indata.

Resten är en berättelse om belöningsdesign. Övervakning är en ”design-graf” av noder och kanter – text, diagram, tabeller, kort, regioner, bildplatser, med inneslutning, justering, ordning och koppling som kanter – vald så att varje egenskap på kanvasen tillhör ett namngivet element och därför kan poängsättas var för sig. Sju kanaler poängsätter resultatet: sex deterministiska verifierare för exekvering, text, gränser, tabell- och diagramdata, semantisk layout och vitrymd, plus en exempelspecifik Visual Graph Rubric som bedöms av en vision-language-modell. Kandidater renderas i en sandlådeskyddad Playwright-webbläsare med externa förfrågningar blockerade, och testramverket läser tillbaka DOM, beräknade stilar, avgränsningsrutor och en skärmbild, vilket är varför tabeller måste vara HTML-tabeller och diagram måste vara ECharts-specifikationer. Träningen var kallstartad övervakad finjustering på 3 000 demonstrationer, därefter GDPO över 7 408 promptar i 400 steg på en enda nod med åtta NVIDIA B200, där varje belöningskanal normaliserades inom sin rollout-grupp så att en tät regelbaserad signal inte kan dränka den glesa visuella signalen. Microsoft mäter den normaliseringen till 5,12 Visual-poäng över vanlig skalär GRPO.

Inget av det där maskineriet finns för att göra AesCode-8B till en bättre allmän assistent. Det finns för att göra utdata kontrollerbara, och det är därför modellens kontext är vad den är.

Sida vid sida, med numren märkta

• Bas — AesCode-8B: Qwen3-VL-8B-Instruct, en checkpoint för vision och språk. Qwen3-8B: samma generations textbaserade generalist.

• Parametrar — AesCode-8B: cirka 8,8B bf16 fördelat över fyra shards. Qwen3-8B: cirka 8,2B totalt, ungefär 7B icke-embedding.

• Indata — AesCode-8B: text plus en valfri referensbild. Qwen3-8B: text.

• Utdata — AesCode-8B: ett komplett HTML- och CSS-dokument. Qwen3-8B: text, verktygsanrop, kod.

• Kontext — AesCode-8B: 24 576 tokens i den rapporterade konfigurationen. Qwen3-8B: 32K inbyggt, 131K utökat via YaRN.

• Språk — AesCode-8B: kortets tagg är enbart "en". Qwen3-8B: 119 språk och dialekter.

• Bevis — AesCode-8B: Microsofts egen bedömningsmall för infografik med 300 sampel, tre generationer per prompt, ingen extern reproduktion. Qwen3-8B: arton månader av oberoende benchmarks, kvantiseringsarbete och driftsättning i produktion.

• Licens — Apache 2.0 för båda, utan spärrar. Oavgjort, och inte den avgörande skillnaden folk tror att det är.

Evidensgapet är den verkliga jämförelsen

Microsoft rapporterar AesCode-8B på 82,94 totalt enligt sin bedömningsmall, före referensbetingad GPT-5.5 på 81,28 och Claude Opus 4.8 på 80,39, och 31,1 visuella poäng över sin egen referensbetingade stomme. Tre siffror i den tabellen är värda mer än rubriken. Den första är Stil, där AesCode-8B ligger på 53,21 och ingen modell i jämförelsen passerar 60 — och Microsofts definition av Stil är design som inte kräver ytterligare visuell revidering före leverans, så på den enda dimensionen som frågar om en människa skulle skicka sidan oredigerad, är modellen inte ledaren. Den andra är gränsfelet: ett allvarligt canvas-överflöd återkommer i 4,3 % av de 300 proverna, jämfört med 34,7 % för GPT-5.5. Den tredje är att den visuella hälften av poängen kommer från en namnlös vision-språk-domare, vilket innebär att den deterministiska hälften är reproducerbar av en utomstående medan den andra hälften inte är det.

Qwen3-8B:s siffror kommer från en helt annan källa, och det spelar större roll än vilken uppsättning siffror som är högre. Arton månader av oberoende utvärdering, community-kvantiseringar, serving-benchmarks och produktionsutrullningar är en annan typ av bevis: det är inte ett påstående, det är en dokumenterad meritlista. Du kan ta reda på hur Qwen3-8B beter sig under fyrabitars kvantisering på ett specifikt grafikkort eftersom någon har publicerat det. Det kan du inte göra för AesCode-8B, eftersom ingen utanför Microsoft har kört det på något ännu, så sent som denna vecka.

Och det finns inget gemensamt mått mellan de två tabellerna. Qwen3-8B har ingen poäng för infografisk layout; AesCode-8B har överhuvudtaget ingen publicerad benchmark för allmänt resonemang. Jämförelsen är varken nära eller inte nära – den är inte tillgänglig.

Vad det faktiskt krävs för att köra var och en

Qwen3-8B är den enkla. En textmodell på 8,2B kvantiseras ner på ett enda konsumentkort, har arton månaders verktyg bakom sig i alla serveringsramverk och lokala körmiljöer, och beter sig förutsägbart. Kontextutökningen till 131K är dokumenterad snarare än hörsägen, och täckningen av 119 språk är anledningen till att den dyker upp i så många flerspråkiga pipelines.

AesCode-8B är ett servingprojekt. Kortets eget kommando är vllm serve microsoft/AesCode-8B --limit-mm-per-prompt image=2 --max-model-len 24576, med transformers 4.57 eller nyare för vägen som inte använder vLLM. De 17,5 GB bf16-vikterna måste rymmas vid sidan av en KV-cache för 24 576 token och upp till två bilder, så ett enda 24 GB-kort är tekniskt sett tillräckligt och obehagligt snävt, medan 40–48 GB eller två 24 GB-kort är den realistiska miniminivån. Budgetera även för en renderare, för varje påstående om den här modellens kvalitet byggde på att rendera dess HTML-utdata i en sandlådad webbläsare – om du vill veta om dina egna utdata är bra, är det den testriggen du måste sätta upp. Och notera att kontexten på 24 576 token testades på enstaka infografiksidor, inte de bildspel med flera sidor som modellen är ämnad för, så kontexttrycket på ett riktigt bildspel är outforskad mark.

Tillgänglighet är den andra halvan av samma poäng. AesCode-8B är inte något som OrcaRouter routar, och vi kunde inte hitta det serverat någon annanstans heller; en utvärdering idag innebär vikter på din egen hårdvara. Dess förfader är en annan historia — Qwen3-VL-8B-Instruct kan anropas via OrcaRouter just nu för $0,18 per miljon indatatoken och $0,70 per miljon utdatatoken över en kontext på 131 072 token, vilket gör det till det billigaste sättet att se vad den ojusterade versionen av exakt denna arkitektur presterar på dina egna infografik-prompter. Längre upp i samma serie är Qwen3.8-27B routbar för $0,33 och $2,40. Leverantörens listpris förs vidare utan påslag och failover mellan leverantörer är automatisk, så att prototypa prompten mot den hostade basmodellen kostar en nyckel i stället för en GPU-vecka, och bara de prompter som faktiskt renderas bra förtjänar reproduktionsarbetet.

Vilken du vill ha beror på artefakten

Välj AesCode-8B när leveransen är en sida och den måste vara redigerbar. Strukturerad HTML-utdata som diffar i Git, tabeller som riktiga tabeller och diagram som ECharts-specifikationer, är en genuint annan artefakt än ett stycke text, och ingen mängd allmän förmåga kan ersätta det. Ta avvägningen medvetet: en oannonserad forskningscheckpoint med ett tvåsiffrigt antal nedladdningar, en 24K-kontext, endast engelska, ingen oberoende utvärdering, ett Style-tak som dess egen leverantör publicerar, och en serveringsnota mätt i tiotals gigabyte.

Välj Qwen3-8B för allt annat — vilket, för de flesta team, är allt. Den är den beprövade generalisten vid denna vikt, den har en längre kontext, den talar etthundranitton språk, den körs på hårdvara du redan äger, och den har arton månader av andras produktionserfarenhet bakom de beslut du är på väg att fatta. Om du inte har något specifikt behov av att generera renderade sidor, har denna jämförelse ett svar.

Argumentet för att vilja ha båda är verkligt, och det är inte ett tiebreak. En pipeline som läser dokument och producerar presentationer använder två modeller med två genuint olika utdatatyper, och den användbara hållningen är att behålla sidrenderaren på hårdvara som klarar av den och dirigera läs- och resonemangsarbetet till något som hostas bakom samma slutpunkt som allt annat.

Vad skulle göra detta till en sida som stänger affärer?

Tre saker, och bara en av dem handlar om benchmarks. En oberoende reproduktion av 82,94 och referensnedgången på 1,00 punkt skulle flytta AesCode-8B från leverantörspåstående till resultat och göra det möjligt att besvara 8B-mot-8B-storleksfrågan på saklig grund. En leverantör som plockar upp checkpointen skulle få driftsättningskolumnen att kollapsa och förvandla ”en GPU-vecka” till ”ett API-anrop”. Och artikeln som modellkortet citerar som under granskning – ”AesCode: Aesthetic Code Generation with Decoupled Cross-Modal Rewards” – skulle besvara frågan som modellkortet inte kan: vad den visuella bedömningsmallen gör när designgrafen som den poängsätter mot själv är fel.

Fram till dess att något av det där slår in är den försvarbara tolkningen den snäva. AesCode-8B är den mer intressanta av dessa två modeller och den mindre användbara. Den är mycket bra på de delar av visuell design som en maskin kan kontrollera, medelmåttig på den del som inte kan automatiseras, och den tillhör samma Qwen3-generationsfamilj som modellen den jämförs med utan att härstamma från den. Qwen3-8B är den du kan sätta in i en pipeline redan i eftermiddag.