Needle - modelo de 26 millones de parámetros destilado para Tool Calling de Gemini

• Modelo open source de 26 millones de parámetros para uso de herramientas (tool use), diseñado para ejecutarse en dispositivos de consumo pequeños como smartphones, smartwatches y gafas
• Parte de la observación de que la llamada de herramientas no es razonamiento, sino búsqueda y ensamblaje (consulta → coincidencia con nombre de herramienta → extracción de argumentos → salida JSON), por lo que no se necesita un modelo grande
• Adopta la arquitectura Simple Attention Network, por lo que todo el modelo está compuesto solo de attention y gating, sin MLP en absoluto
  • Encoder de 12 capas + Decoder de 8 capas, conectados mediante cross-attention
  • d=512, 8H/4KV, BPE=8192
• Generado mediante destilación (distill) de Gemini 3.1, con preentrenamiento de 200B tokens en 16 TPU v6e (27 horas) y entrenamiento posterior con 2B tokens de datos de llamadas a funciones (45 minutos)
• En producción alcanza velocidades de prefill 6,000 tok/s, decode 1,200 tok/s sobre el motor de inferencia Cactus
• Supera a FunctionGemma-270M, Qwen-0.6B, Granite-350M, LFM2.5-350M en benchmarks de llamadas a funciones de una sola invocación
  • Aun así, en entornos conversacionales esos modelos tienen una versatilidad general más amplia
• Puede generalizarse a cualquier tarea con acceso a conocimiento estructurado externo (RAG, uso de herramientas, etc.) incluso sin FFN
  • Si la información factual se proporciona en la entrada, no hace falta memorizarla en los pesos FFN
• Con el comando needle playground es posible probar herramientas propias en una UI web y hacer fine-tuning con un clic; también admite fine-tuning local en Mac/PC
• El dataset de entrenamiento fue sintetizado con Gemini e incluye 15 categorías de herramientas como temporizador, mensajería, navegación y hogar inteligente
• Licencia MIT, basado en Python, con pesos y proceso de generación del dataset completamente publicados en Hugging Face

[wedding]

¿Funcionará bien en coreano..?

[GN⁺]

Comentarios de Hacker News

• Me pregunto si hay ejemplos o datos sobre el poder de discernimiento de los modelos de uso de herramientas
  Un ejemplo sería algo como “cómo está el clima en San Francisco”, y la herramienta que se pasa sería algo como tools='[{"name":"get_weather","parameters":{"location":"string"}}]'
  Hace más de 10 años construí algo[1] que podía manejar este problema con SPARQL y grafos de conocimiento
  Lo que de verdad me da curiosidad es qué tan bien maneja la ambigüedad
  Si le mandas un mensaje como “nos vemos mañana a las 10 para tomar café” y una orden como “guarda esto”, me pregunto si puede elegir la acción de “agregar al calendario” entre decenas de herramientas posibles, aunque no sean cientos
  [1] https://github.com/nlothian/Acuitra/wiki/About

  • Lo probé en el Hugging Face enlazado abajo y no me impresionó
    El prompt fue “tengo que avisarle a mi jefe que voy tarde”, y el resultado fue 20mins [{"name":"set_timer","arguments":{"time_human":"20 minutes"}}]
    No usó la herramienta de correo, y preguntando de 2 o 3 formas distintas fue parecido

• Me pregunto si no les preocupa la respuesta de Google
  Se sabe que Google responde a intentos de destilación con “defensas proactivas en tiempo real que pueden degradar el rendimiento del modelo estudiante”
  Si lo detectaron, también podrían haberle dado adrede una variante de Gemini más tonta pero verosímil: https://cloud.google.com/blog/topics/threat-intelligence/dis...
  Aun así, como este modelo es pequeño y está enfocado solo en uso de herramientas, probablemente ni se acerca en consumo de tokens a quienes intentan destilar un modelo completo

  • También se podría destilar ejecutando modelos Gemma en local, y lo mismo con otros modelos capaces de usar herramientas
  • Desde la perspectiva de los datos de entrenamiento, también se siente como robarle al ladrón

• Tal vez esto haga posible crear algo como un programa de línea de comandos donde puedas especificar argumentos de manera flexible en lenguaje natural
  Claro, mucha gente se va a oponer a meter 14 MB y cómputo extra solo para “parsear”, y si todos empiezan a hacerlo podría salir bastante mal
  Aun así, es realmente interesante que ahora sea posible
  Se podría incluir junto con un modelo ajustado para entender cómo usar el programa
  Por ejemplo, > toolcli what can you do ejecutaría toolcli --help summary, y toolcli add tom to teamfutz group se convertiría en toolcli --gadd teamfutz tom

  • Needle fue entrenado para INT4, y lo que se ve en el playground también es INT4, así que solo ocupa 14 MB
    Aun así, la misma tarea sigue ahí

• Estaría bueno publicar un demo en vivo del “needle playground”
  Como es tan pequeño, el costo de correrlo en algún VPS chico parece que sería bastante bajo

  • Con WebGPU también parece que sería rápido y fácil
  • El único problema es escalarlo, y todavía no hay una infraestructura lista para usar
    Aun así, cualquiera puede hacerlo y también es fácil correrlo directo en una laptop
    Voy a probar también la ruta del VPS
  • Voy a subir esto a chonklm.com

• La observación de que “las tareas de recuperación no necesitan FFN” es interesante
  Si el conocimiento está en el contexto, casi equivale a decir que para esa tarea los pesos FFN son redundantes
  Me pregunto si eso también se generaliza a llamadas de herramientas multi-turno donde hay que seguir el estado a lo largo de varias llamadas, o si ahí es donde se rompe
  Una sola llamada es el caso fácil

• Interesante, y también encaja con una observación que vi al principio usando Claude Code
  Sonnet a menudo llamaba herramientas rápido para reunir más contexto, mientras que Opus tendía a razonar más tiempo con el contexto que ya tenía para resolver el problema
  Esto generaba muchas funciones redundantes y hacía más lento el desarrollo, pero parece que en los modelos nuevos, GPT-5.5 y Opus 4.6, este problema ha disminuido
  Mi conclusión es que un modelo “más tonto”, o sea más pequeño, podría ser mejor como capa de ejecución de agentes, o al menos ser más realista de correr de forma barata y rápida en muchos problemas
  No sentí que Gemini fuera especialmente bueno en tramos largos de llamadas de herramientas
  Sería interesante destilar rastros como sesiones reales de Codex o Claude Code, donde hay cadenas largas de llamadas de herramientas entre consultas del usuario
  Personalmente, me gustaría ver un modelo un poco más grande que se pueda correr fácilmente en una máquina como una MacBook Pro M2 de 32 GB y que tenga como objetivo principal el aprendizaje por refuerzo para llamadas de herramientas
  Modelos de pesos abiertos como Kimi o Qwen se están acercando, pero la cuantización necesaria para que quepan en dispositivos pequeños parece bajar bastante el rendimiento

  • La clave es no ejecutar el LLM en un bucle iterativo
    La moda actual de los frameworks de agentes me parece tonta, y creo que en su mayoría existe para aumentar los ingresos de las empresas de LLM
    Los LLM por sí solos suelen tener una utilidad limitada, pero combinados con un único uso de herramientas se vuelven mucho más útiles y confiables
    Yo mismo uso un conjunto de herramientas muy específico para ciertas tareas sobre la API de openrouter
    Aprietas un botón y el LLM hace una cosa útil, no aprietas un botón para esperar que el LLM se quede 5 minutos en un bucle de llamadas de herramientas procesándolas en el orden correcto
    Si se necesitan varias llamadas de herramientas, las encadeno de forma determinista en código
    Así puedo revisar la salida de A antes de pasar a B o C, lo que es mucho más confiable, y además más eficiente en tiempo y tokens
    Los bucles de agentes me parecen casi una gran estafa
  • Ojalá las grandes empresas de IA no se hubieran pasado el tiempo tapando los huecos de sus propias “herramientas”
    No entiendo por qué nosotros tenemos que esforzarnos para que de alguna manera “funcionen”
    Google, MS, Meta, OpenAI y demás ahora intentan llamar discretamente “Intelligence” a sus herramientas, y ni siquiera “Artificial Intelligence”, así que entonces ¿por qué no son inteligentes y por qué no funcionan?
    ¿Cómo puede ser que, con más de un billón de dólares invertidos, sigamos teniendo que pensar en los mejores conjuros y configuraciones para lograr que un generador de basura produzca una salida medio válida?
    Y eso mientras algunos líderes tecnológicos amenazan abiertamente con doblegarnos dentro de sus extrañas visiones de “civilización”
    Hay mejores usos para nuestro cerebro; no deberíamos rebajarnos a ser asistentes indefensos de un oráculo mágico

• Es interesante el resultado del experimento de Cactus: “mientras el modelo dependa de una fuente de conocimiento externa, se puede eliminar por completo el MLP de la red transformer”
  Justo hoy uno de mis estudiantes presentó resultados de investigación que también lo confirmaban
  Al eliminar el MLP en Qwen, el modelo todavía podía hacer tareas de transformación sobre la entrada, pero perdió el conocimiento

• La diferencia entre M y B es demasiado sutil
  Sugiero escribir 0.026B

  • La notación “M” existe al menos desde los tiempos de BERT y T5/FLAN
    Aunque los desarrolladores de LLM actuales estén más acostumbrados a modelos de miles de millones de parámetros, la notación sigue siendo válida
  • Muchos comentarios en este post me confundían demasiado, pero gracias a esto me di cuenta de que algunos lo estaban leyendo como 26B, y por eso los comentarios no tenían sentido

• Suena prometedor, gran trabajo
  Se suponía que los modelos edge de Gemma4 iban a ser buenos para uso con agentes, pero en todas las pruebas que hice fueron realmente decepcionantes
  Fallan incluso en los escenarios más básicos de uso de herramientas
  Me pregunto si ya corrieron benchmarks de uso de herramientas para Needle, o si tienen pensado hacerlo
  Si sí, estaría bueno agregar los resultados al repositorio

• Acabo de probar poner una alarma y agregar algo a la lista del súper, y lo hizo mejor que Siri