ThinkingCap é uma versão retreinada do Gemma 4 26B-A4B do Google que usa, em média, 38,9 por cento menos tokens de raciocínio com quase a mesma precisão: 75,0 versus 75,2 do modelo base em doze benchmarks. BottleCap AI o publicou em 23 de outubro de 2026 sob licença Apache 2.0, com os pesos completos e versões GGUF no Hugging Face.
É uma substituição direta (drop-in replacement): só mudam os pesos. O template de chat, o tokenizador e a configuração de amostragem recomendada são do modelo base. Todos os números são medições do próprio BottleCap: estão bem feitas, mas ninguém as reproduziu de forma independente ainda. E, como mostra a ficha GGUF do mesmo time, a economia não chega intacta aos arquivos que a maioria executa localmente.
O que são tokens de raciocínio e por que convém reduzi-los?
Os tokens de raciocínio (reasoning tokens ou thinking tokens, em inglês) são o texto que um modelo escreve para si mesmo antes de responder: o rascunho onde resolve o problema passo a passo. Quase nunca você lê, mas paga tudo inteiro em tempo, em energia e em janela de contexto.
Em problemas de matemática difíceis, o Gemma 4 26B escreve entre 15.000 e 22.000 tokens de raciocínio por pergunta. Cortar um terço disso muda quanto você espera por cada resposta e quantas requisições uma única máquina consegue atender. A proposta do BottleCap é exatamente essa: as mesmas respostas, com menos pensamento pelo caminho.
O que é Gemma 4 26B-A4B?
gemma-4-26B-A4B-it é o modelo intermediário da família Gemma 4 do Google DeepMind, com arquitetura de mistura de especialistas (mixture of experts, MoE). Armazena cerca de 26 bilhões de parâmetros, mas ativa apenas cerca de 4 bilhões por token: a cada passo executa 8 de seus 128 especialistas. Isso lhe dá o conhecimento de um modelo grande com um custo de computação próximo ao de um pequeno. Também aceita imagens como entrada.
Seu modo de raciocínio está desligado por padrão: cada requisição precisa ativá-lo com enable_thinking. Todos os números do ThinkingCap foram medidos com o raciocínio ativado, então se você executar o modelo sem ele, não há nada para poupar.
Quantos tokens de raciocínio o ThinkingCap poupa?
Em média, 38,9 por cento em doze benchmarks. Mas a economia varia bastante conforme a tarefa:
| Benchmark | Precisão base | Precisão ThinkingCap | Tokens base | Tokens ThinkingCap | Redução |
|---|---|---|---|---|---|
| LongBench v2 | 59,43 | 60,88 | 9.486 | 2.934 | 69,1% |
| AA-LCR | 64,62 | 60,62 | 6.519 | 2.655 | 59,3% |
| MMLU-Pro | 84,55 | 84,64 | 3.907 | 1.989 | 49,1% |
| GPQA-Diamond | 79,92 | 78,96 | 7.699 | 4.284 | 44,4% |
| AIME 2026 | 86,20 | 86,72 | 14.766 | 8.963 | 39,3% |
| HMMT (fev. 2026) | 72,92 | 74,20 | 22.005 | 14.717 | 33,1% |
| LiveCodeBench v6 | 76,98 | 76,96 | 11.560 | 8.375 | 27,6% |
| τ²-bench | 64,25 | 63,73 | 4.374 | 3.466 | 20,8% |
| IFBench | 76,83 | 78,67 | 6.470 | 5.585 | 13,7% |
| Média (12 benchmarks) | 75,2 | 75,0 | 8.773 | 5.398 | 38,9% |
Seleção de linhas; a tabela completa com doze benchmarks está na ficha do modelo.
As tarefas de contexto longo e de conhecimento são as que mais cortam; código corta menos. Seguimento de instruções e uso de ferramentas em modo agente praticamente não mudam. A explicação do BottleCap é que essas tarefas não consistem em pensar muito, mas em cumprir uma lista de restrições ou uma política fixa.
A segunda melhoria é menos evidente e talvez mais útil na prática: menos loops. O modelo base fica repetindo o mesmo raciocínio em 3,64 por cento de suas respostas; ThinkingCap, em 0,76 por cento. No conjunto de matemática mais difícil (HMMT de fevereiro de 2026), os loops caem de 17,0 para 4,5 por cento. Uma resposta em loop é uma resposta perdida: corre até o limite de tokens e não devolve nada.
ThinkingCap perde precisão frente ao Gemma 4?
Em média, quase nada: 0,15 pontos. Cinco dos doze benchmarks até saem ligeiramente na frente. Mas “sem perda de qualidade” é uma média, não uma garantia. Quatro benchmarks se movem mais do que o ruído entre execuções explica:
- AA-LCR (raciocínio sobre contexto longo): −4,00 pontos. BottleCap reconhece como o único custo real do conjunto. Se seu trabalho consiste em raciocinar sobre documentos muito longos, teste antes de mudar.
- GPQA-Diamond: −0,96 pontos, e MMMLU (multilingue): −0,66 pontos.
- IFBench (seguimento de instruções): +1,83 pontos, desta vez a favor do ThinkingCap.
Quanto ao método, a avaliação é mais sólida que a maioria das cifras autodeclaradas:
- Ambos os modelos medidos por eles mesmos. BottleCap executou o modelo base em lugar de citar as cifras do Google, com o mesmo arnês de avaliação, o mesmo hardware e a mesma configuração de amostragem para os dois.
- Muitas sementes por benchmark. Cada um foi executado entre 4 e 64 vezes, com intervalos de confiança de 95 por cento.
- O ambiente de serviço: vLLM 0.26.0 sobre uma NVIDIA GB300 por servidor, com os pesos completos em bf16.
Esse último detalhe importa se você pensa executá-lo em sua própria máquina.
O ahorro se mantém com quantização GGUF em llama.cpp?
Só em parte, conforme os próprios números do BottleCap. O time testou seu arquivo GGUF recomendado (MXFP4_MOE, 16,6 GB) em llama.cpp contra ThinkingCap em bf16, em nove dos doze benchmarks. Com quantização, o comprimento do raciocínio se desloca nas duas direções:
- AIME 2026: 15,5 por cento mais tokens de raciocínio que a versão bf16
- IFBench: 6,9 por cento mais
- GPQA-Diamond: praticamente igual
- MMLU-Pro: 8,0 por cento menos
- HMMT (fev. 2026): 25,0 por cento menos
A ficha acrescenta que até o GGUF sem quantizar (BF16) em llama.cpp pensa mais que o checkpoint original servido com vLLM: 6,1 por cento mais em AIME e 14,7 por cento mais em GPQA. Ou seja, o próprio runtime muda o comprimento do raciocínio, independente da quantização.
O que não foi publicado é a comparação que realmente importa a quem trabalha localmente: Gemma 4 base em GGUF contra ThinkingCap em GGUF, na mesma máquina. No momento de publicar esta nota (24 de outubro de 2026), nem BottleCap nem ninguém mais tinha publicado essa medição. Espere uma economia real localmente, mas não conte com os 38,9 por cento completos.
Como usar ThinkingCap com llama.cpp ou Ollama?
BottleCap documenta llama.cpp. Estes comandos vêm de sua ficha GGUF:
# serve an OpenAI-compatible endpoint, thinking on, with the base model's recommended sampling
llama-server -hf bottlecapai/ThinkingCap-gemma-4-26B-A4B-it-GGUF:MXFP4_MOE \
--jinja --chat-template-kwargs '{"enable_thinking":true}' --reasoning-format deepseek \
--temp 1.0 --top-p 0.95 --top-k 64 -ub 2048 -b 2048
Com --reasoning-format deepseek, o servidor devolve o raciocínio em reasoning_content e a resposta em content, então você consegue contar os tokens de raciocínio você mesmo. BottleCap faz dois avisos:
- Mantenha a temperatura em 1.0. A decodificação gulosa pode fazer o modelo entrar em loop.
- Mantenha
-ub 2048 -b 2048se enviar imagens. Com o tamanho de lote padrão do llama.cpp, uma imagem grande pode derrubar o servidor.
Ollama, LM Studio e Jan carregam os mesmos arquivos GGUF. A página do Hugging Face gera este comando para Ollama:
ollama run hf.co/bottlecapai/ThinkingCap-gemma-4-26B-A4B-it-GGUF:Q4_K_M
Tenha em mente duas coisas. Esse comando baixa Q4_K_M, que conforme BottleCap performou pior em matemática que MXFP4_MOE. E a ficha do BottleCap não explica como ativar o raciocínio em Ollama, LM Studio ou Jan; sem raciocínio ativado, ThinkingCap não tem nada para poupar. Se quer medir a diferença, use llama.cpp.
Qual arquivo GGUF baixar?
| Arquivo | Tamanho | Notas |
|---|---|---|
MXFP4_MOE |
16,6 GB | Recomendado por BottleCap; é o que avaliaram |
Q4_K_M |
17,0 GB | Performou pior em seus benchmarks de matemática que MXFP4_MOE |
IQ4_XS |
13,6 GB | O menor; não avaliado por BottleCap |
Q6_K / Q8_0 |
23,3 / 26,9 GB | Mais precisão, mais memória |
mmproj-…-f16 |
1,19 GB | Projetor de visão, necessário para enviar imagens |
Em equipos com pouca memória, IQ4_XS é o que cabe, mas também é o único sem números publicados. Se já executa Gemma 4 localmente, nosso guia sobre qual variante de Gemma 4 escolher conforme a RAM de seu Mac cobre a parte de memória.
Para servidores com GPU, a ficha principal documenta vLLM, com parsers de raciocínio e de chamadas a ferramentas:
vllm serve bottlecapai/ThinkingCap-gemma-4-26B-A4B-it --max-model-len 262144 \
--reasoning-parser gemma4 --enable-auto-tool-choice --tool-call-parser gemma4
Os pesos completos em bf16 ocupam cerca de 52 GB.
Quem está por trás do ThinkingCap?
BottleCap AI. É o quinto modelo de sua série ThinkingCap, depois de duas variantes do Qwen3 27B, Nemotron 3.5 Lightning da NVIDIA e Qwen3.8-Flash-Next, e o primeiro construído sobre um modelo do Google. Entre os autores que figuram na citação do modelo está Tomas Mikolov, conhecido por word2vec.
BottleCap também vende uma versão comercial “PRO” que, conforme a empresa, corta o raciocínio 62 por cento em média. Não há nada público sobre ela, então tome como um argumento de venda. No momento de publicar esta nota, a página do modelo gratuito no Hugging Face ainda não mostrava números de downloads: é muito recente.
Quando convém usar ThinkingCap?
- Convém: trabalho com contexto longo, matemática e perguntas de conhecimento onde Gemma 4 pensa muito, e qualquer ambiente onde loops fazem você perder tempo ou GPU.
- Tanto faz: seguimento de instruções e uso de ferramentas em modo agente, onde o ahorro é pequeno (entre 14 e 21 por cento).
- Teste antes: raciocínio sobre documentos longos (a queda em AA-LCR) e qualquer configuração GGUF localmente, onde a cifra principal não foi medida.
Como é uma substituição direta com a mesma licença, a forma mais barata de sair da dúvida é passar seus próprios prompts pelos dois modelos com o raciocínio ativado e comparar o comprimento de reasoning_content.
E você? Ativa o modo de raciocínio quando executa modelos localmente, ou deixa desligado para ganhar velocidade?
- llama.cpp
- Ollama
- LM Studio
- Prefiro outra opção (conte qual)
Comente abaixo ou, se este artigo chegou por email, responda direto ao email: sua resposta se publica aqui.
Relacionado: LM Studio, Ollama ou llama.cpp: qual realmente roda em sua máquina