DeepSeek Infra仙人：从MoE到GRPO的全栈优化拆解

如果你这两年一直泡在 AI 社区八成见过这个说法DeepSeek 是 Infra 仙人。第一次听到我也觉得夸张但把他们的技术路线从头到尾翻完我反而觉得这个词挺精准——“仙人”不是玄学而是把别人不愿意抠的系统级细节一个个抠到位然后反映在训练成本、推理速度、长上下文能力这些硬指标上。今天我想以一名长期做训练/推理系统优化的工程师视角把从细粒度 MoE、MLA、FP8、DualPipe、GRPO再到稀疏注意力与百万 Token Agent 这条硬核技术线完整拆一遍聊聊每项技术解决的瓶颈是什么、为什么这么设计、以及在实际复盘中总结的经验教训。1. 为什么大家都在喊“Infra 仙人”先看全局再看单点大模型圈子里有一个常见误区模型效果好就归功于模型结构模型跑得慢就归功于框架不行。但真实情况是模型结构、训练算法、并行策略、推理部署这四层早就绑死在一起了。你单独优化任何一层效果都可能被另一层的短板吃回去。DeepSeek 最让我佩服的地方恰恰是它把这几层当成一盘棋来下模型设计阶段就考虑到 KV Cache 能不能更小、专家路由能不能更均衡、通信能不能更少、强化学习能不能不背一个巨大的价值网络。“Infra 仙人”这个称呼能在社区传开本质上是因为大家看到了一个结果用有限的算力把模型训练和推理的性价比做到极致。训练侧有 FP8 混合精度、DualPipe 这种系统级调度创新推理侧有 MLA 压缩 KV Cache、稀疏注意力减少计算量算法侧有 GRPO 让强化学习摆脱 critic 模型的大头开销。每个点单拎出来都不算天方夜谭但把它们串成一个完整的系统就不是拼积木这么简单了。要理解这套系统你得接受一个前提真正的 Infra 优化是每一层都为另一层让路。所以这篇不是“DeepSeek 模型讲解”也不是单一框架指南。我想带你走一条完整的技术链从模型结构怎么为推理省钱到训练并行怎么把利用率拉满再到强化学习怎么降低显存压力最后落到长上下文和 Agent 场景下稀疏注意力带来的算力杠杆。读完之后你会发现所谓“Infra 仙人”并不是什么玄学而是把预算思维、瓶颈思维、调度思维刻进了每一项技术选择里。2. 先从模型结构下手细粒度 MoE 与 MLA2.1 细粒度 MoE 到底细在哪MoEMixture of Experts混合专家模型的基本想法是把一个大模型拆成若干个专家子网络每次输入只激活其中一部分。表面上节约了计算量但传统 MoE 工程落地时总是被几个老问题卡住专家数量少、每个专家体积大导致参数容量不够路由网络很容易“一边倒”每次都选同样的热门专家结果热门专家成了瓶颈冷门专家长期饿肚子训练时还要额外加一堆辅助损失来维持负载均衡辅助损失稍微调大又会影响模型本身的收敛质量。细粒度 MoE 的思路是把“大而粗”的专家进一步切成“多而细”的子专家同时额外保留一批共享专家。你可以把它类比成一个大公司原来只有几个事业部每个事业部都臃肿不堪来了新任务只能整组上现在切成大量小团队再配上公共资源池任务来了可以灵活拼装团队组合共享资源池保证基础知识不被每个小团队重复训练。细粒度带来的第一个收益是同等激活参数下专家总数大幅增加模型的知识容量明显提高。第二个收益是路由选择面变大负载更容易均匀辅助损失的压力也随之降低。第三个收益是分布式训练的显存分布更均匀。做 MoE 训练的人都知道专家并行Expert Parallel最怕的就是某张卡上的专家被疯狂访问而细粒度分割让通信和计算的热点都更分散对大规模集群的稳定训练非常关键。2.2 MLA给 KV Cache 做一次低秩瘦身MLAMulti-head Latent Attention多头潜空间注意力在社区讨论里是另一个高频词。理解它之前先想想标准多头注意力在推理时为什么贵。大模型做生成时每个 token 都要把它的 Key 和 Value 缓存下来留给后面所有 token 做注意力计算。这段缓存叫 KV Cache。上下文越长KV Cache 越大如果输入到了几十万 token光 KV Cache 就可能把一块高端 GPU 的显存吃掉大半。多轮对话和 Agent 场景更严重——历史越攒越多显存会持续被占用推理吞吐自然上不去。MQA 和 GQA 的解决思路是让多个注意力头共享同一份 K 和 V这样能减少缓存但代价是不同头之间的表达能力被削弱。MLA 的做法不同它不是简单让头之间共享而是把 K/V 整体投影到一个低维的潜空间里缓存真正参与注意力计算时再从这个潜向量恢复出重建后的 K/V。听起来有点绕但你可以用一个类比缓存时只存一张低分辨率缩略图而不是原图每次计算注意力时先用缩略图快速做匹配筛选等需要真正读取内容细节时再在目标位置放大到可用分辨率。因为潜空间维度远小于原始 K/V 维度KV Cache 的总量被明显压缩长上下文和多并发请求的内存压力都大大缓解。我在实际部署推理服务时最直接的体感是同样的显存预算支持并发数和上下文长度都能上一个台阶。但这里有一个容易被忽略的成本转移MLA 把内存压力转移到了“潜向量上投影重建 K/V”的计算步骤上纯理论看是省了显存实际要实现收益必须把上投影过程做成融合 kernel否则 CPU 和 GPU 之间的拷贝开销会把节省全部吃回去。这也是为什么 MLA 这类模型结构必须配套推理引擎深度优化而不是直接套一个通用框架就能吃满红利。2.3 模型结构如何反哺 Infra细粒度 MoE 和 MLA 加在一起形成了一个很有意思的组合MoE 减小了激活参数量MLA 减小了 KV Cache 量训练阶段看模型每走一步需要的 FLOPs 更可控推理阶段看单请求的显存占用更可控。对 Infra 工程师来说这种“从源头控制资源”的收益比后面再怎么调优调度器都来得直接。所以学这套结构别只看论文里的指标提升多少更要学会问一个问题这个设计让哪个资源瓶颈变松了细粒度 MoE 让“专家并行”更容易做负载均衡MLA 让“长上下文缓存”不再线性吞显存。模型结构的每个细节最终都要翻译成显存、带宽、算力三个维度上的变化这才是 Infra 视角的模型解读。3. 训练系统的硬核突破FP8 与 DualPipe3.1 FP8又快又省的数值格式为什么以前没人敢用FP8 是 8 位浮点数格式。相比 FP16/BF16它的显存占用直接减半同时新一代 GPU 硬件对 FP8 的矩阵运算吞吐往往比 FP16 更高。这听起来是天上掉馅饼但 FP8 真正的难点在于数值范围非常窄一旦权重或梯度里的数值稍微大一点或者小一点就可能溢出或者直接变成 0模型收敛说崩就崩。实际操作时标准做法是把“主权重”保持在 FP32 或 BF16只把前向过程中的激活值、以及反向过程中的梯度值换成 FP8 参与计算。同时配合 per-tensor 或 block-wise 的缩放因子把小数值放大、大数值缩小让数据尽量落在 FP8 可表达的区间里。还有一类做法是分桶保存不同敏感度的层敏感层继续用 BF16非敏感层才用 FP8。各层学习率敏感性差异很大训练时不能一刀切。这里我想给一个实操提醒FP8 的收益不只是省显存更关键的是通信量下降。大规模分布式训练中模型梯度同步的通信开销经常占到大头。如果把梯度在通信前用 FP8 压缩通信时间几乎减半这对训练性价比的提升比单纯算力吞吐更显著。可代价是收敛稳定性需要重新验证Scale 策略稍微调不好loss 就会突然飞掉然后你很可能开始怀疑是不是数据问题实际上一查是 FP8 某个 block 的 scale 在反向传播后期失去了动态平衡。我之前在一套 7B 尺度模型上用类似思路做混合精度跑批实验日志里明确加了三种观测指标梯度范数、每层激活分布、Loss 平滑度。只要这三个指标在 FP8 开关前后保持近一致才敢继续把训练跑下去。没有这套观测体系就贸然压精度大概率会栽跟头。3.2 DualPipe双向流水线把空转气泡压薄说完了精度再谈并行调度。大规模模型训练通常用“数据并行 张量并行 流水线并行”的组合拳。流水线并行把模型按层切成多段分到不同设备上每个设备只负责其中一段。问题也随之而来前后向计算之间经常要互相等待设备上一段时间无所事事这就是“流水线气泡”。早期经典的 1F1B 调度已经能压掉一部分气泡但 DeepSeek 用的 DualPipe 进一步做了双向调度。传统流水线把微批从前往后推像一条单行道上跑接力DualPipe 则从两端同时往里塞数据和计算任务前向计算沿着一个方向推进反向计算沿着另一个方向错峰穿插让每个设备在等待依赖的时候尽量有下一步可算。能不能用一句话理解把训练流水线想象成一条双车道公路你不要等一辆车完全走完整条路才开始发下一辆而是从两个方向同时发车让不同路段的车流尽量重叠。DualPipe 的要点就是把计算图里前向和后向的依赖关系排成更细粒度的交错块让设备永远有活可干。从工程角度看DualPipe 最值钱的不是调度算法本身而是“调度器必须和通信算子重叠设计”的思路。它的效果还严重依赖模型分层和显存预估是否准确。如果某一层因为 FP8 压缩后显存变小你就可以塞更多微批来填充气泡如果某一段算子过重那么反向依赖仍然会把气泡拉回来。所以 DualPipe 与 FP8 的协同不是偶然——省下的显存转手就变成了更密的流水线这两件事是捏在一起的。3.3 训练优化不是单点作战很多人看训练系统会陷入一个误区到处找“最优 micro-batch size”或者“最优并行数”好像这些参数是独立的。但真实的训练优化是一个高度耦合的过程。FP8 改变了显存占用显存占用又决定了流水线能塞多少微批微批数量又直接影响 DualPipe 的气泡率气泡率下降又让通信时间占比上升接着你就要去优化通信与计算重叠。每一步都是连锁反应。这也是为什么 DeepSeek 的训练系统方案经常让我觉得“难抄”单把 DualPipe 借过来但模型还是传统 MHA、精度还停留在 BF16那显存根本不够支撑双向流水线塞更多微批收益自然打折扣。反过来单把 FP8 开启但流水线调度不变通信量和显存省下来也只会变成空闲显存不会自动变成训练吞吐。所以我在自己的项目里一贯建议启动任何训练优化方案前先把资源预算表填清楚——每张卡的显存里模型参数占多少、KV Cache 占多少、梯度通信占多少带宽、计算和通信能不能重叠。预算表填完方向自然清楚。4. 训练算法层的革命GRPO 如何把 critic 裁掉4.1 PPO 在大模型强化学习中的昂贵代价当前大模型的对齐和推理能力提升大量依赖强化学习。传统主流的强化学习算法是 PPO它需要同时训练一个策略模型还有一个评价状态好坏的 Critic 价值网络。这个 Critic 模型往往和主模型规模相当意味着训练的总显存和计算量几乎翻倍而且价值网络很难训稳定经常引入额外的偏差。大模型训练昂贵的背景下你要两个模型同时在 GPU 上跑代价是很高的。尤其在做数学推理、代码生成这类策略优化时我们真正关心的是“这一组答案里哪个相对更好”而不是绝对价值函数到底有多准。这时候硬塞一个庞大的 Critic 模型性价比非常差。4.2 GRPO用组内相对比较替代绝对估值GRPOGroup Relative Policy Optimization群体相对策略优化直接把 Critic 模型砍掉了。它对同一个问题采样出多个不同的输出形成一个组然后根据这个组内不同输出的奖励排序计算出相对优势。哪个回答的奖励比组内平均水平高它就获得正向更新信号低于平均水平后面的更新就会相应降权。这个思路非常符合直觉你不需要一个神准的裁判来告诉你绝对能拿多少分你只需要看同样问题的若干个回答里哪个比哪个好就能指导模型往好答案方向前进。这样做至少有三个优势显存和算力消耗显著下降训练稳定度提升因为不再受价值网络和策略网络之间耦合的影响策略更新的方向更贴近任务实际需求。实操里 GRPO 的 key point 之一是组大小。组太小相对优势的统计噪声太大更新不稳定组太大一次的采样成本暴涨。我个人的调试经验是从 8 到 16 的组大小起步配合 KL 散度约束防止策略更新幅度过大。另一个关键是把奖励归一化做得干净最好在训练循环里把每条样本的原始奖励都打出来目检分布是否合理。如果奖励分布完全扁平GRPO 给出的信号也会很稀薄。4.3 GRPO 对训练基础设施的隐性影响很多讨论只讲 GRPO 算法简单、显存省但没讲它对基础设施形态的影响。由于不再需要为 Critic 模型分配参数存储和通信数据并行/ZeRO 等策略的切分压力变小显存预算更充裕训练时可以把更多全局 batch size 用于采样反过来说分批采样场景天然适合把推理集群和训练集群复用起来——你把老策略模型先放到推理集群上采样一批答案再用这些答案去训练更新这其实就是强化学习训练系统的典型流水线。GRPO 的轻量性让这条流水线更容易搭起来不需要维护一条庞大的双模型训练链路。对我而言GRPO 的价值不只是训练成本下降而是它把“一棵悲观的价值网络”从整个 RL 系统里拿掉让训练过程更加纯粹地押注在优质样本和公平比较上。这种算法选择一旦落到模型更新频率、采样规模的规划里整个训练集群的资源利用率都会上一个大台阶。你有越多资源去采样数据覆盖就越充分模型就越能从相对比较中学到可靠的推理策略。5. 长上下文与百万 Token Agent稀疏 Attention 的算力杠杆5.1 长上下文为什么成了硬骨头大模型从几千 token 一路卷到几十万、甚至百万 token表面看是“窗口变大了”但背后的计算代价不是线性的。标准注意力机制的复杂度随序列长度平方增长序列越长每一个新 token 都要和前面所有 token 都做一次相似度计算计算量、显存占用、带宽需求全都暴涨。更麻烦的是真实 Agent 场景里上下文包含的可能是多个文档、多轮工具调用结果、历史对话很多内容其实是冗余的但模型只能一视同仁地全部计算。这就引出了一个尖锐问题指望把“整段上下文”塞进模型并像读一本书一样逐字精读在算力和延迟上根本不现实。我们真正需要的是让模型学会选择性注意——大部分 token 只需要被粗略处理少部分关键 token 才是注意力应该聚焦的对象。5.2 稀疏注意力从全量计算到选择性聚焦稀疏注意力的核心思想是用更便宜的方式替代全窗口上的两两计算。常见做法包括三类局部窗口注意力只关注附近 token适合捕捉局部语法关系全局 token 作为“记忆锚点”让每个位置都能快速访问文档级关键信息动态选中重要 token通过可学习模块提前判断哪些历史 token 对当前查询更重要然后只在这些 token 上做完整注意力计算。这三类方法各有取舍。局部窗口好在计算固定但信息视野太窄全局锚点能保证长程依赖但锚点本身的选择很关键动态选中重要 token 最灵活但会产生额外的索引开销和负载不均工程实现难度最大。把这三类方法组合起来往往比迷信任意单一方案更稳妥。我自己在长文本抽取任务上测试过稀疏化的注意力版本关键观察是只要保留 top 5% 的重要 token 和全局 token很多下游任务的效果并没有明显下降但显存占用和生成延迟都大幅改善。这说明长文本里绝大部分 token 对当前决策贡献极弱选择性地忽略它们反而是更符合人类阅读习惯的建模方式。5.3 百万 Token Agent 的推理工程配套当 Agent 的上下文接近百万 token 时问题就不只是注意力计算这么简单了。Agent 经常会做多轮工具调用每调用一次工具结果就追加到上下文里下一轮又要重新扫描全部历史。如果不做前缀缓存或者增量处理系统会反复对相同的长前缀做重复计算首 token 延迟被拖得很高。工程上常用的解法是前缀缓存KV Cache 复用把已经处理过的历史 token 的缓存保存下来新增内容只需要从新位置继续计算。但前缀缓存会和稀疏注意力产生新的耦合如果你要跳着读某些 token缓存如何切分哪些 token 需要长期保留这其实是长上下文 Agent 系统最复杂的调度决策之一。另外百万 token 不是“塞得下”就行还必须考虑生成质量。上下文越长模型越容易淹没在冗余信息里出现事实混淆或幻觉。这需要更聪明的上下文管理策略比如让 Agent 自行维护一个外部记忆库只把当前最关键的内容注入模型窗口窗口之外的东西由检索模块按需召回而不是全部堆给模型。这个思路其实已经超越了纯粹的模型层优化进入了系统架构与算法紧密结合的地带。6. “Infra 仙人”的真正底色全栈协同的工程文化6.1 每一项技术都不是孤岛回头看这套技术栈你会发现它们之间的咬合关系才是真正的护城河。MLA 压缩了 KV Cache让长上下文场景下显存不再爆炸这为稀疏注意力减少了计算目标FP8 节省了显存和通信带宽让大规模 MoE 模型在有限集群里能跑得更密DualPipe 把流水线空转压薄又得益于 FP8 腾出的显存GRPO 去掉 critic 模型之后强化学习的采样和训练可以更灵活地复用推理集群。每一个单项技术都是在为其他技术创造更好的系统环境。做 Infra 时间长了会有一个体会真正的性能大杀器通常不在某个孤立的 kernel 优化里而在多个层面的资源预算恰好同时被释放的那一瞬间。DeepSeek 的产品化技术路线恰好就是不断创造这种“同时释放”的场景。6.2 工程师可以带走的五个习惯第一从端到端资源预算出发。不要一上来调参先把显存、带宽、算力、时延四本账算清楚明确瓶颈在哪里再去选技术方案。第二优先创新在瓶颈资源上。别人都在省钱你也可以考虑省显存方向别人都在加层你可以思考如何压缩缓存。第三用调度去填满空闲资源。DualPipe 的本质是调度很多实际项目提升空间都藏在计算与通信的重叠里。第四训练稳定性优先于峰值吞吐。FP8 再快收敛不稳定只会无限拉长调参时间GRPO 再省奖励分布不合理照样训不上去。第五把用户场景焊进架构设计。如果你最终服务的是 Agent 和长文本场景那么 KV Cache 和稀疏注意力从一开始就要进入模型设计清单。6.3 写在最后不要神化要拆解我自己啃这些技术点的体会是如果只盯着一篇模型技术报告里的绚烂词藻很容易被绕晕但如果带着“它优化了哪个瓶颈资源”这个问题去拆每一页都会变成一套很清晰的资源换算题。细粒度 MoE 是在优化参数容量和负载均衡MLA 是在优化 KV Cache 的显存密度FP8 是在优化通信与存储的字节数DualPipe 是在优化空泡和利用率GRPO 是在优化强化学习过程的算力分配稀疏注意力则是在优化长文本下的无效计算。“Infra 仙人”不是天降奇才而是把一条很朴素的工程信条执行到极致不浪费任何一点算力、显存和带宽并且敢于从模型结构层就开始调整一切都为了让有限资源产出更高智能。最后分享一个我自己正在做的小实验在自己的长文本推理服务里把标准缓存替换成类似低秩压缩的思路再配合简单的前缀复用同一台机器上的并发数已经明显上去了。技术史不是线性的而是由无数个这样的小实验和公开报告中的系统方案共同累积出来的。希望你看完这条技术线也能找到属于自己的那个“预算突破口”。