SageMaker يتعلم تقسيم وحدة GPU واحدة إلى 7 أجزاء: نماذج أكثر على العتاد نفسه

الموقف مألوف: لديك مصنّف وreranker ونموذج embeddings ونموذجان خضعا للضبط الدقيق. يحتاج كل منها إلى 10–20 غيغابايت، لكن SageMaker يخصص لكل واحد وحدة GPU كاملة. تبقى بقية الذاكرة معطلة بينما ترتفع الفاتورة. وقد أصلحت AWS هذه المشكلة أخيرًا.

ما الذي تغير؟

يدعم SageMaker Inference الآن تقسيم وحدات GPU بالاعتماد على NVIDIA Multi-Instance GPU (MIG). تُقسَّم البطاقة الفعلية إلى أقسام مستقلة، لكل منها حصته الخاصة من وحدات الحوسبة وذاكرة التخزين المؤقت والذاكرة وعرض نطاق الذاكرة. والعزل هنا عتادي، لا برمجي.

في السابق، كان من يريد MIG يلجأ إلى Kubernetes مستقل، بما يشمل برامج التشغيل وdevice plugin وتهيئة الأقسام والجدولة. ولم تكن multi-model endpoints تحل المشكلة، إذ كانت النماذج تتشارك الجهاز من دون عزل، فضلًا عن حدوث cold start عند التحميل الأول. أما الآن، فما عليك سوى اختيار ملف تعريف للقسم، ويتولى SageMaker الباقي.

كيف يبدو ذلك عمليًا؟

أُضيف حقلان اختياريان. يُحدَّد AcceleratorPartitionLayouts في production variant عند إنشاء تهيئة نقطة النهاية، ويصف كيفية تقسيم كل بطاقة. فعلى مثيلة p4d.24xlarge مثلًا، يستخدم التخطيط mig-4g.20gb + mig-2g.10gb + mig-1g.5gb الشرائح السبع كلها في A100. ومع ثماني بطاقات، ينتج 24 قسمًا، بواقع ثمانية أقسام من كل نوع.

يُحدَّد AcceleratorPartitionType في inference component، وهو الذي يختار القسم الذي سيستضيف النموذج. لا توجد عمليات API أو إجراءات IAM جديدة، ولا يتغير InvokeEndpoint. ومن خلال زيادة CopyCount، يمكن وضع نسخ إضافية من نموذج صغير على الأقسام المتاحة. وقد أضاف إنشاء التقسيم نحو 17 ثانية إلى عملية نشر نقطة النهاية.

تعتمد ملفات التعريف المتاحة على وحدة GPU. تُقسَّم A100 وH100 إلى أسباع من حيث الحوسبة وإلى أثمان من حيث الذاكرة. أما G7 ‏(RTX PRO 4500 Blackwell) فتُقسَّم إلى نصفين، وG7e ‏(RTX PRO 6000 Blackwell) إلى أربعة أرباع. ويتميز ملف 3g بتركيب غير معتاد: فهو يستهلك 3 من أصل 7 كتل حوسبة، لكنه يستخدم 4 من أصل 8 كتل ذاكرة، ولذلك يملأ قسمان من هذا النوع البطاقة بالكامل.

كيفية اختيار ملف التعريف

تُستخدم كتل الحوسبة في مرحلة prefill، أي معالجة الطلب النصي: وكلما طال الإدخال وزاد عدد الطلبات المتوازية، ازدادت أهميتها. أما الذاكرة، فهي مطلوبة لمرحلة decode والسعة، وتشمل الأوزان وذاكرة KV المؤقتة و1–2 غيغابايت من النفقات الإضافية لسياق CUDA. يبلغ حجم نموذج 8B بصيغة FP16 نحو 16 غيغابايت، ويمكنه على قسم بسعة 40 غيغابايت التعامل بأريحية مع سياق من 8,000 token. إذا حُسبت الأوزان وحدها، فقد يُحمَّل النموذج بنجاح، لكنه سيتعطل تحت الضغط أو يقلّص السياق بصمت.

أين تكون الميزة مجدية؟

• مجموعة من النماذج الصغيرة والمتوسطة: نسخ مضبوطة بدقة، ونماذج embeddings، وrerankers.
• تعدد المستأجرين: توجد حدود عتادية بين العملاء، لكن المضيف والشبكة والتوجيه تظل مشتركة، ولذلك فهذا ليس عزلًا كاملًا.
• خطوط معالجة على مثيلة واحدة: النسخ الصوتي، وفصل المتحدثين، وLLM من دون انتقالات عبر الشبكة.
• نموذج guardrail بزمن استجابة يمكن توقعه.
• نشر canary: تشغيل الإصدار المرشح على قسم صغير بجوار إصدار الإنتاج.

القيود

يجب اختيار التخطيط عند إنشاء نقطة النهاية، ولا يمكن تغييره أثناء التشغيل. وتعمل الميزة مع inference components فقط؛ أما نقاط النهاية المستقلة وserverless وغير المتجانسة فلا تحظى بالدعم. ويظل النموذج الذي يحتاج إلى أكثر من بطاقة واحدة بحاجة إلى أجهزة كاملة. على P4d، يتطلب ملف mig-1g.10gb برنامج التشغيل R525 أو إصدارًا أحدث، بينما تأتي الصورة الافتراضية بالإصدار 470، ولذلك يجب تحديد InferenceAmiVersion al2023-ami-sagemaker-inference-gpu-4-1. وإلا ستفشل عملية التقسيم من دون رسالة خطأ واضحة.

ما الذي ينبغي فعله؟

إذا كانت لديك عدة نماذج صغيرة في SageMaker يعمل كل منها على وحدة GPU منفصلة، فاحسب الذاكرة وفق المعادلة «الأوزان + ذاكرة KV المؤقتة + النفقات الإضافية»، ثم حاول تجميعها على بطاقة واحدة. ومن المفيد أيضًا إجراء اختبارات تحميل: لا يعتمد أداء القسم على الأقسام المجاورة، لذا يمكن نقل النتائج إلى بيئة الإنتاج.