حلّ المجتمع

تعذّر على Open WebUI الوصول إلى Ollama في إعداد الذكاء الاصطناعي المحلي على ZimaOS

A ZimaBoard 2 user could launch Stable Diffusion, Open WebUI, and an NVIDIA-enabled Ollama container, but the applications reported connection and network errors between their services.

وصّل أحد مستخدمي ZimaBoard 2 وحدة معالجة رسومات NVIDIA خارجية، وظهرت بشكل صحيح في لوحة المعلومات. بدأ تشغيل Stable Diffusion لكنه أظهر خطأ اتصال عند طلب إنشاء صورة. كما بدأ تشغيل Open WebUI، إلا أنها لم تتمكن من العثور على نموذج عبر أيٍّ من عنوانَي واجهة برمجة تطبيقات Ollama اللذين جرّبهما المستخدم.

فرّقت المناقشة بين الوصول إلى الإنترنت والتواصل بين الحاويات. كان بالإمكان تنزيل التطبيقات والوصول إلى Ollama من جهاز آخر، لكن Open WebUI استمرت في عرض مشكلة في شبكة Ollama. وكان التشخيص النهائي للنقاش هو أن Open WebUI وOllama لم تكونا متصلتين بشبكة Docker نفسها؛ ولم ينشر الكاتب تأكيدًا نهائيًا بعد التوصية الأخيرة.

كانت وحدة معالجة الرسومات ظاهرة، لكن خدمات الذكاء الاصطناعي كانت غير متصلة

ظهرت وحدة معالجة الرسومات NVIDIA الخارجية في لوحة معلومات ZimaOS، لذلك لم يعتبر المجيب الأول أن المشكلة ناتجة عن فشل اكتشاف وحدة معالجة الرسومات. وبدلًا من ذلك، أشار إلى أن Open WebUI واجهة أمامية تتصل بـ Ollama، ولا تنزّل النماذج وتخدمها بنفسها. كما فُسِّر خطأ الاتصال العام في Stable Diffusion على أنه فشل في الوصول إلى الواجهة الخلفية أو واجهة برمجة التطبيقات.

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

لماذا لم يُوجّه المضيف المحلي إلى Ollama

أفاد الكاتب بأن Ollama تعمل على المنفذ 11434، وجرّب عنوان المضيف المحلي وعنوان Docker المقترح. وأوضح أحد أفراد المجتمع أن المضيف المحلي يشير داخل حاوية Open WebUI إلى Open WebUI نفسها، وليس إلى حاوية Ollama منفصلة.

استنادًا إلى قائمة الحاويات الظاهرة في لقطات الشاشة، اقترح المجيب استخدام اسم حاوية Ollama والمنفذ: http://ollama-nvidia:11434. كان المبدأ في ذلك الرد هو استهداف الخدمة التابعة باستخدام هويتها في Docker بدلًا من افتراض أن حاوية الواجهة الأمامية تشارك واجهة loopback الخاصة بالمضيف.

إعدادات اتصال Open WebUI بـ Ollama المعروضة في ZimaOS
إعدادات الاتصال المقدمة للمراجعة.
إعدادات حاوية Ollama في إعداد الذكاء الاصطناعي المحلي في ZimaOS
إعدادات جانب Ollama المعروضة في تسلسل استكشاف الأخطاء وإصلاحها نفسه.
استجابة خدمة Ollama التي تم الوصول إليها من جهاز آخر على الشبكة
كان من الممكن الوصول إلى الخدمة من خارج المسار المتعطل بين الواجهة الأمامية والخلفية.

كانت المشكلة المتبقية هي شبكة Docker

لم يؤدِّ تغيير عنوان URL وحده إلى حل الخطأ. ثم أدرج الكاتب عدة شبكات متاحة، منها bridge وhost، ollama-nvidia_default، و big-bear-open-webui_default. خلص المُجيب إلى أن الحاويتين ظلّتا معزولتين على شبكتين مختلفتين.

كانت التوصية النهائية هي توصيل Open WebUI وOllama بشبكة Docker مشتركة واحدة متطابقة، ثم استخدام اسم حاوية Ollama في عنوان URL لـ API. ينتهي النقاش عند هذه النقطة، لذا فهو يوثّق حدًا محتملًا للشبكة وتصحيحًا مقترحًا، وليس إصلاحًا نهائيًا أكده المستخدم.

الإبلاغ عن مشكلة في شبكة Ollama من جانب Open WebUI
استمر الخطأ بعد اختبار عناوين API متعددة.

الأسئلة الشائعة

هل يثبت تنزيل التطبيقات أن Open WebUI قادر على الوصول إلى Ollama؟

لا. في هذه الحالة، كان لدى ZimaOS اتصال بالإنترنت وكان قادرًا على تنزيل التطبيقات، بينما ظل حاويان قيد التشغيل غير قادرين على التواصل مع بعضهما.

هل تأكد أن وحدة معالجة الرسومات NVIDIA الخارجية هي السبب؟

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