Passo semanas fazendo stress-test do modelo on-device da Apple — o de ~3B parâmetros que roda no Neural Engine de qualquer Mac com Apple Silicon. Para testá-lo a fundo, construí o Think Local, um app macOS que exercita cada capacidade do modelo: chat, geração de imagens, structured output, tool calling e comparação de parâmetros.
Minha conclusão: como chatbot, o modelo é terrível. Mas como motor de structured output e tool calling, é surpreendentemente bom.
Essa distinção importa, porque muda completamente para que você deveria usar esse modelo.
O chat é decepcionante — e isso é normal
O modelo da Apple tem uma janela de contexto de 4.096 tokens. Para colocar em perspectiva: o Claude tem 1M de tokens e o GPT-4o tem 128K. Com a Apple, você coloca um system prompt de 200 tokens, um schema de 150 e três turnos de conversa, e já está em 70%.
A qualidade do texto livre também não impressiona. As respostas são corretas mas genéricas, repetitivas em sessões longas, e os guardrails disparam com falsos positivos irritantes — pergunte sobre segurança da informação e às vezes ele se recusa porque interpreta “ataque” literalmente.
Se você avaliar como chatbot, é um modelo medíocre. Mas avaliá-lo assim é como criticar uma chave de fenda porque é um martelo ruim.
Onde brilha: constrained decoding
Aqui tudo muda. Foundation Models suporta @Generable — um macro que converte um struct Swift em um schema que o modelo é obrigado a respeitar. Não é “pedir JSON e torcer”. É constrained decoding: durante a geração, o modelo literalmente não consegue emitir tokens que violem o schema.
@Generable
struct BugReport {
@Guide(.anyOf(["bug", "feature", "task"]))
var type: String
@Guide(.anyOf(["low", "medium", "high", "critical"]))
var priority: String
var title: String
var description: String
}
Com esse schema, você diz “Classify: the app crashes when I rotate the device” e ele retorna:
{
"type": "bug",
"priority": "high",
"title": "Crash on device rotation",
"description": "The application crashes when the user rotates..."
}
Os campos restritos (type, priority) são sempre válidos — ele não consegue inventar um valor fora da lista. Os campos livres (title, description) são coerentes e concisos. Testei com dezenas de inputs diferentes: zero erros de schema em mais de 200 execuções.
A diferença entre geração livre e constrained decoding nesse modelo é brutal. É como a diferença entre pedir para um júnior escrever o que quiser vs. dar para ele um formulário com campos definidos. O formulário sempre ganha.
Tool calling: um modelo de 3B que sabe quando não sabe
Isso foi o que mais me surpreendeu. Defina uma ferramenta get_weather(city: String), pergunte “Que tempo faz em Madrid?” e ele gera uma invocação estruturada com os parâmetros corretos. Pergunte “Qual é a capital da França?” e ele responde diretamente — sabe que não precisa da ferramenta.
Um modelo de 3B parâmetros, rodando no seu notebook sem rede, distingue quando usar uma ferramenta e quando não. Não é perfeito — com prompts ambíguos às vezes se confunde — mas o nível de acerto em inputs claros é notável.
O tool calling da Apple usa o mesmo mecanismo de constrained decoding: a invocação é um struct @Generable, então os parâmetros são sempre válidos. Não tem parsing de JSON quebrado nem parâmetros inventados.
Image Playground: o outro modelo que ninguém menciona
O Apple Intelligence não é só texto. Image Playground é um framework separado que gera imagens on-device em três estilos: animação, ilustração e esboço. Também roda inteiramente no Neural Engine, sem rede.
O padrão se repete: para o que foi projetado, funciona bem. Ícones, stickers, composições simples — resultados surpreendentemente bons. Texto dentro de imagens, anatomia humana detalhada, composições complexas — desastroso.
Think Local inclui um Image Studio onde você pode testar prompts e comparar estilos lado a lado. A intuição que você ganha em dez minutos testando prompts não vem de nenhum benchmark.
Os números
Medido em um Mac com Apple Silicon, usando o monitor de recursos do Think Local:
| Métrica | Valor |
|---|---|
| Velocidade de geração | ~40 tok/s |
| Cold start (sem prewarm) | ~800ms |
| Cold start (com prewarm) | ~200ms |
| RAM do modelo | ~1.2 GB |
| Janela de contexto | 4.096 tokens |
| Parâmetros | ~3B |
| Impacto na bateria | Mínimo (Neural Engine) |
O dado de bateria é relevante: o Neural Engine consome notavelmente menos que a CPU para inferência. Durante a geração, a CPU sobe um pouco por marshalling e UI, mas o trabalho pesado vai para o Neural Engine. Isso torna viável usar o modelo em background para tooling — hooks de git, linters, classificadores — sem drenar o notebook.
Para que serve e para que não serve
Use para:
- Classificação e triagem (bugs, emails, tickets) → constrained decoding com
@Generable - Extração de dados estruturados de texto livre → schemas com
@Guide - Tool calling leve (buscar, calcular, consultar) → invocações type-safe
- Rascunho e resumo de textos curtos → dentro do limite de 4K tokens
- Geração de imagens simples (ícones, stickers, ilustrações) → Image Playground
- Qualquer tarefa onde você consegue definir o formato de saída
Não use para:
- Conversas longas → a janela de 4K se esgota em 3-4 turnos
- Raciocínio complexo ou multi-step → o modelo é pequeno demais
- Geração criativa longa → as respostas são genéricas e repetitivas
- Qualquer coisa que precise de conhecimento pós-outubro 2023
Teste você mesmo
Think Local é open source (MIT). O app exercita todas essas capacidades com UI visual: um visualizador de tokens que mostra o contexto consumido em tempo real, um editor de schemas, um lab de tool calling, e um compare mode para ver como as respostas mudam com parâmetros diferentes.
git clone https://github.com/frr149/think-local.git
cd think-local
open Package.swift
Requisitos: macOS 26, Apple Silicon, Apple Intelligence ativado. Zero dependências, zero API keys.
A conclusão
A Apple não construiu um chatbot. Construiu um motor de inferência local com constrained decoding e tool calling que por acaso também consegue bater papo. Se você avaliar como chatbot, perde para tudo. Se você avaliar como motor de structured output que roda de graça no seu hardware, sem rede e sem API keys — não tem concorrência. Literalmente ninguém mais oferece isso.
A pergunta correta não é “a Apple consegue competir com GPT-4?” — não consegue. A pergunta é “o que posso construir com um modelo de 3B que roda de graça, local, com constrained decoding?” E a resposta é: bastante mais do que você imagina.