بنية الذكاء الاصطناعي الطرفي: كيف يتواصل الروبوت مع خادم الاستدلال المحلي

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

الجمهور المستهدف هم المشترون والمكاملون الذين يريدون صورة واضحة قبل توقيع أمر الشراء - وليسوا بعد المهندسين الذين يكتبون الكود البرمجي.

مشكلة الصندوقين

يحتوي الروبوت البشري الحديث، مثل Unitree G1 أو Booster T1، على وحدة حوسبة مدمجة: عادةً ما تكون Jetson Orin (من فئة NX أو AGX) أو معالج Snapdragon SoC، وغالبًا ما تقترن بوحدة تحكم دقيقة مخصصة لحلقة التحكم في المحركات. أما الروبوتات رباعية الأرجل، مثل Unitree Go2، فتستخدم تصميمًا مشابهًا ولكن على نطاق أصغر.

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

• التحكم في المحرك في الوقت الحقيقي عزم الدوران المشترك، والتوازن، والمشي. يعمل هذا النظام بتردد يتراوح بين 500 هرتز و1 كيلوهرتز، ولا يتحمل أي تغيير في الشبكة. يبقى النظام محليًا، لا غير.
• ردود فعل فورية للسلامة — الحماية من السقوط، التوقف الطارئ، الاستجابة الفورية. نفس القيد، نفس الإجابة.
• إدراك منخفض الكمون — العمق من الاستريو أو RGB-D، دمج IMU، الكشف الأساسي عن الكائنات (عادةً ما يكون متغيرًا صغيرًا من YOLO أو MobileNet).
• كلمة التنبيه الصوتية وتوجيه الأوامر الأساسية.

ما لا تستطيع الحوسبة الموجودة على متن المركبة تشغيله بشكل معقول:

• نماذج اللغة المرئية الكبيرة (VLMs) مثل Qwen2.5-VL 72B و NVIDIA Cosmos و OpenVLA. تحتاج هذه التقنيات إلى عشرات الجيجابايت من ذاكرة الوصول العشوائي للفيديو (VRAM) وتستهلك طاقة كبيرة جدًا بالنسبة لمنصة تعمل بالبطارية.
• نماذج لغوية كبيرة (LLMs) للحوار أو التخطيط تم تحديد الكمية فوق فئة 7B–8B.
• مخططات الحركة القائمة على الانتشار أو الانحدار الذاتي التي تعمل على مئات المللي ثواني من السياق.
• ذاكرة المشهد ومخططات المهام طويلة المدى.

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

يمكن أن يكون الهدف "الخارجي" هو السحابة (المستضافة على OpenAI أو Anthropic أو NVIDIA Cosmos) أو خادم استدلال محلي. يتناول الجزء المتبقي من هذه المقالة متى ولماذا يُفضّل استخدام الخيار المحلي.

ما الذي يعيش في أي مكان؟ - التقسيم العملي

تقسيم الصندوقين: يبقى التحكم المحلي على الروبوت؛ أما الاستدلال والتدريب المكثف فيتم إرسالهما إلى الخادم المحلي عبر الشبكة المحلية.

ثلاثة أمور يجب ملاحظتها:

1. لا يحتاج الروبوت إلى خادم وحدة معالجة الرسومات (GPU) للمشي. في حال انقطاع الشبكة المحلية، يظل الجهاز قائماً، محافظاً على توازنه، ويتجنب الاصطدام بالجدار. تُضيف تقنية المعالجة الخارجية إمكانياتٍ جديدة - كاللغة والتخطيط والمهام طويلة الأمد - لكنها لا تُغني عن التحكم المحلي.
2. بعض أعباء العمل قابلة للتفاوض. يمكن تشغيل وحدة إدارة دورة حياة افتراضية صغيرة (مثل Qwen2.5-VL 7B quantized) على Jetson Orin AGX. ويعتمد اختيار تثبيتها داخل الجهاز أو خارجه على المفاضلة بين استهلاك الطاقة، والحرارة، وزمن الاستجابة. ولا توجد إجابة واحدة صحيحة.
3. يقوم الخادم بأكثر من مجرد تقديم الاستدلال. يتضمن النشر الجاد أيضًا عمليات تدريب (لضبطها بدقة لتناسب بيئة محددة)، ومحاكاة (باستخدام برنامج Isaac Sim لتكرار السياسات)، واسترجاع/حفظ المشاهد. ويُقصد بـ "خادم الاستدلال" اختصارًا لـ "وحدة معالجة الرسومات الخلفية".

ميزانية زمن الاستجابة

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

الأرقام التي تهيمن على الميزانية هي زمن استجابة نموذج جانب الخادم و(إذا كنت تستخدم اتصالاً لاسلكياً) تذبذب شبكة الواي فاي. نادراً ما تكون عملية النقل نفسها هي العائق في شبكة محلية سلكية. ولهذا السبب تستخدم معظم عمليات تثبيت الروبوتات الجادة كابلًا سلكيًا أو نقطة وصول مخصصة بتقنية Wi-Fi 6/6E ضمن خط الرؤية لمنطقة العمل.

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

audio capture          ~ 50 ms
wake-word + STT        100–250 ms  (on-board or off-board, your choice)
LLM TTFT (planning)    200–500 ms  (server-side)
LLM stream 20 tokens   600–1200 ms
TTS                    100–300 ms
audio playout          ~ 50 ms
                       --------------
                       ~ 1.1 – 2.3 s

لا توجد طريقة لتحقيق زمن استجابة "أقل من ثانية واحدة من البداية إلى النهاية" باستخدام نموذج LLM بحجم 70 بايت في الحلقة الحالية. إما أن تقبل زمن الاستجابة، أو تستخدم نموذجًا أصغر محليًا (بحجم 8-13 بايت)، أو تقسم الاستجابة (تأكيد فوري، وتخطيط في الخلفية).

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

لماذا استخدام البنية التحتية المحلية أصلاً؟

الاستدلال السحابي رخيص، وقابل للتوسع بسهولة، ولا يتطلب أي نفقات رأسمالية. فلماذا قد يشتري أي شخص خادمًا بأربعة أو ثمانية وحدات معالجة رسومية (GPU) بينما يبلغ سعر مفتاح واجهة برمجة تطبيقات OpenAI خمسين دولارًا؟

هناك أربعة أسباب حقيقية، مرتبة تقريبًا حسب مدى تكرار تأثيرها على القرار:

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

2. الحد الأدنى لزمن الاستجابة. يُضيف زمن استجابة الشبكة الواسعة (WAN RTT) لكل مكالمة سحابية، بالإضافة إلى زمن استجابة النموذج، ما بين 15 و40 مللي ثانية. يُعدّ هذا مقبولًا لمعظم مهام الروبوتات، لكن بالنسبة للتحكم التفاعلي ذي الحلقة المغلقة - مثل عمليات الالتقاط والوضع السريعة، واستعادة التوازن بعد الدفع، والتحكم الدقيق - فإن زمن استجابة الشبكة الواسعة (WAN) مرتفع جدًا. أما في الأنظمة المحلية، فيُصبح زمن الاستجابة أقل من 1 مللي ثانية.

3. التكلفة عند الحمل المستمر. تكلفة استدعاء واحد لـ 70 مليار VLM على مزود الخدمة السحابية شبه معدومة؛ إذ يتقاضى منك بضعة سنتات فقط. لكن الروبوت الذي "يفكر باستمرار" يُجري آلاف الاستدعاءات في الساعة. ويمكن لمختبر أبحاث يُجري التدريب، بالإضافة إلى أسطول من الروبوتات التي تستنتج البيانات من النماذج نفسها، أن يُنفق ما بين 5,000 و15,000 دولار شهريًا على الخدمات السحابية. في المقابل، يُعوّض خادم GPU محلي مزود بـ 4 أو 8 وحدات معالجة رسومية (GPU) تكلفته في أقل من اثني عشر شهرًا عند هذا الحمل.

4. اختيار النموذج وتخصيصه. تريد ضبط نموذج إدارة دورة حياة افتراضية (VLM) بدقة لتناسب بيئتك الخاصة. تريد تشغيل نموذج لا يستضيفه مزودو الخدمات السحابية. تريد دمج نماذج مفتوحة الوزن من موردين مختلفين في مسار مخصص. يوفر لك النظام المحلي هذه الإمكانية، بينما لا توفرها واجهات برمجة التطبيقات السحابية.

إذا لم يكن أيٌّ من هذه العوامل الأربعة مهمًا لتطبيقك، فعليك استخدام الحوسبة السحابية. والحقيقة هي أن ما بين 30 و40% من مشتري الروبوتات يحتاجون فعليًا إلى حلول محلية؛ أما البقية فيختارونها لأسباب تتعلق بالمكانة أو لأن قسم المشتريات لديهم غير مرتاح للحوسبة السحابية. وكلا السببين وجيهان، لكننا لن نتجاهل الحقيقة.

طوبولوجيا الشبكة

مخطط الشبكة: الروبوت متصل بشبكة Wi-Fi 6E ← نقطة وصول مخصصة ← محول 10 جيجابت إيثرنت ← خادم استدلال. الوصول إلى الشبكة الخارجية والشبكة الواسعة (WAN) اختياري.

بعض الملاحظات العملية التي قد تفاجئ الناس:

• تقنية Wi-Fi 6E هي الأرضية، وليست السقف. يُعد نطاق 6 جيجاهرتز النطاق الوحيد الذي يتميز بانخفاض زمن الاستجابة بشكل ثابت في البيئات التي تحتوي على أجهزة أخرى. يُنصح بتخصيص نقطة وصول واحدة لكل 50 مترًا مربعًا تقريبًا من مساحة عمل الروبوت، مع مراعاة وجود خط رؤية مباشر إن أمكن.
• لا يزال الاتصال السلكي أفضل. إذا كان الروبوت مزودًا بخيار التوصيل السلكي (بعض الروبوتات البشرية المستخدمة في الأبحاث مزودة به، بينما الروبوتات رباعية الأرجل عادةً لا)، فاستخدمه أثناء التطوير. تجربة التطوير باستخدام شبكة محلية (LAN) فائقة السرعة (أقل من جزء من الألف من الثانية) أفضل بكثير من مواجهة مشاكل شبكة Wi-Fi.
• الخروج اختياري ولكنه مفيد. حتى في حالة النشر المحلي بالكامل، ستحتاج عادةً إلى منفذ WAN للوصول إلى البيانات التالية: تحديث النماذج، وجلب بيانات الخرائط، وسحب حاويات NVIDIA NGC، وبيانات القياس عن بُعد لنظام المراقبة الخاص بك. قم بتأمين هذا المنفذ بجدار ناري محكم؛ ولا تعرض الروبوت أو الخادم للإنترنت.
• تزامن الوقت مهم. قم بتشغيل خادم NTP محلي. يتعطل دمج البيانات الحسية وتخطيط الحركة بطرق دقيقة عندما تختلف التوقيتات عبر الروبوت والخادم وأي أجهزة طرفية مساعدة.

الطاقة والتبريد

يستهلك خادم K-AI رباعي المعالجات الرسومية (4 × RTX 5090 أو 4 × RTX Pro 6000 Blackwell) طاقة تتراوح بين 1.8 و2.4 كيلوواط بشكل مستمر تحت الحمل. أما الخادم ثماني المعالجات الرسومية فيستهلك طاقة تتراوح بين 3.5 و4.5 كيلوواط. هذه الأرقام لا تخص أجهزة سطح المكتب؛ إذ تتطلب دوائر كهربائية بقوة 16 أمبير وتهوية مناسبة للرف.

بالنسبة لمختبر الروبوتات، فإن الميزانية التقريبية هي:

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

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

مجموعة البرامج - ما الذي يتم تشغيله فعليًا

هنا يكمن جوهر التنفيذ. الصورة العامة:

تقسيم البرمجيات: يتواصل نظام ROS 2 الموجود على الروبوت عبر gRPC مع خادم الاستدلال الذي يعمل بنظام vLLM / SGLang.

بعض الآراء الشخصية:

• vLLM هي حزمة الخدمة الافتراضية بالنسبة لأنظمة إدارة التعلم الافتراضية (VLMs) وأنظمة إدارة التعلم المنطقية (LLMs) القائمة على المحولات، فهي أسرع من استدلال HuggingFace البسيط، وتدعم التجميع المستمر وتخزين البادئات مؤقتًا. يُعد SGLang بديلاً قويًا إذا كنت تعمل على مخرجات منظمة أو سير عمل على نمط الوكيل.
• اللاما يُعد هذا هو الجواب الصحيح عندما تقوم بتشغيل نموذج صغير (فئة 7B–13B) على وحدة معالجة رسومية لا يحبها vLLM (مثل RTX 4090 مع التوازي الموتري الغريب)، أو على الروبوت نفسه.
• نفيديا تريتون إعداده أكثر تعقيدًا ولكنه الخيار الصحيح إذا كنت تقوم بخلط أنواع النماذج (LLM + الرؤية + الكلام) وتريد طبقة خدمة واحدة فوقها جميعًا.
• ROS 2 Humble هي اللغة المشتركة. توفر حزم تطوير البرامج (SDKs) الخاصة بالشركات المصنعة (Unitree، Booster، EngineAI) أغلفة ROS 2. قم ببناء التكامل الخاص بك على جانب ROS 2، وليس على البروتوكول الخاص بالشركة المصنعة، إلا إذا كان لديك سبب محدد.

مثال ملموس

تخيل أبسط إعداد إنتاج قابل للتطبيق: روبوت بشري واحد (Unitree G1)، وخادم استدلال واحد (K-AI 256 Turin Dual مع 8× RTX 5090)، ومحول واحد، ونقطة وصول واحدة، في مختبر مساحته 30 مترًا مربعًا.

Hardware:
- Unitree G1 (one unit, ~1 kW charging draw)
- K-AI 256 Turin Dual / 8× RTX 5090 (sustained ~4 kW)
- 10 GbE switch (5 ports, ~30 W)
- Wi-Fi 6E AP (~15 W)
- 32 A three-phase or 2× 16 A single-phase circuit
- ~6 kW dedicated cooling (split AC)

Software on server:
- Ubuntu 22.04, CUDA 13, Docker
- vLLM serving Qwen2.5-VL 72B at INT4
- vLLM serving Qwen2.5 32B (text-only, for planning)
- pgvector for scene memory
- Isaac Sim for policy work
- Prometheus + Grafana

Software on robot:
- Unitree's ROS 2 driver
- Custom command-router ROS 2 node
- gRPC client to vLLM endpoints
- Local YOLO for fast obstacle detection

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

بالنسبة لمختبر أبحاث يحتوي على 2-4 روبوتات، فإن نفس الخادم قابل للتوسع - يتعامل vLLM مع الطلبات المتزامنة بشكل جيد، وتصبح عنق الزجاجة إما ذاكرة وحدة معالجة الرسومات (إذا كنت ترغب في استضافة المزيد من النماذج في وقت واحد) أو طاقة الحائط.

ما الذي يتعطل؟

قائمة صادقة لأنماط الفشل التي لاحظناها، مرتبة تقريبًا حسب مدى تكرار حدوثها:

• تذبذب شبكة الواي فاي تحت الضغط. تتعرض الشبكة، التي كانت تعمل بشكل جيد سابقاً، للازدحام عند انضمام جهاز جديد، مما يؤدي إلى ارتفاع زمن الاستجابة من 5 مللي ثانية إلى 80 مللي ثانية، وتدهور استجابة الروبوت. الحل: شبكة لاسلكية مخصصة للروبوتات، تعمل بتردد 6 جيجاهرتز فقط، مع نقطة وصول مباشرة.
• يؤدي تبديل النموذج إلى تعطيل النظام. عند تحديث VLM، يجب إعادة تحميل vLLM، مما يؤدي إلى انتهاء مهلة مسار أوامر الروبوت. الحل: خدمة الأزرق/الأخضر، نقطتا نهاية، التبديل بينهما واحدة تلو الأخرى.
• التحكم الحراري في أداء الخادم. أثناء التدريب والاستدلال المستمرين، لا يستطيع مكيف الهواء في الغرفة تبريد الغرفة بشكل كافٍ، مما يؤدي إلى خفض تردد وحدات معالجة الرسومات. ويتضاعف زمن استجابة الاستدلال دون أي تنبيه. الحل: زيادة حجم نظام التبريد ليتناسب مع زيادة زمن الاستجابة المستمرة بمقدار 1.3 ضعف، ومراقبة درجة حرارة وحدات معالجة الرسومات، وتفعيل نظام إنذار عند بلوغها 80 درجة مئوية.
• أعطال في الكابلات/الموصلات من جانب الروبوت. تهتز الروبوتات. وتتلف الأسلاك مع مرور الوقت. لذا، خطط لعطل واحد في كابل الشبكة أو كابل المستشعر لكل روبوت كل ثلاثة أشهر في الوحدات التي تُستخدم بكثرة. احتفظ بقطع غيار.
• عدم تطابق إصدار برنامج تشغيل NVIDIA / CUDA بعد الترقية باستخدام apt-get. هذا الأمر يؤثر على الجميع مرة واحدة فقط. ثبّت إصدار برنامج التشغيل، واستخدم الحاويات، ولا تفعل ذلك. apt-get dist-upgrade على خادم يعمل.
• انحراف التوقيت بين الروبوت والخادم. تتفاوت طوابع البيانات المُسجلة من المستشعرات بعشرات المللي ثوانٍ، مما يُنتج بيانات غير صحيحة عند دمجها، ولا أحد يفهم السبب. الحل: استخدام بروتوكول NTP محلي، ومراقبته، وتفعيل تنبيه عند تجاوز التفاوت 5 مللي ثانية.

لا شيء من هذه الأمور كارثي. جميعها يمكن التنبؤ بها بمجرد رؤيتها مرة واحدة.

عندما يكون المسار المحلي هو الحل الخاطئ

بصراحة: خادم الاستدلال المحلي هو الحل الخاطئ عندما —

• الروبوت الخاص بك عبارة عن وحدة يتم التحكم فيها عن بُعد فقط، ومشغله موجود بالفعل على محطة عمل سحابية. لذا، استخدم السحابة.
• أنت تقوم بنشر مركبة رباعية الأرجل لمهمة تفتيش خارجية، ولا حاجة لاستنتاج نموذج كبير؛ فالحسابات الموجودة على متن المركبة تقوم بالمهمة.
• يتناسب حجم نموذجك فعليًا مع Jetson Orin AGX (باستهلاك طاقة يتراوح بين 50 و70 واط)، كما أن هامش زمن الاستجابة لديك يسمح بذلك. يستطيع Orin تشغيل 7B INT4 LLM بسرعة قابلة للاستخدام.
• أنت تُجري عرضًا تجريبيًا لمرة واحدة. يُعدّ الإعداد السحابي أسرع، وأقل تكلفة عند انعدام الحمل، ويمكنك إيقافه في غضون ساعات قليلة.

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

---

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