نشر الأسطول: روبوتات متعددة، حوسبة مشتركة

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

تناولت المقالة I01 مشكلة الصندوقين لروبوت واحد وخادم واحد. وتناولت المقالة K03 كيفية تقسيم vLLM للنموذج عبر وحدات معالجة الرسومات. أما المقالة R08 فقد أوضحت أهمية استخدام البنية التحتية المحلية. تستند هذه المقالة إلى المقالات الثلاث السابقة وتجيب على السؤال التالي: إذا أردت تكرار العملية N مرة، فما الذي سيتعطل؟

الأنظمة الثلاثة

توجد ثلاثة أنظمة مهمة لحجم الأسطول. والانتقالات بينها تشغيلية وليست تقنية - فالأجهزة تبدو متشابهة، لكن طريقة تشغيلها مختلفة.

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

اقتصاديات الحوسبة - ما الذي يخدمه نظام الذكاء الاصطناعي Kentino ذو 8 وحدات معالجة رسومية فعليًا

الرقم الذي يجب أن يُحدد حجم النظام هو عدد طلبات VLM المتزامنة في الثانية لكل روبوت ، وليس عدد الروبوتات لكل خادم. الروبوت ليس حملاً ثابتاً، بل هو فئة من أحمال العمل. مهمة الانتقاء بتردد 2 هرتز تختلف عن مهمة الملاحة بتردد 0.5 هرتز، والتي بدورها تختلف عن وكيل الحوار بتردد 0.2 هرتز.

أظرف تقريبية لمعالج Kentino AI 256 ثماني وحدات معالجة رسومية مع 8 وحدات RTX 5090 (FP8 / INT4 vLLM، نموذج واحد، تجميع مستمر، ذاكرة تخزين مؤقتة للبادئة؛ انظر I02 و K03 ):

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

نادرًا ما يعتمد نظام تشغيل حقيقي على نموذج واحد فقط. عادةً ما يحتاج أسطول من الروبوتات التي تؤدي مهامًا مفيدة إلى وحدة معالجة رسومية افتراضية (VLM) بسعة 72 بت لتحليل المشهد، ووحدة معالجة رسومية خطية (LLM) بسعة 32 بت للتخطيط، ووحدة معالجة رسومية خطية صغيرة (VLA) للتحكم الدقيق في الحركة. يعمل نظام الذكاء الاصطناعي "كينتينو" (Kentino) ذو 8 وحدات على تشغيل هذه الوحدات الثلاث في وقت واحد. مع هذا المزيج، فإن الحد الأقصى الواقعي على خادم واحد هو 4-6 روبوتات بشرية تقوم بمهام VLM ذات حلقة مغلقة . هذا هو العدد الذي يجب التخطيط بناءً عليه، وليس الرقم المتفائل "لقد قمنا بقياس 24 طلبًا متزامنًا بسعة 7 بت".

آلية التجميع (ولماذا الأساطيل رخيصة)

يكمن سر تفوق خادم واحد كبير على العديد من الخوادم الصغيرة في المعالجة الدفعية المستمرة . يحتفظ vLLM بمجموعة متجددة من الطلبات قيد المعالجة؛ ففي كل دورة معالجة، تُحذف الطلبات المكتملة وتُضاف الطلبات الجديدة. تُظهر الاختبارات المعيارية العامة أن vLLM يحقق إنتاجية أعلى بمقدار 2.3 مرة من استدلال توليد النصوص، و14-24 مرة من PyTorch البسيط على نفس الجهاز، وذلك تحديدًا بفضل هذه الميزة.

بالنسبة لأسطول من الروبوتات، يتضاعف التأثير. خمسة روبوتات تصل إلى نفس نقطة نهاية VLM بمطالبات مماثلة تنتج نمط تجميع مثالي تقريبًا: تشترك معظم الطلبات في مطالبة نظام طويلة (معدل نجاح ذاكرة التخزين المؤقت للبادئة 80-95٪)، وأوقات الوصول غير مرتبطة بشكل كافٍ بحيث تظل الدفعة ممتلئة، ويتم استهلاك تكلفة كل طلب مقابل عمل التعبئة المسبقة المشتركة.

1 robot   = 1.00× compute baseline
2 robots  = ~1.6× compute (batching helps)
4 robots  = ~2.5× compute
8 robots  = ~4.0× compute

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

بعد الثامنة، ستحتاج إلى خادم ثانٍ على أي حال، ويصبح السؤال هو كيفية تقسيم حركة المرور - وهو ما سيتم تناوله أدناه.

بنية أسطول من 3 إلى 8 روبوتات

ثلاث طبقات على مضيف مادي واحد (أقل من 8 روبوتات تقريبًا): إدارة الأسطول، والتنسيق، والاستدلال. كل منها مستقل منطقيًا؛ يتم توزيعها على مضيفين يتجاوز هذا الحجم.

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

توجيه الطلبات: ما الذي يقف أمام vLLM

يعمل إعداد بسيط بنقطة نهاية vLLM واحدة، وأربعة روبوتات، وبروتوكول TCP بالتناوب لمدة أسبوع، ثم يتعطل عند أول طلب يستغرق 8 ثوانٍ، وتتأخر الطلبات الأربعة التالية في قائمة الانتظار. الموجه هو ما يمنع حدوث ذلك.

ثلاثة خيارات، مرتبة حسب درجة التعقيد:

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

vLLM Router (Rust، تم إصداره في أواخر عام 2025). يتم استخدام التجزئة المتسقة على بادئة الموجه، بحيث تصل المحادثة نفسها إلى النسخة نفسها ويبقى مخزن البادئة نشطًا. بالنسبة لأسطول حيث يمتلك كل روبوت محادثته الخاصة، لكنهم جميعًا يشتركون في موجه نظام طويل، يُعد هذا الخيار الأمثل. السياسات هي cache_aware, power_of_twoو round_robin; خاصية "الوعي بالتخزين المؤقت" هي الوضع الافتراضي لأسطول الإنتاج.

llm-d على Kubernetes. يوفر تفكيك البيانات المسبق/فك التشفير، وجدولة النسخ المتعددة، وامتدادات استنتاج البوابة. إنه الحل الأمثل عند وجود 4 نسخ أو أكثر، وأنواع نماذج مختلطة، وفريق عمليات متخصص في Kubernetes. أما في الحالات الأخرى، فهو حل مبالغ فيه.

تُعدّ مسألة تقارب الجلسات مسألة دقيقة. يستفيد الروبوت الذي يتواصل مع وكيل التخطيط من التوجيه الثابت إلى نفس النسخة (ذاكرة التخزين المؤقت للبادئة). أما الروبوت الذي يُطلق علامات مشهد VLM لمرة واحدة، فلا يستفيد من ذلك، لأنها عديمة الحالة، ويتم توجيهها بالتناوب. الحل الأمثل هو التوجيه حسب نوع الطلب، وليس حسب العميل : التخطيط إلى التوجيه المُراعي لذاكرة التخزين المؤقت، ووضع علامات المشهد إلى التوجيه بالتناوب. يدعم مُوجِّه vLLM كلا النوعين من خلال سياسة لكل نقطة نهاية.

ذاكرة المشهد: حيث يوجد سياق كل روبوت

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

ثلاثة أنماط:

الخيار أ - استخدام pgvector لكل روبوت على الخادم. يمتلك كل روبوت مجموعته الخاصة في نسخة مشتركة من Postgres+pgvector. الذاكرة متينة، ويمكن الاستعلام عنها من جانب الخادم، كما يمكن الوصول إليها لإدارة الأسطول. يتميز هذا الخيار بالبساطة، وقابلية التوسع لتشمل عشرات الروبوتات على قاعدة بيانات Postgres واحدة. لكن الخصوصية هي نقطة الضعف: فكل بايت من ذاكرة كل روبوت مركزي.

الخيار ب - ذاكرة المشهد على الروبوت مع إرسال RAG إلى الخادم. يحتفظ الروبوت بتضميناته الخاصة في مخزن محلي باستخدام SQLite-VSS أو DuckDB. عند الاستعلام من خادم VLM، يرسل أجزاء البيانات المسترجعة ذات الصلة كجزء من الطلب. الذاكرة محلية وخاصة؛ ولا ترى الشبكة إلا ما اختار الروبوت إرساله. يُعد هذا الخيار أفضل للتطبيقات الحساسة (الطبية، الدفاعية، وأي مكان لا يرغب فيه المشغل بمغادرة الذاكرة الخام من الروبوت). ولكنه يستهلك نطاقًا تردديًا أكبر للشبكة لكل استدعاء.

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

الخيار الافتراضي الأمثل لأسطول روبوتات يتراوح عدده بين 3 و8 روبوتات هو الخيار ج مع تحكم صارم في الوصول ؛ حيث تكتب الروبوتات في مساحة اسمها الخاصة، وتقرأ من مساحة اسم "عالم" مشتركة تخضع للمراجعة (يقوم مدير الأسطول بترقية الملاحظات إليها بعد التحقق من صحتها). أما بالنسبة لعمليات النشر التي تتطلب مراعاة الخصوصية، فيُفضل الخيار ب. يُعد الخيار أ هو الأسهل والأكثر ملاءمةً إذا لم يكن التعاون شرطًا أساسيًا.

استراتيجيات تبادل النماذج

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

حالتان ينهار فيهما النظام:

رؤوس مُعدّلة بدقة لكل روبوت. يوجد الروبوت 1 في المستودع وهو مُعدّ خصيصًا للتعامل مع المنصات. أما الروبوت 2 فيوجد في المختبر وهو مُعدّ خصيصًا للتعامل مع الأجهزة. يتم تشغيل نفس قاعدة VLM مع تحميل محولات LoRA مختلفة لكل طلب. يدعم vLLM خدمة LoRA المتعددة (--enable-lora --max-loras Nمع تكلفة إضافية بسيطة لكل طلب وتجميع نماذج أساسية مشتركة. مفيد عندما تكون عمليات الضبط الدقيق 0.1-1% من الأوزان الأساسية (وهو أمر شائع في LoRA) ولديك من 2 إلى 10 محولات مختلفة.

نماذج متخصصة لكل فئة مهمة. نموذج مختلف لكل مهمة - Qwen2.5-VL للاستدلال العام على المشهد، وOpenVLA للإمساك، و7B مُحسَّن للحوار. يحصل كل نموذج على نقطة نهاية vLLM خاصة به على شريحة GPU مستقلة. يتم التوجيه حسب نوع الطلب. ذاكرة وصول عشوائي للفيديو أكبر، وتجميع أقل لكل نموذج، ومساحة تشغيل أكبر. الإجابة الصحيحة تأتي بعد التأكد من عدم قدرة نموذج واحد على أداء المهمة، وليس قبل ذلك.

ابدأ بنموذج واحد. أضف محولات LoRA عندما يكون لديك فجوة جودة مُقاسة لكل روبوت. أضف نماذج متخصصة عندما يكون لديك فجوة مُقاسة لكل مهمة لا تستطيع LoRA سدّها.

إدارة أسطول الروبوتات (RFM) - اختر منتجًا

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

تتولى إدارة Open-RMF تحالف الروبوتات مفتوحة المصدر منذ عام 2024، وهي مسؤولة عن توزيع المهام، وحل النزاعات، وإدارة البنية التحتية المشتركة (المصاعد، والأبواب، والممرات). بالنسبة لتطبيقات كينتينو المحلية التي تضم روبوتات من موردين مختلفين - على سبيل المثال، روبوت Unitree G1 واحد، وروبوت Booster T1 واحد، وروبوت Go2 رباعي الأرجل، جميعها في نفس الموقع - فإن Open-RMF هو الخيار المفتوح الوحيد الموثوق. صحيح أن Formant وOrbit ممتازتان، لكنهما برمجيات كخدمة (SaaS) وتفضلان بيئتهما الخاصة.

الخيار الافتراضي الأمثل: Open-RMF للأنظمة المحلية متعددة الموردين، وFormant للأنظمة المستضافة التي تتطلب مراقبة مكثفة، وOrbit لأنظمة Boston Dynamics فقط. بناء RFM خاص بك ليس خيارًا مناسبًا إلا إذا كنت تبيع RFM كمنتج بشكل صريح.

تنسيق الروبوتات المتعددة على السلك

مساحات الأسماء في ROS 2. يقوم كل روبوت بتشغيل حزمة ROS 2 الخاصة به ضمن مساحة اسم فريدة (/r01/, /r02/...). يتم أيضًا تنظيم مواضيع وخدمات ومعلمات DDS ضمن مساحات أسماء. تشترك الروبوتات في مواضيع حالة النظراء (/r02/pose, /r03/poseيتم الاتصال مباشرةً عبر DDS، بدون وسيط. نظام DDS في ROS 2 يعمل بنظام الند للند ويتوسع بكفاءة ليشمل عشرات الروبوتات على شبكة محلية واحدة؛ ولكن بعد حوالي 50 روبوتًا، يصبح تدفق بيانات الاكتشاف مزدحمًا، وفي هذه الحالة يُفضل تقسيم الشبكة حسب معرّف نطاق DDS أو الانتقال إلى وضع خادم الاكتشاف في ROS 2.

يُستخدم بروتوكول MQTT لنقل بيانات القياس عن بُعد، بينما تُستخدم الأوامر. يُعدّ نظام ROS 2 / DDS مثاليًا لنقل بيانات حالة الأجهزة عبر الشبكة المحلية (LAN) بزمن استجابة منخفض. لكنه غير مناسب لإرسال بيانات قياس حالة الأجهزة بتردد 0.5 هرتز إلى سحابة إدارة الأسطول عبر شبكة LTE غير مستقرة. يُعدّ MQTT الأداة الأمثل لذلك، فهو خفيف الوزن، ويعمل عبر وسيط، ويدعم مستويات جودة الخدمة (QoS) لضمان التسليم، كما أنه مدعوم بشكل أصلي في جميع منصات إدارة الأساطيل. عادةً ما يتم استخدام DDS على الشبكة المحلية، وMQTT (أو HTTPS) على الشبكة الواسعة (WAN).

توزيع المهام. نهجان مستخدمان فعلياً في أساطيل عام 2026:

1. المنسق المركزي. يُسند مدير الأسطول المهام بناءً على توافر الروبوتات، وحالة البطارية، والموقع، والقدرات. نظام بسيط، قابل للتنبؤ، يُناسب 90% من الحالات. يوفر Open-RMF هذه الميزة بشكل افتراضي.
2. يعتمد على المزاد. تتنافس الروبوتات على المهام بناءً على دالة التكلفة (المسافة، البطارية، الحمل الحالي). يفوز صاحب أقل عرض. يُعد هذا الأسلوب أفضل للأسطول غير المتجانس أو البيئات الديناميكية. تُظهر الدراسات الحديثة أن أساليب المزاد تُحقق وفورات في الطاقة تصل إلى 12% تقريبًا مقارنةً بتخصيص المهام الأقرب، وذلك في أساطيل تتراوح بين 2 و20 روبوتًا. يستحق هذا الأسلوب التعقيد في أساطيل تضم 10 روبوتات أو أكثر، بينما يُعتبر مبالغًا فيه في الأساطيل الأصغر.

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

معالجة الأعطال على نطاق الأسطول

المبدأ بسيط: يجب عزل الأعطال، ومعالجة حالات التدهور بسلاسة، والتعافي تلقائيًا. الأنماط العملية:

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

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

تحديث خادم الاستدلال بشكل متواصل. يوجد نسختان متماثلتان خلف موجه vLLM؛ يتم تفريغ إحداهما، ثم إعادة نشرها، والتحقق منها، ثم تفريغ الأخرى، وإعادة نشرها. لا تلاحظ الروبوتات أي انقطاع مرئي لأن الموجه لا يفرغ إلا النسخ المتماثلة التي لا تحتوي على طلبات قيد التنفيذ. يُعدّ استخدام النمط الأزرق/الأخضر مناسبًا أيضًا لتبديل النماذج - يتم تحميل النموذج الجديد على النسخة المتماثلة B، ثم تبديل مؤشر الموجه، والتحقق من بعض الاستعلامات، ثم إيقاف النسخة المتماثلة A. يؤدي تخطي خطوة التهيئة إلى حدوث مشكلة للجميع مرة واحدة فقط (راجع I02 حول مشكلة التهيئة).

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

إمكانية المراقبة على نطاق الأسطول

لوحة التحكم التي تريدها فعلاً، حسب ترتيب الأولوية:

1. صحة كل روبوت على حدة. بيانات البطارية، ودرجة حرارة وحدة معالجة الرسومات المدمجة، وآخر وقت تم رصده، والمهمة الحالية، وآخر خطأ. صف واحد لكل روبوت، يتم تحديث البيانات كل 5 ثوانٍ، حالة المؤشر: أحمر/أصفر/أخضر. هذا أول ما ينظر إليه المشغل كل صباح.
2. زمن استجابة كل روبوت لخادم الاستدلال. أوقات الاستجابة P50 وP95 وP99 لكل استدعاء VLM من الروبوت. تُعدّ القفزات في P99 مؤشراً رئيسياً على ضعف شبكة Wi-Fi، أو زيادة الضغط على الخادم، أو استبدال النموذج دون تهيئة كافية.
3. عمق طابور خدمة النموذج. vllm_num_requests_waiting لكل نقطة نهاية. يشير استمرار القيمة غير الصفرية إلى أن أسطول الأجهزة يتجاوز قدرة الخادم. تنبيه عند 10+ لأكثر من دقيقة.
4. خريطة حرارية لاستخدام الأسطول. أي الروبوتات مشغولة، وأين في المبنى، وماذا تفعل. عرض تشغيلي؛ يوضح للمدير ما إذا كان أسطول الروبوتات متوازناً.
5. أخذ عينات من مخرجات النموذج. نسبة ضئيلة (1-5%) من استجابات النموذج استمرت في قائمة المراجعة. يتم إجراء فحص يدوي عشوائي أسبوعيًا. هذه هي الطريقة الوحيدة لاكتشاف أي تراجع خفي في الجودة.

يُستخدم Prometheus وGrafana لعرض المقاييس؛ أما عرض حالة كل روبوت على حدة، فيعتمد عادةً على ما توفره RFM (Formant أو Orbit أو Grafana الخاص بك). سلسلة vLLM ذات الصلة هي vllm:num_requests_running, vllm:num_requests_waiting, vllm:gpu_cache_usage_perc, vllm:time_to_first_token_seconds, vllm:time_per_output_token_seconds — هذه هي قصة الصحة من جانب الاستدلال؛ يغطي مُصدِّر DCGM جانب وحدة معالجة الرسومات.

واقع توسيع نطاق التكلفة

ملاحظتان:

• تكون النفقات الرأسمالية لكل روبوت ثابتة تقريبًا بدءًا من 4 روبوتات فصاعدًا. عند أقل من 4، تهيمن التكلفة الثابتة للخادم. أما عند أعلى من 4، فإنك تدفع بشكل خطي مقابل الحوسبة بما يتناسب مع الحمل. النقطة المثلى لـ أول الخادم يتسع لـ 4-6 روبوتات.
• تتوسع النفقات الرأسمالية للروبوتات (وهي منفصلة ومهيمنة) بشكل خطي. تُصبح تكلفة الحوسبة أقل بندًا في الميزانية بمجرد أن يتجاوز عدد الروبوتات في الأسطول 3 روبوتات تقريبًا. أما العامل الرئيسي الوحيد في تحديد التكلفة فهو "هل تحتاج إلى حلول محلية على الإطلاق؟" (انظر RX450), وليس "حجم الخادم".

تُشير اقتصاديات الحوسبة بقوة إلى تفضيل خادم Kentino AI كبير واحد لخدمة 4-8 روبوتات على عدة خوادم أصغر. يُعدّ استخدام خادمين Kentino AI 256 أسوأ من استخدام خادم Kentino AI 256 واحد مع 8 وحدات Pro 6000 لنفس الأسطول، إلى أن يتم الوصول إلى الحد الأقصى لسعة الخادم الذي يُفعّل DP=2. يختلف هذا التفاوت باختلاف حجم العمل، ولكنه يقع عادةً عند 7-9 روبوتات في مهام VLM-in-the-loop المكثفة.

الرأي الصريح

تُمثل أساطيل الروبوتات التي يزيد عددها عن خمسة أنظمة تشغيل مختلفة عن الوحدات الفردية. فهي ليست "مشروعًا بخمسة أضعاف مشروع روبوت واحد". بل هي مشروع ذو شكل مختلف حيث:

• الحساب هو بند صغير في الميزانية؛ العمليات هي الأهم
• عادةً ما تكون نقطة الاختناق بشرية (انتباه المدير) قبل أن تكون تقنية.
• تُشكل شبكة الواي فاي وتخطيط الطاقة عبئًا أكبر بثلاث مرات مقارنةً بحجم الأسطول 1
• تكلفة الضبط الدقيق لكل روبوت على حدة حقيقية؛ وتكلفة تدهور النموذج عبر الأسطول بأكمله حقيقية أكثر.
• إن إنشاء دليل مرجعي خاص بك يكاد يكون خطأً في أغلب الأحيان؛ اختر واحدًا وقم بتخصيصه.

يُحلّ الجانب الحسابي للمشكلة بشكلٍ كامل بحلول عام 2026. إذ يُمكن لـ vLLM، بالإضافة إلى جهاز توجيه وخادم Kentino AI ذي حجم مناسب، التعامل مع أساطيل تصل إلى 8 روبوتات بشرية تقريبًا على جهاز واحد. بعد ذلك، يُمكن التوسع عبر التوازي في البيانات (المزيد من الخوادم خلف جهاز التوجيه) - وهو ما تم تناوله في K03 . أما المشاكل المعقدة التي تتجاوز حجم الأسطول 5 فهي مشاكل تشغيلية وليست معمارية.

هذا جزء من موسوعة كينتينو، وهي سلسلة مرجعية حول الحوسبة الذكية، والروبوتات، والأنظمة التي تربط بينهما. نرحب بالتعليقات والتصويبات على البريد الإلكتروني info@kentino.com.