模型报告中的参数量, 精度格式, 专家数量和上下文长度最终都要落到具体硬件. DeepSeek 的系统材料覆盖了训练集群, 通信拓扑, 推理状态存储和强化学习沙箱, 恰好对应模型生命周期中最重的几类资源: 训练需要计算与 all-to-all 通信, 长上下文推理需要 KV cache 容量与带宽, agent 强化学习需要海量隔离执行环境. 本章从这些资源约束出发理解架构选择.
系统论文的指标必须连同「拓扑」和「工作负载」阅读. 同样的吞吐数字, 在不同 GPU, 网络, batch 和序列长度下没有直接可比性. 更重要的是, 系统常通过改变任务切分和数据路径取得收益. 画出数据在哪里产生, 在哪里保存, 由谁消费, 再读优化细节, 才能判断瓶颈究竟被消除还是转移.
这一章可以按五层资源路径理解. 训练集群决定GPU、网络和存储怎样连接; 并行调度与专家通信决定计算能否持续喂满; kernel和低精度决定热点算子能拿到多少硬件吞吐; 共享存储与远端KV路径决定大状态放在哪里; 沙箱和Harness决定模型生成的动作怎样被执行、记录和复现. 五层相互约束, 不能拿某一层的峰值替代端到端收益.
模型决策会沿这条路径产生具体后果. MoE减少每个token激活的参数, 却要求token在专家之间做all-to-all; MLA压缩KV状态, 仍需要适配其布局的attention kernel; FP8减少计算与传输字节, 同时引入缩放和累加精度; Agent RL扩大可验证轨迹, 也会把CPU、内存、镜像、文件系统与沙箱调度推到训练关键路径.
成本转移是贯穿全章的尺度. 通信重叠减少可见等待, 会增加调度约束和驻留状态; KV外移释放GPU显存, 会增加网络与存储读取; 隔离更强的沙箱提高安全性和复现性, 会增加启动与镜像供给成本. 每篇材料都需要回答原瓶颈减少了多少, 新瓶颈落在什么资源上.
1. 训练集群的起点
1.1. Fire-Flyer 的 PCIe 集群设计
Fire-Flyer AI-HPC 记录了以 PCIe A100 为主要计算节点的大规模训练集群. 在缺少节点内 NVLink 的条件下, GPU 间归约容易受 PCIe 拓扑限制. 系统通过 HFReduce 等组件组织数据路径, 配合计算, 网络和存储设计, 让大规模训练在既有硬件条件下保持效率.
这份材料提供了后续软硬件协同路线的背景. 它关注的不只是某个通信算子的峰值, 还包括作业调度, 故障恢复, 存储供给和集群利用率. 大模型训练持续时间长, 节点数量多, 单点性能提升如果增加全局不稳定性, 总训练时间反而可能变差. 因此可靠性与可观测性属于训练吞吐的一部分.
Fire-Flyer建立的是集群层资源模型. PCIe拓扑、GPU到网卡路径、存储供给与节点规模共同决定训练任务怎样铺开. 后来的H800集群改变了节点内互联和可用算力, 通信策略与并行切分也会随之变化. 将两代系统直接按峰值排序意义不大, 更值得追的是同一瓶颈在不同硬件上怎样重新出现.
训练吞吐应按完整step衡量. 一个GEMM加速以后, all-to-all、流水气泡、数据等待或checkpoint占比会上升; 某个阶段被通信重叠隐藏, 也可能增加另一阶段的显存驻留. Amdahl定律在这里很朴素: 剩余最长路径决定端到端收益. 因而kernel、通信库和调度论文的百分比不能直接相加.
1.2. 系统约束怎样进入模型设计
MoE 降低激活计算, 同时增加 token 在专家间重分布的 all-to-all 通信. 低精度提高张量核吞吐, 同时引入缩放粒度与累加精度问题. 流水线并行切分显存, 同时产生气泡和阶段依赖. 这些权衡使模型架构与集群实现无法分开优化.
阅读 Fire-Flyer 后再看 DeepSeekMoE, V2 和 V3, 可以识别哪些设计延续自硬件条件. 专家划分影响通信消息大小, MLA 改变推理状态规模, FP8 改变计算核与通信数据量. 第四章的 DeepEP, DeepGEMM 和 3FS 分别承担通信, 计算和存储路径, 形成论文设计的执行层.
2. V3 的软硬件协同
2.1. 从 H800 约束解释架构参数
Insights into DeepSeek-V3 从硬件角度回看 V3. H800 的显存容量, 张量计算能力和节点间互联共同约束模型并行方式. MLA 减少推理 KV cache, MoE 控制激活 FLOPs, 节点限制路由减少跨节点流量, FP8 提高训练计算吞吐. 各机制在模型报告中属于架构创新, 在系统视角下则对应不同资源上限.
这类回顾材料适合用资源表来读: 参数和优化器状态占显存, 激活值受 micro-batch 与序列长度影响, 专家路由消耗互联带宽, dense GEMM 消耗计算吞吐. 当某个资源成为瓶颈时, 增加另一类资源通常不能线性改善训练速度. V3 的组合价值来自多处约束同时被处理.
2.2. 并行与数值格式必须共同设计
DualPipe 将前向, 反向和通信安排成交叠执行, 目标是缩短流水线空闲时间. MoE 的 all-to-all 如果落在关键路径上, 即使矩阵乘法很快, GPU 仍会等待通信. 重排调度可以隐藏一部分延迟, 但会增加缓存状态和执行依赖, 对稳定实现提出更高要求.
FP8 训练也不只是把数据类型替换成八位格式. 不同张量需要合适的缩放策略, 累加路径要避免精度损失, 通信与 checkpoint 还要明确保存格式. DeepGEMM 对 Hopper 上的矩阵乘法进行专门实现, 模型论文中的低精度方案因此能够转化为实际吞吐.
3. 长上下文推理的状态路径
3.1. DualPath 分离计算与存储压力
DualPath 面向 agent 工作负载中的长上下文和多轮生成. 这类请求会积累大量 KV cache, 计算节点的显存很快被状态占满; 如果把状态外移, 网络与存储读取又可能拖慢解码. DualPath 重新组织 KV cache 在不同节点和路径之间的传输, 使计算资源与存储资源能够分别扩展.
评估这类系统时, 首 token 延迟, 后续 token 延迟, 并发量和 cache 命中都重要. 状态分离提高容量, 但网络故障, 请求迁移和热点上下文会产生新的尾延迟. 模型侧的 MLA 或进一步 KV 压缩减少单请求状态, 系统侧的分离架构提高总状态供给, 两类方法可以叠加.
3.2. agent 工作负载改变推理假设
普通聊天请求通常有有限上下文和连续解码, agent 则可能反复调用工具, 暂停等待结果, 再带着增长后的上下文恢复. GPU 计算在等待期间闲置, KV cache 却仍需保留. 如果所有状态长期占用本地显存, 系统会因容量而非算力限制并发.
Agent 推理需要显式管理「状态生命周期」. 哪些前缀可复用, 哪些 cache 可迁移, 何时回收, 恢复时从哪里读取, 都会影响服务语义和性能. DualPath 应与模型压缩机制一起阅读, 也应与第四章的 3FS 对照, 因为远端状态路径最终依赖高吞吐存储.
4. 强化学习的执行基础
4.1. DSec 的大规模隔离沙箱
DSec 是服务于代码执行和 Agent 强化学习的沙箱基础设施. 模型生成的程序或命令不能直接在训练控制节点执行, 每条轨迹需要隔离环境, 资源限制, 文件系统和结果回收. 当训练产生大量并发 rollout 时, 沙箱启动速度, 调度容量与安全边界会同时成为瓶颈.
沙箱系统连接训练器和外部可验证信号. 训练器提交任务, 执行环境运行代码或测试, 判定器返回结果, 奖励再进入优化过程. 任一环节的超时, 非确定性或资源泄漏都会污染样本. DSec 的意义在于把这条反馈链做成可规模化的基础设施, 使规则奖励能够覆盖更多程序交互任务.
4.2. Harness 的时空组合
Harness Composability 关注复杂 agent 环境的组件组合. 工具, 环境状态, 轨迹和验证逻辑既有时间顺序, 又有资源与隔离边界. 形式化描述这些组合关系, 可以减少插件系统中隐含的执行冲突, 并让同一训练框架承载不同任务环境.
这条研究线提示系统正确性也是训练数据质量的一部分. 如果环境恢复不完整, 工具调用顺序不稳定或验证器共享了不应共享的状态, 模型接收到的奖励就不再对应真实行为. 对 agent RL 而言, 可复现的环境语义与吞吐同样重要.
训练通信可以沿两层理解. DualPipe官方仓库公开的是前向、反向与通信怎样交叠的流水调度; DeepEP处理专家并行中的dispatch与combine, 同时提供偏高吞吐和偏低延迟的路径. DualPipe安排「什么时候做」, DeepEP优化「专家数据怎样交换」. 调度可以隐藏一部分通信, 无法让all-to-all字节消失; 通信库再快, 负载严重偏斜也会让少数专家拖住整步.
计算路径同样分模型定义和算子实现. DeepGEMM把dense、MoE和低精度矩阵乘等热点放进统一kernel库, FlashMLA处理MLA以及后来稀疏attention的数据布局与执行. 模型报告给出理论FLOPs、激活参数和KV变化, 仓库支持矩阵说明这些变化在哪些GPU、dtype与shape上兑现. 当前README新增的kernel不能倒推早期训练当时已经使用.
低精度的收益来自更高张量核吞吐和更少传输字节, 数值风险则落在scale、量化范围与累加. 如果为保持精度频繁回退BF16, 或额外转换占据关键路径, 理论FP8比例不会等量变成训练加速. 因此V3报告、硬件回顾和DeepGEMM要一起读: 一个说明数值方案, 一个说明资源约束, 一个说明公开实现边界.
状态路径由模型压缩和系统供给共同决定. DualPath官方论文针对Agent推理中的存储带宽瓶颈组织双路径KV加载; 3FS官方仓库提供面向训练数据、checkpoint、shuffle与推理KV cache的共享存储. MLA或进一步压缩减少单请求状态量, DualPath和3FS处理剩余状态放在哪里、怎样取回. 前者不会自动解决总容量, 后两者也不会减少模型数学上需要读取的信息.
KV从HBM迁出以后, 容量增加, 网络和存储延迟也进入decode关键路径. 热点前缀、请求暂停、恢复与迁移会改变命中率, 共享存储故障会影响更多计算节点. 系统收益要同时报告本地显存、远端字节、首token延迟、后续token延迟和尾部请求, 只报容量扩展会漏掉读取代价.
DSec官方论文把它定义为大规模Agent训练的弹性沙箱基础设施, 涵盖分层环境、生命周期、内存回收、CPU调度以及从3FS按需加载镜像数据. 它服务代码执行和Agent RL的环境交互, 不属于Coder模型, 也不是代码能力算法. CodeI/O或规则奖励决定生成何种任务、怎样判分, DSec负责让任务隔离执行、保持状态并把结果稳定送回训练器.
公开材料没有逐项证明所有早期代码模型、R1或GRM训练都使用DSec. 更准确的说法是: DSec提供后来公开的规模化执行底座, 能承载代码验证与Agent rollout; 某个模型是否使用, 仍需对应报告确认. 功能契合与时间接近只能形成线索.
DeepSeek Harness官方仓库使用everything-is-a-plugin架构, 用Cordis组合模型适配、工具、会话日志与Agent循环. 它当前明确标为developer preview, 安全说明也指出沙箱和权限控制不能单独保证安全. Harness关注Agent运行时的可组合性, DSec关注集群级高密度隔离执行, 两者都涉及工具, 系统职责仍然不同.
把这些材料串起来, 因果链便清楚了: 模型架构决定计算、状态与通信形状; DualPipe和DeepEP组织训练关键路径; DeepGEMM与FlashMLA执行热点算子; 3FS与DualPath供给数据和远端状态; DSec把可执行反馈扩成高并发训练资源; Harness组织Agent运行时与插件. 每层承接上层产生的负载, 又把新的延迟、容量或正确性约束传回上层.
这条链也提供反例. MoE在FLOPs上更省, all-to-all可能让GPU等待; FlashMLA单kernel更快, selector或KV搬运可能吃掉端到端收益; 3FS吞吐很高, 单请求尾延迟仍可能受热点和网络影响; 沙箱启动很快, 环境不可复现仍会污染奖励. 系统结论必须在对应工作负载上闭环, 不能用局部峰值替代.
5. 按数据路径阅读本章
5.1. 训练路径
训练路径可以从数据存储开始: 3FS 和 smallpond 提供数据读取与处理, GPU 节点执行前向和反向, DeepGEMM 提供矩阵计算, DeepEP 承担 MoE 通信, DualPipe 编排计算与通信. Fire-Flyer 和 V3 Insights 解释整条路径的拓扑与约束, 开源仓库展示其中组件的实现边界.
沿这条路径阅读时, 每遇到一个优化都确认它改变哪项资源: 减少传输字节, 增加并发, 隐藏延迟, 降低显存, 或提高单个 kernel 的吞吐. 这样可以避免把不同层级的百分比直接相加, 也能看出端到端收益受哪个剩余瓶颈限制.
训练路径还包含失败恢复. 大规模作业运行数周时, checkpoint写入速度、故障检测和重启时间都会进入有效训练吞吐. 3FS提供高带宽共享存储, 并不代表每次checkpoint都没有一致性与恢复成本. 报告稳态tokens/s时, 还应知道故障与保存开销是否被排除.
5.2. 推理与强化学习路径
推理路径从模型权重和 KV cache 开始, FlashMLA 降低注意力执行成本, DualPath 管理远端状态, 3FS 提供存储能力. 强化学习在此基础上增加 rollout 调度, 沙箱执行与奖励回传. 代码和 Agent 任务需要可扩展的执行环境; R1 与 GRM 是否直接使用 DSec, 公开材料没有逐项说明. 因此不能仅凭它们都使用强化学习, 就把 DSec 写成所有训练方案的共同依赖.
Fire-Flyer, V3 Insights, DualPath 和 DSec 分别覆盖训练集群、单代模型的软硬件协同、长上下文服务与大规模交互环境. 第四章的开源组件把这些系统抽象进一步落实到数据结构、通信接口和部署条件.
这些材料合起来形成一个统一判断: Infra的目标不只是让单个算子更快, 而是让模型所需的数据、状态和反馈在正确时间到达正确计算单元. 速度、容量、复现性和隔离性缺少任何一项, 模型侧的训练目标都可能无法按预期兑现.
阅读具体数字时, 要把硬件代际、节点拓扑、batch、序列长度、并发与容错条件一起保留. 同一个组件在训练prefill、在线decode和Agent rollout中面对的消息大小与延迟目标完全不同. 高吞吐路径适合大批量数据, 低延迟路径服务细粒度请求, 两者不能用一个峰值带宽替代.
这也是模型与系统互相校准的地方. 模型侧提出更大的容量、更长的状态或更多可验证轨迹, 系统侧给出可承受的形状与成本; 当代价越过边界, 架构、训练方案或服务目标都要重新调整.
因此, 吞吐、容量和可用性必须回到同一工作负载核对. 局部最优只有进入完整的数据路径, 并同时承受通信、存储与失败恢复的约束, 才具有模型训练或服务意义.