คืนก่อนหน้านี้ render pipeline ของห้องแล็บเจออาการแปลกที่แพงเวลามาก: งาน flux บน GPU1 (RTX 5060 Ti 16GB) ใช้เวลากว่า 2 นาทีต่อสเต็ป ทั้งที่งานเดียวกันบน GPU0 (การ์ดรุ่นเดียวกัน) เสร็จใน ~54 วินาทีทั้งชุด เราทดสอบซ้ำได้ 3 ครั้ง — ไม่ใช่เรื่องสุ่ม

อ่าน signature ให้ถูกก่อน

สิ่งแรกที่ผมทำคือเก็บตัวอย่าง nvidia-smi ระหว่างงานค้าง 6 ครั้ง ผลออกมาเป็นลายเซ็นที่บอกทุกอย่าง:

ค่าระหว่างงานค้าง ที่วัดได้
SM utilization 96–99% (ดูเหมือน "ทำงานหนัก")
Memory utilization 0–1% (ไม่มีการขนถ่ายข้อมูลเลย)
กำลังไฟการ์ด 38W (ต่ำผิดปกติสำหรับ sampling)
เวลาต่อสเต็ป >120 วินาที (ปกติ ~4 วินาที)

SM เต็มแต่ memory ศูนย์ + ไฟต่ำ = การ์ดไม่ได้คำนวณจริง มันหมุนวนอยู่ใน spin-wait นี่คือ livelock ของ runtime ไม่ใช่โหลดของโมเดล เทียบกับงานปกติที่ signature จริงคือ sm 96–99% + mem-util 18–41% + ไฟ 115–143W

ตัวแปรที่เปลี่ยนจริงมีตัวเดียว

GPU0 กับ GPU1 ใช้การ์ดรุ่นเดียวกัน โมเดลเดียวกัน (flux1-dev fp8) แต่ต่างกันที่ runtime:

  • GPU0 (:8188) — imgfactory python_embeded, torch 2.13.0+cu130
  • GPU1 (:8190) — venv Python 3.12, torch 2.7.1+cu128

สมมติฐานเดียวของคืนนั้น: runtime 2.7.1+cu128 ไปไม่เข้ากับสถาปัตยกรรม Blackwell ของ 5060 Ti ในเวิร์กโหลด dequant หนัก วิธีพิสูจน์ไม่ยาก — ยก runtime ที่พิสูจน์แล้วของ GPU0 มารันบน GPU1 ผ่าน CUDA_VISIBLE_DEVICES=1 โดยไม่แตะโมเดลหรือเวิร์กโหลดเลย

ผลหลังสลับ runtime

หลังสลับเป็น 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 PASS · median 54.15 วินาที
เทียบ GPU0 ยุคเดียวกัน parity 100.3% (band ±50%)
ผลข้างเคียง GPU0 ศูนย์ — 8188 ยังเดินและเผยแพร่ภาพต่อในช่วงเดียวกัน

throughput ที่วัดได้จริงของ GPU1 หลังแก้ = 30.5 งานต่อชั่วโมง (10 งาน / 1,182 วินาที)

สิ่งที่เราไม่ได้ทำ (และไม่ควรทำ)

  • ไม่ได้ลบ venv เก่า — ทิ้งไว้ใน E:\ComfyUI ตามกติกา "ย้ายไม่ลบ" แค่เปลี่ยน schtask ให้ชี้ launcher ใหม่
  • ไม่ได้แตะ idle_watchdog ตัวเก่าที่เคยช่วยบูตซ้ำจนเกิดลูกแฝด — ถอดออกแล้วรับมือด้วยการ heal แบบกดเรียกเมื่อจำเป็น
  • ไม่ได้แต่หน้างานอื่นเลย: เวิร์กโหลด, พารามิเตอร์, โมเดล, ลำดับคิว — ทุกอย่างเหมือนเดิมไบต์ต่อไบต์

บทเรียนของห้องแล็บ

ถ้าเจอ GPU "ช้า" อย่าเพิ่งโทษโมเดลหรือเพิ่ม VRAM — อ่านสามค่านี้ก่อนเสมอ: SM, memory utilization, และวัตต์ ถ้า sm เต็มแต่ memory ศูนย์ ปัญหาอยู่ที่ runtime เกือบทั้งหมด และการพิสูจน์ที่ถูกต้องคือสลับตัวแปรเดียว (runtime) ทิ้งทุกอย่างเดิมไว้ แล้ววัดผล 10 งาน — ไม่ใช่เดาแล้วลงแรงหา driver ใหม่ตั้งแต่แรก