علیبابا در تاریخ ۳ اوت Qwen3.8-Max را عرضه کرد. این یک مدل Mixture-of-experts است که تا ۲.۴ تریلیون پارامتر مقیاسپذیر است، اما در زمان استنتاج (inference) تنها ۹۵ میلیارد پارامتر آن فعال میشود. این مدل تصاویر و متن را از طریق درگاه QwenCloud میپذیرد و علیبابا اعلام کرده است که وزنهای مدل هفته آینده بهصورت عمومی در دسترس خواهند بود.
این تیتر پرزرقوبرق، سوال دشوارتری را پنهان میکند: آیا عامل (agent) این مدل میتواند زمانی که ابزارهای مورد اتکای آن دچار مشکل میشوند، با اطمینان کدنویسی کند؟ دموهای فروشنده یک دوره ده روزه کدنویسی کاملاً خودکار را نشان میدهند که یک پروژه را از صفر ساخته است، اما آن اجراها روی زیرساخت خود علیبابا و با مجوزهای ایدهآل انجام شده بودند. توسعهدهندگان در دنیای واقعی نیاز دارند بدانند سیستم زمانی که با محدودیتهای توکن، شکست در فراخوانی ابزارها یا محدودیت دسترسی نوشتن مواجه میشود، چگونه رفتار میکند.
چرا این هیجان اهمیت دارد
طراحیهای Mixture-of-experts اجازه میدهند تا یک مجموعه عظیم از پارامترها تا زمانی که یک «متخصص» خاص فراخوانی نشود، غیرفعال باقی بمانند؛ این امر باعث میشود هزینههای استنتاج کمتر از یک مدل متراکم (dense) با همان اندازه باشد. ورودی چندوجهی (multimodal) نیز موارد استفاده را فراتر از تولید کد ساده گسترش میدهد و به توسعهدهندگان اجازه میدهد نمودارها یا اسکرینشاتها را در همان پرامپت وارد کنند.
اما این وعده به لایه عامل (agent layer) بستگی دارد که ویرایشگرهای فایل، کامپایلرها، اجراکنندههای تست و دستورات کنترل نسخه را هماهنگ میکند. اگر این لایه نتواند از یک فراخوانی ناموفق ابزار بازیابی شود، کل جلسه کدنویسی از هم میپاشد.
قطعه گمشده: تنظیمکننده میزان تلاش برای استدلال
Qwen3.8-Max با سه تنظیم پیشفرض برای «میزان تلاش برای استدلال» (reasoning effort) عرضه میشود: low، medium و xhigh. این تنظیمات سرعت را با کیفیت پاسخ و بهطور حیاتی، با تعداد توکنهایی که مدل تولید میکند، معاوضه میکنند.
یک برنامه تست تکرارپذیر
برای عبور از ادعاهای بازاریابی، پروتکل عملی زیر را با یک بودجه توکن ثابت امتحان کنید:
- یک مخزن (repository) تازه ایجاد کنید که دارای یک ساختار سادهی "hello world" به هر زبانی باشد.
- به عامل (agent) دستور دهید تا ویژگی جدیدی (مثلاً یک REST endpoint) اضافه کند و هر برنامهای که خروجی میدهد، هر فراخوانی ابزاری که انجام میدهد و هر فایلی که تغییر میدهد را ثبت کنید.
- در اولین خطا متوقف شوید — برای مثال، زمانی که یک خطای کامپایل ظاهر میشود — وضعیت داخلی مدل را ذخیره کرده و سپس از همان نقطه بازگشت (checkpoint) ادامه دهید.
- اجرا را تکرار کنید تحت هر تنظیم میزان تلاش برای استدلال، و تعداد کل توکنها، زمان واقعی (wall-clock time) و هرگونه خطای سطح ابزار را یادداشت کنید.
- دسترسیها را محدود کنید در یک مرحله (دسترسی فقط خواندنی/read-only) و در مرحلهای دیگر دسترسی کامل نوشتن را بدهید تا ببینید عامل چگونه خود را تطبیق میدهد.
- تلاشهای مجدد را ثبت کنید: مدل چند وقت یکبار یک ابزارِ بیثبات را دوباره فراخوانی میکند در مقابل اینکه عملیات را متوقف کند؟
جمعآوری این معیارها به شما اجازه میدهد خروجی خام کدنویسی را با هزینه پنهان مدیریت خطا مقایسه کنید. اگر عامل بهطور مکرر یک linterِ بیثبات را دوباره امتحان کند، صورتحساب توکنها به شدت افزایش مییابد، حتی اگر کد نهایی درست به نظر برسد.
آنچه اعداد پنهان میکنند
رقم ۹۵ میلیارد پارامتر فعال مستقیماً به یک مبلغ دلاری تبدیل نمیشود. فراخوانیهای ابزاری که خطا برمیگردانند، مدل را مجبور به تولید پرامپتهای اصلاحی میکنند که باعث تورم مصرف توکن میشود. بدون داشتن وضعیت پایدار (durable state) — یعنی چکپوینتهای دورهای که به شما اجازه میدهند پس از یک کرش ادامه دهید — هزینه یک شکست واحد میتواند به صورت زنجیرهای افزایش یابد.
هشدار در مورد وزنهای باز (Open-weights)
وعده علیبابا برای انتشار وزنها در هفته آینده، امکان استقرار در محل (on-prem) را فراهم میکند، اما دو مانع عملی همچنان باقی است. اول، لایسنس ممکن است استفاده تجاری را محدود کند یا نیاز به ذکر منبع داشته باشد؛ توسعهدهندگان باید قبل از ادغام مدل در یک محصول، آن را مطالعه کنند. دوم، اجرای یک سیستم Mixture-of-experts با ۲.۴ تریلیون پارامتر همچنان نیازمند GPUهای ردهبالا یا شتابدهندههای تخصصی است. کاربران اولیه باید ادعاهای «استقرار محلی» را تا زمانی که الزامات سختافزاری و ارقام عملکرد واقعی تأیید شوند، موقتی تلقی کنند.
استدلال متقابل: دیدگاه فروشنده
تستهای داخلی علیبابا نشان میدهد که مدل یک ماراتن کدنویسی خودکار ده روزه را با موفقیت پشت سر گذاشته و مدیریت مسائل (issue triage)، تولید کد و اجرای تست را بدون دخالت انسان انجام داده است. آن نتایج چیزی را نشان میدهند که تیم میخواهد شما ببینید، اما آنها قابلیت اطمینان در تستهای دنیای واقعی را ثابت نمیکنند.
آنچه در آینده باید زیر نظر داشت
- نهایی شدن لایسنس: شرایط دقیق انتشار وزنهای باز تعیین خواهد کرد که آیا استارتاپها میتوانند محصولاتی مبتنی بر Qwen3.8-Max عرضه کنند یا باید از API میزبانیشده استفاده کنند.
- در دسترس بودن سختافزار: اگر ارائهدهندگان ابری شروع به ارائه نمونههای پیشتنظیمشده برای مدلهای Mixture-of-experts کنند، مانع تست در محل (on-prem) به شدت کاهش خواهد یافت.
نتیجهگیری
اندازه چشمگیر و قابلیتهای چندوجهی خیرهکننده Qwen3.8-Max تنها نیمی از ماجرا هستند؛ معیار واقعی برای توسعهدهندگان این است که چارچوب مدیریت عامل (agent harness) آن چگونه شکستهای ابزار، بودجه توکنها و محدودیتهای دسترسی را مدیریت میکند. یک آزمون منضبط و تکرارپذیر — با تغییر میزان تلاش استدلالی و سطح دسترسیها — مشخص خواهد کرد که آیا این مدل به وعدههای بازاریابی خود عمل میکند یا صرفاً لایه پرهزینه دیگری به خط لوله کدنویسی میافزاید.