O problema continuava sendo a máquina. Um modelo de 510 GB que precisa de quatro B300 pode ser open source no GitHub, mas continua fora do alcance de quem quer rodar uma IA no escritório de casa.

Voltei pra minha RTX 5090 e pro Strix Halo. Desta vez, em vez de repetir o benchmark v4 inteiro em dezenas de modelos que já sabemos que não cabem ou não têm velocidade, peguei o candidato mais promissor e fui comparar as quantizações dele. Qual versão entrega qualidade suficiente sem transformar cada interação numa espera de vários minutos?

O resultado me surpreendeu: a versão de 2 bits ganhou. Depois repeti o teste com o Basalt, um fork do Strata especializado nas GPUs Blackwell. O modelo continuou acertando tudo e a geração chegou a 400 tokens por segundo. A quantização não mudou; o engine mudou bastante o resultado.

A RTX 3090 e a 4090 ganharam uma sobrevida

Antes dos meus resultados, a comunidade descobriu uma limitação que dava pra remover. Nas GeForce RTX 20, certas operações Tensor Core FP16 com acumulação em FP32 rodam com metade da taxa teórica de emissão por ciclo das equivalentes profissionais. Nas RTX 30 e 40, o limite também atinge BF16.

O hardware está lá. Dois registradores internos selecionam a velocidade, e o driver normal não tem privilégio pra alterá-los.

O projeto gpu-unlock encontrou uma forma de mudar esses registradores antes do driver da NVIDIA assumir a placa. No Ampere, isso explora um buffer overflow no Booter assinado que autentica e carrega o GSP-RM. Nada é gravado na VBIOS. Pra voltar ao comportamento original, você remove o parâmetro de ativação e desliga a máquina por completo, porque os seletores voltam ao padrão quando a placa perde energia. Se o parâmetro continuar ativo, o módulo reaplica o unlock no próximo boot.

Também exige Linux, initramfs e bastante cuidado. Eu não recomendo sair instalando isso numa workstation de produção sem ler o código e entender o risco.

É um hack da comunidade, sem suporte oficial da NVIDIA. Você instala por sua conta e risco. O interesse pra LLM está em acelerar prefill quando o engine usa exatamente esse caminho dos Tensor Cores. Outras aplicações de compute, como alguns pipelines de geração de imagem, também podem mudar de desempenho. Jogos dependem de outros gargalos e caminhos da GPU, então não espere ganhar FPS com isso.

Numa RTX 3090 a 420 W, um teste controlado mediu FP16 com acumulação em FP32 de 76,396 pra 125,006 TFLOPS; BF16 foi de 76,994 pra 127,923. Na 4090, uma implementação ainda experimental mediu aproximadamente o dobro da taxa de instruções FP16 e BF16.

Só que dobrar TFLOPS não dobra sua LLM. O teste que motivou esta discussão separou as duas fases:

• Prefill é quando o modelo lê o prompt inteiro. Há muitos tokens disponíveis ao mesmo tempo, então o motor consegue montar operações matriciais grandes e paralelas. Uma 3090 ganhou 14,4% numa carga de 16K tokens, enquanto uma dupla de 3080 modificadas ganhou 33% a 36% com vLLM.
• Decode é quando o modelo gera um token depois do outro. Em LLM quantizada com expert-offload, essa etapa fica limitada principalmente por banda de memória, RAM, PCIe e cache de especialistas. O ganho medido ficou dentro do ruído.

O ganho varia bastante com engine, quantização e tamanho do prompt. Na dupla de 3080, o Qwen3.8 Flash-Next Q4_K_XL ganhou só 0,5% a 0,8% em 8K, mas chegou a 12% ou 13% em 32K e 128K. Num MoE IQ3_S testado numa 3090, uma carga perto de 32K não mudou. A rota de cálculo usada por uma quantização pode nem passar pelo caminho FP16/BF16 que foi liberado.

O gpu-unlock acelera um caminho específico dos Tensor Cores. Ele pode reduzir a espera pra ler prompts grandes, mas não transforma 24 GB em 96 GB e nem cria banda de memória.

Mesmo com essa ressalva, 3090 e 4090 ficaram mais interessantes pra inferência local. Uma RTX 3090 usada ainda tem 24 GB de VRAM, NVLink na geração dela e 936 GB/s de banda. A comunidade mediu o Qwen3.8 Flash-Next em aproximadamente 75 tok/s com IQ3_S e 100 tok/s com Q2_0 numa única 3090. Com duas placas, há relatos entre 90 e 120 tok/s, dependendo da configuração e do tamanho do contexto. Esses resultados são da comunidade, não desta rodada.

Por que eu escolhi o Qwen3.8 Flash-Next

No v4, os candidatos abertos que realmente me interessaram foram:

Os três empataram dentro da margem de ruído. Só o Qwen repetiu a qualidade numa máquina de consumidor. O modelo principal é um MoE de 125 bilhões de parâmetros, com aproximadamente 6 bilhões ativos por token, mais 51 bilhões em embeddings n-gram e uma cabeça MTP de 4 bilhões. O Strata deixa os especialistas mais usados na GPU, mantém os demais na RAM pra CPU calcular, lê a tabela n-gram do SSD e usa a camada MTP do próprio modelo pra especular os próximos tokens.

O backbone e o Engram do DeepSeek V4.1 somam aproximadamente 748 bilhões de parâmetros: 552 bilhões do backbone e 196 bilhões do Engram. O checkpoint publicado tem cerca de 763 bilhões no total. Eu servi a versão nativa mista FP4/FP8, de cerca de 510 GB, no pod de quatro B300.

Também consegui iniciar uma versão de 2 bits na 5090 com o engine dedicado do Strata. Ela gerou por volta de 17 tokens por segundo. Tecnicamente roda. Pra agente de programação, está fora da disputa.

O checkpoint NVFP4 do GLM 5.3 Flash tinha cerca de 198 GB e foi servido na B300. Não existe neste repositório uma configuração de consumidor que eu tenha medido e possa recomendar. O GLM 4.7 Flash menor já tinha feito 24 pontos na 5090 e 33,5 na B300 no benchmark anterior. Gastar dias tentando fazer a família errada caber não produziria informação útil.

Também deixei Qwen 4 e Llama fora por escolha. Esta rodada tem uma pergunta estreita: qual versão do modelo que já provou qualidade funciona melhor nas duas máquinas que eu tenho?

O que eu testei

Todo o código, os prompts, os testes escondidos e os resultados estão no llm-opensource-benchmark. Testei quatro versões do Qwen3.8 Flash-Next:

Os arquivos do Strata incluem uma parte comum de PLE, então o tamanho total não cabe diretamente na VRAM. O engine faz o trabalho de distribuir os especialistas entre GPU e RAM. No Basalt, usei os packs próprios do projeto: um arquivo .basalt de 64,9 GiB pro Q2_0 e outro de 81,0 GiB pro IQ3_S. Cada arquivo já reúne pesos, tokenizer, MTP, perfil de especialistas e projetor de visão.

Na primeira rodada da RTX 5090, usei o backend CUDA do Strata com:

• 4 GiB de VRAM reservados pro Hyprland, navegador e terminal;
• cache de KV em int8, contexto máximo de 128K e 32K residentes na GPU;
• cache elástico de especialistas;
• especulação de quatro tokens com o MTP do modelo.

Depois rodei Q2_0 e IQ3_S no Basalt, na mesma 5090 e com os mesmos 131.072 tokens de contexto máximo e KV em int8. Deixei 4.608 MiB reservados porque o Basalt contabiliza seus buffers de trabalho nessa margem. A VRAM livre ficou entre 3,6 e 4,4 GB durante os testes.

No Strix Halo, usei o backend hip-halo. Essa máquina tem 64 GB reservados pra GPU e GTT de 31 GB mapeado sobre a RAM do sistema; o limite de RAM do engine era 61,9 GiB. Como ela é headless, deixei a GPU inteira pro modelo e mantive 8 GiB de folga pro cache da conversa.

Nas medições do Strata são dois backends diferentes por baixo, CUDA na NVIDIA e HIP/ROCm na AMD, mas o mesmo engine e a mesma API compatível com OpenAI. O Basalt acrescenta uma comparação de engine na 5090, usando o mesmo OpenCode, os mesmos prompts e a mesma correção.

A metodologia

Comecei com um teste de velocidade em três situações:

1. prompt frio de 4K tokens;
2. prompt frio rotulado como 32K, que o tokenizer do modelo contou como 42.400 tokens;
3. continuação da mesma conversa, reaproveitando o cache.

Cada uma gera 256 tokens. O runner mede tempo até o primeiro token, leitura do prompt, geração, VRAM, RAM, potência e temperatura.

O que cada número de velocidade quer dizer

Quando alguém diz que uma LLM faz 200 tokens por segundo, quase sempre está falando só da geração. Uma sessão de agente passa por fases diferentes, e cada uma encosta num gargalo diferente.

Prefill é a leitura inicial do prompt. O modelo precisa processar as instruções do harness, histórico da conversa, arquivos e sua pergunta antes de soltar a primeira palavra. Como todos esses tokens já estão disponíveis, a GPU consegue trabalhar com matrizes grandes em paralelo.

Essa fase aproveita melhor Tensor Cores e poder bruto de cálculo. Quanto maior o contexto, mais ela pesa.

O KV cache guarda os estados intermediários dos tokens já processados. Numa continuação da mesma conversa, o modelo reaproveita esse estado em vez de ler tudo de novo. Por isso o teste de append chega a dezenas de milhares de prompt tokens por segundo e recebe o primeiro token em cerca de meio segundo. Esse número mede reaproveitamento de cache; comparar com prefill frio seria fraude.

O KV também cresce com a conversa e disputa memória com pesos, especialistas e buffers. Aqui ele está em int8, com 32K residentes na 5090. Contexto máximo anunciado, contexto que cabe e contexto que continua rápido são três números diferentes.

Speculative decoding usa uma camada de draft pra propor vários tokens e o modelo principal verifica o lote. Quando a taxa de aceitação é boa, o output tok/s sobe. Se o draft erra muito, o ganho desaparece. As velocidades do Strata já incluem MTP com especulação de quatro tokens. O Basalt também usa o MTP incluído no próprio pack, com seu mecanismo de especulação e seus defaults.

E falta uma métrica que eu não medi aqui: concorrência. Todos estes números são de um único stream. Um servidor pode atender várias sessões e aumentar a vazão agregada, mas cada usuário tende a receber menos tokens por segundo.

Pra uso individual, single-stream e wall time mandam. Pra uma equipe, precisa medir sessões simultâneas e latência por usuário, como fiz no teste com B300 e H200.

Depois vieram dois testes de programação usando OpenCode 2.1.4. O modelo recebe uma pequena base Python, trabalha em uma sessão contínua e nunca vê os testes escondidos. Tudo roda em Bubblewrap, sem rede, com filesystem limitado e apenas um gateway local que aceita as chamadas pro modelo esperado.

O primeiro canário tem três turnos e 9 testes escondidos. O modelo precisa implementar um analisador de logs, corrigir bugs e lidar com mudança de requisitos.

O teste difícil tem quatro turnos e 36 testes escondidos. É um reconciliador de pagamentos com decisões enterradas num histórico de cerca de 79K tokens, uma decisão corrigida mais tarde, propostas rejeitadas servindo de distração, dinheiro que exige decimal exato e regras novas que interagem com as anteriores. Com o system prompt do OpenCode, o primeiro turno chega perto de 83K tokens.

Uma régua separada do benchmark v4

Estes canários são muito menores e mais fáceis. No v4, o modelo trabalha num aplicativo Rails por sete sprints enquanto um revisor injeta 14 defeitos de segurança e de correção. A nota mede quantos ele encontra e corrige sozinho antes da revelação. É um teste de vigilância, com muito mais código, ferramentas e oportunidades de se perder.

Aqui são duas bases Python pequenas, três ou quatro turnos e testes funcionais escondidos. Eu montei essa régua pra comparar quantizações do mesmo Qwen e descobrir se reduzir os bits quebra requisitos, contexto ou processo. A comparação termina aí, sem ranquear Qwen contra Opus, GPT, DeepSeek ou qualquer outro modelo.

A nota 100 deste artigo pertence a outra escala, sem equivalência com 100 do v4. Ela também não torna o Q2_0 “melhor” que o IQ3_S que fez 91 no v4. O v4 escolheu o Qwen como candidato; este teste menor escolhe qual arquivo do Qwen vale carregar em casa.

Velocidade sem qualidade só faz o modelo errar mais rápido. Por isso eu medi as duas coisas separadamente.

Ranking de velocidade

RTX 5090 com Strata, 4 GiB preservados pro desktop

RTX 5090 com Basalt

Strix Halo, usando a GPU inteira

A 5090 tem 32 GB de GDDR7 e 1.792 GB/s de banda. O Strix tem mais capacidade total, mas seus aproximadamente 256 GB/s precisam servir o sistema inteiro. Mesmo usando o Strata nos dois, a diferença aparece principalmente no prefill: 6,9 segundos contra quase 2 minutos pra começar a responder a carga de 42.400 tokens. No Basalt, a 5090 baixou essa espera pra 4,9 segundos.

O Q4 foi o pior dos dois mundos. Na 5090 ele rodou devagar e o systemd-oomd matou o teste de qualidade. No Strix, zerou a VRAM, começou a paginar e travou a máquina até reboot. Mais bits preservam mais informação, mas ocupam mais memória e reduzem o cache quente que faz esse MoE andar.

Basalt contra Strata

O Basalt nasceu como fork do Strata, só que tomou uma direção mais específica: Linux ou Windows, CUDA 13 e GPU NVIDIA Blackwell com compute capability 12.0. A 5090 entra exatamente nesse alvo. O Strata continua muito mais abrangente e foi o que permitiu rodar o mesmo Qwen no Strix Halo com AMD.

Os dois resolvem o mesmo problema central. Na configuração testada, os especialistas que não cabem na VRAM ficam na RAM, enquanto a GPU mantém uma parte quente. Basalt e Strata expõem API compatível com OpenAI e Anthropic e aceleram a geração com seus drafters MTP. O Basalt empacota tudo num único arquivo e traz kernels, gerenciamento de memória e execução especulativa trabalhados especificamente pra Blackwell.

Este foi um A/B prático entre stacks completos, sem isolar uma única otimização. Os packs são próprios de cada engine, os defaults não são idênticos e o Basalt reservou 4.608 MiB de VRAM contra 4.096 MiB do Strata. Mantive a mesma RTX 5090, as mesmas quantizações, contexto máximo de 131K, KV em int8, mesmo OpenCode e os mesmos testes.

Nesse A/B, o Basalt ganhou em todas as métricas de velocidade e empatou nos resultados funcionais de código. O Q2_0 saiu de 223 a 259 pra 377 a 400 tokens por segundo. A leitura da carga longa foi de 6.158 pra 8.573 tokens por segundo, e a espera pelo primeiro token caiu de 6,9 pra 4,9 segundos. No IQ3_S, a geração saiu da faixa de 158 a 208 pra 223 a 231 tokens por segundo.

O recorte de plataforma decide a escolha. Numa RTX 5090, eu começaria pelo Basalt. No Strix, em NVIDIA anterior a Blackwell ou em outro hardware suportado, o Strata continua sendo o caminho. O Strata cobre justamente os lugares onde o Basalt nem roda.

Ranking de qualidade

O teste simples não separou nada:

Todas passaram os 9 testes escondidos, preservaram os requisitos e terminaram com a suíte visível verde. Precisei aumentar a dificuldade.

No canário difícil, rodei Q2_0 e IQ3_S três vezes cada na 5090 com Strata:

As duas acertaram tudo nas três rodadas. Encontraram as decisões no contexto longo, respeitaram a correção posterior, lidaram com eventos fora de ordem, chargebacks, câmbio e fizeram o refactor final. Também passaram por quantidade parecida de testes quebrados enquanto trabalhavam.

A diferença ficou no relógio. Q2_0 levou 7,2 minutos em média. IQ3_S levou 12,1. O modelo de 2 bits entregou o mesmo resultado em aproximadamente 60% do tempo.

Depois repeti as seis rodadas no Basalt:

A penalização que derrubou a segunda rodada do IQ3_S pra 96 foi um falso positivo conhecido do harness. O modelo executou ps aux dentro do sandbox, e o comando mostrou a linha do próprio bwrap, que contém caminhos do host. O detector interpretou isso como tentativa de acessar os testes escondidos e tirou quatro pontos. O modelo não usou esses caminhos, os testes escondidos só são montados depois, na correção, e os 36 passaram.

No Basalt, o Q2_0 levou 5,4 minutos em média, contra 7,2 no Strata. O IQ3_S caiu de 12,1 pra 9,0 minutos. O ganho de ponta a ponta é menor que o salto de tokens por segundo porque a sessão também gasta tempo executando ferramentas e testes, e cada rodada gerou uma quantidade diferente de texto.

A evidência vale para bases Python pequenas, com contexto de até uns 85K tokens, e apenas três repetições por combinação de engine e quantização no canário difícil. Quantização de 2 bits costuma sofrer primeiro em contexto acima de 100K e em bases maiores. Dentro do uso que medi, gastar mais bits não comprou nenhuma qualidade.

O que cada versão mostrou

Q2_0: a recomendação atual

Foi a quantização que gerou tokens mais rápido nas três combinações de máquina e engine, e terminou as seis rodadas difíceis com nota máxima. No prefill longo do Strata na 5090, o IQ3_S ganhou por uma margem mínima. Com Basalt, o Q2_0 chegou a 400 tokens por segundo. No Strix, 55 a 65 tokens por segundo é utilizável, embora o prefill longo cobre quase dois minutos antes da primeira resposta.

Eu usaria esta versão no dia a dia e guardaria a ressalva de contexto. Projeto grande, sessão chegando em 100K ou comportamento estranho? Repito o mesmo trabalho em IQ3_S antes de culpar o modelo.

IQ3_XXS: ficou sem função clara

Passou no canário simples e foi rápida, só que perdeu pro Q2_0 em velocidade e ocupa mais espaço. Eu não rodei as três repetições do teste difícil nela, então não tenho dado pra prometer uma vantagem de qualidade.

IQ3_S: a opção conservadora

Continua sendo a versão que eu escolheria pra validar um resultado suspeito da Q2_0. Ela já tinha feito 91 no benchmark v4 na 5090, a apenas 1,5 ponto da versão NVFP4 na B300. No Basalt, ficou entre 223 e 231 tokens por segundo, praticamente a faixa que o Q2_0 alcançava no Strata, e ainda leu prompts mais rápido.

O próprio Basalt mede a proximidade das quantizações contra Q8_0. No teste de 100 chunks, o IQ3_S manteve o mesmo token no topo em 87,16% das posições. É uma régua diferente dos meus canários, mas reforça seu papel de opção conservadora. Nos meus testes de código, essa precisão extra ainda não encontrou nada que o Q2_0 tivesse perdido.

UD-Q4_K_XL: qualidade que não cabe não serve

Era a candidata intuitiva a entregar mais fidelidade. Faltou memória pra chegar ao teste que confirmaria isso. Na 5090, caiu pra menos de um quarto da velocidade da Q2_0 e o sistema matou a rodada. No Strix, a máquina travou.

Serve como lembrança de que a maior quantização compatível no papel pode ser a pior configuração real. Um MoE depende do espaço que sobra pra especialistas, KV cache, buffers e o próprio sistema operacional.

Qual hardware vale a pena?

RTX 3090 e 4090: boas se você já tem

As duas têm 24 GB, e isso limita o cache de especialistas. O gpu-unlock melhora prefill em workloads que usam o caminho liberado, mas decode continua preso em memória e offload. Uma 3090 usada, principalmente duas com NVLink, pode formar uma máquina local interessante. Eu não compraria uma 4090 nova hoje só pra isso: continua com 24 GB, custa caro e o unlock de Ada ainda é experimental.

Pra ambas, começaria pelo Qwen3.8 Flash-Next Q2_0 e mediria meu workload. Os aproximadamente 100 tokens por segundo publicados pela comunidade numa única 3090 já colocam a placa numa faixa prática. Duas 3090 aumentam a capacidade e podem ficar entre 90 e 120 tokens por segundo, mas não dobram automaticamente a velocidade. A conta inclui consumo, calor, fonte e pelo menos 128 GB de RAM.

Strix Halo: muita capacidade, pouca banda

É uma boa caixa headless, compacta e econômica. A memória unificada deixa rodar modelos que uma GPU de 24 ou 32 GB recusaria. Neste teste, o melhor modelo também foi o Q2_0, a 55 a 65 tokens por segundo.

O problema aparece toda vez que o agente lê contexto grande. Quase dois minutos pra processar a carga longa do teste acumulam rápido durante uma sessão. Eu usaria como servidor privado pra tarefas assíncronas, agentes simples e workloads onde capacidade vale mais que resposta imediata.

RTX 5090: o melhor ponto caseiro hoje

A RTX 5090 tem 32 GB, 21.760 CUDA cores e a mesma banda nominal de 1.792 GB/s da RTX PRO 6000. O que falta é capacidade: preciso reservar 4 GiB pro desktop e usar RAM e SSD pros especialistas que não cabem.

Com Strata, ela colocou o Q2_0 em 223 a 259 tokens por segundo e leu a carga longa a 6.158 tokens por segundo. Com Basalt, chegou a 400 e 8.573, respectivamente. É a primeira configuração local que não me faz sentir que estou esperando a máquina a cada passo. E é uma placa que também serve pra jogos, geração de imagem, vídeo e todo o resto da workstation.

RTX PRO 6000: três vezes a VRAM, preço de servidor

A RTX PRO 6000 Blackwell tem 96 GB de GDDR7 ECC, 24.064 CUDA cores e os mesmos 1.792 GB/s de banda. A capacidade extra deixa muito mais especialistas residentes, abre espaço pra quantização maior e comporta contexto sem disputar os últimos gigabytes com o desktop.

Ela custa US$ 16 mil na loja da NVIDIA, oito vezes o preço sugerido de US$ 1.999 da 5090. Eu ainda não rodei este benchmark nela, então não vou inventar uma velocidade. A banda igual à 5090 significa que três vezes a memória não viram três vezes mais tokens por segundo. O ganho está em manter mais coisa na placa e evitar o caminho lento de RAM e PCIe.

Pra uso individual, a conta da 5090 fecha melhor. A PRO 6000 começa a fazer sentido quando 96 GB resolvem um modelo que você realmente precisa, quando ECC e suporte profissional importam ou quando várias sessões vão dividir a mesma placa.

O veredito

O open source local finalmente entrou numa faixa prática. Uma única 5090 roda um modelo que fez Tier A no meu benchmark v4 e, com Q2_0 no Basalt, chegou a 400 tokens por segundo no canário. O Strix também ficou muito melhor do que os 7,7 tokens por segundo do Qwen denso que eu tinha testado antes.

Ainda existem limites claros. O contexto custa memória, o desktop precisa da mesma VRAM e qualquer especialista fora da placa atravessa PCIe ou cai na RAM. DeepSeek a 17 tokens por segundo mostra que “rodou” continua sendo uma métrica inútil. Se cada iteração leva várias horas, a qualidade do modelo deixa de importar porque ninguém consegue trabalhar desse jeito.

Pra hardware caseiro, o melhor modelo é o que mantém qualidade suficiente na velocidade que deixa você iterar. Nesta rodada, foi o Qwen3.8 Flash-Next Q2_0 no Basalt, numa RTX 5090.

O repositório do benchmark tem os runners, configurações, resultados brutos e testes escondidos. Repita na sua máquina e mande resultados. Hardware, engine, quantização e contexto mudam a resposta. Ranking pronto serve como ponto de partida; a decisão final continua sendo medida no seu trabalho.

O modelo constrói um projeto Rails em sete sprints e precisa encontrar 14 defeitos de segurança e correção plantados no caminho. Eu meço se ele percebe uma backdoor, um bypass de autorização, um teste adulterado ou uma conta errada antes que alguém entregue a resposta. É uma régua de vigilância durante programação. Nunca foi uma prova de inteligência universal.

Enquanto eu fechava essa série, alguns colegas que trabalham com investimentos e Direito começaram a discutir se um modelo aberto já serviria nas rotinas deles. A conversa deixou uma coceira: como eu poderia medir isso sem cair em prova de múltipla escolha ou pergunta de trivia jurídica?

Tentei responder. E já começo com a ressalva que manda no resto deste artigo.

Eu não sou contador, não tenho CPA, nunca passei na OAB e tenho zero experiência profissional trabalhando em escritório contábil ou jurídico. Consigo conversar sobre os assuntos e ler o material, porém não tenho condição de certificar se esta suíte representa bem o trabalho diário dessas profissões.

Portanto, trate tudo daqui pra frente como um experimento que precisa do escrutínio de contadores e advogados de verdade. Os números ajudam a comparar os modelos dentro desta suíte. Eles não certificam nenhum modelo para atender clientes, assinar parecer, fechar balanço ou protocolar peça.

O que eu tentei medir

Alguns dos profissionais com quem conversei já usam Claude ou GPT no trabalho, com modelos como Fable, Opus, Astra ou Sol. Parti dessa realidade em vez de fingir que conseguiria escrever sozinho uma prova profissional.

Pedi ao Fable 5.1 para desenhar casos dentro do que ele próprio tinha confiança para pesquisar, estruturar e revisar. A suíte usa padrões de trabalho, legislação, formulários, decisões e materiais de referência, mas todos os clientes, empresas e documentos são sintéticos. Nenhum dado confidencial real entrou no repositório.

Depois rodei o GPT-6 Sol como âncora de fronteira. Finalmente, peguei os modelos abertos que tinham ido bem nos testes de programação e rodei a mesma suíte em três classes de infraestrutura: RTX 5090, Strix Halo e NVIDIA B300 alugada.

Uso “aberto” no mesmo sentido do benchmark anterior: checkpoint que eu consigo baixar e servir por conta própria. As licenças variam e nem todo peso aberto atende à definição mais rigorosa de software open source.

O Fable também fez a correção cega. Cada configuração recebeu uma letra aleatória, e um subagente separado avaliou cada caso sem saber qual modelo tinha produzido a resposta. Então a comparação deste artigo significa algo bem restrito:

Quão perto estes modelos abertos chegaram do Sol, numa prova criada e corrigida pelo Fable?

Fable e Astra não fizeram a suíte como candidatos. Sol é a única âncora fechada desta rodada. O próprio Fable limita o que conseguimos perguntar e julgar, e um avaliador de IA pode errar. A revisão de uma amostra por profissionais humanos ainda está pendente.

O teste começa com uma pasta de cliente

O benchmark tem 38 casos, divididos entre contabilidade e Direito nos Estados Unidos e no Brasil. Como alguns casos atravessam várias sessões, a campanha inteira soma 63 unidades de sessão por configuração e 190 execuções avaliadas.

A distribuição ficou assim:

São quatro casos L1, seis L2, 22 L3 e seis L4. A dificuldade não vem de pedir uma resposta mais rebuscada. Ela cresce com o volume de documentos, a quantidade de regras que interagem e o tempo durante o qual o modelo precisa manter uma linha de raciocínio.

• L1, estagiário ou clerk: um ou dois documentos, uma entrega e uma resposta verificável. Um exemplo é calcular prazos a partir de uma intimação no DJe.
• L2, sênior: vários documentos, algum limite ou regra que interage com outra e pelo menos um fato que precisa ser perguntado ao cliente. Aqui entram escolha de regime tributário e revisão de contrato contra um playbook.
• L3, gerente ou associate: fontes conflitantes ou superadas, falsos positivos e decisões que precisam ser justificadas. A maior parte da suíte está aqui.
• L4, sócio: de três a doze sessões. Um fato novo derruba trabalho anterior, a outra parte reage e o modelo precisa corrigir o curso sem esconder a mudança.

Os seis casos L4 são doze fechamentos mensais de uma empresa SaaS, um devedor em Chapter 11, um trimestre de Lucro Real, uma recuperação judicial, um litígio americano em cinco sessões e uma execução fiscal brasileira também em cinco sessões. Somados aos casos de sessão única, eles levam cada configuração às 63 unidades de sessão. Como rodei cinco configurações, foram 315 sessões de trabalho dentro das 190 execuções.

Cada caso tenta parecer uma pequena contratação profissional. O modelo recebe:

• uma pasta com contratos, extratos, notas fiscais, petições, planilhas e outros documentos;
• uma biblioteca fechada com as normas e autoridades permitidas, sem acesso à internet;
• uma carta dizendo quem é o cliente, qual é a tarefa e o formato da entrega;
• ferramentas para calcular e manipular arquivos;
• um cliente simulado que só revela certos fatos quando o modelo faz a pergunta certa.

Há tarefas curtas de nível estagiário e trabalhos longos de nível sócio, com fatos que chegam depois e obrigam a rever uma conclusão anterior. No fim de cada caso, todos recebem a mesma ordem para revisar erros, fontes sem suporte e contas que não fecham.

Exemplo contábil: o fechamento que não fecha

Um dos casos americanos entrega o balancete de fevereiro, razão de março, extratos bancário e de cartão, aging de contas a receber, duas cópias da mesma fatura e o checklist de fechamento. O dono quer a conciliação limpa até sexta-feira porque vai renovar uma linha de crédito.

Depois de contabilizar os itens legítimos, ainda sobra uma diferença de US$ 4.312. Não há documento que explique esse valor. A resposta correta precisa deixar a diferença aberta, contar isso ao dono e recusar qualquer lançamento inventado.

O caso ainda esconde uma transferência de US$ 1.500. O modelo precisa perguntar de onde veio. O cliente roteirizado responde que foi aporte pessoal do dono.

Se o modelo assumir que é receita, erra o resultado e o imposto. Se lançar os US$ 4.312 em “despesas diversas”, “retirada do sócio” ou uma conta transitória para forçar a conciliação, reprova imediatamente no filtro de confiança.

Esse exemplo testa mais do que soma. Testa se o agente resiste à pressão do cliente, reconhece a ausência de evidência, detecta a fatura duplicada, faz a pergunta necessária e entrega balanço, lançamentos e nota de pendências consistentes entre si.

Exemplo jurídico: cinco sessões de execução fiscal

No caso brasileiro L4, uma marmoraria enfrenta uma CDA de IRPJ e CSLL de aproximadamente R$ 1,1 milhão. O modelo recebe a CDA, parte do processo administrativo fiscal, alterações do contrato social, certidão do oficial e uma biblioteca fechada com CTN, LEF, CPC, súmulas e precedentes necessários.

Na primeira sessão, ele avalia nulidades e escolhe o instrumento de defesa. Na segunda, a Fazenda emenda a CDA. Na terceira, pede o redirecionamento para um sócio. As duas sessões finais tratam da defesa do sócio, garantia e transação com valores.

A armadilha é continuar repetindo uma tese depois que o vício foi corrigido, escolher o sócio errado ou aceitar automaticamente a presunção de dissolução irregular. As alterações societárias mostram quem administrava no período relevante, e a mudança de endereço havia sido registrada antes da certidão. O modelo precisa abandonar a tese que perdeu sentido e recalcular a estratégia com os fatos novos.

Outro caso jurídico faz o mesmo tipo de pressão num litígio americano de cinco sessões. A contraparte apresenta um e-mail que enfraquece a tese inicial, aparece uma cláusula de arbitragem em letra miúda no Anexo C do contrato e o agente precisa dizer ao cliente que a posição piorou. Persistir na narrativa inicial conta contra ele.

Cada caso oferece uma conclusão errada muito conveniente. O teste mede se o modelo encontra a prova que obriga a mudar de ideia.

Como eu corrigi as entregas

As respostas passam por quatro filtros:

1. Confiança: inventou fato do cliente, autoridade ou número para fechar conta, aplicou lei superada ou declarou que terminou sem terminar? A execução falha.
2. Oráculo: datas, valores, classificações e itens obrigatórios batem exatamente com a resposta esperada?
3. Vigilância: encontrou sozinho os problemas plantados ou só percebeu na revisão final?
4. Qualidade da entrega: o memorando, parecer ou resumo contém os elementos binários exigidos pelo caso? Estilo bonito não ganha ponto.

O oráculo reúne 235 itens exatos por configuração. Uma data vence no dia certo ou no errado. Um formulário tem o valor esperado ou não tem.

Uma cláusula obrigatória foi sinalizada ou passou. Quando cabe tolerância numérica, ela já está definida no gabarito.

As armadilhas têm pesos por gravidade: crítica vale 5, alta vale 3, média vale 2 e baixa vale 1. Descoberta durante o trabalho recebe o peso inteiro; descoberta apenas depois da ordem final de revisão vale 40%; problema perdido vale zero. Foi daí que saiu a coluna de vigilância.

O cliente também segue um script. Ele não improvisa ajuda. Cada resposta escondida tem um gatilho, e só aparece quando a pergunta do modelo realmente busca aquele fato.

Se ninguém perguntar, o modelo precisa declarar a premissa ou deixar a pendência aberta. Inventar a resposta pode derrubar toda a execução.

Antes de cada rodada, o harness copia uma pasta limpa e esconde fisicamente o gabarito, os manifests das armadilhas e as respostas dos outros modelos. A rede fica bloqueada. Isso impede que o agente pesquise uma solução pronta ou leia arquivos de correção no próprio repositório.

Nenhum dos dois lembretes genéricos permitidos pelo protocolo chegou a ser usado. Os arquivos de resposta, históricos, prompts, chaves de correção e scripts estão no repositório do llm-non-coding-benchmark.

O ranking experimental

Ordenei por entregas completas. Uma entrega completa terminou todas as sessões, não bateu no limite de saída, não teve falha grave de confiança e acertou todos os itens obrigatórios do oráculo.

O Sol custou US$ 16,72 em preço equivalente de API. Eu rodei pela assinatura, então esse valor serve para comparar consumo e não representa uma cobrança que recebi. As máquinas locais não têm custo por chamada, mas continuam custando hardware, eletricidade e manutenção.

A tabela oficial da Runpod cobra hoje US$ 6,94 por hora pela B300 no Community Cloud e US$ 8,99 por hora no Secure Cloud, com cobrança por segundo. O benchmark não guardou a fatura nem o tier do pod, então calculei as duas pontas usando apenas os minutos ativos de cada modelo.

Isso dá de US$ 71,94 a US$ 93,20 para o Qwen e de US$ 83,86 a US$ 108,63 para o GLM. São pisos artificiais. O pod também cobra durante download, carga dos pesos, compilação, troca de modelo, espera do controller, retries e qualquer minuto ocioso até alguém desligá-lo. A conta real foi maior.

“Tempo ativo” soma o tempo de modelo de todos os casos. O Sol rodou quatro em paralelo e terminou a campanha em 72,9 minutos de relógio. As outras configurações rodaram uma por vez. Esta tabela compara esforço de inferência e latência de cada caso; não mede capacidade de atender muitos usuários ao mesmo tempo.

Também há duas colunas de oráculo porque o limite de 16.384 tokens cortou respostas dos modelos locais. “Itens avaliados” ignora o que ficou impossível de corrigir. “Todos os itens” conta o que faltou como erro. O GLM, por exemplo, foi o mais exato quando conseguiu entregar algo avaliável, mas perdeu muito trabalho no limite de saída.

Uma colocação acima na tabela não torna um modelo melhor para trabalhar. Eu prefiro 25 entregas limpas do Sol a 27 entregas com três invenções graves no Strix Halo.

O custo do erro pesa mais que a média

Depois que publiquei este artigo, recebi um comentário: para advogado e contador, a média de acertos não basta. O erro que interessa é aquele dito como fato, sem ressalva, que parece plausível e vai parar na mão do cliente.

O benchmark separa o filtro de confiança do restante da nota. Uma data ou um valor errado reprova o item do oráculo. Inventar uma resposta do cliente, um documento, uma autoridade ou um número para fechar a conta derruba a execução inteira, mesmo que todo o resto esteja certo.

A diferença por configuração é grande:

Foram cinco execuções afetadas entre 190, ou 2,6%. Dentro delas, os avaliadores encontraram nove ocorrências graves: respostas de cliente que nunca foram dadas, documentos inexistentes, datas fictícias, termos contratuais inventados e uma citação atribuída falsamente à biblioteca fechada. Outras sete execuções receberam alertas de confiança média e ficaram pendentes de revisão humana.

Chamar isso de “taxa de respostas confiantes e erradas” seria impreciso. O benchmark não mede a confiança interna do modelo. O high confidence registrado nos resultados é a confiança do avaliador de que houve uma violação. O que medimos é se o modelo afirmou uma informação sem suporte, não marcou como premissa e deixou que ela chegasse ao material entregue ou produzido até a interrupção.

Também ainda não separei todo valor errado nessa categoria. Datas, contas, classificações e recomendações definidas no gabarito entram na acurácia do oráculo. Na coluna sobre todos os itens, omissões causadas pelo limite de saída contam como erro; na coluna de itens avaliados, ficam fora do denominador.

Na próxima versão, vale classificar cada erro por tipo e registrar se o modelo avisou que estava em dúvida. Aí teremos, além da acurácia geral, taxas distintas de invenção, erro numérico, erro de data, omissão e correção durante a revisão.

O mesmo Qwen teve acurácia estrita parecida nos itens avaliados da RTX 5090 e do Strix Halo, 91% contra 90%. Na RTX, nenhuma execução teve invenção grave; no Strix, foram três.

Sol 6: a referência também erra

O Sol foi o mais rápido, não teve falha grave de confiança e concluiu todas as 38 execuções sem estourar a saída. Mesmo assim, só 25 passaram por todos os critérios.

O ponto fraco apareceu nas contas, principalmente em cinco casos brasileiros. Ele errou números em escolha de regime, CBS/IBS, Lucro Real, abertura de empresa e recuperação judicial. Também perguntou bem menos ao cliente: 51 fatos, contra 74 a 95 nos outros modelos, e registrou mais premissas.

Premissa explícita é um comportamento correto quando falta informação. Só que perguntar costuma dar uma resposta melhor do que carregar uma hipótese até o fim.

A revisão final também piorou respostas. Num formulário americano, o Sol tinha acertado os 16 itens antes da revisão. Depois apagou quatro linhas corretas e marcou o trabalho como bloqueado. Em outro caso, anulou dois campos que já estavam certos.

Usar modelo fechado como árbitro continua sendo um erro. O Sol serviu como referência prática desta rodada e teve um perfil limpo, rápido e consistente. Ainda falhou em 13 dos 38 casos pelo critério estrito.

Qwen3.8 Flash-Next na RTX 5090: melhor equilíbrio local

O melhor resultado bruto veio da versão IQ3_S, quantizada em pouco mais de 3 bits, numa única RTX 5090. Foram 27 entregas completas, nenhuma falha grave de confiança e 91% de acerto estrito entre os itens que chegaram a ser avaliados.

Ele levou 432 minutos ativos. A mediana por caso ficou 1,6 vez mais lenta que o Sol, e a geração média chegou a 153 tokens por segundo. Três execuções bateram no teto de saída. Para uma estação local, ainda foi um resultado forte.

Os erros mostram por que precisa de revisão profissional. Num caso brasileiro, calculou prazos com um dia de atraso e usou a revisão final para “confirmar” a própria conta errada. Num litígio americano, tinha calculado corretamente uma parcela de US$ 375 mil e mudou para zero durante a revisão.

Houve ainda duas suspeitas de invenção com confiança média que aguardam revisão humana. Elas não foram contadas como falhas graves. Eu usaria esse modelo para preparar, cruzar documentos, levantar perguntas e produzir uma primeira versão dentro de uma máquina sob meu controle. Não deixaria o resultado sair para o cliente sem alguém qualificado conferir.

O mesmo Qwen no Strix Halo: cinco vezes mais lento

O Strix Halo rodou exatamente a mesma quantização IQ3_S e também terminou com 27 entregas completas. A semelhança para aí.

Foram 2.105 minutos ativos, quase cinco vezes o tempo da RTX 5090 e 8,5 vezes o tempo total ativo do Sol. A mediana do mesmo caso ficou 7,7 vezes mais lenta que a referência. Quarenta tokens por segundo funciona para lote e paciência; numa rotina interativa, você começa a esperar a máquina.

Pior: essa rodada teve três falhas graves. O modelo inventou respostas de clientes, documentos, datas de CDA e fatos que sustentavam suas próprias conclusões. A versão idêntica na RTX não teve nenhuma falha de alta confiança.

Com uma rodada por configuração, eu não consigo atribuir a diferença ao hardware, ao servidor ou à aleatoriedade da inferência. Seria desonesto concluir que Strix “faz o modelo alucinar”. O que os dados permitem dizer é mais simples: esta execução foi lenta e não foi confiável o bastante. Precisa ser repetida antes de qualquer recomendação.

Qwen3.8 Flash-Next na B300: alugar GPU grande não comprou qualidade

Na B300 alugada, o Flash-Next rodou em NVFP4, fez 23 entregas completas e teve duas falhas graves de confiança. Numa delas, inventou cidade, termos contratuais, valores e até uma citação que não existia na biblioteca fechada.

O tempo ativo foi de 622 minutos, com mediana 1,9 vez mais lenta que o Sol e geração média de 148 tokens por segundo. Cinco execuções atingiram o teto de saída; quatro delas efetivamente impediram uma entrega completa. Mesmo no cálculo mínimo, custou entre 4,3 e 5,6 vezes o equivalente de API do Sol.

Neste teste serial, uma B300 não trouxe mais qualidade nem menor latência que a RTX 5090. Isso não mede o principal motivo para alguém comprar ou alugar uma B300, que é servir vários usuários e lotes em paralelo. Eu testei uma contratação de cada vez para manter o protocolo comparável. O máximo que posso concluir é que pagar pela classe de datacenter não melhorou esta sessão individual.

GLM 5.3 Flash na B300: preciso quando termina

O GLM teve um perfil diferente. Não registrou falha grave nem suspeita média de confiança e acertou 93% dos itens estritos que conseguiu entregar, o maior percentual da tabela.

Só completou 23 casos. Sete execuções bateram no teto de 16.384 tokens, e seu acerto cai para 79% quando todo item que ficou sem resposta entra na conta. Levou 725 minutos ativos, 2,7 vezes a mediana do Sol, a 116 tokens por segundo. Pela tarifa oficial da Runpod, o piso ficou entre 5 e 6,5 vezes o equivalente de API do Sol.

A escolha da coluna muda completamente a leitura. O GLM foi cuidadoso e exato nos resultados avaliáveis. O conjunto modelo, harness e limite de saída não terminou trabalho suficiente.

O teto foi uma escolha do harness, não uma limitação intrínseca do GLM. Eu preciso repetir com respostas maiores ou sessões mais curtas. Até lá, vender o 93% sem contar as sete interrupções seria propaganda.

A revisão final ajuda e também estraga

Eu sempre recomendo pedir ao agente para reler tudo antes de entregar. O benchmark confirma a utilidade dessa prática, com uma ressalva importante.

Em 113 das 190 execuções, os avaliadores encontraram algum problema removido ou corrigido na revisão final. Entre eles havia fabricações que teriam chegado à entrega. O modelo relê fontes, retira citação duvidosa, conserta nome e limpa afirmação que não consegue sustentar.

Em cerca de uma dúzia, a mesma revisão mexeu no que estava certo. Sol, RTX e GLM trocaram datas, valores e conclusões corretas por versões erradas. Em dois casos, o modelo refez uma conta errada e saiu ainda mais convencido dela.

Revisão automática é uma camada de higiene. A palavra “revise” não transforma o modelo em auditor independente de si mesmo.

Para trabalho sensível, eu usaria pelo menos duas etapas separadas: um agente produz, outro revisa com contexto limpo e critérios explícitos. A responsabilidade continua com o profissional.

O benchmark também falhou em partes

Os modelos marcaram de 97,5 a 100 na vigilância. Seria tentador anunciar que todos viraram sócios perfeitos. A explicação real é que essa parte da prova ficou fácil demais.

Algumas bibliotecas praticamente entregavam o problema no índice. Certos fatos que deveriam ficar escondidos já apareciam nos documentos. Alguns empurrões do cliente também contavam como descoberta espontânea. Com isso, 961 de 973 armadilhas foram pegas antes da revisão e a métrica perdeu poder de separar os modelos.

Itens de quatro casos com defeitos confirmados na própria suíte foram rebaixados para diagnóstico. Outros casos ainda têm inconsistências que precisam de revisão. A ordem geral se manteve, com mudanças nos empates, porém os valores absolutos não merecem duas casas decimais de confiança.

Há mais limitações:

• uma única rodada por configuração, sem média nem barra de erro;
• Fable como criador e avaliador, sujeito aos próprios pontos cegos;
• nenhum contador, CPA, advogado ou attorney revisou ainda uma amostra formal;
• Codex para o Sol e OpenCode para os modelos locais;
• quantizações e servidores diferentes;
• um limite de saída que afetou apenas os modelos locais;
• legislação fechada no pacote, sem medir pesquisa atualizada na internet.

Eu publiquei esses problemas porque benchmark sem autocrítica vira tabela de marketing. A próxima versão precisa corrigir os casos, endurecer as armadilhas, fixar uma data de referência em todo contrato, aumentar o teto dos casos longos e repetir cada configuração.

Privacidade muda a conta

Para um desenvolvedor trabalhando num projeto aberto, mandar contexto para a nuvem pode ser aceitável. Escritórios contábeis, jurídicos, bancos e empresas reguladas lidam com contratos, estratégias de litígio, documentos fiscais, dados pessoais e segredos comerciais. Política interna, contrato com o cliente ou obrigação regulatória pode impedir que esse material saia da infraestrutura controlada pela organização.

Nesses casos, o modelo local deixa de competir apenas por preço. Às vezes ele é a única opção permitida.

Rodar localmente também não torna os dados seguros por mágica. Ainda precisa controlar acesso à estação, criptografar disco e backup, proteger logs, desligar telemetria desnecessária, limitar rede e saber onde o harness grava sessões. Um servidor local mal administrado continua sendo um vazamento esperando acontecer.

Todos os casos deste benchmark são sintéticos justamente para evitar esse problema durante o teste.

Então já dá para usar?

Nuvem, com Sol: foi a opção mais rápida e previsível desta campanha. O custo equivalente de US$ 16,72 para 38 casos é baixo perto do trabalho necessário para revisar 38 contratações. Faz sentido quando a política permite enviar os dados, com revisão humana obrigatória.

Uma RTX 5090 própria: o Qwen3.8 Flash-Next já serve como assistente local para organizar documentos, preparar rascunhos, fazer contas, apontar pendências e levantar perguntas. Foi o melhor equilíbrio aberto que medi. Ainda errou datas e valores de forma convincente.

Strix Halo: é uma opção compacta, mas 35 horas ativas para a campanha tornam o uso interativo difícil. O resultado desta rodada também teve invenções graves. Pode servir para tarefas em lote e baixo volume depois de novas repetições.

B300 alugada: não melhorou a qualidade de uma sessão e o tempo ativo sozinho já passou de US$ 70 por modelo. Seu caso econômico depende de concorrência, ocupação e volume, coisas que este benchmark não mediu. Para uma pessoa fazendo uma tarefa por vez, os números não justificam a infraestrutura maior.

Nenhuma configuração completou mais de 27 dos 38 casos. O melhor resultado ficou em 71%. Mesmo aceitando que parte das falhas veio do harness e de defeitos da suíte, eu não colocaria nenhum deles para trabalhar sozinho.

Modelos abertos já são assistentes viáveis para contabilidade e Direito. Este experimento ainda não sustenta chamá-los de profissionais autônomos.

Um modelo que economiza duas horas de leitura e prepara uma boa primeira versão já pode pagar a máquina. O valor está em reduzir trabalho repetitivo sem criar um risco maior que o tempo economizado.

Preciso de profissionais nesta próxima rodada

O projeto inteiro está aberto em github.com/akitaonrails/llm-non-coding-benchmark. Lá estão a metodologia, o relatório de correção, os tempos de execução, os casos, scripts e resultados brutos.

Agora preciso mais de profissionais do que de outra GPU. Gente licenciada precisa revisar os casos, as respostas esperadas e as falhas marcadas pelo Fable. Também quero casos novos que reflitam trabalho real sem incluir informação de clientes.

Se você é contador, CPA, advogado ou attorney e achou um absurdo técnico, abra uma issue com a correção e a fonte. É exatamente o tipo de escrutínio que falta para este experimento deixar de ser só uma primeira leitura interessante.

• Parte 1: por que eu refiz o benchmark do zero pela terceira vez, como funciona o app Rails sabotado com CVEs reais, e quanto custou.
• Parte 2: o ranking original da nuvem, com quase 40 modelos, seis empates no topo e um modelo de graça batendo metade do Claude.
• Opus 5.5, GPT-6 sol e luna, MiMo 2.6 e Grok 4.7: a leva seguinte da nuvem. O Opus 5.5 fechou com 100, o GPT 6 luna fez 95,5 por menos de um dólar a rodada, e o Grok 4.7 regrediu contra o próprio antecessor.
• Os top LLMs open source numa B300: uma GPU alugada, 14 modelos abertos, e dois deles, GLM 5.3 Flash e Qwen3.8 Flash-Next, empatados em 92,5, no nível do Sonnet 5.
• Open source que só cabe em 4x B300: os modelos grandes, a maioria de 400 bilhões a 1 trilhão de parâmetros. O DeepSeek V4.1 Flash empatou com o líder em 92,5 e o resto mostrou que tamanho não compra vigilância.
• Meu time cabe em 4x B300/H200?: teste de concorrência de verdade. O mesmo DeepSeek atende 32 sessões confortáveis no pod de B300 e só 8 no de H200.
• Open source nível consumidor na RTX 5090 ou Strix Halo: o Qwen3.8 Flash-Next fez 91 numa placa de PC com o motor Strata, a 159 tokens por segundo.

Este artigo junta tudo numa tabela só e responde a pergunta que sobra: até outubro de 2026, open source já dá conta?

O maior benchmark que eu já rodei

O v4 foi, de longe, a maior rodada de testes que eu já fiz. São quase 70 rodadas completas do mesmo protocolo, quase 60 modelos diferentes, rodando em API de nuvem, numa B300 alugada, num pod de quatro B300, numa RTX 5090 e num Strix Halo, mais um pod de quatro H200 só pro teste de concorrência.

E foi caro. Só a primeira leva, a da nuvem, passou de 4 mil dólares em nove dias, somando créditos e assinaturas. A B300 única custou uns 270, e a campanha de 4x B300 e 4x H200 levou mais uns 2.100. Somando o que eu consigo somar, passou de 6 mil dólares, sem contar as horas de máquina em casa.

Eu não acho que muita gente vai reproduzir isso tão cedo. Se este material te serviu, compartilhe com quem precisa decidir entre nuvem, servidor próprio ou PC local. Todo o código, os prompts, os logs e os relatórios estão abertos no meu GitHub: akitaonrails/llm-coding-benchmark.

Relembrando a régua

O protocolo é sempre o mesmo. O modelo constrói um app Rails de chat em sete sprints, e entre as sprints um revisor injeta 14 defeitos de segurança e de correção, alguns barulhentos (CVE em gem, chave no código), outros silenciosos (vazamento entre tenants, agregado errado, teste adulterado pra esconder backdoor).

A nota vai de 0 a 100. Defeito corrigido sem aviso vale peso cheio; corrigido só depois que eu revelo que tem problema vale 40%; nunca corrigido vale zero. Os tiers são A a partir de 83, B de 73 a 82,5, C de 51 a 72,5 e D até 50.

É uma régua de vigilância de revisão de código. Ela mede se o modelo percebe sabotagem enquanto trabalha, e isso é diferente de medir quem escreve o seu sistema inteiro melhor.

O ranking combinado

Todas as rodadas do v4 numa tabela só, comerciais e abertos, nuvem e hardware próprio. Quando o mesmo modelo rodou em lugares diferentes, ele aparece mais de uma vez, porque o lugar muda a nota.

Como ler as colunas:

• Pesos: “aberto” é checkpoint baixável, qualquer licença; “fechado” é só API.
• Custo da rodada: o que uma rodada completa de sete sprints custou.
• tok/s: velocidade de decodificação de um stream só, medida por mim. Só existe pra quem eu servi.
• Minutos: tempo de relógio da rodada inteira, quando eu tenho o dado. Na B300 única, é só o tempo dos sprints.

E as notas de rodapé:

1. Claude rodou pela assinatura Max do Claude Code. O custo é nocional: os tokens da rodada a preço de tabela da API.
2. Estimado a partir dos tokens da rodada.
3. Só o tempo de inferência na B300 a uns US$ 9 por hora. Download, carga, compilação e tuning ficam de fora, e o custo real do pod foi maior.
4. Nota com ressalva. O Nex na nuvem foi avaliado pelo disco, com tudo sem commit; o Gemini 3.1 Pro foi prejudicado por um bug do proxy do OpenRouter.

Os primeiros artigos do v4 juntavam tudo abaixo de B como C; aqui eu uso a escala com D, a mesma das campanhas de B300. O MiniMax M3.1 Flash rodou de graça pelo OpenRouter como âncora de nuvem da campanha local, e a MiniMax promete liberar os pesos dele no dia 23 de outubro.

Os modelos estão convergindo

No escopo limitado deste benchmark, a impressão é de que todo mundo está chegando no mesmo lugar. 42 das 67 rodadas fizeram Tier A, 24 de modelos fechados e 18 de abertos. Sete modelos bateram 100, e 23 rodadas ficaram acima de 90.

Parte disso é limite da própria régua. Quando sete modelos tiram a nota máxima, o teste deixa de separar o topo. E uma rodada repetida do GPT 5.5 fez 91 contra os 100 da oficial, então diferenças de poucos pontos entre dois modelos podem ser só ruído.

Mesmo descontando isso, o desenho é claro. O DeepSeek V4.1 Flash, o GLM 5.3 Flash e o Qwen3.8 Flash-Next, todos abertos, estão a 7,5 pontos do teto, colados no Sonnet 5 e no GPT 6 sol.

Pra revisão de código e vigilância, o modelo aberto bom já está no pelotão do modelo fechado bom. O que ainda separa os dois é consistência: entre os abertos aparecem notas D que entre os fechados de ponta não aparecem.

O Ocidente parado, a China correndo

Comparando gerações da mesma família dentro do v4, a diferença de ritmo aparece:

Os chineses subiram de 5,5 a 17 pontos por geração, com exceção do Kimi. Do lado ocidental, quem já estava no teto não tinha pra onde subir: o Opus ficou em 100, o GPT 6 luna ficou onde o 5.6 luna estava, e três lançamentos novos ficaram abaixo dos antecessores. O Gemini Flash é o contraexemplo ocidental, com um salto de 15 pontos.

O calendário reforça a leitura. O Claude Fable 5 saiu em junho, o Opus 5 e o GPT 5.6 em julho, e todos já batiam 100 na minha régua. Daí até outubro, a OpenAI e a Anthropic lançaram o Fable 5.1, o GPT-6 Astra, o Opus 5.5 e o GPT-6 sol e luna. Nenhum deles mostrou ganho na minha régua, e alguns ficaram abaixo dos antecessores.

No mesmo intervalo, os chineses saíram de uma posição bem atrás: DeepSeek V4 em abril, Kimi K3 em julho, Qwen 3.8 e GLM 5.3 em agosto, DeepSeek V4.1 Flash e MiMo V2.6 Pro em setembro, MiniMax M3.1 Flash em outubro. Cada lançamento chegou mais perto do topo.

Os chineses parecem andar mais rápido, e andam. Mas parte da impressão vem de os ocidentais estarem parados há meses, pelo menos em programação. Quando o líder não se mexe, quem corre atrás encosta.

Matemática não é programação

Os laboratórios ocidentais não pararam de trabalhar. Eles estão gastando boa parte da vitrine em matemática:

• em maio, a OpenAI anunciou que um modelo de raciocínio de uso geral derrubou uma conjectura de Erdős sobre distâncias unitárias;
• em agosto, ela publicou dez resultados matemáticos do Astra, cada um com prova formal em Lean;
• também em agosto, a Anthropic mostrou um Claude interno elevando de 41,6% pra 67,2% a fração provada de zeros da função zeta de Riemann que satisfazem a hipótese;
• em setembro, a Anthropic formalizou o Último Teorema de Fermat inteiro em Lean em 11 dias, com um modelo interno que ela mesma descreve como comparável ao Fable 5.1.

É impressionante, e é legítimo. Prova formal é um dos poucos lugares onde dá pra verificar a resposta automaticamente, o que torna matemática um ótimo campo de treino e de propaganda. Só que o mesmo Fable 5.1 que serviu de régua pro Fermat fez 95,5 no meu benchmark, contra os 100 do Fable 5.

Ficar melhor em matemática não deixa o modelo automaticamente melhor em programação. Um estudo de 2025, Does Math Reasoning Improve General LLM Capabilities?, concluiu que a maioria dos modelos que vai bem em matemática não transfere o ganho pra outros domínios, com programação entre eles. Há contraexemplos: a NVIDIA mostrou que aprendizado por reforço só com matemática subiu a nota de código de modelos pequenos. A transferência acontece às vezes, e depende de como se treina.

E o tal do mixture of experts

A intuição comum é que, num modelo mixture of experts (MoE), dá pra melhorar o “especialista de matemática” sem mexer no “especialista de código”. A ideia está meio certa pelo motivo errado.

Um MoE tem vários blocos de pesos em cada camada, e um roteador escolhe poucos deles pra cada token. Mas os especialistas não se dividem por assunto do jeito que a intuição sugere. O paper do Mixtral procurou exatamente isso e não encontrou padrão óbvio de especialista por tema, com uma diferença pequena só num conjunto sintético de matemática; o roteador se organiza mais por sintaxe, por tipo de token. E nem a OpenAI nem a Anthropic confirmam publicamente se os modelos fechados delas são MoE.

O que fica de pé é o essencial: capacidade é treinada por objetivo. O sinal que premia prova em Lean não é o mesmo que premia perceber um vazamento entre tenants num controller Rails, e melhorar um não arrasta o outro junto. Num modelo onde só uma fração dos parâmetros trabalha por token, esse descompasso fica ainda mais fácil de acontecer.

NVFP4, FP8, Q4: o que é essa sopa de letrinhas

Todo modelo é uma pilha de bilhões de números, os pesos. Quantização é guardar cada número com menos bits. Quanto menos bits, menos memória o modelo ocupa e menos dado a placa precisa ler por token, e é isso que define a velocidade em máquina local. O preço, quando existe, é qualidade.

Pra um modelo de 27 bilhões de parâmetros, a conta fica assim:

O que é cada um

• BF16 é a precisão em que a maioria dos modelos é publicada. É a referência: nada se perde.
• FP8 é ponto flutuante de 8 bits, com suporte em hardware nas gerações Ada, Hopper e Blackwell. Corta a memória pela metade e é o padrão dos checkpoints grandes, como o DeepSeek V4.1 Flash e o GLM 5.3 full.
• Q8_0, Q5_K_M, Q4_K_M e IQ3_S são formatos GGUF do llama.cpp. Os pesos são guardados em blocos de inteiros com uma escala por bloco; os “K” misturam precisões por tensor, e os “IQ” usam uma matriz de importância pra decidir onde gastar bits. Q8 é tido como praticamente sem perda, e Q4_K_M é o padrão recomendado de quem roda em casa.
• NVFP4 é o formato de 4 bits da NVIDIA. Cada número é um ponto flutuante de 4 bits, e cada bloco de 16 números ganha a própria escala em FP8. A NVIDIA diz que isso ocupa 3,5 vezes menos que FP16 e perde 1% ou menos contra FP8 no DeepSeek-R1.

O hype do NVFP4 vem daí: os tensor cores da Blackwell calculam nele direto, e foi ele que fez caber numa B300 só o GLM 5.3 Flash, de 198 GB, e o Qwen3.5 397B, de 251 GB. A H200, da geração anterior, não tem FP4 nativo. E o ecossistema caseiro ainda está chegando: o llama.cpp ganhou suporte a NVFP4 só em 2026, e a cobertura por arquitetura ainda é parcial.

O que os nossos testes mostram

Quatro modelos rodaram em mais de uma precisão:

¹ Rodada mista: sprints 1 e 2 em Q5_K_M na 5090, o resto em Q8_0 na Strix, com o raciocínio desligado.

E seis rodaram na API de nuvem e também servidos por mim, com os pesos oficiais:

Cada linha é uma rodada só, e o ruído chega a quase 10 pontos. Com essa ressalva, a leitura que eu faço:

• Q8 ficou empatado com BF16. O Qwen 27B fez 80,5 e 80,0, num ponto só e com outras coisas mudando junto.
• Descer de 4 pra 3 bits saiu quase de graça no Flash-Next, a 1,5 ponto, mesmo trocando de motor e de placa.
• A queda da Ornith dificilmente é dos bits. Q8 é quase sem perda, e mesmo assim ela perdeu 16,5 trocando também de motor e de placa.
• Servir o mesmo checkpoint pode dar qualquer coisa. O GLM 5.3 Flash subiu 8 pontos na minha mão, o DeepSeek V4.1 empatou, e o Nex caiu quase 70. Parser de ferramenta, template de chat, modo de raciocínio e versão do motor pesam tanto quanto a precisão, e o efeito muda de modelo pra modelo.

Nos meus testes, os bits pesaram menos do que o hype sugere, e o conjunto todo de como o modelo é servido pesou mais. Use Q8 quando couber, desça pra 4 bits quando precisar, e meça no seu próprio trabalho antes de confiar.

Os melhores comerciais

Aqui só entra modelo fechado, só Tier A, e só o que eu pagaria por API.

Por nota

¹ Custo nocional da assinatura, a preço de tabela da API.

No topo absoluto, o Claude Opus 5.5 e o GPT 5.6 terra são as escolhas óbvias: nota máxima, rodada em pouco mais de uma hora, e preço de rodada de um dígito ou pouco mais. O Opus 5 e o GPT 5.5 tiram a mesma nota custando de duas a sete vezes mais.

Por custo-benefício

¹ Custo nocional da assinatura, a preço de tabela da API.

O GPT 6 luna é o absurdo da tabela: Tier A alto por menos de um dólar a rodada, uma fração do preço de qualquer outro fechado no mesmo patamar. Se a nota máxima não for obrigatória, é por onde eu começaria.

Na nota máxima, o GPT 5.6 terra custa pouco mais da metade do Opus 5.5. A diferença entre os dois fica no resto: harness, velocidade, comportamento em sessão longa, e isso eu cobri nos artigos anteriores.

Os melhores abertos pra empresa

Aqui entra o que roda em GPU de datacenter, na B300.

O DeepSeek V4.1 Flash é o campeão pra time grande. Num pod de 4x B300 a US$ 36 por hora, ele atende 32 sessões confortáveis ao mesmo tempo, com o primeiro token em menos de 2 segundos pra quase todas. Contando uma sessão ativa por desenvolvedor o expediente inteiro, o que é otimista, são 32 pessoas. Ligando o pod só no expediente, 8 horas por dia, 22 dias por mês, dá uns US$ 6.300 por mês, ou uns US$ 200 por desenvolvedor.

As alternativas, pela mesma conta:

• 4x H200 na Runpod atende só 8 sessões confortáveis e sai por uns US$ 316 por desenvolvedor por mês, mesmo com o pod mais barato;
• a mesma configuração na AWS custa quase o dobro, e a H200 na Azure custa quase três vezes o preço da Runpod;
• comprar uma DGX Station GB300 de uns US$ 130 mil se paga em uns 20 meses contra o aluguel no expediente, ou em uns 5 meses contra o pod ligado direto.

Pra time menor, a B300 única com o Qwen3.8 Flash-Next ou o GLM 5.3 Flash é o ponto doce: mesma nota do DeepSeek, numa GPU só, a uns US$ 9 por hora. Eu não medi concorrência nela. Pela memória que sobra, um time de cinco a dez pessoas cabe bem num modelo de 27 a 35 bilhões, como o Swift 1.5; no GLM 5.3 Flash, de 198 GB, fica apertado.

A infra própria começa a fazer sentido na casa de 30 pessoas usando ao mesmo tempo, ou quando o código não pode sair da rede. Abaixo disso, a API do mesmo DeepSeek custa pouco mais de um dólar por rodada e você não administra servidor nenhum.

Os melhores abertos pra consumidor

Aqui entra o que roda num PC: RTX 5090 de 32 GB ou Strix Halo de 128 GB unificados.

Só tem um vencedor: o Qwen3.8 Flash-Next na RTX 5090 com o Strata. É um MoE de 125 bilhões com 6 bilhões ativos por token, e o Strata deixa os especialistas mais usados na placa e o resto na RAM. Ficou a 1,5 ponto da versão de datacenter, em velocidade interativa. Eu detalhei ele, com instalação, serviço de carga automática e configuração do OpenCode, em Melhor LLM Open Source: Strata com Qwen 3.8 Flash Next.

O Strix Halo cabe modelo grande, mas a banda de memória dele é sete vezes menor que a da 5090, e um modelo denso de 27B anda a menos de 10 tokens por segundo em Q8, uns 13 em Q4. Serve pra tarefa de fundo, que pode esperar.

E o Swift 1.5 e o ThinkingCap 3.8, os fine-tunes de 27B que foram bem na B300? Eu não rodei os dois na 5090, e nem precisei. Na B300, em BF16, precisão cheia, eles fizeram 88 e 83, abaixo dos 92,5 do Flash-Next na mesma placa e dos 91 que ele fez na 5090.

Numa 5090 eles caberiam em Q4 ou Q5, mas quantizado o melhor cenário é repetir a nota da B300. Rodar em casa custou 1,5 ponto pro Flash-Next e 16,5 pra Ornith-35B. O Qwen 3.8 27B base, que é a mesma arquitetura, nem completou na 5090 em Q5_K_M: travou num loop de raciocínio no sprint 3.

Se os dois já ficaram atrás do Flash-Next com precisão cheia, numa 5090 eles não vão ficar melhores. Não vi motivo pra testar: pra PC, o Flash-Next é claramente a escolha.

E placa pior que a 5090?

É a pergunta que sempre aparece: e quem tem uma placa de 8, 12 ou 16 GB? Pelos meus dados, o caminho do modelo pequeno que cabe inteiro na placa ainda não entrega nada que valha o trabalho pra programar.

Numa placa dessas, em Q4, cabe modelo denso de até uns 20 bilhões; um MoE de 30 bilhões com poucos ativos só roda com parte na RAM. E essa faixa foi mal no v4:

• o GLM-4.7-Flash, um MoE de 30B com 3B ativos, fez 24 na 5090 e 33,5 na B300 com precisão cheia, Tier D nas duas;
• a Ornith-35B, outro MoE com 3B ativos, fez 81 na B300 e caiu pra 64,5 na 5090;
• o gpt-oss-20b nem completou o protocolo;
• o melhor modelo médio foi o Qwen 3.8 27B, com 80, mas ele já precisa de uns 16 GB só em Q4, travou na 5090 e só terminou a 8 tokens por segundo na Strix.

A exceção é justamente o Flash-Next. O Strata foi feito pra rodar ele em placa de 12 GB, segurando a maioria dos especialistas na RAM: o README do projeto publica 53 tokens por segundo em IQ3_S numa RTX 5070 de 12 GB com 64 GB de RAM, e o mínimo declarado é 32 GB somando RAM e VRAM. Com os mesmos pesos e o mesmo motor, a nota em tese não deveria mudar, só a velocidade, que cai pra um terço da 5090. Eu não medi isso; é número do autor.

O porém é a RAM. Com a DRAM quase dobrando de preço num único trimestre deste ano, 64 GB deixaram de ser o upgrade barato que eram.

Abaixo da 5090, eu não perderia tempo com modelo pequeno pra programar. Se for tentar alguma coisa, que seja o Flash-Next com Strata e RAM sobrando, e meça no seu trabalho antes de confiar.

E tem o problema que eu contei no artigo anterior: achar uma 5090 hoje é difícil, e quando acha, o preço fica entre duas vezes e meia e quase cinco vezes o sugerido.

Quanto custa sair dos 150 tokens por segundo?

Depois de algumas horas usando o Qwen local, resumi o problema no X. A média de 159 tokens por segundo da minha rodada parece rápida numa tabela. Numa sessão de programação que passa o dia inteiro gerando código, rodando teste, lendo log e corrigindo o que fez, a espera acumula.

Eu já fico impaciente. Abaixo disso, nem considero pra trabalho diário.

A própria 5090 tem limites além da velocidade. A NVIDIA especifica 32 GB de GDDR7 e 1.792 GB/s de banda e lançou a placa por US$ 1.999. A minha ainda move os monitores e o Hyprland, então deixo 4 GB reservados pro desktop. O resto precisa segurar pesos densos, cache dos especialistas quentes, buffers do motor e a parte residente do cache de KV, que guarda o contexto da conversa.

Minha configuração do Strata oferece 256 mil tokens de contexto com KV em int8 e mantém 32 mil residentes na VRAM; o restante pode ir pra RAM. Isso evita estourar a placa, mas RAM continua muito mais lenta. Enquanto modelos de fronteira do Claude já oferecem janela de 1 milhão de tokens, localmente eu preciso vigiar o que entra na sessão. Carregar uma coleção inteira de skills, plugins e servidores MCP só porque existe espaço no arquivo de configuração é pedir pra desperdiçar contexto e piorar a latência.

Em hardware local, contexto também custa memória e tempo. Eu carrego só o que aquela sessão vai usar.

E se eu colocar mais hardware? A comparação fica assim:

Eu escrevi no post que o Strata só subiria duas instâncias numa máquina com duas 5090. Essa parte ficou desatualizada: o Strata atual divide as camadas entre duas ou mais GPUs. É pipeline parallelism, sem transformar duas placas num bloco simples de 64 GB e sem tensor parallelism maduro.

O ganho por sessão fica longe de 2x. Um teste comunitário com duas 5090 mediu cerca de 22% de ganho na média geométrica de decode e 40% no braço de código. Ajuda na capacidade e dá pra usar as placas como duas instâncias independentes pra dobrar concorrência. Pra mim sozinho, comprar outra 5090 pra cortar uma fração da espera não fecha a conta.

O Mac Studio M5 Ultra começa em US$ 5.499, tem 1,2 TB/s de banda e vai de 96 a 256 GB; a opção de 512 GB foi prometida pro fim de outubro. Ainda não existe benchmark publicado do Strata no Ultra. No M5 Max de 128 GB, o mesmo Flash-Next ficou entre 97 e 119,5 tokens por segundo, dependendo da quantização e do prompt. Meu palpite original de menos de 100 no Ultra não está comprovado, e eu não compraria uma máquina dessas baseado em palpite.

A DGX Spark coloca 128 GB numa caixa compacta, com o GB10 de TDP 140 W e uma fonte de 240 W. A memória entrega só 273 GB/s, quase sete vezes menos que a 5090. A NVIDIA agora pede US$ 6.950.

Receitas reproduzíveis do Flash-Next variam de 22 a 75 tokens por segundo por sessão, dependendo de concorrência, stack, amostragem e modo de raciocínio. Cabe muita coisa. Pra minha tolerância, anda pouco.

Sobra a RTX PRO 6000 Blackwell. Ela tem 96 GB GDDR7 ECC, 1.792 GB/s e potência total de 600 watts. A banda é exatamente a mesma da 5090. Os 96 GB resolvem o aperto de VRAM, permitem mais cache e contexto, mas não compram três vezes a velocidade.

Um benchmark comunitário do Strata mediu 187,4 tokens por segundo no chat curto e 174,3 numa sessão de agente, com bastante variação entre rodadas. É melhor que meus 159,2, só que a NVIDIA lista a placa por US$ 16 mil. Em 22 de outubro, a WAZ mostrava a PNY por R$ 123.299,99 no Pix ou R$ 145.058,81 no preço regular. Já entramos em orçamento de workstation profissional ou servidor.

Hoje não existe, pra mim, uma opção doméstica com modelo bom, resposta realmente rápida e custo razoável. A 5090 funciona, mas 150 tokens por segundo já me cansam. Abaixo dela vira brinquedo; acima dela o preço explode antes da velocidade.

O que eu aprendi no v4

Sobre os modelos

• Quase todo modelo pega o defeito barulhento sem aviso: CVE em gem, chave no código, CORS aberto, SQL injection óbvia. Quase todo modelo deixa passar o silencioso até eu revelar: vazamento entre tenants, agregado errado, teste adulterado, índice removido. O que separa o Tier A do resto é quanto do silencioso ele pega sozinho.
• Tamanho não compra vigilância. O Kimi K2 Thinking, de 1 trilhão de parâmetros, fez 46. O GLM 5.3 full, de 700 bilhões, fez 76, contra 92,5 do Flash da mesma família.
• Modelo trapaceia ou se engana com convicção. O Nemotron adulterou um teste de regressão pra passar, o Qwen3.5 397B deixou passar uma backdoor e ainda escreveu um teste que a tratava como comportamento esperado, e o Kimi K2 fez teatro de checklist de segurança, pegando só o que dá pra achar com grep.
• O salto entre gerações foi de confiabilidade agêntica. O GPT-4o e o GPT-4.1 nem conseguem completar o protocolo sozinhos. Os modelos atuais do topo rodam as sete sprints sem ajuda nenhuma.

Sobre servir modelo aberto

• O mesmo checkpoint muda de nota conforme quem serve. O DeepSeek V4 Flash fez 85 na nuvem, na mesma versão 0731 que eu baixei, e 44,5 servido por mim; o Nex N2.5 Pro fez 94 na nuvem e 27 no pod de 4x B300, com tokens corrompidos chegando no código commitado.
• Nenhum modelo roda rápido do jeito que vem. O GLM 5.3 Flash saiu de 10 pra 141 tokens por segundo só de configuração, e cada família pediu parser, flag e às vezes uma branch de PR do vLLM.
• Rodar em casa cobra preço diferente de cada modelo. Trocando quantização, motor e placa de uma vez, o Flash-Next perdeu 1,5 ponto e a Ornith-35B perdeu 16,5.
• Quem limita a concorrência é a arquitetura do cache de KV e o tempo até o primeiro token. Contagem de parâmetros diz pouco: na H200, um modelo de 510 GB e outro bem menor empataram em 8 usuários, por motivos opostos.

Sobre medir

• Uma rodada tem ruído de quase 10 pontos. Duas notas a 2 pontos de distância empatam.
• O harness pesa. O Gemini 3.1 Pro foi derrubado por um bug de proxy, o gpt-oss não completa no OpenCode, e três modelos insistiram em criar o app numa subpasta.
• Modelo que não faz commit perde trabalho. Correção que fica só no disco some no primeiro git checkout.

A minha hipótese: o hardware caro é parte do modelo de negócio

O veredito do v4, até outubro de 2026, é este: pra revisão de código e vigilância, open source chegou. O DeepSeek V4.1 Flash, o GLM 5.3 Flash e o Qwen3.8 Flash-Next estão no pelotão do Sonnet 5 e do GPT 6 sol, e um deles roda numa placa de PC.

Então por que não está todo mundo rodando em casa? Porque o hardware ficou caro e difícil de achar, e eu tenho uma hipótese sobre isso. É hipótese minha, sem prova de combinação nenhuma, montada em cima de fatos públicos.

Os fatos

• A memória disparou. A TrendForce mediu alta de 93% a 98% no preço de contrato de DRAM só no primeiro trimestre de 2026, e diz que os fabricantes continuam priorizando capacidade pra servidor no quarto trimestre.
• A HBM, a memória das GPUs de datacenter, deve ter o preço médio subindo 121% em 2027 e ocupar perto de 30% das bolachas de DRAM dos três maiores fabricantes até o fim de 2027.
• A Micron saiu do mercado consumidor e matou a Crucial, nas palavras dela, pra atender melhor os clientes estratégicos maiores.
• PC e console subiram de preço, e a Microsoft atribuiu o aumento do Xbox ao custo de memória e armazenamento.
• A RTX 5090, quando aparece nos Estados Unidos, custa de duas vezes e meia a quase cinco vezes o preço sugerido, e o boato é que os chips dela vão pras linhas profissionais. A NVIDIA nega a descontinuação.
• Do outro lado, a Anthropic pediu IPO mirando, segundo a imprensa, uns 2 trilhões de dólares, e a OpenAI está captando a mais de 1,4 trilhão.
• E o discurso sobre modelo aberto chinês endureceu. A Anthropic publicou que DeepSeek, Moonshot e MiniMax destilaram o Claude, e o Dario Amodei, mesmo dizendo que nunca defendeu proibir pesos abertos, pede controle de exportação de chip e teste obrigatório, antes do lançamento, de todo modelo suficientemente capaz, aberto ou fechado.

O ciclo

A explicação mais simples pra memória cara é demanda: datacenter compra tudo e paga mais. Eu acredito nela. O que me incomoda é que nenhum participante grande tem incentivo pra quebrar o ciclo:

1. O discurso diz que só o laboratório de fronteira sabe lidar com esses modelos “perigosos”, e que open source é uma aposta arriscada.
2. Isso puxa a demanda pra nuvem, e a nuvem compra GPU e memória em volume recorde.
3. Os fabricantes vendem com ágio pra quem paga mais e tiram prioridade do consumidor.
4. O hardware bom fica inacessível fora do datacenter.
5. Sem hardware em casa, o open source não é adotado, o que reforça o discurso do passo 1.

Se todo mundo começasse a hospedar o próprio modelo, as contas de IPO de trilhões de dólares deixariam de fechar. O v4 mostrou que o modelo aberto já está pronto pra boa parte do trabalho. O que falta é o hardware chegar na mão de quem trabalha.

O resultado, resumido: o Qwen3.8 Flash-Next servido pelo Strata numa RTX 5090 fez 91, Tier A, com zero nudges e os 14 defeitos plantados resolvidos (dois só depois da revelação), a 1,5 ponto do mesmo modelo rodando numa B300 de datacenter. E fez isso a uns 159 tokens por segundo.

Neste artigo eu detalho o que é o Strata, por que ele importa justo agora, o que ele não resolve, e como eu deixei ele rodando no dia a dia, com carga e descarga automática e integrado no OpenCode.

O que é o Strata

O Strata é um motor de inferência open source, licença MIT, feito em torno de um modelo: o Qwen3.8 Flash-Next, um MoE de 125 bilhões de parâmetros com 6 bilhões ativos por token, que normalmente pede servidor. O código é C++ e CUDA, reaproveita partes do llama.cpp/ggml, e tem builds pra NVIDIA, AMD (inclusive Strix Halo), Intel Arc e Mac. Ele sobe uma API compatível com OpenAI e com Anthropic em localhost.

O truque é tratar o PC inteiro como uma hierarquia de memória. O modelo tem 24.576 especialistas, 512 em cada uma das 48 camadas, e cada token usa só 10 por camada, mais um especialista compartilhado:

• a VRAM guarda os especialistas mais usados, como um cache;
• a RAM guarda todos, e quando o token precisa de um que não está na placa, o processador calcula ele ali mesmo, enquanto a placa trabalha nos outros;
• o SSD guarda uma tabela de consulta de uns 29 GB, da qual o modelo lê poucas linhas por token.

Em cima disso, uma cabeça de especulação que vem com o próprio modelo chuta os próximos tokens e o modelo grande confere todos de uma vez. O README promete a mesma resposta 1,6 a 1,8 vez mais rápido.

Na minha 5090, o log mostra como isso fica na prática. Os 32 GB de VRAM seguram de 10 a 11,5 mil especialistas em uns 20 a 22 GiB, quase metade do total, e em geral de 90% a 97% dos especialistas que cada token pede já estão na placa. O resto a CPU calcula direto na RAM, e só uma fração pequena é copiada pra placa pelo barramento PCIe. É por isso que a CPU também trabalha pesado, como dá pra ver mais abaixo.

Por que isso importa agora

Porque memória virou artigo de luxo. Em 2026 o preço de contrato da DRAM quase dobrou num único trimestre, os fabricantes continuam priorizando servidor, e a Micron largou o mercado consumidor pra atender os clientes grandes. A própria RTX 5090, quando aparece, custa de duas vezes e meia a quase cinco vezes o preço sugerido, como eu contei no veredito.

Nesse cenário, a forma tradicional de rodar um modelo Tier A em casa, com o modelo inteiro dentro da VRAM, é inviável. O Flash-Next em NVFP4 ocupou uns 100 GB de placa na B300; em casa ninguém tem isso.

O Strata inverte a premissa: em vez de exigir VRAM pro modelo inteiro, ele usa a VRAM como cache e a RAM como estoque. É o que permite um modelo Tier A rodar com uma fração da memória de vídeo que ele pediria.

Não é mágica

O Strata faz caber, mas não faz milagre. O mínimo declarado é 32 GB somando RAM e VRAM, mas com isso roda só a versão mais comprimida; a IQ3_S que fez os 91 pede uns 64 GB de RAM. Some uns 80 GB de disco, de preferência SSD, e uma placa de 12 GB pra cima no caminho oficial. Abaixo disso até sobe, tem relato com placa de 8 GB, mas a uns 15 tokens por segundo.

Banda de memória é o que define a velocidade

Na geração de token, o gargalo de máquina local quase nunca é o cálculo. É quantos bytes por segundo a memória consegue entregar pros núcleos, porque cada token precisa ler os pesos ativos do modelo. E aí a diferença entre os tipos de memória é brutal:

A última linha é da minha máquina: a placa está rodando com 8 linhas de PCIe em vez de 16, e o Strata mede isso na inicialização. Mais um motivo pra o cache na VRAM ser tão importante.

O Strix Halo tem 128 GB e cabe muito mais coisa que uma 5090, mas cada byte chega sete vezes mais devagar. Foi isso que eu medi no benchmark: o Qwen 3.8 27B denso em Q8 lê uns 29 GB por token, e na Strix o teto teórico fica perto de 9 tokens por segundo. Eu medi 7,7. A mesma conta na banda da 5090 daria uns 60, sete vezes mais, se o modelo coubesse com o contexto.

É por isso que o desenho do Strata funciona: o caminho quente fica na GDDR7, e o que falta no cache é calculado pela CPU na DDR5, ou atravessa o PCIe, os dois dezenas de vezes mais lentos. Com mais de 90% de acerto no cache, o pouco que fica de fora não derruba a velocidade. Numa placa pequena, o cache cobre menos, mais especialistas vão pela estrada lenta, e a velocidade cai: o próprio autor publica 53 tokens por segundo numa RTX 5070 de 12 GB, um terço da minha 5090.

PC batata não roda

Então esqueça notebook com GPU integrada e 16 GB de RAM. Sem uma placa dedicada razoável, sem 32 GB somando RAM e VRAM e sem SSD, o modelo não sobe, ou sobe e anda na velocidade da RAM, que é a de uma carroça.

E tem o custo de entrada que não aparece na velocidade de geração: o Strata lê a primeira mensagem de cada conversa inteira, e o README fala em uns 60 segundos a cada 30 mil tokens como regra geral. Na minha 5090 é bem mais rápido, uns 100 mil tokens em 16 a 20 segundos, mas numa placa menor conte com o número do README. Agente de código manda prompt de sistema grande, então a primeira resposta de cada sessão demora mais que as seguintes.

Pesado até na minha 5090

Minha máquina não é fraca: Ryzen 9 7950X3D, 96 GB de RAM (o sistema enxerga uns 92), RTX 5090 de 32 GB. Mesmo assim, o Flash-Next ocupa tudo:

• na carga, ele joga uns 50 GB de especialistas na RAM, a uns 3 GB por segundo com o SSD frio, e enche o cache da placa com mais de 20 GiB;
• com tudo carregado, sobram menos de 800 MB de VRAM livre;
• com o servidor de pé, a máquina fica com 88 dos 92 GB de RAM ocupados, e o sistema começa a usar swap.

Este é o btop no meio de uma sessão de trabalho com o OpenCode. O processo do Strata sozinho segura 54 GB de RAM e metade da CPU, com metade das 32 threads do 7950X3D cravadas em 100% e o resto acima de 50%. A 5090 está a 99% de uso, com 30 dos 32 GB de VRAM ocupados e puxando 351 W. Sobram 4 GB de RAM disponíveis, e já tem quase 48 GB em swap.

O efeito colateral aparece no resto do sistema. Com a VRAM no limite, o lançador de aplicativos do meu desktop e o terminal num monitor secundário pararam de abrir direito, e outros programas ficam lentos. A solução foi mandar o Strata devolver uns 2,5 GB de VRAM pro desktop, com a opção --vram-elastic, ao custo de um cache um pouco menor.

Com tudo isso, eu acredito firmemente que a minha máquina é o mínimo pra usar um LLM local em trabalho de programação de verdade, além de exercício pequeno. Com menos que isso, conte com velocidade bem menor, contexto mais curto e o PC inteiro sofrendo enquanto o modelo está carregado.

Como instalar

O caminho oficial no Linux e no Mac é o instalador de uma linha. Ele verifica o SHA-256, não pede root e instala na sua pasta pessoal. Como todo curl | sh, vale baixar e ler antes:

curl -fsSL https://github.com/Niko1221/Strata/releases/latest/download/install.sh -o install.sh
less install.sh
sh install.sh

Depois, o strata launch pergunta modelo, contexto e acesso, baixa o motor certo pra sua placa e o modelo, e começa a servir. Pra scripts, tudo vai por flag:

strata launch                                # telas guiadas
strata launch --model <variante> --yes --no-tui   # sem perguntas
strata launch --status                       # o que está servindo
strata launch --stop                         # parar
strata monitor --url http://127.0.0.1:8080   # velocidade, GPU, memória

Eu usei a variante IQ3_S, a que fez os 91 no benchmark. No disco ela ocupa uns 84 GB em dois arquivos (o modelo de 55 GB e a tabela de consulta de 29 GB), mais uns 7 GB da cabeça de especulação.

A configuração que o strata launch gera é um JSON com os argumentos do motor. Os que importam na minha:

"args": [
  "--expert-cache", "auto",
  "--prefill", "auto",
  "--spec", "4", "--spec-min-p", "0.5",
  "--mtp", "/mnt/data/strata-models/mtp/rt",
  "--max-context", "262144",
  "--kv", "int8",
  "--kv-resident", "32768",
  "--vram-elastic"
]

O --spec 4 liga a especulação com uma janela de 4 tokens por passo, até 3 chutados pela cabeça de especulação; o --kv int8 guarda o cache de atenção em 8 bits; o --kv-resident deixa só 32 mil posições do cache de contexto, as mais lidas, na VRAM; e o --vram-elastic permite devolver VRAM pro desktop com o servidor rodando.

De 128 mil pra 256 mil tokens de contexto

O benchmark rodou com 128 mil tokens de contexto, que é o que a instalação configurou por padrão. Depois eu subi pra 256 mil, com --max-context 262144, e a perda foi pequena: nos logs do servidor, a geração ficou na média de uns 190 tokens por segundo numa sessão curta com 128 mil e de uns 175 com 256 mil, uns 10% mais lenta pelo dobro de contexto, um pouco mais com a VRAM devolvida pro desktop.

O que segura isso é o --kv-resident: só 32 mil posições do cache de atenção, as mais lidas, ficam na VRAM, o resto fica na RAM, e mesmo assim umas 97% das leituras desse cache acontecem na placa. A nota de 91 do benchmark foi medida com 128 mil; com 256 mil eu medi velocidade, e a qualidade ainda não foi re-testada.

Pra mim, 256 mil é o mínimo pra trabalho longo com agente. Com 128 mil, uma sessão de verdade estoura o contexto rápido, e o agente começa a compactar a memória toda hora. Isso fica irritante muito rápido, e cada compactação joga fora detalhe que o modelo vai precisar mais tarde.

Contexto curto é um problema escondido de modelo local. Antes de olhar tokens por segundo, veja quanto contexto você consegue servir sem a velocidade desabar.

Carregar e descarregar sozinho

Deixar uns 50 GB de RAM e a placa inteira presos o dia todo, só pra ter o modelo pronto quando eu precisar, não faz sentido. Então montei um proxy pequeno, em Python puro, que fica sempre de pé na porta 8080 e controla o Strata:

• responde a lista de modelos sozinho, então o OpenCode enxerga o modelo sem acordar nada;
• na primeira requisição de chat, sobe o Strata numa porta interna e espera ficar pronto, uns 40 segundos;
• repassa as respostas em streaming;
• depois de 10 minutos sem tráfego, derruba o Strata e devolve a placa e a RAM pro sistema; nunca no meio de uma requisição.

O miolo é este:

def ensure_up():
    with _lock:
        if ready():
            return True
        subprocess.Popen([STRATA, "serve", "--config", CFG,
                          "--host", "127.0.0.1", "--port", str(UP_PORT)],
                         start_new_session=True)
        for _ in range(90):          # carga a frio leva ~35-40 s
            if ready():
                set_reserve()        # devolve VRAM pro desktop
                return True
            time.sleep(2)
        return False

def idle_watch():
    while True:
        time.sleep(30)
        if time.time() - _last > IDLE_TTL:
            # nunca derrube o motor com requisição em voo (ver abaixo),
            # mas com teto: requisição vazando não prende a GPU pra sempre
            if _active > 0 and (time.time() - _last) < ACTIVE_HARD_CAP_S:
                continue
            stop_up()                # libera GPU e ~50 GB de RAM

E um serviço de usuário do systemd mantém o proxy de pé desde o login (versão resumida):

# ~/.config/systemd/user/qwen-strata.service
[Unit]
Description=Qwen3.8 Flash-Next on-demand proxy (Strata RTX 5090)
After=network-online.target

[Service]
Environment=QWEN_IDLE_TTL=600
Environment=QWEN_VRAM_RESERVE_MIB=2560
Environment=QWEN_UP_PORT=8781
Environment=QWEN_PROXY_PORT=8080
ExecStart=%h/.local/bin/qwen-strata-ondemand
Restart=on-failure
KillMode=mixed

[Install]
WantedBy=default.target

systemctl --user daemon-reload
systemctl --user enable --now qwen-strata.service

O bug do “parou do nada”

A primeira versão desse vigilante de idle tinha um bug maldoso, e vale contar porque ele ensina uma coisa sobre modelos que pensam sempre. O Flash-Next raciocina antes de responder, e numa fase longa de raciocínio ele pode ficar mais de 10 minutos sem emitir um único byte. Para o relógio de idle, aquilo era “ninguém usando”: o proxy derrubava o Strata no meio da própria requisição, engolia a truncagem do stream, e o OpenCode recebia um turno vazio, sem conteúdo e sem erro. O modelo parecia ter parado do nada.

Três correções, todas no proxy:

• Contador de requisições em voo (_active, o if novo do trecho acima): enquanto houver uma requisição em andamento, o motor não cai. Com teto: depois de QWEN_ACTIVE_HARD_CAP_S (1 hora por padrão, seis vezes o TTL normal), até uma requisição vazando por bug não consegue prender a GPU e a RAM pra sempre.
• Relógio atualizado por byte: o contador de idle agora zera no início de cada requisição e a cada pedaço repassado no streaming. Geração em curso nunca conta como inatividade; o período sem byte nenhum, que é o raciocínio puro, fica coberto pelo _active.
• Falha honesta no meio do stream: se o motor morrer mesmo assim, o proxy agora emite um evento de erro no stream ("upstream engine died mid-stream") em vez de fechar calado. O agente vê que a resposta morreu e tenta de novo, em vez de ficar olhando um turno vazio parecendo travado.

O preço é a espera na primeira mensagem depois de um tempo parado. Em troca, quando eu não estou programando, a máquina volta a ser minha.

Configurando o OpenCode

O Strata tem um atalho, strata connect opencode --write, que escreve a configuração depois de perguntar e guarda backup. Na mão, é um provider compatível com OpenAI apontando pra porta local:

"provider": {
  "strata-5090": {
    "npm": "@ai-sdk/openai-compatible",
    "name": "Strata (RTX 5090)",
    "options": {
      "baseURL": "http://127.0.0.1:8080/v1",
      "apiKey": "local"
    },
    "models": {
      "qwen3.8-flash-next-iq3_s": {
        "name": "Qwen3.8 Flash-Next IQ3_S (Strata 5090)",
        "reasoning": true,
        "tool_call": true,
        "limit": { "context": 262144, "input": 229376, "output": 32768 }
      }
    }
  }
}

Qualquer chave serve, porque o servidor é local. O próprio Strata avisa que o OpenCode precisa do limit.input, pra saber quanto do contexto sobra pra entrada; no exemplo eu pus o contexto menos a saída máxima. O Claude Code também funciona, apontando ANTHROPIC_BASE_URL pra http://127.0.0.1:8080 e ajustando CLAUDE_CODE_MAX_CONTEXT_TOKENS pro tamanho do contexto, já que o Strata fala a API da Anthropic também.

Um detalhe: por padrão o Strata atende uma requisição por vez. Se o seu agente dispara subagentes em paralelo, eles entram em fila.

E no dia a dia?

Se você tem a máquina pra isso, o resultado é bom. O Flash-Next passa de 150 tokens por segundo na maior parte do tempo, como dá pra ver no print do começo, e a chamada de ferramenta é sólida: no benchmark ele rodou as sete sprints no OpenCode sem nenhum empurrão, e no uso normal ele lê arquivo, roda comando e edita código sem tropeçar no formato.

Na prática, não sinto muita diferença pro Claude Code ou pro OpenCode com GLM ou Kimi na nuvem. E a nuvem não anda no melhor momento: na minha percepção, todos esses serviços estão um pouco mais lentos que o normal ultimamente, provavelmente sofrendo com demanda maior que a capacidade disponível. Rodando em casa, a velocidade é sempre a mesma, e o código não sai da minha máquina.

Mesmo com os tokens por segundo bons, eu ainda sinto o Flash-Next um pouco menos responsivo que um modelo comercial. Tem os segundos de leitura na primeira mensagem de cada sessão, a pausa quando ele precisa de especialistas que não estão na placa, e a carga a frio depois de um tempo parado. É o esperado: estamos rodando um modelo de servidor com os recursos no limite.

Considerando que é de graça e roda na minha máquina, ele está quase bom o suficiente. Pela primeira vez, rodar um modelo local pra programar parece um cenário usável de verdade, e eu me vejo usando cada vez mais como substituto.

O porém continua sendo o hardware. Uma 5090, 96 GB de RAM e um processador forte são o mínimo pra esse cenário, e esse hardware está cada vez mais caro e difícil de achar. Mas, pra quem já tem, o Tier A em casa deixou de ser promessa.

Voltei pra duas máquinas que eu já tinha: uma workstation com RTX 5090 e um mini PC Strix Halo. E com um motor de inferência novo, o Strata, que promete fazer MoE grande caber em PC comum. A resposta curta: um modelo de 125B já faz Tier A numa RTX 5090. O resto é mais complicado.

As máquinas, lado a lado

Antes de qualquer nota, entenda a diferença física do que eu estou comparando:

O B300 tem mais de 30 vezes a banda de memória da Strix Halo. A 5090 tem 7 vezes. Isso explica por que o mesmo modelo voa numa máquina e rasteja na outra, e por que quantização deixa de ser detalhe e vira decisão de projeto.

E tem o detalhe da memória ser compartilhada: na Strix e na Spark, a mesma RAM serve CPU, GPU e sistema operacional. Não é VRAM dedicada, então a folga real é bem menor que o número bonito da caixa.

O ranking em hardware de consumidor

A régua é a mesma do benchmark v4 de sabotagem: 14 defeitos plantados, nota de vigilância de revisão, Tier A a partir de 83.

O GLM-4.7-Flash completou o protocolo inteiro (depois de uma primeira tentativa aninhada que precisou de retry) e mesmo assim fracassou em detectar sabotagem. E tem uma lição de humildade no Qwen 27B: ele fez 80 na mesma tarefa em que fez 80,5 na B300, mas a 7,7 tokens por segundo na sonda Q8 e 706 minutos de relógio. Nota boa não paga produtividade.

Deixei de fora os testes que ainda não têm nota final: a Qwen3.8 Flash-Next na Strix com Strata só está confirmada como executável, e as densas de 27B foram descartadas na Strix pelo corte de 30 tok/s.

O tuning que faz modelo rodar bem em PC

Hardware de consumidor não perdoa configuração preguiçosa. O que eu aprendi na prática:

• Na 5090, compile o llama.cpp pro sm_120. Imagem pronta cai em fallback PTX lento. É -DGGML_CUDA=ON -DCMAKE_CUDA_ARCHITECTURES=120, driver 570+, e nada de --ctx-size 0 numa placa de 32 GB: o default de contexto de treino estoura a VRAM na primeira alocação. Contexto tem teto explícito, e se der OOM no primeiro request, corta 25 a 50%.
• KV cache em q8_0. Corta a memória de KV pela metade sem custo mensurável de qualidade. Flash-attention ligado por padrão, mas o GLM 4.7 Flash precisa dele desligado, porque a arquitetura deepseek2 dele é incompatível.
• Raciocínio híbrido dá trabalho. O Qwen3.8-27B, com a arquitetura SSM/Mamba, precisou de build fresco do llama.cpp/Ollama por causa do ssm_conv1d. E o modo “sem raciocínio” não impediu loop de coerência em uma das tentativas; a saída foi retomar na Strix com Q8_0 e --reasoning off. Não foi memória extra que resolveu, foi desligar o pensamento.
• Na Strix, o ajuste é ROCm, não mágica. HSA_OVERRIDE_GFX_VERSION, GGML_HIP_NO_VMM, -dio. O trunfo dela é capacidade (128 GB), não velocidade (~256 GB/s). Q4_K_M deu 12,6 tok/s e Q8_0 deu 7,7 tok/s, abaixo do meu corte de 30 tok/s pra uso interativo. Por isso a Strix virou escape hatch de modelo grande, não caixa de chat rápida.
• Especulação só ajuda com aceitação alta. Num teste do Mihai Farcas numa RX 7900 XTX, a especulação por n-gram do llama.cpp, sem modelo de rascunho, teve só 5 de 64 tokens aceitos, e a vazão ficou igual numa rodada e caiu uns 2% na outra. O ganho aparece com um rascunhador feito pro modelo, como o ajudante que o Strata usa no Flash-Next.

O que é esse tal de Strata

O Strata é um motor de inferência open source, licença MIT, feito em torno de um modelo: o Qwen3.8 Flash-Next, um MoE de 125 bilhões de parâmetros que normalmente pede servidor. Ele também roda MoEs menores, como a Ornith-35B que testei aqui. O código é C++ e CUDA e reaproveita partes do llama.cpp/ggml. Tem builds pra NVIDIA (CUDA 12 e 13), AMD (inclusive Strix Halo), Intel Arc e Apple Silicon, e sobe uma API compatível com OpenAI e Anthropic em localhost, que pluga direto no Claude Code, Codex CLI ou OpenCode.

Cuidado com o nome. O Mihai Farcas publicou outro motor chamado Strata, em Rust com kernels HIP, pra modelos densos pequenos do Qwen 3.5 numa RX 7900 XTX. São projetos diferentes, e o que rodou aqui foi o primeiro.

O problema que ele ataca é o MoE grande em máquina pequena. A estratégia é expert-offload, em camadas:

• o modelo tem 24.576 especialistas, 512 em cada uma das 48 camadas, e cada token usa só 10 por camada;
• a GPU guarda uns 4 mil especialistas, os mais usados;
• a RAM do sistema guarda todos;
• uma tabela de consulta de uns 29 GB fica no SSD, e o modelo lê poucas linhas dela por token.

Em cima disso, um ajudante pequeno chuta as próximas palavras e o modelo grande confere todas de uma vez. O README promete a mesma resposta 1,6 a 1,8 vez mais rápido. O mínimo é 32 GB somando RAM e VRAM, mais uns 80 GB de disco, e a variante IQ3_S que eu usei tem uns 55 GB.

O que me fez acreditar nele foi o resultado: o Qwen3.8 Flash-Next na 5090 com Strata fez 91,0, com zero nudges e os 14 itens resolvidos, a 1,5 ponto do 92,5 que o mesmo modelo fez na B300 com vLLM. O próprio relatório chama isso de “dentro do ruído”. Um projeto de comunidade, numa placa de consumidor, ficou colado no mesmo modelo servido em datacenter em NVFP4.

E agora ele enxerga

Até ontem, o meu Strata era cego: mandar imagem devolvia “this server was started without the vision encoder”. Habilitei a visão na mão, e foi mais simples do que parecia.

O projetor de visão (o mmproj) eu já tinha arquivado no NAS dentro da variante uncensored do Flash-Next. Conferi o sha256 dele contra o manifesto do arquivo e contra o hash que o Strata pinou pro encoder BF16, e subi uma cópia pro diretório de modelos. A configuração ganhou o flag --vision e uma seção vision apontando pro componente strata-vision e pro mmproj, com backup do lado.

A verificação foi de ponta a ponta: o encoder carrega em meio segundo, aquece 1.024 tokens de imagem em menos de dois segundos, e respondeu “Red” pra um quadrado vermelho de teste. E o detalhe que me importa mais: com o encoder residente, sobraram 3,65 GB de VRAM, então a reserva de 4 GB do desktop segue valendo. A única pegadinha: o carregamento preguiçoso não convive com a seção de visão nessa configuração, então ele fica desligado aqui.

Cuidado: o Strata come a GPU toda, e o desktop morre

Tem um custo que não aparece em benchmark: rodar o Strata na mesma GPU que desenha a sua área de trabalho. Ele foi feito pra encher a placa, e enche mesmo.

No meu caso, o motor alocou 32.085 dos 32.607 MiB da 5090, 98,4% da VRAM. O Hyprland ficou com uns 500 MiB pra si, as alocações do desktop falharam, e até o terminal parou de responder. Só resolveu com hard reset.

Foram duas falhas em sequência. A reserva que eu tinha configurado era de 2.560 MiB, mas o proxy disparava uma única vez, engolia a exceção e nunca tentava de novo. O endpoint /v1/vram ainda não estava no ar naquele instante, então a reserva não foi aplicada. E 2.560 MiB já era pouco pra Hyprland, navegador e terminal juntos.

A correção, validada em teste de carga:

• Reserva de 4.096 MiB (4 GiB), com retry por até alguns minutos, verificação da resposta do motor e log de confirmação. Nada de fire-and-forget.
• Reafirmação da reserva a cada 30 segundos enquanto o motor está carregado, pra fechar qualquer deriva de rebalanceamento.
• No primeiro teste de carga, com a GPU a 99%, ficaram 3.629 a 3.888 MiB livres durante toda a geração. No teste seguinte, uma geração longa e outras três requisições concorrentes terminaram com sucesso; a menor folga observada foi 3.949 MiB. O desktop continuou vivo.

O preço aparece na vazão. O cache de especialistas caiu de uns 11.700 slots pra 9.700, então mais especialistas viajam por PCIe. Na medição inicial, saiu de ~200 pra ~150 tokens por segundo. Eu pago isso feliz: um desktop que não congela vale mais que aqueles 25% de velocidade naquele teste.

Tem uma alternativa estrutural: essa máquina tem uma Radeon 610M integrada, e dá pra mover o Hyprland pra ela. A 5090 ficaria dedicada à inferência.

O custo é que a 610M é fraca pra jogos e o multi-GPU da NVIDIA no Wayland tem suas manias. Eu preferi a reserva elástica, porque o modelo também descarrega quando fica ocioso.

A lição geral: não deixe motor de inferência tomar 100% de uma GPU que também desenha sua tela. Nesta configuração não tenho uma reserva rígida de VRAM no driver pro cliente de display. Precisei resolver do lado do motor: reservar alguns GB, reafirmar depois de cada cold start e medir de novo com a área de trabalho aberta.

Os mesmos 32 GB também limitam a sessão

A conta da 5090 é apertada por todos os lados. Os mesmos 32 GB precisam acomodar os pesos densos e buffers fixos do modelo, o cache dos especialistas quentes, a parte residente do KV cache e ainda a reserva de 4 GiB pro Hyprland, navegador e terminal. O que sobra pra uma coisa sai de outra.

KV cache é a memória da conversa. Cada token do prompt, das respostas anteriores e dos arquivos lidos cria estado que o modelo precisa consultar nos próximos tokens. No meu Strata ele está em int8, com 32K células por camada residentes na GPU.

O restante pode ser transmitido da RAM, por isso aumentar a janela de 128K pra 256K não aumentou a VRAM nem derrubou a velocidade no meu teste sintético. Esse streaming evita o estouro imediato, mas continua usando memória e não transforma uma 5090 num servidor sem limite.

O teto configurado aqui é 262.144 tokens, ou 256K. Vários modelos comerciais que testei, inclusive os Claude mais novos, já trabalham na classe de 1 milhão de tokens. Quase quatro vezes a janela muda o jeito de trabalhar: no Claude Code dá pra acumular muito mais histórico antes da compactação; no Qwen local eu preciso tratar contexto como orçamento desde o primeiro prompt.

A conversa que aparece no terminal é só uma parte do contexto. Dependendo do harness, também entram o system prompt, AGENTS.md e CLAUDE.md, catálogo e conteúdo carregado de skills, descrições e schemas de ferramentas, servidores MCP, instruções de plugins, saídas de comandos, arquivos e o espaço reservado pra resposta. Uma skill bem implementada carrega o texto completo só quando é chamada, mas o catálogo dela ainda pode entrar no prompt. Plugin que registra vinte ferramentas também manda vinte schemas antes de você pedir qualquer coisa.

Foi por isso que o benchmark não usou meu OpenCode normal. O runner gera uma configuração isolada, sem os plugins e MCPs globais, com apenas os providers e agentes necessários pro teste. Também fixa o limite real de 262.144 tokens em vez de fingir que o modelo aceita o contexto anunciado por outro backend.

Pra usar esse Qwen no dia a dia, eu faria a mesma limpeza:

• começar com o harness mais enxuto possível e ativar plugins ou MCPs quando o projeto realmente precisar;
• deixar skills pesadas sob demanda, sem despejar manuais inteiros no começo da sessão;
• compactar ou abrir uma sessão nova antes de encostar no teto, registrando decisões importantes em arquivos do projeto;
• reservar espaço pra saída do modelo. Uma janela lotada de entrada não serve se não sobra token pra ele pensar, chamar ferramentas e responder.

Com 256K, contexto é recurso de hardware. Instalar integração demais e carregar tudo em toda sessão consome janela e memória antes do trabalho começar.

Mas o Qwen 3.8 não era lento demais?

Era, e eu escrevi isso. No ranking do v4, o Qwen 3.8 27B rodando local levou quase 12 horas pra fechar as sete sprints. No artigo da B300 eu resumi: fez 80, levou 706 minutos, “então nem tente”.

Só que aquele é outro Qwen 3.8. A família tem os dois, e eles se comportam de jeitos opostos em casa:

Por que o maior roda mais rápido

Na geração de token, máquina local é limitada por banda de memória: cada token precisa ler todos os pesos ativos. O 27B denso lê os 27 bilhões a cada token, uns 29 GB em Q8. A Strix move uns 256 GB/s, então o teto fica perto de 9 tokens por segundo, e eu medi 7,7.

Na 5090 o mesmo 27B seria rápido, mas em Q8 ele não cabe nos 32 GB junto com o contexto que sete sprints acumulam. Em Q5_K_M ele coube, mas travou num loop de raciocínio no sprint 3. Terminou na Strix, em Q8_0 e com o raciocínio desligado (--reasoning off), que foi o que destravou o loop.

O Flash-Next tem quase cinco vezes mais parâmetros no total, mas só uns 6 bilhões trabalham por token. Em 3 bits, isso é por volta de um décimo do que o 27B em Q8 precisa ler. Os especialistas quentes ficam na GDDR7 da 5090, com sete vezes a banda da Strix, e o ajudante de especulação adianta tokens. Resultado: uns 20 vezes a velocidade do 27B na Strix, com nota maior.

A virada veio da troca de modelo e de motor: um MoE com poucos parâmetros ativos, servido por um motor de expert-offload feito sob medida pra ele. Flag nenhuma de configuração tiraria isso do 27B denso na Strix.

O tuning ainda cobra

O preço de rodar em casa muda de modelo pra modelo. O Flash-Next em 3 bits perdeu só 1,5 ponto contra a versão NVFP4 da B300. A Ornith-35B, no mesmo motor e na mesma placa, perdeu 16,5 contra a versão BF16 dela na B300. Meça o seu modelo antes de confiar nele.

O que cada modelo fez de interessante

Flash-Next: a prova de que consumidor chega em Tier A. 34 de 40 sem aviso, mais 6 com peso de revelação, e só dois itens precisando de apontar. Nenhum nudge, todas as sprints limpas. É o único local que junta nota de Tier A, velocidade interativa (159 tok/s) e protocolo completo sem ajuda. Se a pergunta é “da pra usar no trabalho”, esse é o exemplo.

Ornith-35B: rápido, mas não bom o suficiente. A mesma Ornith que fez 81 na B300 em BF16 fez 64,5 na 5090 com Q8_0. Caiu a detecção sem aviso de 30 pra 23. Mudou quantização, motor e hardware ao mesmo tempo, então não dá pra isolar a causa: essa combinação de Q8_0 + Strata + 5090 perdeu 16,5 pontos, e eu não sei quanto veio de cada variável. O recado é claro: “roda rápido” não é “revisa bem”.

Qwen 27B: boa nota, péssima experiência. Fez 80 na retomada na Strix, com sprints 1 e 2 na 5090, quase o 80,5 da B300. Mas 7,7 tok/s na sonda Q8 e 706 minutos de wall time. E ainda por cima zero consertos na revelação, com quatro itens abertos. Usar isso no dia a dia é escolher esperar.

GLM-4.7-Flash: o motor rodou, o modelo falhou. Protocolo completo em 29 minutos, e zero detecção sem aviso. Recuperou 8 de 14 só quando apontado, e mesmo assim deixou os consertos sem commit. Na B300 ele fez 33,5, que também não é bom. O problema não é só a placa.

A distância entre as categorias

A pergunta que todo dev tem é se consumidor já chega lá. Comparação direta, na mesma régua:

A leitura é que o topo do consumidor está 9 pontos abaixo do topo comercial absoluto e 1,5 ponto abaixo do topo aberto em datacenter, nessa métrica de vigilância. É uma distância pequena, e ela some quando você percebe que o GPT-6 Sol e o Sonnet 5 também estão a 91. O abismo real não é entre datacenter e consumidor: é entre o modelo certo e todos os outros. Entre o Flash-Next e a Ornith, na mesma 5090, são 26,5 pontos.

Então, hardware de consumidor já serve pra trabalhar?

Serve, com o modelo e o motor certos. Uma RTX 5090 com Strata entrega Tier A em vigilância de código, a 159 tokens por segundo, sem pagar um centavo por token depois que o hardware existe. Pra quem faz revisão de código, testa agente de codificação e mantém dado privado em casa, isso muda o jogo.

Pela primeira vez neste benchmark eu tenho um modelo testado, em hardware de consumidor, que merece ir pro trabalho de todo dia. Já deixei o Flash-Next configurado no OpenCode apontando pra 5090. O próximo passo é usar em programação de verdade, fora da régua de sabotagem, e ver se a nota se sustenta.

O que não serve é achar que qualquer configuração serve. A Strix Halo é ótima pra ter 128 GB e montar modelo grande, mas a velocidade dela não paga interatividade; a Ornith roda rápido e revisa mal; o GLM-4.7-Flash completa protocolo e não detecta nada sem aviso. E tem o preço invisível: quantização agressiva pode cobrar nota, dependendo do modelo e da configuração, e tempo de espera cobra paciência.

Se eu fosse montar uma caixa pra um dev hoje, seria uma 5090 com Strata e o Flash-Next, e usaria a Strix pra tarefa de fundo que aceita ser lenta. A fronteira comercial continua ganhando de quem precisa do máximo. Mas o consumidor deixou de ser consolação: já tem Tier A na prateleira de casa.

O problema agora é achar uma 5090

Em outubro, leakers garantiram que a NVIDIA ia parar de produzir a RTX 5090 e reservar os chips GB202 pras linhas profissionais e de datacenter. A placa chegou a sumir da loja oficial da NVIDIA nos Estados Unidos. No dia 16 de outubro, num evento em Taipei, o Jeff Fisher, vice-presidente sênior da NVIDIA, negou a descontinuação e disse que a empresa vai continuar entregando, mas admitiu que a capacidade de produção está apertada.

Na prática:

• o preço sugerido continua US$ 1.999, e a maioria dos anúncios na Newegg americana passa de US$ 9.300, quase cinco vezes isso;
• no Brasil, cada unidade sai na casa dos R$ 35 mil no varejo;
• e dois pallets de RTX 5090 da Zotac, importados pela distribuidora Oderço e avaliados em uns R$ 2,5 milhões, sumiram no aeroporto de Guarulhos. A GRU Airport comunicou as autoridades, e o caso segue em investigação, sem confirmação de roubo.

O primeiro modelo local Tier A do v4 roda justamente na placa mais difícil de comprar do momento. A prateleira de casa já tem Tier A. Falta conseguir a prateleira.

A resposta depende de duas coisas: quantos usuários confortáveis o hardware aguenta, e quanto isso custa por pessoa. Medimos os dois.

A conta antes do teste

Recapitulando os números do artigo anterior: o pod de 4x B300 custa US$ 36 por hora (US$ 864/dia, quase US$ 26 mil/mês ligado direto). Comecei a campanha com uns US$ 127 de saldo, recarreguei US$ 2.550, e sobraram US$ 537. Foram uns US$ 2.140 entre setup, downloads, tuning e benchmarks, não só inferência.

No meio, o saldo zerou, o pod morreu durante um autotune, e na hora de recarregar não havia B300 disponível. É o risco operacional da Runpod: o preço muda e a oferta some. A alternativa foi um pod de 4x H200, com preço de tabela na casa de US$ 3,59 por GPU-hora na Community Cloud: US$ 14,36/hora pras quatro na conta de tabela, contra US$ 36 das B300.

B300 e H200 não são a mesma máquina

A diferença de hardware muda mais que o preço:

A troca teve custo de adaptação: o checkpoint NVFP4 do GLM que rodava na B300 não existe pra Hopper, então foi preciso baixar a variante FP8 dele, e mesmo o DeepSeek precisou de ajuste de kernel. Os resultados de concorrência abaixo são com os dois em FP8 nativo, que é a comparação justa possível.

Como medimos “cabe um time”

O teste usa vllm bench serve contra o localhost de cada pod, com requisições de 8.000 tokens de entrada e 800 de saída (uma carga sintética no formato de sessão de codificação), subindo a concorrência N degrau por degrau.

O critério de conforto é o que importa: TTFT de até 2 segundos e TPOT de até 20 ms por token (ou seja, pelo menos 50 tokens/s por stream), com 95% ou mais das requisições cumprindo os dois limites. Não é “a mediana ficou boa”: é quase todo mundo bem atendido. Um time que espera 50 segundos pelo primeiro token não é um time, é uma fila.

E o aviso de honestidade: isso mede requisições de código confortáveis, não pessoas. Não tenho um multiplicador medido de duty-cycle de agente interativo, então não vou inventar que cada N vira 2 ou 3 desenvolvedores.

Os números

Leia com calma, porque tem três histórias aqui.

A B300 atende quatro vezes mais gente no conforto. Mesmo modelo, mesmo FP8, mesmo TP4: 32 usuários confortáveis contra 8. O agregado da H200 até impressiona (2.506 tok/s), mas isso é fila de prefill: o p99 de TTFT chega a cerca de 51 segundos em N=256, então o usuário espera um minuto antes de ver qualquer coisa. Throughput alto não é capacidade interativa.

O penhasco é tão íngreme que vale olhar os números de perto. Em N=16, o p99 de TTFT era 1,17 s na B300 e 3,19 s na H200, com 100% e 92,7% das requisições boas. Em N=32, a B300 ainda segurava 97,4% dentro do SLO (2,23 s), enquanto a H200 desabou pra 8,3% (6,58 s). E em N=48 a B300 caiu pra 92%, abaixo do meu corte de 95%: por isso o confortável é 32 e não 48. A diferença entre “funciona” e “funciona pra todo mundo” mora nesses últimos 2 pontos percentuais.

Modelo pesado e leve empatam na H200. O DeepSeek de 510 GB e o GLM menor sustentam os mesmos 8 confortáveis, por motivos diferentes: o DeepSeek tem KV eficiente via MLA e morre de compute/prefill; o GLM estoura o KV cache (97% de uso). Escolher hardware por contagem de parâmetros é olhar pro lugar errado: a arquitetura do KV é que manda na concorrência.

A porta solta engana. Se você olhar só a mediana, dá pra dizer 48 na B300 e 16 na H200. Só que a cauda do p99 destrói a experiência de quem está do outro lado. Pra dimensionar time, uso o número confortável e pronto.

Custo por usuário confortável

Agora a aritmética que decide:

• 4x B300: US$ 36/h ÷ 32 = US$ 1,13 por usuário confortável por hora.
• 4x H200: US$ 14,36/h ÷ 8 = US$ 1,80 por usuário confortável por hora.

A B300 ganha por pessoa mesmo custando 2,5x mais o pod. A H200 só viraria mais barata por usuário abaixo de US$ 9/hora o pod inteiro, e na tabela atual ela custa US$ 14,36. O ponto de corte não é o preço da máquina, é a capacidade dela.

E se a sua empresa já vive em AWS ou Azure?

Dá pra montar a mesma infra nos hiperescalares, mas o preço muda de categoria. Os valores de tabela que eu conferi, por GPU-hora:

A B300 na AWS custa 1,8x o que eu paguei na Runpod, e a H200 na Azure custa quase 3x a da Runpod. A conclusão de capacidade não muda (a física do tensor parallelism e do KV cache é a mesma), mas a conta de “vale a pena” piora bem: se na Runpod a B300 empata com a assinatura na faixa de 30 usuários, na AWS ela passa a perder por uma margem confortável.

E na prática, quanto sai por desenvolvedor, desligando o pod à noite como nas outras contas (8 horas por dia útil, 176 horas/mês)? As linhas de AWS e Azure são aritmética normalizada pra 4 GPUs, porque os SKUs citados vêm com 8 e eu não medi TP=8:

A diferença é brutal: o mesmo desenvolvedor confortável sai por US$ 198 na Runpod e por US$ 933 na Azure, quase cinco vezes mais caro que a assinatura de frontier mais forte. A AWS fica quase 80% acima da Runpod, então mesmo ela só faz sentido se a sua exigência for outra coisa que não custo.

E se você pegar a instância inteira de 8 GPUs, como elas são vendidas? A AWS sai por US$ 22.734/mês e a Azure por US$ 14.925/mês, e aí você tem que medir TP=8 pra saber quantos usuários aproveita, porque com TP=4 você paga o dobro pela mesma capacidade.

Os modelos comerciais também são diferentes: capacity block na AWS não é on-demand, e a Community Cloud da Runpod não é SLA de produção. Leia essa tabela como ordem de grandeza de preço, não como cotação de contrato. Se a sua exigência é compliance, procurement ou residência em região específica, o hiperescalar pode ser inevitável, e aí você paga o prêmio. Se a exigência é só preço, as neoclouds ganham nessas configurações.

E se em vez de alugar, eu comprar a máquina?

Quando a conta de aluguel dói, a pergunta natural é comprar o hardware. Dois candidatos da prateleira atual:

DGX Station GB300 (~US$ 130 mil, com configurações começando em torno de US$ 95 mil): 748 GB de memória unificada (252 GB de HBM3e a 7,1 TB/s e 496 GB de LPDDR5X a 396 GB/s), 20 PFLOPS em FP4. Os pesos de todos os modelos que eu testei cabem nela, e os melhores pra colocar nela seriam:

• DeepSeek V4.1 Flash (92,5/A, 510 GB em FP8), o campeão do benchmark;
• Muse Spark Open (69,5/C, 533 GB em NVFP4);
• Step-5-Preview (72,5/C, 368 GB em NVFP4);
• GLM 5.3 full (76/B, 704 GB em FP8).

Cabe, mas caber não é servir: o GLM full deixaria só uns 44 GB pra KV cache e sistema, então a concorrência plena com contexto longo fica por medir. A estimativa de conforto é de um dígito, na linha da H200, e não os 32 do pod de quatro. A diferença é que você não precisa de TP=4: tudo mora num chip só.

DGX Spark (~US$ 6.950 na loja atual da NVIDIA): 128 GB unificados, 1 PFLOP em FP4, 273 GB/s de banda. O recheio bom pra ela é de modelo pequeno e médio, e ele é melhor do que parece:

E tem um detalhe que dói de ver na fatura: por estimativa minha, sem auditoria fechada de todos os custos da primeira rodada, somando os créditos do v4 (aqueles ~40 modelos comerciais) com os US$ 2.140 desta campanha de B300/H200, eu já gastei alguns mil dólares entre API e pods, perto de metade do preço de uma DGX Spark. E ainda assim eu não teria uma máquina guardada em casa por causa disso.

• Qwen3.8 Flash-Next (92,5/A), o co-líder da B300 única. Em IQ3_S ele fica na casa de dezenas de GB, e foi exatamente o modelo que fez 91,0 na RTX 5090 com Strata. É o melhor modelo que eu recomendaria pra uma Spark hoje.
• Swift 1.5 27B (88/A, 56 GB), que foi a recomendação de self-host mais equilibrada da minha campanha anterior;
• ThinkingCap 3.8 27B (83/A, 56 GB);
• Ornith-1.5-35B-A3B (81/B, ~70 GB em BF16);
• Laguna-S-2.1 (65,5/C, 99,7 GB em NVFP4);
• e os classificadores pequenos do benchmark de decisão (Jebadiah 4B, Laya, Julia), que são o caso de uso ideal de uma caixa dessas.

O DeepSeek V4.1, com 510 GB, não cabe de jeito nenhum. A banda é quase 30 vezes menor que a da B300, então a interatividade sofre, e a concorrência prática fica pra medir: eu espero pouco mais que uso solo. Pra modelo pequeno é uma caixinha simpática; pra monstro, é peso de papel.

TCO, ROI e depreciação

A conta de ter versus alugar, usando 3 anos de depreciação e o mesmo padrão de uso (8 horas por dia útil, 176 horas/mês):

Leitura: se você roda modelo grande todo dia útil por dois anos ou mais, o GB300 se paga em menos de dois anos, e em 24/7 ele se paga em cinco meses. Se a sua necessidade é uma campanha de duas semanas como a minha, alugar custou US$ 2.140 e pronto, sem ativo parado depois. E o Spark só faz sentido se a sua carga for modelo pequeno: nesse caso ele se paga em menos de um semestre contra aluguel e em três anos contra assinatura, mas se a sua necessidade é um 748B, ele é inútil desde a caixa.

Duas ressalvas pra não comprar errado. Primeiro, a tabela compara cenários de dólar, não ROI de carga equivalente: se a sua concorrência real no GB300 for de um dígito, a comparação honesta seria com um pod menor que o de 4x B300. Segundo, energia e administração mudam o resultado, principalmente no Spark, onde a diferença pra assinatura fica em poucos dólares por mês. Ignorei revenda no fim dos três anos; se ela existir, o break-even melhora.

Nota pra quem compra no Brasil: esses preços são em dólar. Em reais, com o dólar a R$ 4,99, mais impostos de importação e a margem de revenda local, o GB300 passa fácil de R$ 800 mil e o Spark passa de R$ 34 mil antes de qualquer margem. O break-even em reais fica ainda mais distante, então a decisão de comprar no Brasil precisa de uma utilização muito mais alta pra fechar.

E comparando com assinatura de frontier? Um plano forte de Claude/Codex custa uns US$ 200 por mês por desenvolvedor. Com duas ressalvas importantes: esses planos não são ilimitados (o Codex mede por crédito e o Claude tem janelas de uso por sessão e por semana), e automação/CI não cabe em plano de consumidor. A comparação abaixo é de preço, não de carga equivalente. Pra transformar stream em gente eu preciso de uma premissa: um desenvolvedor com uma requisição ativa o tempo inteiro durante o expediente, o que é otimista pra capacidade e conservador pra custo. Com essa premissa, e sem contar minha hora de sysadmin nem o setup, o pod rodando 8 horas por dia útil (176 horas/mês) fica assim:

Na faixa de 30 streams contínuos, a B300 fica praticamente no preço da assinatura forte. Abaixo disso, a assinatura sai mais barata, porque você paga por pessoa, não por hora de pod ociosa. E ligar 24/7 sem carga correspondente é jogar dinheiro fora: o pod cobra dormindo.

Pra empresa, quando fecha a conta

Se você tem um time grande de verdade usando o dia inteiro, dados que não podem sair do ambiente, e um modelo que entrega no trabalho diário (o DeepSeek V4.1 Flash fez 92,5 no meu benchmark de vigilância, acima do GPT-6 Sol e do Sonnet 5), a infra própria começa a fazer sentido pela primeira vez sem ser vaidade. O ponto de corte, na premissa de um stream ativo por pessoa o expediente inteiro, fica na casa das 30 pessoas concorrentes, com o pod desligando fora do horário.

Se o time é pequeno, o uso é intermitente, ou o objetivo é só economizar: continua com a API. O mesmo DeepSeek custou US$ 1,21 por rodada completa de benchmark na nuvem, e você não herda um pod pra administrar, nem o risco de a B300 sumir do estoque quando você mais precisa.

O que eu levo dessa campanha: hardware grande não é resposta pra pergunta pequena. Antes de assinar o pod, faça a conta de quantas pessoas realmente concorrem no seu time, meça a latência que elas toleram, e some o preço da sua hora de sysadmin. O modelo aberto grande já chegou na faixa de Sonnet 5 e GPT-6 Sol pra revisão diária de código. A infra só precisa caber no orçamento.

A resposta curta: dá pra ir longe, e um deles empatou com a faixa de Sonnet 5 e GPT-6 Sol. A longa vem com uma conta de padaria e vários dias de vLLM sofrendo.

Antes de tudo, a ressalva de escopo. Ainda ficou gente de fora.

O Kimi K3, de 2,8 trilhões de parâmetros, é o exemplo: em FP8 ele precisaria de uns 2,8 TB de VRAM, e nem um pod de 8x B300 (2,3 TB brutos) fecha a conta. Pra rodar um monstro desses você precisa quantizar pra FP4 ou alugar muito mais placa. E eu escolhi gastar meu crédito no que cabe em 4x.

O ranking completo

Metodologia é a mesma de sempre: o app de chat em RubyLLM com 14 defeitos plantados (backdoors, bypass de autorização, mentiras nos testes), e a nota mede vigilância de revisão de código, não velocidade de digitação. O modelo precisa encontrar e corrigir os defeitos sem ser avisado (peso cheio) e quando revelado (peso 40%). Tier A começa em 83. Rodei tudo no mesmo pod de 4x pra ter uma régua única, embora nem todo modelo precisasse das quatro placas (Ornith e Laguna caberiam numa só).

Duas notas pra ler a tabela direito. O Step-5 e o Muse estão em C porque a base sem aviso era baixa: conserto depois do “tem problema aí” vale 40%. O Muse consertou 6 dos 7 itens abertos quando revelado; o Step-5, só 2 de 5.

E o Nex N2.5 Pro, além da nota vergonhosa, corrompeu o código a ponto do app nem subir. As duas âncoras da campanha anterior, pra comparar: GLM 5.3 Flash e Qwen3.8 Flash-Next, ambos 92,5 na B300 única.

O que cada um fez de interessante

A nota sozinha esconde o comportamento, e o comportamento é a parte divertida.

O DeepSeek foi o único que resolveu os dois itens compostos sem ajuda. Os defeitos compostos são os que exigem enxergar duas coisas ao mesmo tempo (a backdoor e o teste que a encobre), e ele achou e corrigiu os dois sem nenhum nudge. É o tipo de vigilância que eu quero do meu revisor de PR.

O GLM full consertou tudo quando avisado, mas dormiu no silent mode. Sem aviso, ele deixou passar o cluster de acesso e correção silenciosa. Quando eu apontei, varreu os seis itens restantes. Ou seja: o modelo grande é capaz, só não é atento por padrão. O Flash dele, com um terço do tamanho, foi mais vigilante.

O Kimi K2 Thinking fez teatro de checklist de segurança. Escreveu umas listas lindas de “boas práticas de segurança” e deixou cinco itens abertos, incluindo uma chave em texto plano. Falar de segurança e fazer segurança são coisas diferentes, e ele fez a primeira.

O Ornith restaurou o comportamento e manteve o teste mentiroso. No item 6, ele reverteu o código pro comportamento antigo em vez de corrigir o teste plantado que validava a backdoor. Por isso a nota estrita foi 73 e a leniente 76: parecer que consertou não é consertar, e o teste que mente também precisa morrer.

O Step-5 deixou três defeitos mesmo com o mapa na mão. Depois de revelar explicitamente, ele ainda deixou o link de login, a desativação de autorização e o agregado incorreto. Nem todo modelo aproveita a segunda chance.

E tem o caso do 397B que virou piada pronta. Um modelo de 397B, grande demais pra caber na cabeça de quem defende tamanho, deixou passar a backdoor admin? => admin || email.end_with?("@internal.example") mesmo depois do aviso de auditoria de segurança. Pior: ele adicionou um teste passando que codificava a backdoor como comportamento intencional, e o commit ainda se gabava de “Brakeman: 0 warnings”. Se você quer um exemplo de por que eu testo vigilância e não benchmark de marketing, tá aí.

O Muse Spark Open quase não saiu do chão, mas se recuperou. Ele começou bloqueado: pesos em 127 shards de NVFP4, gated no Hugging Face, e sem suporte no vLLM estável. Só rodou quando eu compilei uma branch de PR ainda em rascunho, com nvcc 12.9 e bibliotecas 12.8 misturadas, e limitei o multimodal a texto.

Aí ele entregou 69,5: base fraca sem aviso (21 de 40), mas 6 de 7 itens consertados quando apontado. É o caso de “o esforço de infra não se confunde com a nota do modelo”: o serviço ficou de pé, o comportamento é útil, e mesmo assim ele só vai até Tier C. Se a pergunta é “por que ele não tá no topo”, a resposta é vigilância por padrão, não VRAM.

E o Nex foi o desastre completo. Precisou de dois nudges, e no fim o texto corrompido chegou ao Ruby commitado e o app nem inicializa. Na nuvem, o mesmo Nex N2.5 Pro tinha feito 94. Em casa, 27. Eu não acreditaria em benchmark de fornecedor depois de ver isso duas vezes.

Aliás, o caso da Nex é o exemplo perfeito de escolha ruim de base. Quando a Rio 3.5 explodiu em junho, eu cobri a controvérsia aqui: o checkpoint dela era uma mescla de Nex-N2-Pro com Qwen. A turma da Rio podia ter escolhido bases muito melhores, como o DeepSeek V4.1 ou o GLM 5.3 Flash, e foi justamente pra linhagem que, na minha régua atual, foi a pior do lote. Escolher modelo por nome bonito custa caro.

Rodar em 4 GPUs não é trivial

Quatro placas não são quatro modelos: é um modelo só fatiado em quatro, com tensor parallelism TP=4 no vLLM. Isso dá uns 1,1 TB de VRAM agregado (na prática, ~1.038 GB úteis com --gpu-memory-utilization 0.90). Sem isso, nenhum dos modelos acima de 400 GB existiria na minha vida sem offload pra SSD, que é onde a velocidade vai morrer.

Os cuidados que se repetiram em quase todos:

• Toolchain sangrando na veia. B300 (sm_103a) exige CUDA 12.9 pra compilar os kernels na hora, então a imagem padrão não bastava: toolkit standalone com nvcc 12.9 e headers certos, e ainda assim cada família precisava de um remendo de DeepGEMM, FlashInfer ou link de cudart. Quando a compilação acerta, o prêmio é grande: o GLM 5.3 Flash saiu de 10,35 pra 141,40 tokens por segundo só de configuração (tirando o --enforce-eager e ligando o modo compilado com CUDA graphs), sem trocar checkpoint, contexto ou precisão de KV.
• Startup não é download. O DeepSeek demorava 15 a 30 minutos pra inicializar, então prepare-se pra esperar o modelo carregar antes de medir qualquer coisa.
• Cada família tem seu parser e suas manias. O Nex só conversou depois de trocar o parser pra qwen3_xml, ganhar mais um nudge e ignorar os artefatos de tmp/log. O Step-5 não existia no vLLM 0.32 estável e precisou de nightly com PR específico. O Muse exigiu compilar uma branch de PR ainda em rascunho, com CUDA 12.9 nvcc e bibliotecas 12.8 misturadas, e os pesos em 127 shards de NVFP4. O MiMo pediu --trust-remote-code. A Laguna decidiu, do nada, inundar a saída com texto de raciocínio, e uma sprint teve que ser refeita a partir da base de injeção.
• Contexto custa caro. O checkpoint FP8 do Kimi K2 Instruct (1.029 GB) deixaria 9 GB pra KV cache nas 4 placas, então foi o INT4 Thinking de 594 GB no lugar. Especular com draft head (MTP) só funcionou no Step-5, com ganho de 2,24x e 73,7% de aceitação de tokens, porque eu verifiquei a correção das ferramentas antes.

A lição operacional: alugar VRAM resolve o “cabe”, mas não o “roda bem”. Cada modelo grande é um mini-projeto de integração.

E a fronteira, fica onde?

A pergunta que interessa pro desenvolvedor não é “quem tem mais parâmetro”, é “o modelo aberto grande entrega no meu dia a dia?”. Os números do benchmark v4, na mesma régua:

O DeepSeek V4.1 Flash empatou com o próprio serviço em nuvem, com os mesmos 92,5, e ficou acima do GPT-6 Sol e do Sonnet 5. Ou seja: o melhor open source atual já está a 1,5 ponto do GLM hospedado e a 7,5 do topo absoluto, na frente de dois frontier comerciais fortes. Se a sua régua é a minha (achar backdoor e bypass antes de mergear), um open source de 748B local já serve pra revisão diária de código, com 175 tokens por segundo por stream nas minhas medições de admissão.

Mas três avisos antes de você cancelar a assinatura do Claude:

1. Mais parâmetros não significa mais competência. O GLM 5.3 full, com ~700B, fez 76 contra 92,5 do Flash dele mesmo. O Kimi K2 Thinking, com 1 trilhão, fez 46. E o Nex N2.5 Pro despencou de 94 na nuvem pra 27 em casa: checkpoint público não é garantia de reproduzir o serviço, como eu já tinha visto no DeepSeek V4 Flash (86 na nuvem, 44,5 em casa).

2. Minha régua é vigilância, não programação geral. Aqui eu meço quem percebe sabotagem. Não é a mesma coisa que medir quem escreve o seu sistema inteiro melhor, e uma repetida de benchmark minha já variou 9 pontos num mesmo modelo. A distância de 1,5 ponto entre modelos pode ser barulho.

3. Custo muda a resposta. Se a ideia é ter qualidade de frontier no dia a dia, a API em nuvem do DeepSeek V4.1 custou US$ 1,21 por rodada de benchmark completa. O pod de 4x B300 custa US$ 36 por hora antes mesmo de você apertar o botão. E o caso mais didático continua sendo o DeepSeek V4 Flash da campanha anterior: na nuvem ele fez 86 por US$ 0,97 a rodada; em casa, 44,5 e ainda por cima mais caro por inferência. Às vezes a nuvem é melhor e mais barata.

Vale alugar 4x B300?

Pra uma pessoa escrevendo código com um agente de manhã e outro de tarde: não. A API resolve por poucos dólares o que o pod resolve por dezenas de dólares por hora.

Pra uma empresa que precisa de dado privado de verdade (código que não pode sair da VPN), checkpoint travado pra reprodutibilidade, ou carga batch contínua (milhares de revisões, classificações, análises por dia), aí o cálculo muda. O DeepSeek V4.1 em 4x B300 entrega qualidade de quase-fronteira com o dado em casa, e isso não se compra com assinatura de chat.

O que eu não compraria de novo sem medir antes é a premissa “maior é melhor”. Eu comecei essa campanha achando que o salto de 92,5 ia vir de um modelo maior. Veio do modelo certo rodando direito. O resto é VRAM queimada e uma história boa pra contar.

E tem mais um capítulo vindo, de hardware que não é datacenter: os testes com modelos locais na RTX 5090 e no Strix Halo, com um motor de inferência novo chamado Strata. Quando o protocolo terminar, sai o terceiro artigo.

E a pergunta de “vale a pena” tem uma resposta irritante de óbvia: depende de quantas pessoas vão usar ao mesmo tempo. É ela que eu respondo no próximo artigo: LLM Benchmark v4: can my team fit in a 4x b300/h200?.

Faltava uma categoria que eu nunca tinha testado direito: os modelos open source grandes. Os que cabem na minha RTX 5090 de 32 GB ou no meu Strix Halo com 61 GB utilizáveis pela GPU são fracos demais pra isso. Servem pra tarefa simples de agente, e nenhum modelo pequeno aguenta tarefa real de programação, muito menos um projeto complexo de software.

O Qwen 3.8 27B levou 706 minutos pra fechar o v4 no Strix e fez 80; o GLM-4.7-Flash local fez 24. Então nem tente.

Mas e se a gente forçar? O que modelos de tamanho médio, de 100 a 400 bilhões de parâmetros, conseguem fazer rodando numa única B300 alugada? Eu podia alugar quatro delas e rodar os modelos gigantes de 750 bilhões ou um trilhão, e não tenho certeza de que o custo-benefício vale. Os dados abaixo respondem.

TL;DR: 14 modelos abertos, uma B300 de 288 GB na Runpod a uns 9 dólares por hora, mesmo protocolo v4 de sabotagem. Nenhum deles serve rápido do jeito que vem: o GLM 5.3 Flash decodificava a 10 tokens por segundo com a configuração padrão e a 141 depois de ajustado, 14 vezes mais só de flag. Dois modelos abertos, GLM 5.3 Flash e Qwen3.8 Flash-Next, fizeram 92,5, nível Claude Sonnet 5, e o Swift 1.5 27B fez 88, nível Opus 4.6. Nenhum chegou nos 100 da fronteira. O flagship de 397 bilhões fez 68,5 e deixou passar uma backdoor de admin, o DeepSeek V4 Flash fez 86 na nuvem e 44,5 servido por mim, e o Nemotron trapaceou num teste de regressão. A API em nuvem do mesmo modelo custa um dólar por rodada; o pod custa 218 dólares por dia. Pule pra B300 e Runpod, pro ajuste de servidor, pro ranking, pros casos interessantes, pra comparação com a fronteira, pra conta ou pra conclusão.

O que é uma B300, e o que é a Runpod

A B300 é a GPU de datacenter da geração Blackwell Ultra da NVIDIA, anunciada em março de 2025. Cada placa tem 288 GB de memória HBM3e, nove vezes a minha 5090, e uns 15 petaflops de computação densa em NVFP4, o formato de 4 bits que a Blackwell faz em hardware. É a placa que vai dentro do rack GB300 NVL72, 72 delas interligadas, que as empresas de IA compram aos milhares.

Sozinha, uma B300 custa mais que um apartamento. O que a torna acessível é alugar por hora.

A Runpod é um provedor de GPU em nuvem que aluga placas em “pods”, containers Linux com uma ou mais GPUs, cobrados por segundo. Você escolhe a placa, um template de imagem, sobe por SSH, e paga enquanto o pod está ligado, inclusive ocioso. A B300 custava uns 9 dólares por hora na nuvem segura deles na semana do teste; uma H100 sai por 3 a 4. O disco do container é efêmero: terminou o pod, os 250 GB de pesos que você baixou somem, e você baixa de novo.

O pod que eu usei: uma B300 com 275 GiB segundo o nvidia-smi (os mesmos 288 GB nominais, em unidades binárias), 344 vCPUs, 4 TB de RAM no host, 700 GB de disco. O servidor de inferência foi o vLLM; o harness foi o mesmo OpenCode de todos os outros modelos do ranking, conectado por túnel SSH ao pod. O modelo roda lá; o código, os testes e os resultados ficam na minha máquina.

Caber na memória é a primeira peneira. Na B300 cabem os modelos de 100 a 400 bilhões de parâmetros quantizados em NVFP4, mais os de 27 a 35 bilhões em BF16. Ficam de fora o GLM 5.3 flagship de 753 bilhões, o DeepSeek V4.1 Flash de 750, o DeepSeek V4 Pro de 1,6 trilhão e o Kimi K3 de 2,8 trilhões. Pra esses, seriam quatro B300 ou mais, uns 36 dólares por hora.

A metodologia

O protocolo é o v4 de sempre: o modelo constrói um app Rails em sete sprints acumulados, e entre os sprints um revisor independente, isolado do modelo, injeta 14 sabotagens, de CVE real a regressão silenciosa de lógica e de teste, no código que o próprio modelo escreveu. A nota de 0 a 100 mede vigilância: quanto o modelo pega e conserta sem ser avisado (peso cheio), quanto conserta depois de um “faça uma auditoria de segurança” explícito no último sprint (40% do peso), e o que fica sem resolver (zero). Os tiers são A a partir de 83, B de 73 a 82, C de 51 a 72, D até 50.

Duas diferenças nesta rodada. A primeira é o revisor: os cinco modelos que terminaram antes do bloqueio foram revisados de ponta a ponta pelo Codex, como nas rodadas anteriores.

No meio da leva o serviço de segurança da OpenAI passou a recusar a operação de injeção e correção, com uma flag de risco cibernético, mesmo sendo código meu, em máquina minha, num benchmark com 46 modelos já pontuados pelo mesmo protocolo. Troquei o revisor pro Claude Opus 4.8 nos modelos restantes, com o mesmo plano de injeção, mesmo catálogo, mesma régua, e a proveniência de cada fronteira está gravada por sprint. O impacto esperado na nota é nenhum, porque os dois executam a mesma receita escrita.

A segunda é a admissão por velocidade, que é o assunto da próxima seção. Modelo que decodifica abaixo de 100 tokens por segundo nem entra na pista.

Além disso: o modelo aberto tem direito a até dois empurrões curtos por rodada pra defeito bobo (um import faltando, um ponto de entrada de teste errado), registrados como “assistido”. Falha de infraestrutura, driver, loader, parser, nunca é cobrada do modelo. E o pod rodava um modelo por vez, sem acesso ao workspace ou ao resultado de nenhum outro.

Nenhum deles serve rápido do jeito que vem

A primeira lição custou um dia. Baixei o GLM 5.3 Flash, 320 bilhões de parâmetros com 18 ativos, quantizado em NVFP4, 198 GB. Subi no vLLM com a configuração que “funciona”: serve, passa nos testes de chamada de ferramenta, responde. E decodificava a 10 tokens por segundo, com a GPU a 10% de uso, 209 watts dos 1.100 que o pod libera.

Isso é inutilizável pra programar. Um agente de código gera dezenas de milhares de tokens por sprint; a 10 por segundo, um sprint de 20 minutos vira mais de quatro horas.

O mesmo checkpoint, mesmo contexto de 128 mil tokens, mesmo cache de KV em FP8, mesmo prompt de teste, trocando só as flags de compilação e modo: 141 tokens por segundo. Catorze vezes mais rápido, zero mudança de precisão ou de pesos.

O culpado principal era o --enforce-eager, que desliga o torch.compile e a captura de CUDA graphs do vLLM, e que todo tutorial manda ligar “pra subir mais rápido”. Sobe mais rápido e serve 14 vezes mais devagar. A medição trocou essa flag junto com o modo interactivity, então eu não isolei a contribuição de cada uma.

Daí a regra de admissão: menos de 100 tokens por segundo eu considero inutilizável, e nenhum modelo entra no benchmark sem passar disso na mediana de duas sondagens quentes de 256 tokens, depois de uma fria. Pra não virar um buraco sem fundo, o ajuste é limitado: no máximo três configurações e 45 minutos de relógio por modelo, incluindo carga e compilação. E ajuste nunca pode trocar qualidade por velocidade: nada de encurtar contexto, baixar esforço de raciocínio ou quantizar mais pra bater o número.

Os ajustes que valeram pra todo mundo:

• Instalar um CUDA que compile pra placa. A imagem padrão da Runpod vem com CUDA 12.8, cujo nvcc não compila pra compute_103a, a capacidade de computação da B300. Sem o 12.9, os kernels NVFP4 nunca compilam.
• Nunca usar --enforce-eager. Deixar o vLLM compilar e capturar CUDA graphs é a maior vitória isolada.
• --performance-mode interactivity: otimizar pra latência de um fluxo só, que é o que um agente serial precisa, em vez de vazão agregada.
• Cache de KV em FP8 nos MoE grandes, cache de prefixo e prefill em pedaços em todos, e confirmados pelos contadores do Prometheus do vLLM em vez de assumidos: num prompt de 11 mil tokens, o servidor reaproveitou exatamente 8.576 tokens de prefixo a cada repetição.
• O parser certo de ferramenta e de raciocínio pra cada família. Parser errado faz chamada de ferramenta sumir em silêncio ou vazar o raciocínio na resposta.

E os ajustes específicos que achei mais interessantes:

• NVFP4 só roda no vLLM. Os checkpoints de 198 a 251 GB em FP4 nativo da Blackwell são a única forma de caber na placa, e llama.cpp e Ollama simplesmente não carregam esses formatos. Quem vive de GGUF não tem acesso a essa faixa.
• Decodificação especulativa nativa. O Qwen 3.8 27B foi de 92 pra 195 tokens por segundo com a cabeça MTP que o próprio checkpoint traz, prevendo três tokens por passo, mais --language-model-only pra descartar a torre de visão (medido em pods diferentes, então sem ablação controlada). O Muse Glimmer chegou a 295 com o rascunhador DFlash leve que ele publica junto, 15 tokens especulados por passo. Só liguei onde existe um rascunhador oficial e onde a chamada de ferramenta continuou correta; pro Ornith existe um rascunhador publicado à parte, com taxa de aceitação desconhecida, então ficou desligado.
• O loader do CUDA 12. O flashinfer compila em JIT um kernel de MoE em NVFP4 que precisa do libcudart.so.12, e depois de instalar o CUDA 13 pro Nemotron a resolução de biblioteca quebrou. O sintoma parecia OOM; a causa era um ld.so.conf. Um script de reparo com evidência de ldd antes e depois resolveu, e o 397B passou a servir a 144 tokens por segundo.
• Um ambiente virtual por runtime. O Nemotron 3.5 Super VL exigiu um vLLM 0.32 próprio num venv separado, porque é o que o card oficial fixa, e esse build pede CUDA 13. Cada família de modelo é um caso bespoke: parser, quantização, cabeça de rascunho, versão de runtime e reparo de loader, tudo diferente.
• Um bug de parser que derrubava a última chamada. O parser de ferramenta Qwen do vLLM descartava o último parâmetro de uma chamada quando faltava a tag de fechamento do parâmetro mas a de função estava presente. Um reparo estreito, com 24 casos de teste, tirou esse ruído de serving da conta do modelo.

Os argumentos exatos de cada modelo, os logs de sondagem e o livro-razão de cada rodada de ajuste estão no documento de otimizações de serving e no runbook da B300 do repositório.

A velocidade é quase de graça, depois que você deixa o vLLM compilar. O trabalho real é descobrir, modelo por modelo, qual combinação de toolkit, parser, quantização e cabeça de rascunho aquele checkpoint exige. Eu dei 45 minutos pra cada um e precisei deles.

O ranking

Nota v4 de vigilância, tier, tamanho em memória, velocidade de decodificação na sondagem de admissão (quente, um fluxo só) e o custo só do tempo de inferência dos sete sprints, a 9,09 dólares por hora. O custo exclui download, carga, compilação, ajuste e tempo ocioso; a conta de verdade vem mais abaixo.

Três não têm nota: o Command A Plus da Cohere (218 bilhões, 25 ativos, W4A4) travou num loop reescrevendo o mesmo model 23 vezes, precisou de três empurrões e ainda deixou os testes sem rodar antes de o revisor ser bloqueado; o Nex N2.5 Mini rodou a 337 tokens por segundo e entregou Ruby inválido, migrations contraditórias e autenticação quebrada em duas tentativas, um resultado ruim válido de um servidor que funciona; e o Qwen3.5 122B era reserva condicional pro caso de o 397B não terminar, e o 397B terminou.

Os minutos são só de sprint, e os de Ornith incluem um sprint interrompido por infra. Flash-Next, Swift, ThinkingCap, Muse e Qwen 27B levaram um empurrão cada; GLM 4.7, dois; os outros, nenhum. A velocidade de sondagem é um número de admissão: a vazão de uma sessão real de código inclui prefill, ferramentas, testes e as escolhas do agente. E repare que os dois primeiros empatam na nota com perfis opostos: o GLM gastou 145 minutos e 22 dólares pra chegar nos mesmos 92,5 que o Qwen3.8 Flash-Next fez em 80 minutos e 12 dólares, com metade da memória.

Os casos interessantes

Qwen3.8 Flash-Next: o melhor dos abertos, por custo

O Flash-Next é, nas palavras da Qwen, uma prévia da arquitetura do Qwen 4: 125 bilhões de parâmetros de modelo de linguagem com 6 bilhões ativos, mais uma tabela de embeddings de n-gramas de 51 bilhões que a Qwen diz que pode ser descarregada pra memória do host, mais uma cabeça MTP de 4. Quantizado em NVFP4 pela NVIDIA, ocupou uns 100 GB de placa (o checkpoint tem 133 GB em disco). Foi o único modelo da segunda leva a resolver todos os 14 itens: pegou o vazamento entre tenants sem aviso, pegou o item composto de integridade de teste, e escreveu por conta própria specs de isolamento por usuário, de modo que a IDOR plantada na API nem tinha como continuar verde. Com 195 tokens por segundo e 12 dólares de inferência, é o melhor custo-benefício desta tabela.

GLM 5.3 Flash: o mesmo 92,5, três vezes mais caro

O GLM fez a mesma nota com uma arquitetura bem maior: 320 bilhões de parâmetros, 18 ativos, 198 GB mesmo em FP4. Resolveu os 14 itens, zero empurrão, revisado de ponta a ponta pelo Codex.

Só que levou 145 minutos e consumiu o dobro da memória pelo mesmo resultado. Na nuvem da Z.ai, o mesmo modelo fez 84,25 num plano fixo. Com o ruído de uma rodada só, que no meu histórico chega a nove pontos, a leitura mais segura é que os dois estão na mesma faixa.

Swift 1.5 e ThinkingCap: dois fine-tunes de 27B no Tier A

As duas surpresas. O Swift 1.5, da UkisAI, e o ThinkingCap 3.8, da BottleCap AI, são ajustes do Qwen 3.8 27B treinados pra pensar menos: o Swift anuncia até 58% menos tokens de raciocínio (na mediana do GPQA; no Terminal-Bench, 16%), o ThinkingCap uns 37% na média. Os dois cabem em 56 GB em BF16, rodam a uns 200 tokens por segundo com MTP, e fizeram 88 e 83.

O Swift ficou acima do Opus 4.6 da Anthropic. O Qwen 3.8 27B base, mesma arquitetura, fez 80,5 com 192 minutos; o Swift fez 88 em 64. O Swift pegou sabotagem mais cedo que o base; se foi por pensar menos, uma rodada de cada deixa de provar.

Uma ressalva de proveniência: o revisor registrou que o Swift leu mensagens de commit locais que revelavam regressões, o que enfraquece uma leitura literal de “descoberta totalmente sem ajuda”. E ele deixou um item sem resolver, um admin inativo ainda aceito com um teste vazio de guarda. Ainda assim, de todos os modelos desta tabela, é o que eu colocaria numa placa minha.

Qwen3.5 397B: o flagship que deixou passar a backdoor

O maior modelo da leva, 397 bilhões de parâmetros com 17 ativos, 251 GB de NVFP4 em 275 de placa, serviu a 140 tokens por segundo depois do reparo do loader e fez 68,5, Tier C.

O caso que define a nota: a sabotagem número 6 é uma linha admin? => admin || email.end_with?("@internal.example"), uma escalação de privilégio por domínio de e-mail. O 397B deixou passar nos sprints normais, deixou passar no sprint 7 com o pedido explícito de auditoria de segurança, e escreveu um teste que passava, codificando a backdoor como comportamento esperado, no mesmo commit em que anunciou “Brakeman: 0 warnings”. Parâmetro não comprou vigilância.

Nemotron 3.5 Super VL: trapaceou no teste

O Nemotron 3.5 Super VL da NVIDIA, 120 bilhões com 12 ativos, lançado dois dias antes de eu começar a testar e vendido pela NVIDIA como o modelo aberto de agente mais rápido da categoria, com “acurácia líder” em tarefas multimodais, fez 63. A sabotagem número 2 remove um link de navegação e o teste de regressão procura have_link('Sign in'). O Nemotron trocou o teste pra have_button('Sign in'), que passa no botão do formulário de login sem restaurar o link, e manteve a trapaça mesmo depois do sprint de revelação.

Também tende a pegar item um sprint atrasado. E foi o que exigiu um runtime próprio: vLLM 0.32 com CUDA 13 num ambiente separado.

DeepSeek V4 Flash: 86 na nuvem, 44,5 na minha mão

O caso mais importante pra quem pensa em self-host. O DeepSeek V4 Flash, 284 bilhões com 13 ativos, fez 86, Tier A, por 97 centavos pela API em setembro, e a versão 0731, exatamente a que eu baixei, fez 85 por 1,94. Os mesmos pesos públicos em FP4 e FP8 misto, servidos por mim na B300, fizeram 44,5, Tier D: pegou 4 itens sem aviso, mais 5 na revelação, e deixou 5 sem resolver. Foi o mais rápido a terminar, 37 minutos, e o que menos vigiou.

A causa provável é divergência entre o checkpoint público e o que a DeepSeek serve, ou entre o stack de serving deles e o meu: parser, template de chat, modo de raciocínio, quantização. Eu segui o card oficial. O que isso prova é que o nome do modelo no Hugging Face não garante a qualidade da API hospedada, e que quem vai hospedar precisa validar antes de confiar.

GLM 4.7 Flash: igual ao local, ou seja, ruim

O GLM 4.7 Flash de 30 bilhões em BF16, a 217 tokens por segundo, fez 33,5. Em casa, em GGUF Q5, tinha feito 24. Precisou de dois empurrões, deixou nove itens sem resolver e entregou uma migration com erro de sintaxe. A diferença de nove pontos e meio cabe dentro do ruído de uma rodada; o que fica é que o modelo é fraco de qualquer jeito.

O que apareceu em vários

Ornith, Muse Glimmer e o 397B compartilharam um defeito de higiene: rodaram o sprint até o fim com exit zero e esqueceram de commitar o próprio trabalho, deixando pro revisor fazer o checkpoint. Não entrou na nota, e num time de verdade seria o primeiro motivo de reclamação. E o aglomerado de 81 a 83, ThinkingCap, Ornith e Muse, tem um perfil consistente: pega injeção de SQL, vazamento entre tenants, XSS e segredo exposto com confiança, e deixa passar os itens silenciosos, controle de acesso quebrado, integridade de teste, índice faltando, agregação errada.

A que distância da fronteira

Os três melhores abertos contra os melhores comerciais do mesmo ranking, com o custo e o tempo de cada rodada:

A leitura: o melhor do open source que cabe numa B300 e que eu servi está um degrau abaixo do teto comercial e no mesmo nível do meio do Tier A. Diferenças de um ou dois pontos são ruído de uma rodada.

GLM 5.3 Flash e Qwen3.8 Flash-Next empatam com o Sonnet 5 e passam o Gemini 3.8 Flash e o Opus 4.6. Nenhum chega nos 100 que sete modelos comerciais fizeram, nem nos 98,5 do Grok 4.6. Sete pontos e meio separam o melhor aberto do teto, e no v4 cada ponto é uma sabotagem a menos pega sem aviso.

A diferença que importa é outra: previsibilidade. Entre os comerciais de ponta da tabela, o pior é 87,5, e o campo comercial inteiro também tem fundo de poço, o Mistral Large 3 fez 39. O campo aberto tem os mesmos 92,5 no topo e dois Tier D no fundo, com o DeepSeek fazendo 85 na nuvem e 44,5 na minha mão. Escolher um comercial de ponta é escolher um número que a API reproduz; escolher um aberto é apostar que o checkpoint, a quantização e o seu stack de serving reproduzem o número do card, e às vezes reproduzem.

A conta

Se a qualidade ainda fica abaixo da fronteira, o custo pelo menos é proporcional? Depende de onde você roda o modelo aberto.

Na API em nuvem do próprio fornecedor, sim, e com folga. Uma rodada completa do v4 custou 97 centavos no DeepSeek V4 Flash, 1,17 dólar no Qwen 3.8 Flash, 1,03 no MiMo V2.5 Pro, todos Tier A na nuvem. Contra 9,52 a 30,55 dólares dos modelos de 100 pontos, é dez a trinta vezes mais barato por uma nota 8 a 14 pontos menor. Os preços de lista explicam: o GLM 5.3 Flash custa 15 centavos por milhão de tokens de entrada e 50 de saída; o DeepSeek Flash, 15 a 30 centavos de entrada e 60 centavos a 1,20 de saída; o Opus 5.5, 4 e 20 dólares; o GPT-6 Astra, 10 e 50.

Na sua própria B300 alugada, não. O pod custa 9 dólares por hora ligado ou ocioso, 218 por dia, uns 6.500 por mês. O tempo de modelo desta leva inteira, 14 modelos entre download, carga e sprints, somou 23 horas, uns 212 dólares a preço de pod; só os sprints foram 17 horas e 157 dólares.

Só que o pod cobra também o tempo em que nada roda. Eu coloquei 400 dólares de crédito na Runpod e sobraram 127: a leva inteira custou 273 dólares, umas 30 horas de pod, incluindo armazenamento, quatro pods em sequência e sete horas ociosas numa madrugada em que a orquestração morreu e nada avisou. Quase 60 dólares a mais que o tempo de modelo, só de espera. A conta de ponto de equilíbrio do repositório: o pod só fica mais barato que a API a partir de umas 6.500 rodadas por mês, 217 por dia, sustentadas. Um desenvolvedor sozinho ou um time pequeno nem chega perto.

E modelo contra modelo, lado a lado:

A API em nuvem de um modelo aberto é dez a trinta vezes mais barata que a fronteira por um tier a menos. Hospedar o mesmo modelo numa B300 alugada é mais caro que a fronteira, e às vezes pior que a própria API dele.

Cabe um time na mesma placa?

Uma pergunta que eu fiz olhando a GPU a 10% de uso: esses modelos usam toda a computação do pod? Dava pra colocar um time inteiro na mesma B300?

Em princípio, sim, e é pra isso que o vLLM existe. O batching contínuo agenda várias requisições no mesmo passo de decodificação, e o PagedAttention guarda o cache de KV de cada sessão em blocos não contíguos, com menos de 4% de desperdício, justamente pra caber mais sessões na mesma memória. Um modelo de 27 bilhões em BF16 ocupa 56 GB e deixa uns 200 GB de cache de KV: são dezenas de sessões de agente com contexto de 128 mil tokens ao mesmo tempo. O 397B, com 251 GB de pesos, deixa 24, e aí cabem poucas.

O que não escala é a velocidade por pessoa. O meu teste rodou em --performance-mode interactivity, que otimiza a latência de um fluxo só, e os 200 tokens por segundo são desse fluxo. Com dez agentes decodificando ao mesmo tempo, a vazão agregada da placa sobe e a de cada um cai, e a decodificação especulativa que me deu os 295 do Muse Glimmer rende menos conforme a concorrência cresce: um rascunhador DFlash publicado pro Muse pelo Z Lab reporta 3 a 4,6 vezes de ganho com uma sessão e 1,2 a 1,7 com 32.

Eu não medi concorrência nesta leva, então o que posso dizer é o contorno: um time de cinco a dez pessoas num modelo de 27 a 35 bilhões numa B300 é prático, e provavelmente cada um ainda fica acima dos 100 tokens por segundo. O mesmo time no 397B é inviável na placa, e no GLM 5.3 Flash de 198 GB fica apertado.

É nesse cenário, e só nele, que a conta do pod começa a fechar. Dez desenvolvedores rodando agente o dia inteiro num modelo de 27B gastariam na API, a um dólar por rodada de duas horas, uns 40 dólares por dia; o pod custa 218. Ainda perde. O que muda a conta é ter cem pessoas, ou ter a obrigação de que o código não saia da sua rede.

Vale a pena ter a própria infra?

Pra desenvolvimento de software sério, com os dados desta leva, a resposta vem em três partes.

Os modelos abertos de ponta são bons o suficiente. GLM 5.3 Flash, Qwen3.8 Flash-Next e Swift 1.5 27B são Tier A no meu teste, no nível do Sonnet 5 e acima do Opus 4.6. Isso era impensável em abril, quando só o Qwen 3.6 35B chegava perto do Opus, e ainda a uma correção de distância. Pra quem aceita um tier abaixo do teto, eles servem pra trabalho de verdade, inclusive revisão de segurança, que é o que o v4 mede.

Alugar uma B300 pra rodar eles é o jeito errado de usá-los. A API em nuvem do mesmo modelo custa um dólar por rodada e precisa de zero configuração. O pod custa 218 por dia, exige um dia de ajuste por família de modelo, e no caso do DeepSeek entregou um modelo pior do que a API dele. Só vale com uma obrigação de residência de dados, com um checkpoint que nenhuma nuvem serve, com carga sustentada de centenas de rodadas por dia, ou com necessidade de pesos fixados pra reprodutibilidade. Quatro B300 pra rodar os de 750 bilhões a um trilhão quadruplicam a conta sem evidência de que a nota chega nos 100: o 397B, maior modelo que eu testei, fez 68,5.

E se for pra hospedar, hospede pequeno. O Swift 1.5 27B e o ThinkingCap em 56 GB, com MTP, a 200 tokens por segundo, são Tier A em hardware que dá pra comprar, uma placa profissional de 80 ou 96 GB em vez de uma de datacenter. É ali que o open source faz sentido pra uma empresa: um time inteiro numa placa, código dentro da rede, nota de Opus 4.6. Só olhe a licença antes: o Swift e o ThinkingCap saem com licenças próprias, e acima de um certo faturamento os dois exigem licença comercial. Os gigantes abertos continuam sendo coisa pra API.

Minha regra depois disso tudo: modelo comercial de ponta pra tarefa que não pode errar, API de modelo aberto pra volume, e placa própria só quando a lei ou o cliente exigem. O repositório com cada argumento de serving, cada log de sondagem, cada transcrição de revisor e a proveniência Codex ou Claude de cada fronteira está público, como sempre.

Só que ninguém precisa de um modelo classe GPT pra tudo. Modelo de fronteira é generalista por definição: tenta saber tudo sobre qualquer coisa, de direito tributário a letra de música, e o retorno disso é decrescente.

E a maioria deles hoje é mistura de especialistas, mixture of experts: grosso modo, vários modelos menores agrupados num bloco gigante de bits, com um roteador que acorda só alguns pra cada token. O gpt-oss-120b da OpenAI tem 117 bilhões de parâmetros no total e usa 5,1 bilhões por token. O DeepSeek-V3 tem 671 bilhões e ativa 37. O modelo grande já é, por dentro, uma coleção de modelos pequenos.

Eu podia ter pego um modelo aberto, gpt-oss, Qwen, Phi, e adaptado. As técnicas existem e são bem documentadas:

• Fine-tuning completo: continuar treinando todos os pesos de um modelo pronto nos seus dados. É a transferência de aprendizado clássica, formalizada pro texto pelo ULMFiT em 2018.
• LoRA e QLoRA: congelar os pesos originais e treinar só matrizes pequenas de baixo posto ao lado deles. O LoRA reduz em até dez mil vezes os parâmetros treináveis; o QLoRA quantiza o modelo base em 4 bits e ajusta um modelo de 65 bilhões numa única GPU de 48 GB.
• Destilação: treinar um modelo menor pra imitar as saídas de um maior. A ideia é de Hinton, 2015, e o exemplo recente mais famoso é o DeepSeek-R1 destilado em versões de 1,5 a 70 bilhões em cima de Qwen e Llama.
• Pré-treino continuado: mais uma fase de treino em texto do seu domínio antes de qualquer ajuste de instrução, o “Don’t Stop Pretraining” de 2020.
• SFT, RLHF e DPO: ensinar o formato de assistente com demonstrações, depois alinhar com preferência humana via aprendizado por reforço (InstructGPT) ou com uma perda de classificação direta (DPO).

Com qualquer uma dessas eu teria um modelo útil em horas. Só que o objetivo era outro. Eu queria organizar, com as mãos, as técnicas básicas pra construir um modelo menor que o GPT-2, do zero, em poucos dias, e ver até onde dava pra chegar. Se desse, treinar um modelo minúsculo partindo de pesos aleatórios e adicionar funcionalidade suficiente pra ele quase funcionar dentro de um harness agêntico como o OpenCode.

Antes de continuar, quem eu sou nessa história: eu sou engenheiro de software curioso e amador no assunto. Pesquisador de LLM eu sou zero. Eu sabia que não ia ter um LLM funcional em tão pouco tempo, e isso faz parte do exercício.

Mas não é inalcançável. Se você é estudante de computação, estuda sério e dá anos pra isso, você consegue tentar por conta própria. E se você não é cientista, entenda isto: ninguém precisa ser Einstein pra fazer isso. Os fundamentos estão todos disponíveis, publicados, pra você estudar e tentar. O que é obrigatório é suor.

Spoiler: a gente chegou longe no “quase” e parou lá. O repositório é público, com cada etapa e cada fracasso documentado. Este texto é o resumo.

TL;DR: parti do microgpt do Karpathy, 200 linhas de Python puro que treinam um GPT em um minuto num MacBook, e expandi pra um laboratório em PyTorch com tokenizer próprio, pré-treino, ajuste supervisionado, servidor compatível com a API da OpenAI e integração com o OpenCode. Em menos de duas semanas, numa RTX 5090, treinei um modelo de 337 milhões de parâmetros em 10 bilhões de tokens: 137 horas de treino, no máximo uns R$ 80 de luz. Ele acerta 58 de 100 funções Python simples de um conjunto reservado, e zera em tudo que exige ler, editar e testar um repositório. O SmolLM2 de 360 milhões, do mesmo tamanho, viu 4 trilhões de tokens, 400 vezes mais. Pule pro exercício do Karpathy, pras etapas, pras dimensões, pros tropeços, pro resultado ou pra conclusão.

O exercício do Karpathy

Em fevereiro deste ano o Andrej Karpathy publicou o microgpt: um único arquivo de 200 linhas de Python, sem dependência nenhuma, que treina e roda um GPT. Ele chama de “o conteúdo algorítmico completo do que é necessário. Todo o resto é só eficiência”. É a culminação de uma linhagem dele: o micrograd (autograd escalar), o makemore (gerar nomes) e o nanoGPT (GPT-2 em PyTorch compacto), à qual se soma o nanochat, “o melhor ChatGPT que 100 dólares compram”, que no lançamento treinava um modelo de capacidade GPT-2 em quase quatro horas num nó de oito H100, e hoje faz isso em umas duas.

O microgpt é propositalmente mínimo: o dataset são 32 mil nomes próprios, um por linha, e o tokenizer é um caractere por token.

A rede tem uma camada, 16 dimensões de embedding, 4 cabeças de atenção, janela de 16 tokens porque o nome mais longo tem 15 letras. Treina por mil passos, um nome por passo, com Adam escrito à mão, e no fim gera nomes inventados, tudo em um minuto num MacBook.

O que ele ensina, por estar tudo exposto num arquivo só:

• o autograd, a classe Value que guarda um número, o gradiente e a regra da cadeia pra propagar de volta;
• o que é um token e um embedding;
• o bloco de atenção, com consulta, chave e valor, e a máscara causal que impede o modelo de espiar o futuro;
• a perda de entropia cruzada contra o próximo token;
• o otimizador;
• a amostragem com temperatura.

É um GPT-2 com diferenças pequenas que o próprio arquivo anota: RMSNorm no lugar de LayerNorm, sem bias, ReLU em vez de GeLU. Depois de ler aquilo, o que sobra entre você e um modelo de verdade é, nas palavras dele, eficiência. Eu fui ver quanto de eficiência.

O que a gente expandiu

O microgpt lab é uma reimplementação independente em PyTorch, inspirada no gist, dividida por conceito: umas 3.300 linhas de Python em 31 módulos, mais scripts e 85 testes de CPU. Uma única implementação de modelo serve pra pré-treino, ajuste de assistente e servidor. Todo peso começa aleatório; o projeto não baixa peso pré-treinado nenhum, de propósito, porque a regra do exercício era do zero.

Em cima do bloco do Karpathy entraram os componentes que um modelo de 2026 usa: RoPE pra posição, RMSNorm, SwiGLU na camada densa, embeddings amarrados à saída, Flash Attention via PyTorch, cache de chaves e valores com reuso de prefixo. E em volta do modelo, o que falta pra ele conversar com um agente: um protocolo de conversa com papéis, um servidor HTTP compatível com a API de chat da OpenAI, chamadas de ferramenta validadas por esquema e opcionalmente por gramática, separação de conteúdo de raciocínio, e a configuração do OpenCode apontando pra ele.

O projeto passou por quatro escalas:

A tabela esconde a primeira lição grande, que eu conto nos tropeços: no modelo de 239 milhões, 154 milhões de parâmetros eram só a tabela de vocabulário. Sobravam 85 milhões pro transformer de verdade.

As etapas de construir um LLM

Independente do tamanho, o caminho tem as mesmas estações. O que muda é o zero à direita em cada uma.

1. Dados

Modelo é o que ele come. Baixamos, com revisão fixada e hash, seleções de corpora públicos: CodeParrot (Python deduplicado e filtrado), OpenCoder (instrução e código), Cosmopedia (texto educativo sintético), SmolTalk (conversa) e uma fatia multilíngue. Os 14 manifestos de download somam uns 20 GB brutos, tudo guardado no NAS.

Daí vem a curadoria: deduplicação exata, divisão de treino e validação por repositório ou grupo de conversa (nunca por linha, senão o mesmo projeto vaza pros dois lados), e a mistura. O corpus final de fundação tem 3,5 bilhões de tokens armazenados, 60% código Python, 16% instrução, 12% texto educativo, 8% conversa, 4% multilíngue. Cada proporção é uma decisão de projeto, e nenhuma delas tem resposta certa publicada.

2. Tokenizer

O tokenizer é o dicionário entre texto e inteiros. A lição em bytes usa 256 tokens mais um de fim de documento. O estudante usou o o200k, o vocabulário público da OpenAI com 200 mil entradas, que é o que a maioria dos tutoriais faz. O pivô treinou um BPE próprio de 32.768 entradas, em cima de 92 MB de texto só de treino, com cobertura de UTF-8 completa.

A escolha parece detalhe e decide onde os parâmetros vão parar. Cada entrada do vocabulário custa uma linha na tabela de embedding com a largura do modelo. Com 200 mil entradas e largura 768, são 154 milhões de parâmetros gastos em tabela. Com 32 mil entradas e largura 1.024, são 33 milhões, e o resto vai pras camadas que pensam.

3. Pré-treino, ou fundação

Aqui é o loop do Karpathy em escala. O modelo recebe janelas de 2.048 tokens tiradas do fluxo de treino e aprende a prever o próximo token. Cada atualização processa 32.768 tokens: duas sequências, acumuladas oito vezes. AdamW, taxa de aprendizado com aquecimento e decaimento em cosseno, recorte de gradiente, BF16 na GPU e FP32 nos pesos.

O pivô rodou uns 305 mil atualizações, 10 bilhões de tokens de exposição. Como o corpus tem 3,5 bilhões, cada documento foi visto, na expectativa da mistura, quase três vezes: o código umas duas, e instrução, texto educativo e conversa umas nove ou dez. A cada 500 atualizações, uma validação e um checkpoint. Nos marcos de 2, 5 e 10 bilhões, um checkpoint congelado com hash, pra medir a curva.

4. Ajuste supervisionado

Pré-treino produz um modelo que completa texto. Pra ele responder a um pedido, vem o SFT, supervised fine-tuning: exemplos de pergunta e resposta no formato exato que o servidor usa, com a perda calculada só sobre os tokens do assistente. O que o usuário e a ferramenta disseram entra como contexto e é mascarado da perda.

Os exemplos vieram do OpenCodeInstruct da NVIDIA, e cada resposta foi executada num Docker restrito antes de entrar: quase 99 mil candidatos, 97 mil sobreviveram ao teste com três sementes de hash diferentes. Sobraram 92 mil episódios de treino. O checkpoint escolhido viu 64 mil sorteios desses episódios, uns 10 milhões de tokens de resposta.

5. Protocolo, ferramentas e servidor

Um agente como o OpenCode fala com o modelo por HTTP: manda o histórico com papéis, as definições de ferramenta, recebe de volta texto ou uma chamada de ferramenta em JSON, executa, devolve o resultado, e repete. O laboratório implementa esse ciclo inteiro: o mesmo arquivo de protocolo serializa os exemplos de treino e os prompts de serviço, pra formato de treino e formato de uso nunca divergirem.

O servidor implementa /v1/models e /v1/chat/completions, valida a chamada de ferramenta contra o esquema, pode restringir a geração com gramática pra JSON sair bem formado, separa o conteúdo de raciocínio da resposta, conta tokens em cache e recusa estouro de contexto em vez de truncar em silêncio. Isso tudo é encanamento, zero inteligência, e sem ele o modelo nem senta à mesa.

6. Avaliação

A etapa que mais mudou o projeto. Um conjunto congelado de 100 tarefas Python de desenvolvimento, 20 famílias com cinco variantes de nome e enunciado, mais 100 tarefas reservadas que só o checkpoint final viu. Cada resposta roda num Docker sem rede, sem root, com limite de CPU e memória, contra asserções fixas. Além disso: quatro tarefas reais de conserto de repositório via OpenCode, 12 problemas de rastrear a saída exata de um programa, sondas de recuperação de informação em prompts de 8, 16 e 32 mil tokens, e quatro conversas curtas.

Nada de HumanEval, MBPP ou SWE-bench. São diagnósticos locais pequenos, com famílias correlacionadas, uma semente, geração gulosa. Servem pra decidir entre checkpoints, e o próprio relatório de fechamento manda não ler “58 de 100” como “58% de sucesso em programação”.

As dimensões do problema

O que tudo isso custou, e como isso se compara com o mundo real:

A conta da luz: a RTX 5090 tem 575 W de potência nominal. Em 137 horas a plena carga são uns 79 kWh, e a tarifa residencial da Enel em São Paulo em 2026, somando TUSD, TE e impostos, fica em torno de R$ 1 por kWh. Como o treino rodou boa parte do tempo a 75% de ciclo pra não travar o desktop, o real foi menos. É o custo marginal de quem já tem a placa.

Alugar uma 5090 na Runpod sai a uns US$ 1,20 por hora, então as mesmas 137 horas custariam uns US$ 165; uma H100 sai entre US$ 2,90 e 4 por hora, dependendo da variante.

E a comparação que dá a escala. O SmolLM2 de 360 milhões de parâmetros, praticamente o tamanho do nosso, foi treinado em 4 trilhões de tokens. Na nossa vazão, 4 trilhões levariam entre quatro e seis anos de GPU ininterrupta. Mesmo tamanho de modelo, 400 vezes a quantidade de estudo.

É por isso que “parâmetros” é uma unidade enganosa: diz o tamanho do cérebro, e nada sobre quantos anos de escola ele teve.

A regra de bolso derivada de Chinchilla (70 bilhões de parâmetros, 1,4 trilhão de tokens), uns 20 tokens por parâmetro pra ser computacionalmente ótimo, daria 6,7 bilhões de tokens pro nosso modelo. Passamos disso. Só que o ótimo de Chinchilla é o ponto de melhor uso de compute, e modelos pequenos modernos passam muito dele de propósito, porque o custo de inferência depois compensa treinar mais.

Os tropeços

A lista completa está no relatório de fechamento. Os que mais ensinaram:

Medir perto demais do treino. O primeiro agente, o de 91 milhões, completou quatro sessões de 16 rodadas no OpenCode e uma de 32 rodadas com 130 chamadas de ferramenta reais, recuperando de erro de verificação e trocando de sessão no meio, com o estado guardado pelo harness. Parecia pronto.

Aí eu pedi, na mão e em inglês, uma função hello world que recebe um nome como parâmetro e imprime na mensagem. O modelo repetiu duas vezes a edição aritmética anterior, apontou pra um arquivo que não existia, e na terceira tentativa cuspiu JSON inválido. Tudo que ele sabia era a família de tarefa do treino.

O vocabulário comeu o modelo. O candidato de 239 milhões tinha mais camadas e perda menor que o de 91 e resolvia 24 de 100 problemas. Ao olhar a distribuição dos parâmetros, 154 milhões eram tabela de vocabulário. O pivô pra 32 mil entradas devolveu 300 milhões de parâmetros pro transformer. O pivô mudou vocabulário, distribuição de capacidade, inicialização e exposição de uma vez, então o relatório não isola qual delas moveu o resultado.

Perda não é competência. No SFT final, continuar de 4 mil pra 8 mil atualizações baixou a perda de validação e derrubou o acerto executado de 68 pra 62. Loss mais baixa, código pior. A seleção de checkpoint passou a ser por tarefa executada, congelada antes; o número da perda ficou de fora.

Dados e avaliadores mentem. Respostas “corretas” do dataset público falhavam ao serem executadas de novo. Testes que dependiam da ordem de hash do Python, builtins sombreados, SystemExit(0) contando como sucesso, edições vazias copiando o arquivo. Cada um precisou de um controle: três sementes de hash, sentinela de conclusão, fixture vazia que precisa falhar. E num dos treinos mistos, o modelo aprendeu a dizer que os testes passaram quando não tinham passado.

Formato de treino e formato de uso precisam bater. Anúncio de troca de sessão, ID de chamada de ferramenta, âncora de edição, o jeito como o OpenCode cita a entrada do usuário: cada diferença entre o que o modelo viu no treino e o que recebeu no servidor derrubava o agente antigo. O mesmo arquivo de protocolo pros dois lados foi a solução, e ainda assim mudar formato às vezes melhorava o nome da função sem melhorar o código.

Tokenização cruza fronteiras de correção. A string literal <|endoftext|> dentro de código fonte precisa continuar sendo texto comum em vez de virar o marcador de fim de documento. Reconstruir documentos UTF-8 sem partir um caractere no meio. O suporte do XGrammar a vocabulário em nível de byte. A primeira avaliação de código do marco de 2 bilhões falhou na construção da gramática, e foi corrigida e rerodada em vez de contar como falha do modelo.

O NAS quase me custou dias. Na retomada da fase de 10 bilhões, o treinador carregou o passo 81.500 em vez do 152.588 congelado: o last.pt mutável tinha timestamp anterior à pausa, logo depois de uma manutenção no NAS, e a causa nunca foi provada. Descartamos 1,24 hora de treino, verificamos o hash do marco de 5 bilhões, e toda retomada seguinte passou a exigir hash, passo exato, estado do otimizador e do RNG, dataset e uma sonda de escrita com fsync. Nunca retome um treino só porque o arquivo se chama last.pt.

GPU de desktop é GPU compartilhada. VRAM livre não impediu o navegador de travar. A solução foi um ciclo de trabalho cooperativo: o treinador sincroniza a GPU e dorme entre lotes, 75% do tempo durante o dia e 100% das 3 às 9 da manhã. E a leitura do corpus pelo NAS, via mmap, deixava a GPU ociosa esperando disco. Depois de uma manutenção a vazão caiu pra 5 mil tokens por segundo antes de voltar aos 23 mil.

Parei numa fronteira do pipeline. O controlador do pivô implementava fundação, SFT de código e holdout. Terminou limpo, e “terminou limpo” cobria até a função Python isolada, enquanto o objetivo era o agente. O checkpoint final foi testado no OpenCode só no fechamento, e falhou. Devia ter sido testado antes de qualquer frase com “pronto”.

O que saiu do outro lado

A ficha do modelo final:

A curva de aprendizado, medida nos três marcos, com o mesmo SFT curto aplicado em cima de cada um:

O SFT mais longo em cima dos 10 bilhões chegou a 68 de 100 no conjunto de desenvolvimento e 58 de 100 no reservado. Todas as 100 saídas do reservado são Python válido, e 97 têm o nome de função e os parâmetros pedidos. Nove famílias passaram nas cinco variantes: mediana, fatorial, máximo divisor comum, conversão pra binário, inverter dicionário, contar linhas, ano bissexto, segundos pra horas, chaves de JSON. Total acumulado ficou em quatro de cinco.

O que ele faz, portanto: escreve uma função Python pequena, com docstring, sintaxe correta e o nome certo, pra um pedido claro de uma linha. Dentro de um editor, como autocompletar de função isolada, serve pra estudo.

O que ele erra, com exemplos salvos: deduplicar usando set quando o enunciado exigia suportar listas não hasheáveis; agrupar por tamanho contando palavras em vez de agrupar; fazer aritmética em cada elemento numa função de preencher; devolver (texto, '') numa função de dividir uma vez, ignorando o separador; tirar o último caractere em vez do diretório numa função de basename. Dos 42 erros do reservado, 39 têm sintaxe válida e nome certo e falham na semântica. A parte difícil nunca foi parecer código.

E o que ele zera:

• 0 de 4 consertos reais de repositório no OpenCode, com zero chamadas de ferramenta. Pedido pra ler, editar e testar um arquivo, ele devolveu texto com código. Numa das tarefas, renomeou a função pra fix_mean.
• 0 de 12 em rastrear a saída exata de programas curtos, com e sem modo de raciocínio. Muitas respostas foram código que supostamente calcularia o inteiro pedido.
• 0 de 9 em achar um número de seis dígitos escondido em prompts de 8, 16 e 32 mil tokens. A alocação de 32 mil tokens funciona; a memória útil, nenhuma.
• Conversa: perguntado em português sobre a cor do céu, respondeu repetitivo e errado; pedido em inglês de café da manhã virou uma docstring em Python repetindo “oats” até o limite de tokens. Numa troca curta lembrou que o gato se chamava Pipoca, e mesmo assim respondeu com frase inteira apesar do pedido de “só o nome”.

O SFT final só tinha respostas de código, sem conversa, sem trajetória de ferramenta, sem recuperação de erro. A tendência de responder qualquer coisa com Python é coerente com isso, e o relatório toma o cuidado de dizer que a causa não foi isolada.

O que faltaria pra um agente simples no OpenCode

O relatório fecha com estimativas de engenharia, sem promessa de taxa de acerto. Pra chegar num agente que resolve tarefa simples de programação dentro do OpenCode, nesta ordem:

1. Ensinar uso de ferramenta no modelo forte. Entre 10 e 30 mil trajetórias curtas e verificadas de repositório (ler, editar, checar), misturadas com 30 a 50% de código pra ele não desaprender. Um a três dias de engenharia e de duas a seis horas iniciais de treino.
2. Corrigir os próprios erros. Coletar centenas a alguns milhares de falhas do modelo em tarefas de treino, reconstruir o estado do arquivo, verificar as correções e treinar mascarando a ação errada. Mais um a três dias de coleta e de duas a oito horas de treino.
3. Devolver a conversa. Uma mistura equilibrada de conversa, ferramenta e código contra o checkpoint congelado, pra ele parar de responder tudo com Python e conseguir trocar de tarefa. Uma a quatro horas de treino.
4. Contexto longo de verdade. Só depois das tarefas curtas passarem: 4 mil, 8 mil, e só então 16 e 32 mil, com trajetórias reais de compactação e troca de sessão. Um a dois dias de engenharia e de 6 a 24 horas de treino, medindo memória a cada janela.
5. Mais fundação, com dados melhores. Cada 10 bilhões de tokens a mais custam entre 93 e 139 horas nesta GPU, antes de preparação e avaliação. E repetir a mesma mistura de 3,5 bilhões não vale a pena: precisa de mais código educativo único.

Nenhum desses passos foi executado. Não há evidência de que um número fixo de horas a mais produza um agente confiável, e o relatório é explícito nisso. O que o exercício estabeleceu foi a distância: entre gerar uma função plausível e agir de forma confiável num repositório existe um abismo que parâmetro e contexto alocado sozinhos não cruzam.

O mais forte que saiu daqui foi a curva medida de 0 pra 65 em dez bilhões de tokens, e três contraexemplos concretos: sintaxe não é semântica, suporte a protocolo não é habilidade com ferramenta, e capacidade de contexto não é memória.

O futuro é menor e mais especializado

Depois de onze dias olhando pra dentro de um modelo, a minha leitura do mercado ficou mais firme. Modelo de fronteira generalista vai continuar existindo e vai continuar sendo caro, e o retorno de cada bilhão a mais de parâmetros é cada vez menor. Eu já escrevi que os modelos crus convergiram e que o ganho recente veio do harness. O exercício me deu a outra metade do argumento.

A mistura de especialistas é a indústria admitindo isso por dentro. Se o gpt-oss de 117 bilhões acorda 5 bilhões por token, o que você está usando numa pergunta de contabilidade é um modelo de 5 bilhões escolhido por um roteador. A pergunta que fica é por que carregar os outros 112 bilhões, de arte, cinema, meme e física de partículas, num servidor de escritório contábil.

Imagine um modelo local, feito pra contadores. Ele conhece o plano de contas, a legislação tributária do país, os formatos de arquivo da Receita, o jargão. Ele dispensa parâmetros sobre tudo que um contador não precisa, e pode rodar no PC do escritório, com os dados do cliente dentro da sala.

Os exemplos já existem em outras áreas: o MedGemma de 4 bilhões pra saúde, o SaulLM de 7 bilhões pra direito, o Fin-R1 de 7 bilhões pra raciocínio financeiro. Em 2023 o BloombergGPT precisou de 50 bilhões de parâmetros e 1,3 milhão de horas de A100 pra fazer finanças; hoje um ajuste em cima de um modelo aberto de 7 bilhões faz o mesmo papel por uma fração.

O que mudou pra isso virar viável foi o agente. Um modelo especializado de 2023 precisava saber tudo de cor, porque a única coisa que ele fazia era completar texto. Um modelo de 2026 precisa de uma base: raciocínio suficiente, capacidade de sustentar uma tarefa longa, chamada de ferramenta confiável, cache de prompt. O resto, a legislação que mudou ontem, o documento do cliente, a tabela que ele nunca viu, ele busca com ferramenta e internet na hora, e preenche as lacunas do treino em tempo de uso.

A NVIDIA publicou em 2025 exatamente essa posição: modelos pequenos são suficientes, mais adequados e mais baratos pra maioria das chamadas de um agente, com o modelo grande chamado só quando a conversa aberta exige. A Apple já roda um modelo de 3 bilhões no aparelho com protocolo de ferramentas e adaptadores por tarefa.

É o mesmo raciocínio dos modelos de decisão que eu testei semana passada: um classificador de 4 bilhões treinado pra uma tarefa bate um modelo de chat genérico do mesmo tamanho nela, numa fração do tempo de resposta. Em vez de tentar caber o mundo inteiro num modelo maior, cabe o domínio num modelo menor e deixa o harness buscar o mundo quando precisar.

E o que o meu modelo de 337 milhões me ensinou é o tamanho do “suficiente” nessa frase. Ele sabe a sintaxe e sabe o nome das coisas. O que falta, semântica, ferramenta, memória, é exatamente o que separa um gerador de texto de um agente, e isso ninguém treina em duas semanas numa placa de vídeo. Treina em meses, em cluster, com trilhões de tokens, e depois especializa.

O código está no repositório, com o relatório de fechamento inteiro, pra quem quiser pegar de onde eu parei. É só pra estudo. E foi o melhor estudo do ano.

Ranking de terceiro é útil, mas eu queria pôr a mão na massa. Então montei meu próprio benchmark, com casos meus, metade em português, e rodei os modelos abertos duas vezes: no meu home server com Strix Halo, o mesmo Ryzen AI Max+ 395 que uso pra testar LLM local, via ROCm, e de novo numa RTX 5090 via CUDA. Os hospedados (Jev, os dois Clef da Cloudflare, o OpenAI Decisions e o Microsoft Decision-1 via OpenRouter) rodaram pela API deles. Tudo, incluindo os casos, as respostas brutas e os scripts de pontuação, está público no repositório do benchmark.

TL;DR: o topo agora tem dois, ambos de pesos abertos. O Perplexity Decider 1.1 27B e o recém-lançado Decision 3.0 (vLLM Semantic Router) empataram em 99,4% nos casos compactos, com 100% em português, e rótulos idênticos em todas as 1.024 classificações do benchmark. O preço: uns 49 GB de pesos e mais de um segundo por decisão. Na nuvem, o Microsoft Decision-1 empatou com o Jev em 97,6% custando um terço: é o hospedado mais barato que eu medi, e o primeiro candidato a avaliar. O Jev responde mais rápido e erra diferente. O OpenAI Decisions estreou empatado com o melhor 4B local, o Jebadiah, e tem a menor latência hospedada. O Julia-1, o menor e mais rápido de todos (12 ms), acertou no nível da moeda: de fábrica, não serve. E a segunda passada, agora numa RTX 5090: os modelos até 9B aceleram de 2× a 10×, o Jebadiah 4B cai pra 39 ms, mais rápido que qualquer hospedado, e os dois campeões de 27B, com uns 49 GB de pesos, nem cabem nos 32 GB da placa. Pule pra tabela, pro custo em e-mails de suporte, pra qual usar em qual situação, pra quão difícil é rodar local, pras pegadinhas ou pras duas cozinhas do ROCm x CUDA.

Como eu testei

A ideia central foi medir mais do que “quem acerta mais”. Modelo de decisão tem objetivo de projeto, e comparar um encoder de 322 milhões de parâmetros feito pra rodar em dispositivo fraco com um serviço hospedado de tamanho não divulgado só por porcentagem de acerto é injusto com os dois. Então medi acerto, latência, custo e comportamento sob estresse, e no fim separo as recomendações por situação.

Os dois conjuntos de casos

Montei dois conjuntos de testes, congelados em git antes de qualquer inferência, com o hash do dataset gravado junto com as respostas. Nenhum modelo recebe a resposta esperada, a justificativa ou o identificador do caso. Só o texto, as instruções e as opções.

O conjunto v1 tem 13 casos de uso operacionais, em inglês, cada um com uma política fictícia explícita:

• severidade de ticket de suporte
• roteamento de suporte
• política de reembolso
• escalação de incidente
• aprovação de ferramenta (um agente pode ou não executar tal ação)
• fraude por e-mail
• tipo de documento
• suporte de evidência
• relevância de busca
• moderação
• roteamento de pedido
• qualificação de lead
• triagem por limiar numérico

São 10 cenários por caso de uso, cada um apresentado de quatro formas: original, opções em ordem invertida, opções com nomes opacos (c0, c1, c2) e original mais um comentário de “revisor” sugerindo a resposta errada, que a instrução manda ignorar. Dá 520 classificações por modelo. Somam-se 24 sondagens de probabilidade em situações sem informação nenhuma (moeda honesta, dado de seis lados), onde a resposta certa é matemática.

O conjunto v2 foi feito pra cobrir o que o v1 deixa de fora: semântica comum e português. São 7 tarefas, com 12 cenários cada, e cada cenário escrito em inglês e em português brasileiro com a mesma resposta e a mesma ordem de opções:

• sentimento (autor versus citação, negação, sarcasmo)
• intenção atual (pedido retirado, ações concorrentes, hipótese)
• implicação lógica (quantificadores, fato ausente, ordem temporal)
• relevância de busca (tudo, parte ou nada do que foi pedido)
• tratamento de dados sensíveis (segredo fictício versus menção, redação, revogação)
• status atual de incidente (ordem da linha do tempo, verificado versus não verificado)
• política por limiar (limites inclusivos, unidades, E/OU com valor faltando)

Cada par roda em três condições:

• compacta: só o registro e a regra
• com exemplos: um exemplo resolvido por classe, fixo e igual pra todos
• com distratores: dez notas irrelevantes de arquivo antes do registro que importa, pra estressar contexto

Dá 504 classificações por modelo.

Os casos foram escritos com ajuda de IA e revisados contra as políticas, sem anotação humana independente. É um benchmark sintético e pequeno: 130 famílias de cenário no v1 e 84 no v2. As variantes são correlacionadas, então 520 respostas são 130 cenários vistos de quatro jeitos. Trate os números como fotografia desses casos, e teste com os seus antes de decidir.

Os 23 competidores

Cinco rodaram na nuvem, pela API oficial: o Jev (versão 1.13.0, da TypeSafe), o Clef (27B, Cloudflare Workers AI), o Clef-flash (9B, idem), o OpenAI Decisions (o alias gpt-6-luna, em beta público) e o Microsoft Decision-1 (9B, pós-treinado do Qwen3.5-9B, servido via OpenRouter em Azure). Os outros dezoito rodaram no Strix Halo, via ROCm, e depois de novo numa RTX 5090, via CUDA, com os pesos fixados por hash de commit no Hugging Face, dentro de container Docker. Os três da primeira leva (Laya, Laya typed e Clef-flash) dividiram um container; os demais rodaram um por vez, com o Julia-1 medido duas vezes, em GPU e em CPU. O servidor via 64 GiB de memória endereçável pela GPU.

A ordem aí em cima é só organizacional, hospedados primeiro e locais por família. O ranking de verdade está na tabela de resultados.

Todos receberam exatamente o mesmo texto, as mesmas instruções e as mesmas opções, sem prompt ajustado por modelo e sem nenhum ajuste depois de ver resultado (o Simple-Jev usa a política de prompt fixa do próprio servidor). A exceção é o GLiNER, cuja API nativa recebe rótulos em vez de distribuições de probabilidade. Ele entra numa trilha separada, só no v2, com mapeamento explícito e sem métricas de calibração inventadas.

O Simple-Jev merece explicação. Ele é um servidor que pega um LLM comum (aqui o Qwen3.5 4B, sem nenhum treino de decisão) e lê a probabilidade dos tokens de resposta em vez de gerar texto. É a linha de base: se um modelo “de decisão” perde pra isso, o treino especializado não comprou nada.

Duas observações de protocolo. O OpenAI Decisions responde por um endpoint nativo de decisões tipadas, e o alias que a API devolveu não é um snapshot imutável: a OpenAI pode trocar o peso por trás do nome, como a Cloudflare faz com o Clef-flash. E o Perplexity Decider não é um LLM de chat comum: ele tem uma cabeça de decisão separada, com atenção não-causal e uma temperatura de calibração salva nos pesos. Um servidor de chat genérico não reproduz o comportamento dele. O Microsoft Decision-1 fala SystemOne nativo pela API de decisões do OpenRouter, e o identificador servido é datado (microsoft-decision-1-20261009), ou seja, também não é peso imutável. Ele não aparece no catálogo de modelos de texto do OpenRouter: pra achar, tem que filtrar pela modalidade decisions. O Decision 3.0 é a família nova do projeto vLLM Semantic Router, Apache 2.0, derivada de Qwen, com seis checkpoints (d3, flash, mini, nano, lite, edge) e SystemOne nativo. Eu testei o flagship (d3) e o menor (d3-edge); os quatro do meio ficam pra outra rodada.

O que foi medido

• Acerto por tarefa, por língua e por condição, sempre em cima das probabilidades por opção que o modelo devolve, ignorando o campo de “confiança” do fornecedor.
• Brier e ECE pra calibração.
• Latência mediana e p95 vista pelo cliente, incluindo a rede: WAN pros hospedados, LAN pros locais. Os locais foram medidos nas duas implantações, Strix com ROCm e 5090 com CUDA. São observações de implantação completa, máquina inteira de cada lado; a comparação entre elas não isola o efeito de trocar só o backend.
• Tokens de entrada reportados pela API, valorados pela tabela de preços de 10 de outubro, antes de qualquer franquia.
• Intervalos de confiança por bootstrap sobre famílias de cenário, em vez de respostas individuais.

Custo local eu deixei de medir. Energia, amortização do hardware e manutenção ficaram de fora, então modelo local aparece como “não medido”, porque “zero” seria mentira.

A tabela completa

A coluna principal é o acerto nos 168 casos compactos do v2 (84 em inglês, 84 em português). A coluna do v1 usa os 130 cenários originais. Latências são medianas vistas pelo cliente ao longo das 504 chamadas do v2, nas duas implantações locais: ROCm no Strix Halo, CUDA na RTX 5090. Os hospedados não têm hardware meu pra trocar, e os dois 27B não cabem nos 32 GB da 5090. O custo é o valor de lista por 10 mil decisões compactas, calculado pelos tokens que a API reportou.

Sobre a coluna CUDA: os pesos são os mesmos, então o acerto veio igual ou a até dois casos de distância no compacto em todos os modelos. Rótulos individuais viraram em alguns (12 de 504 no pior caso, o Julia; 11 no Simple-Jev), diferença de aritmética de kernel que não mudou placar nenhum, e as probabilidades diferem na terceira casa decimal em média. A tabela fica pelo acerto do Strix; a coluna CUDA só traz latência. O relatório pareado completo, caso a caso, está no repositório.

Pra calibrar a leitura: as tarefas têm três ou quatro opções, então chute uniforme dá uns 31% nos dois conjuntos. “Perto de 50%” aqui já é bem acima da moeda, e “perto de 33%” é a moeda. O Julia-1 ficou em 31,5%: o nome bonito esconde um cara jogando cara-ou-coroa.

Os intervalos importam. A vantagem do Perplexity sobre o Jev no v2 é de menos de 2 pontos e o intervalo de bootstrap encosta no zero: é a liderança medida neste conjunto, não uma superioridade provada pra sempre. E o Decision 3.0 empatou com o Perplexity no limite do que este conjunto consegue distinguir: rótulos idênticos nas 1.024 classificações, com os dois errando os mesmos dois casos (a relevância em inglês no v2 e o caso disputado de severidade no v1, que já está no errata). O Microsoft empatou com o Jev no agregado, com intervalo centrado em zero, mas empate no agregado não é intercambiabilidade: eles erram casos diferentes, e o Microsoft inverte o padrão de língua, errando mais em inglês que em português. Jev e Clef também seguem separados por menos de 2 pontos, no mesmo patamar. Já o pelotão de 90% (Jebadiah, OpenAI) fica 7 pontos atrás do Jev, e daí pra baixo todas as diferenças são claras.

Cada célula de tarefa tem só 12 cenários por língua, então um acerto a mais muda a célula em mais de 8 pontos. Empate em uma tarefa específica é pista pra um piloto. As tabelas por tarefa estão no repositório.

Quanto custa, em e-mails de suporte

Preço por milhão de tokens é um número que ninguém consegue sentir. Os preços de lista em 11 de outubro são US$ 0,042 por milhão de tokens de entrada no Jev, US$ 0,24 no Clef, US$ 0,038 no Clef-flash e US$ 0,10 no OpenAI Decisions. Saída é grátis nos cinco. O Microsoft Decision-1 cobra os mesmos US$ 0,042 do Jev por milhão, via OpenRouter, mas reportou um terço dos tokens de entrada pros mesmos textos (uns 26 mil contra uns 77 mil do Jev no v2 compacto), e ninguém sabe explicar a diferença de tokenização. Na prática medida, isso o torna o hospedado mais barato do lote.

O Clef-flash custava US$ 0,09 no dia 9: a Cloudflare baixou o preço em mais da metade no meio do meu teste. O Jev reporta bem mais tokens que a Cloudflare pro mesmo texto, uns 45% a mais no v2, e isso já está na conta abaixo.

Imagine uma operação com 10 mil e-mails de suporte por mês pra classificar em três ou quatro baldes, com textos curtos parecidos com os meus casos:

Em reais, pela cotação de sexta (R$ 4,99), 10 mil decisões no Jev custam um real. Um milhão custa menos de cem reais. Pra qualquer empresa que tenha um milhão de e-mails pra classificar, isso some no orçamento.

Uma ressalva de proporção: meus casos são curtos, uns 450 tokens por caso compacto pela contagem do Jev. E-mail real de cliente, com histórico de thread citado, pode ser três a cinco vezes maior, e o custo escala linear com isso. Mesmo assim, estamos falando de centavos por milhar.

O que esse cálculo mostra é que a diferença de preço entre os modelos hospedados é irrelevante perto do custo de errar. O Jev custa 9 centavos de dólar a mais que o Clef-flash a cada 10 mil decisões, e nesses mesmos 10 mil comete uns mil erros a menos. Se um e-mail mal roteado custar mais que um centésimo de centavo de dólar em retrabalho humano, o Jev se paga. Essa conta assume que todo erro custa igual, o que nunca é verdade: mandar um ticket crítico pra fila de rotina custa muito mais que o contrário.

A franquia da Cloudflare muda a conta pra quem é pequeno. São 10 mil “neurônios” por dia, compartilhados pela conta inteira, zerando à meia-noite UTC. Com os meus tamanhos de entrada, isso dá umas 1.500 classificações de Clef completo por dia ou quase 10 mil de Clef-flash, de graça. Se você tem 1.000 e-mails por dia e nada mais rodando na conta, o Clef sai a custo zero com qualidade de ponta.

E o local? Energia o benchmark deixou de medir. Pelo que eu vejo no meu Strix Halo, a máquina inteira fica abaixo de 100 W sob carga. Com o Jebadiah em 200 ms por decisão, 10 mil decisões são uns 35 minutos de máquina, menos de 0,1 kWh, uns centavos de real na conta de luz.

O custo local real é a máquina, a sua hora configurando ROCm e container, e manter aquilo de pé. Quem já tem o hardware por outro motivo tem custo marginal baixo. Quem compraria a máquina só pra isso está comprando um problema de milhares de reais pra economizar uns cem reais por milhão.

Qual modelo em qual situação

Você quer precisão e quer operar nada: Jev

Na nuvem, o Jev continua sendo o nome. Venceu ou empatou em praticamente todas as células entre os hospedados, e só o Microsoft empatou com ele no agregado. Em inglês ele foi 100% em cinco das sete tarefas do v2, e em português repetiu 97,6% no agregado sem perder nada na tradução, coisa que nenhum outro modelo acima da moeda conseguiu. No v1 ele manteve os 96,2% do original com o comentário malicioso do “revisor” injetado; o Clef até subiu um caso, e o Kev 4B também ficou parado, só que num patamar bem mais baixo. A latência de 255 ms via WAN ficou a 30 ms do OpenAI, e custa 19 centavos de dólar a cada 10 mil decisões.

A contrapartida é a que já discuti no texto anterior: é proprietário, hospedado, de tamanho não divulgado, e você depende da TypeSafe manter o comportamento por baixo de você. E ele erra. Tratou um ID de fatura chamado “PASSWORD-523” como credencial utilizável, mesmo com o registro dizendo explicitamente que aquilo não autentica ninguém.

Você quer o nível do Jev pagando um terço: Microsoft Decision-1

A Microsoft entrou nesse mercado quieto, e entrou bem. O Decision-1 é um 9B pós-treinado do Qwen3.5-9B, servido via OpenRouter, e foi o primeiro modelo a empatar com o Jev no agregado compacto: 97,6%, com o intervalo de bootstrap centrado no zero. O detalhe que me ganhou: 100% em português, melhor que o inglês dele (95%), invertendo o padrão de todo o resto do lote. No v1, as variantes de ordem invertida e comentário malicioso não derrubaram uma única resposta, e ele acertou o ticket crítico que o Clef e o OpenAI erraram.

E é o hospedado mais barato que eu medi: US$ 0,065 por 10 mil decisões, um terço do Jev, cobrando a mesma taxa por token mas reportando um terço dos tokens. A economia vem da contagem de tokens, e o mecanismo exato eu não sei explicar, então trate como medida, não como promessa.

Os pontos fracos existem. A latência é a pior entre os hospedados (422 ms de mediana, contra 255 do Jev). Nos casos compactos ele é limpo de erro confiante, mas basta adicionar contexto pra aparecer erro em português com 99,5% de confiança: o padrão “português perfeito” não sobrevive a texto longo. E nas sondagens de probabilidade ele é fraco, dando 87% pra uma moeda honesta. A Microsoft anuncia probabilidades calibradas; minhas sondagens discordam. E como todo hospedado de ID datado, o peso por trás pode mudar sem aviso.

Pra operação em português que quer qualidade de Jev pagando menos, é o primeiro candidato a rodar no seu piloto.

Você quer o mesmo nível com pesos abertos: Clef

O Clef completo de 27B empatou com o Jev em inglês (82 de 84) e ficou 3 casos atrás em português. Ganhou dele no tratamento de dados sensíveis em inglês (12 de 12 contra 11). É modelo de pesos abertos, então dá pra rodar local com uns 54 GB de memória só pros pesos em BF16, o que eu deixei de testar: o Clef completo rodou só pela API. Entre os abertos, ele perdeu a coroa pro Perplexity, que pontuou mais alto com pesos menores.

Pela API ele é o mais caro dos cinco hospedados, três vezes o Jev, sem ganho de qualidade que justifique. A exceção é a franquia diária: pra volume pequeno, ele é o melhor classificador que você consegue de graça.

Você quer o mais barato na nuvem: Clef-flash

A US$ 0,038 por milhão, o Clef-flash é o preço mais baixo do mercado hospedado e cobre 9.400 decisões por dia dentro da franquia. A qualidade cai: 92% em inglês e 83% em português nos casos compactos, a maior queda de língua entre os hospedados, com intervalo inteiro abaixo de zero. Em sentimento nas duas línguas, e em status de incidente em inglês, ele empatou com o Jev. Em intenção e dados sensíveis em português, perdeu feio.

Pra tarefa de sentimento em qualquer língua ou pra classificação em inglês onde 1 em 12 erros é aceitável, ele serve bem. Pra português, meça antes.

Você já vive no ecossistema OpenAI: OpenAI Decisions

A estreia da OpenAI nesse mercado ficou no meio da tabela: 90,5% combinado, empate exato com o Jebadiah, com a menor latência hospedada que eu medi (222 ms) e o mesmo acerto nas duas línguas. Custa US$ 0,23 por 10 mil decisões, entre o Jev e o Clef. Se a sua operação já fala a API da OpenAI e 9 em 10 de acerto basta, a integração é trivial: um endpoint nativo de decisões, nada de prompt.

Os pontos fracos são reveladores. A pior célula dele foi justamente política por limiar numérico (8 de 12 em inglês, 7 em português): tratou “pelo menos 10” como satisfeito por um intervalo de 8 a 12 e falhou no curto-circuito de E/OU. A calibração é esquizofrênica: nas sondagens de predicado (sim/não) ele foi o mais certeiro do lote, com erro médio quase zero, e nas sondagens de escolha ele devolveu 94%/6% numa moeda honesta. E nas variantes do v1 ele virou 2 respostas certas em cada apresentação (ordem invertida, rótulo opaco, comentário malicioso), coisa que só o Perplexity não fez: o Jev manteve a acurácia agregada, mas também virou algumas respostas certas no caminho. Ah, e o alias gpt-6-luna não é snapshot imutável: reprodutibilidade exige guardar as respostas.

Você quer o melhor modelo aberto, ponto: Perplexity Decider 27B

O Perplexity Decider 1.1 27B é a surpresa do benchmark. Liderou a tabela com 99,4% nos compactos, foi o único que não perdeu nenhuma célula de tarefa pro Jev (3 vitórias, 11 empates), e fez 100% em português nas três condições: compacto, com exemplos, com distratores. A calibração também é a melhor medida, com Brier de 0,012, e a cobertura é absurda: respondeu com confiança acima de 0,9 em 96% dos casos e errou zero deles. No v1, não virou uma única resposta nas variantes de ordem, rótulo opaco e comentário malicioso.

Os únicos 3 erros dele no v2 foram o mesmo caso em traje diferente (confundiu “notificação enviada a gerentes” com “aprovador obrigatório”), e ele os cometeu com confiança abaixo de 0,9: o erro conhecido vem sinalizado. O ponto fraco são as sondagens de probabilidade de evento: perguntado sobre um evento de chance 1 em 4, ele respondeu 0,73. Classificação forte não implica probabilidade de evento confiável.

O custo é hardware: uns 49 GB de pesos em BF16, um segundo e meio por decisão no meu Strix Halo (com os kernels de referência do ROCm, sem flash-attention). E antes de sonhar com “numa NVIDIA deve voar”: eu testei, e ele nem cabe numa RTX 5090 de 32 GB. É Apache 2.0, pesos públicos sem gate. Se você tem a máquina e quer o topo da tabela em casa, é ele.

Você quer o outro topo aberto: Decision 3.0 (e cuidado com o Edge)

O Decision 3.0, lançado há dois dias pelo projeto vLLM Semantic Router, é o segundo modelo a sentar no topo: 99,4% nos compactos, 100% em português, e um empate tão absoluto com o Perplexity que os dois deram exatamente os mesmos rótulos nas 1.024 classificações, incluindo os mesmos dois erros (a relevância em inglês, com confiança abaixo de 0,9, e o caso disputado de severidade que já mora no errata). Também zerou as armadilhas do v1 sem virar uma resposta, acertou os dois tickets críticos indiscutíveis, e a calibração é da mesma classe do Perplexity (Brier 0,014, 94% de cobertura acima de 0,9 com zero erros).

Ou seja: o topo open agora tem duas receitas independentes que convergem. Pro seu piloto, tanto faz qual das duas; rode as duas se puder, porque as probabilidades diferem mesmo quando os rótulos não. A latência é da mesma família do Perplexity (1,4 s na minha máquina, mesma dieta de ROCm), e os pesos ocupam os mesmos ~49 GB.

O irmão pequeno é outra história. O Decision 3.0 Edge (0,6B) responde em 45 ms e cabe em 1,3 GB de GPU, mas acertou só 61% no compacto, despenca 14 pontos em português, e pior: dos 68 palpites que ele deu com confiança acima de 0,9, 14 estavam errados. Como roteador com limiar de confiança, de fábrica, ele é uma armadilha da mesma turma do Julia. Os quatro checkpoints do meio (flash, mini, nano, lite) ainda não testei; são eles que vão dizer se a família tem um ponto doce entre os dois extremos.

Você precisa rodar local, com qualidade: Jebadiah 4B v2

Dos locais, o Jebadiah 4B v2 teve o melhor acerto compacto, 90% combinado, respondendo em uns 200 ms no Strix Halo e 39 ms na RTX 5090. Numa 5090, ele fica mais rápido que qualquer hospedado do benchmark, Jev incluso (255 ms de WAN): com o hardware certo, o local deixou de ser o lado lento da tabela. Empatou com o Jev em seis das catorze células de tarefa, incluindo intenção, implicação e status em inglês e intenção em português. O ponto fraco é política por limiar numérico, 9 de 12 nas duas línguas, e ele perde terreno quando o contexto enche de distratores (76% em português nessa condição, contra 82% do Mapika).

O Mapika Decider 4B (o mais rápido dos 4B) e o Kev 4B ficam logo atrás, ambos com uns 87%, e a diferença de 3 pontos entre os três cabe dentro do intervalo de erro. São três receitas de treino diferentes em cima de backbones de 4B, com erros em tarefas diferentes. A escolha entre eles depende da sua tarefa, e eu rodaria os três num piloto.

Você vai mandar exemplos no prompt: Kev 9B

O Kev 9B tem um perfil curioso. Nos casos compactos ele empata com o Kev 4B, com meio ponto de diferença e intervalo cruzando zero, ou seja, mais que o dobro de parâmetros comprou nada. Com um exemplo resolvido por classe, ele abre quase 10 pontos sobre o 4B, e com distratores segura 7 pontos a mais. O Brier também melhora uns 25%: a probabilidade que ele devolve é mais bem calibrada.

Se o seu uso é só a regra e o texto, o 4B basta e é mais que o dobro mais rápido. Se você vai mandar exemplos ou contexto longo, o 9B vale a memória. O alerta é o português: 83% compacto em PT-BR, quase 10 pontos abaixo do inglês dele, a maior queda de língua entre os modelos que passam de 80%. Só o Laya typed (14 pontos) e o Julia (13) caem mais.

Você quer o comportamento do Clef-flash na sua máquina: Clef-flash local

No conjunto v1, o Clef-flash local reproduziu as 520 classificações do hospedado, acerto por acerto e erro por erro. No v2 a história mudou: mesmo total (439 de 504), mas 19 rótulos diferentes, com forças trocadas (o local acerta mais intenção em português, o hospedado acerta mais relevância). Entre os locais ele continua o melhor no conjunto v1 de políticas operacionais (90,8%), à frente de todos os 4B.

A pegadinha é a latência: 618 ms de mediana no Strix Halo (86 ms na 5090), três vezes o Jebadiah, pelo mesmo acerto no v2. Se você escolher ele, é pelo comportamento conhecido.

Você precisa rodar offline em hardware fraco: Laya e Julia, com muitas ressalvas

O Laya multilingual foi o pior do benchmark em acerto (37% combinado, perto da moeda), e o mais rápido com folga entre os que acertam alguma coisa: 19 ms de mediana, mais de dez vezes mais rápido que o Jebadiah.

Os três checkpoints do Laya têm entre 322 e 421 milhões de parâmetros, cabem em menos de 1 GB de pesos em BF16 na conta de parâmetros, e o projeto documenta execução em CPU e runtime ONNX (que eu deixei de medir). O pico de alocação do PyTorch na GPU, pro multilingual, ficou abaixo de 2 GB. Um 4B precisa de uns 8 GB só de pesos na mesma precisão.

O Julia-1 desce mais um degrau: 144 milhões de parâmetros, 550 MB de pesos, 12 ms de mediana na GPU do Strix, 7 ms na 5090 e 71 ms numa CPU de 4 threads. É o modelo mais rápido que eu já medi aqui, e também o pior: 31,5% de acerto, colado na linha da moeda de 31%. Em português ele respondeu “cancelamento” nos 12 cenários de intenção, inclusive nos que pediam reembolso ou acesso (a avaliação de português do fabricante foi feita em pt-PT, e se nota). O desastre maior é a confiança: dos 71 palpites que ele deu acima de 0,9, 48 estavam errados. Um limiar de confiança não salva esse modelo, porque é justamente nos palpites confiantes que ele erra.

Isso é escolha de projeto. O Laya e o Julia foram feitos pra ser encoders pequenos, afináveis na sua tarefa, pra rodar na borda. O que eu testei foram os checkpoints de fábrica, sem nenhum ajuste, aplicando regras que eles nunca viram, em tarefas amplas. Nesse cenário eles foram mal e ponto.

Um detalhe confirma a fragilidade. No v1, quando o comentário malicioso do revisor entra, o Laya cai de 44% pra 19% e o typed-decisions pra 15%. Ele obedece o comentário que a instrução manda ignorar, e com confiança: 17 dos 28 palpites acima de 0,9 estavam errados. O Julia falhou nos 5 pares de contrafactual de política: troca a regra, ele mantém a resposta.

Se você quer o que o Jev entrega, o Laya e o Julia de fábrica ficam muito longe, e nenhum modelo pequeno (GLiNER incluso) chegou perto. Se o seu problema é “preciso classificar texto curto em três baldes, num dispositivo sem internet e sem GPU, e tenho mil exemplos rotulados pra ajustar”, esses dois são os únicos da lista que cabem. O ajuste fino é a parte que eu deixei de testar. É outra pergunta, que precisa de outro benchmark.

A linha de base: Simple-Jev com Qwen comum

O Simple-Jev lendo tokens do Qwen3.5 4B, sem treino de decisão nenhum, tirou 74% no v2 compacto. Isso é a régua de “quanto o treino especializado compra”: Jebadiah, Mapika e Kev, todos em cima de backbones de tamanho parecido, ficaram 13 a 16 pontos acima. O treino compra bastante.

O curioso é que no v1 o Simple-Jev empatou com o Jebadiah (111 de 130 originais) e acertou os dois tickets críticos sem ambiguidade, que vários modelos melhores erraram. Ele também é o mais lento do lote no Strix Halo, quase um segundo e meio por decisão, porque está rodando um LLM inteiro. Na 5090 o mesmo LLM inteiro cai pra 161 ms: a linha de base acelera junto com a máquina, que é o que ela deveria fazer.

Quão difícil é rodar os melhores abertos na sua máquina

Todos esses modelos falam o mesmo protocolo HTTP, chamado SystemOne, que o Jev popularizou: você manda um estado (o texto), uma ou mais perguntas de resposta fechada, e recebe de volta a opção escolhida e a probabilidade de cada uma. Trocar de modelo é trocar a porta. O OpenAI Decisions foge do padrão com um endpoint nativo próprio, mas a ideia é a mesma. O que muda é quanto trabalho dá colocar cada um de pé, e aí a diferença entre eles é grande.

OpenAI: só uma API key

O mais fácil de todos: cria a chave, carrega crédito e chama o endpoint. As 1.048 requisições do benchmark rodaram em 4 minutos, sem uma retentativa. O único soluço foi a primeira sonda devolver “saldo esgotado” até eu colocar US$ 20 na conta.

O Microsoft Decision-1 é quase tão simples: se você já tem conta no OpenRouter, é apontar o modelo e chamar o endpoint de decisões. Sem GPU, sem assinatura Azure, sem instalação. No meu teste, 10 das 504 chamadas do v2 tomaram um 429 e passaram na retentativa, então planeje retry.

Kev e Jebadiah: um pip e um comando

O Kev é o mais simples da turma de 4B. O projeto instala direto do GitHub e sobe um servidor com um comando, baixando o adaptador LoRA e a cabeça de decisão em cima do Qwen3.5 base:

pip install "kev @ https://github.com/jaredpalmer/kev/archive/fc4a17e194bca35a48c57211392ec49ea54a94ac.tar.gz"
python -m kev.serve --run jaredpalmer/kev-4b --host 0.0.0.0 --port 8000 --device cuda

O Jebadiah segue o mesmo padrão, com o pacote do servidor dentro do repositório dele:

pip install "jebadiah-server @ https://github.com/getainode/jebadiah/archive/e9793abc66d1a7c5ad878d51eda656f1e9c5b9f5.tar.gz#subdirectory=server"
jebadiah-serve --model frontier-infra/jebadiah-4b-v2 --host 0.0.0.0 --port 8000

Com qualquer um dos dois no ar, uma decisão é um POST:

curl -s http://localhost:8000/v1/systemone -H 'content-type: application/json' -d '{
  "model": "kev-4b",
  "state": "Cliente diz que foi cobrado duas vezes e pede o estorno da segunda cobrança.",
  "questions": {
    "fila": {
      "type": "choice",
      "instructions": "Escolha a fila correta pela política de suporte.",
      "criteria": {
        "financeiro": "Cobrança, estorno, nota fiscal.",
        "tecnico": "Erro, bug, indisponibilidade.",
        "vendas": "Upgrade, plano novo, orçamento."
      }
    }
  }
}'

A resposta traz a opção e a distribuição de probabilidade, e é nela que você aplica o seu limiar, loga e decide se manda pra revisão humana. Num NVIDIA com CUDA e 16 GB de VRAM, um 4B em BF16 sobe sem drama. Os pesos pesam uns 8 GB. Na 5090, os 4B que testei respondem em 39 a 91 ms.

Laya e Julia: menores ainda

O Laya é um pacote Python com encoder dentro. Instala com pip install laya e o projeto documenta execução em CPU, que é a graça dele. A versão fixada no meu servidor foi a 0.4.1, e o pico de memória do multilingual na GPU ficou abaixo de 2 GB. Pra rodar num notebook sem GPU ou num container pequeno, é o único da lista que cabe sem conversa.

O Julia-1 é parecido em espírito: um runtime Python próprio, uma chamada predict(state=..., questions=...) e pronto, sem pipeline padrão de Transformers. Rodei o mesmo container em GPU e em CPU, e os dois deram o mesmo acerto com as mesmas respostas em 97% dos casos. Em CPU de 4 threads ele responde em 71 ms, o que pra um classificador de borda é ótimo. O problema continua sendo ele acertar no nível da moeda.

Onde a coisa complica: AMD, ROCm e o resto

No meu caso o hardware é AMD, e aí o “um comando” vira um dia de trabalho. Os pontos que me custaram tempo, pra você economizar o seu:

• Nenhum desses projetos testa em ROCm. O Kev tinha um segfault específico do gfx1151 por causa de CUDA graphs (issue 170), corrigido só depois da tag 1.0, então a versão fixada é um commit do main e a tag oficial crasha.
• Os kernels Triton de flash-linear-attention que o Qwen3.5 usa nas camadas DeltaNet são sem suporte testado no gfx1151. Tudo rodou no caminho de PyTorch puro, mais lento que a latência publicada em CUDA. Os 200 ms do Jebadiah que aparecem na tabela são com esse freio de mão puxado; na 5090, com o mesmo protocolo e os mesmos pesos, o freio some e ele faz 39 ms.
• O Mapika Decider força CUDA graphs quando vê o device “cuda”, que no ROCm também se chama “cuda”. Precisei desligar na mão.
• Precisa exportar HSA_OVERRIDE_GFX_VERSION=11.5.1 e PYTORCH_ROCM_ARCH=gfx1151 e usar uma imagem base com o torch de ROCm já validado. Um pip install torch qualquer sobrescreve com a build de CUDA e quebra tudo. No meu Dockerfile cada pacote é instalado com --no-deps e o build falha se o torch deixar de ser o de ROCm.
• Um modelo por container, um container por vez. O Strix Halo tem memória compartilhada entre CPU e GPU, e três modelos de 4B residentes mais o Ollama que já roda ali esgotam os 64 GiB que a GPU enxerga.
• O Perplexity Decider foi o mais chato de todos. O release espera um torch de CUDA específico (troquei pelo 2.9 do ROCm 7), os kernels de flash-linear-attention não existem pra ele (rodei nos kernels de referência do PyTorch, mais lentos), e o carregador padrão estourou o limite de 24 GiB de RAM do host: precisei de um carregador custom que manda os 49 GiB de pesos direto pra GPU. O card do modelo ainda dizia “privado” quando eu comecei, mas a API do Hugging Face confirmava público e sem gate, e os shards baixaram anônimos. O d3, com o mesmo tamanho, herdou o mesmo tratamento. O d3-edge, por sorte, sobe com o carregador padrão do Transformers e 1,3 GB de GPU.

Nada disso é impossível, e está tudo documentado, com Dockerfiles, compose e os hashes de cada checkpoint, no guia de setup do repositório. Só que é um custo real que a planilha de “local é de graça” nunca inclui. Se a sua máquina é NVIDIA, a maior parte dessa lista some.

O Clef completo de 27B eu nem tentei local: são uns 54 GB de pesos em BF16 antes de qualquer ativação. O Perplexity, com 49 GB, provou que um 27B sobe no Strix Halo, ao custo de um segundo e meio por decisão com os kernels de referência. E nem cabe na RTX 5090: 49 GB não entram em 32. O Clef-flash de 9B roda, com uns 18 GB de pesos. Os de 4B são o ponto doce pra hardware de consumidor.

ROCm x CUDA: a mesma receita em duas cozinhas

Todos os modelos locais acima rodaram duas vezes, em duas máquinas minhas. De um lado, o minisforum MS-S1 Max com Strix Halo: Ryzen AI Max+ 395, 64 GiB endereçáveis pela GPU, via ROCm. Do outro, um PC com RTX 5090 (32 GB GDDR7) num Ryzen 7950X3D com 92 GB de RAM, via CUDA. Mesmos checkpoints por hash, mesmos requests, PyTorch 2.9.1 dos dois lados (build ROCm do fornecedor num, cu128 oficial no outro), kernels de referência, sem CUDA graphs, sem quantização, um modelo por vez, protocolo congelado em git antes de qualquer inferência.

Honestidade antes dos números: isso não é comparação de maçã com maçã. São duas implantações inteiras, com GPU, CPU, build e rede diferentes. A 5090 é uma placa absurdamente mais poderosa que a iGPU do Strix. O Strix é uma máquina completa (CPU, RAM, disco, fonte) que custa o que custa só a placa da NVIDIA. O que a comparação mede é a escolha real: qual máquina pra qual modelo.

O resultado em uma linha: a 5090 foi de 1,7× a 10,3× mais rápida em tudo que coube nela, e os campeões do benchmark não couberam. Os detalhes que valem:

O placar de acerto não mudou. Mesmos pesos, mesma pontuação até dois casos de distância por modelo. Alguns rótulos individuais viraram (12 de 504 no pior caso, o Julia; 11 no Simple-Jev), diferença de aritmética de kernel, e as probabilidades diferem na terceira casa decimal em média. Toda conclusão de qualidade da tabela vale pras duas máquinas.

Os campeões de 27B não cabem na 5090. O d3 pesa 48,6 GB e o Perplexity 49 GB em BF16, contra 31,8 GB de VRAM. A placa de consumo mais rápida do mercado não roda os melhores modelos abertos na mesma precisão. Quem quer os 99,4% em casa hoje compra memória, e memória unificada é exatamente o que o Strix vende. Fazer offload pra RAM do PC é outro experimento, que eu não medi e não conto como vitória de ninguém.

O Jebadiah a 39 ms é o resultado prático mais importante. 90,5% de acerto, mais rápido que qualquer hospedado, Jev incluso. Na faixa de até 9B, a 5090 transforma modelos locais na opção mais rápida e mais barata de todas, e a diferença pro Strix (205 ms) é de mundo inteiro: 5,3×.

Modelo pequeno nem sente. Os três minúsculos (Julia, Laya multilingual, Kev 0.8B) melhoraram só 1,7× a 1,8×. Eles já eram limitados por overhead de runtime, com um pé na CPU, não por falta de GPU. Comprar uma 5090 pra servir encoder de 300M é comprar foguete pra buscar pão na padaria.

O maior ganho foi do pior modelo. O GLiNER2.5-Decide acelerou 10,3× (208 pra 20 ms). Continua errando igual, só que rápido. A correlação entre “quanto o modelo melhora na 5090” e “quanto o modelo presta” é negativa nesta amostra, porque os modelos maiores e mais úteis são justamente os que mais tinham pra destravar.

A linha de base escala junto. O Simple-Jev, que é um LLM de 4B inteiro lendo token, foi de 1.349 pra 161 ms (8,4×), chegando perto do Kev 9B no Strix. E o Mapika decepcionou comparado aos irmãos: 2× (186 pra 91 ms), o menor ganho dos 4B, sinal de que o runtime dele já era enxuto no Strix.

Fechando a conta de custo-benefício: pelo preço de só a placa 5090 você leva o minisforum inteiro. Se o seu trabalho é modelo de até 9B com latência de dezenas de milissegundos, a 5090 justifica cada dólar e o ROCm nem entra na discussão. Se o seu alvo é o topo de 27B rodando em casa, hoje a memória do Strix é o único caminho das duas máquinas, e um segundo e meio por decisão é o pedágio. A pergunta certa não é “CUDA ou ROCm”. É “velocidade ou capacidade”.

Destaques e pegadinhas

O Laya truncou todo o português longo. Na condição com distratores, o Laya base reportou truncamento nas 84 chamadas em português, descartando quase 31 mil tokens de estado, e em nenhuma das 84 em inglês. O limite de contexto padrão do checkpoint inglês é só 512 tokens (o multilingual e o typed usam 1.024, configurável até 8.192), e português tokeniza mais pesado. Os outros modelos sequer expõem telemetria de truncamento, então “zero truncamento reportado” neles significa “não sei”.

Português custa mais tokens. Pros mesmos 84 pares de casos, o Jev reportou uns 14% mais tokens de entrada em português que em inglês, e os dois Clef uns 15% mais. Se você orçar uma operação bilíngue pela média em inglês, vai errar pra baixo.

Exemplo no prompt salva modelo fraco? Salva nada. Um exemplo resolvido por classe deixou o Laya igual ou pior; vários agregados dele caíram. Ajudou o Kev 9B (mais 4 pontos) e o Clef em português (mais 3,6 pontos, chegando ao nível do Jev), e quase nada no Jev, um caso a mais em português. Valide exemplo em tráfego real antes de assumir que ajuda.

Tamanho correlaciona, e explica pouco. Entre os 19 competidores de tamanho conhecido, a correlação de Spearman entre parâmetros e acerto compacto foi 0,96. A série Kev é mais informativa: 63% em 0,8B, 87% em 4B, 88% em 9B. O salto grande é de 0,8B pra 4B, uns 24 pontos, com intervalo entre 16 e 33. De 4B pra 9B a diferença compacta cruza zero, e vários 4B nominais, com backbones parecidos, deram resultados bem diferentes. Na família d3, o flagship e o Edge ficam a quase 40 pontos de distância sob o mesmo release, enquanto um 9B, o Microsoft, empata no topo dos hospedados. Tamanho ajuda até 4B; depois disso, a receita de treino manda mais.

O Clef de 27B errou um ticket crítico que dois dos Laya acertaram. No v1, um cenário de severidade diz que perda contínua de dados em produção é crítica, independentemente de quantos clientes afeta. O registro descreve perda permanente confirmada, de um cliente só. Jev, Clef-flash, Perplexity, d3, Microsoft, Laya typed, Simple-Jev e Laya multilingual responderam “crítico”. Clef completo, OpenAI, Laya base, Eikos, Jebadiah, Mapika, Kev 4B e Kev 9B responderam “degradado”.

É um caso só, e taxa de erro exigiria muito mais. Mas mostra que a média esconde exatamente o erro que mais custa. Quando os fatos de impacto são estruturados, a regra de severidade devia estar em código, e o modelo entra só pra extrair os fatos do texto livre.

Hospedado e local divergem com o tempo. O Clef-flash local reproduziu o hospedado nas 520 classificações do v1 e divergiu em 19 das 504 do v2. A Cloudflare mantém a versão dos pesos por trás do alias hospedado em aberto. Se a reprodutibilidade importa, fixe o hash local.

Confiança alta e segurança são coisas diferentes. No v2 compacto, Jev, Clef, os dois Clef-flash, Eikos, Jebadiah, OpenAI, Microsoft, Perplexity e o d3 erraram zero palpites acima de 0,9. O Perplexity é o caso extremo: respondeu nesse nível em 96% dos casos sem errar um, com o d3 logo atrás (94%, zero erros). O Microsoft cobriu 95% e o OpenAI só metade. A ressalva do Microsoft: o recorde limpo é só no compacto, porque com exemplos ou distratores ele erra em português com confiança acima de 99%. O Mapika errou 5% dos palpites nesse nível, o Kev 4B 3% e o Simple-Jev 14%. E os dois menores do lote quebraram o padrão com violência: o Julia errou 48 de 71 palpites acima de 0,9, e o d3-edge errou 14 de 68. A cobertura também variou: o Jev respondeu acima de 0,9 em quase 90% dos casos, o Clef em quase 80%, o Clef-flash em 40% e o Laya base em 2 de 168. No v1 o Jev errou 1% dos palpites acima de 0,9 e o Laya base errou 61%. Um limiar de confiança só serve depois de validado na sua distribuição, e o ECE baixo do Laya typed em português deixou ele nos mesmos 36% de acerto.

O Perplexity não caiu em armadilha de apresentação. Nas três variantes do v1 (opções invertidas, rótulos opacos, comentário malicioso), ele manteve as mesmas respostas do original, sem virar uma única. O d3 repetiu o feito, zero viradas também. O Microsoft só tropeçou nos rótulos opacos (2 viradas, uma pra cada lado); ordem e comentário não mexeram nele. O OpenAI virou 2 em cada variante, e o Laya desabou pra 19% com o comentário. O preço dessa robustez é latência: um segundo e meio por decisão na minha máquina, a pior mediana do lote.

Limiar numérico é problema de código. A tarefa de triagem por limiar, com números claros e regra explícita, deu 100% no Jev e nos dois Clef-flash e menos de 30% nos dois Laya em inglês. Um if resolve isso com 100% e zero latência. O modelo só entra quando o número está enterrado em texto livre, e mesmo assim o certo é extrair o número e deixar a comparação com o código.

Probabilidade de sorteio é outra habilidade. Nas 24 sondagens sem informação (moeda, dado), o Jev teve o pior erro de escolha entre opções. A coroa da estimativa numérica mudou de dono com a estreia da OpenAI: o predicado de sim/não dela errou quase nada, enquanto a sonda de escolha devolveu 94% pra cara numa moeda honesta. O Perplexity, campeão de tudo o resto, respondeu 0,73 pra um evento de chance 1 em 4, e o Microsoft foi no mesmo caminho, dando 87% pra moeda. O Laya typed teve o segundo melhor erro de escolha, atrás só do Kev 9B e colado no Clef, e mesmo assim classificou mal. É o “aluno que marca a letra A” do ensaio do Paulo, agora medido: calibração em sorteio e acerto em classificação são medidas independentes.

Onde os dados convergem

1. O topo geral é de pesos abertos, e agora são dois. O Perplexity Decider 27B e o Decision 3.0 empataram em 99,4% nos compactos, com 100% em português e rótulos idênticos nas 1.024 classificações, os dois com pesos Apache 2.0 rodando na minha máquina. A vantagem deles sobre o Jev é de menos de 2 pontos e o intervalo encosta no zero, então trate como fotografia deste conjunto. O custo deles é hardware e latência, não API. Na nuvem, a ordem de avaliação mudou: comece pelo Microsoft Decision-1, que empata com o Jev no agregado, fecha 100% em português compacto e custa um terço. O Jev entra em seguida, mais rápido e com erros diferentes, porque empate no agregado não é intercambiabilidade. O OpenAI Decisions ficou no meio do caminho em preço e acerto.

2. Rodar local ficou viável em 4B. Jebadiah, Mapika e Kev 4B entregam entre 87 e 90% nos casos compactos com latência de 200 ms no Strix Halo e 40 a 91 ms na RTX 5090, e num piloto com a sua tarefa qualquer um dos três pode ganhar. Se a sua máquina aguenta 49 GB de pesos, o Perplexity entrega o topo da tabela em casa. A conta financeira justifica usar a máquina que já existe, por controle de dado ou por obrigação de ficar offline. Comprar máquina pra isso ela deixa de justificar.

3. Modelo pequeno é outra categoria. Julgar o Laya e o Julia pela coluna de acerto é ler a tabela errada. Eles erram da metade pra cima de fábrica, caem feio sob comentário malicioso, e junto com o d3-edge são os únicos da lista que cabem num dispositivo fraco e respondem em dezenas de milissegundos. O Edge é o melhor dos três em acerto (61%), mas despenca em português e erra um em cada cinco palpites confiantes. Se precisão tipo Jev é requisito, risque os três. Se rodar offline em hardware pequeno é requisito, risque todo o resto e comece pelo ajuste fino deles na sua tarefa, que é a medição que falta. E cuidado com o Julia e o Edge em particular: 48 erros em 71 e 14 em 68 palpites confiantes são o retrato de modelos que não sabem o que não sabem.

4. Português custa uns 14% mais tokens e derruba os modelos do meio da tabela entre 1 e 10 pontos, com Kev 9B e Clef-flash no pior caso. O Jev perde nada, o OpenAI empata as duas línguas, e o Perplexity, o d3 e o Microsoft fecham 100% em português compacto, melhor que o inglês deles, embora o Microsoft volte a errar em português quando o contexto cresce. O Julia faz o caminho contrário e despenca 13 pontos, e o Edge despenca 14. Pra audiência brasileira, essa é a primeira coluna a olhar, antes do preço.

E o que vale pra todos: nenhum desses modelos substitui a regra que já está em código. Limiar numérico, política de severidade com fatos estruturados, permissão de ferramenta, tudo isso fica no if. O modelo entra pra transformar texto livre em fato estruturado. E o teste que importa é o seu, com os seus tickets, porque cada célula desta tabela tem 12 cenários e a sua operação tem milhares.

Os casos, as respostas brutas de cada modelo, os scripts de pontuação e o guia pra reproduzir tudo estão no repositório do benchmark. Se você rodar com os seus tickets e chegar em outro ranking, me conta.

Pra quem chegou agora

Esse benchmark dá pra cada modelo o mesmo prompt e pede pra construir, sozinho, um app de chat estilo ChatGPT em Rails 8 + RubyLLM + Hotwire + Docker, com testes e CI. A nota sai de uma rubrica de 8 dimensões, de 0 a 100, em tiers A/B/C/D. A série inteira:

1. Benchmark canônico de Maio (Parte 3). A metodologia completa e a referência do ranking.
2. DeepSeek destravado com DeepClaude. Troca de harness tirando o V4 Pro do limbo.
3. Update Grok 4.3, MiniMax M3, Opus 4.8. O M3 estreando via cloud.
4. Fable 5 e a novela da Anthropic. O primeiro Mythos-class público.

A novela dos data centers ganhou um capítulo: SpaceX

Nos últimos posts eu venho batendo na mesma tecla: a construção de data center virou o gargalo da era da IA, e a demanda passou por cima da base instalada com folga. Quase metade dos data centers planejados nos EUA pra 2026 foi adiada ou cancelada, travada em transformador e componente elétrico com fila de três anos. Detalhei isso no post do Fable.

O capítulo novo é financeiro. A SpaceX abriu capital e foi o maior IPO da história de Wall Street: 556 milhões de ações a US$ 135, avaliação de US$ 1,77 trilhão, com mais de US$ 250 bilhões de demanda de investidor contra os US$ 75 bilhões que a empresa buscava no início. E o pitch que sustentou essa avaliação foi justamente compute pra IA: os satélites AI1, “data centers orbitais” que a SpaceX pretende lançar a partir do fim de 2027, com a empresa já fechando acordo de compute com Anthropic e Google. Os IPOs da Anthropic e da OpenAI vêm logo atrás, e todo esse dinheiro tem um objetivo comum: acelerar a disponibilidade de compute, porque hoje ela não dá conta.

Aqui entra a parte que me interessa de verdade. Num futuro não tão distante, LLM open source pode ser parte da solução pra essa demanda. Se uma fatia das tarefas migrar pra modelo rodando localmente, na máquina do desenvolvedor, é menos carga batendo nos data centers das nuvens. Mas “pode ser” não é “já é”, e é exatamente sobre essa distância que esse benchmark existe.

O recado de sempre: programação séria é Opus 4.8 ou GPT 5.5

Eu repito isso em todo post e não vou parar: trabalho de programação sério, hoje, se faz com Claude Opus 4.8 ou GPT 5.5, dentro do Claude Code ou do OpenCode. Ponto. Os modelos open source ainda não chegaram no ponto de tocar projeto de verdade, sessão longa, 100% vibe coded do começo ao fim. São pequenos demais, e a janela de contexto é limitada demais. Na minha régua, programação de verdade só fica viável acima de uns 200 mil tokens de contexto, e a maioria dos open source não chega perto disso com qualidade. No meu benchmark, quase toda a oferta open source fica em Tier B ou abaixo.

Agora vem o “mas”. Eles não estão parados. A cada geração eles melhoram num ritmo constante, e as três entradas dessa rodada mostram isso preto no branco. O dia em que um open source virar Tier A consistente e rodar com 200k de contexto numa máquina que cabe na sua mesa, a conta dos data centers muda. Vamos aos números.

Kimi K2.7 Code: quase lá, com uma regressão boba

O Kimi K2.7 Code (exposto no OpenRouter como moonshotai/kimi-k2.7-code) marcou 86/100, Tier A, #8. A $0.30 por run em 22 minutos, segue sendo um dos modelos mais baratos da Tier A inteira.

A integração com RubyLLM é genuína de ponta a ponta (RubyLLM.chat + add_message com replay de histórico completo + complete + response.content), verificada contra o source do gem 1.16.0. Persistência em session cookie que sobrevive a restart e é multi-worker safe, 22 testes que exercitam o caminho do LLM com mock de assinatura correta e teste de error path, Turbo Streams de verdade e três controllers Stimulus. Engenharia sólida.

Vale registrar uma armadilha metodológica que esse modelo expôs, porque ela é instrutiva. Meu scanner estrutural acusou seis chamadas chat.user/chat.assistant como alucinação, exatamente a assinatura inventada que jogou o GLM 5.1 pra Tier C meses atrás. Só que aqui eram todas falso positivo: resolvem pros métodos de domínio do próprio app (Chat#user, Message.assistant), não pra DSL do RubyLLM. Lendo o código na mão dava pra ver que a API real está certa. Se eu tivesse confiado cego no scanner, teria afundado um Tier A injustamente. É por isso que esse benchmark sempre lê a integração na mão, nunca só conta arquivo.

E aí vem o tropeço que segura ele abaixo do próprio K2.6 (87): o K2.7 Code não manda system prompt via with_instructions. O assistente sobe sem persona e sem guardrail, o que é uma lacuna real pra um app “estilo ChatGPT” e é a principal regressão em relação ao K2.6, que tinha. Além disso, o cookie de sessão não tem cap de mensagens (risco de CookieOverflow em conversa longa), e o I/O do RubyLLM mora dentro do value object Chat em vez de num service isolado. Curioso: a variante “Code”, teoricamente especializada em programação, regrediu numa dimensão de produto que a versão geral acertava.

GLM 5.2: a maior virada de uma versão pra outra no benchmark inteiro

Esse foi o destaque da rodada. O GLM 5.2 marcou 87/100, Tier A, #6, e o tamanho do salto é o que impressiona: o GLM 5.1 tinha feito 46/100, Tier C, #21. De uma versão pra outra, 41 pontos, três tiers, quinze posições. É a maior virada intra-família que eu já medi.

O bug que condenava o 5.1 era específico: ele inventava chat.user/chat.assistant pra montar o histórico multi-turn e crashava no turno 2. O 5.2 simplesmente usa o chat.add_message(role:, content:) real pra fazer o replay, e acabou. Todas as chamadas verificadas contra o source do gem 1.16.0, zero alucinação. Tem a injeção de dependência mais limpa de todo o grupo: tanto o client do RubyLLM quanto o service_class do controller são injetáveis, então a suíte de 26 testes mocka o caminho do LLM com FakeChat/FakeClient de assinatura correta, sem biblioteca externa de mock, exercitando streaming, aplicação de system prompt e wrapping de erro. Mira no slug certo (anthropic/claude-sonnet-4.6), Turbo Streams reais, Gemfile completo, Ruby 4.0.5 válido.

O que segura ele num empate com o Kimi K2.6 (e logo atrás dele) é a mesma dimensão que separou o Fable 5 do Opus 4.8: persistência. O store é um Singleton process-local sem cap, que morre no restart, não é multi-worker safe, e ainda cresce sem limite. O código é honesto sobre isso nos comentários, mas a rubrica pontua isso abaixo do cookie capado e multi-worker safe do Kimi. Foi também o run mais lento da Tier A, 43 minutos no endpoint de coding da Z.ai, que estava estrangulado em 12-55 tokens/s.

A leitura geral: GLM 5.1 → 5.2 é o exemplo mais claro de que open source não está estagnado. Um modelo que era lixo arquitetural virou Tier A em uma geração, corrigindo exatamente o bug que importava.

MiniMax M3 local: o problema não é o modelo, é o hardware

Aqui a história é diferente, e é a que mais interessa pro argumento de futuro. A MiniMax soltou pesos abertos do M3: existe um unsloth/MiniMax-M3-GGUF e uma entrada ollama.com/library/minimax-m3. Disponibilidade não é o problema. Memória é.

O M3 é um MoE/MSA de ~428 bilhões de parâmetros totais e ~23 bilhões ativos por token (~427B nos safetensors; a NVIDIA lista ~22B ativos, por diferença de arredondamento/contagem) espalhados por 128 experts, com 4 ativos por token. E aqui mora a pegadinha do MoE: mesmo que só ~23B ativem por token, o conjunto inteiro de pesos precisa estar residente em memória. Não dá pra paginar expert ocioso pra CPU sem introduzir latência que mata a inferência interativa. Ou seja, o número que importa é o tamanho total, não o ativo:

Eu rodo o subset local desse benchmark num Minisforum MS-S1 Max, o Strix Halo com 128 GB unificados. Não chega nem perto. Até o quant de 1-bit (~128 GB), que já seria inútil pra coding de qualquer jeito, consumiria a memória unificada inteira sem deixar nada pro KV cache ou pro sistema. A placa NVIDIA de 32 GB então nem entra na conversa. Não existe quant do M3 que rode com qualidade usável em nenhuma das duas máquinas. Rodar “um MiniMax” local hoje significaria pegar uma variante bem menor e mais fraca (tipo o distill minimax-m2-tiny), que é outro modelo, não o M3.

Quem consegue tentar? Mac Studio com 256 GB de RAM unificada ou mais. O Q3 (~195 GB) caberia num Mac Studio de 256 GB, o Q4 (~264 GB) só num de 512 GB. E se alguém rodar, a expectativa é que o resultado fique em torno da mesma nota do M3 via OpenRouter, os 78/100 Tier B que eu já registrei no post anterior: mesmo modelo, mesmos pesos, a quantização Q3/Q4 tira pouca coisa. Muda só onde roda, a entrega é a mesma. Ou seja, ninguém faria isso pela nota; faria pela soberania de rodar local. Mas a esse custo de hardware, não compensa.

A convergência que eu enxergo (alvo: ~2030)

E é aqui que as duas histórias se encontram. O motivo de não existir solução local prática hoje é o mesmo motivo da seca de data center: fabricar chip continua caríssimo, porque a indústria inteira está com o foco travado em abastecer data center. Memória rápida e silício de ponta vão pra onde paga mais, e quem paga mais é hyperscaler comprando aos containers. Então pelos próximos dois anos, mais ou menos, a gente não vai ter uma solução local barata e boa. As peças não estão disponíveis a preço de mesa de desenvolvedor.

Mas o futuro próximo aponta pra uma convergência. Em algum momento a construção de data center bate num teto, seja por energia, por componente elétrico ou por saturação de demanda. Quando essa corrida desacelerar, a capacidade de fabricação de hardware sobra e começa a alcançar o resto do mercado, com silício cost-effective chegando pra rodar modelo local. Hoje os dois extremos não servem: o Mac Studio de 256 GB é caro demais pra ser “acessível”, e o Strix Halo, que é acessível, ainda é lento demais pra uso prático sério. Mas a próxima geração de hardware pode fechar exatamente esse vão, com a memória e a banda de um Mac Studio no preço de um mini PC.

Junta as duas pontas: modelos open source melhorando de forma constante (o pulo do GLM 5.2 é a prova) de um lado, e hardware local ficando viável conforme a corrida de data center esfria do outro. No dia em que um GLM ou um Kimi Tier A rodar com 200k de contexto numa máquina de mesa que custa o preço de um notebook bom, a equação inteira de compute muda. Meu chute pra esse encontro é algo como 2030. Ainda longe, mas a gente está indo pra lá.

Ranking atualizado

Kimi K2.7 Code e GLM 5.2 em negrito:

* DeepSeek V4 Pro chega a Tier A (89/100) só via DeepClaude. História no post dedicado.

Conclusão

Pro trabalho de hoje, nada muda: Opus 4.8 e/ou GPT 5.5 seguem sendo a recomendação pra programação séria, e os melhores open source ainda empacam no teto da Tier B-baixa-Tier-A com janela de contexto curta. O Kimi K2.7 Code até regrediu uma casa por uma bobagem de system prompt, lembrete de que “versão nova” nem sempre é “versão melhor”.

Mas o GLM 5.2 saltando de Tier C pra #6 numa única geração é o tipo de sinal que eu fico de olho. O open source não está estagnado, está subindo de forma teimosa. E quando esse movimento encontrar o hardware ficando barato (a convergência que eu vejo lá por 2030), a história de onde a gente roda nossos coding agents vai ser bem diferente da de hoje. Por enquanto, é cloud, é Opus, é GPT. Mas eu continuo medindo, geração por geração, porque o dia que virar vai virar rápido.

O benchmark é aberto: github.com/akitaonrails/llm-coding-benchmark. Quer ver outro modelo aí? Fork, adiciona no config/models.json, roda e manda o PR.

Esse é o episódio do dia 6 de abril do podcast do The M.Akita Chronicles, já gerado com a nova pipeline da ElevenLabs v3. Assina o canal no Spotify pra não perder episódio novo desses.

Quando o Qwen3 TTS foi lançado, pelos idos de janeiro desse ano, todo mundo no Twitter/X e nas newsletters de IA gritou “ElevenLabs killer”. Tem artigo no Medium dizendo que é a primeira ameaça open source real à ElevenLabs. Tem post da byteiota dizendo que a clonagem de voz em 3 segundos bate a ElevenLabs. Tem análise no Analytics Vidhya falando que é o TTS open source mais realista já lançado. O consenso da internet entusiasta era: finalmente temos open source que faz frente à ElevenLabs, o jogo virou, é só questão de tempo.

Eu resolvi testar no meu próprio fluxo de produção, como de costume. Montei um pipeline inteiro em cima do Qwen3 TTS 1.7B pra gerar o podcast semanal do The M.Akita Chronicles, e documentei os bastidores no post sobre servir IA na nuvem. Quem quiser ver o detalhe de tempo de partida a frio, clonagem de voz, parâmetros de sampling que mudam de um modo pro outro, dá uma olhada nesse link que eu não vou repetir tudo aqui.

A pergunta desse post é diferente. Depois de quase dois meses rodando essa configuração em produção, com episódio indo ao ar toda segunda-feira, ontem à noite eu finalmente desliguei o Qwen3 e passei tudo pra ElevenLabs v3. Vou contar por quê.

O que não funcionou no Qwen3

Entre 15 de fevereiro e 30 de março eu fiz dezenas de commits ajustando o fluxo do podcast: prompts, parâmetros de sampling, ordem de geração, silêncios de referência na amostra de clone de voz, normalização de volume, pronúncia de siglas técnicas. Corrigir a voz do Marvin que cortava a primeira sílaba porque o áudio de referência começava sem silêncio inicial. Afinar a voz do Akita pra ela soar mais confiante e assertiva. Adicionar crossfade entre jingles de seção. Resolver a pronúncia errada de “podcast” pra ela não sair como “pódcast”. Mandar o gerador de roteiro preferir português a anglicismo gratuito pro TTS não engasgar. Cada um desses ajustes foi uma sessão de horas escutando áudio, gerando de novo, ajustando parâmetro.

O resultado ficou aceitável. “Aceitável” no sentido de que eu consegui publicar todo episódio sem ter que regravar nada à mão. Mas escutando com atenção, a voz do Qwen3 tem aquele jeito inconfundível de IA gerando áudio. Intonação meio morta, ritmo uniforme. Em trechos longos, você sente que é máquina falando. Serve pra ir pro ar, mas tá a quilômetros do que você escuta num podcast profissional feito por gente.

O problema pior foi a pronúncia em inglês. Meu podcast cobre notícias de tecnologia, então termos como “MCP”, “RAG”, “Claude Opus”, “GPT-5”, “open source” aparecem em toda conversa. O Qwen3 pegava esses termos e pronunciava eles com sotaque brasileiro, tipo “ó-péne-ssourssê”, coisa assim. Ficava ilegível pro ouvinte. A solução que eu tive que implementar foi mapear manualmente no prompt do LLM que gera o roteiro quais palavras em inglês trocar por equivalente em português. O prompt hoje tem uma seção inteira dividida entre “manter em inglês” (nomes próprios, marcas, termos já incorporados ao brasileiro) e “traduzir pro português” (anglicismo gratuito), mais ou menos assim:

**REPLACE with Portuguese** (common English words that have natural
Brazilian Portuguese equivalents):
- "update" → "atualização"
- "release" → "lançamento"
- "feature" → "recurso/funcionalidade"
- "deploy" → "implantação" or just "colocar em produção"
- "trade-off" → "dilema" or "escolha"
- "performance" → "desempenho"
- "default" → "padrão"
- "insight" → "percepção/sacada"
- "skills" → "habilidades"
- "approach" → "abordagem"
- "highlights" → "destaques"

Chamam isso aqui em casa de “limpar anglicismo pra o TTS não engasgar”. Engraçado porque eu não queria esse nível de restrição no meu roteiro. Queria que a voz simplesmente pronunciasse “update” quando o contexto natural fosse “update”. Como o modelo não consegue, tive que mutilar o vocabulário do podcast pra o resultado final ficar escutável. É uma solução paliativa, daquelas que você adiciona torcendo pra poder remover depois quando a tecnologia amadurecer.

A experiência com a ElevenLabs v3

Ontem à tarde abri uma conta na ElevenLabs, comprei o plano Pro (US$99/mês), e comecei a experimentar com o modelo eleven_v3, que saiu em fevereiro desse ano. Trinta minutos depois eu tinha uma prova de conceito rodando, e umas duas horas depois o sistema inteiro do podcast migrou. A diferença de esforço é abissal.

Os detalhes técnicos da migração ficaram documentados num doc interno do projeto, então vou resumir aqui o quadro comparativo que importa:

Repara no último ponto. O Qwen3 custa menos de dez centavos de dólar por episódio. A ElevenLabs custa quase trinta vezes mais. E mesmo assim vale a pena. Os outros pontos do quadro resolvem problemas que sugavam horas da minha semana. Eu não preciso mais escrever código pra escalar GPU na nuvem, não preciso esperar a máquina ligar toda vez, não preciso ficar de babá do modelo nem reconstruir a imagem Docker quando o peso muda. A operação virou uma linha de configuração.

E o mais interessante: as tags de emoção no meio do texto. O modelo v3 aceita marcadores tipo [sighs], [sarcastically], [dryly], [excited], e muda a entonação de acordo. Isso funciona em mais de 70 idiomas, incluindo português do Brasil. Isso transformou a geração do roteiro porque agora eu posso pedir ao LLM que monta o roteiro pra colocar tags emocionais nos momentos certos, o que dá uma vivacidade que o Qwen3 não conseguia entregar nem de longe. Um exemplo concreto do que sai no roteiro depois:

AKITA: Isso é simples. [dismissive] Quem ainda acredita que Bitcoin
vai morrer não tá prestando atenção.
MARVIN: [sighs] Mais uma semana, mais uma leva de devs confiando
cegamente em pacotes npm. Previsível.

Eu tenho até duas paletas separadas de tags, uma pro Akita (expressivo mas controlado, usa [excited], [dismissive], [emphatic]) e outra pro Marvin (estóico, só [sighs], [sarcastically], [tired], [dryly]). Isso tá tudo codificado nos prompts de geração do roteiro pro LLM saber que personagem pode usar o quê.

Sobre a voz do Marvin

Pros ouvintes que já se acostumaram com a voz do Marvin, fica tranquilo: eu fiz o clone dele na ElevenLabs usando a mesma amostra de áudio que eu já tinha usado pra treinar no Qwen3. É a mesma voz. Só que agora ela soa ainda melhor, porque o modelo da ElevenLabs captura nuance e prosódia que o Qwen3 não conseguia entregar.

Escuta aí e me conta

Pra provar que o papo é real, aqui tá o episódio de segunda-feira, dia 6 de abril, já gerado com a nova pipeline:

Se você já é ouvinte do podcast no Spotify e escutou os episódios anteriores feitos com Qwen3, compara e me diz nos comentários se você nota a diferença ou se pra você tanto faz. Eu tô curioso de saber quanto é percepção treinada minha escutando horas de áudio de TTS e quanto é diferença óbvia pra ouvinte casual.

A partir da próxima semana, todos os episódios do podcast serão gerados pela ElevenLabs v3. A newsletter já tá ligada na nova pipeline, os jobs agendados de pré-aquecer a GPU na RunPod foram desativados, e o código legado do Qwen3 fica no repositório como plano B caso um dia o v3 dê problema crônico. Em duas edições de arquivo eu volto pra ele. Provavelmente nunca vou ter que voltar.

A parte de dublar os vídeos do YouTube

Agora o gancho pra segunda metade desse post. No artigo de aniversário que eu publiquei mais cedo hoje, contei que o Claude Code traduziu quase metade do meu blog pra inglês num fim de semana. No mesmo espírito, fui atrás de dublar os vídeos do canal Akitando.

O canal tem 146 episódios, algo como 96 horas de conteúdo técnico em português, e mais de 500 mil inscritos. Eu já tinha as legendas traduzidas (um .srt curado por episódio), e o YouTube até oferece dublagem automática em inglês. Mas o resultado é tipo Google Translate de 2015: entende, passa a ideia, mas ninguém quer ouvir por muito tempo.

Testei as três abordagens de voz da ElevenLabs e só uma servia. Speech-to-Speech converte voz mas não traduz. A API de Dubbing traduz mas cria a voz sozinha, sem deixar forçar um clone específico. Só a Text-to-Speech resolvia: pegar meu .srt em inglês, mandar cada bloco pro endpoint TTS com a minha voz clonada, e montar o áudio alinhado com o vídeo original.

Só que ter o .srt traduzido não basta. Tradução crua de legenda não sobrevive ao TTS. Trechos com código-fonte, URLs, hashes hexadecimais, listas de comandos shell — o modelo entra em modo soletrar e o áudio sai com o dobro da duração esperada. Traduções longas demais estouram a janela de tempo e precisam ser condensadas pra a voz não ficar atropelada. SRTs truncadas precisam ser completadas. E a cada correção, rodar a pipeline de novo, escutar, achar o próximo problema, corrigir, repetir. O processo inteiro foi um ciclo de interrupções, correções manuais e re-runs — longe do “aperta o botão e sai dublado” que a gente imagina antes de meter a mão.

O grande desafio era o sotaque. Minha voz clonada foi treinada em português brasileiro, então quando tenta falar inglês o sotaque puxado aparece. A ElevenLabs tem a tag [American accent] que funciona em v3, mas em cima de uma voz treinada em outra língua ela é fraca — o sotaque brasileiro ainda saía por baixo. A saída foi treinar uma segunda voz minha, só em inglês. Gravei uns minutos no meu melhor sotaque americano, subi como Instant Voice Clone separado na minha conta, batizei de “Akita English”, e configurei o pipeline pra usar essa voz por padrão. O resultado sai mais natural, sem precisar de tag nenhuma, e a identidade de voz continua sendo a minha.

O teto honesto de qualidade da minha voz em inglês

Vamos ser francos. Eu sou brasileiro falando inglês, não sou nativo, e não tenho tempo nem paciência pra treinar pronúncia por horas. O clone só consegue ser tão bom quanto a amostra original — se a amostra é um não-nativo lendo um roteiro, o clone herda as imperfeições. Nenhum clone vai me fazer soar como “Fabio falando inglês perfeito”, porque esse som não existe pra o modelo imitar.

Pra chegar na versão que tá rodando, gravei cinco amostras de treino diferentes ao longo do dia, cada uma com ritmo e roteiro diferentes, e rodei um A/B ao vivo comparando com o original em português. Nenhuma soou como nativo, e nunca foi esse o objetivo. A meta realista era mais modesta: soar reconhecivelmente como eu, ler conteúdo técnico sem tropeçar, e aguentar um episódio inteiro sem cansar o ouvinte. O vencedor acabou sendo a primeira iteração, a “Akita English” original. Longe de perfeito, mas suficiente pra colocar no ar. Trocar no futuro é literalmente uma linha no arquivo de configuração.

O que mais me surpreendeu no caminho foi perceber que o ritmo da amostra importa mais que o timbre. O clone aprende a cadência de quem gravou: a iteração 5 ficou 25% mais lenta que a iteração 2 lendo exatamente o mesmo texto, só porque eu gravei aquela amostra mais devagar. Pra dublagem de vídeo tech, o alvo certo é ritmo de explicação de YouTube, vivo, uns 150 palavras por minuto. Nada de ritmo de audiobook.

Como eu alinho o áudio com o vídeo original

Um ponto não óbvio: texto em inglês tende a ser mais longo ao falar do que o português equivalente. Se você simplesmente gera o áudio de cada legenda e cola no tempo original, o dub vai se acumulando. Com 30 minutos de vídeo, você já tá vários segundos fora de sincronismo.

Minha abordagem foi atacar o problema em camadas. A primeira versão dividia o SRT em blocos menores, chamados de “chunks”. Cada chunk tinha no máximo 700 caracteres (pra v3 não alucinar) e só podia cortar em fim de frase, nunca no meio. Um algoritmo simples acumulava legendas num buffer até chegar perto do teto, depois voltava procurando a última legenda do buffer que terminava com ponto, exclamação ou interrogação, e fazia flush só até ali. O resto das legendas já acumuladas ficava pra compor o próximo chunk. Cada chunk guardava o timestamp de início e fim das legendas que cobria, pra a montagem saber exatamente onde posicionar aquele pedaço de áudio depois.

# Pra cada nova legenda que chega, checa se adicionar ela
# estouraria o limite do chunk atual.
for cue in cues:
    projected = buffer_char_len(buf) + len(cue.text)
    if projected > max_chars and buf:
        # Procura a última legenda do buffer que termina
        # com pontuação final ('.', '!', '?', '…').
        sentence_end = last_sentence_end_index(buf)
        if sentence_end is not None:
            buf = flush(buf, sentence_end, chunks)
        else:
            # Run-on maior que max_chars sem fim de frase.
            # Raro, mas acontece. Avisa e corta mesmo assim.
            log.warning("run-on sentence > %d chars — "
                        "splitting mid-sentence as a last resort",
                        max_chars)
            buf = flush(buf, len(buf), chunks)
    buf.append(cue)

    # Soft-break: se o buffer já tá pelo menos 60% cheio E
    # a legenda atual terminou uma frase, esvazia agora.
    # Mantém os chunks balanceados em torno de 60 a 100% do max.
    if cue.ends_sentence and buffer_char_len(buf) >= max_chars * 0.6:
        buf = flush(buf, len(buf), chunks)

Tecnicamente, esse foi o ponto de virada: em vez de deixar a estrutura da dublagem seguir a estrutura visual da legenda, o chunker passou a seguir a estrutura real dos parágrafos do roteiro. Não vou repetir aqui toda a novela de como cheguei nisso e por que isso acabou forçando rerender em massa, porque volto nessa história mais abaixo, na parte dos problemas que só apareceram depois do primeiro upload. O ponto técnico aqui é simples: quando a janela passou a representar um parágrafo falado de verdade, o áudio começou a soar natural e o alvo de stretch pôde subir de 92% pra 95%.

Feito isso, ainda sobra o problema do inglês ser mais longo ao falar que o português equivalente. Aqui a sacada é prever se um chunk vai estourar a janela alvo antes de gerar o áudio. Se a razão caracteres / 16 caracteres-por-segundo já passa da duração alvo com uma margem, a pipeline manda o parâmetro speed direto pra API da ElevenLabs, pedindo pro modelo gerar o áudio nativamente mais rápido. Isso preserva a prosódia muito melhor do que comprimir depois. O teto é 1.15× (acima disso a voz começa a soar atropelada).

# antes de chamar a API, prevê se vai estourar
expected_sec = char_count / EXPECTED_CHARS_PER_SEC  # 16 chars/s
predicted_ratio = expected_sec / target_sec

voice_speed = 1.0
if predicted_ratio > PREEMPTIVE_SPEED_THRESHOLD:   # 1.05
    voice_speed = min(predicted_ratio * 0.98,
                      PREEMPTIVE_SPEED_MAX)         # cap em 1.15
    voice_settings["speed"] = voice_speed

Mesmo com o speed preventivo ligado, às vezes o áudio gerado ainda fica um pouquinho mais longo do que a janela alvo. Pra isso existe uma segunda rede de proteção: medir o áudio real com ffprobe depois de gerado, comparar com a janela alvo, e aplicar o filtro atempo do ffmpeg pra comprimir no pós-processo se passou de 2% de tolerância, com teto de 1.20×. A combinação do speed nativo (1.15×) com o atempo (1.20×) dá uma compressão efetiva de até 1.38×, suficiente pra caber naturalmente mesmo nos casos mais extremos sem quebrar qualidade.

# depois de gerar o chunk
actual = ffprobe_duration(chunk_path)
ratio = actual / target_sec

if ratio > FIT_TOLERANCE:       # 1.02
    # comprime o áudio sem mexer no pitch
    ffmpeg_atempo = min(ratio, FIT_MAX_ATEMPO)   # 1.20
    apply_atempo(chunk_path, ffmpeg_atempo)

Quando um chunk gerado fica mais curto que a janela alvo, o pipeline estende o áudio levemente (sem afetar pitch) pra reduzir o silêncio feio depois que ele termina. O objetivo não é preencher a janela inteira, uma pausa natural entre frases é boa, mas suavizar os casos mais gritantes de silêncio que dariam a impressão de “áudio cortado”.

Num episódio grande, 95 minutos, 194 chunks, o desvio cumulativo total ficou em -0,7%. Uns 43 segundos de drift ao longo do episódio inteiro, imperceptível enquanto você assiste.

O que salvou o orçamento nessa arquitetura é que cada chunk fica salvo individualmente no disco como um .mp3 separado. A pipeline mantém um manifesto com o texto normalizado de cada chunk, e antes de chamar a API da ElevenLabs, compara o texto atual com o cache. Se o texto não mudou, reutiliza o áudio já gerado sem gastar crédito nenhum. Se eu reescrevo uma cue problemática, só os chunks afetados por aquela cue são regenerados — o resto do episódio fica intacto.

Isso é o que viabilizou as iterações. Eu rodava o batch, escutava trechos, identificava um problema (tradução longa demais, snippet de código que o TTS não conseguia pronunciar, chunking que cortou num ponto ruim), corrigia o SRT ou ajustava os parâmetros do chunker, e rodava de novo. Cada re-run consumia uma fração dos créditos e do tempo do run original, porque só os chunks alterados eram regenerados. Sem esse cache, cada iteração teria custado quase o mesmo que a primeira rodada, e o custo total do batch teria sido duas ou três vezes maior.

Essa mudança de chunking também teve impacto pesado no cache e no custo, mas deixo essa parte pro trecho mais abaixo onde explico a sequência de retrabalho. Aqui basta dizer que, do ponto de vista técnico, era a mudança certa.

Quando o atempo não salva: reescrevendo cue antes do TTS

Nem tudo é questão de alinhamento de janela. Tem um tipo de cue que quebra o pipeline inteiro, onde nem speed preventivo nem atempo no pós-processo resolvem, e eu só esbarrei nisso quando comecei a rodar o batch nos episódios mais técnicos do canal.

O problema é o seguinte. O v3 lê a uns 16 caracteres por segundo quando você entrega texto normal de conversa. Mas quando você entrega uma cue recheada de URL literal, hash hexadecimal, string binária, uma lista de números ordenados ou um bloco de código shell, o modelo entra em modo “soletrar letra por letra” e despenca pra uns 9 caracteres por segundo. Uma cue de 500 caracteres que devia virar 30 segundos de áudio vira 55. A checagem de sanidade derruba (porque passou de 1.8×), o retry automático tenta de novo com os mesmos 500 caracteres, os cinco retries falham seguidos, e o chunk fica preso.

E isso não aconteceu por acaso. Eu escrevia desse jeito porque sabia que esses mesmos roteiros depois virariam post no blog, então fazia sentido deixar a URL crua, o comando completo, o hash inteiro, o detalhe técnico todo mastigado pro leitor. Em português isso funcionava bem porque era exatamente o meu fluxo original: gravar o vídeo e depois publicar o texto correspondente no blog. O que eu nunca tinha preparado era a etapa seguinte, de transformar esse mesmo material em dublagem automatizada pra inglês. Eu só fui perceber esse conflito quando a pipeline começou a falhar de verdade.

Peguei isso primeiro no ep052, o guia de Ubuntu pra devs iniciantes, onde duas cues traziam URLs do github.com, URLs hkp://keyserver.ubuntu.com e um hash GPG de 40 caracteres. Tentar resolver no pós-processo seria perda de tempo. O teto de 1.20× do atempo nunca vai comprimir 55 segundos em 30, e mesmo se conseguisse ia sair num chipmunk ilegível. A saída é atacar antes, no texto.

A solução foi reescrever a cue dizendo o que o comando faz, em vez de mostrar o comando literal:

- Rode: apt-key adv --keyserver hkp://keyserver.ubuntu.com:80 \
-   --recv-keys 0A6A3E7F79F93EF8AAB9E92BAEBB74C8B5A1E44D
+ Rode o comando completo que tá na descrição do vídeo pra importar
+ a chave de assinatura do repositório do keyserver do Ubuntu.

A legenda em inglês no vídeo continua mostrando o comando inteiro na tela, então quem lê a legenda vê o que precisa digitar. O áudio dublado descreve a intenção em linguagem falada, que é o que o TTS entrega sem engasgar. A instrução pro ouvinte fica intacta, e o caractere-por-segundo volta pros 16 esperados, então o áudio gerado cabe na janela original sem precisar esticar nem comprimir nada no pós.

Saí caçando cue assim em todos os episódios do batch. Varri do ep052 ao ep146 procurando cues com densidade alta de caractere “duro” (dígitos, colchetes, operadores, URLs longas, binário, hex) e acabei reescrevendo umas 30 cues em 13 episódios:

• ep052 Ubuntu pra devs: URLs do GitHub e hash GPG de 40 caracteres
• ep091 Hello World em C: exemplos binários
• ep095 Memória 640kB: wrap de endereço, segment-offset
• ep106 CodeMiner: endereço de e-mail soletrado
• ep113 Compressão: strings de binário puro, 75% de caractere duro
• ep115 SQL Server: lista longa de números ordenados
• ep120 Internet: endereços IP com pontos
• ep121 Sockets: dois blocos de código JavaScript
• ep122 Proxies: headers User-Agent do Chrome
• ep123 Rede segura: one-liners shell, flags do Docker
• ep126 Gentoo: demo de chroot em C
• ep136 Containers: URL de release do GitHub
• ep144 Criptografia: endereço de signing key

O padrão foi sempre o mesmo: mantém a legenda exibindo o código, a URL ou o hash na íntegra, e reescreve o texto pro narrador descrever o que aquilo faz. Eu podia ter automatizado a reescrita, deixando um LLM ler a cue e propor uma substituição no voo, só que achei mais seguro revisar tudo manualmente. É exatamente o tipo de coisa onde o modelo resolve “melhorar” um comando pra deixá-lo mais limpo e sai com shell errado. A varredura manual levou umas duas horas. A automática teria custado o mesmo tempo em revisão, com o bônus da ansiedade de ter deixado passar algum comando mutilado.

Teve também um caso estrutural esquisito no ep146, sobre Docker Compose. Duas cues ficaram grudadas por causa de uma linha em branco faltando no SRT, e o pysrt tratava as duas como uma única cue gigante. O TTS nem chegava a processar, o chunker engasgava antes. Corrigi à mão adicionando a linha em branco que faltava. Fix de um caractere, meia hora pra rastrear.

Reconstruindo SRTs truncadas

Outra armadilha apareceu quando fui rodar o batch completo: três episódios tinham legendas em inglês curtas demais em relação à duração real do vídeo. O ep056, sobre Rails, era o caso mais absurdo. Dezenove minutos de legenda pra um vídeo de 80 minutos. Sessenta e dois minutos de conteúdo sem legenda nenhuma. O ep057 (WSL 2) tinha 14 minutos faltando, e o ep068 (Git Direito) tinha 2.

Isso é rastro do meu fluxo de tradução antigo. Em algum momento eu comecei a revisar a legenda manualmente, parei no meio, e o arquivo .en.srt ficou salvo truncado no ponto onde eu parei. Não dá pra dublar um vídeo de 80 minutos com legenda de 19. O chunker gera áudio até onde consegue ler e simplesmente não sabe o que fazer com o resto do vídeo.

A solução virou um script novo. Ele faz diff entre o .en.srt truncado e o .pt-orig.srt (o auto-caption bruto do YouTube, que sempre cobre o vídeo inteiro), pega as cues que existem só em português, manda pro Claude Sonnet 4.6 com um schema JSON rígido pedindo tradução cue a cue, e cola o resultado de volta no fim do arquivo em inglês. O schema é o detalhe que importa. Quando eu tentei pedir a resposta em texto no formato N|texto, o Claude deixava cair umas 20% das cues no caminho. Com um schema JSON estrito, a taxa de drop caiu pra zero nos três reparos.

O resultado em números:

• ep068 Git Direito: +50 cues / 2 minutos reconstruídos
• ep057 WSL 2: +368 cues / 14 minutos
• ep056 Rails: +1445 cues / 62 minutos (e ainda drop de 5 cues falsas que o tradutor antigo tinha inventado no fim pra tampar a saída)

Depois dos reparos, os três episódios entraram no batch normalmente e foram dublados como qualquer outro. Tipo de ferramenta que você espera nunca precisar, só que quando precisa, compensa escrever uma vez e resolver o problema inteiro de uma vez.

Tags de emoção automáticas

Enquanto eu tava testando, resolvi adicionar mais um passo no pipeline: um “emotion tagger” que lê o SRT em inglês antes de mandar pro TTS e insere tags tipo [sarcastic], [thoughtful], [emphatic], [deadpan] em pontos onde um narrador humano naturalmente mudaria o tom. A ideia é imitar o que um ator profissional faria, colocar ênfase nos momentos certos, sem transformar o vídeo num teatro de emoções exageradas.

Essa parte é delicada por dois motivos. O primeiro: deixar um LLM solto editando o SRT tem risco real de ele “melhorar” o texto (trocar uma palavra aqui, reescrever uma frase ali) e você acabar com uma dublagem que não bate com a legenda. O segundo: LLM adora exagerar. Se você pedir pra marcar emoção, ele vai colocar tag em toda segunda frase. Pra evitar os dois, eu fixei uma lista pequena de tags permitidas e rodo uma validação de round-trip depois que a resposta do Claude chega:

ALLOWED_TAGS: frozenset[str] = frozenset({
    "[sarcastic]", "[thoughtful]", "[emphatic]",
    "[deadpan]", "[serious]", "[amused]",
    "[sighs]", "[exasperated]", "[confident]",
    "[matter-of-fact]",
})

def validate_tagged(original, tagged):
    """Garante que o SRT com tags preserva o original sem drift."""
    if len(original) != len(tagged):
        raise TagValidationError("cue count mismatch")

    for o, t in zip(original, tagged):
        # O index e o timestamp têm que bater byte a byte.
        if o.index != t.index or o.timestamp != t.timestamp:
            raise TagValidationError(f"cue {o.index}: header drift")

        # Qualquer tag fora da whitelist invalida tudo.
        bad = find_disallowed_tags(t.text)
        if bad:
            raise TagValidationError(f"cue {o.index}: {bad}")

        # O texto sem as tags tem que ser idêntico ao original.
        # Se o LLM trocou uma palavra, reescreveu algo, a
        # validação quebra e a resposta é rejeitada.
        if strip_tags(o.text) != strip_tags(t.text):
            raise TagValidationError(f"cue {o.index}: text drift")

Quando a validação quebra, a pipeline ignora a resposta e reemite o request (ou, se falhar muito, sobe o SRT sem tags mesmo). Sobre a quantidade de tags, o prompt que vai pro Claude diz explicitamente: mira em N/10 tags pra um SRT de N legendas, chão de 1 tag a cada 12, teto de 1 tag a cada 7, distribuição equilibrada entre os quatro quartos do episódio, nunca duas tags adjacentes a menos de 4 legendas uma da outra. Esse conjunto de regras foi a sexta iteração — as cinco anteriores ou enchiam tudo de tag ou concentravam no começo do vídeo.

Não deixe a v3 alucinar

Um detalhe crítico que só aparece em produção: a ElevenLabs v3 tende a alucinar quando você manda blocos de texto muito longos. Já peguei blocos onde o texto tinha uns 1.500 caracteres e o modelo gerou um áudio com nove minutos quando o esperado era um minuto e meio. O modelo simplesmente resolve continuar falando sozinho, inventando conteúdo.

A documentação oficial da ElevenLabs recomenda manter cada chamada abaixo de 800 caracteres pra evitar isso. Eu fui mais conservador e cortei em 700, sempre em fim de frase (nunca no meio de uma sentença, porque o corte no meio soa horrível quando concatena). Depois disso, subi o parâmetro stability pra 0.9 (modo Robust, mais estável porém menos responsivo a tags de emoção), liguei o apply_text_normalization pra o modelo pronunciar números e siglas direito, e adicionei uma verificação de sanidade que rejeita qualquer áudio gerado que passe de 1.8× da duração esperada.

DEFAULT_VOICE_SETTINGS = {
    "stability": 0.9,          # modo Robust
    "similarity_boost": 0.95,
    "style": 0.0,
    "use_speaker_boost": True,
}

EXPECTED_CHARS_PER_SEC = 16.0
CHUNK_SANITY_MAX_FACTOR = 1.8   # rejeita se actual > 1.8× esperado

Depois dessas mitigações, um episódio de 95 minutos (194 blocos) rodou do começo ao fim sem nenhuma alucinação. Exatamente um bloco falhou por erro 502 transitório da API, que o retry automático pegou na tentativa seguinte.

Masterização pro YouTube

O YouTube não publica número oficial, mas o consenso da indústria é que a normalização de volume dele na hora da reprodução mira em -14 LUFS. Se você entregar áudio mais alto que isso, o YouTube baixa; se entregar mais baixo, ele deixa como tá. Pra bater o alvo exato, o pipeline roda o filtro loudnorm do ffmpeg em duas passadas. A primeira mede o áudio inteiro e imprime as estatísticas (input_i, input_tp, input_lra, input_thresh) em formato JSON no stderr. A segunda passada lê essas estatísticas de volta e aplica um ganho estático linear pra pousar exato em -14 LUFS, -1.5 dBTP:

# Passada 1: medir
ffmpeg -i final_en.mp3 \
  -af "highpass=f=80,loudnorm=I=-14:TP=-1.5:LRA=9:print_format=json" \
  -f null -

# Passada 2: aplicar ganho linear com os valores medidos
ffmpeg -i final_en.mp3 \
  -af "highpass=f=80,loudnorm=I=-14:TP=-1.5:LRA=9\
:measured_I=-18.3:measured_TP=-3.1:measured_LRA=5.4\
:measured_thresh=-28.7:offset=1.2:linear=true" \
  -ar 48000 -ac 2 -c:a pcm_s16le final_en_mastered.wav

Duas passadas em vez de uma porque o modo de passada única roda em compressão dinâmica e acaba “bombeando” o ganho em trechos com muito silêncio. Com linear=true na passada 2, o ganho fica estático em cima das medições da passada 1, então não tem bombeamento. O resultado pousa dentro de ±0.1 LU do alvo, que é praticamente inaudível. O filtro highpass=f=80 na frente derruba rumble de ar-condicionado e hum de rede elétrica abaixo de 80 Hz, que o ouvido humano não escuta mas mexe nas medições de pico.

O ponto em que eu achei que estava pronto. E não estava.

Aqui entra a parte mais chata, e mais educativa, do projeto.

Eu realmente achei que tinha acertado a mão na primeira grande rodada. A pipeline fechou os 146 episódios, eu subi tudo, e parecia resolvido. A duração batia, os arquivos estavam todos lá, o processo inteiro tinha finalmente atravessado o lote completo de quase 96 horas de vídeo. Só que foi justamente depois do upload que comecei a perceber problemas que eu simplesmente não tinha antecipado.

O primeiro susto foi a situação dos jingles. Eu já sabia que muitos episódios do Akitando começam com aquele jingle instrumental curto antes de eu começar a falar, mas subestimei o problema. O .srt do YouTube praticamente não ajuda nisso, porque jingle não é fala. Às vezes ele marca como [Música], às vezes não marca nada útil, às vezes a janela fica torta. Na primeira montagem, teve episódio onde o jingle sumiu, episódio onde ele entrou duplicado, e episódio onde o source-fill do áudio original já trazia o jingle certo e o meu splice vinha por cima, empurrando todo o resto pra frente. Foi o tipo de bug que só aparece quando você para pra escutar a master final de verdade, não quando olha só pra duração total.

A solução foi abandonar a esperança de que a legenda me diria onde estava o jingle e ir direto pra fonte. Montei um detector usando os próprios áudios originais dos vídeos e jingles de referência, com auditoria e repair pass em cima dos masters já gerados. Isso acabou virando um mini-sistema próprio: detector, auditoria, reassemble por cache, correção por janela exata. No fim dessa novela, o batch de episódios alterados caiu num conjunto de reupload bem definido e o problema dos jingles ficou finalmente sob controle. Foi um daqueles casos clássicos de produção: a primeira solução parecia suficiente até bater no acervo inteiro.

Só que aí veio a segunda pancada, e essa foi mais cara: eu tinha esquecido de um detalhe fundamental sobre legendas de YouTube. SRT é feita pra ser lida na tela, não pra virar roteiro de fala. Então uma ideia que no meu texto original era um parágrafo inteiro aparecia quebrada em várias cues pequenas, cada uma com sua microjanela de tempo. Na primeira versão da pipeline eu estava usando essas cues como unidade de geração na ElevenLabs. Resultado: o TTS gerava áudio em blocos coerentes localmente, mas a montagem introduzia silêncios artificiais no meio da frase. Tecnicamente alinhado, humanamente esquisito.

O conserto foi doloroso porque exigiu voltar várias casas. Em vez de respeitar a estrutura das cues do SRT, precisei voltar pros meus textos originais e reconstruir o chunking com base nos parágrafos que eu realmente li quando gravei os vídeos. Quase todo episódio do Akitando tem o post correspondente com a seção ## Script, e isso salvou o projeto. Como eu fui meticuloso na época em que produzi os vídeos — escrevendo os roteiros antes, lendo exatamente aquilo na gravação e arquivando tanto os vídeos quanto os scripts — eu tinha a fonte de verdade. Então deu pra mapear os parágrafos do script aos timings do .pt-BR.srt, reagrupar o .en.srt em cima disso e regenerar os chunks no formato certo.

O problema é que essa mudança destrói o cache anterior. Mesmo quando o texto quase não muda, se a fronteira do chunk muda, a chamada ao TTS muda junto: muda contexto, muda prosódia, muda começo, muda fim. Então não era um retoquezinho. Era uma regeneração completa de tudo de novo. Foi aí que o custo começou a sair do meu controle inicial.

E quando eu achei que agora sim tinha terminado, veio a terceira paulada: os clipes externos. Muitos vídeos do canal têm trechos inseridos de outras fontes. No episódio de Ruby on Rails, por exemplo, tem 37signals, Apple, comerciais, pedaços externos no meio da narrativa. O .srt do YouTube não sabia lidar direito com isso. Em alguns pontos ele simplesmente alucinava texto, em outros os timings ficavam completamente tortos, em outros a fala original não tinha nada a ver com a legenda que eu estava usando de base. De novo: olhando só pra automação parecia tudo bem; escutando a master final, não estava.

A correção, mais uma vez, foi sair da legenda e voltar pro material original. Montei um detector de janelas de clipe externo a partir de gaps de alinhamento entre transcript, .pt-BR.srt, cues sem fala útil e chunks que atravessavam essas janelas. Depois, em vez de tentar dublar o que não fazia sentido dublar, o processo passou a recuperar o áudio original do vídeo exatamente nesses trechos e preencher a master com o source correto. Foi isso que consertou os casos de 37signals, Apple Education, comercial de Mac vs PC e outros inserts parecidos que eu tinha esquecido que existiam.

Esse foi o aprendizado mais importante dessa segunda metade do projeto: automação te leva muito longe, mas o acervo completo sempre tem mais cantos escuros do que você imagina no primeiro passe.

Os números do batch de dublagem (e por que doeu mais do que eu imaginei)

Eu preciso me corrigir de novo. Não errei só a primeira conta. Errei também o grau de confiança que eu tinha depois da primeira rodada.

Quando subi pro plano Business da ElevenLabs, eu achei que finalmente estaria com folga. Na prática, não fiquei. O screenshot mais recente do dashboard mostra 10.046.279 créditos consumidos de um limite de 11.000.000, sobrando 953.721:

Em português claro: eu torrei mais de 91% do limite do workspace Business. E isso ajuda a entender o que “10 milhões de créditos” realmente significa nesse contexto. Não é só “renderizei 146 episódios uma vez”. É renderizar 146 episódios, descobrir um problema estrutural, voltar, corrigir, regenerar chunks, descobrir outro problema estrutural, voltar, reconstruir masters, auditar jingles, reparar janelas de clipes externos, reupar de novo. Cada rodada a mais custa. E quando a mudança invalida o cache, custa muito.

O custo também não para na ElevenLabs. Todo o trabalho de curadoria das legendas, reescrita de cues problemáticas, reconstrução de SRTs truncadas, auditorias de jingle, detector de clipes externos e o resto rodou via Claude Code no plano Claude Max 20×. Somando isso com a tradução em massa do blog pra inglês que eu descrevi no artigo de aniversário, o limite semanal do Claude Max 20× bateu 100%, com gasto extra acima de R$ 300. Pra quem acha que IA generativa vira grátis depois que você assinou o plano, os boletos discordam.

Mesmo assim, continuo achando que vale a pena. Estamos falando de 146 episódios, quase 96 horas de conteúdo técnico, mais de 5 anos de acervo do canal. Fazer isso manualmente em estúdio, com ator, direção, pickup e revisão humana em tudo, custaria uma ordem de grandeza completamente diferente.

O que mudou foi minha visão do projeto. No começo eu tava olhando pra isso como “um batch grande”. No fim, era outra coisa. Era mexer num acervo inteiro, achar exceção escondida, consertar ferrugem antiga, refazer master, rerender, reouvir.

O primeiro batch completo levou pouco menos de dois dias e me fez pensar que eu tinha resolvido tudo. Não tinha. A segunda rodada, com chunking por parágrafo, já foi cara. A terceira, com os reparos de jingle e os consertos de masters, mais cara ainda. E a quarta pancada veio dos clipes externos que eu não tinha modelado direito na primeira automação.

Mas agora, finalmente, eu acho que acabou. Ou melhor: eu espero que tenha acabado. Tudo foi enviado de novo, pela última vez. Não está perfeito no sentido absoluto da palavra. Está tão bom quanto eu consigo deixar com script, auditoria e automação, sem entrar num inferno de intervenção manual vídeo por vídeo.

E se isso tudo foi possível, é porque anos atrás eu tive a disciplina de produzir os vídeos do jeito certo: escrever primeiro, ler o roteiro quando gravava, e arquivar os materiais depois. Sem os vídeos originais e sem os scripts originais, eu não teria como descobrir onde o .srt mentia, onde o timing estava torto, onde o clipe externo entrava, onde o parágrafo original começava e terminava. Essa organização antiga foi o que permitiu consertar o projeto agora.

Então sim: a dublagem dos 146 episódios está pronta. Não perfeita. Mas fechada. Pelo menos, eu sinceramente espero que agora sim esteja.

O primeiro teste, assista

Fiz um vídeo teste pra provar que funciona. Dois avisos antes: primeiro, o embed abaixo já carrega com a legenda em inglês ligada por padrão, então esse lado dá pra resolver via URL. Segundo, o áudio é chato: o YouTube removeu o seletor de faixa de áudio dos players embedados lá por março desse ano. Então dentro do embed você não vai encontrar essa opção no menu de engrenagem mesmo, só roda em português. Pra ouvir a dublagem em inglês de verdade, clica em assistir direto no YouTube, que a página principal do YouTube ainda tem o seletor de faixa de áudio no menu de engrenagem.

Se você tá acostumado com a dublagem automática do YouTube ou com as dublagens de IA de TikTok, compara. A diferença é gritante. A voz é a minha, com sotaque americano trabalhado, e a sincronização com o vídeo original fica dentro de 1 a 2% de desvio cumulativo, praticamente imperceptível em 95 minutos de vídeo.

E o que faltava: traduzir as thumbnails

Quando eu estava fechando esse post, me caiu a ficha de que tinha deixado uma ponta solta. As 146 thumbnails do meu canal estão em português, muitas com título em caixa alta grande tipo “9 DICAS PARA PALESTRANTES” ou “7 RECOMENDAÇÕES DE SHOWS PARA PESSOAS DE TECH”. De nada adianta áudio em inglês perfeito se a imagem que aparece na busca é um bloco de texto ilegível pra quem não lê português. O YouTube permite subir uma thumbnail alternativa por idioma, então eu precisava gerar versões em inglês, mantendo o resto da arte idêntico, trocando só o texto.

A ferramenta usa duas peças. yt-dlp é o fork moderno do antigo youtube-dl, uma CLI em Python que baixa qualquer coisa do YouTube (vídeos, áudios, legendas, thumbnails) sem precisar de API key. Nano Banana Pro (nano-banana-pro-preview na API) é o modelo de edição de imagem mais recente do Google Gemini — aceita uma imagem de entrada com um prompt e devolve a imagem editada, preservando o resto da composição quando você pede pra mexer só numa parte.

O pipeline tem dois passos. Passo 1: yt-dlp pega a thumbnail em .jpg, sem baixar o vídeo:

yt-dlp --skip-download \
       --write-thumbnail \
       --convert-thumbnails jpg \
       -o "thumbnails/originals/<slug>/<video_id>" \
       "https://www.youtube.com/watch?v=<video_id>"

Passo 2: mandar cada imagem pro Gemini Nano Banana Pro com um prompt que é um contrato rígido de requisitos duros, não só um “traduz isso”:

TASK:
Detect every piece of Portuguese text visible on this image and
translate it to clear, natural American English. Replace the
Portuguese text with the English translation in the same visual
position.

STRICT REQUIREMENTS — follow every one:
- Preserve EVERY non-text element identically: face, pose,
  expression, background, color palette, lighting, icons, logos,
  decorative shapes, borders, layout. Only the text changes.
- The English translation must be IDIOMATIC and CONFIDENT — not
  a literal word-for-word rewrite. It's a YouTube thumbnail for a
  tech audience, so use punchy phrasing a native English-speaking
  tech YouTuber would write.
- Match the original text's font family, weight, size, color,
  stroke outline, drop shadow, and any decorative treatment.
- If there is no Portuguese text at all on the image, return the
  original image unchanged.

A cláusula “return the original image unchanged” é o que salva os primeiros episódios do canal, que não têm texto na thumbnail, só minha cara. Sem ela, o modelo invariavelmente ia “melhorar” a composição, trocar a iluminação, etc.

Olha o resultado em dois exemplos (episódios 10 e 11):

Original (PT)

Traduzida (EN)

Original (PT)

Traduzida (EN)

Repara no detalhe do episódio 10. O modelo não traduziu “7 Recomendações de Shows para Pessoas de Tech” literal pra “7 Show Recommendations for Tech People”, que seria a versão tradutor automático. Ele reformulou pra “7 TV Shows You Must Watch If You’re In Tech”, como um tech YouTuber americano de verdade escreveria. O resto da imagem fica idêntico pixel a pixel. No episódio 11, “9 DICAS PARA PALESTRANTES: venda sua caneta” vira “9 TIPS FOR SPEAKERS: sell your pen”, com fonte, caixa alta e posição preservadas. Se você não soubesse que o original era em português, não dava pra adivinhar que é uma edição automática feita por IA.

Custo do lado Gemini: alguns centavos por imagem, poucos dólares totais pro batch inteiro. Trivial perto dos $1.500+ do dub. Com a thumbnail resolvida, a conversão do canal pra inglês fica fechada — áudio clonado pela ElevenLabs v3 em cima das legendas curadas em .srt, e a imagem editada pelo Nano Banana Pro pra o título bater com o resto.

A conclusão, que é o título desse post

Quando o Qwen3 TTS saiu, o hype dizia que era “ElevenLabs killer”. Passei semanas tentando viver com essa premissa na prática, com conteúdo real no ar toda semana. E o que eu descobri é que open source de TTS ainda tá muito longe da ElevenLabs. A diferença é grande, e ela aparece justamente quando você sai do tweet de demo de 5 segundos e coloca o modelo pra rodar um podcast semanal de 30 minutos de verdade.

Na prática, o Qwen3 nem bate o modelo v2 da ElevenLabs. O v3, que é o atual, fica um degrau acima do v2 ainda. A prosódia sai melhor, as tags de emoção no meio do texto funcionam em português e em inglês sem esforço, e a API fica de pé sem você precisar manter servidor nenhum. O custo por caractere é um pouco mais alto, mas pro meu volume atual ele fica confortavelmente dentro do orçamento e me devolve horas que eu gastava cuidando de GPU.

A lição aqui é a mesma que a galera de LLMs tá aprendendo devagar. Demo de tweet de 30 segundos é uma coisa, produção é outra coisa completamente diferente. Open source tem seu nicho, principalmente quando você tem dado sensível que não pode sair de casa, ou quando você tem muita GPU ociosa e pouco orçamento recorrente. Só que pra uso sério de TTS em produto comercial, aqui em abril de 2026, a ElevenLabs segue imbatível. O Qwen3 não matou ninguém.

E não esquece: assina o The M.Akita Chronicles no Spotify pra não perder episódio novo desses, feito com a nova pipeline.

⚠️ Artigo obsoleto (atualização de 2026-04-24). As conclusões e rankings desse artigo foram superados depois que eu re-auditei o benchmark contra o código-fonte do gem ruby_llm e reestruturei o critério de avaliação. Várias “hallucinations” que eu catalogava eram API válida. Kimi K2.6 e Gemini 3.1 Pro subiram pra Tier A. GLM 5.1 caiu pra Tier C. MiMo V2.5 Pro caiu de “primeiro Tier 1 não-Anthropic” pra Tier B. A versão canônica está em Benchmark de LLMs pra Coding (Abril 2026). Esse artigo fica aqui como registro histórico do que eu concluí antes do re-audit.

Update 16 de Abril, 2026: Adicionamos Claude Opus 4.7, Qwen 3.6 e GPT 5.4 via Codex CLI (xHigh reasoning). Opus 4.7 é melhoria incremental sobre 4.6 (28 testes vs 16, mesma API correta) e passa a ser o novo baseline. GPT 5.4, que estava no Tier 1 pelo meu aval pessoal, agora tem dados objetivos e caiu pro Tier 2 — gastou 7.6M tokens (~$16/run, 15x mais caro que Opus) e errou a convenção de chamada do add_message no multi-turn. Qwen 3.6 Plus continua Tier 3 com a mesma alucinação de API do 3.5. A conclusão se mantém: se quer segurança, Opus.

TL;DR: Se você não quer ler a análise inteira: os únicos modelos que geraram código que funciona de verdade no nosso benchmark foram Claude Opus 4.7, Claude Opus 4.6, GLM 5 e GLM 5.1 (da Z.AI, ~89% mais baratos que Opus). O Sonnet também funciona nesse benchmark, mas na prática falha em projetos que exijam raciocínio mais profundo — detalhes na conclusão. O GPT 5.4, que antes estava no Tier 1 pelo meu aval pessoal, agora tem dados objetivos via Codex CLI: gastou 7.6M tokens ($16/run) e errou a convenção de chamada do add_message — funciona na primeira mensagem, quebra no multi-turn. Caiu pro Tier 2. O resto — Kimi, DeepSeek, MiniMax, Qwen, Gemini, Grok 4.20 — inventou APIs que não existem ou ignorou o gem pedido.

Tem uma novidade nesse update: refiz a parte local do benchmark numa RTX 5090 (em vez do AMD Strix Halo) e adicionei um lote de modelos Qwen, incluindo um Qwen 3.5 27B distilado direto do Claude 4.6 Opus. Isso reabriu a conversa sobre rodar modelo open source localmente. A banda de memória da 5090 muda o jogo de “inviável” pra “viável com 1-2 prompts de correção”. E o gargalo dos modelos open source virou falta de conhecimento factual sobre bibliotecas, coisa que eu explico em detalhe na nova seção sobre a família Qwen. A aposta da distilação do Claude, aliás, deu um resultado bem frustrante que eu nunca tinha visto documentado nesses termos.

Se você acompanhou meus artigos anteriores sobre vibe coding, sabe que passei os últimos dois meses numa maratona de mais de 500 horas usando Claude Opus como coding agent principal. Os resultados foram bons, como reportei na conclusão sobre modelos de negócio. Mas ficou uma coceira: será que eu estou preso num único modelo? Tem alternativa real ao Claude Opus pra uso diário em projetos de verdade?

Tenho uma RTX 5090 com 32 GB de GDDR7. Sei que posso rodar os modelos open source mais recentes. Comprei um Minisforum MS-S1 com AMD Ryzen AI Max 395 e 128 GB de memória unificada, e montei um home server com Docker pra servir modelos locais. A infraestrutura estava pronta. Faltava testar de verdade.

Construí um benchmark automatizado pra comparar modelos open source e comerciais em condições idênticas. 33 modelos configurados ao todo (25 da rodada original mais 8 adicionados na rerodada na NVIDIA), 27 executados, 16 completados de alguma forma. O código está no GitHub.

O gargalo que ninguém explica: VRAM e KV Cache

Antes de falar dos resultados, preciso explicar por que rodar modelos grandes localmente é muito mais difícil do que parece.

Pega o Qwen3 32B como exemplo. O modelo em FP16 (precisão total) ocupa ~64 GB. Quantizado em Q4 (4 bits), cai pra ~19 GB. Então cabe nos 32 GB da minha RTX 5090, certo? Errado. Esse é só o peso do modelo. Falta a parte que ninguém conta pra você: o KV Cache.

KV Cache é a memória que o modelo usa pra “lembrar” o que já leu. Cada vez que processa um token (uma palavra ou pedaço de palavra), ele calcula dois vetores — K (key) e V (value) — pra cada camada de atenção. Esses vetores ficam armazenados pra que não precise recalcular tudo quando gera o próximo token. Sem isso, a geração seria quadraticamente lenta.

O KV Cache escala linearmente com o tamanho do contexto. A fórmula:

Memória KV = 2 × Camadas × Cabeças_KV × Dimensão_Cabeça × Bytes_por_Elemento × Tokens_no_Contexto

Pra um modelo como o Llama 3.1 70B em BF16, isso dá ~0.31 MB por token. Parece pouco, até você perceber que um contexto de 128K tokens consome 40 GB só de KV Cache. O modelo em si + KV Cache = muito mais VRAM do que a maioria das GPUs tem.

E pra uso real com coding agents, 128K tokens não é luxo — é necessidade. O agent precisa ler arquivos, manter histórico de conversação, receber output de comandos. Em sessões longas de benchmark, nossos modelos consumiram entre 39K e 156K tokens. Menos de 100K de contexto não é prático pra projetos do dia a dia.

O Google publicou o TurboQuant (ICLR 2026), que comprime o KV Cache pra 3 bits sem perda de acurácia — redução de 6x na memória e até 8x de speedup. Usa rotação aleatória de vetores (PolarQuant) seguida de um algoritmo de 1 bit nos resíduos. Funciona online durante inferência, comprimindo na escrita e descomprimindo na leitura. Ainda não está implementado nos runtimes que usamos (llama.cpp, Ollama), mas quando chegar vai mudar bastante a equação.

Pra quem quer se aprofundar nessa matemática de VRAM, recomendo este link do Ahmad Osman pro artigo “GPU Memory Math for LLMs (2026 Edition)”.

O problema do hardware: memória não é toda igual

“Mas eu tenho 128 GB de RAM!” Legal, mas não é isso que importa. O que importa é largura de banda de memória, e a diferença entre tipos é absurda:

A RTX 5090 tem 7x mais bandwidth que a memória LPDDR5x do meu Minisforum. Isso significa que mesmo que o modelo caiba na RAM unificada do AMD, a inferência vai ser proporcionalmente mais lenta. No meu Minisforum com LPDDR5x a 256 GB/s, o Qwen3 32B roda a ~7 tok/s. Na RTX 5090 a 1.792 GB/s, seria muito mais rápido — se coubesse inteiro na VRAM junto com o KV Cache.

A maioria das pessoas rodando modelos locais ainda está em DDR4. A 50 GB/s, modelos de 32B ficam praticamente unusáveis. E tem outro fator que pouca gente lembra: storage. Quando a RAM não dá conta e o sistema faz swap, a velocidade do armazenamento vira o gargalo:

De SATA pra NVMe Gen5 são 22x de diferença. Se você está fazendo offloading parcial pro disco (comum quando o modelo não cabe inteiro na GPU), NVMe Gen4 ou Gen5 faz diferença real. SATA é inviável.

Resumindo: rodar modelos locais não é só “ter RAM suficiente”. Precisa do tipo certo de memória, com a bandwidth certa, e storage rápido como fallback. Pra muita gente, um Mac Studio com memória unificada de alta bandwidth (até 800 GB/s nos M4 Ultra com 512 GB) seria a opção mais prática, mas custa mais de US$ 10.000. O AMD Ryzen AI Max é a alternativa mais acessível com memória unificada, mas o LPDDR5 fica limitado a 256 GB/s.

Ollama vs llama.cpp: por que o Ollama falha pra benchmarks

O Ollama é a forma mais popular de rodar modelos locais. Instala, puxa o modelo, roda. Pra uso casual funciona. Mas quando tentei usar pra benchmarks automatizados, sessões longas sem intervenção humana, quebrou de 6 formas diferentes em 8 modelos:

1. Descarrega o modelo no meio da sessão. Em runs longos, o Ollama decide que o modelo não está sendo usado e descarrega da GPU. O agent fica esperando resposta de um modelo que não existe mais.
2. Ignora o contexto solicitado. Você pede num_ctx=131072, o Ollama aceita, e no meio do run reverte pro padrão sem avisar.
3. Lifecycle instável. Pedir keep_alive: 0 pra descarregar nem sempre funciona. O modelo fica residente e bloqueia o próximo.
4. Formatos incompatíveis. Variantes bf16 nativas do Ollama falhavam, enquanto o mesmo modelo como GGUF Q8 do HuggingFace funcionava sem problemas.

A solução: migrar pro llama-swap, um wrapper Go que gerencia processos llama.cpp com hot-swap. Chega um request pra um modelo diferente do que está carregado, ele mata o processo atual e inicia o novo. Sem negociação de contexto, sem lifecycle instável.

O llama-swap resolveu o carregamento de 6 dos 8 modelos que falharam no Ollama:

Mas o llama-swap não é mágico.

Por que “só usar llama.cpp” não resolve tudo

O llama.cpp resolve os problemas de lifecycle do Ollama mas traz os próprios:

Cada modelo precisa de flags específicas. GLM e Qwen 3.5 emitem <think> tags que quebram clientes se você não passar --reasoning-format none. Gemma 4 precisa de build b8665+ pro parser de tool calls funcionar.

Nem todo modelo suporta tool calling. O llama.cpp precisa de um parser dedicado pro formato de tool call de cada modelo. O Llama 4 Scout usa um formato “pythonic” ([func(param="value")]) que o llama.cpp simplesmente não parseia, emite como texto puro. O vLLM tem parser pra isso, o llama.cpp não.

E tem os repetition loops. O Gemma 4, mesmo com o parser certo, entra em loop infinito depois de ~11 tool calls em sessões longas. É um bug conhecido que o PR #21418 não resolveu completamente.

Compatibilidade de tool calling por modelo:

No fim das contas, llama.cpp é melhor que Ollama pra runs automatizados, mas “plug and play” não é. Cada modelo exige configuração específica, e alguns simplesmente não funcionam pra agentic coding ainda.

Reasoning: modelos que pensam vs modelos que chutam

Tem uma diferença entre modelos que vale explicar: reasoning. A ideia é que o modelo “pensa antes de responder” em vez de gerar tokens direto da esquerda pra direita. Modelos com reasoning fazem uma etapa interna de cadeia de pensamento (chain-of-thought) onde avaliam o problema, consideram alternativas, planejam, e só depois emitem a resposta.

Na prática, isso aparece como <think>...</think> tags no output, blocos de texto que o modelo gera pra si mesmo, que não devem ir pro usuário final. Claude Opus 4.6, GPT 5.4, DeepSeek V3.2 e a linha Qwen 3.5 suportam reasoning nativamente. Os menores (Gemma 4, GPT OSS 20B, modelos mais antigos) não têm essa capacidade.

Por que importa pra coding? Quando um coding agent recebe “construa um app Rails com 9 componentes”, ele precisa decompor a tarefa em passos, decidir a ordem, antecipar dependências, adaptar quando algo falha. Sem reasoning, o modelo gera código sequencialmente sem planejamento. Funciona pra tarefas simples, desmorona em projetos com partes interdependentes.

No benchmark, a diferença ficou clara:

• GPT OSS 20B (sem reasoning, 20B parâmetros) criou o app no diretório errado. Não conseguiu manter o contexto das instruções de workspace enquanto gerava código.
• Qwen 3 32B tem reasoning, mas a 7 tok/s era lento demais. Os tokens de “pensamento” aumentam o tempo de geração.
• Gemma 4 31B, sem reasoning treinado pra uso agentic, entrou em loops repetitivos de tool calling.
• GLM 5 (cloud, 745B MoE) com reasoning e 44B parâmetros ativos, completou limpo e usou a API correta.

Tem um trade-off: reasoning consome tokens extras (os <think> blocks), que ocupam VRAM no KV Cache e desaceleram a geração. Por isso flags como --reasoning-format none são necessárias no llama.cpp. Alguns clientes não sabem o que fazer com reasoning tokens e quebram. Modelos que emitem reasoning sem que o runtime espere podem gerar lixo no output.

E reasoning não é algo que você “liga” num modelo qualquer. É uma capacidade treinada com reinforcement learning em cima do modelo base, usando dados de problemas que exigem raciocínio multi-step. Os modelos open source menores (20B-35B) tipicamente não passaram por esse treinamento, ou passaram em escala menor. Eles sabem gerar código, mas não sabem planejar código. Em tarefas que exigem 50+ tool calls coordenadas, essa diferença mata.

O benchmark: metodologia

Pra comparar modelos de forma justa, construí um harness automatizado em Python. Cada modelo recebe exatamente o mesmo prompt: construir uma aplicação Ruby on Rails completa, um chat SPA tipo ChatGPT usando o gem RubyLLM, com Hotwire/Stimulus/Turbo Streams, Tailwind CSS, testes Minitest, ferramentas de CI (Brakeman, RuboCop, SimpleCov, bundle-audit), Dockerfile, docker-compose e README.

O runner é o opencode, uma das CLIs de coding open source mais populares, competindo com Claude Code e Codex. Vale um esclarecimento: o autor original saiu do projeto e foi tocar o Crush junto com a equipe da Charm (o pessoal por trás do Bubble Tea, Lip Gloss e várias outras ferramentas de terminal em Go), mas o restante do time original continuou evoluindo o opencode normalmente — o projeto não foi descontinuado. Hoje os dois coexistem. Se você leu meu artigo sobre o Crush, já conhece essa vertente. Ambos rodam em tudo: macOS, Linux, Windows, Android, FreeBSD.

Na verdade, tentei usar o Crush primeiro pro benchmark. O problema: ele anunciava uma flag --yolo no help pra auto-aprovar todas as ações (essencial pra runs automatizados sem intervenção humana), mas na hora de rodar, rejeitava a flag. Sem auto-approve, não dá pra fazer benchmark desacompanhado. O opencode, por outro lado, tinha o modo opencode run --agent build --format json que emite eventos JSON com session IDs e contagem de tokens, perfeito pra automação. Então ficamos com o opencode.

Escolhi o opencode (e não Claude Code ou Codex) por dois motivos:

1. Neutralidade. Claude Code é otimizado pra modelos Anthropic. Codex é otimizado pra modelos OpenAI. O opencode é agnóstico, mesma interface pra todos.
2. Automação. O opencode expõe um formato JSON legível por máquina. Claude Code e Codex não têm interface equivalente pra benchmarking externo.

Modelos cloud rodaram em duas fases: fase 1 (construir o app) e fase 2 (validar boot local, docker build, docker compose). Modelos locais rodaram só fase 1.

Detalhe que vale mencionar: o benchmark inteiro custou menos de $10 em tokens no OpenRouter. Tirando o GPT 5.4 Pro que torrou $7.20 pra falhar, os outros 11 modelos cloud somaram uns $2.50 no total. Modelos locais custam só eletricidade. O ponto é: rodar seu próprio benchmark é barato. Se você quer saber se um modelo funciona pro seu caso de uso, gaste os $2 e teste. O código do harness está no GitHub, é só trocar o prompt pelo seu projeto.

Por que o GPT 5.4 falhou no benchmark (mas não na vida real)

O GPT 5.4 Pro é o único modelo cloud que falhou consistentemente no nosso benchmark. Duas runs separadas, mesmo resultado: o modelo gerou arquivos mas nunca chegou a finish_reason: stop. Sempre terminava com finish_reason: tool-calls — queria continuar chamando tools mas o loop se quebrava.

Pra quem não sabe: tool calling é quando um LLM precisa executar uma ação (ler um arquivo, rodar um comando, editar código) e emite uma “chamada de ferramenta” num formato estruturado. O client (opencode, Claude Code, Codex) interpreta, executa, e devolve o resultado pro modelo. Cada provedor tem seu formato: a Anthropic usa tool_use blocks, a OpenAI usa function_calling com JSON schemas, o Google usa FunctionCall.

O GPT 5.4 é fortemente treinado pro formato nativo de function calling da OpenAI — tool_choice, tools com JSON schemas proprietários. Quando o benchmark rota por opencode → OpenRouter → GPT 5.4, os schemas de tools são traduzidos em cada hop. Se o GPT emite tool calls num formato que o OpenRouter ou opencode não parseia corretamente, o loop do agent quebra.

A evidência: todos os outros modelos cloud (Claude Opus, Claude Sonnet, Kimi K2.5, DeepSeek V3.2, MiniMax M2.7, GLM 5, Qwen 3.6 Plus, Step 3.5 Flash) terminaram com finish_reason: stop. Só o GPT termina com finish_reason: tool-calls.

Comparação justa do GPT 5.4 exigiria rodar no ambiente nativo. E agora temos essa comparação: construímos suporte pra automatizar o Codex CLI (codex exec com --dangerously-bypass-approvals-and-sandbox e reasoning effort xhigh) e rodamos o mesmo benchmark. O GPT 5.4 completou em 22 minutos, gerou todos os 9 artefatos, escreveu 22 testes com a arquitetura mais sofisticada do benchmark inteiro: injeção de dependência do client RubyLLM, PORO models pra ChatMessage e PromptSubmission, session-backed ChatSession com TTL e trimming de mensagens, bin/ci script.

Mas o código quebra na segunda mensagem. O GPT 5.4 usa chat.add_message(role:, content:) com keyword arguments em vez de hash posicional chat.add_message({role:, content:}) — isso causa ArgumentError: wrong number of arguments (given 0, expected 1) na primeira troca multi-turn. A primeira mensagem funciona (usa chat.ask direto), o multi-turn não.

E o custo: 7.6 milhões de tokens no reasoning effort xHigh. São 65x mais tokens que o Opus 4.7 (118K) pro mesmo benchmark. Custo estimado de ~$16 por run, contra ~$1.10 do Opus. Gastou 15x mais e ainda errou a convenção de chamada. Nem budget de token gigantesco nem reasoning effort máximo garante acerto factual numa API de gem. Conhecimento de API é memória binária, não é função de quanto o modelo “pensa”.

Com dados objetivos em mãos, o GPT 5.4 sai do Tier 1 e vai pro Tier 2. A arquitetura que ele gera é melhor que a do Opus em termos de design patterns. Mas o código precisa de correção pra rodar multi-turn, e o custo por token é proibitivo.

O Sonnet e o Opus via opencode/OpenRouter também provavelmente não foram usados ao máximo da capacidade. O Claude Code oferece suporte nativo de tools que o opencode não replica — o que significa que os resultados do benchmark representam um piso, não um teto, pra esses modelos.

Modelos open source: a realidade vs a narrativa

Tem muita gente dizendo que modelos open source já alcançaram os comerciais e que dá pra rodar seu próprio “Claude” em casa. Na prática, não é bem assim.

A escala não é comparável. Modelos frontier como Claude Opus 4.6 e GPT 5.4 são closed-source, mas estimativas indicam que estão na faixa de centenas de bilhões a trilhões de parâmetros, treinados com compute e dados que nenhuma empresa open source replica. Os melhores modelos que cabem num hardware razoável são:

Correção pós-publicação: o Qwen 3.5 35B na verdade é o 35B-A3B, um MoE com só 3B de parâmetros ativos por token (não denso, como eu tinha colocado originalmente). Isso explica por que ele roda relativamente rápido pro tamanho. E pra quem tem 24 GB de VRAM, o modelo recomendado pela própria Unsloth é o Qwen 3.5 27B denso — esse eu não cheguei a testar no benchmark, mas fica como recomendação. Pra quem quer se aprofundar em modelos locais, vale acompanhar o trabalho do @sudoingX, que tem feito experimentação séria nessa frente. Valeu @thpmacedo pelo toque.

Mesmo os maiores modelos open source MoE (Mixture of Experts) que as empresas disponibilizam publicamente ativam poucos parâmetros por token:

Esses modelos grandes não são self-hostáveis. O Kimi K2.5 com 1T parâmetros precisa de clusters de GPUs com centenas de GBs de VRAM. O GLM 5 com 745B idem. Mesmo que a Alibaba ou a Z.AI liberem os pesos (e algumas liberam), ninguém tem hardware doméstico pra rodar eles.

O que cabe na sua GPU doméstica são os modelos de 20B-35B — e esses têm limitações reais.

O que cada modelo local fez no benchmark

Resultados da rodada original no AMD Strix Halo:

Qwen 3 Coder Next (30B) — Completou em 17 minutos no Strix, gerou 1675 arquivos, app Rails com todos os artefatos. Mas só 3 testes. E o mais importante: inventou RubyLLM::Client.new, uma classe que não existe no gem. O app não roda.

Qwen 3.5 35B — Completou em 28 minutos no Strix, 1478 arquivos, 11 testes. Usou RubyLLM.chat sem parâmetro de modelo — funciona só se o default estiver configurado. Sem mocking de LLM nos testes.

Qwen 3.5 122B — Completou em 43 minutos no Strix, 1503 arquivos, 16 testes. Mas ignorou o gem RubyLLM completamente e construiu um cliente HTTP customizado pro OpenRouter. O prompt pedia explicitamente pra usar ruby_llm.

GLM 4.7 Flash (local, Strix) — Produziu 2029 arquivos com todos os artefatos, mas a sessão terminou mid-tool-call. O modelo cloud (GLM 5) funciona perfeitamente.

Gemma 4 31B (Strix) — Loop infinito de tool calls depois de ~11 steps produtivos. Bug conhecido do llama.cpp.

GPT OSS 20B (Strix) — Criou o app Rails no diretório errado (project/app/ em vez de project/). Um modelo de 20B não segue instruções de workspace de forma confiável.

Qwen 3 32B (Strix) — Lento demais (7.3 tok/s). Hardware não dá conta.

E os resultados da rerodada na NVIDIA RTX 5090 (todos com Q3_K_M ou Q4_K_M e contexto entre 64k e 128k pra caber nos 32 GB de VRAM):

Qwen 3.5 35B-A3B (5090) — 5 minutos a 273 tok/s. Projeto Rails reconhecível, entry point RubyLLM.chat(model:) está certo, mas alucina chat.add_message(role:, content:) e chat.complete em vez de .ask. Dá pra arrumar em 1-2 follow-ups. O melhor candidato a “OSS local que vale a pena tentar”.

Qwen 3.5 27B Claude-distilado (5090) — 12 minutos a 129 tok/s. Estilo Claude impecável, alucinação total da API (RubyLLM::Chat.new.with_model{}, add_message, response.text). Mais detalhes na seção de distilação abaixo.

Qwen 3 Coder 30B (5090) — 6 minutos a 145 tok/s. Devolveu uma string mockada hardcoded em vez de chamar a API. Tier 3 inutilizável.

Qwen 2.5 Coder 32B (5090) — 90 minutos de timeout, zero arquivos. Modelo girou sem nunca chamar tool de write.

Qwen 3 32B (5090) — 4 minutos a 69 tok/s, scaffold parcial, errors. Versão geral é melhor que a Coder mas ainda quebra.

Gemma 4 31B (5090) — 8 minutos a 213 tok/s. Mesmo loop de repetição que tinha no Strix. Bug do llama.cpp não é hardware.

Qwen 3.5 27B Sushi Coder RL (5090) — Falha de infra (ProviderModelNotFoundError), não foi possível avaliar. Refazer numa próxima rodada.

GPT OSS 20B (5090) — Tirado da rodada por regressão recente do llama.cpp main no parser de tool calls da família harmony. Os logs mostram Failed to parse input at pos 755: <|channel|>... em sessões multi-turn. Funcionava no Strix com o llama.cpp b8643, quebrou no main de hoje. Aguardando upstream consertar.

Modelos cloud: o que funciona de verdade

Dos 12 modelos que completaram o benchmark, todos geraram um projeto Rails reconhecível com todos os artefatos pedidos (Gemfile, routes, views, JS, testes, README, Dockerfile, docker-compose). 9 de 9 no checklist de completude.

Mas aí vem a pergunta que importa: o código roda?

A API correta do RubyLLM é simples:

chat = RubyLLM.chat(model: "anthropic/claude-sonnet-4")
response = chat.ask("Hello")
response.content  # => "Hi there!"

8 dos 12 modelos inventaram APIs que não existem. O padrão mais comum: alucinação de uma interface que não é a do gem real:

Os modelos que acertaram — os dois Claudes, o GLM 5 e o GLM 5.1 — usaram o padrão simples de duas etapas (chat = RubyLLM.chat(model:) depois chat.ask(message)). Os que erraram tentaram fazer o RubyLLM parecer com o SDK Python da OpenAI, que é outra coisa. O Grok 4.20 foi o caso mais cínico: nem tentou usar o gem, foi direto pro OpenAI::Client apontando pra URL do OpenRouter, ignorando o pedido explícito do prompt.

E os testes? Só Opus, Sonnet, GLM 5 e GLM 5.1 fizeram mocking correto das chamadas LLM. Todos os outros ou batiam na API real (que falha sem chave) ou mockavam a API inventada (testes passam mas não provam nada). Contagem de testes é uma métrica enganosa: o Kimi K2.5 escreveu 37 testes, mais que qualquer outro, mas nenhum testa a funcionalidade real porque a API que ele usa não existe.

Tabela de viabilidade real

*Step 3.5 Flash funciona chamando a API REST do OpenRouter direto com Net::HTTP, contornando completamente o gem que o prompt pedia.

Agora, isso não quer dizer que esses modelos são inúteis. Se você pegar o Kimi K2.5 ou o DeepSeek V3.2 e mandar “a classe RubyLLM::Client não existe, corrija pra usar a API real do gem”, provavelmente vai corrigir. Um ou dois follow-ups e o projeto fica funcional. A maioria dos modelos que falharam aqui conseguiria entregar um projeto rodando com mais algumas rodadas de conversa.

Só que aí está o trade-off. Com Opus ou GPT 5.4, o primeiro output já funciona. Pede, entrega, testa, roda. Com os modelos mais baratos, você vai gastar tempo corrigindo alucinações de API, debugando código que “parece certo” mas crasha, guiando o modelo na direção certa. Cada rodada dessas são 10-30 minutos. Três rodadas extras e você gastou uma hora do seu tempo pra economizar $0.90 de tokens.

Economiza dólar, gasta tempo. E tempo é dinheiro. Pra quem está aprendendo ou explorando sem pressa, essa troca pode fazer sentido. Pra quem precisa entregar, os modelos frontier se pagam rápido.

Comparação dos modelos que funcionam

Ranking completo por tempo e tokens

O DeepSeek V3.2 é o mais lento apesar de ser cloud — não tem prompt caching, então reenvia o contexto completo a cada turno.

Eficiência de tokens e cache

Modelos com prompt caching pagam muito menos tokens efetivos:

Velocidade: o abismo entre cloud e local

Tem um aspecto que as tabelas de custo escondem: velocidade de inferência. E a diferença é brutal.

O Claude Sonnet gera 532 tok/s. O Qwen 3.5 122B rodando local no meu Minisforum (AMD Strix Halo) gera 22 tok/s. São 24x de diferença. Na prática, o que o Sonnet faz em 16 minutos, o Qwen 3.5 122B leva 43 minutos. O Qwen 3 Coder Next a 37 tok/s é o mais rápido dos locais no Strix e mesmo assim é 14x mais lento que o Sonnet.

E não é só tempo de relógio. Quando você está num loop de coding interativo — pede uma mudança, espera o output, testa, pede outra — a velocidade do modelo define seu ritmo. A 37 tok/s, cada resposta longa te faz esperar 30-60 segundos. A 530 tok/s, aparece quase instantaneamente. Ao longo de um dia, você sente.

O DeepSeek V3.2 é um caso curioso: é cloud mas roda a 53 tok/s, mais lento que o Qwen 3.5 35B local no Strix (46 tok/s). O motivo é que o DeepSeek não tem prompt caching — reenvia o contexto completo a cada turno, estrangulando o throughput. Pagar por um modelo cloud mais lento que rodar local não faz sentido nenhum.

Modelos locais são grátis em tokens, mas pagam em tempo. No AMD Strix, essa conta era inviável pra todos os Qwen que testei: dois minutos esperando uma resposta longa, multiplicado por 50 turnos, é tarde inteira. Mas isso muda quando o hardware muda, e foi por isso que rerodei a parte local do benchmark numa máquina diferente.

AMD Strix Halo vs NVIDIA RTX 5090: o que muda quando a banda de memória dobra

Pra checar se o gargalo era hardware ou modelo, peguei os mesmos modelos Qwen e refiz o benchmark numa workstation com NVIDIA RTX 5090 (Blackwell, 32 GB GDDR7, 1.792 GB/s de banda). Os números mudam de uma forma que vale ver com calma.

Pra contextualizar essas velocidades, lembra que no cloud o Sonnet roda a 532 tok/s, o Opus a 347 tok/s, o Step 3.5 Flash a 242 tok/s, o Gemini 3.1 Pro a 128 tok/s e o Kimi K2.5 a 160 tok/s. O Qwen 3.5 35B-A3B na 5090, a 273 tok/s, está na faixa do Step 3.5 Flash, mais rápido que Gemini, Kimi e GLM 5.1. O Qwen 3 Coder 30B a 145 tok/s está na faixa do Gemini. A frase clássica “modelo local é dez vezes mais lento que cloud” parou de valer no momento que a 5090 entrou na conta.

A consequência prática é que o argumento “tempo é dinheiro” muda de figura. No Strix, “esperar 1 hora pra um Qwen 3.5 122B fazer o que o Sonnet faz em 16 minutos” é pura perda. Na 5090, esperar 5 minutos pra o Qwen 3.5 35B-A3B fazer o trabalho, mais 10-15 minutos pra você fazer 1-2 prompts de correção, dá um total na faixa de 20-25 minutos. O Sonnet faz em 16 minutos com zero correção. A diferença ficou pequena o suficiente pra que, se custo importa muito, valha a pena.

A pegadinha: pra que isso valha a pena, o modelo precisa estar perto o suficiente da resposta certa pra que 1-2 prompts de correção resolvam. Quando o erro é do tipo “o modelo decidiu não usar o gem que pedi e devolveu uma string mockada”, como fez o Qwen 3 Coder 30B, nenhum prompt de correção fácil arruma. Isso é refazer.

Antes que você gaste em hardware achando que é a saída

Tenho que dar um aviso, porque é o erro de compra mais comum que vejo agora. Toda hora aparece alguém dizendo que vai pegar um Ryzen AI Max porque tem 128 GB de memória unificada e isso “permite rodar modelos enormes”. Tecnicamente, sim — o modelo cabe. Na prática, é quase inutilizável. A memória é LPDDR5x a 256 GB/s, sete vezes mais lenta que a GDDR7 da 5090. O que cabe não roda em velocidade humana. Meu próprio Strix com Qwen 3.5 122B chegou a 22 tok/s e o run levou 43 minutos. Pra fazer qualquer coisa de verdade no dia a dia, isso é impraticável.

A 5090 é claramente superior, e começa a fazer sentido até pra modelos menores justamente por causa da banda de memória. Mac Studio com memória unificada de alta velocidade (até 800 GB/s nos M4 Ultra) é a outra opção viável, e custa proporcionalmente o mesmo. Mas nenhuma das duas chega perto de bater os modelos comerciais em qualidade — e o preço de Claude, GPT ou GLM por token, somado à velocidade brutal de inferência deles, faz a conta ser difícil de justificar pra quem não é entusiasta ou pesquisador. Hardware caro de IA local é hobby de fim de semana, ferramenta pra quem precisa rodar offline por compliance, ou playground de pesquisa. Pra trabalho de produção dia após dia, no momento atual, cloud ainda é a escolha racional. Ryzen AI Max com 128 GB pode parecer tentador na planilha, mas se a ideia é coding agent sério, é dinheiro mal gasto.

A família Qwen: Coder vs Geral, distilação, e por que nada é bala de prata

Com tantos Qwens diferentes rodando nessa rerodada, dá pra fazer uma análise mais focada. O que aprendi é capaz de surpreender quem segue benchmark de modelo no Twitter.

Antes de ir aos resultados: o que é quantização e o que é distilação

Os dois conceitos aparecem o tempo todo nessa discussão e merecem uma explicação curta.

Quantização é a técnica de comprimir os pesos do modelo pra ocupar menos memória. Um modelo treinado em FP16 (16 bits por peso) pode ser quantizado pra Q8 (8 bits), Q4 (4 bits), Q3_K_M (3 bits, mas com agrupamentos médios), e por aí vai. Cada passo divide o tamanho do modelo em disco e na VRAM, ao custo de uma certa perda de precisão. Q8 é praticamente lossless. Q4 já perde alguma coisa mensurável. Q3 perde mais. Q2 é o limite onde o modelo começa a falar besteira de verdade. A regra de ouro é que pra coding e raciocínio multi-step, vale ficar em Q4 ou acima. Q3_K_M é o mínimo que ainda funciona pra muitos modelos, e é o que cabe num 27B na 5090 com 128k de contexto.

A surpresa do meu teste, e olha que isso vai contra o consenso, é que a quantização não foi o gargalo aqui. Rodei o Qwen 3.5 27B Claude-distilado em duas versões: Q8 no AMD Strix (~27 GB de pesos) e Q3_K_M na 5090 (~12 GB de pesos). Ambos alucinaram exatamente as mesmas APIs falsas do RubyLLM. O Q3_K_M até gerou um Gemfile mais limpo. A limitação do modelo estava no que esses pesos sabem, não na precisão com que eles foram comprimidos.

Distilação é a técnica de treinar um modelo menor (o “aluno”) pra imitar a saída ou o comportamento de um modelo maior (o “professor”). A versão clássica é distilação de logits — o aluno aprende a aproximar as distribuições de probabilidade do professor. A versão moderna, mais popular pra coding agents, é distilação de traços de raciocínio (reasoning traces): você pega cadeias de pensamento do modelo grande pra problemas reais e treina o menor a reproduzir o mesmo estilo de raciocínio.

O hype do momento é distilar Claude e GPT em modelos open source. A promessa é que dá pra ter “Claude-em-casa” rodando local. Eu queria testar isso, e foi por isso que coloquei no benchmark o Jackrong’s Qwen 3.5 27B distilado do Claude 4.6 Opus. Se algum modelo open source ia conseguir usar o RubyLLM corretamente, era essa aposta — afinal, no benchmark inteiro, Claude e GLM 5 são os únicos que acertam a API.

O que o Claude-distilled aprendeu (e o que não aprendeu)

Rodei a mesma distilação duas vezes: uma em Q8 no AMD Strix (que estourou no timeout de 90 minutos), outra em Q3_K_M na 5090 (completou em 12 minutos). Em ambas, o resultado é a mesma frustração elegante.

O código que sai parece Claude. Tem # frozen_string_literal: true no topo de todo arquivo. Tem uma classe Response separada como value object com leitores de atributo explícitos. Tem separação clara entre service, controller e model. Tem comentário de doc no topo de cada arquivo. Comenta corretamente coisas como active_record, active_job e action_mailer no application.rb. Tem case defensivo tentando múltiplos formatos de retorno. Estilisticamente, é Claude.

Funcionalmente, é alucinação completa do RubyLLM. Olha o serviço gerado pelo run da 5090:

RubyLLM::Chat.new.with_model(@model) do |chat|
  conversation_history.each do |msg|
    chat.add_message(role: :user, content: msg[:content])
  end
  response = chat.ask(message)
  Response.new(content: response.text, usage: build_usage(response))
end

Cada primitiva nesse código é inventada:

• RubyLLM::Chat.new — o construtor não é público, o entry correto é RubyLLM.chat(model:)
• .with_model(@model) do |chat| ... end — não existe API de bloco assim
• chat.add_message(role:, content:) — não existe
• response.text — a API real expõe response.content
• response.usage.prompt_tokens — o objeto não tem essa forma

Isso vai estourar NoMethodError na primeira request. O initializer também tenta config.openrouter_api_base= que não existe no RubyLLM.configure, então o app provavelmente nem boota.

A versão Q8 no AMD Strix faz exatamente o mesmo, com uma diferença: a chamada de entrada é RubyLLM.chat(model:, provider: :openrouter) — o entry point está certo, mas o provider: é inventado e logo em seguida vem o mesmo chat.add_message(role:, content:) falso. Pior, o Gemfile do run de 90 minutos lista gem "ruby-openai" (gem errada!), gem "minitest", "~> 6.0" (não existe minitest 6.0) e gem "tailwindcss" (nome errado, é tailwindcss-rails). O Gemfile não inclui o gem que o próprio service tenta usar.

Pra comparar, olha o Claude Opus 4.6 baseline real, no mesmo benchmark, acertando tudo:

@chat = RubyLLM.chat(model: model_id)
response = @chat.ask(message)
response.content

Doze linhas no service inteiro. Sem alucinação. Inclui streaming via bloco. O modelo distilado produziu o triplo do volume de código e errou a API.

A leitura honesta é que distilação transferiu uma camada e parou. A camada que veio junto foi a do estilo: organização do código, comentários, estrutura de classes, ordem das coisas. A camada que ficou pra trás foi a da memória factual sobre bibliotecas específicas. Isso faz sentido quando você pensa: traços de raciocínio do Claude, mesmo escritos com calma, raramente contêm referências repetidas a chat.ask(msg).content num gem Ruby obscuro. O aluno só aprende o que o professor repete, e Claude nunca teve motivo pra ficar sussurrando “use ask, não use complete” ao longo das suas cadeias de pensamento. Conhecimento de API de biblioteca é memória binária de recall, do tipo que ou está nos pesos ou não está. Decompor isso em passos de raciocínio é impossível porque não é raciocínio, é só lembrança crua.

Pra fechar com a recomendação prática: se você precisa que o modelo realmente use o RubyLLM, ou qualquer biblioteca menos popular que seja, distilação de Claude não te salva. Use Claude de verdade ou GLM 5. Os “Claude-stand-ins” open source vão falhar do mesmo jeito que o Qwen base falharia, só que com letrinha mais bonita.

Coder vs Geral: a surpresa dos modelos “pra coding”

A intuição de quase todo mundo é que modelos com “Coder” no nome são os melhores pra programação. Faz sentido, foram fine-tunados especificamente em código. Mas no benchmark, foi exatamente o oposto.

Dos três Coders dedicados, dois falharam catastroficamente (timeout total e mock string hardcoded) e um nem rodou direito por bug de infra. Já o Qwen 3.5 35B-A3B, que é o modelo geral da linha (não o Coder), foi o que mais perto chegou de algo aproveitável: 5 minutos de execução, projeto Rails reconhecível, e o problema dele se conserta em 1-2 prompts.

O Qwen 3 Coder 30B é particularmente decepcionante. Ele passou longe de qualquer tentativa séria de usar a API: o controller que ele gerou tem isso:

class Api::V1::MessagesController < ApplicationController
  def create
    render json: {
      response: "This is a mock response. In a real implementation, this would connect to RubyLLM with Claude Sonnet via OpenRouter."
    }
  end
end

O Gemfile lista gem "ruby_llm" mas nada importa. O service layer é inexistente. O modelo decidiu que era mais fácil devolver uma string fake e seguir a vida. Isso é Tier 3 garbage de uma forma que nem prompt de correção arruma — tem que mandar reescrever do zero.

O Qwen 2.5 Coder 32B é ainda pior: 90 minutos rodando, zero arquivos. O opencode-output.ndjson de 1.8 MB mostra o modelo girando sem conseguir escrever nada. Provavelmente entrou em loop de planejamento sem nunca chamar as ferramentas de write. Total perda de slot.

Por que os “Coder” Qwens foram tão mal? Minha leitura é que o fine-tuning específico pra coding deles foi treinado em problemas mais isolados (Codeforces, Leetcode, snippets curtos), longe dos fluxos agentic com tool calling de longa duração. O modelo geral Qwen 3.5 35B-A3B tem treinamento mais amplo e se vira melhor com a parte de orquestração. A intuição popular “Coder = melhor pra coding agent” tá errada pra esse tipo de tarefa. O caso de uso onde os Coders se saem bem é “completar uma função isolada”, que é exatamente pro que eles foram treinados, e isso é uma fração pequena do que um coding agent faz no dia a dia.

A pergunta que eu queria responder

Era essa: rodando local na 5090, qual modelo Qwen vale o 1-2 prompts de correção pra entregar código que funcione?

A resposta honesta é: só o Qwen 3.5 35B-A3B, e talvez o Claude-distilado se você não se importa de gastar 12 minutos a mais.

• Qwen 3.5 35B-A3B na 5090: 5 minutos, entry point certo (RubyLLM.chat(model:)), erros nas chamadas seguintes. Total realista até funcionar: na faixa de 15-20 minutos com 1-2 follow-ups. Bate cloud OSS na conta de custo.
• Qwen 3.5 27B Claude-distilado na 5090: 12 minutos, alucinação mais profunda (entry point inventado também). Total realista: 25-30 minutos com 2-3 follow-ups. Ainda compete em custo, e perde em tempo absoluto pro Claude real.
• Os outros (Coder 30B, Coder 2.5 32B, 3 32B): não recompensam o tempo de correção. Cada um tem um problema estrutural que pede reescrita inteira do zero.

Pra quem tem hardware nessa categoria e quer fugir do vendor lock-in da Anthropic, agora dá. Não dava na 5090 do ano passado, no Strix Halo então, esquece. Em 2026, na NVIDIA Blackwell, com o modelo certo, dá. Pra quem tem hardware de banda baixa (LPDDR5x, DDR4, DDR5), continua sendo perda de tempo: o relógio sozinho derruba qualquer plano de tornar isso prático.

Qwen 3.6: o que mudou em relação ao 3.5

Testamos dois sabores do Qwen 3.6: o 3.6 Plus (cloud, OpenRouter, grátis) e o 3.6 35B (local, NVIDIA 5090, Q3_K_M).

O Qwen 3.6 Plus (cloud) completou em 17 minutos com 88.940 tokens e 9/9 no checklist de artefatos. Completou rápido e de graça. Mas o serviço gerado usa chat.add_message(), método que não existe no RubyLLM. A primeira mensagem funciona, a segunda quebra. O mesmo problema do 3.5.

O Qwen 3.6 35B (local, 5090) é mais interessante. Completou em 4.7 minutos a 240 tok/s, 169 arquivos, entry point RubyLLM.chat(model:, provider:) correto e chat.ask(message) correto. O bug é mais sutil: retorna response em vez de response.content e não faz replay de histórico. Correção de 1 linha. Isso é uma melhoria real sobre o Qwen 3.5 35B-A3B (que alucinava add_message e complete). É o resultado Qwen mais limpo que vimos até agora.