SWE-2: como draft model online, NVFP4 e FP8 explicam o ganho de eficiência da Cognition

Fala aí, beleza? O SWE-2 não ficou mais eficiente só porque alguém jogou dado melhor no treino, boa parte da conta foi resolvida na infraestrutura de serving

A Cognition lançou o modelo em 10 de setembro de 2026, apresentando ele como seu modelo de coding mais avançado e como um avanço na fronteira de Pareto entre capacidade e custo de inferência

E é justamente aí que a coisa fica interessante pra quem gosta de olhar por baixo do capô

Neste post eu vou destrinchar os três pilares técnicos que aparecem no anúncio do SWE-2: draft model treinado online, kernels NVFP4 e FP8 com quantization aware training

Bora? 😀

SWE-2: o que foi lançado e onde já dá pra usar

O SWE-2 é o modelo de coding mais avançado da Cognition, anunciado em 10/09/2026

No lançamento, ele chegou disponível no Devin Desktop e no Devin CLI, com rollout em andamento para o Devin Web e o Fusion

Então, se tu abriu o Devin Web e não viu o modelo lá, calma: o rollout estava em andamento na data do anúncio

Formação Recomendada

Formação Claude Code

Domine Claude Code do absoluto zero até o avançado

• 120 aulas
• 4 projetos
• 9h 45min

Conhecer formação

Do lado do treino, a Cognition escalou RL para o regime de múltiplos trilhões de parâmetros, com um algoritmo que treina todos os níveis de reasoning effort em um único run

Isso é ganho de TREINO, e é importante separar bem esse balde do outro

Porque o assunto daqui pra frente é o segundo balde: o que acontece na hora de servir o modelo, quando o token precisa sair rápido e caber na memória da GPU

Draft model online: como o speculative decoding aumenta o throughput

A peça central do serving do SWE-2 são duas coisas somadas: scheduling aprimorado e um draft model treinado online, ambos pra elevar o throughput de decodificação

"Que draft model?"

Boa pergunta, deixa eu explicar o conceito antes do resto

Num LLM, a decodificação é sequencial: o modelo grande cospe um token, olha o resultado, cospe o próximo, e por aí vai

O speculative decoding quebra essa fila colocando um modelo pequeno e barato (o draft) pra CHUTAR vários tokens de uma vez

Depois o modelo grande só verifica o chute em bloco, aceitando o que bate e descartando o resto

Se você conhece cache de aplicação, a analogia serve bem: é mais rápido validar um palpite pronto do que gerar tudo do zero

O número que importa nessa brincadeira é o accept length: quantos tokens do chute sobrevivem à verificação, em média

Accept length maior significa menos rodadas do modelo grande pra entregar a mesma resposta, ou seja, mais throughput sem mexer na qualidade final

E aqui vem o detalhe que eu achei mto massa: a Cognition integrou o treinamento do draft model ao sistema de RL

Assim, o draft continua acompanhando a policy conforme ela muda durante o treino

Faz todo sentido, né? Um draft congelado envelhece: a policy evolui, o palpite do draft deixa de parecer com o que o modelo grande faria, a taxa de aceite despenca e o ganho evapora

Treinar online é a forma de manter os dois falando a mesma língua

SpecForge e DSpark: as ferramentas por trás dos 15% de accept length

Agora a parte da atribuição, que é onde muita gente se enrola

A ferramenta usada no treino do draft foi o SpecForge, um projeto open source do time SGLang, hospedado em github.com/sgl-project/SpecForge

Ele serve pra treinar modelos de speculative decoding e portar esses modelos pro serving do SGLang

Ou seja: não é ferramenta interna da Cognition, é projeto aberto que tu pode ir olhar agora

Com o SpecForge, a Cognition treinou um novo modelo DSpark, que atingiu accept lengths cerca de 15% mais longos

E o que é o DSpark? Aqui eu preciso te dar a ressalva ANTES de descrever qualquer coisa

Existe um paper público que descreve uma abordagem de speculative decoding com esse mesmo nome, mas eu não consigo afirmar que é exatamente a mesma coisa que a Cognition usou e não um homônimo interno

Então lê o que vem abaixo como "o DSpark do paper", não como descrição confirmada do que roda dentro do SWE-2:

• Geração semi-autorregressiva: um backbone paralelo mais um módulo sequencial leve, em vez de gerar o rascunho todo token a token
• Verificação agendada por confiança: a verificação acontece conforme a confiança do rascunho, não em bloco fixo e cego
• Scheduler ciente de hardware: ajusta o comprimento de verificação por request, adaptando o tamanho do palpite à realidade da máquina

Repara como as três ideias atacam o mesmo problema: chutar mais sem desperdiçar compute com chute ruim

Do lado do anúncio, o que está confirmado é o resultado: o modelo treinado com o SpecForge chegou a accept lengths cerca de 15% mais longos

Ficou registrado pra ninguém sair repetindo por aí 🙂

NVFP4 e FP8: menos memória com escalonamento em dois níveis

Resolvido o throughput, sobra o outro gargalo eterno: memória

O NVFP4 é um formato de ponto flutuante de 4 bits da NVIDIA, e a graça dele está em COMO ele faz o escalonamento

São dois níveis: uma escala FP8 no formato E4M3 por micro bloco de 16 valores, mais uma escala FP32 por tensor

"E por que dois níveis?"

Porque 4 bits é pouquíssimo espaço pra representar valores com magnitudes muito diferentes

O bloco pequeno de 16 valores deixa o ajuste fino acontecer localmente, e a escala por tensor cuida do quadro geral

Na prática, o formato corta a pegada de memória do modelo em aproximadamente 3,5x em relação ao FP16 e 1,8x em relação ao FP8, segundo a documentação da NVIDIA sobre o NVFP4

Tome cuidado com esses dois números: eles são do FORMATO, não do SWE-2

O efeito no modelo da Cognition é outra conversa, e é a próxima seção

Quantization aware training e as camadas MLA: o que mudou do SWE-1.7 para o SWE-2

Aqui está a mudança mais concreta entre as duas gerações

No SWE-2, as camadas MLA usam FP8 para K, Q, V e também para o cálculo dos scores

É uma simplificação frente ao SWE-1.7, que trabalhava com precisão mista: componente NoPE em FP8 e componente RoPE em BF16

Menos malabarismo de precisão dentro da mesma camada, tudo no mesmo formato

Junte isso ao quantization aware training, que é treinar o modelo já sabendo que ele vai rodar quantizado, em vez de quantizar depois e torcer pra dar certo

O resultado combinado dos kernels NVFP4/FP8 com QAT: uso geral de memória menor e mismatch treino/inferência menor que o do SWE-1.7, com throughput similar

E isso apesar de um base model com quase 3x os parâmetros

Olha o tamanho dessa frase: modelo bem maior, memória menor, throughput parecido

O SWE-2 também apresenta KL divergence menor entre inferência e treino, com throughput e eficiência de compute similares aos do SWE-1.7

"Tá, mas por que eu, que só quero escrever código, deveria ligar pra KL divergence?"

Porque mismatch treino/inferência é a diferença entre o modelo que foi TREINADO e o modelo que efetivamente RODA quando tu manda o prompt

Quanto maior essa diferença, maior a chance do comportamento aprendido no RL não aparecer direitinho na hora H

Em tarefa longa de código, com agente atravessando dezenas de passos, esse desvio se acumula

Então cortar o mismatch não é firula acadêmica, é o que segura a compostura do modelo no fim de uma sessão comprida

SWE-1.7 x SWE-2: o que mudou na pilha de inferência

Resumindo só o que está confirmado no anúncio:

Repara que a tabela só carrega o que o anúncio confirma, e por isso não tem coluna de preço por token, latência em ms nem hardware ali em cima

Sobre custo, o que eu tenho pra te dar é a comparação relativa que a própria Cognition publicou, e ela aparece na próxima seção

O resto eu não invento, porque botar número por achismo é exatamente o tipo de coisa que eu acho zoado fazer

O que o ganho de infra do SWE-2 muda na prática para quem programa

Agora a tradução do técnico pro seu dia a dia

Decodificação mais rápida e memória menor são a base material que sustenta a comparação de custo divulgada no anúncio: 50,0% no FrontierCode 1.1 Main, dentro de um ponto do Fable 5.1 e com custo 64% menor

É isso que "fronteira de Pareto" quer dizer na prática: entregar resultado equivalente gastando bem menos pra servir

Mas se liga nesta ressalva, porque ela é obrigatória

O FrontierCode foi criado e é operado pela própria Cognition, construído com mantenedores de repositórios open source que definem o critério de mergeability

Traduzindo: é benchmark da casa

O critério de mergeability vindo de mantenedor real é um ponto forte metodológico, sem dúvida, mas quem publica o número também é quem publica o modelo

Leia como dado do fabricante, não como árbitro neutro, beleza?

E, na hora de colocar a mão, lembra da disponibilidade: Devin Desktop e Devin CLI no lançamento, com Devin Web e Fusion em rollout

Por que draft model, NVFP4 e FP8 importam além do SWE-2

O mais legal desta história é que nada disso é exclusividade da Cognition

Speculative decoding com draft acompanhando a policy, quantização de 4 bits com escalonamento em blocos e quantization aware training são padrões de serving que aparecem em qualquer stack séria de LLM hoje

Muda o nome da ferramenta, muda o formato numérico da vez, a ideia continua a mesma: chutar barato e verificar caro, e guardar peso no menor número de bits que ainda representa bem

Saber o que roda por baixo de um produto muda o que tu espera dele, igual quando a gente foi atrás do modelo por trás do Gemini Notebook

E se tu quiser estudar speculative decoding a fundo, ou aplicar num serving próprio, o caminho está aberto: o SpecForge é open source e existe justamente pra treinar esse tipo de modelo

Não vou te dar passo a passo de instalação aqui porque isso muda rápido e eu prefiro te mandar direto pra fonte do que te ensinar comando errado

Vídeo: o cenário dos modelos de fronteira

Pra entender o tabuleiro em que o SWE-2 entrou, vale olhar a corrida entre os modelos de fronteira

Este vídeo do canal apresenta o Kimi K3, o maior modelo da China, e como ele se posiciona frente ao Opus:

Conclusão

Recapitulando a tese do post: parte relevante do salto do SWE-2 é engenharia de serving, não só dado e escala de RL

Scheduling aprimorado mais draft model treinado online dentro do próprio sistema de RL, com o DSpark chegando a accept lengths cerca de 15% mais longos

Kernels NVFP4/FP8 com quantization aware training cortando memória e derrubando o mismatch treino/inferência, mesmo com base model de quase 3x os parâmetros

O resto (o 50,0% no FrontierCode, o custo 64% menor) é consequência disso, lida com o filtro de que o benchmark é da casa

Próximo passo? Se o assunto te pegou, lê o paper de speculative decoding que leva o nome DSpark e dá uma fuçada no repositório do SpecForge, é o melhor jeito de sair do "ouvi falar" pro "entendi como funciona"

E, se tu usa Devin, o SWE-2 já está no Desktop e no CLI pra testar, com Web e Fusion chegando no rollout

até o próximo post! 😀