هل يمكن لـ Home Assistant مشاركة وحدة معالجة رسومات أو مُسرّع مع حاوية أخرى؟

نعم، يمكن لأحمال العمل المرتبطة بـ Home Assistant أحيانًا مشاركة وحدة معالجة رسومات مع حاوية أخرى، لكن الإجابة تعتمد على مسار المُسرّع وحدود المحاكاة الافتراضية.

لا تحتاج Home Assistant Core نفسها عادةً إلى وحدة معالجة رسومات؛ إذ يُستخدم المُسرّع غالبًا مع Frigate أو الرؤية أو الذكاء الاصطناعي المحلي أو معالجة الوسائط أو خدمة مصاحبة أخرى. في Linux، يمكن غالبًا منح حاويات متعددة إمكانية الوصول إلى جهاز التصيير نفسه وترك برنامج التشغيل يتولى جدولة المهام. أما الآلة الافتراضية التي تتلقى جهاز PCIe كاملًا عبر التمرير المباشر، فتستخدم نموذجًا مختلفًا وقد تجعل الجهاز غير متاح للمضيف والضيوف الآخرين. حدّد المستهلك الفعلي قبل تغيير الأذونات.

حدّد أولًا حمل عمل Home Assistant الذي يحتاج فعلًا إلى المُسرّع

لا تمرّر وحدة معالجة الرسومات إلى حاوية Home Assistant Core لمجرد أن المضيف يحتوي على واحدة. حدّد العملية التي ستستخدمها: فك ترميز الفيديو في Frigate، أو اكتشاف الكائنات عبر OpenVINO، أو خدمة لغة أو رؤية محلية، أو معالجة الكلام، أو أي حاوية أخرى تستدعيها Home Assistant. يجب أن يكون تعيين الجهاز تابعًا لحاوية حمل العمل هذه وحدودها الأمنية.

توضح عمليات نشر Frigate نموذج مسار الجهاز بوضوح: يعتمد التسريع العتادي على ظهور جهاز تصيير محدد عبر طبقات الحاويات بأكملها. يوضح دليل التمرير المباشر لوحدة iGPU وCoral في Frigate الحالي سبب ضرورة التحقق من ظهور الجهاز وأذونات المجموعات وطبقات المحاكاة الافتراضية، بدلًا من استنتاجها لمجرد أن المضيف يحتوي على وحدة معالجة رسومات.

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

تختلف أجهزة التصيير المشتركة في Linux عن التمرير المباشر لوحدة معالجة الرسومات كاملة إلى آلة افتراضية

مع حاويات Linux، يمكن أن يتيح تعيين عقدة تصيير مثل /dev/dri/renderD128 إلى أكثر من حاوية واحدة للتطبيقين إرسال المهام عبر برنامج تشغيل المضيف. إنهما يتشاركان في المجدول وموارد الذاكرة، ولا يتلقى كل منهما وحدة معالجة رسومات فعلية مستقلة. ومع ذلك، يعتمد مدى أمان دعم حمل عمل معين على سلوك برنامج التشغيل والتطبيق.

يوضح دليل التمرير المباشر لوحدة معالجة الرسومات إلى LXC حدود الحاوية بوضوح: يحتفظ المضيف ببرنامج تشغيل وحدة معالجة الرسومات الفعلي، بينما تتلقى الحاوية عقد أجهزة محددة مثل /dev/dri/renderD128. يتيح نموذج جهاز التصيير المشترك هذا لحاويات متعددة الوصول إلى مسار المُسرّع نفسه، لكنها تظل تتنافس على محركات وحدة معالجة الرسومات وعرض نطاق الذاكرة والقيود الخاصة بالمورّد.

يختلف التمرير المباشر لجهاز PCIe كامل إلى آلة افتراضية عن ذلك. يصف دليل Proxmox VFIO الحالي عملية التسليم هذه بأنها ملكية حصرية لوحدة معالجة الرسومات من جانب آلة افتراضية واحدة، ما يزيل مسار المشاركة المعتاد عبر برنامج تشغيل المضيف لتلك البطاقة. يمكن لميزات SR-IOV أو الجهاز الوسيط أو vGPU أو الميزات المماثلة إنشاء نموذج مشاركة آخر على العتاد المدعوم، لكنها إمكانات منفصلة ولا ينبغي افتراض توفرها في التمرير المباشر العادي.

تحقّق من الظهور والأذونات في كلتا الحاويتين قبل اختبار الأداء

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

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

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

-15% OFF

ZimaBoard 2 - خادم منزلي صغير لأفكارك الكبيرة

Single board computer zimaboard2

$339.00 - $519.00

Buy Now

أجرِ اختبارات التشغيل منفردًا ومعًا لتحديد حدود المشاركة

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

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

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