تصاویر استنتاج و آموزش یادگیری عمیق که فریمورکها، درایور CUDA و وزنهای مدل را در خود دارند، معمولاً از 20 تا 30 گیگابایت یا بیشتر فضا میگیرند. کشیدن این تصاویر روی نمونههای GPU میتواند چند دقیقه طول بکشد؛ وقتی شتابدهندهها آمادهٔ پردازشاند اما منتظر انتقال تصویر میمانند، این تاخیر به کاهش قابلتوجهی در بهرهوری و افزایش زمان پاسخ سرویس منجر میشود.
چرا کشیدن تصویر به گلوگاه تبدیل میشود
در یک پلتفرم تولیدی ML روی Amazon EKS، هدف تیم ما آمادهشدن پادها در کمتر از 2 دقیقه بود اما عملیات pull بهتنهایی چند دقیقه طول میکشید. هر پاد حدود 30 گیگابایت تصویر را از رجیستری میکشید و همزمان دادههای مدل را از فایلسرور بارگذاری میکرد. از آنجا که تصاویر مرتب بازساخته میشدند، نودها غالباً با cold pull (بارگذاری سرد) مواجه بودند و کش محلی قابلاستفادهای در دسترس نبود؛ نتیجه: بیکاری شتابدهندهها، autoscaling کند و صفهای طولانی درخواست.
ساختار تصویر کانتینر و اثر آن روی زمان pull
یک تصویر کانتینر مجموعهای از لایهها بهعلاوهٔ یک مانفیست JSON است. هر لایه یک فایل tar فشردهشده با gzip است و برای هر لایه یک digest (SHA-256) در مانفیست ثبت میشود تا صحت انتقال قابلتأیید باشد. بررسی مانفیستهای واقعی نشان میدهد اندازهٔ لایهها بسیار نابرابر است: یک لایه ممکن است نیمی از اندازهٔ کل تصویر را به خود اختصاص دهد (تا 9 گیگابایت یا بیشتر)، در حالی که بقیه لایهها بهمراتب کوچکترند. این نابرابری باعث میشود زمان کل pull بهشدت تحتتأثیر بزرگترین لایهها قرار گیرد.
| تصویر | اندازه فشرده | تعداد لایهها | بزرگترین لایه |
|---|---|---|---|
| AWS DJL LMI 21.0 Inference (cu129) | 16.5 GB | 29 | 9.5 GB |
| AWS PyTorch Training NeuronX 2.7.0 | 12.8 GB | 21 | 3.9 GB |
| AWS SageMaker Distribution 4.2.1 GPU | 10.5 GB | 28 | 9.4 GB |
شش مرحلهٔ مسیر pull که باید بازمهندسی شوند
برای هر لایه، containerd معمولاً شش عملیات پشتسر هم انجام میدهد که سه مرحلهٔ اول مربوط به دانلود و سه مرحلهٔ بعدی مربوط به unpack است:
- دانلود: دریافت blob از رجیستری روی اتصال HTTP، محاسبه SHA-256 روی دادهٔ فشرده برای اعتبارسنجی و نوشتن blob فشرده روی دیسک.
- بازکردن بسته (unpack): از حالت فشرده خارج کردن gzip، محاسبه SHA-256 روی محتوای خارجشده برای تشخیص اشتراک لایهها، و استخراج فایلها به دایرکتوری snapshot که توسط snapshotter مدیریت میشود.
دو نکتهٔ حیاتی:
- محاسبهٔ SHA-256 برای لایههای چندگیگابایتی سنگین و زمانبر است و مطابق با مشخصات OCI الزامی است.
- فشردهسازی gzip معمولاً اندازه را تا ~3 برابر گسترش میدهد و وابستگی بلوکی gzip، پردازش موازی ساده را محدود میکند.
گلوگاه نرمافزاری نه شبکه
پروفایلگیری روی نمونههای GPU با پهنای باند 100–400 گیگابیت نشان داد شبکه ظرفیت کافی دارد؛ مشکل نحوهٔ استفادهٔ نرمافزار از پهنای باند، I/O و محاسبات نمونهها بود. containerd عملیات را بیش از حد متوالی انجام میداد و زمان قابلتوجهی در محاسبات هش و I/O هدر میرفت.
راهحل: همزمانسازی شبکه، ذخیرهسازی و محاسبات
بازمهندسی خط لولهٔ pull با هدف بهرهبرداری موازی از منابع، زمانهای چنددقیقهای را به چند ثانیه کاهش داد. نکات کلیدی پیادهسازی:
۱. افزایش همزمانی دانلود
- تقسیم blobهای بزرگ به بخشهای قابلدانلود موازی و استفاده از چند اتصال HTTP برای بهرهبرداری از پهنای باند موجود.
- اعتبارسنجی بخشبهبخش تا توان محاسباتی لازم برای SHA-256 به صورت پراکنده پخش شود.
۲. پردازش همزمان و استریمینگ
- شروع به بازکردن بسته و محاسبهٔ هش روی بخشهایی از داده که دریافت شدهاند، بدون انتظار برای تکمیل کامل دانلود لایه.
- استفاده از یک خط لولهٔ استریمینگ که دانلود، اعتبارسنجی و unpack را همپای هم پیش میبرد.
۳. تعامل بهتر با snapshotter
- کاهش استخراجهای تکراری از طریق تشخیص دقیقتر لایههای مشترک.
- هماهنگی نزدیکتر بین containerd و snapshotter برای جلوگیری از نوشتن و استخراج غیرضروری.
تغییرات اصلی را به upstream در containerd و SOCI snapshotter ارسال کردیم. این بهبودها اکنون در EKS Auto Mode بهصورت پیشفرض فعال هستند. برای جزئیات بیشتر به صفحهٔ رسمی Amazon EKS مراجعه کنید.
نتایج میدانی
- زمان pull برای تصاویر 20–30 گیگابایتی از چند دقیقه به چند ثانیه کاهش یافت.
- شتابدهندهها سریعتر وارد چرخهٔ پردازش شدند و تاخیر سرویس بهطور قابلتوجهی افت کرد.
- autoscaling پاسخ به بار را سریعتر انجام داد و صفهای درخواست عملاً حذف شد.
توصیههای عملی برای مهندسان
- بهروز نگهداشتن containerd و snapshotter و دنبالکردن تغییرات مرتبط با SOCI.
- اندازهگیری پیکربندی شبکه و I/O نمونهها تا از بهرهگیری کامل پهنای باند اطمینان حاصل شود.
- تحلیل مانفیست و لایهها: کاهش اندازه بزرگترین لایهها یا تقسیم منطقی آنها به لایههای کوچکتر تاثیر زیادی دارد.
چشمانداز
بهبود کشیدن تصاویر کانتینر، بهویژه در حوزهٔ ML، بهرهوری زیرساختهای GPU را افزایش میدهد و تجربهٔ کاربران سرویسهای استنتاج را بهتر میکند. با تکامل استانداردها و پیشرفت snapshotterها، انتظاری منطقی از بهینهتر شدن بیشتر مسیر pull و پیدایی راهکارهای نوین مدیریت لایهها و فشردهسازی مخصوص ML وجود دارد.
