AesCode-8B vs MathForm-8B: Ambos são fine-tunes de 8B cuja saída uma máquina pode verificar

AesCode-8B e MathForm-8B surgiram com oito semanas de intervalo entre si, ambos de repositórios, e não de comunicados à imprensa, e a coincidência é mais interessante do que parece à primeira vista. Ambos partem de um checkpoint da família Qwen3. Ambos dedicam todo o seu orçamento de treinamento a um formato de saída estreito. E ambos foram construídos em torno de um verificador: MathForm-8B é treinado com base no veredito de um compilador Lean 4, e AesCode-8B é pontuado ao renderizar cada página candidata em um navegador em sandbox e ler de volta o DOM, os estilos computados e uma captura de tela. Nenhum dos dois é um chatbot, e nenhum dos dois está tentando se tornar um. O que os separa é o que uma máquina consegue verificar e o que ela não consegue — e, no caso do mais novo dos dois, o que acontece quando metade da pontuação vem de um juiz que ninguém nomeou.

Os registos de publicação não são simétricos. O MathForm-8B veio da OpenBMB e o seu cartão de modelo data o lançamento em 2026-08-14; é construído sobre o Qwen3-8B e treinado no FormalVerse, um corpus de aproximadamente 367 000 exemplos verificados de Lean 4, com ajuste fino supervisionado seguido de aprendizagem por reforço que usa a compilação Lean e verificações de consistência semântica como sinal de recompensa. O AesCode-8B não tem qualquer data de lançamento em nenhum dos seus ficheiros. A Microsoft criou o repositório no Hugging Face em 2026-09-29, fez o commit dos pesos às 03:35 UTC de 2026-10-07 com a mensagem "Release AesCode-8B" e publicou o código de treino no GitHub em 2026-10-08. Nenhum dos eventos foi acompanhado de um anúncio, a citação do cartão de modelo diz "Under review, 2027" e o repositório mostrava duas transferências à data de redação deste texto. É ajustado a partir do Qwen3-VL-8B-Instruct, o que vale a pena notar precisamente por não ser o mesmo antecessor do MathForm-8B.

A ancestralidade explica a maior parte da divisão.

Qwen3-8B e Qwen3-VL-8B-Instruct compartilham uma geração e um nome de família, mas não uma função. O Qwen3-8B é um generalista apenas de texto: aproximadamente 8,2 bilhões de parâmetros totais, cerca de 7 bilhões deles não-embedding, atenção de consulta agrupada, um contexto nativo de 32K tokens extensível para 131K por meio do YaRN, e treinamento em 119 idiomas e dialetos. O Qwen3-VL-8B-Instruct é o irmão de visão e linguagem, e é o checkpoint do qual o AesCode-8B parte — a configuração publicada do AesCode é uma receita direta do Qwen3-VL com 36 camadas ocultas, tamanho oculto de 4.096, 32 cabeças de atenção com 8 cabeças de chave-valor e um vocabulário de 151.936 tokens.

Essa bifurcação define o lado de entrada de ambos os especialistas antes de qualquer um deles ser treinado. O MathForm-8B recebe texto e emite texto em uma sintaxe formal. O AesCode-8B recebe texto mais uma imagem de referência opcional e emite um documento.

• Base — MathForm-8B: Qwen3-8B, somente texto. AesCode-8B: Qwen3-VL-8B-Instruct, imagem e texto na entrada.

• Parâmetros — MathForm-8B: cerca de 8,2B. AesCode-8B: cerca de 8,8B em bf16 em quatro shards, que a Hugging Face arredonda para 9B.

• Dados de treinamento — MathForm-8B: FormalVerse, aproximadamente 367 mil exemplos verificados de Lean 4. AesCode-8B: 3.000 demonstrações de inicialização a frio, depois aprendizado por reforço GDPO sobre 7.408 prompts durante 400 passos.

• O que verifica a saída — MathForm-8B: um compilador Lean 4, além de uma verificação de consistência semântica em relação ao problema original. AesCode-8B: uma renderização Playwright em sandbox com seis verificadores determinísticos e uma rubrica avaliada por modelo.

• Licença — ambos Apache 2.0, ambos sem restrições de acesso, ambos herdando o backbone da família Qwen3.

• Hospedado em qualquer lugar — nenhum dos dois, pelo que conseguimos apurar.

Dois significados diferentes de "verifiable"

Esta é a distinção que vale a pena tratar com calma, porque "machine-checkable" é usado para as duas coisas e não significa a mesma coisa.

O verificador do MathForm-8B é um assistente de prova. O Lean 4 ou aceita uma afirmação, ou não aceita, e o veredito não é uma questão de opinião, de critério de avaliação ou de gosto de um juiz. O ciclo de treinamento é apontado para esse sinal: a etapa de SFT no FormalVerse ensina o mapeamento de um problema informal para um enunciado formal de teorema com um cabeçalho de imports e um teorema nomeado, e a etapa de RL o aprimora usando compilação mais uma verificação de consistência que pergunta se a formalização ainda diz o que o problema original dizia. A compilação é binária e reproduzível por qualquer pessoa com a mesma versão do Lean. A verificação de consistência é a metade menos rigorosa, e é a metade em que os números relatados ficam fracos — que é exatamente o que os resultados publicados mostram.

O verificador do AesCode-8B é um renderizador. Os candidatos são renderizados 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. Seis canais determinísticos pontuam as coisas analisáveis — execução, texto exato, comportamento de limite, dados de tabela e gráfico, layout semântico, espaços em branco — e um sétimo, o Visual Graph Rubric, pontua geometria e posicionamento por meio de perguntas de sim/não vinculadas a grafos. Tabelas devem ser tabelas HTML reais e gráficos devem ser especificações ECharts, o que é uma restrição que faz trabalho de verdade: ela força a saída a assumir um formato que um verificador consegue analisar. A metade determinística é genuinamente reproduzível. A metade visual é julgada por um modelo de linguagem visual cuja identidade a documentação não nomeia, o que significa que ninguém fora do laboratório pode reproduzi-la.

Então, a comparação honesta não é "um é verificado e o outro não". É que o sinal primário do MathForm-8B é um compilador e seu sinal secundário é uma verificação de consistência, enquanto o sinal primário do AesCode-8B é um conjunto de asserções DOM determinísticas e seu sinal secundário é a opinião de um modelo, empacotada dentro da mesma pontuação geral.

O que cada um relata, e quanto isso vale

O MathForm-8B reporta uma média de Pass@8 de 88,06% sob a verificação de sintaxe e 72,37% sob a verificação de consistência em seis benchmarks. A variação por benchmark é a parte interessante: 95,06% de consistência no FormalIMATH e 94,83% no ProverBench, depois 63% no FATE-H e 37% no FATE-X. Esses dois últimos são os enunciados difíceis e realistas, e a queda dos meados dos noventa para os meados dos trinta é a forma honesta da capacidade. Todos esses números são reportados pelo fornecedor e não reproduzidos, e a mistura de benchmarks é ponderada para os conjuntos mais fáceis.

O AesCode-8B reporta 82,94 em Geral na rubrica de infográfico de 300 amostras da Microsoft — 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 — com três gerações por prompt e sem seleção. A Microsoft também reporta que ele supera o GPT-5.5 condicionado por referência, com 81,28, e o Claude Opus 4.8, com 80,39, na mesma rubrica, que uma falha grave de transbordamento do canvas ocorre de forma recorrente em 4,3% das 300 amostras e que 22,4 pontos em Visual separam o modelo companheiro de 32B de seu próprio backbone. Todos os números são do fornecedor, na tarefa do fornecedor, avaliados em relação a canais que o próprio fornecedor projetou.

Os dois conjuntos de números não podem ser comparados entre si de forma alguma. Não há tarefa compartilhada, nem métrica compartilhada, nem juiz compartilhado. Colocar 88,06% ao lado de 82,94 seria comparar uma taxa de aprovação de formalização em Lean com uma pontuação geral de infográfico, e nenhum dos modelos jamais foi avaliado naquilo que o outro faz.

Uma assimetria merece ser nomeada porque vai contra o modelo mais novo. A métrica principal do MathForm-8B tem um árbitro externo embutido: qualquer pessoa pode instalar o Lean, carregar os mesmos benchmarks e verificar se as declarações compilam. A do AesCode-8B não — os verificadores determinísticos poderiam ser reexecutados por um observador externo determinado, mas a metade visual da pontuação depende de um juiz que o artigo não identificou. Uma taxa de aprovação de compilador não reproduzida é uma alegação mais fraca do que uma tabela de benchmark, e ainda assim mais forte do que uma pontuação de rubrica não reproduzida com um avaliador anônimo dentro dela.

Executá-los é uma questão diferente de qualquer uma das duas pontuações

Ambos são decisões de auto-hospedagem hoje. O MathForm-8B é o mais barato por uma margem ampla: um checkpoint somente de texto de cerca de 8,2B com um orçamento de geração em torno de 16K tokens de saída Lean, que quantiza em uma única placa de médio porte. O AesCode-8B é um modelo de visão e linguagem de 8,8B cujo caminho de serviço carrega imagens além de texto; o comando da própria placa é vllm serve microsoft/AesCode-8B --limit-mm-per-prompt image=2 --max-model-len 24576, e 17,5 GB de pesos bf16 mais um cache KV para 24.576 tokens e duas imagens significam que uma placa de 24 GB fica apertada e que 40-48 GB é o piso realista. Reserve orçamento também para uma pilha de renderização se quiser avaliar suas próprias saídas, porque foi assim que todas as alegações de qualidade sobre o modelo foram feitas.

O maior custo oculto é que ambos os modelos são especialistas que você estaria adotando permanentemente. Uma equipe que precisa de formalização e geração de documentos agora mantém dois caminhos de serviço de 8B, dois conjuntos de formatos de prompt, dois perfis de falha, e nenhum dos modelos consegue absorver o trabalho do outro. É para esse caso que existe uma camada de roteamento: manter os especialistas onde a economia e o tratamento de dados justificam ter uma GPU, e enviar o tráfego geral para algo hospedado atrás do mesmo endpoint. Concretamente, os irmãos generalistas dessas duas bases são acessíveis — Qwen3-VL-8B-Instruct a US$ 0,18 por milhão de tokens de entrada e US$ 0,70 por milhão de saída em um contexto de 131.072 tokens, ao lado da família Qwen 3.8 e de outros checkpoints abertos — tudo por meio do OrcaRouter, uma única API que cobre mais de 200 modelos, com o preço de tabela do provedor repassado com 0% de margem e failover automático entre provedores. Nenhum dos especialistas é roteável aqui nem em qualquer outro lugar que consigamos encontrar; o que é roteável é o generalista ao qual você recorre quando o trabalho específico termina, e isso é a diferença entre testar um checkpoint de pesquisa e transformá-lo em uma dependência crítica.

Escolhendo entre eles, se você realmente tiver que fazer isso.

Escolha o MathForm-8B quando o artefato precisar compilar. Conversão de bancos de problemas, corpora formais para um provador, pré-formatação de enunciados para ferramentas baseadas em Lean — é essa a descrição completa do trabalho, e é o único dos dois que foi treinado para isso. Leve a sério os números do FATE na hora de definir o escopo: nos enunciados realistas mais difíceis, cerca de um terço sai consistente, e você vai ter de construir uma etapa de revisão humana de qualquer maneira.

Escolha o AesCode-8B quando o artefato precisar ser renderizado. Entra um briefing, sai um documento HTML editável, tabelas são tabelas e gráficos são especificações de gráficos, e o conjunto todo gera diff no Git. Aceite o teto de Estilo — 53,21, uma dimensão definida como não necessitar de mais nenhuma revisão visual antes da entrega — como a medida honesta de quanta edição ainda resta, e aceite que o contexto de 24.576 tokens só foi validado em páginas únicas de infográfico, em vez dos decks com vários slides que as pessoas realmente querem.

A escolha que a maioria das equipes realmente enfrentará, porém, não é nenhuma dessas. É se um desses especialistas restritos vale a pena para uma implantação, ou se o generalista por trás dele, chamado por uma API, é próximo o suficiente para o volume que você tem. Isso é uma tarde de testes de prompt em vez de uma compra de GPU, e os próprios números dos dois cartões dão o motivo para testar: a consistência no conjunto difícil do MathForm-8B está em 37%, e a pontuação de Estilo do AesCode-8B está em 53%, então nenhum dos dois é um modelo que você colocaria em um pipeline sem supervisão.

O que ambos os lançamentos revelam sobre como os modelos são lançados hoje

Dois fine-tunes de 8B, com oito semanas de diferença, de dois laboratórios diferentes, lançados sem anúncio, sem página de produto e sem avaliação independente, ambos construídos em torno de um loop de verificação, ambos Apache 2.0, nenhum servido por ninguém. Esse padrão é a história mais do que qualquer um dos dois modelos. O método de pesquisa migrou para a função de recompensa — o sinal de compilador da OpenBMB, os canais cross-modais desacoplados da Microsoft — e os artefatos publicados passaram a ser a receita de treinamento mais os pesos, com o artigo chegando depois, se chegar.

O que isso significa para qualquer pessoa que leia uma comparação como esta é que os números do próprio fornecedor são tudo o que você tem por um tempo, e a pergunta útil não é quão altos eles são, mas quão verificáveis eles são. A taxa de overflow do AesCode-8B e seu teto de Style são alegações verificáveis disfarçadas de falhas. O número de consistência FATE-X do MathForm-8B é a mesma coisa. Esses são os números a ler, e os que você deve voltar e reexecutar por conta própria no momento em que os verificadores forem reproduzíveis de ponta a ponta.