การตอบสนองต่อเหตุการณ์สำหรับคลัสเตอร์ GPU: Playbook สำหรับสถานการณ์ความล้มเหลวที่พบบ่อย

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

อัปเดตธันวาคม 2025: ความล้มเหลวของระบบระบายความร้อนด้วยของเหลวขึ้นเป็นหมวดหมู่เหตุการณ์อันดับต้นๆ สำหรับคลัสเตอร์ GPU สมัยใหม่—ความล้มเหลวของ CDU การตรวจจับการรั่วไหล ปัญหาคุณภาพน้ำหล่อเย็น ค่าใช้จ่ายจากการหยุดทำงานของ H100/H200 อยู่ที่ $25-40K ต่อ GPU-วัน ทำให้การตอบสนองอย่างรวดเร็วเป็นสิ่งสำคัญยิ่ง แพลตฟอร์ม AIOps (PagerDuty, Datadog) กำลังรวม runbook เฉพาะ GPU เข้าด้วยกัน Elastic training framework ช่วยลดรัศมีความเสียหายจากความล้มเหลวของ GPU การปรับความถี่ checkpoint ให้เหมาะสม (10-15 นาที) ช่วยลดการสูญเสียการฝึกจากเหตุการณ์

เมื่อ GPU H100 จำนวน 500 ตัวหยุดทำงานกะทันหันระหว่างการฝึกที่สำคัญ ทุกวินาทีมีค่าใช้จ่าย $1,200 จากเวลาประมวลผลที่สูญเสียไป เมื่อระบบระบายความร้อนด้วยของเหลวล้มเหลวในคลัสเตอร์ GPU ขนาด 2MW อุณหภูมิจะเพิ่มขึ้น 1°C ทุก 30 วินาทีจนถึงจุดปิดระบบเนื่องจากความร้อน เมื่อ InfiniBand fabric แบ่งพาร์ติชันระหว่างการฝึกแบบกระจาย การประมวลผล 10,000 GPU-ชั่วโมงจะกลายเป็นไร้ค่า สถานการณ์เหล่านี้ต้องการการตอบสนองที่แม่นยำและผ่านการฝึกซ้อมมาแล้ว เพื่อลดความเสียหายและกู้คืนบริการอย่างรวดเร็ว คู่มือนี้นำเสนอ playbook ที่ผ่านการทดสอบในสนามรบจริงสำหรับเหตุการณ์โครงสร้างพื้นฐาน GPU

การจำแนกเหตุการณ์และระดับความรุนแรง

เหตุการณ์โครงสร้างพื้นฐาน GPU ต้องการการจำแนกความรุนแรงเฉพาะทางนอกเหนือจากกรอบงาน IT แบบดั้งเดิม เหตุการณ์ระดับความรุนแรง 1 (วิกฤต) เกี่ยวข้องกับความล้มเหลวของคลัสเตอร์ทั้งหมด ความเสี่ยงต่อการสูญเสียข้อมูล หรืออันตรายด้านความปลอดภัยที่ส่งผลกระทบต่อ GPU มากกว่า 100 ตัว หรือผลกระทบรายชั่วโมง $50,000 สิ่งเหล่านี้จะกระตุ้นการยกระดับไปยังผู้บริหารทันที การติดต่อผู้ขาย และการเปิดใช้งาน war room ตลอด 24/7 การฝึก GPT-4 ของ OpenAI พบเหตุการณ์ระดับความรุนแรง 1 สามครั้งในช่วงหกเดือน แต่ละครั้งต้องการการมีส่วนร่วมของ CEO เนื่องจากค่าใช้จ่ายการฝึกรายวัน $2 ล้าน

เหตุการณ์ระดับความรุนแรง 2 (สูง) ส่งผลกระทบต่อ GPU 20-100 ตัว หรือทำให้ประสิทธิภาพลดลง 50% ทั่วทั้งคลัสเตอร์ขนาดใหญ่ เป้าหมายเวลาตอบสนองคือ 15 นาที โดยมีเป้าหมายแก้ไขภายใน 2 ชั่วโมง เหตุการณ์เหล่านี้มักเกี่ยวข้องกับความล้มเหลวของระบบระบายความร้อนบางส่วน ปัญหาการจ่ายไฟ หรือเหตุการณ์การแบ่งพาร์ติชันเครือข่าย โครงสร้างพื้นฐานของ Meta จะแจ้งเตือนวิศวกรเวรโดยอัตโนมัติสำหรับเหตุการณ์ระดับความรุนแรง 2 พร้อมการยกระดับไปยังสถาปนิกอาวุโสหลังจากผ่านไป 30 นาทีโดยไม่มีความคืบหน้า

เหตุการณ์ระดับความรุนแรง 3 (ปานกลาง) ส่งผลกระทบต่อ GPU น้อยกว่า 20 ตัว หรือทำให้ประสิทธิภาพลดลง 25% ซึ่งรวมถึงความล้มเหลวของโหนดแต่ละตัว ปัญหาไดรเวอร์ หรือปัญหาเครือข่ายเฉพาะที่ เป้าหมายการแก้ไขขยายเป็น 4 ชั่วโมง โดยการติดตามผลในวันทำการถัดไปเป็นที่ยอมรับได้ ระบบอัตโนมัติจัดการ 70% ของเหตุการณ์ระดับความรุนแรง 3 โดยไม่ต้องมีการแทรกแซงของมนุษย์ผ่านกลไกการซ่อมแซมตัวเอง

เหตุการณ์ระดับความรุนแรง 4 (ต่ำ) เกี่ยวข้องกับความล้มเหลวของ GPU ตัวเดียวหรือการเปลี่ยนแปลงประสิทธิภาพเล็กน้อยต่ำกว่า 10% สิ่งเหล่านี้เข้าสู่เวิร์กโฟลว์การออกตั๋วมาตรฐานโดยมีเป้าหมายการแก้ไขภายใน 24 ชั่วโมง โครงสร้างพื้นฐานของ Anthropic จะกักกันทรัพยากรที่ได้รับผลกระทบโดยอัตโนมัติ ช่วยให้ภาระงานการผลิตดำเนินต่อไปได้ขณะที่การซ่อมแซมดำเนินการในช่วงหน้าต่างการบำรุงรักษา

การคำนวณผลกระทบทางการเงินขับเคลื่อนการกำหนดระดับความรุนแรง GPU H100 แต่ละตัวแทนการลงทุนทุน $30,000 พร้อมค่าใช้จ่ายดำเนินงานรายชั่วโมง $50 การหยุดชะงักของการฝึกอาจทำให้การประมวลผลหลายวันมูลค่าหลายล้านดอลลาร์ไร้ผล Lambda Labs คำนวณค่าใช้จ่ายเหตุการณ์เป็น: (GPU ที่ได้รับผลกระทบ × อัตรารายชั่วโมง × ระยะเวลาที่คาดหวัง) + (เวลากู้คืน checkpoint × ค่าใช้จ่ายคลัสเตอร์) + (ค่าปรับ SLA) สูตรนี้ทำให้เกิดการจำแนกระดับความรุนแรง 1 สำหรับความล้มเหลวของ GPU 50 ตัวเนื่องจากค่าใช้จ่ายกู้คืน checkpoint $500,000

ขั้นตอนการตอบสนองต่อความล้มเหลวของไฟฟ้า

สถานการณ์ไฟฟ้าดับทั้งหมดต้องการการลดโหลดทันทีเพื่อป้องกันความล้มเหลวแบบลูกโซ่ระหว่างการกู้คืน ระบบ UPS ที่รองรับคลัสเตอร์ GPU มักให้รันไทม์ 5-7 นาทีที่โหลดเต็ม 30 วินาทีแรกกำหนดทิศทางของเหตุการณ์: สวิตช์ถ่ายโอนอัตโนมัติต้องทำงาน เครื่องกำเนิดไฟฟ้าต้องสตาร์ท และระบบระบายความร้อนต้องรักษาการทำงาน playbook ของ Microsoft เริ่มต้นการระงับภาระงานโดยอัตโนมัติภายใน 10 วินาทีหลังจากตรวจพบเหตุการณ์ไฟฟ้า

เฟส 1 (0-30 วินาที) มุ่งเน้นที่การรักษาสถานะ งานฝึกแบบกระจายต้อง checkpoint ทันที ซึ่งต้องการตำแหน่ง checkpoint ที่กำหนดค่าไว้ล่วงหน้าพร้อมแบนด์วิดท์เพียงพอ คำสั่ง kubectl exec กระตุ้นการ checkpoint ฉุกเฉินทั่วทั้ง Kubernetes pods ระบบจัดเก็บข้อมูลสลับไปโหมด write-through เพื่อรับประกันความคงทนของข้อมูล อุปกรณ์เครือข่ายบนระบบ UPS แยกต่างหากรักษาการเชื่อมต่อสำหรับการจัดการระยะไกล

เฟส 2 (30 วินาที - 2 นาที) เกี่ยวข้องกับการจัดลำดับความสำคัญของโหลด ภาระงานที่ไม่สำคัญจะยุติโดยอัตโนมัติตาม pod priority classes ภาระงาน inference ดำเนินการให้บริการต่อด้วยความจุที่ลดลง งานฝึกบันทึกสถานะและปิดระบบอย่างสง่างาม ระบบระบายความร้อนลดลงสู่การทำงานขั้นต่ำที่ยังคงใช้งานได้ รักษาอุณหภูมิต่ำกว่าขีดจำกัดความร้อน ระบบจัดการพลังงานลดโหลด 40% ขยายรันไทม์ UPS เป็น 15 นาที

เฟส 3 (2-5 นาที) ต้องการการซิงโครไนซ์เครื่องกำเนิดไฟฟ้า สวิตช์ถ่ายโอนอัตโนมัติซิงค์เอาต์พุตเครื่องกำเนิดไฟฟ้ากับระบบ UPS ก่อนถ่ายโอนโหลด การสตาร์ทเครื่องกำเนิดไฟฟ้าที่ล้มเหลวจะกระตุ้นการยกระดับทันทีพร้อมขั้นตอนการสตาร์ทด้วยตนเอง การตรวจสอบสถานะระบบเชื้อเพลิงรับประกันความจุรันไทม์ 24 ชั่วโมง ศูนย์ข้อมูลของ Google รักษาอุปทานเชื้อเพลิง 48 ชั่วโมงพร้อมสัญญาเติมเชื้อเพลิงอัตโนมัติที่เปิดใช้งานระหว่างการหยุดทำงานเป็นเวลานาน

ขั้นตอนการกู้คืนเริ่มต้นเมื่อไฟฟ้าเสถียรกลับคืนมา การฟื้นฟูแบบเป็นเฟสป้องกันกระแสไหลเข้าพร้อมกันทำให้ระบบไฟฟ้าเกินกำลัง ระบบจัดเก็บข้อมูลเริ่มต้นก่อน ตามด้วยโครงสร้างพื้นฐานเครือข่าย จากนั้นโหนดประมวลผลเป็นส่วนเพิ่มทีละ 10% ขีดจำกัดพลังงาน GPU ลดลงชั่วคราวเป็น 80% ระหว่างการรักษาเสถียรภาพ ความจุเต็มกลับคืนมาหลังจากการทำงานที่เสถียร 30 นาที ระบบอัตโนมัติกู้คืนของ CoreWeave นำ GPU 1,000 ตัวกลับสู่การผลิตใน 45 นาทีหลังจากการฟื้นฟูไฟฟ้า

การตอบสนองต่อความล้มเหลวของระบบระบายความร้อน

ความล้มเหลวของระบบระบายความร้อนด้วยของเหลวทวีความรุนแรงอย่างรวดเร็วโดยอุณหภูมิ GPU เพิ่มขึ้น 20°C ต่อนาทีหากไม่มีการระบายความร้อนที่ใช้งานอยู่ การตอบสนองทันทีจะกระตุ้นการลดความถี่โดยอัตโนมัติ ลดการสร้างความร้อนลง 40% คำสั่ง nvidia-smi -pl 400 ลดพลังงาน H100 จาก 700W เป็น 400W ซื้อเวลาตอบสนองที่สำคัญ การย้ายภาระงานไปยังโซนที่ไม่ได้รับผลกระทบเริ่มต้นโดยอัตโนมัติขณะที่ทีมซ่อมแซมระดมพล

ความล้มเหลวของ loop หลักต้องการการแยกส่วนที่ได้รับผลกระทบในขณะที่รักษาการไหลไปยังพื้นที่ที่ทำงานอยู่ วาล์ว bypass เปลี่ยนเส้นทางการไหลรอบส่วนประกอบที่ล้มเหลว ปั๊มสำรองเปิดใช้งาน รักษาความจุการไหล 60% ความล้มเหลวของ CDU (Coolant Distribution Unit) กระตุ้นการสลับอัตโนมัติไปยังหน่วยสำรองภายใน 30 วินาที ระบบ RSD (Rack Scale Design) ของ Supermicro รวมการควบคุมวาล์วอัตโนมัติที่แยกความล้มเหลวไปยังแร็คแต่ละตัว

ความล้มเหลวของ loop รองระหว่าง CDU และหอหล่อเย็นส่งผลกระทบต่อสิ่งอำนวยความสะดวกทั้งหมด เครื่องทำความเย็นฉุกเฉินเปิดใช้งานภายใน 2 นาที ให้การระบายความร้อนชั่วคราว บุคลากรศูนย์ข้อมูลเปิดช่องระบายอากาศฉุกเฉินด้วยตนเอง ระบายอากาศร้อนออกภายนอกโดยตรงแม้จะสูญเสียประสิทธิภาพ หน่วยระบายความร้อนแบบพกพาติดตั้งไปยังพื้นที่สำคัญภายใน 30 นาที สิ่งอำนวยความสะดวก Prineville ของ Facebook รักษาความจุระบายความร้อนแบบพกพา 2MW สำหรับการตอบสนองฉุกเฉิน

การตรวจจับการรั่วไหลกระตุ้นโปรโตคอลการแยกทันที เซ็นเซอร์น้ำใต้แร็ค GPU เปิดใช้งานวาล์วโซลินอยด์ หยุดการไหลภายใน 500 มิลลิวินาที แร็คที่ได้รับผลกระทบปิดเครื่องโดยอัตโนมัติขณะที่รักษาการเชื่อมต่อเครือข่ายสำหรับการวินิจฉัยระยะไกล ทีมกู้คืนติดตั้งวัสดุดูดซับและเครื่องลดความชื้นแบบพกพาเพื่อป้องกันการกัดกร่อน ศูนย์ข้อมูลใต้น้ำของ Microsoft ใช้ของเหลวระบายความร้อน dielectric ขจัดความเสี่ยงจากความเสียหายจากน้ำทั้งหมด

การเสริมการระบายความร้อนด้วยอากาศสนับสนุนระบบระบายความร้อนด้วยของเหลวระหว่างความล้มเหลวบางส่วน หน่วย CRAC (Computer Room Air Conditioning) เพิ่มเอาต์พุต 50% ชดเชยความจุระบายความร้อนด้วยของเหลวที่ลดลง ระบบกักเก็บทางเดินร้อนเปิดใช้งาน ปรับปรุงประสิทธิภาพการระบายความร้อน 20% พัดลมชั่วคราวติดตั้งในพื้นที่สำคัญ ให้การระบายความร้อนเฉพาะจุดสำหรับแร็คที่ร้อนเกินไป มาตรการเหล่านี้รักษาการทำงานระหว่าง 4-6 ชั่วโมงที่ต้องการสำหรับการซ่อมแซมระบบระบายความร้อนด้วยของเหลว

การแบ่งพาร์ติชันเครือข่ายและการสูญเสียการเชื่อมต่อ

การแบ่งพาร์ติชัน InfiniBand fabric ทำลายประสิทธิภาพการฝึกแบบกระจายทันที การตรวจจับอัตโนมัติกระตุ้นภายใน 100 มิลลิวินาทีโดยใช้ heartbeat ของ subnet manager โหนดที่ได้รับผลกระทบจะถูกกักกันโดยอัตโนมัติ ป้องกันการอัปเดตบางส่วนที่ทำให้สถานะโมเดลเสียหาย ตัวจัดตารางงานได้รับการอัปเดต topology จัดตารางงานใหม่ไปยังพาร์ติชันที่สมบูรณ์ การจัดการข้อผิดพลาด NCCL ยุติ collective operation ที่ได้รับผลกระทบอย่างสะอาด

การกู้คืนต้องการการสร้าง fabric ใหม่อย่างเป็นระบบ subnet manager opensm สร้างตารางเส้นทางใหม่ ค้นพบเส้นทางที่รอดชีวิต การทำงาน fabric บางส่วนดำเนินต่อไปด้วยแบนด์วิดท์ที่ลดลงขณะที่การซ่อมแซมดำเนินการ การลดความกว้างลิงก์จาก 4x เป็น 2x รักษาการเชื่อมต่อด้วยการลดแบนด์วิดท์ 50% โครงสร้างพื้นฐาน EFA (Elastic Fabric Adapter) ของ Amazon เปลี่ยนเส้นทางโดยอัตโนมัติรอบความล้มเหลว รักษาแบนด์วิดท์รวม 85% ระหว่างความล้มเหลวของสวิตช์เดียว

ความล้มเหลวของเครือข่าย Ethernet ส่งผลกระทบต่อทั้งภาระงานการฝึกและ inference แตกต่างกัน การบรรจบ BGP (Border Gateway Protocol) เสร็จสมบูรณ์ภายใน 30 วินาทีสำหรับเส้นทางสำรอง การกำหนดเส้นทาง ECMP (Equal-Cost Multi-Path) กระจายทราฟฟิกข้ามลิงก์ที่รอดชีวิต การจัดลำดับความสำคัญของทราฟฟิกจัดเก็บข้อมูลรับประกันว่าการดำเนินการ checkpoint เสร็จสมบูรณ์แม้จะมีแบนด์วิดท์ที่ลดลง นโยบาย Quality of Service รับประกันแบนด์วิดท์ 40% สำหรับการดำเนินการที่สำคัญ

การแยกเครือข่ายโดยสมบูรณ์กระตุ้นโหมดการทำงานอัตโนมัติ โหนดดำเนินการประมวลผลท้องถิ่นต่อไปขณะที่บัฟเฟอร์ผลลัพธ์ งานฝึกแบบกระจายหยุดที่อุปสรรคการซิงโครไนซ์ รักษาสถานะ ที่เก็บข้อมูล NVMe ท้องถิ่นบัฟเฟอร์ข้อมูล checkpoint สูงสุด 1TB รอการฟื้นฟูการเชื่อมต่อ เมื่อเครือข่ายกู้คืน ข้อมูลที่บัฟเฟอร์จะซิงโครไนซ์โดยอัตโนมัติ กลับมาทำงานภายในไม่กี่นาทีแทนที่จะเป็นชั่วโมงของการรีสตาร์ท

ความล้มเหลวของ DNS และ service discovery ป้องกันการจัดตารางภาระงานแม้ว่าโครงสร้างพื้นฐานจะทำงานได้ เซิร์ฟเวอร์ DNS สำรองเปิดใช้งานโดยอัตโนมัติด้วยค่า TTL (Time To Live) 15 วินาทีที่ช่วยให้อัปเดตได้อย่างรวดเร็ว Kubernetes CoreDNS pods รีสตาร์ทบนโหนดที่ไม่ได้รับผลกระทบภายใน 30 วินาที การกำหนดค่า IP แบบคงที่ใน runbook ฉุกเฉินข้าม DNS สำหรับการเข้าถึงการจัดการที่สำคัญ HashiCorp Consul ให้ความยืดหยุ่นของ service mesh พร้อม failover อัตโนมัติสำหรับ service discovery

การป้องกันการเกิดความล้มเหลวแบบลูกโซ่ของฮาร์ดแวร์

ความล้มเหลวของ GPU ตัวเดียวสามารถเกิดลูกโซ่ผ่านงานฝึกแบบกระจายที่ส่งผลกระทบต่อเครื่องหลายร้อยตัว การแยกทันทีป้องกันการแพร่กระจายข้อผิดพลาด คำสั่ง nvidia-smi drain นำ GPU ออกจากพูลทรัพยากรอย่างสง่างาม Kubernetes device plugins ทำเครื่องหมาย GPU ที่ล้มเหลวว่าไม่สมบูรณ์ ป้องกันการจัดตาราง pod ใหม่ ภาระงานที่ทำงานอยู่จะย้ายไปยังทรัพยากรที่สมบูรณ์ภายใน 2 นาที

ข้อผิดพลาดหน่วยความจำกระตุ้นการตอบสนองแบบก้าวหน้าตามความรุนแรง ข้อผิดพลาดบิตเดียวที่แก้ไขโดย ECC ดำเนินการต่อด้วยความถี่การตรวจสอบที่เพิ่มขึ้น ข้อผิดพลาดสองบิตทำให้เกิดการย้ายภาระงานทันทีและการกักกัน GPU การหมดอายุการเกษียณหน้าหน่วยความจำกระตุ้นการจัดตารางเปลี่ยนฮาร์ดแวร์ ระบบสั่งซื้ออัตโนมัติรักษาสินค้าคงคลังสำรอง 2% สำหรับการเปลี่ยนอย่างรวดเร็ว

ความล้มเหลวของแหล่งจ่ายไฟในการกำหนดค่าสำรองดำเนินการต่อด้วยความจุที่ลดลง การกำหนดค่า N+1 สูญเสียความซ้ำซ้อนแต่รักษาการทำงานเต็มรูปแบบ การปรับสมดุลโหลดกระจายการดึงพลังงานข้ามแหล่งจ่ายที่รอดชีวิต ประสิทธิภาพลดลง 5-10% เพิ่มการสร้างความร้อน การจัดตารางการเปลี่ยนกำหนดเป้าหมายการตอบสนอง 4 ชั่วโมงสำหรับการฟื้นฟูความซ้ำซ้อน คลัสเตอร์ Dojo ของ Tesla รักษาแหล่งจ่ายไฟสำรองแบบ hot-spare ที่ช่วยให้เปลี่ยนได้ใน 5 นาที

ความล้มเหลวของส่วนประกอบเมนบอร์ดต้องการการวินิจฉัยอย่างระมัดระวังเพื่อแยกความแตกต่างระหว่างความล้มเหลวที่ซ่อมแซมได้และความล้มเหลวที่สิ้นสุด PCIe retimers บางครั้งต้องการการใส่ใหม่ เพื่อฟื้นฟูการทำงานโดยไม่ต้องเปลี่ยน ความล้มเหลวของ VRM (Voltage Regulator Module) อาจส่งผลกระทบต่อ GPU ตัวเดียวในขณะที่ตัวอื่นดำเนินการต่อ ขั้นตอนการกู้คืน BIOS ฟื้นฟูเฟิร์มแวร์ที่เสียหายโดยไม่ต้องเปลี่ยนฮาร์ดแวร์ การวินิจฉัยแบบบูรณาการของ Dell EMC ระบุความล้มเหลวระดับส่วนประกอบที่ช่วยให้ซ่อมแซมได้ตรงจุด

การป้องกันการเกิดความร้อนแบบลูกโซ่ต้องการการแทรกแซงอย่างเข้มข้น อุณหภูมิ GPU ที่อยู่ติดกันเพิ่มขึ้น 5-10°C เมื่อเพื่อนบ้านล้มเหลว การกระจายภาระงานใหม่ป้องกันการก่อตัวของจุดร้อน หน่วยแร็คว่างระหว่างฮาร์ดแวร์ที่ล้มเหลวปรับปรุงการไหลของอากาศ เครื่องระบายความร้อนเฉพาะจุดแบบพกพาติดตั้งภายใน 15 นาทีสำหรับพื้นที่สำคัญ

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