AesCode-8B vs Qwen3-8B: Eles parecem pai e filho, mas não são

Os nomes convidam a um erro. AesCode-8B é um modelo 8B com um backbone Qwen3-VL-8B-Instruct, Qwen3-8B é o modelo 8B do próprio fornecedor, e a leitura óbvia é que o primeiro é um ajuste fino do segundo. Não é. A configuração publicada do AesCode-8B declara Qwen3-VL-8B-Instruct como base — o irmão de visão e linguagem, um checkpoint diferente com uma função diferente — e os metadados do Hugging Face o listam como um ajuste fino desse modelo, e não do Qwen3-8B apenas de texto. Os dois modelos AesCode nessa faixa de parâmetros são primos, e não pai e filho, e essa distinção é precisamente o que torna esta página útil: ela informa o que a Microsoft adquiriu ao partir de um checkpoint de visão e linguagem, o que isso custou no lado do texto e por que uma comparação com o generalista 8B simples da família acaba medindo um fork em vez de uma atualização.

Ambos são Apache 2.0 e ambos podem ser baixados, mas seus registros de publicação não poderiam ser mais diferentes. O Qwen3-8B foi lançado em abril de 2025 como parte da linha da geração Qwen3 do fornecedor, com documentação, integração ao ecossistema e dezoito meses de implantações de terceiros por trás dele. O AesCode-8B não traz data de lançamento em lugar algum de seus arquivos. A Microsoft criou o repositório no Hugging Face em 2026-09-29, fez commit dos pesos com a mensagem "Release AesCode-8B" às 03:35 UTC de 2026-10-07 e colocou o código de treinamento no GitHub no dia seguinte. Não há publicação no Microsoft Research, nem nota de lançamento, nem página de produto e nem artigo — a citação do model card diz "Under review", com o ano provisório 2027, e o repositório mostrava dois downloads até o momento desta redação. Tudo o que é quantitativo sobre o AesCode-8B abaixo é da própria Microsoft e não foi reproduzido por ninguém.

A árvore genealógica que os nomes escondem

A linha da geração Qwen3 contém vários checkpoints da classe 8B que compartilham uma linhagem e não muito mais. O Qwen3-8B é o generalista somente texto: aproximadamente 8,2 bilhões de parâmetros totais, com cerca de 7 bilhões não de embedding, atenção de consulta agrupada, contexto nativo de 32K tokens extensível a 131K por meio do YaRN, e treinamento em 119 idiomas e dialetos. Ele raciocina, conversa, programa e chama ferramentas, e é um dos modelos 8B mais amplamente auto-hospedados no ecossistema aberto exatamente por esses motivos. O Qwen3-VL-8B-Instruct é o membro multimodal: a mesma geração da família, uma torre de visão dedicada por cima, imagem e texto na entrada, texto na saída.

A Microsoft partiu da segunda. A configuração do AesCode-8B traz Qwen3VLForConditionalGeneration, com 36 camadas ocultas, tamanho oculto de 4.096, 32 cabeças de atenção e 8 cabeças de chave-valor, um vocabulário de 151.936 tokens e posições mrope intercaladas, e exige transformers 4.57 ou mais recente. Os shards somam 17.543.339.408 bytes, cerca de 8,8 bilhões de parâmetros bf16, e é por isso que o campo de tamanho arredondado do Hugging Face indica 9B, enquanto o fornecedor indica 8B. Trata-se de arredondamento, e não de uma discrepância, e a contagem de parâmetros não é o fork que importa — a modalidade de entrada e o contexto de serviço de 24.576 tokens é que são.

Então, o enquadramento honesto não é "generalista versus seu ajuste fino". É: um generalista de texto com um contexto longo e dezoito meses de histórico de produção, contra um checkpoint de pesquisa multimodal que emite um documento e nunca foi avaliado de forma independente.

Em que a Microsoft gastou o orçamento de treinamento

O briefing de design é citado no cartão do modelo e explica a bifurcação: os modelos de código "não conseguem ver como layout, hierarquia e cor se combinam na tela", enquanto os geradores de imagens "compõem páginas visualmente atraentes, mas muitas vezes renderizam incorretamente texto, números e relações lógicas". O AesCode é a tentativa de tirar o senso de composição de um e a verificabilidade do outro, e a receita é incomum de uma maneira específica.

Cada prompt de treinamento é 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 um breve resumo em um prompt de conteúdo detalhado. A referência carrega apenas layout e estilo; o prompt de texto permanece autoritativo quanto ao conteúdo. Então, na inferência, o modelo quase não precisa dela: omita a referência do AesCode-8B e sua pontuação Visual cai 1,00 ponto em cem, contra 19,55 para o backbone e 10,04 para o GPT-5.5. Um resultado relacionado é que recompensas baseadas em referência elevaram o Visual apenas com prompt de 25,17 para 69,71, de modo que o prior visual migrou para os pesos em vez de permanecer na entrada.

O resto é uma história de design de recompensa. A supervisão é um "grafo de design" de nós e arestas — texto, gráficos, tabelas, cartões, regiões, slots de imagem, com contenção, alinhamento, ordem e conexão como arestas — escolhido para que toda propriedade no canvas pertença a um elemento nomeado e possa, portanto, ser pontuada individualmente. Sete canais pontuam o resultado: seis verificadores determinísticos para execução, texto, limites, dados de tabelas e gráficos, layout semântico e espaços em branco, além de uma Rubrica de Grafo Visual específica de cada amostra, julgada por um modelo de visão-linguagem. Os candidatos são renderizados em um navegador Playwright em sandbox com requisições externas bloqueadas, e o harness lê de volta o DOM, os estilos computados, as caixas delimitadoras e uma captura de tela, razão pela qual tabelas devem ser tabelas HTML e gráficos devem ser especificações ECharts. O treinamento consistiu em ajuste fino supervisionado com cold start em 3.000 demonstrações, depois GDPO sobre 7.408 prompts por 400 passos em um único nó de oito NVIDIA B200s, com cada canal de recompensa normalizado dentro de seu grupo de rollout para que um sinal denso baseado em regras não afogue o sinal visual esparso. A Microsoft mede essa normalização em 5,12 pontos Visual a mais do que o GRPO escalar simples.

Nada dessa maquinaria existe para tornar o AesCode-8B um assistente geral melhor. Ela existe para tornar a saída verificável, e é por isso que o contexto do modelo é o que é.

Lado a lado, com os números etiquetados

• Base — AesCode-8B: Qwen3-VL-8B-Instruct, um checkpoint de visão-linguagem. Qwen3-8B: o generalista somente texto da mesma geração.

• Parâmetros — AesCode-8B: cerca de 8,8B em bf16 distribuídos em quatro shards. Qwen3-8B: cerca de 8,2B no total, aproximadamente 7B não-embedding.

• Entradas — AesCode-8B: texto mais uma imagem de referência opcional. Qwen3-8B: texto.

• Saída — AesCode-8B: um documento HTML e CSS completo. Qwen3-8B: texto, chamadas de ferramentas, código.

• Contexto — AesCode-8B: 24.576 tokens na configuração reportada. Qwen3-8B: 32K nativo, 131K estendido via YaRN.

• Idiomas — AesCode-8B: a tag do cartão é apenas "en". Qwen3-8B: 119 idiomas e dialetos.

• Evidências — AesCode-8B: a própria rubrica de infográficos de 300 amostras da Microsoft, três gerações por prompt, sem reprodução externa. Qwen3-8B: dezoito meses de benchmarks independentes, trabalho de quantização e implantação em produção.

• Licença — Apache 2.0 em ambos, sem restrições. Um empate, e não o diferencial que as pessoas presumem que seja.

A lacuna de evidências é a comparação real

A Microsoft relata o AesCode-8B com 82,94 Geral em sua rubrica, à frente do GPT-5.5 condicionado por referência, com 81,28, e do Claude Opus 4.8, com 80,39, e 31,1 pontos de Visual à frente de seu próprio backbone condicionado por referência. Três números nessa tabela valem mais do que a manchete. O primeiro é Estilo, em que o AesCode-8B fica em 53,21 e nenhum modelo da comparação ultrapassa 60 — e a definição de Estilo da Microsoft é design que não precisa de mais nenhuma revisão visual antes da entrega, então na única dimensão que pergunta se um humano entregaria a página sem edição, o modelo não é o líder. O segundo é a falha de limite: um transbordamento grave de canvas reaparece em 4,3% das 300 amostras, contra 34,7% do GPT-5.5. O terceiro é que a metade visual da pontuação vem de um juiz de visão-linguagem não nomeado, o que significa que a metade determinística é reproduzível por alguém de fora e a outra metade não é.

Os números do Qwen3-8B vêm de uma fonte completamente diferente, e isso importa mais do que qual conjunto é mais alto. Dezoito meses de avaliação independente, quantizações da comunidade, benchmarks de serving e implementações em produção são um tipo diferente de evidência: não é uma alegação, é um histórico comprovado. Você consegue descobrir como o Qwen3-8B se comporta sob quantização de quatro bits numa placa específica porque alguém publicou isso. Você não consegue fazer isso para o AesCode-8B, porque, a partir desta semana, ninguém fora da Microsoft o executou em qualquer coisa.

E não há métrica compartilhada entre as duas tabelas. O Qwen3-8B não tem pontuação de layout de infográfico; o AesCode-8B não tem nenhum benchmark de raciocínio geral publicado. A comparação não é próxima nem não próxima — ela é indisponível.

O que realmente é preciso para executar cada um

Qwen3-8B é o fácil. Um modelo de texto de 8,2B é quantizado para caber em uma única placa de consumidor, tem dezoito meses de ferramentas por trás dele em todos os frameworks de serving e runtimes locais, e comporta-se de forma previsível. A extensão de contexto para 131K está documentada, em vez de ser folclore, e a cobertura de 119 idiomas é a razão pela qual ele aparece em tantos pipelines multilíngues.

AesCode-8B é um projeto de serving. O comando do próprio card é vllm serve microsoft/AesCode-8B --limit-mm-per-prompt image=2 --max-model-len 24576, com transformers 4.57 ou mais recente para o caminho sem vLLM. Os 17,5 GB de pesos bf16 precisam caber ao lado de um KV cache para 24.576 tokens e até duas imagens, então uma única placa de 24 GB é tecnicamente suficiente e desconfortavelmente apertada, e 40-48 GB ou duas placas de 24 GB é o piso realista. Reserve também um renderizador, porque toda alegação sobre a qualidade deste modelo foi feita renderizando sua saída HTML em um navegador em sandbox — se você quer saber se suas próprias saídas são boas, essa é a estrutura de avaliação que você precisa montar. E observe que o contexto de 24.576 tokens foi exercitado em páginas únicas de infográfico, não nos decks com vários slides para os quais o modelo é direcionado, então a pressão de contexto em um deck real é território não testado.

A disponibilidade é a outra metade do mesmo ponto. O AesCode-8B não é algo que o OrcaRouter roteia, e também não conseguimos encontrá-lo servido em nenhum outro lugar; uma avaliação hoje significa pesos no seu próprio hardware. O seu ancestral é outra história — o Qwen3-VL-8B-Instruct pode ser chamado através do OrcaRouter agora mesmo a $0,18 por milhão de tokens de entrada e $0,70 por milhão de saída em um contexto de 131.072 tokens, o que faz dele a maneira mais barata de ver o que a versão não ajustada desta mesma arquitetura faz com os seus próprios prompts de infográfico. Mais acima na mesma linha, o Qwen3.8-27B é roteável a $0,33 e $2,40. O preço de tabela do provedor é repassado sem nenhuma margem adicionada e o failover entre provedores é automático, então prototipar o prompt contra o backbone hospedado custa uma única chave em vez de uma semana de GPU, e só os prompts que realmente renderizam bem é que merecem o trabalho de reprodução.

Qual deles você quer depende do artefato.

Escolha o AesCode-8B quando o entregável for uma página e precisar ser editável. Saída HTML estruturada que faz diff no Git, tabelas como tabelas reais e gráficos como especificações ECharts, é um artefato genuinamente diferente de um parágrafo de texto, e nenhuma quantidade de capacidade geral substitui isso. Aceite a troca conscientemente: um checkpoint de pesquisa não anunciado com contagem de downloads de dois dígitos, um contexto de 24K, apenas inglês, sem avaliação independente, um teto de Style publicado pelo próprio fornecedor, e uma fatura de serviço medida em dezenas de gigabytes.

Escolha o Qwen3-8B para todo o resto — o que, para a maioria das equipes, é tudo. É o generalista comprovado neste peso, tem um contexto mais longo, fala cento e dezenove idiomas, roda em hardware que você já possui e tem dezoito meses de experiência de produção de outras pessoas por trás das decisões que você está prestes a tomar. Se você não tem necessidade específica de emitir páginas renderizadas, esta comparação tem uma resposta.

O argumento a favor de querer os dois é real, e não se trata de um critério de desempate. Um pipeline que lê documentos e produz apresentações usa dois modelos com dois tipos de saída genuinamente diferentes, e a postura útil é manter o renderizador de páginas em hardware capaz de sustentá-lo e encaminhar o trabalho de leitura e raciocínio para algo hospedado atrás do mesmo endpoint que todo o resto.

O que faria disso uma página mais próxima?

Três coisas, e apenas uma delas é sobre benchmarks. Uma reprodução independente do resultado 82,94 e da queda de referência de 1,00 ponto faria o AesCode-8B passar de alegação de fornecedor para resultado, e permitiria que a questão de tamanho 8B contra 8B fosse respondida com base no mérito. Um provedor que adotasse o checkpoint reduziria a coluna de implantação a nada e transformaria "uma semana de GPU" em "uma chamada de API". E o artigo que o cartão cita como em revisão — "AesCode: Aesthetic Code Generation with Decoupled Cross-Modal Rewards" — responderia à pergunta que o cartão do modelo não consegue: o que a rubrica visual faz quando o grafo de design contra o qual ela pontua está ele próprio errado.

Até que um desses chegue, a leitura defensável é a restrita. O AesCode-8B é o mais interessante desses dois modelos e o menos utilizável. Ele é muito bom nas partes do design visual que uma máquina consegue verificar, mediano na parte que não pode ser automatizada, e pertence à mesma família da geração Qwen3 que o modelo com o qual está sendo comparado, sem ser descendente dele. O Qwen3-8B é o que você pode colocar num pipeline hoje à tarde.