في الليلة السابقة، واجه خط العرض في المختبر مشكلة غريبة مكلفة للغاية: استغرق عمل flux على GPU1 (RTX 5060 Ti 16GB) أكثر من دقيقتين لكل خطوة، بينما انتهى نفس العمل على GPU0 (نفس بطاقة الفيديو) في حوالي 54 ثانية للمجموعة كاملة. قمنا بإعادة الاختبار 3 مرات - لم يكن الأمر عشوائيًا.
اقرأ التوقيع بشكل صحيح أولاً
أول ما فعلته هو أخذ عينات من nvidia-smi أثناء 6 عمليات متجمدة. النتائج كانت توقيعًا يوضح كل شيء:
| القيمة أثناء العملية المتجمدة | القيمة المقاسة |
|---|---|
| استخدام SM | 96-99% (يبدو "يعمل بجهد") |
| استخدام الذاكرة | 0-1% (لا يوجد نقل بيانات على الإطلاق) |
| استهلاك طاقة البطاقة | 38W (منخفض بشكل غير طبيعي للتسريع) |
| الوقت لكل خطوة | >120 ثانية (العادي ~4 ثوانٍ) |
SM ممتلئ لكن الذاكرة صفر + طاقة منخفضة = البطاقة لا تحسب فعليًا. إنها تدور في spin-wait. هذا هو livelock في وقت التشغيل وليس حمل النموذج. مقارنة بالعمل العادي حيث التوقيع الحقيقي هو SM 96-99% + استخدام الذاكرة 18-41% + طاقة 115-143W.
المتغير الوحيد الذي تغير فعليًا
يستخدم GPU0 و GPU1 نفس بطاقة الفيديو ونفس النموذج (flux1-dev fp8) لكنهما يختلفان في وقت التشغيل:
- GPU0 (:8188) — imgfactory python_embeded, torch 2.13.0+cu130
- GPU1 (:8190) — venv Python 3.12, torch 2.7.1+cu128
الفرضية الوحيدة لتلك الليلة: وقت التشغيل 2.7.1+cu128 غير متوافق مع بنية Blackwell في 5060 Ti تحت حمل dequant الثقيل. طريقة الإثبات ليست صعبة - نقل وقت التشغيل المثبت من GPU0 لتشغيله على GPU1 عبر CUDA_VISIBLE_DEVICES=1 دون لمس النموذج أو الحمل.
النتائج بعد تبديل وقت التشغيل
بعد التبديل إلى start_gpu1_v2 (imgfactory python_embeded, torch 2.13.0+cu130، مع فصل دلائل output/input/db تمامًا لتجنب التصادم مع 8188):
| البوابة | النتيجة |
|---|---|
| مهمة فردية (job 85917) | 54.4 ثانية - عودة إلى الوضع الطبيعي |
| 8 مهام متتالية | 50.7-127.4 ثانية، جميعها نجحت |
| 10 مهام إجمالاً | 10/10 نجاح · متوسط 54.15 ثانية |
| مقارنة بـ GPU0 في نفس الفترة | تكافؤ 100.3% (نطاق ±50%) |
| تأثير جانبي على GPU0 | صفر - واصل 8188 العمل ونشر الصور خلال نفس الفترة |
معدل الإنتاج الفعلي المقاس لـ GPU1 بعد الإصلاح = 30.5 مهمة في الساعة (10 مهام / 1,182 ثانية)
ما لم نفعله (ولا ينبغي فعله)
- لم نحذف venv القديم - تركناه في E:\ComfyUI وفقًا لقاعدة "النقل دون الحذف"، فقط غيّرنا schtask للإشارة إلى launcher الجديد
- لم نلمس idle_watchdog القديم الذي ساعد سابقًا في إعادة التشغيل مما أدى إلى إنشاء نسخ متطابقة - أزلناه ودينا بالتعافي عند الطلب عند الحاجة
- لم نلمس أي واجهة عمل أخرى: الحمل، المعاملات، النموذج، ترتيب الطابور - كل شيء بقي كما هو بايتًا تلو الآخر
درس المختبر
عند مواجهة GPU "بطيء"، لا تلوم النموذج فورًا أو تزيد VRAM - اقرأ دائمًا هذه القيم الثلاث أولاً: SM، استخدام الذاكرة، والواط. إذا كان SM ممتلئًا لكن الذاكرة صفر، فالمشكلة تكمن في وقت التشغيل في معظم الحالات، والإثبات الصحيح هو تبديل متغير واحد (وقت التشغيل) مع ترك كل شيء آخر كما هو ثم قياس 10 مهام - وليس التخمين ثم بذل الجهد للبحث عن سائق جديد من البداية.
