Thiết kế MoE · granular experts, shared và lịch layer

1Định nghĩa

Khi thiết kế một mô hình Mixture of Experts (MoE) hiện đại, kỹ sư không chỉ chọn tổng số chuyên gia mà phải cấu hình chi tiết cách chia nhỏ và định tuyến chúng. Xu hướng chủ đạo hiện nay (như ở DeepSeek-V3 hay Qwen) là Fine-grained MoE kết hợp Shared Experts: chia mạng FFN thành rất nhiều chuyên gia kích thước nhỏ để tăng số tổ hợp chuyên môn hóa, đồng thời tách riêng một vài chuyên gia cố định luôn chạy cho mọi token nhằm gánh phần tri thức phổ thông.

Một thách thức lớn khi huấn luyện MoE là hiện tượng sập định tuyến (routing collapse — cổng router dồn mọi token vào vài chuyên gia quen thuộc, bỏ đói các nhánh còn lại). Thay vì cộng thêm hàm phạt phụ (auxiliary loss) dễ làm giảm chất lượng mô hình, các kiến trúc mới dùng độ lệch cân bằng tải tự điều chỉnh (auxiliary-loss-free load balancing bias) cộng trực tiếp vào điểm chọn chuyên gia để giữ lưu lượng đồng đều giữa các worker GPU.

Ví dụ đời thường: Thiết kế Fine-grained MoE kèm Shared Experts giống như cách tổ chức một đội ngũ kỹ sư phần mềm: có một nhóm kỹ sư nền tảng luôn tham gia mọi dự án để lo phần khung chung (shared experts), kết hợp với hàng chục chuyên gia phụ trách từng mảng nhỏ chuyên sâu (fine-grained routed experts), cùng một bảng điều phối công việc tự động giữ cho không chuyên gia nào bị quá tải đơn hàng.

2Luồng

flowchart TD
  step1["Đọc router và lịch layer"]
  step2["Dispatch tới expert"]
  step3["Combine output"]
  step1 --> step2
  step2 --> step3

Luồng mô tả cơ chế hoặc quy trình kiểm tra. Các ví dụ số là giả định giáo dục; demo Atlas không chạy kiến trúc production này.

3Giải pháp

Công thức N×3dm và k×3dm chỉ áp experts SwiGLU đồng kích thước. Với shared count s cùng kích thước, cộng s×3dm vào cả total và active; attention/router/embedding tính riêng.

So Qwen3 MoE không shared với DeepSeekMoE có shared và thiết kế Llama 4 xen dense/MoE. GPT-oss dùng expert ít/lớn hơn những thiết kế rất fine-grained; không suy chuyên gia học chủ đề do tên model.

Grok 2.5 có nhánh always-on cùng experts; cần đọc config/code trước khi gộp nó vào shared expert count tiêu chuẩn. Thay đổi k hoặc capacity lúc serving có thể làm lệch model.

4Profiling

• Expert utilization

  Đếm token và FLOPs theo expert, imbalance, drop/padding; không chỉ histogram số request.

• Communication

  Đo dispatch/combine, bytes và thời gian expert kernels ở cùng batch/EP topology.

Mẹo đo lường: ghim số liệu trên workload thật, ghi cả p50/p95/p99 thay vì chỉ trung bình, và luôn ghi lại điều kiện chạy (batch, cache, đồng thời, phần cứng) trước và sau khi tối ưu. Số đo thiếu điều kiện chạy thì không so sánh được.

5Ví dụ

6Thuật ngữ

Granularity

Kích thước một expert và số expert cùng được chọn.

Shared expert

Nhánh luôn tính cho mọi token, cần cộng riêng vào active parameters.

7Bài liên quan

8Nguồn