۴۷۳۷ ساعت محاسباتی متوالی؛ این تمام زمانی بود که برای یک بار اجرای استنتاج جهت نقشه‌برداری از ریسک آتش‌سوزی‌های جنگلی در سراسر آمریکای شمالی تخمین زده شده بود. اما حالا پلتفرم OlmoEarth این بازه زمانی را به تنها ۳۰.۵ ساعت زمان واقعی (Wall-clock time) کاهش داده است. این شتاب خیره‌کننده مدیون لایه زیرساختی جدیدی است که توسط مؤسسه آلن برای هوش مصنوعی (Ai2) طراحی شده تا مدل‌های بنیادی (Foundation Model) — که مانند یک دانشمند همه‌چیزدان، مفاهیم کلی جهان را می‌فهمند و آماده‌اند تا در هر تخصص دقیقی به کار گرفته شوند — را در مقیاس سیاره‌ای عملیاتی کند.
مدل‌های خانواده OlmoEarth با وزن‌های باز (Open Weights) — یعنی دستور پخت مدل علناً منتشر شده و دیگر یک جعبه سیاه نیست — بر روی تقریباً ۱۰ ترابایت داده‌های ماهواره‌ای چندوجهی پیش‌آموزش دیده‌اند. با این حال، اکثر سازمان‌های غیردولتی (NGO) محیط‌زیستی و آژانس‌های دولتی، تیم‌های مهندسی لازم برای مدیریت چرخه کامل این مدل‌ها را ندارند. آن‌ها در «آخرین مایل» مسیر، یعنی برچسب‌گذاری داده‌ها، تنظیم دقیق (Fine-tuning) — شبیه وقتی که به یک پزشک عمومی، تخصص پوست می‌دهیم تا روی یک حوزه دقیق شود — و اجرای استنتاج (Inference) — لحظه‌ای که مدل واقعاً جواب تولید می‌کند، مثل خودِ آشپزی نه دوره‌ی آموزش آشپز — در ابعاد قاره‌ای دچار مشکل هستند؛ چرا که در این ابعاد، حجم داده‌ها بسیار بیشتر از توان محاسباتی مدل است.
به نقل از مستندات Ai2، این مؤسسه از تجربه بیش از یک دهه مدیریت پلتفرم‌های نرم‌افزاری جهانی مثل Skylight و EarthRanger استفاده کرده است. این ابزارها به‌طور روزانه مورد اعتماد سازمان‌ها هستند و این بدان معناست که زیرساخت آن‌ها باید بسیار مستحکم باشد. این تجربه به Ai2 آموخت که برای دستیابی به اثرگذاری واقعی در دنیای فیزیکی، مدل‌ها باید به‌گونه‌ای مقرون‌به‌صرفه اجرا شوند، عملکردشان به‌طور مداوم پایش گردد و خروجی‌های خام آن‌ها به بینش‌های عملی تبدیل شود تا نتایج مورد انتظار شرکا تأیید گردد. تلاش برای تبدیل داده‌های دیجیتال به اقدامات عملی در دنیای فیزیکی، رویه‌ای است که شرکت‌هایی چون انویدیا نیز در مدل Cosmos 3 Edge برای پیش‌بینی اقدامات فیزیکی روی آن متمرکز شده‌اند. همان‌طور که در تحلیل‌های پیشین ما درباره‌ی زیرساخت‌های مدل‌های بازمتن اشاره کردیم، دسترسی به مدل تنها نیمی از راه است و نیمه دیگر، توانایی استقرار آن در مقیاس صنعتی است.
این پلتفرم که در ۲۸ جولای ۲۰۲۶ عرضه شد، دقیقاً مشکلاتی را حل می‌کند که در حوزه مشاهده زمین (Earth Observation) وجود دارد. برخلاف مدل‌های زبانی بزرگ (LLM) استاندارد که تنها چند مگابایت متن یا یک عکس تک‌اسنپ‌شات گوشی را پردازش می‌کنند، کارهای ژئوسپاشال (Geospatial) با ترابایت‌ها داده سروکار دارند. طبق گزارش فنی Ai2، یک پروژه واحد برای تنظیم دقیق یک مدل بنیادی جهت دستیابی به حداکثر عملکرد، می‌تواند ساعت‌ها به طول انجامد و چندین باند طیفی، انواع سنسورها و گام‌های زمانی مختلف را در بر بگیرد. گلوگاه اصلی در اینجا معمولاً پاس پیشرو (Forward Pass) مدل نیست، بلکه زمانی است که صرف دانلود و آماده‌سازی تصاویر از ارائه‌دهندگان پراکنده می‌شود؛ ارائه‌دهندگانی که برخی از آن‌ها ممکن است مشاهدات ناقص داشته باشند یا تصاویرشان با پوشش ابر مختل شده باشد.
خط لوله محاسباتی سه‌مرحله‌ای
برای اینکه GPUهای گران‌قیمت در انتظار دانلود داده‌ها بیکار نمانند و منابع هدر نرود، Ai2 یک تقسیم کار سخت‌افزاری خاص را پیاده‌سازی کرد. از آنجا که اکتساب و آماده‌سازی داده‌ها اغلب بخش عمده‌ای از زمان اجرا را می‌گیرد، واگذاری این کار به GPUها استفاده‌ای ناکارآمد از سخت‌افزارهای گران‌قیمت بود.
- دریافت و پیش‌پردازش داده (CPU, High I/O): این مرحله وظیفه فراخوانی، بازپروژکت (Reproject)، تراز کردن و نرمال‌سازی تصاویر را بر عهده دارد. در این مرحله، داده‌ها در قالبی نوشته می‌شوند که برای بارگذاری سریع در فاز استنتاج بهینه شده است.
- استنتاج (GPU): این لایه پاسِ پیشرو (Forward Pass) مدل را اجرا می‌کند. برای به حداکثر رساندن بهره‌وری، این لایه خروجی‌هایی با پردازش حداقلی را مستقیماً در فضای ذخیره‌سازی می‌نویسد.
- پس‌پردازش (CPU): در این مرحله، خروجی‌های مربوط به هر پنجره (Window) به یکدیگر دوخته شده و ماسک‌ها یا مقیاس‌بندی‌های لازم اعمال می‌شوند. در نهایت، نتایج در قالب‌های کاربر‌پسندی مانند Zarr، GeoTIFF یا GeoJSON صادر می‌گردند.
موازی‌سازی انبوه و بخش‌بندی
لایه اجرایی پلتفرم یعنی OlmoEarth Run، مشکل مقیاس را با شکستن یک منطقه جغرافیایی به بخش‌هایی (Partitions) با اندازه مناسب برای هر نمونه محاسباتی (که به آن‌ها Worker یا کارگر گفته می‌شود) حل می‌کند. این بخش‌ها خود به پنجره‌های کوچک‌تری تقسیم می‌شوند که به‌طور مستقل توسط GPUهای مجزا پردازش می‌گردند.
از آنجا که هر پنجره می‌تواند در یک پاس پیشرو مجزا مدیریت شود، پردازش یک بخش از نقشه نیازی نیست منتظر بخش دیگر بماند. در عمل، یک منطقه به اندازه یک ایالت ممکن است به ۱۰۰ بخش تقسیم شود، در حالی که یک اجرای در مقیاس قاره‌ای می‌تواند به هزاران بخش گسترش یابد. برای تضمین اینکه رستر (Raster) نهایی بدون درز و یکپارچه باشد، بخش‌های مجاور دارای مقدار کمی هم‌پوشانی (Overlap) هستند و پلتفرم در مرحله سرهم‌بندی، این هم‌پوشانی‌ها را تطبیق داده و اصلاح می‌کند.
در پروژه آتش‌سوزی آمریکای شمالی، این معماری اجازه داد تا یک «توزیع گسترده» (Fan-out) شدید رخ دهد. در نقطه اوج، این اجرا از ۱۹۶۰۰ پردازنده مرکزی (CPU) و ۹۹۴ واحد پردازش گرافیکی (GPU) به‌طور موازی استفاده کرد. سیستم به توان عملیاتی (Throughput) شبکه بیش از ۱۶۸ گیگابایت بر ثانیه رسید که نشان‌دهنده افزایش سرعت ۱۵۵ برابری نسبت به محاسبات متوالی (Serial Compute) است. این رویکرد بهینه‌سازی زمان اجرا، یادآور متدهای پیشرفته‌ای است که در پلتفرم MOCA برای کاهش زمان انطباق کاوشگرها به کار گرفته شده تا سرعت عملیات‌های پیچیده را به‌طور چشمگیری افزایش دهد.
مدیریت موازی‌سازی از طریق یک «پیچ تنظیم برای هر اجرا» (per-run knob) انجام می‌شود تا از رسیدن به سقف سهمیه‌های ابری (Cloud Quotas) جلوگیری شود. کاربران می‌توانند متغیرهای زیر را بر اساس وظیفه خاص و بودجه خود تنظیم کنند:
- رزولوشن خروجی: تعادل میان حجم داده و قدرت محاسباتی در برابر جزئیات دقیق‌تر.
- اندازه مدل: تعادل میان زمان اشغال GPU در برابر افزایش دقت.
- کش (Caching): تعادل میان فضای ذخیره‌سازی در برابر افزایش سرعت در اجراهای تکراری روی یک منطقه جغرافیایی یکسان.
رفع گلوگاه داده‌ها
درخواست (Query) از APIهای خارجی STAC (مانند سرویس‌های ESA یا Microsoft Planetary Computer) در حین یک اجرای انبوه، می‌تواند باعث فشار بیش از حد و از کار افتادن آن سرویس‌ها شود. یک پروژه استنتاج بزرگ می‌تواند به‌طور هم‌زمان هزاران درخواست متاداده تولید کند که بسیار بیشتر از ظرفیتی است که این APIها برای مدیریت هم‌زمان طراحی کرده‌اند.
برای دور زدن این مشکل، OlmoEarth ایندکس متاداده داخلی خود را نگه می‌دارد. این ایندکس با انتشار تصاویر جدید به‌روزرسانی می‌شود. برای مجموعه‌داده‌های موجود در AWS Open Data، پلتفرم برای هر صحنه جدید یک اعلان SNS دریافت می‌کند. برای ارائه‌دهندگانی که جریان تغییرات (Change Stream) ندارند، پلتفرم هر چند دقیقه یک‌بار ایندکس بالادستی را بررسی (Poll) می‌کند. این امر تضمین می‌کند که درخواست‌ها با سرعت ثابت انتشار داده‌ها پیش بروند، نه اینکه به صورت انفجاری و ناگهانی ارسال شوند.
این ایندکس، متاداده‌های صحنه و اشاره‌گرهایی (Pointers) به فرمت‌های بهینه شده برای ابر مانند COG یا Zarr را ردیابی می‌کند. با استفاده از «خواندن پنجره‌ای» (Windowed Reads)، پلتفرم به جای دانلود کامل صحنه‌های ماهواره‌ای، تنها بایت‌های خاص مورد نیاز برای یک پارتیشن را بازیابی می‌کند.
این ایندکس همچنین ابزارهای حاشیه‌نویسی (Annotation) را تغذیه می‌کند. چون اشاره‌گرهایی به تصاویر Sentinel-1، Sentinel-2، Landsat و NISAR دارد، می‌تواند تایل‌های هر صحنه ایندکس‌شده را از طریق همان سیستم خواندن پنجره‌ای ارائه دهد. Ai2 اشاره می‌کند که موفق‌ترین ارائه‌دهندگان داده از سه روش بهینه استفاده می‌کنند: اعلان‌های مبتنی بر صف (Queue-based)، ذخیره‌سازی در پلتفرم‌های ابری اصلی بدون محدودیت‌های نرخ اختصاصی (Bespoke rate limits)، و استفاده از فرمت‌های بهینه شده برای ابر که از خواندن محدوده‌ای (Ranged reads) پشتیبانی می‌کنند.
تاب‌آوری در مقیاس بالا
محاسبات توزیع‌شده در این ابعاد، شکست‌های روتین را اجتناب‌ناپذیر می‌کند. ممکن است ارائه‌دهندگان داده کند باشند، متاداده‌ها درباره باندهای موجود نادرست باشند یا تسک‌ها به‌طور کامل کرش کنند. پلتفرم به‌گونه‌ای طراحی شده که با ایجاد یک ماشین مجازی که کانتینر Docker مربوط به اجراکننده (Runner) را اجرا می‌کند، به‌طور خودکار بازیابی شود.
از آنجا که هر تسک «reentrant» و «idempotent» است (یعنی تکرار آن نتیجه‌ای متفاوت نمی‌سازد و وضعیت سیستم را به هم نمی‌ریزد)، شکست‌های متناوب به‌سادگی با اجرای مجدد تسک مدیریت می‌شوند. پلتفرم از ردیابی تسک‌ها، تلاش‌های مجدد خودکار و بازگشت به ارائه‌دهندگانی جایگزین استفاده می‌کند. یک فرآیند نظارتی مجزا، اجراکنندگانی را که متوقف شده یا متوقف گشته‌اند شناسایی کرده و تسک‌های مرتبط با آن‌ها را مجدداً راه‌اندازی می‌کند و تفاوت دقیقی بین خطاهای قابل تکرار (Retryable) و خطاهای مهلک (Fatal) قائل می‌شود.
تحلیل: صنعتی‌سازی حفاظت از محیط زیست
این تغییر، نشان‌دهنده گذار از «تحقیق در هوش مصنوعی» به «خدمات شهری هوش مصنوعی» (AI Utilities) برای سیاره زمین است. با کاهش هزینه استنتاج به کسری از یک پنی برای هر کیلومتر مربع، Ai2 در حال حذف سد مالی است که پیش از این نظارت با رزولوشن بالا را منحصر به کشورهای ثروتمند یا شرکت‌های غول‌پیکر فناوری می‌کرد. امروز، این پلتفرم می‌تواند ده‌ها ترابایت تصویر را در مناطق مقیاس قاره‌ای در حدود یک روز پردازش کند.
برای بخش محیط‌زیستی، برد واقعی، جداسازی تخصص یادگیری ماشین (ML) از اثرگذاری عملیاتی است. وقتی یک گروه حفاظتی بتواند بدون نوشتن حتی یک خط کد Kubernetes، یک هشدار جنگل‌زدایی را بر اساس یک صحنه ماهواره‌ای جدید فعال کند، حلقه بین مشاهده و اقدام به‌طور قابل توجهی بسته می‌شود. این موضوع برای ماموریت‌های حیاتی در حوزه امنیت غذایی و ریسک آتش‌سوزی‌ها حیاتی است.
نقشه راه آینده
مؤسسه Ai2 در حال حاضر قابلیت‌های پلتفرم را برای موارد زیر گسترش می‌دهد:
- زمان‌بندی خودکار: برنامه‌ریزی کارهای استنتاج از پیش یا فعال‌سازی خودکار آن‌ها زمانی که ایندکس تصاویر، صحنه جدیدی را روی یک منطقه مورد نظر ثبت کند.
- تشخیص تغییرات و هشدارها: فراتر رفتن از رسترها برای اعلان فوری به کاربران هنگام تغییر چشم‌اندازها، مثلاً در حین یک حادثه سیل.
- رابط‌های عامل‌محور (Agentic Interfaces): استفاده از عامل‌های هوش مصنوعی برای کاهش موانع فنی در کیوریتور کردن داده‌ها، مهندسی ویژگی‌ها و شناسایی راه‌های بهبود مدل‌های تنظیم‌شده.
- مدل‌های سریع‌تر: همکاری با تیم‌های پژوهشی روی معماری‌های کارآمدی که زمان GPU را برای هر پنجره کاهش می‌دهند.
- مودالیته‌های جدید: افزودن سنسورهای ماهواره‌ای بیشتر و داده‌های هواشناسی (به‌ویژه ERA-5) به مدل‌ها و ایندکس تصاویر.
- جاسازی‌های جهانی (Global Embeddings): توسعه یک مدل جاسازی اختصاصی برای پیش‌محاسبه (Precompute) امبدینگ‌ها در مقیاس جهانی. این کار اجازه می‌دهد استنتاج جایگزین یک پاس پیشرو کامل روی تصاویر خام شود و حجم کاری را به‌طور قابل توجهی سریع‌تر و ارزان‌تر کند.
از آنجا که معماری پلتفرم بر اساس Docker و ذخیره‌سازی Blob است، Ai2 قصد دارد آن را مستقل از ابر (Cloud-agnostic) نگه دارد. اگرچه در حال حاضر روی Google Cloud اداره می‌شود، اما OlmoEarth Run به‌گونه‌ای طراحی شده تا از چندین ابر و استقرارهای داخلی در حساب و محیط محاسباتی شرکا پشتیبانی کند.
گام بعدی شما
- اگر در حوزه تحلیل داده‌های ماهواره‌ای فعال هستید، معماری «تقسیم کار CPU/GPU» این پلتفرم را برای بهینه‌سازی هزینه‌ها بررسی کنید.
- مدل‌های OlmoEarth را برای کاربردهای شناسایی تغییرات محیطی در مقیاس وسیع تست کنید.
- مستندات مربوط به فرمت‌های COG و Zarr را برای سرعت بخشیدن به خواندن داده‌های حجیم مطالعه کنید.
اما داستان سخت‌افزاری این تحول حتی شگفت‌انگیزتر است؛ برای درک اینکه چگونه سخت‌افزارهای جدید این سرعت‌ها را ممکن می‌کنند، به تحلیل ما درباره‌ی تراشه‌های Blackwell مراجعه کنید.
گفتگو