ในขณะที่องค์กรต่างๆ ยังคงลงทุนหลายพันล้านในโครงสร้างพื้นฐาน GPU สำหรับงาน AI ช่องว่างสำคัญได้เกิดขึ้นในความสามารถด้านการตรวจสอบและการสังเกตการณ์ Neurox ซึ่งเป็นแพลตฟอร์มที่โฮสต์เองแบบใหม่ มีเป้าหมายที่จะแก้ปัญหานี้โดยให้การตรวจสอบ GPU แบบครอบคลุมที่ออกแบบมาโดยเฉพาะสำหรับสภาพแวดล้อม Kubernetes
 |
|---|
| ภาพหน้าจอนี้แสดง GitHub repository สำหรับ Neurox Control Helm Chart ซึ่งรองรับการตรวจสอบ GPU ในสภาพแวดล้อม Kubernetes |
ปัญหาการสังเกตการณ์ GPU
การเติบโตอย่างรวดเร็วในโครงสร้างพื้นฐาน AI ได้เผยให้เห็นข้อจำกัดที่สำคัญในโซลูชันการตรวจสอบที่มีอยู่ ตามการสนทนาในชุมชนเทคโนโลยี เครื่องมือปัจจุบันไม่สามารถตอบคำถามพื้นฐานเกี่ยวกับการใช้งาน GPU ความเป็นเจ้าของ และค่าใช้จ่าย ตัวชี้วัดแบบดั้งเดิมเช่น DCGM_FI_DEV_GPU_UTIL สามารถแสดงว่ากำลังเกิดอะไรขึ้นกับ GPU แต่ไม่ใช่เหตุผล - ทำให้ทีมไม่สามารถวินิจฉัยปัญหาเช่น ทรัพยากรที่ใช้งานไม่เต็มประสิทธิภาพ แอปพลิเคชันที่กำหนดค่าไม่ถูกต้อง หรืองานที่เงียบๆ กลับไปใช้การประมวลผล CPU
การสังเกตการณ์ GPU มีปัญหา... แม้ว่าบริษัทจะทุ่มเงินหลายพันล้านไปกับ GPU แต่ไม่มีวิธีง่ายๆ ในการตอบคำถามพื้นฐาน: เกิดอะไรขึ้นกับ GPU ของฉัน? ใครกำลังใช้งานอยู่? โครงการนี้มีค่าใช้จ่ายเท่าไร?
ส่วนใหญ่องค์กรกำลังรวบรวมโซลูชันโดยใช้ Prometheus, Grafana และสคริปต์ kubectl สร้างมุมมองที่แยกส่วนของโครงสร้างพื้นฐาน GPU ของพวกเขา วิธีนี้ไม่เพียงพอเมื่อทีมต้องการเข้าใจความสัมพันธ์ระหว่างเมตริกซ์ สถานะ Kubernetes และข้อมูลทางการเงินในสภาพแวดล้อมมัลติคลาวด์
แนวทางของ Neurox ในการตรวจสอบ GPU
Neurox รวมแหล่งข้อมูลสำคัญสามแหล่งเพื่อให้การสังเกตการณ์ที่ครอบคลุม: สถิติรันไทม์ GPU จาก NVIDIA SMI, ข้อมูล pod ที่กำลังทำงานจากสถานะ Kubernetes และข้อมูลโหนดพร้อมเหตุการณ์จากสถานะ Kubernetes การบูรณาการนี้ช่วยให้ทีมสามารถติดตามปัญหาเช่น สถานะ pod ที่ล้มเหลว การจัดกำหนดการที่ไม่ถูกต้อง และแอปพลิเคชันที่ไม่ได้ใช้ทรัพยากร GPU อย่างเหมาะสม
แพลตฟอร์มนี้นำเสนอแดชบอร์ดที่สร้างขึ้นเฉพาะสำหรับบทบาทต่างๆ ภายในองค์กร นักวิจัยสามารถตรวจสอบงานตั้งแต่การสร้างจนถึงการเสร็จสิ้นบนหน้าจอ Workloads ในขณะที่ทีมการเงินสามารถเข้าถึงข้อมูลค่าใช้จ่ายที่จัดกลุ่มตามทีมหรือโครงการบนหน้าจอ Reports แนวทางตามบทบาทนี้ตอบสนองความต้องการที่หลากหลายของผู้ดูแลระบบ นักพัฒนา นักวิจัย และผู้ตรวจสอบการเงินที่ทำงานกับโครงสร้างพื้นฐาน GPU
ความต้องการของแพลตฟอร์ม Neurox:
- Kubernetes และ CLI 1.29+
- Helm CLI 3.8+
- CPU 12 คอร์
- RAM 24 GB
- พื้นที่จัดเก็บข้อมูลแบบถาวร 120 GB
- มีโหนด GPU อย่างน้อย 1 โหนด
- Ingress ที่สามารถเข้าถึงได้จากอินเทอร์เน็ต
คุณสมบัติหลัก:
- การตรวจสอบการใช้งาน GPU แบบเรียลไทม์และการแจ้งเตือนสำหรับ GPU ที่ไม่ได้ใช้งาน
- การแสดงรายละเอียดค่าใช้จ่ายแยกตามแอปพลิเคชัน/ทีม/โปรเจกต์
- มุมมองแบบรวมศูนย์ครอบคลุมทั้ง AWS, GCP, Azure และโครงสร้างพื้นฐานแบบออนพรีมิส
- รองรับ Kubernetes: เชื่อมโยงเมตริกของโหนดกับพอด, งาน และเจ้าของที่กำลังทำงานอยู่
- การตรวจสอบสุขภาพของ GPU
ความยืดหยุ่นในการปรับใช้และความเป็นส่วนตัวของข้อมูล
แง่มุมสำคัญของสถาปัตยกรรม Neurox คือการแยกระหว่างคอนโทรลเพลนและองค์ประกอบเวิร์กโหลด แพลตฟอร์มนี้ถูกออกแบบให้เป็นซอฟต์แวร์ที่โฮสต์เองเพื่อเก็บข้อมูลที่ละเอียดอ่อนไว้ภายในโครงสร้างพื้นฐานขององค์กร สำหรับทีมที่มีพื้นที่จัดเก็บจำกัดบนคลัสเตอร์ GPU, Neurox เสนอโมเดลการปรับใช้แบบแยกส่วน - คอนโทรลเพลนสามารถติดตั้งบนคลัสเตอร์ Kubernetes ใดก็ได้ที่มีพื้นที่จัดเก็บถาวร (เช่น EKS, AKS หรือ GKE) ในขณะที่เฉพาะเอเจนต์เวิร์กโหลดที่มีน้ำหนักเบาเท่านั้นที่จำเป็นต้องทำงานบนคลัสเตอร์ GPU
ความยืดหยุ่นนี้แก้ไขความกังวลเกี่ยวกับข้อกำหนดพื้นที่จัดเก็บถาวร 120GB ที่กล่าวถึงในเอกสาร ทำให้โซลูชันนี้เป็นไปได้สำหรับคลัสเตอร์ GPU แบบ bare metal ที่มีพื้นที่จัดเก็บในเครื่องจำกัด สถาปัตยกรรมนี้ยังเปิดโอกาสให้มีตัวเลือกคอนโทรลเพลนบนคลาวด์ในอนาคตในขณะที่ยังคงรักษาความปลอดภัยของข้อมูลเวิร์กโหลด
Neurox เสนอระดับฟรีสำหรับการตรวจสอบ GPU สูงสุด 64 หน่วย ซึ่งครอบคลุมกรณีการใช้งานส่วนบุคคล วิชาการ และการใช้งานเชิงพาณิชย์เบาๆ หลายกรณี แม้ว่าปัจจุบันจะไม่เป็นโอเพนซอร์ส บริษัทได้แสดงให้เห็นว่ากำลังพิจารณาเส้นทางนี้สำหรับอนาคต โดยตระหนักว่าความกังวลเรื่องความเป็นส่วนตัวและค่าใช้จ่ายเป็นแรงผลักดันให้เกิดความสนใจในทางเลือกโอเพนซอร์ส
เมื่อโครงสร้างพื้นฐาน AI ยังคงเติบโตในความซับซ้อนและขนาดในสภาพแวดล้อมมัลติคลาวด์ เครื่องมือการสังเกตการณ์ที่สร้างขึ้นเฉพาะเช่น Neurox อาจมีความสำคัญมากขึ้นสำหรับองค์กรที่ต้องการเพิ่มประสิทธิภาพการลงทุน GPU ที่สำคัญของพวกเขา
อ้างอิง: Neurox Control Helm Chart