تصور کنید برنامه‌نویسی هستید که مدل خود را روی یک گوشی پرچم‌دار و متصل به شارژ تست کرده و از سرعت خیره‌کننده آن خوشحال است، اما کاربر نهایی شما با یک گوشی میان‌رده و باتری ۲۰ درصدی در حال استفاده از اپلیکیشن است. در این لحظه، تفاوت بین یک «دموی موفق» و یک «محصول شکست‌خورده» مشخص می‌شود.
به گزارش منابع فنی، اسکرین‌شات‌های ویروسی از بنچمارک‌های مدل MiniMax H3 در واقع پیش‌درآمدی برای یک حادثه در محیط تولید (Production) هستند، اگر این نتایج روی یک گوشی پرچم‌دار متصل به برق ثبت شده باشند. این مدل که به دلیل عملکرد خیره‌کننده‌اش در صدر رتبه‌بندی ویدیوهای AI قرار گرفت، در واقع پیش‌درآمدی برای یک حادثه در محیط تولید هستند. اکثر مدل‌های کوچک و باز در حالتی به نام «وضعیت پایدار» ارزیابی می‌شوند؛ یعنی صفحه‌نمایش روشن، وای‌فای پایدار و باتری کامل. اما کاربران واقعی در چنین شرایطی زندگی نمی‌کنند.
در ۱۰ اوت ۲۰۲۶، یک رویکرد متدولوژیک جدید برای تست این مدل‌ها تحت «انتقالات چرخه حیات» (Lifecycle Transitions) پیشنهاد شد. استدلال اصلی این است که برای قابلیت‌های مبتنی بر دستگاه یا رایانش لبه (Edge Computing) — شبیه به داشتن یک دستیار هوشمند که روی خودِ گوشی زندگی می‌کند و نیازی به سفر تا سرورهای دوردست ندارد — تنها اعدادی اهمیت دارند که در شرایط واقعی بازتولید شوند؛ مثلاً وقتی کاربر از آسانسور خارج می‌شود یا هنگام اجرای برنامه در پس‌زمینه، به یک پیامک پاسخ می‌دهد.
همان‌طور که در تحلیل‌های قبلی ما درباره‌ی استقرار مدل‌های کوچک روی سخت‌افزارهای محدود اشاره کردیم، شکست‌های سیستمی اغلب در نقاط کور بنچمارک‌ها پنهان می‌شوند. برای مثال، کاربری با یک گوشی اندرویدی میان‌رده و باتری ۴۰ درصد، هرگز قدرت پردازشی حداکثری یک تراشه Snapdragon 8 Gen 3 را تجربه نمی‌کند؛ او احتمالاً با یک تراشه Helio G85 و مدیریت توان تهاجمی سیستم‌عامل سر و کار دارد. در این حالت، وقتی مدلی مانند H3 در اینجا مستقر می‌شود، حالت‌های شکست از «سرعت تولید توکن چقدر است؟» به «آیا درخواست کاربر به‌طور خاموش ناپدید شد؟» تغییر می‌کند. این بهینه‌سازی‌های سخت‌افزاری یادآور تلاش‌های این مدل برای کاهش چشمگیر مصرف حافظه گرافیکی در تولید ویدیوهای 2K است تا روی سخت‌افزارهای محدودتر قابل اجرا باشد.
تجهیزات مورد نیاز برای بازتولید
برای اجرای این تست‌ها، شما به محیطی خاص نیاز دارید. دستگاه هدف باید ترجیحاً میان‌رده باشد؛ مثلاً یک Pixel 6a با اندروید ۱۴. طبق مستندات این متد، ثبت دقیق مدل دستگاه، نسخه سیستم‌عامل و نوع تراشه (SoC) در هر خط از لاگ‌ها حیاتی است، زیرا نتایج یک تراشه Snapdragon 8 Gen 3 هیچ اطلاعاتی درباره رفتار یک تراشه Helio G85 نمی‌دهد.
همچنین به یک نقطه اتصال (Endpoint) مدل نیاز دارید که بتوانید آن را در لحظه قطع کنید. این شامل استنتاج (Inference) — لحظه‌ای که مدل واقعاً جواب تولید می‌کند، شبیه به خودِ آشپزی و نه دوره‌ی آموزش آشپز — روی دستگاه (اگر بسته‌بندی شما از آن پشتیبانی کند) یا یک جایگزین میزبانی‌شده برای مقایسه است. برای بخش میزبانی، می‌توان از دسترسی رایگان مدل‌های MonkeyCode و گزینه سرور رایگان آن استفاده کرد تا یک بک‌اند استنتاج کوچک ایجاد شود که بتوان آن را بین هر اجرای تست، خاموش و روشن کرد.
در نهایت، ابزارهایی برای ایجاد تغییرات در چرخه حیات نیاز دارید در حالی که در حال اندازه‌گیری هستید. این کار مستلزم ابزارهایی برای تغییر حالت هواپیما، دستورات adb برای حالت doze و Intentهای پس‌زمینه است. استفاده از سروری که کنترلش با شماست ضروری است، زیرا APIهای مدیریت‌شده‌ای که امکان قطع کردنشان را ندارید، نمی‌توانند به شما بگویند اپلیکیشن شما هنگام مرگ بک‌اند چگونه بازیابی می‌شود.
حلقه اصلی ارزیابی
اشتباه رایج اکثر توسعه‌دهندگان، بنچمارک در وضعیت پایدار است. شکست‌هایی که کاربر را آزار می‌دهند در لحظات «انتقال» رخ می‌دهند. برای ثبت این موارد، از یک ساختار ردیابی (RunLog) استفاده می‌شود (که در اینجا با شبه‌کد کاتلین پیاده شده اما برای Flutter یا React Native نیز کاربرد دارد) که شامل موارد زیر است:
- متادیتای دستگاه: شناسه دستگاه، درصد باتری، وضعیت حرارتی و نوع شبکه (Wi-Fi، LTE یا آفلاین).
- نوع انتقال: اینکه اجرا یک درخواست استاندارد بوده، یا یک رویداد ۱۰ ثانیه‌ای در پس‌زمینه، حالت Doze یا قطع سرور.
- زمان‌بندی: تأخیر تا نخستین توکن (firstTokenMs) و زمان کل (totalMs).
- نتیجه: اینکه درخواست تکمیل شد، بازیابی شد، مجدداً شروع شد یا به‌طور خاموش گم شد.
این فرآیند شامل شروع یک پروب، تأخیر ۴۰۰ میلی‌ثانیه‌ای برای اطمینان از خروج درخواست از دستگاه و سپس اعمال انتقال (مانند فرستادن اپلیکیشن به پس‌زمینه یا تغییر وضعیت رادیو) پیش از انتظار برای نتیجه با یک سیاست بازیابی (Recovery Policy) است.
ماتریس انتقال
توسعه‌دهندگان برای عبور از بنچمارک‌های ایستا، باید از یک ماتریس انتقال استفاده کنند. این کار شامل اجرای حداقل ۲۰ تکرار برای هر سلول در محرک‌های شکست زیر است:
- پس‌زمینه ۱۰ ثانیه‌ای: از طریق Home Button Intent فعال می‌شود تا بررسی شود آیا جریان داده (Stream) از سر گرفته می‌شود یا قطع می‌گردد.
- حالت Doze / App Standby: از طریق دستور
adb shell dumpsys deviceidle force-idleفعال می‌شود تا اجرای به تعویق افتاده و رفتار بیدار شدن اپلیکیشن تست شود. - انتقال Wi-Fi به LTE: در میانه استریم از طریق تنظیمات تغییر می‌کند تا بقای سوکت و صحت تلاش مجدد (Retry) بررسی شود.
- حالت هواپیما (۵ ثانیه روشن و سپس خاموش): از طریق تنظیمات سریع تغییر می‌کند تا تشخیص آفلاین بودن و سیاست بازگشت به اتصال (Reconnect Backoff) تست شود.
- قطع سرور در میانه درخواست: از طریق اجرای دستور
kill -9روی بک‌اند (مثلاً:./serve-model --port 8080 & SERVER_PID=$!; kill -9 $SERVER_PID) برای تأیید بازیابی کلاینت و جلوگیری از بریدگی خاموش متن. - باتری زیر ۲۰٪ + فشار حرارتی: فعال کردن حالت ذخیره باتری روی دستگاه گرم برای اندازه‌گیری اثر محدودیت‌های سیستم‌عامل (Throttling) تحت فشار OS.
اندازه‌گیری نتیجه به‌جای تأخیر
بر اساس گزارش dev.to، حیاتی‌ترین معیار، ستون «نتیجه» است. توسعه‌دهندگان باید نتایج را در سه دسته قرار دهند:
۱. بازیابی‌شده (Recovered): یک تلاش مجدد شفاف یا از سرگیری که کاربر هیچ قطعی را حس نمی‌کند.
۲. شروع مجدد (Restarted): اجرای مجدد کامل یا تکرار محتوا که برای کاربر قابل مشاهده است و در صورت اطلاع‌رسانی، پذیرفتنی است.
۳. گم‌شده خاموش (Lost Silently): بدترین حالت؛ جایی که آیکون لودینگ برای همیشه می‌چرخد یا خروجی ناقص به‌عنوان خروجی کامل نمایش داده می‌شود.
اگر مدلی در آزمون MMLU نمره بالایی بگیرد اما هنگام تغییر شبکه به‌طور خاموش ناپدید شود، یک ریسک سیستمی است. هدف این است که بفهمیم آیا زمان بازیابی دووجهی (Bimodal) است یا خیر؛ یعنی برخی اجراها در گروه‌های سریع (حدود ۲ ثانیه) و برخی در گروه‌های کند (بیش از ۱۵ ثانیه) خوشه‌بندی می‌شوند که نشان‌دهنده یک سیاست بازگشت (Backoff Policy) معیوب است که منجر به بستن اجباری اپلیکیشن توسط کاربر می‌شود.
مزیت وزن‌های باز
مدل‌های کوچک با وزن‌های باز (Open Weights) — یعنی مدل‌هایی که «دستور پخت» آن‌ها علناً منتشر شده و نه فقط غذای آماده — مانند MiniMax H3 برای این تست‌ها ایده‌آل هستند، زیرا کنترل کامل روی کل پشته (Full-stack) را فراهم می‌کنند. برخلاف APIهای بسته و مدیریت‌شده، یک مدل باز را می‌توان روی دستگاه بسته‌بندی کرد یا روی سرور شخصی میزبانی کرد تا توسعه‌دهنده بتواند عمداً آن را کرش دهد. شما نمی‌توانید تست بازیابی kill -9 را روی یک نقطه اتصال اختصاصی و بسته انجام دهید؛ شکستی که شما بیشتر از همه از آن می‌ترسید، همان شکستی است که اجازه خلق کردنش را ندارید.
با استفاده از ابزارهایی مثل MonkeyCode که دسترسی به سرورهای قابل قطع را فراهم می‌کند، توسعه‌دهندگان می‌توانند دقیقاً همان شکست‌هایی را شبیه‌سازی کنند که از آن‌ها می‌ترسند. این رویکرد «خودت خرابش کن»، برای پایداری موبایل بسیار ارزشمندتر از هر جایگاهی در جدول رده‌بندی (Leaderboard) است.
این تغییر در تست‌ها، فرض بنیادی استقرار هوش مصنوعی در موبایل را عوض می‌کند و تمرکز را از «هوش مدل» به «استواری سیستم» منتقل می‌کند. نتیجه، محصولی است که نه فقط در آزمایشگاه، بلکه در هرج‌ومرج جیب کاربر زنده می‌ماند.
محدودیت‌ها و اجرا
این گزارش هشدار می‌دهد که برای بازارهای نوظهور، تست با یک دستگاه تنها یک «تست دود» (Smoke Test) است. یک ماتریس آماده تولید باید حداقل یک دستگاه با رم پایین را شامل شود تا اثرات بسته شدن اپلیکیشن به دلیل فشار حافظه (Memory-pressure kills) که در گوشی‌های پرچم‌دار رخ نمی‌دهد، سنجیده شود.
علاوه بر این، توسعه‌دهندگان نباید سیستم‌های خود را با فرض ثابت ماندن لایه‌های رایگان یا محدودیت‌های خاص سرور طراحی کنند، بلکه باید معماری را به‌گونه‌ای بسازند که بک‌اند به‌راحتی قابل تعویض باشد (Backend Swappability). اگر یک قابلیت، فراخوانی ساده، غیرجریانی و از نوع «ارسال و فراموش» (Fire-and-forget) است، این ماتریس شاید زیاده‌روی باشد، اما برای قابلیت‌هایی که گم شدن درخواست در آن‌ها آسیب کاربر-محور ایجاد می‌کند، ضروری است.
برای شروع، منطق تلاش مجدد (Retry Logic) فعلی خود را بازبینی کنید. بررسی کنید آیا اپلیکیشن شما می‌تواند تفاوت بین یک درخواست «شکست‌خورده» و یک درخواست «تکمیل‌شده» را در حین یک رویداد قطع سرور تشخیص دهد یا خیر. اگر ماتریس را اجرا می‌کنید، مهم‌ترین داده‌ای که باید ردیابی کنید، نتیجه است: بازیابی‌شده، شروع مجدد یا گم‌شده خاموش.
گام بعدی شما
- منطق Retry اپلیکیشن خود را بررسی کنید تا مطمئن شوید درخواست‌های قطع‌شده در میانه راه، به‌طور خاموش در حالت Loading نمی‌مانند.
- یک دستگاه میان‌رده (مانند سری Pixel a یا سامسونگ‌های سری A) را به چرخه تست‌های خود اضافه کنید.
- ماتریس انتقال را با تمرکز بر «تغییر شبکه» و «قطع سرور» پیاده‌سازی کنید تا نرخ «گم‌شدن خاموش» را بسنجید.
اما داستان سخت‌افزاری این تحول حتی شگفت‌انگیزتر است — به تحلیل ما درباره‌ی تراشه‌های NPU در گوشی‌های میان‌رده مراجعه کنید.
گفتگو