doanh thu

(github.com/deepseek-ai)

12 điểm bởi xguru 2025-03-02 | 1 bình luận | Chia sẻ qua WhatsApp

Vào cuối tuần công bố mã nguồn mở, họ bất ngờ tung ra one more thing là cái nhìn tổng quan toàn bộ hệ thống và cả chi phí vận hành

Tổng quan hệ thống suy luận DeepSeek-V3/R1

Mục tiêu tối ưu của hệ thống suy luận DeepSeek-V3/R1 là thông lượng cao hơn và độ trễ thấp hơn
Để đạt được điều này, họ tối ưu bằng cách áp dụng Cross-Node Expert Parallelism (EP).
- Tăng thông lượng: EP mở rộng kích thước batch để nâng hiệu quả phép toán ma trận trên GPU và tăng thông lượng.
- Giảm độ trễ: Phân tán các chuyên gia (Expert) trên nhiều GPU để giảm gánh nặng truy cập bộ nhớ trên từng GPU, từ đó hạ độ trễ.
Tuy nhiên, EP cũng làm tăng độ phức tạp của hệ thống:
- Cần giao tiếp liên node: Phải chồng lấp giao tiếp và tính toán để tránh nghẽn cổ chai.
- Sử dụng nhiều node: Cần áp dụng Data Parallelism (DP) và cần cân bằng tải giữa các DP.

Mô hình DeepSeek-V3/R1 chỉ kích hoạt 8 trong 256 chuyên gia ở mỗi layer, nên việc mở rộng kích thước batch là bắt buộc
Khác biệt về mức độ song song giữa giai đoạn Prefill và Decode:
- Giai đoạn Prefill: EP32, DP32 (4 node, mỗi GPU xử lý 9 chuyên gia)
- Giai đoạn Decode: EP144, DP144 (18 node, mỗi GPU xử lý 2 chuyên gia)

Vì EP làm tăng chi phí giao tiếp liên node, họ dùng chiến lược chồng lấp batch kép để giảm chi phí này.
- Giai đoạn Prefill: Chạy xen kẽ hai microbatch để ẩn phần giao tiếp của một batch phía sau phần tính toán của batch còn lại.
- Giai đoạn Decode: Chia layer attention thành hai giai đoạn và dùng pipeline 5 bước để tối đa hóa việc chồng lấp tính toán - giao tiếp.

Để tránh mất cân bằng giữa các GPU và tối đa hóa mức sử dụng tài nguyên, họ áp dụng ba kỹ thuật cân bằng tải.
1. Bộ cân bằng tải Prefill
- Vấn đề: Sự khác biệt về số lượng request và độ dài sequence khiến tải tính toán core-attention và tải truyền dữ liệu bị lệch.
- Mục tiêu:
  - Duy trì cân bằng tải tính toán core-attention giữa các GPU.
  - Cân bằng số lượng token đầu vào trên mỗi GPU.
1. Bộ cân bằng tải Decode
- Vấn đề: Mức sử dụng KVCache khác nhau khiến tải tính toán giữa các GPU không đồng đều.
- Mục tiêu:
  - Duy trì cân bằng mức sử dụng KVCache giữa các GPU.
  - Cân bằng số lượng request trên mỗi GPU.
1. Bộ cân bằng tải Expert-Parallel
- Vấn đề: Tải của một số chuyên gia (Expert) cao hơn làm phát sinh mất cân bằng tính toán giữa các GPU.
- Mục tiêu:
  - Duy trì cân bằng tải tính toán chuyên gia trên từng GPU.

Dịch vụ suy luận DeepSeek-V3/R1 chạy trên H800 GPU và giữ nguyên độ chính xác tính toán như lúc huấn luyện
- FP8: phép toán ma trận và truyền dữ liệu
- BF16: phép toán MLA cốt lõi và truyền kết hợp
Chiến lược vận hành giờ cao điểm và ban đêm
- Ban ngày tải dịch vụ cao, còn ban đêm tải giảm xuống
- Khung giờ cao điểm: dùng tất cả node để chạy dịch vụ suy luận
- Khung giờ thấp tải ban đêm: chuyển một phần node sang phục vụ nghiên cứu và huấn luyện để tận dụng tài nguyên hiệu quả
Thống kê vận hành 24 giờ (UTC+8, 2025-02-27 12:00 PM ~ 2025-02-28 12:00 PM)
- Tổng token đầu vào: 608B (trong đó 342B, tương đương 56.3%, là cache hit của KV cache)
- Tổng token đầu ra: 168B (tốc độ đầu ra trung bình 20~22 token/s)
- Độ dài KVCache trung bình: 4,989 token cho mỗi token đầu ra
- Tốc độ xử lý trên mỗi node H800:
  - Giai đoạn Prefill: 73.7k token/s (bao gồm cache hit)
  - Giai đoạn Decode: 14.8k token/s

Mức sử dụng GPU: 278 node ở thời điểm đỉnh, trung bình 226.75 node (mỗi node gồm 8 GPU H800)
Chi phí thuê GPU: $2/giờ cho mỗi H800 GPU → tổng chi phí vận hành mỗi ngày: $87,072
Nếu giả định tất cả token đều được tính phí thì doanh thu lý thuyết mỗi ngày: $562,027 → tỷ suất lợi nhuận 545%
- (Giá token đầu vào/đầu ra của R1: $0.14M(cache hit), $0.55M(cache miss), $2.19M)
Tuy nhiên, doanh thu thực tế thấp hơn:
- Mức giá của DeepSeek-V3 thấp hơn R1 rất nhiều
- Chỉ một phần dịch vụ được kiếm tiền (bản web và app được cung cấp miễn phí)
- Ban đêm có áp dụng giảm giá tự động

sppappi 2025-03-03

Chỉ hỏi 3 câu là đã đơ luôn..