MoE 模型服务概念指南

当前版本：vLLM v0.18+ / v0.19.x（2026-04 基准）

创建日期：2025-02-09 | 修改日期：2026-04-06 | 阅读时间：约 6 分钟

概述

Mixture of Experts（MoE）模型是最大化大规模语言模型效率的架构。仅激活部分 Expert，以比 Dense 模型更少的计算达到同等质量。

本文档涵盖 MoE 架构核心概念、各模型资源需求、分布式部署策略。

实战部署指南

MoE 模型的 EKS 部署 YAML、helm 命令、多节点配置等实战部署请参阅 自定义模型部署指南。

---

MoE 架构理解

Expert 网络结构

MoE 模型由多个"Expert"网络和选择它们的"Router（Gate）"网络组成。

路由机制

MoE 模型的核心是根据输入 Token 选择合适 Expert 的路由机制。

MoE 路由机制

🎯Top-K Routing

说明

仅激活前 K 个 Expert

代表模型

Mixtral (K=2)

🔄Expert Choice

说明

Expert 选择要处理的令牌

代表模型

Switch Transformer

⚖️Soft MoE

说明

将权重分配给所有 Expert

代表模型

Soft MoE

#️⃣Hash Routing

说明

基于哈希的确定性路由

代表模型

Hash Layers

路由工作原理

1. Gate 计算：将输入 Token 的 hidden state 通过 Gate 网络
2. Expert 选择：从 Softmax 输出中选择 Top-K Expert
3. 并行处理：选中的 Expert 并行处理输入
4. 加权求和：用 Gate 权重组合 Expert 输出

MoE vs Dense 模型对比

MoE vs Dense 模型比较

特性

Dense 模型

MoE 模型

⚡

参数激活

100%（全部）

10-25%（部分 Expert）

🔢

推理计算量

高

相对较低

💾

内存需求

与参数数量成正比

需要加载全部参数

📚

学习效率

标准

使用更多数据进行高效学习

📈

可扩展性

线性增长

通过添加 Expert 高效扩展

MoE 模型的优势

• 计算效率：仅激活部分参数提升推理速度
• 可扩展性：通过添加 Expert 扩展模型容量
• 专业化：各 Expert 可特化于特定领域/任务

---

GPU 内存需求

MoE 模型虽然激活参数少，但需要将全部 Expert 加载到内存。

MoE 模型 GPU 内存需求

模型	总参数	活跃参数	FP16 内存	INT8 内存	推荐 GPU
Mixtral 8x7B	46.7B	12.9B	~94GB	~47GB	2x A100 80GB
Mixtral 8x22B	141B	39B	~282GB	~141GB	4x H100 80GB
DeepSeek-V3	671B	37B	~800GB*	~400GB*	8x H100 80GB
DeepSeek-MoE 16B	16.4B	2.8B	~33GB	~17GB	1x A100 40GB
Qwen2.5-MoE-A14B	~50B	14B	~100GB	~50GB	2x A100 80GB
Qwen1.5-MoE-A2.7B	14.3B	2.7B	~29GB	~15GB	1x A100 40GB
DBRX	132B	36B	~264GB	~132GB	4x H100 80GB
GLM-5	744B	40B	~1.5TB	~744GB	2x p5.48xlarge (PP=2)
Kimi K2.5	~1T	32B	~2TB	~500GB	1x p5.48xlarge (INT4)

最新 MoE 模型内存优化

DeepSeek-V3：使用 Multi-head Latent Attention（MLA）架构显著减少 KV 缓存内存。比传统 MHA 约节省 40% 内存，实际内存需求可能低于标称值。

GLM-5（2026 年 2 月发布）：744B 总参数 / 40B 激活，256 个 experts 中激活 8 个。SWE-bench Verified 77.8%，Agentic Coding 第 1 名（55.00），MIT 许可。FP8 量化版需要约 744GB VRAM（2x p5.48xlarge，PP=2）。HuggingFace：zai-org/GLM-5-FP8

Kimi K2.5（2026 年 1 月发布）：约 1T 总参数 / 32B 激活，Modified DeepSeek V3 MoE 架构。SWE-bench Verified 76.8%，HumanEval 99%，Agent Swarm 支持。INT4 量化版需要约 500GB VRAM（1x p5.48xlarge，TP=8）。HuggingFace：moonshotai/Kimi-K2.5

准确内存需求取决于批大小和序列长度，建议进行分析。

内存计算注意事项

• KV Cache：根据批大小和序列长度需要额外内存
• Activation Memory：推理中存储中间激活值的空间
• CUDA Context：每 GPU 约 1-2GB CUDA 开销
• Safety Margin：实际运营建议预留 10-20% 余量

---

分布式部署策略

大规模 MoE 模型无法加载到单个 GPU，分布式部署是必须的。

MoE 模型并行化策略

🔷

Tensor Parallelism (TP)

说明

在 GPU 之间分割层内张量

优点

✓ 低延迟

缺点

✗ 高通信开销

🎯

Expert Parallelism (EP)

说明

在 GPU 之间分布 Expert

优点

✓ 针对 MoE 优化

缺点

✗ 需要 All-to-All 通信

📊

Pipeline Parallelism (PP)

说明

在 GPU 之间顺序分割层

优点

✓ 内存高效

缺点

✗ 出现管道气泡

Tensor Parallelism 配置

张量并行将模型各层分割到多个 GPU。

vLLM Tensor Parallelism 推荐配置

模型

推荐 TP 大小

GPU 配置

内存/GPU

Mixtral 8x7B

2

2x A100 80GB

~47GB

Mixtral 8x22B

4

4x H100 80GB

~70GB

DeepSeek-MoE 16B

1

1x A100 40GB

~33GB

DBRX

4-8

4-8x H100 80GB

~33-66GB

张量并行优化

• 利用 NVLink：使用支持 NVLink 的实例实现 GPU 间高速通信
• TP 大小选择：根据模型大小和 GPU 内存选择最小 TP
• 通信开销：TP 越大 All-Reduce 通信越多

Expert Parallelism

Expert 并行将 MoE 模型的 Expert 分布到多个 GPU。vLLM v0.6+ 中 Expert 在 TP 内自动分布放置。

Expert 激活模式

MoE 模型性能优化需要理解 Expert 激活模式。

Expert 负载均衡

• Auxiliary Loss：训练时引导 Expert 间均匀分配的辅助损失
• Capacity Factor：限制每个 Expert 可处理的最大 Token 数
• Token Dropping：容量超出时丢弃 Token（推理时建议禁用）

700B+ MoE 模型多节点部署概念

GLM-5、Kimi K2.5 等 700B+ MoE 模型无法加载到单节点，多节点部署是必须的。vLLM v0.18+ 支持基于 LeaderWorkerSet（LWS） 的多节点部署。

模型	总参数	激活参数	推荐配置	VRAM 需求
GLM-5 FP8	744B	40B	2x p5.48xlarge, PP=2, TP=8	~744GB
Kimi K2.5 INT4	~1T	32B	1x p5.48xlarge, TP=8	~500GB
DeepSeek-V3	671B	37B	2x p5.48xlarge, PP=2, TP=8	~671GB
Mixtral 8x22B	141B	39B	1x p5.48xlarge, TP=4	~282GB
Mixtral 8x7B	47B	13B	1x p4d.24xlarge, TP=2	~94GB

700B+ MoE 模型部署建议

• 使用 LeaderWorkerSet：无 Ray 依赖的 Kubernetes 原生多节点部署
• Pipeline Parallelism：PP=2 以上跨节点分割层
• FP8 量化：节省内存（推荐 GLM-5 FP8 版本）
• 网络优化：通过 NCCL 设置优化节点间通信（推荐 EFA）
• INT4/AWQ 量化：可单节点部署时考虑（Kimi K2.5）

多节点部署注意事项

• 网络带宽：节点间 All-Reduce 通信开销（推荐 EFA）
• 加载时间：700B+ 模型初始加载可能需要 20-30 分钟
• 内存余量：需要 10-15% Safety margin
• LeaderWorkerSet CRD：集群需安装 LWS Operator

---

vLLM MoE 服务功能

vLLM v0.18+ 为 MoE 模型提供以下优化：

• Expert Parallelism：多 GPU 分布 Expert
• Tensor Parallelism：层内张量分割
• PagedAttention：高效 KV Cache 管理
• Continuous Batching：动态批处理
• FP8 KV Cache：2 倍内存节省
• Improved Prefix Caching：400%+ 吞吐量提升
• Multi-LoRA Serving：单一基础模型上同时服务多个 LoRA 适配器
• GGUF Quantization：支持 GGUF 格式量化模型

TGI 进入维护模式

Text Generation Inference（TGI）从 2025 年开始进入维护模式。新部署请使用 vLLM。 从 TGI 迁移时 vLLM 提供 OpenAI 兼容 API，客户端代码变更最小化。

vLLM vs TGI 性能对比

vLLM vs TGI 性能比较

特性

vLLM 推荐

TGI (旧版参考)

⚡

吞吐量 (tokens/s)

高

中上

⏱️

延迟 (TTFT)

低

中等

💾

内存效率

非常高 (PagedAttention)

高

🎯

MoE 优化

优秀

良好

🔢

量化支持

AWQ, GPTQ, SqueezeLLM

AWQ, GPTQ, EETQ

🔌

API 兼容性

OpenAI 兼容

自定义 API + OpenAI 兼容

👥

社区

活跃

活跃

---

AWS Trainium2 MoE 推理

Trainium2 概述

AWS Trainium2 是 AWS 设计的第 2 代 ML 加速器，提供比 GPU 更高性价比的推理。

主要特点：

• 高性能：单个 trn2.48xlarge 可推理 Llama 3.1 405B
• 成本效率：比 GPU 最高节省 50%
• NeuronX SDK：支持 PyTorch 2.5+，最少代码变更即可上手
• NxD Inference：简化大规模 LLM 部署的 PyTorch 库
• FP8 量化：提升内存效率
• Flash Decoding：支持 Speculative Decoding

GPU vs Trainium2 成本对比

AWS Trainium2 实例类型

trn2.48xlarge

16

512GB

800 Gbps

Mixtral 8x7B、Llama 3.1 70B

trn2.48xlarge (UltraServer)

32

1TB

1600 Gbps

Mixtral 8x22B、Llama 3.1 405B

GPU vs Trainium2 成本比较

配置

实例

每小时成本

月成本 (730h)

相对成本

🎮

GPU (NVIDIA)

p5.48xlarge (8x H100)

$98.32

$71,774

100%

🎮

GPU (NVIDIA)

p4d.24xlarge (8x A100)

$32.77

$23,922

33%

⚡

Trainium2

trn2.48xlarge (16 cores)

$21.50

$15,695

22%

💡

成本节약효果： Trainium2 相比 H100 GPU 节省 78%，相比 A100 GPU 节省 34%

Trainium2 推荐使用场景

• 成本优化：需要比 GPU 节省 50% 以上
• 大规模部署：运营数十~数百推理端点
• 稳定工作负载：稳定性和成本比实验性功能更重要的生产环境
• AWS 原生：偏好 AWS 生态内完全托管方案

Trainium2 限制

• 模型支持：并非所有模型都支持，需确认 NeuronX SDK 兼容性
• 自定义内核：部分自定义 CUDA 内核需要移植到 Neuron
• 调试：比 GPU 调试工具有限
• 区域可用性：仅在部分 AWS 区域可用

---

性能优化概念

KV Cache 优化

KV Cache 是对推理性能有重大影响的核心要素。

vLLM KV Cache 配置参数

💾

--gpu-memory-utilization

说明

GPU 内存使用比例

推荐值

0.85-0.92

📏

--max-model-len

说明

最大上下文长度

推荐值

模型支持范围内

🔢

--max-num-batched-tokens

说明

每批次最大令牌数

推荐值

根据内存调整

✅

--enable-chunked-prefill

说明

启用 Chunked Prefill

推荐值

推荐

Speculative Decoding

Speculative Decoding 使用小型 Draft 模型提升推理速度。

Speculative Decoding 效果

• 速度提升：1.5x - 2.5x 吞吐量增加（因工作负载而异）
• 质量维持：输出质量相同（通过验证过程保证）
• 额外内存：需要 Draft 模型的额外 GPU 内存

批处理优化

批处理优化技术

🔄

Continuous Batching

说明

动态添加/删除批次中的请求

效果

吞吐量提高 2-3 倍

⚡

Chunked Prefill

说明

将 Prefill 分块以与 Decode 并行

效果

延迟降低

🎯

Dynamic SplitFuse

说明

Prefill/Decode 动态分离

效果

GPU 利用率提高

---

监控指标

主要监控指标

MoE 模型主要监控指标

vllm:num_requests_running

当前处理中的请求数

-

信息

vllm:num_requests_waiting

等待中的请求数

> 100 警告

警告

vllm:gpu_cache_usage_perc

KV Cache 使用率

> 95% 警告

危险

vllm:avg_prompt_throughput_toks_per_s

提示吞吐量

-

信息

vllm:avg_generation_throughput_toks_per_s

生成吞吐量

-

信息

DCGM_FI_DEV_GPU_UTIL

GPU 使用率

> 90% 警告

警告

DCGM_FI_DEV_FB_USED

GPU 内存使用量

> 95% 危险

危险

核心告警标准：

指标	阈值	严重度	说明
P95 响应延迟	大于 30 秒	Warning	MoE 模型响应延迟
KV Cache 使用率	大于 95%	Critical	可能拒绝新请求
等待请求数	大于 100	Warning	需要扩容

---

总结

核心要点

1. 架构理解：掌握 Expert 网络和路由机制的工作原理
2. 内存规划：需要加载全部 Expert，确保充足 GPU 内存
3. 分布式部署：合理组合张量并行和 Expert 并行
4. 推理引擎选择：推荐 vLLM（最新优化技术及活跃更新）
5. 性能优化：应用 KV Cache、Speculative Decoding、批处理优化

下一步

• GPU 资源管理 - GPU 集群动态资源分配
• Inference Gateway 路由 - 多模型路由策略
• Agentic AI 平台架构 - 整体平台架构

---

参考资料

• vLLM 官方文档
• Mixtral 模型卡
• MoE 架构论文
• PagedAttention 论文