开源周第三天、第四天连更不停：DeepSeek 的高强度开源把行业卷成了什么样

开源周第三天、第四天连更不停DeepSeek 的高强度开源把行业卷成了什么样【免费下载链接】DeepGEMMDeepGEMM: clean and efficient BLAS kernel library on GPU项目地址: https://gitcode.com/GitHub_Trending/de/DeepGEMM2025 年 2 月底DeepSeek 用连续数日每日一开源的节奏把行业对它的关注从模型参数彻底引向了底层算子。开源周第三天2025 年 2 月 26 日放出的 DeepGEMM是一个以约 300 行核心代码挑战 NVIDIA 专家调优闭源库的 FP8 通用矩阵乘法库第四天它又一口气公开了训练提速、GPU 利用率与优化经验三个方向的项目。本文以仓库源码为证据复盘这条高强度开源时间线拆解 DeepGEMM 究竟靠什么立住性能标杆并尝试回答 cnBeta 当时抛给行业的那个问题这种节奏的开源影响几何开源周时间线复盘从 DeepGEMM 到第四天的连更先还原时间线。开源周前两日已经连续发布到第三天DeepSeek 直接放出了支撑 V3/R1 训练与推理的关键算子库 DeepGEMM——社区当日大量解读的标题几乎共享同一组关键词FP8、300 行、Hopper、超越专家调优库。第四天2025 年 2 月 27 日智源社区等媒体确认其一口气开源 3 个项目方向分别落在训练速度、GPU 利用与优化经验上——这不是零散的代码倾倒而是一次有组织的软件栈公开。仓库自身的演进记录印证了开源周只是起点在 README.md 的 News 时间线中2025 年 4 月 H800 上 FP8 GEMM 冲到1550 TFLOPS5 月补上稠密与 MoE 的权重梯度内核7 月完成 SM90/SM100 双架构重构并引入低 CPU 开销的 JIT 模块9 月为 v3.2 的 lightning indexer 增加 MQA scoring 内核2026 年 4 月发布 Mega MoE、FP8xFP4 GEMM 与 Programmatic Dependent LaunchPDL2026 年 9 月继续推出 Sparse Indexer、Mega Gate、Mega mHC。当前仓库版本号已迭代到 2.8.0见 deep_gemm/init.py。开源周更像是给行业的一个信号这家公司把训练效率的底牌从公开模型延伸到了公开每一层软件实现。DeepGEMM 的价值主张在仓库里写得非常直白它借用了 CUTLASS 与 CuTe 的概念但刻意避免重度依赖其模板与代数README.md只保留数量有限的核心内核函数目标是成为学习 NVIDIA GPU 内核优化的干净教材同时性能匹配甚至超越各矩阵形状下的专家调优库。这正是300 行代码叙事的真正含义——不是省略了对硬件的理解而是把模板复杂度收敛掉让关键路径足够短、足够可读。支撑无需编译安装体验的是仓库里的 DeepJIT 体系。csrc/runtime/jit.hpp 中通过deep_jit::LazyInitdeep_jit::Runtimedeep_jit::CUDA在首次调用时按需拉起编译运行时csrc/python_api.cpp 通过deep_jit::register_python_api把整套 JIT 对象注册进 Pythonsetup.py 更进一步——DG_SKIP_CUDA_BUILD可跳过扩展编译CachedWheelsCommand会优先从 GitHub Releases 拉取预编译 wheel失败才退回本地源码构建。用户在pip install阶段拿到的是二进制真正的内核编译被推迟到运行时按形状、按架构现场完成配合DG_JIT_CACHE_DIR等环境变量做缓存管理。高频开源的压力传导商业公司与研究机构都坐不住了DeepGEMM 之所以让行业卷起来是因为它动的是最敏感的那块蛋糕NVIDIA 自己的 cuBLAS/cuBLASLt。品玩当时给出的标题极具代表性——比英伟达更懂如何优化英伟达。仓库中的性能测试体系对此毫不掩饰在 tests/test_fp8_fp4.py 里每个形状都会调用 cuBLAS 做基线打印cuBLAS speeduptests/test_bf16.py 则直接输出Average speedup over cuBLASLt。公开报道中早期版本相比 CUTLASS 3.6 的 2.7 倍提速、后续 H800 上 1550 TFLOPS 的数字让闭源库的护城河第一次被大规模重新审视——既然开源库用更少的代码达到同等甚至更高吞吐闭源二进制还能靠什么溢价更值得注意的压力传导发生在系统层面而非单点 GEMM。仓库里最能说明问题的是 Mega MoE 这条产品线它把 EPExpert Parallel通信调度、Linear 1/Linear 2FP8xFP4 或 FP8xFP8、SwiGLU 与 EP combine 全部融合进单个 mega-kernel并让 NVLink 通信与张量核心计算重叠。deep_gemm/mega/init.py 展示了完整用法先通过get_symm_buffer_for_mega_moe基于 PyTorch 的 symmetric memory 机制分配跨进程可见的对称缓冲再经transform_weights_for_mega_moe完成 gate/up 权重的交错与缩放因子的 UTCCP 转置最后单次调用fp8_fp4_mega_moe完成整条 MoE 前向。内核侧的调度器deep_gemm/include/deep_gemm/scheduler/mega_moe.cuh甚至为L1 与 L2 任务交替调度可能引发的死锁专门计算了最小 warmup wave 数deep_gemm/include/deep_gemm/layout/mega_moe.cuh 中的MegaMoESignals结构体则容纳了 grid 同步、NVLink barrier、环形缓冲区信号与combine_ready_grid_idx等跨 rank 握手状态。基准测试 tests/test_mega_moe.py 默认跑在 8 rank、384 专家、top-6、hidden 7168 的 V3 级配置上对比基线是DeepEP 分发 分组 GEMM tilelang SwiGLU的拼接实现输出维度涵盖 TFLOPS、HBM 吞吐与 NVLink 吞吐并用approx_factor单独估算通信重叠带来的等效加速。这类通信-计算重叠 融合内核的系统级优化才是让商业推理引擎团队感受到直接压力的部分——它不是某个算子快一点而是整个 MoE 前向的执行模型被重构了。对研究机构而言压力则是另一副面孔机会。CSDN 上大量 Day 3 学习笔记DeepGEMM 学习笔记小白版解析说明研究者第一次能拿到一份可读、可跑、可复现的工业级内核优化样本——持久化 warp 专业化在 deep_gemm/include/deep_gemm/impls/sm90_fp8_gemm_1d1d.cuh 中以kNumTMAThreads128加kNumMathThreads的编译期拆分显式呈现FP8 缩放因子布局SM90 的 FP32、SM100 的 packed UE8M0在 README.md 中被写成规范化文档启发式选型在 csrc/jit_kernels/heuristics/common.hpp 中表现为对布局、存储、流水线、发射配置的逐项比较而 csrc/jit_kernels/heuristics/runtime.hpp 甚至给出了 SM100 上UMMA_N256 支持固定 256 对齐、对 MoE cast 与分组算子更友好的设计理由。这些代码本身就是最好的教科书也让GPU 内核优化从玄学变成了可审计的工程。行业影响几何cnBeta 的问题我们接着答cnBeta 在开源第三日的报道标题是行业影响几何——时隔近两年、站在仓库当前 2.8.0 版本的源码面前这个问题有了更清晰的答案分三层。第一层这是不是营销节奏不是。若只是营销仓库不会在开源周之后持续一年半滚动发布——从 1550 TFLOPS 的 FP8 GEMM、SM100 支持、到 Mega MoE、Sparse Indexer、Mega GateREADME.md 的 News 列表里每一次大版本都对应可运行的测试与基准。开源周真正输出的不是新闻热度而是一条代码持续公开的默认路径。第二层300 行代码意味着底层优化没有门槛了吗恰恰相反门槛只是转移了。单算子层面DeepGEMM 证明极简内核 运行时 JIT 选型可以逼近硬件极限但系统层面deep_gemm/mega/init.py、deep_gemm/include/deep_gemm/scheduler/mega_moe.cuh 与 deep_gemm/include/deep_gemm/layout/mega_moe.cuh 里的对称内存规划、环形缓冲容量推导、死锁规避与 NVLink 握手协议难度远超单个 GEMM。竞争的战场从把 GEMM 写快升级到了把 MoE 整条链路焊成一个可调度的内核。第三层开源是否真的稀释了商业壁垒要给出有依据的答案必须看到硬币的两面。一面是普惠化DeepSeek 同期联合开源的昇腾平台基础设施TileLang、计算库与分布式通信库报道以及其自研推理芯片的战略分析共同指向一条软件开源降低硬件进入门槛的路径——CUDA 生态的排他性正在被开源软件栈从边缘撬动。另一面是共存开源并未消灭闭源价值csrc/apis/gemm.hpp 中cublaslt_gemm_*、batched_syrk、batched_symm等 API 的注册表明DeepGEMM 自己也会在合适场景回落到 cuBLASLt例如确定性算法开启或特定 batched 原语开源库与闭源库在真实系统中是按场景择优的关系。所以最终答案落在一个判断上DeepSeek 的开源周没有把行业卷死而是把行业的竞争维度从你会不会优化重置成了你优化什么、优化得多透明。算子层的性能上限被开源迅速拉平之后Mega MoE 式的系统级融合、通信重叠与端到端调度以及这些能力是否愿意公开才成为新一轮的分水岭。DeepGEMM 的源码此刻就摊在仓库里——它既是答卷也是下一场考试的开卷样本。【免费下载链接】DeepGEMMDeepGEMM: clean and efficient BLAS kernel library on GPU项目地址: https://gitcode.com/GitHub_Trending/de/DeepGEMM创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考