NCCLbpf: ใช้ eBPF เพื่อเพิ่มความปลอดภัยและประสิทธิภาพในการสื่อสารคลัสเตอร์ GPU แก้ปัญหาความน่าเชื่อถือในการฝึกอบรม AI

คำสำคัญ: NCCL, eBPF, การสื่อสารคลัสเตอร์ GPU, ส่วนขยายความปลอดภัย, การปรับปรุงประสิทธิภาพ

ในคลัสเตอร์ฝึกอบรม AI การล่มของปลั๊กอิน NCCL เป็นสาเหตุของความล้มเหลวมากกว่า 30% และการอัปเดตนโยบายแต่ละครั้งมักหมายถึงการรีสตาร์ทงานฝึกอบรมทั้งหมด NCCLbpf แก้ปัญหานี้โดยนำกลไกการตรวจสอบของ eBPF เข้าสู่ไลบรารีการสื่อสาร GPU ด้วยค่าใช้จ่ายที่ต่ำมากเพียง 80-130 นาโนวินาที ทำให้สามารถดำเนินการปลั๊กอินอย่างปลอดภัยและอัปเดตแบบร้อน (hot update) แบบอะตอมมิกได้ โดยเพิ่มปริมาณงาน AllReduce สูงถึง 27% ในสภาพแวดล้อม 8-GPU NVLink

ในปี 2024 Llama 3 ของ Meta ถูกฝึกอบรมล่วงหน้า (pre-trained) บน GPU 16,384 ตัว เป็นเวลา 54 วัน และประสบกับงานขัดข้อง 466 ครั้ง ซึ่งหมายความว่ามีความล้มเหลวเกิดขึ้นโดยเฉลี่ยทุก 2.8 ชั่วโมง การวิเคราะห์แสดงให้เห็นว่า ประมาณ 30% ของงานฝึกอบรมที่ล้มเหลวสามารถสืบเนื่องมาจากข้อผิดพลาดในการเขียนโปรแกรมและการกำหนดค่า ภายใต้ความล้มเหลวเหล่านี้ มีองค์ประกอบสำคัญแต่ถูกละเลยบ่อยครั้งที่เล่นบทบาทสำคัญ นั่นคือ NCCL (NVIDIA Collective Communications Library)

NCCL เป็นมาตรฐานโดยพฤตินัยสำหรับการสื่อสารคลัสเตอร์ GPU เป็นโครงสร้างพื้นฐานให้กับเฟรมเวิร์กการฝึกอบรมแบบกระจายหลักๆ เช่น Megatron-LM, DeepSpeed, PyTorch FSDP เพื่อจัดการกับความซับซ้อนของสถาปัตยกรรมฮาร์ดแวร์และโทโพโลยีเครือข่ายที่แตกต่างกัน NCCL ได้ออกแบบกลไกปลั๊กอินที่ยืดหยุ่น ช่วยให้ผู้ให้บริการคลาวด์และผู้จำหน่ายฮาร์ดแวร์สามารถปรับแต่งพฤติกรรมขณะทำงานได้ผ่านปลั๊กอินประเภท tuner, profiler, net

อย่างไรก็ตาม ความยืดหยุ่นนี้ได้นำมาซึ่งความเสี่ยงด้านความน่าเชื่อถือที่ร้ายแรง

ปลั๊กอิน NCCL ทำงานในรูปแบบโค้ดเนทีฟ และใช้พื้นที่แอดเดรสเดียวกันกับ NCCL โดยไม่มีแซนด์บ็อกซ์ ไม่มีการตรวจสอบ และไม่มีการแยกความปลอดภัยใดๆ การ dereference พอยน์เตอร์ว่างเพียงครั้งเดียวก็สามารถทำให้งานฝึกอบรมทั้งหมดล่มได้ การวนลูปไม่สิ้นสุดก็สามารถทำให้การสื่อสารแบบ collective ของ GPU หลายพันตัวรอคอยตลอดไป

• ปลั๊กอิน inspector ของ NVIDIA เองก็เคยทำให้สภาพแวดล้อมการผลิตล่มเนื่องจากปัญหา use-after-free และ deadlock
• ปลั๊กอิน profiler ก่อให้เกิด segmentation fault บนโหนดหลาย GPU บังคับให้งานฝึกอบรมสิ้นสุดก่อนกำหนด

ที่น่าหงุดหงิดยิ่งกว่านั้นคือ การอัปเดตนโยบายปลั๊กอินจำเป็นต้องรีสตาร์ทงานฝึกอบรมทั้งหมด ในคลัสเตอร์ขนาดใหญ่ นี่หมายถึงเวลาหยุดทำงานหลายชั่วโมงและการสูญเสียพลังการคำนวณที่มีราคาแพง

ปัญหาเหล่านี้ก่อให้เกิดภาวะกลืนไม่เข้าคายไม่ออกแบบคลาสสิก: เราต้องการความยืดหยุ่นเพื่อปรับปรุงประสิทธิภาพ แต่ความเสี่ยงด้านความปลอดภัยที่มากับความยืดหยุ่นกลับทำให้ระบบเปราะบาง มีวิธีใดบ้างที่สามารถรักษาความสามารถในการปรับแต่งของปลั๊กอิน NCCL ได้ ในขณะเดียวกันก็มีความปลอดภัยและน่าเชื่อถือเหมือนส่วนขยายเคอร์เนล?

นี่คือปัญหาที่ทีมวิจัยจาก University of California, Santa Cruz แก้ไขใน NCCLbpf พวกเขานำ eBPF — เฟรมเวิร์กส่วนขยายความปลอดภัยที่ได้รับการพิสูจน์แล้วใน Linux kernel — เข้าสู่ระบบปลั๊กอินของ NCCL สร้างวิธีการดำเนินการนโยบายการสื่อสาร GPU แบบใหม่ที่สามารถตรวจสอบได้และสามารถประกอบเข้าด้วยกันได้

สารบัญ

• 1. พื้นหลัง: ภาวะกลืนไม่เข้าคายไม่ออกด้านความปลอดภัยของระบบปลั๊กอิน NCCL
  • 1.1 ระบบนิเวศของปลั๊กอิน NCCL
  • 1.2 กรณีศึกษาความล้มเหลวจริง
  • 1.3 ทำไมโซลูชันที่มีอยู่จึงไม่เพียงพอ?
  • 1.4 แรงบันดาลใจจาก eBPF
• 2. ปรัชญาการออกแบบของ NCCLbpf
  • 2.1 การแลกเปลี่ยนการออกแบบหลักสี่ประการ
  • 2.2 แบบจำลองภัยคุกคาม
• 3. การวิเคราะห์โครงสร้าง: eBPF ถูกฝังลงใน NCCL อย่างไร
  • 3.1 โครงสร้างโดยรวม
  • 3.2 โมเดลการเขียนโปรแกรม
• 4. รายละเอียดการนำไปใช้: ปัญญาวิศวกรรมในโค้ด 2500 บรรทัด
  • 4.1 การรวม bpftime
  • 4.2 การลงทะเบียนปลั๊กอิน
  • 4.3 ความท้าทายในการรวม NCCL
  • 4.4 กลไกการอัปเดตแบบร้อน
  • 4.5 ฐานเนทีฟ
• 5. การประเมิน: ประสิทธิภาพ ความปลอดภัย และประโยชน์ใช้สอย
  • 5.1 สภาพแวดล้อมการทดสอบ
  • 5.2 ค่าใช้จ่ายด้านประสิทธิภาพ: ชัยชนะระดับนาโนวินาที
  • 5.3 การตรวจสอบความปลอดภัย: จับข้อบกพร่องประเภททำให้ล่มทั้งหมด
  • 5.4 การอัปเดตแบบร้อน: การพัฒนานโยบายที่ราบรื่น
  • 5.5 กรณีศึกษา 1: นโยบายปรับตัวตาม NVLink
  • 5.6 กรณีศึกษา 2: ความสามารถในการประกอบจาก Profiler ไปยัง Tuner
  • 5.7 กรณีศึกษา 3: ความสามารถในการขยายของปลั๊กอิน Net
• 6. งานที่เกี่ยวข้อง: ตำแหน่งของ NCCLbpf ในระบบนิเวศ
  • 6.1 ระบบการสื่อสารแบบ collective
  • 6.2 กลไกการขยาย GPU
  • 6.3 กลไกการขยายทางเลือก
• 7. การอภิปรายและทิศทางในอนาคต
  • 7.1 ข้อจำกัดปัจจุบันและการขยาย
  • 7.2 แรงบันดาลใจที่เหนือกว่า NCCL
  • 7.3 แรงบันดาลใจสำหรับโครงสร้างพื้นฐาน AI
• สรุป

1. พื้นหลัง: ภาวะกลืนไม่เข้าคายไม่ออกด้านความปลอดภัยของระบบปลั๊กอิน NCCL

1.1 ระบบนิเวศของปลั๊กอิน NCCL

งานหลักของ NCCL คือการทำให้เกิดการสื่อสารแบบ collective ระหว่าง GPU: AllReduce, AllGather, Broadcast เป็นต้น สำหรับการเรียกใช้การสื่อสารแบบ collective แต่ละครั้ง NCCL ต้องตัดสินใจที่สำคัญสามประการ:
* การเลือกอัลกอริทึม: ใช้อัลกอริทึม Ring หรือ Tree?
* โปรโตคอลการส่งข้อมูล: เลือก LL (ความหน่วงต่ำ), LL128 หรือ Simple?
* จำนวนช่องทาง: ใช้ช่องทางขนานกี่ช่องเพื่อส่งข้อมูล?

การตัดสินใจเหล่านี้ส่งผลกระทบโดยตรงต่อประสิทธิภาพการสื่อสาร NCCL เปิดเผยจุดควบคุมเหล่านี้ผ่านปลั๊กอิน tuner ฟังก์ชัน getCollInfo ของปลั๊กอิน tuner รับประเภทการดำเนินการแบบ collective ขนาดข้อความ ข้อมูลโทโพโลยี และมีอิทธิพลต่อการตัดสินใจของ NCCL โดยการปรับเปลี่ยนตารางต้นทุน (cost table)

นอกจากนี้ NCCL ยังมีปลั๊กอิน profiler (รับการเรียกกลับเหตุการณ์ไทม์สแตมป์) ปลั๊กอิน net (ควบคุมการส่งผ่านเครือข่าย) และปลั๊กอิน env (ตั้งค่าพารามิเตอร์ขณะทำงาน) ปลั๊กอินทั้งสี่นี้ถูกโหลดแบบไดนามิกเป็นไลบรารีแชร์ผ่าน dlopen

ปัญหาคือปลั๊กอินเหล่านี้เป็นจุดขยายที่เป็นอิสระและไม่น่าเชื่อถือ พวกมันไม่มีกลไกการสื่อสารระหว่างกัน และที่สำคัญกว่านั้นคือไม่มีกระบวนการตรวจสอบความปลอดภัยใดๆ

1.2 กรณีศึกษาความล้มเหลวจริง

ผู้เขียนอ้างอิงรายงานความล้มเหลวของ NCCL จริงสองกรณี:

1. NCCL issue #2000: ปลั๊กอิน inspector มีบั๊ก use-after-free และ deadlock ทำให้งานฝึกอบรมล่ม

ปลั๊กอิน inspector ของ NCCL 2.28.9 มีปัญหาสำคัญสองประการ: หนึ่งคือการทำลายล็อคอ่าน-เขียนโดยไม่ปลดล็อคก่อน ก่อให้เกิด deadlock ของเธรดและทำให้กระบวนการ GPU หยุดค้าง; สองคือการนำ collInfo ที่ถูกปล่อยแล้วกลับมาใช้ใหม่ (UAF) ทำให้หน่วยความจำ heap เสียหายและโปรแกรมล่ม การฝึกอบรมลำดับยาวทำให้เกิดซ้ำได้ง่ายกว่า และสามารถบรรเทาได้ชั่วคราวด้วย object pool เท่านั้น https://github.com/NVIDIA/nccl/issues/2000

2. NCCL issue #1992: ปลั๊กอิน Inspector ก่อให้เกิด segmentation fault บนโหนดหลาย GPU

ในสภาพแวดล้อม NCCL 2.28.9 และ CUDA 12.8 ผู้ใช้เปิดใช้งานฟังก์ชัน inspector ของ NCCL Profiler Plugin บนแพลตฟอร์ม H200 แล้วโปรแกรมฝึกอบรมล่มเนื่องจาก segmentation fault; การปิดใช้งานปลั๊กอินนี้ทำให้ทำงานปกติได้ ผู้ใช้วิเคราะห์ว่าอาจเป็นเพราะ RecordEvents ถูกเรียกซ้ำหลังจาก StopEvent แล้ว ซึ่งนำไปสู่ข้อบกพร่องนี้ การอภิปรายที่เกี่ยวข้องยังชี้ให้เห็นว่าปัญหานี้เชื่อมโยงกับปัญหา deadlock และการล่มที่เกิดจาก “use-after-free” ดูรายละเอียดเพิ่มเติมได้ที่ GitHub issue: https://github.com/NVIDIA/nccl/issues/1992

ปัญหาประเภทนี้ไม่ใช่ความเสี่ยงทางทฤษฎี ในสภาพแวดล้อมการผลิตขนาดใหญ่ ต้นทุนของความล้มเหลวดังกล่าวสูงมาก ตัวอย่างเช่น บันทึกการฝึกอบรมของ Llama 3 แสดงให้เห็นว่าใน 466 ครั้งของการขัดข้องในการฝึกอบรม มีส่วนหนึ่งที่เกี่ยวข้องกับไลบรารีการสื่อสาร

การศึกษาที่กว้างขึ้นแสดงให้เห็นว่าในคลัสเตอร์ GPU การผลิต ประมาณ 30% ของงานฝึกอบรมที่ล้มเหลวสามารถสืบเนื่องมาจากข้อผิดพลาดในการเขียนโปรแกรมและการกำหนดค่า ข้อบกพร่องด้านความปลอดภัยของกลไกปลั๊กอินเนทีฟเป็นหนึ่งในปัจจัยสำคัญที่นำไปสู่ปัญหาเหล่านี้

1.3 ข้อจำกัดของโซลูชันที่มีอยู่

เมื่อเผชิญกับปัญหาข้างต้น วิธีการแก้ปัญหาทั่วไปและข้อจำกัดมีดังนี้:

• การจัดตารางแบบคงที่: โซลูชันเช่น MSCCL และ TACCL ปรับปรุงประสิทธิภาพโดยสร้างตารางการจัดตารางการสื่อสารแบบออฟไลน์ แต่ไม่สามารถปรับตัวเข้ากับการเปลี่ยนแปลงแบบไดนามิกของสภาพแวดล้อมขณะทำงานได้
• WebAssembly Sandbox: แม้จะสามารถให้การแยกหน่วยความจำได้ แต่ขาดการรับประกันการตรวจสอบแบบคงที่เช่น eBPF (เช่น การพิสูจน์การสิ้นสุดของโปรแกรม) และการตรวจสอบขอบเขตขณะทำงานจะนำมาซึ่งค่าใช้จ่ายด้านประสิทธิภาพที่สูงกว่า
• บริการนอกกระบวนการ: การย้ายตรรกะนโยบายไปยังกระบวนการอิสระสามารถเพิ่มการแยกได้ แต่ความหน่วงของการสื่อสารระหว่างกระบวนการมักอยู่ในระดับไมโครวินาที ซึ่งสูงกว่าค่าใช้จ่าย 80-130 นาโนวินาทีที่ NCCLbpf ทำได้ถึงหนึ่งลำดับความสำคัญ
• การแยกฮาร์ดแวร์: เช่น Memory Protection Keys สามารถแยกหน่วยความจำได้ แต่ไม่สามารถตรวจสอบความถูกต้องเชิงตรรกะของโปรแกรมเองได้

ดังนั้น สิ่งที่เราต้องการจริงๆ คือกลไกการขยายที่ ทั้งรับประกันความปลอดภัย (หลีกเลี่ยงการล่มและการเสียหายของหน่วยความจำ) และรักษาประสิทธิภาพสูง (ค่าใช้จ่ายระดับนาโนวินาที)

1.4 แรงบันดาลใจจาก eBPF

eBPF ในตอนแรกเป็นเฟรมเวิร์กการดำเนินการใน Linux kernel สำหรับการกรองแพ็กเก็ตข้อมูลและการติดตามระบบ แกนกลางของมันคือการรับประกันความปลอดภัยของหน่วยความจำและการดำเนินการที่มีขอบเขตผ่านการตรวจสอบแบบคงที่ก่อนการโหลด และทำงานด้วยความเร็วใกล้เคียงเนทีฟหลังการคอมไพล์แบบทันที (JIT) ปัจจุบัน eBPF ถูกนำไปใช้อย่างประสบความสำเร็จในหลายสถานการณ์ เช่น การจัดเก็บข้อมูล เครือข่าย การจัดการหน่วยความจำ และแม้แต่การจัดการทรัพยากรไดรเวอร์ GPU

คุณสมบัติสำคัญสามประการของ eBPF ที่ทำให้มันเหมาะสมอย่างยิ่งสำหรับการนำไปใช้เป็นเฟรมเวิร์กการดำเนินการนโยบายของ NCCL คือ:

1. การตรวจสอบขณะโหลด: ตรวจสอบความปลอดภัยของหน่วยความจำและการสิ้นสุดก่อนที่โปรแกรมจะทำงาน เพื่อตรวจจับข้อผิดพลาดที่อาจทำให้ล่มได้ล่วงหน้า
2. การแมปแบบมีประเภท: ให้กลไกการแบ่งปันสถานะพร้อมกันอย่างปลอดภัย ทำให้โปรไฟเลอร์และตัวปรับแต่งสามารถสื่อสารผ่านการแมปที่แชร์กันได้
3. การแทนที่โปรแกรมแบบอะตอมมิก: รองรับการอัปเดตแบบร้อนของโปรแกรมที่ได้รับการตรวจสอบแล้ว โดยไม่ต้องรีสตาร์ทบริการ

เป็นที่น่าสังเกตว่า กลไกปลั๊กอินเครือข่ายของ NCCL มีความคล้ายคลึงอย่างมากกับสถานการณ์ดั้งเดิมของ eBPF ที่จัดการแพ็กเก็ตข้อมูลเครือข่าย ในขณะที่อินเทอร์เฟซของตัวปรับแต่งและโปรไฟเลอร์สอดคล้องกับจุดติดตาม (tracepoint) ในเคอร์เนล การเปรียบเทียบเชิงโครงสร้างนี้เป็นแรงบันดาลใจให้ทีมวิจัยนำ eBPF เข้าสู่ระบบนิเวศของ NCCL

2. ปรัชญาการออกแบบของ NCCLbpf

2.1 การแลกเปลี่ยนการออกแบบหลักสี่ประการ

การออกแบบของ NCCLbpf หมุนรอบความตึงเครียดหลักสี่กลุ่มต่อไปนี้

⚠️ หมายเหตุ: เนื้อหาได้รับการแปลโดย AI และตรวจสอบโดยมนุษย์ หากมีข้อผิดพลาดโปรดแจ้ง

☕ สนับสนุนค่ากาแฟทีมงาน

หากคุณชอบบทความนี้ สามารถสนับสนุนเราได้ผ่าน PromptPay

SCAN TO PAY WITH ANY BANK