DeepSeek 在 GitHub 发布了 DeepGEMM “Public Release 26/09” 更新，新增稀疏索引（Sparse Indexer）、融合内核（Mega Gate、Mega mHC）、Mega MoE 优化与运行时 JIT（DeepJIT），面向其称作 V4.1 的计算路径做了多项底层性能改进。公开代码表明这是一次面向 GPU 张量核和分布式 MoE 系统的基础设施升级，但不能单独证明已有新模型发布或商业化部署的性能结论。
DeepSeek在GitHub公开了高性能GPU张量核库DeepGEMM的“Public Release 26/09”更新。此次变化集中在稀疏索引、MoE路由、HyperConnection和即时编译等底层计算组件，并针对DeepSeek所称的V4.1相关工作负载进行了优化。
但这不是一次新的大语言模型发布。公开信息能够确认的是，DeepGEMM代码库在2026年9月10日合并了一批新的内核、接口和性能改进；它们可能服务于模型训练和推理，却不能单独证明某个新模型已经发布、完成训练，或已经在商业服务中大规模部署。
一次面向GPU计算底层的公开更新
这次更新以DeepGEMM仓库的Public Release 26/09提交对外呈现。GitHub提交页面显示，提交信息为“Public Release 26/09”，由维护者zheanxu在9月10日提交；相关合并请求为#432。
根据合并请求说明，这批改动包括新内核、新功能以及针对既有路径的优化。提交页面显示本次提交涉及128个文件，新增代码超过1.2万行、删除代码超过5,000行。不过，代码改动规模本身并不等同于模型能力或商业性能提升。
DeepGEMM官方仓库将项目定位为统一的高性能张量核库，覆盖现代大语言模型常用的矩阵乘法和注意力相关计算。仓库当前说明列出FP8、FP4和BF16 GEMM、融合MoE、MQA scoring、HyperConnection以及通过通信重叠加速的Mega MoE等组件。
项目采用运行时编译机制。官方README称，内核通过DeepJIT在运行时编译，安装时不需要完成全部CUDA内核编译；当前文档还列出了NVIDIA SM90或SM100架构GPU、CUDA Toolkit 12.9及以上版本、PyTorch 2.3及以上版本等环境要求。代码仓库采用MIT许可证。
稀疏索引对应更复杂的注意力计算路径
本次更新最直接的新内核之一是Sparse Indexer，即稀疏索引器。DeepSeek在合并请求中将其描述为面向V4.1的层级稀疏索引，并称其吞吐量接近Lightning Indexer。
索引器的作用不是生成文本，而是在注意力计算前帮助模型从更大的键值集合中筛选更值得计算的部分。对于长上下文模型，若每个查询都对全部历史键值进行完整计算，计算量和显存访问压力会迅速增加。稀疏索引的基本思路，是先用较低成本的方式缩小候选范围，再对有限的候选执行更精细的计算。
DeepGEMM此前已经支持与DeepSeek V3.2 Lightning Indexer相关的MQA scoring内核。仓库历史记录显示，2025年9月的更新加入了用于Lightning Indexer的加权ReLU MQA logits scoring kernels；2026年4月的公开更新又加入了FP4 Indexer等功能。此次26/09版本则进一步把稀疏索引路径纳入公开代码。
这些变化说明，DeepSeek正在把注意力稀疏化从模型论文或架构描述推进到更具体的GPU内核实现。但目前公开材料没有给出在统一硬件、相同序列长度和相同批量设置下的完整第三方对比，因此“接近Lightning Indexer”应理解为项目维护者对实现吞吐的描述，而不是独立基准结论。
Mega Gate和Mega mHC把多步计算压缩到更少的内核中
第二组变化集中在融合计算。
合并请求称，Mega Gate将路由GEMM和多个MoE路由操作融合到一个内核中，项目方给出的速度提升范围为30%至75%。MoE模型会先根据路由分数把每个token分配给不同专家，路由过程涉及矩阵计算、排序或选择以及数据组织。将这些步骤更多地放到同一GPU执行路径中，目标是减少中间结果写回显存和多次启动CUDA内核的开销。
Mega mHC则针对HyperConnection相关计算，将多个Hyper-Connection操作与RMSNorm融合到一个内核。项目方给出的速度提升范围为45%至85%。HyperConnection是DeepSeek模型架构中的连接机制之一，RMSNorm则是大模型中的常见归一化操作。两者融合的重点并不在新增模型功能，而在减少算子之间的数据搬运和调度成本。
这些百分比是DeepSeek在GitHub合并请求中披露的项目数据。页面没有在摘要中提供足以复核这些数字的完整测试矩阵、硬件型号、批量大小和基线实现。因此，实际收益仍取决于GPU架构、输入形状、通信拓扑、CUDA与PyTorch版本，以及上层推理框架如何调用这些内核。
Mega MoE继续围绕通信与计算重叠优化
DeepGEMM的另一条重要路线是Mega MoE。官方README将其描述为一个融合内核，把专家并行（EP）分发、第一层线性计算、SwiGLU、第二层线性计算和EP合并组合起来，同时尝试重叠NVLink通信与Tensor Core计算。
这类设计针对的是分布式MoE系统中的一个现实问题：token需要在GPU之间发送给对应专家，而专家计算完成后还要把结果合并返回。如果通信、矩阵乘法和激活函数严格串行执行，GPU可能在等待数据时闲置。融合和重叠的目标，是让通信与计算尽量同时进行，从而提高单次请求的有效利用率。
26/09合并请求称，版本针对V4.1优化了Mega MoE，在低延迟场景下约快15%，高吞吐场景下约快4%。这两个数字反映的是不同运行目标之间的取舍：低延迟服务更关心单批次或小批量请求的响应时间，而高吞吐服务更关心单位时间内处理的token数量。
不过，README也显示Mega MoE需要多进程启动、对称内存以及较新的PyTorch版本，并且涉及特定的FP8与FP4权重布局。它不是可以在任意显卡和任意部署环境中直接获得收益的通用开关。对于使用者而言，安装成功、内核能够运行，与在完整模型服务中得到稳定加速，是两个不同的问题。
DeepJIT让代码库更接近运行时专用化
26/09版本还加入了DeepJIT集成。官方将DeepJIT描述为轻量级、头文件式的JIT运行时，用于在运行时编译和加载CUDA内核。
即时编译可以让库根据GPU型号、矩阵形状和运行参数选择或生成更适合的内核。对于大模型系统而言，不同阶段的计算形状差异很大：训练、预填充和解码所需的矩阵尺寸并不相同，MoE专家收到的token数量也会随请求变化。运行时选择有机会减少为所有可能形状预先编译大量内核的需要。
但JIT同样带来新的工程约束，包括首次调用的编译开销、编译缓存管理、CUDA工具链兼容性以及不同驱动环境下的可重复性。DeepGEMM文档列出了一组与JIT相关的环境变量，用于控制编译器、缓存目录、调试输出以及寄存器溢出检查等行为。这意味着，使用者需要把它视为一套与CUDA环境紧密结合的基础设施，而不是普通的Python依赖包。
这次更新透露了什么，又没有透露什么
从公开代码可以确认，DeepSeek正在继续把面向大型MoE模型的优化下沉到GPU内核层：一端是稀疏索引和MQA scoring等注意力相关计算，另一端是路由、专家计算、通信和连接操作的融合。FP4、FP8和BF16等低精度计算格式，则为不同阶段的带宽和算力约束提供了实现选项。
从更新说明提到的“V4.1”可以推断，这些内核至少与DeepSeek内部所称的V4.1工作负载存在关系。但这不能推出一个完整的V4.1模型已经在9月10日发布，也不能据此确定模型参数规模、训练成本、推理价格或对外服务状态。底层库的代码公开，更多说明的是软件栈准备支持哪些计算路径。
同样不能直接从这次提交推导出具体的训练成本下降幅度或商业部署效果。内核速度提升并不自动等于端到端服务成本按相同比例下降，因为系统还会受到GPU采购、显存容量、NVLink或其他互联带宽、专家负载均衡、编译时间、故障重试和服务调度的影响。
AIFlux此前报道的DeepSeek正式发布V4.1-Flash显示，模型架构、上下文处理和推理成本之间的竞争正在变得更加紧密；而DeepGEMM这类项目则体现了另一条竞争路径，即通过算子、通信和编译系统的协同优化，把模型设计转化为真实硬件上的执行效率。
接下来值得关注的，是Sparse Indexer和Mega MoE是否会被更多推理框架正式集成，公开基准能否在独立环境中复现，以及DeepSeek是否会进一步公开与V4.1相关的模型、系统或部署资料。在这些信息出现之前，26/09版本更适合被看作一次重要的基础软件公开迭代，而不是一次新的模型发布或已经验证的性能跃升。
来源：DeepGEMM官方仓库、Public Release 26/09提交、GitHub合并请求#432、DeepGEMM 26/04公开更新说明。