Auxiliary-Loss-Free Load Balancing [DeepSeek-V3提出]
和DeepSeek-V3一样，DeepSeek-R1接纳了细粒度的MoE，一些expert作为共享expert，另一些expert作为routed expert进行动态激活。对于第t个token u t u_t ut，下面是MoE计算的过程：
以前基于auxiliary loss的方法需要修改loss function，当auxiliary loss很大时会影响模型性能。那么Auxiliary-Loss-Free则是在gating value g g g的基础上，额外加上了bias来实现负载均衡：
留意bias只影响专家路由，而不影响任何梯度。专家overloaded则降低bias，专家unoverloaded则增大bias。调整的速率由超参数 γ \gamma γ控制，这个和反向传播的梯度更新过程雷同。
下图是该方法的出处：Auxiliary-Loss-Free Load Balancing Strategy for Mixture-of-Experts文章所提出的负载均衡策略：
真正推理时，cache的就是低维的 c t K V c_t^{KV} ctKV，而且down-proj和up-proj矩阵可以分别被吸收进 W Q W^Q WQ和 W O W^O WO中，不会造成额外的计算开销。这个方法和Palu: Compressing KV-Cache with Low-Rank Projection那篇文章同等。具体的融合过程如下（以 W Q W^Q WQ的融合为例）：
为了在练习时降低激活的memory，也对query做低秩压缩：
【对query低秩分解怎么省memory，算的时间不需要重构回去？】【回答：只需要生存低秩的query，然后在反向传播时重计算一步，节省了需要存储的memory】 RoPE位置编码兼容性考虑
但是KV cache的低秩压缩和RoPE位置编码并不兼容！如果对 k t C k_t^C ktC做RoPE， W U K W^{UK} WUK会和位置敏感的RoPE矩阵耦合在一起，从而不能在推理时被吸收进 W Q W^Q WQ中（这里应该强调一下吸收是totally offline完成的），带来额外的计算。
进一步理解 W U K W^{UK} WUK和RoPE矩阵的耦合：与生成当前token相干的RoPE矩阵位于 W Q W^{Q} WQ和 W U K W^{UK} WUK之间，而矩阵乘法不满足交换律。
于是DeepSeek-V2提出相识耦RoPE策略，用额外的多头query和一个共享key来计算RoPE，然后和原本的query和key拼接起来。至于这里怎么得到的额外query和key，就是用来两个额外的线性层来算得的。
