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

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

I01 تمت معالجة مشكلة الصندوقين لروبوت واحد وخادم واحد. كيه03 تم شرح كيفية قيام vLLM بتقسيم النموذج عبر وحدات معالجة الرسومات (GPUs). RX450 لقد أوضحت هذه المقالة أهمية استخدام البنية التحتية المحلية من الأساس. وتستند هذه المقالة إلى النقاط الثلاث السابقة، وتجيب على السؤال التالي: إذا أردتَ تكرار هذه العملية عددًا من المرات، فما الذي سيتعطل؟

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

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

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

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

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

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

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

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

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

السبب في أن خادمًا واحدًا كبيرًا يتفوق على العديد من الخوادم الصغيرة هو الإنتاج الدفعي المستمريحتفظ 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 خلف جهاز التوجيه. تعمل هذه الطبقات على نفس المضيف الفعلي لـ K-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), وليس "حجم الخادم".

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

الرأي الصريح

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

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

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

---

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