گلوگاه حرارتی؛ دلیل شکست عامل‌های هوش مصنوعی در سخت‌افزارهای لبه

عامل هوش مصنوعی شما در اولین دستور شکست نمی‌خورد؛ بلکه در هشتمین مرحله، درست زمانی که تراشه به سقف دمایی خود می‌رسد، از کار می‌افتد. در حالی که بنچمارک‌های صنعتی بر روی حداکثر توکن در ثانیه برای یک بار اجرا تمرکز دارند، unite.ai گزارش می‌دهد که بار کاری واقعی یک عامل — یعنی حلقه‌ای مداوم از تصمیم‌گیری، فراخوانی ابزار و مشاهده — یک مسئله محاسباتی را به یک بحران حرارتی تبدیل می‌کند.

برای سال‌ها، سلسله‌مراتب سخت‌افزاری اولویت را به حداکثر کردن توان عملیاتی داد و مدیریت حرارت را به موضوعی ثانویه تبدیل کرد. این فلسفه طراحی بر اساس بارهای کاری «انفجاری» (Burst) بود: مدل ورودی را می‌گیرد، خروجی تولید می‌کند و تراشه خنک می‌شود. اما با چرخش صنعت به سمت عامل‌های خودمختار، چرخه کاری تغییر کرده است. اکنون در استقرارهای صنعتی، مدیریت توان در اولویت اول و توان عملیاتی خام در جایگاه آخر قرار دارد. دستگاه‌های لبه با محدودیت حرارتی روبرو هستند، نه محدودیت محاسباتی، و گوشی‌های هوشمند در حال حاضر در لبه این محدودیت‌ها قرار دارند.

همان‌طور که در تحلیل‌های پیشین ما درباره‌ی بهینه‌سازی مدل‌های کوچک اشاره کردیم، انتقال مدل به لبه بدون تغییر در معماری سخت‌افزاری، تنها بخشی از مسیر است.

ماهیت حلقه عامل‌محور

یک حلقه عامل‌محور (Agentic) تا زمانی که به یک محدودیت نرم‌افزاری برسد، باز می‌ماند؛ این یعنی سخت‌افزار باید باری را تحمل کند که سیستم‌های خنک‌کننده غیرفعال (Passive Cooling) توان مدیریت آن را ندارند. این یک ادعای نظری نیست، بلکه نحوه ساخت فریم‌ورک‌هاست. در SDK عامل‌های OpenAI، اجراکننده یک «حلقه» را اجرا می‌کند. وقتی مدل فراخوانی‌های ابزار تولید می‌کند، محیط اجرا آن فراخوانی‌ها را انجام داده، نتایج را ضمیمه می‌کند و حلقه را دوباره اجرا می‌کند.

تنها چیزی که جلوی این فرآیند را می‌گیرد، محدودیت تعداد نوبت‌هاست. اگر سیستمی از max_turns فراتر رود، یک استثنا (Exception) رخ می‌دهد. مستندات حتی اشاره می‌کنند که قرار دادن max_turns=None این محدودیت را کاملاً غیرفعال می‌کند. در یک سرور، این یک تصمیم مالی است — چون در نهایت کسی متوجه صورت‌حساب می‌شود. اما در یک دستگاه لبه، این یک تصمیم حرارتی است، زیرا طول حلقه مستقیماً با چرخه کاری تراشه رابطه دارد.

دیوار حرارتی در سخت‌افزارهای پرچمدار

یک بنچمارک در مارس ۲۰۲۶، چهار پلتفرم را با استفاده از یک مدل ۱.۵ میلیارد پارامتری کوانتیده (Quantized) و یک پرامپت ثابت ۲۵۸ توکنی در ۲۰ اجرای متوالی تحلیل کرد. نتایج، شکاف عمیقی را در نحوه مدیریت بارهای کاری مداوم توسط دستگاه‌های پرچمدار نشان می‌دهد:

• iPhone 16 Pro: در ابتدا به ۴۰.۳۵ توکن در ثانیه رسید، اما در عرض دو استنتاج، دچار افت ۴۴ درصدی شد و به ۲۲.۵۶ توکن در ثانیه رسید. این دستگاه به دلیل مکانیزم DVFS (مقیاس‌بندی دینامیک ولتاژ و فرکانس) که با افزایش دما سرعت کلاک را کاهش می‌دهد، در ۶۵٪ زمان تست در حالت محدود شده باقی ماند.
• Galaxy S24 Ultra: شکست سخت‌تری را تجربه کرد. در تکرار ششم و با رسیدن دما به ۷۸.۳ درجه سانتی‌گراد، کنترل‌کننده حرارتی اندروید یک کف سخت برای فرکانس GPU اعمال کرد که باعث توقف کامل استنتاج (Inference) شد.

این تفاوت حیاتی است. در حالی که آیفون دچار «تخریب تدریجی» شد، گلکسی S24 Ultra کاملاً غیرقابل استفاده شد. این یافته‌ها تأییدی بر مقاله سال ۲۰۲۴ MobiCom با عنوان «نقطه ذوب» (MELTing point) است که نتیجه گرفت اجرای مداوم مدل‌های زبانی بزرگ بر اساس مبانی انرژی و حرارت، همچنان دست‌نیافتنی است. حتی با گذشت دو سال و تغییر گره‌های تولید تراشه، صنعت همچنان به همان دیوار برخورد می‌کند.

تلاقی شکست

حلقه‌های عامل‌محور جریمه‌ای مکانیکی ایجاد می‌کنند که پرامپت‌های تکراری ساده ندارند. رمزگشایی در مدل‌های زبانی محدود به پهنای‌باند حافظه است، به این معنی که توان عملیاتی به سرعت خواندن KV Cache (حافظه کلید-مقدار) توسط تراشه بستگی دارد، نه به عملیات تئوریک در ثانیه. هرچه یک عامل در حلقه پیش می‌رود، نتایج ابزارها، مشاهدات و برنامه‌های جزئی را به زمینه (Context) اضافه می‌کند و باعث رشد KV Cache می‌شود.

این وضعیت یک تقاطع مرگبار ایجاد می‌کند: هزینه محاسباتی هر گام با گسترش زمینه افزایش می‌یابد، درست در همان لحظه‌ای که کنترل‌کننده حرارتی دستگاه برای جلوگیری از گرم شدن بیش از حد، سرعت کلاک را پایین می‌کشد. محصول دقیقاً در نقطه‌ای می‌شکند که این دو منحنی با هم تلاقی می‌کنند — هرگز در گام اول، بلکه در اعماق اجرای وظیفه.

مقیاس هزینه‌ها

یک مشکل مقیاس عظیم در پس این تغییر نهفته است. کارهای زاینده (Generative) از نظر هزینه با تراشه‌های لبه دهه گذشته متفاوت هستند. مطالعه‌ای روی ۸۸ مدل نشان داد که طبقه‌بندی متن تقریباً ۰.۰۰۲ کیلووات ساعت برای هر هزار استنتاج هزینه دارد. در مقابل، تولید متن ۰.۰۴۷ کیلووات ساعت هزینه داشت — یعنی تقریباً ۲۰ برابر بیشتر، پیش از آنکه حلقه‌های عامل‌محور این هزینه را چندین برابر کنند.

برای درک بهتر، همین مطالعه اشاره می‌کند که یک شارژ کامل گوشی هوشمند ۰.۰۲۲ کیلووات ساعت است. اگرچه عدد ۰.۰۴۷ کیلووات ساعت روی GPUهای مرکز داده اندازه‌گیری شده، اما این نسبت، تقاضای شدید انرژی در تولید متن را نسبت به طبقه‌بندی نشان می‌دهد. این چالش در مقیاس کلان‌تر، منجر به بازنگری در نحوه توزیع منابع شده است، مشابه آنچه در بهینه‌سازی تخصیص GPUها برای افزایش بهره‌وری خوشه‌های پردازشی مشاهده کردیم.

کارایی در برابر سرعت خام

این بنچمارک برنده غیرمنتظره‌ای را در بهره‌وری انرژی معرفی می‌کند. یک NPU مدل Hailo-10H سرعت متواضعانه ۶.۹ توکن در ثانیه را ارائه داد، اما با مصرف کمتر از ۲ وات و ضریب تغییرات توان عملیاتی بسیار پایین (۰.۰۴٪) عمل کرد.

در مقابل، یک GPU لپ‌تاپ ۱۳۱.۷ توکن در ثانیه تولید کرد اما ۳۴.۱ وات مصرف نمود. وقتی معیار «انرژی به ازای هر توکن» باشد، NPU کوچک (۲۷۰.۵ میلی‌ژول) در واقع از GPU پرقدرت (۲۹۷.۳ میلی‌ژول) بهتر عمل کرد و پایداری تقریباً کاملی داشت. این نشان می‌دهد که برای عامل‌ها، پیش‌بینی‌پذیری و مقدار ژول به ازای هر وظیفه، ارزشمندتر از حداکثر توکن در ثانیه است. بنچمارکی که فقط توان عملیاتی پیک را گزارش می‌کند، در واقع فقط درباره اولین استنتاج روز به شما خبر می‌دهد.

بازتعریف پشته هوش مصنوعی لبه

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

به جای آن، توسعه‌دهندگان باید «پوشش حرارتی» (Thermal Envelope) را به عنوان یک ضرب‌الاجل سخت در نظر بگیرند. این یعنی تعیین محدودیت max_turns در مشخصات محصول بر اساس ظرفیت گرمایی دستگاه، نه کشف آن در لحظه کرش کردن برنامه. این رویکرد دقیقاً مشابه تغییر پارادایم در تیم‌های توسعه است که در آن حاکمیت داده‌ها بر سرعت صرف کدنویسی اولویت یافت تا پایداری سیستم در بلندمدت تضمین شود.

علاوه بر این، وضعیت سخت‌افزاری باید بخشی از زمینه (Context) خود عامل باشد. اگر یک عامل بداند در گام هشتم از یک بودجه حرارتی ۱۰ گامی است، یا باتری کم است و محدودیت حرارتی آغاز شده، می‌تواند تصمیم بگیرد یافته‌های خود را خلاصه کرده و به پاسخ نهایی متعهد شود، به جای اینکه تا زمان بسته شدن فرآیند توسط سیستم‌عامل، به جست‌وجو ادامه دهد. این اطلاعات — فضای خالی باقی‌مانده و وضعیت باتری — درست مانند زمان فعلی، باید در زمینه مدل قرار گیرند.

تست‌ها نیز باید از میانگین عملکرد فاصله بگیرند. چون مورد شکست همیشه در «اجراهای طولانی» رخ می‌دهد — جایی که یک ابزار در گام سوم نتیجه‌ای مبهم برمی‌گرداند و تکرارهای اضافی را تحمیل می‌کند — شبیه‌سازی تنها راه قابل اعتماد برای تست انتهای طیف عملکرد سخت‌افزار است. شما نمی‌توانید این شکست‌ها را به صورت دستی روی گوشی‌ای تست کنید که بین هر تلاش نیاز به خنک شدن دارد.

هیچ‌کدام از این‌ها نیازمند تراشه‌ای سریع‌تر نیست؛ بلکه نیازمند پذیرش این واقعیت است که شکل بار کاری تغییر کرده است. هیچ‌کس دستگاهی را نمی‌سازد که باتری‌اش فقط برای یک عکس اندازه شده باشد؛ پس باید از عرضه دستگاه‌هایی که بودجه حرارتی‌شان فقط برای یک استنتاج طراحی شده، دست برداریم.

گام بعدی شما

• در پیاده‌سازی عامل‌های لبه، مقدار max_turns را بر اساس تست‌های استرس حرارتی دستگاه هدف تنظیم کنید، نه بر اساس منطق نرم‌افزاری.
• وضعیت باتری و دمای دستگاه را به عنوان متغیرهای محیطی (Environmental Variables) به پرامپت سیستمی عامل اضافه کنید تا مدل بتواند استراتژی خروجی خود را با محدودیت سخت‌افزاری تطبیق دهد.
• برای ارزیابی مدل‌های لبه، به جای «میانگین توکن در ثانیه»، روی «پایداری توان عملیاتی در ۱۰ تکرار متوالی» تمرکز کنید.

اما داستان سخت‌افزاری این تحول حتی شگفت‌انگیزتر است — به تحلیل ما درباره‌ی تراشه‌های Blackwell و مدیریت توان در مقیاس مرکز داده مراجعه کنید.