企业官网建设流程全解析

简介：DeepSeek-V2 论文原文以单份 PDF 形式提供，面向大模型研究者、算法工程师及关注 MoE 架构与推理成本优化的开发者，可用于架构选型、成本评估和论文精读。文件共 1 个 PDF，压缩包约 1.5MB，目录涵盖模型架构、预训练、微调、评估及成本对比等章节，便于直接检索与归档；目前已有 294 人学习。论文围绕总参数 236B、每 token 激活 21B 的 MoE 语言模型展开，重点阐述 Multi-head Latent Attention 通过低秩键值联合压缩与解耦旋转位置嵌入降低 KV 缓存占用，以及 DeepSeekMoE 借助稀疏计算、设备受限路由和负载均衡辅助损失控制训练开销。读者可获取 128K 上下文、8.1T token 预训练、SFT 与 RL 流程等关键信息，并对照 DeepSeek 67B 的训练成本节省 42.5%、KV 缓存减少 93.3%、最大生成吞吐提升至 5.76 倍等数据，理解高性能与经济性之间的权衡。文中还给出开源检查点链接，方便进一步复现与应用研究。

1. 236B 参数只激活 21B：省下的到底是算力还是显存

DeepSeek-V2 这篇论文最容易被误读的一句话，是「总参数 236B、每 token 激活 21B」。多数人看到这里立刻得出结论：MoE 就是靠稀疏激活省算力。这只对了一半，而另一半恰恰是工程上真正卡脖子的地方。一个 21B 激活的模型在 128K 上下文下做推理，限制吞吐的通常不是矩阵乘法的 FLOPs，而是每一层、每一个 token 都要重复读写的 KV cache——它随序列长度线性膨胀，把显存带宽吃干净，batch size 提不上去，长上下文直接变成摆设。

所以这篇论文的两条主线是配套的，不是拼盘：DeepSeekMoE 负责把「训练出一个强模型」的单位成本压下来，MLA 负责把「部署时每个 token 的记忆开销」压下去。前者省的是 GPU 小时，后者省的是显存带宽，两者合起来才有那组数字——训练成本降 42.5%、KV cache 降 93.3%、最大生成吞吐提到 5.76 倍。搞懂这两条线为什么必须一起做、各自又付出了什么代价，基本就摸到了当代高效大模型架构的骨架。

2. MLA 的低秩联合压缩：KV cache 凭什么能砍掉九成

2.1 先算清楚 MHA 的 KV cache 到底占多少

标准多头注意力里，第 t 个 token 的输入 $h_t \in \mathbb{R}^d$，经过三个投影矩阵得到 $q_t, k_t, v_t \in \mathbb{R}^{n_h d_h}$，然后按头切分成 $n_h$ 份做注意力。单看计算量，生成阶段每个 token 的注意力部分只有 $O(n_h d_h T)$，而自回归解码时每生成一个 token 就要把历史所有 k、v 重新读一遍，读的是显存，不是寄存器。

于是每 token 每层必须缓存的元素数就是 $2 n_h d_h$：k 一份、v 一份，各 $n_h$ 个头、每头 $d_h$ 维。乘上层数 $l$ 和序列长度，再乘数据类型字节数，就是实打实的显存占用。这个量级的读写属于典型的低算术强度操作——搬运的字节数远多于参与的浮点运算次数，GPU 的计算单元在等显存控制器。MHA 在长上下文下不划算，根子在这里，而不是在 FLOPs。

用一个脚本把这个账算清楚，比任何定性描述都直观：

def kv_cache_bytes(seq_len, n_layers, per_token_per_layer, dtype_bytes=2): """估算单条请求的 KV cache 字节数 per_token_per_layer: 每 token 每层缓存的元素个数 dtype_bytes: fp16/bf16 记 2 字节 """ return seq_len * n_layers * per_token_per_layer * dtype_bytes # MHA: k 和 v 各 n_heads 个头，每头 d_head 维 mha = 2 * 128 * 128 # n_heads=128, d_head=128 # MLA: 只缓存一个 d_c 维的潜向量 + 一小段承载 RoPE 的维度 mla = 512 + 64 # d_c=512, 解耦 RoPE 维度 64（示意取值） print(kv_cache_bytes(131072, 60, mha) / 2**30, "GiB / 请求 (MHA)") print(kv_cache_bytes(131072, 60, mla) / 2**30, "GiB / 请求 (MLA)")

参数怎么调：per_token_per_layer是唯一需要按模型配置改的量，MHA 填 $2 n_h d_h$，MLA 填 $d_c + d_h^R$。跑一遍就能看出，在 128K 长度下单请求的 KV cache 从几十 GiB 量级掉到几 GiB 量级，压缩比正好落在十几倍这个区间——论文报的 93.3% 削减和这个量级是对得上的。

2.2 低秩联合压缩：K 和 V 共享同一个瓶颈

MLA 的核心动作不复杂：不再把 k、v 从 $h_t$ 直接投到 $n_h d_h$ 维，而是先投到一个远小于原维度的潜向量 $c_t^{KV} \in \mathbb{R}^{d_c}$，再从 $c_t^{KV}$ 分别上投影出 k 和 v。

import torch.nn as nn class LatentKVCompression(nn.Module): def __init__(self, d_model, n_heads, d_head, d_c): super().__init__() # 下投影：把 hidden 压到低秩瓶颈 self.W_dkv = nn.Linear(d_model, d_c, bias=False) # 上投影：从同一个潜向量分别还原 K 和 V self.W_uk = nn.Linear(d_c, n_heads * d_head, bias=False) self.W_uv = nn.Linear(d_c, n_heads * d_head, bias=False) def forward(self, h): c_kv = self.W_dkv(h) # [T, d_c] —— 推理时只缓存这个 k = self.W_uk(c_kv) # [T, n_heads*d_head] v = self.W_uv(c_kv) # [T, n_heads*d_head] return c_kv, k, v

关键在于「联合」二字。如果对 K 和 V 各自做一次低秩分解，会得到两个独立的潜向量，缓存两个瓶颈；而这里 K 和 V 共用同一个 $c^{KV}$，缓存只需一份 $d_c$ 维向量。数学上这等价于把拼接矩阵 $[W_K; W_V] \in \mathbb{R}^{2n_h d_h \times d}$ 视作近似低秩，用一个共享的低秩因子去参数化它。这也解释了为什么压缩后性能不降反升：低秩约束本身就是一种正则，注意力被迫在更紧凑的子空间里组织信息，反而比全秩的 MHA 更抗过拟合。

Query 侧也做了低秩压缩（$h_t \to c_t^Q \to q_t$），但目的不同——它不减 KV cache，只减训练时的激活显存。这个区别很容易被混淆：训练时激活值占大头，推理时 cache 占大头，两个瓶颈对应两种压缩，论文把它们分开处理，说明作者对显存账本拆得很细。

2.3 矩阵吸收：推理时 K 和 V 压根不用被算出来

真正让这个设计变得漂亮的，是矩阵吸收。注意力分数是 $q_{t,i}^\top k_{j,i}$，代入 $k_{j,i} = W_{UK,i} c_j^{KV}$，得到：

$$q_{t,i}^\top k_{j,i} = (W_{UQ,i} c_t^Q)^\top (W_{UK,i} c_j^{KV}) = (W_{UK,i}^\top W_{UQ,i} c_t^Q)^\top c_j^{KV}$$

右边这个形式意味着：可以把 $W_{UK}^\top W_{UQ}$ 在推理前预先合成一个矩阵，直接用 $c^{KV}$ 参与内积，根本不需要把 $k$ 展开出来。V 侧同理，$W_{UV}$ 可以吸收进输出投影 $W_O$，注意力加权求和直接在潜空间完成，最后一步才投回 $d$ 维。

从缓存角度看，推理时显存里躺着的只有 $c^{KV}$；从计算角度看，K 和 V 从头到尾没有作为独立的张量出现过。这种「潜向量既是存储格式又是计算格式」的做法，把访存和计算合并成了一遍，避免了先读 cache、再展开、再算的冗余搬运。这是我读这篇论文时觉得最优雅的一处——它没有发明新算子，只是把线性代数的结合律用到了极致。

注意：矩阵吸收改变的是推理路径，训练时仍然要显式展开 K、V，否则反传的梯度形状对不上。很多复现踩坑就踩在把吸收版实现直接拿去做训练。

2.4 解耦 RoPE：低秩压缩和位置编码为什么天生打架

低秩压缩做完，新的问题冒出来：RoPE 没法用了。RoPE 的做法是对 q 和 k 的每一维按位置角度做旋转，旋转矩阵 $R_j$ 依赖绝对位置 j。如果把 RoPE 作用在压缩后的 $c^{KV}$ 上，再上投影展开，等价于对每个 k 的维度施加了一组被 $W_{UK}$ 混合过的旋转——旋转和上投影不可交换，位置信息会被搅乱；反过来先旋转再压缩，则 $c^{KV}$ 里混入了位置相关成分，矩阵吸收的前提（$W_{UK}$ 与位置无关）就被破坏了。

MLA 的解法是「拆开」：把每个头的 key 分成两路。一路是内容部分，走低秩压缩，不带位置信息，可被吸收；另一路是位置部分 $k_t^R$，维度很小（$d_h^R$ 远小于 $d_h$），直接由 $h_t$ 投影得到、不做压缩，专门用来承载 RoPE 旋转，而且这一路在所有注意力头之间共享同一份。Query 侧对称地拆出 $q_t^R$ 和内容部分。

这样每 token 每层的缓存量就变成 $d_c + d_h^R$，而不是 $2 n_h d_h$。代价是多了一条小分支、多了一点实现复杂度；收益是既保住了 RoPE 的外推能力，又保住了低秩压缩的收益。这个设计取舍很能说明问题：凡是「既要又要」的地方，答案往往不是折中，而是把冲突的两个需求在维度上切开，各走各的路。

3. DeepSeekMoE 的稀疏路由：细粒度专家与共享专家怎么分工

3.1 细粒度专家分割：切得更碎，组合空间反而更大

传统 MoE 的做法是从 N 个专家里选 top-K 激活，模型能表达的知识组合数是 $\binom{N}{K}$。这个数看着不小，但当 N 只有 8 或 16 时，组合空间很快见顶，专家被迫各自变得「全能」，专业化程度有限。

DeepSeekMoE 的做法是把每个专家再切成 m 份更小的专家，专家总数变成 mN，同时把激活数也放大到 mK，保持总激活参数量不变。组合数变成 $\binom{mN}{mK}$，在同样的参数预算和计算预算下膨胀了好几个数量级。直观理解：一个 8 选 2 的系统只有 28 种搭配，而一个 64 选 16 的系统有天文数字级的搭配，后者能覆盖的知识组合自然细得多。

代价也很直接：专家越碎，路由决策越多，每个 token 要触达的专家数量上升，all-to-all 通信的报文数量和调度开销一起涨。这为后面两节埋下了伏笔——细粒度不是免费的，必须配通信控制手段。

3.2 共享专家隔离：把通用知识从路由竞争里摘出去

如果所有专家都参与路由，会出现一个隐性浪费：不管什么领域的 token，都需要一批通用的语言能力（语法、常识、指代），于是每个被激活的专家都得在自己的参数里重复存一份通用知识。参数利用率被这种冗余拉低。

共享专家隔离的做法是划出一小批「永远激活」的专家，专门吸收跨领域的共性知识；剩下的路由专家只负责差异化部分。这样路由专家不必再为通用能力分心，可以把容量全部用于领域特化。从梯度角度看，共享专家收到的是全量 token 的梯度，收敛稳定；路由专家收到的是稀疏的、领域集中的梯度，分工自然形成。

这个思路和后来的很多 MoE 变体是一致的：与其让路由去学习「哪些是通用知识」，不如在结构上直接把通用通路固定下来，把学习难度降一个量级。

3.3 设备受限路由：先选设备再选专家，把 all-to-all 关进笼子

训练时专家分布在不同设备上，token 路由本质上是一次 all-to-all 通信。如果 top-K 专家随机散布在 8 台机器上，一个 token 可能要发往最多 K 台设备，通信量随 K 线性增长，而通信往往是 MoE 训练里最大的时间黑洞。

设备受限路由的思路是把两级选择拆开：先按设备聚合亲和度分数，只保留亲和度最高的 M 台设备（M 远小于设备总数），把其余设备上的专家分数直接屏蔽，再在这 M 台设备内部的专家里做 top-K。

def device_limited_routing(scores, expert_to_device, top_k, top_m): """scores: [T, N_experts] 路由打分 expert_to_device: [N_experts] 每个专家所在设备编号 返回每个 token 选中的专家下标 """ n_devices = expert_to_device.max() + 1 # 第一步：按设备聚合，得到 token 对每台设备的亲和度 dev_scores = scores.new_zeros(scores.size(0), n_devices) dev_scores.scatter_add_(1, expert_to_device.expand(scores.size(0), -1), scores) # 只保留 top-M 台设备 _, keep_dev = dev_scores.topk(top_m, dim=1) dev_mask = scores.new_zeros(scores.size(0), n_devices) dev_mask.scatter_(1, keep_dev, 1.0) # 屏蔽未选中设备上的所有专家 mask = dev_mask.gather(1, expert_to_device.expand(scores.size(0), -1)).bool() scores = scores.masked_fill(~mask, float('-inf')) # 第二步：在保留下来的专家里做 top-K return scores.topk(top_k, dim=1).indices

参数说明：top_k控制每 token 激活的专家数，直接决定计算量；top_m控制每 token 最多触达的设备数，直接决定通信量。把top_m压到 3 左右，意味着每个 token 至多和三台设备交换数据，通信上限被硬性锁死，不再随专家总数增长。这个设计的精髓在于：用一点点路由自由度换取通信量的确定性上界，工程上极其划算。

3.4 辅助损失与 token dropping：负载均衡的两道保险

路由有个自我强化的坏倾向：某个专家一旦早期表现好一点，就会收到更多 token，梯度更强，变得更好，最后所有 token 都涌向少数专家，其余专家几乎不更新。这是 MoE 训练里最经典的失败模式，光靠调学习率救不回来。

论文用了多层辅助损失压这个倾向。专家级平衡损失约束各专家的 token 分配比例与路由概率乘积的均衡；设备级平衡损失在设备粒度上再压一层，防止设备间负载差导致某台机器成为长尾；通信平衡损失则约束设备间的实际通信量，让 all-to-all 不至于在某一台上堆积。三层损失叠在一起，从「专家」「设备」「通信」三个维度同时约束稀疏路由的分布。

token dropping 是第二道保险。训练时为每个专家设一个容量上限（按平均分配量乘一个容量因子），超出上限的 token 直接丢弃，但保留残差连接保证梯度通路不断。推理时可以选择不做丢弃，或者调大容量因子。这里有个常见误判：训练时丢弃率不高不代表推理时也不会丢，长尾输入在推理阶段更容易触发容量溢出，需要单独监控。

4. 从 8.1T tokens 到 128K 上下文：训练成本省下的 42.5% 从哪来

4.1 数据构成：8.1T tokens 里加的不只是量

预训练语料做到了 8.1T tokens，相比上一代 67B 模型用的语料，除了规模扩大，结构上还有两个变化：中文数据占比明显提升，以及整体质量筛选更严。论文附录里专门讨论了预训练数据去偏，涉及去重、质量分级、领域配比调整这几类动作。这些工作在论文里只有半页，但对最终效果的影响往往比架构改动还大——尤其是中英双语场景，语料配比失衡会让模型在一种语言上「能说但不精」。

从工程角度看，8.1T tokens 意味着数据管道的吞吐必须和训练吞吐匹配上，否则 GPU 就会等数据。这部分的实现细节通常落在数据加载器的预取深度、样本打包（packing）策略和跨节点分片上，论文没有展开，但做大规模预训练的人都清楚这是血泪经验密集的区域。

4.2 成本节省的三个来源

42.5% 的训练成本节省不是单一技术带来的，粗略可以拆成三块。第一块是 MoE 稀疏化本身：总参数 236B 但每 token 只算 21B，同样的效果下 FLOPs 大幅下降。第二块是 MLA 带来的训练侧激活显存下降，使得同样硬件上能跑更大的 batch 或更长的序列，硬件利用率提上来。第三块是工程侧的并行策略和通信重叠，把 all-to-all 藏在计算后面。

# 粗算训练成本的量级，用于横向比较不同架构，不追求精确 def est_train_cost(tokens, activated_params, flops_per_param_token=6, mfu=0.4): total_flops = flops_per_param_token * activated_params * tokens gpu_flops_per_hour = 989e12 * 3600 * mfu # 以某个算力档位示意 return total_flops / gpu_flops_per_hour

参数含义：activated_params一定要填激活参数而不是总参数，这是很多人第一次估成本时最容易搞错的地方；mfu是算力利用率，MoE 因为通信开销通常低于稠密模型，取值要保守。用这个式子粗算，稀疏模型相对稠密模型的优势立刻显现，而且随着序列变长、batch 变大，MLA 省下的显存还能进一步抬高mfu。

4.3 128K 长上下文：分阶段扩展而不是一步到位

直接把位置编码外推到 128K，训练会崩。通行做法是分阶段继续预训练：先在较短长度上稳定，再逐步拉长，每一步都配合位置插值类的方案调整旋转频率。论文对长上下文的处理沿用了这一路线，把上下文从基础长度扩到 128K 的整个过程拆成若干阶段，每个阶段用不同的数据配比和长度分布。

这里有个容易被忽略的细节：长上下文能力不只是位置编码的事，训练数据里必须真的有长距离依赖的样本，否则模型学到的只是「能处理长输入」而不是「能利用长输入」。很多团队扩完长度发现效果不对，排查半天位置编码，最后发现是长文本数据太稀。

4.4 对齐阶段：GRPO 省掉了那个最贵的组件

SFT 用了约 1.5M 条会话数据，覆盖数学、代码、写作、推理、安全等方向。强化学习阶段用的是 GRPO，思路可以浓缩成一段伪代码：

# GRPO：同一 prompt 采样 G 条回复，用组内统计量做优势归一化 for prompt in batch: outs = policy.generate(prompt, num_samples=G) # G 条采样 rewards = reward_model(outs) # 每条一个标量奖励 adv = (rewards - rewards.mean()) / (rewards.std() + 1e-8) # 组内归一化 loss = -(ratio * adv).mean() + beta * kl_penalty # ratio 为重要性采样比

关键在于adv的计算方式。PPO 需要一个和策略模型同规模的 value 网络来估计基线，显存和训练成本都翻倍；GRPO 直接用同一 prompt 下 G 条采样奖励的均值和标准差做归一化，把 critic 整个省掉。这个改动在大模型 RL 里意义很大——省下的不只是显存，还有 critic 训不准带来的方差问题。G的取值要在方差和采样成本之间权衡，太小归一化噪声大，太大单步开销高。

5. 部署排查：MLA 与 MoE 落地时最容易翻车的五个地方

5.1 换成 MLA 之后显存没降

现象：按论文改完注意力结构，单请求显存占用几乎没变，长上下文仍然 OOM。

原因：缓存写错了对象。实现里为了省事，把上投影之后的完整k、v张量塞进了 cache，而c_kv只是中间变量。这样一来缓存量还是 $2 n_h d_h$，压缩白做。

解决：cache 里只存c_kv和承载 RoPE 的那一小段k_rope，上投影放到 attention 计算时现算，或者干脆把 $W_{UK}$、$W_{UV}$ 预先吸收进 $W_Q$、$W_O$，让展开这一步彻底消失。改完之后拿 2.1 节的脚本重新算一遍单请求字节数，和理论值对上了再往下走。

5.2 RoPE 加在错误的位置，长文本能力断崖

现象：短文本表现正常，超过一定长度后困惑度暴涨，检索类任务几乎失效。

原因：RoPE 被直接施加在低秩压缩后的潜向量上，或者先旋转再压缩，导致位置信息与内容信息纠缠，矩阵吸收的前提被破坏，同时位置编码的周期性也被压缩矩阵混合掉。

解决：严格按解耦方案拆成两路。内容路走低秩压缩，不碰 RoPE；位置路单独用一个小维度承接旋转，且这一路在所有头之间共享。检查方法很简单：把位置路整个置零，模型应该退化成长文本能力丧失但短文本尚可，这说明两路确实是解耦的。

5.3 专家利用率严重倾斜

现象：训练 loss 曲线看着正常，但统计下来少数几个专家承担了绝大部分 token，其余专家几乎不更新，模型效果比同参数稠密模型还差。

原因：路由塌缩。要么辅助损失系数给小了，要么只加了专家级损失、没加设备级和通信级损失，导致设备间负载也失衡，进一步放大专家倾斜。

解决：三层平衡损失都要有，系数从一个小量级开始逐步调；监控每个专家的 token 计数分布，而不只看总 loss。如果倾斜发生在训练早期，宁可加大辅助损失把分布拉开，也不要指望后期自己纠正——这个坑一旦踩进去基本没有后悔药。

5.4 多机训练吞吐上不去，GPU 大量空等

现象：单机跑得好好的，扩到多机后线性加速比严重不达标，profiler 显示大量时间花在通信等待上。

原因：路由没有做设备限制，每个 token 的 top-K 专家散布在所有设备上，all-to-all 的报文数和设备数成正比；同时通信没有和计算重叠，变成了串行。

解决：先上设备受限路由，把top_m压到 3 左右，通信量立刻有了上界；再把 all-to-all 拆成发送、计算、接收三段做流水，让通信藏在计算后面。注意top_m压太小会影响模型质量，这个参数要在吞吐和质量之间扫一遍。

5.5 推理时 token 被静默丢弃

现象：线上服务的输出质量比离线评测差一截，尤其是长尾输入，但日志里没有任何报错。

原因：训练时设的专家容量上限被带到了推理路径上，长尾输入触发了 token dropping，被丢的 token 只保留残差、不带专家输出，质量悄悄下降，而且不报错——这是个典型的黑匣子问题。

解决：推理路径上关掉 dropping，或者把容量因子调到足够大；如果显存顶不住，改成按请求动态分配容量。上线前做一次带丢弃统计的对拍，把丢弃率作为监控指标挂上去，别等用户反馈才发现。

6. 设计取舍：MLA、GQA 与 MQA 的边界到底在哪里

把四种注意力机制放在一起看，取舍关系就非常清楚了。

GQA 和 MQA 的思路是「减少头的数量」，本质上是砍表达能力换显存；MLA 的思路是「压缩每个头的表示」，用低秩约束换显存，同时靠低秩正则把表达能力补回来。前者是减法，后者是换维。这就解释了为什么 MLA 能在 cache 更小的同时性能不降——它不是在同一维度上做取舍，而是换了一个参数化方式。

但这个方案不是没有代价。MLA 的实现复杂度明显高于 GQA：解耦 RoPE 要求模型结构里预留一条独立分支，矩阵吸收要求推理引擎理解「潜向量直接参与 attention」这种非标准的数据流，主流的推理框架要么改 kernel，要么退回展开模式、牺牲一部分收益。相比之下 GQA 在几乎所有框架里都是开箱即用的。所以选型时不能只看论文里的数字，要看团队有没有能力把这条非标准路径落到 kernel 层。

MoE 侧的取舍同理。稀疏度越高，同等算力下的模型容量越大，但路由复杂度、通信开销、负载均衡难度一起上升。细粒度专家把组合空间做大了，也把通信报文数做多了；设备受限路由把通信上界锁死了，也牺牲了一部分路由自由度。这些参数没有普适最优解，只能针对具体的硬件拓扑和 batch 规模去扫。

想验证一个 MLA 实现是否正确，我一般会走三步：第一步，用 2.1 节的脚本核对单请求 KV cache 字节数是否和公式吻合，对不上说明缓存对象错了；第二步，把矩阵吸收开关打开和关闭，两种路径的输出差值应该在数值误差范围内，差得多说明吸收的矩阵乘顺序或者头的切分搞错了；第三步，构造一个明显依赖长距离位置的检索任务，长度从 4K 扫到 128K，看曲线是否平滑下降而不是断崖，断崖就回去查解耦 RoPE 那一路。

从那以后我每次评估一个新的注意力变体，都强制先拿公式把单 token、单层的缓存量算一遍，再谈精度和吞吐——因为这个数一旦算错，后面所有的 benchmark 对比都建立在错误的前提上，白忙一场。这份论文里 MLA 和 DeepSeekMoE 的完整推导、消融对比和实现细节，值得逐节对着公式读一遍，尤其是附录里 MHA/GQA/MQA 的对照实验，能把「为什么必须换维而不是减头」这件事讲透。希望帮到你。

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