在大型语言模型的推理与训练场景中，FP8 量化已成为平衡计算吞吐与数值精度的关键技术路径。然而，传统 FP8 GEMM 实现往往面临细粒度缩放缺失、内存拷贝开销大、内核参数难以迁移等痛点。DeepGEMM 作为 DeepSeek 开源的统一张量核心库，通过零拷贝设计理念与运行时 JIT 编译机制，为 FP8 矩阵乘提供了兼顾性能与灵活性的工程化解法。本文将从细粒度缩放策略、零拷贝架构设计、内核调参实践三个维度，系统梳理其核心优化思路与可复现参数配置。
细粒度缩放的技术动机与实现路径
FP8 格式的动态范围仅为 FP32 的约 1/256，单一全局缩放因子难以同时覆盖权重与激活值的分布特征。DeepGEMM 引入分层缩放机制，在张量核心计算前对输入进行本地缩放，随后在累加阶段引入全局缩放因子进行补偿。这种设计允许 LHS（左侧矩阵）与 RHS（右侧矩阵）独立配置缩放粒度：LHS 缩放因子采用 TMA 对齐的转置布局，RHS 缩放因子则与矩阵存储布局保持一致。
对于 SM90 架构（Hopper），缩放因子必须以 FP32 格式存储；对于 SM100 架构（Blackwell），则需使用 packed UE8M0 格式 —— 每 4 个 UE8M0 缩放因子打包为单个 torch.int32。这种差异化设计源于两家架构对 FP8 累加精度的不同硬件支持程度。实际部署时，开发者可通过 deep_gemm.transform_sf_into_required_layout() 工具函数自动完成格式转换，无需手动处理底层位级操作。
在具体数值范围控制上，建议将 FP8 输入的动态范围维持在 [-240, 240] 区间，对应 E4M3 格式的最大非无穷值。超出此范围的激活值应先进行预处理缩放，而非依赖内核动态调整，以避免精度损失累积。
零拷贝架构与 JIT 编译策略
DeepGEMM 的核心设计哲学是「零拷贝计算」—— 通过运行时 JIT 编译将内核直接加载到设备端，避开传统 CUDA 扩展的预编译与安装流程。所有内核函数在首次调用时触发即时编译，编译产物缓存至本地目录（默认 $HOME/.deep_gemm），后续调用直接复用缓存实现毫秒级启动。
这种设计带来了三个关键优势：其一，内核参数可根据实时矩阵形状动态调优，而非固定编译时参数；其二，避免了 Python-C++ 边界的数据序列化开销；其三，开发者可通过环境变量灵活控制编译行为。生产环境推荐启用 DG_JIT_USE_NVRTC=1，该选项将 nvcc 替换为 NVRTC，可实现最高 10 倍的编译加速，尽管部分场景下可能存在轻微性能回退（通常低于 3%）。
针对大规模部署，DeepGEMM 提供了多层次缓存机制。通过设置 DG_JIT_CACHE_DIR 可将编译缓存挂载至共享存储，实现多节点间的内核复用。对于延迟敏感的推理服务，建议在服务启动预热阶段主动调用核心 GEMM 接口完成缓存预填充，避免首次请求的冷启动开销。
可复现的内核调参与量化阈值配置
DeepGEMM 的性能调优涉及多个可配置维度，以下为经过验证的关键参数阈值与调优建议。
SM 占用率控制：通过 deep_gemm.set_num_sms(n) 设定活跃 SM 数量。建议将 n 设置为 GPU 物理 SM 总数的 70% 至 85%，留下部分 SM 供调度与 IO 任务使用。在 H800 112 SM 配置下，推荐使用 80 至 96 个 SM。
张量核心利用率估算：调用 deep_gemm.set_tc_util(ratio) 设置目标张量核心利用率。该参数影响内核 tile 形状与 warp 调度策略的选取。建议从 0.8 开始基准测试，根据实际吞吐量微调至 0.85 至 0.95 区间。
连续布局的 M/K 对齐：对于 MoE 场景下的分组 GEMM，需通过 deep_gemm.set_mk_alignment_for_contiguous_layout(align) 设定 M 轴与 K 轴的对齐要求。对齐值必须是 16 的倍数，默认建议设为 128，可通过 deep_gemm.get_theoretical_mk_alignment_for_contiguous_layout() 验证是否达到理论最小值。
量化精度阈值：FP8 输出转换为目标精度时，建议设置以下阈值进行数值校验 —— 相对误差容限 1e-3、绝对误差容限 1e-4、置信区间覆盖率 99.7%。若业务场景对精度更敏感，可将 FP8 累加路径改为 FP16 中间累加，最终输出再 demote 至 FP8 或 FP32。
环境变量速查表：生产部署建议固定以下环境变量 ——DG_JIT_CACHE_DIR=/shared/cache/deep_gemm、DG_PRINT_CONFIGS=1（仅调试）、DG_JIT_WITH_LINEINFO=0（生产环境关闭行信息以减少二进制体积）、DG_USE_NVIDIA_TOOLS=0（外部工具监控时禁用内部 profiling）。
工程落地的监控与回滚
性能监控层面，建议集成 NVIDIA Nsight Systems 采集内核级执行轨迹，重点关注 TMA 内存拷贝与张量核心计算的 overlapped 比例。DeepGEMM 在内核层面已实现计算与数据移动的流水线化，但仍需确保输入张量满足 TMA 对齐要求（可通过 deep_gemm.get_tma_aligned_size() 校验）。
当出现数值异常或性能回退时，可依次回滚以下配置：恢复默认 SM 占用率、禁用 NVRTC 编译选项、检查输入张量对齐是否满足 16 字节倍数要求、验证 CUDA Toolkit 版本是否在 12.3+（SM90）或 12.9+（SM100）的兼容区间内。
综合而言，DeepGEMM 通过细粒度缩放矩阵解耦了量化精度与动态范围约束，零拷贝 JIT 架构消除了传统 GPU 库部署的编译依赖，而可调内核参数则为不同业务场景提供了灵活的优化空间。掌握上述参数阈值与配置策略，是在大规模 LLM 训练与推理中充分发挥 Hopper/Blackwell 架构性能的关键路径。
资料来源：DeepGEMM 官方 GitHub 仓库（https://github.com/deepseek-ai/DeepGEMM）