يمكن أن يؤدي استبدال وحدة معالجة رسومات NVIDIA ببطاقة Intel Arc إلى استمرار عمل أحد التطبيقات المستضافة ذاتيًا، مع فقدان تطبيق آخر للتسريع. وهذا ما حدث تحديدًا في سلسلة المصدر هذه بين يونيو وأغسطس 2026. فبعد استبدال RTX 2070 ببطاقة Intel Arc A310، استمر الترميز باستخدام العتاد في Jellyfin، و intel-gpu-top عمل ذلك على مضيف ZimaOS، لكن التعرّف على الوجوه في Immich توقف، واختفى عنصر واجهة وحدة معالجة الرسومات من الصفحة الرئيسية في ZimaOS.
كشف ملف YAML المنشور لـ Immich سبب اختلاف سلوك التطبيقين: إذ ظلت خدمة تعلّم الآلة تحتوي على حجز لوحدة معالجة رسومات بأسلوب NVIDIA. ويستخدم مسار Intel في Immich تقنية OpenVINO ووصولًا مباشرًا إلى /dev/driعدّل صاحب المنشور الأصلي ملف YAML في النهاية عبر واجهة ZimaOS الأحدث، وأكد أن تعلّم الآلة بدأ يعمل مجددًا.
عمل Jellyfin لا يثبت امتلاك Immich ML وصولًا إلى وحدة معالجة الرسومات
Jellyfin وتعلّم الآلة في Immich حاويتان منفصلتان. تحصل كل منهما على صورتها وأجهزتها وبيئتها وأذونات وقت تشغيلها الخاصة. وتمرير وحدة معالجة رسومات Intel إلى Jellyfin لا يمنح Immich ML وصولًا إلى وحدة معالجة الرسومات /dev/dri تظهر تلقائيًا داخل immich-machine-learning.
كان هذا التصحيح المفاهيمي الأهم في النقاش. فاكتشاف وحدة معالجة الرسومات على مستوى المضيف، وترميز Jellyfin، وتعلّم الآلة في Immich، وعنصر واجهة وحدة معالجة الرسومات في ZimaOS، أربع طبقات منفصلة.
ظلت خدمة تعلّم الآلة تستخدم إعداد NVIDIA القديم
احتوى ملف YAML المصدر على حجز لجهاز Docker مشابه لما يلي:
deploy:
resources:
reservations:
قسم devices:
- capabilities:
- gpu
device_ids:
- "0"كان حجز وحدة معالجة الرسومات العام قد نُقل من إعداد RTX 2070 السابق. ولم يتوافق مع مسار Intel OpenVINO المعتاد الذي يستخدمه Immich.
تحقّق أولًا من وجود وحدة معالجة الرسومات Intel على مضيف ZimaOS
كان صاحب المنشور الأصلي قد أثبت بالفعل حقيقتين مهمتين:
-
intel-gpu-topعمل ذلك من طرفية ZimaOS؛ - كان بإمكان Jellyfin استخدام Arc A310 للترميز باستخدام العتاد.
تُظهر هذه النتائج أن نواة المضيف ومسارًا واحدًا على الأقل من مسارات الوسائط في مساحة المستخدمين قادران على استخدام وحدة معالجة الرسومات. لذلك فإن تفسير المشكلة بأنها «بطاقة Arc غير مكتشفة إطلاقًا» ليس تفسيرًا مرجحًا لفشل Immich.
ثم تحقّق من /dev/dri داخل حاوية Immich ML
اقترح أحد أعضاء المجتمع فحص المضيف والحاوية كلًّا على حدة. وأكثر تشخيص مفيد هو التحقق مما إذا كانت حاوية تعلّم الآلة تستطيع رؤية /dev/dri.
إذا كان الجهاز المضيف يضم جهاز العرض من Intel لكن الحاوية لا تملكه، فينبغي إجراء الإصلاح في تعريف الحاوية بدلًا من إعدادات BIOS الخاصة باللوحة الأم أو إعدادات PCIe.
تعلّم الآلة الحالي في Immich على أجهزة Intel يستخدم OpenVINO
يستخدم دعم Immich الحالي لتعلّم الآلة المتسارع عتاديًا OpenVINO لأجهزة Intel. تحتاج حاوية تعلّم الآلة إلى صورة OpenVINO المناسبة أو نسخة الصورة الملائمة، إضافةً إلى الوصول إلى أجهزة العرض.
قبل تعديل حزمة حالية، استخدم متطلبات Immich الحالية لتعلّم الآلة المتسارع عتاديًا على أجهزة Intel باستخدام OpenVINO، لأن علامات الصور وخيارات المسرّعات المدعومة قد تتغير بين إصدارات Immich.
اقترح المجتمع إزالة حجز NVIDIA وإضافة الوصول إلى أجهزة Intel
اقترح المجيب إزالة الإعداد القديم deploy.resources.reservations.devices لخدمة تعلّم الآلة والتأكد من تمرير أجهزة العرض من Intel، باستخدام الصيغة التالية من حيث المبدأ:
قسم devices:
- /dev/dri:/dev/driاقترح الرد أيضًا صورة تعلّم آلة مخصصة لـ OpenVINO للإصدار الذي نشره المستخدم.
تنتمي علامات الإصدارات الدقيقة هذه إلى الإطار الزمني للمصدر. استخدم علامات Immich الحالية بدلًا من تثبيت رقم إصدار 2026.
استخدم سجلات تعلّم الآلة للتأكد من موفّر المسرّع
يعمل /dev/dri يُعد mount ضروريًا لكنه غير كافٍ. بعد تغيير YAML، أعد تشغيل Immich وافحص سجلات تعلّم الآلة بحثًا عن تهيئة المسرّع أو تحميل النموذج أو أخطاء موفّر الخدمة.
وهذا أفضل من الحكم على نجاح العملية استنادًا إلى أداة GPU في ZimaOS، لأن سجل التطبيق يوضح ما إذا كانت خدمة تعلّم الآلة المحددة تستخدم الواجهة الخلفية المقصودة فعليًا.
تعديل YAML في إصدارات ZimaOS الأحدث سهّل الإصلاح
عندما عاد صاحب المنشور الأصلي في 24 أغسطس، أشار تحديدًا إلى أن أحدث إصدار من ZimaOS أتاح تعديل YAML مباشرةً من الصفحة الرئيسية للخادم. وقد أزال ذلك الصعوبة السابقة في العثور على ملف YAML الأساسي للتطبيق.
هذه نقطة فاصلة مهمة بين الإصدارات: فالنصائح الأقدم حول العثور يدويًا على ملفات Compose المُنشأة أصبحت أقل صلة بعد أن أضاف متجر تطبيقات ZimaOS 2.0 إمكانية تعديل YAML بشكل أصلي.
أكد صاحب المنشور الأصلي استعادة تعلّم الآلة
يذكر الرد النهائي في المصدر أنه بعد إزالة كتلة حجز GPU القديمة وضبط إعدادات الأجهزة، عاد تعلّم الآلة في Immich إلى العمل.
وهذا يجعلها حالة مصدر محلولة. ولا يثبت ذلك أن كل طراز من Intel Arc أو كل إصدار من Immich يستخدم ملف YAML نفسه تمامًا، لكنه يؤكد التشخيص بقوة: كانت حاوية تعلّم الآلة لا تزال مهيأة لطراز GPU السابق.
اختفاء أداة GPU في ZimaOS كان مشكلة منفصلة
اختفت أداة GPU من الصفحة الرئيسية بعد التبديل إلى Arc A310، لكن Jellyfin كان يستخدم GPU بالفعل. وهذا يعني أنه لا يمكن اعتبار أداة لوحة المعلومات المؤشر الموثوق لدعم GPU.
عند استكشاف أخطاء التطبيقات وإصلاحها، أعطِ الأولوية لاكتشاف الجهاز على المضيف، وإمكانية رؤية الجهاز داخل الحاوية، وسجلات التطبيق، بدلًا من أداة عرض زخرفية لاستخدام GPU.
قائمة تحقق أفضل لترحيل GPU
- أكد ظهور GPU وبرنامج التشغيل الجديدين على مستوى مضيف ZimaOS.
- تحقق من كل تطبيق يستخدم التسريع على حدة.
- أزل حجوزات الأجهزة الخاصة بالمورّد القديم.
- استخدم الواجهة الخلفية للتسريع التي يتطلبها المورّد الجديد.
- مرّر أجهزة العرض المطلوبة إلى كل حاوية معنية.
- أعد تشغيل الحزمة المتأثرة فقط وافحص السجلات.
- شغّل مهمة جديدة لتعلّم الآلة في Immich وتأكد من ظهور النتائج.
الأسئلة الشائعة حول Intel Arc في Immich
لماذا استمر Jellyfin في العمل بينما توقّف التعرّف على الوجوه في Immich؟
يعمل التطبيقان في حاويتين مختلفتين ويتطلبان إعدادًا منفصلًا لـ GPU.
ما الواجهة الخلفية التي يستخدمها Immich حاليًا لتعلّم الآلة عبر GPU من Intel؟
OpenVINO.
هل حُلّت مشكلة Arc A310 الأصلية؟
نعم. أكد المستخدم أن تعديل YAML أعاد وظائف تعلّم الآلة.
هل تحدد أداة GPU في ZimaOS ما إذا كان بإمكان Immich استخدام GPU؟
لا. كانت حالة المصدر تتضمن أداةً مصغّرة مفقودة، بينما ظل تسريع GPU في Jellyfin يعمل.
