核查：H3 的 ComfyUI「今天掉了 10G 显存 + 速度瞬间提很多」——是本体适配还是节点更新？

核查人：DSH（本机 192.168.31.76）
核查时间：2026-09-24 13:2x–14:0x CST
核查对象：网友说法「H3 的 CUI 是适配更新了还是节点更新了？今天突然掉了 10G 左右的显存使用量，速度瞬间提了很多」
核查环境：GPU 机 192.168.31.31（RTX 5060 Ti 16GB, sm_120）、ComfyUI v0.37.0 / HEAD c194dd00（2026-09-21 04:57 UTC 拉取）

一、结论（直接回答网友的问题）

问题	结论	依据
是 ComfyUI 本体适配，还是节点更新？	"能让 H3 显存/速度跳一档"的能力全部来自 ComfyUI 本体（内核）适配，而且都是 2026-09-05 ~ 09-20 合并的，不是这两天的自定义节点更新	见第二节提交时间线
「今天」有新适配吗？	没有。 09-21 ~ 09-24 上游没有任何 H3 显存/速度相关提交；这三天 H3 只有两个补丁：VAE 瓦片拼接、rms_rope 崩溃修复	见第二节表
「掉了 10G 显存」能由注意力机制解释吗？	不能。本机实测 comfy-kitchen INT8 注意力显存不降反升（8K token：稠密 86 MiB → INT8 617 MiB）。10GB 级别的下降只可能来自权重换成更小的量化档或 ComfyUI 缓存被释放	见第三、四节实测
「速度瞬间提很多」能解释吗？	能，且量级吻合。 H3 5s@1MP ≈ 2~3 万 token，正处于本机实测的交叉点之后：32K token 时稠密 479.8 ms → INT8 244.6 ms（1.96×）；社区 SPEED V2 渐进分辨率节点自报 1.23–2.41×	见第四节

一句话：如果网友没动工作流却"变快了"，那是内核适配（Comfy 编译器 / 核心稀疏注意力 / comfy-kitchen INT8）；如果显存真的少了 10G，那几乎只能是换了更小的量化权重（本机两档 H3 权重相差 8.43 GB）或者缓存被释放（本机实测空闲常驻 13.78 GB，一条 /free 就掉到 310 MiB）——与"注意力节点更新"无关。

二、上游证据：09-20 → 09-24 全部提交（Comfy-Org/ComfyUI master）

2026-09-24 03:01  1568e6cf  Lower memory usage and .comfy_attention support for lumina family models. (#16515)
2026-09-24 01:57  3b4c0b0e  feat: ming-image support (#16482)
2026-09-23 03:16  b5cc8830  Port some optimizations to flux model family. (#16488)
2026-09-23 01:39  912fca4f  Fix MiniMax-H3 VAE rms_rope crash on offloaded qk_norm_scale (#16485)   ← H3，仅修崩溃
2026-09-22 16:27  95539f56  support union cn 2.0 (#16471)
2026-09-22 06:22  b33e2b55  workflow templates v0.11.68 (#16466)
2026-09-22 01:57  e638023d  Fast disk detection to all model loaders. (#16425)
2026-09-22 01:56  fc584aaa  Blend H3 VAE tiles against composited neighbours (#16436)              ← H3，仅 VAE 拼接画质
2026-09-22 01:49  d1584209  Cuda graphs + memory compiler on ace step 1.5 (#16461)
2026-09-21 05:58  b0f4b7b2  JsonExtractString ...
2026-09-20 17:31  c194dd00  Allow model files to contain which attention should be used for each block. (#16419)  ← 关键（本机 HEAD）
2026-09-20 15:27  73c9bad4  ComfyUI v0.37.0
2026-09-20 02:50  c8ed2c8c  Lower wan peak vram when using comfy kitchen attention. (#16418)

结论：09-21 之后没有一条 H3 显存/速度提交。H3 最近真正碰显存的是 09-15（f14bbe28 Lower minimax VAE usage by a bit、b2e31e89 MiniMax-H3 VAE optimizations）。

真正能造成"跳一档"的内核改动，全都早于"今天"：

日期	提交	内容	作用侧
09-05	#15861	Comfy 编译器（comfy-aimdo 内存编译器 + CUDA graphs），Wiki 明说让 H3 720p/158 帧从"停滞"变为 ~43 s/step，并让"物理显存峰值=逻辑分配峰值，不再让已释放分配留在缓存"	本体
09-06	#16072	核心「Block Sparse Attention」节点（Sol-Attn / top-k SLA / VSA 三后端，H3 首个转换）	本体（核心节点）
09-07	#16148	长时稀疏分配时暂停 Comfy 编译器（修早期 OOM/崩溃）	本体
09-08	#16154	统一模型注意力节点（`Model Attention Backend`，可选 `comfy kitchen attention` = INT8）	本体（核心节点）
09-20	#16419	允许模型文件逐块声明用哪种注意力（本机 HEAD）	本体

三、机制拆解：哪些能解释"掉 10G"，哪些只能解释"变快"

机制 A：模型文件里的 `attention.config` 张量（本体适配，本机未生效）

本机 comfy/ldm/modules/attention.py:76 的 ComfyAttention：

metadata = state_dict.pop(prefix + "config", None)      # 从权重里取 "….comfy_attention.config"
if metadata is not None:
    config = json.loads(metadata.numpy().tobytes())
    method = config.get("attention")                     # 支持 "comfy_kitchen_int8"
    if method == "comfy_kitchen_int8" and comfy_kitchen.int8_attention_is_available(...):
        self.function = attention_comfy_kitchen_int8     # 自动切 INT8 注意力

H3 的 Attention.forward() 已经把 preferred_attention=self.comfy_attention 传下去（comfy/ldm/minimax/model.py:161,200）——这是 #16419（09-20）本体适配。
但全库递归扫描 84 个 safetensors，带该 config 张量的是 0 个（含 6 个 H3 权重与 MiniMaxH3/ 子目录 3 个）。
⇒ 机制存在、但要靠模型重导出才生效；本机（以及任何用老模型的网友）不会自动变。

机制 B：comfy-kitchen INT8 注意力 / 稀疏注意力（本体，只提速，不省显存）

见第四节实测：INT8 显存高于稠密。所以"掉 10G"不能归因于注意力后端。

机制 C：换更小的量化权重档（最可能解释"掉 10G"）

本机现成两档 H3 权重实测文件大小：

权重	大小	差值
`minimax_h3_ref2va_pruned_int8_convrot.safetensors`	20.97 GB	—
`minimax_h3_ref2va_pruned_w4a8_mixed.safetensors`	12.54 GB	−8.43 GB

fl2va 档同为 20.97 vs 12.54 GB。
这些格式（int8_convrot / w4a8）由内核 comfy-kitchen 直接支持（本机启动日志列出 cuda 后端能力：w4a8_int8_linear、int8_linear、quantize_int8_convrot_weight、sol_attn 等），不需要第三方节点。
20.97 → 12.54 GB 的切换，在 nvidia-smi 上就是"显存掉了 8~10G"，同时因为 INT8/低比特张量核心，速度也同步变快——与网友描述的两个症状同时出现完全吻合。

机制 D：ComfyUI 缓存/暂存行为（也能解释"显存突然掉 10G"，而且是"假"掉）

本机实测（空闲、队列为空）：

释放前：nvidia-smi memory.used = 13782 MiB   （进程 5056 占 13756 MiB）
POST /free {"unload_models":true,"free_memory":true}  →  http 200
释放后：nvidia-smi memory.used =    310 MiB

也就是说空闲时"占着 13.78 GB"几乎全是暂存的权重（日志：Model QwenImage21TEModel_ prepared for dynamic VRAM loading. 8916MB Staged.）。
版本升级或启动参数变化（如 --cache-lru、--fast-disk、动态 VRAM 策略）会让这个数字突然掉十几 G，但生成速度未必变化；反过来 Comfy 编译器/aimdo（09-05）宣称的正是"不再让已释放的分配留在缓存里"→ 视觉上就是"显存占用掉了"，同时步进更快。

机制 E：社区节点「MiniMax H3 SPEED V2」（节点侧，渐进分辨率）

包：StanLukuvka/ComfyUI-MiniMax-H3-SPEED（custom_nodes），把早期去噪步骤放在低分辨率网格上跑，再逐步放大。
作者自报（RTX 5080，960×544/10.125s）：全分辨率基线 571.49s → 4 阶段 delta 0.05 时 237.57s（2.41×）。
早期步骤网格更小 ⇒ 显存峰值也确实会下降，但主要是 latent 侧，量级达不到 10G（权重才是大头）。
这属于"节点更新"，且 Wiki 明确说 V2 的采样器组合尚无独立复现。

四、本机实测：H3 真实注意力维度的稠密 vs INT8 A/B

H3 注意力维度从权重头推得：blocks.0.attn.qkv_proj.weight [21504, 2688]、out_proj [5376, 3584] ⇒ hidden 3584 / 56 heads / head_dim 96。 GPU：RTX 5060 Ti，sm_120；comfy-kitchen 0.2.35；int8_attention_is_available=True、sol_attn_is_available=True。

序列长度 S	稠密 PyTorch SDPA 显存	INT8 显存	稠密耗时	INT8 耗时	加速
8,192	86 MiB	617 MiB	33.4 ms	42.3 ms	0.79×
16,384	172 MiB	1,233 MiB	119.8 ms	62.0 ms	1.93×
32,768	343 MiB	2,466 MiB	479.8 ms	244.6 ms	1.96×
65,536	未测	4,932 MiB	—	942.7 ms	—
98,304	未测	7,398 MiB	—	1,986.0 ms	—

要点：

INT8 注意力更费显存（S=32K 时 +2.1 GB），因为它要物化 int8 副本/中间张量；它不是省显存的手段。
INT8 的收益全在速度：交叉点约在 12K token，之后约 2×；且随 S 线性增长（稠密是 O(S²) 计算）。
稠密路径显存极小（flash 类内核不物化 S×S），⇒ H3 的显存峰值由权重主导，这反过来印证机制 C。
H3 的真实 token 量级：VAE 空间 /16、时间 /4，DiT 再 patchify (1,2,2)，latent 帧率 frames_per_token=(1,4,4,4,4)。5s、约 1 MP（如 768×1344 / 1280×720）落在 2~3 万 token 量级 ⇒ 正好是上表 INT8 已有 2× 收益的区间，与"速度瞬间提很多"量级相符。

五、本机环境快照（供对照）

项	值
ComfyUI 版本	v0.37.0，HEAD `c194dd00`，拉取于 2026-09-21 04:57 UTC（`git reflog`）
上游最新（核查时）	09-24 `1568e6cf`；tags 已有 v0.37.1 / v0.37.2
comfy-kitchen	0.2.35（cuda 后端可用，含 `sol_attn`、`w4a8_int8_linear`、`int8_linear`）
comfy-aimdo	0.5.5（日志：`comfy-aimdo inited for GPU: NVIDIA GeForce RTX 5060 Ti`）
启动参数	`--lowvram --force-fp16 --reserve-vram 1.0 --fast-disk --cache-lru 20`
稀疏/注意力文件	`comfy_extras/nodes_sparse_attention.py` 存在；`ModelAttentionBackend` 节点存在
官方 H3 Director 工作流	12 个 JSON，均不含注意力补丁节点（仅 `MotionContext-fl2va-ref2va.json` 引用未安装的 `H3SLAAttention`）
带 `attention.config` 的模型	0 / 84

六、给网友的 5 分钟自查清单（判断"适配"还是"节点"）

cd ComfyUI && git log -1 --date=iso → 看拉取日期。若在 09-20 之前，就不可能有逐块注意力（#16419）。
看模型文件名：...int8_convrot（≈21 GB）还是 ...w4a8_mixed（≈12.5 GB）。显存"掉 10G"基本就是这一项。→ 用 ls -l models/diffusion_models/。
工作流里搜有没有 Model Attention Backend 或 Block Sparse Attention 节点（本体核心节点，选了 comfy kitchen attention 就会提速 ~2×）。
有没有装社区包：ComfyUI-MiniMax-H3-SPEED（渐进分辨率，节点侧提速）、ComfyUI-SolAttn*、ComfyUI-KJNodes 等。→ ls custom_nodes/。
显存是"生成时峰值"掉了，还是"空闲占用"掉了？后者先 POST /free 试一次——本机实测能一次掉 13.5 GB，属于缓存而非真实占用。

七、本次核查的副作用（已确认无碍）

代理修复：核查开始时本机 v2ray 全 timeout（SS 节点 IP 轮换）。已按 ~/Downloads/v2ray-setup/refresh-sub.sh 刷新订阅 → 节点更新为 176.122.134.43 / 176.122.191.251 → 验证 Google 200、下载 4139 KB/s。
ComfyUI 缓存释放：为腾出显存做长序列基准，对空闲的 ComfyUI（队列为空）调用了一次 POST /free。这只清缓存，不影响运行；下次出图会自动重新加载模型（首次略慢）。
未改动任何模型文件、工作流配置或 ComfyUI 代码。

附：本次核查使用的关键命令

# 上游提交（走 v2ray 代理）
curl -s -x http://127.0.0.1:10809 \
  "https://api.github.com/repos/Comfy-Org/ComfyUI/commits?since=2026-09-20T00:00:00Z&per_page=100"

# H3 注意力维度（从 safetensors 头）
#   blocks.0.attn.qkv_proj.weight [21504,2688] / out_proj [5376,3584] -> 56 heads x 96

# 全库扫描 attention.config
python3 -c "..."   # models/**/*.safetensors 84 个，命中 0

# 显存 A/B（GPU 机 venv）
cd /home/zyw/ComfyUI && venv/bin/python /tmp/h3_attn_bench3.py

# 空闲缓存实测
curl -s --noproxy '*' -X POST http://127.0.0.1:8189/free \
  -H 'Content-Type: application/json' -d '{"unload_models": true, "free_memory": true}'

2026-09-24-核查-H3掉10G显存与突然提速-是适配还是节点.md