نکات کلیدی

• برای سازمان‌هایی که از فناوری‌های AI/ML استفاده می‌کنند، حیاتی است که ردپای کربنی چرخه عمر ML را به‌صورت سیستماتیک رصد کنند و بهترین روش‌ها را در مرحله توسعه مدل و استقرار اجرا کنند.
• ردیابی نیازهای انرژی با چالش‌هایی مثل نبود روش‌های استاندارد برای محاسبه مصرف انرژی و پیچیدگی اندازه‌گیری دقیق ردپای کربنی AI همراه است.
• انتشارها را می‌توان به دو نوع تقسیم کرد: انتشارهای عملیاتی که به هزینه انرژی اجرای آموزش مدل‌ها و استنتاج (inference) و هزینه پشتیبانی سخت‌افزار ML اشاره دارد؛ و انتشارهای چرخه‌عمر که شامل کربن نهفته در فرایند ساخت همه اجزای درگیر، از چیپ‌ها تا ساختمان‌های دیتاسنتر، و همچنین انتشارهای عملیاتی است.
• بهترین روش‌ها برای ساخت یک چرخه عمر ML پایدار شامل اولویت دادن به انتخاب مدل‌های کارآمد، بهینه‌سازی مدل برای کاهش پیچیدگی، انتخاب سخت‌افزار مناسب (CPU، GPU و NPU)، و تصمیم‌گیری بین میزبانی ابری در برابر زیرساخت آن‌پرمیس است.

ابزارهای متن‌باز مثل CodeCarbon و MLCarbon برای ردیابی و کاهش مصرف انرژی وجود دارند. پلتفرم‌های ابری مثل Google Cloud Platform (GCP) و Amazon Web Services (AWS) هم با ابزارهایی که ردپای کربنی را کم می‌کنند، به پایداری بارهای کاری AI کمک می‌کنند.

مقدمه

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

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

با این حال، ردیابی نیازهای انرژی ساده نیست، چون چند چالش جدی دارد:

• نبود آگاهی کافی درباره ردپای کربنی در سیستم‌های AI

• نبود روش‌های استاندارد برای محاسبه مصرف انرژی

• اندازه‌گیری دقیق ردپای کربنی AI پیچیده است و مقایسه مدل‌ها و پیگیری پیشرفت را سخت می‌کند

• در «عملکرد در برابر بهره‌وری انرژی»، بهره‌وری انرژی همیشه یک تریدآف است

• حرکت به سمت منابع انرژی سبز و کارآمد، با محدودیت‌های جغرافیایی و فنی کند می‌شود

• KPIهای اصلی در توسعه نرم‌افزار معمولاً عملکرد و هزینه هستند، نه انرژی

• مدل‌های زبانی بزرگ (LLMها) در چند سال اخیر هم پیچیده‌تر شده‌اند و هم رشد نمایی در اندازه داشته‌اند

معماری‌های مبتنی بر ترنسفورمر و معماری‌های Mixture of Experts (MoE) رشد اندازه مدل‌ها را به‌شدت شتاب داده‌اند. تا سال ۲۰۲۲، مدل‌های زبانی بزرگی مثل GPT-3 به پیشرفت‌های مهمی رسیدند و از ۱۷۵ میلیارد پارامتر پشتیبانی کردند. بعد از ۲۰۲۲ هم این رشد شتاب گرفت و مدل‌هایی مثل GPT-4 با معماری‌های بزرگ‌تر مطرح شدند. این روند با مدل‌های جدیدتر ادامه دارد.

شکل بالا نشان می‌دهد که مدل‌های AI فقط در بازه سه تا چهار سال چقدر از نظر اندازه و پیچیدگی رشد کرده‌اند. حالا رشد اندازه چند مدل را به‌صورت پیوسته در جدول ۱ می‌بینیم.

جدول ۱: مدل و تعداد پارامترها

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

اگر کمی عمیق‌تر به خود مدل نگاه کنیم، درک دو مفهوم Floating Point Operations (FLOPS) و Parameters کمک می‌کند رابطه بین اندازه مدل و میزان محاسبات موردنیاز را بهتر بفهمیم. FLOPS میزان پیچیدگی محاسباتی مدل را نشان می‌دهد، و پارامترها اندازه و ظرفیت مدل را بیان می‌کنند. هرچه مدل‌ها عظیم‌تر می‌شوند، معمولاً FLOPs و تعداد پارامترها بالا می‌رود و نتیجه‌اش هم دقت بیشتر و هم مصرف انرژی بیشتر در آموزش و استنتاج است. این دقیقاً همان جایی است که اهمیت ایجاد توازن بین عملکرد و کارایی یادآوری می‌شود.

پژوهشگران در حال بررسی روش‌هایی هستند که مدل‌های کارآمدتری بسازند که با پارامترهای کمتر، عملکرد مشابه یا بهتر بدهند؛ با تکنیک‌هایی مثل فشرده‌سازی مدل (model compression)، تقطیر دانش (knowledge distillation) و توسعه معماری‌های پیشرفته‌تر که بتوانند با تعداد پارامتر کمتر، بهره‌وری بیشتری داشته باشند.

ردپای کربنی چرخه عمر ML

مراحل چرخه عمر ML شامل پردازش داده، آموزش (training)، و استنتاج (inference) است. پردازش داده کارهایی مثل جمع‌آوری داده و مهندسی ویژگی را شامل می‌شود که از نظر محاسباتی معمولاً سبک‌تر از آموزش و استنتاج هستند. آموزش شامل محاسبات سنگین برای ساخت مدل‌های دقیق است، سپس مدل‌ها مستقر می‌شوند و برای استنتاج در کاربردهای متعدد بارها و بارها استفاده می‌شوند. بعضی مدل‌ها به‌صورت ۲۴ ساعته و ۷ روز هفته اجرا می‌شوند که باعث می‌شود تقاضای کلی انرژی بالا برود. خیلی‌ها فکر می‌کنند چون آموزش به داده و منابع عظیم نیاز دارد، پس آموزش از استنتاج انرژی‌برتر است، اما این درست نیست.

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

انتشارها در ارتباط با آموزش ML را می‌توان به دو نوع تقسیم کرد:

1. انتشارهای عملیاتی به هزینه انرژی اجرای آموزش و استنتاج اشاره دارد، و همچنین هزینه پشتیبانی سخت‌افزار ML، از جمله سربارهای دیتاسنتر مثل خنک‌سازی.
2. انتشارهای چرخه‌عمر شامل کربن نهفته‌ای است که طی ساخت همه اجزای درگیر منتشر می‌شود، از چیپ‌ها تا ساختمان‌های دیتاسنتر، و همچنین انتشارهای عملیاتی را هم در بر می‌گیرد. این انتشارها یک مشکل بزرگ ایجاد می‌کنند که حل کردنش خیلی سخت است.

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

چطور ردپای کربنی کدتان را اندازه‌گیری کنید

چند ابزار و فریم‌ورک با ویژگی‌ها و کاربردهای متفاوت برای اندازه‌گیری ردپای کربنی مدل‌های ML وجود دارد. در این مقاله، به دو فریم‌ورک زیر می‌پردازیم:

• CodeCarbon

• MLCarbon

CodeCarbon یک کتابخانه متن‌باز و سبکِ پایتون است که انتشارها را در طول آموزش مدل‌های ML تخمین می‌زند. انرژی مصرف‌شده توسط ماشین‌های محلی و محیط‌های ابری را ردیابی می‌کند. امکان یکپارچه‌سازی با فریم‌ورک‌هایی مثل PyTorch، Keras و Scikit-learn را دارد. CodeCarbon اجازه می‌دهد چند اجرای آموزشی را دنبال کنید، اندازه‌های مختلف مدل را با هم مقایسه کنید، و انتشارهای GPU در برابر CPU را در مناطق مختلف مانیتور کنید.

این ابزار را می‌توان با دستور زیر نصب کرد. دستورالعمل‌های راه‌اندازی هم در مخزن GitHub CodeCarbon آمده است:

بیایید مثالی ببینیم که چطور تغییر اندازه دیتاست و پیچیدگی مدل، روی انتشارها اثر می‌گذارد.

من سه طبقه‌بند Random Forest با پیچیدگی‌های متفاوت را با scikit-learn آموزش دادم و انتشارهای کربنی آن‌ها را با CodeCarbon اندازه‌گیری کردم. آزمایش‌ها روی پردازنده Apple M1 Pro با ۱۰ هسته CPU انجام شد. برای شبیه‌سازی بارهای محاسباتی مختلف، سه سناریو با پیچیدگی رو به افزایش ساختم. هر مدل با RandomForestClassifier در scikit-learn آموزش داده شد و مقدار n_estimators (تعداد درخت‌ها) و اندازه دیتاست متفاوت بود. انتشارها با EmissionsTracker در CodeCarbon ردیابی شد که مصرف انرژی حین آموزش را اندازه‌گیری و به CO2 معادل تبدیل کرد. نتایج در جدول ۲ و شکل ۲ آمده‌اند و کد هم به‌عنوان یک اسکریپت نوت‌بوکی در GitHub موجود است.

CodeCarbon یک لاگر داخلی دارد که برای هر اجرا داده‌ها را در فایل CSV با نام emissions.csv در مسیر ریشه پروژه ذخیره می‌کند. با این حال، خروجی‌ها را می‌توان به یک پلتفرم مانیتورینگ مثل Prometheus و یک پلتفرم مشاهده‌پذیری مثل LogFire هم فرستاد تا ردیابی بهتر شود.

جدول ۲: پیچیدگی مدل در برابر عملکرد و انتشارها برای پیکربندی‌های RF

• یک Random Forest ساده با ۱۰۰ درخت که روی ۱۰ هزار نمونه آموزش دید، مقدار بسیار ناچیز ۰.۰۰۰۰۰۲ kg CO2eq منتشر کرد و زمان اجرای کوتاه ۱.۵۳ ثانیه داشت و دقت ۸۵.۱% ارائه داد.

• یک RF متوسط با ۵۰۰ درخت که روی ۵۰ هزار نمونه آموزش دید، ۰.۰۰۰۱۰۳ kg CO2eq منتشر کرد و زمان اجرای طولانی‌تر ۷۴.۲۹ ثانیه داشت و دقت ۹۲.۹۵% ارائه داد. اینجا افزایش انتشارها که با تقاضای محاسباتی بیشتر همبستگی دارد، واضح‌تر می‌شود.

• یک Random Forest پیچیده با ۱۰۰۰ درخت که روی ۱۰۰ هزار نمونه آموزش دید، ۰.۰۰۰۶۳۷ kg CO2eq منتشر کرد و زمان اجرای ۵۶۶.۹۹ ثانیه داشت و دقت ۹۶% ارائه داد. این نشان‌دهنده هزینه محاسباتی بالاتر است چون هم اندازه نمونه بزرگ‌تر شده و هم تعداد درخت‌ها زیادتر، و هر دو به افزایش انتشارها کمک کرده‌اند.

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

مشکلات رایج و راه‌حل‌ها

راه‌اندازی کلی ساده است، اما داشتن یک رویکرد ساختاریافته، بینش‌های قابل اقدام برای بهینه‌سازی اثرات زیست‌محیطی در گردش‌کارهای ML می‌دهد. هنگام راه‌اندازی و اجرای codecarbon، چند مشکل رایج که ممکن است ببینید:

• “Another instance of codecarbon running”: این خطای فایل قفل (lock file) را می‌توان با پاک‌سازی خودکار حل کرد. قبل از شروع از cleanup_tracker() استفاده کنید تا محیط ردیابی تمیز شود و بین اجراها پاک‌سازی انجام شود.

• “No emissions data recorded”: این خطا به خاطر بار محاسباتی ناکافی است. مطمئن شوید بارهای ML قابل اندازه‌گیری هستند و حداقل زمان پیشنهادی آموزش بیشتر از ۵ دقیقه باشد.

• گاهی زمان انتظار برای دیدن داده‌های انتشار طولانی است چون رفتار پیش‌فرض tracker این است که داده‌ها را وقتی stop می‌شود در فایل می‌نویسد. اما برای اجراهای طولانی‌تر می‌توانید با فراخوانی flush() داده‌های میانی را هم ذخیره کنید.

CodeCarbon انتشارهای عملیاتی را در طول اجرای کد به‌خوبی ردیابی می‌کند، از جمله انرژی مصرفی CPU، GPU و RAM، و برای مدل‌های ML کوچک‌تر خوب جواب می‌دهد. اما در حال حاضر برای ردیابی انتشارهای LLMهای بزرگ در مقیاس بالا مناسب نیست. برای مدل‌های dense یا MoE یا LLMها قابل توسعه نیست چون پارامترهای معماری حیاتی مدل را نادیده می‌گیرد.

MLCarbon یک ابزار متن‌باز مدل‌سازی ردپای کربنی است که پارامترهای معماری را در نظر می‌گیرد و برای LLMها جامع‌ترین فریم‌ورک محسوب می‌شود. این ابزار مراحل سرتاسری چرخه عمر LLM را پوشش می‌دهد: آموزش، استنتاج، آزمایش‌گری (experimentation) و ذخیره‌سازی. همچنین هم انتشارهای عملیاتی (مصرف انرژی حین اجرا) و هم انتشارهای نهفته/جسمانی (از تولید سخت‌افزار و زیرساخت) را لحاظ می‌کند.

حالا بررسی می‌کنیم MLCarbon چطور با یک مثال استفاده می‌شود و بعد درباره نتایج کلیدی صحبت می‌کنیم.

مثال برای MLCarbon

سناریوی نمونه:

فرض کنید یک مهندس ML یا دیتا ساینس در مراحل اولیه طراحی یک مدل زبانی بزرگ جدید برای خلاصه‌سازی متن است. او دارد بین دو اندازه مدل تصمیم می‌گیرد: یکی با حدود ۳۰ میلیارد پارامتر و یکی بزرگ‌تر و محاسبات‌محورتر با حدود ۱۰۰ میلیارد پارامتر. قرار است این مدل‌ها را روی یک کورپوس بزرگ متنی آموزش دهد و به یک پلتفرم محاسبات ابری دسترسی دارد که GPUهای NVIDIA A100 را در دیتاسنتری با PUE برابر ۱.۱۵ و شدت کربنی تخمینی ۰.۳۵ tCO2eq/MWh ارائه می‌دهد. او برای مدل کوچک‌تر ۳۰ روز و برای مدل بزرگ‌تر ۶۰ روز زمان آموزش پیش‌بینی می‌کند و قرار است تعداد مشخصی GPU استفاده کند.

برای این‌که قبل از شروع آموزش، MLCarbon بتواند ردپای کربنی عملیاتی را تخمین بزند، مهندس باید اطلاعات زیر را جمع کند. کافی است ریپو GitHub را کلون کند، فایل database.csv را با اطلاعات مرتبط به‌روزرسانی کند و اسکریپت llmcarbon_tutorial.py را اجرا کند تا داده‌های انتشار تولید شوند.

پارامترهای فایل database.csv شامل موارد زیر هستند:

• معماری LLM: مبتنی بر ترنسفورمر (هرچند MLCarbon شاید ورودی مستقیم تعداد پارامتر هم اجازه دهد)

• تعداد پارامتر: ۳۰ میلیارد (سناریوی اول) و ۱۰۰ میلیارد (سناریوی دوم)

• اندازه دیتاست آموزشی (بر حسب توکن): یک تخمین بر اساس کورپوس

• پیکربندی سخت‌افزار: GPUهای NVIDIA A100 و تعداد GPU برنامه‌ریزی‌شده برای هر اندازه مدل

• مدت آموزش: ۳۰ روز برای مدل 30B و ۶۰ روز برای مدل 100B

• مشخصات دیتاسنتر: PUE برابر ۱.۱۵ و شدت کربنی ۰.۳۵ tCO2eq/MWh

برای مدل dense مربوط به GPT3، مقادیر این‌طور هستند:

GPT3,dense,175,,300,0.429,1.1,V100,300,330,125,24.6,0.197,10000,314,14.8,552.1,1287

جدول ۳ زیر یک تفکیک روشن و خلاصه از کلیدها و توضیحشان ارائه می‌دهد.

جدول ۳: کلیدهای پیکربندی مدل در فایل database

سپس MLCarbon از مدل‌های داخلی‌اش (مدل FLOP، مدل بهره‌وری سخت‌افزار، و مدل کربن عملیاتی) استفاده می‌کند تا مصرف انرژی (بر حسب MWh) و انتشار کربن عملیاتی (بر حسب tCO2eq) را برای هر دو پیکربندی مدل تخمین بزند. جمع‌آوری و ذخیره این اطلاعات باید خودکار شود تا مهندسان به‌راحتی به این داده‌ها دسترسی داشته باشند و قبل از آموزش یا استنتاج، بینش بگیرند. چون اگر مهندسان مجبور شوند برای جمع‌آوری این داده‌ها کار دستی زیاد انجام دهند، روند اندازه‌گیری ردپای کربنی عملاً بهتر نخواهد شد.

نتایج مقدار delta را نشان می‌دهد: (predicted_value / actual_value) – 1. مقادیر منفی یعنی کم‌برآوردی انتشارها، مقادیر مثبت یعنی بیش‌برآوردی، و هرچه به ۰ نزدیک‌تر باشد یعنی دقت بهتر است. برای GPT-3، نتیجه ۰.۰۰۲۲۵ است که بهترین عملکرد را با کمترین خطا نشان می‌دهد.

در حالی که ابزارهایی مثل CodeCarbon برای تحلیل پسینی (post hoc) اثرات زیست‌محیطی در ML ارزشمندتر هستند، ابزارهایی مثل MLCarbon شکاف ارزیابی پیش‌دستانه (preemptive) اثرات زیست‌محیطی را در مرحله انتخاب مدل پر می‌کنند؛ چون اجازه می‌دهند مهندسان قبل از توسعه مدل و آموزش پرهزینه، ردپای کربنی معماری‌ها و پیکربندی‌های سخت‌افزار مختلف را تخمین بزنند. اما حتی با این قابلیت‌های پیش‌بینی، باز هم می‌شود با برنامه‌ریزی فعالانه برای انتخاب و بهینه‌سازی مدل و استفاده از منابع ابری کم‌مصرف، انتشارها را بیشتر کاهش داد و پایداری را بالاتر برد.

بهترین روش‌ها برای ساخت چرخه عمر ML پایدار

برای کاهش بیشتر انتشارها و افزایش پایداری در یادگیری ماشین، یک رویکرد جامع لازم است که انتخاب سنجیده مدل، بهینه‌سازی مداوم مدل، و استفاده راهبردی از محاسبات ابری کم‌مصرف را با هم ترکیب کند. متخصصان AI/ML باید راهبردهای زیر را برای کاهش انتشارهای عملیاتی و ساخت سیستم‌های ML پایدار بشناسند.

۱. اولویت دادن به انتخاب مدل‌های کارآمد

انتخاب معماری اولیه مدل، اثر بزرگی روی مصرف انرژی و انتشار کربن دارد. همان‌طور که در مقاله «The Carbon Footprint of Machine Learning Training Will Plateau, Then Shrink» آمده، انتخاب معماری‌های کارآمدتر مثل مدل‌های sparse به‌جای dense می‌تواند کاهش محاسباتی حدود ۵ تا ۱۰ برابر ایجاد کند.

قبل از انتخاب یک LLM متن‌باز یا بسته، مهندسان باید این سؤال را جدی بپرسند: آیا این مسئله با مدلی کم‌محاسبه‌تر یا کم‌منبع‌تر هم قابل حل است؟ مثلاً استفاده از Distil BERT به‌جای BERT و استفاده از GPT-3.5/4 Turbo به‌جای GPT-3/4. Distil BERT نسخه فشرده BERT است و ۹۷٪ عملکرد را با ۴۰٪ پارامتر کمتر و ۶۰٪ زمان استنتاج سریع‌تر حفظ می‌کند، بنابراین انرژی‌کارآمدتر است. مدل‌های Turbo هم برای هر استنتاج منابع کمتری مصرف می‌کنند، مقرون‌به‌صرفه هستند و برای کارهای پرحجم که بهره‌وری حیاتی است مناسب‌اند.

۲. بهینه‌سازی مدل برای کاهش پیچیدگی

کم کردن محاسبات لازم برای یک مدل در حالی که عملکرد حفظ شود، چالش بزرگی است. تکنیک‌های بهینه‌سازی و مزایایشان در جدول ۴ آمده است.

پس، ساخت مدل‌های task-specific را در نظر بگیرید. این مدل‌ها به‌جای عمومی بودن، روی یک حوزه یا کاربرد مشخص تمرکز می‌کنند. همین دانش دامنه باعث می‌شود بسیار کارآمد باشند و برای کاهش تأخیر و هزینه محاسباتی کلی عالی‌اند.

استفاده از مدل‌های کم‌محاسبه، مثل Small Language Models (SLMs) هم یک راهبرد دیگر است که مصرف منابع را کم می‌کند، در حالی که برای وظایف مشخص عملکرد را نگه می‌دارد. این رویکرد مخصوصاً برای محیط‌هایی با توان محاسباتی محدود مثل دستگاه‌های edge مفید است. SLMها شبیه زیرمجموعه‌هایی از مدل‌های زبانی مبتنی بر ترنسفورمر هستند اما با پارامترهای خیلی کمتر. چون پارامتر کمتر دارند، معمولاً داده آموزشی کمتر و منابع محاسباتی کمتری می‌خواهند، زمان آموزش و هزینه را کم می‌کنند. برای محیط‌های محدود مثل edge مناسب‌اند و در عین حال می‌توانند چند وظیفه درون همان دامنه را پوشش دهند.

تکنیک‌های دیگر مثل fine-tuning و pruning هم می‌توانند بدون قربانی کردن عملکرد، مدل را کارآمدتر کنند. fine-tuning یعنی تنظیم مدل‌های از پیش آموزش‌دیده برای وظایف مشخص، که عملکرد را بهتر می‌کند و نیاز به آموزش از صفر را کم می‌کند. حتی بعد از فشرده‌سازی و pruning هم می‌تواند دقت و پایداری را برگرداند.

Pruning پارامترها و اتصال‌های کم‌اهمیت را حذف می‌کند، اندازه مدل و هزینه محاسباتی را پایین می‌آورد و سرعت استنتاج را بهتر می‌کند. اگر درست انجام شود، می‌تواند بدون افت محسوس دقت، کارایی را حفظ یا حتی بهتر کند. مثلاً یک مدل prune شده ممکن است ۹۰٪ دقت اصلی را با فقط ۱۰٪ پارامترهای اصلی حفظ کند. اما تریدآف مهم این است که تعادل درست بین کاهش اندازه و حفظ عملکرد پیدا شود. گاهی بعد از pruning لازم است fine-tuning انجام شود تا بخشی از دقت از دست رفته برگردد.

Quantization هم تکنیکی است که بار محاسباتی و مصرف انرژی را کم می‌کند. با کاهش دقت وزن‌های مدل، بدون این‌که عملکرد خیلی ضربه بخورد، محاسبات کمتر می‌شود.

جدول ۴: تکنیک‌های بهینه‌سازی و مزایای انرژی

۳. انتخاب سخت‌افزار کارآمد

انتخاب سخت‌افزار کم‌مصرف مثل TPUها یا GPUهای بهینه‌شده برای بارهای کاری یادگیری عمیق، نسبت به CPUها می‌تواند مصرف انرژی را بدون افت عملکرد کاهش دهد. جدول زیر انواع سخت‌افزار (CPU، GPU و NPU) را برای بارهای کاری AI مقایسه می‌کند و روی نقش، شیوه پردازش، سطح عملکرد و مصرف انرژی تمرکز دارد. این مقایسه نشان می‌دهد انتخاب سخت‌افزار درست، برای ایجاد تعادل بین عملکرد و انرژی چقدر مهم است و به اهداف پایداری کمک می‌کند. توجه کنید که از نظر مصرف انرژی، هرچند GPUها مصرف کلی بالایی دارند، اما برای برخی بارهای AI مثل آموزش، از CPUها انرژی‌کارآمدتر هستند. برای مقایسه سریع به جدول ۵ مراجعه کنید.

جدول ۵: نوع سخت‌افزار و بهره‌وری

۴. آن‌پرمیس در برابر ابر (On-Premise Vs. Cloud)

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

پلتفرم‌های ابری مثل GCP و AWS با ارائه ابزارهایی برای کم کردن ردپای کربنی، پایداری بارهای کاری AI را ممکن می‌کنند. GCP اجازه می‌دهد کاربران مناطق کم‌کربن را بر اساس معیارهایی مثل درصد CFE و شدت کربن شبکه انتخاب کنند و مناطقی مثل Montréal و Finland به نزدیک ۱۰۰٪ CFE می‌رسند. AWS با بهینه‌سازی زیرساخت، حرکت به سمت انرژی تجدیدپذیر و استفاده از چیپ‌های اختصاصی (purpose-built silicon)، ردپای کربنی بارهای AI را کاهش می‌دهد و تا ۹۹٪ کاهش کربن نسبت به راه‌حل‌های آن‌پرمیس گزارش کرده است. هر دو پلتفرم به سازمان‌ها کمک می‌کنند عملیات AI را با اهداف پایداری همسو کنند. با این حال، بسیاری از مهندسان و سازمان‌ها هنگام انتخاب region، معیارهای CFE یا PUE را نادیده می‌گیرند. شاخص‌های پایداری مثل CFE معمولاً در لحظه انتخاب region در اولویت ذهن کاربر نیست؛ اغلب اول عملکرد، هزینه و KPIهای کسب‌وکار دیده می‌شود.

مقاله گوگل با عنوان «The Carbon Footprint of Machine Learning Training Will Plateau, Then Shrink» نشان می‌دهد اگر بهترین روش‌های 4M (Model, Machine, Mechanization, Map) به شکل راهبردی اعمال شوند، مصرف انرژی در آموزش ML می‌تواند تا ۱۰۰ برابر کاهش پیدا کند و انتشار CO2 تا ۱۰۰۰ برابر کم شود.

4Mها مجموعه‌ای از بهترین روش‌های پیشنهادی گوگل هستند که اثرات زیست‌محیطی آموزش و توسعه ML را به‌طور معنی‌دار کم می‌کنند.
اول، Model روی انتخاب معماری‌های کارآمد مثل مدل‌های sparse تمرکز دارد که می‌تواند محاسبات را ۵ تا ۱۰ برابر کاهش دهد.
دوم، Machine یعنی استفاده از پردازنده‌های بهینه‌شده برای ML مثل TPU یا GPUهای جدید که می‌توانند عملکرد به ازای هر وات را ۲ تا ۵ برابر نسبت به پردازنده‌های عمومی بهتر کنند.
سوم، Mechanization یعنی استفاده از محاسبات ابری که بهره‌وری انرژی دیتاسنتر بهتر دارد و می‌تواند هزینه انرژی را ۱.۴ تا ۲ برابر نسبت به دیتاسنترهای آن‌پرمیس کاهش دهد.
چهارم، Map یعنی انتخاب لوکیشن‌های ابری با انرژی پاک‌تر که می‌تواند ردپای کربنی ناخالص را ۵ تا ۱۰ برابر کاهش دهد.
اجرای همزمان هر چهار مورد می‌تواند مصرف انرژی و انتشار CO2 را به‌طور چشمگیر پایین بیاورد.

جمع‌بندی

پیچیدگی روزافزون و رشد مدل‌های AI، به‌خصوص LLMها، نشان می‌دهد سیستم‌های AI چقدر انرژی‌بر شده‌اند. به همین دلیل، اندازه‌گیری ردپای انرژی در کل چرخه عمر ML، از پردازش داده تا آموزش و مخصوصاً استنتاج، حیاتی است. اندازه‌گیری ردپا کمک می‌کند هنگام توسعه و استقرار مدل، تصمیم‌های آگاهانه بگیریم و در نهایت سیستم‌های AI/ML انرژی‌کارآمد بسازیم. ابزارهایی مثل CodeCarbon و MLCarbon راه‌های ارزشمندی برای اندازه‌گیری و پایش این انتشارها ارائه می‌دهند. اما یک نکته مهم این است که «فقط اندازه‌گیری» کافی نیست.

مسیر AI پایدار، یک راهبرد چندبخشی می‌خواهد. علاوه بر ردیابی انتشارها، انتخاب سنجیده مدل، کاهش بار محاسباتی، انتخاب سخت‌افزار کم‌مصرف، و استفاده هوشمندانه از زیرساخت ابری در مناطق کم‌کربن، می‌تواند ردپای انرژی را بیشتر کاهش دهد. با پذیرش این بهترین روش‌ها، می‌توانیم سیستم‌های AI/ML انرژی‌کارآمد بسازیم و نوآوری را مسئولانه جلو ببریم.