1777 lines
72 KiB
Plaintext
1777 lines
72 KiB
Plaintext
---
|
||
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>>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>
|