Cactus Hybrid: modelo local com score de confiança

Todo mundo que já tentou colocar um LLM local em produção esbarrou no mesmo muro. O modelo pequeno é rápido, barato e privado — mas às vezes erra. E o pior: erra com a mesma cara de certeza de quando acerta. Você não tem como saber qual resposta confiar. Então desiste do local e manda tudo pra nuvem. Fim da economia, fim da privacidade.

A Cactus atacou exatamente esse ponto. Eles pós-treinaram o Gemma 4 E2B com uma probe de confiança embutida no próprio checkpoint: cada geração sai acompanhada de um score de 0 a 1 dizendo o quanto o modelo confia na própria resposta. Score alto? Fica no device. Score baixo? A query escala pro modelo grande na nuvem. Automaticamente.

Neste post vamos destrinchar como a probe funciona, ver o código de integração (spoiler: o roteamento é um if), fazer a conta de custo e mapear onde isso quebra. Porque quebra — e é bom saber onde antes de colocar num produto.

TL;DR

O que é: Cactus Hybrid — Gemma 4 E2B pós-treinado com probe de confiança nativa; cada resposta carrega um score 0–1 estruturado pra decidir se escala pra nuvem.
Stack/Modelos: checkpoints no Hugging Face (gemma-4-e2b-it-hybrid, variantes MLX e GGUF Q4_K_M); integra com Cactus SDK, MLX e Transformers.
Custo/Acesso: open-source, MIT (termos de uso do Gemma à parte). Roda local; a nuvem só entra no handoff.
Resultado-chave: iguala o Gemini 3.1 Flash-Lite em benchmarks roteando só 15–55% das queries. AUROC de 0,814 na detecção de erro, contra 0,549 da entropia de tokens.

O contexto: por que "saber quando está errado" muda o jogo

O padrão dominante hoje é binário. Ou você manda tudo pra nuvem (caro, latência de rede, dado do usuário viajando), ou roda tudo local (barato, privado, mas com teto de qualidade baixo). Router de queries já existe, claro — mas os routers clássicos decidem antes da inferência, chutando a dificuldade da pergunta, ou dependem de heurísticas frágeis sobre a saída.

A heurística mais comum é a entropia de tokens: se o modelo distribui probabilidade entre muitos tokens, ele "está em dúvida". Parece razoável. Na prática, funciona mal — o benchmark da Cactus mede AUROC de 0,549 pra entropia como detector de erro. Isso é quase moeda ao ar (0,5 seria aleatório). O modelo pode estar linguisticamente confiante e factualmente errado. Alucinação é exatamente isso.

A probe da Cactus ataca por outro ângulo: em vez de olhar a distribuição de tokens, ela lê o hidden state do modelo — e foi treinada, no pós-treino, pra mapear esse estado interno num sinal de correção. AUROC médio de 0,814. O detalhe mais interessante do repo: a probe foi treinada com zero dados de áudio e mesmo assim atinge 0,79–0,88 de AUROC em quatro benchmarks de áudio. Ou seja, ela não decorou padrões de superfície de um domínio. Ela aprendeu a ler um sinal de correção que independe da modalidade. Isso é o que separa um truque de benchmark de um mecanismo generalizável.

O resultado prático, medido contra o Gemini 3.1 Flash-Lite como modelo de escape: o Gemma 4 E2B Hybrid iguala o Flash-Lite nos benchmarks roteando só uma fração das queries — 15–20% no ChartQA, 30–35% no MMBench, 45–55% no MMLU-Pro (números do checkpoint FP16). O anúncio fez 185 pontos no Hacker News em 22 de julho, e não foi hype à toa: é um padrão de integração novo, não só mais um modelo.

Pré-requisitos e ferramentas

Pra reproduzir o exemplo abaixo você precisa de:

[ ] Python 3.11+ com transformers>=5.5.4 e torch (ou mlx-lm no Mac, ou o cactus-compute SDK pra mobile)
[ ] Hardware pra rodar um E2B: qualquer GPU modesta, Apple Silicon ou até CPU aguentam — é um modelo pequeno por design
[ ] Uma chave de API do modelo grande que vai receber o handoff (Gemini, Claude, o que seu produto já usa)

Se você nunca rodou modelo local, o caminho das pedras está no nosso guia como rodar LLM local.

▪ Clã Beer and Code

Não só acompanhe as novidades — domine. Engenharia de IA na prática, ao vivo, toda semana, na maior comunidade do Brasil.

Entrar no Clã

Mão na massa: o roteamento é um if

Passo 1: gerar resposta com confiança estruturada

O ponto central da API: o score não é extraído do texto da resposta. Ninguém está pedindo pro modelo "diga sua confiança" no prompt — isso seria pedir pra raposa auditar o galinheiro. O score vem como campo estruturado da inferência. Com Transformers:

import torch
from transformers import AutoModelForCausalLM, AutoTokenizer

model_id = "Cactus-Compute/gemma-4-e2b-it-hybrid"
device = "cuda" if torch.cuda.is_available() else "cpu"

tokenizer = AutoTokenizer.from_pretrained(model_id, trust_remote_code=True)
model = AutoModelForCausalLM.from_pretrained(
    model_id, trust_remote_code=True, dtype="auto"
).to(device)

messages = [{"role": "user", "content": "Qual a capital da França?"}]
inputs = tokenizer.apply_chat_template(
    messages, add_generation_prompt=True, return_tensors="pt", return_dict=True
).to(device)

out = model.generate(**inputs, return_confidence=True, max_new_tokens=512)

print(tokenizer.decode(out.sequences[0][inputs["input_ids"].shape[-1]:]))
print("confidence:", out.confidence)

Um parâmetro (return_confidence=True), um campo (out.confidence). No MLX é model.last_confidence depois do generate; no Cactus SDK o cactus_complete() devolve result["confidence"] direto — e tem até um flag auto_handoff pra quem quer que o SDK resolva o roteamento sozinho.

Passo 2: rotear

Toda a arquitetura "local-first com escalonamento por confiança" cabe nisto:

if confidence < 0.85:
    answer = ask_a_bigger_model(prompt)

É esse o snippet do README oficial. Sem classificador externo, sem segundo modelo julgando o primeiro, sem parsing de texto. O threshold de 0,85 é o ponto de partida sugerido — e é aqui que entra a engenharia de verdade: esse número é uma decisão de produto. Threshold alto = mais qualidade, mais handoff, mais custo. Threshold baixo = mais economia, mais respostas locais erradas passando. Você calibra com os seus dados, não com os do benchmark.

Passo 3: fazer a conta de custo

Chame de C o custo médio de uma query no modelo de nuvem. Hoje, num app 100% cloud, 1 milhão de queries custa 1.000.000 × C. Com o padrão híbrido e um handoff de 30% (a faixa do MMBench), a mesma carga custa 300.000 × C — queda de 70% na fatura de inferência, com qualidade equivalente à do Flash-Lite no benchmark. No perfil do ChartQA (15–20% de handoff), a queda passa de 80%.

E custo é só uma das três colunas. Latência: 70–85% das respostas nem tocam a rede — inferência local não tem round-trip. Privacidade: a maioria dos dados do usuário nunca sai do device; só o subconjunto difícil viaja. Pra qualquer app mobile, extensão ou desktop com LLM embarcado, essa conta muda a arquitetura inteira.

Limitações e pontos de atenção

Primeiro: quantização degrada a probe junto com o modelo. Os números bonitos são do FP16. Em 4-bit, o handoff do ChartQA sobe pra 25–30% e o do MMLU-Pro vai pra ~90% — nesse ponto o "modelo local" virou um proxy caro pra nuvem. Em 3-bit, MMLU-Pro nem fecha a conta. Se seu caso de uso é conhecimento factual denso, o híbrido quantizado agressivamente não te salva.

Segundo: suporte de runtime ainda é cru. Rodar via llama.cpp exige compilar uma engine patchada pra expor a probe. O caminho feliz hoje é Transformers, MLX ou o SDK da própria Cactus.

Terceiro: confiança não é garantia. AUROC 0,814 é muito melhor que 0,549, mas não é 1,0. Vai existir resposta errada com score alto passando pelo filtro. Pra caso de uso crítico (médico, financeiro, jurídico), a probe reduz risco — não elimina. Trate o score como sinal de roteamento, não como selo de verdade.

Quarto: o benchmark de paridade é contra o Flash-Lite — o degrau mais barato da nuvem. Igualar um frontier model é outra conversa.

FAQ rápido

Posso usar comercialmente? Sim. O código é MIT, mas os pesos herdam os termos de uso do Gemma do Google — leia antes de embarcar num produto. São permissivos pra uso comercial, com restrições de uso proibido.

Funciona com qualquer modelo de nuvem no handoff? Sim. O ask_a_bigger_model() é seu — pode ser Gemini, Claude, GPT ou um modelo maior self-hosted. O benchmark de paridade usou Gemini 3.1 Flash-Lite, mas o roteamento não depende do destino.

Por que não usar logprobs/entropia que já existem de graça? Porque o sinal é ruim: AUROC de 0,549, quase aleatório. O modelo alucina com fluência — a distribuição de tokens não denuncia erro factual. A probe lê o hidden state e foi treinada especificamente pra prever correção. É outra categoria de sinal.

Isso funciona pra outros modelos além do Gemma 4 E2B? Hoje os checkpoints publicados são do E2B (coleção no Hugging Face). A técnica — probe de correção treinada no pós-treino — é geral, e a evidência de generalização entre modalidades sugere que veremos isso replicado em outros modelos rápido.

Conclusão

O Cactus Hybrid não é "mais um modelo pequeno". É a primeira implementação aberta e usável de um padrão que faltava: local-first com escalonamento por confiança, onde o próprio modelo carrega o sinal de quando pedir ajuda. Um if confidence < 0.85 substitui uma arquitetura inteira de roteamento.

A provocação: se todo checkpoint pequeno passar a sair de fábrica com probe de confiança — e depois desse repo, a pressão pra isso existe — o padrão "tudo na nuvem" vira desperdício difícil de justificar. A pergunta deixa de ser "local ou nuvem?" e vira "qual threshold?".

E se você quer contexto sobre o que um modelo local aguenta hoje na prática, com custo real medido, veja nosso teste Claude Opus 4.8 vs Minimax M3 vs Qwen 3 local: o mesmo produto construído três vezes, do frontier pago ao local de graça.