মেটা মিউজ গ্লিমার প্রকাশ করেছে, যা প্রায় 30B প্যারামিটারের একটি মাল্টিমোডাল এজেন্ট মডেল, যা 128K স্তরের কনটেক্সট সমর্থন করে এবং 24GB ভিডিও মেমোরি সহ ডিভাইসে চালানো যায়। এই মডেলটি Apache 2.0 লাইসেন্সে উন্মুক্ত, GQA ব্যবহার করে KV Cache-এর ব্যবহার কমিয়ে দেওয়া হয়েছে, এবং দীর্ঘ কনটেক্সটের গণনা খরচ কমানোর জন্য লোকাল এবং গ্লোবাল অ্যাটেনশনের মিশ্র আর্কিটেকচার ব্যবহার করা হয়েছে। এছাড়াও, বিভিন্ন ভিডিও মেমোরি ডিভাইসের জন্য দুটি কোয়ান্টাইজড ভার্সন প্রদান করা হয়েছে। ভিজুয়াল মডিউলটিতে স্ক্রিনশট এবং স্ক্রিন তথ্য প্রক্রিয়াকরণের জন্য একটি স্বতন্ত্র ViT Perception Encoder যুক্ত করা হয়েছে, এবং ট্রেনিংয়ের সময় On Policy Distillation-এর মাধ্যমে দীর্ঘ টাস্ক-এর জন্য ডিভিয়েশন-সহ অবস্থা কভার করা হয়েছে। DFlash ইনফারেন্স অপটিমাইজেশন কম্পোনেন্টটি Block Diffusion-এর মাধ্যমে Token-এর প্যারালাল পূর্বানুমান করে, RTX 5090-এ প্রায় 3x ডিকোডিং গতির উন্নতি ঘটিয়েছে। মডেলটি MCP Atlas, DeepSearch QA-এর মতো Agent Benchmark-এ উত্তমভাবে পারফরম করেছে, তবে OSWorld Verified-এর মতো শুধুমাত্র GUI-ভিত্তিক সিনারিওতেও উন্নতির সম্ভাবনা রয়েছে।

লেখক এবং উৎস: লেইফেঙ্গওয়েন

গতকাল, মেটা মিউজ গ্লিমার প্রকাশ করেছে। এটি একটি প্রায় 30B প্যারামিটারের মাল্টিমোডাল এজেন্ট মডেল, যা 128K স্তরের কনটেক্সট সমর্থন করে, টুল কল করতে পারে, কোড এক্সিকিউট করতে পারে এবং ছবি এবং স্ক্রিন তথ্য প্রক্রিয়া করতে পারে।

এই মডেলটি Apache 2.0 লাইসেন্সে উন্মুক্ত, এছাড়াও দুটি 4bit কোয়ান্টাইজড ভার্সন, স্বতন্ত্র ভিজুয়াল এনকোডার এবং DFlash ইনফারেন্স স্পিড-আপ কম্পোনেন্ট সহ প্রদান করা হয়েছে, এবং llama.cpp, MLX, ExecuTorch ইত্যাদি স্থানীয় ডিপ্লয়মেন্ট বিকল্প প্রদান করা হয়েছে।

যদিও আজকের দিনে 30B প্যারামিটার স্কেল এবং 128K কনটেক্সট বিরল নয়, কিন্তু সমস্যা হলো, Meta এটিকে সাধারণ চ্যাটের জন্য নয়, বরং একটি সম্পূর্ণ স্থানীয় Agent রান প্যারাডাইম তৈরি করতে চায়।

মিউজ গ্লিমারের জন্য ডিজাইন করা দীর্ঘমেয়াদী স্থানীয় এজেন্টগুলি কঠোর প্রকৌশল সীমাবদ্ধতার সম্মুখীন হয়: এটি সীমিত 24GB ভিডিও মেমরিতে অবিরাম স্ক্রিনশট প্রক্রিয়াকরণের পাশাপাশি দশকগুলির কাজের যুক্তি বজায় রাখতে হবে। একটি কাজ দশকগুলি চলার পরে, পূর্ববর্তী টুলের ফলাফল, কোড লগ, পেজের অবস্থা এবং যুক্তির প্রক্রিয়া ধারাবাহিকভাবে কনটেক্সটে থেকে যায়।

এই সময়, চ্যাট স্কেনারিওতে আগে পরিষ্কার না হওয়া অনেক সমস্যা দ্রুত বড় হয়ে ওঠে। 128K কনটেক্সটকে সীমিত জিপিইউ মেমোরিতে কীভাবে ফিট করা যায়, স্ক্রিনশটের সংখ্যা বাড়তে থাকলে হিস্টোরি স্টেট কীভাবে ম্যানেজ করা যায়, টুল কল ব্যর্থ হলে মডেলটি কীভাবে এগিয়ে যায়, এবং বহুল রিজনিং টোকেন ডিকোডকে কতটা ধীর করে ফেলে।

মিউজ গ্লিমারের টেকনিক্যাল ডিজাইন মূলত এই প্রশ্নগুলির চারপাশে ঘুরে বেড়ায়। এটি কোনও একটি বিশেষভাবে উল্লেখযোগ্য নতুন আর্কিটেকচারের উপর নির্ভর করে সবকিছু সমাধান করেনি, বরং Attention, KV Cache, ট্রেনিং পদ্ধতি, কোয়ান্টাইজেশন এবং Decode-এ উদ্ভট সমঝোতা করেছে।

যদি আগের স্থানীয় মডেলগুলি ছিল "চলমান", তবে Muse Glimmer-এর লক্ষ্য হল "ক্লাউডের মতো সহজে ব্যবহারযোগ্য এবং অবিরামভাবে কাজ করা"।

এই অংশগুলি একসাথে দেখলে, Meta এটিকে বর্তমান রূপে কেন তৈরি করেছে তা শুধুমাত্র 30B বা 128K একা দেখার চেয়ে বুঝতে সহজ।

128K কনটেক্সটকে 24GB জিপিইউ মেমোরিতে কিভাবে ফিট করাবেন

মিউজ গ্লিমার 52 স্তরের ডেনস ট্রান্সফরমার, 6656 হিডেন সাইজ এবং 32 কোয়েরি হেড, কিন্তু মাত্র 2 কেভি হেড ব্যবহার করে।

লক্ষণীয় যে, প্রতিটি স্তরে সম্পূর্ণ প্রসঙ্গ প্রক্রিয়াকরণ করা হয় না, বরং তিনটি লোকাল অ্যাটেনশন এবং একটি গ্লোবাল অ্যাটেনশনের চক্রীয় পদ্ধতি ব্যবহার করা হয়।

লোকাল অ্যাটেনশন শুধুমাত্র পাশের 2048 টোকেন প্রক্রিয়া করে, গ্লোবাল অ্যাটেনশনই দীর্ঘ দূরত্বের তথ্য বিনিময়ের জন্য দায়ী।

এই দুটি ডিজাইন একসাথে দীর্ঘ কনটেক্সটের খরচ বাড়াচ্ছে। মডেল নতুন টোকেন তৈরি করার সময়, আগের টোকেনগুলির কী এবং ভ্যালু ক্যাশ করে রাখে, যাকে KV ক্যাশ বলা হয়। কনটেক্সট যত দীর্ঘ হবে, এই অংশটি এতটাই বেশি জায়গা নেবে।

মিউজ গ্লিমারের প্রতিটি স্তরে শুধুমাত্র 2টি KV হেড রয়েছে, এবং প্রতিটি হেড ডাইমেনশন 128। BF16 অনুযায়ী প্রায় হিসাব করলে, একটি টোকেন একটি স্তরে প্রায় 1024 বাইট KV দখল করে।

যদি 52টি স্তরের প্রতিটি সম্পূর্ণ 128K কনটেক্সট সংরক্ষণ করা হয়, তবে KV ক্যাশে প্রায় 6.5 গিবিবাইট প্রয়োজন হবে। তবে Muse Glimmer-এ বাস্তবে 39টি লোকাল স্তর এবং 13টি গ্লোবাল স্তর রয়েছে। লোকাল স্তরগুলির জন্য শুধুমাত্র প্রায় 2048 টোকেনের স্লাইডিং উইন্ডো বজায় রাখতে হয়, কেবলমাত্র গ্লোবাল স্তরগুলিই সম্পূর্ণ দীর্ঘ কনটেক্সট সংরক্ষণ করে।

একই পদ্ধতিতে আনুমান করা যায় যে KV Cache প্রায় 1.7 GiB পর্যন্ত কমে যায়। এটি অফিসিয়ালভাবে প্রকাশিত রানটাইম ভিডিও মেমোরি নয়, বরং প্রকাশিত আর্কিটেকচার প্যারামিটারগুলির উপর ভিত্তি করে তৈরি একটি তাত্ত্বিক আনুমান, কিন্তু এটি এই স্ট্রাকচারটির এইভাবে ডিজাইনের কারণটি বুঝতে পারার জন্যই যথেষ্ট।

যদি এটি 2টি KV হেড ব্যবহার না করে এবং প্রতিটি 32টি হেডের জন্য প্রত্যেকটির জন্য স্বতন্ত্র KV সংরক্ষণ করে, তবে একই শর্তে, KV ক্যাশে তাত্ত্বিকভাবে আরও প্রায় 16 গুণ বৃদ্ধি পাবে, যা সরাসরি 20+ GiB-এ পৌঁছাবে।

একটি মাত্র 24GB গ্রাফিক্স কার্ডের চেয়ে একক KV ক্যাশে বেশি। এখানে আসলে দুটি পদ্ধতি ব্যবহার করা হয়েছে। GQA প্রতিটি টোকেনের জন্য সংরক্ষণ করার প্রয়োজনীয় 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টি বেঞ্চমার্কের গড় সঠিকতা ক্ষতির মধ্যে, ডাইনামিক কে কোয়ান্টাইজেশন প্রায় 0.2%, কে কোয়ান্টাইজেশন 17GB প্রায় 1.0%।

অর্থাৎ, 24GB সংস্করণটি গ্রাফিক্স মেমোরি আরও কমিয়ে দেয় এবং কম স্থান দখল করে, তবে একটু বেশি পারফরম্যান্স হ্রাস গ্রহণযোগ্য। 32GB সংস্করণটি মূল মডেলের পারফরম্যান্স সর্বাধিকভাবে বজায় রাখে।

মিউজ গ্লিমারের 128K কনটেক্সট এই কম্বিনেশনেই সম্ভব। অ্যাটেনশন প্রথমে ক্যালকুলেশন লোড কমায়, তারপর GQA দ্বারা KV ক্যাশে কমায়, এবং শেষে কোয়ান্টাইজেশন দিয়ে মডেল ওয়েট কমানো হয়।

এই পদ্ধতিটিরও একটি মূল্য রয়েছে। 39টি লোকাল স্তর শুধুমাত্র পাশের 2048টি টোকেনে সরাসরি অ্যাক্সেস করতে পারে, দূরবর্তী তথ্যের জন্য গ্লোবাল স্তরের মাধ্যমে প্রচার প্রয়োজন। তাই, 128K ইনপুট করা এবং সম্পূর্ণ 128K স্থিরভাবে ব্যবহার করা একই বিষয় নয়।

মেটার বিম 128K ফলাফল দেখায় যে লোকাল এবং গ্লোবাল মিশ্র স্ট্রাকচার এখনও দীর্ঘ দূরত্বের তথ্য ব্যবহারের জন্য ভালো ক্ষমতা রাখে, কিন্তু এটি লং কনটেক্সট সমাধান করে, দীর্ঘমেয়াদী মেমোরি নয়। কোন তথ্য সংরক্ষণ করা উচিত, কোনটি পুরনো হয়ে গেছে, এবং কখন স্ট্যাটাস আপডেট করা উচিত—এগুলি এখনও এজেন্ট রানটাইম দ্বারা পরিচালিত হতে হবে।

এই সমস্যাটি ভিজুয়াল এজেন্টের ক্ষেত্রে আরও পরিষ্কারভাবে দেখা যাবে।

128K অসীম স্থান নয়

Muse Glimmer একটি প্রায় 1.8B প্যারামিটার বিশিষ্ট ViT-G-14 Perception Encoder ও সংযুক্ত রয়েছে, যা স্ক্রিনশট, ওয়েবপেজ, গ্রাফ এবং ডকুমেন্ট প্রক্রিয়াকরণের জন্য ব্যবহৃত হয়। একটি ছবি সর্বোচ্চ 4096টি Visual Token-এ রূপান্তরিত হতে পারে।

এটি বর্তমানে টেক্সট এবং ইমেজ ইনপুট, টেক্সট আউটপুট, সমস্ত মোডালিটিকে একই জেনারেটিভ মডেলে ফেলে দেওয়া হয়নি।

এজেন্ট ওয়ার্কফ্লোতে, এই দৃশ্যমান ক্ষমতাটি পরিবেশের অবস্থা পড়ার জন্য দায়ী। কম্পিউটার ব্যবহার এজেন্টটি প্রথমে বর্তমান স্ক্রিনটি দেখে, পেজ, বোতাম এবং টেক্সটের অবস্থান চিহ্নিত করে, তারপর একটি অপারেশন সম্পাদন করে। পেজটি পরিবর্তিত হওয়ার পর, এটি নতুন স্ক্রিনশটটি পড়ে, পরবর্তী পদক্ষেপ নির্ধারণ করে।

অতএব, দৃশ্য ইনপুট নিয়মিত কনটেক্সটে প্রবেশ করে। যদি ডজন বা ডজন পাঁচেক ধাপের কাজের সমস্ত স্ক্রিনশট সংরক্ষিত থাকে, তবুও 128K থাকলেও কনটেক্সট দ্রুত ভিজুয়াল টোকেন দ্বারা পূর্ণ হয়ে যায়। পুরনো স্ক্রিনশটগুলি বর্তমান অবস্থার সাথে সংঘাতে পড়তে পারে। পৃষ্ঠাটি পরিবর্তিত হয়েছে, কিন্তু আগের বোতাম এবং উইন্ডোগুলি এখনও কনটেক্সটে রয়ে গেছে, যার ফলে মডেলকে অতিরিক্তভাবে বিচার করতে হয় যে কোনটি সর্বশেষ অবস্থা।

মেটা OSWorld Verified-এর রিভিউতেও স্ক্রিনশট হিস্ট্রি অসীমভাবে সংরক্ষণ করে না, বরং শুধুমাত্র সাম্প্রতিক কিছু স্ক্রিনশট রাখে। এটি নির্দেশ করে যে পারসেপশন এনকোডার এবং কনটেক্সট ম্যানেজমেন্ট দুটি আলাদা সমস্যা।

প্রথমটি বর্তমান স্ক্রিনটিকে মডেলের বোঝার যোগ্য তথ্যে রূপান্তরিত করে, আর দ্বিতীয়টি নির্ধারণ করে কোন ইতিহাসগত অবস্থা গুরুত্বপূর্ণ এবং কোনগুলো মুছে ফেলা উচিত। তাই 128K-এর মতো বড় স্পেসটি Agent-এর জন্য অবস্থা পরিচালনা বাতিল করার জন্য নয়, বরং একটি বড় কাজের জায়গা প্রদান করে।

যখন এজেন্ট পর্যায়ক্রমে পরিবেশের সাথে মিথস্ক্রিয়া করে, তখন প্রশ্নটি মডেল কী দেখেছে থেকে মডেল সম্প্রতি কী করেছে তার দিকে সরে যায়।

এখন মিউজ গ্লিমারের প্রশিক্ষণ অংশে প্রবেশ করুন।

এজেন্ট যদি বিভ্রান্ত হয়ে যায়, তাহলে কীভাবে এগিয়ে যাবেন

মিউজ গ্লিমার বড় মিউজ স্পার্ক থেকে প্রক্রিয়াকৃত হয়েছে।

মেটা প্রশিক্ষণকে প্রি ট্রেনিং, মিড ট্রেনিং এবং পোস্ট ট্রেনিং-এ বিভক্ত করে। প্রি ট্রেনিং-এ লগিট ডিস্টিলেশন ব্যবহার করা হয়, মিড ট্রেনিং-এ আরও বেশি দীর্ঘ কনটেক্সট, রিজনিং ট্রেস এবং এজেন্ট ডেটা যোগ করা হয়, এবং পোস্ট ট্রেনিং-এ SFT, অন-পলিসি ডিস্টিলেশন এবং RL যোগ করা হয়।

লগিট ডিস্টিলেশন এবং সাধারণভাবে বড় মডেলের উত্তর ব্যবহার করে ছোট মডেল ট্রেন করার মধ্যে একটি পার্থক্য আছে। টিচার পরবর্তী টোকেনটি পূর্বানুমান করার সময়, সম্পূর্ণ ভোকাবুলারির জন্য একটি সম্ভাবনার বণ্টন প্রদান করে। স্টুডেন্ট শুধুমাত্র চূড়ান্তভাবে নির্বাচিত টোকেনটি শিখে না, বরং অন্যান্য প্রতিদ্বন্দ্বীদের প্রতি টিচারের আপেক্ষিক মূল্যায়নও দেখে।

এটি এজেন্টের জন্য খুব উপযোগী, কারণ অনেক পরিস্থিতিতে একটিমাত্র ক্রিয়া বিদ্যমান নয়। একটি ওয়েবপেজের সামনে মডেলটি অনুসন্ধান চালিয়ে যেতে পারে, কোনো ফলাফল খুলতে পারে, অথবা অন্য একটি টুল ব্যবহার করতে পারে। শিক্ষকের সম্ভাব্যতা বণ্টনটি শুধুমাত্র শেষ আউটপুট টেক্সটটির জন্য নয়, বরং এই ক্রিয়াগুলির প্রতি তার পছন্দকেও অন্তর্ভুক্ত করবে।

মিড ট্রেনিং-এ পৌঁছানোর পর, ট্রেনিং একক উত্তর থেকে সম্পূর্ণ কার্য ট্রাজেক্টরির দিকে এগিয়ে যায়। টুল বাস্তবায়নের পর, পরিবেশ পরিবর্তিত হয়। অনুসন্ধান নতুন ফলাফল ফেরত দেয়, কোড চালানোর ব্যর্থতা ত্রুটি দেখায়, এবং 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 Token জেনারেট করতে বাধ্য করে, যা জটিল Coding এবং Agent টাস্কে উচ্চতর সফলতার হার দিতে পারে, কিন্তু এর মূল্যও সরাসরি। Context দ্রুত বৃদ্ধি পায় এবং Decode সময়ও বেড়ে যায়।

মেটা পাবলিক বেঞ্চমার্কে high Reasoning Strength ব্যবহার করে। এটি DFlash-এর দিকে নিয়ে যায়।

ট্রান্সফরমারের ডিকোড অটোরিগ্রেসিভ। দ্বিতীয় টোকেনের জন্য প্রথম টোকেনের অপেক্ষা করতে হয়, তৃতীয় টোকেনটি দ্বিতীয় টোকেনের উপর নির্ভরশীল। কয়েকশ টোকেনের উত্তরের জন্য এটি গ্রহণযোগ্য, কিন্তু এজেন্টের একটি কাজে হাজার বা এমনকি লক্ষ টোকেন সঞ্চিত হতে পারে।

স্পেকুলেটিভ ডিকোডিংয়ের পদ্ধতি হল একটি ছোট ড্রাফটার যোগ করা। ড্রাফটার প্রথমে ভবিষ্যতের কিছু টোকেন পূর্বানুমান করে, তারপর মূল মডেল একবারে তা যাচাই করে। যদি একাধিক প্রত্যাশিত টোকেন ক্রমাগতভাবে গ্রহণযোগ্য হয়, তবে 30B মূল মডেলের ডিকোড স্টেপের সংখ্যা কমিয়ে ফেলা যায়।

প্রাচীন পদ্ধতির সমস্যা হলো, ড্রাফটার নিজেই সাধারণত একটি অটোরিগ্রেসিভ মডেল। যদি এটি 16টি টোকেন ড্রাফট করে, তবুও একটি একটি করে তৈরি করতে হবে।

ডিফ্ল্যাশ এই অংশটি ব্লক ডিফিউশনে পরিবর্তন করেছে।

মিউজ গ্লিমারের ডিফ্ল্যাশ ব্লক সাইজ 16, যা একটি সেট প্রত্যাশিত টোকেনকে সমান্তরালে পূর্বানুমান করতে পারে। কিন্তু ড্রাফটার শুধু দ্রুত হওয়াই যথেষ্ট নয়। যদি অনুমান ভুল হয়, তবে মূল মডেল প্রত্যাশিতগুলির বেশিরভাগকে প্রত্যাখ্যান করবে, এবং আগের গতির সুবিধা দ্রুত নষ্ট হয়ে যাবে।

অতএব, DFlash সরাসরি Muse Glimmer-এর 1ম, 13য়, 25তম, 37তম এবং 49তম স্তরের Hidden Feature পড়ে এই মধ্যবর্তী প্রতিনিধিত্বগুলি কেবলমাত্র 5 স্তরের Drafter-এর কাছে পাঠায়। এভাবে Drafter-এর নিজের পুরো Context বুঝতে হয় না, বরং এটি 30B মূল মডেল দ্বারা ইতিমধ্যে গঠিত অভ্যন্তরীণ প্রতিনিধিত্বগুলির সরাসরি ব্যবহার করে।

এই ফিচারগুলি শুধুমাত্র ইনপুট প্রান্তে একবার ব্যবহার করা হয় না, বরং ড্রাফটারের সমস্ত স্তরের কী এবং ভ্যালুতে ধারাবাহিকভাবে সংযোজিত হয়, যাতে নেটওয়ার্কের গভীরতা বাড়ার সাথে সাথে এগুলি দুর্বল হয়ে না পড়ে।

প্রশিক্ষণের সময় আরও একটি বিস্তারিত রয়েছে। একটি 16 টোকেন ব্লকে, প্রথমের টোকেনগুলি পরেরগুলির চেয়ে গুরুত্বপূর্ণ। যদি ১ম টোকেনটি ভুল হয়, তবে পরবর্তীগুলি যতই সঠিকভাবে অনুমান করা হয়, ক্রমিক গ্রহণযোগ্য দৈর্ঘ্য খুব ছোট হবে।

অতএব, DFlash ব্লকের আগের টোকেনগুলিকে বেশি Loss Weight দেয় এবং পরবর্তীগুলি ধীরে ধীরে কমিয়ে দেয়। এটি শুধুমাত্র 16টি পজিশনের গড় সঠিকতা অর্জনের চেয়ে যতদীর্ঘ সম্ভব গ্রহণযোগ্য প্রিফিক্স অপ্টিমাইজ করে। Meta-এর প্রদত্ত K Quant 17GB ডেটাতে, RTX 5090-এ Decode Speed প্রায় 74.9 Token/s থেকে বেড়ে 233.4 Token/s হয়।

যদি একটি Agent টাস্ক মোট 10,000 টোকেন জেনারেট করে, তবে শুধুমাত্র Decode দেখলে, প্রথমটি প্রায় 134 সেকেন্ড এবং দ্বিতীয়টি প্রায় 43 সেকেন্ড সময় নেয়। বাস্তব টাস্কে প্রিফিল, টুল এক্সিকিউশন এবং নেটওয়ার্ক ওয়েটিংও অন্তর্ভুক্ত থাকে, কিন্তু উচ্চ Reasoning Strength সম্পন্ন Agent-এর জন্য এই পার্থক্যটি পূর্ণাঙ্গ টাস্ক অভিজ্ঞতাকে স্পষ্টভাবে প্রভাবিত করবে।

হাই রিজনিং স্ট্রেন্থ টোকেন জেনারেশন বাড়ায়, ডি-ফ্ল্যাশ এই সময় কমাতে দায়িত্ব পালন করে। লং কনটেক্সট KV ক্যাশে বাড়ায়, জি-কিউ-এ এবং লোকাল অ্যাটেনশন মেমোরি কমাতে দায়িত্ব পালন করে। কোয়ান্টাইজেশন মডেল ওয়েটসকে কনজুমার-লেভেল জিপিইউ-এর সহনশীলতার মধ্যে রাখে।

এছাড়াও, Muse Glimmer MCP Atlas, DeepSearch QA, Gaia2 ইত্যাদি এজেন্ট বেঞ্চমার্কে ভালো পারফর্ম করে। এই টাস্কগুলির জন্য দীর্ঘ একেকটি একেকটি একecution chain প্রয়োজন।

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, টার্মিনাল এবং কিছু Coding Agent সেটিংয়ে উল্লেখযোগ্য উন্নতির সম্ভাবনা রয়েছে। এই স্কোরগুলিকে প্রচলিত মডেল র‍্যাঙ্কিংয়ের মতো বুঝা যায় না।

Agent Benchmark-এর ফলাফল সিস্টেম প্রম্পট, টুল ডেফিনিশন, স্ক্যাফোল্ড, সর্বাধিক বাস্তবায়ন ধাপ, স্যাম্পলিং প্যারামিটার এবং জজ মডেলের উপরও নির্ভর করে। মেটা নিজেই উল্লেখ করেছে যে তৃতীয় পক্ষের মডেলগুলি যে এজেন্ট টুলস এবং সিস্টেম প্রম্পট ব্যবহার করে, তা অবশ্যই তাদের জন্য অপ্টিমাইজড হয়নি।

অতএব, এজেন্ট পর্যায়ে পৃথকভাবে চেকপয়েন্ট তুলনা করে সম্পূর্ণ পরিস্থিতি বোঝা ক্রমশ কঠিন হয়ে পড়ছে। নিরাপত্তা নিয়েও একই সমস্যা।

স্থানীয়ভাবে চালানো সত্যিই ফাইল, স্ক্রিনশট এবং ব্যক্তিগত Context-এর প্রায়শই ক্লাউডে পাঠানো কমিয়ে দেয়, কিন্তু এটি শুধুমাত্র ডেটা পথকে সমাধান করে। Prompt Injection, ভুল Tool Call, অনুমতির অতিক্রমণ এবং অপরিবর্তনযোগ্য অপারেশন এখনও বিদ্যমান। Meta আলাদাভাবে Agentic Risk, Privacy এবং Prompt Injection-এর মূল্যায়নও করেছে এবং বাস্তব ডিপ্লয়মেন্টে Guardrail এবং প্রয়োজনীয় Human in the Loop-এর পরিমাণ বৃদ্ধির পরামর্শ দিয়েছে।

একটি স্পষ্ট ক্ষমতা রুট

মিউজ গ্লিমারের সম্পূর্ণ প্রযুক্তিগত পথ শেষ পর্যন্ত একটি পরিষ্কার লিঙ্কে যুক্ত হতে পারে।

মডেল সাইজ প্রায় 30B এ রাখুন, GQA এবং Local Attention ব্যবহার করে 128K Context-এর জন্য গ্রাফিক্স মেমোরি খরচ কমান, কোয়ান্টাইজেশনের মাধ্যমে মডেলটিকে 24GB এবং 32GB ডিভাইসে প্রবেশ করান, Perception Encoder ভিজুয়াল পরিবেশ পড়তে দায়ি, On Policy Distillation দীর্ঘ টাস্কের মধ্যে বিচ্যুত স্টেটগুলি কভার করে, Reasoning Strength ডেভেলপারদের রিজনিং বাজেট নিয়ন্ত্রণের সুযোগ দেয়, DFlash বড় পরিমাণ Reasoning Token-এর কারণে হওয়া Decode ল্যাটেন্সি আবার প্রক্রিয়া করে।

মিউজ গ্লিমার স্থানীয় 30B মডেলকে ক্লাউড-ভিত্তিক ফ্রন্টিয়ার মডেলের বিকল্প হিসেবে প্রমাণ করেনি, কিন্তু এটি প্রমাণ করেছে যে 30B স্থানীয় মডেলের চূড়ান্ত লক্ষ্য শুধুমাত্র আকারের উপর নির্ভর করে না, বরং বিভিন্ন হার্ড সীমাবদ্ধতার সমন্বিত হেজিংয়ের জন্য সিস্টেম-লেভেল ইঞ্জিনিয়ারিংয়ের উপর। এটি ইতিমধ্যেই স্থানীয় Agent-এর সবচেয়ে কঠিন চারটি সীমাবদ্ধতা—ভিডিও মেমোরি, কনটেক্সট, পরিবেশের অবস্থা বোধ এবং যুক্তির গতি—কে একই সিস্টেম ডিজাইনের মধ্যে রেখেছে।

মিউজ গ্লিমার যদিও এখনও ক্লাউড-ভিত্তিক ফ্ল্যাগশিপ মডেলকে সম্পূর্ণরূপে প্রতিস্থাপন করতে পারে না, তবুও "প্রত্যেকের নিজস্ব এজেন্ট" লক্ষ্যের জন্য একটি শিল্প-মানের বাস্তবায়নের পথ প্রশস্ত করেছে।