Needle - Gemini Tool Calling से distilled 26 मिलियन पैरामीटर मॉडल

• 26 मिलियन पैरामीटर वाला ओपन सोर्स tool use मॉडल, जिसे स्मार्टफोन, स्मार्टवॉच और चश्मे जैसे छोटे consumer devices पर चलने के लिए डिज़ाइन किया गया है
• यह अवलोकन इसकी शुरुआत है कि tool calling inference नहीं बल्कि retrieval और assembly (query → tool name matching → argument extraction → JSON output) है, इसलिए बड़े मॉडल की ज़रूरत नहीं होती
• Simple Attention Network आर्किटेक्चर अपनाया गया है, जिसमें पूरा मॉडल केवल attention और gating से बना है, और MLP बिल्कुल नहीं है
  • Encoder 12 लेयर + Decoder 8 लेयर, cross-attention से जुड़े हुए
  • d=512, 8H/4KV, BPE=8192
• Gemini 3.1 को distill करके बनाया गया, 16 TPU v6e पर 200B tokens का pretraining (27 घंटे), फिर 2B tokens के function calling डेटा पर further training (45 मिनट)
• प्रोडक्शन में Cactus inference engine पर prefill 6,000 tok/s, decode 1,200 tok/s की गति हासिल
• single-call function calling benchmark में FunctionGemma-270M, Qwen-0.6B, Granite-350M, LFM2.5-350M से बेहतर
  • हालांकि conversational environment में उन मॉडलों की generality अधिक व्यापक है
• FFN के बिना भी उन सभी tasks पर generalize किया जा सकता है जहाँ बाहरी structured knowledge तक पहुँचना संभव हो (RAG, tool use आदि)
  • अगर factual information input में दी गई हो, तो उसे FFN weights में याद रखने की ज़रूरत नहीं
• needle playground कमांड से web UI में अपने tools का test और one-click fine-tuning संभव, Mac/PC पर local fine-tuning सपोर्ट
• training dataset को Gemini से synthesize किया गया, जिसमें timer, messaging, navigation, smart home आदि 15 tool categories शामिल हैं
• MIT लाइसेंस, Python आधारित, weights और dataset generation process पूरी तरह Hugging Face पर सार्वजनिक

[wedding]

क्या Korean ठीक से काम करेगा..?

[GN⁺]

Hacker News टिप्पणियाँ

• मैं जानना चाहता हूँ कि tool-use model की विवेक-क्षमता के लिए कोई उदाहरण या डेटा है या नहीं
  उदाहरण के लिए, “सैन फ़्रांसिस्को का मौसम कैसा है” जैसा कुछ, और दिया गया tool लगभग tools='[{"name":"get_weather","parameters":{"location":"string"}}]' है
  10 साल से भी पहले मैंने SPARQL और knowledge graph के साथ इस समस्या को संभालने वाली चीज़[1] बनाई थी
  असली जिज्ञासा यह है कि ambiguity handling यह कितना अच्छी तरह करता है
  अगर आप “कल 10 बजे कॉफ़ी पर मिलते हैं” जैसा टेक्स्ट और “इसे सेव कर दो” जैसा कमांड भेजें, तो क्या यह सैकड़ों नहीं तो कम-से-कम दर्जनों संभव tools में से “कैलेंडर में जोड़ो” वाला action चुन सकता है?
  [1] https://github.com/nlothian/Acuitra/wiki/About

  • मैंने नीचे लिंक किए गए Hugging Face पर इसे टेस्ट किया, लेकिन यह प्रभावशाली नहीं लगा
    प्रॉम्प्ट था “मुझे अपने बॉस को बताना है कि मैं देर से पहुँचूँगा”, और नतीजा था 20mins [{"name":"set_timer","arguments":{"time_human":"20 minutes"}}]
    इसने email tool का इस्तेमाल नहीं किया, और 2-3 अलग तरीकों से पूछने पर भी नतीजा लगभग ऐसा ही था

• मैं सोचता हूँ कि क्या Google की प्रतिक्रिया चिंता की बात नहीं है
  बताया जाता है कि Google distillation प्रयासों के जवाब में “real-time proactive defenses that can degrade student model performance” का इस्तेमाल करता है
  अगर यह पकड़ा गया हो, तो हो सकता है उन्होंने जानबूझकर Gemini का थोड़ा ज़्यादा बेवकूफ़ लेकिन विश्वसनीय दिखने वाला variant खिलाया हो: https://cloud.google.com/blog/topics/threat-intelligence/dis...
  हालाँकि यह model छोटा है और सिर्फ tool use पर केंद्रित है, इसलिए token usage के हिसाब से यह पूरे model को distill करने वालों के आसपास भी नहीं पहुँचता होगा

  • आप Gemma model को लोकल में चलाकर distill कर सकते हैं, और tool use करने वाले दूसरे models भी इस्तेमाल कर सकते हैं
  • training data के नज़रिए से देखें तो यह कुछ-कुछ चोर को लूटने जैसा लगता है

• शायद अब ऐसा command-line program बनाना संभव हो जाए जिसमें arguments को natural language में वैकल्पिक रूप से निर्दिष्ट किया जा सके
  बेशक, “parsing” के लिए 14MB और अतिरिक्त compute जोड़ने पर बहुत से लोग आपत्ति करेंगे, और अगर हर कोई ऐसा करने लगे तो यह काफ़ी खराब भी हो सकता है
  फिर भी, अब यह संभव है — यही बात सचमुच दिलचस्प है
  आप ऐसा model साथ में fine-tune करके शामिल कर सकते हैं जो program usage को समझता हो
  उदाहरण के लिए > toolcli what can you do से toolcli --help summary चलाया जाए, और toolcli add tom to teamfutz group का मतलब toolcli --gadd teamfutz tom हो

  • Needle को INT4 के लिए train किया गया है, और playground में जो दिख रहा है वह भी INT4 है, इसलिए यह सिर्फ 14MB है
    हालाँकि वही task अब भी बाकी है

• अच्छा होगा अगर वे “needle playground” का live demo सार्वजनिक करें
  यह इतना छोटा है कि किसी छोटे VPS पर इसे चलाने की लागत भी काफ़ी सस्ती होगी

  • यह WebGPU पर भी तेज़ी और आसानी से संभव लगता है
  • समस्या सिर्फ scale से निपटने की है, और ready-to-use infra अभी तैयार नहीं है
    फिर भी यह कोई भी कर सकता है, और laptop पर सीधे चलाना भी आसान है
    मैं VPS वाला रास्ता भी आज़माऊँगा
  • मैं इसे chonklm.com पर डालकर देखूँगा

• “search tasks को FFN की ज़रूरत नहीं होती” वाला अवलोकन दिलचस्प है
  अगर knowledge context के भीतर है, तो दावा लगभग यह है कि उस task के लिए FFN weights redundant हैं
  मैं जानना चाहता हूँ कि क्या यह multi-turn tool calling तक generalize होता है, जहाँ कई calls के बीच state ट्रैक करनी पड़ती है, या वहीं जाकर यह टूट जाता है
  single call तो आसान case है

• यह दिलचस्प है, और Claude Code के शुरुआती इस्तेमाल में मैंने जो देखा था उससे मेल भी खाता है
  Sonnet अक्सर ज़्यादा context इकट्ठा करने के लिए जल्दी-जल्दी tools call करता था, जबकि Opus उपलब्ध context के साथ समस्या हल करने के लिए ज़्यादा देर तक reason करता था
  इससे duplicate functions बहुत बनते थे और development धीमा हो जाता था, लेकिन नए models GPT-5.5 और Opus 4.6 में यह समस्या कम लगती है
  मेरा निष्कर्ष यह है कि “ज़्यादा बेवकूफ़”, यानी छोटे models, agent execution shell के रूप में बेहतर हो सकते हैं, या कम-से-कम बहुत-सी समस्याओं में उन्हें सस्ते और तेज़ ढंग से चलाना ज़्यादा व्यावहारिक हो सकता है
  मुझे नहीं लगा कि Gemini लंबे tool-call sequences में खास तौर पर अच्छा है
  अगर Codex या Claude Code sessions जैसी चीज़ों से, जहाँ user queries के बीच लंबे tool-call chains होते हैं, distillation traces मिलें तो वह दिलचस्प होगा
  निजी तौर पर मैं ऐसा थोड़ा बड़ा model देखना चाहूँगा जो 32GB M2 MacBook Pro जैसी मशीन पर आसानी से चल सके और जिसका मुख्य लक्ष्य tool-calling reinforcement learning हो
  Kimi या Qwen जैसे open-weight models काफ़ी करीब पहुँच रहे हैं, लेकिन छोटे devices पर फिट करने के लिए ज़रूरी quantization शायद performance को काफ़ी गिरा देती है

  • कुंजी यह है कि LLM को iterative loop में न चलाया जाए
    आजकल agent frameworks का चलन मूर्खतापूर्ण है, और मेरे हिसाब से वे ज़्यादातर LLM कंपनियों की कमाई बढ़ाने के लिए ही मौजूद हैं
    LLM आम तौर पर सीमित उपयोगिता रखते हैं, लेकिन एक बार के tool use के साथ वे कहीं ज़्यादा उपयोगी और भरोसेमंद बन जाते हैं
    मैं खुद openrouter API के ऊपर बहुत specific task tools के bundles बनाकर इस्तेमाल करता हूँ
    आप बटन दबाते हैं और LLM एक उपयोगी काम करता है; यह मॉडल नहीं कि बटन दबाएँ और LLM 5 मिनट तक loop में tool calls चलाता रहे और उम्मीद करें कि वह सब सही क्रम में कर देगा
    अगर कई tool calls चाहिए हों, तो मैं उन्हें code में deterministically जोड़ता हूँ
    A का output जाँचकर B या C की तरफ़ बढ़ सकते हैं, इसलिए यह कहीं ज़्यादा भरोसेमंद है, और समय व tokens दोनों के लिहाज़ से भी कुशल है
    agent loops मुझे एक बहुत बड़े छलावे जैसे लगते हैं
  • मैं चाहता हूँ कि बड़ी AI कंपनियाँ अपने “tools” की कमियाँ जैसी हैं वैसी ही छोड़ दें, उन्हें भरने में हमारा समय बर्बाद न हो
    समझ नहीं आता कि हमें क्यों किसी तरह इसे “चलाने लायक” बनाने के लिए मेहनत करनी चाहिए
    Google, MS, Meta, OpenAI वगैरह अब अपने tools को धीरे-धीरे “Intelligence” कहने लगे हैं, जबकि वे “Artificial Intelligence” भी नहीं हैं; तो फिर वे बुद्धिमान क्यों नहीं हैं और काम क्यों नहीं करते?
    1 ट्रिलियन डॉलर से ज़्यादा निवेश के बाद भी हमें अब तक यह सोचते रहना पड़ रहा है कि कौन-से जादुई prompts और settings दें ताकि ये घटिया output generators आधे-अधूरे तौर पर वैध output दे सकें
    और यह सब तब, जब कुछ tech leaders अपनी अजीब “civilization” वाली कल्पनाओं के भीतर हमें अधीन करने की खुली धमकी भी देते हैं
    हमारे बेहतर दिमाग का इस्तेमाल कहीं और होना चाहिए; हमें खुद को किसी जादुई oracle के लाचार सहायक के रूप में नीचे नहीं गिराना चाहिए

• Cactus experiments का यह नतीजा दिलचस्प है कि “जब तक model बाहरी knowledge source पर निर्भर करता है, transformer network से MLP को पूरी तरह हटाया जा सकता है”
  संयोग से, आज ही मेरे एक छात्र ने भी इसकी पुष्टि करने वाला research result प्रस्तुत किया
  Qwen से MLP हटाने पर model अब भी input पर transformation tasks कर पा रहा था, लेकिन उसका knowledge गायब हो गया

• M और B का फ़र्क बहुत सूक्ष्म है
  मैं इसे 0.026B लिखने का सुझाव दूँगा

  • “M” notation कम-से-कम BERT और T5/FLAN के ज़माने से मौजूद है
    भले ही आजकल LLM developers अरबों पैरामीटर वाले models के ज़्यादा अभ्यस्त हों, यह notation अब भी वैध है
  • इस पोस्ट के बहुत-से comments इतने उलझाऊ लगे, लेकिन अब आपकी वजह से समझ आया कि कुछ लोगों ने इसे 26B पढ़ लिया था, इसलिए उनके comments का कोई मतलब नहीं बन रहा था

• उत्साहित हूँ, काम शानदार है
  Gemma4 edge models से agent use में अच्छा प्रदर्शन करने का वादा किया गया था, लेकिन मैंने जो भी tests किए उनमें वे सचमुच निराशाजनक रहे
  वे सबसे बुनियादी tool-use scenarios में भी fail हो जाते हैं
  मैं जानना चाहता हूँ कि क्या आपने Needle पर tool-use benchmarks चलाए हैं, या ऐसा करने की योजना है
  अगर हैं, तो अच्छा होगा कि results repository में जोड़ दिए जाएँ

• मैंने अभी alarm set करना और shopping list में चीज़ें जोड़ना आज़माया, और इसने Siri से बेहतर किया