开源周第三天、第四天连更不停：DeepSeek 的高强度开源把行业卷成了什么样
【免费下载链接】DeepGEMMDeepGEMM: clean and efficient BLAS kernel library on GPU项目地址: https://gitcode.com/GitHub_Trending/de/DeepGEMM
2025 年 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 TFLOPS；5 月补上稠密与 MoE 的权重梯度内核；7 月完成 SM90/SM100 双架构重构并引入低 CPU 开销的 JIT 模块；9 月为 v3.2 的 lightning indexer 增加 MQA scoring 内核；2026 年 4 月发布 Mega MoE、FP8xFP4 GEMM 与 Programmatic Dependent Launch（PDL）；2026 年 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::LazyInit<deep_jit::Runtime<deep_jit::CUDA>>在首次调用时按需拉起编译运行时，csrc/python_api.cpp 通过deep_jit::register_python_api把整套 JIT 对象注册进 Python；setup.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 speedup；tests/test_bf16.py 则直接输出"Average speedup over cuBLASLt"。公开报道中，早期版本相比 CUTLASS 3.6 的 2.7 倍提速、后续 H800 上 1550 TFLOPS 的数字，让"闭源库的护城河"第一次被大规模重新审视——既然开源库用更少的代码达到同等甚至更高吞吐，闭源二进制还能靠什么溢价？
更值得注意的压力传导发生在系统层面，而非单点 GEMM。仓库里最能说明问题的，是 Mega MoE 这条产品线：它把 EP（Expert Parallel）通信调度、Linear 1/Linear 2（FP8xFP4 或 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 中以kNumTMAThreads=128加kNumMathThreads的编译期拆分显式呈现；FP8 缩放因子布局（SM90 的 FP32、SM100 的 packed UE8M0）在 README.md 中被写成规范化文档；启发式选型在 csrc/jit_kernels/heuristics/common.hpp 中表现为对布局、存储、流水线、发射配置的逐项比较，而 csrc/jit_kernels/heuristics/runtime.hpp 甚至给出了 SM100 上"UMMA_N=256 支持固定 256 对齐、对 MoE cast 与分组算子更友好"的设计理由。这些代码本身就是最好的教科书，也让"GPU 内核优化"从玄学变成了可审计的工程。
行业影响几何：cnBeta 的问题我们接着答
cnBeta 在开源第三日的报道标题是"行业影响几何？"——时隔近两年、站在仓库当前 2.8.0 版本的源码面前，这个问题有了更清晰的答案，分三层。
第一层：这是不是营销节奏？不是。若只是营销，仓库不会在开源周之后持续一年半滚动发布——从 1550 TFLOPS 的 FP8 GEMM、SM100 支持、到 Mega MoE、Sparse Indexer、Mega Gate，README.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），仅供参考
