मेटा ने Muse Glimmer जारी किया है, जो एक लगभग 30B पैरामीटर वाला बहु-मोडल एजेंट मॉडल है जो 128K स्तर के संदर्भ का समर्थन करता है और 24GB VRAM वाले उपकरणों पर चल सकता है। यह मॉडल Apache 2.0 लाइसेंस के तहत खुला है, GQA का उपयोग करके KV Cache का उपयोग कम करता है, लंबे संदर्भ की गणना लागत को कम करने के लिए स्थानीय और वैश्विक ध्यान के मिश्रित आर्किटेक्चर को एकीकृत करता है, और विभिन्न VRAM उपकरणों के अनुकूल दो क्वांटाइज्ड संस्करण प्रदान करता है। दृश्य मॉड्यूल में स्क्रीनशॉट और स्क्रीन जानकारी को संभालने के लिए एक स्वतंत्र ViT Perception Encoder शामिल है, और प्रशिक्षण चरण में लंबे कार्यों की अवस्था से विचलन को कवर करने के लिए On Policy Distillation का प्रयोग किया गया है। DFlash निष्पादन त्वरण घटक Block Diffusion का उपयोग करके Token का समानांतर पूर्वानुमान लगाता है, जिससे RTX 5090 पर डिकोडिंग गति में लगभग 3 गुना की वृद्धि होती है। मॉडल MCP Atlas, DeepSearch QA आदि Agent Benchmark में उत्कृष्ट प्रदर्शन करता है, लेकिन OSWorld Verified जैसे शुद्ध GUI परिदृश्यों में अभी भी सुधार की आवश्यकता है।

लेखक, स्रोत: लेफेंगवेन

कल, मेटा ने Muse Glimmer जारी किया। यह एक लगभग 30B पैरामीटर वाला बहुआधारित एजेंट मॉडल है, जो 128K स्तर के संदर्भ का समर्थन करता है, टूल्स को कॉल कर सकता है, कोड निष्पादित कर सकता है, और छवियों और स्क्रीन जानकारी को भी संभाल सकता है।

यह मॉडल Apache 2.0 लाइसेंस के तहत खुला है, साथ ही दो 4bit क्वांटाइज्ड संस्करण, स्वतंत्र विजुअल एन्कोडर और DFlash इन्फरेंस त्वरण घटक भी उपलब्ध हैं, और llama.cpp, MLX, ExecuTorch आदि स्थानीय डिप्लॉयमेंट विकल्प प्रदान किए जाते हैं।

हालांकि 30B पैरामीटर स्केल और 128K कॉन्टेक्स्ट आज के लिए कम नहीं हैं, लेकिन समस्या यह है कि Meta इसे सामान्य चैट के बजाय एक पूर्ण स्थानीय Agent रनिंग पैराडाइम बनाने के लिए चाहता है।

Muse Glimmer के लिए लंबे समय तक चलने वाले स्थानीय Agent को कठोर इंजीनियरिंग सीमाओं का सामना करना पड़ता है: इसे सीमित 24GB वीडियो मेमोरी में, लगातार उत्पन्न हो रहे स्क्रीनशॉट्स को संभालते हुए, दर्जनों कदमों तक के कार्य तर्क को बनाए रखना होता है। एक कार्य के दर्जनों कदमों के बाद, पिछले टूल परिणाम, कोड लॉग, पेज स्थिति और निष्कर्षण प्रक्रिया लगातार संदर्भ में रहती रहती हैं।

इस समय, चैट स्थितियों में अस्पष्ट बहुत से प्रश्न तेजी से बढ़ जाते हैं। 128K कॉन्टेक्स्ट को सीमित वीडियो मेमोरी में कैसे फिट किया जाए, स्क्रीनशॉट बढ़ने के बाद हिस्ट्री स्टेट को कैसे प्रबंधित किया जाए, टूल कॉल विफल होने के बाद मॉडल कैसे आगे बढ़े, और बहुत सारे Reasoning Token Decode को कितना धीमा कर देते हैं।

म्यूज़ ग्लिमर का तकनीकी डिज़ाइन इन सवालों के चारों ओर केंद्रित है। इसने सभी मुद्दों को एक विशेष रूप से दिखाई देने वाले नए आर्किटेक्चर पर निर्भर नहीं किया, बल्कि अटेंशन, KV कैश, प्रशिक्षण विधि, क्वांटाइज़ेशन और डिकोड पर जोरदार समझौते किए हैं।

अगर पिछले स्थानीय मॉडल "चलाने योग्य" थे, तो Muse Glimmer का लक्ष्य "बादलों की तरह उपयोग करने में आसान और निरंतर कार्य करना" है।

इन भागों को एक साथ देखने से, Meta ने इसे इस तरह क्यों बनाया है, इसे समझना 30B या 128K को अलग-अलग देखने से आसान होता है।

128K कॉन्टेक्स्ट को 24GB वीडियो मेमोरी में कैसे फिट करें

Muse Glimmer 52 परतों के Dense Transformer, 6656 के Hidden Size, 32 Query Head और केवल 2 KV Head का उपयोग करता है।

ध्यान दें, हर स्तर पर पूर्ण संदर्भ को नहीं लिया जाता, बल्कि तीन स्थानीय ध्यान और एक वैश्विक ध्यान का चक्रीय तरीका अपनाया जाता है।

Local Attention केवल निकटस्थ 2048 टोकन को संभालता है, जबकि Global Attention दूरस्थ सूचना आदान-प्रदान के लिए जिम्मेदार होता है।

ये दोनों डिज़ाइन वास्तव में लंबे संदर्भ की लागत को एक साथ बढ़ा रहे हैं। मॉडल नए टोकन को जनरेट करते समय, पिछले टोकन के Key और Value को कैश करता है, जिसे KV Cache कहते हैं। संदर्भ जितना लंबा होगा, इस भाग का स्थान उतना ही अधिक लेगा।

Muse Glimmer की प्रत्येक परत में केवल 2 KV हेड होते हैं, और प्रत्येक हेड आकार 128 होता है। BF16 के अनुसार लगभग गणना करने पर, एक टोकन का एक परत में KV लगभग 1024 बाइट घेरता है।

यदि 52 स्तरों को पूर्ण 128K Context के साथ सहेजा जाए, तो KV Cache लगभग 6.5 GiB की आवश्यकता होगी। लेकिन Muse Glimmer में वास्तव में 39 स्थानीय स्तर और 13 वैश्विक स्तर हैं। स्थानीय स्तरों को केवल लगभग 2048 टोकन की स्लाइडिंग विंडो को बनाए रखने की आवश्यकता है, केवल वैश्विक स्तरों को ही पूर्ण लंबे संदर्भ को सहेजने की आवश्यकता है।

उसी तरह के अनुमान के अनुसार, KV कैश लगभग 1.7 गिबीबाइट के स्तर तक घट सकता है। यह आधिकारिक रूप से घोषित रनटाइम वीएमएम नहीं है, बल्कि केवल जनता के लिए उपलब्ध आर्किटेक्चर पैरामीटर के आधार पर किया गया सैद्धांतिक अनुमान है, लेकिन यह पहले से ही बता रहा है कि इस संरचना को ऐसे क्यों डिज़ाइन किया गया है।

अगर यह 2 KV हेड के बजाय पारंपरिक MHA की तरह 32 हेड के लिए अलग-अलग KV सहेजता है, तो उसी स्थिति में, KV कैश सिद्धांत रूप से लगभग 16 गुना बढ़ जाएगा और सीधे 20+ गीबी तक पहुँच जाएगा।

अकेले KV Cache का आकार 24GB के एक ग्राफिक्स कार्ड से अधिक है। यहाँ वास्तव में दो तरीके इस्तेमाल किए जाते हैं। GQA प्रत्येक Token के लिए कितने KV सहेजने की आवश्यकता है, यह कम करता है, जबकि Local Attention पूरे KV को लंबे समय तक सहेजने की आवश्यकता वाली परतों की संख्या कम करता है।

इस चरण के बाद ही वजन की मात्राकरण का अर्थ होता है। Muse Glimmer का K Quant 17GB वजन लगभग 16.8GB है, विजुअल मॉड्यूल लगभग 1.4GB है, DFlash लगभग 1.6GB है, और इन सभी भागों का योग लगभग 20GB हो जाता है। यह संस्करण 24GB VRAM वाले डिवाइस के लिए है, जबकि लगभग 20GB का Dynamic K Quant 32GB डिवाइस के लिए है।

दोनों क्वांटाइजेशन न केवल फाइल साइज में अलग हैं। मेटा द्वारा दिए गए 15 बेंचमार्क की औसत एक्यूरेसी लॉस में, डायनेमिक K क्वांट करीब 0.2% है, जबकि K क्वांट 17GB करीब 1.0% है।

इसका मतलब है कि 24GB संस्करण वीडियो मेमोरी को और घटाकर कम स्थान लेता है, लेकिन थोड़े अधिक स्पष्ट क्षमता ह्रास को स्वीकार करना पड़ता है। 32GB संस्करण मूल मॉडल के प्रदर्शन को अधिकतम रखने का प्रयास करता है।

Muse Glimmer का 128K Context इसी संयोजन में संभव है। Attention पहले गणना लागत को कम करता है, GQA फिर KV Cache को कम करता है, और अंत में मॉडल वजन को क्वांटाइज़ करके घटाया जाता है।

इस योजना की भी कीमत है। 39 Local परतें केवल निकटस्थ 2048 टोकन तक सीधे पहुँच सकती हैं, दूरस्थ जानकारी को Global परत के माध्यम से प्रसारित करना पड़ता है। इसलिए, 128K इनपुट करने में सक्षम होना और पूरे 128K का स्थिर रूप से उपयोग करना अलग-अलग बातें हैं।

Meta के Beam128K परिणाम दर्शाते हैं कि यह स्थानीय और वैश्विक मिश्रित संरचना अभी भी लंबी दूरी की जानकारी का प्रभावी उपयोग करने में सक्षम है, लेकिन यह लंबे संदर्भ को हल करती है, लंबे समय की स्मृति नहीं। कौन सी जानकारी संग्रहित की जानी चाहिए, कौन सी अप्रासंगिक हो चुकी है, और कब स्थिति को अपडेट किया जाए, यह अभी भी Agent Runtime द्वारा संभाला जाना चाहिए।

यह समस्या विजुअल एजेंट पर अधिक स्पष्ट हो जाएगी।

128K भी असीमित स्थान नहीं है

Muse Glimmer के साथ एक लगभग 1.8B पैरामीटर वाला ViT G 14 Perception Encoder भी शामिल है, जो स्क्रीनशॉट, वेबपेज, ग्राफ़ और दस्तावेज़ को संसाधित करने के लिए उपयोग किया जाता है। एक छवि को अधिकतम 4096 Visual Token में बदला जा सकता है।

यह वर्तमान में टेक्स्ट और इमेज इनपुट, टेक्स्ट आउटपुट है, और सभी मोडलिटीज को एक ही जनरेटिव मॉडल में नहीं डाला गया है।

एजेंट वर्कफ्लो में रखा जाने पर, यह दृश्य क्षमता मुख्य रूप से वातावरण की स्थिति पढ़ने के लिए जिम्मेदार होती है। कंप्यूटर उपयोग एजेंट पहले वर्तमान स्क्रीन को देखता है, पेज, बटन और पाठ की स्थिति का निर्णय लेता है, और फिर एक कार्रवाई करता है। पेज में परिवर्तन के बाद, यह नए स्क्रीनशॉट को पढ़ता है और अगला कदम तय करता रहता है।

इसलिए दृश्य इनपुट लगातार संदर्भ में प्रवेश करता रहता है। यदि दर्ज़नों कदमों की सभी स्क्रीनशॉट्स को पूरी तरह से बरकरार रखा जाता है, तो भले ही 128K हो, संदर्भ जल्द ही दृश्य टोकन से भर जाएगा। पुरानी स्क्रीनशॉट्स वर्तमान स्थिति के साथ टकरा सकती हैं। पेज पहले ही बदल चुका है, लेकिन पिछले बटन और विंडो संदर्भ में अभी भी मौजूद हैं, और मॉडल को अतिरिक्त रूप से निर्णय लेना पड़ता है कि कौन सी स्थिति सबसे हालिया है।

Meta ने OSWorld Verified के समीक्षा में भी स्क्रीनशॉट इतिहास को असीमित रूप से नहीं बरकरार रखा है, बल्कि केवल हाल के कुछ स्क्रीनशॉट्स को ही बनाए रखा है। इससे स्पष्ट होता है कि Perception Encoder और Context Management दो अलग-अलग समस्याएँ हैं।

पहला वर्तमान स्क्रीन को मॉडल के लिए समझने योग्य जानकारी में बदलता है, जबकि दूसरा यह निर्णय लेता है कि कौन से इतिहास की स्थितियाँ मूल्यवान हैं और कौन सी हटाई जानी चाहिए। इसलिए 128K एजेंट को अधिक कार्य स्थान प्रदान करता है, न कि स्थिति प्रबंधन को रद्द करता है।

और जब एजेंट लगातार वातावरण के साथ बातचीत करता रहता है, तो प्रश्न अब मॉडल ने क्या देखा, इससे बदलकर मॉडल ने अभी क्या किया, इस ओर जा रहे हैं।

अब म्यूज ग्लिमर के ट्रेनिंग भाग में प्रवेश करें।

एजेंट भटक जाने के बाद कैसे आगे बढ़ें

Muse Glimmer को बड़े Muse Spark से डिस्टिल किया गया है।

मेटा ने प्रशिक्षण को प्री ट्रेनिंग, मिड ट्रेनिंग और पोस्ट ट्रेनिंग में विभाजित किया है। प्री ट्रेनिंग में लॉगिट डिस्टिलेशन का उपयोग किया जाता है, मिड ट्रेनिंग में अधिक लंबे संदर्भ, तर्क ट्रेस और एजेंट डेटा शामिल किए जाते हैं, और पोस्ट ट्रेनिंग में SFT, ऑन पॉलिसी डिस्टिलेशन और RL को जोड़ा जाता है।

Logit Distillation और सामान्य रूप से बड़े मॉडल के उत्तर का उपयोग करके छोटे मॉडल को प्रशिक्षित करने में एक अंतर है। शिक्षक अगले टोकन का अनुमान लगाते समय, पूरे वैबुलरी के लिए एक संभावना वितरण प्रदान करता है। छात्र को सिर्फ अंतिम चुने गए टोकन ही नहीं, बल्कि शिक्षक द्वारा अन्य प्रत्याशियों के प्रति सापेक्ष निर्णय भी देखने को मिलता है।

यह एजेंट के लिए उपयोगी है, क्योंकि कई परिदृश्यों में एकल क्रिया नहीं होती। एक वेबपेज के सामने, मॉडल खोज जारी रख सकता है, किसी परिणाम को खोल सकता है, या एक अलग उपकरण चुन सकता है। शिक्षक का प्रायिकता वितरण इन क्रियाओं के प्रति उसकी प्राथमिकताओं को शामिल करेगा, केवल अंतिम आउटपुट पाठ तक सीमित नहीं।

मिड ट्रेनिंग तक पहुँचने पर, प्रशिक्षण एकल उत्तर से पूर्ण कार्य ट्रैजेक्टरी की ओर बढ़ने लगता है। उपकरण के निष्पादन के बाद, वातावरण बदल जाता है। खोज नए परिणाम लौटाती है, कोड चलाने में विफल होने पर त्रुटि संदेश आता है, और GUI पर गलत क्लिक करने से पेज बदल जाता है। अर्थात, एजेंट का आउटपुट सीधे अगले इनपुट को बदल देता है।

मान लीजिए कि टीचर का सही पथ A से B है, फिर C, और अंत में D। यदि स्टूडेंट केवल टीचर के डेटा को ही सीखता रहता है, तो यह बार-बार A से B और B से C देखेगा। लेकिन वास्तविक संचालन के दौरान, स्टूडेंट पहले कदम में ही एक अलग B स्थिति पर पहुँच सकता है।

अब से, परिदृश्य बदल चुका है, और ट्रेनिंग सेट में B से C तक का प्रवाह इसे अब कैसे संभालना है, यह सीधे नहीं बता सकता। ऑन-पॉलिसी डिस्टिलेशन ठीक यहीं काम करता है। स्टूडेंट पहले अपने आप रोलआउट करता है, अपने वास्तविक स्थितियों में प्रवेश करता है, और फिर इन स्थितियों पर अधिक मजबूत मॉडल के निर्देशन को स्वीकार करता है।

इसलिए ट्रेनिंग डेटा में केवल शिक्षक की आदर्श राह ही शामिल नहीं है, बल्कि छात्र द्वारा बनाई गई गलत स्थितियाँ भी शामिल हैं। यह Muse Glimmer द्वारा जोर देकर बताई गई विफलता पुनर्प्राप्ति से जुड़ा हुआ है।

पैरामीटर गलत भरने के बाद, यदि मॉडल त्रुटि को समझ सकता है और एक बार फिर टूल कॉल को संशोधित कर सकता है, तो कार्य जारी रह सकता है। अगर वेबसाइट पर गलत रास्ता अपना लिया जाता है, तो जब तक वर्तमान स्थिति को गलत पहचाना जा सके, तब तक पीछे हटना या मार्ग बदलना संभव है। वास्तविक समस्या तब होती है जब मॉडल को त्रुटि का एहसास नहीं होता और वह गलत स्थिति पर ही आधारित कार्य करता रहता है, जिससे विचलन एकत्रित होता रहता है।

इसलिए, एजेंट की क्षमता को केवल एक बार के टूल कॉल की सहीता से नहीं, बल्कि पूरे कार्य के अंतिम परिणाम और मध्य में त्रुटि होने पर उसकी पुनर्प्राप्ति क्षमता से भी मापा जाना चाहिए। इसीलिए Muse Glimmer कुछ लंबी प्रक्रिया एजेंट बेंचमार्क पर बेहतर प्रदर्शन करता है।

हालांकि कार्य पूरा किया जा सकता है, इसका अर्थ यह नहीं है कि स्थानीय रन में कोई समस्या नहीं है। यदि एक जटिल कार्य के लिए बहुत सारे Reasoning Token का उत्पादन किया जाना है, तो नया बॉटलनेक जल्द ही Decode बन जाएगा।

दो प्रश्न, एक के बाद एक

Muse Glimmer समर्थन करता है low, medium, high, xhigh चार स्तरों के Reasoning Strength का। इस सेटिंग को रनटाइम रीजनिंग बजट के रूप में समझा जा सकता है।

उच्चतर स्तर आमतौर पर मॉडल को अधिक Reasoning Token उत्पन्न करने की अनुमति देते हैं, जिससे जटिल Coding और Agent कार्यों पर अधिक सफलता की संभावना होती है, लेकिन इसकी कीमत सीधी है। Context तेजी से बढ़ता है और Decode समय भी अधिक होता है।

Meta ने पब्लिक बेंचमार्क में high Reasoning Strength का उपयोग किया है। इससे DFlash का उदय हुआ।

Transformer का डिकोड अनुक्रमिक होता है। दूसरा टोकन पहले टोकन का इंतजार करता है, तीसरा टोकन दूसरे पर निर्भर करता है। कुछ सौ टोकन के उत्तर के लिए यह स्वीकार्य है, लेकिन एजेंट एक कार्य के दौरान हजारों या लाखों टोकन तक उत्पन्न कर सकता है।

स्पेकुलेटिव डिकोडिंग का तरीका एक छोटा Drafter जोड़ना है। Drafter पहले भविष्य के कुछ Token का अनुमान लगाता है, और फिर मुख्य मॉडल एक साथ उनकी पुष्टि करता है। यदि कई प्रत्याशित Token लगातार स्वीकार किए जा सकते हैं, तो 30B मुख्य मॉडल द्वारा Decode Step के निष्पादन की संख्या कम हो जाती है।

पारंपरिक समाधान की समस्या यह है कि Drafter खुद अक्सर आत्म-प्रगतिशील मॉडल होता है। यदि इसे 16 टोकन ड्राफ्ट करने हों, तो फिर भी इसे एक-एक करके उत्पन्न करना पड़ता है।

DFlash ने इसे Block Diffusion से बदल दिया।

Muse Glimmer का DFlash Block Size 16 है, जो एक साथ कई उम्मीदवार टोकन का अनुमान लगाने की अनुमति देता है। लेकिन Drafter केवल तेज़ होना पर्याप्त नहीं है। यदि अनुमान गलत हैं, तो मुख्य मॉडल उम्मीदवारों को अधिकतर अस्वीकार कर देगा, और पहले का गति लाभ जल्द ही समाप्त हो जाएगा।

इसलिए DFlash, Muse Glimmer की 1वीं, 13वीं, 25वीं, 37वीं और 49वीं परतों के Hidden Feature को सीधे पढ़ता है और इन मध्यवर्ती प्रतिनिधित्वों को केवल 5 परतों वाले Drafter को भेजता है। इस तरह Drafter को पूरे Context को फिर से समझने की आवश्यकता नहीं होती, बल्कि वह 30B मुख्य मॉडल द्वारा पहले से बनाए गए आंतरिक प्रतिनिधित्व का सीधे उपयोग करता है।

ये फीचर्स केवल इनपुट एंड पर एक बार ही उपयोग नहीं किए जाते, बल्कि ड्राफ्टर की सभी परतों में की और वैल्यू के रूप में लगातार शामिल किए जाते हैं, ताकि नेटवर्क के गहरा होने के साथ इनकी ताकत कम न हो।

ट्रेनिंग के दौरान एक और बारीकी है। एक 16 टोकन ब्लॉक में, पिछले टोकन की तुलना में पहले टोकन महत्वपूर्ण होते हैं। यदि पहला टोकन गलत है, तो भले ही बाद के टोकन सही अनुमानित हों, लगातार स्वीकृत लंबाई बहुत कम होगी।

इसलिए DFlash Block के पहले के Token को अधिक Loss Weight देगा और बाद के Token के साथ-साथ यह कम होता जाएगा। यह 16 स्थितियों की औसत सटीकता की बजाय संभवतः सबसे लंबे स्वीकार्य प्रीफिक्स को अनुकूलित करता है। Meta द्वारा प्रदान किए गए K Quant 17GB डेटा में, RTX 5090 पर Decode Speed लगभग 74.9 Token/s से बढ़कर 233.4 Token/s हो गई।

यदि एक Agent Task ने कुल 10,000 Token उत्पन्न किए हैं और केवल Decode को देखा जाए, तो पहला लगभग 134 सेकंड लेता है, जबकि दूसरा लगभग 43 सेकंड। वास्तविक कार्य में Prefill, टूल निष्पादन और नेटवर्क प्रतीक्षा भी शामिल होती है, लेकिन उच्च Reasoning Strength वाले Agent के लिए, यह अंतर पूर्ण कार्य अनुभव को स्पष्ट रूप से प्रभावित करता है।

High Reasoning Strength टोकन उत्पन्न करने को बढ़ाता है, DFlash इस समय को कम करने के लिए जिम्मेदार है। लंबा Context KV Cache को बढ़ाता है, GQA और Local Attention मेमोरी को कम करने के लिए जिम्मेदार हैं। क्वांटाइजेशन तब तक मॉडल वेट्स को कंस्यूमर-ग्रेड GPU के सहनशीलता सीमा में रखता रहता है।

इसके अलावा, Muse Glimmer MCP Atlas, DeepSearch QA, Gaia2 आदि Agent Benchmark पर अच्छा प्रदर्शन करती है। इन कार्यों के लिए लंबी निष्पादन श्रृंखला की आवश्यकता होती है।

MCP Atlas को कई MCP सर्वर्स के बीच उपकरणों का चयन और कॉल करना होता है। DeepSearch QA को लगातार खोजना, पेज खोलना, जानकारी ढूंढनी और नए परिणामों के आधार पर आगे बढ़ना होता है। Gaia2 ईमेल, कैलेंडर, संपर्क आदि स्थितियों वाले एप्लिकेशन्स का अनुकरण करता है, और पर्यावरण स्वयं कार्य के दौरान बदलता रहता है।

ये कार्य Muse Glimmer के प्रशिक्षण विधि के साथ अच्छी तरह मेल खाते हैं। लेकिन OSWorld Verified, TerminalBench और SWE Bench Verified पर, यह समान लाभ नहीं बनाए रखता। उदाहरण के लिए, OSWorld Verified पर Muse Glimmer का स्कोर 65.9 है, जबकि Qwen3.6 27B का 75.6 है। TerminalBench 2.1 पर Muse Glimmer का स्कोर 51.7 है, जबकि दूसरा 60.7 तक पहुँचता है।

इसलिए इसकी क्षमता का वितरण अपेक्षाकृत स्पष्ट है। रिसर्च एजेंट, उपकरण सहयोग और लंबी प्रक्रिया स्थिति कार्य मजबूत हैं, जबकि शुद्ध GUI, टर्मिनल और कुछ कोडिंग एजेंट परिदृश्यों में अभी भी स्पष्ट सुधार का स्थान है। ये स्कोर पारंपरिक मॉडल रैंकिंग के अनुसार पूरी तरह से समझे नहीं जा सकते।

Agent Benchmark के परिणाम System Prompt, Tool Definition, Scaffold, अधिकतम निष्पादन चरणों, Sampling पैरामीटर और यहां तक कि Judge Model से भी प्रभावित होते हैं। Meta खुद भी स्पष्ट करता है कि तीसरे पक्ष के मॉडल द्वारा उपयोग किए जाने वाले Agent Tools और System Prompt उनके लिए आदर्श रूप से अनुकूलित नहीं हो सकते हैं।

इसलिए एजेंट चरण तक पहुँचने पर, चेकपॉइंट की अलग-अलग तुलना करके पूरी स्थिति को समझना हर बार और अधिक कठिन होता जा रहा है। सुरक्षा के मामले में भी यही समस्या है।

स्थानीय रूप से चलाने से फाइलों, स्क्रीनशॉट्स और निजी Context को बार-बार क्लाउड पर भेजने में कमी आती है, लेकिन यह केवल डेटा पथ को हल करता है। Prompt Injection, गलत Tool Call, अधिकारों का अतिक्रमण और अपरिवर्तनीय कार्रवाइयाँ अभी भी मौजूद हैं। Meta ने Agentic Risk, Privacy और Prompt Injection का अलग से मूल्यांकन किया है और वास्तविक डिप्लॉयमेंट के लिए Guardrail और आवश्यक Human in the Loop को बढ़ाने की सिफारिश की है।

एक स्पष्ट क्षमता मार्ग

Muse Glimmer की पूरी तकनीकी योजना अंततः एक बहुत स्पष्ट लिंक बना सकती है।

मॉडल आकार लगभग 30B पर नियंत्रित किया जाता है, GQA और Local Attention द्वारा 128K Context की वीडियो मेमोरी लागत कम की जाती है, क्वांटाइजेशन मॉडल को 24GB और 32GB डिवाइस में प्रवेश करने देता है, Perception Encoder विजुअल वातावरण को पढ़ने के लिए जिम्मेदार है, On Policy Distillation लंबे कार्यों में विचलित स्थितियों को कवर करता है, Reasoning Strength डेवलपर्स को रीजनिंग बजट पर नियंत्रण देता है, DFlash बड़ी संख्या में Reasoning Token द्वारा उत्पन्न Decode देरी को पुनः संसाधित करता है।

Muse Glimmer ने साबित नहीं किया कि स्थानीय 30B मॉडल क्लाउड Frontier Model को प्रतिस्थापित कर सकता है, लेकिन इसने साबित किया कि 30B स्थानीय मॉडल का अंतिम लक्ष्य केवल स्केल पर नहीं, बल्कि विभिन्न हार्ड कॉन्स्ट्रेंट्स के लिए सिस्टम-लेवल इंजीनियरिंग के समग्र हेजिंग पर आधारित है। इसने स्थानीय Agent में सबसे कठिन चार कॉन्स्ट्रेंट्स—वीएम, कॉन्टेक्स्ट, एनवायरनमेंट स्टेट परिज्ञान और इनफरेंस स्पीड—को एक ही सिस्टम डिज़ाइन में शामिल कर लिया है।

Muse Glimmer हालांकि अभी भी क्लाउड-आधारित फ्लैगशिप मॉडल को पूरी तरह से बदल नहीं सकता, लेकिन "हर कोई अपना निजी Agent प्राप्त करे" के लक्ष्य के लिए एक औद्योगिक स्तर पर लागू करने योग्य मार्ग प्रशस्त कर चुका है।