DeepGEMM 重大更新：DeepSeek 开源 FP8 矩阵运算库性能飙升 2.7 倍

DeepSeek 对其开源 FP8 矩阵运算库 DeepGEMM 进行重大更新，核心内核仅 300 行代码，在 H800 上实现最高 1358 TFLOPS 算力与 2.7 倍加速比，直接影响大模型训练与推理效率。

DeepSeek 近日对旗下开源矩阵运算库 DeepGEMM 推出了一次重大更新。这个专为 FP8 精度通用矩阵乘法（GEMM）设计的库，核心内核代码仅约 300 行，却在 H800 GPU 上跑出了最高 1358 TFLOPS 的算力和 2.7 倍于 CUTLASS 优化基线的加速比。

对于关注 AI 基础设施的开发者来说，这不是一个可以忽略的数字。

先说清楚 DeepGEMM 是什么

矩阵乘法是大模型计算的绝对底层。无论是 Transformer 的注意力机制，还是前馈网络的线性变换，归根结底都是在做矩阵乘法。GPU 之所以能训练大模型，核心能力就是并行处理海量矩阵运算。

长期以来，大家默认使用 NVIDIA 官方 CUDA 库（cuBLAS）或者 CUTLASS 来做这件事。这些库经过多年打磨，性能已经很强。但 DeepSeek 团队在训练 V3 和 R1 模型的过程中发现，针对 FP8 精度和特定模型结构，还有很大的优化空间。

DeepGEMM 就是这个优化的产物。它不是一个通用的数学库，而是一个高度专注的工具——专门解决 FP8 精度下的矩阵乘法问题，并且内置了 DeepSeek-V3 所使用的精细化缩放（fine-grained scaling）能力。

用一个类比来说：cuBLAS 是瑞士军刀，什么都能干；DeepGEMM 是一把手术刀，只干一件事，但干到极致。

这次更新带来了什么

此次重大更新在原有基础上进一步提升了性能表现和工程可用性。几个关键点值得展开说。

性能数据：不是微调，是质变

DeepSeek 团队使用 NVCC 12.8 编译器在 H800 GPU 上，针对 DeepSeek-V3/R1 推理中实际使用的所有矩阵形状进行了系统测试。结果相当亮眼：

峰值算力：1358 TFLOPS
峰值内存带宽：2668 GB/s
相比 CUTLASS 3.6 优化基线，最高加速比达 2.7 倍

具体到不同矩阵形状，性能表现差异明显。以密集模型的普通 GEMM 测试为例：

M	N	K	算力	内存带宽	加速比
64	2112	7168	206 TFLOPS	1688 GB/s	2.7x
64	7168	16384	336 TFLOPS	—	—

2.7 倍是什么概念？假设你原来训练一个模型需要 100 张 H800 跑一周，矩阵乘法部分如果能快 2.7 倍，整体训练时间和成本都会显著下降。当然，实际收益取决于矩阵乘法在整个计算图中的占比，但对于 Transformer 架构来说，这个占比通常很高。

需要注意的是，2.7 倍是最佳条件下的峰值加速比，出现在较小的 M 值（如 M=64）场景下。这恰好对应推理阶段的典型矩阵形状——batch size 较小时，矩阵的一个维度会比较短。换句话说，DeepGEMM 对推理场景的优化尤其突出。

DeepGEMM 在不同矩阵形状下与 CUTLASS 3.6 的性能对比柱状图

对 MoE 模型的专项优化

DeepSeek-V3 采用了混合专家模型（Mixture of Experts, MoE）架构，这意味着它需要大量的分组矩阵乘法（Grouped GEMM）。普通的矩阵乘法库对这种场景的支持往往不够好。

DeepGEMM 本次更新对 MoE 场景提供了约 1.2 倍的稳定性能提升。1.2 倍听起来不如 2.7 倍那么震撼，但有两点值得注意：

第一，这是"稳定"的 1.2 倍，意味着在各种矩阵形状下都能保持，而不是某个特定 case 的峰值。

第二，MoE 模型的计算量本身就很大，1.2 倍的稳定提升累积起来，对整体训练和推理效率的影响不容小觑。DeepSeek-V3 有 256 个专家，每次推理都要做大量的分组矩阵乘法，这个优化直接作用于模型的核心计算路径。

300 行代码的工程哲学

DeepGEMM 最让人印象深刻的，可能不是性能数字，而是它的代码量——核心内核函数仅约 300 行。

做过 CUDA 开发的人都知道，写一个高性能的 GEMM 内核有多复杂。CUTLASS 的代码量以万行计，各种模板元编程、流水线调度、内存层级管理，复杂度极高。DeepGEMM 用 300 行做到了更好的性能，这背后的工程取舍值得琢磨。

关键在于两个设计决策：

其一，放弃通用性，只做 FP8。不需要支持 FP16、FP32、INT8 等各种数据类型，代码量自然大幅缩减。

其二，采用 JIT（Just-In-Time）即时编译。DeepGEMM 不预编译内核，而是在运行时根据实际的矩阵形状动态编译。这意味着编译器可以针对具体参数做更激进的优化，比如常量折叠、循环展开等。代价是首次运行时有编译开销，但对于大模型训练和推理这种长时间运行的场景，这点开销完全可以忽略。

这种设计哲学和 DeepSeek 一贯的风格一致：不追求大而全，而是在特定场景下做到极致。300 行代码也意味着极低的维护成本和极高的可读性，其他团队想要理解、修改、适配到自己的场景，门槛大大降低。

放在更大的图景里看

要理解 DeepGEMM 这次更新的意义，需要把它放到 DeepSeek 的整体开源战略里看。

2025 年初，DeepSeek 搞了一个"开源周"，连续五天发布了五个核心技术组件：

FlashMLA（Day 1）：针对 Hopper 架构 GPU 优化的 MLA 解码内核，在 H800 上实现 3000GB/s 吞吐和 580 TFLOPS 算力
DeepEP（Day 2）：MoE 模型的 EP 通信库，解决 GPU 间 token 分发和聚合的效率问题
DeepGEMM（Day 3）：FP8 矩阵运算库
以及后续的其他组件

这五个组件加在一起，构成了 DeepSeek 训练和推理基础设施的核心技术栈。它们不是孤立的工具，而是一套协同工作的系统。FlashMLA 优化注意力计算，DeepEP 优化专家间通信，DeepGEMM 优化矩阵乘法——三者分别攻克了大模型计算中最关键的三个瓶颈。

此次 DeepGEMM 的重大更新，说明 DeepSeek 并没有把开源周当作一次性的 PR 活动，而是在持续迭代这些基础组件。这对整个开源社区来说是个积极信号。

对开发者意味着什么

说点实际的。

如果你在做大模型训练，尤其是使用 FP8 精度训练（这在 H100/H800 上越来越普遍），DeepGEMM 值得认真评估。2.7 倍的峰值加速比意味着实实在在的成本节省。即使平均下来只有 1.5-2 倍的提升，对于动辄数百万美元的训练成本来说，也是一笔可观的数字。

如果你在做推理优化，DeepGEMM 的价值可能更大。推理阶段的矩阵形状（小 batch size，即小 M 值）恰好是 DeepGEMM 加速比最高的场景。对于需要部署大模型推理服务的团队，这可以直接转化为更低的延迟和更高的吞吐。

如果你只是在应用层调用模型 API，不直接接触底层计算，那 DeepGEMM 的影响是间接的——它会让模型提供商的推理成本降低，最终可能反映在 API 价格上。目前 DeepSeek 的模型已经以极低的 API 价格著称，DeepGEMM 这类底层优化是其成本优势的重要来源。

对于想要通过 API 调用 DeepSeek 模型的开发者，可以通过 OpenAI Hub 直接接入，兼容 OpenAI SDK 格式，省去单独对接的麻烦：

from openai import OpenAI

client = OpenAI(
    api_key=\"你的 OpenAI Hub API Key\",
    base_url=\"https://api.openai-hub.com/v1\"
)

response = client.chat.completions.create(
    model=\"deepseek-chat\",
    messages=[
        {\"role\": \"system\", \"content\": \"你是一个有帮助的助手。\"},
        {\"role\": \"user\", \"content\": \"解释一下 FP8 精度在大模型训练中的优势\"}
    ],
    temperature=0.7
)

print(response.choices[0].message.content)

# 用 curl 也行
curl https://api.openai-hub.com/v1/chat/completions \
  -H \"Content-Type: application/json\" \
  -H \"Authorization: Bearer 你的OpenAIHubAPIKey\" \
  -d '{
    \"model\": \"deepseek-chat\",
    \"messages\": [
      {\"role\": \"user\", \"content\": \"DeepGEMM 的 JIT 编译机制有什么优势？\"}
    ]
  }'

和竞品比一比

目前 FP8 矩阵运算领域的主要选择包括：

NVIDIA cuBLAS：官方库，通用性最强，但针对特定场景的优化不如专用库
CUTLASS 3.6：NVIDIA 开源的模板库，灵活性高，是很多团队的默认选择，也是 DeepGEMM 的主要对比基线
Triton：OpenAI 推出的编译器，用 Python 写 GPU 内核，开发效率高但峰值性能通常不如手写 CUDA
DeepGEMM：专注 FP8，代码极简，峰值性能最强，但通用性最窄

选择哪个取决于你的场景。如果你需要支持多种数据类型和硬件平台，CUTLASS 仍然是更稳妥的选择。如果你明确在 Hopper 架构 GPU 上做 FP8 计算，尤其是跑 DeepSeek 系列模型，DeepGEMM 几乎是目前的最优解。

一个有意思的趋势是，越来越多的团队开始针对特定场景做"窄而深"的优化，而不是依赖通用库。DeepGEMM 的成功验证了这条路径的可行性。可以预见，未来会有更多类似的专用优化库出现。

一些值得关注的细节

翻了一下社区讨论，有几个点值得补充：

关于硬件适配。DeepGEMM 目前主要针对 NVIDIA Hopper 架构（H100/H800）优化。如果你用的是 A100 或更早的 GPU，FP8 本身就不被原生支持，DeepGEMM 自然也用不上。这是一个硬件门槛。

关于精度问题。FP8 的精度损失一直是业界关注的焦点。DeepGEMM 内置的精细化缩放机制（来自 DeepSeek-V3 的设计）在一定程度上缓解了这个问题，但并不能完全消除。对于精度敏感的场景，仍然需要仔细验证。

关于集成难度。得益于 JIT 编译和极简的代码设计，DeepGEMM 的集成门槛相当低。不需要复杂的编译环境配置，pip install 之后就能用。这一点比 CUTLASS 友好很多——后者的编译配置经常让人头疼。

关于开源协议。DeepGEMM 采用 MIT 协议开源，商用无限制。这对于想要将其集成到自己产品中的团队来说是个好消息。

写在最后

DeepGEMM 这次更新再次证明了一件事：在 AI 基础设施层面，"小而美"的专用优化往往比"大而全"的通用方案更有效。300 行代码做到 2.7 倍加速，这个投入产出比在整个 CUDA 生态里都算得上惊人。

DeepSeek 正在用实际行动重新定义 AI 基础设施的开源标准。从 FlashMLA 到 DeepEP 再到 DeepGEMM，每一个组件都不是玩具级的 demo，而是经过大规模生产验证的工业级工具。这种开源力度和质量，在国内 AI 公司中确实少见。

对于开发者来说，现在是一个好时候——底层计算效率在快速提升，模型能力在持续进化，而获取这些能力的门槛在不断降低。无论你是在做底层优化还是上层应用，都值得持续关注 DeepSeek 的开源动态。

参考来源

DeepSeek 发布 DeepGEMM 重大更新 - Linux.do 社区讨论（社区对本次更新的技术讨论）

DeepGEMM 大更新：300行代码把矩阵乘法拉快2.7倍