6.4 Data parallelism và expert parallelism

TP và PP đều cắt một bản sao. Khi thông lượng thiếu mà một bản đã đủ độ trễ, bước đơn giản nhất là mở thêm bản—đó là DP. Với mô hình Dense gần như không còn gì để nói: các bản không nói chuyện với nhau; khó là cân tải.

MoE khác. Trong 671B tham số của DeepSeek-V3, khoảng 97% là routed expert, mỗi token chỉ dùng 8 expert. Expert nằm nguyên trên các card khác nhau (EP); attention hợp hơn khi mỗi card một bản, phục vụ request của chính nó (DP). Ghép lại là bố cục chủ đạo cho suy luận MoE lớn hiện nay. Mục này nói DP trước, rồi giao tiếp EP, đồng bộ và cân tải, cuối cùng là triển khai thật của DeepSeek-V3.

⏰ Độ mới của thông tin: Mô tả vLLM theo tài liệu và mã nguồn v0.32.0 (phát hành 2026-10-18); số liệu DeepEP từ README v1.2.1; triển khai DeepSeek-V3 từ technical report (arXiv 2412.19437).

📑 Mục lục

• 1. DP mô hình Dense: mở thêm cửa hàng
• 2. Vì sao MoE cắt theo expert
• 3. Dispatch và Combine: hai lần All-to-All
• 4. Attention DP + expert EP
• 5. Tải lệch: expert bận nhất quyết nhịp
• 6. Kernel giao tiếp: DeepEP và backend vLLM
• 7. Case: triển khai suy luận DeepSeek-V3
• Tóm tắt
• Danh sách tự kiểm
• Tài liệu tham khảo

---

1. DP mô hình Dense: mở thêm cửa hàng

1.1 Các bản sao không giao tiếp

DP là ẩn dụ “mở thêm cửa hàng” ở mục 6.1: mỗi cửa hàng có đủ bộ bếp, tự tiếp khách. Mỗi bản giữ nguyên mô hình (hoặc cả một nhóm TP/PP), tự lịch trình, tự quản KV Cache.

Trong một forward Dense không có đồng bộ giữa các bản; thông lượng tăng gần tuyến tính theo số bản. Nó không tiết kiệm bộ nhớ; tiền đề là một bản đã vừa.

1.2 Khó là cách chia request

Các bản không nói chuyện, nên cách chia request quyết định kết quả:

• Tải: một bản chất đầy prompt dài thì TTFT tệ trong khi bản khác ngồi không. Gán theo số request “đang chạy + đang xếp hàng” tốt hơn round-robin.
• Prefix cache: KV Cache mỗi bản độc lập. Request dùng chung System Prompt mà rải sang nhiều bản thì mỗi bản tính lại prefix. Đưa request cùng prefix về cùng một bản sẽ nâng hit rate prefix-cache ở chương 2 mục 2.3.

1.3 Hai cách trong vLLM

Với Dense, cách thẳng là vài process vllm serve độc lập phía sau load balancer. Tài liệu vLLM cũng nói vậy cho Dense: chế độ cân tải ngoài chỉ hỗ trợ MoE; Dense nên khởi động instance độc lập, không dùng --data-parallel-*.

Hoặc để vLLM quản:

# Một máy 8 GPU: 4 bản, mỗi bản TP=2, một cổng ngoài
vllm serve $MODEL --data-parallel-size 4 --tensor-parallel-size 2

Khi đó chỉ còn một cổng HTTP. Số process API Server mặc định bằng kích thước DP (ở đây 4); chúng gán request từ hàng đợi running và waiting của từng bản. Lưu ý --max-num-seqs là trần theo từng DP rank, còn --max-num-queued-reqs là toàn dịch vụ; đặt thì quy đổi theo số bản.

---

2. Vì sao MoE cắt theo expert

2.1 Gần như mọi tham số nằm ở expert

Lấy DeepSeek-V3 ($h=7168$, 61 lớp, 3 Dense đầu và 58 MoE cuối, mỗi lớp 256 routed expert cộng 1 shared expert, intermediate của expert là 2048). Một expert là ba ma trận gate, up, down:

$$3\times7168\times2048\approx44\text{M parameters}$$

58 lớp × 256 routed expert ≈ 654B, khoảng 97% của tổng 671B. Mỗi token mỗi lớp chỉ kích hoạt 8, nên tham số kích hoạt là 37B.

Vậy bộ nhớ suy luận MoE gần như là một đống expert phần lớn thời gian nằm không. Cách đặt các expert đó là câu hỏi triển khai chính.

2.2 Vấn đề khi TP-cắt expert

Bước thẳng là TP-cắt mọi expert như FFN Dense. Hai vấn đề:

• Ma trận quá mỏng: intermediate expert vốn chỉ 2048; TP=8 thì mỗi card giữ 256 cột. GEMM nhỏ vậy hiếm khi lấp đầy Tensor Core.
• Mọi card đụng mọi token: mọi expert sống trải trên mọi card, nên dù token chọn expert nào, mọi card cũng tham gia tính và AllReduce.

2.3 EP: mỗi expert nguyên trên một card

EP đảo ý tưởng: không cắt expert; đặt nguyên expert lên các card khác nhau. EP=8 mỗi card giữ 32 expert đầy đủ; EP=32 mỗi card giữ 8.

Với trọng số FP8, routed expert DeepSeek-V3 ở EP=8 khoảng 82 GB mỗi card—H100 80GB không vừa—nên ví dụ EP một node của vLLM dùng H200 hoặc H20; EP=32 thì còn khoảng 20 GB mỗi card.

Cái giá là token phải “đi”: mỗi token tới card sở hữu expert nó chọn, rồi quay về. Đó là ẩn dụ “quầy theo món” ở mục 6.1.

---

3. Dispatch và Combine: hai lần All-to-All

3.1 Luồng dữ liệu trong một lớp MoE

Mỗi lớp MoE có bốn bước:

1. Route: mỗi card chạy Router trên token của mình, lấy top-$k$ expert và trọng số từng token.
2. Dispatch: theo route, copy hidden state của mỗi token $k$ lần và gửi tới card sở hữu các expert đó. Mọi card vừa gửi vừa nhận—một lần All-to-All.
3. Tính expert: mỗi card chạy expert của mình trên token đã nhận.
4. Combine: gửi kết quả về card gốc của token và cộng có trọng số theo route—All-to-All lần nữa.

Hình là EP=4, 8 expert, top-2 mỗi token; màu đánh dấu token đến từ card nào. Trái là token của từng card sau attention; phải là token mỗi card nhận sau Dispatch:

GPU0 nhận 12 bản, GPU3 chỉ 4. Combine chờ mọi card; thời gian lớp này do GPU0 quyết. Mục 5 nói sâu hơn.

3.2 Khối lượng giao tiếp

Khối lượng khứ hồi mỗi token mỗi lớp MoE khoảng $2\times k\times h\times b$. Với DeepSeek-V3, $k=8$, $h=7168$:

Dispatch bằng FP8 là thực hành của DeepSeek-V3 và DeepEP; so với BF16 end-to-end tiết kiệm khoảng một phần tư. Token mà expert đã nằm trên card gốc thì không rời node.

So với TP, giao tiếp EP chỉ xảy ra trên lớp MoE, hai lần mỗi lớp; nhưng khối lượng tỉ lệ với $k$ và traffic là many-to-many không đều, nên áp lực xuyên node cao hơn PP nhiều.

---

4. Attention DP + expert EP

4.1 Vì sao attention dùng DP

Expert đã cắt EP thì attention vẫn cần bố cục. Với mô hình MLA như DeepSeek-V3, TP là giao dịch tệ: mục 6.2 nói MLA cache một latent nén; dưới TP mọi card lưu full latent KV, nên bộ nhớ KV lãng phí tuyến tính theo TP.

DP tránh được: mỗi card giữ một bản trọng số attention đầy đủ, chỉ phục vụ tập request của mình, chỉ lưu KV của các request đó. Trọng số attention chỉ là phần nhỏ của mô hình MoE; vài bản không đắt.

Tài liệu vLLM cũng khuyến nghị vậy: với MoE, đặc biệt DeepSeek dùng MLA, dùng DP cho attention và EP hoặc TP cho expert.

4.2 Kích thước EP là TP × DP

vLLM không có cờ kích thước EP riêng. Với --enable-expert-parallel:

$$\text{EP\_SIZE}=\text{TP\_SIZE}\times\text{DP\_SIZE}$$

Không có --enable-expert-parallel thì lớp MoE mặc định một nhóm TP kích thước TP × DP; mọi expert bị cắt, quay lại vấn đề ở 2.2.

4.3 DP rank không còn độc lập: rank rảnh vẫn chạy

Bản Dense DP mặc kệ nhau; DP rank của MoE phải giữ nhịp. All-to-All cần mọi rank; nếu một card bước này không có request, token card khác gửi tới không có chỗ đáp và nhóm kẹt.

Vì vậy vLLM yêu cầu: miễn còn rank nào còn request đang chạy, rank không có request cũng phải chạy dummy forward và đi cùng mọi giao tiếp lớp MoE với các rank khác. Trong hình GPU3 tạm không có request nhưng vẫn tham gia Dispatch và Combine:

Một process DP Coordinator riêng lo việc này. Nó nói chuyện với mọi rank và vài bước một lần chạy collective xem mọi rank đã rảnh chưa; chỉ khi đó chúng mới dừng cùng nhau. Trong mã nguồn khoảng đó là dp_sync_interval, mặc định 16 bước.

📌 Điểm then chốt: Hai hệ quả. Thứ nhất, request giữa các DP rank nên đều nhất có thể, nếu không card ít request chủ yếu dummy-run. Thứ hai, mọi bước nhóm chờ rank chậm nhất; Prefill dài trên một rank làm chậm Decode trên mọi rank.

4.4 Lệnh khởi động

Một node 8 GPU (ví dụ tài liệu vLLM; cần card bộ nhớ lớn hơn như H200 hoặc H20):

vllm serve deepseek-ai/DeepSeek-V3-0324 \
    --tensor-parallel-size 1 \
    --data-parallel-size 8 \
    --enable-expert-parallel

Mỗi DP rank là một process EngineCore riêng với scheduler và KV Cache riêng, nói với API Server phía trước qua ZMQ. Khởi động đa node nằm ở mục 6.5.

---

5. Tải lệch: expert bận nhất quyết nhịp

5.1 Vì sao tải lệch

Huấn luyện thường thêm aux loss cân tải, hoặc như DeepSeek-V3 dùng bias không aux loss, để số token mỗi expert trên phân phối train gần đều. Traffic suy luận trong một cửa sổ có thể tập trung một domain (ví dụ toàn code); expert nóng khi đó nhận nhiều hơn trung bình xa.

Dưới EP mọi lớp chờ expert compute của mọi card trước khi Combine, nên thời gian lớp do card nhận nhiều token nhất quyết. Chỉ số là “card bận nhất ÷ trung bình”; 1 nghĩa là cân hoàn toàn.

5.2 Mô phỏng thực hành: EP lớn hơn, lệch tệ hơn

Script giả định độ phổ biến expert theo power law (số mũ 0.4 là giả định, không phải mô hình thật nào), route kiểu DeepSeek-V3 256-chọn-8 trên 4096 token một bước, rồi so ba cách đặt:

# Simulate MoE load imbalance: expert popularity ~ power law (assumed),
# compare how much the busiest card exceeds the average under three placements.
# Count tokens only; ignore communication and compute efficiency.
import random

random.seed(0)
EXPERTS, TOP_K, TOKENS = 256, 8, 4096      # DeepSeek-V3-style route: 256 choose 8; 4096 tokens / step
SKEW = 0.4                                  # power-law exponent; 0 is fully even; assumed

weights = [1 / (i + 1) ** SKEW for i in range(EXPERTS)]
random.shuffle(weights)                     # scatter hot experts across IDs
counts = [0] * EXPERTS
for _ in range(TOKENS):
    chosen = set()
    while len(chosen) < TOP_K:              # each token picks 8 distinct experts
        chosen.add(random.choices(range(EXPERTS), weights=weights)[0])
    for e in chosen:
        counts[e] += 1


def contiguous(ep):
    """Default placement: experts assigned to cards in contiguous ID ranges"""
    per = EXPERTS // ep
    load = [sum(counts[g * per:(g + 1) * per]) for g in range(ep)]
    return max(load) / (sum(load) / ep)


def balanced(ep, redundant):
    """Reorder by observed load: give redundant slots to experts with highest
    load-per-replica, then place replicas heaviest-first onto the currently
    lightest card that still has a free slot"""
    replicas = [1] * EXPERTS
    for _ in range(redundant):
        e = max(range(EXPERTS), key=lambda i: counts[i] / replicas[i])
        replicas[e] += 1
    copies = sorted((counts[e] / replicas[e] for e in range(EXPERTS) for _ in range(replicas[e])), reverse=True)
    slots = (EXPERTS + redundant) // ep
    load, used = [0.0] * ep, [0] * ep
    for c in copies:
        g = min((g for g in range(ep) if used[g] < slots), key=lambda g: load[g])
        load[g] += c
        used[g] += 1
    return max(load) / (sum(load) / ep)


avg = TOKENS * TOP_K / EXPERTS
print(f"hottest expert {max(counts)} tokens, coldest {min(counts)}, average {avg:.0f}")
print(f"{'EP':>4} {'experts/GPU':>6} {'contiguous':>7} {'rebalance':>7} {'+1 redun/GPU':>8}")
for ep in [8, 32, 64, 256]:
    print(f"{ep:>4} {EXPERTS // ep:>8} {contiguous(ep):>10.2f}x {balanced(ep, 0):>11.2f}x {balanced(ep, ep):>11.2f}x")

Đầu ra:

hottest expert 640 tokens, coldest 67, average 128
  EP   experts/GPU    contiguous   rebalance   +1 redun/GPU
   8       32       1.14x        1.01x        1.00x
  32        8       1.41x        1.17x        1.00x
  64        4       1.93x        1.64x        1.00x
 256        1       5.00x        5.00x        1.01x

Dưới các giả định này:

• EP lớn hơn, lệch tệ hơn. EP=8 mỗi card 32 expert; nóng và lạnh bù nhau; card bận nhất chỉ hơn trung bình 14%. EP=256 mỗi card 1 expert; 640 token của expert nóng nhất đổ hết lên một card—gấp 5 trung bình.
• Chỉ sắp lại không nhân bản thì EP lớn không giúp. Một expert mỗi card thì không còn chỗ để chuyển; trước và sau sắp lại đều 5.00×.
• Một expert dư mỗi card gần như cân hoàn toàn. Expert nóng có nhiều bản; token chia giữa các bản; card bận nhất nằm trong 1.01× trung bình.

⚠️ Lưu ý: Mô phỏng này sắp lại từ thống kê cùng bước—như thể bạn đã biết route của bước này. Trường hợp lý tưởng. Hệ thống thật chỉ điều chỉnh từ lịch sử gần; traffic đổi thì có độ trễ.

5.3 EPLB: expert dư cộng cân lại định kỳ

Expert Parallel Load Balancer (EPLB) của vLLM là ý “dư + cân lại” ở trên: mỗi forward ghi tải từng expert, định kỳ gán lại expert lên card từ thống kê đó, và expert nóng có thể có thêm bản.

vllm serve deepseek-ai/DeepSeek-V3-0324 \
    --tensor-parallel-size 1 \
    --data-parallel-size 8 \
    --enable-expert-parallel \
    --enable-eplb \
    --eplb-config '{"window_size":1000,"step_interval":3000,"num_redundant_experts":8,"log_balancedness":true}'

Vài điểm:

• --enable-eplb phải đi với --enable-expert-parallel, không thì khởi động lỗi.
• Có dư thì số expert mỗi card là $(\text{total experts}+\text{redundant})/\text{EP}$. Lệnh trên là $(256+8)/8=33$.
• Expert dư tốn bộ nhớ. Theo ước lượng vLLM, thêm một expert mỗi card DeepSeek-V3 cần khoảng 2.4 GB, khớp phép tính 2.1: 58 lớp × 44M params ≈ 2.55 GB FP8 (2.4 GiB). Cân nhắc khi chỗ KV chật.
• Triển khai đa node lớn, tài liệu vLLM gợi ý num_redundant_experts 32 để expert nóng luôn có bản dự phòng.

💡 Mẹo: Bật log_balancedness một lúc trước, rồi mới quyết có dư và dư bao nhiêu. Balancedness đã gần 1 thì expert dư chỉ phí bộ nhớ.

---

6. Kernel giao tiếp: DeepEP và backend vLLM

6.1 Hai họ kernel của DeepEP

DeepEP mã nguồn mở của DeepSeek là thư viện giao tiếp viết cho MoE Dispatch/Combine. Nó có hai họ kernel cho Prefill và Decode:

• Normal Kernel: ưu tiên thông lượng. Traffic xuyên node đi RDMA tới node đích, rồi NVLink trong node, nên traffic liên node được gộp tối đa. Phù hợp Prefill với message lớn hàng nghìn token.
• Low-latency Kernel: ưu tiên độ trễ. Thuần RDMA, thân thiện CUDA Graph; chồng compute/comm qua hook mà không chiếm SM. Phù hợp Decode với message nhỏ vài chục đến vài trăm token mỗi bước.

Số liệu README DeepEP v1.2.1 (H800, mỗi GPU một NIC CX7 400 Gb/s):

Setup là hidden 7168, top-8, Dispatch FP8, Combine BF16. Độ trễ low-latency từ EP=64 lên EP=256 chỉ tăng khoảng 20 µs (Dispatch) và 50 µs (Combine)—tiền đề cho EP lớn ở Decode.

6.2 Backend All-to-All của vLLM

vLLM chọn triển khai giao tiếp EP bằng --all2all-backend. Các lựa chọn thường gặp trong tài liệu:

Backend DeepEP cần cài DeepEP và DeepGEMM trước. Tài liệu cũng ghi hai họ DeepEP thiết kế cho tách PD; Prefill+Decode lẫn có thể kém. Triển khai tách PD thì instance Prefill dùng deepep_high_throughput, instance Decode dùng deepep_low_latency (chương 7).

Cờ liên quan là --enable-dbo (Dual Batch Overlap): tách một batch thành hai để một bên All-to-All trong khi bên kia tính, giấu giao tiếp sau tính toán—cùng ý tưởng chồng dual micro-batch trong case DeepSeek-V3 dưới đây.

⚠️ Lưu ý: Backend cũ pplx và naive đã biến mất ở v0.32.0; đặt chúng sẽ cảnh báo và fallback về allgather_reducescatter. Tutorial cũ trên mạng vẫn còn nhắc chúng.

---

7. Case: triển khai suy luận DeepSeek-V3

Technical report DeepSeek-V3 công bố bố cục suy luận online—một tổ hợp đầy đủ các mảnh của mục này. Prefill và Decode triển khai tách (tách PD) với mức song song khác nhau:

Các điểm map ngược:

• Prefill EP nhỏ, Decode EP lớn. Prefill xử lý nhiều token cùng lúc; mọi expert có đủ việc; EP32 đủ. Decode mỗi bước ít token; EP320 cho mỗi card một expert, mỗi card đọc ít trọng số expert nhất và cắt độ trễ mỗi bước. Khớp số liệu DeepEP Low-latency ở trên: EP từ 64 lên 256 gần như không tăng độ trễ Dispatch.
• Expert dư lấy từ thống kê tải. Prefill chọn expert tải cao để dư từ thống kê online và chỉnh lại khoảng mỗi 10 phút. Đó là việc EPLB ở 5.3 làm.
• Shared expert coi như routed. Ở Decode shared expert là routed bắt buộc chọn, nên mỗi token thực tế chọn 9 expert.
• Attention là TP4 + DP, không thuần DP. Report chỉ nói TP nhỏ như 4 giới hạn chi phí giao tiếp TP; không giải thích vì sao không thuần DP. Cách đọc hợp lý: nhóm TP4 đủ nhỏ để nằm trong node, đồng thời cắt trọng số và tính attention mỗi card.

⚠️ Lưu ý: Đây là stack suy luận riêng của DeepSeek trên H800, không phải mặc định vLLM. Với vLLM bạn có thể ghép --data-parallel-size, --enable-expert-parallel, --all2all-backend và EPLB theo cùng hướng, nhưng số cụ thể cần số GPU của bạn và tải đã đo.

---

📝 Tóm tắt

• DP nhân bản nguyên. Bản Dense không giao tiếp; khó là gán request. --max-num-seqs là theo từng DP rank.
• Gần như mọi tham số MoE nằm ở routed expert (≈97% với DeepSeek-V3). TP-cắt expert xé mỏng ma trận; EP đặt mỗi expert nguyên trên một card.
• EP làm hai All-to-All mỗi lớp MoE: Dispatch gửi token tới card expert, Combine trả về và cộng có trọng số; khối lượng khứ hồi mỗi token mỗi lớp ≈ $2kh b$.
• Bố cục MoE phổ biến là attention DP + expert EP; trong vLLM kích thước EP = TP × DP. Mọi DP rank phải giữ nhịp; rank rảnh vẫn dummy-run.
• Thời gian lớp do card nhận nhiều token nhất quyết; EP lớn hơn làm lệch tệ hơn. EPLB dùng expert dư và cân lại định kỳ với cái giá bộ nhớ.
• DeepEP Normal Kernel phù hợp Prefill; Low-latency Kernel phù hợp Decode—khớp deepep_high_throughput và deepep_low_latency của vLLM.

🎯 Danh sách tự kiểm

• Nói được khác biệt Dense DP và MoE DP, và vì sao MoE cần dummy-run
• Tính được số tham số một expert DeepSeek-V3, tỉ trọng routed expert, và trọng số expert mỗi card ở một EP cho trước
• Viết được khối lượng Dispatch và Combine mỗi token mỗi lớp, và lợi ích của Dispatch FP8
• Giải thích được vì sao attention MLA thích DP hơn TP
• Tính được kích thước EP vLLM từ TP và DP, và số expert mỗi card sau khi dư
• Giải thích được vì sao EP lớn làm lệch tải tệ hơn, và vì sao expert dư thắng chỉ sắp lại
• Chọn được --all2all-backend vLLM riêng cho Prefill và Decode đa node

📚 Tài liệu tham khảo

• GShard: Scaling Giant Models with Conditional Computation and Automatic Sharding
• Switch Transformers: Scaling to Trillion Parameter Models with Simple and Efficient Sparsity
• DeepSeek-V3 Technical Report
• DeepEP (v1.2.1)
• vLLM docs: Data Parallel Deployment
• vLLM docs: Expert Parallel Deployment
• vLLM source: vllm/config/parallel.py (v0.32.0)