deepseek的moe路由是动态加权选择机制，对每个token计算权重并top_k选出2–4个专家加权融合输出，保留梯度可导性；采用容量因子与负载均衡损失双约束缓解专家负载不均；专家为独立ffn且参数不共享；v3引入两级路由提升长序列稳定性。
☞☞☞AI 智能聊天, 问答助手, AI 智能搜索, 多模态理解力帮你轻松跨越从0到1的创作门槛☜☜☜
MoE的路由机制本质是动态加权选择，不是固定分配
DeepSeek的MoE不把输入“分发”给某个专家，而是对每个token计算一组权重，再用top_k选出最相关的2–4个专家，最后加权融合它们的输出。这和传统硬路由（比如哈希或聚类）完全不同——它保留梯度可导性，让门控网络能通过反向传播持续优化选择逻辑。
常见错误是误以为路由结果是确定性的：实际每次前向传播都依赖当前logits值，而logits受输入嵌入、位置编码、上层状态共同影响。哪怕同一句话，在不同上下文位置触发的专家组合也可能不同。
-
top_k=2是默认值，但训练时可能临时设为3或4以缓解专家坍缩 - 门控网络输出未经softmax直接进
topk，避免小数值被归一化抹平区分度 - 温度系数（如
/1.0）在推理时通常冻结，但微调阶段会调整它来控制路由锐度
专家负载不均会直接拖慢推理，必须靠容量因子+辅助损失双约束
如果只做top_k选择，少数专家会被高频选中，其余长期闲置——这不仅浪费参数，更会导致显存访问不均衡、GPU利用率骤降。DeepSeek用两个硬性机制压住这个问题：
- 容量因子（
capacity_factor=1.2）：限制每个专家单次最多处理total_tokens * 1.2 / num_experts个token，超限token会被静默丢弃或路由到次优专家 - 负载均衡损失（
auxiliary_loss）：不是简单算各专家被选次数，而是惩罚权重分布的KL散度，公式里含log(w_i / mean_w)项，强制模型学习均匀分配 - 注意：
auxiliary_loss只参与训练，推理时完全不生效；但没它，训练中期就会出现2个专家扛80%流量的现象
专家本身是标准Transformer FFN块，但参数不共享
每个专家对应一个独立的前馈网络（FFN），结构和原版Transformer的FeedForward一致：两层线性变换 + 激活函数（如SwiGLU）。关键点在于——它们的权重矩阵完全不共享，且初始化方差按专家数缩放（例如128专家时，初始化标准差除以√128），否则门控网络学不出有效区分。
使用Perplexity API进行网络搜索的AI助手。当用户需要最新信息并附有来源引用、时事事实查询，或研究类答案时使用。当用户提及Perplexity或需要带有参考文献的最新信息时，默认使用此技能。
容易踩的坑是试图复用专家参数来省显存：这会破坏MoE的核心前提——“分而治之”。实测显示，即使只共享bias项，也会导致load_balance_loss上升40%以上，最终推理延迟反而增加。
- 专家数量（
num_experts=64或128）直接影响总参数量，但激活参数恒定≈2×单专家参数 - 专家内部不做Dropout，因为稀疏激活本身已是正则化手段
- 推理时，专家计算可并行，但
top_k索引需全局同步，这是隐藏的通信开销点
DeepSeek-V3的两级路由不是噱头，它解决的是长序列下的路由噪声问题
单层路由在seq_len > 8k时，gate输出的logits方差会急剧增大，导致top-k选择抖动严重。V3改用两级：先用轻量group_gate粗筛8个组（每组16专家），再在组内用精细expert_gate选2–4个。这样既保持细粒度适配能力，又把路由噪声控制在局部范围内。
这个设计代价是多一次matmul和两次topk，但实测在2048长度下，路由稳定性提升5倍以上。如果你在微调时关掉二级路由，perplexity曲线会在第3 epoch后突然震荡，就是噪声开始主导选择的结果。
- 第一级
group_gate输出维度是8，第二级才是16；两者的hidden_size可以不同 - 组间切换有缓存友好性优势：同一组专家的权重更容易留在L2缓存中
- 部署时若显存紧张，可只缓存当前活跃组的专家权重，而非全部128个
真正难的不是看懂路由公式，而是理解每个capacity_factor、每个top_k、每次auxiliary_loss加权，都在和硬件访存模式、梯度传播路径、甚至CUDA kernel launch overhead做隐性博弈。这些细节不写在论文里，但卡在推理吞吐上时，全得从这里挖。
