AesCode-32B: cichy model 33B Microsoftu, który tworzy prezentacje jako edytowalny HTML

Znaczniki czasu w AesCode-32B nie zgadzają się ze sobą, a ta rozbieżność to większość tego, co jest do zaraportowania. Repozytorium Hugging Face microsoft/AesCode-32B zostało utworzone 29 września 2026 r., ale wszystko w nim pojawiło się w jednym commicie z 7 października 2026 r., którego komunikat brzmi po prostu „Release AesCode-32B” — a stos szkoleniowy, który czyni wynik odtwarzalnym, został wypchnięty do github.com/microsoft/AesCode 8 października. Microsoft nic nie ogłosił: żadnego wpisu na blogu, żadnego preprintu na arXiv, żadnego zgłoszenia do rankingu, żadnej strony modelu na własnej witrynie. Istnieje natomiast model wizyjno-językowy o 33 miliardach parametrów, który przyjmuje prompt i generuje kompletny, samodzielny dokument HTML — slajd, plakat, dashboard — plus mniejszy model towarzyszący, microsoft/AesCode-8B. Oba zostały dostrojone na podstawie modeli wizyjnych Qwen3-VL — Qwen3-VL-32B-Instruct i Qwen3-VL-8B-Instruct odpowiednio — oba są na licencji Apache 2.0 i oba można dziś pobrać.

Identyfikator repozytorium brzmi microsoft/AesCode-32B, a karta zaczyna się od triku: AesCode łączy twoje polecenie z obrazem wygenerowanym na podstawie tego samego polecenia, używa obrazu jako odniesienia estetycznego, a jeśli chodzi o właściwą treść, kieruje się tekstem. Generatory obrazów komponują atrakcyjną stronę i błędnie renderują znajdujące się na niej liczby; modele kodu podają liczby poprawnie, ale nie widzą, jak wygląda strona. AesCode to próba połączenia jednego i drugiego, a uczciwe podsumowanie na dzień 11 października 2026 r. jest takie, że wagi są prawdziwe i sprawdzalne, liczby benchmarkowe pochodzą od samego laboratorium i z napisanego przez nie harnessu, a nikt spoza firmy Microsoft nie opublikował dla niego jeszcze żadnej liczby. Ten tekst konsekwentnie rozdziela te trzy kategorie na każdym poziomie.

Co tak naprawdę znajduje się w repozytorium, bajt po bajcie

Zacznij od tego, co możesz zweryfikować, nie ufając ani jednemu słowu z karty modelu. Repozytorium 32B zawiera czternaście fragmentów safetensors o łącznym rozmiarze 66 714 912 704 bajtów, co przy BF16 daje około 33,4 miliarda parametrów — zgodnie z „33B params” z karty i jej ostrzeżeniem, że same wagi wymagają około 65 GB pamięci akceleratora. Konfiguracja deklaruje Qwen3VLForConditionalGeneration jako architekturę, a qwen3_vl jako typ modelu, więc nie jest to nowa architektura i nie potrzebuje nowej: ładuje się z transformers>=4.57, a karta zawiera polecenie vLLM, które obsługuje go na czterech rangach równoległości tensorowej, z dwoma obrazami dozwolonymi na prompt i limitem 24 576 tokenów.

Liczniki zaangażowania są najcichszą częścią tego wydania. Dwa pobrania i jedno polubienie w repozytorium 32B w chwili pisania tego tekstu. Nie ma wpisu w mapowaniu dostawców inferencji Hugging Face, co oznacza, że za stroną repozytorium nie jest podłączony żaden hostowany endpoint, a nigdzie nie jest reklamowana żadna kompilacja GGUF, MLX ani llama.cpp. Jak na model noszący nazwę Microsoftu i osiągający wyniki, które biją GPT-5.5 w tabeli samego dostawcy, to uderzająco mały ślad — i jest to najsilniejszy dostępny dowód, że zostało to opublikowane bez stojącej za tym premiery.

Towarzyszące repozytorium kodu wypełnia drugą połowę osi czasu i to właśnie tam kwestia daty wydania staje się naprawdę niejednoznaczna. microsoft/AesCode zostało utworzone 23 lipca 2026 r. — dziesięć tygodni przed wagami — i zawiera czternaście commitów, z których każdy został autorstwa tego samego współtwórcy i każdy ma znacznik czasu w ciągu dwudziestu sekund od pozostałych, 8 października 2026 r., między 23:14:04 a 23:14:24 UTC. Obejmują one specyfikację generowania promptów i weryfikowalnych wymagań, pipeline danych budujący grafy projektowe i pytania rubrykowe, etap SFT zimnego startu, pętlę uczenia ze wzmocnieniem GDPO, weryfikator renderowania oparty na Playwright, testy oraz README dokumentujący to wszystko. Nie ma żadnych wydań ani tagów, opis repozytorium jest pusty, a ono ma jedną gwiazdkę.

Więc która data jest datą wydania? Zapis w repozytorium wskazuje 29 września. Commit, który zawiera model, wskazuje 7 października. Kod, który wyjaśnia, jak powstał model, wskazuje 8 października. Trzy znaczniki czasu w jednym dwutygodniowym oknie, żadnemu z nich nie towarzyszy zdanie od Microsoftu: „wypuszczamy to”. Traktuj 7–8 października jako obowiązującą datę dla artefaktów, które większość ludzi faktycznie pobierze, a 29 września jako datę zarezerwowania repozytorium. Każdy, kto mówi ci, że AesCode-32B „miał premierę” konkretnego dnia, wybiera w twoim imieniu jeden z tych znaczników czasu.

Mechanizm: obraz jako wskazówka estetyczna, wykres jako nagroda

Twierdzenie karty jest wąskie i konkretne, co jest jej atutem. Model jest trenowany za pomocą nadzorowanego dostrajania z zimnym startem na 3000 demonstracji przy współczynniku uczenia 1e-5, a następnie z GDPO — wariantem optymalizacji polityki względem grupy — na ponad 7408 promptach przez 520 kroków. Model 8B użył tego samego przepisu i zatrzymał się na 400 krokach. Przebieg RL wykorzystał hybrydowy silnik FSDP-vLLM verl bez krytyka i bez osobno trenowanego modelu nagrody, AdamW przy stałym współczynniku 5e-6 bez rozgrzewki, 128 promptów na krok z ośmioma rollouts każdy, a prompt i odpowiedź zostały ograniczone do 8192 tokenów każdy.

To, co czyni tę nagrodę nietypową, polega na tym, że nie jest ona pojedynczym skalarem. Każdy cel treningowy jest opisany jako graf projektu obejmujący całe płótno, dzięki czemu poszczególne właściwości można przypisać oddzielnie. Z tego grafu wywodzi się siedem kanałów — wykonanie, tekst, granice, tablechart, układ, biała przestrzeń i design — z których każdy jest normalizowany w obrębie swojej grupy rolloutów przed agregacją, aby jeden dominujący sygnał nie zagłuszył pozostałych. Deterministyczne weryfikatory oceniają to, co można sparsować z kodu i jego renderowania; sędzia wizyjno-językowy ocenia to, czego nie można, korzystając z rubryki powiązanej z elementami i relacjami samego grafu. Kandydacki kod HTML jest oceniany przez renderowanie go w przeglądarce Playwright działającej w piaskownicy, z zablokowanymi żądaniami zewnętrznymi, co eksportuje DOM, obliczone style, obwiednie, status konsoli i zrzut ekranu.

Konsekwencja inżynieryjna jest warta podkreślenia, bo widać ją w danych wyjściowych, które otrzymujesz: model jest uczony emitować tabele jako prawdziwe struktury tabel HTML, a wykresy jako specyfikacje ECharts, dzięki czemu oba można bezpośrednio sprawdzać, zamiast mieć je wtopione w piksele. To różnica między prezentacją, którą można przekazać projektantowi, a prezentacją, którą można przekazać linterowi. Wymagania odtwarzalności są odpowiednio duże — README wymaga Pythona 3.10, CUDA 12.6 i węzła z ośmioma GPU B200, przypina konkretny commit verl i wyraźnie stwierdza, że wymagana jest względem niego poprawka, ponieważ standardowy verl nie obsługuje Qwen3-VL, oraz ostrzega, że bez bibliotek systemowych Playwright przeglądarka zawodzi przy uruchomieniu i strony dostają zero punktów, a bez przypiętego stosu OCR odpowiedni kanał nagrody zwraca zero zamiast wstrzymać się i po cichu psuje sygnał.

Tabela benchmarków i cztery powody, by nie trzymać się jej kurczowo

Główne liczby AesCode-32B pochodzą z 300 próbek infografik, trzech generacji na prompt przy temperaturze 0,8 i top-p 0,95, do 12 000 tokenów wyjściowych każda, bez selekcji spośród generacji. Wyniki podano w procentach. W warunkach referencyjnych model 32B raportuje Text 95,34, Boundary 97,27, Table/Chart 90,37 oraz średnią Rule 94,33; po stronie wizualnej Content 85,76, Layout 90,58, Style 55,99, co daje średnią Visual 77,44 i Overall 85,89. W tej samej tabeli GPT-5.5 z referencją uzyskuje 81,28 Overall, a Claude Opus 4.8 z referencją uzyskuje 80,39, podczas gdy backbone Qwen3-VL-32B-Instruct, na którym trenowano model, uzyskuje 61,10.

Cztery zastrzeżenia trzeba wymienić jednym tchem razem z tymi liczbami i żadne z nich nie jest oczernianiem tej pracy. Po pierwsze, każdy wiersz — w tym wiersze GPT-5.5 i Claude Opus 4.8 — został uruchomiony przez Microsoft na stanowisku testowym Microsoftu i według rubryki Microsoftu; to nie są liczby innych laboratoriów, tylko pomiary Microsoftu dotyczące modeli konkurencji, a sama karta nazywa rubrykę „specyficzną dla danej próbki” dla każdego grafu projektu. Po drugie, rubryka powstaje w tym samym potoku, który wygenerował dane treningowe, a to dokładnie taki układ, w którym benchmark może dryfować w stronę mocnych stron modelu; karta otwarcie mówi o ograniczeniach tej rubryki — Styl, który wymaga, aby projekt nie potrzebował żadnych dalszych poprawek wizualnych przed dostarczeniem, nazywany jest „wspólnym pułapem dla każdego systemu”, a żaden model w tabeli nie przekracza 60. Po trzecie, nie ma nigdzie niezależnego pomiaru tego modelu: żadnego wpisu w rankingu podmiotów trzecich, żadnej reprodukcji, a biorąc pod uwagę dwa pobrania, prawie na pewno nikt spoza laboratorium jeszcze go nie uruchomił. Po czwarte, porównanie jest subtelnie asymetryczne w sposób, który warto zauważyć — wszystkie wiersze AesCode-32B są warunkowane referencją, więc model jest mierzony w konfiguracji, do której był trenowany, co karta przyznaje, pokazując, że jakość wciąż jest najwyższa, gdy dostarczono referencję.

Jedyny wynik w tabeli, który broni się lepiej niż nagłówek, to twierdzenie o odporności, a nie o jakości. Wstrzymanie obrazu referencyjnego podczas wnioskowania kosztuje AesCode-8B tylko 1,00 punktu Visual, wobec 19,55 dla jego szkieletu Qwen3-VL-8B-Instruct i 10,04 dla GPT-5.5. Argument karty modelu jest taki, że trening warunkowany referencją internalizuje planowanie wizualne w politykę, zamiast uczyć model kopiowania tego, co widzi. Jest to zgłoszone przez dostawcę i nieodtworzone, a to także rodzaj twierdzenia, które rozstrzygnęłoby pojedyncze niezależne uruchomienie — i rodzaj, który ma największe znaczenie w produkcji, gdzie nie zawsze będziesz mieć pod ręką obraz referencyjny.

Ile kosztuje jego eksploatacja i co to oznacza dla porównania

W samodzielnym hostowaniu tego modelu nie ma nic taniego. Od dziesięciu do dwunastu tysięcy tokenów wyjściowych to roboczy rozmiar pojedynczego artefaktu, a pełny dokument HTML ze specyfikacją ECharts jest bliżej górnej granicy tego zakresu niż dolnej, więc każde generowanie to długie dekodowanie. Sama karta modelu w przepisie na serwowanie wymaga czterech GPU w tensor parallelism, aby pomieścić około 65 GB parametrów BF16, a przepis na trening wymaga ośmiu B200. To prawdziwa maszyna, a nie hobbystyczne wdrożenie, i to wyznacza warunki porównania: modele, z którymi porównuje się AesCode-32B, są wynajmowane za token, a sam model jest wynajmowany za godzinę GPU, niezależnie od tego, czy posiadasz sprzęt, czy nie.

Praktyczny kształt tego porównania to właśnie powód, dla którego istnieje warstwa routingu, i warto być precyzyjnym co do tego, co hostujemy, a czego nie. AesCode-32B nie znajduje się w katalogu OrcaRouter i nie obsługujemy go — nie ma dla niego żadnego hostowanego punktu końcowego, który mógłbym zweryfikować, w tym tego od Microsoftu. W katalogu jest natomiast druga strona stołu: hostowane modele, z którymi porównywałbyś samodzielnie hostowany generator artefaktów, w tym GPT-5.5 oraz mniejsze modele wizyjne Qwen3-VL, dostępne przez jeden klucz API w cenie katalogowej dostawcy z 0% marży, co oznacza, że zmiana ceny przez dostawcę jest u nas widoczna tego samego dnia. Porównywanie wynajmowanego punktu końcowego z modelem, który uruchamiasz sam, nie wymaga drugiej umowy ani drugiego SDK, a DSL routingu pozwala umieścić własne, samodzielnie hostowane wywołanie obok hostowanych, za jednym punktem końcowym. Jeśli AesCode-32B okaże się dobry w tym jednym, co obiecuje jego karta, kosztem sprawdzenia jest rachunek za GPU, a kosztem alternatyw, z którymi go porównujesz, jest jeden klucz, który prawdopodobnie już masz.

Co możesz z tym zrobić dzisiaj, a co nie istnieje

• Pobierz i uruchom — wagi są na licencji Apache 2.0, oparte na backbone Qwen3-VL, z czternastoma shardami BF16 oraz działającą transformersścieżką w wersji powyżej 4.57 i przepisem na vLLM w karcie modelu.

• Odtwórz trening — kod jest na licencji MIT i wystarczająco kompletny, by miał sens: weryfikator nagrody, kreator rubryk, etapy SFT i GDPO, przypięty commit verl oraz patch dodający obsługę Qwen3-VL, a także README, które wymienia tryby awarii, zamiast je ukrywać.

• Oceń to bez referencji — model przyjmuje prompty z obrazem referencyjnym lub bez niego, a najbardziej testowalne twierdzenie karty tkwi w tej konfiguracji.

• Zdobyć do tego API — nie da się. Nie ma hostowanego endpointu, mapowania dostawcy inferencji w repozytorium ani kompilacji GGUF lub MLX; uruchomienie tego oznacza uruchomienie sprzętu.

• Przeczytaj artykuł — jeszcze nie możesz. Karta linkuje artykuł zatytułowany AesCode: Aesthetic Code Generation with Decoupled Cross-Modal Rewards, a jego własny wpis BibTeX podaje miejsce publikacji jako „Under review" i rok 2027. Wyszukiwanie w arXiv nie zwraca żadnego artykułu o tym tytule. Istnieje inny, wcześniejszy artykuł Microsoftu o niemal identycznej nazwie — Code Aesthetics with Agentic Reward Feedback z października 2025 r., w którym udostępniono model AesCoder-4B oraz zbiór danych AesCode-358K — i nic w karcie AesCode-32B nie cytuje go ani nie określa swojego związku z nim. Jeśli szukasz lektur wprowadzających i trafisz właśnie na tamten, czytasz o innym modelu stworzonym przez częściowo tych samych autorów.

• Porównaj to na publicznym rankingu — jeszcze nie. Żaden zewnętrzny indeks nie wygląda na to, by go ocenił, co nie jest zaskakujące w przypadku repozytorium z dwoma pobraniami.

Kogo to powinno obchodzić, a kto powinien poczekać

Grupa docelowa tego jest węższa, niż sugeruje tabela w nagłówku, i bardziej konkretna niż „każdy, kto buduje z modelami”. Jeśli Twój produkt zamienia prompty w prezentacje, plakaty, raporty lub pulpity nawigacyjne, które ktoś musi później edytować, to już odkryłeś wybór, na który ten model jest ukierunkowany: generowanie obrazów daje ci piękny prostokąt, którego nie możesz zmienić, a generowanie kodu daje ci coś edytowalnego, co wygląda, jakby zostało złożone przez kompilator. Model 33B o otwartych wagach, który emituje pełny dokument HTML z prawdziwymi tabelami i specyfikacjami ECharts, który utrzymuje się w granicach około jednego punktu od swojej jakości warunkowanej referencją, gdy nie masz mu żadnej referencji do podania, i który możesz dostroić do własnego stylu firmowego na licencji Apache 2.0, to naprawdę użyteczna rzecz, że coś takiego istnieje. Żaden inny model nie wykonuje dokładnie tego zadania przy tym rozmiarze i na tych warunkach.

Przeciwko temu: wszystko, co wiesz o jakości, pochodzi z tabeli zbudowanej przez dostawcę, schemat oceny, który za nią stoi, został wytworzony przez ten sam potok, który stworzył dane treningowe, a jedyny limit, do którego przyznaje się karta — Styl poniżej 60 dla każdego testowanego systemu — jest dokładnie tym wymiarem, o który najbardziej dbałby produkt wrażliwy na design. Zespół, który z powodów zgodności musi utrzymywać generowanie u siebie i ma zapasowy węzeł z ośmioma GPU, ma dość, by zacząć już dziś. Zespół wybierający model do produkcji w przyszłym tygodniu nie ma niezależnej liczby, na której mógłby oprzeć wybór, i nie powinien odczytywać 85,89 wobec 81,28 jako rozstrzygającego wyniku.

Co zamieniłoby to w opowieść?

Cztery rzeczy, z których żadna jeszcze nie istnieje. Zapowiedź — Microsoft nic nie powiedział, a artykuł, do którego odwołuje się karta, jest wyraźnie oznaczony jako będący w recenzji, więc raport techniczny ze szczegółami treningu wykraczającymi poza podsumowanie karty może pojawić się w dowolnym momencie. Niezależne uruchomienie — twierdzenie o odporności bez referencji i wynik Boundary, który według karty spada do poważnej awarii w 4,3% próbek wobec 34,7% dla GPT-5.5, są tanie w testowaniu i oba warte przetestowania. Wsparcie dla serwowania poza recepturą dostawcy — kompilacja GGUF lub wpis do popularnego środowiska uruchomieniowego zmieniłyby narrację o sprzęcie bardziej niż jakikolwiek benchmark. I drugi punkt danych w kwestii rozmiaru: model 8B uzyskujący 82,94 Overall wobec 85,89 modelu 32B w tej samej tabeli to dwupunktowa różnica przy jednej czwartej parametrów — coś, co albo zostanie zreprodukowane, albo po cichu przestanie być wspominane.

Dopóki któreś z nich nie nastąpi, dokładny opis AesCode-32B jest następujący: rzeczywiste wagi na licencji permisywnej, stack treningowy opisany wystarczająco szczegółowo, aby dobrze wyposażone laboratorium mogło go odtworzyć, tabela benchmarków będąca pomiarem dokonanym przez jedną firmę na jej własnym modelu i na dwóch modelach konkurencji oraz historia repozytorium, która nie pozwoli ci nazwać żadnego pojedynczego dnia datą premiery. To ciekawszy artefakt, niż sugeruje jego licznik dwóch pobrań, i mniej sprawdzony, niż wskazuje jego 85,89. Obie połowy tego zdania to uczciwy odczyt na dzień 11 października 2026.