Ion Stoica والتجريدات الكامنة وراء الحوسبة الموزعة

الملخص

• Ion Stoica أستاذ في UC Berkeley ومدير Sky Computing Lab وأحد مؤسسي Conviva وDatabricks وAnyscale؛ وتعرّفه Databricks بأنه رئيس مجلس الإدارة التنفيذي.
• تنقل أبحاثه مرارًا موضع الحالة الموزعة إلى ما وراء واجهات أبسط، بدءًا من Core-Stateless Fair Queueing وChord وصولًا إلى عروض الموارد في Mesos وسلسلة الاشتقاق في Spark وRay وSkyPilot.
• أنشأت هذه الأنظمة فرق من الطلاب وأعضاء هيئة التدريس والمهندسين والمساهمين في المصدر المفتوح؛ وتراوحت أدوار Stoica بين المؤلف المشارك والمشرف ومدير المختبر والمؤسس المشارك لشركات.
• تخفف هذه التجريدات أعباء البرمجة والتشغيل من دون أن تجعل الشبكات أو المسرّعات أو السُحُب أو الأسعار أو الحوكمة متجانسة؛ فالنجاح ينشئ مستويات تحكم وتبعيات جديدة.

يبدأ النظام الموزع بجدل حول الموضع الذي ينبغي أن توجد فيه الحالة

غالبًا ما توصف الحوسبة الموزعة من خلال أدواتها: العناقيد، والمجدولات، وأنظمة التخزين، والسُحُب، والمسرّعات. لكن تحت هذه المنتجات يكمن سؤال تصميم أكثر استمرارية: أي جزء من النظام يجب أن يتذكر ماذا، وأي أطراف تستطيع العمل من دون رؤية الصورة كاملة؟

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

يبدو السجل البحثي لـIon Stoica متماسكًا على نحو لافت عند النظر إليه من خلال هذا التوتر. نقل Core-Stateless Fair Queueing تقديرات التدفقات نحو حافة الشبكة وحمل المعلومات داخل الحزم، كي لا تحتاج الموجّهات الأساسية إلى جدول لكل اتصال. وربط Chord العقد والمفاتيح بحلقة، بحيث يستطيع أحد الأطراف تحديد موقع البيانات من دون الاحتفاظ بدليل شامل. واستخدم Internet Indirection Infrastructure معرّفات الالتقاء لفصل الاتصال عن عنوان وجهة ثابت. وقدّم Mesos الموارد إلى أطر التطبيقات بدلًا من إجبار مجدول واحد على فهم كل عبء عمل. وكشف Ray المهام والكيانات الفاعلة، فيما تولى إدارة التوزيع والتعافي من الأعطال تحت مستوى التطبيق.

تختلف هذه الأنظمة في الغرض والنضج. أصبح بعضها بروتوكولات واسعة الانتشار في التدريس، لا بنية تحتية شاملة. وتحول بعضها إلى مشروعات مفتوحة المصدر. وشكل عدد منها الجذور التقنية لشركات. وكان القاسم المشترك بينها إنشاء عقد صغير قابل للتوسع عند حدّ تصبح عنده عملية التنسيق المباشر مكلفة لولا ذلك.

يجعل هذا الاستمرار Stoica منظورًا مفيدًا لفهم البنية التحتية الحديثة. لكنه ينشئ أيضًا فخًا في إسناد الفضل. فالأستاذ الذي أشرف على مشروع، والمؤلف المشارك الذي صاغ خوارزمية، ومدير المختبر الذي موّل فريقًا، والمؤسس الذي ساعد على إنشاء شركة لا يؤدون الوظيفة نفسها. لا يمكن فصل Spark عن Matei Zaharia ومجتمع AMPLab. ومن المؤلفين الرئيسيين لـRay كل من Philipp Moritz وRobert Nishihara وفريق RISELab الأوسع. وتسرد Databricks سبعة مؤسسين مشاركين. وقدمت مختبرات Berkeley الطلاب والموظفين والبرمجيات والثقافة المؤسسية التي لم يملكها فرد واحد.

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

أظهر العمل المبكر على الإنصاف كلفة نقل الحالة إلى الحافة

أكمل Stoica الدكتوراه في Carnegie Mellon University عام ٢٠٠٠، بعد دراسة سابقة في بوخارست. وقد واجه بحثه للدراسات العليا مشكلة مألوفة لكل من يبني بنية تحتية مشتركة: يكون الإنصاف أسهل عندما يتتبع النظام كل مستخدم، لكن تتبع كل مستخدم قد يمنع النظام من التوسع.

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

استكشف Dynamic Packet State وCore-Stateless Fair Queueing توزيعًا مختلفًا. فقد قدّرت أجهزة الحافة معدل التدفق ووضعت المعلومات في الحزم. وأمكن للموجّهات الأساسية استخدام تلك العلامة لاتخاذ قرارات احتمالية بإسقاط الحزم من دون الاحتفاظ بجدول كامل للتدفقات. لم يكن القلب عديم الحالة حرفيًا؛ إذ احتفظ بإعدادات مجمعة ونفّذ خوارزمية. لكنه كان عديم الحالة فيما يخص التدفقات الفردية.

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

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

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

طبقت أنظمة لاحقة المنطق نفسه على المفاتيح وموارد العناقيد وسلسلة اشتقاق البيانات ومهام الذكاء الاصطناعي. تغيرت الوحدة، وبقيت الغريزة المعمارية.

اختزل Chord نظامًا نظيرًا إلى نظير متغيرًا في حلقة

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

قدّم Chord، الذي نشره في SIGCOMM عام ٢٠٠١ فريق ضم Stoica وDavid Karger وFrans Kaashoek وRobert Morris وHari Balakrishnan، إجابة مقتصدة عمدًا. فقد جزّأ العقد والمفاتيح إلى فضاء المعرّفات نفسه، ورتبها في حلقة منطقية، وأسند كل مفتاح إلى عقدة تالية. واحتفظ كل طرف بمعلومات عن العقدة التالية مباشرة، وبمجموعة لوغاريتمية من «الأصابع» الأبعد مدى. وكان البحث ينتقل عبر معرّفات تزداد قربًا تدريجيًا حتى يصل إلى العقدة المسؤولة عن المفتاح.

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

أصبح Chord مثالًا تعليميًا مرجعيًا لأن آليته موجزة بما يكفي للاستدلال عليها، وغنية بما يكفي لكشف حقائق الأنظمة الموزعة. فالمسافة بين المعرّفات ليست زمن انتقال الشبكة؛ وقد تكون عقدة قريبة منطقيًا بعيدة ماديًا. ويقع النسخ المتماثل والتحكم في الوصول واتساق التخزين والدفاع ضد الأطراف الخبيثة خارج بروتوكول البحث الأساسي. كما يظل على التطبيق تقرير معنى المفتاح وكيفية التعامل مع البيانات غير المتاحة أو المتعارضة.

لا ينبغي الخلط بين أثر الورقة البحثية وخدمة إنتاجية واحدة أو تأليف فردي. كان Chord نتيجة عمل جماعي، وطورت جداول التجزئة الموزعة اللاحقة هياكل وخصائص أمنية بديلة. ولم يُعد معظم الإنترنت العام تنظيم نفسه في حلقة Chord واحدة.

يتمثل درسه الدائم في المعرفة المحدودة. يستطيع أحد الأطراف اجتياز نظام كبير ومتغير إذا وفرت له الطبقة الفوقية علاقة مستقرة بين الأسماء والمسؤولية. وتعمل الحلقة كتجريد تحكم فوق أجهزة تظل غير موثوقة وغير متساوية الاتصال.

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

فك Internet Indirection Infrastructure الارتباط الصارم بين العنوان ونقطة النهاية

يوجّه الإنترنت الحزم عادة نحو عنوان وجهة. ويصبح هذا النموذج مربكًا عندما يتحرك المستقبِل، أو ينبغي لعدة مستقبِلين تلقي البيانات نفسها، أو تريد خدمة الاختيار بين نقاط نهاية محتملة. استكشف Internet Indirection Infrastructure، أو i3، طبقة فوق IP يخاطب فيها المرسلون معرّفات، ويثبت المستقبِلون مشغلات تربط تلك المعرّفات بالمواقع الحالية.

فصلت نقطة الالتقاء الاسم الذي يستخدمه التطبيق عن العنوان القادر حاليًا على تلقي الحركة. وأمكن للآلية نفسها التعبير عن التنقل والبث المتعدد والبث إلى أقرب وجهة وتركيب الخدمات. وكان بوسع المستقبِل تغيير موقعه بتحديث مشغل، بدلًا من مطالبة كل مرسل بتعلم عنوان جديد.

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

لم يحل i3 محل توجيه الإنترنت المعتاد على نطاق واسع. ولا تعني هذه النتيجة أن البحث أخفق؛ بل توضح فرقًا متكررًا بين آلية ذات قدرة تعبيرية ومؤسسة قابلة للنشر. تحتاج طبقة التقاء عامة إلى مشغلين وحوافز وأمن ومسارات انتقال. وكان لدى الإنترنت القائم بالفعل تخصيص للعناوين وDNS وأنظمة لتوصيل المحتوى وحلول خاصة بالتطبيقات، ولكل منها أطراف مستثمرة فيها.

أظهر عمل Stoica حول Chord وi3 إمكان إنشاء نقاط تحكم جديدة فوق الشبكة من دون استبدال كل موجّه. وأظهر أيضًا ضرورة حوكمة نقطة التحكم الجديدة. قد توزع البرمجيات المعرّفات، لكن جهة ما تظل مسؤولة عن تشغيل العقد ووضع قواعد مكافحة الإساءة ودفع كلفة السعة.

تهم هذه الخبرة أنظمة السُحُب المتعددة اليوم. فالوسيط الذي يربط عبء عمل بمزوّد يبدو مختلفًا عن طبقة التقاء فوقية، لكنه يواجه السؤال المؤسسي نفسه. يستطيع التجريد إعادة توجيه الطلب، لكنه لا يستطيع جعل البدائل متكافئة أو ضمان بقاء الوسيط محايدًا.

جعلت Berkeley مجتمعات المصدر المفتوح جزءًا من منهج البحث

انضم Stoica إلى University of California, Berkeley، حيث أصبح عمله جزءًا من نموذج مختبري يجمع بين توجيه أعضاء هيئة التدريس وبناء الأنظمة بقيادة الطلاب والبحث المحكّم والإصدار المبكر مفتوح المصدر. تغيرت أسماء المختبرات مع تطور البرامج البحثية—AMPLab ثم RISELab والآن Sky Computing Lab—لكن المنهج ظل واضح المعالم.

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

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

يمكن لبروز Stoica عبر مشروعات عدة أن يحجب هذه البنية. كان مشرفًا ومؤلفًا مشاركًا في التاريخ الأكاديمي لـSpark، لكن Matei Zaharia قاد العمل الأصلي وأصبح شخصية تقنية وتجارية محورية. وظهر Ray من عمل Philipp Moritz وRobert Nishihara وفريق أوسع. وكان لـMesos عدة مصممين رئيسيين. لا تنتقص الرواية الدقيقة من دور Stoica؛ بل تحدد ما تفعله قيادة المختبر فعلًا.

أنشأ نموذج Berkeley أيضًا نوعًا معينًا من الشركات. لم تبدأ Databricks وAnyscale بإخفاء بروتوكول وبيع حق الوصول إليه، بل نشأتا حول أنظمة مفتوحة المصدر كان المستخدمون قادرين بالفعل على تشغيلها. وتمثلت الفرصة التجارية في جعل تلك الأنظمة أسهل تشغيلًا ودمجًا ودعمًا على نطاق واسع.

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

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

لم تنتشر Chord وSpark وMesos وRay من خلال البرمجيات وحدها، بل من خلال مفردات أيضًا. فقد منحت الحلقات وسلسلة الاشتقاق وعروض الموارد والمهام والكيانات الفاعلة المهندسين مفاهيم لوصف السلوك الموزع. ويصبح النظام أسهل تبنيًا عندما تستطيع الفرق الاستدلال عليه من دون تعلم كل مكوّن داخلي أولًا.

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

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

يعترف انتخاب Stoica عام ٢٠٢٤ لعضوية National Academy of Engineering بسجل تراكمي في الأنظمة الموزعة والسحابية. ولا يعيد التكريم توزيع الفضل بعيدًا عن المتعاونين، بل يعكس دور باحث ساعد على جعل عدة حدود صعبة في الأنظمة واضحة بما يكفي كي يبني الآخرون عليها.

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

اختبرت Conviva قدرة أبحاث الأنظمة الموزعة على تحسين جلسة فيديو

شارك Stoica في تأسيس Conviva عام ٢٠٠٦، قبل شركات البيانات والذكاء الاصطناعي اللاحقة في Berkeley. عالجت الشركة مشكلة تربط الشبكات والقياس وتجربة التطبيقات: تعتمد جودة البث على سلسلة لا يراها أي طرف كاملًا. ويمكن لاتصال المشاهد ومسار توصيل المحتوى وسلوك المشغّل والجهاز ومزوّد المحتوى أن تؤثر جميعًا في التوقفات وزمن البدء.

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

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

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

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

حوّل Mesos الجدولة إلى تفاوض على الموارد

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

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

جعل هذا التصميم ثنائي المستوى العقدة الرئيسية وسيطًا بدلًا من عقل شامل لكل التطبيقات. واستطاع Hadoop وMPI وغيرهما من الأطر مشاركة عنقود من دون التخلي عن منطق الجدولة لديها. واحتفظ مشغّل العنقود بالسياسة من خلال التخصيص والحصص وآليات الإنصاف، بينما احتفظت الأطر بمسؤولية تحديد المهام الملائمة للعرض.

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

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

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

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

ساعد Mesos على ترسيخ فكرة أن العنقود يمكن أن يكون منصة للمنصات. واستفاد Spark من تلك البيئة بمنح تطبيقات البيانات تجريدًا آخر أعلى مستوى.

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

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

ترث المجدولات الحديثة المشكلة نفسها حتى عندما تتغير الواجهة. وينبغي للتوزيع الآلي كشف الهدف والاستثناءات، بدلًا من تقديم اختياره على أنه الإجابة الوحيدة الكفؤة.

يوضح تاريخ أنظمة Stoica أن قابلية التوسع تأتي غالبًا من نقل القرارات إلى حدّ معين. أما الحوكمة فتتطلب تسمية القرار الذي يبقى في المركز. فلا بد أن تظل جهة ما مسؤولة عن تحديد من يتلقى العرض.

تعامل Spark مع البيانات الوسيطة المفقودة بوصفها حسابًا قابلًا للتكرار

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

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

ظهر Spark من عمل Matei Zaharia مع مجتمع AMPLab في Berkeley، بما في ذلك Stoica ومتعاونون كثر. وشمل تطوره اللاحق إلى SQL والبث والتعلم الآلي ومنصة بيانات واسعة مجتمعًا مفتوح المصدر أكبر بكثير. ووصفه بأنه اختراع Stoica سيمحو الأشخاص الذين قادوا النظام وصانوه.

يهم دوره على المستوى المؤسسي. دعم المختبر المشروع، وساعد على صياغة أسئلة الأنظمة، وربط البحث بالمستخدمين. وأصبح Stoica واحدًا من سبعة مؤسسين مشاركين لـDatabricks عند تأسيس الشركة عام ٢٠١٣. وقدمت Databricks مسارًا مُدارًا للمؤسسات التي أرادت قدرات Spark من دون تجميع الحزمة التشغيلية كاملة بنفسها.

توسعت المنصة التجارية لاحقًا إلى ما هو أبعد بكثير من الورقة الأصلية عن RDDs. وأصبحت حوكمة البيانات ومعمارية lakehouse والتعلم الآلي وخدمات الذكاء الاصطناعي والأمن والتكامل السحابي أجزاء من المنتج. ولا يجوز استخدام الحجم الحالي للشركة مقياسًا دقيقًا لمساهمة ورقة واحدة أو مؤسس واحد.

يمثل Spark مع ذلك نقطة تحول في مسيرة Stoica. فلم يعد التجريد متعلقًا أساسًا بحزم الشبكة أو البحث بين النظراء، بل بعنصر البيانات الذي يراه المبرمج وخطة التعافي التي يراها وقت التشغيل. وأتاحت سلسلة الاشتقاق للنظام إخفاء تعطل الأجهزة خلف تاريخ حتمي للتحويلات.

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

أظهر Alluxio كيف يمكن لموقع البيانات أن يهيمن على تجريد الحوسبة

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

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

يوضح المشروع كيف يكشف تجريد واحد الحاجة إلى تجريد آخر. شارك Mesos الحوسبة بين الأطر، وجعل Spark المجموعات الموزعة قابلة للبرمجة، وعالجت طبقة بيانات مشتركة كلفة نقل مجموعات العمل بين المحركات والتخزين. ومع نمو الحزمة، ازداد عدد مستويات التحكم التي يمكن أن تختلف بشأن قرب البيانات والإخلاء والتعافي.

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

لا ينبغي إسناد إنشاء Alluxio إلى Stoica وحده. وتكمن صلته بالقصة في المفهوم: فقد وجدت مجموعة مشروعات Berkeley مرارًا واجهة مفقودة بين أنظمة قابلة للبرمجة منفردة، لكنها غير كفؤة مجتمعة. جعلت كل طبقة جديدة الكل أسهل استخدامًا، وأدخلت خدمة أخرى ذات حالة يتعين إدارة فشلها وسياساتها.

حوّلت Databricks تبني المصدر المفتوح إلى التزام تشغيلي تجاري

تستطيع الورقة البحثية وصف آلية وتقييمها تحت أعباء عمل مختارة. أما الشركة فعليها دعم آلاف العملاء الذين لا تشبه بياناتهم ومتطلباتهم الأمنية وأنماط فشلهم بيئة اختبار الورقة. وتمثل Databricks أوضح مثال في سجل Stoica على هذا التوسع المؤسسي.

أسست الشركة مجموعة ضمت Ali Ghodsi وMatei Zaharia وIon Stoica وزملاء آخرين من Berkeley. وتعرّف مواد الشركة الحالية Stoica بأنه مؤسس مشارك ورئيس مجلس الإدارة التنفيذي. وهذا المنصب مختلف عن منصب الرئيس التنفيذي أو مشرف صيانة المشروع أو مؤلف كل منتج؛ إذ يضعه في حوكمة الشركة واستراتيجيتها الطويلة الأجل، ولا يجعله مشغّل كل خدمة.

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

هذه هي الاقتصاديات المعتادة لشركة بنية تحتية مفتوحة المصدر. يخفض المشروع المشترك كلفة التبني ويمنح المستخدمين، من حيث المبدأ، مسارًا للخروج. وتحقق الخدمة المُدارة الإيرادات عبر تسهيل التشغيل وإضافة قدرات قد لا تنتقل بسهولة إلى مكان آخر. يكسب العملاء الإنتاجية، فيما يقبلون علاقة مع مزوّد.

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

التقييمات الاستثمارية وجولات التمويل أدلة ضعيفة على المساهمة التقنية. فهي تتغير سريعًا وتخص الشركة، ولا تعود تلقائيًا إلى مؤسس واحد. والخلاصة القابلة للدفاع أضيق: توضح Databricks أن تجريد تحكم أكاديميًا يمكن أن يصبح مركز منصة مؤسسية كبرى عندما تتحمل مؤسسة العمل اللازم لإبقائه موثوقًا.

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

جعل Ray المهام والكيانات الفاعلة وحدة وقت تشغيل للذكاء الاصطناعي

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

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

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

كانت ورقة Ray المنشورة في OSDI عام ٢٠١٨ نتاج فريق في RISELab التابع لـBerkeley، وكان من المؤلفين الرئيسيين Philipp Moritz وRobert Nishihara. واكتسب المشروع مجتمعًا مفتوح المصدر، وأصبح عدد من المساهمين مؤسسين مشاركين لـAnyscale مع Stoica. ويهم حد الإسناد لأن تطبيق Ray العملي وخريطة طريقه الحالية يمتدان إلى ما هو أبعد كثيرًا من مشرف أكاديمي واحد.

يوضح Ray تحولًا آخر في موضع الحالة. يسمّي التطبيق المهام والكيانات الفاعلة والكائنات بدلًا من الأجهزة. وتحافظ مكونات التحكم الشامل والجدولة المحلية في وقت التشغيل على معرفة تكفي لتوزيع العمل والتعافي من الأعطال. ويتخلى المبرمج عن التحكم المباشر في المضيف مقابل وحدة تركيب أكثر فائدة.

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

لذلك لا تكمن أهمية Ray في جعله الذكاء الاصطناعي الموزع بسيطًا، بل في جعله فئة واسعة من تطبيقاته قابلة للبرمجة عبر مفاهيم مشتركة، مع تركيز العمل الصعب في وقت تشغيل يتعين على المؤسسات تعلم تشغيله.

سوّقت Anyscale نظام Ray من دون أن تصبح هي مجتمع Ray

تأسست Anyscale عام ٢٠١٩ كشركة تجارية حول Ray. وتشبه العلاقة مسار Spark إلى Databricks السابق، لكنها ليست المؤسسة نفسها ولا السوق نفسها. ويظل Ray نظامًا مفتوح المصدر له مساهمون ومستخدمون خارج الشركة، فيما تقدم Anyscale التشغيل المُدار والتكامل المؤسسي والدعم.

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

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

تضيف الخدمة أيضًا طبقة تحكم بين المستخدم والسحابة الأساسية. فهي تقرر كيفية تحزيم وقت التشغيل والميزات المدعومة وكيفية التعامل مع القياسات التشغيلية والترقيات. وقد يظل العميل قادرًا على تشغيل Ray مستقلًا، بينما يصبح معتمدًا على مسارات العمل المُدارة وعمليات الدمج والمعرفة التشغيلية المتراكمة حول الخدمة.

يربط دور Stoica كمؤسس مشارك النظام البحثي بهذه المؤسسة التجارية. لكنه لا يثبت مسؤوليته الحالية عن كل قرار متعلق بالمنتج، وينبغي أخذ الألقاب التشغيلية الدقيقة من صفحات الشركة الحالية. والحقيقة المستقرة هي أنه ساعد على تأسيس الشركة مع انتقال المشروع إلى الاستخدام الإنتاجي.

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

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

تتفاوض حوسبة السماء بين سُحُب تظل مختلفة

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

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

لا يستطيع النظام تحويل السُحُب إلى سلع قابلة للاستبدال. فقد يُحاط نوع من المسرّعات بشبكات أو تخزين مختلفين. وقد لا يكون لقاعدة بيانات مُدارة أو خدمة هوية مقابل مباشر في مكان آخر. ويمكن لجاذبية البيانات أن تطغى على سعر الحوسبة. كما تغير رسوم خروج البيانات والالتزامات التعاقدية ما يبدو أنه التوزيع الأرخص. وقد لا تكون الحصة الموجودة على الورق متاحة عند بدء المهمة.

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

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

يربط موقع Stoica البحثي الحالي العمل السابق على البحث الموزع وجدولة العناقيد بهيكل السوق هذا. وأصبحت وحدة التخصيص الآن أسطولًا من المسرّعات تملكه شركات منفصلة. ويتعين على مستوى التحكم مراعاة المال والتنظيم والسياسة المؤسسية، إلى جانب CPU والذاكرة.

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

نقل vLLM وChatbot Arena المختبر نحو مركز بنية الذكاء الاصطناعي التحتية

تسرد صفحة Stoica الحالية في Berkeley مشروعات تشمل vLLM وChatbot Arena وSkyPilot وRay وSpark. وتبين القائمة اتساع برنامج Sky Computing Lab، لكن لا ينبغي قراءتها كادعاء بأن المدير صمم كل نظام بنفسه.

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

يستخدم Chatbot Arena مقارنات التفضيلات البشرية لتقييم مخرجات النماذج. وينشئ أدلة مشتركة في سوق ينشر فيه المورّدون غالبًا اختبارات معيارية منتقاة. وتواجه المنصة أيضًا مشكلات أخذ العينات والتمثيل وإساءة الاستخدام والحوكمة. فالترتيب ملاحظة من مجموعة سكانية وفترة محددتين، وليس مقياسًا دائمًا للقدرة المعرفية أو السلامة.

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

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

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

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

قسّم Kubernetes مشكلة التحكم بدلًا من أن يحل محل Mesos أو Ray

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

قد تتداخل هذه الأنظمة، لكنها لا تطرح السؤال نفسه. يستطيع منظم الحاويات ضمان تشغيل عقدة Ray الرئيسية وأسطول العاملين. ومع ذلك يظل Ray مسؤولًا عن تقرير موضع تنفيذ مهام التطبيق وكيفية توزيع الكيانات الفاعلة ذات الحالة. وقد يختار مجدول سحابي المنطقة قبل بدء أي من النظامين. وتشكل الأنظمة تسلسلًا هرميًا لمستويات التحكم، لا استبدالًا مباشرًا.

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

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

بالنسبة إلى المؤسسات التي تختار المنصات، ليست الرائجة منها هي الاختبار الصحيح. السؤال الحقيقي هو: أي طبقة ينبغي أن تمتلك كل قرار، وكيف ستُرصد التعارضات؟ قد يجمع تشغيل Ray فوق Kubernetes بين إدارة ناضجة للبنية التحتية ووقت تشغيل للتطبيقات، لكنه يتطلب أيضًا من الفرق فهم كليهما. انتقل العبء التشغيلي من كتابة مجدول إلى حوكمة الحد الفاصل بين المجدولات.

جدولة الذكاء الاصطناعي قرار لتخصيص رأس المال أيضًا

يغير عبء عمل الذكاء الاصطناعي الحالي الاقتصاديات الكامنة خلف سؤال Stoica البحثي الطويل. يمكن لعنقود CPU أن يهدر الموارد ويواصل إنجاز عمل مفيد. أما أساطيل المسرّعات الكبيرة فمكلفة إلى درجة تجعل التوزيع السيئ أو الذاكرة العاطلة أو توقف عملية جماعية ذا عواقب مالية وطاقية فورية.

يستطيع وقت تشغيل مثل Ray أو محرك استدلال مثل vLLM تحسين الاستفادة عبر حزم العمل ومشاركة الحالة والتكيف مع الطلب. كما تستطيع أداة عابرة للسُحُب البحث عن المسرّعات النادرة. وتخصص هذه القرارات أكثر من وقت الأجهزة؛ إذ تحدد المزوّد الذي يتلقى الإنفاق، والموضع الذي تنتقل إليه البيانات، وقيود الطاقة والشبكة التي تُستخدم.

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

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

يلائم تقليد Stoica في التجريد هذه البيئة لأنه يبحث عن واجهة ضيقة لموارد غير متجانسة. وتكمن المخاطرة في أن الواجهة تخفي إدارة الندرة ذاتها التي تحتاج فرق الإدارة إلى حوكمتها. فلا يكفي طلب «مسرّع» عندما يحدد حجم الذاكرة والترابط وإصدار البرمجيات وعقد التوريد إمكان التنفيذ.

سيجعل النظام الدائم التالي الطلب بسيطًا، مع إبقاء المقايضات قابلة للفحص. وهذا هدف أصعب من الجدولة التلقائية؛ فهو يتعامل مع برمجيات البنية التحتية بوصفها جزءًا من الحوكمة المالية والطاقية، لا مجرد أداة للمطورين.

التعافي من الأعطال هو العقد المخفي المشترك بين الأنظمة

تختلف التجريدات في مسيرة Stoica في كيفية استجابتها لاختفاء أحد المكونات. يصلح Chord حالة التوجيه بعد مغادرة عقدة. ويستطيع Spark إعادة بناء بعض الأقسام المفقودة من سلسلة الاشتقاق. ويمكن لـRay إعادة محاولة المهام وإعادة إنشاء الكيانات الفاعلة في ظل شروط يحددها التطبيق. ويستطيع مشغّل متعدد السُحُب تجربة منطقة أخرى عند غياب السعة. وفي كل حالة لا تكون الواجهة موثوقة إلا إذا كان نموذج الفشل صريحًا.

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

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

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

غالبًا ما يُحتفى بالأنظمة المرتبطة بـStoica لسرعتها أو نطاقها. لكن إنجازها المشترك الأعمق هو جعل الفشل الجزئي حدثًا قابلًا للبرمجة بدلًا من لغز استثنائي. وتبقى مخاطرة أن تشجع سهولة واجهة التعافي المستخدمين على افتراض قدرات تتجاوز ما يستطيع التطبيق تقديمه بأمان.

تتسرب التجريدات عبر الأداء والكلفة والأمن

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

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

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

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

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

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

يتيح التجريد للتطبيق تسمية مهمة أو كيان فاعل أو مجموعة بيانات بدلًا من مضيف. ثم يحتفظ وقت التشغيل ببيانات الاعتماد وحالة التوزيع وسلطة بدء البرمجيات عبر أجهزة كثيرة. وقد يكون اختراق مستوى التحكم أكثر قيمة من اختراق عامل واحد.

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

يمكن لوضوح المصدر المفتوح تحسين المراجعة، ويمكن للتشغيل المُدار تطبيق التصحيحات والمراقبة باتساق. ولا يضمن أي منهما سلامة الإعدادات. فقد تعرض منصة وقت تشغيل آمنًا من خلال حساب خدمة واسع الصلاحيات، أو يعزل مستخدم العاملين ويترك المجدول مسارًا منفردًا عبر المستأجرين.

ينبغي أن يتبع نموذج الأمن التجريد. فإذا كانت المهمة وحدة العمل، وجب أن تكون الهوية والسياسة قابلتين للتعبير على ذلك المستوى، بدلًا من أن ترثا إعدادات العنقود بلا تمييز. وإذا كان الوسيط قادرًا على الاختيار بين السُحُب، فلا ينبغي أن تمنحه بيانات اعتماده سلطة غير محدودة في كل منها.

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

يوزع المصدر المفتوح حقوق التأليف، بينما تركز الشركات مسؤولية التشغيل

تمتد المشروعات المرتبطة بـStoica عبر نماذج حوكمة عدة. ينتمي Apache Spark إلى عملية مجتمع Apache Software Foundation. وRay مشروع مفتوح المصدر له مشرفو صيانة ومنظومة تجارية. وقد لا تملك النماذج البحثية الأولية مؤسسة دائمة بعد نشر الورقة. أما Databricks وAnyscale فشركتان مسؤولتان أمام العملاء والموظفين والمستثمرين.

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

تعبر مسيرة Stoica النماذج الثلاثة. وهذا يمنحه تأثيرًا غير معتاد، وينشئ حاجة إلى وصف أدواره بدقة. فقد يملك المؤسس حصة ومنصبًا في مجلس الإدارة من دون صيانة مستودع المصدر المفتوح. ويستطيع الأستاذ الإشراف على بحث يقود الطلاب تطبيقه. ويمكن لرئيس مجلس الإدارة التنفيذي التأثير في الاستراتيجية من دون أن يكون الرئيس التنفيذي.

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

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

لا توجد صيغة دائمة، بل يجب حوكمة الحد مشروعًا تلو الآخر. ويوضح سجل Stoica لماذا يمكن لمسار البحث إلى الشركة إنتاج بنية تحتية دائمة، ولماذا ينبغي ألا يُفهم على أنه نقل بسيط للملكية من المختبر إلى المؤسس.

يستند تأثير Stoica إلى حدود استطاعت مجتمعات أخرى البناء عليها

قد يحوّل سرد Chord وMesos وSpark وRay المسيرة إلى قائمة من الأسماء الشهيرة. لكن الرابط الأكثر فائدة معماري: فقد حدد كل نظام موضعًا يمكن فيه تمثيل التعقيد الموزع من خلال عقد أصغر.

طلب الإنصاف عديم الحالة في القلب من الحافة حمل معلومات لا يستطيع القلب تحمل كلفة الاحتفاظ بها. واستخدم Chord توزيعًا متسقًا وحالة توجيه جزئية بدلًا من دليل شامل. وقدّم Mesos الموارد بدلًا من فرض طريقة تنفيذ كل مهمة. وسجل Spark سلسلة الاشتقاق بدلًا من نسخ كل نتيجة وسيطة. وكشف Ray المهام والكيانات الفاعلة بدلًا من الأجهزة. ويعبّر SkyPilot عن احتياجات عبء العمل، ثم يتفاوض بين المزوّدين.

لا يكتمل أي من هذه التجريدات. يفترض كل منها مكونات متعاونة وبيانات وصفية دقيقة ومؤسسة مشغّلة. وقد يفشل كل منها عندما تتصرف الطبقة المخفية على نحو يخالف النموذج. ويأتي نجاحها من فائدتها رغم هذه الحدود.

تختلف مساهمة Stoica عبر هذه السلسلة، وتستحق الفرق فضلًا محددًا. ويتمثل دوره الدائم في كونه باحثًا وباني مؤسسات ساعد على تحويل هذه الحدود إلى مشروعات ومختبرات وشركات. انتخبته National Academy of Engineering عام ٢٠٢٤ تقديرًا لسجل أوسع في الأنظمة الموزعة والسحابية؛ والتكريم للشخص، بينما تظل الأنظمة إنجازات جماعية.

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

سيُحكم على الجيل التالي من تقليد Stoica البحثي بحسب قدرة تجريداته على البقاء قابلة للفحص عندما تعبر السُحُب والشركات. البرمجة قيّمة لأن المستخدمين لا يحتاجون إلى معرفة كل جهاز. أما القدرة على الصمود فتتطلب أن يظلوا عارفين بمن يتخذ القرارات التي لم يعودوا يتخذونها بأنفسهم.