激活与驻留不是一回事
混合专家模型单次生成只激活部分专家：计算量按激活的那部分参数走，但权重显存要按全部专家驻留。这带来一个常见误判：按总参数量估计算力需求，或按激活参数量估算显存需求，都会偏离实际。部署前先确认框架对这类结构的算子与并行支持。
基本信息
| 适用平台 | 支持混合专家结构的推理框架 |
|---|---|
| 关键字段 | 专家数量与每个词元激活的专家数 |
| 显存特点 | 权重按全部专家驻留，量化与专家并行常用 |
| 压测要求 | 按真实路由分布压测，吞吐与激活分布相关 |
部署前核对
部署前核对
grep -E 'num_experts|num_experts_per_tok' <模型目录>/config.json
vllm serve <模型路径> # 先用小并发验证专家结构的算子可用性典型使用场景
- 显存核算：权重按全部专家算，缓存按激活路径算
- 并行策略：专家并行可以把专家分散到多张卡上
- 压测设计：不同任务的路由分布不同，吞吐要以业务数据为准
- 量化配合：量化能显著降低全量专家的驻留占用
- 版本核对：先确认框架版本对目标结构的支持状态
与常规稠密模型对照
| 维度 | 混合专家模型 | 常规稠密模型 |
|---|---|---|
| 权重显存 | 按全部专家计算 | 按全部参数计算 |
| 单次计算量 | 按激活的专家计算 | 按全部参数计算 |
| 吞吐影响因素 | 路由分布与专家并行 | 批大小与序列长度 |
显存瓶颈在全部专家的驻留权重：量化与专家并行是常见组合，吞吐要按激活参数与路由分布实测。
不同任务触发的专家不同：同一模型在两类业务上的实测吞吐可能差得很多，容量结论不要跨业务直接套用。
先把小并发跑通：确认算子与并行组合可用之后，再进入容量压测环节。