เลือกเครื่องมือ Observability สำหรับ NVIDIA AI Factories อย่างไรให้มีประสิทธิภาพ

เลือกเครื่องมือ Observability สำหรับ NVIDIA AI Factories อย่างไรให้มีประสิทธิภาพโครงสร้างพื้นฐาน AI นั้นซับซ้อน ครอบคลุมหลายชั้น ตั้งแต่การประมวลผล (Compute) เครือข่าย (Networking) ไปจนถึงการจัดเก็บข้อมูล (Storage) การจัดการ (Orchestration) และแอปพลิเคชัน เมื่อประสิทธิภาพลดลง การระบุต้นตอของปัญหาอาจเป็นเรื่องยาก เพราะอาการที่พบในชั้นหนึ่งอาจมีสาเหตุมาจากชั้นอื่นในสแต็กได้การมีกลยุทธ์ Full-Stack Observability ที่ดี จะช่วยเชื่อมโยงข้อมูล Telemetry จากทุกชั้นเข้าด้วยกัน ทำให้ทีมปฏิบัติการสามารถตรวจจับปัญหา แยกแยะสาเหตุ และรักษาความเสถียรของเวิร์กโหลด AI ได้อย่างมีประสิทธิภาพ บทความนี้จะนำเสนอแนวทางปฏิบัติเพื่อเลือกเครื่องมือ Observability ที่เหมาะสมสำหรับโครงสร้างพื้นฐาน NVIDIA AI และแสดงวิธีการนำไปใช้ในสถานการณ์ทั่วไปทำไม Full-Stack Observability จึงสำคัญสำหรับ AI Factories?ลองนึกภาพการเทรนโมเดล AI แบบกระจายที่ดำเนินมาสามวันแล้ว แต่พบว่าอัตราการผลิตลดลงอย่างเห็นได้ชัด แม้ว่าการใช้งาน GPU และเวลารอคอยคิวจะยังคงปกติ การไล่ตรวจสอบพบว่าสาเหตุมาจาก "ความล้มเหลวแบบสีเทา" (Gray Failure) ในลิงก์ InfiniBand เพียงลิงก์เดียว ที่เริ่มมีอัตราข้อผิดพลาดของบิต (Bit Error Rate) สูงขึ้นนี่คือตัวอย่างคลาสสิกที่ฮาร์ดแวร์เริ่มเสื่อมสภาพ แต่ระบบยังไม่รายงานว่า "ดาวน์" (Down) การเทรน AI มักใช้โมเดล Bulk Synchronous Parallel (BSP) ซึ่งระบบที่เชื่อมต่อกันอย่างใกล้ชิดเหล่านี้มีความอ่อนไหวต่อ "Stragglers" หรือส่วนที่ทำงานช้า หากมีส่วนใดส่วนหนึ่งช้า จะส่งผลกระทบต่อทั้งระบบ โดยเฉพาะการดำเนินการแบบ Collective Operations เช่น NVIDIA Collective Communications Library (NCCL) all-reduce ที่หากลิงก์มีปัญหา การส่งข้อมูลจะล่าช้า ทำให้ส่วนที่เหลือต้องรอ ส่งผลให้ประสิทธิภาพโดยรวมลดลงปัญหานี้พบได้บ่อยใน AI Factories ข้อมูล Telemetry ที่จำเป็นมักมีอยู่แล้ว แต่ความท้าทายคือการเลือกสัญญาณที่ถูกต้องจากเครื่องมือที่เหมาะสมตั้งแต่เนิ่นๆ เพื่อให้สามารถดำเนินการได้ทันท่วงที ผู้ปฏิบัติงานไม่จำเป็นต้องมีเมตริกทั้งหมดจากทุกผลิตภัณฑ์ แต่ต้องการ เส้นทางการตัดสินใจ ที่เชื่อมโยงส่วนประกอบต่างๆ เข้ากับเครื่องมือ ชุดการแจ้งเตือนที่กระชับ และแดชบอร์ดเดียวสำหรับการตรวจสอบปัญหา (Triage)การระบุ Failure Domains ที่ต้องสังเกตการณ์ก่อนที่จะเลือกซอฟต์แวร์การตรวจสอบ ควรระบุ "โดเมนความล้มเหลว" (Failure Domains) ที่อาจทำให้เวลา GPU สูญเปล่าโดยไม่รู้ตัว:สุขภาพแพลตฟอร์ม (Platform Health): พัดลม, แหล่งจ่ายไฟ (PSU), BMC, แชสซี, CPU, หน่วยความจำ, พื้นที่จัดเก็บข้อมูลภายในสุขภาพและประสิทธิภาพ GPU (GPU Health & Performance): การใช้งาน (Utilization), อุณหภูมิ, การใช้พลังงาน, XID/ECC, และปริมาณงาน NVLinkเครือข่าย (Fabric): ความสมบูรณ์ของลิงก์ InfiniBand หรือ Ethernet, ความแออัด, สุขภาพสวิตช์/สายเคเบิล; NVLink ระดับแร็ค (Rack-scale NVLink) หากมีคลัสเตอร์และงาน (Cluster & Jobs): การจัดตารางเวลา (Scheduling), การจองทรัพยากร (Reservations), GPU ที่ถูกจัดสรรแต่ไม่ได้ใช้งาน, เวลาที่ต้องรอในคิวบริการ Inference (Inference Services): ความหน่วง (Latency), อัตราความสำเร็จ (Success Rate), และพฤติกรรมแคช เมื่อใช้ NVIDIA NIM microservices หรือบริการที่คล้ายกันในระบบที่ซับซ้อน ช่องว่างในการครอบคลุมมักไม่สามารถแก้ไขได้ในครั้งเดียว แต่อาจปรากฏขึ้นภายหลังเมื่อเกิดความล้มเหลวที่ซ่อนอยู่ภายใต้ภาระงานหนัก การวิเคราะห์โหมดความล้มเหลวเหล่านี้ตั้งแต่เนิ่นๆ จะช่วยลดระยะเวลาในการค้นพบและป้องกันไม่ให้ปัญหาเกิดขึ้นซ้ำการจับคู่ส่วนประกอบ AI Infrastructure กับเครื่องมือ Telemetryทีมปฏิบัติการต้องการการจับคู่ที่ชัดเจนระหว่างส่วนประกอบและแหล่งที่มาของ Telemetry เครื่องมือหลักที่ใช้กัน ได้แก่:NVIDIA Data Center GPU Manager (DCGM): สำหรับการจัดการและตรวจสอบ GPUNVIDIA System Management (NVSM): สำหรับตรวจสอบสุขภาพระบบโดยรวมของโหนด DGXNVIDIA Unified Fabric Manager (UFM): สำหรับจัดการและตรวจสอบเครือข่าย InfiniBandNVIDIA NetQ: สำหรับตรวจสอบเครือข่าย Ethernet/RoCENVIDIA NMX: สำหรับตรวจสอบ NVLink ระดับแร็คNVIDIA Base Command Manager (BCM): สำหรับการจัดการคลัสเตอร์และงานNVIDIA Run:ai / NIM: สำหรับการจัดการเวิร์กโหลดและบริการ Inferenceข้อควรพิจารณาในการเลือกเครื่องมือ:DCGM vs NVSM สำหรับ GPU: แนะนำ DCGM สำหรับการส่งข้อมูลการใช้งาน, พลังงาน, อุณหภูมิ, NVLink, และ XID/ECC ไปยัง Prometheus ส่วน NVSM ยังคงจำเป็นสำหรับสุขภาพระบบโดยรวมของโหนด DGX (ไดรฟ์, พลังงาน, สุขภาพทั่วไป)UFM vs NetQ: เลือกตามประเภทเครือข่าย InfiniBand ใช้ UFM, Spectrum Ethernet/RoCE ใช้ NetQ หากมีทั้งสองประเภท ให้ใช้งานทั้งคู่NMX: จำเป็นสำหรับ Rack-scale NVLink หากไม่ได้ใช้ในโทโพโลยีแบบเดิม ก็สามารถละเว้นได้BCM: ใช้เป็นตัวรวบรวมข้อมูลระดับคลัสเตอร์และงาน ไม่ใช่แหล่งข้อมูลระดับต่ำ เครื่องมือเฉพาะทางยังคงรับผิดชอบ Telemetry เชิงลึกRun:ai และ NIM: นำมาใช้เมื่อการจัดตารางงานที่เป็นธรรม (Fairness) หรือ SLOs ของ Inference เป็นข้อกำหนดการปฏิบัติงานที่สำคัญ แต่ไม่สามารถทดแทน DCGM หรือการตรวจสอบเครือข่ายได้กฎสำคัญ: ครอบคลุมทุกความต้องการด้วยเครื่องมือที่น้อยที่สุด เครื่องมือเพิ่มเติมที่ไม่มีเส้นทางการตรวจสอบที่ชัดเจนจะเพิ่มสัญญาณรบกวน ทำให้เกิด "Alert Fatigue" หรือความเหนื่อยล้าจากการแจ้งเตือนการประยุกต์ใช้ Observability Framework กับ InfiniBand Clusterสำหรับ DGX cluster ที่ใช้ InfiniBand, BCM, และ Slurm โดยเน้นที่งานเทรนเป็นหลัก ข้อกำหนดคือมีแดชบอร์ด Triage เพียงแดชบอร์ดเดียว และการแจ้งเตือนที่ตรวจจับความเสื่อมของเครือข่ายและ GPU ได้ก่อนที่งานจะสูญเสียเวลาหลายชั่วโมงขั้นตอนการตัดสินใจ:โดเมนที่เกี่ยวข้อง: สุขภาพแพลตฟอร์ม, GPU, เครือข่าย InfiniBand, คลัสเตอร์/งานเครื่องมือที่เลือก:Redfish/IPMI สำหรับสุขภาพ BMC (พัดลม, PSU, แชสซี)DCGM สำหรับประสิทธิภาพ GPU (การใช้งาน, พลังงาน, อุณหภูมิ, XID/ECC, NVLink)NVSM สำหรับการรวบรวมสุขภาพระบบบนโหนด DGXUFM สำหรับสุขภาพพอร์ต InfiniBand, BER, ความแออัด, และการกำหนดเส้นทางBCM สำหรับการรวบรวมข้อมูลคลัสเตอร์, งาน, การจอง, และการแจ้งเตือนฮาร์ดแวร์แบบรวมเหตุผล: การมีเพียง DCGM จะพลาดการถดถอยของ BER ใน InfiniBand ซึ่งส่งผลกระทบต่อเวิร์กโหลดที่ต้องทำงานพร้อมกัน การมีเพียง UFM จะพลาดปัญหา GPU XID Storm หรือ Node Power Fault ส่วน BCM อย่างเดียวก็ไม่สามารถให้ข้อมูลระดับต่ำได้ การรวมเครื่องมือเหล่านี้เข้าด้วยกันจะครอบคลุมโดเมนที่ทำให้เสียเวลา GPUเครื่องมือที่ยกเว้น (สำหรับตอนนี้): NetQ, NMX, Run:ai, NIM เนื่องจากยังไม่มีการใช้งาน Ethernet, Rack-scale NVLink, หรือบริการ Inferenceผลลัพธ์คือ Stack เริ่มต้นที่ประกอบด้วย IPMI, DCGM, NVSM, UFM, และ BCM ซึ่งรวมศูนย์อยู่ใน Prometheus/Grafanaการสร้างชุดการแจ้งเตือนที่ดำเนินการได้ (Actionable Alert Set)เครื่องมือส่วนใหญ่มีเมตริกหลายร้อยรายการ ควรเลือกชุดการแจ้งเตือนสั้นๆ ที่เชื่อมโยงกับ Service Level Indicators (SLIs) และ Service Level Objectives (SLOs) ไม่ใช่การรวบรวมเคาน์เตอร์ฮาร์ดแวร์ทั้งหมด การแจ้งเตือนแต่ละรายการควรเชื่อมโยงกับการดำเนินการแก้ไขที่ชัดเจนตัวอย่างการแจ้งเตือนเบื้องต้น:แพลตฟอร์ม: ความเร็วพัดลม, สถานะ PSU, อุณหภูมิสำคัญ (ผ่าน Redfish/IPMI)GPU: DCGMFIDEVGPUUTIL, DCGMFIDEVMEMCOPYUTIL, DCGMFIDEVPOWERUSAGE, DCGMFIDEVXID_ERRORS, รวมถึงสุขภาพ GPU/ระบบจาก NVSMInfiniBand: PortXmitDataExtended, SymbolErrorCounterExtended, EffectiveBER, TotalRawBER, ChipTempงาน: สัญญาณจาก BCM/Slurm สำหรับงานที่กำลังทำงาน, การจอง GPU, และเวลารอคอย เพื่อให้การแจ้งเตือนเครือข่ายหรือ GPU สามารถเชื่อมโยงกับผลกระทบของเวิร์กโหลดได้ควรขยายชุดการแจ้งเตือนเฉพาะเมื่อเกิดเหตุการณ์ที่แสดงให้เห็นช่องว่างในการครอบคลุมเท่านั้น ควรแจ้งเตือนที่อาการซึ่งเชื่อมโยงกับการดำเนินการที่กำหนด (เช่น การระบายโหนด, การเปลี่ยนสายเคเบิล, การเปิดเคสเครือข่าย) ไม่ใช่ทุกเคาน์เตอร์ที่สามารถปล่อยออกมาได้การสร้าง Unified AI Infrastructure Triage Dashboardเมื่อเลือกเครื่องมือและเมตริกหลักได้แล้ว ให้สร้างแดชบอร์ด Triage แบบรวมศูนย์:ติดตั้ง Exporter: ติดตั้ง IPMI และ DCGM exporters บนทุก GPU nodeรวบรวมข้อมูลเครือข่าย: รัน UFM Telemetry และ scrape หรือ export เข้าสู่ Prometheusจัดการคลัสเตอร์: ใช้ BCM เป็นแกนหลักในการจัดการและรวบรวมข้อมูลแสดงผล: ชี้ Grafana ไปที่ Prometheus เพื่อสร้างแดชบอร์ดและการแจ้งเตือนสำหรับสัญญาณ GPU, Node, และ Fabricบริบทงาน: เพิ่มแดชบอร์ด Slurm หากบริบทระดับงานยังไม่มีใน BCMใช้วิธีการตรวจสอบสองชั้น: ชั้นที่ 1 ให้มุมมองระดับสูงสำหรับการ Triage (ปัญหาอยู่ที่ GPU, Node, หรือ Fabric?) ชั้นที่ 2 คือการเจาะลึกใน UI ของผู้จำหน่าย (UFM web UI, BCM Base View) เมื่อทราบโดเมนที่เสียหายแล้ว การดำเนินการในวันที่สอง (Day 2 operations) จะเร็วขึ้นเมื่อชั้นที่ 1 สามารถตอบคำถาม Triage ได้จากบอร์ดเดียวเกณฑ์การยอมรับ Observabilityคุณจะพร้อมดำเนินการต่อเมื่อ:ทุก Failure Domain ที่อยู่ในขอบเขต มีเครื่องมือที่รองรับอย่างน้อยหนึ่งรายการจาก Frameworkการแจ้งเตือนเชื่อมโยงกับรายการเมตริกสั้นๆ ที่มีเจ้าของและการดำเนินการที่ชัดเจนสัญญาณ GPU, Node, และ Fabric อยู่บนไทม์ไลน์เดียวกันในมุมมองเดียวเครื่องมือเพิ่มเติม (Ethernet, Rack-scale NVLink, Run:ai, NIM) ถูกเพิ่มเข้ามาเมื่อจำเป็นเท่านั้น ไม่ใช่ตามค่าเริ่มต้นอย่าประเมินความสมบูรณ์ของ Observability จากจำนวนแดชบอร์ด แต่ให้วัดจากความสามารถในการแสดงส่วนประกอบที่ล้มเหลวและขั้นตอนถัดไปก่อนที่ทรัพยากรประมวลผลจำนวนมากจะสูญเสียไปการขยาย Stack NVIDIA AI Infrastructure Observabilityหลังจากที่การติดตั้งเริ่มต้นตรงตามเกณฑ์ที่กำหนดแล้ว ให้ขยายการครอบคลุมตามลำดับนี้:เปิดใช้งาน GPU Telemetry: ใช้ DCGM User Guide และ GPU Telemetryตรวจสอบสุขภาพระบบ DGX: ตรวจสอบเส้นทางสุขภาพระบบ DGX ใน NVSM User Guideกำหนดค่าการมองเห็นเครือข่าย: ใช้ UFM Telemetry หรือ NetQ ขึ้นอยู่กับประเภทเครือข่ายการรวบรวมระดับคลัสเตอร์: เริ่มต้นด้วย Base Command Manager และ NVIDIA Mission Control (หากมี)บริการ Inference: เพิ่ม Observability สำหรับ NVIDIA NIM Operatorใช้ Decision Framework เพื่อให้เหตุผลในการเพิ่มแต่ละรายการ จัดทำคู่มือ Metric Dictionary และ Protocol Matrix ใน Runbooks หรือเอกสารผลิตภัณฑ์ และรักษาชุดการแจ้งเตือนการผลิตให้สั้นพอสำหรับการใช้งานของทีม On-callกรอบการตัดสินใจที่ดี จะช่วยให้คุณเลือกสัญญาณที่เหมาะสมเพียงไม่กี่อย่างและแดชบอร์ด Triage เพียงแดชบอร์ดเดียว แทนที่จะมีแดชบอร์ดมากมายที่ไม่มีใครอ่าน#AI #NVIDIA #Observability #AIInfrastructurehttps://developer.nvidia.com/blog/how-to-choose-full-stack-observability-for-nvidia-ai-factories/