DeepSeek 被戏称为「源神」, 这个称呼多少带点玩笑, 却很贴切. 它开源的不只有模型权重: DeepSeekMoE, MLA, 无辅助损失负载均衡, FP8 训练, DualPipe, 3FS, DeepEP, DeepGEMM, FlashMLA, DSec, 一路从模型结构延伸到集群通信, 文件系统和 Agent 沙箱. 单独看其中一篇论文, 容易把它当成又一个局部改进; 把这些材料按时间和系统层次排在一起, 才能看见 DeepSeek 反复追问的是同一件事: 在硬件, 数据和训练预算已经给定时, 怎样把更多容量, 更长上下文和更多强化学习轨迹塞进可承受的成本里.
我喜欢 DeepSeek 的地方也在这里. 模型论文里的结构选择, 经常能在另一篇系统论文或一个开源仓库中找到工程后果: MoE 增加专家通信, 后面就有 DeepEP; MLA 压缩 KV cache, 后面就有 FlashMLA 和远端 KV 路径; Agent RL 需要海量可执行环境, 后面就出现 DSec. 模型能力和 Infra 回答的是同一组约束, 只是落在不同层次. 这座知识库把分散在论文, 技术报告, README 和代码里的材料接回同一条技术线.
收录范围分成三类: 模型技术报告; 不以发布模型为目的的方法论文 (NSA, mHC, Engram, DSpark 等); 支撑训练和推理的系统论文与开源仓库 (Fire-Flyer, 3FS, DeepEP, DeepGEMM, FlashMLA, DSec 等). 从第一代语言模型一直读到后来的推理, 多模态和 Agent 系统, 可以追踪架构怎样改变计算与状态, Infra 又怎样反过来限定模型可以采用的结构.
每篇论文一个目录, 目录里两篇文章: -bi 是原文逐段中英对照, 难懂的地方插有疑惑块; -analysis 是读完全文和代码之后写的技术解析, 讲每个机制解决哪项成本, 怎么做, 代价多大, 实验数字在什么设置下得出. 开源仓库没有论文, 只写解析, 对照稿翻译仓库自带的设计文档.
这两条线并不是后来硬凑到一起的. DeepSeek-V2 的官方发布把 MLA 与 DeepSeekMoE 放在同一份架构说明里: 前者压缩推理时的 KV 状态, 后者让总参数增长时每个 token 只激活一部分专家. 到 DeepSeek-V3 技术报告, MLA 与 MoE 被保留下来, FP8 混合精度, 无辅助损失负载均衡, Multi-Token Prediction 和 DualPipe 又把问题推进到数值格式, 路由稳定性与流水线调度. 模型报告在讲能力, 同时也一直在交代这些能力为何能在给定集群上训练出来.
Infra 线也不只是给模型做几个快 kernel. DeepEP 处理 MoE 专家并行中的 dispatch 与 combine, DeepGEMM 把 dense、MoE、低精度矩阵乘以及后来出现的若干关键算子放到一套 kernel 库里, FlashMLA 则从 MLA 的推理形态继续走到 dense 与 sparse attention kernel. 3FS 把训练数据、checkpoint、shuffle 和推理 KV cache 都放进共享存储问题里考虑. 从这里回看模型结构, 很多选择不再是一张架构图上的缩写, 而是会落到通信字节、HBM 读取、流水气泡和存储带宽上的具体约束.
这也是本库采用「模型—方法—系统—仓库」四层组织的原因. 模型技术报告给出一代模型的整体设计与结果; 方法论文把某个机制抽出来, 让人看清变量和消融; 系统论文解释硬件拓扑、训练调度、存储与执行环境怎样限定可行方案; 开源仓库让论文里的名词落到接口、数据布局和支持边界. 四层之间有来回关系, 并非从理论一路单向走到实现. 一个 kernel 的可用形态会反过来影响模型愿意采用多大的块、怎样量化、如何组织专家或 KV.
另一条很容易被割裂的线是推理能力与反馈基础设施. DeepSeek-R1 的官方材料明确区分了直接用大规模强化学习训练的 R1-Zero, 以及在此基础上加入冷启动数据和多阶段训练的 R1. 数学、代码与形式化证明能够提供相对明确的反馈, 开放任务则需要奖励模型、验证器与更多采样. 当训练扩展到 Agent 轨迹, 沙箱吞吐、失败隔离、环境复现和长上下文状态就不再是外围工程, 它们直接决定一天能产生多少有效经验.
所以这里不会把 DeepSeek 简化成「某个便宜模型为什么突然成功」的故事. 真正值得追的是一组连续决策: DeepSeekMoE 怎样把容量稀疏化, MLA 怎样压缩状态, V3 怎样把 FP8 与通信重叠推到大规模训练, R1 怎样改变后训练的主要信号, 稀疏注意力与条件记忆又怎样继续处理长上下文成本. 每一代模型都承接前一代已经成立的部分, 再暴露新的瓶颈; 对应的仓库和系统论文则把瓶颈落到可测量的资源上.
作者评价可以直说: DeepSeek 被叫作「源神」, 确实有它让人兴奋的地方. 但这个评价要由具体开放物支撑. 官方组织公开了模型权重与技术报告, 也公开了 DualPipe 的调度实现、DeepEP 的专家通信库、DeepGEMM 与 FlashMLA 的算子实现、3FS 的源码和设计文档. 开放程度并不等于训练全流程已经完整复现; 数据配方、内部训练框架、线上系统配置和不同版本之间的细节仍有边界. 本库既记录公开到什么程度, 也会在证据停住的地方停住.
阅读这些材料时, 最重要的尺度是分清论文结论、仓库当前能力与作者判断. 论文数字只在原实验设置下成立, README 中的支持矩阵会随版本变化, 仓库里的新接口也不能倒推早期模型当时已经使用. 本库按一手材料校正事实, 再用统一的问题串联: 它减少的是计算、状态还是通信; 节省是否转移成另一项成本; 质量证据和系统证据分别覆盖到哪里.
库里的章节关系可以理解成两条互相穿过的坐标轴. 横轴是版本演进, 从早期 dense 模型, DeepSeekMoE 与 V2, 走到 V3/R1 以及后续长上下文、推理和多模态版本; 纵轴是系统层次, 从训练目标和模型结构, 下沉到并行策略、通信、kernel、存储与执行环境. 沿横轴读, 能看见一项机制怎样被保留、修改或替换; 沿纵轴读, 能追问同一个版本为何能训练、怎样部署、成本落在哪里.
这套组织尤其适合处理那些名称相近、实质并不相同的工作. Coder 到 Coder-V2 讨论代码底座和数据演进, CodeI/O研究用可执行输入输出构造训练信号, DSec处理大规模Agent执行环境, 三者都和代码有关, 却分别位于模型、数据与基础设施层. DSec 与代码能力的关系停在执行基础设施, 不能把它列成代码模型的后继版本. Math、R1、Math-V2 与 Prover也不能压成一条简单榜单: 自然语言数学、通用推理、证明验证和Lean形式化反馈使用的目标与判分方式不同. 本库会把联系讲清, 同时保留边界.
首页只给出地图, 具体结论回到对应论文和仓库. 模型报告适合确认一代系统的整体选择, 方法论文适合看机制是否经过控制变量检验, 系统论文适合核对资源模型, 代码仓库适合确认公开实现真正支持哪些形状与硬件. 四类材料互相补证时, 结论可以写得更实; 只有单一来源时, 就按它能够证明的范围表述.
这也给出了本库的适用边界. 它适合追踪 DeepSeek 公开技术如何彼此连接, 不能替代未公开的训练日志和生产配置. 某个仓库后来增加的新能力, 会按当前版本记录, 同时避免把它追认成早期模型已经采用的设计. 版本、证据和时间对应起来, 技术线才不会被事后叙事抹平.
1 收录范围与组织
1.1 四章的分法
第一章是模型技术报告, 从 DeepSeek LLM 到 DeepSeek-V4.1-Flash, 包括 MoE 主线 (DeepSeekMoE, V2, V3, V3.1, V3.2, V4), 推理模型 R1, 以及代码, 数学, 定理证明, 视觉语言, 统一多模态, OCR 等分支. 这一章目前有 24 个模型目录, 其中 16 个与模型库的 DeepSeek 家族重合, 其余条目只在这个专题库收录. 两边各自维护, 便于在本库内部互相链接.
第二章是架构与算法论文. 这些论文不发布旗舰模型, 而是把某个机制单独拿出来做充分的消融: 原生稀疏注意力 NSA, 流形约束超连接 mHC, 条件记忆 Engram, 无辅助损失的负载均衡, 专家专精微调 ESFT, 以代码输入输出预测为训练信号的 CodeI/O, 推理时可扩展的生成式奖励模型 GRM, 以及投机解码框架 DSpark. 它们多数后来进了某一代旗舰模型, 读论文能看到机制在小规模实验里的原始形态和被舍弃的变体.
第三章是系统论文. Fire-Flyer AI-HPC 讲约一万张 PCIe A100 组成的 集群的软硬件协同设计, Insights into DeepSeek-V3 从硬件角度回顾 V3 的架构选择, DualPath 解决 agent 推理里 KV cache 存储带宽的瓶颈, DSec 讲支撑 agent RL 的沙箱平台, Spatiotemporal Composability 给 DeepSeek Harness 的插件系统提供形式化基础.
第四章目前收录五个开源仓库: FlashMLA, DeepEP, DeepGEMM, 3FS 与 smallpond. 目录清单只写已经完成解析的仓库, 不把论文中出现过或计划补充的组件提前算作已收录内容. 这些仓库的设计信息散落在 README, 设计文档和代码注释里, 解析以代码为准.
1.2 相关主题
llm-guide 讲机制本身: MLA 的矩阵吸收, GRPO 的目标函数, 稀疏注意力的一般设计空间. 本库讲 DeepSeek 在具体论文里做了什么选择, 在什么设置下测了什么数. 本库解析遇到需要完整推导的机制, 链接 llm-guide 的对应文章, 不在这里重复推导.
模型库 按家族收录各家模型的技术报告, DeepSeek 只是其中一个家族. 本库第一章与模型库 DeepSeek 家族内容重合, 但本库另外收了方法论文, 系统论文和代码仓库, 模型库不收这些.
2 技术主线
2.1 稀疏化: 专家, 注意力, 记忆
DeepSeek 的论文有一条贯穿三年的主线: 把计算或存储做稀疏, 让总参数和上下文长度增长时, 每 token 的实际开销增长得更慢. DeepSeekMoE 用细粒度专家和共享专家把 FFN 做稀疏; 无辅助损失的负载均衡去掉了平衡损失对主目标的干扰; V2 的 MLA 把 KV cache 压到低秩潜变量; NSA 和 V3.2 的 DSA 把注意力做成按块或按 token 选择; V4 的 CSA 与 HCA 把压缩和稀疏结合起来做百万 token 上下文; Engram 用确定性寻址的 N-gram 查表, 给稀疏增加了「条件记忆」这条轴.
按时间读这一组论文, 能看到同一个问题在不同层次上的解法: FFN 采用专家稀疏, 注意力转向动态选择, 一部分知识存储又被挪到可以放在主机内存的查找表里. 每一步都伴随着对应的 kernel 和通信库: MoE 对应 DeepEP 与 EPLB, MLA 对应 FlashMLA, DSA 对应 DeepSelect.
2.2 训练信号: 规则奖励, 生成式奖励, 自我验证
第二条主线是「RL 的奖励从哪里来」. DeepSeekMath 提出 GRPO, R1 用规则奖励在数学和代码上训出长思维链; GRM 论文把奖励模型做成先写评价原则再打分的生成式模型, 让奖励本身也能靠多采样来提升; DeepSeekMath-V2 训练证明验证器, 让模型对没有标准答案的证明题也能得到可靠的奖励; Prover 系列用 Lean 的形式化检查作为奖励.
这条线和基础设施直接相关. 规则奖励需要大量代码执行和沙箱, DSec 论文给出的数字是单个生产单元每天约 300 万个沙箱, 并发超过 38 万个. agent 场景下的长上下文推理又把 KV cache 的存储和带宽推到瓶颈, DualPath 与 V4.1-Flash 的 KV 压缩都在处理这个问题.
2.3 软硬件协同
第三条主线是「按硬件约束设计模型」. Fire-Flyer 论文讲在 PCIe A100 节点上怎样用 HFReduce 绕开受限的 GPU 到网卡 P2P 路径, 后续版本再用成对 NVLink Bridge 减少主机内存流量; Insights 论文把 V3 的 MLA, MoE 规模, FP8 训练, 节点限制路由逐条对应到 H800 的显存, 算力和互联带宽; DualPipe 让前向与反向的计算和 all-to-all 通信重叠; DeepGEMM 的 FP8 GEMM 处理 Hopper 张量核累加精度不足的问题. 这些论文和仓库放在一起读, 能解释 V3 的很多超参数为什么是那个值.
3 阅读路径
3.1 按主线读
第一次读这个库, 建议沿 MoE 主线按时间读: DeepSeekMoE → DeepSeek-V2 → DeepSeek-V3 → DeepSeek-V3.2 → DeepSeek-V4. 每读完一篇, 去第二章找它引入的机制对应的方法论文, 再去第四章找对应的仓库.
关心 RL 与推理模型的读者, 从 DeepSeekMath 的 GRPO 开始, 接 DeepSeek-R1, 再读第二章的 GRM 和第一章的 Math-V2 与 Prover 系列.
3.2 按问题查
数字旁会标出表号和实验设置; 同目录的 bi 稿保留原文措辞, 页标记 <!-- page k of N --> 对应 PDF 页码. 第四章各仓库的解析则把机制落到具体源码文件和接口.
各章的完整清单见章首页: 模型技术报告, 架构与算法, 基础设施, 开源仓库.
3.3 从论文走到实现
模型报告里出现的新机制, 通常能在另外三章找到更细的材料. V3 的无辅助损失负载均衡对应第二章的独立论文, 专家通信对应第四章的 DeepEP, FP8 训练对应 DeepGEMM, 整体选择又能在第三章的硬件回顾中找到资源约束. V2 的 MLA 可以沿 FlashMLA 走到 kernel, 再沿 DualPath 走到长上下文服务. 这种跨章阅读能区分架构减少了多少理论开销, 实现拿到了多少硬件吞吐, 系统最终保留了多少端到端收益.
强化学习路线也跨越四章. DeepSeekMath 给出 GRPO, R1 展示规模化训练方案, GRM 扩展开放问题的奖励来源, CodeI/O 提供可执行数据, DSec 负责隔离执行环境. 奖励算法决定模型优化什么, 沙箱与验证器决定反馈是否可信, 推理系统决定单位时间能够产生多少轨迹. 只读其中一层, 很难判断能力提升来自训练目标还是样本供给.
4 共同的阅读尺度
4.1 能力数字要带着条件
模型规模, 数据范围, 上下文长度, 采样预算和评测设置都会改变数字含义. 推理模型增加 TestingTime 采样可以提高通过率, 形式化证明增加搜索预算也会提高累计成功率, 系统基准改变 batch 或拓扑则会改变吞吐. 因此每个结果都应与对应表格、实验设置和原文限定语一起读.
版本之间比较时, 先确认底座, 后训练和评测协议是否一致. V3.1, V3.1-Terminus 与 V3.2 的名称接近, 但目标并不完全相同; Coder, Math, Prover 和 VL 各自使用专项数据与任务, 不宜用单一总分排出一条能力序列. 本库更关心机制在什么条件下有效, 以及条件变化后哪些结论仍然成立.
4.2 成本分成计算, 状态与通信
DeepSeek 技术路线反复调整三类成本. MoE 减少每个 token 激活的参数计算, 同时增加专家通信; MLA 和稀疏注意力减少长上下文的状态或读取量; FP8, DeepGEMM 与 FlashMLA 提高具体计算路径的硬件效率. 3FS, DualPath 和 DSec 则把存储与外部执行纳入整条服务链.
遇到「更高效」的结论时, 可以定位它改变哪一项成本, 是否把压力转移到另一项资源, 以及端到端实验有没有覆盖转移后的瓶颈. 这套尺度贯穿四章, 也决定了推荐读法: 模型报告确认目标和结果, 方法论文检查变量控制, 系统论文解释资源约束, 仓库接口则给出实现边界.