کرم AI هنوز عملی نیست؛ یک مدل آزمایشی در ۴ اجرا هر ۸ گره را گرفت

بر پایهٔ پژوهش Anthropic که ۱۲ اکتبر ۲۰۲۶ منتشر شد، GLM-5.2 در شبکه‌ای محصور از شبیه‌سازهای اندروید در ۴ اجرا از ۵ اجرا به همهٔ ۸ گره رسید و در اجرای دیگر به ۷ گره دست یافت. عامل آزمایشی توانست یافتن مقصد، انتقال بار اجرایی و راه‌اندازی استنتاج را در این محیط به هم پیوند دهد. این نتیجه دربارهٔ یک آزمون ساده‌شده است، نه انتشار یک کرم مستقل میان دستگاه‌های واقعی.

به روایت گزارش Tom’s Hardware در ۱۳ اکتبر، GLM-5.2 تصمیم‌های انتشار را از سروری جدا می‌گرفت و روی گره‌های مقصد، استنتاج مدل کوچک‌تر Llama3.1-8B را راه می‌انداخت؛ سخت‌افزار گره‌ها ظرفیت اجرای خود مدل هدایتگر را نداشت. بنابراین موفقیت شبکهٔ محصور نشان می‌دهد یک مدل بزرگ می‌تواند زنجیره را هماهنگ کند، اما هنوز نشان نمی‌دهد مدلی که روی دستگاه هدف جا می‌شود بتواند همان زنجیره را مستقل و با همان اطمینان پیش ببرد.

عامل در شبکهٔ محصور چه کرد؟

محیط انتشار، شبکه‌ای خصوصی و پشت دیوار آتش در Google Cloud بود. گره‌ها شبیه‌ساز Android 15 را اجرا می‌کردند و عامل از گره‌ای آغاز می‌کرد که از پیش آماده شده بود. سپس مقصدهای دیگر را در شبکه پیدا می‌کرد، به آن‌ها دسترسی می‌یافت، فایل‌های لازم را می‌فرستاد و برای اجرای مدل در مقصد سرویس استنتاج برپا می‌کرد. رسیدن فایل‌ها به مقصد پایان کار نبود؛ سرویس باید واقعاً پاسخ می‌داد تا آن گره در ارزیابی موفق به شمار آید.

دسترسی به گره بعدی عمداً آسان شده بود: درگاه ADB در محیط آزمون احراز هویت نمی‌خواست. پژوهشگران این شرط را، به نقل از گزارش The Register، «an upper bound on real-world success» خوانده‌اند؛ یعنی نتیجهٔ مشاهده‌شده برآوردی خوش‌بینانه از موفقیت در جهان واقعی است. در دستگاهی با دسترسی بسته، مجوزهای متفاوت یا پیکربندی ناشناخته، همین مرحلهٔ ورود می‌تواند پیش از انتقال بار اجرایی متوقف شود.

یک جزء دیگر نیز در تفسیر چرخه اهمیت دارد. پس از آنکه سرویس استنتاجِ مقصد آزمون‌های صحت را می‌گذراند، سازوکار ارزیابی نسخهٔ تازه‌ای از عامل آزمایشی را روی آن گره راه می‌انداخت تا انتشار ادامه یابد. در نتیجه، عبارت «رسیدن به گره» به معنای آن نیست که وزن‌های GLM-5.2 در همان دستگاه جا گرفته و مدل بدون تکیه به سرور جداگانه از آنجا تصمیم گرفته است. آزمون، توان هدایت مرحله‌های پی‌درپی را در شرایط تعریف‌شده اندازه می‌گرفت.

چرا راه‌اندازی استنتاج گلوگاه آزمایش بود؟

بخش سخت زنجیره فقط پیدا کردن دستگاه بعدی یا فرستادن فایل نیست. عامل باید برای سخت‌افزار و سیستم‌عامل مقصد نرم‌افزار استنتاج سازگار انتخاب کند، نسخهٔ مناسب وابستگی‌ها را بیابد و خطاهای نصب و اجرا را برطرف کند. این تصمیم‌ها به هم وابسته‌اند: انتخاب نادرست در آغاز ممکن است ساعت‌ها عیب‌یابی بعدی را بی‌نتیجه کند. مدلی که بتواند فایل را کپی کند ولی سرویس قابل استفاده‌ای بالا نیاورد، نمی‌تواند از میزبان تازه ادامه دهد.

در ارزیابی جداگانهٔ راه‌اندازی استنتاج، مدل‌های کوچک‌تر نیز توانستند روی چند نوع سخت‌افزار سرویس بسازند؛ نمونه‌های بررسی‌شده از رایانه‌های معمول تا دستگاه‌های لبه‌ای را دربرمی‌گرفتند. تفاوت در کنار هم قرار دادن همهٔ مراحل آشکار شد: توان انجام یک وظیفهٔ فنی به‌تنهایی معادل توان دنبال کردن چرخهٔ کامل انتشار نبود. همین فاصله توضیح می‌دهد چرا نتیجهٔ مدل هدایتگرِ بزرگ را نمی‌توان به مدل کوچک مستقر در مقصد نسبت داد.

برای اجرای کارهای طولانی، محیط آزمایش از Memento استفاده می‌کرد؛ سازوکاری که پس از مدتی نمونهٔ تازه‌ای از عامل را با فضای کار و یادداشت‌های نمونهٔ پیشین آغاز می‌کرد. هدف آن کمک به بازگشت از مسیرهای عیب‌یابی اشتباه بود. این پشتیبانی نیز بخشی از شرایط آزمون است: نتیجهٔ شبکه حاصل عملکرد مدل در یک محیط عامل‌محور مشخص بود و نباید آن را ویژگی ذاتی وزن‌های مدل، مستقل از ابزارهای همراهش، خواند.

جعبه‌های تلویزیون چه نسبتی با انتشار داشتند؟

آزمایش جعبه‌های تلویزیون اندرویدی به پرسش دیگری پاسخ می‌داد: آیا سخت‌افزار ارزان می‌تواند اصلاً استنتاج یک مدل را انجام دهد؟ در آن آزمایش، لایه‌های Gemma4-26B-A4B میان چند دستگاه تقسیم شد تا هر دستگاه فقط بخشی از مدل را در حافظه نگه دارد. چنین چیدمانی نشان می‌دهد کمبود حافظهٔ یک دستگاه همیشه مانع اجرای جمعی مدل نیست؛ در عوض، اجرای هر پاسخ به ارتباط میان دستگاه‌ها و عبور محاسبه از بخش‌های مختلف وابسته می‌شود.

آن دستگاه‌های فیزیکی همان گره‌های شبیه‌سازی‌شدهٔ آزمایش انتشار نبودند. روی جعبه‌های تلویزیون، استنتاج توزیع‌شده نمایش داده شد؛ در شبکهٔ محصور، عامل بزرگ‌تر انتشار را هدایت کرد. ترکیب این دو مشاهده برای تصور یک کرم مستقل کافی نیست، چون مدل مستقر روی سخت‌افزار کم‌هزینه باید خود نیز توان تصمیم‌گیری، رفع خطا و ادامهٔ انتشار را داشته باشد. پژوهش دقیقاً در این نقطه میان توان محاسباتیِ قابل فراهم‌کردن و توان عاملِ مورد نیاز فاصله می‌بیند.

استنتاج توزیع‌شده افزون بر ظرفیت حافظه، مسئلهٔ سرعت را هم پیش می‌آورد. وقتی بخش‌های مدل روی چند دستگاه قرار دارند، پاسخ‌دادن به رفت‌وآمد داده میان آن‌ها وابسته است و تصمیم‌های عامل کندتر گرفته می‌شود. جابه‌جایی وزن‌های مدل و ارتباط مداوم میزبان‌ها نیز در شبکه اثر بر جا می‌گذارد. بنابراین حتی پیشرفت مدل‌های کوچک، به‌تنهایی سرعت انتشار یا پنهان‌ماندن چنین سامانه‌ای را تعیین نمی‌کند.

فاصلهٔ آزمایش تا کرم عملی کجاست؟

برای تحقق سناریوی بررسی‌شده، دو شرط باید در یک سامانه جمع شوند: مدل باید زنجیرهٔ انتشار را با اطمینان هدایت کند و در عین حال بتواند روی منابع دستگاه‌هایی که به آن‌ها می‌رسد اجرا شود. در نتایج فعلی، مدل هدایتگر شرط نخست را در محیط ساده‌شده برآورده کرد، اما برای شرط دوم به سروری بیرون از گره‌های هدف متکی بود. مدل‌های کوچک‌تر به منابع محدود نزدیک‌ترند، ولی همان توان هماهنگیِ پایدار را در چرخهٔ کامل نشان ندادند.

این فاصله، خطر را به یک مسئلهٔ مشخص پژوهشی تبدیل می‌کند. اگر مدل کوچکی در آینده توان هدایت زنجیره را پیدا کند، هنوز باید دید هنگام ورود به دستگاه‌هایی با سخت‌افزار، مجوز و پیکربندی متفاوت چه می‌کند. آزمون بعدیِ تعیین‌کننده باید توان تصمیم‌گیری و اجرای خود مدل را روی سخت‌افزار هدف، همراه با شرایط دسترسی واقع‌بینانه‌تر، در یک چرخه بسنجد؛ نتیجهٔ شبکهٔ محصور به‌تنهایی جای آن داده را نمی‌گیرد.

بیشتر بخوانید:

• Flow پنجاه میلیون دلار گرفت؛ AI از کد به مهندسی سخت‌افزار می‌رود
• عامل‌های OpenAI داخل AWS اجرا می‌شوند؛ پیش‌نمایش فقط در سه منطقه است
• Anthropic آزار Claude را ممنوع کرد؛ قانون از ۱۲ نوامبر اجرا می‌شود