AesCode-8B vs Gemma 4 12B: Twee kleine visiemodellen, twee totaal verschillende outputs

AesCode-8B en Gemma 4 12B beide nemen een afbeelding en een zin en beide zijn Apache-2.0-checkpoints die je downloadt in plaats van huurt, daarom zetten zoekmachines ze graag naast elkaar. De gelijkenis is echt en ook oppervlakkig. Gemma 4 12B geeft een antwoord terug — een beschrijving, een transcriptie, een codefragment, een redeneerspoor. AesCode-8B geeft een gerenderde pagina terug: een dia, een poster of een dashboard als een compleet HTML- en CSS-document dat je in een browser kunt openen en met de hand kunt bewerken. Dezelfde invoervorm, ongeveer dezelfde gewichtsklasse, en een uitvoer die bijna niets gemeen heeft met de andere. Dat ene verschil bepaalt vrijwel elke praktische vraag hieronder, inclusief welke je morgen voor een gebruiker kunt zetten.

Het is de moeite waard dit vooraf te zeggen, want het bepaalt hoeveel gewicht de cijfers kunnen dragen: Gemma 4 12B werd op 2026-06-03 door DeepMind gelanceerd met een modelkaart, documentatie en een ecosysteem, en is sindsdien onafhankelijk getest. AesCode-8B werd helemaal niet gelanceerd. De repository van Microsoft daarvoor werd aangemaakt op 2026-09-29 en de gewichten belandden in een commit met de titel "Release AesCode-8B" om 03:35 UTC op 2026-10-07, terwijl de trainings- en evaluatiecode de volgende dag op GitHub verscheen. Er is geen Microsoft Research-post, geen productpagina, geen releasenote en geen preprint — de citatie van de modelkaart luidt "Under review" met 2027 als placeholderjaar. Op het moment van schrijven toont de 8B-repository twee downloads en één like. Alle kwantitatieve informatie over AesCode-8B is dus afkomstig van Microsoft zelf, en niets is door iemand anders gereproduceerd.

De twee modellen, op hun eigen voorwaarden

Gemma 4 12B is een middelgroot open model, een dichte checkpoint met 11,95 miljard parameters waarvan de bepalende ontwerpkeuze is dat het geen aparte visuele of audio-encoder heeft: afbeeldingspatches en audiogolfvormen gaan rechtstreeks de transformer in. Het heeft een 256K-tokencontext en vraagt ongeveer 16 GB VRAM, waarbij de BF16-gewichten rond 27 GB liggen en gekwantiseerde builds onder 7 GB. De eigen modelkaart van de leverancier — door de leverancier gerapporteerd, en hier als zodanig gelabeld — vermeldt DocVQA 94,9, InfoVQA 88,4, MMLU-Pro 77,2, GPQA Diamond 78,8, AIME 2026 77,5 en LiveCodeBench v6 72,0 in denkmodus. Onafhankelijke evaluatie is het deel dat zwaarder weegt: Artificial Analysis scoort de redeneerconfiguratie op een Intelligence Index van 14, meet ongeveer 114 tokens per seconde, en prijst een typische afgehandelde aanroep op ongeveer $0,10 per miljoen inputtokens en $0,30 per miljoen outputtokens. Het heeft drieënhalve maand deployment achter de rug.

AesCode-8B is een fine-tune van Qwen3-VL-8B-Instruct, gepubliceerd met vier safetensors-shards met in totaal 17.543.339.408 bytes — ongeveer 8,8 miljard bf16-parameters, daarom geeft het afgeronde grootteveld van Hugging Face 9B aan, terwijl de leverancier 8B zegt. De gepubliceerde configuratie is een rechtstreeks Qwen3-VL-recept: 36 verborgen lagen, verborgen grootte 4.096, 32 attention-heads met 8 key-value-heads, een vocabulaire van 151.936 tokens, en een vereiste van transformers 4.57 of nieuwer. De gerapporteerde runs van Microsoft gebruikten een context van 24.576 tokens met maximaal 12.000 uitvoertokens, temperatuur 0,8, top-p 0,95 en drie generaties per prompt zonder selectie. De licentie is Apache 2.0, zonder gating, geen addendum voor aanvaardbaar gebruik. Wat niet in de doos zit, zijn de trainings- en evaluatiegegevens, en geen enkele gehoste endpoint — we konden AesCode-8B nergens aangeboden vinden, en het staat niet in onze eigen catalogus.

Wat de modellen eigenlijk zijn getraind om te doen

De designbrief wordt geciteerd in de modelkaart en het is de moeite waard die als de volledige these te lezen: codemodellen "kunnen niet zien hoe lay-out, hiërarchie en kleur samenkomen op het canvas", terwijl beeldgeneratoren "visueel overtuigende pagina's componeren, maar tekst, cijfers en logische relaties vaak verkeerd weergeven." AesCode is de poging om het compositiegevoel en de verifieerbaarheid tegelijk te behouden.

Het mechanisme is op één specifiek punt ongewoon. Elke trainingsprompt wordt gekoppeld aan een referentieafbeelding die uit diezelfde prompt is gegenereerd, en die zorgt voor lay-out en stijl, terwijl de tekstprompt de autoriteit over de inhoud blijft. Bij inferentie heeft het model het beeld vervolgens nauwelijks nodig: laat je de referentie weg bij AesCode-8B, dan daalt zijn Visual-score met 1,00 punt van de honderd. Laat je die weg bij Qwen3-VL-8B-Instruct, dan is de daling 19,55. Laat je die weg bij GPT-5.5, geëvalueerd in dezelfde testomgeving, dan is de daling 10,04. De visuele prior is uiteindelijk in de gewichten terechtgekomen in plaats van in de invoer, en dat is het echte onderzoeksresultaat achter de kop.

Het trainingsdoel van Gemma 4 12B is het gewone multimodale doel, en het is geen kritiek om dat te zeggen: lees de afbeelding, beantwoord de vraag, volg de instructie, roep de tool aan. Niets in zijn modelkaart wijst erop dat het ooit gericht was op het produceren van een gerenderd artefact, en geen enkele gepubliceerde Gemma 4 12B-evaluatie meet de kwaliteit van documentlay-out, canvasoverloop of ontwerpconsistentie, want dat zijn niet de metrieken van het model.

Het scorebord, en van wie de rubric is

• Parameters — AesCode-8B: 8.8B bf16, dense. Gemma 4 12B: 11.95B dense.

• Invoer — AesCode-8B: tekst plus een optionele referentieafbeelding. Gemma 4 12B: tekst, afbeelding, audio en video.

• Uitvoer — AesCode-8B: een compleet HTML- en CSS-document. Gemma 4 12B: tekst, inclusief toolaanroepen.

• Context — AesCode-8B: 24.576 tokens in de gerapporteerde configuratie. Gemma 4 12B: 256K tokens.

• Licentie — beide Apache 2.0, zonder toegangsbeperking, gewichten inbegrepen.

• Bewijs — AesCode-8B: Microsofts eigen infographic-rubric van 300 samples, drie generaties per prompt, geen onafhankelijke reproductie. Gemma 4 12B: een leverancierskaart en een onafhankelijke Intelligence Index van 14 en gemeten doorvoer op Artificial Analysis.

Nu het deel dat het scorebord niet kan weergeven. Microsoft rapporteert AesCode-8B op 82,94 Overall op die set van 300 samples, voor referentie-geconditioneerde GPT-5.5 op 81,28 en Claude Opus 4.8 op 80,39, en 31,1 Visual-punten voor op zijn eigen Qwen3-VL-8B-backbone. Lees dat allemaal als door de leverancier gerapporteerd en niet gereproduceerd, op een rubric die de leverancier heeft gebouwd, op samples die de leverancier heeft gekozen, gescoord door een harness waartegen de leverancier het model heeft getraind. De kaart is eerlijk genoeg om een dimensie te publiceren waarop geen enkel model in de vergelijking boven de 60 uitkomt — Style, waar AesCode-8B op 53,21 staat en GPT-5.5 leidt met 57,91 — en Microsofts eigen definitie van die dimensie is ontwerp dat geen verdere visuele revisie nodig heeft vóór oplevering. Op de enige as die de vraag stelt of een mens de pagina ongewijzigd zou opleveren, is het 8B-model niet de leider. Dat is het getal om aan vast te houden wanneer iemand de 82,94 citeert.

Waar ze daadwerkelijk overlappen

Er is precies één gedeelde plank, en die is nauwer dan hij lijkt. Als je kleine open vision-modellen evalueert voor een documentintensieve pipeline, zijn beide kandidaten — de een voor het lezen van een document, de ander voor het produceren ervan. Een team dat interne dashboards als HTML genereert en ook cijfers uit geüploade PDF's moet halen, heeft in dezelfde week met beide producten te maken.

De splitsing binnen die overlap is helder. Gemma 4 12B is het model dat je op een binnenkomend document richt. AesCode-8B is het model dat je op een briefing richt wanneer de oplevering een pagina is. Geen van beide vervangt de andere, en een pipeline die beide wil, is een tweemodelpipeline in plaats van een keuze.

Deployment, en dat is waar de asymmetrie echt toeslaat

Het servingverhaal van Gemma 4 12B is klaar. Je downloadt het, kwantiseert het als je wilt, draait het op 16 GB VRAM, en er is een grote basis aan tooling die dit al doet. Als je het liever helemaal niet zelf draait, is een gehoste aanroep goedkoop en onafhankelijk geprijsd.

Het verhaal over het serveren van AesCode-8B is een opdrachtregel en wat rekenwerk. De modelkaart geeft de route direct — vllm serve microsoft/AesCode-8B --limit-mm-per-prompt image=2 --max-model-len 24576, met transformers 4.57 of nieuwer voor het niet-vLLM-pad. Er moet 17,5 GB aan bf16-gewichten naast een KV-cache voor 24.576 tokens en maximaal twee afbeeldingen staan, dus één kaart van 24 GB is technisch genoeg en ongemakkelijk krap; 40-48 GB, of twee kaarten van 24 GB, is de realistische ondergrens. Reken ook op een renderer, want elke kwaliteitsclaim over dit model wordt gemaakt door de HTML-uitvoer ervan in een sandboxbrowser te renderen, dus om je eigen resultaten te scoren moet je iets Playwright-achtigs opzetten met externe verzoeken geblokkeerd.

Dan is er de eerlijke staat van beschikbaarheid. Wij routeren AesCode-8B niet, en voor zover wij kunnen nagaan doet niemand anders dat ook; een evaluatie vandaag betekent gewichten op je eigen hardware. Het dichtstbijzijnde dat aanroepbaar is, is de architectuur waarop het model is fine-tuned. Qwen3-VL-8B-Instruct is nu routeerbaar via OrcaRouter voor $0,18 per miljoen invoertokens en $0,70 per miljoen output binnen een context van 131.072 tokens, en de twee checkpoints die wij wel aanbieden worden op dezelfde manier geprijsd — Gemma 4 26B-A4B voor $0,06 en $0,33, Gemma 4 31B voor $0,13 en $0,38. De lijstprijs van de provider wordt zonder opslag doorgegeven, en failover tussen providers gebeurt automatisch, dus de goedkope manier om erachter te komen of je prompts überhaupt goed renderen, is eerst de niet-getunede backbone testen en de GPU-week alleen te besteden aan de prompts die het overleven.

Welke je eigenlijk wilt

Kies AesCode-8B als het op te leveren resultaat een pagina is. Het model genereert gestructureerde, bewerkbare HTML — tabellen als HTML-tabellen, grafieken als ECharts-specificaties — wat betekent dat de uitvoer in Git te diffen is en door een designer opnieuw kan worden gestyled zonder deze opnieuw te genereren. Accepteer de afweging: een onaangekondigde researchcheckpoint met een dubbelcijferig aantal downloads, geen onafhankelijke evaluatie, geen gehost endpoint, een 24K-context die alleen is gevalideerd op afzonderlijke infographicpagina's, en een Engelstalige taaltag op de kaart.

Kies Gemma 4 12B voor al het overige. Het leest documenten beter dan de meeste modellen die twee keer zo groot zijn, het verwerkt audio, het volgt instructies voor tools, het heeft een kwart miljoen tokens aan context, en er zit drieënhalve maand ervaring van anderen achter. Als je een van deze twee kiest als je kleine visionmodel, en je niet specifiek is gevraagd om slidedecks als code te produceren, dan is dit het antwoord.

En als de eerlijke vereiste beide is, behandel het dan niet als een tiebreak. Leid het leeswerk naar een gehost model en houd het renderwerk op welke machine dan ook die de gewichten kan bevatten.

Wat zou deze pagina veranderen

Drie signalen. Een onafhankelijke reproductie van de 82,94 en de referentiedaling van 1,00 punt zou AesCode-8B van een leveranciersclaim naar een resultaat verplaatsen, en zou de vraag over de 8B-versus-12B-grootte werkelijk interessant maken in plaats van alleen in naam. Een inferentieprovider die het checkpoint oppikt, zou de deploymentkolom doen instorten, wat momenteel het hele praktische verschil is. En de paper die Microsoft aanhaalt als zijnde in review — "AesCode: Aesthetic Code Generation with Decoupled Cross-Modal Rewards" — zou de vragen beantwoorden die de modelkaart niet kan, te beginnen met hoe de visuele rubric zich gedraagt wanneer de ontwerpgraaf zelf verkeerd is. Totdat een van die dingen landt, is de verdedigbare lezing smal en echt: AesCode-8B is heel goed in de delen van visueel ontwerp die een machine kan controleren, middelmatig in het deel dat die niet kan, en Gemma 4 12B is een afgewerkt product dat een andere taak vervult.