deepseek-tech-notes · 中文导读

丝滑阅读 × 深度拆解 × 前沿跟进 — 非官方 DeepSeek 技术笔记（V1→V4）。与 DeepSeek 官方无隶属关系。

Smooth, deep notes on frontier DeepSeek tech. Unofficial; not affiliated with DeepSeek.

← English homepage

在线成书

推荐阅读

本笔记是双向引用 wiki：文首有反向回链，文内有正向深入链接。要发挥这套导航的价值，请用下面两种方式之一——不要用 GitHub 仓库内的 blob 预览。

小结：本地 IDE Preview 与 Pages 二选一即可；编辑与 PR 仍在本仓库 docs/ 进行。

善意提醒：正文里的 SVG 插图下方，通常都有 「图示详情」 链接——点进去可在新页查看可缩放的原图。不少机制就写在图里的箭头、分区与小字标注里，值得放慢节奏、仔细品读。

项目仍在完善中：梗概补全、书中镜像、链接与图示校验仍在推进。阅读时请以各篇文首的 arXiv / 官方 PDF 为准；发现断链、口径不一致或表述错误，欢迎提 issue。

这个项目在做什么

我从 DeepSeek V1 技术报告 一路跟到 V4，并把大部分主要技术文章里的机制与细节拆开写清楚：架构怎么变、训练/推理在优化什么、版本之间如何衔接。

范围包括：

• DeepSeek 主线（见 算法线 · MoE 线）：MLA、DeepSeekMoE、aux-loss-free 路由、MTP、RLVR / R1、DSA、CSA / HCA、mHC、Hash MoE、V4 异构 KV 等。
• V4 及衍生的推理技术（见 基础设施线）：如 DSpark 投机解码（半自回归 draft + 置信度调度验证）、HiSparse、磁盘 Prefix Cache 等。
• 叠在 DeepSeek checkpoint 上的衍生工作——尤其 AI Infrastructure 向：
• Index Share / IndexCache（清华 + 智谱）：跨层复用 DSA indexer 的 top-$k$ index，纯推理补丁；逻辑详解
• ESS（百度百舸）：Latent-Cache CPU offload，与 DSA 算法正交；论文梗概

演进

版本演进总览 — 全系列唯一主线入口：时间线 + 算法 / 基础设施 / MoE 三线；各版本与 infra 补丁的内链均从此文展开。

图示详情 · 与 演进总览 §1 对照阅读

图示详情 · RLVR / GRPO · R1

图示详情 · DSpark 投机解码 · MTP 融合 scheme

文章

许可

DeepSeek 论文、权重与官方代码库另有其许可；引用时请以 arXiv / 官方发布 为准。

DeepSeek 版本演进：V1 → V3 → V3.2 → V4，Index Share 与 KV-offload

更新：2026-06-25 ← 中文导读 · ← 仓库首页（EN） · V1→V3 前代演进

1. 总览

DeepSeek 开源主线分两段：

1. V1 → V2 → V3（2024）：稠密双语基座 → MLA + MoE → 671B 旗舰（详见 V1→V3 演进）
2. V3 之后（2025–2026）：R1 / V3.1 / V3.2 / V4 与 infra 补丁

V3 发布后的 Attention / KV infra 与全系列的 MoE 可概括为三条线：

1. 算法线：MLA → DSA 稀疏注意力 → CSA/HCA 混合压缩注意力 + mHC
2. 基础设施线：标准 MLA KV cache → Indexer/Latent 异构 cache → Index Share → ESS offload → V4 异构 KV + HiSparse
3. MoE 线：稠密 FFN → DeepSeekMoE → aux-loss-free 路由 + $L_{\mathrm{Bal}}$ → Hash MoE + FP4

1.1 各工作优化方向分类

下列 §3 版本 与 §4–§6 infra 中的每一项工作，按三条正交优化轴归类。多轴并存时给出 比例（合计 100%）；单列 100 表示该工作主要落在此轴。

图示详情

版本 / 工作一览：

版本级粗汇总：

读法：Index Share、ESS、DSpark 等 100% 架构-infer 的工作，与「改权重」的 V3.2 DSA、V4 CSA 可叠加部署；§5 KV-offload 三代与 §6 推理栈是 infer 轴的进一步展开。

1.2 Transformer 四模块演进

Raschka 第三方解读 §8 · 表 8-1 将 Transformer 拆成四条正交演进链；下表映射到本仓库版本节点（非 exhaustive，仅 DeepSeek 主线）：

读法：V3.2 的「唯一结构改动」几乎全在 Attention 轴（DSA）；V4 同时在 Attention（CSA/HCA）、残差（mHC）、FFN（Hash MoE）三轴打包升级；后训练（R1 RLVR）与 infer 补丁（Index Share / ESS / DSpark）不改变模块拓扑，见 §1.1。

延伸：Raschka 全文 §8 · mHC 专文 §1

图示详情

2. 版本时间线与关系

图示详情

图 2 补充：V1 · V2 · MLA · DeepSeekMoE · aux-loss-free · RLVR · DSA · Index Share · ESS · V4 · DSpark · mHC · 优化方向分类 §1.1 各节代表图：§3.1 scaling/BBPE · §3.2 MLA · §3.3 MoE vs V2 / MTP / FP8 · §3.4 GRPO · §3.5 MLA 模式切换 · §3.6 DSA · §3.7 V4 异构 KV + DSpark · §3.8 Visual Primitives · §4 Index Share · §5.1–5.3 KV offload 三代

arXiv 说明：V3.1 / Terminus 为 post-train 与 checkpoint，无独立论文；V3.2-Exp 先发 GitHub 技术报告，DSA 完整叙述并入 V3.2 论文 2512.02556。DSpark 无独立 arXiv，技术报告见 DeepSpec / DSpark_paper.pdf；与 V4 同期开源，叠加在 V4 checkpoint 之上（§3.7 / §6）。

3. 各版本详解

各版本一页纸梗概见 版本梗概索引。以下为展开说明（按时间线从 V1 起）。更细的 V1→V3 脉络另见 V1→V3 演进。

3.1 DeepSeek-LLM V1

V1 正文：DeepSeek-LLM V1（2401.02954 完整中文译文）

论文：DeepSeek-LLM arXiv:2401.02954

架构要点

• 稠密 LLaMA 系：Pre-Norm + RMSNorm + SwiGLU + RoPE；7B（30 层 MHA）与 67B（95 层加深 + 8 头 GQA）。
• 上下文 4K；词表 BBPE 102,400。
• 预训练 2.0T 中英双语；数据管线：跨 dump 去重 → 过滤 → domain 重混。
• 对齐：~150 万 instruction，SFT + DPO。

研究贡献

• 系统 scaling laws（$C=M\cdot D$）；IsoFLOP 下数据质量越高越应扩模型而非堆数据。

答疑：为何用 $C=M\cdot D$ 而非 Chinchilla 的 $C=6ND$？ — $M$=non-embedding FLOPs/token、Table 3 误差、与 IsoFLOP 的关系

Figure 4a — IsoFLOP 曲线（各算力档 loss 随 $M$ 呈 U 形，谷底 = 最优分配）

来源：V1 论文 Figure 4a（详见 V1 §3.2 最优 model/data Scaling）。横轴 = non-embedding FLOPs/token $M$；纵轴 = validation bits-per-byte；每条 U 形曲线对应固定总算力 $C$，谷底即该预算下最优 model/data 分配。

词表 BBPE：

图示详情 · V1 BBPE 专文

推理 infra 特征

• 标准 GQA/MHA KV cache（与后续 MLA 不兼容）；无 MoE、无 latent 压缩；可按常规 Transformer 部署。

3.2 DeepSeek-V2

梗概：DeepSeek-V2 · MLA 详解

论文：DeepSeek-V2 arXiv:2405.04434 仓库：deepseek-ai/DeepSeek-V2

相对 V1 的架构跃迁

要点

• MLA 将 K/V 压入 latent cache；论文称相对 67B 稠密 KV 体积约 -93.3%、生成吞吐 5.76×。
• MoE 路由为 softmax 系（V3 起改为 aux-loss-free sigmoid 路由）。
• MLA 结构被 V3 / R1 / V3.1 / V3.2 沿用；V2 是系列中 MLA+MoE 的首次引入。

图示详情 · 公式与符号详解

为什么 1536 能变成 [128,128] 和 [128,64]? ——不是切分,是两个独立上投影矩阵放大后按头 reshape:

• $q_t^C = W^{UQ} c_t^Q$: $[16384 \times 1536] \cdot [1536] \to [16384]$, 其中 $16384 = n_h \times d_h = 128 \times 128$ → reshape $[128, 128]$
• $q_t^R = \mathrm{RoPE}(W^{QR} c_t^Q)$: $[8192 \times 1536] \cdot [1536] \to [8192]$, 其中 $8192 = n_h \times d_h^R = 128 \times 64$ → reshape $[128, 64]$

$[128,128]$ 里两个 128 含义不同:前一个是头数 $n_h$(共 128 个头),后一个是每头维度 $d_h$(每头 128 维),本配置恰好都等于 128。二者都是架构超参,不是从 1536 算出来的;1536 只决定矩阵的列数。(KV 侧同理:$c_t^{KV} = 512$ 经 $W^{UK}, W^{UV}$ 投影成 $[128,128]$。)

右边 $k_t^R = [64]$ 的 64 怎么来? ——$64 = d_h^R$(每头 RoPE 维度,架构超参);$W^{KR}: [64 \times 5120] \cdot h_t \to [64]$,再加上 RoPE。 关键: $k_t^R$ 没有头维度——所有 $n_h = 128$ 个头共享同一个 $[64]$(解耦 RoPE);而左边 $q_t^R$ 是每头各一份 $[128, 64]$。 正因为 K 的 RoPE 部分全局只存一份 $[64]$(不按头复制),KV 缓存才这么小——这是 MLA 省显存的另一半原因。

MLA 到底压缩了谁?如果不做压缩会变多大? ——下面三项就是 MLA 压缩/解耦的对象(格式:MLA 压缩后 $\Rightarrow$ 不压缩):

• $c_t^Q$ 查询潜向量: $1536 \Rightarrow 16384\ (= n_h d_h)$, 约 11×; 不进缓存,省的是参数与计算量。
• $c_t^{KV}$ KV 联合潜向量: $512 \Rightarrow 16384\ (= n_h d_h)$, 32×; ★进缓存 —— 这是省显存的核心。
• $k_t^R$ 共享 RoPE 键: $64 \Rightarrow 8192\ (= n_h d_h^R)$, 128×; ★进缓存,靠全头共享(不按头复制),而非低秩压缩。

缓存总量: 标准 MHA $= 2n_h d_h = 32768$ → MLA 若不压缩 $= 16384 + 64 = 16448$(仅 MHA 一半) → 实际 MLA $= 512 + 64 = 576 \approx$ MHA 的 1/57

来源：V2 论文 Eq. 37–47；cache 仅存 $c_t^{KV}$（512）+ 共享 $k_t^R$（64）。

推理 infra 特征

• KV cache 变为 MLA latent 格式；需引擎侧自定义 kernel / 适配（后续 FlashMLA 等）。

3.3 DeepSeek-V3

梗概：DeepSeek-V3 · 相对 V2 纯模型结构优化：§对比 V2

论文：DeepSeek-V3 Technical Report 仓库：deepseek-ai/DeepSeek-V3

相对 V2 的架构升级

要点（三条结构线）

1. MoE 路由革新：去掉 aux loss 主路径；router 内 可学习 bias 做负载均衡，sigmoid affinity 选 expert、门控与选择解耦；专家池扩至 256/8，激活占比更低。

2. MTP（全新）：输出层 Multi-Token Prediction 辅助目标；推理可原生投机解码 → 投机解码与 DSpark 专文 §2

3. MLA 继承：K/V 仍压入 latent cache（$c_t^{KV}$ 512 + 共享 $k_t^R$ 64）；V3 价值在旗舰规模与 128K 巩固，非新 attention 算子（Hybrid / DSA 在 V3.1 / V3.2）。

图示详情 · MoE 详解 · aux-loss-free · MLA 前向流程图

• 训练：14.8T tokens；后训练含 SFT + RL（R1 为同架构 + RLVR）。

训练 infra（非模型结构）：FP8 动态量化 — 块级 scale + 每 $N_c{=}128$ MMA 提升 FP32 累加；与 DualPipe / DeepEP 并列，支撑 671B 预训练吞吐与数值稳定。

推理 infra 特征

• KV cache 为 MLA latent 格式，与标准 GQA/MHA 不兼容。
• vLLM 等引擎需 --trust-remote-code、--block-size 1（MLA 专用）。
• 长上下文下主要瓶颈是 Latent-Cache 线性增长 占满 HBM，限制 batch size。

3.4 DeepSeek-R1

梗概：DeepSeek-R1 · RLVR 详解

论文：DeepSeek-R1 arXiv:2501.12948 训练管线：DeepSeek-R1 训练 Pipeline

要点

• 架构与 V3 完全相同；差异仅在 后训练。
• RLVR（Reinforcement Learning with Verifiable Rewards）：数学/代码等用 规则验证器 给奖励，配合 GRPO（无 critic），不用神经 reward model 做主信号。
• R1-Zero：V3-Base 上纯 RL，推理能力自发涌现；可读性弱。
• R1：冷启动 SFT → RL → 拒绝采样 SFT → 二阶段 RL（推理 + 通用 RM），补齐 helpful / safe。

图示详情 · RLVR 详解 · GRPO 算法

推理 infra：与 V3 相同（MLA latent KV、引擎配置一致）。

3.5 DeepSeek-V3.1 / V3.1-Terminus

梗概：DeepSeek-V3.1 · V3.1-Terminus checkpoint

变化：在 V3 权重基础上做 post-training，无架构变更。

V3.1-Terminus 是 V3.1 系列的最终 checkpoint，上下文已扩至 128K，作为 V3.2 继续预训练 的起点。

MLA 模式切换：

图示详情 · V3.1 专节

• Prefill：MHA 模式（多 query head 独立 latent）
• Decode：MQA 模式（latent 在 query head 间共享）

这为后续 DSA 在 MQA 模式下做稀疏选择打下基础。

3.6 DeepSeek-V3.2 / V3.2-Exp

梗概：DeepSeek-V3.2 · V3.2-Exp

论文：DeepSeek-V3.2 · V3.2-Exp 仓库：deepseek-ai/DeepSeek-V3.2

相对 V3.1-Terminus 的唯一架构改动：DeepSeek Sparse Attention (DSA)

逻辑详解：DSA逻辑详解 · DSA稀疏注意力

图示详情 · DSA 逻辑详解

DSA 两阶段（三阶段表）：

1. Lightning Indexer：对每个 query，用廉价点积为所有历史 token 打分（复杂度仍 $O(L^2)$，但 head 维极低）。
2. Top-$k$ Selector：选出 $k=2048$ 个最重要 token 的 latent entry。
3. Core Attention（Core MLA）：仅对这 $k$ 个 latent 做 MLA attention（复杂度 $O(Lk)$）。

概念：Lightning Indexer · Top-$k$ Selector · Core MLA · Indexer-Cache · Latent-Cache · ESS

因此 V3.2 的 cache 分裂为两类（异构 KV · DSA逻辑详解 §4）：

V3.2-Exp 与 V3.2 架构相同；Exp 用于验证 DSA 不损精度，V3.2 为正式训练 + 后训练成品。

推理内核：DeepGEMM（indexer logits）、FlashMLA（sparse attention paged kernel）→ 推理 infra

3.7 DeepSeek-V4

梗概：DeepSeek-V4-Pro / V4-Flash

论文：DeepSeek-V4: Towards Highly Efficient Million-Token Context Intelligence 模型：V4-Pro（1.6T / 49B act）、V4-Flash（284B / 13B act）

相对 V3.2 的算法大步进

图示详情 · V4 梗概 · CSA/HCA 详解 · Hash MoE + FP4 · Muon 详解 · mHC 详解

1M context 效率

Agentic Coding 场景：V4 面向 100K–1M token 的 agent 工作流（代码库、多轮 tool trace），算法侧用 CSA/HCA 压 cache，infra 侧用异构 KV 管理 + offload 才能「真的跑得动」。

推理加速：V4 预览引擎已部署 投机解码与 DSpark（相对 MTP-1 基线；同等吞吐下单用户 +57%–85%）。细节、图示、自测与 MTP 机制 均在专文，此处不重复。

专文：投机解码与 DSpark · DeepSpec

Ablation 困境：V4 同时改了注意力、残差、优化器、MoE 路由、量化精度，很难像 V3.2 那样做单一变量对照——这也是社区更青睐 Index Share 这类「纯 infra、零重训」补丁的原因之一。

3.8 Thinking with Visual Primitives

要点专文：Visual Primitives 论文要点 · PDF：Visual Primitives 原文 PDF

定位：V4-Flash 之上的 MLLM 支线——把 点 / 框 作为 CoT 的 visual primitives，解决语言难以精确 空间引用 的 Reference Gap。

双模块架构：

Figure 2 | Model architecture and training pipeline（论文原图）。756×756 示例：2,916 patch → 324 LLM token → 81 KV entries，总压缩 7,056×。

直接打开 Figure 2 · 要点专文 §2

效率与精度：

Table 1 | Comparison with frontier models（bold=最佳）。

直接打开 Figure 1 · Table 1 · 要点专文 §4–§5

与 §3.7 V4 的关系：共享 CSA 压缩 attention 与 MoE 推理栈；增量在 ViT 编码器 + visual primitives 后训练管线，属于 模型轴（数据/对齐）+ 架构-train（ViT 模块） 的扩展，而非新的文本稀疏注意力变体。

4. Index Share

梗概：Index Share 逻辑详解：Index Share逻辑详解

社区昵称 Index Share / 「V3.3」；正式名 IndexCache。 论文：arXiv:2603.12201（清华大学 + 智谱 AI / Z.ai）· 代码：THUDM/IndexCache

4.0 技术归属

详见 Index Share梗概 §技术归属。

4.1 解决什么问题

DSA 的 indexer 每层独立运行，复杂度 $O(L^2)$，长上下文 prefill 时 indexer 成为显著开销。观察：相邻层的 top-$k$ index 高度相似。

4.2 机制

将 Transformer 层分为两类：

• Full (F) 层：保留 indexer，正常计算 top-$k$
• Shared (S) 层：不跑 indexer，直接复用最近一个 F 层的 cached indices

典型模式：每 4 层保留 1 个 F 层（FFFS 重复），去掉 75% indexer 计算。

图示详情 · Index Share 逻辑详解

两种部署：

4.3 为何被称为「最好的 infra 补丁」

结论：Index Share 典型体现「infra 归 infra，算法归算法」——在 DSA 算法不变的前提下，用跨层冗余做系统优化。

5. KV-offload 演进

KV-offload 指将部分 cache 卸载到 CPU DRAM（或磁盘），按需 prefetch 回 GPU。DeepSeek 各代的 cache 形态不同，offload 策略也完全不同。

5.1 V3 / V3.1：标准 MLA Latent-Cache

• Cache 内容：单一 MLA latent 向量序列。
• Offload：可用通用 KV offload（FlexGen、vLLM CPU offload 等），但 MLA 自定义格式导致很多引擎 不支持标准 offload。
• 瓶颈：线性增长的 latent 占满 HBM → decode batch size 受限。

图示详情 · MLA 前向专文 · MLA §KV Cache

5.2 V3.2：Indexer-Cache + Latent-Cache 分离 → ESS

归属澄清：DeepSeek-V3.2-Exp / V3.2 与 DSA 均为 DeepSeek 官方发布。下文 ESS 论文标题虽含「DeepSeek-V3.2-Exp」，但 ESS 算法来自百度百舸，是针对 DeepSeek DSA 模型的 Latent-Cache offload 方案，不是 DSA 本身，也不是 V3.2-Exp 的发布方。

详解：ESS Latent offload

论文：ESS: An Offload-Centric Latent-Cache Management Architecture for DeepSeek-V3.2-Exp

图示详情 · ESS 概念 · ESS 论文梗概

收益：32K context 吞吐 +69.4%；128K 最高 +123%。

与 V3 的本质区别：offload 单位从「整条 MLA latent 序列」变为「稀疏选中的 Latent-Cache entry」，且需与 indexer 的 top-$k$ 选择协同。

5.3 V4：异构 KV + HiSparse + 磁盘 Prefix Cache

V4 的 cache 不再是单一 MLA latent，而是多类型并存：

图示详情 · V4 §推理 infra

KV layout→ 专文：V4 KV Layout

• Classical KV cache：按 $\mathrm{lcm}(m, m')$ 对齐的压缩块，服务 CSA/HCA
• State cache：每请求固定大小块，存 SWA + 未就绪压缩尾

HiSparse→ 专文：V4 HiSparse

• 将 inactive 的 C4（CSA 4:1 压缩层）cache entry offload 到 CPU pinned memory
• GPU 只保留 active「热」工作集
• 单节点 B200 上 KV 容量从 ~1.2M tokens 提升到 ~3.7M tokens（约 3×）

磁盘 Prefix Cache→ 专文：V4 磁盘 Prefix Cache

• CSA/HCA 压缩 entry 可直接落盘，共享 prefix 免重复 prefill
• SWA 体积约为压缩 entry 的 8×，提供 Full / Periodic Checkpointing / Zero 三档策略

5.4 三代 offload 对比

知乎社区观点（2026-06）：V4 的 KV-offload 策略与 DSV3.2 完全不同——不是简单扩大 ESS，而是围绕异构压缩 cache 重新设计内存层级；V3.2 上可叠加 Index Share + ESS，V4 则需要 HiSparse + 定制 layout。

6. 推理技术栈对照

7. 与本仓库其他专题的关系

优化方向：各专题在 §1.1 模型 / 架构-train / 架构-infer 分类 中的落点见该表「工作一览」。

8. 参考资料

1. DeepSeek-AI. DeepSeek-V3 Technical Report. arXiv:2412.19437, 2024.
2. DeepSeek-AI. DeepSeek-V3.2: Pushing the Frontier of Open Large Language Models. arXiv:2512.02556, 2025.
3. DeepSeek-AI. DeepSeek-V3.2-Exp: Boosting Long-Context Efficiency with DeepSeek Sparse Attention. 2025.
4. Chen et al. ESS: An Offload-Centric Latent-Cache Management Architecture for DeepSeek-V3.2-Exp. arXiv:2512.10576, 2025.
5. Bai et al. IndexCache: Accelerating Sparse Attention via Cross-Layer Index Reuse. arXiv:2603.12201, 2026.
6. DeepSeek-AI. DeepSeek-V4: Towards Highly Efficient Million-Token Context Intelligence. arXiv:2606.19348, 2026.
7. Together.ai. Serving DeepSeek-V4: why million-token context is an inference systems problem. 2026.

DeepSeek 算法线：MLA → DSA → CSA/HCA + mHC

← 中文导读 · ← 仓库首页（EN） · 更新：2026-06-27 ← 演进总览 §1 · 基础设施线导读 · MoE 线导读 · 版本梗概索引 · 《ds-技术报告》读本

V3 发布之后，DeepSeek 在 注意力与残差路径 上的算法演进可概括为（与 演进总览 §1 正文内联一致）：

MLA → DSA 稀疏注意力 → CSA/HCA 混合压缩注意力 + mHC

本文是这条 算法线 的专题导读与双向跳转 hub；全景时间线（含 infra 线）见 版本演进总览。

1. 演进链

注意：mHC 改的是 残差路径（与 Attention / KV 正交），在演进总览里与 CSA/HCA 并列 标注，便于对照 V4 全架构；详见 mHC §7。

2. 阅读顺序

1. MLA 低秩注意力 — latent KV 压缩基座
2. V3.1 Hybrid — Prefill MHA / Decode MQA（DSA 前置）
3. DSA 梗概 → 逻辑详解 → Lightning Indexer
4. CSA/HCA 混合压缩注意力 — 4:1 稀疏 + 128:1 dense
5. V4 梗概 — 两个规格、MoE、训练与 infra 总览
6. Hyper-Connections（HC） — 多路残差流基础
7. mHC 流形约束超连接 — V4 残差组件

外部解读：Raschka 要点速读 §3–4 MLA/DSA · §8 mHC

3. 节点间关系

4. 与 infra 线的交叉

完整 基础设施线 见 基础设施线导读。

MoE 线：MoE 线导读。

5. 反向引用

维护约定见 DeepSeek 版本演进线文档引用约定。

DeepSeek 基础设施线：MLA KV → 异构 Cache → Index Share → ESS → V4 HiSparse

← 中文导读 · ← 仓库首页（EN） · 更新：2026-06-27 ← 演进总览 §1 · 算法线导读 · MoE 线导读 · 版本梗概索引 · 《ds-技术报告》读本

V3 发布之后，DeepSeek 推理侧 KV cache 与 offload 的演进可概括为（与 演进总览 §1 正文内联一致）：

标准 MLA KV cache → Indexer/Latent 异构 cache → Index Share → ESS offload → V4 异构 KV + HiSparse

本文是这条 基础设施线 的专题导读与双向跳转 hub；算法侧演进见 算法线导读，全景时间线见 版本演进总览。

1. 演进链

③ 与 ④ 并列：二者都依赖 ② 异构 cache，分别优化 indexer 算力 与 Latent 显存；可 同开。 ⑥ 与 ①–⑤ 正交：DSpark 优化 decode 步吞吐，不改变 KV 布局。

2. 阅读顺序

1. MLA 低秩注意力 — 理解 同质 latent KV 基线
2. DSA 梗概 §异构 KV — Indexer/Latent 分裂
3. Index Share 梗概 → 逻辑详解 — 跨层 index 复用
4. ESS 概念 → 论文梗概 — Latent offload
5. V4 §推理 infra — 异构 cache 总览

• KV layout §3.5.1 · HiSparse · 磁盘 Prefix Cache §3.5.2（演进总览 §5.3）

6. 投机解码与 DSpark — 唯一入口（MTP、自测、DSpark、MTP-1）

对照表：演进总览 §5.4 三代 offload 对比

3. 节点间关系

4. 与算法线的交叉

算法线完整导读见 算法线导读。MoE 线见 MoE 线导读。

5. 反向引用

维护约定见 DeepSeek 版本演进线文档引用约定。

DeepSeek MoE 线：稠密 FFN → DeepSeekMoE → aux-loss-free → Hash MoE

← 中文导读 · ← 仓库首页（EN） · 更新：2026-06-27 ← 演进总览 §1 · 算法线导读 · 基础设施线导读 · V1→V3 演进 · 版本梗概索引 · 《ds-技术报告》读本

DeepSeek 在 FFN / 专家路由 上的演进可概括为（与 演进总览 §1 正文内联一致）：

稠密 FFN → DeepSeekMoE → aux-loss-free 路由 + $L_{\mathrm{Bal}}$ → Hash MoE + FP4

本文是 MoE 线 专题导读；Attention 侧见 算法线导读，KV/offload 见 基础设施线导读。

1. 演进链

③ 与 ④ 互补：aux-loss-free $b_i$ 管 **batch 级**主均衡；$L_{\mathrm{Bal}}$ 防 单序列内 expert 打穿。

2. 阅读顺序

1. V1 正文 — 稠密基线
2. DeepSeekMoE 架构 — 细粒度 routed + shared（Figure 2 优化逻辑 · Fine-grained vs GShard）
3. V2 梗概 — MLA + MoE 版本落地（236B/21B）
4. V3 梗概 — 256 / 8 act 旗舰化
5. aux-loss-free 路由逻辑 → $L_{\mathrm{Bal}}$ 详解
6. Hash MoE + FP4 — Hash 路由与 FP4 量化
7. V4 梗概 — 两个规格、Attention、训练与 infra 总览

前代三代对照：V1→V3 演进 §3.2 FFN

3. 节点间关系

4. 与 Attention / infra 线的交叉

5. 反向引用

维护约定见 版本演进线文档引用约定。

DeepSeek V1 → V2 → V3：前代到旗舰基座

更新：2026-06-25 ← 全系列演进总览 · V1 正文 · V2 · V3

1. 三代在系列中的位置

DeepSeek 开源主线可粗分为两段：

1. V1 → V2 → V3（2024）：从稠密双语基座，到 MLA + MoE 效率架构，再到 规模化旗舰 MoE（671B）
2. V3.1 → V3.2 → V4（2025–2026）：在同一 V3 权重架构上 post-train、加 DSA、再 架构大步进

本文梳理第一段：V1 → V2 → V3。

2. 对照总表

3. 演进逻辑

3.1 注意力：标准 GQA → MLA

图示详情

• V2 首创 MLA（2405.04434）；V3 沿用同一 latent 格式（MLA 详解）
• V3.1 再在 Prefill/Decode 间切换 MHA/MQA 模式；V3.2 叠加 DSA — 均属 V3 代之后，不在 V1–V3 段

3.2 FFN：稠密 → MoE → 大规模 aux-loss-free MoE

3.3 规模与数据：scaling laws → 产品化旗舰

4. 能力代际

图示详情

5. 推理 infra 代际差异

6. 阅读顺序

1. V1 正文（DeepSeek-LLM 完整译文）
2. DeepSeekMoE 架构 · V2 梗概 · MLA 前向流程图
3. V3 梗概 · 演进总览 §3
4. 后续代际：R1 → V3.1 → V3.2 → V4

7. 参考

• V1 BBPE 词表专文
• V1 技术报告精读 stub

1. DeepSeek-AI. DeepSeek LLM: Scaling Open-Source Language Models with Longtermism. arXiv:2401.02954, 2024.
2. DeepSeek-AI. DeepSeek-V2: A Strong, Economical, and Efficient Mixture-of-Experts Language Model. arXiv:2405.04434, 2024.
3. DeepSeek-AI. DeepSeek-V3 Technical Report. arXiv:2412.19437, 2024.

DeepSeek 各版本梗概

更新：2026-06-25 ← 中文导读 · ← 仓库首页（EN） · 版本演进总览 · 算法线导读 · 基础设施线导读 · MoE 线导读

每篇一页纸梗概：定位、核心改动、infra 关注点、上下游关系。

| 算法线 | 算法线导读 | MLA → DSA → CSA/HCA + mHC 专题 hub | | 基础设施线 | 基础设施线导读 | MLA KV → 异构 Cache → Index Share → ESS → V4 HiSparse | | MoE 线 | MoE 线导读 | 稠密 FFN → DeepSeekMoE → aux-loss-free → Hash MoE |

推理答疑：答疑索引（如 H2D / D2H）

DSA / Index Share 逻辑详解：DeepSeek DSA 与 Index Share 系列

| mHC | mHC | 双随机流形约束残差超连接（含 §3 流形推导）；V4 落地 | | Hyper-Connections | Hyper-Connections | $n$ 路并行残差流 + pre/post/comb；mHC 前置（HC 子专文） | | CSA / HCA | CSA / HCA | 4:1 稀疏 + 128:1 dense 混合压缩注意力；V4 算法线 ③ | | Hash MoE + FP4 | Hash MoE + FP4 | 前几层 Hash 路由 + routed expert FP4；MoE 线 ⑤ | | Muon | Muon 优化器 | 矩阵正交化优化器；V4 训练侧替换大部分 AdamW | | V4 | DeepSeek-V4 | V4-Pro / V4-Flash 梗概，1M context | | V4 KV layout | V4 KV Layout | Classical + State 双池 | | V4 HiSparse | V4 HiSparse | inactive C4 CPU offload；~3× KV 容量 | | V4 磁盘 Prefix | V4 磁盘 Prefix Cache | CSA/HCA 落盘 + SWA 三档策略（§3.5.2） | | DSpark / 投机解码 | 投机解码与 DSpark | 唯一专文（MTP + 自测 + DSpark + MTP-1） |

DeepSeek 技术报告与外部解读

← 中文导读 · ← 仓库首页（EN） · 版本梗概 · 演进总览 · Raschka V3→V3.2 解读

本目录存放 官方技术报告摘要 与 第三方深度解读。

CI 门禁：bash scripts/doc_series_gate.sh（check_svgs + build_book + FP8 导航 spot-check）

外部原文：A Technical Tour of the DeepSeek Models from V3 to V3.2（Sebastian Raschka，2025-12-03，更新 2026-01-01）

DeepSeek-V3 梗概

← 中文导读 · ← 仓库首页（EN） · ← 演进总览 §3.3 · ← MoE 线导读 · ← 版本目录 · Raschka 解读

定位

2024 年 12 月发布的开源旗舰 Base 模型，奠定 DeepSeek 后续全系架构基座。671B 总参数、每 token 激活 37B，支持 128K 上下文。同年 1 月基于同一架构推出 DeepSeek-R1（RLVR 推理专精，DeepSeek-R1），架构不变、训练管线不同。

核心架构

对比 V2：纯模型结构优化

边界：本节只讲 Transformer 内部 — MoE 路由、注意力、预测头、层内数据流；不含 DualPipe / FP8 训练框架、DeepEP、vLLM 调度、KV 量化等训推系统（见文末 排除项）。

一、MoE：路由与负载均衡

图示详情 · 详解：aux-loss-free · DeepSeekMoE

二、MLA 注意力

V3 沿用 V2 的 MLA 方程与 latent KV 格式（$c_t^{KV}$ 512 + 共享 $k_t^R$ 64 进 cache；前向流程图）。相对 V2 的改动主要是 671B 母版下的 hidden / 层数 / 128K 上下文配比，而非全新 attention 算子。

易混：Prefill MHA / Decode MQA Hybrid 自 V3.1-Terminus 起；Lightning Indexer + top-$k$ 稀疏 自 V3.2 DSA 起。二者均 不是 V3-Base 相对 V2 的架构差分。

三、MTP：Multi-Token Prediction

V3 相对 V2 全新 的训练目标头：主 loss + MTP 辅助头（链式预测 $t{+}2, t{+}3, \ldots$）。推理时可丢弃 MTP，也可 复用做 speculative decoding。

投机解码全集：投机解码与 DSpark§2

补充阅读：酱紫君（GalAster）知乎：DSpark 与投机解码全篇 — 投机背景、半自回归、MTP 融合、draft 训练；知乎原文

四、Transformer 主干层内微调

• RMSNorm / 残差：随层数与 MoE 深度做实现级微调，适配 671B 稀疏 FFN 栈（细节见 2412.19437）。
• 128K 原生配比：hidden、MLA latent 秩、MoE intermediate 等张量维随旗舰规模重配；词表扩至 128K（V1 BBPE 演进）。
• MoE 层内张量布局：routed 按 expert 分组 gather/scatter 的 层内数据流 随 256/8 专家池优化（属模块前向结构，非 EP 通信库本身）。

附、FP8 动态量化

不属于上文「纯模型结构」；与 DualPipe / DeepEP 并列，支撑 671B 预训练。详解：FP8 动态量化专文

图示详情 · FP8 专文

五、排除项

六、浓缩：V3 相对 V2 的三条结构线

1. MoE 路由：aux-loss-free（bias 均衡 + sigmoid）+ 256/8 细粒度稀疏，激活占比 5.5% vs V2 8.9%。
2. MTP：多 token 并行预测头，预训练提效 + 推理可投机解码。
3. MLA：结构继承 V2；V3 价值在 671B / 128K / 14.8T 旗舰化落地（Hybrid、DSA 在后续版本）。

V2 ↔ V3 结构对照

MoE 线位置

训练约 14.8T tokens；后训练含 SFT + RL。

推理 infra 关注点

• KV cache 为 MLA latent 格式，与标准 GQA/MHA 不兼容
• vLLM 等需 --trust-remote-code、--block-size 1
• 长上下文瓶颈：Latent-Cache 线性增长占满 HBM，限制 decode batch size
• 通用 KV CPU offload 常因 MLA 自定义格式而不可用

上下游

参考

• 论文：arXiv:2412.19437
• MoE 路由：aux-loss-free 负载均衡
• 仓库：deepseek-ai/DeepSeek-V3
• R1 训练：DeepSeek-R1 训练管线

MLA前向计算流程

← 中文导读 · ← 仓库首页（EN） · ← 演进总览 §2 · ← 算法线导读 · ← 基础设施线导读 · ← V3 梗概 · V2 MLA 首发 · V3.1 Hybrid MLA 切换 · 下游 DSA · Raschka §3.1 MLA 论文：DeepSeek-V2 首次提出 MLA arXiv:2405.04434；V3/R1/V3.1/V3.2 沿用同一 MLA 结构

一句话

MLA 把 K/V 先压到低维 latent $c^{KV}$ 再写入 KV cache；推理时对 latent 升维 得到多头 K/V 的 content 部分；RoPE 的 R 分量维度小且 全头共享。相对标准 MHA，单 token cache 可从 $O(n_h d_h)$ 降到 $O(d_c^{KV} + d_h^R)$。

流程图

图示详情

为什么 1536 能变成 [128,128] 和 [128,64]? ——不是切分,是两个独立上投影矩阵放大后按头 reshape:

• $q_t^C = W^{UQ} c_t^Q$: $[16384 \times 1536] \cdot [1536] \to [16384]$, 其中 $16384 = n_h \times d_h = 128 \times 128$ → reshape $[128, 128]$
• $q_t^R = \mathrm{RoPE}(W^{QR} c_t^Q)$: $[8192 \times 1536] \cdot [1536] \to [8192]$, 其中 $8192 = n_h \times d_h^R = 128 \times 64$ → reshape $[128, 64]$

$[128,128]$ 里两个 128 含义不同:前一个是头数 $n_h$(共 128 个头),后一个是每头维度 $d_h$(每头 128 维),本配置恰好都等于 128。二者都是架构超参,不是从 1536 算出来的;1536 只决定矩阵的列数。(KV 侧同理:$c_t^{KV} = 512$ 经 $W^{UK}, W^{UV}$ 投影成 $[128,128]$。)

右边 $k_t^R = [64]$ 的 64 怎么来? ——$64 = d_h^R$(每头 RoPE 维度,架构超参);$W^{KR}: [64 \times 5120] \cdot h_t \to [64]$,再加上 RoPE。 关键: $k_t^R$ 没有头维度——所有 $n_h = 128$ 个头共享同一个 $[64]$(解耦 RoPE);而左边 $q_t^R$ 是每头各一份 $[128, 64]$。 正因为 K 的 RoPE 部分全局只存一份 $[64]$(不按头复制),KV 缓存才这么小——这是 MLA 省显存的另一半原因。

MLA 到底压缩了谁?如果不做压缩会变多大? ——下面三项就是 MLA 压缩/解耦的对象(格式:MLA 压缩后 $\Rightarrow$ 不压缩):

• $c_t^Q$ 查询潜向量: $1536 \Rightarrow 16384\ (= n_h d_h)$, 约 11×; 不进缓存,省的是参数与计算量。
• $c_t^{KV}$ KV 联合潜向量: $512 \Rightarrow 16384\ (= n_h d_h)$, 32×; ★进缓存 —— 这是省显存的核心。
• $k_t^R$ 共享 RoPE 键: $64 \Rightarrow 8192\ (= n_h d_h^R)$, 128×; ★进缓存,靠全头共享(不按头复制),而非低秩压缩。

缓存总量: 标准 MHA $= 2n_h d_h = 32768$ → MLA 若不压缩 $= 16384 + 64 = 16448$(仅 MHA 一半) → 实际 MLA $= 512 + 64 = 576 \approx$ MHA 的 1/57

口诀：$h_t$ → Q 降维 $c^Q$ / KV 共享降维 $c^{KV}$ → Q/K 拆头 C + 共享 R（RoPE）→ V 仅 C → 注意力 → concat + $W^O$。

符号

三分支计算

① Query

② Key

③ Value

④ 注意力与输出

$$ o_{t,i} = \sum_{j=1}^{t} \mathrm{Softmax}j\left( \frac{q{t,i}^\top k_{j,i}}{\sqrt{d_h^C + d_h^R}} \right) v_{j,i}^C $$

$$ u_t = W^O, [o_{t,1};\ldots;o_{t,n_h}] $$

KV Cache 里到底存什么

推理时从 cache 读出 $c_j^{KV}$ 再乘 $W^{UK}$、$W^{UV}$ 现场升维；多一次矩阵乘，换显存。

V3.1 Hybrid：Prefill 时 Q/K可按 MHA 式展开 latent；Decode 时 MQA 式共享 latent。cache 布局仍是 MLA latent，切换的是展开方式。

基础设施线位置

算法线位置

与后续版本

延伸

论文：V2 2405.04434 · V3 2412.19437

DeepSeekMoE 架构

← 中文导读 · ← 仓库首页（EN） · ← 演进总览 §2 · ← MoE 线导读 · V2 首发版本 · V3 旗舰化 · aux-loss-free 下游 论文：V2 arXiv:2405.04434 · V3 arXiv:2412.19437 §2.1

一句话

DeepSeekMoE = DeepSeek 自研的 细粒度 routed experts + shared experts FFN 稀疏激活框架：每 token 只激活少量 routed expert，并 始终保留 shared expert 路径；V2（2024-05）首次引入，V3 / R1 / V3.1 / V3.2 沿用同一 MoE 骨架，V3 起路由改为 aux-loss-free，V4 前几层改 Hash 路由。

相对稠密 FFN 的动机

V2 论文相对 67B 稠密：训练成本 -42.5%、生成吞吐 5.76×（同参数量级对比语境见 DeepSeek-V2）。

优化逻辑：从常规 MoE 到 DeepSeekMoE

V2 技术报告 §2.2 将 DeepSeekMoE 概括为两步改进（引自 Dai et al., 2024）：

1. Fine-grained expert segmentation（细粒度专家切分） — 把粗专家拆小，在相同激活算力下提高组合灵活性；
2. Shared expert isolation（共享专家隔离） — 固定激活 shared expert 承担通用知识，routed expert 专注特化，减轻冗余与「参数竞争」。

论文用三张子图 (a)→(b)→(c) 说明：每一步都尽量保持每 token 激活的 FFN 参数量 / FLOPs 不变，只改「专家怎么切、怎么路由」。

直接打开 Figure 2

来源：DeepSeek-V2 论文 Figure 2 — Illustration of DeepSeekMoE。蓝 = routed expert；绿 = shared expert；黄 = Router。

常规 Top-$K$ 路由

局限：专家粒度粗，每个 expert 体积大；Top-2 组合空间只有 $\binom{N}{2}$ 种，特化不够细——不同 token 往往被迫共用同一套「大块」知识。

+ 细粒度专家切分

直觉：用「更多、更小」的积木拼 FFN；每 token 仍只付固定算力，但可访问的组合从「选 2 大块」变成「选 4 小块」，表达更灵活、特化更准。 V2 产品配置是这一思想的规模化：单层 160 routed、每 token 6 routed（见下表），而非示意图里的 $N/2N$ 玩具数。

答疑：Fine-grained 为何优于 GShard？ — 组合数 $\binom{N}{K}!\to!\binom{mN}{mK}$、IsoFLOP 切分与训练机制

+ Shared Expert 隔离

为什么要 shared？ 许多 token 都需要的通用 FFN 模式（语法、高频搭配等）若全塞进 routed expert，会占掉 routed 容量，导致：

• 多个 routed expert 学重复（knowledge redundancy）；
• 特化 expert 抢不过通用模式，负载均衡更难。

Shared 路径隔离通用知识，routed 专注长尾 / 领域特化——论文称这能提升 expert specialization 与知识获取精度。

三步合起来：设计不变量

前向公式

对第 $t$ 个 token 的 FFN 输入 $u_t$，输出 $h_t'$ 为 残差 + shared 支路 + routed 支路：

$$ h_t' = u_t + \sum_{i=1}^{N_s} \mathrm{FFN}i^{(s)}(u_t) + \sum{i=1}^{N_r} g_{i,t},\mathrm{FFN}_i^{(r)}(u_t) $$

其中 routed 门控：

$$ g_{i,t} = \begin{cases} s_{i,t}, & s_{i,t} \in \mathrm{TopK}\big({s_{j,t}}{j=1}^{N_r},, K_r\big) \ 0, & \text{otherwise} \end{cases}, \quad s{i,t} = \mathrm{Softmax}_i(u_t^\top e_i) $$

答疑：为何叫 centroid 而非 gate-weight？ — affinity / gate 分工与 V3 选择-门控解耦

Shared 项无 $g_{i,t}$ 门控 — 与图中 Expert 1（绿）始终接通一致。

与 V2 工程配置的对应

示意图用 $N,,2N,,K=2/4/3$ 做教学缩放；DeepSeek-V2 真实超参：

结构要点

1. Fine-grained routed experts：单层 routed 数量 显著多于 早期 MoE（V2：160），单 expert 更小 → 见上文 §优化逻辑 (b)。
2. Shared experts：每层 恒激活 shared FFN（V2：2 个），与 routed 输出相加 → 见 §优化逻辑 (c)。
3. Per-token top-$K_r$：V2 每 token 6 routed；V3 8 routed / 256 池。
4. 路由演进：V2 softmax + aux balance loss → V3 aux-loss-free + $L_{\mathrm{Bal}}$。

各版本配置

版本文档：V2 · V3 · V4

MoE 线位置

推理 infra 关注点

• Expert Parallel（EP）：routed expert 分片；负载不均时 GPU 空转 → 路由均衡是训练关键（答疑：EP 与 gather/scatter）。
• Shared + routed 双路径：引擎需支持 shared 始终 on + 稀疏 routed gather/scatter。
• V2 路由为 softmax 系；V3+ 为 sigmoid + 动态 bias，权重 checkpoint 不混用路由逻辑。

参考

• DeepSeek-V2 梗概 — MLA + DeepSeekMoE 首次落地（8.1T）
• DeepSeek-V3 梗概 — 256/8 旗舰化 + MTP
• aux-loss-free 路由逻辑
• 仓库：DeepSeek-V2 · DeepSeek-V3

aux-loss-free MoE 路由逻辑

← 中文导读 · ← 仓库首页（EN） · ← 演进总览 §3.3 · ← MoE 线导读 · ← DeepSeekMoE 上游 · ← V3 梗概 · 版本目录 论文：DeepSeek-V3 arXiv:2412.19437 §2.1 · Megatron MoE aux loss free

一句话

aux-loss-free = MoE 不用（或几乎不用）辅助损失 逼专家均匀，而是在每个 routed expert 上维护一个 可学习的 routing bias $b_i$，按 batch 负载 动态加减 $b_i$ 来调 top-$K$ 路由；门控权重仍用原始 affinity $s_{i,t}$，避免 aux loss 伤害主任务 loss。

V3 起标配；V4 系仍沿用同一思路。

为什么 MoE 要「负载均衡」

因此几乎所有 MoE 都要某种 load balancing——关键是 用什么机制，以及会不会 牺牲模型质量。

传统做法：auxiliary loss 及其矛盾

经典 Switch / GShard 路线在总 loss 里加 辅助损失 $L_{\mathrm{Bal}}$，惩罚专家负载不均（token 级或 sequence 级）。

DeepSeek-V3 论文 Table 5：纯 aux-loss 基线在多数 benchmark 上 不如 aux-loss-free。

aux-loss-free 核心逻辑

1. 路由分数 vs 门控值

DeepSeek-V3 MoE 对 routed experts 用 sigmoid affinity $s_{i,t}$，再对选中专家做归一化得到门控 $g_{i,t}$（与 V2 的 softmax 路由不同，见 V3 论文 §2.1）。

aux-loss-free 只改「谁进 top-$K$」，不改门控乘到 FFN 输出的数值：

这样 bias 是 纯路由调度旋钮，不直接扭曲 expert 输出的幅度。

2. 每个训练 step 末尾更新 $b_i$

监控 整个 batch（一步训练）上各 expert 的负载：

图示详情

$\gamma$ = bias update speed（V3 预训练：前 14.3T tokens 取 0.001，论文 §3.2）。

无 aux loss 梯度 参与均衡；均衡靠 启发式反馈 调 bias，主 loss 只负责「学得好不好」。

3. 公式

专家 $i$ 在 token $t$ 被激活，当且仅当 $s_{i,t} + b_i$ 落在 top-$K_r$ 集合内；否则 $g'{i,t}=0$。门控 $g{i,t}$ 仍由 $s_{i,t}$ 经 top-$K$ 内归一化得到。

与传统 aux loss 对比

表：V3 论文 Table 5 摘要

Small MoE

Large MoE

论文结论：去掉纯 aux loss、改用 aux-loss-free 后，大多数评测一致更好。

补充：sequence-wise auxiliary loss 仍在

aux-loss-free 不是完全不管极端倾斜。V3 还保留 互补的 sequence-wise balance loss $L_{\mathrm{Bal}}$，防止 单条序列内 专家极度失衡——但 主均衡机制 仍是 bias 方案。

详解：序列均衡损失 — $f_i$、$P_i$ 如何在每条序列上统计、$f_i P_i$ 如何反传拉平负载、与 $b_i$ 的分工。

论文 §4.5.3：batch-wise（含 aux-loss-free）比 sequence-wise 更灵活，专家更易 按领域分化；1B/3B 实验上 batch-wise aux 与 aux-loss-free 的 val loss 可打平。sequence-wise 单独作主均衡时会 压平序列内 specialization（val loss 略差）。

推理时是什么

• $b_i$ 在训练结束后 固定（推理不再按 step 更新）。
• 路由仍按 训练结束时的 $s+b$ 选 expert；与训练一致。
• 与 Index Share / DSA 等 无关——纯 MoE router 训练策略。

工程对应

DeepSeek-V3 细粒度 MoE + sigmoid router 在 Megatron侧常配合 FlexDispatcher + DeepEP 做 token dispatch。

MoE 线位置

在 DeepSeek 系列中的位置

演进总览表中「aux-loss-free 路由」即指此项，不是 Engram 或 DSA 的 index。

参考

• DeepSeek-V3：arXiv:2412.19437 — §2.1 Auxiliary-Loss-Free Load Balancing；Eq. 17–20 sequence-wise $L_{\mathrm{Bal}}$；§4.5.2 Table 5；§4.5.3 batch vs sequence
• 方法先例：Wang et al., 2024a（V3 论文引用）
• 本地：序列均衡损失 · DeepSeek-V3 梗概§DeepSeekMoE · Raschka V3 导读

序列均衡损失

← 中文导读 · ← 仓库首页（EN） · ← 演进总览 · ← MoE 线导读 · ← aux-loss-free 主文档 · V3 梗概 论文：DeepSeek-V3 arXiv:2412.19437 §2.1（Eq. 17–20）；§4.5.3 batch vs sequence

一句话

V3 主均衡靠 batch-wise $b_i$ 启发式（aux-loss-free）；$L_{\mathrm{Bal}}$ 是互补兜底：在 每条序列内 用极小 $\alpha$ 惩罚 $\sum_i f_i P_i$，梯度反传进 router，防单条序列里少数 expert 被「打穿」。

两条机制的分工

论文 §4.5.3：sequence-wise 强制序列内更均匀 → 抑制按领域 specialization；batch-wise（含 aux-loss-free）更灵活（Fig. 9）。

MoE 线位置

总公式与符号

对 一条序列（长度 $T$，$N_r$ 个 routed expert，每 token 激活 $K_r$ 个）：

$$ \mathcal{L}{\mathrm{Bal}} = \alpha \sum{i=1}^{N_r} f_i , P_i \qquad \text{（Eq. 17）} $$

$f_i$ 与 $P_i$ 对照（先建立地图）

前置：「槽位」是什么？

MoE 每一层、对 一条序列：

• $T$ 个 token，每个 token 选 $K_r$ 个 routed expert
• 共 $K_r \times T$ 个槽位（slot）= 每次 expert 被选中的机会

T=4, K_r=2 → 共 8 个槽位

token1 → [A, B] token2 → [A, C]
token3 → [A, D] token4 → [B, C]

$f_i$ 数的是：这 8 个槽位里 expert $i$ 占几个。 $P_i$ 看的是：router 在每个 token 上对 $i$ 的归一化意愿，整条序列平均多少。

batch 里 每条序列单独 算一套 $(f_i, P_i)$，不跨样本混合。

一、$f_i$：实际负载

核心：$f_i$ = 这条序列里 expert $i$ 分到的槽位，相对完全均匀水平的倍数；均匀时 $f_i = 1$。

公式

$$ f_i = \frac{N_r}{K_r T} \sum_{t=1}^{T} \mathbf{1}!\left( \text{expert } i \text{ 在 token } t \text{ 被选入 top-}K_r \right) $$

归一化直觉

$$ \text{raw}_i = \frac{\mathrm{count}_i}{K_r T}, \qquad f_i = N_r \cdot \text{raw}_i $$

论文写「均匀时 $f_i = 1/N_r$」指 raw 形态 $\mathrm{count}_i/(K_r T)$；与本文 $f_i = N_r \cdot \text{raw}_i$ 差一个 $N_r$，说的是同一件事。

实现注意：计数用 $s$ 还是 $s+b$？

二、$P_i$：平均路由概率

核心：$P_i$ = 这条序列上，router 对 expert $i$ 的 归一化意愿 的时间平均；均匀时 $P_i = 1/N_r$。

公式

Step 1 — 原始 affinity

$$ s_{i,t} = \mathrm{Sigmoid}(\mathbf{u}_t^\top \mathbf{e}_i) \in (0, 1) \qquad \text{（Eq. 15）} $$

$\mathbf{u}_t$：token $t$ 的 FFN 输入；$\mathbf{e}_i$：expert $i$ 的路由向量。注意：这里用 $s$，不加 $b_i$。

Step 2 — 在全体 expert 上归一化

$$ s'{i,t} = \frac{s{i,t}}{\displaystyle\sum_{j=1}^{N_r} s_{j,t}} $$

• 分母是 全部 $N_r$ 个 routed expert，不是只在 top-$K_r$ 内
• 对每个 token $t$，$\sum_i s'_{i,t} = 1$（概率分布）
• $s'_{i,t}$ 可微，梯度可回传到 router

Step 3 — 对序列求平均

$$ P_i = \frac{1}{T} \sum_{t=1}^{T} s'_{i,t} $$

$P_i$ 与门控 $g_{i,t}$ 的区别

$L_{\mathrm{Bal}}$ 通过 $P_i$ 调的是 router 的 全局偏好；门控 $g$ 只管选中 expert 的输出权重。

三、为什么乘 $f_i P_i$？

Switch / GShard 经典结构：离散负载 × 连续概率 = 可微的负载均衡信号。

计算流水线（每条序列、每个 MoE 层）

图示详情

四、完整手算示例

设定：$N_r=4,, K_r=2,, T=4$ → 8 个槽位；均匀目标每 expert 2 次。

4.1 路由结果

4.2 各 token 的 $s$ 与 $s'$

设每层 router 给出的 raw affinity（sigmoid 后）：

token 1 归一化：

$$ s'{0,1} = \frac{0.90}{2.30} \approx 0.391,\quad s'{1,1} \approx 0.304,\quad s'{2,1} \approx 0.174,\quad s'{3,1} \approx 0.130 $$

对 $t$ 求平均得 $P_i$：

4.3 合并算 $L_{\mathrm{Bal}}$

（忽略 $\alpha$，只看 $\sum_i f_i P_i$）

$$ \sum_i f_i P_i \approx 1.10 $$

反传会 压低 A 的 $s_{0,t}$ → 后续 token 更少选 A，$P_0$ 与 $\mathrm{count}_0$ 一起下降。D 的 $f_3 P_3$ 很小，loss 几乎不阻止其他 expert 把活分给 D。

五、超参与总 loss

$\alpha$：论文取 极小值（extremely small），$L_{\mathrm{Bal}}$ 只作安全网（对比 aux-loss-free Table 5 里大 $\alpha$ 的纯 aux-loss 基线）。

$$ \mathcal{L} = \mathcal{L}{\mathrm{main}} + \lambda{\mathrm{MTP}}\mathcal{L}{\mathrm{MTP}} + \alpha \sum{i} f_i P_i + \cdots $$

$L_{\mathrm{Bal}}$ 只动 router（经 $s_{i,t}$）；不改 $b_i$ 启发式；不加在 expert FFN 上。

六、工程与场景

参考

• aux-loss-free MoE 路由 — $b_i$、top-$K$ 双轨
• DeepSeek-V3 §4.5.3 — batch-wise vs sequence-wise val loss
• Megatron MoE README

DeepSeek-V3 FP8 动态量化

← 中文导读 · ← 仓库首页（EN） · ← 演进总览 §3.3 · ← V3 基座 · 论文 Figure 7 边界：属 训练侧 GEMM 数值/内核（与 DualPipe、DeepEP 并列），不是 Transformer 权重结构本身；V3 纯模型结构对比 刻意不含本节。

一句话

V3 在 FP8 Tensor Core GEMM 上用 块级动态 scale（fine-grained quantization） 抑制激活离群点误差，并 每隔 $N_c{=}128$ 次 MMA（名词解释：MMA）把 Tensor Core 低精度累加 提升到 CUDA Core FP32 寄存器 再续算——在保持 FP8 吞吐的同时，把 671B 预训练做稳。

为何需要「动态」量化

答疑：partial sum 漂移是什么、为何每 128 MMA 要提升 FP32？

Figure 7 两路逻辑

图示详情

Fine-grained quantization

对 激活 与 权重 均按长度 $N_c$ 分块：

1. 每块各自算 动态 scale $s_x$（激活）、$s_w$（权重）；
2. 块内元素量化到 FP8 后在 Tensor Core 做 GEMM / MMA，得到 低精度积；
3. 在 CUDA Core 用 $s_x \cdot s_w$ 反量化 写回输出。

要点：scale 随块动态更新，离群只污染所在块，不拖垮整条 tensor。

实现：$s_x = \mathrm{absmax}(X_{\mathrm{block}}) / F_{\max}$（$F_{\max}$ 为 FP8 可表示最大值；$s_w$ 同理）；量化 $\mathrm{FP8}(x) = \mathrm{round}(x / s_x)$；MMA 输出在 CUDA Core 做 $\mathrm{out} \mathrel{+}= \mathrm{MMA}(\mathrm{FP8}(x), \mathrm{FP8}(w)) \cdot s_x s_w$。

Increasing accumulation precision

一次 GEMM 对应多轮 WGMMA（warp-group MMA）：

1. Tensor Core 内先用 低精度累加器 收 partial sum；
2. 每累计 $N_c = 128$ 个 MMA 元素，把当前 partial 提升到 CUDA Core 的 FP32 寄存器 再累加；
3. 下一轮 WGMMA 再从低精度路径开始，避免 全程 FP8/低精度 长链漂移。

要点：算在 TC、稳在 CUDA FP32——速度与 671B 训练可收敛性之间的折中。

实现：沿归约维 $K$ 维护 MMA 计数；每 128 步执行 acc_fp32 += promote(acc_tc); acc_tc = 0；GEMM 结束后再 acc_fp32 += promote(acc_tc) 写回 BF16/FP16 激活。

分工速查

答疑：partial sum 漂移与 (a)(b) 实现分工

硬件分工

这与 V3 报告里 FP8 训练框架（配合 DualPipe 并行、DeepEP 通信）同属 训推系统层；换推理引擎 FP8 kernel（如自测 draft+FP8）是 另一套部署量化，数值策略不必与训练块 scale 完全相同。

在 V3 全景中的位置

参考

• 论文：DeepSeek-V3 arXiv:2412.19437 · Figure 7
• 结构边界：DeepSeek-V3 梗概§排除项
• 演进总览：§3.3 DeepSeek-V3

RLVR

← 中文导读 · ← 仓库首页（EN） · ← 演进总览 §2 · ← R1 梗概 · Raschka §RLVR/GRPO 论文：DeepSeek-R1 arXiv:2501.12948

一句话

RLVR = 在强化学习里 不用神经 reward model，而对 可程序/符号验证 的任务（数学答案、代码单测、格式规则）直接给 0/1 或规则分 作奖励；DeepSeek 用 GRPO 做优化（无 critic 的组内相对 advantage）。R1 = V3-Base 架构不变 + RLVR 后训练。

和 RLHF / GRPO 的关系

图示详情

同一条 prompt 采样 $G$ 次 rollout：每条用 verifier 打分（对/错、格式、语言）→ 组内减均值得 advantage → 更新 policy（R1 上即 V3-Base 权重）。

RLVR 省掉什么：不训、不依赖 reward model，减轻 reward hacking（模型讨好 RM 而非真做对题）。

RLVR 局限：只适合 答案可验证 的短程任务；开放域写作、主观 helpfulness 仍需 RM 或 LLM-as-judge（V3.2 后训练即 RLVR + 生成式 RM 混合）。

DeepSeek-R1 里的 RLVR

算法：GRPO

• 同一 prompt 生成 $G$ 条 完整回答（R1 一阶段约 16 rollout / 题）
• 每条算规则奖励 → 组内相对 advantage（无 value network）
• 配合 KL 到 reference、clip 等稳定训练

R1 奖励

两条产物

详见 R1 四阶段训练管线（含 Dev-1→R1 与 Table 3 指标）。

在 DeepSeek 系列中的位置

图示详情

为何 R1 不改架构

RLVR 只改 后训练（采样、奖励、策略梯度），不动 MLA / MoE 结构。因此 R1 与 V3 权重形状、KV cache 格式、推理引擎配置一致——差异在 行为分布（更长 CoT、更强推理）。

延伸

论文：R1 2501.12948 · V3 2412.19437

DeepSeek-R1 梗概

← 中文导读 · ← 仓库首页（EN） · ← 演进总览 §3.4 · ← 版本目录 · RLVR 详解 · Raschka §RLVR/GRPO

定位

2025 年 1 月发布，基于 DeepSeek-V3-Base 的 推理专精 模型。架构与 V3 完全相同（671B / 37B activated / 128K）；差异在 RLVR + GRPO 后训练，带火「可验证奖励强化学习」路线。

核心训练

训练管线：DeepSeek-R1 训练 Pipeline

与相邻版本

推理 infra

与 V3 相同：MLA latent KV、--trust-remote-code、--block-size 1 等。

参考

• 论文：arXiv:2501.12948
• RLVR 概念与奖励设计
• Raschka R1/RLVR 梳理

RL / 后训练笔记

← 演进总览 §3.4 R1 · RLVR 详解 · 书中 RL 卷

GRPO 长程任务局限

← 中文导读 · ← 仓库首页（EN） · ← RL 笔记索引 · ← RLVR · GRPO · ← 演进总览 §3.4 R1 · 书中对应

作者：划水的青蛙 · 知乎原文
性质：社区讨论整理；非 DeepSeek 官方文档。商业转载请联系原作者。

一句话

GRPO 仍是好算法，但 R1 时代验证的是 短程、可终局判分 的任务；硬搬到 长程 Agent / 编程 时，会在 吞吐、奖励稀疏、组内可比性 上同时吃瘪——智谱、MiniMax、DeepSeek 的后续路线都在 绕开或补 GRPO 的短板。

背景：短程优化 vs 长程 Agent

R1 的 RLVR + GRPO 针对的是 同一 prompt、$G$ 条 rollout、终局 verifier 打分——在短 CoT 上成立。长程任务把 轨迹长度、上下文压缩、延迟归因 拉进同一个组内比较，前提就被动摇了。

核心结论

工程瓶颈：吞吐 vs 样本多样性

长程 RL 要先解决 怎么跑起来，再谈算法：

1. 先短后长：课程从短任务切到长任务时，梯度信号剧烈震荡。
2. 长短混训、同组打分：短 rollout 先结束，长 rollout 还在跑 → 组内 advantage 汇总前 大量 GPU 空转。
3. 全组长程失败：一组任务跑数小时、$G$ 条全败 → 零 reward，等于白烧资源（见下文「全败退化态」）。

GRPO 的三条前提

社区归纳 GRPO / RLVR 能 work 的三条前提，以及长程下的裂缝：

同题可比较：A/B/C/D 反例

同一长程 prompt 采样 $G=4$，终局成功 $=1$、失败 $=0$，组内均分 $\bar r = 0.5$：

问题在于：

• 同样的 $+0.5$，A 与 B 不是一回事：B 里大量 冗余 token 也被正向奖励 → per-token 信用分配不一致。
• B 后半段 可能在 摘要/压缩后的上下文 上生成，与 A 全程单一状态 的轨迹 不可比。
• GRPO 只奖终局：无法表达「前半段垃圾、后半段正确」这类 过程结构。

信号可验证 → 延迟归因

模型收到的是 「这次整体不行」，而不是 「第 $X$ 步动作错了」。错误可能要 几十步之后 才暴露，需要 反传归因——critic / 过程奖励 擅长，纯组内终局比较 不擅长。

组内降噪 → 两种退化态

短程任务里「独赢」相对少见；长程里 二者都更常出现。

业界应对

三家路径不同，共同点：承认 GRPO 直接硬上长程不够，要在 critic、过程奖励、蒸馏监督 上补洞。

与本地文档的对照：

延伸阅读

DeepSeek-R1 训练 Pipeline

← 中文导读 · ← RL 笔记索引 · ← 演进总览 §3.4 R1 · 《ds-技术报告》 论文：DeepSeek-R1: Incentivizing Reasoning Capability in LLMs via Reinforcement Learning arXiv：2501.12948 · PDF：DeepSeek-R1 论文 PDF 基座：DeepSeek-V3 Base

参考图（公众号整理版）

总览：两条支路

图示详情

支路 A：DeepSeek-R1-Zero

输入 / 算法 / Reward

涌现行为

• 响应长度随训练增长（「思考时间」增加）
• 自反思、验证、换策略
• 「Aha moment」：模型自发学会重新审视

局限

• 可读性差、中英混杂
• 偏推理，写作/开放域 QA 弱

支路 B：DeepSeek-R1 四阶段

中间 checkpoint：Dev-1 → Dev-2 → Dev-3 → R1

阶段 1：冷启动 SFT → R1 Dev-1

冷启动 CoT 风格要求：

1. 先理解问题 → 详细推理 → 反思与验证
2. 第一人称、段落简短、避免 markdown
3. 语言与问题一致（V3 翻译 thinking 消混杂）

Trade-off：Dev-1 指令遵循↑（IF-Eval、ArenaHard），但冷启动数据小，AIME 等推理略降于 R1-Zero。

阶段 2：第一阶段 RL → R1 Dev-2

Dev-2 推理能力恢复并超越 Dev-1（Table 3：AIME、Codeforces 等显著提升）。

阶段 3：拒绝采样 + SFT → R1 Dev-3

后处理链：

图示详情

Dev-3 在推理与通用（MMLU、IF-Eval）上进一步平衡。

阶段 4：第二阶段 RL → DeepSeek-R1

最终 R1：推理保持 + helpful & harmless 对齐。

各阶段指标快照

与 OneReason / LoRA 系列对照

蒸馏

DeepSeek-R1 还将长 CoT 能力 蒸馏到小模型（Qwen/Llama 等），开源 R1 系列 checkpoint。

文件索引

DeepSeek-LLM V1

← 中文导读 · ← 仓库首页（EN） · ← 演进总览 §3.1 · ← 版本目录 · BBPE 词表专文 · V1→V3 演进 原文：DeepSeek LLM: Scaling Open-Source Language Models with Longtermism · arXiv:2401.02954 PDF：2401.02954.pdf · 图件见 Scaling Laws 图件 · BBPE 词表专文

命名说明：论文与社区常称 DeepSeek-LLM 或 DeepSeek V1；与后续 DeepSeek-V2 / V3（MoE + MLA 旗舰线）是不同架构代际，但构成同一产品线的早期稠密基座。

摘要

开源大语言模型（LLM）近年来发展迅猛，但既往文献中的 scaling laws 结论各异，给 LLM 规模化扩展蒙上了阴影。本文深入研究 scaling laws，并给出适用于两种主流开源配置（7B 与 67B）的独到发现。在 scaling laws 指导下，我们推出 DeepSeek LLM——一项以长期主义推进开源语言模型的工程。

预训练阶段我们构建了目前约 2 万亿 tokens、持续扩充的数据集；并对 Base 模型进行 监督微调（SFT） 与 直接偏好优化（DPO），得到 Chat 模型。评测表明：DeepSeek LLM 67B 在多项 benchmark 上超越 LLaMA-2 70B，尤其在代码、数学与推理领域；开放评测中，DeepSeek LLM 67B Chat 表现优于 GPT-3.5。

1. 引言

基于 decoder-only Transformer 的 LLM 已成为通向 AGI 的核心路径。通过下一词预测在大规模语料上自监督预训练，模型获得创作、摘要、代码补全等能力；SFT 与奖励建模使其更好遵循用户意图，对话能力迅速扩展。

ChatGPT、Claude、Bard 等闭源产品以巨大算力与标注成本拉高社区对开源 LLM 的期望。LLaMA 系列整合多项工作，形成高效稳定架构（7B–70B），成为开源模型的 de facto 基准。

然而开源社区在 LLaMA 之后多聚焦于固定尺寸（7B/13B/34B/70B）的高质量训练，较少系统研究 scaling laws。早期工作（Chinchilla、Kaplan 等）对模型/数据随算力扩展的最优分配结论不一致，对超参讨论也不充分。

本文工作：

1. 研究 batch size 与 learning rate 的 scaling laws；
2. 系统研究 模型与数据规模 的 scaling laws，揭示最优分配策略并预测大模型性能；
3. 发现 不同数据集 拟合出的 scaling laws 差异显著——数据选择会明显影响 scaling 行为，跨数据集泛化 scaling laws 需谨慎。

在 scaling laws 指导下，我们从零训练并尽可能开源信息：

• 2T tokens 预训练语料，以中英文为主；
• 架构大体遵循 LLaMA，但用 multi-step LR 替代 cosine，便于 continual training；
• 150 万+ SFT 实例；并采用 DPO 提升对话表现。

DeepSeek LLM 67B 在代码/数学/推理上超越 LLaMA-2 70B；67B Chat 在中英文开放评测上优于 GPT-3.5；安全评测表明 67B Chat 在实践中可给出无害回复。

2. 预训练

2.1 数据

目标：全面提升数据丰富度与多样性。参考 The Pile、RedPajama、FineWeb、LLaMA 等来源，流程分三阶段：

去重：对 Common Crawl 全语料去重，效果远优于单 dump 内去重。91 个 dump 跨库去重率达 89.8%，单 dump 仅 22.2%（Table 1）。

Tokenizer — 完整解读见 BBPE 词表与 Tokenizer 专文（§2.1 论文段落；V2 沿用同词表）：

编码流程（推理侧） · 系列延续（V2→V4）

图示详情 · 详述见 BBPE 专文 §2

2.2 架构

Table 2 — DeepSeek LLM 规格

同 D、不同 M → 不同 $C$；2T 是产品统一语料，非 Formula 4 compute-optimal 要求（7B 相对 ~140B 最优属 over-train）。详见 产品训练与 Scaling Law。

微观设计：

• Pre-Norm + RMSNorm
• FFN：SwiGLU，中间维 8/3 × d_model
• 位置编码：RoPE
• 67B 使用 GQA 降低推理成本

宏观设计：

• 7B：30 层；67B：95 层（在参数量与其他开源模型可比的前提下，便于 pipeline 划分）
• 与常见 GQA 模型加宽 FFN 不同，67B 加深网络而非加宽 FFN，以追求更好性能

2.3 超参数

• 初始化 std = 0.006
• AdamW：β1=0.9, β2=0.95, weight_decay=0.1
• Multi-step LR（非 cosine）：
• Warmup 2000 steps 至最大 LR
• 80% tokens 后降至最大值的 31.6%
• 90% tokens 后降至 10%
• 梯度裁剪：1.0

Multi-step vs Cosine：1.6B 模型、100B tokens 上，最终性能基本一致；multi-step 在扩大训练规模时可复用第一阶段 checkpoint，便于 continual training。三阶段 token 比例选 80% / 10% / 10% 以平衡复用与性能。

原理详解、公式与 LLaMA cosine 对比 → 学习率调度 Wiki

Batch size 与 LR 随模型规模变化，见 Table 2。

2.4 基础设施

• 并行：数据并行 + 张量并行 + 序列并行 + 1F1B 流水线并行
• Flash Attention
• ZeRO-1 分片 optimizer states
• 计算/通信 overlap（ZeRO-1 reduce-scatter、序列并行 all-gather 等）
• 算子融合：LayerNorm、GEMM、Adam update
• bf16 训练 + fp32 梯度累积
• In-place cross-entropy（kernel 内 bf16→fp32，降低显存）
• 每 5 分钟 异步 checkpoint；支持换 3D 并行配置 resume
• 评测：vLLM（生成任务）；continuous batching（非生成）

3. Scaling Laws

算力预算 $C$、模型规模 $N$、数据规模 $D$：传统近似 $C \approx 6ND$。核心问题：算力增加时如何最优分配模型与数据。

答疑：为何改用 $C=M\cdot D$？ — $6N_1$/$6N_2$ 相对 $M$ 的误差（Table 3）、IsoFLOP 为何必须用 $M$

早期工作对最优分配结论不一，且超参是否达最优存疑。本文：

1. 先研究超参 scaling laws（batch、LR）；
2. 用 M（non-embedding FLOPs/token） 替代 N，用 C = MD 替代 C = 6ND；
3. 发现数据质量影响最优 model/data 分配。

3.1 超参 Scaling Laws

小算力（$C=10^{17}$ FLOPs，177M FLOPs/token）网格搜索：batch 与 LR 在较宽范围内 generalization error 稳定（Figure 2a）。

Figure 2 — batch × LR 网格搜索（上：$C=10^{17}$；下：$C=10^{20}$ 验证）

来源：Figure 2。(a) 小算力下 batch/LR 宽带稳定；(b) $10^{20}$ 验证时拟合点（红星）落在最优区中心。

用 multi-step LR 训练多组模型（算力 $10^{17}$–$2\times10^{19}$），复用第一阶段。将 generalization error 超出最小值 ≤0.25% 的参数视为 near-optimal，拟合得 Formula 1：

$$ \begin{aligned} \eta_{\mathrm{opt}} &= 0.3118 \cdot C^{-0.1250} \ B_{\mathrm{opt}} &= 0.2920 \cdot C^{0.3271} \end{aligned} $$

Formula 1 数值对照：

• 算力 ↑ → $B_{\mathrm{opt}}$ ↑，$\eta_{\mathrm{opt}}$ ↓

直接打开 Figure 3

• 7B/67B 实测点落在 near-optimal 带内；$10^{20}$ 验证时拟合参数位于最优区中心（Figure 2b）

局限：尚未建模 $C$ 以外因素；同算力不同 model/data 分配下最优超参空间略有差异——待后续研究。→ Scaling-Law 选择性应用 §3

3.2 最优模型/数据 Scaling

传统写法用 $C \approx 6ND$，其中模型规模 $N$ 有两种常见取法：

于是可用 $6N_1$ 或 $6N_2$ 近似「每 token 算力」。但两者都有明显误差：

• $6N_1$：不含 attention 的 $O(L^2)$ 计算开销；
• $6N_2$：多了 vocab 投影（对模型能力贡献小），仍不含 attention。

为此报告引入 $M$（non-embedding FLOPs/token）：计入 attention，不计 vocab；算力预算简化为 $C = M \cdot D$。

Formula 2 — 三种表示的关系：

$$ \begin{aligned} 6N_1 &= 72 \cdot n_{\mathrm{layer}} \cdot d_{\mathrm{model}}^2 \ 6N_2 &= 72 \cdot n_{\mathrm{layer}} \cdot d_{\mathrm{model}}^2 + 6 \cdot n_{\mathrm{vocab}} \cdot d_{\mathrm{model}} \ M &= 72 \cdot n_{\mathrm{layer}} \cdot d_{\mathrm{model}}^2 + 12 \cdot n_{\mathrm{layer}} \cdot d_{\mathrm{model}} \cdot l_{\mathrm{seq}} \end{aligned} $$

Table 3 — 不同规模下 $6N_1$、$6N_2$ 相对 $M$ 的偏差（$n_{\mathrm{vocab}}=102400$，$l_{\mathrm{seq}}=4096$）：

Table 3 — 模型规模三种表示的差异（$N_1$、$N_2$ 相对 $M$ 的偏差）

来源：Table 3。右两列 $6N_1/M$、$6N_2/M$ 越偏离 1，用 $6N$ 近似 $M$ 的误差越大。

怎么读 Table 3：

• $6N_1/M < 1$（小模型仅 0.43）：$6N_1$ 低估算力，因缺 attention 项；层数少、$d$ 小时最明显。
• $6N_2/M > 1$（小模型 1.32）：$6N_2$ 高估算力，因计入 vocab 投影。
• 模型变大后两列趋近 1，但小模型上偏差仍可达 50%，会污染 IsoFLOP 拟合——故 Formula 4 统一用 $M$ 而非 $6N_1$/$6N_2$。

采用 IsoFLOP profile（Chinchilla）：8 个算力预算（$10^{17}$–$3\times10^{20}$），每预算约 10 种 model/data 分配；超参由 Formula 1 确定；在 100M tokens 独立验证集上算 generalization error（bits-per-byte）。

Figure 4a — IsoFLOP 曲线（各算力档 loss 随 $M$ 呈 U 形，谷底 = 最优分配）

来源：Figure 4a。横轴 = non-embedding FLOPs/token $M$；纵轴 = validation bits-per-byte。

Formula 4 — 最优 model/data 分配：

$$ \begin{aligned} M_{\mathrm{opt}} &= 0.1715 \cdot C^{0.5243} \ D_{\mathrm{opt}} &= 5.8316 \cdot C^{0.4757} \end{aligned} $$

→ 模型与数据规模随算力近似等比扩展（指数 $a \approx b \approx 0.5$）。

Formula 4 数值对照：

Figure 4b/4c — 最优 model / data scaling

来源：Figure 4b/4c。左：$M_{\mathrm{opt}}$ vs $C$；右：$D_{\mathrm{opt}}$ vs $C$。

Figure 5 — 性能 scaling 曲线（小实验预测 7B/67B）

来源：Figure 5。灰点 = 小算力实验；虚线 = loss 幂律拟合；蓝星 = DeepSeek LLM 7B / 67B（各 2T tokens）。

小实验可准确预测 1000× 算力下 7B/67B 性能。

读图提示：Figure 3/5 蓝星 = 给定产品 $(M,D=2T)$ 校验 hyperparam / loss；Figure 4 = 固定 $C$ 下最优 $M/D$ 分配（未用于 Table 2 定 2T）。详见 Scaling-Law 选择性应用。

3.3 不同数据上的 Scaling Laws

DeepSeek LLM 开发过程中语料迭代多轮：调整各数据源占比、提升整体质量。借此可分析数据集差异对 scaling laws 的影响。

在三种语料上分别拟合 Formula 4 的指数 $a$（$M_{\mathrm{opt}} \propto C^a$）与 $b$（$D_{\mathrm{opt}} \propto C^b$）：

• 早期内部数据 vs 当前内部数据（质量逐步提升）
• OpenWebText2（Kaplan et al. 用过的公开集；规模较小、处理更精细，质量甚至高于当前内部数据）

Table 4 — 模型/数据 scaling 系数随训练数据分布而变：

Table 4 — 模型/数据 scaling 系数随训练数据分布而变

来源：Table 4。$a$ 越大 → 算力应多投模型；$b$ 越大 → 算力应多投数据。

数据质量越高 → $a$ 越大、$b$ 越小 → 应多分配算力给模型扩展。高质量数据逻辑清晰、充分训练后预测难度低，扩大模型更有利。不同数据集的 scaling 指数差异也可作为数据质量间接指标——这或许也是早期 scaling law 研究结论不一致的原因之一。

4. 对齐

4.1 数据

约 150 万 中英 instruction 实例：

• Helpful（120 万）：通用 31.2% / 数学 46.6% / 代码 22.2%
• Safety（30 万）：各类敏感话题

4.2 SFT

• 7B：GSM8K、HumanEval 持续提升；67B 很快触顶
• 监控 repetition ratio：3868 条中英 prompt，统计无法终止、无限重复的比例
• 数学 SFT 增多 → repetition ratio 上升（推理模式相似，弱模型难学）
• 缓解：两阶段 SFT（第二阶段去掉 math/code）或 DPO

7B 两阶段 SFT：stage-1 repetition 2.0% → stage-2 1.4%

4.3 DPO

• 基于 helpfulness / harmlessness 构建 preference 数据
• Helpful：多语言 prompt（创作、QA、指令遵循等），用 DeepSeek Chat 生成候选回复
• 1 epoch，LR 5e-6，batch 512，warmup + cosine LR
• 效果：增强开放域生成；标准 benchmark 变化不大

5. 评测

5.1 公开 Benchmark

数据集覆盖：

• 多选：MMLU, C-Eval, CMMLU
• 语言理解/推理：HellaSwag, PIQA, ARC, OpenBookQA, BBH
• 闭卷 QA：TriviaQA, NaturalQuestions
• 阅读：RACE, DROP, C3
• 指代：WinoGrande, CLUEWSC
• LM：Pile
• 中文：CHID, CCPM
• 数学：GSM8K, MATH, CMath
• 代码：HumanEval, MBPP
• 考试：AGIEval

评测方式：

最大序列长度 2048 或 4096。

5.1.1 Base 模型

• 2T 双语预训练，英文理解与 2T 英文 LLaMA-2 相当
• 67B 在 MATH、GSM8K、HumanEval、MBPP、BBH、中文 benchmark 上显著优于 LLaMA-2 70B
• 67B 相对 LLaMA-2 70B 的优势 大于 7B 相对 7B——语言冲突对小模型影响更大
• LLaMA-2 在部分中文任务（如 CMath）表现不错——数学推理可跨语言迁移；但 CHID（成语）等需足够中文 tokens

5.1.2 Chat 模型

• SFT 后多数任务提升
• 知识类（TriviaQA, MMLU）：小幅波动，不代表 SFT 增删知识；Chat 0-shot 可比 Base 5-shot
• 推理类：SFT 含 CoT 格式，BBH 等略升——主要是学会推理格式而非新推理能力
• 下降任务：HellaSwag 等完形/句补——纯 LM 更擅长
• 数学/代码：HumanEval、GSM8K 等提升 20+ 点——Base 在这些任务上欠拟合，SFT 补充知识；能力可能偏代码补全与代数题

5.2 开放评测

5.2.1 中文 — AlignBench

683 题，8 大类 36 小类；GPT-4 按参考答案与模板打分。

• DeepSeek 67B Chat 超越 ChatGPT 等基线，仅次于两版 GPT-4
• DPO 版几乎全面提升
• 中文基础语言：DPO 版甚至高于最新 GPT-4；中文推理：显著领先其他中文 LLM

5.2.2 英文 — MT-Bench

8 类多轮对话。

• 67B Chat：8.35，与 GPT-3.5-turbo 可比；超越 LLaMA-2-Chat 70B、Xwin 70B、TÜLU 2+DPO 70B
• 67B Chat-DPO：8.76，仅次于 GPT-4

5.3 Held-Out 评测

在独立 held-out 集上 bits-per-byte 与 scaling 预测一致，验证 scaling laws 有效性。

5.4 安全评测

20 人专家团队，覆盖歧视偏见、侵犯合法权益、违法犯罪等类别。

• 多数子类 >95% 无害回复率（如歧视类 486/500，侵权类 473/500）
• 安全贯穿预训练、SFT、DPO 全流程

5.5 讨论

• 避免 benchmark decoration 与训练「暗箱」
• 双语训练在代码/数学/推理上的优势随规模放大
• SFT 数据配比（尤其数学）需与模型容量匹配

6. 结论、局限与未来工作

结论

DeepSeek LLM 是在 2T 中英 tokens 上从零训练的开源系列。本文详述超参选择、scaling laws 与微调经验；校准既往 scaling laws，提出新的最优 model/data 分配策略；给出给定算力下 near-optimal batch/LR 的预测方法；并指出 scaling laws 与数据质量相关——可能是不同工作 scaling 行为差异的根因。在 scaling laws 指导下完成预训练与全面评测。

局限

• Chat 模型无预训练后持续知识更新
• 可能生成非事实内容、幻觉
• 初版中文数据不 exhaustive，部分中文话题表现欠佳
• 语料以中英为主，其他语言需谨慎使用

未来

• 发布代码智能与 MoE 技术报告（高质量代码预训练数据、稀疏架构达稠密性能）
• 构建更大更好数据集，提升推理、中文知识、数学、代码
• 对齐团队研究 helpful/honest/safe；初步实验表明 RL 可提升复杂推理

附录概要

相关文档

• 版本演进总览 · 《ds-技术报告》§3.1 V1
• BBPE 词表与 Tokenizer 专文（§2.1 Tokenizer；预分词 / 102,400 embedding）
• V1→V3 演进
• Scaling 专题（本仓答疑）
• 产品训练 vs Scaling Law：7B/67B 为何都训 2T？
• Scaling-Law 选择性应用（Figure 3/4/5 分工）
• Scaling 答疑（Formula 1/4 推导）
• 学习率调度（§2.3 multi-step vs cosine）
• 中文结构化译文
• 技术要点提炼
• 索引
• 英文原文
• H20 八卡 Scaling Law 实验设计（Figure 3 / Formula 4 / Figure 5 拟合配置）

DeepSeek-LLM V1：BBPE 词表与 Tokenizer

← 中文导读 · ← 仓库首页（EN） · ← V1 正文 · ← 演进总览 §3.1 V1 · V1→V3 演进 论文：DeepSeek-LLM arXiv:2401.02954 §2.1 · V2 沿用同词表

一句话

DeepSeek-LLM V1 采用 BBPE（Byte-level Byte-Pair Encoding）：在 UTF-8 字节序列上做 BPE，配合 字符类预分词 与 数字单 digit 拆分；常规词表 100,000，加 15 个 special token 后 100,015，模型 embedding 维配置 102,400 以预留扩展位。

BPE 简述

Byte Pair Encoding（BPE） 是 subword 分词里最常用的训练式词表构造法之一（Sennrich et al., 2016；GPT-2 / RoBERTa 系广泛采用）。相对词级分词，它在 词表大小 与 序列长度 / OOV 之间折中：常见片段共享 id，罕见词由若干 subword 拼成，无需 <unk>。

训练：

1. 初始符号表 = 基础单元（字符、或 字节 —— 见下节 BBPE）
2. 重复：统计当前序列中 相邻 symbol pair 的频率，将最高频 pair 合并为新 symbol，写入词表
3. 达到目标 merge 次数或词表大小 $V$ 后停止

编码：对输入做同样的预切分后，按 merge 优先级 贪心最长匹配（或等价 trie 查表），得到 token id 序列。解码为 merge 的逆过程：id → subword 字符串 → 拼接还原文本。

对已有 NLP 基础的读者：BPE 不建模语义，只压缩词表；预分词（pre-tokenization） 规则（空格、标点、CJK 边界等）往往比 merge 算法本身更影响中英混排质量。DeepSeek V1 在标准 BPE 之上把基础单元降到 UTF-8 字节，并约束字符类不跨类 merge —— 即下文 §2 BBPE。

1. 与预训练数据管线的关系

Tokenizer 训练语料来自 V1 三阶段数据管线 的多语言子集（与 V1 §2.1 数据 / #tokenizer 同一论文段落）：

图示详情

BBPE 本身在约 24GB 多语言语料 上训练 merge 规则；2.0T tokens 的预训练则走完整管线后再分词。

2. BBPE 是什么

BBPE = 在 字节（byte）序列 上运行 BPE，而非 Unicode 字符或 SentencePiece 的 pretokenized 单元。

直觉：先 text → bytes，再在 byte 序列上统计 pair 频率、迭代 merge，得到 subword 词表。

图示详情

示意说明：预分词后文本变为 UTF-8 字节流；初始符号表为 256 个字节；每轮合并语料中最高频 相邻 byte pair，写入 merge 表；重复至 100,000 次 merge。推理时对同样预切分后的字节序列 贪心最长匹配。因任意 UTF-8 文本可先落到字节层，不会出现字符级 OOV（罕见片段至多拆成更多 byte/subword token，序列变长而非 <unk>）。

图上 48 69、E4 B8 96 是十六进制记法，不是单独一套「16 进制词表」。实现里每个符号是 8-bit 字节 $b \in {0,\ldots,255}$（即 0x00–0xFF）；48 = 十进制 72 = 'H'，69 = 'i'。E4 B8 96 等为 中文等 CJK 字符在 UTF-8 下的 3 字节编码示意。HuggingFace tokenizers 在内部用 u8 序列做 merge/encode。

3. 预分词规则

论文在 BPE 合并前做 pre-tokenization，限制 不同字符类之间不得跨类 merge（做法类似 GPT-2）：

效果：中英双语 + 代码混排时，CJK 与 Latin 边界清晰，数字可组合性更好。

4. 词表规模与 embedding 配置

易混点：HF config.json 里的 vocab_size=102400 是 embedding 矩阵行数；有效 token id 仍以 tokenizer 的 100,015 为准，未用 id 对应 embedding 行可视为预留。

5. 编码流程

图示详情

与后续 MLA / MoE / DSA 正交：改 attention 或 FFN 不改变 tokenizer；V1 Chat 的 SFT/DPO 也在同一词表上继续。

6. 在 DeepSeek 系列中的延续

V1 的 102,400 embedding 预留 与 V3 的 128K 扩展 是不同代际决策；读 checkpoint 时须对齐 config.vocab_size 与 tokenizer 文件。

7. 推理 infra 关注点

参考

1. DeepSeek-AI. DeepSeek LLM: Scaling Open-Source Language Models with Longtermism. arXiv:2401.02954, 2024. — §2.1 Data, Tokenizer; Table 1 dedup.
2. DeepSeek-V2：同 tokenizer（§2 / Appendix 数据节）。
3. 本地精读：V1 §2.1 Tokenizer · technical-highlights（复现向）

DeepSeek-V2 梗概

← 中文导读 · ← 仓库首页（EN） · ← 演进总览 §3.2 · ← MoE 线导读 · ← 版本目录 · V1→V3 演进 · MLA 详解 · V1 BBPE 词表 · Raschka 解读

定位

2024 年 5 月发布。相对 DeepSeek-LLM 67B 稠密，V2 是架构代际跃迁：首次引入 MLA 与 DeepSeekMoE，236B 总参、每 token 激活 21B，128K 上下文。论文称相对 67B 稠密：训练成本 -42.5%、KV cache -93.3%、生成吞吐 5.76×。

核心架构

相对 V1 的关键变化

推理 infra 关注点

• KV cache 变为 MLA latent 格式（后续 V3 系继承）
• 需自定义 kernel / vLLM 适配（DeepSeek 后续提供 FlashMLA 等）
• MoE 路由为 softmax 系（V3 改为 aux-loss-free sigmoid 路由，见 aux-loss-free）

上下游

参考

• 论文：arXiv:2405.04434
• 仓库：deepseek-ai/DeepSeek-V2
• MLA 前向：MLA前向计算流程§流程图 · 公式详解

DeepSeek-V3.1 梗概

← 中文导读 · ← 仓库首页（EN） · ← 演进总览 §3.5 · ← 版本目录 · Raschka §3.4 Hybrid

定位

2025 年中期在 V3 权重基础上做 post-training，无架构变更。主要贡献是 Hybrid 推理模式：同一套权重可在 thinking（推理链）与 chat（直接回答）之间切换，不再像 V3/R1 那样 Base 与推理模型分离。

V3.1-Terminus 是 V3.1 系列收尾 checkpoint，上下文扩至 128K，并作为 V3.2 继续预训练 的起点。

相对 V3 的变化

MLA 模式切换

为后续 DSA 铺路，Prefill 与 Decode 采用不同 MLA 模式：

图示详情 · 演进总览 §3.5

• Prefill：MHA 模式（各 query head 独立 latent）
• Decode：MQA 模式（latent 在 query head 间共享）

两阶段 仍是 MLA（低秩 latent 进 cache）；差别在 latent 按 head 展开还是全体共享。与常见注意力族的对应（以 8 个 Q head 为例）：

延伸：DSA 逻辑 · 演进总览 §V3.1

推理 infra 关注点

• 与 V3 相同：同质 MLA Latent-Cache
• 新增 Prefill MHA / Decode MQA 切换逻辑，引擎需正确实现两阶段模式
• KV offload 困境与 V3 相同：格式非标准，长上下文仍受 HBM 限制

上下游

参考

• 外部解读：Raschka V3→V3.2 梗概 · 全文解析 · 原文
• 仓库：deepseek-ai/DeepSeek-V3（V3.1 权重见 HuggingFace 发布页）

DeepSeek-V3.2 梗概

← 中文导读 · ← 仓库首页（EN） · ← 演进总览 §3.6 · ← 版本目录 · DSA 梗概 · Raschka §4 DSA

定位

2025 年 12 月正式版；2025 年 9 月先有 DeepSeek-V3.2-Exp（DeepSeek 官方实验 release）。相对 V3.1-Terminus，唯一架构改动是引入 DeepSeek Sparse Attention (DSA)——DeepSeek 原创稀疏注意力，在长上下文场景显著降算量，公开 benchmark 与 V3.1-Terminus 基本持平。

V3.2-Exp 与 V3.2 架构相同；Exp 用于验证稀疏注意力不损精度，V3.2 为完整续训 + 后训练成品。

DSA 机制

DSA 详解 · 完整逻辑 · 系列目录

两阶段稀疏注意力：

1. Lightning Indexer：廉价点积为历史 token 打分（仍 $O(L^2)$，但 head 维极低）
2. Top-$k$ Selector：选出 $k=2048$ 个最重要 latent entry
3. Core Attention：仅对 top-$k$ 做 MLA attention（$O(Lk)$）

概念：Lightning Indexer · Top-$k$ Selector · Core MLA · Indexer-Cache · Latent-Cache · ESS

异构 Cache

异构 KV 表 · DSA逻辑详解 §4

推理 infra 关注点

• DeepGEMM：indexer logit kernel（含 paged 版）
• FlashMLA：sparse attention paged kernel
• Index Share（IndexCache）与 ESS offload 均叠加在 V3.2 上
• vLLM day-0 support；需自定义 sparse attention 代码路径