MoE ตัวร้ายประสิทธิภาพการฝึก! ByteDance UniEP ใช้เทคโนโลยี MegaKernel เร่งความเร็ว 1.38 เท่า โดยไม่ลดทอนความสอดคล้องของค่าตัวเลข

“ส่วนประกอบเฉพาะของ MoE (ครอบคลุมขั้นตอนการกระจาย การคำนวณผู้เชี่ยวชาญ และการรวม) อาจกินงบประมาณการฝึกอบรมทั้งหมด 30% ถึง 80%” ข้อมูลนี้ในรายงานวิจัยน่าตกใจเป็นพิเศษ และชี้ให้เห็นถึงปัญหาทั่วไปที่อุตสาหกรรมการฝึกอบรมโมเดลขนาดใหญ่ต้องเผชิญ

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

การขนานผู้เชี่ยวชาญ (Expert Parallelism) ซึ่งเป็นโซลูชันการกระจายมาตรฐานสำหรับการฝึกอบรมโมเดล MoE แม้จะแก้ปัญหาการจัดเก็บและคำนวณพารามิเตอร์ผู้เชี่ยวชาญได้ แต่ก็ทำให้เกิดค่าใช้จ่ายในการสื่อสารแบบ token routing จำนวนมาก เพื่อปกปิดความล่าช้าในการสื่อสารนี้ นักวิจัยได้เสนอเทคนิคการซ้อนทับการคำนวณและการสื่อสารหลายวิธี แต่วิธีการเหล่านี้ไม่ว่าจะต้องพึ่งพาการจัดการหลายสตรีมที่ซับซ้อน ทำให้ค่าใช้จ่าย CPU เพิ่มสูงขึ้นและเกิดฟองอากาศซิงโครไนซ์ หรือต้องแยกไมโครแบทช์เพื่อให้เกิดการซ้อนทับ ซึ่งทำให้เสียความสอดคล้องของค่าตัวเลข และไม่สามารถตอบสนองข้อกำหนดที่เข้มงวดของการฝึกอบรมระดับการผลิตได้

• UniEP: Unified Expert-Parallel MoE MegaKernel for LLM Training
• https://arxiv.org/pdf/2604.19241
• โค้ด: https://github.com/ByteDance-Seed/Triton-distributed
• 15,000 คำ อ่าน 60 นาที พอดแคสต์ 23 นาที

เพื่อแก้ไขปัญหาเหล่านี้ ทีม Seed ของ ByteDance ร่วมกับภาควิชาวิทยาการคอมพิวเตอร์ มหาวิทยาลัยชิงหัว ได้เปิดตัว UniEP ซึ่งเป็นระบบฝึกอบรมแบบขนานผู้เชี่ยวชาญแบบครบวงจร ข้อมูลเชิงลึกหลักของ UniEP คือการขยายเทคโนโลยี MegaKernel ซึ่งเดิมใช้สำหรับสถานการณ์การอนุมาน ไปสู่ขอบเขตการฝึกอบรม โดยการรวมกราฟย่อยการสื่อสารและการคำนวณของ MoE เข้าเป็น MegaKernel เดียว ทำให้เกิดการซ้อนทับการคำนวณและการสื่อสารในระดับละเอียดที่ระดับ SM ของ GPU พร้อมกับใช้กลไกการแมป token แบบกำหนดตายตัว เพื่อรับประกันความสอดคล้องของค่าตัวเลขในระดับบิตกับการดำเนินการตามลำดับอย่างเคร่งครัด

ผลการทดลองแสดงให้เห็นว่า บนคลัสเตอร์ที่ติดตั้ง GPU NVIDIA Hopper นั้น UniEP มีความเร็วเพิ่มขึ้น 1.03 ถึง 1.38 เท่า เมื่อเทียบกับระบบ COMET ที่ทันสมัยที่สุดในปัจจุบัน ในคลัสเตอร์การฝึกอบรมระดับการผลิตที่มี 128 GPU ปริมาณงานการฝึกอบรมเพิ่มขึ้นจาก 127 พันล้าน token/วัน เป็น 138 พันล้าน token/วัน หรือเพิ่มขึ้น 9%

รูปที่ 3: ประสิทธิภาพระดับเคอร์เนลของ UniEP บนคลัสเตอร์ 1 และคลัสเตอร์ 2 แผนภูมิเปรียบเทียบความแตกต่างของประสิทธิภาพระหว่าง UniEP, COMET และเบสไลน์แบบอนุกรมบนเคอร์เนลการกระจายและรวม ในสภาพแวดล้อมที่จำกัดแบนด์วิดท์ (คลัสเตอร์ 1) และแบนด์วิดท์สูง (คลัสเตอร์ 2) ยิ่งแบนด์วิดท์ถูกจำกัดมากเท่าไหร่ ข้อได้เปรียบของ UniEP ก็ยิ่งเด่นชัดมากขึ้นเท่านั้น โดยมีความเร็วสูงสุดถึง 1.87 เท่า ในสถานการณ์แบนด์วิดท์สูง ก็ยังคงเป็นผู้นำด้วยการหลอมรวมสตรีมเดียว หัวใจสำคัญมาจากการบีบอัดแบนด์วิดท์ของงานรีเลย์และการออกแบบสตรีมเดียวที่ไม่มีฟองอากาศ ซึ่งยืนยันความสามารถในการปรับตัวที่แข็งแกร่งของ UniEP ต่อสถานการณ์คอขวดด้านการสื่อสาร และยังพิสูจน์ให้เห็นถึงผลประโยชน์ร่วมกันของการหลอมรวมเคอร์เนลและการเพิ่มประสิทธิภาพแบนด์วิดท์ รูปที่ 4: ประสิทธิภาพระดับเลเยอร์ของ UniEP บนคลัสเตอร์ 1 และคลัสเตอร์ 2 แผนภูมิรวมความหน่วงของเลเยอร์ MoE ทั้งหมดทั้งไปข้างหน้าและย้อนกลับ ข้อได้เปรียบของ UniEP จะขยายตัวอย่างต่อเนื่องในลำดับยาว โดยในคลัสเตอร์ 1 มีความเร็วเพิ่มขึ้นกว่า 20% เมื่อเทียบกับ COMET การหลอมรวมสตรีมเดียวช่วยขจัดค่าใช้จ่ายในการซิงโครไนซ์ข้ามสตรีม การจัดลำดับ token แบบกำหนดตายตัวรับประกันความเสถียรของค่าตัวเลข และงานรีเลย์ช่วยลดการส่งข้อมูลซ้ำซ้อนของ NVLink ประสิทธิภาพระดับเลเยอร์สอดคล้องกับการฝึกอบรมทางอุตสาหกรรมจริง พิสูจน์ว่า UniEP ไม่เพียงแต่มีเคอร์เนลที่มีประสิทธิภาพ แต่ยังสามารถรักษาประสิทธิภาพ ความแม่นยำ และความเสถียรในห่วงโซ่การฝึกอบรมที่สมบูรณ์ ปรับให้เข้ากับความต้องการการฝึกอบรม LLM จริง ตารางที่ 8: ประสิทธิภาพสัมบูรณ์ (มิลลิวินาที) ที่ความยาวลำดับ 128k ตารางแสดงข้อมูลความหน่วงของ UniEP, COMET และเบสไลน์แบบอนุกรมภายใต้การฝึกอบรมลำดับยาวพิเศษ UniEP มีความเร็วเพิ่มขึ้น 2.38 ถึง 6.9 เท่าเมื่อเทียบกับเบสไลน์ ภายใต้ลำดับยาวพิเศษ แรงกดดันด้านการสื่อสารเพิ่มสูงขึ้น ข้อได้เปรียบของการหลอมรวมสตรีมเดียวและการบีบอัดแบนด์วิดท์ของ UniEP ถูกขยายให้ใหญ่สุด ความหน่วงต่อขั้นตอนต่ำกว่าเบสไลน์อย่างมีนัยสำคัญ ในการฝึกอบรมบริบทระยะยาวระดับอุตสาหกรรม การเพิ่มปริมาณงานมากกว่า 10% สามารถแปลงเป็นการประหยัดต้นทุนพลังการคำนวณมหาศาล ยืนยันคุณค่าหลักของ UniEP ในการฝึกอบรม LLM ขนาดใหญ่และลำดับยาว ปรับให้เข้ากับความต้องการการฝึกอบรม LLM รุ่นต่อไป

ที่สำคัญยิ่งกว่านั้น การปรับปรุงประสิทธิภาพทั้งหมดนี้ เกิดขึ้นภายใต้เงื่อนไขการรักษาความสอดคล้องของค่าตัวเลขระดับบิต ซึ่งหมายความว่า UniEP สามารถแทนที่โมดูลการขนานผู้เชี่ยวชาญในระบบการผลิตที่มีอยู่ได้โดยตรง โดยไม่ส่งผลกระทบต่อวิถีการฝึกอบรมหรือความแม่นยำของโมเดล

ปัจจุบัน การใช้งาน MegaKernel ของ UniEP ได้เปิดเป็นโอเพนซอร์สที่ https://github.com/ByteDance-Seed/Triton-distributed เพื่อให้ชุมชนได้ศึกษาและนำไปใช้

unsetunsetสารบัญunsetunset

• หนึ่ง ภาวะกลืนไม่เข้าคายไม่ออกด้านการสื่อสารของการฝึกอบรม MoE และข้อบกพร่องร้ายแรงของโซลูชันที่มีอยู่
  • 1.1 แก่นแท้ของการขนานผู้เชี่ยวชาญและที่มาของค่าใช้จ่ายในการสื่อสาร
  • 1.2 ข้อบกพร่องหลักสองประการของวิธีการเพิ่มประสิทธิภาพที่มีอยู่
• สอง การออกแบบหลักของ UniEP: สถาปัตยกรรม MegaKernel แบบครบวงจร
  • 2.1 ข้อมูลเชิงลึกหลัก: จากการซ้อนทับแบบหยาบหลายสตรีมสู่การหลอมรวมแบบละเอียดสตรีมเดียว
  • 2.2 รายละเอียดการใช้งาน Dispatch+GroupGEMM MegaKernel
  • 2.3 ความแตกต่างที่สำคัญของ GroupGEMM+Combine MegaKernel
• สาม การปรับแต่งอัตโนมัติ: จากการปรับพารามิเตอร์ด้วยตนเองสู่การกำหนดค่าที่เหมาะสมที่สุดโดยรับรู้ถึงฮาร์ดแวร์
  • 3.1 พื้นที่การเพิ่มประสิทธิภาพและการแลกเปลี่ยนพารามิเตอร์
  • 3.2 การสร้างแบบจำลองประสิทธิภาพเชิงวิเคราะห์
  • 3.3 การจัดตาราง token แบบลำดับความสำคัญและการเพิ่มประสิทธิภาพรันไทม์
• สี่ การประเมินผลการทดลอง: การก้าวกระโดดของประสิทธิภาพที่ผ่านการตรวจสอบระดับการผลิต
  • 4.1 การตั้งค่าการทดลองและการเลือกเกณฑ์มาตรฐาน
  • 4.2 การตรวจสอบความแม่นยำของค่าตัวเลข: ความสำคัญที่ก้าวล้ำของการเบี่ยงเบนเป็นศูนย์
  • 4.3 การเปรียบเทียบประสิทธิภาพระดับเคอร์เนลและเลเยอร์
  • 4.4 ประสิทธิภาพการฝึกอบรมบริบทยาวและแบบ end-to-end
  • 4.5 การทดสอบการตัดออก: การวัดปริมาณการมีส่วนร่วมของส่วนประกอบการเพิ่มประสิทธิภาพแต่ละส่วน
• ห้า การเปรียบเทียบกับงานที่เกี่ยวข้อง
  • 5.1 ไลบรารีเคอร์เนลประสิทธิภาพสูงและคอมไพเลอร์เทนเซอร์
  • 5.2 เทคนิคการซ้อนทับการคำนวณและการสื่อสาร
  • 5.3 กรอบงานการฝึกอบรมและการอนุมาน MoE
• หก บทสรุปและแนวโน้มในอนาคต
  • 6.1 สรุปผล
  • 6.2 การวิเคราะห์ขั้นสูง: ขอบเขตและข้อจำกัดของวิธีการ
  • 6.3 งานในอนาคต

unsetunsetหนึ่ง ภาวะกลืนไม่เข้าคายไม่ออกด้านการสื่อสารของการฝึกอบรม MoE และข้อบกพร่องร้ายแรงของโซลูชันที่มีอยู่unsetunset

เมื่อขนาดพารามิเตอร์ของโมเดลภาษาขนาดใหญ่ทะลุระดับล้านล้าน สถาปัตยกรรม Mixture-of-Experts (MoE) ได้กลายเป็นเส้นทางสู่การปรับขนาดที่可行ได้เพียงเส้นทางเดียวที่อุตสาหกรรมยอมรับ ตั้งแต่ GPT-5, Gemini3 Pro ไปจนถึง DeepSeek-V3, Qwen3 โมเดลขนาดใหญ่ชั้นนำทุกรุ่นล้วนใช้การออกแบบ MoE โดยไม่มีข้อยกเว้น

อย่างไรก็ตาม สถาปัตยกรรม MoE ในขณะที่นำมาซึ่งความสามารถในการปรับขนาดพารามิเตอร์ ก็ได้นำมาซึ่งความท้าทายด้านการสื่อสารที่ไม่เคยมีมาก่อนเช่นกัน การขนานผู้เชี่ยวชาญ (Expert Parallelism) ซึ่งเป็นกลยุทธ์การกระจายมาตรฐานสำหรับการฝึกอบรม MoE มีแกนหลักคือการปรับใช้ผู้เชี่ยวชาญที่แตกต่างกันบน GPU ที่แตกต่างกัน และบรรลุการกระจายโหลดการคำนวณที่สมดุลผ่าน token routing แต่กระบวนการ routing นี้เองที่กลายเป็นคอขวดที่ใหญ่ที่สุดของระบบฝึกอบรมทั้งหมด

1.1 แก่นแท้ของการขนานผู้เชี่ยวชาญและที่มาของค่าใช้จ่ายในการสื่อสาร

ขั้นตอนการทำงานของเลเยอร์ MoE สามารถแบ่งออกเป็นสองระยะ: การแพร่กระจายไปข้างหน้า (Forward Propagation) และการแพร่กระจายย้อนกลับ (Backward Propagation) ดังแสดงในรูปที่ 1

รูปที่ 1: กระบวนการแพร่กระจายไปข้างหน้าและย้อนกลับของ MoE รูปนี้แสดงการไหลของข้อมูลของเลเยอร์ MoE ในระหว่างการฝึกอบรมอย่างสมบูรณ์: การแพร่กระจายไปข้างหน้าจะผ่านสามขั้นตอนตามลำดับ: การกระจาย (Scatter), การคำนวณ GroupGEMM และการรวม (Combine) การแพร่กระจายย้อนกลับเป็นกระบวนการย้อนกลับของการแพร่กระจายไปข้างหน้า แต่การคำนวณเกรเดียนต์ของน้ำหนักต้องใช้ GroupGEMM แบบทรานสโพส ในกระบวนการนี้ การดำเนินการสื่อสารในขั้นตอนการกระจายและการรวมเป็นคอขวดด้านประสิทธิภาพหลัก ในโหมดขนานผู้เชี่ยวชาญ (EP) การสื่อสารและการคำนวณจะ交织กันอย่างลึกซึ้ง วิธีการดั้งเดิมจะแยกออกเป็นฟังก์ชันเคอร์เนลอิสระ อาศัยการซิงโครไนซ์ CPU จึงทำให้เกิดค่าใช้จ่ายเพิ่มเติมและความผันผวนของค่าตัวเลข UniEP จะรวมขั้นตอนข้างต้นเป็นเคอร์เนลขนาดใหญ่ (MegaKernel) เดียว โดยเพิ่มประสิทธิภาพโดยตรงกับคอขวดของกระบวนการ ให้พื้นฐานระดับกระบวนการสำหรับการออกแบบการหลอมรวมสตรีมเดียว และเน้นย้ำถึงจุดเจ็บปวดหลักของการเพิ่มประสิทธิภาพ EP

• ในระยะการแพร่กระจายไปข้างหน้า ประการแรก เครือข่ายประตู (Gating Network) จะคำนวณความน่าจะเป็นที่แต่ละ token จะถูกกำหนดให้กับผู้เชี่ยวชาญแต่ละคน จากนั้นจะกำหนดผู้เชี่ยวชาญเป้าหมายและ GPU เป้าหมายของแต่ละ token ตามการเลือก top-k (โดยปกติ k=6 หรือ 8) ต่อจากนั้น token จะถูกจัดเรียงใหม่และส่งไปยัง GPU เป้าหมายผ่าน primitive การสื่อสาร AlltoAll หรือ AllGather ซึ่งเป็นขั้นตอนการกระจาย เมื่อ token มาถึง GPU เป้าหมายแล้ว จะดำเนินการคำนวณผ่านการดำเนินการ GroupGEMM หลังจากเปิดใช้งานด้วย SwiGLU แล้ว จะถูกฉายกลับไปยังมิติเดิมผ่าน GroupGEMM ตัวที่สอง สุดท้าย ผลลัพธ์การคำนวณจะถูกส่งกลับไปยัง GPU ต้นทาง และทำการถ่วงน้ำหนักและรวมตามคะแนนประตู ซึ่งเป็นขั้นตอนการรวม
• ขั้นตอนการแพร่กระจายย้อนกลับมีความสมมาตรกับการแพร่กระจายไปข้างหน้า แต่มีความซับซ้อนที่สำคัญ: การคำนวณเกรเดียนต์ของน้ำหนักต้องใช้ GroupGEMM แบบทรานสโพส แตกต่างจาก GroupGEMM ในการแพร่กระจายไปข้างหน้าที่แบ่งพาร์ติชันตามมิติ token GroupGEMM แบบทรานสโพสจะแบ่งพาร์ติชันตามมิติการสะสม ซึ่งหมายความว่าวิธีการแบ่งชุดข้อมูลนำเข้าจะเปลี่ยนลำดับการสะสมของเกรเดียนต์ เนื่องจากการบวกเลขทศนิยมไม่เป็นไปตามสมบัติการเปลี่ยนหมู่ โดยเฉพาะอย่างยิ่งที่ความแม่นยำ BFloat16 การเปลี่ยนแปลงลำดับการสะสมจะทำให้เกิดความแตกต่างในระดับบิตของเกรเดียนต์ ซึ่งส่งผลต่อความสามารถในการทำซ้ำของการฝึกอบรมและความแม่นยำของโมเดล

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

1.2 ข้อบกพร่องหลักสองประการของวิธีการเพิ่มประสิทธิภาพที่มีอยู่

เพื่อบรรเทาคอขวดด้านการสื่อสารในการฝึกอบรม MoE นักวิจัยได้เสนอวิธีการเพิ่มประสิทธิภาพมากมายในด้านการคำนวณ การสื่อสาร และการซ้อนทับ

• ในด้านการคำนวณ GroupGEMM แบบไม่เติม (Padding-free GroupGEMM) เป็นการเพิ่มประสิทธิภาพหลักที่สุด
  • การใช้งาน GroupGEMM แบบดั้งเดิมใช้การเติมเพื่อรวมจำนวน token ที่แตกต่างกันของผู้เชี่ยวชาญแต่ละคน ทำให้ทรัพยากรการคำนวณจำนวนมากสูญเปล่า
  • ระบบเช่น MegaBlocks และ vLLM เสนอ GroupGEMM แบบไม่เติมโดยใช้รูปแบบ稀疏แบบบล็อก (block-sparse format) จัดการกับ offset token ที่ไม่สม่ำเสมอผ่านเลขคณิตพอยน์เตอร์แบบไดนามิก เพิ่มอัตราการใช้ประโยชน์ Tensor Core ของ GPU ให้สูงกว่า 65%
• ในด้านการสื่อสาร การเพิ่มประสิทธิภาพ primitive โดยใช้ NVSHMEM ได้กลายเป็นกระแสหลัก
  • ไลบรารี NCCL แบบดั้งเดิมได้รับการปรับให้เหมาะสมสำหรับการขนานเทนเซอร์แบบหนาแน่นเป็นหลัก และไม่รองรับรูปแบบการสื่อสารแบบ稀疏และไดนามิกของ MoE ได้ดี
  • ระบบเช่น COMET และ DeepEP ใช้ NVSHMEM เพื่อให้สามารถเข้าถึงหน่วยความจำ GPU ถึง GPU ได้โดยตรง ข้าม CPU โฮสต์ และเพิ่มอัตราการใช้แบนด์วิดท์การสื่อสารอย่างมีนัยสำคัญ โดย DeepEP เชี่ยวชาญในการเพิ่มประสิทธิภาพ primitive AlltoAll ในขณะที่ COMET เพิ่มประสิทธิภาพ primitive AllGather
• ในด้านการซ้อนทับ วิธีการที่มีอยู่แบ่งออกเป็นสองประเภทหลัก: การซ้อนทับระดับ tile และการซ้อนทับระดับแบทช์
  • การซ้อนทับระดับ tile จะ分解ปริมาณงานเป็น tile ขนาดคงที่ ดำเนินการสื่อสารและคำนวณในสตรีม CUDA ที่แตกต่างกัน และซิงโครไนซ์ผ่านสัญญาณ粒度ละเอียดในหน่วยความจำส่วนกลาง COMET ใช้วิธีนี้
  • การซ้อนทับระดับแบทช์ใช้เทคนิค double buffering ในระดับไมโครแบทช์: เมื่อสตรีมหนึ่งประมวลผลการคำนวณของแบทช์ปัจจุบัน อีกสตรีมหนึ่งจะดำเนินการสื่อสารของแบทช์ถัดไป DeepEP ใช้วิธีนี้

แม้ว่าวิธีการเพิ่มประสิทธิภาพเหล่านี้จะประสบความสำเร็จในระดับหนึ่ง แต่รายงานวิจัยชี้ให้เห็นว่ามีข้อบกพร่องร้ายแรงสองประการ:

• ประการแรก วิธีการที่มีอยู่ถือว่าการคำนวณและการสื่อสารเป็นการดำเนินการที่แยกจากกัน และอาศัยการจัดการหลายสตรีมแบบหยาบเพื่อให้เกิดการซ้อนทับ การแยกนี้จำเป็นต้องมีการแทรกแซงจากฝั่งโฮสต์บ่อยครั้งเพื่อเริ่มเคอร์เนลและซิงโครไนซ์สตรีม ทำให้เกิดค่าใช้จ่าย CPU จำนวนมากและฟองอากาศซิงโครไนซ์ ในการฝึกอบรมแบบกระจายขนาดใหญ่ การซิงโครไนซ์ rank ระหว่าง GPU ที่แตกต่างกันจะขยายฟองอากาศเหล่านี้ให้ใหญ่ขึ้น และอาจ抵消ผลประโยชน์จากการซ้อนทับได้อย่างสมบูรณ์ ที่ร้ายแรงกว่านั้น การซ้อนทับระดับแบทช์จำเป็นต้องแยกไมโครแบทช์ ซึ่งจะเปลี่ยนลำดับการสะสมเกรเดียนต์ของ GroupGEMM แบบทรานสโพส ทำให้เกิดความไม่เสถียรของค่าตัวเลข และทำลายความสามารถในการทำซ้ำของการฝึกอบรม
• ประการที่สอง กรอบงานที่มีอยู่ขาด primitive การสื่อสารแบบครบวงจร AllGather มีประสิทธิภาพแบนด์วิดท์สูงกว่าเมื่อ top-k มีขนาดใหญ่ ในขณะที่ AlltoAll มีประสิทธิภาพดีกว่าเมื่อ routing แบบ稀疏 การแบ่งขั้วนี้บังคับให้นักพัฒนาต้องรักษากฎฮิวริสติกที่ซับซ้อนและเคอร์เนลอิสระหลายตัว ซึ่งไม่เพียงเพิ่มต้นทุนการพัฒนาและบำรุงรักษา แต่ยังจำกัดความสามารถในการพกพาและความสามารถในการปรับตัวของระบบ

วิธีการเพิ่มประสิทธิภาพการฝึกอบรม MoE ที่มีอยู่陷入了一个无法突破的悖论: ไม่ว่าจะแยกไมโครแบทช์เพื่อให้เกิดการซ้อนทับประสิทธิภาพสูง แต่เสียสละความสอดคล้องของค่าตัวเลข หรือรักษาความสอดคล้องของค่าตัวเลข แต่ได้ผลการซ้อนทับที่จำกัดเท่านั้น เป้าหมายหลักของ UniEP คือการ打破悖论นี้ โดยให้เกิดการซ้อนทับการคำนวณและการสื่อสารสูงสุดภายใต้เงื่อนไขการรับประกันความสอดคล้องของค่าตัวเลขอย่างเคร่งครัด

unsetunsetสอง การออกแบบหลักของ UniEP: สถาปัตยกรรม MegaKernel แบบครบวงจรunsetunset

นวัตกรรมหลักของ UniEP คือการขยายเทคโนโลยี MegaKernel จากสถานการณ์การอนุมานไปสู่ขอบเขตการฝึกอบรม โดยการรวมกราฟย่อยการสื่อสารและการคำนวณของ MoE เข้าเป็น MegaKernel เดียว ทำให้เกิดการซ้อนทับการคำนวณและการสื่อสารในระดับละเอียดที่ระดับ SM ของ GPU

แตกต่างจากวิธีการหลายสตรีมแบบดั้งเดิม UniEP จะถ่ายโอนตรรกะการจัดตารางทั้งหมดไปยัง GPU SM โดยสมบูรณ์ โดยไม่จำเป็นต้องมีการแทรกแซงจากฝั่งโฮสต์ใดๆ这不仅消除了ค่าใช้จ่าย CPU และฟองอากาศซิงโครไนซ์ แต่ยัง实现了การปรับสมดุลโหลดอัตโนมัติของทรัพยากรการคำนวณและการสื่อสารผ่านการจัดตาราง SM แบบไดนามิก ในเวลาเดียวกัน UniEP รับประกันความสอดคล้องของค่าตัวเลขในระดับบิตกับการดำเนินการตามลำดับอย่างเคร่งครัดผ่านกลไกการแมป token แบบกำหนดตายตัว

2.1 ข้อมูลเชิงลึกหลัก: จากการซ้อนทับแบบหยาบหลายสตรีมสู่การหลอมรวมแบบละเอียดสตรีมเดียว

การออกแบบของ UniEP ขึ้นอยู่กับข้อมูลเชิงลึกหลักสองประการ:

• ข้อมูลเชิงลึกแรกคือ สตรีมมิ่งโปรเซสเซอร์ (SM) ของ GPU สามารถ实现การซ้อนทับแบบละเอียดของการคำนวณและการสื่อสารผ่านการจัดตารางระดับบล็อก โดยไม่จำเป็นต้องมีการจัดการหลายสตรีมจากฝั่งโฮสต์ วิธีการหลายสตรีมแบบดั้งเดิมถือว่า GPU ทั้งหมดเป็นทรัพยากรเดียว และจัดสรรให้กับงานคำนวณหรือการสื่อสารในเวลาที่แตกต่างกัน ในความเป็นจริง GPU ประกอบด้วย SM อิสระหลายตัว และ SM ที่แตกต่างกันสามารถดำเนินงานที่แตกต่างกันพร้อมกันได้ UniEP ใช้ประโยชน์จากสิ่งนี้ โดยจัดสรร SM ที่แตกต่างกันแบบไดนามิกให้กับบทบาทการสื่อสารหรือการคำนวณ ทำให้เกิดการซ้อนทับระดับคำสั่งภายในสตรีม CUDA เดียว

• ข้อมูลเชิงลึกที่สองคือ ผ่านการ抽象แบบกำหนดพารามิเตอร์ (parameterized abstraction) สามารถรวมรูปแบบการสื่อสาร AllGather และ AlltoAll เข้าด้วยกันได้ โดยไม่จำเป็นต้องสลับเคอร์เนลอย่างชัดเจน ความแตกต่างที่สำคัญระหว่าง AllGather และ AlltoAll อยู่ที่วิธีการกระจายข้อมูล: AllGather ส่งข้อมูลทั้งหมดไปยังทุก rank จากนั้นจึงทำการกระจาย (scatter) ในเครื่อง ในขณะที่ AlltoAll ส่งข้อมูลไปยัง rank เป้าหมายโดยตรง

UniEP 实现รูปแบบผสมผ่าน Relay Worker ซึ่ง既保留了ข้อได้เปรียบด้านปริมาณการสื่อสารที่ต่ำของ AlltoAll ก็มีความยืดหยุ่นของ AllGather ในขณะเดียวกันก็ปรับให้เข้ากับปริมาณงานที่แตกต่างกันโดยอัตโนมัติผ่านพื้นที่การกำหนดค่าที่กำหนดพารามิเตอร์

จากข้อมูลเชิงลึกทั้งสองนี้ UniEP ได้ออกแบบ MegaKernel หลักสองตัว: Dispatch+GroupGEMM MegaKernel และ GroupGEMM+Combine MegaKernel

MegaKernel ทั้งสองนี้สอดคล้องกับสองขั้นตอนหลักของการแพร่กระจายไปข้างหน้าของเลเยอร์ MoE และยัง適用กับขั้นตอนที่สอดคล้องกันของการแพร่กระจายย้อนกลับอีกด้วย

2.2 รายละเอียดการใช้งาน Dispatch+GroupGEMM MegaKernel

Dispatch+GroupGEMM MegaKernel เป็นส่วนประกอบหลักที่สุดของ UniEP ซึ่งรวมสองขั้นตอนของการกระจาย token และการคำนวณผู้เชี่ยวชาญในการแพร่กระจายไปข้างหน้าเข้าเป็นเคอร์เนลเดียว การใช้งานขึ้นอยู่กับเทคโนโลยีสำคัญห้าประการ: สถาปัตยกรรม Worker แบบถาวร (Persistent Worker Architecture), การแมป token แบบกำหนดตายตัว (Deterministic Token Mapping), กลไกการซิงโครไนซ์ Scoreboard, การจัดตาราง SM แบบไดนามิก (Dynamic SM Scheduling) และการเพิ่มประสิทธิภาพแบนด์วิดท์ Relay Worker

สถาปัตยกรรม Worker แบบถาวร

MegaKernel ของ UniEP ใช้การออกแบบบล็อกเธรดแบบถาวร (Persistent Thread Block) เมื่อเริ่มเคอร์เนล จะเริ่มบล็อกเธรดจำนวนเท่ากับจำนวน SM ทางกายภาพของ GPU ทุกประการ โดยแต่ละบล็อกเธรดจะทำหน้าที่เป็น Worker ถาวร ครอบครอง SM หนึ่งตัวตลอดระยะเวลาการดำเนินการของเคอร์เนล การแมปแบบหนึ่งต่อหนึ่งนี้ช่วยขจัดค่าใช้จ่ายในการสลับบริบทของบล็อกเธรด และหลีกเลี่ยงปัญหาการ deadlock ที่อาจเกิดขึ้นเนื่องจากจำนวนบล็อกเธรดเกินความจุของฮาร์ดแวร์

Worker แต่ละตัวสามารถรับหนึ่งในสามบทบาทแบบไดนามิก:

Communication Worker

มีหน้าที่ส่ง token และเริ่มต้นธุรกรรมการแลกเปลี่ยนข้อมูลข้าม GPU

Compute Worker

ดำเนินการงานคำนวณ tile ของ GroupGEMM โดยเฉพาะ

Relay Worker

รับผิดชอบในการจัดการสัญญาณซิงโครไนซ์ และดำเนินการ multicast ข้อมูลภายใน GPU

การแมป token แบบกำหนดตายตัว

ความสอดคล้องของค่าตัวเลขเป็นข้อกำหนดเบื้องต้นพื้นฐานสำหรับการฝึกอบรมระดับการผลิต และลำดับการส่งและรับ token ส่งผลโดยตรงต่อความเสถียรของผลลัพธ์นี้ เพื่อให้แน่ใจว่าไม่ว่าลำดับการดำเนินการแบบขนานจะเปลี่ยนแปลงไปอย่างไร ลำดับการจัดเรียง token ในบัฟเฟอร์แคชของผู้เชี่ยวชาญเป้าหมายจะถูกกำหนดไว้ UniEP เสนออัลกอริทึมการแมป token ระดับโลกแบบกำหนดตายตัว ดังแสดงในอัลกอริทึมที่ 1

อัลกอริทึมที่ 1: การแมป token ระดับโลกแบบกำหนดตายตัว อัลกอริทึมนี้สร้างที่อยู่ระดับโลกที่ไม่ซ้ำกัน (ประกอบด้วยการ์ดเป้าหมาย หมายเลขผู้เชี่ยวชาญ offset) สำหรับแต่ละ token ผ่านการเรียงลำดับเสถียรในเครื่อง (local stable sort), AllGather นับจำนวนทั่วโลก และการคำนวณ offset ผลรวมนำหน้า (prefix sum) กระบวนการทั้งหมดไม่จำเป็นต้องใช้ atomic lock การคำนวณแบบขนานทั้งหมดไม่มีการขัดแย้ง ทำให้แน่ใจว่าลำดับของ token ถูกกำหนดไว้หลังจากการส่งข้ามการ์ด นี่คืออัลกอริทึมหลักที่ UniEP ใช้เพื่อให้ได้ค่าตัวเลขที่เสถียร แก้ปัญหาความไม่เป็นระเบียบของการสะสมเกรเดียนต์ที่เกิดจากการจัดตารางการซ้อนทับ รับประกันความสอดคล้องระดับบิตในการแพร่กระจายย้อนกลับ ทำให้การซ้อนทับประสิทธิภาพสูงและการทำซ้ำความแม่นยำระดับอุตสาหกรรมสามารถเกิดขึ้นได้พร้อมกัน เป็นการออกแบบที่สำคัญที่ทำให้ UniEP แตกต่างจากโซลูชันที่มีอยู่

แนวคิดหลักของอัลกอริทึมที่ 1 คือ: ใช้การดำเนินการ AllGather เพื่อรวบรวมจำนวน token ที่ทุก rank ส่งไปยังผู้เชี่ยวชาญแต่ละคน จากนั้นคำนวณ offset ฐานระดับโลก b ของ token ที่แต่ละ rank ส่งไปยังผู้เชี่ยวชาญแต่ละคน โดยเฉพาะอย่างยิ่ง สำหรับผู้เชี่ยวชาญ e offset ฐานระดับโลกของ token จาก rank r เท่ากับผลรวมนำหน้าของจำนวน token ที่ rank ทั้งหมดที่มีหมายเลขน้อยกว่า r ส่งไปยังผู้เชี่ยวชาญ e จากนั้น รวม offset ฐานนี้กับดัชนีการเรียงลำดับเสถียรในเครื่อง จะได้ที่อยู่เป้าหมายที่ไม่ซ้ำกันและไม่มีการขัดแย้งสำหรับแต่ละ token

กลไกการแมปนี้ทำให้ Communication Worker สามารถส่ง token แบบขนานได้ โดยไม่จำเป็นต้องซิงโครไนซ์รันไทม์ใดๆ ในขณะเดียวกันก็รับประกันลำดับของ token ในบัฟเฟอร์แคชเป้าหมายอย่างเคร่งครัด ซึ่งทำให้แน่ใจว่าลำดับการสะสมของ GroupGEMM และการดำเนินการลดรูป (reduce) ที่ตามมานั้นสอดคล้องกับการดำเนินการตามลำดับอย่างสมบูรณ์ จึง实现ความสอดคล้องของค่าตัวเลขในระดับบิต

กลไกการซิงโครไนซ์ Scoreboard

เพื่อประสานงานความสัมพันธ์แบบพึ่งพาระหว่างผู้ผลิต (Communication Worker และ Relay Worker) และผู้บริโภค (Compute Worker) UniEP ใช้ Scoreboard หน่วยความจำส่วนกลางแบบน้ำหนักเบา Scoreboard นี้แบ่งออกเป็นสองส่วน:

• ส่วนแรกใช้สำหรับติดตามสถานะการมาถึงของ token แต่ละตัว
• ส่วนที่สองใช้สำหรับทำเครื่องหมายว่า tile GroupGEMM ที่สมบูรณ์พร้อมแล้วหรือไม่

Relay Worker มีหน้าที่ตรวจสอบสถานะการมาถึงของ token เมื่อ Communication Worker เขียน token ลงในบัฟเฟอร์แคชเป้าหมายสำเร็จ จะอัปเดตรายการที่สอดคล้องกันในส่วนแรก Relay Worker จะ轮询รายการเหล่านี้ เมื่อ token ทั้งหมดของ tile GroupGEMM ที่สมบูรณ์ (เช่น ประกอบด้วย 128 token) มาถึงแล้ว Relay Worker จะตั้งค่าสถานะที่สอดคล้องกันในส่วนที่สองด้วยการดำเนินการแบบอะตอม

Compute Worker จะ轮询ส่วนที่สอง เมื่อตรวจพบสัญญาณ tile พร้อมแล้ว จะดำเนินการคำนวณ GroupGEMM ของ tile นั้นทันที UniEP ใช้เคอร์เนล GroupGEMM แบบไม่เติม (padding-free) ที่ได้รับแรงบันดาลใจจาก MegaBlocks และ vLLM จัดการกับรูปร่าง tile ที่ไม่สม่ำเสมอผ่านเลขคณิตพอยน์เตอร์แบบไดนามิก จึงมั่นใจได้ว่าอัตราการใช้ Tensor Core สูง

การจัดตาราง SM แบบไดนามิก

การจัดสรรบทบาท SM แบบคงที่มักนำไปสู่การโหลดที่ไม่สมดุล โดยเฉพาะอย่างยิ่งในสถานการณ์ที่โหลดการ routing ของ MoE เปลี่ยนแปลงแบบไดนามิก เพื่อแก้ปัญหานี้ UniEP ใช้กลยุทธ์การจัดสรรบทบาทใหม่แบบไดนามิกโดยใช้ตัวนับอะตอมระดับโลก

ระบบจะรักษาตัวนับอะตอมระดับโลกหนึ่งตัว ซึ่งทำหน้าที่เป็นเคอร์เซอร์ของคิวงาน พื้นที่งานถูกทำให้เป็นเส้นตรง: ดัชนีจาก 0 ถึง (N_{comm}-1) สอดคล้องกับงานสื่อสาร จาก (N_{comm}) ถึง (N_{total}-1) สอดคล้องกับงานคำนวณ ในรันไทม์ SM แต่ละตัวจะได้รับงานโดยการเพิ่มตัวนับระดับโลกแบบอะตอม ID งานที่ส่งคืนจะกำหนดบทบาทปัจจุบันของ SM:

1. หาก ID สอดคล้องกับงานสื่อสาร SM จะกลายเป็น Communication Worker
2. หาก ID สอดคล้องกับงานคำนวณ SM จะกลายเป็น Compute Worker (อาจต้องรอสัญญาณ Scoreboard)
3. เมื่องานเสร็จสมบูรณ์ SM จะขอ ID งานใหม่

กลไกนี้ปรับสมดุลปริมาณงานโดยธรรมชาติ: ในตอนแรก SM ทั้งหมดจะประมวลผลงานสื่อสาร เมื่อข้อมูลมาถึงและ Scoreboard ถูกเติม SM จะค่อยๆ เปลี่ยนไปสู่บทบาทการคำนวณ

รูปที่ 2: ตัวอย่างลำดับเวลาและเวิร์กโฟลว์ของ Dispatch + GroupGEMM MegaKernel รูปนี้แสดงตรรกะการจัดตารางแบบไดนามิกภายในสตรีมเดียวของ UniEP อย่าง直观: SM ของ GPU จะสลับบทบาทการสื่อสาร การถ่ายทอด และการคำนวณแบบไดนามิก ดำเนินงานแบบขนานเพื่อขจัดฟองอากาศซิงโครไนซ์ในสตรีมคู่แบบดั้งเดิม ในช่วงแรกจะเน

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

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

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

SCAN TO PAY WITH ANY BANK