Files
llm-atlas/src/pages/deepseek/index.astro
T

1777 lines
72 KiB
Plaintext
Raw Blame History

This file contains ambiguous Unicode characters
This file contains Unicode characters that might be confused with other characters. If you think that this is intentional, you can safely ignore this warning. Use the Escape button to reveal them.
---
import BaseLayout from "@/layouts/BaseLayout.astro";
import DeepSeekLineage from "@/components/DeepSeekLineage.astro";
import DeepSeekLab from "@/components/DeepSeekLab.astro";
import DeepSeekArtifactLab from "@/components/DeepSeekArtifactLab.astro";
import { deepseekBranches, deepseekLedgers, deepseekPaperChain, deepseekWaves } from "@/data/deepseek";
const toc = [
["00", "compass", "先问清二十四张账"],
["01", "lineage", "十次问题转向"],
["02", "grammar", "读参数与成本数字"],
["03", "dense", "LLM:Dense 坐标"],
["04", "moe", "MoE:专家特化"],
["05", "mla", "V2:缓存状态"],
["06", "absorption", "MLA:吸收与位置分叉"],
["07", "v3", "V3:四层协同"],
["08", "balance", "路由:均衡不干扰能力"],
["09", "fp8", "FP8:精度角色合同"],
["10", "dualpipe", "DualPipe:隐藏空泡"],
["11", "mtp", "MTP:训练与推理两用"],
["12", "grpo", "Math:GRPO"],
["13", "r1zero", "R1-Zero:隔离实验"],
["14", "r1", "R1:可用训练链"],
["15", "dapo", "DAPO / Dr.GRPO 反查"],
["16", "v32", "V3.2:稀疏注意力"],
["17", "agent-data", "V3.2:Agent 环境"],
["18", "v4", "V4:百万上下文"],
["19", "v4-state", "V4:异构状态与稳定性"],
["20", "k3", "与 K3 的继承边界"],
["21", "lab", "四联交互实验"],
["22", "artifact", "真实权重执行"],
["23", "branches", "别漏掉旁支"],
["24", "audit", "事实、推导与教学模型"],
["↳", "papers", "六十节点阅读链"],
];
---
<BaseLayout
title="DeepSeek 技术谱系与真实权重深读:从 Dense、MoE、MLA 到 R1 与 V4"
description="用二十四张问题账、十次技术转向、十个交互实验、真实 V2-Lite 权重、公开语料路由区间与吸收式缓存 trace 和六十个一手节点,完整理解 DeepSeek 的 MoE、MLA、FP8、DualPipe、GRPO、R1、V3.2 与 V4。"
section="deepseek"
>
<header class="page-hero deepseek-hero">
<div class="page-hero-inner">
<div>
<p class="eyebrow"><span>SPOTLIGHT / DEEPSEEK · ROUND 03</span> ALGORITHM × SYSTEM × REAL WEIGHTS</p>
<h1>不要背模型名<br />要看懂每次为什么转向</h1>
<p class="lead">
这不是七篇报告的摘要,而是一套可追问、可计算、可反驳的技术谱系:
容量、激活、缓存、通信、数值、奖励和长程状态各自记账,再看它们怎样从 DeepSeek LLM
一路汇入 V4,并与 Kimi K3 发生继承或分叉。
</p>
</div>
<dl class="page-facts">
<div><dt>SPAN</dt><dd>2024.01 → 2026.06</dd></div>
<div><dt>LEDGERS</dt><dd>24 张问题账</dd></div>
<div><dt>LINEAGE</dt><dd>10 次技术转向</dd></div>
<div><dt>LABS</dt><dd>10 个可操作实验</dd></div>
<div><dt>EVIDENCE</dt><dd>60 个一手 / 官方节点</dd></div>
<div><dt>STATUS</dt><dd>三轮 · 真实权重执行</dd></div>
</dl>
</div>
</header>
<div class="report-shell">
<aside class="side-rail" aria-label="本页目录">
<p>CONTENTS</p>
<ol>
{toc.map(([number, id, label]) => (
<li><a href={`#${id}`}><span>{number}</span>{label}</a></li>
))}
</ol>
<div class="rail-note">
<b>阅读约定</b>
作者报告、公式推导与教学模型使用不同标签;DAPO / Dr.GRPO 明确标为公开后续研究,不冒充 R1 内部配方。
</div>
</aside>
<article class="article">
<section class="article-section" id="compass">
<p class="eyebrow"><span>00</span> THE PROBLEM COMPASS</p>
<h2>先把二十四个对象分开,才不会被“大、快、强”三个字带走</h2>
<p class="lede">
一篇技术报告最容易制造的错觉,是把参数量、激活计算、缓存、训练成本、吞吐和能力揉成一个“效率”。
下面每张账只问一个对象,并把回答能走到哪里、不能走到哪里同时写出来。
</p>
<div class="ledger-grid">
{deepseekLedgers.map(([id, object, question, boundary]) => (
<article class="ledger-card">
<header><span>{id}</span><b>{object}</b></header>
<h3>{question}</h3>
<p>{boundary}</p>
</article>
))}
</div>
<div class="reading-rule">
<span>一条贯穿全文的读法</span>
<p><b>先认对象</b><i>→</i><b>再看瓶颈</b><i>→</i><b>找到机制</b><i>→</i><b>核对系统代价</b><i>→</i><b>最后看证据边界</b></p>
</div>
</section>
<section class="article-section" id="lineage">
<p class="eyebrow"><span>01</span> TEN PROBLEM SHIFTS</p>
<h2>时间线不是发布会日历,而是十次“问题定义”转向</h2>
<p class="lede">
把 DeepSeek 看成模型名字序列会很乱;把它看成“容量、缓存、训练、推理、长上下文”五张账单,
技术演进就清楚了。
</p>
<DeepSeekLineage />
<div class="wave-grid">
{deepseekWaves.map(([id, time, title, text]) => (
<article>
<header><span>{id}</span><time>{time}</time></header>
<h3>{title}</h3>
<p>{text}</p>
</article>
))}
</div>
<div class="thesis">
<span class="micro-label">核心观察</span>
<p>
DeepSeek 的强项是把模型结构和硬件约束写在同一张设计图里。MLA 不只是新 attention,
它直接针对服务时 KV Cache;FP8 不只是少用几个比特,它要求累加精度、缩放和通信共同配合;
GRPO 不只是 PPO 变体,它直接移除同规模 critic 的显存负担。
</p>
</div>
</section>
<section class="article-section" id="grammar">
<p class="eyebrow"><span>02</span> NUMBER GRAMMAR</p>
<h2>先学会读报告数字:总容量、激活路径和系统成本不是同一列</h2>
<div class="number-grammar">
<article>
<span>TOTAL PARAMETERS</span>
<b>模型“装得下”多少容量</b>
<p>MoE 的绝大多数专家参数对某个 Token 并未激活,但部署时权重仍要存放、调度和读取。</p>
</article>
<article>
<span>ACTIVATED PARAMETERS</span>
<b>单 Token 经过哪部分参数</b>
<p>它比 total 更接近稀疏计算量,却仍不包含 attention、router、通信、padding 和 kernel 效率。</p>
</article>
<article>
<span>STATE / BYTES</span>
<b>请求进行时不断增长的历史</b>
<p>KV/latent state 与层数、上下文、batch 和存储格式相乘,是 V2 之后独立的一等架构对象。</p>
</article>
<article>
<span>WALL CLOCK / SCORE</span>
<b>系统与协议共同产出的结果</b>
<p>GPU hours、吞吐和 benchmark 必须携带硬件、软件、预算、脚手架与比较基线。</p>
</article>
</div>
<div class="plain-language">
<b>以 V3 的 671B-A37B 为例</b>
<p>
671B 描述总容量,37B 描述每 Token 激活的参数子集;它不等于“和 37B dense 一样便宜”,
因为 attention、专家 dispatch/combine、负载长尾、并行通信与实际 kernel 都没有被这个缩写计算进去。
</p>
</div>
</section>
<section class="article-section" id="dense">
<p class="eyebrow"><span>03</span> DEEPSEEK LLM</p>
<h2>先用 Dense 模型建立基线:规模、数据和双语能力</h2>
<p>
2024 年初的 <a href="https://arxiv.org/abs/2401.02954">DeepSeek LLM</a> 发布 7B 与 67B dense 模型,
在约 2T 中英文 Token 上预训练。它的重要性不在今天看来并不夸张的参数量,而在于建立后续研究的可比基线:
tokenizer、数据配方、训练稳定性、中文评测和 scaling behavior 有了统一起点。
</p>
<h3>为什么先做 Dense 很重要</h3>
<p>
MoE 同时改变总参数、激活参数、路由、通信和数据分配。没有 dense 基线,很难判断收益来自“更多容量”
还是来自别的训练差异。DeepSeek LLM 还训练小规模模型拟合 scaling laws,
再用这些规律选择 67B 的超参数;这条“先小规模试验,再外推大模型”的方法后来在 V3/K3 都持续出现。
</p>
<div class="plain-language">
<b>把这一代当作实验坐标系</b>
<p>
DeepSeek LLM 回答的是“如果我们先不引入稀疏专家和低秩缓存,一套扎实的中英 dense Transformer 能到哪里?”
后面的论文才有明确的对照物。
</p>
</div>
</section>
<section class="article-section" id="moe">
<p class="eyebrow"><span>04</span> DEEPSEEKMOE</p>
<h2>专家越大不一定越专:把一个大专家拆成许多细粒度专家</h2>
<p>
传统 MoE 往往把 FFN 分成少数大专家,每个 Token 选 1–2 个。问题是一个大专家仍可能同时处理许多无关知识,
专家之间也会重复学习公共能力。<a href="https://arxiv.org/abs/2401.06066">DeepSeekMoE</a>
提出两项互补策略。
</p>
<div class="moe-compare">
<article>
<span>CONVENTIONAL MOE</span>
<h3>少数大专家</h3>
<div class="expert-pool large"><i>E1</i><i>E2</i><i>E3</i><i>E4</i></div>
<p>每个专家覆盖面广,公共知识在多个专家中重复;可组合的专业分工有限。</p>
</article>
<article>
<span>DEEPSEEKMOE</span>
<h3>细粒度 routed + shared</h3>
<div class="expert-pool fine"><i>S</i><i>e1</i><i>e2</i><i>e3</i><i>e4</i><i>e5</i><i>e6</i><i>e7</i></div>
<p>shared expert 吸收公共知识;更多小 routed experts 可以按 Token 组合出细分能力。</p>
</article>
</div>
<h3>Fine-Grained Expert Segmentation</h3>
<p>
在保持单 Token 激活计算近似不变时,把专家 FFN 切得更小,同时选择更多个小专家。
组合数显著增加:同样的 Token 可以同时调用“代码语法”“Python 库”“矩阵计算”等几个子专长,
不必把它们硬塞进一个笼统的“代码专家”。
</p>
<h3>Shared Expert Isolation</h3>
<p>
某些变换几乎每个 Token 都需要。如果全部交给 routed experts,多个专家会重复学习。
DeepSeekMoE 把 shared experts 始终激活,承担公共知识;路由专家获得更强动力去形成差异化专长。
这套组织直接进入 DeepSeek-V2/V3,也成为 Kimi K3 Stable LatentMoE 的结构祖先。
</p>
<div class="warning-note">
<b>MoE 的代价从 FLOPs 转移到了通信</b>
<p>
Token 必须被发送到拥有对应专家的设备。专家越细、选择越多,all-to-all、负载波动和权重读取越可能成为瓶颈。
因此模型侧路由与系统侧 Expert Parallel 从来不能分开看。
</p>
</div>
<a class="button primary" href="/moe/#deepseek">进入 MoE 专题:比较粗专家、细粒度专家与共享专家 →</a>
</section>
<section class="article-section" id="mla">
<p class="eyebrow"><span>05</span> DEEPSEEK-V2 / MLA</p>
<h2>训练只付一次参数成本,KV Cache 却在每个请求、每个 Token 上重复付费</h2>
<p>
<a href="https://arxiv.org/abs/2405.04434">DeepSeek-V2</a> 是整条谱系的关键转折:
236B 总参数、21B 激活参数、128K 上下文,把 DeepSeekMoE 用于训练经济性,
再用 Multi-head Latent Attention(MLA)直接攻击推理服务的内存瓶颈。
</p>
<div class="stat-strip">
<div><b>−42.5%</b><span>训练成本</span></div>
<div><b>−93.3%</b><span>KV Cache</span></div>
<div><b>5.76×</b><span>最大生成吞吐</span></div>
<p>均为 V2 报告相对 DeepSeek 67B 的特定配置结果,不应外推为任意硬件上的固定倍数。</p>
</div>
<h3>标准 MHA 为什么会让 KV Cache 爆长</h3>
<p>
自回归生成每一步都要查询历史 Token。历史的 K/V 不变,因此缓存起来避免重算。
但 MHA 为每层、每个 Token、每个 head 保存 K 和 V;batch、序列和层数一大,缓存会吃掉大量显存,
直接限制并发和长上下文。
</p>
<div class="mla-visual" role="img" aria-label="标准多头注意力与 MLA 缓存差异">
<div class="mha-side">
<span>MHA CACHE / EACH TOKEN</span>
<div class="heads"><i>K₁</i><i>V₁</i><i>K₂</i><i>V₂</i><i>K₃</i><i>V₃</i><i>K₄</i><i>V₄</i></div>
<p>每个 head 各存一份 K/V。</p>
</div>
<strong>→</strong>
<div class="latent-side">
<span>MLA CACHE / EACH TOKEN</span>
<div class="latent"><i>cᴷⱽ</i></div>
<p>先存低维 joint latent,计算时再上投影。</p>
</div>
</div>
<div class="formula">
cₜᴷⱽ = Wᴰᴷⱽhₜ  kₜᶜ = Wᵁᴷcₜᴷⱽ  vₜᶜ = Wᵁⱽcₜᴷⱽ
<small>
省略 decoupled RoPE key、各 head 展开与权重吸收细节。核心是 K/V 先联合低秩压缩,缓存 latent 而非完整多头表示。
</small>
</div>
<h3>为什么 MLA 比简单 MQA/GQA 更有野心</h3>
<p>
MQA 让所有 Query heads 共用一组 K/V,GQA 让一组 Query heads 共用 K/V,缓存更小但容量可能下降。
MLA 用低秩 latent 保留可恢复的内容子空间,并把 RoPE 相关部分分离,追求接近 MHA 的表达力与更小缓存。
它后来被 Kimi K2/K2.5 采用,并在 K3 中作为周期性全局注意力保留。
</p>
</section>
<section class="article-section" id="absorption">
<p class="eyebrow"><span>06</span> WEIGHT ABSORPTION × DECOUPLED ROPE</p>
<h2>MLA 真正精巧的地方:低秩只是第一步,能否不还原才决定推理价值</h2>
<p>
V2 把历史内容压到联合 latent <code>cₜᴷⱽ</code>。如果每次 attention 又把它上投影回所有 head 的完整
content K/V,缓存虽然小了,解码计算和中间张量仍会把收益吃掉。线性代数的结合律允许把固定上投影移到
query 与 output 权重一侧。
</p>
<div class="absorption-explainer">
<article>
<span>KEY CONTENT</span>
<code>qᵀ(Wᵁᴷc) = (Wᵁᴷᵀq)ᵀc</code>
<p>先变换当前 query,再直接与缓存 latent 相乘;不需要物化完整多头 content key。</p>
</article>
<article>
<span>VALUE CONTENT</span>
<code>Wᴼ(Wᵁⱽc) = (WᴼWᵁⱽ)c</code>
<p>value 上投影也可预先并入 output projection,计算对象仍停留在低维 latent。</p>
</article>
<article class="position">
<span>POSITION BREAKS IT</span>
<code>qᵀR(t−j)Wᵁᴷc</code>
<p>RoPE 的旋转依赖相对位置,不能成为一组固定吸收权重,所以 V2 把位置分支单独拆出。</p>
</article>
</div>
<div class="formula">
cache<sub>MLA</sub> / token / layer = d<sub>c</sub> + d<sub>h</sub><sup>R</sup> = 512 + 64 = 576 elements
<small>
这是 V2 配置的 content latent 与 decoupled RoPE key 之和。只写 512 会漏掉位置缓存;字节数还要乘 dtype、层数、上下文与 batch。
</small>
</div>
<div class="warning-note">
<b>MLA、MQA、GQA 不能只比一个压缩百分比</b>
<p>
MQA/GQA 通过共享 K/V 头减少状态;MLA 用联合低秩内容空间与独立位置分支减少状态。
表达能力、投影计算、kernel 支持和量化元数据都依配置而变,实验台会把“元素公式”与“报告数字”分开展示。
</p>
</div>
</section>
<section class="article-section" id="v3">
<p class="eyebrow"><span>07</span> DEEPSEEK-V3</p>
<h2>V3 的亮点不是一个技巧,而是四层协同</h2>
<p>
<a href="https://arxiv.org/abs/2412.19437">DeepSeek-V3</a> 扩到 671B 总参数、37B 激活参数,
在 14.8T Token 上预训练。报告给出的完整训练用量约 2.788M H800 GPU hours,并称整个训练没有不可恢复的 loss spike 或回滚。
这组数字之所以引人注目,是因为它背后同时改动模型、目标、数值和系统。
</p>
<div class="four-layer">
<article><span>MODEL</span><h3>MLA + DeepSeekMoE</h3><p>沿用 V2 验证过的低缓存 attention 与细粒度专家。</p></article>
<article><span>ROUTING</span><h3>Aux-loss-free balance</h3><p>用动态 expert bias 调整负载,减少辅助平衡损失对主目标的干扰。</p></article>
<article><span>OBJECTIVE</span><h3>Multi-Token Prediction</h3><p>训练时预测多个未来 Token,增加训练信号,并可转化为推测解码草稿能力。</p></article>
<article><span>SYSTEM</span><h3>FP8 + DualPipe</h3><p>低精度训练、计算通信重叠、跨节点专家并行共同压低成本。</p></article>
</div>
<h3>无辅助损失负载均衡</h3>
<p>
MoE 必须避免少数专家过载。传统做法加入 load-balancing auxiliary loss,
但它与语言建模主目标可能冲突:为了均匀而把 Token 送给次优专家。V3 为每个专家维护 bias,
根据近期负载上调冷门专家、下调热门专家;bias 只影响路由选择,不直接进入最终门控权重,
从而把“系统要均衡”和“模型要准确”更松地解耦。
</p>
<p>
<a href="/moe/#balance">专题版推导</a>会进一步区分 z-loss、辅助平衡损失、Loss-Free expert bias
与 K3 Quantile Balancing;“aux-loss-free”并不等于系统里不存在任何平衡约束。
</p>
<h3>FP8 训练真正难在哪</h3>
<p>
FP8 动态范围和有效精度有限,不能简单把所有 tensor 强转为 8 位。V3 使用细粒度量化、较高精度累加、
在线缩放和特定敏感模块的高精度保留;同时让低精度通信减少跨卡带宽。
论文最值得看的不是“首次大规模 FP8”宣传,而是哪些路径降精度、哪些路径绝不降,以及误差怎样被控制。
</p>
<h3>DualPipe:流水线的空泡是一笔真金白银</h3>
<p>
Pipeline Parallel 把层切到不同 stage;朴素调度会让设备在前向/反向依赖之间等待。
DualPipe 从流水线两端同时喂入 micro-batch,并重叠前向、反向与专家通信,尽量把空泡藏在计算后面。
它与 DeepEP 的高吞吐/低延迟 all-to-all 一起,把 MoE 理论稀疏性变成真实集群效率。
</p>
</section>
<section class="article-section" id="balance">
<p class="eyebrow"><span>08</span> ROUTING WITHOUT OBJECTIVE COLLISION</p>
<h2>让系统更均匀,但别让“均匀”改写模型真正想选的专家</h2>
<p>
路由有两种意图:模型想把 Token 交给最适合的专家,集群希望每个专家收到近似相同的负载。
传统辅助损失直接进入训练目标,均衡梯度可能与语言建模梯度争夺方向。V3 给每个 routed expert 维护动态 bias:
热门专家下调,冷门专家上调。
</p>
<div class="routing-contract">
<article>
<span>SELECTION</span>
<b>top-k(sᵢ + bᵢ)</b>
<p>动态 bias 只改变谁能进入候选集合。</p>
</article>
<i>≠</i>
<article>
<span>COMBINATION</span>
<b>Σ gᵢEᵢ(h)</b>
<p>真正组合专家输出时,gate weight 不含这个 balance bias。</p>
</article>
<i>+</i>
<article>
<span>SAFETY RAIL</span>
<b>sequence-wise aux</b>
<p>报告仍保留序列级辅助项,防止单个序列出现极端失衡。</p>
</article>
</div>
<p>
所以 “auxiliary-loss-free” 指主要全局负载策略不靠辅助损失,并不等于训练系统完全没有辅助均衡约束。
K3 的 Quantile Balancing 继续处理同一个问题,但面对近千专家使用不同的分位数反馈,属于同题新解。
</p>
</section>
<section class="article-section" id="fp8">
<p class="eyebrow"><span>09</span> FP8 ROLE CONTRACT</p>
<h2>“用 FP8 训练”不是一个开关,而是一张谁低精度、谁负责兜底的岗位表</h2>
<div class="precision-table">
<div class="head"><b>数值角色</b><b>V3 的处理</b><b>为什么不能一刀切</b></div>
<div><span>主要 GEMM 输入</span><strong>FP8 + 细粒度缩放</strong><p>吞吐和通信收益最大,但要控制不同 tile/block 的动态范围。</p></div>
<div><span>乘加累积</span><strong>更高精度路径</strong><p>大量小乘积累积会放大舍入误差,不能把输入 dtype 等同于累加 dtype。</p></div>
<div><span>master / optimizer state</span><strong>BF16 / FP32 角色</strong><p>权重更新需要保留微小变化,优化器矩对精度更敏感。</p></div>
<div><span>Norm、Softmax 等敏感算子</span><strong>高精度保留</strong><p>尺度估计和概率归一若失真,会向全层传播。</p></div>
<div><span>activation 与通信</span><strong>按路径选择</strong><p>节省保存与带宽,但要把缩放元数据和转换成本一起计入。</p></div>
</div>
<div class="plain-language">
<b>判断任何“低精度训练”声明时,至少问六个问题</b>
<p>输入是什么格式?如何缩放?在哪里累加?master weight 放哪?哪些敏感算子保留高精度?通信和缓存是否也量化?</p>
</div>
</section>
<section class="article-section" id="dualpipe">
<p class="eyebrow"><span>10</span> DUALPIPE × DEEPEP</p>
<h2>理论 FLOPs 不会自动变成训练吞吐:GPU 等待和跨节点搬运都要付墙钟时间</h2>
<p>
Pipeline Parallel 把连续层分给不同 stage。一次前向必须沿 stage 传播,反向又沿相反方向返回;
micro-batch 不够多或调度不佳时,管线两端会出现大片空泡。DualPipe 从两端注入 micro-batch,
把成对的 forward/backward chunk 排在一起,并尝试将 MoE 的 dispatch/combine 隐藏在计算之后。
</p>
<div class="schedule-diagram" role="img" aria-label="单向 pipeline 与双端教学调度对比">
<article>
<span>ONE-DIRECTION FILL</span>
<div><i class="idle">idle</i><i>F</i><i>F</i><i>F</i><i>B</i><i>B</i><i class="idle">idle</i></div>
<p>依赖传播造成 warm-up / cool-down;通信若未重叠会继续暴露。</p>
</article>
<article class="dual">
<span>DUAL-ENDED / TEACHING VIEW</span>
<div><i>F</i><i>B</i><i>F</i><i class="comm">C∥</i><i>B</i><i>F</i><i>B</i></div>
<p>两端供给和 compute–communication overlap 减少空闲,但不保证任何配置都零 bubble。</p>
</article>
</div>
<p>
DeepEP 则负责专家并行的高吞吐/低延迟 all-to-all。两者解释了一个重要边界:
DeepSeekMoE 的参数稀疏性是模型性质,真实集群效率必须由拓扑、路由分布和通信 kernel 兑现。
</p>
</section>
<section class="article-section" id="mtp">
<p class="eyebrow"><span>11</span> MULTI-TOKEN PREDICTION</p>
<h2>MTP 不是把一次采样魔法般变成多 Token,而是给每层表示更多未来监督</h2>
<p>
标准 next-token prediction 每个位置只监督下一个 Token。V3 在主模型之后串联多个 MTP module:
第 <i>k</i> 个模块结合上一模块的状态与更远未来 Token 的 embedding,预测第 <i>k+1</i> 个未来目标。
embedding 与 output head 可与主模型共享。
</p>
<div class="mtp-life">
<article><span>TRAIN</span><b>增加未来监督密度</b><p>每段文本为中间表示提供更多学习信号,并鼓励预先组织未来信息。</p></article>
<i>→</i>
<article><span>PLAIN INFERENCE</span><b>模块可以丢弃</b><p>主模型仍按标准自回归方式运行,不必为训练辅助头永久付费。</p></article>
<i>或</i>
<article><span>DRAFT INFERENCE</span><b>改作推测解码</b><p>让 MTP 给出候选未来 Token,再由主模型验证;收益依接受率与 kernel 而定。</p></article>
</div>
<div class="formula">
L = L<sub>NTP</sub> + λ · mean<sub>k</sub>(L<sub>MTP</sub><sup>k</sup>)
<small>V3 的目标是顺序多未来监督;它与一次并行确定输出多个 Token、blockwise decoding 或独立 draft model 都不完全相同。</small>
</div>
</section>
<section class="article-section" id="grpo">
<p class="eyebrow"><span>12</span> DEEPSEEKMATH / GRPO</p>
<h2>GRPO:不用再养一个和策略模型同样昂贵的 Critic</h2>
<p>
<a href="https://arxiv.org/abs/2402.03300">DeepSeekMath</a> 不只是数学模型论文。
它在 7B 模型和 120B 数学相关 Token 上验证数据工程,同时提出 Group Relative Policy Optimization,
为后来 DeepSeek-V2 对齐和 R1 大规模推理 RL 铺路。
</p>
<h3>PPO 的显存账单</h3>
<p>
经典 RLHF/PPO 常同时保留 policy、reference、reward model 和 value/critic model。
对大模型而言,critic 往往与 policy 同量级。GRPO 对同一道题采样一组答案,
用组内奖励的均值和标准差构造相对优势,省去单独 value model。
</p>
<div class="grpo-visual">
<div class="prompt"><span>PROMPT</span><b>证明 / 求解一道题</b></div>
<i>sample group</i>
<div class="answers">
<div><b>y₁</b><span>reward 0</span></div>
<div><b>y₂</b><span>reward 1</span></div>
<div><b>y₃</b><span>reward 0.7</span></div>
<div><b>y₄</b><span>reward 0.2</span></div>
</div>
<i>normalize</i>
<div class="advantage"><span>RELATIVE ADVANTAGE</span><b>高于组均值的轨迹被鼓励</b></div>
</div>
<div class="formula">
Âᵢ = (rᵢ − mean(r₁…rᴳ)) / (std(r₁…rᴳ) + ε)
<small>GRPO 完整目标仍包含 clipped policy ratio 与 KL 约束;这里只展示“组相对优势”这一核心直觉。</small>
</div>
<h3>组相对不是免费午餐</h3>
<p>
一道题要采样多条答案,rollout 成本仍然很高;奖励若不可验证或存在偏差,组内比较也会放大奖励漏洞。
当一组奖励全相同,归一优势几乎不给学习信号。R1 的成功因此同时依赖可验证数学/代码奖励、足够多样的采样和大规模基础设施。
</p>
</section>
<section class="article-section" id="r1zero">
<p class="eyebrow"><span>13</span> R1-ZERO / ISOLATION EXPERIMENT</p>
<h2>它隔离掉的是 reasoning SFT,不是预训练知识、提示先验和验证器</h2>
<p class="lede">
R1-Zero 从 DeepSeek-V3 Base 开始,直接用 GRPO 与规则奖励训练,没有先用人工或教师 CoT 做 reasoning SFT。
这让研究者能单独观察:强 base model 中已有的求解分布,能否被结果奖励重新排序和继续塑造。
</p>
<div class="zero-contract">
<article class="removed"><span>刻意移除</span><b>reasoning SFT</b><p>不先规定“优秀推理轨迹应该长什么样”。</p></article>
<article><span>依然存在</span><b>V3 Base</b><p>大规模预训练已经提供数学、代码、语言和潜在反思模式。</p></article>
<article><span>依然存在</span><b>rule verifier</b><p>准确性与格式奖励定义了什么会被强化。</p></article>
<article><span>依然存在</span><b>rollout + GRPO</b><p>同题多样采样、相对优势、clip 与 KL 仍构成优化系统。</p></article>
</div>
<p>
训练中出现更长轨迹、反思、回溯与自我验证,论文把部分轨迹描述为 “aha moment”。
但公开的 Dr.GRPO 研究观察到 V3 Base 本身也能生成 “wait”等反思词,因此词面现象不能作为“RL 从零发明推理”的因果证据。
</p>
<div class="warning-note">
<b>R1-Zero 证明的是可塑性,不是无中生有</b>
<p>
更严谨的结论是:在强 base、可验证任务和大规模 rollout 条件下,无 reasoning SFT 的规则奖励 RL
能显著改变求解策略与测试时计算。开放任务、不可验证质量和 base 能力边界仍然没有被这个实验消除。
</p>
</div>
</section>
<section class="article-section" id="r1">
<p class="eyebrow"><span>14</span> DEEPSEEK-R1 / USABLE PIPELINE</p>
<h2>正式 R1 的贡献,是承认隔离实验不等于可直接使用的助手</h2>
<p class="lede">
<a href="https://arxiv.org/abs/2501.12948">DeepSeek-R1</a> 的历史意义,
不只在 R1-Zero 的能力增长,也在把可读性、广度、帮助性和安全重新接回训练流程。
</p>
<h3>R1-Zero 暴露的问题决定了后面的每个阶段</h3>
<p>
R1-Zero 会重复、可读性差、混合语言。奖励只关心最终正确时,模型没有充分动力照顾人类阅读体验。
正式 R1 因而先加入少量高质量 cold-start CoT 数据,再做 reasoning-oriented RL;
随后用 rejection sampling 产生 SFT 数据,混入写作、事实问答等非推理任务,再进行第二阶段 RL 兼顾帮助性与安全。
</p>
<div class="r1-pipeline">
<div><span>BASE</span><b>DeepSeek-V3 Base</b><small>强预训练基础</small></div>
<i>→</i>
<div><span>COLD START</span><b>少量可读 CoT</b><small>稳定格式与语言</small></div>
<i>→</i>
<div class="hot"><span>REASONING RL</span><b>可验证奖励 + GRPO</b><small>强化求解策略</small></div>
<i>→</i>
<div><span>SFT MIX</span><b>拒绝采样 + 通用数据</b><small>恢复广泛任务</small></div>
<i>→</i>
<div><span>FINAL RL</span><b>帮助性与安全</b><small>统一模型</small></div>
</div>
<h3>Distillation 的关键发现</h3>
<p>
团队用 R1 生成并筛选的约 800K 样本微调 Qwen/Llama dense 模型,发布 1.5B–70B 蒸馏版本。
这说明小模型不一定要自己承担完整的探索式 RL 成本,可以模仿强 reasoning teacher 的轨迹;
但蒸馏得到的是 teacher 数据分布上的能力,不等于小模型内部复现了同样的 RL 发现过程。
</p>
<div class="warning-note">
<b>CoT 变长不等于推理一定更好</b>
<p>
长轨迹可能包含有效搜索,也可能是重复与绕路。R1 证明的是在可验证任务和适当训练下,
增加推理计算可以转化为能力;不是“输出越长越聪明”。
</p>
</div>
<a class="button primary" href="/reasoning/#deepseek">进入推理专题:从 DeepSeekMath、R1 到 DAPO / Dr.GRPO 的完整推导 →</a>
</section>
<section class="article-section" id="dapo">
<p class="eyebrow"><span>15</span> PUBLIC FOLLOW-UP / DAPO × DR.GRPO</p>
<h2>复现不是脚注:它把“R1-like 训练有效”拆成了四种优化偏差</h2>
<p>
<a href="https://arxiv.org/abs/2503.14476">DAPO</a> 与
<a href="https://arxiv.org/abs/2503.20783">Understanding R1-Zero-Like Training</a>
都是 R1 之后的公开研究,不是 DeepSeek 已披露的内部 R1 recipe。它们的价值是让研究者看到:
一条奖励曲线上升,可能同时包含能力改善、采样过滤、长度倾向和损失聚合偏差。
</p>
<div class="followup-grid">
<article>
<span>DAPO / CLIP-HIGHER</span><h3>正向更新别太早被截断</h3>
<p>提高正优势样本的上界,为少见但正确的长推理保留更大上升空间。</p>
</article>
<article>
<span>DAPO / DYNAMIC SAMPLING</span><h3>全对与全错组不给相对信号</h3>
<p>过滤组内奖励方差为零的 prompt,避免花 rollout 成本却得到近零归一优势。</p>
</article>
<article>
<span>DAPO / TOKEN-LEVEL LOSS</span><h3>先按 Token 聚合再更新</h3>
<p>改变不同长度响应对 batch 梯度的权重,避免 response-level aggregation 的隐含偏置。</p>
</article>
<article>
<span>DAPO / OVERLONG SHAPING</span><h3>截断不该制造奖励悬崖</h3>
<p>对接近长度上限的轨迹做平滑惩罚,降低突然截断带来的噪声。</p>
</article>
<article class="wide">
<span>DR.GRPO / TWO BIASES</span><h3>响应长度偏差 + 题目难度偏差</h3>
<p>
response-level 长度归一会改变长短答案的 Token 权重;用每题组内标准差归一,又会让不同奖励方差的题目获得不同尺度。
Dr.GRPO 去掉这些归一项,追问“我们究竟在优化正确率,还是在无意中优化长度与题型权重?”
</p>
</article>
</div>
<div class="plain-language">
<b>这些修正没有给出唯一正确的 RL 算法</b>
<p>
它们给出的是审计工具:观察采样组是否有方差、clip 是否非对称、长响应怎样进入损失、截断怎样进入奖励、
不同难度题是否被标准差重新加权。页面实验台会让这些偏差在一个小样本里显形。
</p>
</div>
</section>
<section class="article-section" id="v32">
<p class="eyebrow"><span>16</span> DEEPSEEK-V3.2 / DSA</p>
<h2>从会推理到会在长上下文里使用工具</h2>
<p>
<a href="https://arxiv.org/abs/2512.02556">DeepSeek-V3.2</a> 把三条线合并:
DeepSeek Sparse Attention(DSA)降低长上下文成本,更大规模的 RL 提升 reasoning,
Agentic task synthesis 则把 reasoning 放进工具交互轨迹。
</p>
<h3>DSA 的两阶段直觉</h3>
<p>
完整注意力让每个 Query 和全部历史交互。DSA 先用轻量、可学习的 indexer 给历史 Token 评分,
选出小部分候选,再让主 attention 只在候选上做高容量计算。
关键不只是 top-k,而是 indexer 也在训练中学习“什么值得看”;这比固定窗口更能适应内容相关的远距离依赖。
</p>
<div class="sparse-visual">
<div class="history">
{Array.from({ length: 18 }, (_, index) => <i class:list={{ picked: [1, 5, 6, 12, 16].includes(index) }}>{index + 1}</i>)}
</div>
<span>learned indexer → top-k</span>
<div class="picked"><i>2</i><i>6</i><i>7</i><i>13</i><i>17</i></div>
<span>main attention</span>
<b>Query</b>
</div>
<p>
Agent 方面,V3.2 的任务合成管线系统地产生复杂、交互式工具任务,让思考与 tool use 交织。
这与 K3 的 white-box harness、知识图谱任务合成和可验证环境形成同期对照:前沿模型竞争正在从静态题库转向训练环境。
<a href="/agents/#deepseek-v32">进入 Agent 专题查看 V3.2 的 search/code/general-agent 合成管线 →</a>
</p>
</section>
<section class="article-section" id="agent-data">
<p class="eyebrow"><span>17</span> V3.2 / AGENTIC DATA LOOP</p>
<h2>从“回答一道题”到“在环境里留下可验证的状态变化”</h2>
<p>
V3.2 的 Agent 能力不是在聊天模板上多放几个 tool token。报告把 specialist distillation 与 mixed RL 结合,
分别训练 search、code 和 general-agent 能力,再把它们蒸馏回统一模型。general-agent 部分报告了
1,827 个合成环境;这个数字只代表该报告口径,不是所有 Agent 数据的总量。
</p>
<div class="agent-loop">
<article><span>ENVIRONMENT</span><b>有状态世界</b><p>文件、网页、API 或模拟器会因动作而改变。</p></article>
<i>→</i>
<article><span>TOOLS</span><b>受约束动作</b><p>schema、权限、错误和延迟共同限定策略空间。</p></article>
<i>→</i>
<article><span>TASK + SOLUTION</span><b>可执行轨迹</b><p>不只要语言通顺,还要工具调用能够推进状态。</p></article>
<i>→</i>
<article><span>VERIFIER</span><b>检查最终世界</b><p>最终答案、测试、文件或环境状态构成奖励证据。</p></article>
</div>
<p>
这条线与 K3 的 white-box harness、知识图谱任务合成和百万 Token Agentic RL 同期呼应;
两份报告都把竞争焦点从静态 benchmark 推向“环境能否生成、执行、验证和归因”。
<a href="/agents/#deepseek-v32">Agent 专题给出了完整环境合同与失败树 →</a>
</p>
</section>
<section class="article-section" id="v4">
<p class="eyebrow"><span>18</span> DEEPSEEK-V4</p>
<h2>百万上下文从“支持”变成一套专门架构</h2>
<p>
2026 年的 <a href="https://arxiv.org/abs/2606.19348">DeepSeek-V4 preview</a> 包含
1.6T-A49B 的 Pro 与 284B-A13B 的 Flash,均支持 1M Token。
它使用 Compressed Sparse Attention(CSA)与 Heavily Compressed Attention(HCA)的混合注意力,
Manifold-Constrained Hyper-Connections(mHC)改善深度残差,并采用 Muon 优化器。
</p>
<div class="stat-strip v4">
<div><b>1.6T / 49B</b><span>V4-Pro total / active</span></div>
<div><b>284B / 13B</b><span>V4-Flash total / active</span></div>
<div><b>&gt;32T</b><span>预训练 Token</span></div>
<p>V4 官方报告摘要数据;模型是 preview 版本,后续版本需按研究截止日重新核验。</p>
</div>
<p>
报告称在 1M 上下文下,V4-Pro 的单 Token 推理 FLOPs 是 V3.2 的 27%,KV Cache 是 10%。
这说明长上下文竞争已从单一位置外推转向混合注意力、压缩缓存、残差、优化器和后训练的系统协同。
它也解释 K3 报告为何把 V4 列为同代开放基础模型对照。
</p>
<p>
<a href="/long-context/#hybrids">进入长上下文专题</a>,可以把 V4 的 CSA/HCA 与 K3 的
KDA/NoPE MLA 放进同一张“计算—缓存—状态容量”账本逐项比较。
</p>
<div class="warning-note">
<b>V4 与 K3 不是同一条注意力路线</b>
<p>
V4 用 CSA/HCA 混合压缩与稀疏注意力;K3 用 3:1 KDA/Gated MLA 混合线性递归与全局注意力。
两者目标相近——降低百万上下文成本并保留能力——但状态表示、检索方式和系统内核不同。
</p>
</div>
</section>
<section class="article-section" id="v4-state">
<p class="eyebrow"><span>19</span> V4 / HETEROGENEOUS STATE MACHINE</p>
<h2>CSA 与 HCA 不是两个稀疏率档位,而是两种不同的历史表示</h2>
<div class="state-machines">
<article>
<header><span>CSA</span><b>Compressed Sparse Attention</b></header>
<div class="state-flow"><i>原序列</i><u>压缩</u><i>compressed KV</i><u>index</u><i>top-k</i><u>attend</u><i>输出</i></div>
<p>先以较温和压缩率形成历史条目,再用 DSA 风格 indexer 选 top-k,让主 attention 只访问相关子集。</p>
</article>
<article>
<header><span>HCA</span><b>Heavily Compressed Attention</b></header>
<div class="state-flow"><i>原序列</i><u>强压缩</u><i>少量全局条目</i><u>all</u><i>全部读取</i></div>
<p>使用更激进的压缩率,把所有 compressed entries 保留下来,不再走与 CSA 相同的 top-k 稀疏路径。</p>
</article>
</div>
<h3>为什么长上下文还需要一整套稳定性与优化器设计</h3>
<div class="v4-contract">
<article><span>ATTENTION SCALE</span><b>headwise Q/K RMSNorm</b><p>按 head 控制 query 与 compressed KV 的尺度。</p></article>
<article><span>POSITION</span><b>partial RoPE · last 64 dims</b><p>只在部分维度编码旋转位置,保留内容与位置的职责分离。</p></article>
<article><span>RESIDUAL</span><b>mHC · expansion 4</b><p>把 residual mixing 映射到双随机 Birkhoff polytope,约束深层信息混合。</p></article>
<article><span>OPTIMIZER</span><b>Muon + AdamW roles</b><p>多数二维参数用 Muon;embedding、head、RMSNorm 等角色仍由 AdamW 处理。</p></article>
<article><span>FFN EXTREMES</span><b>SwiGLU clamp</b><p>线性分支截到 [−10, 10]、gate 设上限 10,限制极端激活。</p></article>
<article><span>KV SHARING</span><b>shared-KV MQA</b><p>再配 grouped output,把内容压缩与 head 组织一起设计。</p></article>
</div>
<div class="precision-table compact">
<div class="head"><b>V4 变体</b><b>骨架</b><b>稀疏 / 压缩合同</b></div>
<div><span>V4-Pro</span><strong>61 layers · width 7168 · 1.6T-A49B</strong><p>top-6 routed experts;HCA rate 128、CSA rate 4、CSA top-k 1024。</p></div>
<div><span>V4-Flash</span><strong>43 layers · width 4096 · 284B-A13B</strong><p>top-6 routed experts;同样混合 HCA/CSA,CSA top-k 512。</p></div>
</div>
<div class="warning-note">
<b>27% FLOPs 与 10% KV Cache 是报告内比较,不是通用常数</b>
<p>
V4 报告把 Pro 在 1M context 下与 V3.2 比较。真实服务还受 batch、序列分布、量化、page allocator、
kernel、并行策略和硬件影响;这里保留“作者报告”标签,不把比例外推到任意部署。
</p>
</div>
</section>
<section class="article-section" id="k3">
<p class="eyebrow"><span>20</span> INTO KIMI K3</p>
<h2>DeepSeek 的哪些思想直接流入 K3,哪些只是同期呼应</h2>
<div class="mapping-table">
<div class="head"><b>DeepSeek 线索</b><b>K3 中的落点</b><b>关系</b></div>
<div><span>DeepSeekMoE shared + routed experts</span><span>Stable LatentMoE 保留 shared/routed 组织</span><em>直接结构祖先</em></div>
<div><span>V2 Multi-head Latent Attention</span><span>每四层一次 Gated MLA,全局注意力</span><em>明确采用并改造</em></div>
<div><span>V3 Auxiliary-loss-free balancing</span><span>Quantile Balancing 应对近千专家</span><em>同一问题的新方案</em></div>
<div><span>V3 FP8 / 低精度协同</span><span>专家 MXFP4 权重、MXFP8 激活与 QAT</span><em>更低精度的延伸</em></div>
<div><span>DeepSeekMath / R1 的 GRPO 与 RL</span><span>多 domain、多 effort RL + MOPD</span><em>共享测试时扩展范式</em></div>
<div><span>V4 的 Muon 参数分工</span><span>Per-Head Muon 按 attention head 组织更新</span><em>同优化器族的新粒度</em></div>
<div><span>V4 mHC:扩宽并约束 residual stream</span><span>AttnRes:93 层按 12 层 block 路由到 9 个深度来源</span><em>同期不同设计</em></div>
<div><span>V3.2 DSA / V4 CSA-HCA</span><span>3 层 KDA + 1 层 NoPE Gated MLA 周期</span><em>同目标、不同状态机器</em></div>
<div><span>R1 / V4 的离线教师与 RL 配方</span><span>MOPD 让多教师给 on-policy Token 分布</span><em>同题新解</em></div>
</div>
<p>
这正是为什么 DeepSeek 值得在 LLM Atlas 中作为贯穿案例:它不是 K3 的“对手名单”之一,
而是 K3 架构里多条思想的公开祖先与同代参照。读懂 V2 的 MLA 和 DeepSeekMoE,
K3 的一半架构会突然变得熟悉。
</p>
<div class="warning-note">
<b>不要把 K3 报告里的两个 “block size” 混在一起</b>
<p>
主模型 AttnRes 以 12 层为一个深度 block;报告中 block size 2 出现在芯片设计 nano-model 的
MiniTriton proof-of-concept,不是 93 层主模型结构。这类同词异义正是继承图必须保留上下文的原因。
</p>
</div>
</section>
<section class="article-section" id="lab">
<p class="eyebrow"><span>21</span> FOUR INTERACTIVE LEDGERS</p>
<h2>把四个最容易被口号遮住的对象,重新变成可以动手改的变量</h2>
<p class="lede">
稀疏容量实验区分总容量、激活计算与通信;MLA 实验给出精确缓存元素并把 RoPE key 算进去;
V3 协同实验拆开 FP8、pipeline 与 MTP;RL 偏差镜则让零方差、长度偏差和难度归一在同一组样本里显形。
</p>
<DeepSeekLab />
</section>
<section class="article-section" id="artifact">
<p class="eyebrow"><span>22</span> OFFICIAL WEIGHTS / EXECUTED</p>
<h2>从“MLA 与 MoE 的概念”再往前一步:让官方 V2-Lite 权重真的跑起来</h2>
<p class="lede">
前面的四联实验负责建立公式与角色合同;下面的六联工件实验固定官方 revision、tokenizer、
模型代码和 checkpoint 第一分片,在 RTX 5090 上连续执行 layer 0–6。它把真实观测、shape 推导、
吸收式 latent cache、128 条公开语料的路由区间、实现差距和未覆盖范围放在同一张证据图里。
</p>
<div class="artifact-callout">
<article><span>X / FORWARD</span><b>7 / 27 layers</b><p>1 个 dense 层 + 6 个 MoE 层;layer 7 因跨分片停止。</p></article>
<article><span>X / ROUTES</span><b>304,560</b><p>128 条公开 prompt、8,460 token、6 个 MoE 层的真实 top-6 选择。</p></article>
<article><span>X / ABSORB CACHE</span><b>266,240 → 29,952 B</b><p>同一真实 layer-1 权重的 naive / absorb active buffers。</p></article>
<article><span>X / RERUN</span><b>BYTE-EXACT</b><p>固定选样、逐 prompt loads 与 2,000 次 bootstrap 摘要完整复跑。</p></article>
</div>
<DeepSeekArtifactLab />
</section>
<section class="article-section" id="branches">
<p class="eyebrow"><span>23</span> THE MAIN LINE IS NOT THE WHOLE TREE</p>
<h2>如果只读 V2 → V3 → R1 → V4,会漏掉五条反过来影响主线的旁支</h2>
<div class="branch-grid">
{deepseekBranches.map(([name, line, text, url]) => (
<a href={url} rel="noreferrer">
<span>{name}</span>
<h3>{line}</h3>
<p>{text}</p>
<b>打开一手来源 →</b>
</a>
))}
</div>
<p>
旁支不是“其它产品”清单:Coder-V2 检验 V2 架构如何继续预训练,ESFT 检验 expert specialization
如何进入微调,Prover 把可验证奖励推进 formal proof,DeepEP/DualPipe 把模型假设变成系统实现,
Engram 则提出不同于专家和注意力的条件记忆稀疏轴。
</p>
</section>
<section class="article-section" id="audit">
<p class="eyebrow"><span>24</span> EVIDENCE AUDIT</p>
<h2>同一张页面里有三种知识,它们的语气必须不同</h2>
<div class="audit-grid">
<article class="reported">
<span>AUTHOR-REPORTED</span><h3>作者报告或官方仓库明确写出的事实</h3>
<p>模型配置、训练阶段、V2 的 93.3%、V3 的 2.788M H800 hours、V3.2 的 1,827 environments、V4 的 27%/10% 都属于这一层,必须携带比较对象。</p>
</article>
<article class="derived">
<span>FORMULA-DERIVED</span><h3>从公开配置按公式重新计算</h3>
<p>例如 MHA 的 2nₕdₕ 与 V2 MLA 的 d꜀+dᴿ 元素数。公式可以精确,换成 GiB 时仍依赖 dtype、batch、allocator 与实现。</p>
</article>
<article class="toy">
<span>TEACHING MODEL</span><h3>为了看趋势而构造的交互近似</h3>
<p>通信压力、pipeline bubble 和 RL 权重是方向性玩具模型;它们不冒充 H800 集群、真实 checkpoint 或论文复跑。</p>
</article>
</div>
<div class="audit-rules">
<p><b>不写:</b>R1-Zero 没有任何监督或先验;RL 从零发明了 “aha”。</p>
<p><b>不写:</b>DAPO / Dr.GRPO 是 DeepSeek 官方 R1 recipe。</p>
<p><b>不写:</b>aux-loss-free 就是完全没有辅助均衡;FP8 就是全模型都用 8 位。</p>
<p><b>不写:</b>V4 和 K3 都是 1M,所以架构相同;蒸馏学生就是小号 R1-Zero。</p>
</div>
</section>
<section class="article-section" id="papers">
<p class="eyebrow"><span>↳</span> READING ORDER</p>
<h2>六十个一手 / 官方节点:从祖先、对照、主线、复现到 K3 汇流点</h2>
<p>
不建议直接从 R1 开始。先读 MoE、MQA/GQA、RoPE、PPO 和 pipeline 的祖先,再进入 DeepSeek 主线;
DAPO / Dr.GRPO 放在 R1 后作为反查,Kimi K2/K3 放在末端做同题对照。
</p>
<div class="paper-chain expanded" data-deepseek-paper-chain>
{deepseekPaperChain.map(([number, year, title, url, role]) => (
<a class="paper-row" href={url} rel="noreferrer">
<time>{number}</time><b>{title}</b><p><span>{year}</span>{role}</p>
</a>
))}
</div>
<div class="hero-actions">
<a class="button primary" href="/long-context/">精读 MLA、DSA、CSA/HCA 与 KDA →</a>
<a class="button" href="/k3/">回到 K3</a>
<a class="button" href="/roadmap/">完整课程地图</a>
</div>
</section>
</article>
</div>
<style>
.deepseek-hero::before {
background:
radial-gradient(circle at 43% 47%, rgba(107, 98, 145, 0.16), transparent 31%),
radial-gradient(circle at 65% 38%, rgba(84, 124, 116, 0.13), transparent 24%);
}
.artifact-callout {
display: grid;
grid-template-columns: repeat(4, minmax(0, 1fr));
max-width: 980px;
margin: 30px 0;
border-top: 1px solid var(--line);
border-left: 1px solid var(--line);
}
.artifact-callout article {
min-height: 155px;
padding: 20px;
border-right: 1px solid var(--line);
border-bottom: 1px solid var(--line);
background: var(--paper-raised);
}
.artifact-callout span {
display: block;
color: var(--copper);
font: 700 0.58rem/1 var(--mono);
letter-spacing: 0.08em;
}
.artifact-callout b {
display: block;
margin-top: 18px;
font-size: 1.14rem;
}
.artifact-callout p {
margin: 11px 0 0;
color: var(--muted);
font-size: 0.68rem;
line-height: 1.55;
}
.moe-compare,
.four-layer {
display: grid;
grid-template-columns: repeat(2, minmax(0, 1fr));
max-width: 920px;
margin: 34px 0;
border-top: 1px solid var(--line);
border-left: 1px solid var(--line);
}
.moe-compare article,
.four-layer article {
min-height: 260px;
padding: 26px;
border-right: 1px solid var(--line);
border-bottom: 1px solid var(--line);
}
.moe-compare article > span,
.four-layer span {
color: var(--copper);
font: 0.62rem/1 var(--mono);
letter-spacing: 0.09em;
}
.moe-compare h3,
.four-layer h3 {
margin: 24px 0 14px;
font-size: 1.15rem;
}
.moe-compare p,
.four-layer p {
color: var(--muted);
font-size: 0.78rem;
line-height: 1.72;
}
.expert-pool {
display: flex;
flex-wrap: wrap;
gap: 7px;
margin: 22px 0;
}
.expert-pool i {
display: grid;
place-items: center;
width: 46px;
height: 46px;
border: 1px solid var(--line-strong);
border-radius: 6px;
color: var(--muted);
font: 0.68rem/1 var(--mono);
font-style: normal;
}
.expert-pool.large i {
width: 66px;
height: 66px;
background: var(--sky-pale);
}
.expert-pool.fine i {
background: var(--copper-pale);
}
.expert-pool.fine i:first-child {
border-color: var(--sage);
background: var(--sage-pale);
color: var(--sage);
}
.stat-strip {
display: grid;
grid-template-columns: repeat(3, minmax(0, 1fr));
max-width: 860px;
margin: 34px 0;
border-top: 1px solid var(--line);
border-left: 1px solid var(--line);
}
.stat-strip > div {
min-height: 130px;
padding: 25px;
border-right: 1px solid var(--line);
border-bottom: 1px solid var(--line);
background: var(--paper-raised);
}
.stat-strip b,
.stat-strip span {
display: block;
}
.stat-strip b {
color: var(--copper);
font: 700 1.4rem/1 var(--mono);
}
.stat-strip span {
margin-top: 16px;
color: var(--muted);
font-size: 0.74rem;
}
.stat-strip > p {
grid-column: 1 / -1;
padding: 12px 18px;
border-right: 1px solid var(--line);
border-bottom: 1px solid var(--line);
color: var(--muted);
font-size: 0.68rem;
}
.mla-visual {
display: grid;
grid-template-columns: 1fr 50px 1fr;
gap: 18px;
align-items: center;
max-width: 820px;
margin: 34px 0;
}
.mla-visual > div {
min-height: 210px;
padding: 26px;
border: 1px solid var(--line);
background: var(--paper-raised);
}
.mla-visual > strong {
color: var(--muted-light);
text-align: center;
}
.mla-visual span,
.grpo-visual span,
.r1-pipeline span {
color: var(--muted);
font: 0.62rem/1 var(--mono);
}
.heads {
display: grid;
grid-template-columns: repeat(4, 1fr);
gap: 6px;
margin: 27px 0;
}
.heads i,
.latent i {
display: grid;
place-items: center;
height: 46px;
border: 1px solid var(--sky);
background: var(--sky-pale);
color: var(--sky);
font: 0.67rem/1 var(--mono);
font-style: normal;
}
.latent {
margin: 27px 0;
}
.latent i {
width: 74px;
border-color: var(--copper);
background: var(--copper-pale);
color: var(--copper);
}
.mla-visual p {
color: var(--muted);
font-size: 0.75rem;
}
.four-layer {
grid-template-columns: repeat(4, minmax(0, 1fr));
}
.four-layer article {
min-height: 230px;
padding: 22px;
}
.grpo-visual {
display: grid;
grid-template-columns: 160px 70px 1fr 70px 220px;
gap: 10px;
align-items: center;
max-width: 920px;
margin: 34px 0;
}
.grpo-visual > div:not(.answers) {
min-height: 125px;
padding: 18px;
border: 1px solid var(--line);
background: var(--paper-raised);
}
.grpo-visual > i {
color: var(--muted);
font: 0.6rem/1.4 var(--mono);
font-style: normal;
text-align: center;
}
.grpo-visual b {
display: block;
margin-top: 23px;
font-size: 0.82rem;
}
.answers {
display: grid;
grid-template-columns: repeat(4, 1fr);
gap: 7px;
}
.answers div {
min-height: 110px;
padding: 14px;
border: 1px solid var(--line);
background: var(--paper-raised);
}
.answers span {
display: block;
margin-top: 24px;
color: var(--muted);
font-size: 0.58rem;
}
.r1-pipeline {
display: grid;
grid-template-columns: repeat(4, minmax(110px, 1fr) 22px) minmax(110px, 1fr);
gap: 8px;
align-items: center;
max-width: 940px;
margin: 34px 0;
}
.r1-pipeline > div {
min-height: 130px;
padding: 17px;
border: 1px solid var(--line);
background: var(--paper-raised);
}
.r1-pipeline > div.hot {
border-color: var(--copper);
background: var(--copper-pale);
}
.r1-pipeline > i {
color: var(--muted-light);
font-style: normal;
}
.r1-pipeline b,
.r1-pipeline small {
display: block;
}
.r1-pipeline b {
margin-top: 20px;
font-size: 0.78rem;
}
.r1-pipeline small {
margin-top: 8px;
color: var(--muted);
font-size: 0.62rem;
}
.sparse-visual {
display: grid;
grid-template-columns: 1fr 120px auto 100px 60px;
gap: 15px;
align-items: center;
max-width: 910px;
margin: 34px 0;
padding: 28px;
border: 1px solid var(--line);
background: var(--paper-raised);
}
.history,
.picked {
display: flex;
flex-wrap: wrap;
gap: 5px;
}
.history i,
.picked i,
.sparse-visual > b {
display: grid;
place-items: center;
width: 28px;
height: 28px;
border: 1px solid var(--line);
color: var(--muted-light);
font: 0.58rem/1 var(--mono);
font-style: normal;
}
.history i.picked,
.picked i {
border-color: var(--copper);
background: var(--copper-pale);
color: var(--copper);
}
.sparse-visual > span {
color: var(--muted);
font: 0.58rem/1.4 var(--mono);
text-align: center;
}
.sparse-visual > b {
width: 56px;
height: 56px;
border-color: var(--sky);
border-radius: 50%;
background: var(--sky-pale);
color: var(--sky);
}
.mapping-table {
display: grid;
max-width: 940px;
margin: 34px 0;
border-top: 1px solid var(--line);
border-left: 1px solid var(--line);
}
.mapping-table > div {
display: grid;
grid-template-columns: 1fr 1.2fr 0.7fr;
}
.mapping-table > div > * {
padding: 15px 17px;
border-right: 1px solid var(--line);
border-bottom: 1px solid var(--line);
font-size: 0.75rem;
line-height: 1.6;
}
.mapping-table .head {
background: var(--ink);
color: var(--paper-raised);
}
.mapping-table .head b {
font: 0.62rem/1.5 var(--mono);
letter-spacing: 0.08em;
}
.mapping-table em {
color: var(--copper);
font-style: normal;
}
.ledger-grid {
display: grid;
grid-template-columns: repeat(3, minmax(0, 1fr));
max-width: 980px;
margin: 34px 0;
border-top: 1px solid var(--line);
border-left: 1px solid var(--line);
}
.ledger-card {
min-height: 235px;
padding: 21px;
border-right: 1px solid var(--line);
border-bottom: 1px solid var(--line);
background: var(--paper-raised);
}
.ledger-card header,
.wave-grid header,
.state-machines header {
display: flex;
align-items: center;
justify-content: space-between;
gap: 12px;
}
.ledger-card header span,
.wave-grid header span,
.wave-grid time,
.number-grammar span,
.absorption-explainer span,
.routing-contract span,
.precision-table .head,
.schedule-diagram span,
.mtp-life span,
.zero-contract span,
.followup-grid span,
.agent-loop span,
.state-machines header span,
.v4-contract span,
.branch-grid > a > span,
.audit-grid > article > span {
color: var(--copper);
font: .54rem/1.4 var(--mono);
letter-spacing: .07em;
}
.ledger-card header b {
color: var(--muted);
font: 600 .57rem/1.4 var(--mono);
}
.ledger-card h3 {
min-height: 66px;
margin: 25px 0 13px;
font-size: .88rem;
line-height: 1.45;
}
.ledger-card p,
.wave-grid p,
.number-grammar p,
.absorption-explainer p,
.routing-contract p,
.precision-table p,
.schedule-diagram p,
.mtp-life p,
.zero-contract p,
.followup-grid p,
.agent-loop p,
.state-machines p,
.v4-contract p,
.branch-grid p,
.audit-grid p {
color: var(--muted);
font-size: .67rem;
line-height: 1.7;
}
.reading-rule {
max-width: 980px;
margin: 24px 0 38px;
padding: 25px;
background: var(--ink);
color: white;
}
.reading-rule > span {
color: #d8a183;
font: .55rem var(--mono);
}
.reading-rule p {
display: flex;
flex-wrap: wrap;
align-items: center;
gap: 12px;
margin-top: 17px;
}
.reading-rule b { color: white; font: 650 .72rem var(--sans); }
.reading-rule i { color: #d8a183; font-style: normal; }
.wave-grid {
display: grid;
grid-template-columns: repeat(2, minmax(0, 1fr));
max-width: 960px;
margin: 35px 0;
gap: 1px;
border: 1px solid var(--line);
background: var(--line);
}
.wave-grid article {
min-height: 185px;
padding: 22px;
background: var(--paper-raised);
}
.wave-grid time { color: var(--muted); }
.wave-grid h3 { margin: 24px 0 10px; font-size: 1rem; }
.number-grammar,
.precision-table,
.v4-contract {
display: grid;
grid-template-columns: repeat(4, minmax(0, 1fr));
max-width: 960px;
margin: 34px 0;
border-top: 1px solid var(--line);
border-left: 1px solid var(--line);
}
.number-grammar article,
.v4-contract article {
min-height: 220px;
padding: 22px;
border-right: 1px solid var(--line);
border-bottom: 1px solid var(--line);
background: var(--paper-raised);
}
.number-grammar b,
.v4-contract b {
display: block;
min-height: 54px;
margin: 25px 0 12px;
font-size: .8rem;
}
.absorption-explainer {
display: grid;
grid-template-columns: repeat(3, minmax(0, 1fr));
max-width: 940px;
margin: 34px 0;
border: 1px solid var(--line);
}
.absorption-explainer article {
min-height: 235px;
padding: 24px;
border-right: 1px solid var(--line);
background: var(--paper-raised);
}
.absorption-explainer article:last-child { border-right: 0; }
.absorption-explainer article.position { background: var(--copper-pale); }
.absorption-explainer code {
display: block;
margin: 28px 0 20px;
color: var(--ink);
font: 650 .76rem/1.6 var(--mono);
white-space: normal;
}
.routing-contract {
display: grid;
grid-template-columns: 1fr 40px 1fr 40px 1fr;
align-items: center;
max-width: 940px;
margin: 34px 0;
}
.routing-contract article {
min-height: 185px;
padding: 22px;
border: 1px solid var(--line);
background: var(--paper-raised);
}
.routing-contract > i {
color: var(--copper);
font: normal 1rem var(--mono);
text-align: center;
}
.routing-contract b,
.mtp-life b,
.zero-contract b,
.agent-loop b {
display: block;
margin: 25px 0 12px;
font: 650 .72rem/1.45 var(--mono);
}
.precision-table {
grid-template-columns: .9fr 1fr 1.6fr;
}
.precision-table > div {
display: contents;
}
.precision-table > div > * {
min-height: 72px;
padding: 15px 17px;
border-right: 1px solid var(--line);
border-bottom: 1px solid var(--line);
background: var(--paper-raised);
}
.precision-table .head > * {
min-height: auto;
background: var(--ink);
color: white;
}
.precision-table strong { font-size: .66rem; line-height: 1.6; }
.precision-table.compact { grid-template-columns: .65fr 1.25fr 1.5fr; }
.schedule-diagram {
display: grid;
grid-template-columns: 1fr 1fr;
max-width: 940px;
margin: 34px 0;
gap: 12px;
}
.schedule-diagram article {
padding: 24px;
border: 1px solid var(--line);
background: var(--paper-raised);
}
.schedule-diagram article.dual { background: var(--sage-pale); }
.schedule-diagram article > div {
display: grid;
grid-template-columns: repeat(7, 1fr);
gap: 4px;
margin: 25px 0 17px;
}
.schedule-diagram i {
display: grid;
place-items: center;
height: 42px;
background: var(--sage);
color: white;
font: normal .55rem var(--mono);
}
.schedule-diagram i.idle { background: var(--line); color: var(--muted); }
.schedule-diagram i.comm { background: var(--copper); }
.mtp-life,
.agent-loop {
display: grid;
grid-template-columns: 1fr 35px 1fr 35px 1fr;
align-items: center;
max-width: 950px;
margin: 34px 0;
}
.mtp-life article,
.agent-loop article {
min-height: 195px;
padding: 22px;
border: 1px solid var(--line);
background: var(--paper-raised);
}
.mtp-life > i,
.agent-loop > i { color: var(--copper); font-style: normal; text-align: center; }
.zero-contract {
display: grid;
grid-template-columns: repeat(4, minmax(0, 1fr));
max-width: 960px;
margin: 34px 0;
border: 1px solid var(--line);
}
.zero-contract article {
min-height: 215px;
padding: 22px;
border-right: 1px solid var(--line);
background: var(--paper-raised);
}
.zero-contract article:last-child { border-right: 0; }
.zero-contract article.removed { background: var(--copper-pale); }
.followup-grid {
display: grid;
grid-template-columns: repeat(2, minmax(0, 1fr));
max-width: 960px;
margin: 34px 0;
gap: 1px;
border: 1px solid var(--line);
background: var(--line);
}
.followup-grid article {
min-height: 205px;
padding: 23px;
background: var(--paper-raised);
}
.followup-grid article.wide {
grid-column: 1 / -1;
min-height: auto;
background: var(--copper-pale);
}
.followup-grid h3 { margin: 24px 0 11px; font-size: .92rem; }
.agent-loop {
grid-template-columns: 1fr 28px 1fr 28px 1fr 28px 1fr;
}
.agent-loop article { min-height: 210px; }
.state-machines {
display: grid;
grid-template-columns: 1fr 1fr;
max-width: 960px;
margin: 34px 0;
gap: 12px;
}
.state-machines article {
min-height: 290px;
padding: 24px;
border: 1px solid var(--line);
background: var(--paper-raised);
}
.state-machines header b { font-size: .68rem; }
.state-flow {
display: flex;
flex-wrap: wrap;
align-items: center;
gap: 7px;
margin: 32px 0 22px;
}
.state-flow i {
padding: 10px;
background: var(--sky-pale);
font: normal .54rem var(--mono);
}
.state-flow u {
color: var(--copper);
font: .48rem var(--mono);
text-decoration: none;
}
.v4-contract {
grid-template-columns: repeat(3, minmax(0, 1fr));
}
.v4-contract article { min-height: 205px; }
.branch-grid {
display: grid;
grid-template-columns: repeat(2, minmax(0, 1fr));
max-width: 960px;
margin: 34px 0;
gap: 12px;
}
.branch-grid > a {
min-height: 230px;
padding: 24px;
border: 1px solid var(--line);
background: var(--paper-raised);
color: inherit;
text-decoration: none;
}
.branch-grid > a:last-child {
grid-column: 1 / -1;
min-height: 190px;
}
.branch-grid h3 { margin: 24px 0 12px; font-size: 1rem; }
.branch-grid > a > b { display: block; margin-top: 20px; color: var(--copper); font: .55rem var(--mono); }
.audit-grid {
display: grid;
grid-template-columns: repeat(3, minmax(0, 1fr));
max-width: 960px;
margin: 34px 0 18px;
gap: 1px;
border: 1px solid var(--line);
background: var(--line);
}
.audit-grid > article {
min-height: 280px;
padding: 24px;
background: var(--paper-raised);
}
.audit-grid > article.derived { background: var(--sage-pale); }
.audit-grid > article.toy { background: var(--copper-pale); }
.audit-grid h3 { min-height: 62px; margin: 27px 0 13px; font-size: .92rem; }
.audit-rules {
display: grid;
max-width: 960px;
margin-bottom: 36px;
border-top: 1px solid var(--line);
}
.audit-rules p { padding: 13px 5px; border-bottom: 1px solid var(--line); font-size: .68rem; }
.audit-rules b { color: var(--copper); }
.paper-chain.expanded {
display: grid;
grid-template-columns: repeat(2, minmax(0, 1fr));
max-width: 980px;
margin: 34px 0;
border-top: 1px solid var(--line);
border-left: 1px solid var(--line);
}
.paper-chain.expanded .paper-row {
display: grid;
grid-template-columns: 35px 1fr;
min-height: 125px;
padding: 17px;
border-right: 1px solid var(--line);
border-bottom: 1px solid var(--line);
background: var(--paper-raised);
}
.paper-chain.expanded time { grid-row: 1 / 3; color: var(--copper); font: .54rem var(--mono); }
.paper-chain.expanded b { font-size: .68rem; line-height: 1.45; }
.paper-chain.expanded p { color: var(--muted); font-size: .57rem; }
.paper-chain.expanded p span { margin-right: 10px; color: var(--copper); font: .5rem var(--mono); }
@media (max-width: 820px) {
.moe-compare,
.four-layer,
.stat-strip,
.ledger-grid,
.wave-grid,
.number-grammar,
.absorption-explainer,
.schedule-diagram,
.zero-contract,
.followup-grid,
.state-machines,
.v4-contract,
.artifact-callout,
.branch-grid,
.audit-grid,
.paper-chain.expanded {
grid-template-columns: 1fr;
}
.stat-strip > p {
grid-column: auto;
}
.mla-visual,
.grpo-visual,
.r1-pipeline,
.sparse-visual,
.routing-contract,
.mtp-life,
.agent-loop {
grid-template-columns: 1fr;
}
.mla-visual > strong,
.r1-pipeline > i,
.mtp-life > i,
.agent-loop > i {
transform: rotate(90deg);
}
.mapping-table > div,
.precision-table,
.precision-table.compact {
grid-template-columns: 1fr;
}
.precision-table > div { display: grid; }
.precision-table > div > * { min-height: auto; }
.routing-contract > i { transform: rotate(90deg); }
.followup-grid article.wide,
.branch-grid > a:last-child { grid-column: auto; }
.absorption-explainer article,
.zero-contract article { border-right: 0; border-bottom: 1px solid var(--line); }
}
</style>
</BaseLayout>