Uma GPU gamer de 2020 rodando IA melhor que o Claude Opus?

Parece piada, mas não é. Um desenvolvedor no Hacker News postou que resolveu um problema de equação diferencial ordinária que o Mathematica 14.3 não conseguiu resolver — usando uma placa de vídeo RTX 2070 Super, a 25 tokens por segundo, com um modelo de apenas 3 bilhões de parâmetros.

O modelo se chama VibeThinker-3B, e a equipe do Sina Weibo (sim, a rede social chinesa) publicou um paper no ArXiv afirmando que ele compete de igual para igual com modelos como DeepSeek V3.2 (671 bilhões de parâmetros), Claude Opus 4.5 e Gemini 3 Pro em tarefas de raciocínio lógico e programação competitiva.

Eu já vi modelos pequenos prometerem muito e entregarem pouco. Mas o VibeThinker tem algo diferente: os benchmarks são específicos o suficiente para levantar sobrancelhas — e a controvérsia ao redor dele é ainda mais interessante que os números.

Os números que chamaram atenção

Vamos direto aos dados que o paper apresenta:

O número que explodiu o Hacker News: 94.3 no AIME 2026, exatamente o mesmo score de um modelo com 671 bilhões de parâmetros — 223 vezes maior. No LeetCode, o VibeThinker acertou 123 de 128 problemas na primeira tentativa.

E no IFBench, marcou 74.5 contra 58.0 do Claude Opus 4.5.

Com test-time scaling (onde o modelo “pensa mais” antes de responder), o score no AIME sobe para 97.1.

Como um modelo de 3B faz isso?

A resposta curta: especialização extrema.

A equipe do Weibo não tentou criar um modelo que sabe tudo. Eles pegaram o Qwen 2.5-Coder como base e aplicaram o que chamam de “Spectrum-to-Signal post-training paradigm” — um pipeline de quatro etapas que comprime raciocínio puro em poucos parâmetros.

Etapa 1: SFT Curricular

O modelo passa por fine-tuning supervisionado em um dataset ordenado por dificuldade. Começa com problemas simples de aritmética e lógica básica, depois escala para álgebra, geometria, teoria dos números, e finalmente problemas de competição olímpica. É o mesmo princípio que funciona quando você aprende qualquer coisa — ninguém começa cálculo integral sem saber álgebra.

A sacada aqui é que a ordem dos dados importa tanto quanto os dados em si. Modelos treinados em datasets embaralhados aprendem de forma diferente (e geralmente pior) do que modelos expostos a uma progressão curricular. Quem já treinou um modelo sabe: se você joga problemas de competição no início, o modelo aprende padrões superficiais. Se você constrói a base primeiro, ele internaliza estruturas de raciocínio.

Etapa 2: RL Multi-Domínio

Depois do SFT, vem reinforcement learning em três domínios sequenciais: Matemática → Código → STEM. A ordem é deliberada e não pode ser invertida. O modelo primeiro aprende a raciocinar em provas matemáticas — onde as respostas são verificáveis e não existe ambiguidade. Depois aplica esse raciocínio em código, onde a verificação é automática (o código compila e passa nos testes, ou não). E por fim generaliza para ciências.

Cada etapa de RL usa um reward model diferente, calibrado para o domínio. No RL de matemática, a recompensa é binária: resposta certa ou errada. No RL de código, é baseada em pass rates em test suites. No RL de STEM, combina acurácia com qualidade de explicação.

Etapa 3: Auto-Destilação Offline

Aqui fica interessante. O modelo gera milhares de soluções para cada problema, avalia quais estão corretas (usando os próprios verificadores do RL), e se re-treina apenas nas soluções de maior qualidade. É como um aluno que resolve cem provas, corrige todas, descarta as erradas, e estuda apenas as melhores respostas.

Esse processo é repetido em múltiplos ciclos. A cada iteração, a qualidade média das soluções geradas melhora, criando um loop de auto-aperfeiçoamento que não depende de dados humanos adicionais. Na prática, o modelo está destilando conhecimento de si mesmo — daí o nome “auto-destilação”.

Etapa 4: RL para Instruções

Uma rodada final de reinforcement learning focada em seguir instruções com precisão — formatação, estrutura de resposta, respeito a constraints do prompt. Isso explica por que o modelo pontua tão alto em benchmarks como IFEval (93.4) e IFBench (74.5). Muitos modelos de raciocínio são bons em resolver problemas mas péssimos em entregar a resposta no formato que o usuário pediu. Essa etapa corrige exatamente isso.

O paper propõe uma hipótese formal para justificar por que isso funciona: a Parametric Compression-Coverage Hypothesis. A ideia central é que raciocínio é compressível — você pode espremer capacidade de raciocínio em poucos parâmetros sem perder performance. Já conhecimento geral (saber que pelicanos têm asas, que Paris é capital da França) exige cobertura paramétrica ampla.

Em outras palavras: você pode ensinar um modelo pequeno a pensar, mas não pode ensinar ele a saber tudo.

O que o VibeThinker NÃO faz

E aqui é onde a história fica honesta.

Nos comentários do Hacker News, desenvolvedores que testaram o modelo na prática relataram resultados muito menos impressionantes do que os benchmarks sugerem:

Sem tool calling. O VibeThinker não foi treinado para chamar ferramentas. Isso significa zero capacidade de agente autônomo — ele não consegue buscar na web, executar código, ou interagir com APIs. Para quem trabalha com agentes de IA, isso é um dealbreaker imediato.

Conhecimento geral limitado. Um usuário pediu para gerar um SVG de um pelicano. O modelo não tinha a menor ideia do que era um pelicano. Parece bobagem, mas ilustra perfeitamente a hipótese dos próprios autores: o modelo sacrificou conhecimento por raciocínio.

Caça a bugs? Nem pensar. Um pesquisador de segurança tentou usar o VibeThinker para encontrar vulnerabilidades em código — e o resultado foi “terrivelmente ruim”, nas palavras dele. Encontrar bugs exige não só raciocínio, mas contexto sobre padrões de vulnerabilidade, convenções de linguagem, e conhecimento de frameworks.

Tarefas abertas = desastre. Qualquer tarefa que não tenha uma resposta verificável e fechada tende a falhar. O modelo brilha em “resolva esta integral” ou “implemente este algoritmo”, mas pede para ele escrever um email profissional e o resultado é sofrível.

Benchmaxxing: o elefante na sala

A comunidade de IA tem um termo para isso: benchmaxxing. É quando um modelo é otimizado especificamente para pontuar alto em benchmarks, sem necessariamente ser útil na prática.

E o VibeThinker tem todas as marcas registradas.

Primeiro: todos os benchmarks são auto-reportados. A equipe do Weibo rodou os testes no próprio harness de avaliação. Até o momento da publicação deste artigo, nenhum laboratório independente reproduziu os resultados.

Segundo: a seleção de benchmarks é conveniente. AIME, LeetCode e LiveCodeBench são tarefas com respostas verificáveis e objetivas — exatamente o tipo de problema onde modelos especializados brilham. O paper não reporta performance em tarefas como escrita criativa, análise de sentimento, tradução, ou qualquer coisa que exija mundo aberto.

Terceiro: o modelo é baseado no Qwen 2.5-Coder, que já é um modelo forte em código. O VibeThinker não partiu do zero — partiu de uma base que já sabia programar.

Isso invalida o modelo? Não. Mas coloca os números em perspectiva.

Existe um paralelo interessante com o mundo dos benchmarks de processadores. Quando a AMD lançou chips que batiam a Intel em benchmarks single-thread específicos, a Intel respondeu que “benchmarks não contam a história completa”. E a Intel tinha razão — mas os chips da AMD também eram genuinamente bons. O mesmo vale aqui. O VibeThinker provavelmente é otimizado para os benchmarks que reporta, mas isso não significa que ele é inútil. Significa que você precisa entender onde ele é bom e onde ele vai falhar.

A pergunta que todo engenheiro deveria fazer ao ver resultados de benchmark é: “isso se traduz na minha tarefa específica?” Se sua tarefa é resolver problemas de competição de programação, provavelmente sim. Se é manter um sistema de produção com 200 microserviços, provavelmente não.

Na prática: quando vale usar?

Se você tem uma RTX 2070 ou superior e precisa de um modelo local para:

• Resolver problemas matemáticos — O VibeThinker é absurdamente bom nisso. Se você está estudando para competições de matemática ou precisa de um assistente de cálculo, ele roda na sua máquina sem custo de API.
• Programação competitiva — 96.1% de aceitação no LeetCode é brutal. Se você pratica coding challenges, ter esse modelo rodando localmente é como ter um tutor de plantão.
• Prototipagem rápida de algoritmos — Para implementar soluções algorítmicas rapidamente, o modelo funciona bem. Não espere ele entender seu codebase de 50 mil linhas, mas para funções isoladas ele dá conta.

Não vale a pena se você precisa de:

• Agentes autônomos (sem tool calling)
• Geração de texto criativo ou longo
• Análise de código legado (falta contexto)
• Qualquer tarefa que exija conhecimento do mundo real

Rodando localmente

O modelo está disponível no Hugging Face (WeiboAI/VibeThinker-3B) e roda confortavelmente com quantização de 4 bits:

# Com ollama
ollama pull vibethinker-3b

# Com llama.cpp (GGUF)
./llama-cli -m vibethinker-3b-q4_k_m.gguf -p "Solve: integrate x^3 * ln(x) dx"

Para quem usa Python, a integração com transformers é direta:

from transformers import AutoModelForCausalLM, AutoTokenizer

model = AutoModelForCausalLM.from_pretrained(
    "WeiboAI/VibeThinker-3B",
    torch_dtype="auto",
    device_map="auto"
)
tokenizer = AutoTokenizer.from_pretrained("WeiboAI/VibeThinker-3B")

prompt = "Prove that the sum of the first n odd numbers equals n^2"
inputs = tokenizer(prompt, return_tensors="pt").to(model.device)
outputs = model.generate(**inputs, max_new_tokens=2048)
print(tokenizer.decode(outputs[0], skip_special_tokens=True))

Requisitos mínimos: 2-3 GB de VRAM com Q4. Uma RTX 2060 já roda. Uma RTX 3060 roda com sobra e velocidade boa. Um desenvolvedor no HN reportou 25 tokens por segundo numa RTX 2070 Super — placa de 2019, custando menos de R$ 1.500 usada hoje.

O que isso significa para o futuro dos modelos de IA

O VibeThinker levanta uma questão que a indústria vai precisar responder: até que ponto modelos menores podem substituir os gigantes em tarefas específicas?

A resposta, pelo que sabemos hoje, é “bastante — mas só dentro do domínio de treino”.

O padrão que emerge é claro. Modelos como o VibeThinker, o Needle (que cobrimos aqui no CodeInsider com 26 milhões de parâmetros fazendo tool calling), e o Gemma 4 do Google mostram que a corrida não é apenas por modelos maiores. Existe um mercado enorme para modelos que rodam localmente, offline, sem custo de API, em hardware acessível.

Para empresas, isso significa que nem toda tarefa de IA precisa de uma chamada de API para o Claude ou GPT. Se seu caso de uso é específico o suficiente — validação de fórmulas, resolução de algoritmos, assistência em cálculos — um modelo de 3B rodando num servidor local pode economizar milhares de dólares por mês.

Para desenvolvedores individuais, é liberdade. Rodar IA na sua própria máquina, sem depender de terceiros, sem enviar dados para a nuvem, sem pagar por token.

Mas ninguém deveria trocar o Claude Opus ou o GPT-5.5 por um modelo de 3B para trabalho geral. A real é que esses modelos grandes ainda são insubstituíveis quando você precisa de raciocínio + conhecimento + seguimento de instruções complexas + tool calling, tudo ao mesmo tempo.

O debate que importa

O VibeThinker-3B não é sobre “modelo pequeno beats modelo grande”. É sobre a pergunta certa para o modelo certo.

Se você precisa resolver uma integral, qual é o sentido de pagar R$ 0,15 por chamada de API para um modelo de 671 bilhões de parâmetros quando um modelo de 3 bilhões na sua GPU resolve em 2 segundos?

E se você precisa de um agente que navega na web, lê documentação, escreve código, e abre pull requests? Aí o VibeThinker não chega nem perto.

A indústria de IA adora uma narrativa binária — “modelo X matou modelo Y”. Mas o que estamos vendo em 2026 é a fragmentação. Modelos especializados para tarefas específicas. Modelos gigantes para trabalho generalista. E a habilidade de saber qual usar para cada situação está se tornando o skill mais valioso de um engenheiro de IA.

O código do VibeThinker está no Hugging Face, o paper no ArXiv. Roda na sua máquina. Testa e tira suas próprias conclusões — porque no final, benchmark nenhum substitui a experiência prática.

E se você ainda não tem uma GPU dedicada? Um Raspberry Pi 5 com 16GB de RAM roda modelos quantizados de 3B com velocidade aceitável para testes. Não vai ganhar competição de velocidade, mas vai te dar uma noção de como o modelo se comporta antes de investir em hardware melhor.

A próxima vez que alguém te disser que IA local é impossível sem um cluster de H100, mostra o VibeThinker rodando na sua placa gamer de 2019. Depois a gente discute benchmarks.

Fonte de inspiração: VibeThinker-3B: Exploring the Frontier of Verifiable Reasoning in Small Language Models (ArXiv)