江南卡皇12 天前
KV 曲线的关键在混合比例：Mamba-2 那部分状态是固定大小，不随序列长度涨；涨的是 Transformer 全注意力层那部分。所以显存不是线性爆，是按「全注意力层数占比」分段涨。官方既然给到 1M ctx，说明他们已经算过 96GB 部署矩阵下 1M 是可行的——但那用的是他们自己的 attention 实现（配 flashinfer 的 mamba backend）。用社区 vLLM 复现，KV 布局可能不同，建议先量 128K / 256K 两档的斜率再外推。
晒成果
Nemotron 3.5 Super-VL 120B-A12B：75GB NVFP4 权重塞进 96GB PRO 6000 的可行性讨论
ke chen12 天前3 条回复NVIDIA 的另一个 Nemotron 3.5：Super-VL-120B-A12B-NVFP4，120B 总参 / 12B 激活，Mamba-2 + Transformer 混合 MoE + C-RADIO 视觉编码器，1M 上下文，原生 MTP 投机解码（LiLiCorr 草稿模型，每步 7 token）。
官方给的 NVFP4 权重实测 75.0GB（HF 仓库 88 个 safetensors 分片相加），部署矩阵写的是 1× DGX Spark (GB10)、1× RTX PRO 6000、1× H200、2× H100、1× GB200。
但站内这边零实测，原因是两本账：站内 fit 用的是保守 padding 口径（params × 2 × 量化系数 + 2，含 KV 与运行时余量），120B 的 NVFP4 在这个公式下要 180GB 以上，96GB 级显卡直接判不 fit。物理账则是 75GB 权重确实能装进 96GB 的 PRO 6000——但 75GB 权重 + 1M ctx 的 KV cache + vLLM 运行时，96GB 真的还剩多少？
我想讨论的几点：
- 1M ctx 的 KV 到底吃多少？混合 Mamba-2 + Transformer 架构下 KV 是按什么比例涨的，有没有人实测过 128K 以上的显存曲线
- NVFP4 消费卡路径：PRO 6000 是 Blackwell 数据中心卡，NVFP4 是原生格式；但 5090（SM120）这条路上官方没写，vLLM 的模拟路径能跑吗
- vLLM 依赖：官方命令行带
--mamba-backend flashinfer、--speculative_config.method dflash、--video-pruning-rate 0.5、--media-io-kwargs（视频 fps 2 / 256 帧）——这几个参数绑 nightly 镜像吗，能不能跟现有 vLLM 0.28 并存 - NVFP4 vs BF16 基准基本持平（Terminal-Bench 2.1 62.78 / 60.67，SWE-bench Verified 71.07 / 71.10），那生产上为什么不用 BF16
回复（3）
ke chen12 天前
NVFP4 vs BF16 生产上我会选 BF16 的理由很朴素：可复现。NVFP4 是 Blackwell 数据中心原生格式，消费卡上走模拟路径的话性能打折、行为也不完全一致；BF16 在 96GB 卡上 75→150GB 权重装不下，那就得换部署目标（H100 80GB ×2 或 GB200）。既然 NVFP4 权重 75.0GB 能在 PRO 6000 跑，NVFP4 才是单卡方案，BF16 是双卡方案——这才是真正的取舍，而不是「哪个分高」。基准上两者基本打平（Terminal-Bench 2.1 62.78 / 60.67，SWE-bench Verified 71.07 / 71.10），NVFP4 还多个 10% 吞吐优势。
bit_squeezer12 天前
补一个部署层面的现实：Super-VL 要 vLLM nightly + --mamba-backend flashinfer，跟现有 vLLM 0.28 环境基本是两套。DGX Spark（GB10）那条路反而最省心——官方直接给整套 Docker 参数，不跟主机环境打架。RTX PRO 6000 上要自己拼镜像。另一个坑：视频输入官方是 fps 2 / 256 帧（--media-io-kwargs），长视频要先自己抽帧，这个预处理成本在服务端很容易被忽略。
登录后即可回复，与社区交流部署经验。
登录后回复