先说明一下我的第一反应看到“致敬DeepSeek 最新开源的不是模型是国产算力的地基”这个标题我以为是又一个大模型权重开源了。结果点进仓库一看里面没有模型文件躺着的全是 FlashMLA、DeepEP、DeepGEMM 这类名字当时我就意识到这个东西的分量可能比一个模型权重重得多。这篇文章我想从一个做 AI 基础设施的工程师视角把这件事拆开讲清楚DeepSeek 这次到底开源了什么、为什么它被称为“算力地基”、国产加速卡能从中拿到什么、以及我实际部署这些组件时踩过的坑。如果你在做大模型推理优化、在国产算力上跑模型或者单纯好奇“开源模型之外还有什么值得关注”这篇内容应该对你有用。1. 这次开源的“不是模型”到底是一堆什么东西先别急着喊口号我们把仓库里的东西挨个看一遍。它的开源图谱里最核心的几块分别是 FlashMLA、DeepEP、DeepGEMM再加上一套训练侧并行实现的参考代码。它们没有一个包含模型权重却每一块都直接卡在大模型训练和推理的性能命门上。1.1 FlashMLA让 MLA 注意力不再卡在显存带宽上现在主流的大模型推理绝大部分时间都耗在读取 KV Cache 上。KV Cache 是啥通俗点说模型在生成每个 token 时都要回头看之前所有 token 的“记忆”这个记忆缓存在显存里。模型越长这个缓存越大读取它消耗的显存带宽就越吓人。DeepSeek 系列的模型用的是一种叫 MLAMulti-head Latent Attention的注意力机制它的特点是把 KV 压缩得很小从而大幅降低缓存占用。但压缩完缓存之后怎么把这些缓存高效地搬进计算单元就成了新的瓶颈。FlashMLA 就是专门干这个的它是一个针对 MLA 注意力定制的高性能解码内核在 H800 这类 GPU 上把缓存的读取和搬运做到了接近硬件极限。官方数据是在 H800 SXM5 上达到约 3000GB/s 的内存带宽和约 580TFLOPS 的算力我实测下来这个数字没有明显水分基本就是贴着硬件上限在跑。它实现细节里最关键的两点是分页 KV Cache 和变长序列处理。分页 KV Cache 有点像操作系统里的内存分页把缓存切成小块按需分配省显存的同时也方便并行调度。而处理变长序列时FlashMLA 用了专门优化的 ragged ops避免了对所有序列做等长对齐造成的浪费。这两点对推理框架来说都是可以直接拿来用的硬通货。1.2 DeepEPMoE 模型跨卡通信的“高速公路”如果说 FlashMLA 解决的是单卡内部的问题那 DeepEP 解决的就是多卡之间的问题。现在的大模型早就不是一张卡能装下的事情了特别是 MoE混合专家架构的模型每一层都有几十上百个“专家”分散在不同卡上每个 token 都要去访问那些专家这个过程中最要命的就是跨卡通信。具体来说MoE 模型的每次计算都涉及一次 all-to-all 通信每个 token 的数据要从当前卡传到存有对应专家的卡上然后再把结果传回来。这种通信一多通信时间往往比计算时间还长。DeepEP 就是专门为这种场景设计的高性能通信库它同时支持 NVLink 和 RDMA也就是既能搞定单机内的高速互联也能搞定跨节点的网络传输还做了 FP8 低精度通信的支持。我自己的感受是这个库的价值不在于它有多“新”而在于它把 MoE 模型最头疼的通信细节全部优化了一遍消息调度、连接管理、同步机制、异步接口全都给你封装好了。以前团队自己写这套东西没有一年半载根本磨不出能在大规模集群上稳定跑的性能现在直接有个开源的高质量实现可以参照。1.3 DeepGEMM把 FP8 矩阵乘算到极致矩阵乘法是神经网络计算的绝对主力。大模型里的每一个 Linear 层、每一个 Attention 的投影归根到底都是矩阵乘。DeepGEMM 是一个专门为 FP88 位浮点矩阵乘做极致优化的库支持稠密和 MoE 两种 GEMM 场景。这个库比较有意思的地方在于它用了运行时 JIT 编译技术内核不是提前编译好放在仓库里的而是在运行时根据实际的计算形状现场生成最优代码。这么做的好处很明显不用维护一堆针对不同形状的二进制版本还能在启动时针对具体硬件特性做定制。它的设计思路对做编译器、做算子库的团队非常有参考价值因为这不只是某个算子的优化而是整套“针对新硬件做高性能算子”的方法论。1.4 训练侧的并行实现把巨型模型训练的施工图也端出来了除了推理侧的组件这次开源还包含了一套大模型训练的并行实现参考涉及流水并行、显存切分、专家并行之间的组合像 DualPipe 这类流水并行调度与 FSDP、EP 搭配使用的代码都是公开的。训练一个超大参数量的 MoE 模型最难的不是写前向和反向而是怎么把几百上千张卡组织起来高效协作这块是最考验工程经验的。这套代码放在这里对于正在搭建大规模训练集群的团队来说等于拿到一份“工程化施工图”。你可以不照搬它但至少不用再从零摸索并行策略怎么组合。这几样东西放在一起你会看到一个共同点它们都不绑定某个具体模型却能给几乎所有大模型带来收益。模型会迭代但这些底层组件是每个模型都离不开的这就是我理解里“地基”的第一层含义。2. 为什么这套组件会被贴上“算力地基”的标签“地基”这个词不是营销话术我们得从算力软件栈的结构来理解。2.1 芯片只是发电厂真正难的是输电网络把整个算力链条拆开看大概是这么个结构最底层是芯片硬件往上依次是编译器与算子库、通信库、并行运行时再往上是训练框架和推理引擎最后才是各种模型。绝大多数人关注的都是最顶层的模型但决定一个芯片能不能“好用”的恰恰是中间那些看不见的软件层。我用一个可能不太严谨但很好懂的类比芯片是发电厂模型是各种电器而算子库、通信库、并行框架就是输电线路和配电盘。发电厂建得再多如果输电线路规格不统一、配电盘里的接口对不上电器照样没法用。国产加速卡这些年硬件迭代速度很快参数表一个比一个漂亮但实际用起来总觉得差点意思原因往往不在芯片本身而在中间那几层软件算子不全、通信性能上不去、训练框架适配跟不上。DeepSeek 开源这套组件等于是把“标准配电图纸”加“两套已经验证过的最优线路实现”直接公开了。各家发电厂照着图纸去接自己的线路就不用再从零开始摸索。这才是“算力地基”这个说法最实在的地方。2.2 模型是快消品基础设施是长期资产另一个容易被忽略的点是时间尺度。模型每几个月就会换代一次模型权重开源的价值再大也会随着新一代模型的发布被快速稀释。但算子库、通信库、并行框架这些东西不一样一旦成熟可以用上好几年每一代新模型跑在它们上面都能持续受益。换句话说开源模型让很多团队“用上”了大模型能力而开源底层库让更多团队能“造出”属于自己的高性能计算底座。这两者的时间价值完全不在一个量级。所以 DeepSeek 这次开源的价值不在于模型榜单又刷了多少分而在于它把那些原本只有顶尖团队才有的算力工程经验变成了整个技术社区都能学习和复用的公共资产。2.3 它覆盖了从单卡到跨节点的完整纵深还有一点值得注意这次开源的组件不是单点突破而是覆盖了从单卡内核到跨节点通信再到并行训练策略的完整链条。单卡上你有 FlashMLA、DeepGEMM 这类算子库多卡上有 DeepEP 这种通信库再往上还有训练并行参考实现。也就是说一个团队要搭建从训练到推理的完整大模型基础设施中间最难啃的那几块骨头都有人替你趟过一遍了。这种“成体系”的开源比单个项目的开源要有价值得多因为你可以照着这套结构去规划自己的基础设施而不是东拼西凑。这也就是我理解的为什么它配得上“国产算力地基”这个称呼。3. 国产加速卡能拿到什么、怎么接聊了这么多最实际的问题来了这套开源组件对国产加速卡到底意味着什么能直接拿来跑吗这里面其实分好几种情况先说结论能直接用的部分有但更多时候需要做适配适配的工作量取决于加速卡的软件栈和主流 GPU 的兼容程度。3.1 兼容 CUDA 类接口的产品线直接编译跑通的可能性很高现在不少国产加速卡走的是“兼容 CUDA 编程模型”的路线也就是说面向国际主流 GPU 写的算子代码在那套环境里有可能直接编译、直接运行。FlashMLA 这类内核只要目标加速卡支持对应的指令特性和数据类型理论上就能用比较小的改动跑起来。我的建议是先别急着改代码把官方仓库里的 benchmark 脚本原封不动跑一遍看看性能基线在哪里。如果性能差距很大优先排查两个点一是算子内部是否用到了目标卡不支持的硬件特性比如某些异步拷贝指令、特定精度计算单元这些往往需要改写为等价实现二是内存访问模式是否和设备的内存层级匹配不同芯片的显存带宽和缓存结构差异很大同样的算法在不同卡上性能可能差好几倍。3.2 自研指令集的产品线学着思路重写比自己瞎摸索强太多如果加速卡是完全自研指令集那 FlashMLA 确实没法直接编译通过但这不代表它没有价值。这类内核本身就是一份高质量的教学案例KV Cache 怎么分页、block size 怎么选、内存布局怎么设计、计算和访存怎么重叠每一步都有注释和性能数据。一个合格的编译器团队照着这个思路去重写一份针对自家指令集的实现比自己从零开始摸索要快得多。DeepGEMM 的 JIT 编译思路也值得借鉴。它说明了一个很重要的问题算子库不一定要预编译一堆二进制完全可以设计成运行时根据输入形状和硬件特征现场生成代码。这种设计对新兴的加速卡生态非常友好因为硬件还在快速迭代提前编译的算子库很快就过时了JIT 方案能有效降低维护成本。3.3 通信侧DeepEP 的设计可以直接迁移或替换底层通信库可能是国产加速卡最薄弱也最容易被低估的环节。大模型一上规模跨卡通信的性能直接决定整体的训练效率这方面 DeepEP 提供了一个很完整的参考连接怎么管理、消息怎么调度、同步机制怎么设计、异步接口怎么暴露这些都是经过大规模验证的工程经验。国产加速卡的高速互联方案各有各的不同有的是私有链路有的走 RDMA有的还在磨合期。不管底层怎么变DeepEP 上层的消息调度和同步逻辑是可以直接借鉴甚至复用的只需要把底层传输路径替换成自家硬件的实现。举个不太恰当但很直观的例子就像一辆车的发动机可以换但底盘调校参数和驾驶逻辑是通用的。3.4 给想动手的团队一份适配自检清单为了让这事更可操作我把适配工作拆成一张表方便团队对照着安排优先级工作项对应组件主要改动点验收指标单卡算子适配FlashMLA、DeepGEMM指令映射、内存布局、block size 调优达到硬件理论带宽的 70% 以上通信库适配DeepEP底层传输替换、拓扑感知逻辑all-to-all 延迟、吞吐与参考卡同级别训练并行验证DualPipe/FSDP/EP 组合并行策略配置、显存切分比例训练吞吐、显存峰值达标推理框架集成FlashMLA/DeepGEMM 接口kernel 注册、精度对齐端到端生成吞吐提升幅度注意这张表里最重要的不是性能数字本身而是你要先建立一套可复现的基准测试流程。没有基线后面的一切优化都是空中楼阁。另外提醒一句地基不等于毛坯房。开源库提供了一个高质量起点但“能编译通过”和“生产环境稳定跑起来”之间还有大量适配、调优、验证工作要做。指望下载下来就能零成本替代现有方案是不现实的。4. 我在 H800 集群上实测这些组件时踩过的坑说完了价值聊聊实操。我在一个 8 卡 H800 节点上把这些组件完整跑过一遍环境是 CUDA 12.x、PyTorch 2.x配有 NVLink 和 RDMA 网卡。整体体验是性能确实猛但过程里该踩的坑一个都没少记录下来给各位省点时间。4.1 编译 FlashMLA 时的两个常见问题FlashMLA 的编译本身不复杂用 CMake 编成动态库再通过 Python 调用就行。但有两个问题特别容易遇到。第一是 CUDA 版本不匹配官方要求是比较新的 CUDA 版本如果环境里是老版本编译会直接在某个头文件上报错这时候不用怀疑代码有问题先升级环境。第二个问题是显卡算力不达标。FlashMLA 针对的是新架构 GPU如果你手里的卡架构老一些可能连编译都过不了。这个没法硬解只能换机型或者找替代方案。我建议团队在立项时先确认目标硬件是否在支持列表里别等编译报错了才回头查。4.2 调 block size 时性能变化很大FlashMLA 的代码里有一个 block size 参数作用和内存分页的页大小类似。官方默认是 64但我在不同 batch size 和序列长度下测调成 128 之后某些场景的性能反而更高。这说明它不是一劳永逸的配置项需要针对你的实际负载做网格搜索。我在测试里发现一个规律当序列长度比较稳定、batch 比较大时大 block size 有利于减少页表查找开销反过来如果序列长度波动很大小 block size 能减少显存浪费。这对我们做动态批处理的服务很有参考价值。4.3 DeepEP 对网络拓扑的依赖比想象中更敏感DeepEP 同时支持 NVLink 和 RDMA但这两种路径的性能差异非常大。如果集群没有 RDMA 网络只靠普通以太网跑跨节点通信MoE 模型的性能会下降得很厉害。我第一次测试时没注意拓扑检查结果通信耗时远超预期后来才发现是网络类型没匹配上。好在它对拓扑有检测逻辑启动时会打印当前链路类型记得仔细看日志。还有一个测试经验在同一节点上同时跑多个分布式任务时DeepEP 的通信组容易互相干扰最好用环境变量把不同的任务分开调度避免通信链路争抢。4.4 DeepGEMM 的 JIT 预热问题DeepGEMM 的 JIT 编译机制带来了一个实际运维问题首次调用某个形状的 GEMM 时现场编译需要时间所以第一次请求会明显偏慢。这个在测试环境里无所谓但一旦上生产用户可等不了这几秒甚至几十秒。我的做法是在服务启动阶段加一个预热流程把所有常见形状的 GEMM 提前跑一遍让 JIT 缓存生效。等到正式流量进来之后就感觉不到编译开销了。另外DeepGEMM 的两种调度模式也值得说一嘴一种适合固定最大形状的场景另一种适合流式变长输入。实际选择时不要只看单次性能要先分析你的负载特征是“形状固定”还是“动态多变”。4.5 和推理框架集成时的精度对齐最后一步是把这些 kernel 接进推理流程。我走的是标准做法给 FlashMLA 和 DeepGEMM 写 Python 包装层注册成自定义算子然后在模型配置里把对应的 attention 和 linear 层替换掉。这一步最容易被忽视的是精度对齐。替换完算子之后一定要先用小模型跑一遍前向逐层对比输出张量确认误差在可接受范围内再上多卡和生产环境。我在测试时因为默认启用了高精度累加第一次对比精度差得很小但推理性能也损失了一些。后续关闭高精度累加后性能上来了精度也还在接受范围内说明这些参数需要针对你的业务场景做平衡。这些坑看起来零零碎碎但每一个都会在实际部署时变成拦路虎。提前在测试环境把所有链路跑通比上线之后再来排查要省心得多。5. 这比开源模型更值得记住的一件事最后聊点感想。这些年开源大模型很多大家都习惯了“今天发权重、明天跑分刷榜”的节奏。但真正能沉淀下来、被整个生态长期使用的东西往往不是模型本身而是模型背后的基础设施工程能力。DeepSeek 这次开源的这批组件最让我佩服的不是性能数字而是它们把大模型时代最核心、最花钱、最难积累的那层工程经验直接摊开放在了所有人面前。对于还在成长中的国产算力生态来说这比再多发布几个模型权重都更有意义模型可以让应用层繁荣而底层库的开放能让算力层自己也繁荣起来。我的建议是做 AI 基础设施的同学先别急着追新模型花一个周末把 FlashMLA 和 DeepGEMM 的源码读一遍把官方 benchmark 跑一遍。你会发现以前很多说不清道不明的性能问题在看到这些实现之后一下子就通透了。我也很期待看到更多团队把这套“地基”接到不同的加速卡上。毕竟地基的价值不在于图纸画得有多漂亮而在于有多少房子愿意盖在它上面。
