AMD RX580 تشغّل نماذج LLM في المنزل: كيف تتغلب على ROCm وOllama وتحصل على GPU inference

لم يكن تشغيل LLM على بطاقة AMD RX580 القديمة مسألة أمر واحد ناجح، بل تحقيقًا هندسيًا متكاملًا. حاول المؤلف الحصول على GPU inference سليم عبر ROCm وOllama داخل Kubernetes، لكنه حصل بدل التوليد المستقر على مؤشرات نجاح كاذبة وانهيارات مرتبطة بالذاكرة ونصوص عديمة المعنى في بعض الأحيان.

الأعراض والفخاخ

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

تم التعرف على GPU، وامتلأت VRAM، وبدأت الحاويات بالعمل، لكن inference

كان ينهار بأخطاء hipMemGetInfo.

تُظهر هذه الحالة خطأً شائعًا عند تشغيل LLM محليًا، وهو الاكتفاء بالنظر إلى «علامات الحياة» في البنية التحتية. فإذا شغّل Kubernetes الحاوية، ورأت Ollama النموذج، وشغل GPU عدة غيغابايتات، فهذا لا يثبت أن حزمة ROCm تنفّذ العمليات المصفوفية كما ينبغي. وفي البطاقات القديمة مثل RX580 تحديدًا، لا يكفي التحقق من توفر الجهاز، بل يجب التحقق من مسار الحوسبة الفعلي (compute-path)، لأن العطل قد يكمن في طبقة أدنى من التطبيق نفسه.

كيف عُثر على السبب

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

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

• التحقق من حوسبة GPU الفعلية، لا من استخدام VRAM فقط
• مقارنة سلوك ROCm وVulkan
• استبعاد مشاكل الحاوية والتنسيق (orchestration)
• البحث عن إصدارات متوافقة من kernel وROCm
• مراقبة جودة مخرجات النموذج نفسها

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

التركيبة العاملة على RX580

لم تكن نهاية التجربة «إعدادًا سحريًا»، بل تركيبة من الإصدارات والمكونات تعطي فيها RX580 القديمة نتيجة مستقرة. يكتب المؤلف أن إصدارات محددة من ROCm ونواة Linux كانت هي العاملة، وبعد إزالة التعارضات توقف inference عن الانهيار وبدأ يعطي نصًا سليمًا. وهذا استنتاج مهم لكل من يحاول تشغيل نماذج محلية على رسوميات AMD غير الحديثة: فالنجاح هنا لا يعتمد على الدعم الاسمي للعتاد بقدر ما يعتمد على التطابق الدقيق بين طبقات برامج التشغيل والنظام وبيئة التشغيل.

والنتيجة العملية مقنعة: تم الحصول على نحو 42 توكن في الثانية على RX580. وبالنسبة إلى بطاقة منزلية من الجيل السابق، لم يعد هذا مجرد عرض توضيحي، بل وضع عمل فعلي يمكن فيه اختبار المساعدات المحلية ونماذج أولية لسيناريوهات RAG وخدمات inference شخصية دون ترقية إلزامية إلى حزمة NVIDIA حديثة. لكن الدرس الأهم ليس رقم السرعة، بل المنهج: فمجرد أن GPU «يبدو أنه يعمل» لا يكفي. المطلوب هو التحقق من ثبات الحسابات وصحة المخرجات وقابلية تكرار النتيجة.

ماذا يعني هذا

تُظهر قصة RX580 أن LLM inference المحلي على عتاد AMD القديم ممكن، لكنه يتطلب انضباطًا في التشخيص. وهي مرجع جيد للمطورين: لا تخلطوا بين VRAM المشغولة وعمل النموذج الفعلي، وافحصوا الحزمة كاملة من kernel حتى runtime، وتعاملوا مع المخرجات الغريبة بوصفها خطأً حقيقيًا لا عطلًا طفيفًا. وبالنسبة إلى المختبرات المنزلية، فهي أقرب إلى قائمة تحقق جاهزة لتفادي إضاعة أيام خلف مؤشرات نجاح كاذبة.