专家容量因子（Capacity Factor）是专家混合（Mixture of Experts, MoE）模型里的一个乘数，用来决定一个批次（batch）中每个专家最多能接收多少 token。简单说，它给每个专家设了一个“最大接待量”，超出的 token 要么被丢掉，要么绕过这个专家。
要理解它，先看 MoE 怎么工作。假设一个 batch 有 4096 个 token，模型有 8 个专家。路由（routing）会给每个 token 挑一个或几个专家。平均下来，每个专家该处理 4096 / 8 = 512 个 token。但路由不会那么均匀：有的专家特别热门，可能被几千个 token 选中；有的专家很冷门，一个 token 都没有。如果让热门专家无限接收，计算图就会严重不均衡，显存和并行效率都会崩。
于是框架给每个专家设上限：
每个专家的容量 =（batch 里 token 数 / 专家数）× 容量因子
如果容量因子是 1.0，每个专家最多处理 512 个 token；设成 1.5，上限就是 768。容量因子大于 1，相当于给热门专家多备了一些“餐盘”，减少溢出。
那溢出的 token 怎么办？主流做法是“丢弃 + 绕过”。比如 GShard、Switch Transformer 这类早期 MoE 工作中，超过容量的 token 不会被这个专家处理，直接通过残差连接（residual connection）传到下一层。注意，它并不是从序列里被删掉，而是“绕过”了这层专家计算，表示基本不变地继续往前走。就像食堂窗口满了，你不在这个窗口打菜，但还能去下一个环节，不会饿死。
也有实现会尝试把溢出 token 重新路由到还有余量的专家，或者交给共享专家、通用专家。但“丢弃 + 残差绕过”是最常见的默认行为，所以调容量因子时，一定要看丢弃率（drop rate）。
用一个表区分相邻概念：
| 概念 | 作用 | 说明 |
|---|---|---|
| 容量因子 | 控制每个专家最多收多少 token | 略大于 1，常见在 1.0～2.0 之间 |
| 专家数量 | 决定模型总容量和路由空间 | 8、64、256 等 |
| top-k 路由 | 每个 token 选几个专家 | 通常 1 或 2 |
| 负载均衡损失 | 训练时鼓励 token 均匀分到各专家 | 防止热门专家挤爆 |
对从业者来说，容量因子是“模型质量”和“计算效率”之间的旋钮。太小，热门专家溢出多，很多 token 没被专家处理，质量会下降；太大，每个专家都要预留大量显存和计算槽位，冷门专家大量空转，浪费严重。训练时通常设得略大于 1，并监控丢弃率；推理时对延迟更敏感，往往更保守。具体默认值和实现细节，以官方代码和文档为准。
对普通人，可以这么记：MoE 像一家有很多窗口的食堂，容量因子决定每个窗口最多备多少份饭。备少了，热门窗口排不下，后来的人只能绕过这个窗口；备多了，每个窗口都堆一堆没人吃的饭。调它，就是在“别让顾客吃不到”和“别浪费粮食”之间找平衡。