AesCode-32B: o discreto modelo de 33B da Microsoft que escreve apresentações como HTML editável

As marcas de data e hora no AesCode-32B não coincidem entre si, e a divergência é praticamente tudo o que há para relatar. O repositório do Hugging Face microsoft/AesCode-32B foi criado em 29 de setembro de 2026, mas tudo nele chegou em um único commit datado de 7 de outubro de 2026, cuja mensagem é simplesmente "Release AesCode-32B" — e a pilha de treinamento que torna o resultado reproduzível foi enviada para github.com/microsoft/AesCode em 8 de outubro. A Microsoft não anunciou nada: nenhum post de blog, nenhum preprint no arXiv, nenhuma submissão a leaderboard, nenhuma página do modelo em seu próprio site. O que existe é um modelo de linguagem visual de 33 bilhões de parâmetros que recebe um prompt e emite um documento HTML completo e autocontido — um slide, um pôster, um dashboard — além de um modelo complementar menor, microsoft/AesCode-8B. Ambos passaram por ajuste fino a partir de modelos de visão Qwen3-VL — Qwen3-VL-32B-Instruct e Qwen3-VL-8B-Instruct respectivamente — ambos são Apache 2.0, e ambos podem ser baixados hoje.

O id do repositório é microsoft/AesCode-32B e o card abre com o truque: o AesCode combina seu prompt com uma imagem gerada a partir desse mesmo prompt, usa a imagem como referência estética e segue o texto para o conteúdo de fato. Geradores de imagem compõem uma página bonita e renderizam mal os números nela; modelos de código acertam os números e não conseguem ver como a página fica. O AesCode é uma tentativa de ter os dois, e o resumo honesto dele em 11 de outubro de 2026 é que os pesos são reais e verificáveis, os números de benchmark são do próprio laboratório em um harness que o laboratório escreveu, e ninguém fora da Microsoft publicou um número para ele até agora. Este artigo mantém essas três categorias separadas do começo ao fim.

O que está realmente no repositório, byte a byte

Comece pelo que você pode verificar sem confiar em uma palavra do cartão do modelo. O repositório de 32B contém quatorze fragmentos safetensors que totalizam 66.714.912.704 bytes, o que, em BF16, corresponde a aproximadamente 33,4 bilhões de parâmetros — consistente com o "33B params" do cartão e com seu aviso de que os pesos sozinhos precisam de cerca de 65 GB de memória do acelerador. A configuração declara Qwen3VLForConditionalGeneration como a arquitetura e qwen3_vl como o tipo de modelo, portanto esta não é uma nova arquitetura e não precisa de uma: é carregado com transformers>=4.57, e o cartão traz um comando vLLM que o serve em quatro ranks de tensor-parallel com duas imagens permitidas por prompt e um teto de 24.576 tokens.

Os contadores de engajamento são a parte mais silenciosa do lançamento. Dois downloads e um like no repositório 32B no momento em que escrevo. Não há entrada no mapeamento de provedores de inferência do Hugging Face, o que significa que nenhum endpoint hospedado está configurado por trás da página do repositório, e nenhuma build de GGUF, MLX ou llama.cpp é anunciada em lugar algum. Para um modelo que carrega o nome da Microsoft e apresenta resultados que superam o GPT-5.5 na própria tabela do fornecedor, essa é uma presença surpreendentemente pequena — e é a evidência mais forte disponível de que isso foi publicado sem um lançamento por trás.

O repositório de código complementar preenche a outra metade da linha do tempo, e é onde a questão da data de lançamento se torna genuinamente ambígua. microsoft/AesCode foi criado em 23 de julho de 2026 — dez semanas antes dos pesos — e contém quatorze commits, todos eles de autoria do mesmo contribuidor e todos com carimbo de data/hora dentro de vinte segundos uns dos outros em 8 de outubro de 2026, entre 23:14:04 e 23:14:24 UTC. Eles incluem a especificação para gerar prompts e requisitos verificáveis, o pipeline de dados que constrói grafos de design e perguntas de rubrica, um estágio de SFT de início a frio, o loop de aprendizado por reforço GDPO, um verificador de renderização baseado em Playwright, testes e o README que documenta tudo isso. Não há releases nem tags, a descrição do repositório está vazia e ele tem uma estrela.

Então, qual é a data do lançamento? O registro do repositório diz 29 de setembro. O commit que carrega o modelo diz 7 de outubro. O código que explica como o modelo foi feito diz 8 de outubro. Três carimbos de data e hora dentro de uma única janela de duas semanas, nenhum deles acompanhado de uma frase da Microsoft dizendo "estamos lançando isto". Considere 7–8 de outubro como a data efetiva para os artefatos que a maioria das pessoas realmente vai baixar, e 29 de setembro como a data em que o repositório foi reservado. Qualquer pessoa que lhe diga que o AesCode-32B "foi lançado" em um dia específico está escolhendo um desses carimbos de data e hora em seu nome.

O mecanismo: uma imagem como orientação estética, um grafo como a recompensa

A alegação técnica do cartão é restrita e específica, o que é um ponto a seu favor. O modelo é treinado com ajuste fino supervisionado com inicialização a frio em 3.000 demonstrações a uma taxa de aprendizado de 1e-5, depois com GDPO — uma variante de otimização de política relativa ao grupo — sobre 7.408 prompts por 520 passos. O modelo de 8B usou a mesma receita e parou em 400 passos. A execução de RL usou o mecanismo híbrido FSDP-vLLM do verl sem crítico e sem modelo de recompensa treinado separadamente, AdamW a uma constante de 5e-6 sem aquecimento, 128 prompts por passo com oito rollouts cada, e prompt e resposta limitados a 8.192 tokens cada.

O que torna a recompensa incomum é que ela não é um único escalar. Cada alvo de treinamento é descrito como um grafo de design que cobre toda a tela, para que propriedades individuais possam ser atribuídas separadamente. Desse grafo vêm sete canais — execução, texto, limite, tablechart, layout, espaço em branco e design — cada um normalizado dentro do seu grupo de rollout antes da agregação, para que um sinal dominante não possa abafar os outros. Verificadores determinísticos pontuam o que pode ser analisado a partir do código e de sua renderização; um juiz de visão-linguagem pontua o que não pode, usando uma rubrica vinculada aos próprios elementos e relações do grafo. O HTML candidato é pontuado renderizando-o em um navegador Playwright em sandbox com requisições externas bloqueadas, que exporta o DOM, estilos computados, caixas delimitadoras, status do console e uma captura de tela.

A consequência de engenharia vale a pena ser declarada porque aparece na saída que você recebe: o modelo é treinado para emitir tabelas como estruturas de tabela HTML reais e gráficos como especificações ECharts, então ambos são diretamente inspecionáveis em vez de embutidos em pixels. Essa é a diferença entre um deck que você pode entregar a um designer e um deck que você pode entregar a um linter. Os requisitos de reprodução são correspondentemente pesados — o README pede Python 3.10, CUDA 12.6 e um nó de oito GPUs B200, fixa um commit específico do verl e declara claramente que é necessário um patch contra ele porque o verl padrão não tem suporte a Qwen3-VL, e avisa que, sem as bibliotecas de sistema do Playwright, o navegador falha ao iniciar e as páginas pontuam zero, e que, sem a pilha de OCR fixada, o canal de recompensa correspondente retorna zero em vez de se abster e corrompe silenciosamente o sinal.

A tabela de referência, e as quatro razões para não se apegar a ela

Os números de destaque do AesCode-32B vêm de 300 amostras de infográficos, três gerações por prompt com temperature 0.8 e top-p 0.95, até 12.000 tokens de saída cada, sem seleção entre as gerações. As pontuações são percentuais. Com referência, o modelo de 32B reporta Texto 95,34, Limite 97,27, Tabela/Gráfico 90,37 e uma média de Regras de 94,33; no lado visual, Conteúdo 85,76, Layout 90,58, Estilo 55,99, para uma média Visual de 77,44 e um Geral de 85,89. Na mesma tabela, o GPT-5.5 com uma referência obtém 81,28 no Geral e o Claude Opus 4.8 com uma referência obtém 80,39, enquanto o backbone Qwen3-VL-32B-Instruct a partir do qual o modelo foi treinado obtém 61,10.

Quatro ressalvas devem vir no mesmo fôlego que esses números, e nenhuma delas é uma difamação ao trabalho. Primeiro, cada linha — incluindo as linhas do GPT-5.5 e do Claude Opus 4.8 — foi executada pela Microsoft no harness da Microsoft com a rubrica da Microsoft: esses não são os números dos outros laboratórios, são medições da Microsoft sobre modelos concorrentes, e o próprio card chama a rubrica de "específica da amostra" para cada grafo de design. Segundo, a rubrica é produzida pelo mesmo pipeline que gerou os dados de treinamento, que é exatamente a configuração na qual um benchmark pode tender para os pontos fortes de um modelo; o card é franco sobre os limites dessa rubrica — Style, que exige que um design não precise de nenhuma revisão visual adicional antes da entrega, é chamado de "o teto compartilhado para todos os sistemas", e nenhum modelo da tabela ultrapassa 60. Terceiro, não há medição independente deste modelo em lugar nenhum: nenhuma entrada em ranking de terceiros, nenhuma reprodução e, considerando que houve dois downloads, quase certamente ninguém fora do laboratório o está executando ainda. Quarto, a comparação é sutilmente assimétrica de um modo que vale a pena notar — as linhas do AesCode-32B são todas condicionadas por referência, então o modelo está sendo medido na configuração para a qual foi treinado, o que o card reconhece ao mostrar que a qualidade ainda é mais alta quando uma referência é fornecida.

O único resultado da tabela que se sustenta melhor do que a manchete é uma alegação de robustez, e não de qualidade. Omitir a imagem de referência na inferência custa ao AesCode-8B apenas 1,00 ponto Visual, contra 19,55 para seu backbone Qwen3-VL-8B-Instruct e 10,04 para o GPT-5.5. O argumento do model card é que o treinamento condicionado à referência internaliza o planejamento visual na política, em vez de ensinar o modelo a copiar o que vê. Isso é relatado pelo fornecedor e não reproduzido, e também é o tipo de afirmação que uma única execução independente resolveria — e o tipo que mais importa em produção, onde você nem sempre terá uma imagem de referência à mão.

Quanto custa operar, e o que isso significa para a comparação

Nada neste modelo é barato para auto-hospedar. De dez a dez mil tokens é a faixa de trabalho de um único artefato, e um documento completo com uma especificação do ECharts está mais próximo do topo dessa faixa do que da base, então cada geração é longa. A própria receita de serviço do card pede 4 GPUs em paralelismo de tensor para comportar 65 GB de parâmetros BF16, e isso significa oito B200s. Isso é um servidor, não um hobby, e define os termos da comparação: os modelos com os quais o AisCode-2B está sendo comparado são alugados por token, e o modelo é alugado por GPU, quer você seja dono do hardware ou não.

A forma prática dessa comparação é justamente a razão de existir uma camada de roteamento, e vale a pena ser exato sobre o que hospedamos e o que não hospedamos. O AesCode-32B não está no catálogo do OrcaRouter e não o servimos — não existe endpoint hospedado para ele em nenhum lugar que eu consiga verificar, incluindo o da Microsoft. O que está no catálogo é o outro lado da mesa: os modelos hospedados com os quais você compararia um gerador de artefatos auto-hospedado, incluindo o GPT-5.5 e os modelos de visão Qwen3-VL menores, acessíveis por meio de uma única chave de API pelo preço de tabela do provedor, com 0% de margem, o que significa que uma mudança de preço do fornecedor entra em vigor do nosso lado no mesmo dia. Comparar um endpoint alugado com um modelo que você mesmo executa não exige um segundo contrato nem um segundo SDK, e uma DSL de roteamento permite que uma chamada auto-hospedada fique ao lado das hospedadas por trás de um único endpoint. Se o AesCode-32B se mostrar bom na única coisa que sua ficha técnica promete, o custo de descobrir isso é uma conta de GPU, e o custo das alternativas com as quais você está comparando é uma chave que você provavelmente já tem.

O que você pode fazer com isso hoje, e o que não existe

• Baixe e execute — os pesos são Apache 2.0, seguindo o backbone Qwen3-VL, com catorze shards BF16 e um caminho transformers funcional acima da versão 4.57 e uma receita vLLM no card.

• Reproduza o treinamento — o código tem licença MIT e é completo o suficiente para ser significativo: o verificador de recompensa, o construtor de rubricas, os estágios de SFT e GDPO, um commit fixado do verl mais o patch que adiciona suporte ao Qwen3-VL, e um README que lista os modos de falha em vez de ocultá-los.

• Avalie-o sem referência — o modelo aceita prompts com ou sem a imagem de referência, e a afirmação mais testável do card está nessa configuração.

• Conseguir uma API para isso — você não consegue. Não há endpoint hospedado, nem mapeamento de provedor de inferência no repositório, e não há build GGUF ou MLX; executar isso significa executar o hardware.

• Leia o artigo — você ainda não consegue. O cartão aponta para um artigo intitulado AesCode: Aesthetic Code Generation with Decoupled Cross-Modal Rewards, e sua própria entrada BibTeX informa o veículo como "em avaliação" e o ano como 2027. Uma busca no arXiv não retorna nenhum artigo com esse título. Há um artigo diferente e anterior da Microsoft com um nome quase idêntico — Code Aesthetics with Agentic Reward Feedback de outubro de 2025, que lançou um modelo AesCoder-4B e um conjunto de dados AesCode-358K — e nada no cartão do AesCode-32B o cita ou declara uma relação com ele. Se você for procurar leituras de contexto e, em vez disso, acabar caindo nesse outro, você está lendo sobre um modelo diferente criado por autores em comum.

• Compará-lo em um placar público — ainda não. Nenhum índice de terceiros parece tê-lo avaliado, o que não é surpreendente para um repositório com dois downloads.

Quem deve se importar, e quem deve esperar

O público para isto é mais restrito do que a tabela principal sugere e mais específico do que "qualquer pessoa que construa com modelos". Se o seu produto transforma prompts em apresentações, pôsteres, relatórios ou dashboards que alguém tem de editar depois, você já descobriu a escolha que este modelo tem em vista: a geração de imagens lhe dá um retângulo bonito que você não pode alterar, e a geração de código lhe dá algo editável que parece ter sido montado por um compilador. Um modelo de pesos abertos de 33B que emite um documento HTML completo com tabelas reais e especificações ECharts, que se mantém dentro de cerca de um ponto da sua qualidade condicionada por referência quando você não tem referência para lhe dar, e que você pode ajustar finamente ao estilo próprio da sua empresa sob a Apache 2.0, é algo genuinamente útil de existir. Nenhum outro modelo faz exatamente esse trabalho neste tamanho com estes termos.

Em contrapartida: tudo o que você sabe sobre a qualidade vem de uma tabela que o fornecedor montou, a rubrica por trás dela foi produzida pelo mesmo pipeline que criou os dados de treinamento, e o único teto que a ficha admite — Estilo abaixo de 60 para todos os sistemas testados — é justamente a dimensão com que um produto sensível a design mais se importaria. Uma equipe com um motivo de conformidade para manter a geração internamente e um nó sobressalente de oito GPUs tem o suficiente para começar hoje. Uma equipe que está escolhendo um modelo para produção na próxima semana não tem nenhum número independente no qual basear a escolha e não deveria interpretar 85,89 contra 81,28 como um resultado definitivo.

O que transformaria isto numa história?

Quatro coisas, nenhuma das quais existe ainda. Um anúncio — a Microsoft não disse nada, e o artigo referenciado pela ficha está explicitamente em revisão, então um relatório técnico com detalhes de treinamento além do resumo da ficha pode aparecer a qualquer momento. Uma execução independente — a alegação de robustez sem referência e a pontuação Boundary, que, segundo a ficha, cai para uma falha grave em 4,3% das amostras, contra 34,7% do GPT-5.5, são ambas baratas de testar e ambas valem a pena testar. Suporte de serving fora da receita do fornecedor — uma build GGUF ou uma entrada em runtime mainstream mudaria o cenário de hardware mais do que qualquer benchmark mudaria. E um segundo ponto de dados sobre a questão do tamanho: um modelo 8B obtendo 82,94 Overall contra 85,89 do 32B na mesma tabela é uma diferença de dois pontos para um quarto dos parâmetros, que é o tipo de coisa que ou é reproduzida ou silenciosamente deixa de ser mencionada.

Até que uma dessas coisas se concretize, a descrição precisa do AesCode-32B é esta: pesos reais sob uma licença permissiva, uma pilha de treinamento detalhada o suficiente para ser reproduzida por um laboratório bem equipado, uma tabela de benchmarks que é a medição de uma empresa do seu próprio modelo e da de dois concorrentes, e um histórico de repositório que não permite que você chame nenhum dia isolado de data de lançamento. É um artefato mais interessante do que seu contador de dois downloads sugere, e um menos comprovado do que seu 85,89 implica. As duas metades dessa frase são a leitura honesta em 11 de outubro de 2026.