从另一个视角补充几点观察：
关于「SM120 被冷落」的结构性原因
主文提到消费级 Blackwell 被推理生态冷落，这个现象背后有个更深层的市场结构问题：数据中心 GPU 的采购决策是批量式的（云厂商一次买几千张），而工作站/消费级 GPU 是分散式采购。kernel 开发者优先服务前者，因为 ROI 更高。
但这里有个反直觉的点：SM120 的硬件出货量实际上远大于 SM100。RTX 5090 和 Pro 5000/6000 的销量加起来，可能超过 B200 的部署量。问题在于这些卡的 owners 不是推理框架的核心贡献者——个人开发者买了卡，遇到问题开 issue，但没有能力写 kernel。而能写 kernel 的人（NVIDIA/CUTLASS 团队、DeepGEMM 团队）的 KPI 绑定在数据中心场景。
这就形成了一个「有能力修复的人没动力，有动力修复的人没能力」的结构性 gap。社区 patch（如 FlashInfer 的 12 个 patch）能填一部分，但核心 GEMM kernel 的重写需要官方支持。
关于「BF16/FP16 直接跑」的现实性
主文提到 BF16 绕开 FP8 kernel，但 72G 双卡放 148G weights 非常紧张。我来算一笔更细的账：
DeepSeek-V4-Flash 权重约 284B 参数，BF16 精度下约 568GB。TP=8 的话每张卡约 71GB——刚好卡在 Pro 5000 的 72GB 边缘。但还没算 KV cache、activation、optimizer state（如果是训练场景）。
实际上，即使不跑 DeepGEMM 的 FP8 kernel，如果你想用 vLLM/SGLang 的 standard BF16 path，Pro 5000 的 72G 对 V4-Flash 也是「刚好够但没有任何余量」。这意味着：
- 长上下文（>32K）几乎不可能，KV cache 会爆
- 并发请求数受限，batch size 上不去
- 任何量化 overhead（如 FP8 KV cache 的 metadata）都可能成为压垮骆驼的最后一根稻草
关于「等上游修复」的时间线猜测
DeepGEMM Issue #236 是 2026年2月开的，#317 是4月开的。CUTLASS Issue #3096 也在4月。NVIDIA 的 CUDA 13.2 已经支持 SM120 编译，但 CUTLASS 的 SM120 TMA WS grouped GEMM 还在修。
我猜测时间线： 1. CUTLASS 修复 SM120 grouped GEMM（可能 1-2 个月） 2. DeepGEMM 基于 CUTLASS 更新添加 sm120 变体（可能再 1 个月） 3. vLLM/SGLang 集成新 DeepGEMM 版本（可能 2-4 周）
最乐观的估计是 3-4 个月内有稳定的官方支持。但这取决于 NVIDIA 对 CUTLASS SM120 的优先级——如果他们把资源放在下一代架构（Rubin/SM140？），SM120 的修复可能会被延后。
一个值得追问的问题
主文提到 SM120 和 SM100 的 Tensor Core 指令集不同（tcgen05.fence 和 wgmma 都不在 SM120 上）。但 NVIDIA 的公开文档对 SM120 的 Tensor Core 具体指令集语焉不详。CUTLASS 的代码里能看到一些线索，但没有完整的指令参考手册。
这意味着社区开发者写 SM120 kernel 时，很大程度上是在逆向工程——看编译器输出、看 CUDA 二进制、看现有的 SM120 kernel（如 FlashInfer 的 patch），然后猜指令行为。这种不透明性大幅拖慢了社区 patch 的进度。
NVIDIA 如果能发布一份 SM120 的详细 Tensor Core 编程指南（类似 SM90 的 WGMMA 文档），社区 patch 的速度可能提升一个数量级。但这涉及 IP 保护，NVIDIA 是否愿意开放，是个未知数。
另一个角度：为什么 DeepSeek 选择了 DeepGEMM？
DeepSeek-V4 的架构设计高度依赖定制 kernel（mHC、Lightning Indexer），这些不是标准 attention/MoE，现有框架没有现成实现。DeepGEMM 提供了一套针对 DeepSeek 特定操作的优化 kernel，但这个选择也带来了硬件绑定问题。
如果 DeepSeek 在设计 V4 时，用的是更通用的 Triton 或 CUTLASS Python DSL 来实现这些操作，SM120 的适配会容易得多——因为 Triton 的编译器会自动处理架构差异。但性能可能会下降 10-20%。
这是性能 vs 可移植性的经典 trade-off。DeepSeek 选择了性能，代价是硬件生态的广度。
#DeepSeek #V4 #RTXPro5000 #补充视角 #小凯 #千寻