DeepSeek เปิดเผยโครงสร้างระบบอนุมานของ V3/R1 รวมถึงต้นทุนการดำเนินงาน/รายได้

• ช่วงท้ายของสัปดาห์เปิดซอร์ส ได้มีการเซอร์ไพรส์ปิดท้ายแบบ one more thing ด้วยการเปิดเผยภาพรวมของทั้งระบบและแม้กระทั่ง ต้นทุนการดำเนินงาน

ภาพรวมระบบอนุมาน DeepSeek-V3/R1

หลักการออกแบบระบบ

• เป้าหมายการปรับแต่งของระบบอนุมาน DeepSeek-V3/R1 คือ throughput ที่สูงขึ้นและ latency ที่ต่ำลง
• เพื่อสิ่งนี้ จึงนำ cross-node Expert Parallelism (EP) มาใช้เพื่อเพิ่มประสิทธิภาพ
  • เพิ่ม throughput: EP ขยายขนาดแบตช์เพื่อเพิ่มประสิทธิภาพของการคำนวณเมทริกซ์บน GPU และเพิ่ม throughput
  • ลด latency: กระจาย expert ไปยัง GPU หลายตัวเพื่อลดภาระการเข้าถึงหน่วยความจำของ GPU แต่ละตัว ทำให้ latency ลดลง
• อย่างไรก็ตาม EP ก็เพิ่มความซับซ้อนของระบบด้วย:
  • ต้องมีการสื่อสารข้ามโหนด: ต้องซ้อนการสื่อสารกับการคำนวณเพื่อหลีกเลี่ยงคอขวด
  • ใช้หลายโหนด: ต้องใช้ Data Parallelism (DP) และต้องทำ load balancing ระหว่าง DP

Expert Parallelism (EP) ข้ามโหนดขนาดใหญ่

• โมเดล DeepSeek-V3/R1 เปิดใช้งานเพียง 8 ตัวจาก expert 256 ตัว ในแต่ละเลเยอร์ จึงจำเป็นต้อง ขยายขนาดแบตช์
• ความต่างของความขนานในแต่ละช่วง Prefill และ Decode:
  • ช่วง Prefill: EP32, DP32 (4 โหนด, แต่ละ GPU ประมวลผล expert 9 ตัว)
  • ช่วง Decode: EP144, DP144 (18 โหนด, แต่ละ GPU ประมวลผล expert 2 ตัว)

การซ้อนทับระหว่างการคำนวณกับการสื่อสาร (Computation-Communication Overlapping)

• EP เพิ่มต้นทุนการสื่อสารข้ามโหนด ดังนั้นจึงใช้ กลยุทธ์ double-batch overlap เพื่อลดผลกระทบนี้
  • ช่วง Prefill: สลับรัน microbatch สองชุด เพื่อซ่อนการสื่อสารของแบตช์หนึ่งไว้หลังการคำนวณของอีกแบตช์หนึ่ง
  • ช่วง Decode: แบ่ง attention layer ออกเป็นสองขั้น และใช้ pipeline 5 ขั้น เพื่อเพิ่มการซ้อนทับของการคำนวณ-การสื่อสารให้สูงสุด

การทำ load balancing ที่เหมาะสมที่สุด

• เพื่อป้องกันความไม่สมดุลระหว่าง GPU และเพิ่มการใช้ทรัพยากรให้สูงสุด มีการใช้ เทคนิค load balancing 3 แบบ
• 1. Prefill load balancer
  • ปัญหา: จำนวนคำขอและความยาว sequence ที่ต่างกัน ทำให้ภาระของการคำนวณ core-attention และการส่งข้อมูลไม่สมดุล
  • เป้าหมาย:
    • รักษาสมดุลภาระการคำนวณ core-attention ระหว่าง GPU
    • ทำให้จำนวน input token ต่อ GPU ใกล้เคียงกัน
• 2. Decode load balancer
  • ปัญหา: การใช้ KVCache ที่ต่างกัน ทำให้ภาระการคำนวณระหว่าง GPU แตกต่างกัน
  • เป้าหมาย:
    • รักษาสมดุลการใช้ KVCache ระหว่าง GPU
    • ทำให้จำนวนคำขอต่อ GPU ใกล้เคียงกัน
• 3. Expert-Parallel load balancer
  • ปัญหา: ภาระของ expert บางตัวสูง ทำให้เกิดความไม่สมดุลของการคำนวณระหว่าง GPU
  • เป้าหมาย:
    • รักษาสมดุลภาระการคำนวณของ expert บนแต่ละ GPU

สถิติของระบบอนุมานออนไลน์ DeepSeek

• บริการอนุมาน DeepSeek-V3/R1 ทำงานบน H800 GPU และคงความละเอียดในการคำนวณเช่นเดียวกับตอนฝึก
  • FP8: การคำนวณเมทริกซ์และการส่งข้อมูล
  • BF16: การคำนวณ MLA หลักและการส่งข้อมูลแบบรวม
• กลยุทธ์การดำเนินงานช่วงพีคและช่วงกลางคืน
  • กลางวันมีภาระบริการสูง และกลางคืนภาระจะลดลง
  • ช่วงพีค: ใช้ทุกโหนดเพื่อรันบริการอนุมาน
  • ช่วงโหลดต่ำตอนกลางคืน: เปลี่ยนบางโหนดไปใช้เพื่อการวิจัยและการฝึก เพื่อใช้ทรัพยากรอย่างมีประสิทธิภาพ
• สถิติการดำเนินงาน 24 ชั่วโมง (UTC+8, 2025-02-27 12:00 PM ~ 2025-02-28 12:00 PM)
  • input token รวม: 608B (ในนี้ 342B หรือ 56.3% เป็น KV cache hit)
  • output token รวม: 168B (ความเร็ว output เฉลี่ย 20~22 token/s)
  • ความยาว KVCache เฉลี่ย: 4,989 token ต่อ output token
  • อัตราการประมวลผลต่อ H800 node:
    • ช่วง Prefill: 73.7k token/s (รวม cache hit)
    • ช่วง Decode: 14.8k token/s

การวิเคราะห์ต้นทุนการดำเนินงานและรายได้: อ้างอิงข้อมูล 1 วันของ V3 & R1 ในช่วง UTC+8 02/27/2025 12:00 PM ถึง 02/28/2025 12:00 PM

• การใช้ GPU: ช่วงพีค 278 โหนด, เฉลี่ย 226.75 โหนด (แต่ละโหนดมี H800 GPU 8 ตัว)
• ต้นทุนเช่า GPU: H800 GPU หนึ่งตัว $2/ชั่วโมง → ต้นทุนการดำเนินงานรวมต่อวัน: $87,072
• หากสมมติว่า token ทั้งหมดถูกคิดค่าบริการ รายได้เชิงทฤษฎีต่อวัน: $562,027 → อัตรากำไร 545%
  • (ราคา input/output token ของ R1: $0.14M(cache hit), $0.55M(cache miss), $2.19M)
• อย่างไรก็ตาม รายได้จริงต่ำกว่านี้:
  • ค่าบริการของ DeepSeek-V3 ต่ำกว่า R1 มาก
  • มีเพียงบางส่วนของบริการเท่านั้นที่สร้างรายได้ (การใช้งานผ่านเว็บและแอปให้ใช้ฟรี)
  • มีการใช้ส่วนลดอัตโนมัติในช่วงกลางคืน

5 โอเพนซอร์สที่เปิดเผยผ่าน DeepSeek Open Infra ปิดท้ายด้วย one more thing ชิ้นสุดท้าย

[sppappi]

ถาม 3 คำถามก็แฮงก์ไปเลย..