Needle - modelo de 26 milhões de parâmetros destilado para chamadas de ferramentas do Gemini

• Needle é um modelo experimental destilado do Gemini 3.1 em uma Simple Attention Network de 26 milhões de parâmetros, com possibilidade até de fine-tuning local em Mac/PC
• O objetivo é redefinir pequenas IAs usadas em dispositivos de consumo como celulares, relógios e óculos, com foco em chamadas de ferramentas de execução única para IA pessoal
• Em produção, roda sobre o Cactus e alcança prefill de 6000 toks/sec e decode de 1200
• Os pesos estão totalmente abertos em Cactus-Compute/needle, e a geração do dataset também foi publicada
• O pré-treinamento foi executado em 16 TPU v6e com 200B tokens por 27 horas, e o treinamento posterior foi feito por 45 minutos com um dataset de 2B tokens de chamadas de função de execução única
• Em chamadas de função de execução única, é apresentado como superior a FunctionGemma-270m, Qwen-0.6B, Graninte-350m e LFM2.5-350m, mas esses modelos têm escopo e capacidade mais amplos e se destacam em configurações conversacionais
• Como modelos pequenos podem ser difíceis de lidar, recomenda-se o fluxo da web UI fornecida para testar com suas próprias ferramentas e fazer fine-tuning personalizado com um clique
• needle playground abre a web UI em http://127.0.0.1:7860, e os pesos podem ser baixados automaticamente para teste e fine-tuning
• Ao usar Python, é possível fornecer consulta e esquema de ferramenta com SimpleAttentionNetwork, load_checkpoint, generate e get_tokenizer para gerar um JSON de chamada de ferramenta como get_weather
• A CLI oferece playground, finetune, run, train, pretrain, eval, tokenize, generate-data e tpu, cobrindo inferência, treinamento, avaliação, geração de dados e gerenciamento de TPU
• A configuração do modelo é d=512, 8H/4KV, BPE=8192, e usa encoder de 12 camadas e decoder de 8 camadas, além de GQA+RoPE, cross attention, gated residual, tied linear e shared embedding

[GN⁺]

Comentários do Hacker News

• Fico curioso se há exemplos ou dados sobre o poder de discernimento de um modelo de uso de ferramentas
  Um exemplo seria algo como “como está o clima em San Francisco”, e a ferramenta passada seria algo como tools='[{"name":"get_weather","parameters":{"location":"string"}}]'
  Há mais de 10 anos eu cheguei a criar algo[1] que conseguia lidar com esse tipo de problema com SPARQL e grafos de conhecimento
  O que realmente me deixa curioso é o quão bem ele lida com ambiguidade
  Se você mandar uma mensagem como “vamos nos ver amanhã às 10 para tomar um café” e um comando como “salva isso”, será que ele consegue escolher a ação de “adicionar ao calendário” entre dezenas de ferramentas possíveis, ainda que não sejam centenas?
  [1] https://github.com/nlothian/Acuitra/wiki/About

  • Testei no Hugging Face linkado abaixo e não achei impressionante
    O prompt foi “preciso avisar meu chefe que vou me atrasar”, e o resultado foi 20mins [{"name":"set_timer","arguments":{"time_human":"20 minutes"}}]
    Ele não usou a ferramenta de e-mail, e eu perguntei de outras 2 ou 3 formas, mas foi parecido

• Fico me perguntando se isso não preocupa o Google
  Foi divulgado que o Google reage a tentativas de destilação com “defesas proativas em tempo real que podem degradar o desempenho do modelo aluno”
  Se isso foi detectado, talvez tenham alimentado de propósito uma variante do Gemini mais burra, mas plausível: https://cloud.google.com/blog/topics/threat-intelligence/dis...
  Dito isso, como esse modelo é pequeno e focado só em uso de ferramentas, em consumo de tokens ele provavelmente nem chega perto de quem está tentando destilar um modelo completo

  • Também daria para destilar rodando um modelo Gemma localmente, e o mesmo vale para outros modelos com capacidade de usar ferramentas
  • Do ponto de vista dos dados de treinamento, isso até parece meio que roubar de ladrão

• Talvez isso torne possível criar algo como um programa de linha de comando em que dá para especificar argumentos de forma opcional em linguagem natural
  Claro, muita gente vai ser contra incluir 14 MB e computação extra só para fazer “parsing”, e se todo mundo começar a fazer isso pode ficar bem ruim
  Ainda assim, é muito interessante que agora isso seja possível
  Você poderia embutir junto um modelo ajustado para entender como usar o programa
  Por exemplo, > toolcli what can you do executaria toolcli --help summary, e toolcli add tom to teamfutz group viraria toolcli --gadd teamfutz tom

  • O Needle foi treinado para INT4, e o que aparece no playground também é INT4, então ele tem só 14 MB
    Mesmo assim, a mesma tarefa continua aí

• Seria legal publicar uma demo ao vivo do “needle playground”
  Como ele é pequeno, imagino que o custo para rodar isso em algum VPS pequeno também seria bem barato

  • Com WebGPU também parece que daria para fazer de forma rápida e fácil
  • O problema é só escalar, e a infraestrutura pronta para isso ainda não está preparada
    Mesmo assim, qualquer um consegue fazer, e também é fácil rodar direto no notebook
    Vou tentar a rota do VPS também
  • Vou colocar isso no chonklm.com

• Acho interessante a observação de que “tarefas de recuperação não precisam de FFN”
  Se o conhecimento está no contexto, isso é quase afirmar que os pesos de FFN são redundantes para essa tarefa
  Fico curioso se isso também se generaliza para chamadas de ferramenta multi-turno, em que é preciso acompanhar estado ao longo de várias chamadas, ou se quebra aí
  Chamada única é o caso fácil

• Interessante, e bate com uma observação que eu tive no começo usando Claude Code
  O Sonnet muitas vezes chamava ferramentas rapidamente para reunir mais contexto, enquanto o Opus tendia a raciocinar por mais tempo com o contexto que já tinha para tentar resolver o problema
  Isso acabava gerando muita função redundante e deixando o desenvolvimento mais lento, mas nos modelos mais novos, GPT-5.5 e Opus 4.6, esse problema parece ter diminuído
  Minha conclusão é que um modelo “mais burro”, isto é, menor, talvez seja melhor como casca de execução de agente, ou pelo menos pode ser mais realista rodá-lo de forma mais barata e rápida em muitos problemas
  Não senti que o Gemini fosse particularmente bom em longos trechos de chamadas de ferramenta
  Seria interessante destilar rastros como os de sessões reais do Codex ou do Claude Code, em que há longas cadeias de chamadas de ferramenta entre as consultas do usuário
  Pessoalmente, eu gostaria de um modelo um pouco maior que rodasse com facilidade em algo como um MacBook Pro M2 de 32 GB, com aprendizado por reforço para chamadas de ferramenta como objetivo principal
  Modelos de pesos abertos como Kimi ou Qwen estão chegando perto, mas a quantização necessária para caber em dispositivos pequenos parece derrubar bastante o desempenho

  • O ponto principal é não rodar o LLM em um loop iterativo
    A moda atual de frameworks de agentes é idiota, e acho que em grande parte existe para aumentar a receita das empresas de LLM
    Em geral, LLMs têm utilidade limitada, mas quando combinados com um único uso de ferramenta ficam muito mais úteis e confiáveis
    Eu mesmo crio conjuntos de ferramentas bem específicos para tarefas em cima da API do openrouter
    Você aperta um botão e o LLM faz uma coisa útil, não aperta um botão e fica 5 minutos num loop de chamadas de ferramenta torcendo para processar tudo na ordem certa
    Se forem necessárias várias chamadas de ferramenta, eu encadeio isso de forma determinística no código
    Dá para verificar a saída de A antes de seguir para B ou C, então fica muito mais confiável, além de ser mais eficiente em tempo e tokens
    Acho que loop de agente é quase uma grande fraude
  • Eu queria que as grandes empresas de IA não gastassem tempo tapando os buracos das próprias “ferramentas”
    Não sei por que nós é que temos de nos esforçar para “fazer funcionar” de algum jeito
    Google, MS, Meta, OpenAI e afins agora querem chamar discretamente suas ferramentas de “Intelligence”, e nem é “Artificial Intelligence”, então por que não é inteligente e por que não funciona?
    Entrou mais de 1 trilhão de dólares nisso, e ainda assim continuamos pensando nas melhores magias e configurações para fazer um gerador de porcaria produzir uma saída mais ou menos válida
    Enquanto isso, alguns líderes de tecnologia chegam a nos ameaçar abertamente com a ideia de nos subjugar dentro de sua estranha visão de “civilização”
    Acho que temos usos melhores para nossos cérebros do que nos rebaixar a assistentes impotentes de um oráculo mágico

• Achei divertido o resultado do experimento Cactus de que “enquanto o modelo depender de fontes externas de conhecimento, dá para remover completamente os MLPs da rede transformer”
  Por coincidência, um dos meus alunos apresentou hoje mesmo um resultado de pesquisa confirmando isso
  Removendo os MLPs do Qwen, o modelo ainda conseguia fazer tarefas de transformação sobre a entrada, mas perdia o conhecimento

• A diferença entre M e B é sutil demais
  Sugiro escrever como 0.026B

  • A notação com “M” existe pelo menos desde a época do BERT e do T5/FLAN
    Mesmo que os desenvolvedores de LLM hoje estejam mais acostumados com modelos na casa dos bilhões, essa notação continua válida
  • Muitos comentários neste post estavam confusos demais, e graças a isso percebi que parte das pessoas estava lendo como 26B, o que explicava por que os comentários não faziam sentido

• Animado com isso, excelente trabalho
  Os modelos edge do Gemma4 prometeram ser bons para uso com agentes, mas em todos os testes que fiz foram realmente decepcionantes
  Eles falham até nos cenários mais básicos de uso de ferramentas
  Queria saber se vocês já rodaram algum benchmark de uso de ferramentas no Needle, ou se pretendem rodar
  Se tiverem, seria legal adicionar os resultados ao repositório

• Acabei de testar definir um alarme e adicionar algo à lista de compras, e foi melhor que a Siri