DeepGEMM 一句话：DeepSeek 把 LLM 推理和训练里最吃算力的那几个「核心矩阵计算原语」——FP8/FP4 GEMM、带通信的融合 MoE、闪电索引器的 MQA 打分、HyperConnection——收进了一套干净、能直接读 CUDA 内核源码的库。它不是又一个「加速库」，而是把 CUTLASS 那套复杂模板剥掉，只留少数几个核心 kernel 函数，官方定位就是「能拿来学 NVIDIA GPU kernel 优化的干净资源」。官方实测在 H800 上跑到 up to 1550 TFLOPS，性能「达到或超过专家调优的库」。

一、它到底是啥：一个统一 kernel 库，不是单一 GEMM

实查坐标：deepseek-ai/DeepGEMM，★8281 / fork 1326 / MIT / CUDA / 2.4MB / 2025-02-13 建、2026-09-30 还在推（活跃）/ 149 open issues / desc「clean and efficient BLAS kernel library on GPU」。它一口气覆盖：

  • 正常 GEMM：fp8_fp4_gemm_{nt,nn,tn,tt}、BF16 / TF32，命名约定 D = C + A @ B（NT 布局）；
  • 分组 GEMM（MoE 专用）：沿 M 轴分组的 m_grouped_*_contiguous / _masked + 沿 K 轴分组的 k_grouped_fp8_gemm_tn（MoE 反向）；
  • Mega MoE：把 EP dispatch + linear1/linear2（FP8×FP4）+ SwiGLU + EP combine 融进一个 mega-kernel，用对称内存让 NVLink 通信和张量核计算重叠；
  • MQA 打分 / lightning indexer（DeepSeek v3.2 专用）、HyperConnection 等一堆 DeepSeek 自家模型的专用 kernel。

为什么 kernel 多且专用？因为它就是为 DeepSeek 的推理/训练栈服务的——mega_moe、mqa_logits、locality_domain、mega_mhc 这些名字，全是从 DeepSeek 模型结构里长出来的。

二、机制：DeepJIT 运行时编译，装的时候不编译 CUDA（代码证据）

它最反直觉的设计是「安装零 CUDA 编译」：README 明写「All kernels are compiled at runtime through DeepJIT, requiring no CUDA compilation during installation」。读 csrc/runtime/jit.hpp 看得很清——它靠 DeepSeek 自家的 deep_jit 在运行时把 kernel 用 nvcc 编译好并缓存，安装阶段不碰 nvcc：

#include <deep_jit/backend/cuda/backend.hpp>
namespace deep_gemm {
// 一个惰性初始化的 JIT 运行时，prefix "DG"，按 CUTLASS 版本命名空间
inline deep_jit::LazyInit<deep_jit::Runtime<deep_jit::CUDA>> jit(nullptr);
inline void init_jit(const std::string& library_root_path) {
    const auto config = deep_jit::Config(
        library_root, "DG", "cutlass-" + std::to_string(CUTLASS_VERSION),
        {include_dir}, {"deep_gemm/"});
    jit = deep_jit::LazyInit<deep_jit::Runtime<deep_jit::CUDA>>([config] {
        auto runtime = std::make_shared<deep_jit::Runtime<deep_jit::CUDA>>(config);
        runtime->default_compiler_options.nvcc_flags->
            emplace_back("--diag-suppress=39,161,174,177,186,940");  // 运行时 nvcc
        return runtime;
    });
}
}  // 编译产物落 $HOME/.dj 缓存（DG_JIT_CACHE_DIR），命中即免重编

第二件事：公开 API 干净到能数得过来。读 csrc/apis/gemm.hpp 的 register_apis，暴露给 Python 的核心就这一组（每个都是「a,b,d + 一堆默认值」的短签名，带 recipe 量化配方 + epilogue 融合尾钩子）：

// FP8×FP4 四种布局 + MoE 三种分组 + K 轴反向（register_apis，摘）
m.def("fp8_fp4_gemm_nt", a, b, d, c, recipe, recipe_a, recipe_b,
      compiled_dims="nk", disable_ue8m0_cast=False, alpha, epilogue)
// 同类: _nn / _tn / _tt
m.def("m_grouped_fp8_fp4_gemm_nt_contiguous", ..., grouped_layout, ...)
m.def("m_grouped_fp8_fp4_gemm_nt_masked",    ..., masked_m, expected_m, ...)
m.def("k_grouped_fp8_gemm_tn_contiguous",     ..., ks_cpu, grouped_layout,
      recipe=(1,1,128), ...)
# 配套工具: set_tc_util / set_pdl / get_mn_major_tma_aligned_tensor / transform_sf...

这套「就几个核心函数 + 默认值兜底 + 可选 epilogue」的克制设计，是它自称「clean and accessible for learning kernel optimization」的底气——不像 CUTLASS 那样要你啃模板代数。

三、数字要分清楚：官方口径 vs 营销话术（数据红线）

这里是必须较真的地方。本次选题的 brief（#YesLabAI 那条转述）说 DeepGEMM 把「模型推理成本从 $50 砍到 $1.6、算力成本暴砍 98%」。我把官方 README 和引用的 PR 全部翻了一遍，结论是：官方从头到尾没给过任何美元成本数字。官方能查证的口径只有两条：

  • 性能：README 的 News 里 2025.04.18 那条写着 「up to 1550 TFLOPS on H800」（引用 PR #74/#78/#81/#86）；主文一句 「performance matches or exceeds expert-tuned libraries across various matrix shapes」。更硬的一条官方对比：早期 Performance 表（H800 SXM5 + NVCC 12.8，测 DeepSeek-V3/R1 推理用到的所有矩阵形状）里，vs 内部基于 CUTLASS 3.6 调优的实现，最高加速比 2.7x（如 64×2112×7168 那档 206 TFLOPS、2.7x），这是官方给出的、可当事实用的「省算力」证据。
  • 覆盖：FP8/FP4/BF16/TF32 全精度、SM90(Hopper)+SM100(Blackwell) 双架构、JIT 免装编译。

所以 「$50→$1.6、98%」是传播端加的营销口径，不是 DeepSeek 官方声明——本文一律按官方 TFLOPS / 架构 / 精度口径写，成本那条只在「它确实能省卡时」这个意义上呼应，不把那个具体数字当成事实。这是本篇最大的坑，别被二手转述带跑。

四、横向对比：它跟 CUTLASS / cuBLAS / 各家自研 kernel 的位置

  • vs CUTLASS：它借鉴了 CUTLASS/CuTe 的概念但刻意不依赖其模板代数（README 原话「avoids heavy reliance on their templates or algebras」）——把复杂度藏在少数 kernel 里，代价是覆盖不了 CUTLASS 那么全的场景，是「够用且好读」的取舍。
  • vs cuBLAS/cuBLASLt：代码里 cublaslt_gemm_* 是拿来当基线对照的（见 gemm.hpp 里那几个 static 函数），DeepGEMM 主打 FP8/FP4 低精度 + MoE 融合通信这些 cuBLAS 不特别擅长的点。
  • vs SGLang/vLLM 自研 kernel：它们把 DeepGEMM 当底层 kernel 直接调用（DeepGEMM 的 masked GEMM 就是给 DeepEP 低延迟 kernel 的输出喂的），是「引擎里的算子库」而非独立引擎。

五、坑与诚实边界（本机实跑不了）

  • 需要 NVIDIA SM90（Hopper）或 SM100（Blackwell）独显：requirements 明写，且要 CUDA 12.9+ / PyTorch 2.3+ / CUTLASS 4.0+。我本机没有 NVIDIA 卡、没有 CUDA，跑不了任何 GEMM benchmark——所以本文没有我自己测的加速数字，性能一律引官方 README/PR 口径，不冒充实测。
  • DeepJIT 运行时首次调用要现编译：缓存落 $HOME/.dj（可用 DG_JIT_CACHE_DIR 改），冷启动第一发慢，之后命中即快；要 dump PTX/SASS 调试用 DG_JIT_DUMP_PTX/SASS。
  • Scaling factor 布局是坑点：SM90 要 FP32 scale、SM100 要 packed UE8M0（4 个 UE8M0 塞进一个 int），LHS 还要求 TMA 对齐转置布局——跨架构移植时最容易翻车。

六、我的判断

DeepGEMM 的价值不在「又多了个更快的 GEMM」，而在「把 LLM 的算力底座写成能读懂的 kernel 代码」：少数几个核心函数、运行时 JIT、低精度全支持、还专门把 MoE 通信和计算融成一个 kernel。对做推理优化的人，它是比 CUTLASS 好入门得多的 NVIDIA kernel 范本。但两条得拎清：① 官方口径是 TFLOPS 不是美元，「98% 成本」是营销话术，引用时别当官方数据；② 它吃 Hopper/Blackwell 独显，没有这张卡就只能读代码不能跑。它和 DeepEP、SGLang/vLLM 是一套组合拳，单独拎出来说「DeepGEMM 让推理成本砍 98%」既不准确也不完整。