Modal تطلق حاسبة GPU: يتفوق serverless عندما تتجاوز الذروة خصم الحجز المسبق

نشرت Modal، منصة الحوسبة serverless على GPU، نموذجًا تفاعليًا للمقارنة بين طريقتين لشراء المسرّعات: الدفع بحسب الاستخدام الفعلي، والحجز المسبق طويل الأجل. وتحتسب الحاسبة افتراضيًا تكلفة B200 وفق تعرفة Modal الحالية، ووفق الحجز لثلاث سنوات لدى مزوّدي الحوسبة السحابية الضخمة (hyperscalers). والخلاصة الرئيسية للشركة: عندما تتجاوز نسبة ذروة الطلب إلى متوسطه 5:1، يصبح serverless أرخص، رغم ارتفاع سعر ساعة GPU فيه.

تهدف المقالة إلى التوفيق بين طرفين داخل الشركات. فالماليون يريدون التحكم في النفقات، لكنهم لا يفهمون دائمًا حمل التطبيق. أما المهندسون فيفهمون الحمل، لكنهم لا يطّلعون على أسعار السوق. ويمكن للمستخدم اختيار سيناريو جاهز مبني على تجربة العملاء، أو رسم منحنى حركة المرور الخاص به بالفأرة.

صيغة واحدة بدل الجدل

يقوم النموذج على بنية بسيطة. يُرمز إلى الطلب على GPU عبر الزمن بالدالة demand(t). في serverless تساوي التكلفة السعر Rs مضروبًا في الطلب الفعلي في كل لحظة، أي في متوسط الطلب خلال الفترة. أما في الحجز المسبق فيجب شراء طاقة تغطي الذروة طوال مدة العقد: السعر Rr × أقصى طلب × المدة T.

بعد قسمة إحدى التكلفتين على الأخرى، تبقى مقارنة بين إحصاءين للطلب: الذروة والمتوسط. يكون serverless أجدى عندما تتجاوز نسبة الذروة إلى المتوسط نسبة السعرين Rs/Rr. ومثال من النص: إذا كان الحجز أرخص بعشر مرات، وبلغت ذروة التطبيق عشرة أضعاف المتوسط، فالتكلفة متساوية.

الأرقام التي تذكرها Modal:

• الخصومات المعتادة على الحجز المسبق: 2–5×؛
• نسبة الذروة إلى المتوسط في الاستدلال والتدريب والتطوير القائم على الوكلاء: 5–10×، وأحيانًا أعلى؛
• استخدام الموارد المحجوزة بحسب استطلاعات الصناعة: أقل من 30%، وغالبًا أقل من 10%؛
• نسبة الذروة إلى المتوسط في الارتفاعات المفاجئة فوق الحمل الأساسي: 10–100×؛
• حجم فئة Enterprise: مئات وآلاف وحدات GPU.

أين يخطئ النموذج، ولصالح من

يسرد المؤلفون الافتراضات بصراحة. الأول: أن الطلب يمكن التنبؤ به تمامًا طوال مدة الحجز. وهذا تساهل لصالح الحجز المسبق، لأن الخطأ نحو الأقل يؤدي عمليًا إلى طوابير انتظار وخرق لـ SLO ومفاوضات شراء عاجلة، أما الخطأ نحو الأكثر فيعني أموالًا أُنفقت هدرًا.

الافتراض الثاني يصبّ في صالح serverless: أن تخصيص GPU وتحريرها يتمان فورًا. وهنا تقر Modal بتحفظ: الهدف أن تتحقق اتفاقيات SLO أثناء التوسع التلقائي. وتؤكد الشركة أن حتى خادم vLLM أو SGLang يبدأ العمل في ثوانٍ، وأن هناك لبقية الحالات مجمّعات دافئة ومخازن مؤقتة، وهي ترفع التكلفة، لكنها ترخص بالنسبة للوحدة الواحدة مع اتساع النطاق.

الافتراض الثالث: أن الاستراتيجية إما serverless بالكامل وإما حجز بالكامل. فبعض الشركات تغطي الحمل الأساسي بالحجز المسبق وتوجّه الارتفاعات المفاجئة إلى serverless. وتنطبق الحسابات نفسها على ما يزيد عن الحمل الأساسي، وهناك تحديدًا تبلغ نسب الذروة إلى المتوسط 10–100×. وتدرس Modal النموذج الهجين فحسب، ولا تقدمه حتى الآن بوصفها مزوّدًا واحدًا.

الرابع: أن تكلفة GPU ليست العامل الوحيد. فتشير Modal إلى سرعة البدء البارد التي تتيح التطوير على البنية التحتية نفسها المستخدمة في الإنتاج. ولا يتضمن المقال تقديرًا كميًا لهذا الأثر.

كيف تستفيد من ذلك

ينبغي التذكّر أن هذه أداة من مزوّد: فالأسعار والمعاملات مضبوطة بما يناسب منتج Modal، ولم تُكشف حالات العملاء. ومع ذلك، فالمنطق نفسه عام، ويمكن اختبار أي عروض به، بما فيها العروض المنافسة.

والترتيب العملي للخطوات كما يلي. خذ تقريرًا فعليًا بالاستخدام الساعي لوحدات GPU لعدة أشهر على الأقل، واحسب الذروة والمتوسط. ثم اقسم سعر serverless على سعر الحجز المسبق، مع مراعاة مدة العقد والسعر الفعلي للساعة، لا قائمة الأسعار المعلنة. فإذا كانت نسبة الذروة إلى المتوسط أعلى بوضوح، فإن serverless يستحق النظر الجاد. أما إذا كان الحمل ثابتًا، كالتدريب المتواصل على عنقود ثابت، فيبقى الحجز المسبق خيارًا معقولًا.

وتحقق بصورة منفصلة من استخدام الموارد المحجوزة التي اشتريتَها بالفعل. فإذا كان أقرب إلى 10% منه إلى 30%، يمكن أن يبدأ الحديث عن الارتفاعات المفاجئة من فواتيرك أنت. ولا تنسَ احتساب تكلفة المخازن المؤقتة الدافئة، فهي التي تحدد ما إذا كان serverless سيحقق SLO الخاص بك فيما يتعلق بزمن الاستجابة.