企业官网建设流程全解析

简介：DeepSeek-V2 官方技术论文 PDF 面向大模型研究者、算法工程师与 MoE 架构学习者，系统阐述 2360 亿总参数、每 token 仅激活 210 亿参数的 MoE 语言模型设计，并支持 128K 上下文。论文重点剖析 Multi-head Latent Attention 与 DeepSeekMoE 两项创新架构：前者将 KV 缓存压缩为潜在向量以提升推理效率，后者借助稀疏计算降低训练成本；同时给出 8.1 万亿 token 预训练、SFT 与 RL 的完整流程及评测对比。相较 DeepSeek 67B，其训练成本节省 42.5%、KV 缓存减少 93.3%、最大生成吞吐量提升至 5.76 倍，并附检查点获取地址。资源包共 1 个 PDF 文件，约 1.5MB，含架构推导、性能图表与实验数据，便于精读复现与引用。已有 294 人学习下载，适合关注高性能、低成本训练与推理优化的读者参考。

1. 236B 参数只激活 21B：MoE 大模型省钱的底层逻辑

一个 2360 亿参数的模型，每个 token 只激活 210 亿参数，训练成本比上一代稠密模型省 42.5%，KV 缓存压掉 93.3%，生成吞吐量拉到 5.76 倍。这几个数字放在一起，第一反应往往是「参数是不是虚标了」或者「省下来的钱是不是拿性能换的」。DeepSeek-V2 这篇论文给出的答案恰恰相反：它在 MMLU 上的表现比同规模稠密模型更好，而推理时占用的显存和带宽却小了一个量级。真正值得搞懂的不是这些数字本身，而是它凭什么能同时做到「强」和「省」——答案藏在两个架构改动里：用低秩联合压缩把 KV 缓存压成一个潜在向量，用细粒度专家加共享专家的稀疏结构把训练算力花在刀刃上。搞懂这两件事，再看今天几乎所有 MoE 模型的架构图，就不会再觉得那是一堆看不懂的矩阵乘法了。

2. MLA：KV 缓存为什么能压掉 93.3%

2.1 标准 MHA 的缓存瓶颈到底卡在哪

先把问题摆清楚。标准多头注意力里，每个 token 在每一层都要产生一份 Key 和一份 Value，推理时这些 K/V 必须全部缓存下来，否则每生成一个新 token 都要把整段历史重算一遍。论文里给的量是：MHA 每个 token 每层要缓存2 * n_h * d_h个元素，乘上层数l，就是2 * n_h * d_h * l。以 128K 上下文、几十层、几十个头的配置去算，这个数字会直接顶到显存天花板，进而限制 batch size 和序列长度——也就是说，KV 缓存不是「慢一点」的问题，它是决定你能不能把长上下文跑起来的硬约束。

业界先有的两条路是 MQA 和 GQA。MQA 让所有头共享一份 K/V，缓存是小了，但表达能力掉得厉害；GQA 折中，几个头共享一组 K/V，性能和缓存之间取平衡。论文附录里专门做了 MHA、GQA、MQA 的消融对比，结论很明确：这两种方法在压缩缓存的同时都牺牲了性能，达不到 MHA 的水平。这就是 MLA 要解决的矛盾——既要 MHA 级别的表达能力，又要远小于 MHA 的缓存。

2.2 低秩联合压缩：把 K 和 V 压成一个 latent 向量

MLA 的核心动作是「联合压缩」。它不再为每个头单独算 K 和 V，而是先把输入投影到一个低维的 latent 空间，再从 latent 空间上投影出 K 和 V：

# MLA 的 KV 联合压缩（对应论文公式 9-11） # h_t: 第 t 个 token 的隐藏状态, 维度 d # d_c: KV 压缩维度, 远小于 n_h * d_h c_kv = W_DKV @ h_t # 下投影: d -> d_c, 得到压缩 latent 向量 k_c = W_UK @ c_kv # 上投影: d_c -> n_h * d_h, 还原 Key v_c = W_UV @ c_kv # 上投影: d_c -> n_h * d_h, 还原 Value

关键在推理阶段缓存什么。训练时 K 和 V 是显式算出来的，但推理时只需要缓存c_kv这一个d_c维的向量，每 token 每层的缓存量从2 * n_h * d_h降到d_c。论文里d_c远小于n_h * d_h，这就是 93.3% 压缩率的来源。更妙的一步是「吸收」：因为W_UK可以乘进W_Q里、W_UV可以乘进W_O里，推理时甚至不需要把 K 和 V 真正还原出来，直接在 latent 空间完成注意力计算。这一步是纯代数等价变换，不损失任何信息，却省掉了上投影的矩阵乘。

提示：这里的「吸收」成立的前提是注意力打分和输出投影都是线性的，所以矩阵可以提前合并。任何在 K/V 上做非线性操作的改动都会破坏这个性质，这是理解 MLA 边界的关键。

2.3 解耦 RoPE：位置编码为什么不能直接压在 latent 上

低秩压缩带来一个新麻烦：RoPE 位置编码。RoPE 是对 K 做旋转操作，而旋转是位置相关的、非线性的，没法塞进那个被压缩的 latent 向量里再「吸收」回去。如果硬把 RoPE 加在压缩后的 K 上，位置信息会和压缩表示纠缠在一起，破坏前面说的代数等价性。

MLA 的解法是「解耦」：把每个头的维度拆成两部分，一部分走压缩路径、不带 RoPE，另一部分单独保留、专门承载 RoPE。论文里用[q_t,i; q_t,i^R]和[k_t,i; k_t,i^R]这种拼接形式表示，带 R 后缀的就是 RoPE 分支。这样位置信息有了独立通道，压缩路径保持纯净，两者在计算注意力时再拼回去。这个设计看起来是个工程补丁，实际上是 MLA 能同时拿到「压缩」和「位置编码」两个好处的前提——没有它，低秩压缩和 RoPE 只能二选一。

2.4 查询也做低秩压缩：省的是训练激活内存

论文还做了一件容易被忽略的事：对 Query 也做低秩压缩，c_Q = W_DQ @ h_t，再上投影回q_C。注意这一步不减少 KV 缓存，因为 Q 本来就不缓存。它的目的是降低训练时的激活内存占用——Q 的中间张量在反向传播时要留着，压缩一下能显著减少显存压力。这是一个典型的「训练侧优化」，和推理侧的 KV 压缩是两笔账，读论文时要把它们分开看，否则会误以为 Q 压缩也贡献了那 93.3%。

3. DeepSeekMoE：稀疏计算怎么把训练成本打下来

3.1 细粒度专家加共享专家：稀疏的两种切法

MoE 的基本思路是把 FFN 拆成多个专家，每个 token 只走其中几个，从而让总参数量远大于每 token 计算量。但传统 MoE（比如 GShard 那类）有两个毛病：专家粒度太粗，每个专家什么都学一点，专业化程度不够；以及所有 token 都要经过路由专家，通用知识被迫分散在各个专家里重复学习。

DeepSeekMoE 的两个改动正好对症。第一是「细粒度专家分割」：把每个专家切得更小、数量更多，路由时选更多个小专家，组合空间变大，专业化更容易发生。第二是「共享专家隔离」：留出固定几个专家，所有 token 都无条件经过它们，专门承载通用知识；路由专家则专注学细分领域的差异。论文的架构图里，共享专家那条路是不经过 Router 的，直接接进输出，这个细节很重要——它意味着通用能力的计算是确定性的，不受路由波动影响。

3.2 设备受限路由：专家并行下的通信账

MoE 训练通常用专家并行，不同专家放在不同设备上，token 路由到哪个专家就要跨设备传数据。如果路由完全自由，一个 token 可能被发到任意设备，通信开销和负载不均会同时爆炸。论文提出的「设备受限路由」是：先把 token 路由到设备，再在设备内部选专家，保证每个 token 最多只跨有限个设备。这是一个用「路由自由度」换「通信可预测性」的取舍——牺牲一点最优路由的可能性，换来通信模式规整、易于流水线调度。

3.3 负载均衡损失与 token 丢弃：训练稳定性的两道保险

稀疏路由天然有马太效应：被选中的专家越来越强，没被选中的越来越弱，最后路由塌缩到少数专家上。论文用辅助损失做负载均衡，在训练目标里加一项惩罚，让各专家的 token 分配尽量均匀。另一道保险是 token 丢弃策略：当某个专家过载时，超出容量的 token 直接跳过该专家（走残差），而不是排队等待。这在训练时是有损的，但保证了计算图的形状固定、不出现动态等待，对分布式训练的稳定性至关重要。

# DeepSeekMoE 前向的简化逻辑（示意，非源码） # shared_experts: 所有 token 必经, 承载通用知识 # routed_experts: 经 Router 选择 top-K, 承载细分知识 shared_out = sum(expert(h) for expert in shared_experts) # 设备受限: 先选设备组, 再在组内选专家 device_ids = topk(device_router(h), k=num_device_groups) scores, expert_ids = topk(expert_router(h, device_ids), k=top_k) routed_out = 0 for score, eid in zip(scores, expert_ids): if load[eid] < capacity: # token 丢弃: 超容量则跳过 routed_out += score * experts[eid](h) load[eid] += 1 output = shared_out + routed_out

这段逻辑里三个参数值得盯：top_k决定每 token 激活多少路由专家，直接对应「21B 激活参数」这个数；capacity是每个专家的容量上限，设小了丢 token 多、设大了显存吃紧；num_device_groups控制跨设备范围，是通信开销的旋钮。调这几个参数时的血泪经验是：容量和 top_k 要一起调，单独动一个很容易在训练中期出现 loss 尖刺。

4. 避坑：复现 MoE 架构时最容易翻车的几件事

4.1 现象：MLA 推理显存没降下来

原因：只实现了 latent 缓存，但没有做W_UK吸收进W_Q、W_UV吸收进W_O的合并，推理时仍然把 K/V 上投影还原出来再算注意力，等于缓存省了、计算没省，显存峰值反而因为多了一次上投影而升高。解决：在推理前把上投影矩阵和 Q/O 投影做一次矩阵乘合并，确保注意力直接在 latent 空间完成；用一个小 batch 对比合并前后的显存占用和输出数值，确认等价。

4.2 现象：加了 RoPE 之后模型效果明显变差

原因：把 RoPE 直接作用在压缩后的 K 上，位置信息和压缩表示纠缠，破坏了 MLA 的解耦结构。解决：严格按解耦设计，把每个头的维度拆成非 RoPE 和 RoPE 两段，RoPE 只作用在独立分支上，拼接后再算注意力。验证方法是关掉 RoPE 分支看 loss 是否异常，如果关掉反而更好，说明位置编码的注入位置错了。

4.3 现象：训练到中期 loss 突然尖刺，路由塌缩到少数专家

原因：负载均衡辅助损失的系数太小，或者 token 丢弃容量设得过紧，导致过载专家持续被跳过、欠载专家拿不到梯度。解决：先把均衡损失系数调大观察路由分布是否均匀，再逐步放宽容量的同时监控丢 token 比例；两个参数不要同时大改，一次只动一个，否则无法归因。

4.4 现象：专家并行下吞吐远低于预期

原因：路由没有做设备限制，token 被随机发往所有设备，跨设备通信成为瓶颈，且通信模式不规则导致无法重叠计算。解决：实现设备受限路由，先选设备组再选组内专家，把每个 token 的跨设备跳数压到常数；用通信耗时占比作为指标，占比超过计算耗时说明路由约束还不够紧。

4.5 现象：共享专家和路由专家的输出量级不一致

原因：共享专家无条件接收所有 token，梯度信号远强于单个路由专家，导致两者输出尺度漂移，简单相加后数值不稳。解决：对两路输出分别做归一化再合并，或在初始化时按接收 token 比例缩放；训练早期监控两路输出的方差比，偏离太多就调整缩放系数。

5. 设计取舍：为什么是「压缩 + 稀疏」而不是别的组合

把 MLA 和 DeepSeekMoE 放在一起看，会发现它们解决的是两个不同维度的成本问题，而且这两个维度恰好是互补的。MLA 压的是推理时的显存带宽——KV 缓存决定了你能开多大 batch、跑多长上下文，这是部署侧的成本；DeepSeekMoE 压的是训练时的算力——稀疏激活让总参数涨上去而每 token 计算量不涨，这是训练侧的成本。一个模型如果只做其中一个，要么训得起但部署不起，要么部署轻但训不动。论文里 42.5% 训练成本节省和 93.3% KV 缓存压缩同时出现，本质是两条正交的优化路径叠加。

但每个选择都有代价，值得摊开看。MLA 的代价是架构复杂度：解耦 RoPE、矩阵吸收、latent 空间计算，每一处都增加了实现和调试的难度，前面避坑章节里那些翻车点基本都是这个复杂度的副产品。它换来的收益是「性能不降反升」——论文的消融显示 MLA 甚至优于 MHA，这在压缩类方法里是少见的，因为 MQA/GQA 都是拿性能换缓存。DeepSeekMoE 的代价是训练稳定性：路由、均衡、丢弃、设备限制，四个机制互相牵制，调参空间大且不直观。它换来的是「总参数可以堆到 236B 而激活只有 21B」，让模型容量和计算成本解耦。

如果要验证这套设计是否真的 work，我一般会分三步走：先在小规模上单独验证 MLA 的缓存压缩是否数值等价（关掉压缩对比输出），再单独验证 MoE 的路由分布是否健康（看专家负载熵），最后才把两者合起来跑长上下文，观察吞吐和 loss 曲线是否同时达标。跳过任何一步，出问题时都很难判断是压缩的锅还是路由的锅。

这份论文的价值不在于给出一个「标准答案」，而在于展示了两个约束下的取舍过程：当你既要长上下文又要低部署成本时，压缩是绕不开的；当你既要大容量又要低训练成本时，稀疏是绕不开的。至于压缩到什么维度、稀疏到什么粒度，论文里的具体数字是他们的答案，不是唯一答案。从那以后我每次读 MoE 架构，都会先把「缓存什么」和「激活什么」这两笔账分开算一遍，再去看那些花哨的模块名——希望这个习惯也能帮到你。

本文还有配套的精品资源，点击获取