چرا بارهای هوش مصنوعی با وجود GPUهای ظاهراً بیکار در صف می‌مانند؟

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

استفاده با دسترس‌پذیری فرق دارد

شاخص رایج GPU utilisation معمولاً درصد فعال‌بودن واحدهای محاسباتی را در یک بازه نشان می‌دهد. این شاخص مشخص نمی‌کند دستگاه قبلاً به یک پاد اختصاص یافته، چه مقدار VRAM اشغال شده یا یک بار تازه با قیود سخت‌افزاری و زمان‌بندی موجود سازگار است. بنابراین GPU با ۵ درصد فعالیت محاسباتی ممکن است از دید Kubernetes کاملاً اشغال باشد.

گزارش به عدد میانگین ۵ درصد استفاده محاسباتی در گزارش بهینه‌سازی Kubernetes سال ۲۰۲۶ شرکت Cast AI اشاره می‌کند. این عدد نشانه‌ای از کم‌استفاده‌ماندن منابع در مجموعه بررسی‌شده است، اما به معنای آزاد و قابل‌بازیابی بودن فوری ۹۵ درصد ظرفیت نیست؛ هر کلاستر باید جداگانه بررسی شود.

چهار علت اصلی صف در کنار GPU ظاهراً بیکار

• تخصیص انحصاری دستگاه: افزونه NVIDIA در حالت پیش‌فرض، GPU کامل را به یک پاد می‌دهد. حتی بار کم نیز مانع استفاده پاد دیگر از همان دستگاه می‌شود.
• اشغال حافظه: مدل و کش آن ممکن است VRAM را پر کرده باشند، هرچند واحدهای محاسباتی بیشتر زمان بیکار باشند. اشتراک زمانی مشکل کمبود حافظه را حل نمی‌کند.
• محدودیت جانمایی: انتخاب نوع خاص GPU، affinity، taint و topology می‌تواند مانع زمان‌بندی روی سخت‌افزار آزاد شود.
• گلوگاه بیرون از GPU: پیش‌پردازش CPU، بارگذاری داده، شبکه، ذخیره‌سازی یا انتقال PCIe می‌تواند GPU را منتظر نگه دارد، بدون اینکه ظرفیت آن واقعاً برای کار دیگری آزاد باشد.

روش تشخیص

ترتیب بررسی اهمیت دارد: نخست وضعیت تخصیص GPU در گره‌ها، سپس مصرف VRAM، بعد رویدادهای پادهای Pending و در پایان الگوی زمانی فعالیت محاسباتی را بررسی کنید. پیام‌هایی مانند کمبود منبع، ناسازگاری node selector یا taint می‌توانند مشکل جانمایی را آشکار کنند. اگر فعالیت GPU به شکل جهشی میان صفر و مقدار بالا تغییر می‌کند، احتمال گلوگاه CPU یا ورودی‌ـ‌خروجی وجود دارد.

مقایسه روش‌های اشتراک GPU

Time-slicing روی GPUهای مختلف NVIDIA قابل استفاده است و دسترسی چند کار را در زمان جابه‌جا می‌کند، اما حافظه و خطا را از هم جدا نمی‌کند. MIG در نسل Ampere و جدیدتر، GPU را به نمونه‌های سخت‌افزاری با حافظه جدا تقسیم می‌کند و برای بارهای چندمستاجری با نیاز به جداسازی مناسب‌تر است، هرچند پروفایل‌های آن ثابت‌اند. MPS اجرای هم‌زمان چند فرایند CUDA را ممکن می‌کند و سربار جابه‌جایی را کاهش می‌دهد، ولی در پیکربندی پایه جداسازی کامل حافظه ندارد.

هیچ‌کدام نسخه واحدی برای همه بارها نیستند. مدل‌هایی مانند vLLM نیز ممکن است پیش‌فرض بخش بزرگی از VRAM را از ابتدا رزرو کنند؛ بنابراین پیش از هم‌مکانی چند سرویس باید مجموع حافظه، الگوی درخواست و اثر آن بر تأخیر دنباله‌ای مانند p95 و p99 آزمایش شود.

چه زمانی GPU بیشتری لازم است؟

خرید سخت‌افزار تازه زمانی توجیه دارد که پس از کنارگذاشتن مشکلات تخصیص، حافظه، جانمایی و برنامه، دستگاه‌ها واقعاً در ظرفیت مؤثر خود کار کنند؛ یا اشتراک منابع تأخیر غیرقابل‌قبولی ایجاد کند. در غیر این صورت، افزودن GPU ممکن است فقط گلوگاه پیکربندی را بزرگ‌تر کند، نه اینکه صف را از بین ببرد.

این مطلب بر پایه مقاله‌ای در AI News تهیه شده است. نمونه‌ها و برخی آمارهای عملکردی نقل‌شده در منبع به گزارش‌ها و محصولات Cast AI مربوط‌اند و باید در محیط واقعی هر سازمان به‌طور مستقل آزموده شوند.