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

機器環境：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（圖）

② Krea-2 Turbo（圖）

③ MiniMax-H3（影片＋音訊）

④ Noct-Q V4（備用・uncensored）

一眼看完版：要出圖→ 用 ①（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 次熱機平均）：

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

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

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

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

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

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

影片輸出驗證（第 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 使用者的三句話）

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

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