为什么 W4A8 / W4A4 ConvRot、NVFP4 在我们的 RTX 5090 上都没有省显存

临时报告 · 追到 comfy_kitchen 0.2.28/0.2.31 内核源码级别 · 目标机器 viggle_new_5090 (RTX 5090 ×8, compute capability 12.0)

先回答你的两个具体问题

def _cuda_device_supports_native_int4_mma(tensor: torch.Tensor) -> bool:
    if not tensor.is_cuda or _FORCE_INT4_INT8_FALLBACK:
        return False
    major, _minor = _cuda_device_capability(tensor.get_device())
    # The current ConvRot W4A4 kernel emits m16n8k64 s4 MMA, which is the
    # sm80+ integer MMA shape. Hopper is routed through the INT8 fallback for
    # better behavior with this implementation.
    return major == 8

>>> torch.cuda.get_device_name(0)
'NVIDIA GeForce RTX 5090'
>>> torch.cuda.get_device_capability(0)
(12, 0)

if linear_dtype == "int8" or not (
    _cuda_device_supports_native_int4_mma(x2d) or _should_use_turing_int4(x2d)
):
    qact_int8, x_scale = quantize_int8_rowwise_convrot64(x2d, convrot_groupsize)  # 激活值先转 int8
    ...
    out = _int4_weight_int8_act_gemm_dequant_chunked(   # 权重 int4 解包成 int8,再做 INT8×INT8 GEMM
        qact_int8, qweight, x_scale, wscales, bias, x.dtype)

为什么之前测的 NVFP4 也没省显存(补充细节,呼应你问的"有做过 nvfp4 的吗")

做过,而且这次翻源码把机制钉死了。我们自制的 minimax_h3_ref2va_pruned_nvfp4.safetensors 是 weight-only 配方(参照 lilcheaty/MiniMax-H3-NVFP4),检查了实际存的 key:

blocks.0.mlp.fc1.weight        U8   [28672, 2688]      # 打包的 fp4 数据
blocks.0.mlp.fc1.weight_scale  F8_E4M3 [28672, 336]     # block scale
blocks.0.mlp.fc1.weight_scale_2 F32  []                 # 二级 scale
# 没有 input_scale / pre_quant_scale —— 说明激活值量化的标定数据根本不存在

没有 input_scale,ComfyUI 就不可能对激活值做 fp4 量化,只能走"weight_only_quant"分支:

if weight_only_quant:
    weight, bias, offload_stream = cast_bias_weight(
        self, input=None, dtype=self.weight.dtype, device=input.device,
        bias_dtype=input.dtype, offloadable=True,
        compute_dtype=compute_dtype, want_requant=True,
    )
    weight = weight.to(dtype=input.dtype)   # <-- 整层权重现场转回 bf16
else:
    ...
x = self._forward(input, weight, bias)      # <-- 然后就是普通 bf16 矩阵乘,没有走 nvfp4 的 cuBLAS FP4 GEMM

comfy/ops.py:1340-1367

换句话说,我们的 NVFP4 checkpoint 从来没有机会用上 comfy_kitchen 里那条真正的 scaled_mm_nvfp4(cuBLAS 原生 FP4×FP4 GEMM,理论上确实能加速+省显存)——因为那条路径要求 输入激活值也必须先转换成 FP4,而我们的 checkpoint 没有做那一步所需的标定 scale。 所以我们测到的"nvfp4 更慢、还得配合 LoRA bypass"完全是 weight-only 反量化+bypass 双重开销叠加的结果, 不是 FP4 张量核心不行,而是我们这份 checkpoint 从格式上就没资格用它。

追问验证:LoRA "必须走 bypass" 到底是不是真的?

之前记录里写的是"nvfp4+LoRA 必须 bypass",但没验证过具体原因,只是经验结论。这次直接补测—— 同一 case、同一 seed,分别用 LoraLoaderModelOnly(普通合并)和 LoraLoaderBypassModelOnly 跑我们的 nvfp4 checkpoint,GPU 清零后对照:

结论:普通合并不会报错,但输出画面严重劣化。左边是普通合并,右边是 bypass,同一 seed、同一参考图:

左:普通合并——画面整体模糊、带一层网格状纹理噪声,人物边缘全程糊掉。右:bypass——清晰连贯,细节正常。

所以"必须 bypass"是真的,但原因不是"跑不通",而是普通合并会静默产出劣化画面,报错都不会报,很容易被忽略。 根源在于重新量化(set_weight → requantize_from_float)这一步:

@classmethod
def requantize_kwargs(cls, qtensor: QuantizedTensor) -> dict[str, Any]:
    """Return layout-specific kwargs for requantizing a dequantized tensor."""
    return {}   # <-- 基类默认实现,NVFP4Layout 没有覆写它

comfy_kitchen/tensor/base.py:119-121 (grep 确认 comfy_kitchen/tensor/nvfp4.py 里没有覆写此方法)

对比 W4A8 那边的量化实现,专门为"LoRA 合并进低比特权重"这件事做了 ALS 迭代精修 + 随机舍入, 代码注释原话是 "unbiased in expectation, so sub-quantum deltas (e.g. a small LoRA merged into a low-bit weight) survive instead of being rounded away"——W4A8 的量化流程是专门考虑过"合并进来的小 delta 不能被舍入抹掉"这件事的。 而 NVFP4 的重新量化完全走通用兜底逻辑,没有任何针对"重新量化时保留小 delta"的特殊处理。NVFP4 的 E2M1 格式本身只有 4 位表示精度,block scale 需要重新拟合,LoRA 合并进去的那部分改动大概率在重新定标时被直接舍入抹平或算错 scale—— 这才是普通合并画面劣化的真正原因,而不是"用不了"这么简单。

实测数据(同一 case,清空显存后严格对照)

1 张参考图 + 文本 prompt,768p,141帧(~5.9s),8-step turbo LoRA,普通合并(非 bypass),GPU 重启清零后测:

测试脚本:test_w4a8_lora_merge.py / test_int8_compare.py,均在 GPU0(systemctl --user restart 清零后)上跑,峰值显存用 2s 轮询 nvidia-smi 采样。

文件小了 37%,峰值显存反而多了约 2GB——文件大小只反映"静态存储",不反映"运行时要额外分配多少临时转换缓冲区"。 参考视频越长(我们真正在意的 15s/362帧场景),这个 gap 只会因为激活量化缓冲区随 token 数线性增长而进一步拉大,不会缩小。

追加实测:峰值显存到底出现在哪一刻?(逐秒时间线)

刚才的对照表只给了"峰值"这一个数字,不够看。这次给同一个 nvfp4 普通合并跑一遍, 每 1 秒采一次 nvidia-smi,同时实时读 ComfyUI 自己的加载日志,把两者按时间对上, 才看得出显存到底花在哪个阶段——鼠标悬停柱子可以看到具体秒数和显存值:

追问验证:轻量 case 的结论,换成真正的重负载(15s/362帧+参考视频)还成立吗?

上面那组时间线用的是 141 帧(~5.9s)、没有参考视频的轻量 case——用户敏锐地指出这可能不是生产 真正关心的场景。直接换成跟生产同规格的重负载重测一遍:768p、362帧(15s)、1张参考图 + 1个参考视频 (按生产设置压缩到 0.02MP),同样每秒采样 + 对齐加载日志:

追问验证②:参考视频不压缩,保留原生 480×704,会撑爆吗?

直接测(生产 int8_convrot 格式,768p/362帧/15s,1图 + 参考视频保留原生 480×704,不经过任何压缩节点):

结论:原生分辨率不会撞显存墙,但会让参考视频的 token 负担直接体现在时间上——不压缩不代表跑不动, 只是从"跑不完(OOM)"变成"跑得慢"。这跟之前算过的 token 成本模型是一致的:只要没有超过总显存预算, 更多 token 换来的是更长的采样时间,不是失败。

顺带修正一下"合并为什么撑爆"这个说法

之前把这个尖峰主要归因于"NVFP4 重新量化需要额外的 scratch buffer"。拿这次 int8 + 原生视频的实测数字核对了一下, 发现真正占大头的原因更简单——不是量化数学本身要很多显存,是模型切换的交接窗口期:

nvfp4 那组简单相加(28.9GB)跟实测峰值(27.4~30.2GB)量级完全对得上。int8 那组更能说明问题:三者相加(36.9GB) 已经超过了显卡总容量(32.1GB),但实测峰值只有 30.95GB——说明 ComfyUI 的 DynamicVRAM 管理器并不是傻等三个东西 完全常驻,而是新模型往里搬的同时,旧的 CLIP 在被逐步换出去,只是这个换出过程没快到完全避免瞬间的部分重叠, 这个重叠窗口就是尖峰的真正来源——不是"量化计算"这个动作本身要额外显存,是"新旧模型交接没完全错开"。

结论 / 建议