คำสำคัญ: การทับซ้อนการคำนวณ-การสื่อสาร การจัดตารางแบบบล็อก คอมไพเลอร์แบบกระจาย GPU Triton งานหลาย GPU
บรรลุการทับซ้อนเชิงลึกของการคำนวณและการสื่อสารภายในเคอร์เนลเดียวผ่านการจัดตารางระดับบล็อก
ในปีที่ผ่านมา ขนาดของโมเดลภาษาขนาดใหญ่เติบโตแบบทวีคูณ การฝึกฝนโมเดลเหล่านี้ต้องการ GPU หลายร้อยหรือหลายพันตัว ในระบบหลาย GPU การสื่อสารได้แทนที่การคำนวณเป็นคอขวดหลัก แม้จะใช้เทคโนโลยีการเชื่อมต่อความเร็วสูง เช่น NVLink, NVSwitch การดำเนินการสื่อสารแบบรวมกลุ่ม เช่น AllGather, ReduceScatter ยังคงครอบครองสัดส่วนเวลาที่สำคัญของเวลาแบบ end-to-end
เพื่อซ่อนต้นทุนการสื่อสาร ระบบที่มีอยู่ส่วนใหญ่ใช้กลยุทธ์ การทับซ้อนระดับเคอร์เนล: จัดสรรเคอร์เนลคำนวณและเคอร์เนลสื่อสารไปยัง CUDA สตรีมที่แตกต่างกันเพื่อดำเนินการพร้อมกัน ซึ่งทำให้เกิดการทับซ้อนการคำนวณ-การสื่อสารในระดับหยาบ
ตารางที่ 1 | การเปรียบเทียบโครงการที่เกี่ยวข้องกับการดำเนินการแบบกระจายประเภทต่างๆ ตารางนี้เปรียบเทียบความแตกต่างระหว่างโซลูชันแบบกระจายสามประเภท (การทำให้เป็นอัตโนมัติ การดำเนินการด้วยมือ ภาษาเฉพาะโดเมน) กับ AutoOverlap จากห้ามิติหลัก: ความละเอียด การคำนวณ การสื่อสาร การจัดตาราง ประสิทธิภาพ โซลูชันอัตโนมัติแบบดั้งเดิมรองรับเฉพาะความละเอียดระดับเคอร์เนล ในขณะที่การดำเนินการด้วยมือและ DSL สามารถปรับแต่งในระดับบล็อก/ไทล์ได้ แต่ต้องพึ่งพาการพัฒนาด้วยมือ ในขณะที่ AutoOverlap เป็นผู้บุกเบิกการปรับแต่งระดับบล็อกอัตโนมัติ ทำให้การคำนวณ การสื่อสาร และการจัดตารางเป็นอัตโนมัติทั้งหมด พร้อมทั้งบรรลุประสิทธิภาพสูงสุดของการปรับแต่งด้วยมือ เติมเต็มช่องว่างทางเทคนิคระหว่างการคอมไพล์อัตโนมัติและการปรับแต่งระดับละเอียด
อย่างไรก็ตาม การทับซ้อนระดับหยาบนี้มีข้อบกพร่องพื้นฐานและไม่สามารถใช้ประโยชน์จากทรัพยากรการคำนวณของ GPU สมัยใหม่ได้อย่างเต็มที่
เพื่อตอบสนองความท้าทายนี้ ทีมวิจัยจาก University of California, San Diego และ Meta ได้เสนอ AutoOverlap — กรอบงานคอมไพเลอร์และรันไทม์ที่สามารถบรรลุการทับซ้อนของการคำนวณและการสื่อสารในระดับละเอียดภายในเคอร์เนลฟิวชันเดียว
บทความนี้จะตีความนวัตกรรมของ AutoOverlap เพื่อทำความเข้าใจว่ามันสามารถเร่งความเร็วงานหลาย GPU ได้สูงสุดถึง 4.7 เท่าได้อย่างไร ผ่านการสร้างนามธรรม “บล็อกการสื่อสาร” และการจัดตารางอัจฉริยะ
1. พื้นหลังและการวิจัยที่เกี่ยวข้อง
1.1 สถานะปัจจุบันของคอมไพเลอร์แบบกระจาย
เมื่อขนาดโมเดลเติบโตขึ้น คอมไพเลอร์เทนเซอร์ (เช่น TVM, TensorIR ฯลฯ) เริ่มรวมการรองรับหลาย GPU คอมไพเลอร์เหล่านี้มักใช้วิธีผสมผสานของ “เคอร์เนล GPU เดี่ยว + ไพรมิทีฟการสื่อสารแบบรวมกลุ่มที่กำหนดไว้ล่วงหน้า”
คอมไพเลอร์แบบกระจาย เช่น Alpa, Mercury จะสร้างตารางการสื่อสารที่มีการดำเนินการ เช่น AllGather, ReduceScatter หลังจากค้นหากลยุทธ์การขนาน จากนั้นจัดสรรเคอร์เนลคำนวณและเคอร์เนลสื่อสารไปยังสตรีมที่แตกต่างกัน เพื่อเพิ่มการทับซ้อนระดับเคอร์เนลให้สูงสุด
อย่างไรก็ตาม การออกแบบนี้มีข้อจำกัดพื้นฐาน: การสื่อสารถูกวางแผนเป็นชุดของเคอร์เนลการดำเนินการแบบรวมกลุ่มที่สมบูรณ์ เวลาเริ่มต้นและเสร็จสิ้นของเคอร์เนลเป็นหน่วยพื้นฐานของการจัดตาราง คอมไพเลอร์แบบกระจายที่มีอยู่ทั้งหมดมุ่งเน้นเฉพาะตารางการสื่อสารในระดับเคอร์เนล และ “มองไม่เห็น” โอกาสการทับซ้อนในระดับละเอียดภายในเคอร์เนล — ตัวอย่างเช่น ไม่สามารถบรรลุการทับซ้อนของการสื่อสารและการคำนวณต่อชาร์ด (per-shard) หรือต่อบล็อก (per-tile) ไม่สามารถนำข้อมูลระยะไกลกลับมาใช้ใหม่ภายในเคอร์เนล และไม่สามารถใช้ประโยชน์ไปป์ไลน์ที่รับรู้โทโพโลยีได้
1.2 การออกแบบเคอร์เนลด้วยมือ
งานอีกประเภทหนึ่งพยายามก้าวข้ามการทับซ้อนระดับเคอร์เนล โดยออกแบบไปป์ไลน์ระดับละเอียดด้วยมือ
- Flux ผสาน GEMM และการสื่อสารแบบรวมกลุ่มในระดับบล็อก
- Comet ใช้การสร้างนามธรรมเทนเซอร์ร่วมและบัฟเฟอร์ NVSHMEM สำหรับโมเดล MoE เพื่อทับซ้อนการสื่อสารระดับโทเค็นกับการคำนวณระดับบล็อก
- FlashOverlap กระตุ้นการสื่อสาร NCCL ผ่านสัญญาณพร้อมใช้งานแบบน้ำหนักเบาโดยไม่ต้องแก้ไขเคอร์เนล
- DSL เช่น TritonDistributed ทำให้กระบวนการเขียนเคอร์เนลทับซ้อนง่ายขึ้น
แม้ว่าการดำเนินการด้วยมือเหล่านี้จะมีประสิทธิภาพดี แต่ทั้งหมดพึ่งพา การปรับแต่งด้วยมือโดยผู้เชี่ยวชาญสำหรับโอเปอเรเตอร์และแพลตฟอร์มฮาร์ดแวร์เฉพาะ
1.3 ความหลากหลายของแบ็กเอนด์การสื่อสาร
GPU สมัยใหม่มีกลไกการถ่ายโอนข้อมูลระหว่างอุปกรณ์หลายรูปแบบ แต่ละรูปแบบมีการแลกเปลี่ยนระหว่างประสิทธิภาพและความสามารถในการโปรแกรมที่แตกต่างกัน ดูตารางที่ 2
ตารางที่ 2 | การเปรียบเทียบกลไกการสื่อสาร GPU ประเภทต่างๆ ตารางวิเคราะห์คุณลักษณะหลักและการแลกเปลี่ยนของกลไกการสื่อสาร GPU สามประเภท (Copy Engine, TMA, Load/Store) จากสี่มิติ: ตัวนำฮาร์ดแวร์ วิธีการเขียนโปรแกรม การรองรับการสื่อสารแบบรวมกลุ่ม แบนด์วิธ Copy Engine มีแบนด์วิธสูงสุดแต่พึ่งพาการเริ่มต้นจากโฮสต์และไม่รองรับการสื่อสารแบบรวมกลุ่ม TMA ขับเคลื่อนโดยคำสั่งแบบอะซิงโครนัส มีแบนด์วิธรองลงมา Load/Store มีความยืดหยุ่นสูงสุดแต่มีแบนด์วิธต่ำสุดและใช้ทรัพยากร SM การเปรียบเทียบนี้ให้พื้นฐานฮาร์ดแวร์สำหรับการเลือกแบ็กเอนด์การสื่อสารแบบปรับตัวของ AutoOverlap ทำให้สามารถจับคู่กลไกที่เหมาะสมที่สุดตามสถานการณ์การสื่อสารได้อย่างไดนามิก
- Copy Engine (เครื่องมือคัดลอก) สามารถทำงานแยกจาก SM โดยไม่ใช้ทรัพยากรการคำนวณ แต่สามารถถ่ายโอนข้อมูลต่อเนื่องเท่านั้น และแต่ละการถ่ายโอนต้องการค่าใช้จ่ายเริ่มต้นประมาณ 2-3 ไมโครวินาที
- Tensor Memory Accelerator (TMA) ใช้ฮาร์ดแวร์คัดลอกเทนเซอร์แบบอะซิงโครนัสเฉพาะเจาะจง มีปริมาณงานสูงถึง 300+ GB/s ต้องการเพียง SM จำนวนเล็กน้อยเพื่อเริ่มคำสั่ง แต่ปัจจุบันรองรับเฉพาะการสื่อสารแบบจุดต่อจุดภายในโหนด
- ในขณะที่วิธีการ Load/Store ทั่วไปมีความยืดหยุ่นสูงสุด สามารถทำงานร่วมกับ NVSHARP เพื่อลดขนาดในเครือข่าย แต่ใช้ทรัพยากร SM และมีความซิงโครนัสสูง ต้องการการจัดตารางที่ละเอียด
ความหลากหลายของแบ็กเอนด์การสื่อสารหมายความว่า ไม่มีกลไกใดที่เหมาะสมที่สุดในทุกสถานการณ์ คอมไพเลอร์ต้องเลือกแบ็กเอนด์ที่เหมาะสมที่สุดตามความละเอียดการถ่ายโอนและรูปแบบอย่างไดนามิก
2. แรงจูงใจ: ทำไมต้องมีการทับซ้อนระดับละเอียด?
ทีมวิจัยเปิดเผยข้อบกพร่องพื้นฐานของการทับซ้อนระดับเคอร์เนลและศักยภาพของการทับซ้อนระดับละเอียดผ่านชุดการทดสอบมาตรฐานขนาดเล็ก
รูปที่ 1 | ตัวอย่าง AutoOverlap ด้านซ้ายแสดงข้อจำกัดของการทับซ้อนระดับเคอร์เนลแบบดั้งเดิม เช่น ค่าใช้จ่ายซิงโครไนซ์อุปกรณ์ เวลาว่างของ SM ที่ยาวนาน และความล่าช้าส่วนท้ายของการสื่อสาร ด้านขวาแสดงโซลูชันนวัตกรรมของ AutoOverlap ซึ่งฝังการดำเนินการสื่อสารลงในเคอร์เนลฟิวชันผ่านการปรับแต่งสามประการ: แบ็กเอนด์การสื่อสารแบบปรับตัว การจัดตารางไทล์ภายในเคอร์เนล และขนาดบล็อกแบบปรับตัว ทำลายคอขวดประสิทธิภาพแบบดั้งเดิม ตัวเลขสีแดงแสดงการปรับปรุงโดยตรงของการทับซ้อนระดับละเอียดเมื่อเทียบกับการทับซ้อนระดับเคอร์เนล ตัวเลขสีส้มแสดงการปรับปรุงเพิ่มเติมที่เกิดจากพื้นที่การออกแบบใหม่ที่ AutoOverlap เปิดขึ้น
2.1 ข้อมูลเชิงลึก 1: ข้อจำกัดของการทับซ้อนระดับเคอร์เนล
การทับซ้อนระดับเคอร์เนลนำไปสู่การลดลงของอัตราการใช้ SM และค่าใช้จ่ายเริ่มต้นเคอร์เนล
รูปที่ 2 | ผลการทดลอง (a) อัตราการใช้ SM ภายใต้ขนาด GEMM และขนาดไทล์ที่แตกต่างกัน แสดงให้เห็นว่าเมื่อขนาด GEMM ลดลง การแบ่งพาร์ติชันเคอร์เนลจะทำให้อัตราการใช้ SM ลดลงอย่างมีนัยสำคัญ (b) การเปรียบเทียบประสิทธิภาพระหว่างเคอร์เนล GEMM แบบสตรีมมิ่งและเกณฑ์มาตรฐานการแบ่งพาร์ติชันเคอร์เนล พิสูจน์ว่าเคอร์เนลสตรีมมิ่งรักษาไทล์คำนวณระดับละเอียด หลีกเลี่ยงค่าใช้จ่ายเริ่มต้นเพิ่มเติมในขณะที่รักษาอัตราการใช้สูง (c) (d) แสดงประสิทธิภาพแบนด์วิธของแบ็กเอนด์การสื่อสารต่างๆ ภายใต้ขนาดข้อความที่แตกต่างกัน วัดปริมาณความสัมพันธ์ระหว่างแบ็กเอนด์การสื่อสารและความละเอียดการถ่ายโอน แสดงว่า Copy Engine มีแบนด์วิธดีที่สุดภายใต้ข้อความขนาดใหญ่ ในขณะที่ TMA และ Load/Store มีสถานการณ์ที่เหมาะสมต่างกัน ซึ่งให้การสนับสนุนข้อมูลสำหรับการออกแบบนามธรรมบล็อกในภายหลัง
GEMM ขนาดใหญ่มีคลื่นไทล์มากพอที่จะอิ่มตัว SM แต่เมื่อขนาด GEMM ลดลง จำนวนคลื่นไทล์ลดลง สัดส่วนของเวลาดำเนินการที่ถูกครอบครองโดยคลื่นที่เติมบางส่วนสุดท้ายเพิ่มขึ้น ส่งผลให้อัตราการใช้ SM ลดลง การแบ่ง GEMM ออกเป็นหลายเคอร์เนลย่อย บังคับให้แต่ละการเริ่มต้นทำงานกับรูปร่างที่เล็กลง ตกอยู่ในพื้นที่อัตราการใช้ต่ำนี้ (สอดคล้องกับ ① ในรูปที่ 1)
รูปที่ 2(b) เปรียบเทียบสองรูปแบบ:
* รูปแบบหนึ่งแบ่งออกเป็นหลายเคอร์เนลเล็กเพื่อให้เกิดการทับซ้อน
* อีกรูปแบบหนึ่งใช้ไปป์ไลน์ภายในภายในเคอร์เนลเดียว (GEMM แบบสตรีมมิ่ง)
แม้ว่าทั้งสองรูปแบบจะดำเนินการคำนวณทางคณิตศาสตร์เดียวกัน แต่เกณฑ์มาตรฐานการแบ่งพาร์ติชันเคอร์เนลประสบปัญหาการลดลงของประสิทธิภาพอย่างมากเนื่องจากค่าใช้จ่ายเริ่มต้นเคอร์เนลเพิ่มเติม (①) และอัตราการใช้ SM ไม่เพียงพอ (②)
สรุป: การเริ่มต้นเคอร์เนลเพิ่มเติมอย่างง่ายไม่ใช่เส้นทางที่มีประสิทธิภาพในการบรรลุการทับซ้อน เราต้องการกลไกที่เปิดเผยความพร้อมกันภายในเคอร์เนลในขณะที่รักษาการดำเนินการ GPU ที่มีประสิทธิภาพ
2.2 ข้อมูลเชิงลึก 2: ความละเอียดการถ่ายโอนและผลกระทบของแบ็กเอนด์
ประสิทธิภาพการสื่อสารเปลี่ยนแปลงอย่างรุนแรงตามความละเอียดการถ่ายโอนและการเลือกแบ็กเอนด์
รูปที่ 2(c) และ 2(d) แสดงแบนด์วิธของแบ็กเอนด์การสื่อสารต่างๆ ที่เปลี่ยนแปลงตามขนาดการถ่ายโอนและจำนวน SM แต่ละแบ็กเอนด์มีพฤติกรรมการปรับขนาดที่แตกต่างกัน: บางส่วนถึงแบนด์วิธสูงสุดที่ขนาดการถ่ายโอนปานกลาง บางส่วนต้องการปริมาณการถ่ายโอนที่มากขึ้นหรือ SM มากขึ้นเพื่อแสดงศักยภาพ นอกจากนี้ แบ็กเอนด์ต่างๆ รองรับโหมดที่แตกต่างกัน เช่น การถ่ายโอนแบบจุดต่อจุดกับการลดขนาด
นี่หมายความว่าการกำหนดค่าที่เหมาะสมที่สุดขึ้นอยู่กับขนาดไทล์คำนวณ (กำหนดจังหวะที่ผลลัพธ์พร้อมใช้งาน) ขนาดการถ่ายโอนการสื่อสาร (แลกเปลี่ยนระหว่างความล่าช้าและแบนด์วิธ) และการรวมกันของแบ็กเอนด์การสื่อสาร การทับซ้อนระดับเคอร์เนลไม่สามารถประสานพารามิเตอร์เหล่านี้ได้อย่างยืดหยุ่น เนื่องจากการคำนวณและการสื่อสารเป็นเคอร์เนลอิสระที่แข็งกระด้าง ในขณะที่การทับซ้อนภายในเคอร์เนลสามารถประสานการคำนวณและการสื่อสารในเวลาเดียวกัน ทำให้ความเร็วการสร้างไทล์สอดคล้องกับ “จุดหวาน” ของแบ็กเอนด์ เลือกความละเอียดการถ่ายโอนที่สามารถรักษาอัตราการใช้สูงของ SM และเครื่องมือคัดลอก
2.3 ข้อมูลเชิงลึก 3: ต้องการนามธรรมระดับบล็อกที่เป็นมาตรฐาน
การทับซ้อนภายในเคอร์เนลที่มีประสิทธิภาพต้องการหน่วยการสื่อสารที่มีความละเอียดปรับได้ และสามารถให้อินเทอร์เฟซที่เสถียรบนแบ็กเอนด์การสื่อสารที่แตกต่างกัน
* ขนาดของหน่วยนี้ต้องจับคู่ทั้งความเร็วที่ข้อมูลไทล์ถูกสร้าง และจุดประสิทธิภาพของแบ็กเอนด์ต่างๆ
* ในเวลาเดียวกัน ต้องให้ขอบเขตที่เสถียรระหว่างการจัดตารางการสื่อสารระดับสูงและการนำไปใช้เฉพาะแบ็กเอนด์ ทำให้การจัดตารางการสื่อสารไม่ต้องเขียนใหม่สำหรับแต่ละแบ็กเอนด์
ดังนั้น AutoOverlap จึงแนะนำ นามธรรมบล็อก (chunk) — บล็อกข้อมูลเชิงตรรกะที่ทำหน้าที่เป็นหน่วยพื้นฐานของการสื่อสาร มีความละเอียดปรับได้ และสามารถแมปไปยังแบ็กเอนด์ที่หลากหลายผ่านอินเทอร์เฟซที่เป็นมาตรฐาน
⚠️ หมายเหตุ: เนื้อหาได้รับการแปลโดย AI และตรวจสอบโดยมนุษย์ หากมีข้อผิดพลาดโปรดแจ้ง
☕ สนับสนุนค่ากาแฟทีมงาน
หากคุณชอบบทความนี้ สามารถสนับสนุนเราได้ผ่าน PromptPay
本文来自网络搜集，不代表คลื่นสร้างอนาคต立场，如有侵权，联系删除。转载请注明出处：https://www.itsolotime.com/th/archives/22860