IA de 20B Rodando a 120 tok/s no iPhone: Como o Maple-Preview Usa Pesos Ternários para Ser 16x Mais Rápido

Imagina rodar um modelo de linguagem com 20 bilhões de parâmetros no seu iPhone. Sem servidor, sem nuvem, sem latência. A 120 tokens por segundo. Parece ficção científica? A DeepGrove acabou de fazer exatamente isso com o Maple-Preview, e a comunidade de IA está pirando.

O segredo não é mágico: é matemático. Enquanto a maioria dos modelos usa pesos em ponto flutuante de 16 bits, o Maple-Preview opera com pesos ternários, ou seja, cada peso pode ser apenas -1, 0 ou +1. Essa restrição brutal transforma multiplicações complexas em simples somas, e o resultado é um modelo de 5,31 GB que cabe na memória de qualquer celular moderno.

O que é o Maple-Preview e por que ele importa

O Maple-Preview é um modelo de linguagem open source (licença MIT) desenvolvido pela DeepGrove AI. Ele combina duas técnicas que, juntas, criam algo que não deveria funcionar tão bem: pesos ternários e Mixture of Experts (MoE).

Eu vou ser direto: modelos que rodam no celular não são novidade. O que é novidade é um modelo de 20 bilhões de parâmetros resolvendo problemas de olimpíada de matemática (IMO) a 120 tokens por segundo num iPhone. Isso muda a conversa sobre IA local.

A arquitetura usa atenção do tipo SWA-512 (Sliding Window Attention) combinada com Group Attention numa proporção de 3:1. Na prática, isso significa que o modelo consegue processar contextos longos sem explodir o consumo de memória.

Pesos ternários: quando menos é absurdamente mais

Vamos falar de como funciona essa loucura.

Num modelo convencional, cada peso é um número de ponto flutuante com 16 bits de precisão (bfloat16). Quando o modelo processa um token, ele faz bilhões de multiplicações entre esses pesos e os valores de ativação. Cada multiplicação consome energia, tempo e memória.

No modelo ternário, cada peso é restrito a três valores: -1, 0 ou +1. O que isso significa na prática?

• Se o peso é 0: ignora completamente aquela conexão. Zero custo.
• Se o peso é +1: soma o valor de ativação diretamente. Sem multiplicação.
• Se o peso é -1: subtrai o valor de ativação. Também sem multiplicação.

# Modelo convencional (float16)
resultado = peso * ativação  # multiplicação cara

# Modelo ternário
if peso == 0:
    resultado = 0           # pula
elif peso == 1:
    resultado = ativação     # copia
else:  # peso == -1
    resultado = -ativação    # inverte sinal

Troca-se uma operação de multiplicação por uma operação de soma (ou nenhuma operação). Em escala de bilhões, o ganho é monstruoso.

Aqui é onde a maioria dos artigos erra ao explicar modelos ternários: eles fazem parecer que é uma simples “compressão” pós-treino, como se você pegasse um modelo pronto e espremesse os pesos. O Maple-Preview não faz isso. Ele foi treinado do zero com pesos ternários. A diferença é enorme.

Quando você quantiza um modelo depois do treino, está jogando informação fora. Quando você treina nativamente com pesos ternários, o modelo aprende a distribuir a inteligência de forma diferente. Ele compensa as limitações dos pesos simples usando mais experts, mais camadas, e padrões de ativação mais inteligentes.

256 experts, 8 ativos: o MoE que faz tudo funcionar

Se pesos ternários são o motor, a arquitetura Mixture of Experts é o câmbio.

O Maple-Preview tem 256 experts especializados. Para cada token processado, apenas 8 desses experts são ativados. Isso significa que, apesar de ter 20 bilhões de parâmetros no total, apenas cerca de 1 bilhão está ativo em qualquer momento.

Pensa assim: é como ter 256 consultores especializados, mas para cada pergunta você só chama os 8 mais relevantes. Você tem o conhecimento de todos, mas paga o custo computacional de poucos.

A combinação ternário + MoE é poderosa porque resolve dois problemas de uma vez. O MoE reduz o compute ativo. Os pesos ternários eliminam as multiplicações restantes. O resultado: 5 a 16x mais rápido que modelos comparáveis como Gemma 4 e Qwen3.5.

Benchmarks: números que fazem barulho

Aqui é onde o Maple-Preview fica interessante de verdade.

No Mac Mini M4, ele atinge 218 tokens por segundo. No iPhone, 120 tok/s. Para contexto, o GPT-4o via API entrega algo em torno de 80 a 100 tok/s, e isso passando por servidores com GPUs H100.

Os benchmarks de raciocínio são surpreendentemente bons para um modelo tão compacto:

• AIME 2026: resolve problemas de competição de matemática de nível avançado
• HMMT 2026: lida com problemas de competição de Harvard-MIT
• GPQA-D: acerta questões de doutorado em ciências
• LCBv6: performance competitiva em coding

A DeepGrove afirma que o Maple-Preview “define novos pontos na fronteira de Pareto para relação memória/performance e velocidade/performance”. Em português: nenhum outro modelo consegue essa combinação de tamanho pequeno, velocidade alta e raciocínio forte.

Agora, preciso ser honesto sobre as limitações.

Onde o Maple-Preview tropeça (e feio)

Modelo pequeno é modelo pequeno. Não adianta fingir que 1B de parâmetros ativos com pesos ternários vai competir com o Claude Opus ou o GPT-5.5 em conhecimento geral.

Na discussão do Hacker News, vários devs testaram o modelo e encontraram problemas sérios de alucinação factual. Um teste simples pedindo a etimologia de uma palavra gerou uma resposta completamente inventada, com datas e origens fictícias escritas com total confiança.

Isso não é bug, é limitação estrutural. Modelos menores não conseguem armazenar o mesmo volume de conhecimento que modelos maiores. O Maple-Preview compensa isso com raciocínio forte (ele sabe “pensar”), mas o conhecimento factual que ele carrega é limitado.

A própria DeepGrove reconhece no card do modelo:

O pós-treino foi mínimo, focado especificamente em raciocínio. Pode ter performance inferior em benchmarks de agentes.

Ou seja: ele é bom em raciocinar sobre o que você dá para ele, mas não espere que ele saiba tudo sobre o mundo. A real é que o caso de uso ideal é outro: ferramenta de raciocínio local, tool-calling, processamento de documentos no device.

Na prática: como rodar o Maple-Preview

Rodar o modelo é surpreendentemente simples. Ele suporta as ferramentas mais populares do ecossistema.

Com Transformers (PyTorch)

from transformers import pipeline

pipe = pipeline(
    "text-generation",
    model="deepgrove/maple-preview",
    trust_remote_code=True
)

messages = [
    {"role": "user", "content": "Explique quicksort em 3 passos"}
]

response = pipe(messages)
print(response[0]["generated_text"])

Com vLLM (produção)

pip install vllm
vllm serve "deepgrove/maple-preview"

# API compatível com OpenAI
curl -X POST "http://localhost:8000/v1/chat/completions" \
  -H "Content-Type: application/json" \
  --data '{
    "model": "deepgrove/maple-preview",
    "messages": [
      {"role": "user", "content": "Qual a complexidade do merge sort?"}
    ]
  }'

Com SGLang

pip install sglang
python3 -m sglang.launch_server \
    --model-path "deepgrove/maple-preview" \
    --host 0.0.0.0 \
    --port 30000

Um detalhe importante: o modelo exige trust_remote_code=True porque usa implementações customizadas para os kernels ternários. Isso é normal para modelos com arquiteturas não-padrão, mas vale prestar atenção se você está rodando em ambiente de produção.

O contexto maior: a corrida pela IA no bolso

O Maple-Preview não existe no vácuo. Ele faz parte de uma tendência que está acelerando: a descentralização da IA.

Em julho de 2026, a PrismML lançou o Bonsai 27B, builds ternárias e de 1-bit do Qwen 3.6 que rodam em laptops e celulares. A Microsoft tem o BitNet. A Apple vem investindo pesado em modelos on-device com o Apple Intelligence. O Google roda o Gemini Nano direto no Chrome e lançou a Prompt API para que qualquer dev rode IA no navegador sem servidor.

A lógica é simples: quem controla a inferência controla o jogo. Se a IA roda na nuvem, você depende do provedor (e da conexão, e do preço, e dos termos de uso). Se roda no seu device, você tem soberania total sobre os seus dados e o seu modelo.

Esse movimento tem um nome: edge AI. E os números explicam por que as big techs estão apostando nele. Segundo análises recentes, o mercado de inferência na nuvem cresce 40% ao ano, mas o custo por token para os provedores também cresce. Cada novo modelo de fronteira exige mais GPUs, mais energia, mais refrigeração. Em algum momento, a conta não fecha.

A alternativa? Empurrar o máximo de inferência possível para o device do usuário. O Apple Intelligence já faz isso. O Chrome instalou 4 GB de IA no seu PC sem pedir (a gente escreveu sobre isso). E agora modelos como o Maple-Preview mostram que inferência local de alta qualidade é viável em hardware que cabe no bolso.

Para devs, isso abre possibilidades que não existiam há um ano:

• Apps offline com IA: imagine um editor de código com autocomplete inteligente que funciona sem internet, no avião, no metrô
• Privacidade real: processamento de documentos sensíveis sem enviar nada para servidores externos. Compliance com LGPD e GDPR fica trivial quando os dados nunca saem do device
• Latência zero: 120 tok/s no device vs. 80 tok/s passando por uma API que mora a 200ms de distância. Para UX, essa diferença é brutal
• Custo zero de inferência: depois de baixar o modelo, cada token gerado é grátis. Escala para milhões de usuários sem escalar a conta de cloud

Ternário vs. quantização tradicional: por que treinar do zero importa

Existe uma diferença fundamental entre o que o Maple-Preview faz e o que ferramentas como GGML/llama.cpp fazem quando você baixa um modelo Q4_K_M.

A quantização pós-treino (PTQ) pega um modelo treinado em float16 e comprime os pesos para inteiros de 4 bits, 2 bits, ou até 1 bit. O processo inevitavelmente perde informação. Quanto mais agressiva a quantização, mais o modelo degrada.

O treino nativo ternário é diferente. O modelo nunca conheceu pesos de alta precisão. Desde o primeiro passo de treino, ele aprendeu a representar conhecimento usando apenas -1, 0 e +1. É como a diferença entre comprimir um MP3 para 64kbps (perde qualidade) e gravar diretamente em 64kbps com um codec otimizado (qualidade surpreendentemente boa).

O paper do BitNet b1.58 da Microsoft Research foi o primeiro a demonstrar que modelos treinados nativamente com pesos ternários (1.58 bits por peso) podem igualar a performance de modelos float16 do mesmo tamanho. O Maple-Preview leva essa ideia adiante, combinando com MoE para escalar sem explodir o custo computacional.

Comparação de custo por operação:

Float16:  1 multiplicação = ~20 operações de hardware
Int8:     1 multiplicação = ~4 operações de hardware
Int4:     1 multiplicação = ~2 operações de hardware
Ternário: 0 multiplicações = 1 soma ou 0 operações

Essa diferença no nível do silício é o que permite 218 tok/s num chip M4 que não foi projetado para IA.

Quando usar (e quando não usar) o Maple-Preview

Eu sei que a tentação é pegar o modelo e sair usando para tudo. Resiste.

Use o Maple-Preview para:

• Raciocínio matemático e lógico local
• Tool-calling e agentic workflows onde velocidade importa mais que conhecimento
• Processamento de documentos que você já fornece como contexto
• Prototipagem rápida de features de IA em apps mobile
• Backup rápido quando a API do seu provedor cai

Não use para:

• Perguntas factuais que exigem conhecimento enciclopédico
• Geração de conteúdo longo onde precisão factual é crítica
• Substituir completamente modelos de fronteira em produção
• Qualquer coisa onde uma alucinação confiante pode causar dano real

O ponto de ouro está em combinar o Maple-Preview com um modelo maior via fallback. Use o modelo local para 80% das requisições (as rápidas e simples) e escale para a nuvem nos 20% que exigem mais.

O que vem depois

A DeepGrove deixou claro que o Maple-Preview é exatamente isso: um preview. A versão completa do Maple vai ter pós-treino mais extenso, melhor performance em tarefas de agente, e provavelmente um context window ainda maior.

Mas o impacto real do Maple-Preview vai além do modelo em si. Ele prova uma tese que muita gente considerava impossível até pouco tempo: que pesos ternários treinados do zero, combinados com MoE massivo, produzem modelos que competem com modelos dense de precisão completa numa fração do custo computacional.

Se a DeepGrove conseguiu isso com 20B de parâmetros, imagine quando alguém aplicar a mesma técnica em modelos de 100B ou 200B. Um modelo ternário de 200B-A10B caberia em talvez 50 GB, rodando em qualquer MacBook Pro com 64 GB de RAM a velocidades absurdas. Modelos de fronteira no laptop, sem cloud.

A pergunta que fica: se inferência local ternária fica boa o suficiente para 80% dos casos de uso, quem vai continuar pagando $15 por milhão de tokens na API?

Eu diria que a resposta assusta um pouco as empresas que vendem inferência por token. Mas, como todo dev sabe, o futuro sempre chega mais rápido do que a gente planeja.

Fonte de inspiração: Maple-Preview no Hacker News e repositório no Hugging Face