โมเดล MoE: การปฏิวัติแบบเบาบางจะก้าวข้ามคอขวดการขยายตัวของโมเดลภาษาขนาดใหญ่ได้อย่างไร?

บทนำ

ในช่วงหลายปีที่ผ่านมา การขยายตัวของโมเดลภาษาแบบหนาแน่นขนาดใหญ่เป็นแรงขับเคลื่อนหลักในการพัฒนาของโมเดลภาษาขนาดใหญ่ (LLMs) ตั้งแต่โมเดลยุคแรกๆ เช่น ULMFiT (ประมาณ 30 ล้านพารามิเตอร์) หรือ GPT-2 (1.5 พันล้านพารามิเตอร์) ไปจนถึงระบบในปัจจุบันที่มีพารามิเตอร์หลายแสนล้านพารามิเตอร์ แนวคิดหลักในการขยายขนาดยังคงเป็นไปตามกระบวนทัศน์ง่ายๆ:

ข้อมูลมากขึ้น + พารามิเตอร์มากขึ้น = ประสิทธิภาพที่ดีขึ้น

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

นี่คือจุดที่ โมเดลผสมผู้เชี่ยวชาญ เข้ามามีบทบาทและเปิดการปฏิวัติแบบเบาบาง

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

จากหนาแน่นสู่เบาบาง: MoE คืออะไร?

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

รูปที่ 1: เราเตอร์เปิดใช้งานผู้เชี่ยวชาญ 1 สำหรับโทเค็นปัจจุบันจากผู้เชี่ยวชาญ 4 คน (แผนผัง)

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

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

ยกตัวอย่างโมเดล gpt-oss-20b: มีพารามิเตอร์ทั้งหมด 21 พันล้าน แต่แต่ละโทเค็นเปิดใช้งานเพียง 4 คนจากผู้เชี่ยวชาญ 32 คน รวมกับพารามิเตอร์ที่แชร์ในโมเดล แต่ละโทเค็นใช้พารามิเตอร์ประมาณ 3.6 พันล้านพารามิเตอร์ในการคำนวณจริง บน M3 Ultra Mac ที่มีแบนด์วิธหน่วยความจำประมาณ 800GB/s ความเร็วในการสร้างตามทฤษฎีสามารถประมาณคร่าวๆ ได้ดังนี้:

800 / (3.6 × 2) (ภายใต้ความแม่นยำ bfloat16 พารามิเตอร์แต่ละตัวใช้ 2 ไบต์)

ผลลัพธ์ประมาณ 111 โทเค็น/วินาที ในขณะที่ความเร็วที่วัดได้จริงประมาณ 115 โทเค็น/วินาที ซึ่งสอดคล้องกับการประมาณอย่างมาก นี่แสดงให้เห็นว่าเมื่ออนุมาน ค่าใช้จ่ายในการคำนวณของโมเดลคล้ายกับโมเดลหนาแน่น 3.6 พันล้านพารามิเตอร์ แต่สามารถแสดงประสิทธิภาพใกล้เคียงกับโมเดล 21 พันล้านพารามิเตอร์

(หมายเหตุ: หากใช้เคอร์เนลควอนไทซ์ mxfp4 ดั้งเดิมของโมเดล ความเร็วจะเพิ่มขึ้นอีก)

ข้อได้เปรียบของ MoE แสดงให้เห็นในหลายด้าน:

1. ประสิทธิภาพการคำนวณที่สูงขึ้น: ภายใต้งบประมาณการคำนวณการฝึกเดียวกัน โมเดล MoE มักจะได้รับประสิทธิภาพที่ดีกว่าโมเดลหนาแน่นขนาดเท่ากัน
   
   รูปที่ 2: เส้นโค้งเปรียบเทียบการสูญเสียระหว่างการฝึกของโมเดลหนาแน่นและโมเดล MoE
2. เหมาะโดยธรรมชาติสำหรับการคำนวณแบบขนาน: เครือข่ายผู้เชี่ยวชาญสร้างขอบเขตโครงสร้างที่ชัดเจนในกราฟการคำนวณ เนื่องจากโทเค็นที่แตกต่างกันใช้ผู้เชี่ยวชาญที่แตกต่างกัน การคำนวณแบบขนานที่มีประสิทธิภาพสามารถทำได้ในมิติของผู้เชี่ยวชาญ
3. การนำไปใช้อย่างกว้างขวางในอุตสาหกรรม: MoE ได้กลายเป็นแนวโน้มสำคัญของสถาปัตยกรรมโมเดลขนาดใหญ่ในปัจจุบัน โมเดล MoE แบบโอเพ่นซอร์สที่เผยแพร่ล่าสุดรวมถึง Qwen 3.5, MiniMax M2, GLM-5, Kimi K2.5 เป็นต้น แนวโน้มนี้เร่งขึ้นอย่างเห็นได้ชัดหลังจากการเผยแพร่ DeepSeek R1 ซึ่งสถาปัตยกรรมของมันสามารถย้อนกลับไปยัง DeepSeek V2 ที่เก่ากว่าได้ ผลงานตัวแทนที่เก่ากว่าอีกชิ้นหนึ่งคือ Mixtral-8x7B ที่เผยแพร่ในเดือนธันวาคม 2023
   
   รูปที่ 3: แนวโน้มการเติบโตของจำนวนโมเดล MoE ในไลบรารี Transformers ในช่วงสองปีที่ผ่านมา การเผยแพร่ DeepSeek R1 เป็นจุดเปลี่ยนสำคัญ

โมเดลแบบปิด (closed-source) ก็ใช้สถาปัตยกรรม MoE อย่างกว้างขวางเช่นกัน ChatGPT ถูกคาดการณ์มานานว่าใช้สถาปัตยกรรมแบบเบาบาง ในขณะที่โมเดลโอเพ่นซอร์สซีรีส์ gpt-oss ใช้การออกแบบ MoE อย่างชัดเจน

Transformers กับ MoE

เครื่องมือส่วนใหญ่ในระบบนิเวศปัจจุบัน (เช่น การโหลดโมเดล การจัดสรรอุปกรณ์ การควอนไทซ์ และแบ็กเอนด์การดำเนินการ) ออกแบบมาในตอนแรกสำหรับโมเดล หนาแน่น ลักษณะแบบเบาบางของ MoE ท้าทายสมมติฐานพื้นฐานเหล่านี้

เพื่อให้ MoE เป็น พลเมืองชั้นหนึ่ง ในไลบรารี transformers ไม่เพียงแต่ต้องเพิ่มคลาสโมเดลใหม่เท่านั้น แต่ยังต้องปรับโครงสร้างกระบวนการโหลดโมเดล กลไกการดำเนินการ และนามธรรมแบบกระจายใหม่ทั้งหมด ต่อไป เราจะเน้นแนะนำว่าไลบรารี transformers พัฒนาเพื่อรองรับสถาปัตยกรรมแบบเบาบางอย่างไร:

• [การปรับโครงสร้างการโหลดน้ำหนัก]
• [แบ็กเอนด์การดำเนินการผู้เชี่ยวชาญ]
• [การขนานผู้เชี่ยวชาญ]
• [การฝึก MoE ด้วย Transformers]

การปรับโครงสร้างการโหลดน้ำหนัก

สำหรับโมเดลหนาแน่น กระบวนการ AutoModelForCausalLM.from_pretrained(“model_id”) ค่อนข้างตรงไปตรงมา: เทนเซอร์น้ำหนักแต่ละตัวที่ดาวน์โหลดจากจุดตรวจสอบ มักจะจับคู่กับพารามิเตอร์บางตัวของโมดูลรันไทม์ได้โดยตรง

แต่สำหรับโมเดล MoE สถานการณ์ซับซ้อนกว่า ในจุดตรวจสอบของโมเดล MoE ส่วนใหญ่ น้ำหนักของผู้เชี่ยวชาญแต่ละคนจะถูกบันทึกแบบอนุกรมแยกกัน ตัวอย่างเช่น เมื่อดูไฟล์ดัชนีจุดตรวจสอบของ DeepSeek-V3 คุณจะเห็นชื่อคีย์ดังต่อไปนี้:

model.layers.3.mlp.experts.0.gate_proj.weight
...
model.layers.3.mlp.experts.255.gate_proj.weight

ผู้เชี่ยวชาญแต่ละคนมีชุดเมทริกซ์น้ำหนักของตัวเองที่เป็นอิสระ ตัวอย่างเช่น DeepSeek-V3 โดยพื้นฐานแล้วคือการบันทึกน้ำหนักของเครือข่ายฟีดฟอร์เวิร์ดขนาดเล็ก (FFN) 256 ตัว (หมายเลข 0 ถึง 255) ไว้เคียงข้างกัน

อย่างไรก็ตาม เมื่อโมเดลทำงานจริง GPU จะดำเนินการเคอร์เนลการคำนวณที่ได้รับการปรับให้เหมาะสมสูง เคอร์เนล MoE สมัยใหม่ เช่น grouped GEMM และการใช้งาน MoE แบบฟิวชัน ออกแบบมาเพื่อประมวลผลผู้เชี่ยวชาญทั้งหมดพร้อมกันในการดำเนินการครั้งเดียว แทนที่จะวนซ้ำผู้เชี่ยวชาญ

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

สิ่งนี้ทำให้เกิดความไม่ตรงกันที่สำคัญ:
* รูปแบบจุดตรวจสอบ: เทนเซอร์อิสระ 256 ตัว
* ความต้องการรันไทม์: เทนเซอร์ต่อเนื่องที่บรรจุแล้ว 1 ตัว

บทบาทหลักของการปรับโครงสร้างการโหลดน้ำหนักคือการเชื่อมช่องว่างนี้ด้วยวิธีที่เป็นระบบ แนวคิดเปลี่ยนจากการที่ “โครงสร้างจุดตรวจสอบตรงกับโครงสร้างรันไทม์ เพียงคัดลอกตามคีย์” ไปเป็นแนวคิดที่ยืดหยุ่นกว่า: จุดตรวจสอบเป็นเพียงแหล่งที่มาของการบันทึกแบบอนุกรมของเทนเซอร์ กระบวนการโหลดโดยพื้นฐานแล้วเป็นไปิปไลน์การแปลงที่แปลงเทนเซอร์ดั้งเดิมเหล่านี้เป็นเลย์เอาต์ที่ต้องการสำหรับรันไทม์

การใช้ WeightConverter เพื่อโหลดแบบไดนามิก

นามธรรมหลักที่การปรับโครงสร้างนี้นำเข้ามาคือ การโหลดน้ำหนักแบบไดนามิก ซึ่งดำเนินการผ่านคลาส WeightConverter

WeightConverter อนุญาตให้เรากำหนดกฎการแมปจากรูปแบบต้นทางไปยังรูปแบบเป้าหมาย:
source key patterns → target key(s) + operations

การดำเนินการพื้นฐาน (เช่น การแบ่ง การเชื่อมต่อ ฯลฯ) สามารถรวมกันได้อย่างยืดหยุ่น ในหมู่พวกนี้ มีสองการดำเนินการที่ใช้บ่อยในสถานการณ์ MoE:

• MergeModulelist: ใช้เพื่อรวมชุดเทนเซอร์เป็นเทนเซอร์เดียว ตัวอย่างเช่น สามารถใช้ MergeModulelist ร่วมกับการดำเนินการ Concatenate เพื่อซ้อนและบรรจุน้ำหนักของผู้เชี่ยวชาญหลายคนในเลเยอร์ MoE เป็นเทนเซอร์รวมเดียว
  python
WeightConverter(
["block_sparse_moe.experts.*.w1.weight", "block_sparse_moe.experts.*.w3.weight"],
"mlp.experts.gate_up_proj",
operations=[
MergeModulelist(dim=0),
Concatenate(dim=1),
],
)
• SplitModulelist: ใช้เพื่อแยกเทนเซอร์กลับเป็นชุดเทนเซอร์ ตัวอย่างเช่น สามารถแยกน้ำหนักผู้เชี่ยวชาญที่ซ้อนและบรรจุแล้วกลับเป็นน้ำหนักผู้เชี่ยวชาญอิสระ
  python
WeightConverter(
"mlp.experts.down_proj",
"block_sparse_moe.experts.*.w2.weight",
operations=[SplitModulelist(dim=0)],
)

การสร้างอินสแตนซ์เทนเซอร์แบบล่าช้า

การปรับโครงสร้างนี้ไม่เพียงแต่เพิ่มความสามารถในการแปลง แต่ยังปรับปรุงกลยุทธ์การจัดตารางเวลาการดำเนินงานการแปลงด้วย

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

กลไกการสร้างอินสแตนซ์แบบล่าช้านี้ช่วยลดการสแกนซ้ำซ้อนและจุดสูงสุดของการใช้หน่วยความจำได้อย่างมีประสิทธิภาพ

การทดสอบมาตรฐาน: การปรับปรุงประสิทธิภาพของกระบวนการโหลดน้ำหนัก

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

การทดสอบใช้สาขาโค้ดต่อไปนี้เพื่อเปรียบเทียบ:
* สาขา v4
* สาขา v5

โค้ดตัวอย่างการทดสอบมีดังนี้:
python
from transformers import AutoModelForCausalLM

model_id = “Qwen/Qwen1.5-110B-Chat”
model = AutoModelForCausalLM.from_pretrained(model_id)

การทดสอบเกี่ยวข้องกับตัวแปรสภาพแวดล้อมที่สำคัญสองตัว:
* HF_ENABLE_PARALLEL_LOADING: ใช้เพื่อเปิดใช้งานฟังก์ชันการโหลดแบบขนานแบบแบ่งส่วนตามเธรด

ตัวแปรสภาพแวดล้อม HF_DEACTIVATE_ASYNC_LOAD

• HF_DEACTIVATE_ASYNC_LOAD: ตั้งค่าเป็น True เพื่อปิดโฟลว์การโหลดแบบอะซิงโครนัสที่เปิดใช้งานโดยค่าเริ่มต้นในเวอร์ชัน v5 เป็นตัวเลือกสำหรับการย้อนกลับไปยังวิธีการโหลดแบบซิงโครนัสรุ่นเก่า

ผลการทดสอบประสิทธิภาพ

โมเดลทดสอบ: Qwen/Qwen1.5-110B-Chat
ฮาร์ดแวร์ทดสอบ: 1× A100 (80GB)

| เวอร์ชัน | กลยุทธ์ขนาน | วิธีการโหลด | เวลาโหลด |
| :— | :— | :— | :— |
| v4.57.6 | auto | พูลเธรด | 66.24s |
| v4.57.6 | auto | ลำดับ | 67.29s |
| v4.57.6 | TP | — | OOM |
| v5 | auto | อะซิงโครนัส (ค่าเริ่มต้น) | 20.71s |
| v5 | auto | ซิงโครนัส | 45.3s |
| v5 | TP | อะซิงโคร

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

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

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

SCAN TO PAY WITH ANY BANK