V100 32G 跑 COMFYUI QWEN KREA2 H3 測試心得

pofu lin 0

V100 32G ＋ ComfyUI：三大生成模組實戰全紀錄

設定過程・踩坑・篩選・成品效率・生成時間

機器環境：Ubuntu・Python 3.14.9・torch 2.14.1+cu126・ComfyUI 0.44・comfy-kitchen 0.2.41
顯示卡：NVIDIA V100 32GB（sm_70 Volta）為主卡，GTX 1660 SUPER 6G 備卡
成品：三組主力（Qwen-Image-2.1-Turbo 圖片／Krea-2 Turbo 圖片／MiniMax-H3 影片＋音訊）全數測通，外加一組備用 uncensored（Noct-Q V4）。模型總計 100G，每組只留最快/最佳版。

〇、成品總覽：V100 32G 三大模組「一張表看懂最佳效率設定」

主題：V100 32G 上這三組（＋1 備用）怎麼設定效率最高。
先講結論：三組全部跑 --fp16-unet FP16 運算→ 圖片組十幾秒一張、影片組 49 幀 80 秒；H3 那組檔案 34G 超 32G 顯存，靠 ComfyUI Dynamic VRAM 自動串流不爆卡。下表是各組定案設定＋實測數字，照抄即可。

① Qwen-Image-2.1-Turbo（圖）

項目	內容
出成品	靜態圖 1024×1024
主模型（DiT）	`Qwen-Image-2.1-Turbo-BF16.gguf` 13.25G
文字編碼器	`qwen3vl_8b_int8_convrot` 8.71G
LoRA	—
VAE	`qwen_image_2.1_vae_bf16` 0.63G
步數／sampler	8 步・euler・cfg 1
伺服器旗標	`--fp16-unet --fp16-vae`
生成時間（熱機）	11.3s／張
冷機（含載入）	23s
顯存需求	32G 放得下
disk 佔用	22.6G
定位	最快出圖（要極速選這組）

② Krea-2 Turbo（圖）

項目	內容
出成品	靜態圖 1024×1024
主模型（DiT）	`krea2_turbo_bf16.safetensors` 24.48G
文字編碼器	`qwen3vl_4b_int8_convrot` 4.52G
LoRA	—
VAE	`qwen_image_vae` 0.24G
步數／sampler	8 步・euler・cfg 1
伺服器旗標	同 ①
生成時間（熱機）	16s／張 ✓ 達 <20s 目標
冷機（含載入）	24s
顯存需求	32G 放得下
disk 佔用	29.2G
定位	最快出圖＋風格多變（16s 達標，主力）

③ MiniMax-H3（影片＋音訊）

項目	內容
出成品	影片 768×448・49 幀（約 2.3s）＋ AAC 音訊
主模型（DiT）	`minimax_h3_fl2va_pruned_int8_convrot.safetensors` 19.53G
文字編碼器	`qwen3vl_32b_minimax_h3_nvfp4_awq` 14.61G
LoRA	`minimax_h3_fl2v_turbo_4step_v1.0_768p_comfyui_bf16`（官方）1.82G
VAE	video int8 2.62G＋audio fp32 0.56G＋sol int8 1.85G
步數／sampler	4 步（turbo LoRA 內建）
伺服器旗標	`--fp16-unet --fp16-vae`（＋Dynamic VRAM 自動啟用）
生成時間（熱機）	≈80s／49 幀（全長 124 幀推算 ≈3 分鐘）
冷機（含載入）	≈95s（首次含模型載入）
顯存需求	檔案 41G＞32G → 串流，不 OOM
disk 佔用	41.0G
定位	唯一影片＋音訊組

④ Noct-Q V4（備用・uncensored）

項目	內容
出成品	靜態圖 1024×1536（NSFW 不拒）
主模型（DiT）	`NoctQ_V4_int8_convrot.safetensors` 6.76G
文字編碼器	共用 ① 的 8b int8
LoRA	—
VAE	共用 ①
步數／sampler	25 步・euler・cfg 1（快）／cfg 3（品質）
伺服器旗標	同 ①
生成時間（熱機）	125s（cfg1）／≈250s（cfg3）
冷機（含載入）	≈250s
顯存需求	32G 放得下
disk 佔用	＋6.8G（共用件不算新增）
定位	備用：uncensored 寫實（慢，品質 9.5/10）

一眼看完版：要出圖→ 用 ①（11.3s）或 ②（16s），都走 FP16；要出影片＋音訊→ 用 ③（80s/49 幀，Dynamic VRAM 救 32G 顯存）；要不拒內容→ ④ 備用（代價：慢 10 倍）。三組主力 disk 總計 93G＋備用 6.8G。

【上傳圖片1：compare_lineup.jpg（四大組成品一覽）】

圖說：四大組成品 lineup，每格標了生成秒數。上左＝① Qwen 小貓熊（11.3s）；上右＝② Krea-2 雨夜街景（16s）；下左＝③ H3 海邊夕陽影片截幀（80s/49 幀）；下右＝④ Noct-Q 風暴燈塔（125s）。
後文講怎麼走到這些數字：硬體限制（一）→ 設定（二）→ 踩坑（三）→ 篩選（四）→ 效率表（五）。

一、硬體殘酷事實：V100 的 GEMM 階梯（先懂這個才懂後面決策）

V100 是 Volta（sm_70）：沒有 BF16 tensor cores、沒有 FP8/NVFP4、裝不了 FlashAttention-2（要 sm_80+）。
我用 4096³ matmul 實測（torch 2.14.1+cu126、50 次熱機平均）：

GEMM 路徑	時間	有效算力	相對速度
FP16 tensor cores	1.63ms	≈84.4 TFLOPS	1×（最快）
INT8 DP4A（torch._int_mm）	2.76ms	≈99.7 TOPS	1.7× 慢
BF16（fp32 SIMT 路徑）	13.9ms	≈9.9 TFLOPS	8.5× 慢（地雷）

這張表決定後面所有決策：能走 FP16 就一律導向 FP16。

二、設定過程（依序 5 步）

torch 版本命門：一定要 cu126 build。cu132 砍掉 CC 7.0 kernel，V100 會直接沒戲。
ComfyUI-GGUF 補丁：官方 converter 對 Qwen-Image-2.1 系模型偵測不完整，補 convert.py 的 ModelQwenImage 偵測後 GGUF denoiser 才能正確載入。
下載通道：HuggingFace 的 xet CDN 在本機被限流到 ~4KB/s（下 24G 要一年）。解法＝改 ModelScope 鏡像（快 CDN，12 併流 ≈19-20MB/s，24G 約 20 分鐘）；HF 傳統 LFS CDN 其實可直連多併流。自寫 msdl.sh（curl range 多併流＋resume）——它的坑見「坑 4」。

伺服器腳本 run.sh：

main.py --listen 0.0.0.0 --port 8188 \
  --output-directory ~/output \
  --temp-directory ~/.hermes/cache/scratch/comfy_tmp \
  --fp16-unet --fp16-vae

--fp16-unet 是全部加速的鑰匙（見坑 2）。

Dynamic VRAM：H3 組 DiT 19.5G＋編碼器 14.6G＋VAE ≈ 34G，超過 32G 顯存。ComfyUI 自動串流出/入 VRAM，不會 OOM，只是慢（可接受）。

三、踩坑日記（最值錢的部分）

坑 1：把「生成慢」誤診成「下載慢」

一開始覺得第一組慢在下載，拆開測：冷機 51.8s／熱機 44.2s，差只有 ~8s——成本全在 sampling。接著才去測 GEMM 算力，找到真正病根（下一條）。

坑 2：ComfyUI 會「靜默」用 BF16 慢路徑（44s → 11.3s 的關鍵）

Qwen-Image-2.1-Turbo 的模型 registry 只宣告 supported_inference_dtypes=[bf16, fp32] → ComfyUI 預設跑 BF16 GEMM＝9.9 TFLOPS 慢路徑，吃 8.5 倍懲罰。

修法：server 加 --fp16-unet --fp16-vae（檔案還是 BF16/GGUF，儲存格式 ≠ 運算格式，載入時轉 FP16 計算）。
成果：Qwen 1024²×8 步 44s → 11.3s（3.9 倍），出圖無精度偽影。

坑 3：舊伺服器佔 port，整輪測試全白跑

重啟帶 --fp16-unet 的 server 時 8188 被舊 pid 佔著 → 新 process 直接掛掉，測試全跑在舊（BF16）server 上，數字全無效。
鐵律：重啟前 ss -ltnp | grep 8188 找真實佔用者殺掉、確認新 pid 上線，才准開始測。

坑 4：自寫多併流下載器的兩個死穴（腐壞檔案會出「純噪點圖」）

(a) curl 的 -r（range）和 -C -（resume）互斥 → 一律 0 bytes，要手動記錄 offset 做 resume。
(b) 組裝用了 cat part_*——shell 字典序在 10 個以上 segment 時把 part_10 排在 part_2 前面 → 檔案大小、safetensors header 全對，內容卻亂序。

這坑害我最慘：Krea-2 bf16（24G、12 併流）組裝腐壞 → 連測 4 次出全灰噪點圖，一度誤判「Krea-2 在 FP16 數值上崩掉、FP16 壞圖」。重下＋抽 5 個 range 對 CDN 逐位元驗證後，FP16 一次通過。

【上傳圖片2：compare_corrupt_vs_good.jpg（腐壞檔案 vs 正常檔案）】

圖說：左＝下載檔案腐壞時生成的「純噪點圖」（當時實際產生的 6 張已清掉，此為模擬示意：大小與 header 都正常、內容亂序的檔案，模型照跑、出圖全是雪花噪點，完全不報錯）；右＝修好組裝、抽 range 對 CDN 驗證位元後重下的檔案，同 prompt 出正常狐狸照。
教訓：出純噪點圖，第一反應是「檔案腐壞」，不是「這個 dtype 跑不動」——先抽 range 對源頭驗位元，再下結論。

坑 5：第三方 GGUF 格式不保證相容

找 uncensored 編碼器時下了 AtomicChat（stable-diffusion.cpp 生態）的 Qwen-Image-2.1-Turbo-Uncensored-BF16.gguf（15.4G）——跑起來報 normalized_shape=[4096] but got [1,512,12288]：context 維度跟 ComfyUI-GGUF 介面對不上。白下 15.4G，刪。
改選 ComfyUI 原生的 Noct-Q V4（int8_convrot safetensors，核心節點即可跑、0 自訂節點）。

坑 6：測速會被 ComfyUI 快取騙

相同 prompt＋seed 會命中 cache（顯示「0.00s」）。測速一定換 prompt；冷機（含 compile）與熱機要分開記。

坑 7：GEMM 排名 ≠ 端到端排名（Krea-2 的反轉）

理論上 INT8 DP4A（99.7 TOPS）該比 FP16（84.4 TFLOPS）快……但 Krea-2 實測 int8_convrot 28s／bf16 檔＋FP16 運算 16s——int8 反而慢（dequant 開銷＋非 GEMM 部分）。

【上傳圖片3：compare_krea2_int8_vs_fp16.jpg（Krea-2 INT8 vs FP16）】

圖說：同一 prompt、同一 seed 的狐狸照——左＝INT8 convrot 模型（28s），右＝BF16 檔＋FP16 運算（16s）。兩張構圖幾乎相同（驗證 seed 一致）；右圖毛髮邊緣與背景銳利度明顯更好，而且快 12 秒。GEMM 算力排名（INT8 99.7 TOPS > FP16 84.4 TFLOPS）完全沒 predicting 到最終結果——永遠用整條 pipeline 的實測秒數做取捨。
依此定案：Krea-2 刪 int8（13.5G），留 krea2_turbo_bf16。

坑 8：LoRA 品質 A/B（H3 影片）

Pika 的 H3 4-step LoRA vs Comfy-Org 官方 minimax_h3_fl2v_turbo_4step_v1.0_768p：同 prompt 同 seed 各跑 49 幀，速度相同（約 80s），品質差出來：

【上傳圖片4：compare_h3_pika_vs_official.jpg（H3 Pika vs 官方 LoRA）】

圖說：同一影片（海邊夕陽）抽 frame 5／45 對照。左列 Pika FL2VA LoRA：浪面偏平滑、泡沫感弱、frame 45 濕沙反射邊緣糊；右列官方 4-step 768p LoRA：浪尖泡沫氣泡結構清楚、沙粒水紋銳利。同速取優 → 官方勝，Pika LoRA（3.7G）刪除。

其他小坑

snap 版 curl 一直噴 sandbox 警告（無傷大雅，curl.snap-acked 可關）；snap curl 寫不了 /tmp 與 /home 隱藏目錄，驗證位元改用 python urllib。
長命 process 別用 nohup 包，用追蹤型 background process。
hf CLI 新版沒有 --local-dir-use-symlinks-false 參數。

四、篩選過程（每組怎麼選到最快版）

組	候選	實測（1024² 除非註記）	去留
1 Qwen-2.1-Turbo	BF16 GGUF＋fp16（11.3s）／BF16 直跑（44s）／int8 GGUF（19-25s）	FP16 勝	留 BF16 GGUF＋`--fp16-unet`
2 Krea-2	int8_convrot（28s）／bf16 檔＋fp16（16s）／fp8_scaled（V100 無 FP8 core，不划算）	bf16 勝	留 `krea2_turbo_bf16`，刪 int8（13.5G）
3 H3	DiT：pruned int8 convrot（最快）；TE：qwen3vl_32b nvfp4（one-shot 可忍 fallback）；LoRA：官方 4step 768p（勝 Pika，坑 8）；VAE：video int8＋audio fp32	官方 LoRA 勝	刪 Pika LoRA（3.7G）
4 Noct-Q V4（備用 uncensored）	HF 搜 "qwen-image uncensored"：Noct-Q V4（33 萬下載、ComfyUI 原生）＞ AtomicChat GGUF（不相容，坑 5）	Noct-Q 勝	留 V4 int8（6.8G）

每組定案後執行「只留最快版」：models 從 105G 清到 100G 內，每組一組檔案、一條 workflow。

五、成品效率與生成時間（正式 FP16 伺服器上的數字）

#	模組（類型）	檔案（disk 佔用）	規格	生成時間
1	Qwen-Image-2.1-Turbo（圖）	DiT 13.25G＋TE 8.71G＋VAE 0.63G＝22.6G	1024²、8 步、euler、cfg 1	11.3s 熱機（冷機 23s）
2	Krea-2 Turbo（圖）	DiT 24.48G＋TE 4.52G＋VAE 0.24G＝29.2G	1024²、8 步、euler、cfg 1	16s 熱機（冷機 24s）✓ 達 <20s 目標
3	MiniMax-H3（影片＋音訊）	DiT 19.53G＋TE 14.61G＋官方 LoRA 1.82G＋3 個 VAE 5.03G＝41.0G	768×448、49 幀、4 步 turbo LoRA	≈80s／49 幀（h264＋AAC 真音訊）；全長 124 幀（~5s 影片）推算 ≈3 分鐘
4	Noct-Q V4（uncensored 圖，備用）	DiT 6.76G（TE/VAE 跟第 1 組共用）＝＋6.8G	1024×1536、25 步、euler	cfg1 快版 125s／cfg3 品質版 ≈250s

影片輸出驗證（第 3 組 H3）

【上傳圖片5：compare_h3_motion.jpg（H3 影片動作條）】

圖說：H3 官方 LoRA 輸出影片抽 3 幀——f5 浪頭拍岸（白色泡沫捲起）→ f25 浪退潮（夕陽倒影清晰落在濕沙）→ f45 新波湧進（泡沫重新覆蓋沙灘）。浪的進退位移清楚可見＝證明是真動態影片（非靜圖循環）；音訊軌 AAC 量測 peak −23.9dB、平均 −37.7dB，非靜音。

補充

第 3 組 41G 檔案放 32G 顯存＝Dynamic VRAM 串流，慢但不爆；H3 的 bottleneck 在影片 VAE 解碼＋4 步 sampling，不是 GEMM。
第 4 組 int8 是「便宜」不是「快」——它本是 25 步完整版 Qwen-Image-2.1（非 turbo），速度不該拿前兩組比。
所有測試輸出都在 ~/output/（每組 1-3 張代表樣本＋影片抽幀），乾淨可驗。

六、結論（給其他 V100 使用者的三句話）

V100 跑現世代模型仍可用：--fp16-unet 一招讓 turbo 級圖片模型做到 11-16s/張（1024²）、影片 49 幀 80s——Volta 不是不能玩，是不能用錯 dtype。
檔案的儲存格式與運算格式是兩回事：BF16/int8 檔都可以「存」，但 V100 上「算」要盡量導向 FP16 tensor cores；同時永遠用整條 pipeline 的實測秒數做最終取捨（GEMM 排名會騙你，見坑 7）。
多併流下載要驗位元：出「全噪點圖」第一反應是檔案腐壞（header 與大小全對都會發生，見坑 4），不是「這個 dtype 跑不動」——先抽 range 對 CDN 驗，再下結論。

模型來源：Comfy-Org（ModelScope 鏡像下載最快）、Noctaluna Noct-Q（HF）。

terry

以后发帖之后自己看一看，不要贴一大段话，有显示异常也不处理，我帮你处理了下。

pofu lin 0

第一次發表謝謝指教

抡锤者