NCCL EP รวบรวมระบบนิเวศการสื่อสาร MoE: ทำลายความแตกแยก เร่งยุคใหม่ของการอนุมานโมเดลขนาดใหญ่

คำสำคัญ: MoE (Mixture-of-Experts), NCCL, การสื่อสาร GPU, การสื่อสารที่ริเริ่มจากอุปกรณ์ (Device-Initiated Communication), การอนุมานโมเดลขนาดใหญ่

บนเส้นทางสู่ปัญญาประดิษฐ์ทั่วไป ขนาดของโมเดลกำลังขยายตัวด้วยความเร็วที่ไม่เคยมีมาก่อน เมื่อโมเดล Transformer แบบหนาแน่น (dense) ถึงจุดอิ่มตัวในด้านประสิทธิภาพการคำนวณและพารามิเตอร์ สถาปัตยกรรมผู้เชี่ยวชาญผสม (Mixture-of-Experts, MoE) ด้วยคุณสมบัติ “เพิ่มคน เพิ่มการ์ด แต่ไม่เพิ่มการคำนวณ” ได้กลายเป็นเส้นทางสำคัญในการขยายขีดความสามารถของโมเดล ตั้งแต่ DeepSeek-V3 ถึง Mixtral, MoE ได้แยกพารามิเตอร์โมเดลออกเป็นเครือข่าย “ผู้เชี่ยวชาญ” แบบเบาบาง ทำให้ความจุของโมเดลเติบโตขึ้นอย่างมีนัยสำคัญ ในขณะที่ยังคงควบคุมต้นทุนการอนุมานได้

อย่างไรก็ตาม สถาปัตยกรรม MoE ได้นำความท้าทายด้านการสื่อสารรูปแบบใหม่ที่ซับซ้อนเข้ามาด้วย ลองจินตนาการถึงเครือข่ายย่อย “ผู้เชี่ยวชาญ” หลายหมื่นตัวกระจายอยู่บน GPU หลายพันตัว โทเค็นอินพุตแต่ละตัวต้องถูกกระจายอย่างแม่นยำไปยังผู้เชี่ยวชาญที่ถูกเลือกเพียงไม่กี่ตัวเพื่อประมวลผลตามกฎการกำหนดเส้นทาง (routing) แบบไดนามิก จากนั้นจึงรวบรวมผลลัพธ์กลับมา กระบวนการนี้ไม่ใช่การสื่อสารแบบซิงโครนัสขนาดใหญ่แบบดั้งเดิม (เช่น AllReduce) อีกต่อไป แต่เปลี่ยนเป็นการสื่อสารแบบละเอียด (fine-grained), แบบไดนามิก และแบบทุกต่อทุก (All-to-All)

เพื่อรับมือกับความท้าทายนี้ อุตสาหกรรมได้เห็นการเกิดขึ้นของไลบรารีการสื่อสารที่ริเริ่มจากอุปกรณ์ (Device-Initiated) หลายตัว เช่น DeepEP, Hybrid-EP เป็นต้น พวกมันเปรียบเสมือน “บริการจัดส่งด่วนพิเศษ” ที่ออกแบบมาเฉพาะสำหรับ MoE โดยอนุญาตให้ GPU ริเริ่มการเข้าถึงหน่วยความจำโดยตรงระยะไกล (RDMA) ได้โดยตรง ข้าม CPU ลดความล่าช้าในการสื่อสารลงอย่างมาก

ตาราง I: การเปรียบเทียบไลบรารีการสื่อสาร MoE ทั่วไปในมิติต่างๆ เช่น API มาตรฐาน การรองรับโหมด อินเทอร์เฟซการเขียนโปรแกรม และโหลดเป้าหมาย การวิเคราะห์แสดงให้เห็นว่าอีโคซิสเต็มในปัจจุบันมีปัญหาการแตกแยก: DeepEP และ pplx-kernels แม้จะมีประสิทธิภาพยอดเยี่ยม แต่ให้ API แยกกันสำหรับโหมดความล่าช้าต่ำ (LL) และปริมาณงานสูง (HT); ในขณะที่ Hybrid-EP มุ่งเน้นไปที่สถานการณ์การฝึกฝนเป็นหลัก ในทางตรงกันข้าม NCCL EP เป็นโซลูชันเดียวที่ให้ทั้ง API C/Python มาตรฐาน รองรับโหมดคู่ และสร้างขึ้นบนอีโคซิสเต็ม NCCL อย่างสมบูรณ์ ความเป็นหนึ่งเดียวนี้ทำให้การรวมเฟรมเวิร์กง่ายขึ้น หลีกเลี่ยงความซับซ้อนที่ผู้ใช้ต้องสลับระหว่างไลบรารีต่างๆ ซึ่งเป็นก้าวสำคัญสู่การมาตรฐานและแพลตฟอร์มของการสื่อสาร MoE

แต่ปัญหาการแตกแยกของอีโคซิสเต็มก็ปรากฏชัดขึ้นเช่นกัน แต่ละไลบรารีมี API ที่เป็นเอกลักษณ์ บางตัวได้รับการปรับให้เหมาะสมสำหรับการอนุมาน บางตัวสำหรับการฝึกฝน และสแต็กเทคโนโลยีพื้นฐานที่พึ่งพา (เช่น NVSHMEM, IBGDA) ก็แตกต่างกัน สิ่งนี้บังคับให้นักพัฒนาและผู้ดูแลเฟรมเวิร์กต้องดิ้นรนระหว่าง “ภาษาถิ่น” ต่างๆ เพิ่มความซับซ้อนและต้นทุนการบำรุงรักษาในการปรับใช้

ในบริบทนี้ NVIDIA ได้เปิดตัว NCCL EP (Expert Parallelism) มันไม่ได้เริ่มต้นใหม่จากศูนย์ แต่เลือกเส้นทาง “การรวมเป็นหนึ่งเดียว” โดยการผนวกความสามารถการสื่อสาร MoE เข้าไปใน NCCL (NVIDIA Collective Communications Library) อย่างเป็นธรรมชาติและเป็นหนึ่งเดียว

ดังที่ระบุไว้ในเอกสารวิจัย:

“By building MoE communication natively within NCCL, NCCL EP provides a supported path for expert parallelism on current and emerging NVIDIA platforms.”
(ด้วยการสร้างการสื่อสาร MoE ขึ้นภายใน NCCL อย่างเป็นธรรมชาติ NCCL EP จึงเป็นเส้นทางที่ได้รับการสนับสนุนสำหรับการขนานแบบผู้เชี่ยวชาญบนแพลตฟอร์ม NVIDIA ในปัจจุบันและที่กำลังจะเกิดขึ้น)

แนวคิดหลักของ NCCL EP คือ: ให้ชุด API ncclEpDispatch และ ncclEpCombine ที่เป็นหนึ่งเดียว โดยระดับล่างจะเลือกอัลกอริธึมการสื่อสารที่เหมาะสมที่สุด (โหมดความล่าช้าต่ำหรือโหมดปริมาณงานสูง) ตามโหลดงาน (ฝึกฝน/อนุมาน) และใช้ API ของอุปกรณ์ (Device API) ของ NCCL อย่างเต็มรูปแบบ ซึ่งหมายความว่านักพัฒนาไม่จำเป็นต้องสลับระหว่างไลบรารีหลายตัว เพียงใช้ชุด API เดียวก็สามารถรับประสิทธิภาพการสื่อสาร MoE ที่ปรับให้เหมาะสมบนฮาร์ดแวร์ NVIDIA ได้

รูปที่ 1: แผนภาพสถาปัตยกรรม NCCL EP การออกแบบเคอร์เนลความล่าช้าต่ำได้รับแรงบันดาลใจจาก DeepEP การออกแบบเคอร์เนลปริมาณงานสูงได้รับแรงบันดาลใจจาก Hybrid-EP โดยทั้งสองใช้ NCCL GIN (GPU-Initiated Networking) สำหรับการสื่อสาร RDMA ระหว่างโหนด ในขณะที่ยังคงการใช้งาน NVLink ดั้งเดิมสำหรับการสื่อสารภายในโหนด สถาปัตยกรรมนี้เผยให้เห็นแนวคิดหลักของ NCCL EP: รวบรวมข้อดีจากทุกฝ่าย และรวมเป็นหนึ่งภายใต้เฟรมเวิร์ก NCCL มันไม่ได้ออกแบบอัลกอริธึมเคอร์เนลใหม่ แต่ปรับเคอร์เนลที่ยอดเยี่ยมซึ่งผ่านการทดสอบจากอุตสาหกรรม (DeepEP สำหรับความล่าช้าต่ำ, Hybrid-EP สำหรับปริมาณงานสูง) และแทนที่พรีมิทีฟการสื่อสารระดับล่างด้วย GIN และ LSA จาก NCCL Device API ด้วยวิธีนี้ NCCL EP จึงสืบทอดข้อได้เปรียบด้านประสิทธิภาพของเคอร์เนลเหล่านี้ในแต่ละสถานการณ์ และรวมแบ็กเอนด์การสื่อสารเป็นหนึ่งเดียว ทำให้สามารถใช้ประโยชน์จากความสามารถในการรับรู้โทโพโลยีของ NCCL (เช่น การเลือก NVLink หรือ PCIe) และความเข้ากันได้ของอีโคซิสเต็มได้โดยอัตโนมัติ การออกแบบแบบบูรณาการนี้มีจุดมุ่งหมายเพื่อสร้างสมดุลระหว่างประสิทธิภาพและความสามารถในการบำรุงรักษา

แล้วผลลัพธ์จริงเป็นอย่างไร? ตามข้อมูลการทดลอง:
* ในโหมดความล่าช้าต่ำ (LL) สำหรับสถานการณ์การถอดรหัสการอนุมาน ปริมาณงานการกระจาย (Dispatch) ของ NCCL EP บนคลัสเตอร์ 8 โหนด (64 GPU) เทียบเท่ากับ DeepEP ที่ทันสมัยที่สุดหรือดีกว่าเล็กน้อย
* ในการทดสอบบูรณาการการอนุมานแบบครบวงจร (ใช้เฟรมเวิร์ก vLLM, โมเดล Qwen3-30B-A3B) NCCL EP ที่ขนาด 4 โหนด (32 GPU) มีปริมาณงานเอาต์พุตถึง 563.3 tok/s เวลาเฉลี่ยในการประมวลผลต่อโทเค็นคือ 54.1 ms ความแตกต่างของประสิทธิภาพกับ DeepEP อยู่ภายใน 10% และช่องว่างนี้ส่วนใหญ่มาจากค่าใช้จ่ายในการสื่อสาร ซึ่งเป็นจุดสำคัญสำหรับการปรับให้เหมาะสมในอนาคต

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

• หนึ่ง. พื้นหลัง: ทำไมการสื่อสาร MoE จึง “แตกต่าง” มากเช่นนี้?
  • 1.1 กระบวนการส่งต่อ (Forward Pass) ของ MoE
  • 1.2 ลักษณะสำคัญสามประการของการสื่อสาร MoE
• สอง. ปรัชญาการออกแบบ NCCL EP: จาก “ร้อยสำนักร้อยลัทธิ” สู่ “มาตรฐานเดียวกัน”
  • 2.1 API มาตรฐานเดียว ขจัดความแตกแยก
  • 2.2 NCCL ดั้งเดิม สืบทอดข้อได้เปรียบของอีโคซิสเต็ม
  • 2.3 การจัดการวงจรชีวิตทรัพยากร
• สาม. การวิเคราะห์แกนกลาง: โหมดการสื่อสารสองแบบของ NCCL EP
  • 3.1 โหมดความล่าช้าต่ำ (Low-Latency Mode, LL Mode): ออกแบบมาเพื่อ “การถอดรหัส” โดยเฉพาะ
  • 3.2 โหมดปริมาณงานสูง (High-Throughput Mode, HT Mode): ออกแบบมาเพื่อ “การฝึกฝน” และ “การเติมล่วงหน้า”
• สี่. พลังระดับล่าง: ความน่าดึงดูดของ NCCL Device API
  • 4.1 โมดูล 1: Load/Store Accessible (LSA)
  • 4.2 โมดูล 2: GPU-Initiated Networking (GIN)
  • 4.3 โมดูล 3: Multiterm
• ห้า. การบูรณาการอีโคซิสเต็ม: จากเอกสารวิจัยสู่การผลิต
  • 5.1 Megatron-LM (การฝึกฝน)
  • 5.2 vLLM (การอนุมาน)
• หก. งานที่เกี่ยวข้อง: NCCL EP ภายใต้หมู่ดาวที่สุกสกาว
• เจ็ด. การประเมินประสิทธิภาพและมุมมองในอนาคต
• สรุป

หนึ่ง. พื้นหลัง: ทำไมการสื่อสาร MoE จึง “แตกต่าง” มากเช่นนี้?

ก่อนที่จะเจาะลึกถึง NCCL EP มีความจำเป็นต้องเข้าใจปัญหาที่มันมุ่งหมายจะแก้ไขก่อน นั่นคือ ความพิเศษของการสื่อสาร MoE โมเดล Transformer แบบดั้งเดิม (เช่น GPT-3) มีรูปแบบการสื่อสารที่สม่ำเสมอและสมมาตรสูง ในสถานการณ์การขนานแบบโมเดลหรือข้อมูลแบบขนาน มักใช้ AllReduce เพื่อซิงโครไนซ์เกรเดียนต์ หรือใช้ AllGather เพื่อรวบรวมผลลัพธ์ขั้นกลาง พรีมิทีฟการสื่อสารเหล่านี้มีลักษณะเฉพาะคือ: ฝ่ายที่เข้าร่วมทั้งหมดแลกเปลี่ยนข้อมูลในปริมาณเท่ากัน และรูปแบบการสื่อสารคงที่

1.1 กระบวนการส่งต่อ (Forward Pass) ของ MoE

โมเดล MoE ได้เปลี่ยนกระบวนทัศน์นี้โดยสิ้นเชิง กระบวนการส่งต่อสามารถแยกย่อยได้ดังนี้:

1. การกำหนดเส้นทาง (Gating): โทเค็นอินพุตแต่ละตัวผ่านตัวกำหนดเส้นทาง (Router) สร้างการกระจายน้ำหนัก และเลือกผู้เชี่ยวชาญที่ตรงที่สุด k คน (top-k)
2. การกระจาย (Dispatch): ตามผลการกำหนดเส้นทาง ส่งข้อมูลโทเค็นและเมตาดาต้าไปยัง GPU ที่ผู้เชี่ยวชาญที่เลือกอยู่
3. การคำนวณผู้เชี่ยวชาญ (Expert Computation): GPU ปลายทางดำเนินการคำนวณเครือข่ายผู้เชี่ยวชาญ (เช่น FFN) บนโทเค็นที่ได้รับ
4. การรวบรวม (Combine): นำผลลัพธ์ที่คำนวณโดยผู้เชี่ยวชาญมา รวมตามลำดับโทเค็นเดิมและน้ำหนักการกำหนดเส้นทางด้วยการรวมถ่วงน้ำหนัก และรวบรวมกลับไปยัง GPU เดิม

1.2 ลักษณะสำคัญสามประการของการสื่อสาร MoE

จากขั้นตอนข้างต้น สามารถสรุปลักษณะสำคัญสามประการของการสื่อสาร MoE ได้:

• การกำหนดเส้นทางแบบไดนามิก: รูปแบบการสื่อสารเปลี่ยนแปลงแบบไดนามิกในแต่ละการส่งต่อ ถูกกำหนดโดยผลการกำหนดเส้นทางของโทเค็นในแบทช์ปัจจุบันทั้งหมด
• ขนาดข้อความไม่สม่ำเสมอ: “ความร้อนแรง” ของผู้เชี่ยวชาญแต่ละคนบน GPU ต่างๆ แตกต่างกัน ส่งผลให้ปริมาณข้อมูลที่แลกเปลี่ยนระหว่าง GPU แต่ละคู่ไม่สมมาตรสูง
• โหลดไม่สมดุล: “ผู้เชี่ยวชาญยอดนิยม” จะได้รับโทเค็นมากกว่า “ผู้เชี่ยวชาญที่ไม่เป็นที่นิยม” อย่างมาก ทำให้เกิดความไม่สมดุลของโหลดการสื่อสารและการคำนวณอย่างรุนแรง

ลักษณะเหล่านี้ทำให้การสื่อสารแบบรวมกลุ่ม AllToAll แบบดั้งเดิมรับมือได้อย่างมีประสิทธิภาพยาก NCCL AllToAll มาตรฐานสมมติว่าปริมาณการสื่อสารระหว่าง rank ทุกตัวสมดุลกัน ไม่สามารถจัดการ “ปรากฏการณ์มัทธิว” นี้ได้อย่างมีประสิทธิภาพ ดังนั้นจึงจำเป็นต้องมีไลบรารีการสื่อสาร MoE เฉพาะทาง ซึ่งต้องมีความสามารถในการประมวลผลแบบไดนามิกและการจัดตารางเวลาที่ยืดหยุ่นบนฝั่งอุปกรณ์

สอง. ปรัชญาการออกแบบ NCCL EP: จาก “ร้อยสำนักร้อยลัทธิ” สู่ “มาตรฐานเดียวกัน”

เมื่อเผชิญกับความท้าทายข้างต้น การออกแบบ NCCL EP หมุนรอบปรัชญาหลักสองประการคือ “ความเป็นหนึ่งเดียว” และ “ความเป็นธรรมชาติ”

2.1 API มาตรฐานเดียว ขจัดความแตกแยก

นี่เป็นหนึ่งในผลงานที่โดดเด่นที่สุดของ NCCL EP มันละทิ้งรูปแบบที่ไลบรารีการสื่อสาร MoE หลายตัวต่างดำเนินการของตัวเองในอดีต และให้ชุด API ภาษาซีและ Python ที่เป็นมาตรฐานเดียว

ตาราง II: การออกแบบหลักของ NCCL EP C API การออกแบบนี้แบ่ง API ออกเป็นสองประเภทหลักอย่างชัดเจน: การจัดการทรัพยากรและการสื่อสาร การจัดการทรัพยากรใช้โครงสร้างสองระดับ: ncclEpGroup_t แทนกลุ่มการสื่อสารที่มีอยู่ยาวนาน (จัดการการเชื่อมต่อ, บัฟเฟอร์ ฯลฯ) ในขณะที่ ncclEpHandle_t จะห่อหุ้มสถานะการกำหนดเส้นทางแบบไดนามิกสำหรับแต่ละการส่งต่อ การออกแบบนี้ช่วยลดค่าใช้จ่ายในการสร้างการเชื่อมต่อ และยังปรับให้เข้ากับพลวัตของการกำหนดเส้นทาง MoE ได้ด้วย แฟล็ก send_only ใน API การสื่อสารเป็นกุญแจสำคัญในการทับซ้อนการคำนวณและการสื่อสาร อนุญาตให้ปล่อยทรัพยากร GPU ก่อนที่ข้อมูลจะถูกส่งถ่ายทั้งหมด สอดคล้องกับโมเดลการดำเนินการแบบอะซิงโครนัสสตรีมมิ่งของ NCCL เป็น

---

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

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

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

SCAN TO PAY WITH ANY BANK

本文来自网络搜集，不代表คลื่นสร้างอนาคต立场，如有侵权，联系删除。转载请注明出处：https://www.itsolotime.com/th/archives/27457