AesCode-8B foi lançado discretamente: o modelo 8B da Microsoft escreve slides e dashboards como HTML

O número mais interessante no novo lançamento da Microsoft é 1,00. Retire a imagem de referência de AesCode-8B — um modelo de 8 bilhões de parâmetros que escreve slides, pôsteres e dashboards como HTML e CSS editáveis — e sua pontuação visual cai um ponto em cem. Retire a mesma referência de Qwen3-VL-8B-Instruct, o modelo de pesos abertos a partir do qual o AesCode-8B foi ajustado, e a queda é de 19,55 pontos. Do GPT-5.5 é de 10,04. É nessa comparação que reside o verdadeiro resultado da pesquisa, e ela está por baixo de uma manchete que a Microsoft também publicou: em sua própria rubrica de 300 amostras, a pontuação geral de 82,94 do AesCode-8B supera por pouco o GPT-5.5 condicionado à referência, com 81,28, e o Claude Opus 4.8, com 80,39, com um irmão maior, AesCode-32B, com 85,89.

Nada sobre este lançamento foi anunciado. A Microsoft publicou os pesos no Hugging Face em 2026-10-07 sob a licença Apache 2.0 — AesCode-8B, além de um modelo complementar de 32B construído da mesma forma a partir do Qwen3-VL-32B-Instruct — e enviou o código de treinamento e avaliação para o GitHub no dia seguinte. Não há post no blog da Microsoft Research, nota de lançamento, página de produto nem preprint: a citação na ficha do modelo diz "Under review", ano 2027, o que é um espaço reservado, e não uma data. Em 2026-10-11, o repositório do 8B mostra dois downloads e uma curtida; o repositório do GitHub mostra uma estrela. Tudo abaixo que contém um número é ou um carimbo de data/hora que você mesmo pode verificar, ou um número que a Microsoft relatou sobre seu próprio conjunto de avaliação — e essa distinção importa mais do que o normal aqui, porque nenhuma parte deste modelo foi medida por mais ninguém.

O que foi enviado e o que não está na caixa

Três datas definem este lançamento, e são as únicas datas que ele contém. O repositório do Hugging Face para microsoft/AesCode-8B foi criado em 29 de setembro de 2026, os pesos foram commitados com a mensagem "Release AesCode-8B" às 03:35 UTC de 7 de outubro de 2026, e o microsoft/AesCode, repositório de código, se tornou público no dia seguinte, 8 de outubro de 2026, às 23:14 UTC. Os pesos de 32B chegaram na mesma janela de commits. Nada nesse intervalo foi anunciado em lugar nenhum.

• Pesos — quatro shards safetensors totalizando 17.543.408.408 bytes, o que equivale a aproximadamente 8,8 bilhões de parâmetros bf16. A Hugging Face rotula o modelo como 8B; o campo de tamanho dela o arredonda para 9B. Isso é arredondamento, não uma discrepância.

• Arquitetura — um ajuste fino direto da receita do Qwen3-VL: Qwen3VLForConditionalGeneration, 36 camadas ocultas, tamanho oculto 4.096, 32 cabeças de atenção com 8 cabeças de chave-valor, um vocabulário de 151.936 tokens e posições mrope intercaladas. Ele requer transformers 4.57 ou posterior.

• Contexto e saída — as execuções relatadas usaram um contexto de 24.576 tokens com até 12.000 tokens de saída, gerados com temperatura 0,8 e top-p 0,95 em três rollouts por prompt, sem seleção. O comando de serviço do vLLM permite duas imagens por prompt: a de referência, e nada mais, porque a saída é texto.

• Licença — Apache 2.0, descrita como seguindo o backbone Qwen3-VL. Totalmente permissiva, sem restrições de acesso, sem adendo de uso aceitável.

• Não incluído — os dados de treino e avaliação. O repositório disponibiliza o pipeline e documenta as entradas e saídas esperadas, e menciona os arquivos de divisão que espera, mas nenhuma versão do conjunto de dados está listada nem no model card nem no repositório de código. Você recebe a receita, não os ingredientes.

• Também não está incluído — nenhum endpoint hospedado. Não conseguimos encontrar uma API que disponibilize o AesCode-8B em lugar nenhum, e ele não está no nosso próprio catálogo. Até que um provedor o adote, avaliá-lo significa carregar os pesos nas suas próprias GPUs.

Vale a pena citar a forma como a Microsoft enquadra a questão, porque ela constitui todo o briefing de design: os modelos de código "não conseguem ver como layout, hierarquia e cor se combinam no canvas", enquanto os geradores de imagens "compõem páginas visualmente atraentes, mas frequentemente renderizam mal texto, números e relações lógicas". O AesCode é a tentativa de retirar o senso de composição de um e a verificabilidade do outro.

O resultado de 1,00 ponto, explicado

Eis o mecanismo por trás do número no primeiro parágrafo. Durante o treinamento, cada prompt é emparelhado com uma imagem de referência gerada a partir desse mesmo prompt — as próprias execuções da Microsoft usaram o GPT-Image-2 para a imagem e o GPT-5.5 para expandir uma ideia curta no prompt de conteúdo detalhado. A referência não tem autoridade sobre o conteúdo; o prompt de texto continua sendo a fonte da verdade. O que a referência fornece é layout e estilo, e a função de recompensa é construída para manter essas duas coisas separadas.

A consequência é que o prior visual acaba na política, e não na entrada. O AesCode-8B perde 1,00 ponto Visual quando a referência é removida na inferência. Seu próprio backbone, avaliado condicionado à referência em 44,72 Visual, perde 19,55 pontos sem uma. O GPT-5.5 perde 10,04. A versão destilada disso: o modelo deixou de precisar da imagem.

A segunda metade do resultado é a que é fácil de passar despercebida. A Microsoft relata que as recompensas baseadas em referências elevaram o Visual apenas com prompt de 25,17 para 69,71 — o modelo que nunca vê uma referência no momento da inferência ainda se beneficia de ter sido treinado com elas. Se você estava planejando pular a etapa de geração de referências no seu próprio pipeline, esse é o número que diz que você também não deveria se dar ao trabalho de pulá-la no treinamento.

A ressalva honesta sobre tudo isso: esta é a rubrica da Microsoft, sobre as 300 amostras de infográficos da Microsoft, pontuada três vezes por prompt, sem seleção seletiva de resultados. Metade da pontuação vem de verificadores determinísticos, que qualquer pessoa poderia reproduzir; a outra metade, as dimensões da lista de verificação, é avaliada por um modelo de visão e linguagem cuja identidade a documentação não nomeia. Você não pode reproduzir a segunda metade sem saber qual avaliador a produziu.

Onde o gosto entra nos pesos

O método de treino é a parte desta versão com as ideias mais transferíveis, e é mais mecânico do que o resultado sugere.

• Tudo é, antes de tudo, um grafo.Cada alvo é representado como um grafo de design: nós para texto, gráficos, tabelas, cartões, regiões e espaços para imagens, e arestas para contenção, alinhamento, ordem e conexão. O objetivo do grafo é a atribuição — cada propriedade no canvas pertence a um elemento nomeado, de modo que cada propriedade possa ser pontuada individualmente.

• Sete canais de recompensa.Seis verificadores determinísticos checam as coisas analisáveis — execução, texto exato, limites, dados de tabela e gráfico, layout semântico, espaços em branco — e uma Rubrica de Grafo Visual específica por amostra, construída como perguntas de sim/não vinculadas ao grafo sobre geometria e posicionamento, pontua o restante. Os canais são execução, texto, limite, tablechart, layout, espaços em branco e design.

• Os canais são normalizados antes de serem combinados.O GDPO normaliza cada canal dentro do seu grupo de rollout, de modo que um sinal denso baseado em regras não possa abafar o sinal visual esparso. A Microsoft mede isso em 5,12 pontos Visual a mais do que o GRPO escalar simples com a mesma configuração — relatado pelo fornecedor, mas uma ablação concreta em vez de uma afirmação.

• A pontuação é feita por renderização.O HTML candidato é renderizado em um navegador Playwright em sandbox, com solicitações externas bloqueadas, e o harness lê de volta o DOM, estilos computados, caixas delimitadoras, status do console e uma captura de tela. Tabelas devem ser tabelas HTML; gráficos devem ser especificações ECharts. Essa restrição está fazendo um trabalho real — ela força a saída a assumir um formato que um verificador consegue analisar.

• A receita em si. Fine-tuning supervisionado com inicialização a frio em 3.000 demonstrações com taxa de aprendizado de 1e-5, depois GDPO sobre 7.408 prompts por 400 etapas no motor híbrido FSDP-vLLM da verl, sem crítico e sem modelo de recompensa treinado separadamente. AdamW a uma constante de 5e-6, sem warmup, decaimento de peso 0,01, 128 prompts por etapa com 8 rollouts cada, coeficientes de KL e entropia ambos 0,001, prompt e resposta limitados a 8.192 tokens cada. As execuções publicadas usaram um único nó com oito NVIDIA B200s. AesCode-32B usa a mesma receita por 520 etapas.

Lido como um todo, este é um artigo de design de recompensas vestindo um lançamento de modelo como fantasia — e isso é consistente com a citação que diz "Em revisão" em vez de apontar para um preprint.

O placar, e quem o avaliza

Tudo o que se segue é a avaliação da própria Microsoft, relatada no cartão de modelo, em 300 amostras de infográficos. Regra calcula a média das verificações programáticas de Text, Bound e Chart; Visual calcula a média das dimensões Content, Layout e Style da lista de verificação; Geral é a média das duas. As pontuações são percentagens calculadas em média sobre três gerações por prompt, sem seleção. "Ref." indica se foi fornecida ao modelo uma referência gerada juntamente com o prompt.

• AesCode-8B com referência — Texto 94,06, Limite 88,36, Gráfico 87,79, Regra 90,07; Conteúdo 86,41, Layout 87,80, Estilo 53,21, Visual 75,80; Geral 82,94.

• Em comparação com seu próprio backbone — o Qwen3-VL-8B-Instruct condicionado por referência obtém 44,72 em Visual e 51,93 em Overall. Isso representa um ganho de 31,1 pontos em Visual e um ganho de 31,0 pontos em Overall, e é a comparação menos surpreendente da tabela, já que o objetivo central do treinamento é a metade visual.

• Contra o GPT-5.5, condicionado por referência — Geral 81.28, Conteúdo 82.44, Layout 89.93 e Estilo 57.91.

• Contra o Claude Opus 4.8, condicionado por referência — Geral 80,39, Conteúdo 86,42, Layout 89,76.

• AesCode-32B, condicionado por referência — Texto 95,34, Limite 97,27, Gráfico 90,37, Regra 94,33, Layout 90,58, Visual 77,44, Geral 85,89. Vinte e dois vírgula quatro pontos de Visual sobre seu próprio backbone de 32B.

• O teto de Style — nenhum modelo na tabela ultrapassa 60, e a pontuação de 57,91 do GPT-5.5 é a melhor entre eles. O AesCode-8B fica em 53,21. A definição da própria Microsoft é implacável: o Style só credita um design quando ele não precisa de mais nenhuma revisão visual antes da entrega. Portanto, na única dimensão que mede se um humano realmente publicaria a página sem edição, o modelo 8B não é o líder.

• Falhas de limite — uma falha grave de transbordamento do canvas volta a ocorrer em 4,3% das 300 amostras, contra 34,7% do GPT-5.5. O transbordamento é o modo de falha que torna o HTML gerado inutilizável, e não apenas feio.

Agora a parte que importa tanto quanto a tabela. Todos os números acima são relatados pelo fornecedor e não foram reproduzidos. O AesCode-8B não aparece em nenhum ranking independente que conseguimos encontrar, e a comparação com o GPT-5.5 e o Claude Opus 4.8 está sendo feita com a rubrica da Microsoft, numa tarefa para a qual esses modelos não foram ajustados, com uma definição de "Layout" que recompensa o simples fato de gerar uma página. Uma pontuação de 94,06 em Texto não significa que este modelo supere o GPT-5.5 em texto. Significa que ele posiciona rótulos sem contradizer o prompt em páginas de infográfico, o que é uma alegação muito menor. O resultado de Estilo é o indício de que a rubrica não está manipulada em favor do AesCode — a maior vitória no placar vem acompanhada do maior número nada lisonjeiro logo ao lado dela.

O que está confirmado e o que não está

Como isso foi lançado discretamente, vale a pena separar os dois explicitamente.

• Confirmado — os pesos existem e podem ser baixados sob a Apache 2.0; os dois carimbos de data/hora de lançamento estão nos repositórios; a arquitetura, a contagem de parâmetros, o comprimento de contexto e as configurações de amostragem estão todos na configuração publicada e no cartão do modelo; a receita de treinamento e o design de recompensa estão documentados com detalhe suficiente para se argumentar; o código, a pilha de verificação e o construtor de rubricas são públicos; existe um companheiro de 32B.

• Não confirmado — qualquer um dos números de benchmark, por qualquer pessoa que não seja o fornecedor. O artigo, que a própria documentação descreve como em revisão. A identidade do juiz de visão-linguagem por trás da metade visual das pontuações. Se algum provedor irá hospedá-lo. Se o contexto de 24.576 tokens se sustenta em apresentações reais com vários slides, já que a avaliação relatada é em páginas de infográfico individuais. E qualquer coisa sobre comportamento fora do inglês — a etiqueta de idioma do cartão do modelo é apenas "en".

Se você quiser executá-lo, e quanto isso custa

Qwen3-8B-Instruct — do qual o AesCode-8B foi derivado, e a mais forte comparação individual disponível até que alguém publique um resultado independente do AesCode — é outra questão:

O caminho de serving do próprio AesCode-8B é curto, e o model card o fornece diretamente: vllm serve microsoft/AesCode-8B --limit-mm-per-prompt image=2 --max-model-len 24576, com transformers 4.57 ou mais recente para a rota sem vLLM, e um trecho de código Python que aceita uma imagem de referência opcional antes do prompt de texto.

A conta que você mesmo precisa fazer é a de memória. 17,5 GB de pesos bf16 precisam caber junto com um cache KV para um contexto de 24.576 tokens e até duas imagens, então uma única placa de 24 GB é tecnicamente suficiente para os pesos e desconfortavelmente apertada para todo o resto; 40-48 GB, ou duas placas de 24 GB, é o piso realista. O companheiro de 32B é um problema de outra ordem — seus shards somam 66,7 GB, então ele precisa de paralelismo de tensores e um nó multi-GPU. Reserve também um renderizador: o modelo emite um documento HTML completo, e toda alegação de qualidade sobre ele é feita renderizando esse documento, então avaliar suas próprias saídas significa subir o Playwright com requisições externas bloqueadas.

Não precisa de gerar uma imagem de referência no momento da inferência — é exatamente isso que o resultado de 1,00 ponto lhe dá —, mas a documentação é clara ao afirmar que a qualidade continua a ser mais elevada quando uma é fornecida, pelo que a configuração honesta é opcional quanto à referência em vez de livre de referência.

O AesCode-8B não é algo que o OrcaRouter roteie, e também não conseguimos encontrá-lo hospedado em nenhum outro lugar, então uma avaliação atualmente significa pesos no seu próprio hardware. A espinha dorsal dele é outra história. Qwen3-VL-8B-Instruct pode ser roteado pelo OrcaRouter hoje a US$ 0,18 por milhão de tokens de entrada e US$ 0,70 por milhão de saída, com um contexto de 131.072 tokens — o que faz dele a forma barata de ver o que a versão não ajustada dessa arquitetura faz com os seus próprios prompts de infográfico antes de você gastar uma semana de GPU reproduzindo a receita de outra pessoa. O OrcaRouter repassa o preço de tabela do provedor com 0% de margem e faz failover automaticamente entre provedores, então essa comparação custa uma chave e nenhum segundo contrato; se o AesCode-8B algum dia chegar a um provedor que roteamos, ele estará no catálogo no mesmo dia. E, se você o hospedar por conta própria, os modelos para os quais você faria fallback em produção são os que já estão por trás desse único endpoint — o que é a postura razoável para um modelo lançado discretamente e com zero avaliação independente.

O que assistir

Duas coisas, e nenhuma delas é outra tabela de benchmark.

O primeiro é o artigo. "AesCode: Aesthetic Code Generation with Decoupled Cross-Modal Rewards" é citado como em revisão para 2027, o que soa como um marcador de posição digitado em uma entrada BibTeX, e não um cronograma. Até que um preprint ou uma versão final (camera-ready) apareça, a explicação do canal de recompensa acima é um resumo de um abstract que ninguém fora do laboratório consegue ler — e as perguntas interessantes, como a forma como o Visual Graph Rubric lida com um grafo de design que é ele próprio incorreto, só são respondidas no texto completo.

O segundo é hospedagem. Um modelo Apache-2.0 de 8,8B que emite HTML estruturado e verificável é exatamente o formato que uma plataforma adota, porque a saída é inspecionável de uma forma que um JPEG não é. No momento em que alguém o serve, isso deixa de ser uma decisão de auto-hospedagem e passa a ser uma decisão de roteamento — e a comparação de custos deixa de ser sobre horas de GPU.

O que não se deve esperar é um veredito inequívoco. O Estilo é o teto para todos os sistemas daquela tabela, incluindo este, e o Estilo é a única dimensão que pergunta se uma pessoa publicaria a página como está. A leitura defensável do AesCode-8B é estreita e real: ele é muito bom nas partes do design visual que podem ser verificadas por uma máquina, é mediano na parte que não pode, e é o primeiro modelo de pesos abertos neste nicho em que a lacuna entre essas duas coisas é o ponto do lançamento, e não um acidente dele.