DeepSeek-V2拆解：MLA与MoE如何把KV缓存压降93.3%

简介：DeepSeek-V2论文PDF面向大模型研究、MoE架构设计与推理优化方向的开发者与研究人员，聚焦如何在控制训练成本的同时提升模型性能与推理效率。资源为1个PDF文件，包体约1.5MB，便于直接查阅与归档。论文围绕236B总参数、每token激活21B、128K上下文长度的DeepSeek-V2展开，系统介绍Multi-head Latent Attention与DeepSeekMoE两项关键架构，并说明其如何压缩KV缓存、降低训练开销。文中还给出8.1万亿token预训练、SFT与强化学习流程，以及与DeepSeek 67B的对比数据：训练成本节省42.5%、KV缓存减少93.3%、最大生成吞吐量提升至5.76倍，并附开源检查点线索。已有294人学习，适合需要深入理解MoE大模型设计取舍、成本优化和性能评估的读者参考。

1. DeepSeek-V2 论文公开：21B 激活参数为什么成了 MoE 的一条分界线

2024 年 6 月公开的 DeepSeek-V2 论文，英文标题译过来很朴素：一个强、经济、高效的混合专家语言模型。真正让工程团队坐直的不是「强」这个形容词，而是后面两个词被写成了可核对的数字——236B 总参数下每个 token 只激活 21B，训练成本比上一代 67B 稠密模型低 42.5%，推理时 KV 缓存压掉 93.3%，最大生成吞吐抬到 5.76 倍。一组改动同时落在训练和推理两端，这在当时的开源模型里并不常见。对做推理服务的人，它意味着单机装得下的上下文变长了；对做训练的人，它意味着同样的卡数能多跑几轮实验。下面把这份论文拆成三件事：架构上改了什么、成本省在哪、谁先受益。

2. 架构拆解：MLA 与 DeepSeekMoE 各自动了哪块地基

2.1 从 MHA 到 MLA：把 KV 缓存压成一个潜向量

标准多头注意力的瓶颈不在算力，在显存。生成阶段每个 token 的 key 和 value 都要留在显存里，供后续 token 查表，论文给出的量级是 2·n_h·d_h·l 个元素，随头数和层数线性增长。批量一开大、上下文一拉长，KV 缓存往往先于算力把卡占满，最大 batch size 和序列长度都卡在它上面。

业界的常规解法是砍头。MQA 让所有注意力头共享一组 KV，GQA 折中成分组共享，缓存确实小了，但论文附录 C.1 的消融结论很直接：这两条路的效果都追不上 MHA——省的是显存，亏的是质量。真正要做的是找一个既不牺牲效果、又能把缓存压下去的结构。

MLA 的解法是低秩联合压缩。它不直接缓存完整的 K 和 V，而是先把隐状态 h_t 下投影成一个低维潜向量 c_t，推理时只缓存这个 c_t；需要 K、V 时再用上投影矩阵还原。缓存元素数量从 2·n_h·d_h·l 变成 d_c·l，其中 d_c 远小于 n_h·d_h。用代码表达这个压缩动作，结构相当简洁：

import torch import torch.nn as nn class LatentKVCompression(nn.Module): """MLA 键值低秩联合压缩的最小示意。""" def __init__(self, d_model: int, kv_rank: int): super().__init__() # 下投影：把每个 token 的隐状态压到低维潜空间 d_c self.down_proj = nn.Linear(d_model, kv_rank, bias=False) # 上投影：还原 K / V，训练时需要显式计算，推理时可与 W_Q / W_O 融合 self.up_k = nn.Linear(kv_rank, d_model, bias=False) self.up_v = nn.Linear(kv_rank, d_model, bias=False) def forward(self, h: torch.Tensor, cache: torch.Tensor | None = None): # h: [batch, seq_len, d_model] c_kv = self.down_proj(h) # [batch, seq_len, kv_rank] if cache is not None: # 推理时只把潜向量追加进缓存，不缓存完整的 K、V c_kv = torch.cat([cache, c_kv], dim=1) return c_kv

参数含义值得逐一说清：d_model是隐层维度，kv_rank就是论文里的压缩维度 d_c，取值远小于 n_h·d_h；cache是已经生成的潜向量序列，按 token 逐个追加。这段代码省略了位置编码与分头逻辑，只保留了「缓存的是低维潜向量而不是完整 KV」这一条核心事实。

更关键的是下一步。论文指出上投影矩阵 W_UK 可以吸收进查询投影 W_Q，W_UV 可以吸收进输出投影 W_O，因此推理时根本不需要把 K 和 V 显式还原出来，直接在潜空间完成部分计算。这解释了为什么 KV 缓存能降 93.3% 这个量级——省下的是整条 KV 通路的驻留开销，不是靠量化或稀疏化抠出来的零头。

MLA 还处理了两个容易被忽略的工程细节。一是查询侧也做低秩压缩，虽然不减少 KV 缓存，但能降低训练时的激活内存占用；二是解耦式旋转位置编码，因为 RoPE 与低秩联合压缩在维度上并不天然兼容，论文为此设计了单独承载位置信息的分支。这两处改动在架构图上是两个小方块，落地时却直接决定能不能训得动。

提示：读 MLA 时不要只看缓存压缩比，要同时看它在论文附录里相对 MHA 的效果对比。压缩比再漂亮，如果效果掉下来，服务端省下的显存会被质量返工吃掉。

2.2 DeepSeekMoE：细粒度专家与共享专家的成本账

注意力层之外，第二块地基是前馈网络的稀疏化。DeepSeekMoE 的核心是两条设计：细粒度专家切分与共享专家隔离。前者把专家的粒度切得更细、数量更多，让每个专家有更强的特化空间；后者固定一批每次都会被激活的共享专家，用来承接通用知识，避免路由专家重复学习同样的东西。

这个设计的意义在于参数效率。MoE 的传统难题是专家同质化——路由看似分流了，实际每个专家学到的内容高度重叠，总参数上去了，有效容量没上去。细粒度加共享专家，本质是在结构上逼迫路由专家分工：通用部分交给共享专家兜底，路由专家只负责专精。

但 MoE 训练的真正难点从来不在架构图，在通信。论文为此补了三个工程机制，这部分往往被读者跳过，却是「经济」二字的由来：

• 设备受限路由：每个 token 只能被路由到有限数量的设备上，避免一个 token 的专家散落到所有节点，触发 all-to-all 通信风暴。在专家并行下，这是控制跨节点流量的阀门。
• 负载均衡辅助损失：给路由加约束项，防止流量塌缩到少数几个专家上。塌缩一旦发生，等于花 236B 的钱只用了其中一小部分，训练曲线看起来正常，实际容量白白浪费，属于典型的黑匣子式翻车。
• Token 丢弃策略：给每个专家设容量上限，超出部分在训练时丢弃。用极小的样本损失换吞吐稳定，是工程上的取舍而非理论上的最优。

这三条的作用是让稀疏激活在真实集群上跑得起来。从行业角度看，MoE 论文里最容易翻车的从来不是数学推导，而是路由与并行的配合——同一套结构，通信策略差一点，吞吐能差出数倍。

2.3 两个改动叠在一起，才有 5.76 倍吞吐

把 MLA 和 DeepSeekMoE 分开看，各自都不算石破天惊；叠在一起，才是论文那句「strong、economical、efficient」的完整含义。

MLA 解决的是推理侧的内存墙：每 token 的 KV 缓存变小，单卡能承载的 batch 和上下文同步变大，单位时间能吐出的 token 数随之上升。DeepSeekMoE 解决的是训练侧的算力墙：每 token 只走 21B 参数，同样规模的集群能处理更多 token。一个管生成阶段，一个管训练阶段，两条曲线在论文图 1(b) 里被画在同一张散点图上，横轴是激活参数量，纵轴分别对应训练成本与生成吞吐。

这里有个容易被跳过的因果链：如果只做 MLA 不做 MoE，模型仍是稠密结构，每 token 的计算量降不下来，训练成本省不了 42.5%；如果只做 MoE 不做 MLA，稀疏化让计算变便宜了，但 KV 缓存仍是按稠密头的规模增长，长上下文场景照样被显存卡死。5.76 倍的最大生成吞吐，是长上下文能力、缓存压缩、稀疏计算三者共同作用的产物，而不是某一个模块的单独功劳。

理解了这一层，再去看后面所有关于「MoE 省钱」的讨论，才不会把账算错——省下来的钱分别来自哪一段流水线，对应的复用条件完全不同。

3. 数字背后：42.5%、93.3%、5.76 倍分别在说什么

3.1 8.1T token 语料与 1.5M 对话样本的配比逻辑

论文披露的预训练语料规模是 8.1T token，高质量、多来源，相比上一代 67B 所用的语料，数据量有扩展，中文数据占比提升，整体质量更高。这个数字和 21B 的激活参数放在一起看，比例相当激进：按激活参数摊，每个激活参数分到的训练 token 数量不低。对比行业惯例，这条路线的取向很清楚——把参数规模压在「够用」的量级，把预算挪到数据上。

对齐阶段的数据是另一个口径：150 万条对话会话，覆盖数学、代码、写作、推理、安全等多个领域，用于有监督微调；随后用强化学习进一步对齐人类偏好。1.5M 这个量级放在今天不算夸张，但它的领域配比是有讲究的——论文明确点出的几个方向，恰好是当时开源模型最容易掉链子的方向，尤其是数学与代码这类需要长链条推理的任务。

注意：8.1T 是预训练 token 总量，1.5M 是 SFT 会话条数，两者单位不同，不能直接比较。看论文时把预训练、SFT、RL 三个阶段的数据规模分开记，混淆是常见误读的起点。

从工程视角看，这套配比透露的信号是：稀疏模型的容量要靠数据喂饱，否则多出来的专家就是闲置资产。很多团队做 MoE 时把注意力全放在路由算法上，语料规模和质量没跟上，最后得到的是一个参数很多、效果平平的模型。

3.2 横向坐标：和上一代稠密模型比，差在哪一段

论文给出的对比集中在三个可量化维度上。把上一代 67B 稠密模型作为基准，DeepSeek-V2 的位置可以整理成这样：

表格里「基准」两字要读准：42.5%、93.3%、5.76 倍都是相对自家上一代稠密模型的口径，不是相对任意模型的通用常数。换一套硬件、换一种并行策略、换一个上下文长度，这几个比例都会漂移。

论文图 1(a) 用的是另一套坐标：横轴激活参数，纵轴 MMLU 准确率。DeepSeek-V2 落在一个「激活参数很小但准确率靠前」的位置上，这张图想说明的是参数效率，而不是绝对分数。图 1(b) 则把训练成本与每 token KV 缓存、最大生成吞吐放在同一个坐标系里横向铺开，覆盖了同代多个开源稠密模型与 MoE 模型。从行业角度看，这类散点图比单一榜单更有信息量——它同时暴露了「花多少钱」和「跑多快」两个维度，而多数评测只报效果。

还有一组对比容易被忽略：论文附录给了 MHA、GQA、MQA 三者的消融。结论是 MQA 与 GQA 在缓存更小的同时效果不及 MHA，而 MLA 在缓存显著更小的前提下效果优于 MHA。这句话的分量在于，它把「省显存」和「保效果」之间那个长期存在的取舍给拆掉了，这才是后续一堆模型跟进改注意力结构的直接原因。

3.3 谁先受益：推理侧成本敏感的场景会先动

论文的数字落到业务上，受益顺序并不均匀。最先动的一定是对单位 token 成本最敏感、同时对上下文长度有硬需求的场景。

第一类是长文档处理。128K 上下文配上压缩后的 KV 缓存，意味着同样的显存能撑住更长的输入或更大的并发批次。合同比对、财报抽取、长代码库理解这类任务，过去常靠切块加重排绕过去，切块本身就损失跨段落信息，现在可以整篇塞进去。

第二类是高频调用的批处理场景。最大生成吞吐提升到 5.76 倍，摊到每次调用的成本就下来了。数据清洗、批量打标、内容初筛这类「量大、单次价值低」的任务，成本曲线一变，原本不划算的自动化方案就划算了。

第三类是对首 token 延迟敏感的交互产品。KV 缓存压缩直接缓解的是显存带宽压力，长会话下的响应衰减会明显好转。真实的用户抱怨往往不是模型不够聪明，而是聊到二十轮之后开始卡，这类问题靠换更大的模型解决不了，得靠缓存结构。

反过来说，短期内不太会受益的是那些对绝对效果要求极高、且上下文很短的场景。稀疏激活在短输入下的优势不明显，MLA 的收益也主要体现在长序列与高并发上。判断自己该不该跟进，先算清楚业务里 KV 缓存占总显存的比例，这个比例决定了收益上限。

4. 常见误读：MoE 省钱这件事被读歪的四个地方

4.1 误读一：236B 总参数就等于 236B 的算力开销

误判点：看到 236B 总参数，第一反应是「这模型太大，跑不动」，或者反过来，看到 21B 激活参数，就以为成本只按 21B 算。

为什么：MoE 的两笔账性质完全不同。算力账按激活参数走，每 token 只经过 21B 参数，这是稀疏计算省下来的部分；显存账要按总参数走，所有专家的权重都得驻留在显存里（或按层、按专家分片放在多卡上），并不能因为这次没用上就不占地方。两个数字描述的是不同资源，混在一起算必然出错。

怎么看：把部署预算拆成「权重驻留」和「单 token 计算」两行分别估算。前者的量级由 236B 决定，后者的量级由 21B 决定。做容量规划时按前者买卡，做吞吐估算时按后者算力。任何一份只说一个数字的评测，都不足以支撑采购决策。

4.2 误读二：KV 缓存降 93.3% 就等于显存占用降 93.3%

误判点：把 93.3% 直接套到整卡显存上，得出「原来要 8 张卡，现在半张就够」的结论。

为什么：KV 缓存只是显存占用的一部分，同一块卡上还住着模型权重、激活值、临时缓冲、框架自身的开销。而且 93.3% 是相对上一代 67B 的特定配置算出来的比例，它取决于层数、头数、头维度、压缩维度这几个超参，换一个模型规格，比例就会变。上下文越长、并发越高，KV 在总显存里的占比越大，收益越接近这个数；短上下文低并发时，收益会被其他开销稀释。

怎么看：先量出自己场景下 KV 缓存占总显存的实际比例，再乘上压缩比估收益。长上下文高并发的服务，这个比例可能过半，收益显著；短请求为主的服务，比例可能只有一两成，收益就没那么夸张。用一段代码把这个账算清楚，比拍脑袋可靠：

# 按论文口径估算每 token 的 KV 缓存元素数，用于比较不同注意力结构 def kv_elements_per_token(layers: int, heads: int, head_dim: int) -> int: # MHA：每层缓存 K 与 V，各 heads * head_dim 个元素 return layers * 2 * heads * head_dim def kv_elements_per_token_mla(layers: int, kv_rank: int) -> int: # MLA：每层只缓存一个压缩后的潜向量 return layers * kv_rank # 代入具体超参即可得到比值，注意这只算 KV 部分，不含权重与激活

三个参数分别对应层数、注意力头数、每头维度；MLA 版本只需要层数与压缩维度。算出来的元素数乘上数据类型字节数，才是真正的缓存体积。这段估算不含分页、对齐与碎片，实际占用会略高，但用来判断量级足够。

4.3 误读三：21B 激活参数意味着单卡就能跑起来

误判点：把激活参数当成模型体积，认为 21B 级别一张卡就能装下，于是按 21B 的规格准备硬件。

为什么：激活参数决定的是「算多少」，不是「装多少」。权重驻留依旧按 236B 走，加上 128K 上下文下的 KV 缓存、框架运行时开销，真实显存需求远高于 21B 模型。此外长上下文推理的显存峰值往往出现在预填充阶段，那一刻的激活值占用比解码阶段高得多。

怎么看：把「能装下」和「能跑快」分开评估。装得下看总参数加 KV 峰值，跑得快看激活参数加显存带宽。中间还有一个常被漏掉的变量：并行切分方式。专家并行、张量并行、流水并行的组合不同，卡间通信开销差别很大，同样的卡数能跑出的吞吐可能差一截。稳妥做法是先按总参数规划卡数，再用激活参数估吞吐，最后留出长上下文的峰值余量。

4.4 误读四：训练成本降 42.5% 意味着小团队也能复现

误判点：把 42.5% 读成「门槛降了一半」，进而认为中等规模团队可以自己训一个同级别模型。

为什么：42.5% 是相对自家上一代稠密模型的口径，绝对量仍然是集群级别的投入。更关键的是，省钱的前提是你已经具备那套工程能力：专家并行的通信优化、设备受限路由的调参、负载均衡辅助损失的权重设置、token 丢弃策略的容量设定。这些细节在论文里只占几行，实际调起来是漫长的血泪经验，任何一处没调好，省下来的成本会以训练不收敛的形式加倍还回去。数据侧的投入同样不可忽略——8.1T token 的清洗、去重、配比，本身就是一个独立的大工程。

怎么看：把 42.5% 换算成「同预算下多跑约 1.7 倍实验」更贴近实际含义（1 ÷ (1 − 0.425) ≈ 1.74）。它是给已有训练能力的团队提效率的，不是给没有训练能力的团队发入场券的。对多数团队，更现实的路径是基于公开检查点做继续训练或蒸馏，而不是从零复现。

5. 对齐与评测：38.9 的胜率是怎么攒出来的

5.1 两段式对齐：SFT 打底，GRPO 收口

论文的对齐流程是标准的两段式。第一段是有监督微调，用 150 万条覆盖数学、代码、写作、推理、安全等领域的会话数据，把预训练底座的能力引导到对话形态上。第二段是强化学习，沿用同系列数学模型的 GRPO 方法，用组内相对优势替代独立的价值网络，降低 RL 阶段的显存与调参负担。

这个组合的关键在于分工。SFT 决定模型「会说什么」，包括格式、语气、拒答边界；RL 决定模型「倾向说什么」，把人类偏好里那些难以用监督信号表达的部分（比如简洁、条理、不啰嗦）压进策略里。两段之间任何一段掉链子，最终效果都会打折——SFT 数据领域覆盖不全，RL 阶段再怎么调也补不回来；RL 的奖励设计有偏，模型会学会讨好评分器而不是解决问题。

从行业角度看，对齐阶段的成本占比在上升。预训练是算力密集型，对齐是数据与实验密集型，后者对团队的隐性要求更高：需要能持续产出高质量偏好数据，需要稳定的训练框架支撑多轮 RL，需要对奖励信号做持续校准。这部分工作量在论文里往往只有一节，实际投入却常常超过预期。

5.2 评测坐标：三个指标各自在测什么

论文给出的三个对齐后指标，口径差别很大，放在一起看才有意义：

把这三个数放在当时的开源模型里比，结论是英文开放式对话处于头部区间，中文场景则更强——论文明确写到，在中文上超过所有开源模型，且优于多数闭源模型。这个结论和语料构成是自洽的：预训练阶段中文数据量相比上一代明显扩展，对齐数据里中文场景的覆盖也更足。

需要提醒的是评测的边界。长度控制胜率解决的是长度偏置，解决不了「裁判偏好某类文风」的问题；MT-Bench 的高分也不等于事实准确性高。真实业务里的失败案例，大多不是这些榜单能测出来的——多轮上下文遗忘、指令冲突、边界条件处理，这些得靠自己的评测集。

5.3 被低估的一环：对齐阶段的数据工程

论文里关于 SFT 数据的描述只有一句话的篇幅：150 万条会话，覆盖多个领域。这句话背后的工作量，是整份论文里最难复现的部分。

领域配比怎么定，直接决定模型的能力分布。数学和代码给多了，通用对话会变得生硬；写作给多了，推理链条容易松散。安全数据怎么放，决定拒答边界的位置——放太少，该拒的不拒；放太多，正常问题也被挡回去。这些都没有普适答案，只能对着自己的目标场景反复试。

提示：如果打算基于公开检查点做继续训练，优先补的是自己业务领域的高质量会话数据，而不是无差别堆量。150 万条这个量级，靠堆通用数据凑出来容易，靠堆领域数据凑出来难，后者才是差异化的地方。

RL 阶段同样如此。奖励信号的稳定性、训练轮次的把控、退化现象的监控，每一项都需要工程投入。论文能给出方法和结果，给不出调参过程中的取舍记录，这部分只能自己踩。

6. 效率竞赛的下一段：三条值得盯住的观察线

第一条线是注意力结构的「缓存效率」竞赛。MLA 之后，单纯用 GQA 做默认解的时代基本结束了，因为论文附录的消融已经把话说清楚：GQA 和 MQA 在减小缓存的同时牺牲了效果，而低秩联合压缩能同时拿到两头。后续一段时间的模型架构讨论，大概率会围绕「怎么在潜空间里做注意力」展开，压缩维度怎么选、位置编码怎么解耦，这些细节会从附录走进正文。

第二条线是 MoE 的工程细节权重上升。拓扑图谁都能画，决定成败的是路由与并行的配合：设备受限路由的阈值、辅助损失的系数、token 丢弃的容量上限。这三个参数没有通用最优值，只能跟着集群规模和并行策略调。判断一个团队有没有真做过 MoE，问这三个参数怎么定，比问架构图长什么样有效得多。

第三条线是对齐成本占比继续走高。预训练阶段靠算力和数据规模，边际改进越来越贵；对齐阶段靠数据质量和实验迭代，投入产出比反而更可观。对中小团队来说，这意味着一个现实的机会窗口——底座用公开检查点，把资源集中在领域对齐上，比从头训一个模型划算得多。

落到具体动作上，不同角色的优先级并不一样：

从我自己的习惯说起。早些年看 MoE 论文，我第一反应总是去比对参数规模和榜单分数，结果在实际评估部署方案时反复踩坑——把激活参数当成显存需求，把相对比例当成通用常数，把论文里的省钱口径直接套到自己的业务上。后来我给自己定了一条硬规矩：每读一篇效率类论文，先把「显存账」和「算力账」分成两列写下来，再单独列一列「这些数字的相对基准是谁」。三列对不上，说明还没读懂，先别急着做技术选型。这份论文值得完整读一遍的地方，不在结论，在附录里那几组消融和架构对比——它们才是判断「这套东西能不能搬到我的场景」的依据。希望帮到你。

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