AesCode-32B: il discreto modello da 33B di Microsoft che scrive presentazioni come HTML modificabile

I timestamp su AesCode-32B non concordano tra loro, e il disaccordo costituisce gran parte di ciò che c'è da segnalare. Il repository Hugging Face microsoft/AesCode-32B è stato creato il 29 settembre 2026, ma tutto ciò che contiene è arrivato in un unico commit datato 7 ottobre 2026, il cui messaggio è semplicemente "Release AesCode-32B" — e lo stack di addestramento che rende il risultato riproducibile è stato pubblicato su github.com/microsoft/AesCode l'8 ottobre. Microsoft non ha annunciato nulla: nessun post sul blog, nessun preprint su arXiv, nessun invio a una classifica, nessuna pagina del modello sul proprio sito. Ciò che esiste è un modello visione-linguaggio da 33 miliardi di parametri che accetta un prompt e genera un documento HTML completo e autonomo — una diapositiva, un poster, una dashboard — più un compagno più piccolo, microsoft/AesCode-8B. Entrambi sono messi a punto a partire da modelli di visione Qwen3-VL — Qwen3-VL-32B-Instruct e Qwen3-VL-8B-Instruct rispettivamente — entrambi sono Apache 2.0 ed entrambi sono scaricabili oggi.

L'id del repository recita m/AesCode-32B e la scheda si apre con il trucco: AesCode abbina il tuo prompt a un'immagine generata da quel prompt, usa l'immagine come riferimento estetico e segue il testo per il contenuto effettivo. I generatori di immagini compongono una bella pagina e rendono male i numeri che vi compaiono; i modelli di codice azzeccano i numeri e non riescono a vedere come appare la pagina. AesCode è un tentativo di avere entrambe le cose, e il riepilogo onesto che se ne può fare all'11 ottobre 2026 è che i pesi sono reali e verificabili, i numeri del benchmark sono quelli del laboratorio stesso, ottenuti su un harness scritto dal laboratorio, e nessuno al di fuori di Microsoft ha ancora pubblicato un numero al riguardo. Questo pezzo tiene distinte quelle tre categorie fino in fondo.

Cosa c’è effettivamente nel repository, byte per byte

Inizia da ciò che puoi verificare senza fidarti di una parola della scheda del modello. Il repository 32B contiene quattordici shard safetensors per un totale di 66.714.912.704 byte, che in BF16 corrispondono all'incirca a 33,4 miliardi di parametri — coerente con i "33B params" della scheda e con l'avvertenza che i soli pesi richiedono circa 65 GB di memoria dell'acceleratore. La configurazione dichiara Qwen3VLForConditionalGeneration come architettura e qwen3_vl come tipo di modello, quindi questa non è una nuova architettura e non ne ha bisogno: si carica con transformers>=4.57, e la scheda include un comando vLLM che lo serve su quattro rank tensor-parallel, con due immagini consentite per prompt e un tetto di 24.576 token.

I contatori delle interazioni sono la parte più silenziosa del rilascio. Due download e un like sul repository 32B al momento in cui scriviamo. Non c'è alcuna voce nella mappatura dei provider di inferenza di Hugging Face, il che significa che nessun endpoint ospitato è collegato dietro la pagina del repository, e nessuna build GGUF, MLX o llama.cpp è pubblicizzata da nessuna parte. Per un modello che porta il nome di Microsoft e che riporta risultati che battono GPT-5.5 nella tabella dello stesso fornitore, si tratta di un'impronta sorprendentemente piccola — ed è la prova più forte disponibile che questo è stato pubblicato senza un lancio alle spalle.

Il repository di codice complementare completa l'altra metà della cronologia, ed è qui che la questione della data di rilascio diventa davvero ambigua. microsoft/AesCode è stato creato il 23 luglio 2026 — dieci settimane prima dei pesi — e contiene quattordici commit, ognuno dei quali realizzato dallo stesso contributore e ognuno con timestamp a non più di venti secondi dagli altri l'8 ottobre 2026, tra le 23:14:04 e le 23:14:24 UTC. Includono la specifica per generare prompt e requisiti verificabili, la pipeline dati che costruisce grafi di progettazione e domande basate su rubriche, una fase SFT cold-start, il ciclo di apprendimento per rinforzo GDPO, un verificatore di rendering basato su Playwright, test e il README che documenta tutto quanto. Non ci sono release né tag, la descrizione del repository è vuota e ha una stella.

Quindi qual è la data del rilascio? La registrazione del repository dice 29 settembre. Il commit che contiene il modello dice 7 ottobre. Il codice che spiega come è stato realizzato il modello dice 8 ottobre. Tre timestamp all'interno di un'unica finestra di due settimane, nessuno dei quali accompagnato da una frase di Microsoft che dica "lo stiamo rilasciando". Considera il 7–8 ottobre come la data operativa per gli artefatti che la maggior parte delle persone scaricherà effettivamente, e il 29 settembre come la data in cui il repository è stato riservato. Chiunque ti dica che AesCode-32B è stato "lanciato" in un giorno specifico sta scegliendo uno di quei timestamp per conto tuo.

Il meccanismo: un'immagine come guida estetica, un grafo come ricompensa

L'affermazione tecnica della scheda è ristretta e specifica, il che è un punto a suo favore. Il modello viene addestrato con fine-tuning supervisionato a cold-start su 3.000 dimostrazioni con un tasso di apprendimento di 1e-5, poi con GDPO — una variante di ottimizzazione della politica relativa al gruppo — su 7.408 prompt per 520 passi. Il modello 8B ha usato la stessa ricetta e si è fermato a 400 passi. L'esecuzione RL ha utilizzato il motore ibrido FSDP-vLLM di verl senza critico e senza un modello di ricompensa addestrato separatamente, AdamW a 5e-6 costante senza warmup, 128 prompt per passo con otto rollout ciascuno, e prompt e risposta entrambi limitati a 8.192 token.

Ciò che rende insolita la ricompensa è che non è un singolo scalare. Ogni obiettivo di addestramento è descritto come un grafo di design che copre l'intero canvas, così le singole proprietà possono essere attribuite separatamente. Da quel grafo derivano sette canali — esecuzione, testo, confine, tablechart, layout, spazio bianco e design — ciascuno normalizzato all'interno del proprio gruppo di rollout prima dell'aggregazione, in modo che un segnale dominante non possa soffocare gli altri. I verificatori deterministici valutano ciò che può essere analizzato dal codice e dalla sua resa; un giudice vision-language valuta ciò che non può, usando una rubrica legata agli elementi e alle relazioni del grafo stesso. L'HTML candidato viene valutato renderizzandolo in un browser Playwright in sandbox con le richieste esterne bloccate, che esporta il DOM, gli stili calcolati, i bounding box, lo stato della console e uno screenshot.

La conseguenza ingegneristica vale la pena di essere enunciata perché si manifesta nell'output che ricevi: il modello è addestrato a emettere tabelle come vere strutture di tabelle HTML e grafici come specifiche ECharts, quindi entrambi sono direttamente ispezionabili anziché incorporati nei pixel. Questa è la differenza tra una presentazione che puoi consegnare a un designer e una presentazione che puoi consegnare a un linter. I requisiti di riproduzione sono corrispondentemente pesanti — il README richiede Python 3.10, CUDA 12.6 e un nodo di otto GPU B200, fissa uno specifico commit di verl e dichiara chiaramente che è richiesta una patch contro di esso perché verl standard manca del supporto a Qwen3-VL, e avverte che senza le librerie di sistema di Playwright il browser fallisce all'avvio e le pagine ottengono un punteggio zero, e che senza lo stack OCR fissato il corrispondente canale di ricompensa restituisce zero invece di astenersi e corrompe silenziosamente il segnale.

La tabella di benchmark, e le quattro ragioni per prenderla con le molle

I numeri principali di AesCode-32B provengono da 300 campioni di infografica, tre generazioni per prompt a temperatura 0,8 e top-p 0,95, fino a 12.000 token di output ciascuna, senza selezione tra le generazioni. I punteggi sono percentuali. In condizioni con riferimento, il modello 32B riporta Testo 95,34, Confini 97,27, Tabella/Grafico 90,37 e una media Regola di 94,33; sul fronte visivo Contenuto 85,76, Layout 90,58, Stile 55,99, per una media Visuale di 77,44 e un Complessivo di 85,89. Nella stessa tabella, GPT-5.5 con un riferimento ottiene 81,28 nel Complessivo e Claude Opus 4.8 con un riferimento ottiene 80,39, mentre il backbone Qwen3-VL-32B-Instruct da cui è stato addestrato il modello ottiene 61,10.

Quattro avvertenze vanno dette insieme a quei dati, e nessuna di esse getta discredito sul lavoro. Primo, ogni riga, comprese quelle di GPT-5.5 e Claude Opus 4.8, è stata eseguita da Microsoft sull'harness di Microsoft con la griglia di valutazione di Microsoft — non sono i numeri degli altri laboratori, sono le misurazioni di Microsoft dei modelli dei concorrenti, e la scheda stessa definisce la griglia di valutazione «specifica per campione» per ciascun grafo di progettazione. Secondo, la griglia di valutazione è prodotta dalla stessa pipeline che ha generato i dati di addestramento, che è esattamente la configurazione in cui un benchmark può scivolare verso i punti di forza di un modello; la scheda è sincera sui limiti di quella griglia — Style, che richiede che un design non necessiti di ulteriori revisioni visive prima della consegna, viene indicato come «il tetto condiviso per ogni sistema», e nessun modello nella tabella supera 60. Terzo, non esiste alcuna misurazione indipendente di questo modello da nessuna parte: nessuna voce in una classifica di terze parti, nessuna riproduzione e, visti i due download, quasi certamente nessuno fuori dal laboratorio lo sta ancora eseguendo. Quarto, il confronto è sottilmente asimmetrico in un modo che vale la pena notare — le righe di AesCode-32B sono tutte condizionate da un riferimento, quindi il modello viene misurato nella configurazione per cui è stato addestrato, il che la scheda riconosce mostrando che la qualità resta la più alta quando viene fornito un riferimento.

L'unico risultato nella tabella che regge meglio del titolo di apertura è un'affermazione di robustezza più che di qualità. Omettere l'immagine di riferimento in fase di inferenza costa ad AesCode-8B solo 1,00 punto Visual, contro 19,55 per il suo backbone Qwen3-VL-8B-Instruct e 10,04 per GPT-5.5. L'argomentazione della scheda è che l'addestramento condizionato dal riferimento interiorizza la pianificazione visiva nella policy invece di insegnare al modello a copiare ciò che vede. Si tratta di un dato riportato dal fornitore e non riprodotto, ed è anche il tipo di affermazione che una singola esecuzione indipendente risolverebbe — e il tipo che conta di più in produzione, dove non avrai sempre un'immagine di riferimento a portata di mano.

Quanto costa gestirlo, e cosa significa per il confronto

Non c'è nulla di economico nel self-hosting di questo modello. Da dieci a dodicimila token di output sono la dimensione di lavoro di un singolo artefatto, e un documento HTML completo con una specifica ECharts è più vicino all'estremo superiore di quell'intervallo che a quello inferiore, quindi ogni generazione è una decodifica lunga. La ricetta di serving della scheda stessa richiede quattro GPU in parallelismo tensoriale per contenere circa 65 GB di parametri BF16, e la ricetta di addestramento richiede otto B200. Questa è una macchina vera, non un deployment hobbistico, e fissa i termini del confronto: i modelli rispetto ai quali AesCode-32B viene misurato si noleggiano a token, e il modello stesso si noleggia a GPU-ora, che tu possieda l'hardware o meno.

La forma pratica di quel confronto è il motivo per cui esiste un livello di routing, e vale la pena essere precisi su ciò che ospitiamo e ciò che non ospitiamo. AesCode-32B non è nel catalogo di OrcaRouter e non lo serviamo — non esiste un endpoint ospitato per esso in nessun luogo che io possa verificare, incluso quello di Microsoft. Ciò che è nel catalogo è l'altro lato del tavolo: i modelli ospitati con cui confronteresti un generatore di artefatti self-hosted, inclusi GPT-5.5 e i modelli di visione Qwen3-VL più piccoli, raggiungibili tramite una singola chiave API al prezzo di listino del provider con 0% di ricarico, il che significa che una variazione di prezzo del fornitore è attiva dalla nostra parte lo stesso giorno. Confrontare un endpoint a noleggio con un modello che esegui da te non richiede un secondo contratto o un secondo SDK, e un DSL di routing consente a una chiamata self-hosted di stare accanto a quelle ospitate dietro un unico endpoint. Se AesCode-32B si rivela buono nell'unica cosa che la sua scheda dichiara, il costo per scoprirlo è una bolletta GPU, e il costo delle alternative con cui lo stai confrontando è una chiave che probabilmente hai già.

Cosa puoi fare con esso oggi, e cosa non esiste

• Scaricalo ed eseguilo — i pesi sono Apache 2.0, seguono il backbone Qwen3-VL, con quattordici shard BF16 e un percorso funzionante per transformers superiore alla versione 4.57 e una ricetta vLLM nella scheda.

• Riprodurre il training — il codice è con licenza MIT e abbastanza completo da essere significativo: il verificatore del reward, il costruttore di rubriche, le fasi SFT e GDPO, un commit di verl fissato più la patch che aggiunge il supporto a Qwen3-VL, e un README che elenca le modalità di fallimento invece di nasconderle.

• Valutalo senza riferimento: il modello accetta prompt con o senza l'immagine di riferimento, e l'affermazione più verificabile della scheda risiede proprio in questa configurazione.

• Ottenere un'API per questo — non è possibile. Non c'è alcun endpoint ospitato, nessuna mappatura di provider di inferenza nel repository e nessuna build GGUF o MLX; eseguirlo significa eseguire l'hardware.

• Leggi il paper — non puoi ancora. La scheda rimanda a un paper intitolato AesCode: Aesthetic Code Generation with Decoupled Cross-Modal Rewards, e la sua stessa voce BibTeX indica la sede come "Under review" e l'anno come 2027. Una ricerca su arXiv non restituisce alcun paper con quel titolo. Esiste un altro paper Microsoft, diverso e precedente, con un nome quasi identico — Code Aesthetics with Agentic Reward Feedback di ottobre 2025, che ha rilasciato un modello AesCoder-4B e un dataset AesCode-358K — e nulla nella scheda di AesCode-32B lo cita o ne dichiara un rapporto. Se cerchi letture di approfondimento e finisci invece su quello, stai leggendo di un modello diverso, realizzato da autori in parte coincidenti.

• Confrontalo su una classifica pubblica — non ancora. Nessun indice di terze parti sembra averlo valutato, il che non sorprende per un repository con due download.

Chi dovrebbe preoccuparsi e chi dovrebbe aspettare

Il pubblico di questo è più ristretto di quanto suggerisca la tabella di riferimento e più specifico di «chiunque costruisca con i modelli». Se il tuo prodotto trasforma prompt in presentazioni, poster, report o dashboard che qualcuno deve poi modificare, hai già scoperto la scelta a cui questo modello è mirato: la generazione di immagini ti dà un rettangolo bellissimo che non puoi cambiare, e la generazione di codice ti dà qualcosa di modificabile che sembra essere stato assemblato da un compilatore. Un modello open-weights da 33B che emette un documento HTML completo con tabelle reali e specifiche ECharts, che resta entro circa un punto dalla sua qualità condizionata dal riferimento quando non hai alcun riferimento da dargli, e che puoi mettere a punto sul tuo stile aziendale sotto Apache 2.0, è una cosa davvero utile che esista. Il modello di nessun altro svolge esattamente quel compito a questa dimensione con queste condizioni.

Di contro: tutto ciò che sai sulla qualità proviene da una tabella costruita dal fornitore, la rubrica che ne sta alla base è stata prodotta dalla stessa pipeline che ha creato i dati di addestramento, e l'unico limite che la scheda ammette — Style sotto 60 per ogni sistema testato — è proprio la dimensione a cui un prodotto sensibile al design terrebbe di più. Un team che ha ragioni di conformità per tenere la generazione internamente e un nodo da otto GPU di riserva ha abbastanza per iniziare oggi. Un team che sceglie un modello per la produzione la prossima settimana non ha alcun numero indipendente su cui basare la scelta, e non dovrebbe leggere l'85,89 contro 81,28 come un risultato assodato.

Che cosa trasformerebbe questo in una storia?

Quattro cose, nessuna delle quali esiste ancora. Un annuncio — Microsoft non ha detto nulla, e il paper a cui fa riferimento la scheda è esplicitamente in revisione, quindi un rapporto tecnico con dettagli di addestramento oltre il riassunto della scheda potrebbe apparire in qualsiasi momento. Un'esecuzione indipendente — l'affermazione di robustezza senza riferimento e il punteggio Boundary, che secondo la scheda scende a un fallimento grave sul 4,3% dei campioni contro il 34,7% per GPT-5.5, sono entrambi economici da testare e vale la pena testarli entrambi. Supporto di serving al di fuori della ricetta del fornitore — una build GGUF o un'entry di runtime mainstream cambierebbe la storia hardware più di quanto farebbe qualsiasi benchmark. E un secondo punto dati sulla questione delle dimensioni: un modello 8B che totalizza 82,94 Overall contro 85,89 del 32B sulla stessa tabella è un divario di due punti per un quarto dei parametri, che è il tipo di cosa che o viene riprodotta o smette silenziosamente di essere menzionata.

Finché uno di questi non si concretizza, la descrizione accurata di AesCode-32B è questa: pesi reali sotto una licenza permissiva, uno stack di addestramento sufficientemente dettagliato da poter essere riprodotto da un laboratorio ben attrezzato, una tabella di benchmark che è la misurazione, da parte di una sola azienda, del proprio modello e di quelli di due concorrenti, e una cronologia del repository che non permette di indicare un singolo giorno come data di lancio. È un artefatto più interessante di quanto suggerisca il suo contatore di due download, e meno comprovato di quanto implichi il suo 85,89. Entrambe le metà di quella frase sono la lettura onesta dell'11 ottobre 2026.