MoE 与稠密模型是什么
稠密（Dense）模型对每个 token 都过一遍全部参数；MoE（Mixture of Experts，混合专家）把前馈层拆成多个专家，路由网络只为每个 token 选中少数几个专家参与计算，于是总参数量可以做得很大，而单次计算量只按激活参数算。DeepSeek-V3 这类模型总参数数百亿级以上、激活参数只有几十亿；Llama 3.1 8B/70B、Qwen 稠密版则属全参数参与。选型时最容易踩的坑是：MoE 省的是算力，不省显存。
基本信息
| 稠密计算方式 | 每个 token 经过全部参数 |
|---|---|
| MoE 计算方式 | 每个 token 激活少量专家，常含共享专家 |
| 总参数与激活参数 | MoE 总参数大、激活参数小 |
| MoE 代表 | DeepSeek-V3、Qwen3 系列 MoE 版、Mixtral |
| 稠密代表 | Llama 3.1 8B/70B 等 |
| 显存估算 | 按总参数算；吞吐按激活参数估 |
典型使用场景
- 硬件采购前的显存规划：决定单卡还是多卡、是否需要量化
- 自托管选型：高并发场景用 MoE 摊薄算力，低频推理用稠密小模型更划算
- 成本对比：把 GPU 租赁或整机成本换算成每百万 token 单价
- 微调可行性评估：MoE 微调对显存和框架支持要求更高
- 部署后的吞吐预估：判断峰值并发能否被单实例承接
推理显存粗算
推理显存粗算
# 权重显存 ≈ 总参数量(十亿) × 每参数字节数
# FP16≈2GB、INT8≈1GB、INT4≈0.5GB（每十亿参数）
# 例：70B 稠密模型 INT4 约 35GB 权重，另加 KV Cache 与框架开销
# 例：MoE 总参数 671B / 激活 37B，权重按 671B 算，算力按 37B 估
# KV Cache 随上下文长度与并发数增长，长上下文场景必须单独预留
# 结论：量化能压显存，激活参数只影响算力与吞吐两种架构对比
| 维度 | 稠密 | MoE |
|---|---|---|
| 计算量 | 全参数参与，token 成本高 | 只激活部分专家，单 token 便宜 |
| 显存占用 | 与参数规模成正比 | 按总参数算，明显更大 |
| 吞吐表现 | 稳定可预测 | 受专家负载均衡影响，存在波动 |
| 训练与微调 | 工具链成熟 | 并行策略复杂，框架支持要求高 |
| 适用场景 | 低并发、边缘部署、小参数场景 | 高并发推理与大规模服务 |
MoE 的价值在高并发：请求越密，被摊薄的算力越多。单机低并发时它的性价比往往不如同档稠密小模型，选型要先看真实并发而不是峰值参数展示。
专家负载不均会让实际吞吐低于理论值，压测要用真实业务分布的长短请求混合，而不是单条短请求反复打。