التنقل الرأسي: الاستدلال من المنتجات الدنيا المقبولة (MVP) إلى أعباء العمل ذات التريليون معلمة — سيتانشو غوبتا، CoreWeave
AAI Engineer
컴퓨터/소프트웨어AI/미래기술
스크립트
00:00:00مساء الخير جميعا. أنا سيتان شو من كورفي. سأتحدث اليوم عن التنقل
00:00:19العامودي. العنوان الذي اخترناه جذاب نوعاً ما، لكننا سنتحدث بشكل أساسي عن
00:00:26منصة الاستدلال المتوفرة لدينا في كورفي والتي نبنيها لخدمة
00:00:30النماذج الصغيرة والكبيرة ومختلف أنواع أحمال العمل. نبذة سريعة عني، لقد انضممت إلى
00:00:38كورفي قبل حوالي أربعة أشهر، لأقود قطاع الاستدلال هناك. وقبل ذلك،
00:00:44كنت أيدير كل شيء في مختبرات AWS Annapurna للتدريب، وقبل ذلك، الاستدلال
00:00:49والتدريب في Sambanova. لذا لدي خبرة لا باس بها في هذا المجال بالذات. والطريقة
00:00:56التي سأصطحبكم بها هي شرح نماذج الاستهلاك
00:01:00التي لدينا، ومن خلال ذلك، كيف استنتجنا شكل المنصة بحيث
00:01:04لا نحتاج إلى الاستمرار في تغيير المنصة ونواصل إجراء تحسينات عليها
00:01:09التي نملكها لخدمة الاستدلال، وكيف ولماذا يلعب الأداء دوراً مهمًا
00:01:14هناك. أعتقد أن القليل من هذا قد يكون مشتركاً مع الموضوع السابق الذي تم تناقشه
00:01:20هنا. نماذج الاستهلاك. إذن لدينا بشكل عام نموذجان رئيسيان للاستهلاك. الأول هو الخادمات السحابية (Serverless)،
00:01:29وهو حيث يمكن للعملاء الدخول، ويمكن للمستهلكين الدخول، دون الحاجة إلى القلق بشأن إدارة
00:01:35الأجهزة بأنفسهم، ودون الحاجة إلى القلق بشأن إدارة الحزم، أو التنسيق، أو أي شيء على الإطلاق.
00:01:40هناك واجهة برمجة تطبيقات (API)، وهناك واجهة مستخدم، يمكنك الدخول، والدفع مقابل كل رمز (Token)، ويتم خدمة نموذجك.
00:01:47أهم شيء هنا هو نوع النماذج التي نخدمها في الكتالوج، أي تنوع
00:01:54النماذج التي سيتمكن العميل من استعراضها. سأتحدث عن النماذج المخصصة ثم أعود إلى السحابية (Serverless)،
00:02:01لأن هناك شيئاً فريداً من نوعه في جانب الخادمات السحابية. خدمة الاستدلال المخصصة التي نقدمها
00:02:05هي أكثر للعملاء الذين يرغبون في معرفة الأجهزة التي سيستخدمونها وتشغيلها بالتحديد،
00:02:11ولكن نشر النموذج يعتمد عليهم أيضاً. لذا فهي تستخدم خدمتنا، وتستخدم طبقات التنسيق الخاصة بنا،
00:02:18لكن نشر النموذج يعتمد عليهم. أداء النموذج يعتمد عليهم أيضاً، طالما أننا نقدم
00:02:25في المنصة القدرة والأدوات لخدمة تلك الميزات. بالعودة إلى الخادمات السحابية،
00:02:30أحد الجوانب المثيرة للاهتمام هنا هو أن نماذج الخادمات السحابية عادة ما تواجه مشاكل الجيران المزعجين،
00:02:38حيث إنه إذا كان الجميع يضغطون على نفس النموذج تماماً، فقد تواجه انتهاء المهلة (Timeout)
00:02:43بشكل كبير، اعتماداً على مقدار السعة التي أمتلكها خلف الكواليس. لذا هناك ميزة أخرى لدينا على جانب الخادمات السحابية
00:02:48وهي ما نسميه الإنتاجية المُخصّصة (Provisioned Throughput). لذا كعميل، إذا كنت تعرف نمط حركة المرور الخاص بك،
00:02:55وإذا بإمكانك إعلامنا بذلك، يمكننا تخصيصها لك خصيصاً،
00:03:00خلف الكواليس. لا يزال يتعين عليك عدم القلق بشأن الأجهزة التي تعمل عليها بالضبط،
00:03:04طالما يتم الحفاظ على الإنتاجية واتفاقيات مستوى الخدمة (SLAs) الخاصة بك.
00:03:07إذن هذه ميزة أخرى على جانب الخادمات السحابية، ولا يزال المحاسبة عليها تتم بالرمز (Token)،
00:03:12ولكنك تعلم أنك لن تواجه مشكلة الجار المزعج هناك.
00:03:19دعوني ألقي نظرة سريعة على بعض أنواع أشكال أحمال العمل المختلفة التي لدينا،
00:03:27والتي نشهدها، والنسبة بينها تتغير باستمرار، على الرغم من أن أحمال الوكلاء (Agentic)
00:03:32مرتفعة حقاً. أحمال الوكلاء والمحادثة متشابهة جداً، كلاهما عالي جداً في أطوال تسلسل الإدخال،
00:03:39ومنخفض جداً في أطوال تسلسل الإخراج عادةً. ولكن الاختلاف الأكبر بين الوكلاء و
00:03:43المحادثة هو حقيقة أن المحادثات المتعددة في أحمال الوكلاء ذات زمن انتقال منخفض للغاية مقارنة بالمحادثات العادية، لأنه عندما
00:03:50تحصل على رد المستخدم، عليك قراءة الإجابة ثم الرد عليها. إذن هناك
00:03:56فروق هناك. وهذا الاختلاف الكبير يتحول في النهاية إلى شيء
00:04:01مرتبط بإدارة ذاكرة التخزين المؤقت لـ KV (KVCache). لكن كلاهما في الوقت الفعلي، وهناك عبء عمل آخر في الوقت الفعلي وهو
00:04:09الصوت والفيديو، وهي عمليات بث ثابتة وحساسة للغاية لزمن الانتقال. على جانب الوكلاء والمحادثة،
00:04:16المتطلبات غالباً ما تكون من منظور الإنتاجية، وليست كثيرة من منظور زمن الانتقال، ولكن الصوت والفيديو في الوقت الفعلي
00:04:23حساسان تماماً لزمن الانتقال. بالانتقال إلى الدفعات (Batch)، الدفعات هي حيث تكون اتفاقيات مستوى الخدمة مرنة للغاية.
00:04:32فهي تعمل لثوانٍ ودقائق، وأحياناً لبعض العملاء تكون بالساعات.
00:04:37يقولون: سأقوم فقط بطرح، امنحني قدرة حمل عمل من 10 إلى 12 ساعة وسأطرح ما أستطيع،
00:04:44وقم بمعالجتها متى شئت. هذه الأحمال الجماعية، والطريقة التي تظهر بها هنا في
00:04:52تحديد، عذراً، كونها مطلوبة لبعض خيارات التصميم التي نتخذها في البنية. تخيل
00:04:59هذه الأشكال الأربعة المختلفة لأحمال العمل. في بُعد الوقت، عليك لعب لعبة
00:05:04الخصائص حول كيف يمكنك ملؤها للاستفادة القصوى من البنية التحتية الأساسية.
00:05:12سأعطي لمحة عامة عن شكل بنيتنا الآن. وسأصطحبكم عبر تدفق الطلبات
00:05:19هنا. إذن لكل من الخادمات السحابية والمخصصة، إذا نظرت إلى الجانب الأيمن من
00:05:24الشاشة، سترى أنه على جانب المنصة، ستنتقل إلى مستوى التحكم (Control Plane) للحصول على
00:05:31عمليات التحقق من الصلاحيات، وتحديد معدل الطلبات (Rate limiting)، وتتبع الاستخدام، وما إلى ذلك، حتى تتم محاسبتك وفقاً لذلك.
00:05:37وقابلية المراقبة (Observability) لضمان عدم انتهاك اتفاقيات مستوى الخدمة (SLAs) التي تم التوقيع عليها، أليس كذلك؟
00:05:45أسفل المنصة، لقد أوضحت على مستوى عالٍ جداً أن لدينا محركات الاستدلال المختلفة هذه،
00:05:52مثل VLLMs و SGLangs و TensorRT-LLM، ولكن هناك الكثير من التفاصيل هنا التي سأطرق إليها.
00:06:00وتحت ذلك، ما أثبته هنا باللون الأخضر هو قطع مختلفة من الأجهزة.
00:06:09لذا الأمر ليس كذلك، لذا يجب أن تتمتع المنصة بالقدرة الكافية على مشاركة وتوزيع عبء العمل
00:06:15حمل العمل عبر أجيال مختلفة من وحدات معالجة الرسومات (GPUs) هذه، وتحديداً وحدات معالجة الرسومات من Nvidia
00:06:21التي نستخدمها، أليس كذلك؟ فلناخذ بعض الأمثلة هنا. لنفترض أن الطلب ينشأ من جانب العميل
00:06:31عبر التطبيقات أو الدفاتر (Notebooks)، أي منها، أو عبر الوكلاء، أليس كذلك؟ إنه يصل إلى البوابة (Gateway).
00:06:36بمجرد وصوله إلى البوابة، إذن، مثلما ذكرت على مستوى التحكم، يمر عبر المصادقة،
00:06:42وما إلى ذلك، ولكن يأتي بعد ذلك إما الخادمات السحابية أو المخصصة. لذا في حالة الخادمات السحابية،
00:06:48سيكون الدفع مقابل كل رمز، لذا سيتم مراقبة استخدام الرموز هنا، وليس الرموز الدقيقة،
00:06:53ولكن فقط استخدام الرموز، لأننا نحافظ على سياسات الاحتفاظ الصفري بالبيانات (ZDR).
00:06:59وهو، اعتماداً على التعددية أو التخصيص، إذا تم تخصيصه، فنحن نعلم
00:07:05أنه يجب على الموجه (Router) الدخول واستهداف عمليات النشر الصريحة لعمللاء
00:07:12الإنتاجية المُخصّصة. أما بالنسبة لعملاء التعددية (Multi-tenant)، فهناك عمليات نشر منفصلة.
00:07:17الموجه هنا، وتحديداً، الموجه مهم جداً، نظراً لأن الموجه مسؤول عن
00:07:26اتخاذ خيارات توجيه واعية بذاكرة التخزين المؤقت KV. لماذا هذا مهم؟ لأنه، كما ذكرت عندما كنا
00:07:31نناقش ملفات تعريف أحمال العمل، فإن حالات استخدام الوكلاء عادة ما تكون كثيفة للغاية على أطوال تسلسل الإدخال،
00:07:39ومعظم طول تسلسل الإدخال، حوالي 80 إلى 90 بالمائة، اعتماداً على الشركة،
00:07:44واعتماداً على العملاء، فإن 80 إلى 90 بالمائة منه هو نفسه لمختلف الطلبات.
00:07:51لذا لا جدوى من الدخول وإعادة حساب مرحلة التعبئة (Pre-fill) أو إعادة القيام بالتعبئة لذلك.
00:07:57التعبئة هي عملية مكثفة الحساب للغاية، ومكلفة للغاية، ولهذا السبب بقدر ما يمكنك ضرب ذاكرة التخزين المؤقت،
00:08:04كلما زادت توفيرك، ولهذا السبب إذا نظرت إلى تسعير الرموز في أي مكان، فهناك سعر محدد
00:08:11لرموز الإدخال وهناك سعر أرخص بكثير لرموز إدخال التخزين المؤقت. لذا يصبح التخزين المؤقت مهمًا حقًا
00:08:18هنا. وكيف تريد تقسيم الأجهزة يعتمد كلياً على الاختيار في
00:08:26المنصة ونحن ن则نقدر القدرة على القيام بأي منهما. إما إجراء فصل بين التعبئة وفك التشفير (Pre-fill decode disaggregation) إذا كانت
00:08:31حالة الاستخدام تتطلب ذلك أو عدم القيام بذلك لأن فصل التعبئة وفك التشفير ليس رخيصاً لكل نوع من حالات الاستخدام.
00:08:41دعونا نأخذ تدفق طلبات آخر هنا. لنر ما إذا كان عميلاً مخصصاً، فماذا سيحدث.
00:08:48العميل المخصص سيارة أخرى سيمر عبر البوابات التي تم إعدادها لهم مع عزل مناسب.
00:08:55الفوترة ليست على أساس الرموز، بل تستند الفوترة إلى استخدام وحدة معالجة الرسومات لكل ساعة.
00:09:03إنها بوابة خاصة حتى لا تكون هناك مشكلة الجار المزعج، ولا يمكن لأي شخص آخر الدخول.
00:09:09نفس منطق الموجه هنا بحيث إذا كانت هناك طلبات متشابهة جداً، فإنها تصل إلى ذاكرة التخزين المؤقت بشكل كبير.
00:09:18واعتماداً على النشر الذي يقوم به العميل هناك على وحدات معالجة الرسومات المخصصة الخاصة بهم،
00:09:24يمكنهم تحديد ما إذا كانوا يريدون إجراء فصل التعبئة وفك التشفير أم لا. يمكنهم تحديد المحرك
00:09:29الذي سيستخدمونه، VLLM أو SG-Lang أو TensorRT-LLM. وبالنظر إلى الجزء الأكبر من السعة التي حجزها العميل،
00:09:35يمكنهم تحديد ما إذا كانوا يريدون نشر نموذج واحد فقط مع القدرة على التوسع
00:09:42عبر المجموعة بأكملها أو ما إذا كانوا يريدون الحصول على عدة نماذج مختلفة وعمليات نشر متعددة.
00:09:47الشيء الوحيد الذي أود ذكره حول الموجه هنا هو حقيقة أن
00:09:54السعة غير المتجانسة عبر المناطق والمناطق المختلفة
00:09:59مدعومة. إنها مشكلة صعبة بعض الشيء لموازنة التحميل عبرها.
00:10:04لذا فإن ترتيب الأولوية الذي نأخذه عادة هو أولاً محلية ذاكرة التخزين المؤقت لـ KV ثم التراجع إلى الأقل حملاً.
00:10:16هذا كل شيء. تدفق طلبات آخر أريد مراجعته هنا والذي
00:10:21قد يكون من الصعب رؤيته من الرسم التخطيطي وهو أنني أود تناول سير عمل الدفعات.
00:10:25بالنسبة لسير عمل الدفعات، ما سنفعله فعلياً هو السعة الأساسية التي يمتلكها العميل،
00:10:31لنفترض نفس عميل الاستدلال المخصص، خلال النهار في الولايات المتحدة يقومون بتشغيل أحمال عملهم في الوقت الفعلي
00:10:37ومن المساء إلى الليل يريدون تشغيل أحمال عمل الدفعات، ويمكن جدولة نفس السعة بعد الوقت
00:10:43لتشغيل أحمال العمل الجماعية. لذلك نحن نقدم القدرة في واجهة برمجة التطبيقات لتحديد متى يتم التوسيع للأعلى و
00:10:51متى يتم التوسيع للأسفل وحسب الجدول الزمني، إذا استطعنا، وإذا أبلغونا أنه يمكننا التصغير،
00:10:56فسوف نقوم بالتخفيض ونفتح الباب لمعالجة الدفعات طوال الليل.
00:11:05أعتقد أنني تحدثت كثيراً عن التحسينات على جانب ذاكرة التخزين المؤقت KV ولكني أريد أن أكرر القليل
00:11:10لأن هذه واحدة من أكثر القطع إثارة للاهتمام. إذا تمكنا من الوصول إلى ذاكرة التخزين المؤقت بشكل أكبر،
00:11:19وهكذا تتجنب تكلفة مرحلة الإعداد المسبق، وهي الجزء الأكثر تكلفة هنا.
00:11:26إن إعادة استخدام ذاكرة التخزين المؤقت KV عبر دورات مختلفة في مهام وكلائك، توفر أيضاً بين الدورات
00:11:31الكثير من عمليات الإعداد المسبق المتشابهة في طول التسلسل المدخل.
00:11:38فكر في مهام المحادثة، حيث يصبح تفريغ ذاكرة التخزين المؤقت KV مهمًا للغاية أيضاً،
00:11:43لأنه في مهام المحادثة لدينا الكثير من التأخير بين الدورات المختلفة المتعددة
00:11:49التي نُدخلها نحن المستخدمين. ولكن إذا قمنا بحذف كل ما كان في محادثتنا المعينة تماماً،
00:11:57فإن المرة التالية التي نطرح فيها سؤالاً في نفس المحادثة ستستغرق وقتاً أطول قليلاً.
00:12:02لذا بدلاً من الحذف الكامل وإعادة الإعداد المسبق مرة أخرى، فإن التقنيات
00:12:08المستخدمة قد تتضمن تقنياتنا الخاصة، بينما نعرف خارجياً تقنيات مثل LM cache و Mooncakes.
00:12:17وما نقوم به هو تفريغ ذاكرة التخزين المؤقت KV إلى وحدة تخزين عالية النطاق الترددي
00:12:21حتى نتمكن من تخزين الكثير من عمليات الإعداد المسبق هذه، بحيث كلما جاء الطلب المرافق
00:12:28لتلك المحادثة المعينة، يمكن تحميله مباشرة في ذاكرة HPM.
00:12:37وفيما يتعلق بعوامل الأداء، أود فقط ذكر عدد من عوامل الأداء التي
00:12:41ناقشناها مثل PD DSAG، ولكن هناك عوامل أخرى كالتكميم وفك التشفير التخميني، وكيفية
00:12:48اختيار درجات التوازي والاستراتيجيات بعناية، فهذا أمر مهم للغاية في الواقع.
00:12:54اثنان من أكبر العوامل التي عملنا عليها هما التكميم إلى NVFE4 وفك التشفير التخميني.
00:13:01نحن توفر ميزة حيث إذا كان لدى العميل مجموعة بياناته ويريد منا تدريب نماذج التخمين
00:13:07لمجموعات بياناتهم لتحسين معدلات القبول، مما يجعل الإنتاجية النهائية
00:13:12أعلى بكثير. لدينا هذه الميزة أيضاً. لكن ذلك يحدث بشكل غير متزامن. فنحن نحصل على البيانات بشكل غير متزامن،
00:13:20وندرب نماذج التخمين بشكل غير متزامن، ثم ننشرها في بيئات نشر العملاء
00:13:26إذا كان هذا ما يريدونه. ترون هنا ثلاث لقطات شاشة. لقد نشرتها من
00:13:32عمل الشهر الماضي الذي قام به بعض أفراد فريقي. يمكنكم أن تروا كيف وصلنا
00:13:39سريعاً إلى صدارة لوحة المتصدرين على Kimi 2.6 و 2.7، وتلك النتائج هي من التحليل الاصطناعي
00:13:46وبالعودة إلى الجلسة التي سبقت هذه، هل يمكننا الوثوق بذلك؟ لهذا السبب بالنسبة لـ GLM، لدي النتائج
00:13:52من Open Router. لذا عندما يقوم التحليل الاصطناعي بإجراء اختبارات الأداء، فإنهم يشغلون مهام محددة للغاية.
00:13:58أما Open Router فهو لحركة مرور المستخدمين الفعليين، ويمكنك أن ترى في جانب Open Router، Weights & Biases. لذا فإن
00:14:05العلامة التجارية تختلف، لكن Weights & Biases هي أساساً كيرفي. لقد استهلكنا Weights & Biases
00:14:09قبل حوالي عام. يمكنك أن ترى السرعة هنا التي نحصل عليها من نشرنا وهي قريبة جداً
00:14:16مما توفره Fireworks باعتبارها سرعة Fireworks، أليس كذلك؟ لكن التقنيات الأساسية التي نستخدمها هي
00:14:21ما أود التركيز عليه أكثر هنا لتحسين الأداء. يصبح ذلك حاسماً لأنه
00:14:27في النهاية ما تريد تقديمه للعميل، وما نريد تقديمه للعميل هو ميزة السعر مقابل الأداء.
00:14:36باختصار سريع، المنصة الموحدة هي ما حاولت التركيز عليه وما أحاول إظهاره.
00:14:44نموذجان مختلفان للاستهلاك، بدون خادم (Serverless) ومخصص (Dedicated) للعملاء، وضمن نموذج بدون خادم،
00:14:49وصفت نموذجّين استهلاكيين مختلفين أيضاً، الدفع حسب الاستخدام والإنتاجية المزودة إذا كنت تهتم
00:14:53بذلك، وفي النهاية مضاعفة المكاسب من خلال تحسينات الأداء في حزمة البرمجيات.
00:15:01هذا كل شيء. شكراً لكم جميعاً.
커뮤니티 글
아직 글이 없습니다. 이 영상에 대한 첫 번째 글을 작성해 보세요!
이 영상에 대해 글쓰기