كيفية التحقق مما إذا كان نموذج اللغة الكبير المحلي يستخدم ملفات النموذج ومسار التخزين الصحيحين

يمكن لـ LLM المحلي أن يجيب على طلب ولا يزال يستخدم مسار نموذج خاطئ. قد يعرض واجهة التطبيق اسم النموذج الذي تتوقعه، لكن وقت التشغيل قد يقرأ ذاكرة تخزين مؤقت قديمة، أو دليل داخلي لـ Docker، أو مجلد نموذج افتراضي، أو ملف تم سحبه مرة أخرى في مكان آخر.

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

المجلد الذي تراه ليس دائمًا هو المسار الذي يستخدمه وقت التشغيل

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

يضيف Docker طبقة أخرى. قد يتم تعيين مسار مضيف مثل /mnt/storage/ai/models إلى مسار داخل الحاوية مثل /root/.ollama، ويرى مشغل النموذج فقط مسار الحاوية. توضح وثائق ربط التثبيت في Docker أن source هو مسار الجانب المضيف وdestination أو target هو المسار داخل الحاوية، لذا يجب التحقق من الاثنين معًا عبر ربط التثبيت في Docker.

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

ابدأ بقائمة نماذج وقت التشغيل

قبل فحص كل مجلد، اسأل قائمة نماذج وقت التشغيل عما يعرفه. بالنسبة لـ Ollama، ابدأ بـ:

ollama list

داخل حاوية Docker، استخدم نفس فحص وقت التشغيل من داخل حدود الخدمة:

docker exec -it ollama ollama list

يؤكد سجل وقت التشغيل أن وقت التشغيل قد سجل علامة نموذج، لكنه لا يثبت تمامًا أن مسار الملف أو التكميم أو موقع التخزين صحيح. يسرد مرجع CLI الخاص بـ Ollama الأمر ollama ps لتشغيل النماذج، بينما يشرح قسم الأسئلة الشائعة دليل دليل دليل تخزين النماذج ومتغير البيئة OLLAMA_MODELS.

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

طابق مسار المضيف مع مسار الحاوية

بالنسبة لنشر Docker، السؤال الأهم هو ما إذا كان مسار المضيف ومسار الحاوية يتطابقان فعليًا. شغّل:

docker inspect <container-name>

ثم انظر إلى قسم التركيبات. يجب أن يشير المصدر إلى مجلد تخزين NAS الذي كنت تنوي استخدامه، ويجب أن يشير الوجهة إلى دليل النموذج المستخدم داخل الحاوية. يعيد أمر inspect في Docker معلومات كائن منخفضة المستوى، مما يجعل docker inspect Mounts مصدرًا أفضل للحقيقة من الذاكرة أو لقطات الشاشة.

يجب أن يجعل تعيين تركيب Docker علاقة التخزين واضحة:

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

تحقق من ملفات النموذج الفعلية، وليس فقط اسم النموذج

اسم النموذج ليس هو نفسه ملف نموذج تم التحقق منه. يمكن أن يشير نفس الاسم إلى علامات، تنسيقات، مستويات تكميم، محولات، أو كتل مخبأة مختلفة حسب وقت التشغيل.

بالنسبة لأولاما، افحص بيانات وصف النموذج باستخدام:

ollama show <model-name> --modelfile

داخل Docker، شغّل نفس فحص ملف النموذج عبر الحاوية:

docker exec -it ollama ollama show <model-name> --modelfile

بيانات وصف ملف نموذج أولاما مهمة هنا. توضح وثائق ملف النموذج في أولاما أن ollama show --modelfile يمكن أن يكشف عن تكوين النموذج، بما في ذلك مصدر FROM وراء النموذج. بالنسبة لملفات .gguf التي تم تنزيلها يدويًا، توضح وثائق التكميم في llama.cpp تنسيقات GGUF مثل Q4_K_M، لذا فإن بيانات وصف ملف نموذج GGUF هي جزء من التحقق، وليس فقط لضبط الأداء.

السجلات تخبرك أي مسار تم تحميله فعليًا

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

بالنسبة لـ Docker، استخدم هذا الفحص لسجل الحاوية:

docker logs <container-name>

تشرح وثائق تسجيل Docker أن سجلات الحاوية عادةً ما تعرض مخرجات عملية الحاوية من STDOUT وSTDERR، بينما تشير صفحة استكشاف الأخطاء وإصلاحها لـ Ollama إلى أن سجلات Ollama المحوّمة يمكن عرضها باستخدام docker logs.

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

تأكيد أن النموذج نشط في الذاكرة

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

ollama ps

داخل Docker، شغّل نفس فحص النموذج النشط داخل الحاوية:

docker exec -it ollama ollama ps

ما هو ollama ps ما يمكن إثباته

ollama ps يعرض النماذج المحملة حاليًا. تشرح الأسئلة الشائعة لـ Ollama أن عمود Processor يمكن أن يظهر ما إذا كان النموذج محملاً على CPU أو GPU أو مقسمًا بين CPU وGPU، مما يساعد في تأكيد حالة التشغيل النشطة بدلاً من مجرد مكتبة النموذج.

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

ما لا يمكن إثباته

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

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

علامات تحذيرية على أن مسار النموذج خاطئ

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

راقب هذه إشارات عدم تطابق المسار:

• يعرض التطبيق النموذج، لكن مجلد النموذج المقصود لا ينمو.
• docker inspect يظهر مسار المصدر مختلفًا عن مجلد تخزين NAS الخاص بك.
• يتم تنزيل النموذج مرة أخرى بعد أن ظننت أنه موجود بالفعل.
• تذكر السجلات دليل نموذج افتراضي بدلاً من مسارك المخصص.
• ollama list يظهر علامة أو حجمًا مختلفًا عما توقعت.
• ollama show --modelfile يشير إلى قاعدة أو كتلة مختلفة عن المتوقع.
• ollama ps يظهر نموذج نشط غير متوقع بعد موجه.
• يفقد قرص التمهيد مساحة بعد كل سحب نموذج.

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

ترتيب تحقق أنظف لتخزين LLM المحلي

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

1. أكد مجلد التخزين المضيف المقصود.
2. تحقق من المساحة الحرة على قرص النظام وقرص النموذج.
3. تشغيل docker inspect <container-name> وتحقق من المصدر / الوجهة.
4. تحقق من قائمة نماذج وقت التشغيل باستخدام ollama list.
5. اسحب أو استورد نموذجًا صغيرًا معروفًا واحدًا.
6. تشغيل du -sh <model-folder> قبل وبعد السحب.
7. افحص البيانات الوصفية باستخدام ollama show <model-name> --modelfile.
8. أرسل موجهًا قصيرًا واحدًا.
9. تشغيل ollama ps لتأكيد النموذج النشط.
10. اقرأ سجلات الحاوية أو الخدمة للحصول على أدلة حول المسار أو التنزيل أو الأذونات.

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

ما يظهره بحث ZimaOS AI عن مسارات النماذج المرئية

يجب أن تجعل ميزة الذكاء الاصطناعي المحلية المُتحكم بها مسار النموذج، وحالة التنزيل، واستخدام الموارد، والسجلات مرئية بما يكفي للتحقق. وإلا، سيظل المستخدمون يتساءلون عما إذا كانت خدمة الذكاء الاصطناعي تستخدم بالفعل ملفات النموذج المتوقعة.

ZimaOS-AI هو مثال مفيد. يشرح دليل ZimaSpace لـ البحث بالذكاء الاصطناعي أن وحدة الذكاء الاصطناعي تستخدم نموذج لغة محلي لاستخراج الميزات من الصور والصوت والفيديو لبحث ZimaOS. تشير الملاحظات نفسها إلى أن ملفات النموذج مخزنة في /media/ZimaOS-HD/AppData/.models، وإذا تم ترحيل AppData، فإن استخدام التخزين الفعلي يتبع موقع AppData المهاجر.

تصف الدليل أيضًا فحوصات التشغيل مثل التنزيلات التلقائية للنماذج، فترات استخراج الميزات، سجل المكالمات، فحوصات حركة الشبكة، وjournalctl -xef -u zimaos-ai لاستكشاف الأخطاء وإصلاحها. هذه هي بالضبط الإشارات التي يحتاجها عبء عمل الذكاء الاصطناعي المحلي: مسار مرئي، سلوك تنزيل مرئي، سجلات مرئية، وحالة وقت تشغيل مرئية.

لإعداد سحابة خاصة مثل ZimaCube 2، الدرس الأكبر هو: يجب ألا يكون الذكاء الاصطناعي المحلي صندوقًا أسود. سواء كانت المهمة بحثًا، دردشة، تضمينات، أو تحليل وسائط، يجب أن يكون مسار النموذج وحالة وقت التشغيل سهل التحقق منهما.

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

كيف أعرف أين يخزن Ollama ملفات النموذج؟

تحقق من دليل النموذج الافتراضي لـ Ollama لنظام التشغيل الخاص بك، ثم تحقق مما إذا كان OLLAMA_MODELS قد غيّره. على Docker، افحص أيضًا تركيب الحاوية لتعرف أي مجلد مضيف يطابق دليل النموذج في وقت التشغيل.

كيف أتحقق مما إذا كان Docker يستخدم مجلد النموذج الصحيح؟

شغّل docker inspect <container-name> وراجع قسم Mounts. يجب أن يكون المصدر هو مسار تخزين NAS الذي قصدته، والوجهة يجب أن تكون دليل النموذج المستخدم داخل الحاوية.

ما هي manifests و blobs في دليل نموذج Ollama؟

في دليل نموذج بأسلوب Ollama، تصف البيانات الوصفية بيانات النموذج والمراجع، بينما تحتوي ملفات blobs على ملفات الحمولة الأكبر للنموذج. إذا نما مجلد blobs بعد سحب نموذج، فهذا دليل قوي على أن هذا الدليل يُستخدم لتخزين النماذج.

كيف يمكنني معرفة أي نموذج محمّل حاليًا؟

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

لماذا يعرض التطبيق النموذج بينما يبدو مسار الملف لا يزال خاطئًا؟

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

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