Mixture of Experts (MoE) 2026 - Kiến trúc Sparse Activation, Expert Routing, Auxiliary-Loss-Free Load Balancing và Serving với Expert Parallelism cho DeepSeek V3, Kimi K2, Qwen3-MoE, MiniMax M2 trong Multi-Agent Production với Redis và ClickHouse

Posted on: 4/15/2026 2:58:21 PM

1. Kỷ nguyên MoE: Khi mô hình dense đụng trần scaling

Trong giai đoạn 2022-2024, hầu hết LLM thương mại đều là kiến trúc dense Transformer: mỗi token đi qua toàn bộ tham số của mô hình. Công thức tăng chất lượng rất đơn giản — cộng thêm tham số và cộng thêm dữ liệu. Nhưng đến cuối 2024, tất cả các lab lớn đều đụng cùng một bức tường: chi phí huấn luyện tăng tuyến tính theo tham số, trong khi chất lượng chỉ tăng theo căn bậc hai. Một mô hình 500B dense cần vài chục nghìn H100 chạy 3 tháng, nhưng chỉ hơn mô hình 100B dense vài điểm MMLU. Thị trường không kham nổi nữa.

Giải pháp không phải mới — Mixture of Experts (MoE) đã được Shazeer và Hinton đề xuất từ 2017, nhưng phải đến cuối 2024 với DeepSeek V3 (671B tổng / 37B active) mới thực sự chứng minh: MoE rẻ hơn, nhanh hơn, và đạt chất lượng GPT-4 class với chi phí huấn luyện chỉ 5.576 triệu USD. Từ đó đến nay, gần như mọi frontier open model đều là MoE: Kimi K2 (1T/32B), Qwen3-235B-A22B, MiniMax M2 (456B/45.9B), GLM-4.6-MoE, dbrx, Granite 4.0, OLMoE. Bài viết này mổ xẻ kiến trúc sparse activation từ góc nhìn System Design: router, expert routing, load balancing, expert parallelism, Multi-Head Latent Attention, serving cost và cách tích hợp với hệ Multi-Agent production.

2. Kiến trúc Sparse MoE: Router, Experts và Gating

Trong một Transformer block thông thường, mỗi token đi qua khối Feed-Forward Network (FFN) với toàn bộ tham số. Ở MoE, FFN được thay bằng một bank gồm N expert — mỗi expert là một FFN độc lập — và một router (thường là linear projection) quyết định mỗi token nên gửi tới những expert nào. Chỉ K expert được kích hoạt (thường K=2 đến K=8), nên số tham số "active" trên mỗi token chỉ là K/N phần của tổng. Thay đổi nhỏ trong kiến trúc nhưng tác động cực lớn: huấn luyện và inference đều chỉ tốn công theo active params, trong khi khả năng lưu trữ tri thức bằng total params.

graph TB
    TOK["Input token"] --> ATTN["Self Attention"]
    ATTN --> RES1["Residual Norm"]
    RES1 --> ROUTER["Router Linear N logit"]
    ROUTER --> TOPK["Top K Gating softmax"]
    TOPK --> E1["Expert 1 FFN"]
    TOPK --> E2["Expert 2 FFN"]
    TOPK --> E8["Expert K FFN"]
    TOPK --> SHARED["Shared Expert luon bat"]
    E1 --> COMB["Weighted combine"]
    E2 --> COMB
    E8 --> COMB
    SHARED --> COMB
    COMB --> RES2["Residual Norm"]
    RES2 --> OUT["Output token"]
    style ROUTER fill:#e94560,stroke:#fff,color:#fff
    style SHARED fill:#4CAF50,stroke:#fff,color:#fff
    style E1 fill:#2196F3,stroke:#fff,color:#fff
    style E2 fill:#2196F3,stroke:#fff,color:#fff
    style E8 fill:#2196F3,stroke:#fff,color:#fff

Hình 1: Một MoE block điển hình — router quyết định top-K expert + một shared expert luôn bật

2.1. Router — Trái tim của MoE

Router là một phép nhân ma trận rất nhỏ: đầu vào là hidden state [d_model], đầu ra là [N] logit tương ứng N expert. Với DeepSeek V3, N=256 routed experts + 1 shared expert, d_model=7168, nên ma trận router chỉ nặng 7168×256 ≈ 1.8M tham số mỗi layer, không đáng kể so với hàng tỉ tham số của expert. Nhưng router quyết định ai đi đâu, và đây là điểm sinh tử: nếu router gửi 90% token vào 5 expert đầu, 251 expert còn lại sẽ không được train đủ, và load imbalance làm mọi thứ chậm đi. Điểm tinh tế là router phải học được cách phân công khối lượng sao cho mỗi expert đều được sử dụng đều, đồng thời phân công có ý nghĩa — token về toán gửi tới "expert toán", token về code gửi tới "expert code".

2.2. Top-K Gating — Công thức tiêu chuẩn

Công thức cơ bản của một MoE layer:

logits = x @ W_router        # [d_model] x [d_model, N] -> [N]
topk_logits, topk_idx = top_k(logits, K)
gate = softmax(topk_logits)  # [K]
output = sum(gate[i] * expert[topk_idx[i]](x) for i in range(K)) + shared_expert(x)

Ba tham số quan trọng: N (số expert), K (số active), và capacity factor. Capacity factor là một nhân tố > 1.0 (thường 1.25) quy định mỗi expert chỉ nhận tối đa (total_tokens / N) * capacity_factor * K token mỗi batch — token vượt quá sẽ bị drop (hoặc bypass qua residual connection). Điều này cần thiết khi triển khai expert parallelism: GPU chứa expert A có bộ nhớ cố định, nếu nhận quá nhiều token thì out-of-memory. Nghệ thuật tinh chỉnh capacity là cân bằng giữa drop rate và bộ nhớ lãng phí.

2.3. Shared Expert — Phát minh của DeepSeek

Trước DeepSeek V2 (2024), mọi MoE đều chỉ có routed expert. Nhưng nhóm DeepSeek quan sát: các token luôn cần một lớp kiến thức "chung" (grammar, tokenizer artifact, thường thức) và routed expert học kém vì router cứ phải "chia phần" kiến thức chung này ra khắp N expert. Giải pháp: thêm shared expert — một expert luôn được kích hoạt cho mọi token — song song với routed experts. Kết quả: routed expert được tự do đặc hoá cho domain cụ thể, còn shared expert gánh phần chung. DeepSeek V3 có 1 shared expert, Qwen3-MoE có 1, GLM-4.6 có 1. Chi phí tính toán tăng rất ít (shared expert chỉ 1 FFN) nhưng chất lượng tăng ~1-2 điểm MMLU.

3. Load Balancing: Từ Auxiliary Loss đến Auxiliary-Loss-Free

Bài toán muôn thuở của MoE: làm sao để N expert đều được dùng? Nếu không có can thiệp, router sẽ hội tụ về trạng thái "router collapse" — chỉ 2-3 expert được chọn, còn lại chết. Lịch sử MoE có ba thế hệ giải pháp.

graph LR
    G1["Gen 1 Auxiliary Loss Switch GShard"] --> G2["Gen 2 Expert Choice Google PaLM 2"]
    G2 --> G3["Gen 3 Auxiliary Loss Free DeepSeek V3"]
    G1 --> A1["Cong them L_balance vao loss"]
    G2 --> A2["Expert chon token thay vi token chon expert"]
    G3 --> A3["Bias b_i cap nhat theo EMA khong cong loss"]
    style G1 fill:#888,stroke:#fff,color:#fff
    style G2 fill:#2196F3,stroke:#fff,color:#fff
    style G3 fill:#4CAF50,stroke:#fff,color:#fff

Hình 2: Ba thế hệ giải pháp load balancing trong MoE

3.1. Auxiliary Loss — Giải pháp truyền thống

Ra đời cùng Switch Transformer (Google 2021) và GShard, công thức là cộng vào main loss một phần phạt tỉ lệ với sum(f_i * P_i), trong đó f_i là tần suất token rơi vào expert i, P_i là trung bình gate probability cho expert i. Khi f_i và P_i cùng lệch cao, loss phạt lớn, router bị ép phân bổ lại. Vấn đề: auxiliary loss làm rối gradient chính — mô hình không tối ưu thuần cho next-token prediction mà còn phải thoả mãn ràng buộc phụ. Mixtral, Llama MoE, Qwen2 MoE, Grok-1 đều dùng công thức này với hệ số α ≈ 0.01.

3.2. Expert Choice — Đảo ngược hướng chọn

Google đề xuất 2022: thay vì mỗi token chọn K expert, mỗi expert chọn top-C token (với C = capacity). Điều kiện load balance được đảm bảo by construction vì mỗi expert chỉ nhận đúng C token. Nhược điểm: một số token có thể bị "bỏ rơi" hoàn toàn (không expert nào chọn), và logic này khó triển khai trong decode mode (sinh từng token). Expert Choice phù hợp với encoder và training, không phù hợp cho autoregressive inference.

3.3. Auxiliary-Loss-Free — Phát minh DeepSeek V3

Giải pháp đột phá năm 2024 của DeepSeek: không thêm loss, không đảo hướng. Thay vào đó, thêm một bias term b_i vào router logit trước khi top-K — nhưng bias này chỉ dùng cho routing, không nhân vào output weight. Công thức:

logits_with_bias = x @ W_router + b    # b la vector [N]
topk_idx = top_k(logits_with_bias, K)
gate = softmax(x @ W_router[topk_idx])  # dung logit khong bias cho gate

Sau mỗi step, b_i được cập nhật offline theo EMA: nếu expert i load quá cao (nhận > average), b_i giảm; load thấp, b_i tăng. Chu trình này không đi qua backward pass nên không làm nhiễu main loss. Kết quả trên DeepSeek V3 là load balance gần hoàn hảo (CV < 0.05) mà MMLU không mất điểm nào. Đây là lý do DeepSeek V3 có thể train với 14.8T token bằng H800 giới hạn — hiệu quả huấn luyện cao đến mức toàn bộ pretraining chỉ tốn 5.576 triệu USD (2.788M GPU hours).

4. Landscape các mô hình MoE 2026

Bức tranh MoE đầu 2026 vô cùng sôi động. Bảng dưới đây liệt kê những mô hình nền tảng quan trọng đang được dùng trong production.

Hai điểm đáng chú ý: (1) tỉ lệ sparsity ngày càng cực đoan — từ Mixtral 8x22B sparsity ~3.6x, đến Qwen3-Next-80B-A3B sparsity ~26x, vượt xa tưởng tượng ban đầu; (2) hybrid attention + MoE đang trở thành xu hướng — MiniMax M2, Granite 4.0, Qwen3-Next đều kết hợp linear attention (Lightning/Mamba/DeltaNet) với global attention để cân bằng throughput và chất lượng long-context.

5. Multi-Head Latent Attention (MLA) — Cặp đôi hoàn hảo của MoE

Một điểm thường bị bỏ qua khi nói về DeepSeek V3: MoE không đứng một mình. DeepSeek phát minh song song một kỹ thuật attention mới gọi là Multi-Head Latent Attention (MLA) để giải quyết bài toán KV cache — vốn là nút thắt cổ chai của serving LLM. MLA nén KV cache xuống còn ~7% so với MHA truyền thống bằng cách chiếu K và V qua một latent vector thấp chiều, sau đó chỉ cache latent này:

# MHA classical
K = x @ W_K  # [seq, d_model] x [d_model, d_head*n_head] -> [seq, d_head*n_head]
V = x @ W_V  # full cache per head
# MLA
c_kv = x @ W_DKV      # [seq, d_model] x [d_model, d_c] -> [seq, d_c] (d_c ≈ 512)
# Khi compute attention:
K = c_kv @ W_UK       # [seq, d_c] x [d_c, d_head*n_head]
V = c_kv @ W_UV
# Chi cache c_kv — nho hon MHA khoang 14 lan

Với DeepSeek V3, KV cache giảm từ ~14GB/1K context xuống ~1GB/1K context ở batch 1, giúp serving 160K context trở nên khả thi trên 8×H100. Kết hợp với MoE giảm compute, DeepSeek V3 đạt ~80 token/s/user với cost per million output token khoảng $1.09 — một trong những điểm rẻ nhất thị trường. Qwen3 và Kimi K2 cũng adopt MLA; MiniMax M2 dùng Lightning Attention — lựa chọn khác nhưng cùng mục tiêu giảm KV cache.

5.1. DSA Sparse Attention — Nâng cấp MLA trong V3.2

DeepSeek V3.2-Exp đi xa hơn một bước với DeepSeek Sparse Attention (DSA): thay vì attend toàn bộ context, mỗi query chỉ attend tới top-K key theo một scoring light-weight (lightning indexer). Kết quả: chi phí attention giảm từ O(L²) xuống O(L·K), cho phép mở rộng context window tới 160K mà không đánh đổi chất lượng nhiều. Kết hợp MoE + MLA + DSA biến V3.2 thành mô hình frontier giá rẻ nhất hiện nay: $0.28/1M input cached, $0.42/1M input, $1.68/1M output.

6. Multi-Token Prediction (MTP) — Speculative decoding tích hợp sẵn

Một nâng cấp đáng chú ý khác của DeepSeek V3 là Multi-Token Prediction — huấn luyện mô hình dự đoán đồng thời D token kế tiếp (D=1 là dense head thông thường, DeepSeek V3 dùng D=1 extra head). Khi inference, hai head chạy song song: main head dự đoán token tiếp theo, MTP head dự đoán token thứ hai. Nếu MTP head đúng (kiểm chứng bằng main head ở bước sau), thì ta đã "tiết kiệm" được một step decode. Về bản chất, đây là speculative decoding built-in — không cần draft model riêng như medusa/eagle.

7. Expert Parallelism: Bài toán serving MoE ở quy mô lớn

Khi triển khai DeepSeek V3 hay Kimi K2 trên cluster GPU, ta không thể replicate toàn bộ model lên mỗi GPU — 671B params cần ~1.3TB memory ở FP16, vượt xa cả H200 (141GB). Giải pháp chuẩn là Expert Parallelism (EP): phân bổ các expert khác nhau lên các GPU khác nhau. Với 256 routed experts và 32 GPU, mỗi GPU chứa 8 expert.

graph TB
    subgraph Client
    CLI["Prompt hon hop"]
    end
    subgraph GPU0
    E0["Expert 0 7"]
    end
    subgraph GPU1
    E1["Expert 8 15"]
    end
    subgraph GPU2
    E2["Expert 16 23"]
    end
    subgraph GPU31
    E31["Expert 248 255"]
    end
    CLI --> DISP["Dispatch routing"]
    DISP -- all_to_all --> E0
    DISP -- all_to_all --> E1
    DISP -- all_to_all --> E2
    DISP -- all_to_all --> E31
    E0 -- combine --> AGG["Weighted sum"]
    E1 -- combine --> AGG
    E2 -- combine --> AGG
    E31 -- combine --> AGG
    AGG --> OUT["Next layer"]
    style DISP fill:#e94560,stroke:#fff,color:#fff
    style AGG fill:#4CAF50,stroke:#fff,color:#fff

Hình 3: All-to-all dispatch và combine trong Expert Parallelism với 32 GPU

7.1. All-to-All Communication — Điểm nghẽn thực sự

Ở mỗi MoE layer, token phải được gửi từ GPU chứa nó sang GPU chứa expert được chọn, chạy expert, rồi gửi ngược về. Phép gửi này gọi là all-to-all — mọi GPU gửi dữ liệu tới mọi GPU khác. Đây là collective communication nặng nhất: bandwidth bị giới hạn bởi link chậm nhất trong cluster. Trên NVLink (900 GB/s), all-to-all nhanh; trên InfiniBand NDR (400 Gb/s), bắt đầu chậm; trên Ethernet, cực kỳ chậm. DeepSeek đã công bố DeepEP — một thư viện expert parallel tối ưu bằng tay cho H800 với NVLink Bridge, giảm latency all-to-all xuống còn 45μs/token (so với 160μs của baseline NCCL).

7.2. EP + DP + TP Hybrid — Kịch bản production

Trên thực tế, ta không dùng EP thuần. Kịch bản tiêu chuẩn của vLLM và SGLang là hybrid:

• EP (Expert Parallelism): 32 GPU chia 256 expert (8 expert/GPU).
• TP (Tensor Parallelism): 8 GPU chia attention layer + dense FFN của shared expert.
• DP (Data Parallelism): Replicate toàn bộ setup 4 lần để tăng throughput.

Với cấu hình này, một DeepSeek V3 cluster cần 32×4 = 128 GPU H200, đạt throughput ~10K token/s/node ở batch 256. vLLM hỗ trợ EP+TP+DP hybrid từ v0.8.0, SGLang v0.3 có expert parallelism optimizer riêng gọi là --enable-ep-moe. TensorRT-LLM từ 0.14 bổ sung MoE plugin với all-to-all từ NCCL 2.24.

7.3. Expert Placement Optimization

Khi 256 expert không đồng đều (một số nhận nhiều token, một số ít), đặt expert vào GPU ngẫu nhiên làm tải GPU không cân. Kỹ thuật expert placement giải quyết bằng cách: chạy warmup vài nghìn request, đo tần suất sử dụng mỗi expert, rồi sắp xếp lại sao cho tổng load trên mỗi GPU xấp xỉ bằng nhau. DeepSeek mở nguồn công cụ expert-placement-scheduler làm việc này offline. Kimi K2 đi xa hơn với online re-sharding — khi phát hiện một GPU quá tải, hệ thống migrate một expert nóng sang GPU mát trong vài giây, không downtime.

8. Serving Engine: vLLM, SGLang, TensorRT-LLM cho MoE

Bảng so sánh các inference engine hỗ trợ MoE trong 2026:

SGLang là lựa chọn được cộng đồng DeepSeek khuyên dùng cho frontier MoE, nhờ tích hợp DeepEP native + RadixAttention prefix cache cực hiệu quả. vLLM đuổi sát với EP+DP hybrid và hệ sinh thái ecosystem lớn nhất. TensorRT-LLM dẫn đầu throughput thuần trên Hopper nhưng trade-off về linh hoạt.

9. Kinh tế học của MoE: FLOPs, Memory, Bandwidth

Ba tài nguyên mà serving MoE phải cân bằng:

Hệ quả thú vị: MoE rẻ hơn dense về compute (FLOPs tương đương 37B dense) nhưng đắt hơn dense về memory (cần hold 671B trong GPU). Cho single-user latency, MoE nhanh như 37B dense. Cho throughput batch lớn, MoE chỉ đạt được tốc độ tối đa khi all-to-all nhanh — nghĩa là cần NVLink, không phải Ethernet.

Công thức cost per million token output có thể xấp xỉ:

cost_per_M_output ≈ (
    active_params * 2 / (gpu_fp16_tflops * utilization)   # compute
  + (total_params * 2 * bytes_per_param) / (total_gpu_hbm * gpu_count)  # memory amortize
  + all_to_all_overhead_per_layer * num_layers              # bandwidth
)

Với DeepSeek V3 trên 8×H200 (NVLink 900GB/s, utilization 40%), cost per million output token là $1.09 — rẻ hơn GPT-4o $10 gần 10 lần, chất lượng tương đương MMLU. Đây là "công thức thần kỳ" của MoE mà frontier dense không thể bắt kịp trừ khi tái kiến trúc.

10. MoE trong hệ Multi-Agent: Routing, Specialization, Cost

Ở tầng thấp hơn hệ Multi-Agent, MoE có ba tác động thú vị cho System Design.

graph TB
    USER["User request"] --> LLMGATEWAY["LLM Gateway"]
    LLMGATEWAY --> AGENT_ROUTER["Agent Router semantic"]
    AGENT_ROUTER --> PLAN["Planner Claude Opus"]
    AGENT_ROUTER --> CODE["Code Agent DeepSeek V3"]
    AGENT_ROUTER --> MATH["Math Agent Kimi K2"]
    AGENT_ROUTER --> CHAT["Chat Agent Qwen3 Next"]
    PLAN --> TOOLS["Tool Use"]
    CODE --> TOOLS
    MATH --> TOOLS
    CHAT --> TOOLS
    TOOLS --> CH["ClickHouse Observability"]
    LLMGATEWAY --> REDIS["Redis Semantic Cache"]
    style AGENT_ROUTER fill:#e94560,stroke:#fff,color:#fff
    style CH fill:#2196F3,stroke:#fff,color:#fff
    style REDIS fill:#4CAF50,stroke:#fff,color:#fff

Hình 4: Multi-Agent system dùng nhiều MoE model chuyên biệt, Redis cho cache và ClickHouse cho trace

10.1. Routing theo chuyên môn của mô hình

Hầu hết các MoE mô hình đều có "sở trường": DeepSeek V3 mạnh code + math, Kimi K2 mạnh agentic + long context, Qwen3-Next mạnh đa ngôn ngữ + tốc độ cực nhanh, MiniMax M2 mạnh multimodal + long context. Một Agent Router ở tầng trên có thể classify request bằng semantic classifier rồi gửi tới MoE backend phù hợp — tương tự bài viết Agent Router & Model Cascading 2026 trên anhtu.dev. Nghiên cứu của RouteLLM, Martian, Notdiamond cho thấy routing thông minh giữa các MoE tiết kiệm 40-60% cost mà không mất chất lượng.

10.2. "Nested MoE" — Khi mỗi sub-agent lại là MoE

Cấp độ cao hơn: hệ Multi-Agent có thể được coi như một MoE ngoài trời — "expert" là các agent chuyên biệt (Code Agent, Research Agent, QA Agent...), "router" là planner LLM, "gate" là confidence score. Tương tự như MoE nội bộ của mô hình, hệ thống này cần load balancing, expert placement, và observability riêng. Điểm khác biệt quan trọng: nested MoE có latency granularity thô hơn (tính bằng giây, không phải microsecond), nên các pattern tối ưu hoá là khác — Redis Streams cho queue, Temporal cho orchestration, ClickHouse cho metric (xem bài Event-Driven Multi-Agent Orchestration 2026).

10.3. ClickHouse cho Expert Utilization Tracking

Khi serving MoE ở quy mô lớn, việc hiểu expert nào đang được dùng cho request nào là critical. SGLang và vLLM đều emit metric per-expert (load, latency, drop rate) qua OpenTelemetry. Schema ClickHouse ví dụ:

CREATE TABLE moe_expert_trace (
    request_id String,
    timestamp DateTime64(3),
    model String,
    layer_idx UInt16,
    expert_idx UInt16,
    token_count UInt32,
    gate_score Float32,
    latency_us UInt32,
    gpu_id UInt8
) ENGINE = MergeTree()
PARTITION BY toYYYYMMDD(timestamp)
ORDER BY (model, layer_idx, expert_idx, timestamp)
TTL timestamp + INTERVAL 14 DAY;

Với schema này, ta có thể chạy query phân tích hot expert:

SELECT expert_idx, sum(token_count) AS tokens,
       avg(latency_us) AS avg_lat, count() AS hits
FROM moe_expert_trace
WHERE model='deepseek-v3' AND timestamp > now() - INTERVAL 1 HOUR
GROUP BY expert_idx ORDER BY tokens DESC LIMIT 20;

Kết quả giúp phát hiện drift: một expert nào đó bỗng nhận 10% traffic (trong khi bình thường 0.4%) — có thể là dấu hiệu của prompt injection dạng adversarial, hoặc drift của input distribution. ClickHouse 24.10 cho phép chạy query này trên hàng tỉ row trong ~150ms nhờ sparse MergeTree index.

10.4. Redis cho Routing Cache

Một tối ưu ít được nói tới: khi input semantic giống với request trước (ví dụ cùng prompt template, chỉ khác tên biến), routing decision ở tầng Agent Router gần như giống hệt. Cache routing decision trong Redis (key = embedding hash, value = model chosen + confidence) có thể tiết kiệm 5-10ms/request và giảm tải lên classifier:

SET routing:{sha256(query_embedding)} "deepseek-v3" EX 3600
HSET routing_meta:{hash} model deepseek-v3 confidence 0.92 chosen_at 1712567890

Redis 8 Vector Sets (xem bài Redis 8 Vector Sets 2026) còn cho phép routing semantic: tìm 1-NN trong tập các "canonical query" đã routing trước, nếu khoảng cách < threshold thì reuse decision. Đây là bản scaled của semantic caching áp vào routing.

11. Thách thức còn tồn đọng của MoE

MoE không phải silver bullet. Vài thách thức kỹ thuật và tổ chức mà team production cần biết.

11.1. Fine-tuning MoE khó hơn dense

LoRA, QLoRA, DoRA trên MoE bị phức tạp hoá bởi sparse activation: một adapter phải apply lên mọi expert để đảm bảo không mất tính toán, trong khi chỉ K/N expert được kích hoạt cho mỗi token. Hiệu quả huấn luyện giảm mạnh. Giải pháp: MoE-specific adapter như MoLoRA (LoRA per expert), AdaMoLE, hoặc chỉ fine-tune shared expert. Kinh nghiệm cộng đồng: fine-tune Qwen3-MoE cần 2-3x compute so với dense Qwen3 cùng active params, và hay bị degradation nếu không tune hyperparameter cẩn thận.

11.2. Quantization khó đều

AWQ, GPTQ, GGUF đều hoạt động trên MoE nhưng kết quả không đều: expert ít được dùng có sample calibration kém, quantize xuống int4 bị mất nhiều accuracy hơn expert hot. Giải pháp của Unsloth và llama.cpp là dynamic quantization — quantize theo per-expert calibration, expert hot giữ fp8, expert cold xuống int4. Công cụ ggml-quant-strategy trong llama.cpp 0.5 làm tự động việc này cho DeepSeek V3 GGUF.

11.3. Training instability

Sparse gradient làm training MoE kém ổn định hơn dense. Loss spike, router collapse, expert imbalance là ba thất bại kinh điển. Kỹ thuật chống: Muon optimizer (Kimi K2) — một bộ optimizer mới được Moonshot công bố 2024, có gradient clip per-expert và dynamic LR scheduling; MuonClip là variant có thêm Q/K projection clipping, giúp huấn luyện ổn định ở scale 1T params. DeepSeek V3 dùng một version customized của AdamW với warm-up routing.

12. Best Practices cho team triển khai MoE production

13. Timeline tiến hoá MoE 2024-2026

14. Kết luận: MoE là kiến trúc mặc định của frontier LLM 2026

Nhìn lại 2024-2026, MoE đi từ một ý tưởng "quirky" được vài lab dùng, trở thành kiến trúc mặc định cho mọi frontier open model. Tiết kiệm 10-20x chi phí training, 5-10x chi phí inference so với dense cùng chất lượng, MoE giải phóng một làn sóng mô hình mới mà các startup AI có thể triển khai trên cluster H100/H200 vừa phải. Đồng thời, nó nâng chuẩn System Design lên một bậc: expert parallelism, all-to-all bandwidth, expert placement, aux-loss-free router, MTP, MLA — tất cả những khái niệm này giờ là kiến thức tối thiểu cho infra engineer làm LLM production.

Đặc biệt với hệ Multi-Agent, MoE cho phép một bức tranh mới: Agent Router ở tầng ngoài chọn giữa nhiều MoE backend chuyên biệt, mỗi MoE lại có router nội bộ chọn expert chuyên sâu hơn nữa. Hai tầng routing này — nested MoE — mở ra hiệu quả chi phí chưa từng có, nhưng đòi hỏi đầu tư nghiêm túc vào observability (ClickHouse), cache (Redis), và gateway (LLM Gateway). Như đã nói trong các bài liên quan trên anhtu.dev, những thành phần hạ tầng này không chỉ là "nice to have" — chúng là xương sống của bất kỳ AI production nào muốn scale ổn định.

Câu hỏi mở cho 2026-2027: dense model có quay lại không, hay MoE sẽ thống trị vĩnh viễn? Gợi ý của các lab là cả hai sẽ cùng tồn tại — dense cho distillation targets và on-device SLM, MoE cho frontier. Nhưng với mỗi kỹ sư System Design, việc nắm chắc nguyên lý MoE hôm nay là khoản đầu tư cao nhất cho skill 2-3 năm tới.

15. Nguồn tham khảo

• DeepSeek-V3 Technical Report (arXiv 2412.19437)
• DeepSeek-V2: A Strong, Economical, and Efficient Mixture-of-Experts Language Model (arXiv 2405.04434)
• DeepSeekMoE: Towards Ultimate Expert Specialization in Mixture-of-Experts Language Models (arXiv 2401.06066)
• Auxiliary-Loss-Free Load Balancing Strategy for Mixture-of-Experts (arXiv 2408.15664)
• DeepEP — Expert Parallel communication library
• Kimi K2 — Moonshot AI frontier open MoE (GitHub)
• Qwen3 — Alibaba Qwen series blog announcement
• Qwen3-Next — Ultra-sparse MoE with Hybrid Attention
• MiniMax M2 — Lightning Attention + MoE hybrid
• OLMoE: Open Mixture-of-Experts Language Models (arXiv 2409.02060)
• Mistral AI — Mixtral of Experts announcement
• Databricks — Introducing DBRX: A New Open LLM
• vLLM — Expert Parallel documentation
• SGLang — MoE backend and EP-MoE documentation
• NVIDIA TensorRT-LLM — Mixture of Experts guide
• ClickHouse — Building LLM observability with ClickHouse
• Outrageously Large Neural Networks: The Sparsely-Gated Mixture-of-Experts Layer (arXiv 1701.06538)
• Mixture-of-Experts with Expert Choice Routing (arXiv 2202.09368)