Needle - modelo de 26 millones de parámetros destilado para llamadas de herramientas de Gemini

• Needle es un modelo experimental destilado de Gemini 3.1 en una Simple Attention Network de 26 millones de parámetros, y permite incluso fine-tuning local en Mac/PC
• El objetivo es redefinir la IA pequeña que se usa en dispositivos de consumo como teléfonos, relojes y lentes, con foco en llamadas de herramientas de ejecución única para IA personal
• En producción corre sobre Cactus y alcanza prefill 6000 toks/sec y velocidad de decode de 1200
• Los pesos están completamente abiertos en Cactus-Compute/needle, y también se publica la generación del dataset
• El preentrenamiento se realizó durante 27 horas con 16 TPU v6e sobre 200B tokens, y el entrenamiento posterior duró 45 minutos con un dataset de 2B tokens de llamadas de funciones de ejecución única
• En llamadas de funciones de ejecución única, se presenta como superior a FunctionGemma-270m, Qwen-0.6B, Graninte-350m y LFM2.5-350m, aunque esos modelos tienen un alcance y capacidad más amplios y destacan en configuraciones conversacionales
• Como los modelos pequeños pueden ser difíciles de manejar, se recomienda el flujo del web UI incluido para probar con tus propias herramientas y hacer fine-tuning personalizado con clics
• needle playground abre el web UI en http://127.0.0.1:7860, y los pesos se descargan automáticamente para usarlos en pruebas y fine-tuning
• Al usar Python, con SimpleAttentionNetwork, load_checkpoint, generate y get_tokenizer se pueden pasar consultas y esquemas de herramientas para generar JSON de llamada de herramienta como get_weather
• El CLI ofrece playground, finetune, run, train, pretrain, eval, tokenize, generate-data y tpu para cubrir inferencia, entrenamiento, evaluación, generación de datos y administración de TPU
• La configuración del modelo es d=512, 8H/4KV, BPE=8192, y usa 12 capas de encoder y 8 de decoder, GQA+RoPE, cross attention, gated residual, tied linear y shared embedding

[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