AWS تطلق حجز وحدات GPU بالساعات: لاختبارات التعلم الآلي والتحضير للإصدارات

قدّمت AWS خدمة EC2 Capacity Blocks for ML، إلى جانب خطط التدريب SageMaker training plans المتكاملة معها، وهي حل جديد لحجز سعة GPU لفترات قصيرة. ويعالج هذا الحل أبرز مشكلة يواجهها مهندسو تعلّم الآلة: النقص الحاد في وحدات GPU المتاحة، والحاجة إلى دفع تكلفة عقود طويلة حتى لو كانت القدرة الحاسوبية مطلوبة لبضع ساعات فقط. وبات بالإمكان الآن حجز العدد المطلوب بالضبط من وحدات GPU، وللفترة التي تلزم بالضبط.

متى تلزم وحدات GPU لفترات قصيرة

في الواقع العملي، سيناريوهات الاستخدام هذه أكثر مما يبدو. فاختبار الأحمال (load testing) قبل إطلاق ميزة جديدة يتطلب بنية تحتية كاملة، لكن ليوم أو يومين فقط، وبعد انتهاء الاختبارات لا جدوى من الاستمرار في الإنفاق. أما التحقق من صحة النماذج (model validation)، أي فحص موجّه (prompt) جديد أو نموذج خضع للضبط الدقيق (fine-tuned) على بيانات حقيقية، فيستغرق في الغالب من 4 إلى 8 ساعات.

وورشات عمل الفرق التي تدرّب المهندسين على العمل مع أطر مثل PyTorch وTensorFlow تحتاج إلى GPU طوال مدة الجلسة فقط، لا بشكل دائم. وقبل أي إصدار كبير، ينبغي تجهيز بنية الاستدلال (inference): تشغيل الخوادم، وتسخين الذاكرة المؤقتة، وإجراء اختبارات smoke. يضاف إلى ذلك الارتفاعات المؤقتة في حركة المرور (spikes) في ساعات الذروة، حين تلزم قدرة حاسوبية إضافية ثم يتراجع الطلب بعد ذلك.

• اختبار الأحمال قبل إطلاق الميزات
• التحقق من النماذج بعد الضبط الدقيق (fine-tuning)
• تدريب الفرق وورشات العمل
• تجهيز سعة الاستدلال (inference) قبل الإصدار (release)
• التعامل مع الارتفاعات المؤقتة في حركة المرور (spikes)

كيف تعمل Capacity Blocks

الفكرة بسيطة: بدلاً من Reserved Instance (عقد شهري أو سنوي) أو On-Demand (مكلف عند الاستخدام المستمر)، تحجز كتلة من وحدات GPU لوقت محدد يتراوح من بضع ساعات إلى عدة أيام. وتضمن AWS أن تكون السعة محجوزة ومتاحة تحديداً في الفترة المختارة. وهذا يمنح المهندسين قابلية للتنبؤ: فأنت تعرف أن وحدة GPU ستكون جاهزة في الموعد المخطط له.

والخدمة متكاملة مع SageMaker Training Plans، فتطلق مهمة التدريب (training job) دون القلق من نفاد وحدات GPU في منتصف تدريب النموذج. وتعمل EC2 Capacity Blocks مع أنواع مختلفة من وحدات GPU: NVIDIA H100 (لنماذج LLM)، وA100 (خيار شامل)، وL4 (مدمجة، للاستدلال). وتختار التكوين بحسب نوع الحمل. وتُدار الخدمة بالكامل عبر واجهة AWS المعتادة، مع التكامل مع SageMaker وCloudFormation وأدوات أخرى.

الأسعار والمرونة

كان الاختيار سابقاً غير مريح. فإما Reserved Instance لسنة مقدماً، وهو رخيص لكنه يفقدك المرونة، وإما On-Demand بالساعة، وهو مرن لكنك تدفع أضعاف السعر بمقدار 3-4 مرات. وتقع Capacity Blocks بين هذين الطرفين: أرخص من On-Demand، ولكن دون عقد طويل الأجل. والأهم أنك لا تدفع مقابل الوقت غير المستخدَم.

وهذا يعني للشركات تخطيطاً أدق لميزانية البنية التحتية وتجنباً للمدفوعات الزائدة. فلن يطلب المهندسون وحدات GPU «احتياطاً» فيرفعوا النفقات دون داعٍ. وستتمكن فرق DevOps من توسيع البنية التحتية بمرونة قبل اللحظات الحرجة، كالإصدارات والمؤتمرات والحملات التسويقية، مع معرفة السعر الدقيق لكل ساعة.

ماذا يعني ذلك

تتكيف الخدمات السحابية أكثر فأكثر مع الاحتياجات الفعلية لأعمال تعلّم الآلة. فعصر حجز وحدات GPU مسبقاً ودفع ثمن الوقت غير المستخدَم يوشك على الانتهاء. وبدلاً من ذلك، تدفع فقط مقابل ما تستخدمه، وفي اللحظة التي تستخدمه فيها بالضبط، وهذا أوفر وأكثر منطقية ويقلل الهدر (waste) في مشاريع البنية التحتية.