การแก้ไขปัญหา GPU Cluster: ปัญหาที่พบบ่อยและคู่มือการแก้ไข

อัปเดต 8 ธันวาคม 2025

อัปเดตธันวาคม 2025: ความล้มเหลวของระบบระบายความร้อนด้วยของเหลวกลายเป็นหมวดหมู่เหตุการณ์อันดับหนึ่ง—ปัญหา CDU การปนเปื้อนของสารหล่อเย็น อากาศติดขัด NVIDIA DCGM 3.3+ ปรับปรุงความครอบคลุมการวินิจฉัยสำหรับ H100/H200 รหัสข้อผิดพลาด XID อัปเดตสำหรับสถาปัตยกรรม Blackwell รูปแบบข้อผิดพลาดหน่วยความจำ (การแก้ไข ECC, row remapping) ถูกนำมาใช้มากขึ้นสำหรับการตรวจจับความล้มเหลวเชิงคาดการณ์ การวินิจฉัย NVLink จำเป็นสำหรับปัญหาการฝึกสอนแบบ multi-GPU

GPU cluster ล้มเหลวแตกต่างจากโครงสร้างพื้นฐานการประมวลผลแบบดั้งเดิม GPU ที่เสื่อมประสิทธิภาพเพียงตัวเดียวใน training cluster 512 โหนดสามารถลด throughput โดยรวมได้ถึง 40% ข้อผิดพลาดหน่วยความจำที่อาจยอมรับได้ในงาน CPU ทำให้การ training ล้มเหลวทันที ความล่าช้าของเครือข่ายในระดับไมโครวินาทีทำลายประสิทธิภาพของ distributed training คู่มือนี้นำเสนอแนวทางเชิงระบบในการวินิจฉัยและแก้ไขโหมดความล้มเหลวเฉพาะของโครงสร้างพื้นฐาน GPU

รูปแบบความล้มเหลวของฮาร์ดแวร์และการวินิจฉัย

ความล้มเหลวของฮาร์ดแวร์ GPU แสดงออกผ่านสามรูปแบบหลัก: ความล้มเหลวทันที ประสิทธิภาพลดลง และข้อผิดพลาดเป็นระยะ ความล้มเหลวทันทีมักกระตุ้นข้อผิดพลาด XID ในการติดตั้ง NVIDIA โดย XID 79 (GPU has fallen off the bus) ส่งผลกระทบต่อ 3.2% ของการติดตั้ง H100 ในปีแรกตามรายงานโครงสร้างพื้นฐานของ Meta ความล้มเหลวเหล่านี้ต้องการการแยกอย่างเป็นระบบเพื่อระบุสาเหตุที่แท้จริง

NVIDIA Data Center GPU Manager (DCGM) ให้การวินิจฉัยฮาร์ดแวร์ที่ครอบคลุมผ่านคำสั่ง dcgmi diag การวินิจฉัยระดับ 3 ทำงาน 12 นาที ทดสอบ memory bandwidth, PCIe throughput, การเชื่อมต่อ NVLink และพฤติกรรมความร้อนภายใต้โหลด กลุ่ม Azure GPU ของ Microsoft รันการวินิจฉัย DCGM บน GPU 100,000 ตัวทุกคืน ระบุฮาร์ดแวร์ที่เสื่อมประสิทธิภาพก่อนส่งผลกระทบต่อลูกค้า ระบบอัตโนมัติของพวกเขาถอด GPU ที่แสดงการเสื่อมประสิทธิภาพ 15% ออกจาก production pools

ข้อผิดพลาดหน่วยความจำครองสถิติความล้มเหลวของ GPU High Bandwidth Memory (HBM) ใน GPU H100 ทำงานที่ 3.35TB/s ทำให้มีความเสี่ยงต่อทั้ง hard และ soft errors ECC (Error-Correcting Code) จับ single-bit errors แต่ uncorrectable double-bit errors (DBE) ต้องเปลี่ยน GPU ทันที การวิเคราะห์ของ Google Cloud แสดงว่าข้อผิดพลาด HBM เพิ่มขึ้นแบบเอกซ์โพเนนเชียลเกิน 75°C โดยอัตราความล้มเหลวเพิ่มเป็นสองเท่าสำหรับทุกๆ 5°C ที่เพิ่มขึ้นเกินเกณฑ์นี้

ความล้มเหลวของอินเทอร์เฟซ PCIe แสดงออกเป็นการเสื่อมของ bandwidth หรือการสูญเสียการเชื่อมต่อโดยสมบูรณ์ คำสั่ง nvidia-smi -q เปิดเผยสถานะลิงก์ PCIe แสดง generation และ width ปัจจุบัน GPU H100 ต้องการ PCIe Gen5 x16 สำหรับ bandwidth เต็ม 128GB/s การเสื่อมลงเป็นความเร็ว Gen4 ลด bandwidth เหลือ 64GB/s ส่งผลกระทบต่อเวลาโหลดโมเดล 50% Lambda Labs พบว่า 8% ของเซิร์ฟเวอร์ GPU ของพวกเขาทำงานที่ความเร็ว PCIe ที่ลดลงเนื่องจากการตั้งค่า BIOS ผิดพลาด ทำให้สูญเสีย 2.3 ล้านดอลลาร์ต่อปีจากการใช้งานที่ลดลง

ความล้มเหลวของการจ่ายไฟสร้างปัญหาประสิทธิภาพที่ละเอียดอ่อนก่อนความล้มเหลวโดยสมบูรณ์ Voltage Regulator Modules (VRMs) บนบอร์ด H100 รองรับ 700A ที่แรงดันแกน 1.1V VRM ที่เสื่อมทำให้เกิด power throttling ลดความถี่ GPU จาก 1.98GHz ลงเหลือ 1.2GHz เครื่องมือตรวจสอบต้องติดตามทั้งการใช้พลังงานแบบทันทีและเฉลี่ย CoreWeave ใช้การตรวจสอบพลังงานแบบ differential เปรียบเทียบงานที่เหมือนกันระหว่าง GPU เพื่อระบุการเสื่อมของการจ่ายไฟ 5% ก่อนส่งผลกระทบต่อลูกค้า

ปัญหาไดรเวอร์และเฟิร์มแวร์

ความไม่ตรงกันของเวอร์ชันไดรเวอร์ทำให้เกิด 31% ของปัญหา GPU cluster ตามสถิติการสนับสนุนของ NVIDIA แอปพลิเคชัน CUDA ที่คอมไพล์สำหรับเวอร์ชันไดรเวอร์เฉพาะล้มเหลวอย่างลึกลับเมื่อมีการอัปเดตไดรเวอร์ เครื่องมือ nvidia-smi แสดงเวอร์ชันไดรเวอร์ 545.23.08 แต่แอปพลิเคชันอาจต้องการ 535.104.12 สำหรับฟีเจอร์ CUDA เฉพาะ การล็อกเวอร์ชันป้องกันการอัปเดตอัตโนมัติแต่ต้องจัดการแพตช์ความปลอดภัยด้วยตนเอง

การซิงโครไนซ์เฟิร์มแวร์ระหว่าง cluster เป็นสิ่งสำคัญสำหรับ distributed training ความไม่ตรงกันของเฟิร์มแวร์ NVLink ระหว่าง GPU ทำให้ collective operations ล้มเหลวด้วยข้อผิดพลาด NCCL ที่เข้าใจยาก คำสั่ง nvidia-smi -q | grep "VBIOS Version" เปิดเผยเวอร์ชันเฟิร์มแวร์ที่ต้องตรงกันทุกประการเพื่อประสิทธิภาพสูงสุด training cluster GPT-4 ของ OpenAI กำหนดมาตรฐานเวอร์ชันเฟิร์มแวร์เฉพาะ โดยความเบี่ยงเบนใดๆ จะกระตุ้นการกักกันโหนดอัตโนมัติ

การรั่วไหลของหน่วยความจำไดรเวอร์สะสมตลอดหลายสัปดาห์ของการทำงาน การสร้าง CUDA context โดยไม่มีการล้างที่เหมาะสมใช้หน่วยความจำระบบ ในที่สุดทำให้เกิดข้อผิดพลาด out-of-memory แม้ว่า VRAM จะยังมีอยู่ คำสั่ง nvidia-smi แสดง 0MB ที่ใช้ แต่ lsof เปิดเผย file descriptors ที่ถูกทิ้งหลายพันตัว โครงสร้างพื้นฐานของ Anthropic รีสตาร์ทไดรเวอร์ GPU ที่แสดง file descriptors เปิดมากกว่า 1000 ตัวโดยอัตโนมัติ ป้องกันการหมดหน่วยความจำ

ความขัดแย้งของ kernel module ระหว่าง nouveau (โอเพนซอร์ส) และไดรเวอร์ NVIDIA แบบ proprietary สร้างความล้มเหลวในการเริ่มต้น คำสั่ง lsmod | grep nouveau เปิดเผยโมดูลที่ขัดแย้งซึ่งต้องถูก blacklist ระบบ Ubuntu 22.04 ต้องการการ blacklist อย่างชัดเจนใน /etc/modprobe.d/blacklist-nouveau.conf ตามด้วย update-initramfs -u เพื่อป้องกันการโหลดระหว่างบูต ปัญหานี้ส่งผลกระทบต่อ 12% ของการติดตั้งใหม่ตามข้อมูลสนับสนุนของ Canonical

การตั้งค่า container runtime ที่ผิดพลาดป้องกันการเข้าถึง GPU แม้ว่าจะติดตั้งไดรเวอร์ถูกต้อง NVIDIA Container Toolkit เวอร์ชัน 1.14.0 แนะนำการเปลี่ยนแปลงที่ไม่เข้ากันซึ่งต้องเลือกอุปกรณ์อย่างชัดเจนผ่านตัวแปรสภาพแวดล้อม NVIDIA_VISIBLE_DEVICES Docker containers ที่เริ่มต้นโดยไม่มี flag --gpus all ดูเหมือนจะทำงานแต่คำนวณบน CPU เท่านั้นที่ความเร็ว 1/100 ของที่คาดหวัง การติดตั้ง Kubernetes ต้องการ resource limits nvidia.com/gpu ในข้อกำหนด pod สำหรับการจัดตาราง GPU ที่เหมาะสม

ปัญหาการจัดการความร้อน

Thermal throttling ลดประสิทธิภาพ GPU ก่อนกระตุ้นการปิดเครื่องเพื่อความปลอดภัย GPU H100 throttle ที่ 83°C ลดความเร็วสัญญาณนาฬิกา 15MHz สำหรับทุกองศาที่เกินเกณฑ์ การติดตั้งใน production ควรรักษาอุณหภูมิต่ำกว่า 75°C เพื่อประสิทธิภาพสูงสุด คำสั่ง nvidia-smi -q -d TEMPERATURE ให้อุณหภูมิปัจจุบัน สูงสุด และ throttle สำหรับการตรวจสอบเชิงรุก

ความล้มเหลวของระบบระบายความร้อนด้วยของเหลวนำเสนอความท้าทายในการวินิจฉัยที่เฉพาะตัว การเสื่อมของอัตราการไหล 20% เพิ่มอุณหภูมิ GPU 8-10°C เซ็นเซอร์แรงดันที่ทางออก CDU (Coolant Distribution Unit) ควรรักษา 30-35 PSI สำหรับการไหลที่เหมาะสม cluster ระบายความร้อนด้วยของเหลวของ Microsoft ใช้การตรวจสอบแรงดันแบบ differential แจ้งเตือนเมื่อแรงดันลดลงเกิน 5 PSI ระหว่าง supply และ return manifolds การปนเปื้อนอนุภาคทำให้เกิด 60% ของการจำกัดการไหล ต้องเปลี่ยนฟิลเตอร์ทุกไตรมาส

จุดร้อนเกิดจากการทา thermal paste ไม่สม่ำเสมอหรือการติดตั้ง cold plate ภาพความร้อนเปิดเผยความแตกต่างของอุณหภูมิเกิน 15°C ข้ามแผ่น GPU การติดตั้งที่เหมาะสมต้องใช้แรงบิด 35 in-lbs บนสกรูยึด โดยใช้รูปแบบกากบาทเพื่อให้แน่ใจว่าแรงกดสม่ำเสมอ กระบวนการผลิตของ Supermicro รวมการตรวจสอบความร้อนแสดงความแตกต่างน้อยกว่า 5°C ข้ามแผ่น โดยต้องติดตั้งใหม่สำหรับความแตกต่างที่มากกว่า

การเปลี่ยนแปลงอุณหภูมิแวดล้อมระหว่างโซน cluster สร้างความไม่สมดุลของประสิทธิภาพ GPU ใน hot aisles ที่อุณหภูมิแวดล้อมถึง 35°C throttle บ่อยกว่า 20% เมื่อเทียบกับที่ 25°C การสร้างแบบจำลอง Computational Fluid Dynamics (CFD) ระบุโซนการหมุนเวียนที่อากาศไอเสียเข้าสู่เส้นทางไอดีอีกครั้ง ศูนย์ข้อมูลของ Facebook ใช้โซลูชันการควบคุมรักษาความสม่ำเสมอของอุณหภูมิ 3°C ข้าม GPU 10,000 ตัว

ความล้มเหลวของพัดลมลุกลามผ่านการติดตั้ง GPU หนาแน่น GPU H100 แต่ละตัวพึ่งพาพัดลมระบบที่ให้การไหลเวียนอากาศ 200 CFM ความล้มเหลวของพัดลมตัวเดียวเพิ่มอุณหภูมิ GPU ข้างเคียง 5-7°C การกำหนดค่าพัดลมซ้ำซ้อน (N+1) ป้องกันเหตุการณ์ความร้อน แต่ต้องใช้พลังงานเพิ่ม 20% การบำรุงรักษาเชิงคาดการณ์โดยใช้ความแปรผันของความเร็วพัดลมระบุตลับลูกปืนที่เสียหาย 30 วันก่อนความล้มเหลวโดยสมบูรณ์ ช่วยให้เปลี่ยนทดแทนได้เชิงรุก

การแก้ไขปัญหาเครือข่ายและการเชื่อมต่อ

ปัญหา fabric InfiniBand ทวีคูณข้ามงาน distributed training ข้อผิดพลาดลิงก์เดียวทำให้การดำเนินการ MPI_Allreduce ค้างไม่มีกำหนด คำสั่ง ibdiagnet ทำการตรวจสอบ fabric อย่างครอบคลุม ตรวจสอบความเร็วลิงก์ ตัวนับข้อผิดพลาด และตารางการกำหนดเส้นทาง Symbol errors เกิน 100 ต่อชั่วโมงบ่งชี้ว่าสายเคเบิลเสื่อมสภาพต้องเปลี่ยน โครงสร้างพื้นฐานของ Meta ถอดโหนดที่แสดงข้อผิดพลาด InfiniBand มากเกินไปออกจาก training pools โดยอัตโนมัติ

การเสื่อมประสิทธิภาพ RDMA (Remote Direct Memory Access) เกิดขึ้นโดยไม่มีข้อผิดพลาดที่ชัดเจน PCIe Access Control Services (ACS) ต้องถูกปิดใช้งานสำหรับการถ่ายโอนแบบ peer-to-peer ระหว่าง GPU คำสั่ง setpci แก้ไข PCIe configuration space แต่การเปลี่ยนแปลงไม่คงอยู่ข้ามการรีบูตโดยไม่มีการแก้ไข BIOS การวัดความล่าช้าโดยใช้ ib_write_lat ควรแสดง 1.8 ไมโครวินาทีสำหรับการเชื่อมต่อในเครื่อง โดยความแปรผัน 10% บ่งชี้ความแออัดหรือการตั้งค่าผิดพลาด

การตั้งค่า topology NVLink ที่ผิดพลาดลด bandwidth ระหว่างคู่ GPU คำสั่ง nvidia-smi topo -m แสดง topology การเชื่อมต่อ โดย NV12 บ่งชี้ bandwidth NVLink เต็มที่และ PHB แสดงการเชื่อมต่อ PCIe เท่านั้น การกำหนดค่าที่เหมาะสมสร้าง mesh NVLink ที่เชื่อมต่อเต็มรูปแบบภายในโหนด instance p5.48xlarge ของ Amazon ให้ bandwidth NVLink แบบสองทิศทาง 900GB/s เมื่อกำหนดค่าอย่างเหมาะสม แต่การตั้งค่าผิดพลาดลดลงเหลือความเร็ว PCIe 64GB/s

ความแออัดของเครือข่ายจากทราฟฟิก storage ส่งผลกระทบต่อการสื่อสาร GPU การติดตั้งแบบ Ethernet/InfiniBand ผสมต้องการการกำหนดค่า Quality of Service (QoS) อย่างระมัดระวัง ทราฟฟิก storage ที่ใช้ 40% ของ bandwidth ที่มีเพิ่มเวลาการดำเนินการ MPI collective 3 เท่า เครือข่าย storage เฉพาะหรือการจัดรูปแบบทราฟฟิกรักษา 60% bandwidth สำรองสำหรับการสื่อสาร GPU ป้องกันการชะลอตัวของการ training

ข้อผิดพลาดการซิงโครไนซ์เวลาทำให้ distributed training ล้มเหลว clock skew เกิน 1 มิลลิวินาทีระหว่างโหนดทำให้เกิดข้อผิดพลาด NCCL timeout Precision Time Protocol (PTP) รักษาการซิงโครไนซ์ระดับ sub-microsecond แต่ต้องการการสนับสนุน hardware timestamps คำสั่ง chrony sources แสดงสถานะการซิงโครไนซ์ โดยค่า offset เกิน 100 ไมโครวินาทีต้องแก้ไขทันที โครงสร้างพื้นฐานของ Google รักษาการซิงโครไนซ์ 100-nanosecond ข้าม GPU cluster ทั่วโลกโดยใช้การอ้างอิง atomic clock

การตรวจจับและแก้ไขข้อผิดพลาดหน่วยความจำ

ข้อผิดพลาด HBM (High Bandwidth Memory) ปฏิบัติตามรูปแบบที่คาดเดาได้ช่วยให้แทรกแซงเชิงรุก Single-bit errors ที่แก้ไขโดย ECC บ่งชี้เซลล์หน่วยความจำที่เสื่อมสภาพ คำสั่ง nvidia-smi -q -d ECC รายงานทั้งจำนวนข้อผิดพลาดแบบ volatile และ aggregate จำนวน volatile รีเซ็ตเมื่อรีบูต ในขณะที่จำนวน aggregate คงอยู่ GPU ที่แสดง single-bit errors มากกว่า 10 ต่อชั่วโมงควรกำหนดการเปลี่ยนในช่วงหน้าต่างการบำรุงรักษาถัดไป

ความล้มเหลวในการจัดสรรหน่วยความจำแม้ว่า VRAM จะยังมีบ่งชี้ fragmentation torch.cuda.memory_stats() ของ PyTorch เปิดเผยหน่วยความจำที่จัดสรรเทียบกับที่สงวน หน่วยความจำที่สงวนอาจเป็น 2 เท่าของที่จัดสรรเนื่องจากพฤติกรรม caching allocator ตัวแปรสภาพแวดล้อม PYTORCH_CUDA_ALLOC_CONF กำหนดค่ากลยุทธ์การจัดสรร โดย max_split_size_mb=512 ลด fragmentation สำหรับโมเดลที่มีขนาด tensor หลากหลาย

เกณฑ์ page retirement กำหนดอายุการใช้งาน GPU NVIDIA GPU ถอน memory pages ที่เกิดข้อผิดพลาดที่แก้ไขไม่ได้ ลดหน่วยความจำที่มี คำสั่ง nvidia-smi -q -d PAGE_RETIREMENT แสดงจำนวน page ที่ถอนและความพร้อมของ pages เพิ่มเติม GPU H100 สามารถถอนได้ถึง 512 pages ก่อนต้องเปลี่ยน การตรวจสอบอัตโนมัติควรกระตุ้นการเปลี่ยนเมื่อถอน 400 pages ป้องกันความล้มเหลวโดยสมบูรณ์ระหว่างการ training ที่สำคัญ

การเสื่อมของ memory bandwidth บ่งชี้ปัญหาความร้อนหรือพลังงาน ตัวอย่าง CUDA bandwidthTest ควรได้ 3.35TB/s บน GPU H100 ประสิทธิภาพต่ำกว่า 3.0TB/s บ่งชี้ throttling คำสั่ง nvidia-smi -q -d PERFORMANCE เปิดเผยความเร็ว memory clock ปัจจุบัน ความเร็วที่ลดลงมักสัมพันธ์กับอุณหภูมิเกิน 75°C หรือการใช้พลังงานเข้าใกล้ขีดจำกัด TDP

ข้อผิดพลาด CUDA out of memory (OOM) ต้องการการ debug อย่างเป็นระบบ ตัวแปรสภาพแวดล้อม CUDA_LAUNCH_BLOCKING=1 บังคับการทำงานแบบ synchronous ให้ตำแหน่งข้อผิดพลาดที่แม่นยำ การ profiling หน่วยความจำโดยใช้ nsys profile เปิดเผยรูปแบบการจัดสรรและอายุการใช้งาน

[เนื้อหาถูกตัดสำหรับการแปล]