DeepSeek-V4 เปิดตัว: ซ่อนความหน่วงในการสื่อสารแบบขนานผู้เชี่ยวชาญละเอียด, การปรับแต่ง FP4 Quantization และ TileLang ร่วมกันเพื่อเพิ่มประสิทธิภาพบริบท Token หลายล้าน

เทคโนโลยี Expert Parallel (EP) ที่ใช้ในโมเดล Mixture of Experts (MoE) แม้จะช่วยเร่งกระบวนการอนุมานและฝึกฝนโมเดลได้อย่างมีประสิทธิภาพ แต่ก็นำมาซึ่งปัญหาการสื่อสารระหว่างโหนดที่ซับซ้อน ปัญหานี้กำหนดข้อกำหนดที่เข้มงวดอย่างยิ่งเกี่ยวกับแบนด์วิธและความหน่วงของการเชื่อมต่อระหว่างกัน ส่งผลให้กลายเป็นคอขวดหลักที่จำกัดการปรับปรุงประสิทธิภาพของโมเดลขนาดใหญ่

DeepSeek-V4 ได้สร้างระบบโครงสร้างพื้นฐานทั่วไปที่สมบูรณ์แบบ เพื่อรับมือกับความท้าทายสำคัญหลายประการอย่างแม่นยำ เช่น การทำงานร่วมกันระหว่างการสื่อสารและการคำนวณ ประสิทธิภาพการพัฒนาเคอร์เนล ความแน่นอนในการฝึกฝน การปรับใช้เชิงปริมาณ และการอนุมานบริบทยาว

• DeepSeek-V4: Towards Highly Efficient Million-Token Context Intelligence
• https://huggingface.co/deepseek-ai/DeepSeek-V4-Pro/blob/main/DeepSeek_V4.pdf
• ลิงก์โอเพนซอร์ส: https://huggingface.co/collections/deepseek-ai/deepseek-v4
• เนื้อหาทั้งหมดประมาณ 10,000 คำ ใช้เวลาอ่าน 40 นาที เวอร์ชันพอดแคสต์ประมาณ 30 นาที

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

ในขณะเดียวกัน ทีมวิจัยใช้ภาษาเฉพาะโดเมน (DSL) อย่าง TileLang เพื่อลดความซับซ้อนของขั้นตอนการพัฒนาเคอร์เนลลงอย่างมาก โดยการผสมผสานการสร้างโค้ดโฮสต์เข้ากับการวิเคราะห์เชิงรูปแบบด้วย SMT Solver ทำให้สามารถรักษาสมดุลระหว่างประสิทธิภาพการพัฒนาและประสิทธิภาพการทำงาน นอกจากนี้ ทีมงานยังสร้างไลบรารีเคอร์เนลที่แน่นอนและไม่แปรผันตามแบตช์ เพื่อรับประกันความสามารถในการทำซ้ำของการฝึกฝน นำการฝึกฝนที่รับรู้การควอนไทซ์ FP4 มาใช้เพื่อเร่งการปรับใช้และประหยัดหน่วยความจำ และปรับแต่งเฟรมเวิร์กการฝึกฝนให้เหมาะสมกับ Muon Optimizer, โครงสร้าง mHC และกลไกความสนใจแบบผสม พร้อมทั้งออกแบบกลยุทธ์การจัดการ KV Cache แบบ Heterogeneous เพื่อเพิ่มประสิทธิภาพการอนุมาน

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

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

unsetunsetสารบัญunsetunset

• คำถามสำคัญ
  • คำถามที่ 1. ไปป์ไลน์แบบละเอียดจะไร้ประสิทธิภาพในแบตช์ขนาดเล็กมากหรือไม่?
  • คำถามที่ 2. สูตร “อัตราส่วนการคำนวณต่อการสื่อสาร” ทำให้ความเป็นจริงง่ายเกินไปหรือไม่?
• หนึ่ง การทับซ้อนการสื่อสาร-การคำนวณแบบละเอียดใน Expert Parallel
  • 1.1 ความหน่วงของการสื่อสารสามารถซ่อนได้
  • 1.2 แผนการ Expert Parallel แบบละเอียด
  • 1.3 ประสิทธิภาพและเคอร์เนลขนาดใหญ่แบบโอเพนซอร์ส
  • 1.4 ข้อสังเกตและข้อเสนอแนะ
• สอง การพัฒนาเคอร์เนลที่ยืดหยุ่นและมีประสิทธิภาพด้วย TileLang
  • 2.1 ลดค่าใช้จ่ายในการเรียกใช้ผ่านการสร้างโค้ดโฮสต์
  • 2.2 การวิเคราะห์จำนวนเต็มเชิงรูปแบบโดยใช้ SMT Solver
  • 2.3 ความแม่นยำเชิงตัวเลขและความสามารถในการทำซ้ำระดับบิต
• สาม ไลบรารีเคอร์เนลที่แน่นอนและไม่แปรผันตามแบตช์ประสิทธิภาพสูง
  • 3.1 ความไม่แปรผันตามแบตช์
  • 3.2 ความแน่นอน
• สี่ การฝึกฝนที่รับรู้การควอนไทซ์ FP4
• ห้า เฟรมเวิร์กการฝึกฝน
  • 5.1 การใช้งาน Muon Optimizer อย่างมีประสิทธิภาพ
  • 5.2 การใช้งาน mHC ที่มีต้นทุนต่ำและใช้หน่วยความจำน้อย
  • 5.3 Context Parallel สำหรับความสนใจบริบทยาว
  • 5.4 การขยาย Automatic Differentiation สำหรับ Flexible Activation Checkpointing
• หก เฟรมเวิร์กการอนุมาน
  • 6.1 โครงสร้างและการจัดการ KV Cache
  • 6.2 การจัดเก็บ KV Cache บนดิสก์
• บทสรุป

unsetunsetคำถามสำคัญunsetunset

คำถามที่ 1. ไปป์ไลน์แบบละเอียดจะไร้ประสิทธิภาพในแบตช์ขนาดเล็กมากหรือไม่?

ผู้เขียนชี้ให้เห็นว่าในสถานการณ์เช่น RL rollout มีปัญหา “แบตช์ขนาดเล็กแบบหางยาว” และใช้สิ่งนี้เป็นข้อได้เปรียบหลักของ Expert Parallel แบบละเอียด อย่างไรก็ตาม ค่าใช้จ่ายในการเริ่มต้นและระบายไปป์ไลน์ที่เกิดจากการจัดตาราง Wave ในแบตช์ที่เล็กมาก จะกลบผลประโยชน์จากการทับซ้อนหรือไม่? เมื่อปริมาณการคำนวณของ Wave เดียวต่ำกว่าความหน่วงในการเริ่มต้นการสื่อสาร อัตราเร่งของแผนการนี้จะลดลงอย่างรวดเร็วหรือไม่ หรือแย่กว่าแผนการแบบหยาบ?

คำตอบคือไม่ มันไม่เพียงแต่จะไม่ไร้ประสิทธิภาพ แต่มันคือเป้าหมายการออกแบบและข้อได้เปรียบที่ใหญ่ที่สุดของแผนการนี้

DeepSeek ระบุอย่างชัดเจนว่าสถานการณ์เช่น RL rollout มีปัญหา “ข้อมูลแบตช์ขนาดเล็กแบบหางยาว” จริง แผนการ Expert Parallel แบบดั้งเดิมเมื่อแบตช์มีขนาดเล็ก สัดส่วนค่าใช้จ่ายในการสื่อสารจะเพิ่มขึ้นอย่างรวดเร็ว เนื่องจากขาดปริมาณการคำนวณที่เพียงพอที่จะซ่อนความหน่วงของการสื่อสาร Expert Parallel แบบละเอียดถูกออกแบบมาเพื่อแก้ปัญหาจุดเจ็บปวดนี้โดยเฉพาะ: มันแบ่งผู้เชี่ยวชาญออกเป็นหลาย Wave แต่ละ Wave มีผู้เชี่ยวชาญเพียงไม่กี่คน เมื่อ Wave หนึ่งสื่อสารเสร็จ การคำนวณของมันสามารถเริ่มต้นได้ทันที โดยไม่ต้องรอ Wave อื่น ในสถานะคงที่ การคำนวณของ Wave ปัจจุบัน การส่ง Token ของ Wave ถัดไป และการส่งคืนผลลัพธ์ของผู้เชี่ยวชาญที่เสร็จแล้ว จะดำเนินการพร้อมกันทั้งสามอย่าง ซึ่งหมายความว่า แม้ในแบตช์ที่เล็กมาก ตราบใดที่ปริมาณการคำนวณของ Wave เดียวเพียงพอที่จะครอบคลุมความหน่วงในการเริ่มต้นการสื่อสาร ไปป์ไลน์ก็สามารถทำงานได้อย่างต่อเนื่อง

ผลการวัดจริงก็สนับสนุนข้อสรุปนี้: แผนการนี้ในสถานการณ์ที่ไวต่อความหน่วง เช่น การอนุมานแบบ Reinforcement Learning และบริการ Agent ความเร็วสูง มีอัตราเร่งสูงสุดถึง 1.96 เท่า ซึ่งสูงกว่าอย่างมีนัยสำคัญเมื่อเทียบกับงานอนุมานทั่วไปที่ 1.50~1.73 เท่า ซึ่งแสดงให้เห็นว่าสถานการณ์แบตช์ขนาดเล็กมากไม่ได้ทำให้ประสิทธิภาพลดลง แต่กลับกัน เนื่องจากมันเผยให้เห็นคอขวดการสื่อสารของแผนการดั้งเดิมได้ชัดเจนยิ่งขึ้น ผลประโยชน์จากการทับซ้อนแบบละเอียดจึงถูกขยายให้ใหญ่ขึ้น ค่าใช้จ่ายในการเริ่มต้นและระบายมีอยู่จริง แต่เนื่องจากจำนวน Wave สัมพันธ์กับจำนวนผู้เชี่ยวชาญทั้งหมด ไม่ใช่ขนาดแบตช์ ดังนั้นในการออกแบบจึงได้ปรับให้เหมาะสมกับโหลดทั่วไปแล้ว

คำถามที่ 2. สูตร “อัตราส่วนการคำนวณต่อการสื่อสาร” ทำให้ความเป็นจริงง่ายเกินไปหรือไม่?

ผู้เขียนให้สูตรในการวิเคราะห์อัตราส่วนการคำนวณต่อการสื่อสารของ MoE ชั้นเดียว (โดยที่ คือปริมาณงานคำนวณสูงสุด คือแบนด์วิธการเชื่อมต่อระหว่างกัน คือมิติกลาง) และสรุปว่าเมื่อแบนด์วิธข้ามเกณฑ์นี้ การสื่อสารจะสามารถซ่อนอยู่ในการคำนวณได้อย่างสมบูรณ์ และไม่เป็นคอขวดอีกต่อไป แต่การ推导นี้【พิจารณา】เฉพาะความเข้มข้นทางคณิตศาสตร์ของชั้น MoE เดียวเท่านั้น ละเลยฟองไปป์ไลน์เมื่อซ้อนหลายชั้น การแข่งขันโทโพโลยีภายในโหนด และการแย่งชิงทรัพยากรบนชิป (เช่น SM, แบนด์วิธหน่วยความจำ) ระหว่างการสื่อสารและการคำนวณโดยสิ้นเชิง ในการฝึกฝนหลายโหนดจริง เกณฑ์ในอุดมคตินี้มีนัยสำคัญในทางปฏิบัติหรือไม่?

สูตรนี้เป็นการ推导ในอุดมคติที่มีสมมติฐานชัดเจน DeepSeek ตระหนักดีถึงสิ่งนี้ และไม่ได้อ้างว่าสามารถครอบคลุมข้อจำกัดในทางปฏิบัติทั้งหมดได้

ประการแรก สูตรนี้มุ่งเน้นไปที่ความสัมพันธ์ระหว่างการสื่อสารและการคำนวณภายในชั้น MoE เดียว เพื่อตอบคำถามเฉพาะ: ภายใต้เงื่อนไขใดที่ความหน่วงของการสื่อสารสามารถซ่อนไว้ในการคำนวณได้อย่างสมบูรณ์? คำตอบชัดเจน – เมื่อแบนด์วิธการเชื่อมต่อระหว่างกันเป็นไปตาม ทุกๆ 1 GBps ของแบนด์วิธสามารถรองรับการคำนวณ 6.1 TFLOP/s และซ่อนการสื่อสารได้ มูลค่าในทางปฏิบัติของข้อสรุปนี้คือการกำหนดกรอบอ้างอิงสำหรับการออกแบบฮาร์ดแวร์ ผู้เขียนระบุทันทีว่า: “เมื่อแบนด์วิธถึงเกณฑ์นี้ มันจะไม่เป็นคอขวดอีกต่อไป การเพิ่มพื้นที่ชิปเพื่อเพิ่มแบนด์วิธต่อไปจะให้ผลตอบแทนส่วนเพิ่มที่ลดลง” ซึ่งแสดงให้เห็นว่าจุดประสงค์ของสูตรไม่ใช่เพื่ออธิบายพฤติกรรมของทั้งระบบ แต่เพื่อกำหนดขอบเขตผลตอบแทนของการลงทุนด้านแบนด์วิธ

ประการที่สอง บทความได้กล่าวถึงปัญหาในทางปฏิบัติที่สูตรไม่ได้ครอบคลุมในหัวข้อ “ข้อสังเกตและข้อเสนอแนะ” โดยเฉพาะ: การจำกัดพลังงานกลายเป็นปัจจัยจำกัดประสิทธิภาพหลักภายใต้โหลดพร้อมกันทั้งหมด การเลือกโหมด Push/Pull ของพรีมิทีฟการสื่อสารส่งผลต่อความหน่วงจริง ชนิดของฟังก์ชันกระตุ้นเปลี่ยนความเข้มข้นทางคณิตศาสตร์ เป็นต้น ซึ่งแสดงให้เห็นว่าผู้เขียนแยกการ推导ในอุดมคติออกจากข้อจำกัดทางวิศวกรรม – สูตรใช้เพื่อกำหนดทิศทางการออกแบบฮาร์ดแวร์ ในขณะที่ปัญหาเช่น การแข่งขันโทโพโลยีและการแย่งชิงทรัพยากรในการปรับใช้จริง จะจัดการผ่านมาตรการทางวิศวกรรม เช่น การรวมเคอร์เนล การจัดตาราง Wave และคำแนะนำงบประมาณพลังงาน ดังนั้น สูตรนี้จึงเป็นเครื่องมือวิเคราะห์ที่ใช้งานได้ในขอบเขตจำกัด ไม่ใช่การทำให้ความซับซ้อนของระบบง่ายขึ้นทั้งหมด

unsetunsetหนึ่ง การทับซ้อนการสื่อสาร-การคำนวณแบบละเอียดใน Expert Parallelunsetunset

โมเดล Mixture of Experts (MoE) สามารถเร่งความเร็วได้ด้วยเทคโนโลยี Expert Parallel (EP) อย่างไรก็ตาม กลไก Expert Parallel อาศัยการสื่อสารระหว่างโหนดที่ซับซ้อน ซึ่งกำหนดข้อกำหนดที่เข้มงวดเกี่ยวกับแบนด์วิธและความหน่วงของการเชื่อมต่อระหว่างกัน เพื่อแก้ปัญหาคอขวดการสื่อสารของ Expert Parallel และบรรลุประสิทธิภาพแบบ end-to-end ที่ดีขึ้นภายใต้ความต้องการแบนด์วิธการเชื่อมต่อระหว่างกันที่ต่ำกว่า DeepSeek-V4 เสนอแผนการ Expert Parallel แบบละเอียด แผนการนี้ผสานการสื่อสารและการคำนวณเข้าเป็นเคอร์เนลไปป์ไลน์เดียว ทำให้ทั้งสองสามารถทับซ้อนกันได้

1.1 ความหน่วงของการสื่อสารสามารถซ่อนได้อย่างมีประสิทธิภาพ

แนวคิดหลักของแผนการ Expert Parallel นี้คือ ความหน่วงของการสื่อสารของชั้น MoE สามารถซ่อนไว้ในกระบวนการคำนวณได้อย่างชาญฉลาด

รูปที่ 5: แผนภาพเปรียบเทียบแผนการ Expert Parallel (EP) ของ DeepSeek-V4 กับงานที่เกี่ยวข้อง แสดงให้เห็นความแตกต่างพื้นฐานของกลยุทธ์การดำเนินการ MoE สามแบบ แผนการแบบดั้งเดิมไม่มีการทับซ้อนระหว่างการสื่อสารและการคำนวณเลย มีประสิทธิภาพต่ำมาก Comet ทำได้เพียงการทับซ้อนแบบหยาบในเฟส การเพิ่มประสิทธิภาพมีจำกัด ในขณะที่ DeepSeek-V4 แบ่งผู้เชี่ยวชาญออกเป็นหลาย Wave เพื่อจัดตารางเวลา ทำให้เกิดไปป์ไลน์พร้อมกันเต็มรูปแบบระหว่างการคำนวณของ Wave ปัจจุบัน การส่งข้อมูลของ Wave ถัดไป และการส่งคืนผลลัพธ์ของผู้เชี่ยวชาญที่เสร็จแล้ว ส่งผลให้ความหน่วงของการสื่อสารถูกกลบด้วยการคำนวณอย่างสมบูรณ์ ในสถาปัตยกรรม DeepSeek-V4-Flash อัตราเร่งตามทฤษฎีของแผนการนี้สูงถึง 1.92 เท่า ซึ่งดีกว่า Comet ที่ 1.42 เท่าอย่างมีนัยสำคัญ ไม่เพียงลดการพึ่งพาแบนด์วิธการเชื่อมต่อระหว่างกัน แต่ยังปรับให้เข้ากับความต้องการประสิทธิภาพของสถานการณ์แบตช์ขนาดเล็กแบบหางยาว เช่น การอนุมานแบบ Reinforcement Learning (RL) ได้เป็นอย่างดี

ดังแสดงในรูปที่ 5 ในโมเดลซีรีส์ DeepSeek-V4 แต่ละชั้น MoE สามารถแบ่งออกเป็นสี่เฟสหลัก: สองเฟสที่ผูกกับการสื่อสาร (การกระจายและการรวม) และสองเฟสที่ผูกกับการคำนวณ (เลเยอร์เชิงเส้นแรกและเลเยอร์เชิงเส้นที่สอง) ผลการวิเคราะห์ประสิทธิภาพระบุอย่างชัดเจนว่า เวลารวมของการสื่อสารภายในชั้น MoE เดียวน้อยกว่าเวลารวมของการคำนวณ ดังนั้น เมื่อการสื่อสารและการคำนวณถูกรวมเป็นไปป์ไลน์เดียว การคำนวณยังคงเป็นคอขวดหลัก ซึ่งหมายความว่าระบบสามารถทนต่อแบนด์วิธการเชื่อมต่อระหว่างกันที่ต่ำกว่าได้โดยไม่ต้องเสียสละประสิทธิภาพแบบ end-to-end

1.2 แผนการ Expert Parallel แบบละเอียด

เพื่อลดความต้องการแบนด์วิธการเชื่อมต่อระหว่างกันลงอีก และขยายผลประโยชน์จากการดำเนินการที่ทับซ้อนกัน DeepSeek-V4 เสนอแผนการแบ่งผู้เชี่ยวชาญที่ละเอียดยิ่งขึ้น โดยได้รับแรงบันดาลใจจากงานวิจัยที่เกี่ยวข้องหลายชิ้น (Aimuyo et al., 2025; Zhang et al., 2025b) DeepSeek-V4แบ่งและจัดตารางผู้เชี่ยวชาญออกเป็นหลาย Wave แต่ละ Wave มีผู้เชี่ยวชาญเพียงไม่กี่คน

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

รูปที่ 5: แผนภาพเปรียบเทียบแผนการ Expert Parallel (EP) ของ DeepSeek-V4 กับงานที่เกี่ยวข้อง

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

1.3 ประสิทธิภาพและเคอร์เนลขนาดใหญ่แบบโอเพนซอร์ส

แผนการ Expert Parallel แบบละเอียดของ DeepSeek-V4 ได้รับการตรวจสอบบนแพลตฟอร์ม NVIDIA GPU[1] และ Huawei Ascend NPU[2]

DeepSeek เปิดซอร์สไลบรารีเคอร์เนลการฝึกฝนภายใน TileKernels: ตั้งแต่ MoE Routing ไปจนถึง Quantization Fusion ทั้งหมดใช้ TileLang

เมื่อเปรียบเทียบกับเส้นฐานแบบ Fusion ที่แข็งแกร่ง แผนการนี้ให้อัตราเร่ง 1.50 ถึง 1.73 เท่าในงานอนุมานทั่วไป และในสถานการณ์ที่ไวต่อความหน่วง เช่น การอนุมานแบบ Reinforcement Learning และบริการ Agent ความเร็วสูง อัตราเร่งสูงสุดถึง 1.96 เท่า DeepSeek-V4 ได้เปิดซอร์สการใช้งานเคอร์เนลขนาดใหญ่บน CUDA ชื่อ MegaMoE ซึ่งเป็นหนึ่งในส่วนประกอบของ DeepGEMM ที่ลิงก์โครงการ: MegaMoE[3]

DeepGEMM #304 วิเคราะห์เบื้องต้น: Mega MoE, FP4 Indexer และการอัปเกรดสถาปัตยกรรมโดยรวม

1.4 ข้อสังเกตและข้อเสนอแนะ

DeepSeek-V4 แบ่งปันข้อสังเกตและประสบการณ์จากกระบวนการวิจัยและพัฒนาเคอร์เนล และเสนอข้อเสนอแนะแก่ผู้ผลิตฮาร์ดแวร์ โดยมีเป้าหมายเพื่อช่วยในการออกแบบฮาร์ดแวร์ที่มีประสิทธิภาพ และบรรลุการทำงานร่วมกันระหว่างซอฟต์แวร์และฮาร์ดแวร์ที่ดีขึ้น:

• อัตราส่วนการคำนวณต่อการสื่อสาร: การทับซ้อนอย่างสมบูรณ์ระหว่างการสื่อสารและการคำนวณขึ้นอยู่กับอัตราส่วนการคำนวณต่อการสื่อสาร ไม่ใช่แค่ขนาดแบนด์วิธเท่านั้น กำหนดให้ปริมาณงานคำนวณสูงสุดคือ และแบนด์วิธการเชื่อมต่อระหว่างกันคือ เมื่อ การสื่อสารสามารถซ่อนได้อย่างสมบูรณ์ โดยที่ แทนปริมาณการคำนวณ และ แทนปริมาณการสื่อสาร สำหรับโมเดล DeepSeek-V4-Pro แต่ละคู่ Token-Expert ต้องการการดำเนินการ FLOP 6hd ครั้ง (รวมถึง SwiGLU gating, up projection, down projection) และต้องการการสื่อสารเพียง 3h ไบต์ (FP8 scatter + BF16 gather) สูตรสามารถย่อได้เป็น: นั่นคือ ทุกๆ 1GBps ของแบนด์วิธการเชื่อมต่อระหว่างกัน สามารถรองรับปริมาณการคำนวณ 6.1TFLOP/s และซ่อนความหน่วงของการสื่อสารได้ เมื่อแบนด์วิธถึงเกณฑ์นี้ มันจะไม่เป็นคอขวดอีกต่อไป การเพิ่มพื้นที่ชิปเพื่อเพิ่มแบนด์วิธต่อไปจะให้ผลตอบแทนส่วนเพิ่มที่ลดลง DeepSeek-V4 แนะนำให้การออกแบบฮาร์ดแวร์ในอนาคตกำหนดเป้าหมายไปที่จุดสมดุลนี้ แทนที่จะเพิ่มแบนด์วิธอย่างไม่มีเงื่อนไข
• งบประมาณพลังงาน: การรวมเคอร์เนลอย่างถึงที่สุดทำให้การคำนวณ หน่วยความจำ และเครือข่ายอยู่ในสถานะโหลดสูงพร้อมกัน การจำกัดพลังงานกลายเป็นปัจจัยจำกัดประสิทธิภาพหลัก DeepSeek-V4 แนะนำให้การออกแบบฮาร์ดแวร์ในอนาคตมีงบประมาณพลังงานสำรองที่เพียงพอสำหรับโหลดงานแบบพร้อมกันทั้งหมดนี้
• พรีมิทีฟการสื่อสาร: แผนการนี้ใช้วิธีการสื่อสารแบบ Pull โดย GPU แต่ละตัวจะอ่านข้อมูลจาก GPU ระยะไกลอย่างแข็งขัน ซึ่งหลีกเลี่ยงความหน่วงในการแจ้งเตือนที่สูงของวิธีการสื่อสารแบบ Push แบบละเอียด ฮาร์ดแวร์ในอนาคตที่มีความสามารถในการส่งสัญญาณข้าม GPU ที่มีความหน่วงต่ำกว่าจะทำให้การสื่อสารแบบ Push เป็นไปได้ ทำให้เกิดรูปแบบการสื่อสารที่เป็นธรรมชาติมากขึ้น
• ฟังก์ชันกระตุ้น: DeepSeek-V4 แนะนำให้ใช้ฟังก์ชันกระตุ้นแบบ element-wise ที่มีต้นทุนต่ำแทน SwiGLU ซึ่งไม่ต้องการการดำเนินการเลขชี้กำลังหรือการหาร ซึ่งจะช่วยลดแรงกดดันในการประมวลผลหลังการคูณเมทริกซ์ได้โดยตรง ภายใต้งบประมาณพารามิเตอร์เดียวกัน การลบ gating projection สามารถขยายมิติกลาง ซึ่งจะช่วยลดความต้องการแบนด์วิธลงอีก

unsetunsetสอง การพัฒนาเคอร์เนลที่ยืดหยุ่นและมีประสิทธิภาพด้วย TileLangunsetunset

ในการใช้งานจริง สถาปัตยกรรมโมเดลที่ซับซ้อนก่อให้เกิดโอเปอเรเตอร์ Torch ATen แบบละเอียดหลายร้อยตัว DeepSeek-V4 ใช้ TileLang (Wang et al., 2026) พัฒนาชุดเคอร์เนลแบบ Fusion เพื่อแทนที่โอเปอเรเตอร์ดั้งเดิมส่วนใหญ่ บรรลุประสิทธิภาพสูงสุดด้วยต้นทุนการวิจัยและพัฒนาที่ต่ำมาก ภาษานี้ยังรองรับการสร้างต้นแบบโอเปอเรเตอร์ เช่น Attention variants อย่างรวดเร็วในขั้นตอนการตรวจสอบ เคอร์เนลเหล่านี้มีบทบาทสำคัญในการวิจัยและพัฒนาสถาปัตยกรรมโมเดล การฝึกฝนขนาดใหญ่ และการปรับใช้การผลิตบริการอนุมานขั้นสุดท้าย

ในฐานะภาษาเฉพาะโดเมน (DSL) TileLang สร้างสมดุลระหว่างประสิทธิภาพการวิจัยและพัฒนาและประสิทธิภาพรันไทม์ รองรับทั้งการพัฒนาที่รวดเร็วและการเพิ่มประสิทธิภาพเชิงลึกซ้ำๆ ในโค้ดเบสเดียวกัน นอกจากนี้ DeepSeek-V4 ยังทำงานร่วมกับชุมชน TileLang อย่างใกล้ชิด เพื่อร่วมกันสร้างกระบวนการพัฒนาเคอร์เนลที่คล่องตัว มีประสิทธิภาพ และเสถียรมากขึ้น

2.1 ลดค่าใช้จ่ายในการเรียกใช้ผ่านการสร้างโค้ดโฮสต์

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

DeepSeek-V4 บรรเทาค่าใช้จ่ายนี้ผ่านการสร้างโค้ดโฮสต์ โดยย้ายตรรกะทางฝั่งโฮสต์ส่วนใหญ่ไปยังโค้ดโฮสต์ที่สร้างขึ้น โดยเฉพาะ:

• DeepSeek-V4 สร้างเคอร์เนลอุปกรณ์และตัวเรียกใช้โฮสต์แบบน้ำหนักเบาร่วมกันในชั้น Intermediate Representation (IR) ก่อน และฝังข้อมูลเมตาที่จำเป็น (เช่น ชนิดข้อมูล ข้อจำกัดอันดับ/รูปร่าง สมมติฐานสไตรด์/เลย์เอาต์) ที่แยกวิเคราะห์จากส่วนหน้าของภาษา
• จากนั้น ตัวเรียกใช้จะถูกคอมไพล์เป็นซอร์สโค้ดโฮสต์ตามเฟรมเวิร์ก TVM-FFI (Chen et al., 2006) ซึ่งข้อตกลงการเรียกที่กะทัดรัดและความสามารถในการทำงานร่วมกันของเทนเซอร์แบบ Zero-copy ช่วยลดค่าใช้จ่ายทางฝั่งโฮสต์ให้เหลือน้อยที่สุด
• ในรันไทม์ โค้ดโฮสต์ที่สร้างขึ้นจะรับผิดชอบการตรวจสอบและห่อหุ้มพารามิเตอร์ โดยย้ายตรรกะการตรวจสอบของการเรียกแต่ละครั้งออกจากเส้นทางการดำเนินการ Python

ผลการทดสอบแสดงให้เห็นว่า ค่าใช้จ่ายในการตรวจสอบทางฝั่ง CPU ลดลงจากหลายสิบถึงหลายร้อยไมโครวินาทีต่อการเรียก ไปเป็นต่ำกว่า 1 ไมโครวินาที

2.2 การวิเคราะห์จำนวนเต็มเชิงรูปแบบโดยใช้ SMT Solver

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

เพื่อการนี้ DeepSeek-V4 ได้ฝัง Z3 SMT Solver (De Moura and Bjørner, 2008) เข้ากับระบบพีชคณิตของ TileLang อย่างราบรื่น ทำให้สามารถวิเคราะห์เชิงรูปแบบสำหรับนิพจน์จำนวนเต็มส่วนใหญ่ในโปรแกรมเทนเซอร์ได้

โดยเฉพาะ DeepSeek-V4 จะแมปนิพจน์จำนวนเต็มของ TileLang เป็นรูปแบบ Quantifier-Free Nonlinear Integer Arithmetic (QF_NIA) ของ Z3 ซึ่งเป็นการหาจุดสมดุลที่ละเอียดอ่อนระหว่างต้นทุนการคำนวณและความสามารถในการแสดงออกเชิงรูปแบบ QF_NIA ที่ใช้ ILP Solver สามารถแก้ปัญหานิพจน์จำนวนเต็มเชิงเส้นมาตรฐานที่พบได้ทั่วไปในเคอร์เนลได้อย่างราบรื่น ในขณะที่กลไกการอนุมานแบบไม่เชิงเส้นในตัวของมันสามารถรับมือกับความท้าทายระดับสูง เช่น การทำเวกเตอร์ของรูปร่างเทนเซอร์ที่แปรผันได้อย่างมีประสิทธิภาพ ภายใต้ข้อจำกัดทรัพยากรที่เหมาะสม Z3 ช่วยเพิ่มประสิทธิภาพการเพิ่มประสิทธิภาพโดยรวมได้อย่างมาก ในขณะที่ควบคุมค่าใช้จ่ายด้านเวลาในการคอมไพล์ให้อยู่ในหลักวินาที การเพิ่มประสิทธิภาพนี้แสดงให้เห็นผลลัพธ์ที่สำคัญในกระบวนการคอมไพล์หลายอย่าง เช่น การทำเวกเตอร์ การแทรกบาเรีย และการลดความซับซ้อนของโค้ด

2.3 ความแม่นยำเชิงตัวเลขและความสามารถในการทำซ้ำระดับบิต

ในสภาพแวดล้อมการผลิต ความถูกต้องและความสามารถในการทำซ้ำของตัวเลขมีความสำคัญไม่น้อยไปกว่าปริมาณงานดิบ ดังนั้น การกำหนดค่าเริ่มต้นของ DeepSeek-V4 คือ ให้ความสำคัญกับความแม่นยำเป็นอันดับแรก: ปิดการเพิ่มประสิทธิภาพทางคณิตศาสตร์แบบเร็วในระดับคอมไพเลอร์ โดยให้การคำนวณโดยประมาณที่ส่งผลต่อความแม่นยำผ่านโอเปอเรเตอร์ส่วนหน้าที่ชัดเจนและเลือกได้ (เช่น T.exp, T.log, T.__sin) เท่านั้น ในทางกลับกัน เมื่อจำเป็นต้องปฏิบัติตามความหมาย IEEE-754 อย่างเคร่งครัด TileLang จะมีฟังก์ชันภายในที่สอดคล้องกับมาตรฐาน IEEE และมีโหมดการปัดเศษที่ชัดเจน (เช่น T.ieee_fsqrt, T.ieee_fdiv, T.ieee_add) เพื่อให้นักพัฒนาสามารถกำหนดพฤติกรรมเชิงตัวเลขได้อย่างแม่นยำ

DeepSeek-V4 ยังบรรลุ ความสามารถในการทำซ้ำระดับบิต โดยมีเป้าหมายเพื่อเปรียบเทียบและตรวจสอบเคอร์เนลกับเส้นฐาน CUDA ที่เขียนด้วยมือ โดยการจัดแนวการลดความซับซ้อนทางพีชคณิตและกฎการคอมไพล์ของ TileLang ให้สอดคล้องกับชุดเครื่องมือ CUDA กระแสหลัก (เช่น NVCC) เพื่อหลีกเลี่ยงความแตกต่างระดับบิตที่ไม่ได้ตั้งใจอันเกิดจากการแปลงโค้ด คำอธิบายประกอบเลย์เอาต์ (เช่น T.annotate_layout) อนุญาตให้ผู้ใช้ล็อคการตัดสินใจในการคอมไพล์ที่เกี่ยวข้องกับเลย์เอาต์ เพื่อให้แน่ใจว่าลำดับการคำนวณและการสะสมสอดคล้องกับการใช้งาน CUDA อ้างอิง ซึ่งจะทำให้ได้เอาต์พุตที่เหมือนกันทุกประการในระดับบิตเมื่อจำเป็น

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

unsetunsetสาม ไลบรารีเคอร์เนลที่แน่นอนและไม่แปรผันตามแบตช์ประสิทธิภาพสูงunsetunset

เพื่อให้บรรลุการฝึกฝนและการอนุมานที่มีประสิทธิภาพ DeepSeek-V4 ได้สร้างชุดเคอร์เนลการคำนวณประสิทธิภาพสูงที่สมบูรณ์ นอกเหนือจากฟังก์ชันพื้นฐานและการเพิ่มประสิทธิภาพการใช้ฮาร์ดแวร์ให้สูงสุดแล้ว เป้าหมายการออกแบบหลักยังรวมถึงการรับประกันความสามารถในการทำซ้ำของการฝึกฝน และการจัดตำแหน่งระดับบิตระหว่างกระบวนการก่อนการฝึกฝน หลังการฝึกฝน และการอนุมาน เพื่อการนี้ DeepSeek-V4 ได้บรรลุ เคอร์เนลที่แน่นอน ไม่แปรผันตามแบตช์ระดับ end-to-end และระดับบิต โดยมีค่าใช้จ่ายด้านประสิทธิภาพต่ำมาก เคอร์เนลเหล่านี้มีความสำคัญอย่างยิ่งต่อการดีบัก การวิเคราะห์เสถียรภาพ และการบรรลุพฤติกรรมหลังการฝึกฝนที่สอดคล้อง

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

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

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

SCAN TO PAY WITH ANY BANK