DeepSeek 的模型谱系没有沿着参数规模排成一条直线. 通用语言模型承担架构验证, 代码与数学模型把训练目标推向可验证任务, Prover 系列把验证进一步收紧到形式系统, 视觉语言与 Janus 系列则处理理解和生成之间的表征冲突. 各分支积累的机制随后回到旗舰模型: DeepSeekMoE 的细粒度专家进入 V2 和 V3, DeepSeekMath 的 GRPO 成为 R1 的训练基础, 长上下文与稀疏注意力研究又改变了 V3.2 之后的推理成本结构.
本章适合按“底座, 专项能力, 推理训练, 多模态”四条线交叉阅读. 只按发布时间顺序读, 容易把一次模型发布当成孤立事件; 只看最新模型, 又会错过关键设计为什么出现. 技术报告的价值在于同时给出模型结构, 训练数据与目标, 后训练方法和评测结果. 同一个指标只有放回这些条件中才有可比性.
这里说的「继承」至少有三层. 第一层是模型底座: 专项模型从哪一个 checkpoint 继续训练, 决定它一开始拥有怎样的通用能力、架构和上下文机制. 第二层是数据: 代码仓库、数学网页、形式化证明或图文对改变模型反复见到的模式. 第三层是目标: 下一 token 预测、FIM、规则奖励、Lean 验证、视觉对齐和图像重建会把相同底座推向不同方向. 名称排在同一分支上, 不代表三层都连续.
因此本章关心哪些部分被带到下一代, 以及哪些部分重新训练. DeepSeekMoE 的专家结构进入 V2/V3, V2 的 MLA 又成为后续旗舰底座的重要组成; Coder-V2 官方说明明确写明它从 DeepSeek-V2 的中间 checkpoint 继续预训练, 这与第一代 DeepSeek Coder 从头训练代码模型属于两种继承方式. R1 沿用了 V3-Base 这一代底座并扩大强化学习, 它与 DeepSeekMath 的联系主要落在 GRPO 和可验证奖励经验, 模型接续关系仍需单独核对.
版本比较可以从参数来源开始. 从头预训练意味着架构、tokenizer 与数据配方共同塑造底座; continued pre-training 保留已有表示, 再用专项数据移动能力分布; post-training 则更多改变模型在指令、奖励和采样下的行为. 三种路径即使使用相近名称, 可归因的范围也不同. 例如 Coder-V2 的代码能力不能脱离 DeepSeek-V2 已有的 MoE 与通用能力讨论, R1 的推理表现也不能只归给某一个 RL 公式.
然后看「专项数据到底提供了什么约束」. 代码数据包含语法、仓库依赖与可执行行为, 数学数据包含自然语言推导和可核对答案, Lean 数据把证明压进形式系统, 图文数据则要求视觉表征与语言序列对齐. 数据规模很重要, 数据能否产生可靠反馈同样重要. 规则可核验的任务更容易扩大强化学习, 开放任务需要验证器或奖励模型承担判断.
评测数字也要回到底座和目标. Coder 的补全、修复与仓库级任务, Math 的答案准确率, Prover 的 pass@k, VL 的 OCR 与 grounding, Janus 的理解与生成, 衡量的函数并不相同. 将它们排成单一能力榜会丢掉最有价值的信息: 哪种训练信号改善了哪类行为, 代价又落在数据、搜索还是推理预算上.
旗舰模型像一条汇流线, 专项分支更像实验场. 某项方法先在代码、数学或小规模架构实验中验证, 进入通用模型时还要重新面对多领域数据、负载均衡、通信和服务成本. 所以“后来被采用”只能说明它通过了新的组合检验, 不能把专项论文里的全部结论原样搬到旗舰模型.
这套尺度也能避免一个常见误读: 看到专项模型成绩更高, 就认定它的架构更先进. 很多时候架构基本继承自底座, 真正变化的是继续预训练数据、上下文长度、指令数据与验证奖励; 另一些时候模型规模相近, 激活参数和总参数却因 MoE 相差很大. 比较前至少对齐底座 checkpoint、总参数与激活参数、训练 token、上下文长度、后训练阶段和测试时采样预算.
章内文章会把这些条件放回各自版本. 主线报告负责说明组合方案, 专项报告负责解释某类能力怎样获得, 二者通过明确的底座关系连接. 若官方材料只公开权重、报告或推理代码中的一部分, 结论也停在对应层级, 不用仓库后来新增的能力替早期版本补齐历史.
读者因此可以沿版本追踪继承, 也可以沿能力分支寻找训练信号. 两条路径在同一份技术报告处交会时, 底座贡献、专项数据和后训练目标都能被单独指出, 不会把相近的模型名称误当成完整因果解释.
这也是整章统一采用的比较尺度.
1. 从稠密底座到 MoE 主线
1.1. 早期底座划定训练边界
DeepSeek LLM 是理解后续工作的起点. 它讨论数据清洗, 训练稳定性, Scaling Laws 和通用能力评测, 提供了从数据规模到模型规模的基础坐标. 阅读时应关注实验条件和训练配方, 而非把榜单数字单独摘出. 后续模型改变架构以后, 数据质量和训练稳定性仍然是共同约束.
早期底座还说明 DeepSeek 的路线始终把训练效率与能力扩展放在同一设计里. 架构改动只有能够在给定集群和训练预算内稳定执行, 才会进入更大规模实验. 因而第一代报告与第三章的系统论文并非两套叙事: 模型侧提出规模和通信需求, 系统侧决定哪些组合能够真正运行.
1.2. DeepSeekMoE 建立专家分工
DeepSeekMoE 把传统 MoE 的专家切得更细, 同时保留共享专家吸收跨领域知识. 每个 token 只激活部分专家, 总参数量可以增长而单次前向计算保持受控. 细粒度划分增加了路由和通信压力, 也要求更稳定的负载分布, 因此它应与第二章的无辅助损失负载均衡以及第四章的 DeepEP 一起阅读.
「共享专家」负责高频公共模式, 路由专家负责条件计算. 这种分工影响后续模型的容量利用方式, 但不自动保证专家专精; 数据分布, 路由偏置和并行策略都会改变实际激活. ESFT 对专家选择的研究可以作为后续补充, 它展示了微调阶段如何利用已经形成的专家结构.
1.3. V2 与 V3 把容量扩展变成系统设计
DeepSeek-V2 的关键变化是 MLA 与更成熟的 DeepSeekMoE. MLA 将推理时需要保存的键值信息压入低秩潜变量, 降低 KV cache 占用; MoE 继续扩大总容量而控制激活参数. 两者分别处理注意力状态与 FFN 计算, 共同降低大模型服务成本.
DeepSeek-V3 进一步加入无辅助损失负载均衡, MTP 和 FP8 训练. 这些机制分别处理路由干扰, 训练信号密度与硬件吞吐. 阅读 V3 时应同步查看第三章的硬件回顾和第四章的 DeepGEMM, DeepEP. 技术报告给出最终组合与效果, 系统材料解释组合在 H800 集群上怎样避开显存, 通信和数值精度瓶颈.
V3.1, V3.1-Terminus 与 V3.2 位于基础模型和推理产品之间. DeepSeek-V3.1 将思考与非思考模式纳入同一模型, V3.1-Terminus 集中修正语言和工具调用表现, V3.2 则把稀疏注意力带入正式模型路线. 这一组报告适合按版本差异阅读, 重点看训练目标, 上下文机制与评测协议发生了什么变化.
2. 可验证任务推动推理训练
2.1. 代码和数学提供明确反馈
DeepSeek Coder 与 Coder-V2 把代码仓库结构, 补全目标和长上下文纳入训练. 代码任务既要求自然语言理解, 又能通过编译, 测试和执行结果提供反馈. 这使代码模型成为验证数据工程, 上下文长度和后训练方法的合适分支.
两代 Coder 的底座差异需要单独看. 第一代官方仓库给出的训练设置是从头训练, 数据以代码为主并混入中英文自然语言; Coder-V2 则从 DeepSeek-V2 中间 checkpoint 继续预训练 6T token, 将 DeepSeekMoE、MLA 和 128K 上下文带进代码分支. 所以 Coder-V2 的提升同时来自更强底座、更多语言与代码数据、上下文扩展和后训练, 不能全归给某一个代码目标.
CodeI/O 位于这条线的训练信号一侧. 它研究如何从程序输入与输出构造可执行预测任务, 让模型学习执行语义; 它不是 Coder-V2 的后继型号. DSec 更远一层: 它解决沙箱调度、隔离和大规模执行, 为代码奖励与 Agent RL 提供反馈基础设施. 把 DSec 排进 Coder 模型谱系, 会把「模型能力怎样训练」和「训练样本怎样安全执行」混为一谈.
DeepSeekMath 从数学语料和监督微调出发, 再用 GRPO 进行强化学习. GRPO 不依赖单独的价值模型, 通过同一问题的一组采样结果构造相对优势. 其意义不只是一项数学成绩, 还在于给后续 R1 提供了可扩大规模的训练方法. 阅读时应把奖励可验证性与算法形式同时考虑: 当答案能够规则判定时, 大量采样产生的奖励更可靠; 开放问题则需要不同的奖励来源.
2.2. R1 将强化学习推到通用推理
DeepSeek-R1 展示了规则奖励, 冷启动数据和多阶段训练如何组合. R1-Zero 用强化学习观察推理行为能否自行出现, 正式 R1 再以冷启动样本改善表达与稳定性, 并通过蒸馏把能力迁移到较小模型. 报告中的长推理轨迹是训练结果, 但长度本身不是正确性的充分条件; 奖励规则, 采样策略与问题分布共同决定行为.
从 DeepSeekMath 到 R1 的阅读顺序能够分开「优化算法」和「训练方案」. GRPO 提供组内相对优化方法, R1 把方法放入更长的训练流水线. 第二章的 GRM 又将奖励模型本身改造成可进行 TestingTime 采样的生成模型. 三者合读, 可以看到奖励从规则判定, 学习式评分到生成式评审的变化.
Math-V2 与 Prover 又从 R1 之后分出两种验证接口. Math-V2关注自然语言数学中的生成、验证与自我修正, 证明未必有短答案可直接比对; Prover 把题目和证明放进 Lean, 由形式系统判断内核是否接受. 两者都利用更强推理底座, 数据形态和奖励却不同. 「能验证」在前者更多依赖训练出来的验证器, 在后者则有形式化内核提供硬反馈.
这条数学线可以写成 Math → R1 → Math-V2/Prover, 但箭头表示方法与经验的流动, 不表示所有模型使用相同底座或同一评测. 比较结果时要把自然语言答案、证明质量、Lean通过率以及测试时搜索预算分别列出. pass@k提高可能来自更多采样, 与单次生成能力不是一回事.
2.3. 形式化证明收紧验证环
DeepSeek-Prover 系列把自然语言数学推理转入 Lean. DeepSeek-Prover 关注形式化数据生成和证明能力, Prover-V1.5 继续结合搜索与强化学习. 形式化验证器可以明确判断证明是否通过, 但训练仍受制于形式化题目分布, 搜索预算和证明语言覆盖率.
Prover 与普通数学模型的关键差别在「反馈接口」. 数值答案可以用规则比较, Lean 证明必须通过类型检查与内核验证. 更严格的反馈减少评分歧义, 同时增加数据构造和搜索成本. 阅读 Prover 时应把通过率和采样预算一起看, 避免将更大的搜索量误判成单次生成能力的等量提升.
3. 多模态中的理解与生成
3.1. 视觉语言模型建立对齐接口
DeepSeek-VL 将视觉编码器, 投影模块和语言模型连接起来, 处理图像理解, OCR 与视觉问答. 这类报告的重点是分辨率策略, 视觉 token 数量, 训练阶段和数据混合. 视觉输入会显著改变上下文长度和计算分布, 所以语言模型规模相同并不意味着推理成本相同.
视觉语言分支为后续统一模型提供感知基础. 它也与 OCR 专项形成互补: 通用视觉问答重视跨任务覆盖, OCR 更关心高分辨率文档中的文字密度, 页面结构和长序列效率. 两者的评测集和错误类型不同, 阅读时不宜用一个汇总分数替代具体任务分析.
DeepSeek-VL2 官方仓库显示, 这一代已经把 DeepSeekMoE 引入视觉语言模型, 并以不同总参数和激活参数提供 Tiny、Small 与完整版本. 这里的继承既有语言底座, 也有 MoE 的条件计算方式; 视觉编码器、投影器、动态分辨率与多阶段图文数据仍是专项部分. 不能看到「DeepSeek-V2」底座就忽略视觉侧新增的训练变量.
3.2. Janus 分离理解与生成表征
Janus 系列处理视觉理解和图像生成对视觉表征要求不同的问题. 理解任务需要稳定的语义特征, 生成任务需要适合离散重建的表示. 将两种路径分开编码, 再接入共同的语言主干, 可以减少目标之间的直接冲突. Janus-Pro 在数据规模与训练配方上继续扩展这一路线.
Janus 的统一范围可以从三处判断: 输入图像怎样编码, 输出图像怎样离散化, 文本与视觉 token 怎样组成序列. 「统一多模态」通常指共享自回归主干和交互格式; 各模态仍可使用不同编码器和损失函数.
4. 一条可复用的阅读路线
4.1. 先建立旗舰模型骨架
第一次进入本章, 可依次阅读 DeepSeek LLM, DeepSeekMoE, V2, V3 与 R1. 这五份材料覆盖稠密训练, 条件计算, KV cache 压缩, 低精度与并行训练, 强化学习推理. 读完以后再进入 V3.1, V3.2 等增量版本, 版本说明中的变化才有明确参照.
每份报告先定位四类信息: 基础架构, 训练阶段, 数据与奖励来源, 评测协议. 架构决定一次前向如何计算, 训练阶段说明能力从何而来, 数据与奖励决定优化方向, 评测协议界定数字能说明什么. 对照译稿用于核对原文, 技术解析用于连接机制和实验.
4.2. 再沿专项分支回到主线
关注代码能力时, 从 Coder 到 Coder-V2, 再看 CodeI/O 怎样用输入输出关系构造可执行训练数据. DSec 不属于代码模型的能力演进线; 它是代码执行与 Agent RL 的沙箱基础设施, 适合在追踪「可执行反馈怎样规模化」时阅读. 关注数学推理时, 从 Math 到 R1, 再进入 Math-V2 和 Prover; 关注视觉时, 从 VL 到 Janus 与 OCR. 每条分支都应回看当时采用的基础模型, 因为专项成绩同时受到底座, 数据和训练目标影响.
章节之间的对应关系也提供了复核路径. 模型报告出现 MLA, MoE 通信, FP8 或稀疏注意力时, 第二章解释算法形成过程, 第三章说明集群约束, 第四章展示 kernel 和通信实现. 这样阅读能够把发布结果还原成可验证的设计链条, 也能区分论文中的机制贡献与工程扩展带来的收益.