先给结论
服务端追求能力上限与整体吞吐量时，应当选择混合专家模型；显存受限环境或端侧小规模场景，则应当选择稠密模型。混合专家模型的核心选型逻辑，是用额外的物理显存换取同等推理算力下的更大总参数量，适合资源充足的云端部署，以满足服务侧高吞吐需求。稠密模型因每个 token 会激活全部参数，训练与推理行为可预期，batch 内计算更均匀。在硬件资源有限、需要简单可靠部署的场景下，稠密模型更为稳妥。端侧设备通常优先考虑较小稠密模型或蒸馏版本。
逐项对比
| 对比维度 | Dense (稠密模型) | MoE (混合专家模型) |
|---|---|---|
| 定位 | 每个 token 激活全部参数 | 路由器为每个 token 选少数专家 |
| 强项 | 训练与推理行为可预期，batch 内计算均匀 | 同等推理算力下可堆更大总参数换取能力 |
| 弱项 | 能力上限受总参数与算力约束 | 显存需装下全部专家，存在负载均衡问题 |
| 典型场景 | 显存受限部署、小规模场景、端侧设备 | 追求能力密度与吞吐的服务侧部署 |
| 成本 | 参数即成本，算力与显存消耗成正比 | 显存占用大，单请求延迟优势不如吞吐优势 |
稠密模型与混合专家模型在底层计算逻辑上存在根本差异。稠密模型在训练和推理时，每一个 token 都会经过网络中的所有参数，这种机制使得 batch 内的计算非常均匀。其代价是参数量直接等同于计算成本，模型能力的上限被总参数量和可用算力严格限制。
混合专家模型引入了路由机制，在 FFN 层为每个 token 挑选少数专家进行计算。这种设计让模型在保持单 token 激活参数量较小的前提下，能够有效增加总参数量。就像一个分科医院，病人只去对应科室看病，总体规模可以建得很庞大。这种机制在同等推理算力下换取了更高的模型能力，并在服务侧展现出明显的总吞吐优势。需要注意，其单请求延迟优势不如总吞吐优势明显。
稀疏激活特性也带来了工程代价。推理侧中，batch 内不同的 token 会激活不同的专家，改变了通信与显存占用模式，且物理显存必须装下全部专家参数。训练侧则面临路由带来的负载均衡问题，专家倾斜现象使得训练稳定性更难调节。
面试怎么答
面试遇到选型问题，应当先问清部署环境限制与业务目标，比如显存预算具体是多少、是端侧还是云端、核心诉求是响应延迟还是整体吞吐量。明确前提条件后，再按照云端高吞吐选混合专家模型、端侧或显存受限选稠密模型的逻辑给出结论，并补充混合专家模型在显存占用和通信模式上的代价。
常见的错误答法是脱离显存约束直接推荐混合专家模型，或者误以为该模型能改善单请求延迟。面试官通常会追问底层细节，作答时必须提前准备好负载均衡辅助损失的原理，以及专家并行的切分逻辑。