คำสำคัญ: TorchInductor, CuteDSL, GEMM, การอนุมานบน GPU, การปรับแต่งอัตโนมัติ
“บนเส้นทางของการแลกเปลี่ยนระหว่างการลดทอนความซับซ้อนและประสิทธิภาพ ภาษาเฉพาะโดเมน (DSL) ที่ดีแต่ละตัวล้วนมีตำแหน่งเฉพาะของตัวเอง” ก่อนหน้านี้ PyTorch 的 TorchInductor ได้รองรับแบ็กเอนด์การปรับแต่งอัตโนมัติสามตัว ได้แก่ Triton, CUTLASS (C++) และ cuBLAS การเพิ่มเข้ามาของ CuteDSL ไม่เพียงแต่เติมเต็มช่องว่างทางเทคนิคที่เขียนด้วย Python และมีทั้งความซับซ้อนต่ำและประสิทธิภาพสูง แต่ยังตอบสนองความต้องการที่เข้มงวดของ TorchInductor ต่อแบ็กเอนด์ใหม่ที่ “มีต้นทุนการบำรุงรักษาต่ำ ไม่ลดประสิทธิภาพ และดีกว่าในโหลดเป้าหมาย”
- Generating State-of-the-Art GEMMs with TorchInductor’s CuteDSL backend
- https://pytorch.org/blog/gemms-torchinductor-cutedsl-backend/
- ที่เก็บโค้ด: http://github.com/pytorch/pytorch/tree/main/torch/_inductor/codegen/nv_universal_gemm
ในฐานะ DSL ที่ NVIDIA กำลังพัฒนาอย่างแข็งขัน CuteDSL สืบทอดความสามารถในการลดทอนความซับซ้อนระดับล่างของ CUTLASS C++ ในขณะเดียวกันก็มีความเร็วในการคอมไพล์ที่เร็วกว่าและคุณลักษณะการบำรุงรักษาที่เรียบง่ายกว่า โดยเฉพาะอย่างยิ่งในสถานการณ์การคำนวณหลักของแบบจำลองภาษาขนาดใหญ่อย่างการคูณเมทริกซ์ (GEMM) นั้นแสดงผลได้โดดเด่น
ปัญหาการไม่สอดคล้องกันระหว่างการพัฒนาฮาร์ดแวร์และการพัฒนาเคอร์เนลคอมไพเลอร์สำหรับการคูณเมทริกซ์ (GEMM): ความเร็วในการพัฒนาฮาร์ดแวร์เร็วกว่าจังหวะการอัปเดตเคอร์เนลคอมไพเลอร์ GEMM มาก แผนภูมิวงกลมแสดงให้เห็นว่าในโมเดล Llama 3.3 70B การดำเนินการ GEMM คิดเป็น 89% ของค่าใช้จ่ายเวลาทำงาน ซึ่งเป็นจุดคอขวดประสิทธิภาพของโมเดล Transformer ผู้ใช้คาดหวังว่า torch.compile จะสามารถให้ GEMM ประสิทธิภาพสูงโดยไม่ต้องใช้เคอร์เนลที่กำหนดเองและการปรับแต่งด้วยมือ แต่คุณลักษณะใหม่ๆ ของสถาปัตยกรรมใหม่ในแต่ละรุ่น เช่น โหมด Tensor Core รูปแบบความแม่นยำต่ำใน Blackwell ฯลฯ ได้ทำลายความคาดหวังนี้ และเน้นย้ำถึงความต้องการเร่งด่วนในการปรับตัวให้เข้ากับโซลูชัน GEMM ฮาร์ดแวร์ใหม่
โดยการผสานรวม cutlass_api กับโมเดลการวิเคราะห์ nvMatmulHeuristics แบ็กเอนด์ CuteDSL สามารถกรองการกำหนดค่าเคอร์เนลที่เหมาะสมที่สุดได้อย่างแม่นยำ ทำให้ได้การเพิ่มขึ้นของปริมาณงานเคอร์เนลสูงสุด 1.78 เท่า บน GPU B200 และลดความล่าช้าในการอนุมานแบบ end-to-end ได้สูงสุด 6.5%
บทความนี้จะแยกย่อยสถาปัตยกรรมทางเทคนิค กลยุทธ์การผสานรวม ประสิทธิภาพ และวิธีการใช้งานโดยละเอียด เพื่อแสดงให้เห็นว่าแบ็กเอนด์นี้จะเติมพลังใหม่ให้กับการคำนวณบน GPU ได้อย่างไร
ข้อได้เปรียบหลักสามประการของ CuTe DSL ในฐานะโซลูชันที่ขยายได้สำหรับการดำเนินการคูณเมทริกซ์ (GEMM) ระดับ SOTA: ประการแรกคือการเปิดเผยลำดับชั้นของเธรดและหน่วยความจำอย่างสมบูรณ์ ซึ่งสามารถใช้ประโยชน์จากคุณลักษณะของสถาปัตยกรรมฮาร์ดแวร์ได้เต็มที่ และปลดปล่อยขีดจำกัดประสิทธิภาพสูงสุด ประการที่สองคือประสิทธิภาพการคอมไพล์ที่ยอดเยี่ยม ใช้เวลาใกล้เคียงกับ Triton รองรับการผสานการประมวลผลส่วนท้าย การทดสอบมาตรฐานและการปรับแต่งอัตโนมัติข้ามการกำหนดค่าเคอร์เนล ประการที่สามคือการพึ่งพาการลงทุนเชิงรุกของ NVIDIA โดยใช้สิทธิ์การเข้าถึงฮาร์ดแวร์ในระยะแรก สามารถปรับตัวให้เข้ากับคุณลักษณะฮาร์ดแวร์ใหม่ได้อย่างรวดเร็ว และให้การสนับสนุนที่มีประสิทธิภาพสำหรับการคำนวณประสิทธิภาพสูง
สารบัญบทความ
- 1. บทนำ
- 1.1 ภาพรวม
- 2. กลยุทธ์: เหตุใดจึงมุ่งเน้นการคำนวณ GEMM
- 2.1 ความแตกต่างในการปรับแบ็กเอนด์สำหรับการดำเนินการต่างๆ
- 3. พื้นหลัง: TorchInductor สร้างเคอร์เนล GEMM ได้อย่างไร
- 3.1 การวิเคราะห์ขั้นตอนการปรับแต่งอัตโนมัติ
- 4. การออกแบบสถาปัตยกรรมของแบ็กเอนด์ CuteDSL
- 4.1 กระบวนการทำงานหลัก
- 5. ผลการทดสอบประสิทธิภาพ
- 5.1 สภาพแวดล้อมการทดสอบและตัวชี้วัดการประเมิน
- 5.2 การเพิ่มประสิทธิภาพระดับเคอร์เนล
- 5.3 ประสิทธิภาพการอนุมาน vLLM แบบ end-to-end
- 6. ฟังก์ชันที่รองรับโดยแบ็กเอนด์ CuteDSL
- 6.1 รายการฟังก์ชัน
- 7. วิธีทดลองใช้แบ็กเอนด์ CuteDSL
- 7.1 ขั้นตอนการติดตั้ง
- 7.2 วิธีการใช้งาน
- 8. งานในอนาคต: แผนงานการพัฒนา
- สรุป: สรุปและมุมมอง
1. บทนำ
1.1 ภาพรวม
ปัจจุบัน TorchInductor รองรับแบ็กเอนด์การปรับแต่งอัตโนมัติสำหรับการคูณเมทริกซ์ (GEMM) สามตัว ได้แก่ Triton, CUTLASS (C++) และ cuBLAS บทความนี้จะแนะนำแผนการผสานรวม แรงจูงใจในการวิจัยและพัฒนาเทคโนโลยี และผลลัพธ์ประสิทธิภาพที่สังเกตได้จนถึงปัจจุบันของแบ็กเอนด์ที่สี่ นั่นคือ CuteDSL
ภาษาเฉพาะโดเมน (DSL) ในด้านการเขียนเคอร์เนลกำลังเติบโตอย่างรวดเร็ว โดย Triton, Helion, Gluon, CuTile และ CuteDSL แต่ละตัวมีตำแหน่งเฉพาะของตัวเองในการแลกเปลี่ยนระหว่างระดับการลดทอนความซับซ้อนและประสิทธิภาพ เมื่อประเมินว่าจะผสานรวมแบ็กเอนด์ใหม่เข้ากับ TorchInductor หรือไม่ เราปฏิบัติตามมาตรฐานหลักสามประการ:
- การผสานรวมจะไม่สร้างภาระการบำรุงรักษาที่หนักหน่วงให้กับทีม หรือมีผู้ขายให้การสนับสนุนอย่างต่อเนื่องในระยะยาว
- เมื่อเทียบกับแบ็กเอนด์ที่มีอยู่ จะไม่เพิ่มเวลาคอมไพล์หรือเวลาทดสอบมาตรฐาน
- สามารถให้ประสิทธิภาพที่ดีกว่าในโหลดงานเป้าหมาย
CuteDSL ตอบสนองมาตรฐานทั้งสามประการนี้อย่างสมบูรณ์ NVIDIA กำลังพัฒนา CuteDSL อย่างแข็งขัน และจัดเตรียมเทมเพลตเคอร์เนลที่ปรับแต่งให้เหมาะสมแล้ว ซึ่งช่วยลดแรงกดดันในการบำรุงรักษาของทีม TorchInductor ลงอย่างมาก เวลาคอมไพล์ของมันเทียบเท่ากับแบ็กเอนด์อื่นๆ ของเรา และเมื่อเทียบกับโซลูชัน CUTLASS C++ ที่ต้องเรียกใช้ nvcc แบบเต็มรูปแบบแล้ว มีการปรับปรุงที่เห็นได้ชัด
นอกจากผลประโยชน์ทันทีเหล่านี้แล้ว CuteDSL ยังเป็นการลงทุนเชิงกลยุทธ์ระยะยาวอีกด้วย มันมีพื้นฐานมาจากสถาปัตยกรรมการลดทอนความซับซ้อนเดียวกันกับ CUTLASS C++ ซึ่งแสดงประสิทธิภาพที่ยอดเยี่ยมในการคำนวณ GEMM ความแม่นยำ FP8 และการผสานการประมวลผลส่วนท้าย แต่ CuteDSL เขียนด้วย Python มีความเร็วในการคอมไพล์ที่เร็วกว่า และมีความซับซ้อนในการบำรุงรักษาที่ต่ำกว่า ในขณะที่ NVIDIA ยังคงทุ่มเทให้กับการปรับแต่งประสิทธิภาพของ CuteDSL มันมีแนวโน้มที่จะแทนที่แผนการผสานรวม CUTLASS C++ บนฮาร์ดแวร์รุ่นใหม่ๆ ในอนาคต และทำให้โค้ดเบสของ TorchInductor เรียบง่ายขึ้น
แรงจูงใจที่สอดคล้องกันระหว่างผู้ขายและชุมชน อัตราการนำไปใช้โอเพ่นซอร์สที่เพิ่มขึ้น และโมเดลการเขียนโปรแกรมระดับล่างที่สามารถเปิดเผยลำดับชั้นของเธรดและหน่วยความจำได้อย่างเต็มที่ ทำให้ CuteDSL เป็นแบ็กเอนด์ในอุดมคติสำหรับการบรรลุประสิทธิภาพ GEMM ที่ดีที่สุดบนฮาร์ดแวร์ NVIDIA ในปัจจุบันและอนาคต
2. กลยุทธ์: เหตุใดจึงมุ่งเน้นการคำนวณ GEMM
2.1 ความแตกต่างในการปรับแบ็กเอนด์สำหรับการดำเนินการต่างๆ
ไม่ใช่การดำเนินการทั้งหมดที่จะได้รับประโยชน์เท่ากันจากแบ็กเอนด์ใหม่ สำหรับการดำเนินการที่ถูกจำกัดด้วยหน่วยความจำ เช่น การดำเนินการทางคณิตศาสตร์แบบองค์ประกอบต่อองค์ประกอบ ฟังก์ชันกระตุ้น และการดำเนินการลดทอน Triton สามารถสร้างโค้ดคุณภาพสูงได้แล้ว โมเดลการเขียนโปรแกรมระดับบล็อกของมันเหมาะอย่างยิ่งกับโหลดงานประเภทนี้ที่ต้องการเพียงการเข้าถึงหน่วยความจำแบบเวกเตอร์ และประสิทธิภาพของเคอร์เนลที่สร้างโดย Triton แตกต่างจากเคอร์เนลที่เขียนด้วยมือเพียงเล็กน้อย
CuteDSL แม้ว่าสามารถแสดงการดำเนินการแบบจุดต่อจุดและการลดทอนได้ แต่ความซับซ้อนในการนำเคอร์เนลของมันไปสร้างอัตโนมัติตั้งแต่เริ่มต้นนั้นค่อนข้างสูง การทดสอบจริงแสดงให้เห็นว่าประสิทธิภาพของ DSL ทั้งสองในโหลดงานประเภทนี้ใกล้เคียงกัน ความซับซ้อนในการนำไปใช้เพิ่มเติมไม่ได้นำมาซึ่งผลประโยชน์ด้านประสิทธิภาพที่สำคัญ การทดลองยืนยันข้อสรุปนี้: บน GPU GB200 ทดสอบเคอร์เนล softmax ที่นำไปใช้ด้วย Triton และ CuteDSL ด้วยขนาดอินพุตต่างๆ ทั้งคู่สามารถเข้าใกล้ขีดจำกัดแบนด์วิธของฮาร์ดแวร์ได้
ตารางเปรียบเทียบประสิทธิภาพของโอเปอเรเตอร์ Softmax ที่นำไปใช้ด้วย Triton และ CuteDSL บนแพลตฟอร์ม GB200 ที่ความแม่นยำ FP16 ในการทดสอบหลายขนาดตั้งแต่ 3096² ถึง 16384² เวลาที่ใช้ของทั้งคู่เกือบเท่ากัน Speedup (Triton/CuTe DSL) คงที่ที่ 0.98x-1.00x และแบนด์วิธเพิ่มขึ้นตามขนาดสูงสุดประมาณ 7.2K GB/s ผลลัพธ์แสดงให้เห็นว่าประสิทธิภาพของเคอร์เนล Softmax ของ CuteDSL เทียบเท่ากับการนำไปใช้หลักของ Triton ซึ่งยืนยันว่าไม่เพียงแต่ใน GEMM เท่านั้น แต่ในโอเปอเรเตอร์ทั่วไปก็สามารถบรรลุประสิทธิภาพระดับมาตรฐานอุตสาหกรรมได้
การคำนวณ GEMM เป็นอีกเรื่องหนึ่ง การคูณเมทริกซ์มีบทบาทเด่นในโมเดลที่ใช้ Transformer: ในการส่งต่อของโมเดลภาษาขนาดใหญ่ทั่วไป การดำเนินการ GEMM ในการฉายภาพความสนใจ ชั้นเครือข่ายฟีดฟอร์เวิร์ด และเฮดเอาต์พุตใช้รอบการคำนวณ GPU ส่วนใหญ่
เพื่อให้ได้อัตราการใช้ฮาร์ดแวร์ใกล้เคียบค่าสูงสุดในการดำเนินการเหล่านี้ จำเป็นต้องมีการควบคุมที่แม่นยำของคุณลักษณะฮาร์ดแวร์ที่ GPU รุ่นใหม่แต่ละรุ่นแนะนำ ซึ่งรวมถึงการปรับขนาดบล็อกให้เข้ากับไปป์ไลน์ Tensor Core การจัดการแคชระดับหน่วยความจำร่วมอย่างชัดเจน การจัดตารางระดับ warp และเทคโนโลยีคลัสเตอร์บล็อกเธรดและหน่วยความจำร่วมแบบกระจายบนสถาปัตยกรรมใหม่ เช่น B200 สิ่งเหล่านี้คือรายละเอียดที่ภาษาระดับสูงซ่อนไว้เพื่อลดความซับซ้อนในการใช้งาน เพื่อลดความซับซ้อนของการสร้างโค้ดระดับล่าง เราไม่ได้เลือกที่จะสร้างเคอร์เนลตั้งแต่เริ่มต้น แต่พัฒนาบนพื้นฐานของเทมเพลตที่ปรับแต่งให้เหมาะสมด้วยมือ ซึ่งเปิดเผยพารามิเตอร์ที่กำหนดค่าได้ที่จำเป็นสำหรับการปรับประสิทธิภาพตามขนาดปัญหาต่างๆ
แบ็กเอนด์ CUTLASS C++ ที่มีอยู่แก้ไขปัญหานี้โดยให้ความสามารถในการควบคุมระดับล่าง แต่ค่าใช้จ่ายสูงของการคอมไพล์ C++ นำมาซึ่งข้อจำกัดในทางปฏิบัติ: แต่ละตัวแปรเคอร์เนลต้องมีการเรียกใช้ nvcc แบบเต็มรูปแบบ ซึ่งทำให้การประเมินตัวเลือกจำนวนมากในกระบวนการปรับแต่งอัตโนมัติมีต้นทุนสูงมาก และไม่สามารถทดสอบมาตรฐานการตัดสินใจผสานการประมวลผลส่วนท้ายในขั้นตอนการจัดตารางได้
CuteDSL แก้ไขปัญหานี้ด้วยคอมไพเลอร์ Python ถึง MLIR ที่กำหนดเอง
DSL นี้มีพื้นฐานมาจากสถาปัตยกรรมการลดทอนความซับซ้อนเดียวกันกับ CUTLASS C++ พีชคณิตบล็อกเดียวกัน ไพรมิทีฟลำดับชั้นหน่วยความจำเดียวกัน โมเดลการผสานการประมวลผลส่วนท้ายเดียวกัน แต่ความเร็วในการคอมไพล์สามารถเทียบเคียงได้กับแบ็กเอนด์อื่นๆ ของ TorchInductor การรวมกันของคุณลักษณะนี้ทำให้ TorchInductor สามารถนำกระบวนการปรับแต่งอัตโนมัติแบบเต็มและการทดสอบมาตรฐานการผสานที่ใช้กับแบ็กเอนด์อื่นๆ ไปใช้กับเคอร์เนล GEMM ที่มีความสามารถในการควบคุมฮาร์ดแวร์ระดับ CUTLASS คุณลักษณะหลักที่ทำให้บรรลุเป้าหมายนี้รวมถึง:
- การเปิดเผยลำดับชั้นของเธรดและหน่วยความจำอย่างสมบูรณ์: CuteDSL จัดเตรียมกลไกการซิงโครไนซ์ การควบคุมระดับ warp คลัสเตอร์บล็อกเธรด และไพรมิทีฟลำดับชั้นเธรด/หน่วยความจำแบบเต็ม สิ่งนี้ทำให้สามารถใช้ประโยชน์จากคุณลักษณะของสถาปัตยกรรมเฉพาะ เช่น หน่วยความจำร่วมแบบกระจายบน H100 และ B200
- การปรับเวลาคอมไพล์ให้เหมาะสม: โซลูชัน CUTLASS C++ ต้องดำเนินการเรียกใช้ nvcc แบบเต็มสำหรับแต่ละตัวแปรเคอร์เนล ค่าใช้จ่ายนี้ทำให้การทดสอบมาตรฐานการผสาน (คอมไพเลอร์ประเมินตัวเลือก GEMM หลายตัวที่มีการผสานการประมวลผลส่วน
⚠️ หมายเหตุ: เนื้อหาได้รับการแปลโดย AI และตรวจสอบโดยมนุษย์ หากมีข้อผิดพลาดโปรดแจ้ง
☕ สนับสนุนค่ากาแฟทีมงาน
หากคุณชอบบทความนี้ สามารถสนับสนุนเราได้ผ่าน PromptPay
SCAN TO PAY WITH ANY BANK本文来自网络搜集，不代表คลื่นสร้างอนาคต立场，如有侵权，联系删除。转载请注明出处：http://www.itsolotime.com/th/archives/31122