简介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 让所有注意力头共享一组 KVGQA 折中成分组共享缓存确实小了但论文附录 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, biasFalse) # 上投影还原 K / V训练时需要显式计算推理时可与 W_Q / W_O 融合 self.up_k nn.Linear(kv_rank, d_model, biasFalse) self.up_v nn.Linear(kv_rank, d_model, biasFalse) 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], dim1) return c_kv参数含义值得逐一说清d_model是隐层维度kv_rank就是论文里的压缩维度 d_c取值远小于 n_h·d_hcache是已经生成的潜向量序列按 token 逐个追加。这段代码省略了位置编码与分头逻辑只保留了「缓存的是低维潜向量而不是完整 KV」这一条核心事实。更关键的是下一步。论文指出上投影矩阵 W_UK 可以吸收进查询投影 W_QW_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 的位置可以整理成这样对比项上一代 67B 稠密模型DeepSeek-V2论文口径总参数67B236B全部专家权重之和每 token 激活参数67B21B稀疏激活约三成不到上下文长度正文未做同口径对比128K token长上下文扩展后训练成本基准降低 42.5%图 1(b)按每万亿 token 的 GPU 小时计每 token KV 缓存基准降低 93.3%MLA 压缩后最大生成吞吐基准提升至 5.76 倍同口径生成吞吐表格里「基准」两字要读准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 评测坐标三个指标各自在测什么论文给出的三个对齐后指标口径差别很大放在一起看才有意义指标数值测的是什么读的时候注意什么AlpacaEval 2.0 长度控制胜率38.9开放式对话中相对基线的胜率长度控制是为了消除「答得越长越容易赢」的偏置MT-Bench 综合分8.97多轮对话的裁判打分裁判模型本身有偏好分数适合横向比不适合当绝对能力AlignBench 综合分7.91偏中文场景的对齐质量中文表现是这份论文的强项区间把这三个数放在当时的开源模型里比结论是英文开放式对话处于头部区间中文场景则更强——论文明确写到在中文上超过所有开源模型且优于多数闭源模型。这个结论和语料构成是自洽的预训练阶段中文数据量相比上一代明显扩展对齐数据里中文场景的覆盖也更足。需要提醒的是评测的边界。长度控制胜率解决的是长度偏置解决不了「裁判偏好某类文风」的问题MT-Bench 的高分也不等于事实准确性高。真实业务里的失败案例大多不是这些榜单能测出来的——多轮上下文遗忘、指令冲突、边界条件处理这些得靠自己的评测集。5.3 被低估的一环对齐阶段的数据工程论文里关于 SFT 数据的描述只有一句话的篇幅150 万条会话覆盖多个领域。这句话背后的工作量是整份论文里最难复现的部分。领域配比怎么定直接决定模型的能力分布。数学和代码给多了通用对话会变得生硬写作给多了推理链条容易松散。安全数据怎么放决定拒答边界的位置——放太少该拒的不拒放太多正常问题也被挡回去。这些都没有普适答案只能对着自己的目标场景反复试。提示如果打算基于公开检查点做继续训练优先补的是自己业务领域的高质量会话数据而不是无差别堆量。150 万条这个量级靠堆通用数据凑出来容易靠堆领域数据凑出来难后者才是差异化的地方。RL 阶段同样如此。奖励信号的稳定性、训练轮次的把控、退化现象的监控每一项都需要工程投入。论文能给出方法和结果给不出调参过程中的取舍记录这部分只能自己踩。6. 效率竞赛的下一段三条值得盯住的观察线第一条线是注意力结构的「缓存效率」竞赛。MLA 之后单纯用 GQA 做默认解的时代基本结束了因为论文附录的消融已经把话说清楚GQA 和 MQA 在减小缓存的同时牺牲了效果而低秩联合压缩能同时拿到两头。后续一段时间的模型架构讨论大概率会围绕「怎么在潜空间里做注意力」展开压缩维度怎么选、位置编码怎么解耦这些细节会从附录走进正文。第二条线是 MoE 的工程细节权重上升。拓扑图谁都能画决定成败的是路由与并行的配合设备受限路由的阈值、辅助损失的系数、token 丢弃的容量上限。这三个参数没有通用最优值只能跟着集群规模和并行策略调。判断一个团队有没有真做过 MoE问这三个参数怎么定比问架构图长什么样有效得多。第三条线是对齐成本占比继续走高。预训练阶段靠算力和数据规模边际改进越来越贵对齐阶段靠数据质量和实验迭代投入产出比反而更可观。对中小团队来说这意味着一个现实的机会窗口——底座用公开检查点把资源集中在领域对齐上比从头训一个模型划算得多。落到具体动作上不同角色的优先级并不一样角色现在可以做的事依据推理服务先量 KV 缓存占总显存比例再判断结构改造收益每 token KV 缓存降 93.3%训练工程重点看专家并行的通信控制与路由限设备策略设备受限路由与负载均衡设计应用侧重估长上下文场景的成本尤其是批量调用128K 上下文与 5.76 倍吞吐算法研究把 MLA 的低秩压缩思路迁移到自家结构上验证消融显示其效果优于 MHA从我自己的习惯说起。早些年看 MoE 论文我第一反应总是去比对参数规模和榜单分数结果在实际评估部署方案时反复踩坑——把激活参数当成显存需求把相对比例当成通用常数把论文里的省钱口径直接套到自己的业务上。后来我给自己定了一条硬规矩每读一篇效率类论文先把「显存账」和「算力账」分成两列写下来再单独列一列「这些数字的相对基准是谁」。三列对不上说明还没读懂先别急着做技术选型。这份论文值得完整读一遍的地方不在结论在附录里那几组消融和架构对比——它们才是判断「这套东西能不能搬到我的场景」的依据。希望帮到你。本文还有配套的精品资源点击获取 
长河君 · 2026/10/26 18:01:47 · 阅读 1.2k 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 让所有注意力头共享一组 KVGQA 折中成分组共享缓存确实小了但论文附录 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, biasFalse) # 上投影还原 K / V训练时需要显式计算推理时可与 W_Q / W_O 融合 self.up_k nn.Linear(kv_rank, d_model, biasFalse) self.up_v nn.Linear(kv_rank, d_model, biasFalse) 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], dim1) return c_kv参数含义值得逐一说清d_model是隐层维度kv_rank就是论文里的压缩维度 d_c取值远小于 n_h·d_hcache是已经生成的潜向量序列按 token 逐个追加。这段代码省略了位置编码与分头逻辑只保留了「缓存的是低维潜向量而不是完整 KV」这一条核心事实。更关键的是下一步。论文指出上投影矩阵 W_UK 可以吸收进查询投影 W_QW_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 的位置可以整理成这样对比项上一代 67B 稠密模型DeepSeek-V2论文口径总参数67B236B全部专家权重之和每 token 激活参数67B21B稀疏激活约三成不到上下文长度正文未做同口径对比128K token长上下文扩展后训练成本基准降低 42.5%图 1(b)按每万亿 token 的 GPU 小时计每 token KV 缓存基准降低 93.3%MLA 压缩后最大生成吞吐基准提升至 5.76 倍同口径生成吞吐表格里「基准」两字要读准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 评测坐标三个指标各自在测什么论文给出的三个对齐后指标口径差别很大放在一起看才有意义指标数值测的是什么读的时候注意什么AlpacaEval 2.0 长度控制胜率38.9开放式对话中相对基线的胜率长度控制是为了消除「答得越长越容易赢」的偏置MT-Bench 综合分8.97多轮对话的裁判打分裁判模型本身有偏好分数适合横向比不适合当绝对能力AlignBench 综合分7.91偏中文场景的对齐质量中文表现是这份论文的强项区间把这三个数放在当时的开源模型里比结论是英文开放式对话处于头部区间中文场景则更强——论文明确写到在中文上超过所有开源模型且优于多数闭源模型。这个结论和语料构成是自洽的预训练阶段中文数据量相比上一代明显扩展对齐数据里中文场景的覆盖也更足。需要提醒的是评测的边界。长度控制胜率解决的是长度偏置解决不了「裁判偏好某类文风」的问题MT-Bench 的高分也不等于事实准确性高。真实业务里的失败案例大多不是这些榜单能测出来的——多轮上下文遗忘、指令冲突、边界条件处理这些得靠自己的评测集。5.3 被低估的一环对齐阶段的数据工程论文里关于 SFT 数据的描述只有一句话的篇幅150 万条会话覆盖多个领域。这句话背后的工作量是整份论文里最难复现的部分。领域配比怎么定直接决定模型的能力分布。数学和代码给多了通用对话会变得生硬写作给多了推理链条容易松散。安全数据怎么放决定拒答边界的位置——放太少该拒的不拒放太多正常问题也被挡回去。这些都没有普适答案只能对着自己的目标场景反复试。提示如果打算基于公开检查点做继续训练优先补的是自己业务领域的高质量会话数据而不是无差别堆量。150 万条这个量级靠堆通用数据凑出来容易靠堆领域数据凑出来难后者才是差异化的地方。RL 阶段同样如此。奖励信号的稳定性、训练轮次的把控、退化现象的监控每一项都需要工程投入。论文能给出方法和结果给不出调参过程中的取舍记录这部分只能自己踩。6. 效率竞赛的下一段三条值得盯住的观察线第一条线是注意力结构的「缓存效率」竞赛。MLA 之后单纯用 GQA 做默认解的时代基本结束了因为论文附录的消融已经把话说清楚GQA 和 MQA 在减小缓存的同时牺牲了效果而低秩联合压缩能同时拿到两头。后续一段时间的模型架构讨论大概率会围绕「怎么在潜空间里做注意力」展开压缩维度怎么选、位置编码怎么解耦这些细节会从附录走进正文。第二条线是 MoE 的工程细节权重上升。拓扑图谁都能画决定成败的是路由与并行的配合设备受限路由的阈值、辅助损失的系数、token 丢弃的容量上限。这三个参数没有通用最优值只能跟着集群规模和并行策略调。判断一个团队有没有真做过 MoE问这三个参数怎么定比问架构图长什么样有效得多。第三条线是对齐成本占比继续走高。预训练阶段靠算力和数据规模边际改进越来越贵对齐阶段靠数据质量和实验迭代投入产出比反而更可观。对中小团队来说这意味着一个现实的机会窗口——底座用公开检查点把资源集中在领域对齐上比从头训一个模型划算得多。落到具体动作上不同角色的优先级并不一样角色现在可以做的事依据推理服务先量 KV 缓存占总显存比例再判断结构改造收益每 token KV 缓存降 93.3%训练工程重点看专家并行的通信控制与路由限设备策略设备受限路由与负载均衡设计应用侧重估长上下文场景的成本尤其是批量调用128K 上下文与 5.76 倍吞吐算法研究把 MLA 的低秩压缩思路迁移到自家结构上验证消融显示其效果优于 MHA从我自己的习惯说起。早些年看 MoE 论文我第一反应总是去比对参数规模和榜单分数结果在实际评估部署方案时反复踩坑——把激活参数当成显存需求把相对比例当成通用常数把论文里的省钱口径直接套到自己的业务上。后来我给自己定了一条硬规矩每读一篇效率类论文先把「显存账」和「算力账」分成两列写下来再单独列一列「这些数字的相对基准是谁」。三列对不上说明还没读懂先别急着做技术选型。这份论文值得完整读一遍的地方不在结论在附录里那几组消融和架构对比——它们才是判断「这套东西能不能搬到我的场景」的依据。希望帮到你。本文还有配套的精品资源点击获取