Ember-1 vs MathForm-8B: Dois Modelos Construídos ao Restringir uma Base Emprestada

Ember-1 e MathForm-8B compartilham uma estratégia que nenhum dos laboratórios anuncia como tal: ambos são estreitamentos de um modelo que outra pessoa treinou. Ember-1 é o derivado especializado da Fireworks Research do Kimi K3 da Moonshot AI, publicado em 23 de setembro de 2026, retreinado para atingir a precisão do K3 com cerca de 40% menos tokens. MathForm-8B é o modelo de autoformalização 8B da OpenBMB, lançado discretamente em 14 de agosto de 2026 como um fine-tune Apache-2.0 do Qwen3-8B da Alibaba que transforma matemática informal em declarações de teoremas Lean 4 que um compilador pode verificar. Um estreitamento removeu deliberação desperdiçada e manteve a capacidade geral intacta. O outro removeu quase toda a capacidade geral e comprou verificabilidade em troca. Colocá-los lado a lado é a maneira mais clara de ver quanto custa realmente uma especialização, porque os dois modelos gastaram seus orçamentos de treinamento em lados opostos desse livro-razão.

Dois tipos de estreitamento

A intervenção da Fireworks Research é comportamental. O Ember-1 mantém a arquitetura do Kimi K3 e sua amplitude — matemática, programação, seguimento de instruções, conversação, busca, uso de ferramentas e engenharia de software aparecem todos na mistura de treinamento — e muda apenas quanto tempo o modelo delibera antes de responder. O resultado relatado é que o comprimento do raciocínio caiu de 35–50% sem perda de acurácia em sete benchmarks e dois testes A/B de produção de clientes, com uma carga de trabalho de programação em produção caindo de 49,3K para 29,9K tokens de saída, enquanto sua pontuação se manteve em 0,753 contra 0,751. Todos os números são relatados pelo fornecedor e não reproduzidos.

A intervenção da OpenBMB é contratual. O MathForm-8B pega o Qwen3-8B e direciona todo o orçamento de treinamento para um único formato de saída: uma declaração Lean 4 com um cabeçalho de imports e um teorema nomeado. O pipeline consiste em ajuste fino supervisionado no FormalVerse — um corpus de aproximadamente 367.000 exemplos verificados de Lean 4 que a OpenBMB construiu e lançou junto com o modelo — seguido por aprendizado por reforço que usa a compilação do Lean e o feedback de consistência semântica como sinal de recompensa. O modelo não resolve provas. Ele escreve a declaração que um provador vai terminar, e o próprio enquadramento do artigo descreve a avaliação de seis benchmarks como o objetivo do exercício.

Do que cada um abriu mão

Ember-1 abriu mão de muito pouco no papel, e é nisso que consiste toda a alegação. Sua tabela publicada mostra uma vitória no Terminal Bench 2.1, com 82,0% contra 80,9% do Kimi K3 Max, e no DeepSWE 1.1, com 75,2% contra 66,4%, além de derrotas apertadas no SWE-bench Verified, com 92,2% contra 93,2%, e no SWE-Interact, com 20,0% contra 21,3%. Esses são números de fornecedor em conjuntos escolhidos pelo fornecedor, mas o padrão é consistente: um modelo que não perdeu capacidade, e sim redirecionou onde emprega esforço. A economia de tokens, porém, varia de 51,9% no Terminal Bench até 5,9% no τ-2 Bench Airline, então "cerca de 40%" é uma média em uma faixa muito ampla.

MathForm-8B abriu mão da maior parte daquilo pelo que o Qwen3-8B é conhecido. Ele não sustenta uma conversa geral, não cobre os 119 idiomas e dialetos nos quais o Qwen3-8B foi treinado e não aceita imagens ou áudio. Seu orçamento de geração é dimensionado para saída Lean, não para raciocínio misto estendido. O que ele manteve é uma licença permissiva e uma pegada pequena: quatro fragmentos safetensors em BF16, rodando sob Transformers, vLLM ou SGLang atrás de um endpoint compatível com OpenAI, com um caminho de compilação que espera um Kimina Lean Server no Lean 4.21.0.

Os números medem coisas diferentes, e a diferença é justamente o ponto.

O número de destaque do Ember-1 é uma percentagem de tarefas concluídas corretamente por um agente — Terminal Bench 2.1, 89 amostras, 82,0%. Os números de destaque do MathForm-8B são pontuações médias de Pass@8 em seis benchmarks de autoformalização: 88,06% sob uma verificação de sintaxe e 72,37% sob uma verificação de consistência mais rigorosa. Esses valores não estão no mesmo eixo. Um mede se um agente concluiu um trabalho num terminal; o outro mede se uma declaração de teorema gerada é analisada sintaticamente e se significa a mesma coisa que o problema informal de que se originou.

A diferença de 88,06 contra 72,37 dentro dos resultados do próprio MathForm é o número mais instrutivo. A lacuna entre "isto compila" e "isto compila e diz o que eu quis dizer" é de aproximadamente dezesseis pontos, e é o modo de falha que torna a autoformalização difícil: uma declaração que passa na verificação de tipos enquanto enfraquece silenciosamente a afirmação original é pior do que um erro óbvio, porque nada a jusante sinaliza isso. Nos conjuntos mais difíceis, a verificação de consistência cai para 63% no FATE-H e 37% no FATE-X, enquanto conjuntos fáceis como FormalIMATH ficam em 95,06% e ProverBench em 94,83%. Isso é um especialista sendo honesto sobre onde um especialista é fraco, e é mais útil do que uma única média.

O contraste, dimensão por dimensão

• Modelo base — Ember-1: Kimi K3. MathForm-8B: Qwen3-8B.

• O que o treinamento mudou — Ember-1: por quanto tempo o modelo raciocina, com a capacidade mantida constante. MathForm-8B: o que o modelo produz, com a generalidade em grande parte sacrificada.

• Parâmetros — Ember-1: não divulgados. MathForm-8B: ~8B, denso, BF16.

• Contrato de saída — Ember-1: texto comum e chamadas de ferramentas, com qualidade de nível K3. MathForm-8B: uma declaração Lean 4 com um cabeçalho e um teorema nomeado.

• Licença e pesos — Ember-1: nenhuma publicada; pré-visualização de pesquisa por meio da plataforma do próprio fornecedor. MathForm-8B: Apache 2.0, pesos e conjunto de dados ambos disponíveis para download.

• Manchete reportada — Ember-1: 82,0% no Terminal Bench 2.1 com 51,9% menos tokens. MathForm-8B: 88,06% de média de Pass@8 sob verificação de sintaxe, 72,37% sob verificação de consistência.

• Verificação independente — nenhuma das duas; ambas são relatadas pelo fornecedor e não foram reproduzidas.

A linha da licença decide mais do que os benchmarks

Apesar de toda a diferença numérica, a diferença prática entre esses dois lançamentos é a distribuição. O MathForm-8B é um arquivo. A OpenBMB publicou os pesos, o conjunto de dados FormalVerse e o artigo no mesmo dia, sob a Apache 2.0, sem anúncio e sem API hospedada — o cartão do modelo é o lançamento. Você pode baixá-lo hoje à tarde e executá-lo em uma única GPU, e ninguém pode tirá-lo de você. O Ember-1 é um serviço. Não há pesos, nem preço publicado, e a janela de acesso é descrita como um período serverless de duas semanas cuja continuação depende da demanda. Você pode chamá-lo hoje e não pode ter certeza de que poderá chamá-lo em novembro.

Essa diferença também define para que cada modelo pode ser usado. Um componente de formalização deve ficar dentro de um pipeline que você controla, fixado em uma versão, com o toolchain do Lean na mesma máquina — e é por isso que um checkpoint Apache-2.0 sem restrições é o formato certo para a tarefa do MathForm-8B, e por que o link de código do GitHub que falta no README dele (ainda um placeholder no momento em que escrevo) é uma lacuna mais incômoda do que qualquer número de benchmark. Um modelo de custo de raciocínio deve ficar atrás de uma API, onde a conta de tokens é o que está sendo otimizado, e onde os fornecedores competem em preço e latência. O formato do Ember-1 também se encaixa na tarefa dele; só significa que a dependência é comercial, e não técnica.

Onde um pipeline usaria ambos

Esses dois modelos são complementares em vez de concorrentes, e a composição é fácil de descrever: um especialista em formalização converte um problema em uma declaração verificável, e um modelo de raciocínio trabalha na declaração ou na engenharia ao redor. Nenhum deles está no OrcaRouter — MathForm-8B é apenas auto-hospedado, e Ember-1 está na prévia do próprio fornecedor — mas a composição em si é um padrão para o qual nosso DSL de roteamento existe. Compor vários modelos em uma única chamada é como um pipeline obtém um especialista e um generalista sem manter dois caminhos de integração e dois contratos, e a fusão de modelos vai um passo além ao permitir que um painel de modelos responda em conjunto quando o modo de falha de um único modelo é caro.

Para uma stack de formalização especificamente, o argumento a favor da composição é mais forte do que o habitual. O modo de falha visível é um enunciado que compila e significa algo ligeiramente diferente, e a defesa mais barata contra um erro silencioso é um segundo modelo lendo o mesmo problema — o que é uma decisão de roteamento, não uma decisão de treinamento.

Qual é a melhor compra

Se você precisa de matemática verificável por máquina, o MathForm-8B é o único dos dois que produz algo do tipo, e seu principal custo é a generalidade que você não iria usar para esta tarefa de qualquer forma. Baixe-o, reserve orçamento para o servidor Lean e monte sua própria avaliação — o artigo da OpenBMB não vai lhe dizer como ele se sai na sua distribuição.

Se você precisa de um raciocinador geral com uma fatura de tokens menor, o Ember-1 é destinado a você, e o próximo passo certo é fazer tráfego sombra contra o que você executa hoje, em vez de uma comparação de benchmark. O risco dele é disponibilidade, não capacidade, e esse é um risco que você pode mitigar mantendo a camada de roteamento entre sua aplicação e o modelo.

A conclusão incômoda para quem espera que um destes resolva a questão é que nenhum dos dois foi avaliado de forma independente. O MathForm-8B está disponível publicamente há seis semanas e nenhum terceiro publicou uma reprodução; o Ember-1 está disponível publicamente há um dia. Ambos pedem que você seja o avaliador, o que é a condição normal de escolher um modelo especializado em 2026.

O que eles de fato provam é que a estratégia de estreitamento funciona nos dois sentidos. Um modelo de fronteira pode se tornar mais barato sem se tornar pior, e um modelo base pequeno pode se tornar rigoroso ao direcionar seu treinamento para um compilador. A questão interessante não é qual dessas duas abordagens vence, mas por quanto tempo mais cada uma delas continuará sendo necessária depois que as técnicas nelas contidas se tornarem prática padrão.