72G显存的Blackwell，为什么跑不了DeepSeek V4？

买了两张 RTX Pro 5000，72G GDDR7，Blackwell 架构。显存加起来 144G，DeepSeek-V4-Flash 权重约 148G，TP=2 每卡约 73G——理论上刚好能放下。装完驱动、配好 CUDA 13、拉起 vLLM，模型加载成功，然后：

RuntimeError: Assertion error: Unsupported architecture

不是显存不够。不是模型太大。是DeepGEMM 不认识你的 GPU。

SM120 不是 SM100

这是问题的根源，也是最容易被忽略的点。

NVIDIA 的 Blackwell 架构分两条线：

架构	Compute Capability	代表产品	定位
SM100	10.0	B200, GB200	数据中心
SM120	12.0	RTX Pro 5000/6000, RTX 5090	消费级/工作站

它们在 Tensor Core 微架构上有差异。SM100 用的是完整数据中心规格（tcgen05.fence, wgmma），SM120 是面积和功耗优化的消费级版本。SM100 编译的 kernel 不能直接在 SM120 上跑。

DeepGEMM 的代码库里有 sm90_* 和 sm100_* 的实现，但没有 sm120_*。所以当你调用 kernel 时，架构检测直接抛 Unsupported architecture。

缺了哪两个 kernel？

DeepSeek-V4 依赖 DeepGEMM 的两个关键算子：

1. tf32_hc_prenorm_gemm 用于 Manifold-Constrained Hyper-Connections（mHC）的前归一化 GEMM。这是 V4 架构特有的层——不是标准 attention，不是标准 MoE，是 DeepSeek 自己设计的 hyper-connection 机制。

现有实现：sm90_tf32_hc_prenorm_gemm.hpp, sm100_tf32_hc_prenorm_gemm.hpp 缺失：sm120_tf32_hc_prenorm_gemm.hpp

2. paged_mqa_logits 用于 Lightning Indexer——V4 的压缩注意力索引机制。这个 kernel 负责在 FP8 KV cache 上做分页多查询注意力的 logits 计算。

现有实现：sm90_fp8_paged_mqa_logits.cuh, sm100_fp8_paged_mqa_logits.cuh 缺失：sm120_fp8_paged_mqa_logits.cuh

这两个 kernel 没有 fallback。没有通用 CUDA 实现。没有 Triton 替代路径。它们只存在于 DeepGEMM，而 DeepGEMM 只给 SM90 和 SM100 写了优化版本。

为什么不是简单的"等补丁"？

这里有个深层问题：SM120 的 Tensor Core 指令集和 SM100 不同。你不能把 SM100 的 kernel 改个名字就编译给 SM120。

具体来说：

SM100 用 tcgen05.fence → SM120 没有这个指令
SM90 用 wgmma → SM120 也不支持这个指令
SM120 有自己的 Tensor Core 操作码，需要从头写 warp-level GEMM

这意味着社区不能简单复制粘贴再编译。需要理解 SM120 的 micro-architecture，重写 warp-matrix-multiply-accumulate 的核心循环。这不是改几行 CMake 就能解决的。

当前的 workaround（按靠谱程度排序）

方案一：SGLang + TileLang（部分可用）

SGLang 的 mhc_pre 路径用 TileLang（TVM JIT）在运行时编译 SM120 代码，可以绕过第一个 kernel 的崩溃。但 paged_mqa_logits 没有替代 backend，仍是硬阻塞。

状态：mHC 层能过，attention indexer 会挂。

方案二：ktransformers 社区 hack（有人跑通但不稳）

GitHub 上有人用这套参数在 RTX PRO 4000（SM120, 24G）上跑通：

export SGLANG_DISABLE_DEEP_GEMM=1
export SGLANG_OPT_USE_TILELANG_INDEXER=1
# 加一堆 triton backend fallback

但实测输出是 all-zero token，或者 logits NaN。原因是 fallback 的 fp8_paged_mqa_logits 实现（torch reference 和 tilelang 版本）在 SM120 上结果错误。torch reference 里甚至有个 F.relu 错误地截断了负注意力分数。

状态：能启动，输出不可用。

方案三：Marlin W4A16 fallback（能跑但极慢）

禁用所有 DeepGEMM / NVFP4 路径，回退到 Marlin 量化。在 Qwen3.5-397B 的测试里，Marlin 只跑到 ~5 tok/s，而正确实现的 FP4 路径应该是 50+ tok/s。

而且 Marlin 的激活分布和原生 FP4 不同，会导致 MTP（Multi-Token Prediction）draft head 误判， speculative decoding 反而拖慢速度。

状态：能跑，但速度和体验不如上一代卡。

方案四：等上游修复（最干净但时间未知）

DeepGEMM Issue #236：SM120 feature request（2026年2月开的）
DeepGEMM Issue #317：DeepSeek-V4 具体崩溃（2026年4月开的）
CUTLASS Issue #3096：SM120 TMA WS grouped GEMM 失败
FlashInfer 需要 12 个 patch 才能编译通过 SM120

截至 2026年5月26日，没有 ETA。

给你的建议

如果你已经买了 Pro 5000，现在想跑 V4：

方案	前提	结果
SGLang + 全关 DeepGEMM + Triton backend	愿意折腾	mHC 能过，attention 大概率仍挂
BF16/FP16 直接跑	接受 TP=4 或更长上下文	绕开 FP8 kernel，但 72G 双卡放 148G weights 非常紧张
上 RTX Pro 6000（96G）	预算允许	同样受 SM120 kernel 缺失限制，只是显存裕度更大
等	不着急	最干净，但不知道要等多久

如果你还没买卡在选型：

跑 DeepSeek-V4 的生产环境：上 H100/H200（SM90）或 B200（SM100），生态成熟，vLLM/SGLang 开箱即用
本地开发/测试：Pro 6000 的 96G 比 Pro 5000 的 72G 更有价值——不只是显存大小，而是很多模型在 72G 上刚好差一口气，96G 能放下
SM120 的 Pro 5000/6000：硬件算力很强，但软件生态还在 catch-up。适合跑对 kernel 没特殊要求的模型（Llama 3, Qwen3 标准版），或者愿意做社区 early adopter

这不是你的错

问题的本质不是"配置错了"或"显存不够"，而是消费级 Blackwell 被推理生态冷落了。

DeepSeek-V4 的 kernel 设计高度依赖 DeepGEMM 的定制算子。这些算子优先服务数据中心 GPU（SM90/SM100），因为那是云厂商部署的主流。RTX Pro 系列和 5090 虽然是 Blackwell 架构，但 SM120 的微架构差异让它们被排除在首批支持之外。

72G 显存、GDDR7、Blackwell——硬件规格完全够用。缺的是一行行针对 SM120 重写的 warp-level GEMM 代码。

这不是第一次发生。SM89（RTX 4090）刚出时也经历过类似的 gap——新架构的 kernel 支持总是落后一代。历史规律是：社区 patch 会在 3-6 个月内跟上，但如果你想"今天就用"，要么接受 fallback 的性能损失，要么换 SM90/SM100 的卡。

---

参考

DeepGEMM Issue #317: DeepSeek-V4 on SM120 — Unsupported architecture
DeepGEMM Issue #236: Feature Request: Support sm_120 (5090 and blackwell 6000 pro)
ktransformers Issue #2001: RTX PRO 4000 Blackwell all-zero tokens
CUTLASS Issue #3096: SM120 TMA WS grouped GEMM failure
FlashInfer Issue #2577: NVFP4 mm_fp4 GEMM broken on SM120

#DeepSeek #V4 #RTXPro5000 #SM120 #Blackwell #DeepGEMM #推理部署 #GPU选型 #小凯