[Benchmark] 2080 Ti 也吃得下 Sol-H3 兩段式：1344×768 有聲影片 165 秒

一張 2018 年的改裝 2080 Ti 22G 跑出來的：1344×768、121 幀、含音訊。草稿由 MiniMax-H3 在 672×384 畫，LTX-2.5 用三步精修拉到兩倍——鬍鬚、逆光下的毛尖、背景的浮塵都是精修那三步補上的。牠說的是「這張卡比我還老，但它跑得動。」

前言

同一份食譜給三個廚房，不會得到三份一樣的菜。爐子的火力不同、鍋子的大小不同，有些步驟得換順序，有些材料得換。難的不是知道要換，是有些替換做錯了不會冒煙——菜端出來擺盤完美，吃下去才發現是生的。

這條產線 NVIDIA 自己叫 MiniMax H3 Super Acceleration：MiniMax-H3 用 4 步畫草稿，LTX-2.5 再用 3 步把它精修到目標解析度。四個很容易混在一起的名字先分清楚——方法本身叫 H3 Super Acceleration、Sol Engine 是發表它的加速框架、Sol-H3 是同一個方法在 DGX Spark 上的官方版本、Sol-Attn 是 Stage 2 那顆稀疏注意力 kernel。

NVIDIA 自己在一台 DGX Spark 上跑這個組態是 56 秒。GB200 那條線的 6.852 秒別拿來並排——那個數字是兩段分開量測後相加、而且明寫不含模型載入與暖機，跟本文「送出到拿到檔案」的整條時間不是同一種量法。

上一篇在 RTX 5090 上把方法拆開講過，也是那輪把精修的 sigma 從官方的 0.909375, 0.725, 0.421875, 0 校到 0.78, 0.643, 0.546, 0。

這篇搬到另一個極端：一張 2018 年的改裝 2080 Ti 22G。系列 #11 已經證明這張卡跑得動 MiniMax-H3，但那是單段、864×480。這次要的是完整的兩段式，而且輸出拉到 1344×768。

⚠️ 一個很容易搞混的點：這裡的組態就是 NVIDIA 的 Spark 版——草稿 672×384、124 幀、4 步，精修 3 步，輸出 1344×768 的 5 秒 24fps，一個參數都沒動。你在 GB200 那頁看到的 896×512 是另一條線的草稿尺寸。下面那組 sigma 是對 672×384 校準的，換草稿尺寸那個點就會跑掉。

165 秒，而且中間踩了六個坑

先給結果。同一個 workflow、同一組 prompt，1344×768、121 幀、24 fps、含音訊：

下面會一直出現「冷機」跟「熱機」，跟溫度無關：冷機＝這一發要從硬碟把模型讀進來；熱機＝上一發剛跑完、模型還在記憶體裡。

	秒數
ComfyUI 剛重啟後的第一發	190（兩發都是 190.1）
冷機	178
熱機（換 seed、不清模型）	165（三發中位，極差 1.08 秒）
兩者之差＝載入成本	13

📦 跑出這些數字的那張圖已經放上 HuggingFace，可以直接下載。 不是示意、不是簡化版，就是這台機器實際在跑的 32 節點 workflow：

hf download coolthor/H3-Super-Acceleration-Turing --local-dir . \
  workflows/minimax-h3-ltx-two-stage-turing-sm75.json TURING.md

同一個 repo 還有啟動 adapter、轉檔腳本，以及那顆 13.2 GiB 的 heretic 文字編碼器。 完整清單與逐步操作在 TURING.md。

冷熱之差 13 秒就是把 54 GiB 權重讀進來的成本；熱機那 165 秒全部是算力。所以如果你在連續調參數，不要每次都清模型——那 13 秒是免費省下來的。

第一列要單獨講，因為那是你照這篇裝完之後會看到的第一個數字。ComfyUI 一重啟，Triton 的 kernel 快取就沒了，SageAttention 那六支 kernel 要重編一次，成本約 12 秒。這筆只付一次：同一個 ComfyUI 行程裡，之後清掉模型再跑就是 178 秒。

對照組在文章後半，但先講一個最重要的：把 SageAttention 關掉，冷機變成 213 秒，而熱機直接 OOM。它在這張卡上不是可有可無的加速，而是這條管線能不能連跑第二發的前提。

怎麼設定

整套可執行的東西在 HuggingFace 這個 repo 的 TURING.md——32 節點的 workflow、啟動 adapter、轉檔腳本、那顆 13.2 GiB 的文字編碼器，照著做就會動。

# 一行看完要拿哪些東西
hf download coolthor/H3-Super-Acceleration-Turing --local-dir . TURING.md && cat TURING.md

下面這六節不重複那份文件的步驟，講的是為什麼每一處非改不可——因為其中兩處失敗時完全沒有聲音，你照抄 DGX Spark（Blackwell 架構）那張圖不會看到任何錯誤訊息，只會拿到壞掉的東西。（第三處會印錯誤，但它印完就自己降級繼續跑，很容易當成雜訊滑過去。）

一、先拿到權重的存取權

兩個 repo 都是 gated，沒先處理下面的 hf download 會回 401。訊息本身講得很清楚（Access to model ... is restricted. You must have access to it and be authenticated），只是如果你是照著別人的腳本跑，很容易把它讀成網路問題。瀏覽器開 coolthor/H3-Super-Acceleration-Turing 和 Lightricks/LTX-2.5 各按一次同意，然後 hf auth login。

⚠️ H3 那個 repo 的 gating 是刻意的——MiniMax-H3 的社群授權排除歐盟、英國、南韓與美國，那個限制跟著權重走。

二、權重（54 GiB，但不需要同時進 VRAM）

# H3 那一側，六個檔都在同一個 repo
hf download coolthor/H3-Super-Acceleration-Turing --local-dir ComfyUI/models \
  diffusion_models/minimax_h3_fl2va_pruned_int8_convrot.safetensors \
  text_encoders/qwen3vl_32b_heretic_convrot_w4a4.safetensors \
  loras/minimax_h3_fl2v_turbo_4step_v0.1_768p_sla_comfyui_bf16.safetensors \
  vae/minimax_h3_video_vae_fp16.safetensors \
  vae/minimax_h3_audio_vae_fp32.safetensors \
  conditioning_cache/ltx_generic_refine.cond

# LTX 那一側，精修用 GGUF，原因在下一節
hf download agosh/LTX-2.5-Comfy-GGUF --local-dir ComfyUI/models/diffusion_models \
  ltx-2.5-22b-distilled-transformer-bf16-Q4_K_M.gguf
hf download Lightricks/LTX-2.5 --local-dir ComfyUI/models \
  vae/ltx-2.5-video-vae-conv-bf16.safetensors \
  vae/ltx-2.5-audio-vae-bf16.safetensors \
  latent_upscale_models/ltx-2.5-latent-spatial-upscaler-x2-bf16-1.0.safetensors

22 GB 的卡裝不下 54 GiB，但不需要。ComfyUI 會依序載入、用完就換，H3 的 transformer 自己就回報 loaded partially ... 2861 MB offloaded。真正的前提是快的硬碟加夠大的系統記憶體——這台是 128 GB。

⚠️ 那 13 秒的載入成本會直接反映硬碟速度。這台的 ext4 NVMe 實測 2.3 GB/s，而同機另一顆 ntfs3 只有 1.2 GB/s。我一開始把 13.2 GiB 的文字編碼器放在後者上，搬過去就省了 5.6 秒。

三、節點包（三個）

git clone https://github.com/T8mars/comfyui-minimax-h3-audio-T8 \
  ComfyUI/custom_nodes/comfyui-minimax-h3-audio-T8

git clone https://github.com/xmarre/ComfyUI-Spectrum-MiniMax-H3 \
  ComfyUI/custom_nodes/ComfyUI-Spectrum-MiniMax-H3

git clone https://github.com/city96/ComfyUI-GGUF \
  ComfyUI/custom_nodes/ComfyUI-GGUF

第三個是這台才需要的，提供 UnetLoaderGGUF。

還有第四個：節點 32 的 LoadConditioningT 來自 ComfyUI-CondCache，它隨 workflow 一起出貨，不是 git clone 而是從 HF 抓一個檔案放進 custom_nodes/：

hf download coolthor/H3-Super-Acceleration-Turing --local-dir ComfyUI \
  custom_nodes/ComfyUI-CondCache/__init__.py

漏掉它的症狀是整張圖載不進來，而錯誤訊息講的是「節點不存在」不是「檔案缺了」——你會跑去找一個其實已經在的權重。

另外還要一支啟動 adapter，跟 workflow 一起放在 HF：

hf download coolthor/H3-Super-Acceleration-Turing --local-dir ComfyUI \
  custom_nodes/ComfyUI-LTXV-Turing-FP16/__init__.py

它只在 torch.cuda.get_device_capability() == (7, 5) 時動作，理由在後面〈進階〉那節的〈靜默失敗之二〉。

四、把 LTX 的 bf16 檔轉成 fp16

Turing 沒有 bf16 硬體，ComfyUI 會把 bf16 升成 fp32，記憶體剛好翻倍。 實測 1.35 GiB 的 ltx-2.5-video-vae-conv-bf16 載入後是 2769.87 MB，0.93 GiB 的 x2 放大器是 1899.22 MB。

轉檔腳本在同一個 repo：

hf download coolthor/H3-Super-Acceleration-Turing --local-dir . scripts/bf16_to_fp16.py

python scripts/bf16_to_fp16.py \
  models/vae/ltx-2.5-video-vae-conv-bf16.safetensors \
  models/vae/ltx-2.5-video-vae-conv-fp16.safetensors

三個檔（video VAE、audio VAE、x2 放大器）都轉，省約 2.7 GB。轉的時候逐張量檢查過，權重最大值超出 fp16 範圍的是 0 個。

那句話要照字面讀：它檢查的是權重本身的數值範圍，不是推論當下流過的數值、不是下溢、也不是畫質。我另外的依據是轉完之後的產物我自己看過。而 fp16 存 10 個尾數位、bf16 只存 7 個，但這不代表轉換能補回精度——bf16 當初丟掉的位元不會回來，轉 fp16 只是讓 ComfyUI 不再把它升到 fp32。

⚠️ 那支腳本會保留 safetensors 的 header metadata，而且非保留不可。save_file() 預設會丟掉它，而 ComfyUI 的 VAELoader 靠裡面的 config 鍵決定 VAE 架構。我第一版漏了，症狀是 size mismatch for encoder.down_blocks.7.conv.conv.weight: copying a param with shape [128, 1024, 3, 3, 3] ... current model is [256, 1024, 3, 3, 3]。

五、SageAttention 要開，而且要改一行

服務啟動旗標：

--use-sage-attention --reserve-vram 2 --disable-pinned-memory

版本必須是 1.0.6。2.x 以後要 sm_80 以上，官方 issue #137 就是一位 2080 Ti 使用者撞到 Unsupported CUDA architecture: sm75。

然後要調它的 Triton kernel。原廠設定要 67584 bytes 共享記憶體，而 Turing 的硬上限是 65536，Triton 直接拒絕，ComfyUI 靜靜退回 pytorch attention。site-packages/sageattention/ 底下六支 attn_qk_int8_*.py，把啟動參數改成：

num_stages=3 if head_dim == 64 else 1)

⚠️ 不要改 BLOCK_M。 它不是排程旋鈕：quant_per_block.py 的 per_block_int8(BLKQ=128) 是每 BLKQ 列產生一個量化 scale，而 kernel 用自己的 BLOCK_M 去索引那個陣列。只改一邊會讀到錯的 scale 甚至越界，而且不會報錯。num_stages 只改軟體管線深度，演算法本身不變。

六、Workflow 裡的三個值

圖也在同一個 repo，拖進 ComfyUI 就好：

hf download coolthor/H3-Super-Acceleration-Turing --local-dir . \
  workflows/minimax-h3-ltx-two-stage-turing-sm75.json

32 節點，跟 Blackwell 版不同的三處：

節點 15 是 UnetLoaderGGUF 不是 UNETLoader。 這是最重要的一處，下一節整節在講。

節點 16 的 attention_backend 是 dense_reference。 Sol-Attn 的 kernel 是 bf16-only，這張卡跑不到，設 auto_sol_attn 只是讓它每次呼叫都靜默退回 dense。寫死 dense_reference 只是讓設定值等於這張卡實際會跑的東西。

節點 7 要明寫 bootstrap_first_forecast: false。 Spectrum 節點把這個選項的預設改成 true，而它要求 degree == 1 且 warmup_steps <= 1，跟圖裡的 4 和 5 衝突。不明寫的話節點 7 會拋 ValueError: bootstrap_first_forecast requires degree == 1，整張圖停在那裡。

全黑那次：規格完全正確、status: success、每個像素都是 0

這是這台機器上最值得講的一個坑，因為它把「機器檢查全過」和「東西是壞的」拉開到最遠。如果每一個你會去檢查的訊號都說沒事，你要怎麼知道它壞了？

第一次跑完整管線，284 秒，status: success。輸出是 1344×768、121 幀、5.04 秒、h264 加 aac 兩軌齊全的 mp4。cached=0，日誌裡沒有任何錯誤訊息。

然後我抽了三幀出來，三個 JPEG 檔案大小一模一樣都是 6250 bytes。打開一看，整張圖 100% 是精確的 RGB(0,0,0)。這還不足以診斷什麼——黑畫面可以來自裁切、解碼或後處理——但它足以讓我決定去量 latent 本身。

用 SaveLatent 把精修前後兩個 latent 存下來量：

精修前  (1,128,16,24,42) fp32   NaN 0 個        min -6.1942  max 5.4041  std 0.9560
精修後  同樣形狀                 NaN 2,064,384 / 2,064,384 = 100%

進去乾淨、出來全毀，那中間那一步到底換了什麼？換成同一個模型的 GGUF Q4_K_M 版就完全正常，而且那顆只有 11.38 GiB，比壞掉的 20.03 GiB 還小。

⚠️ 這個對照能推到多遠要講清楚。它證明的是在這個版本堆疊下，那顆檔壞、GGUF 那顆好——ComfyUI 0.31.0、comfy-kitchen 0.2.28、torch 2.6。它沒有分辨出錯的是權重、反量化、還是 kernel，因為換檔案是一次換掉三樣。版本那一軸我測不了：comfy-kitchen 0.2.31 在 torch 2.6 下根本 import 不起來（backends/eager/na.py 的 list[int] 標註過不了 infer_schema），而 torch 2.6 正是 sageattention 1.0.6 與 triton 3.2.0 綁著的那版。那組版本是這張卡跑得動的唯一組合，所以結論的作用域就是它。

⚠️ 有一件事要特別講：H3 自己的 int8-convrot 在同一張卡上是好的。 ComfyUI 載入時印的 Native ops: int8_tensorwise, asym_w4a8_int8, convrot_w4a4 意思是「不走模擬路徑」，不是「算得對」。這兩件事要分開，而且只能逐個模型驗。

💡 同場加映：降解析度換時間，像素少多少、時間就少多少

165 秒對很多用途還是太久。那還能砍哪裡？最有效的是降低草稿解析度——但要知道它連帶降低輸出，因為 LTXVLatentUpsampler 是鎖死的 ×2，草稿永遠是輸出的一半。

三個點，同一個 workflow 只改草稿尺寸與交接目標：

草稿	輸出	冷機	熱機	草稿像素比	熱機時間比
672×384	1344×768	179.8	167.0	1.000	1.000
544×320	1088×640	129.5	117.3	0.675	0.702
432×240	864×480	84.5	76.9	0.402	0.460

擬合出來乾淨得有點意外：

熱機秒數 ≈ 16.4 + 150.6 × (草稿像素 / 258,048)

中間那個點用這條式子預測是 118.0 秒，實測 117.3，誤差 0.6%。

我原本預測會是超線性，理由是 attention 的成本隨 token 數平方成長。結果幾乎是線性的——代表 attention 在這個工作量上不是主導項，線性的那半才是。降解析度沒有額外紅利，也沒有陷阱。

推薦停在 544×320 → 1088×640。 117 秒，省 30%，而髮絲、耳飾、皮膚層次看起來幾乎沒掉。再往下那階雖然只要 77 秒，但明顯軟了。

同一隻貓、同一個 seed，草稿降到 544×320：輸出 1088×640。跟文章開頭那支並排看，差的是尺寸多過細節。

⚠️ 一個判讀上的提醒：三階是三次不同的生成，不是同一段影片的三種畫質。解析度變了 latent 形狀就變，同一個 seed 也會走出不同的取樣軌跡。能比的是細節密度，不是內容。

另外還有一個不吃解析度的槓桿：幀數。草稿 124 幀、輸出 121 幀（24 fps 下是 5.04 秒），砍短片長理論上是近乎線性的節省而且不損失空間細節——不過這條我沒有實測，只是機制上該成立。

---

進階：兩個靜默失敗、一個會喊但沒人聽，與四個被排除的假設

不讀這節不影響使用。這裡是怎麼從「全黑」走到「換一顆檔」的過程，以及沿路排除掉的東西。

沿路排除的四個假設

從全黑到定位根因，中間有四個看起來很像的假設被實測排除。這部分比答案本身有用，因為下次再碰到黑畫面，我八成還是會先懷疑這四件事。

記憶體不足。 日誌裡有一行非常可疑：最後那顆 LTX VideoVAE 是 loaded partially; 0.00 MB usable, 0.00 MB loaded, 2769.87 MB offloaded——整顆推去 CPU、一個位元組都沒進 VRAM。而當時 nvidia-smi 顯示卡上還有 4,260 MiB 是空的。

看起來就是它了。換成 VAEDecodeTiled 重跑，記憶體行為完全不同，畫面照黑。更後來的事實更徹底：正常產出的那些發也會出現同一行。⇒ 那是症狀不是病因。

計算 dtype 掉到 fp32。 兩階段的載入行並排看：

Stage 1 (H3)  : model weight dtype torch.float16,  manual cast: torch.float16
Stage 2 (LTX) : model weight dtype torch.bfloat16, manual cast: torch.float32

LTX 的計算 dtype 落到 fp32，而 convrot kernel 只吃 FP16/BF16。修好之後秒數從 266 降到 179，省 33%——是真問題，但畫面照黑。⇒ 必要不充分。

排程或條件強度。 把 sigma 壓到 0.05, 0.03, 0.01, 0，在那個強度下精修幾乎不該改動輸入。照黑。⇒ 不是排程。

fp16 範圍溢位。 這個我一度下了結論，而且錯了。黑得太乾淨、latent 全 NaN，跟 2026-08 在這張卡上修 H3 那次的溢位同型。但有一個事實我當時略過了：fp32 那幾發也是黑的。如果純粹是範圍問題，fp32 應該只是慢而不是壞。⇒ 兩種 dtype 都黑，至少排除了「頂層計算 dtype 太小」這個解釋。⚠️ 嚴格講它沒有排除 kernel 內部仍以 fp16 做某些運算而溢位——要排除那個得進去插樁，我沒做。

最後定案的證據是一組只換一個變因的對照，同模型、同版本、同 sigma、同 VAE、同機器：

精修用的 LTX 檔	反量化路徑	秒數	結果
...comfy-int8-convrot 20.03 GiB	comfy-kitchen convrot kernel	179.1	⬛ 100% NaN
...bf16-Q4_K_M.gguf 11.38 GiB	ComfyUI-GGUF（dequant→fp16→一般 GEMM）	185.0	✅ 正常
sulphur-distil-ltx23av-Q4_K_M.gguf（LTX 2.3）	同上	198.2	✅ 正常但換臉

LTX-2.3 那行值得一提：它精修得出來，但臉變成另一個人。sigma 0.78 是在 5090 上跑六臂對 2.5 校準出來的轉折點——再高一點就開始換臉，再低一點細節回不來。換一個世代那個點就跑掉了。那不是 GGUF 的問題。

靜默失敗之一：Sol-Attn 永遠不會告訴你它沒跑

ComfyUI-SolAttn_triton 的 kernel 是 bf16-only，資格檢查寫在 __init__.py:176-177：

if q.dtype != torch.bfloat16:
    return f"dtype {q.dtype} (kernel is bf16-only)"

Turing 沒有 bf16，所以這一行每次都成立。而不合格之後是 return None 落回 dense，不是拋例外。更關鍵的是註冊表進入點 attention_sol 把 verbose 寫死成 False，所以走 attention_backend 進來的路徑一行訊息都不會印。

它自己有一個計數器可以問：sol_attn_stats() 回傳的 dict 裡有 sparse 與 dense_fallback。sparse > 0 才代表 kernel 真的跑了。 那比看日誌可靠，因為它的 _log_once 會對同一組 (shape, reason) 去重——「log 沒訊息」分不出「機制沒啟動」和「被去重掉」，計數器分得出來。

順帶一提，Sol-Attn 的兩個 ComfyUI 移植也都不支援 Turing：Saganaki22 版寫明 SM89–SM121、quzopl 版是 SM89/90/100/120。

靜默失敗之二：--fp16-unet 對量化模型完全無效

第三節那支啟動 adapter 存在的理由。LTXV.supported_inference_dtypes 是 [bfloat16, float32]，Turing 沒有 bf16，計算 dtype 就落到 fp32。

直覺會想到下 --fp16-unet。它不管用，而且原因在 comfy/sd.py：

if model_config.quant_config is not None:
    manual_cast_dtype = unet_manual_cast(None, load_device, model_config.supported_inference_dtypes)
else:
    manual_cast_dtype = unet_manual_cast(unet_dtype, load_device, model_config.supported_inference_dtypes)

量化模型走上面那條，weight_dtype 刻意傳的是 None（合理：權重是 int8，它的 dtype 說明不了計算該用什麼）。於是 unet_manual_cast 裡所有比對 weight_dtype 的分支全部落空，只剩最後那個 for dt in supported_dtypes 迴圈——而旗標改的 unet_dtype 在這條路上根本沒被傳進去。

症狀是日誌變成 model weight dtype torch.float16, manual cast: torch.float32：旗標動得了前半，動不了後半。

三種改法比一下：

做法	有效	作用範圍	ComfyUI 升級後存活	看得見
改 comfy/supported_models.py	✅	只 LTXV	❌ 會被蓋掉	❌
--fp16-unet 旗標	❌ 量化模型無效	全服務	✅	✅
custom_nodes/ 啟動 adapter	✅	只 LTXV	✅	✅ 啟動日誌

第三種是這台機器原本就有的做法——它早就有一支 kitchen_turing_int8_enable.py 在做同類的事。照抄那個形狀寫，刪一個檔就還原。

會喊但沒人聽：SageAttention 退回 pytorch，只差 2048 bytes

日誌裡幾十行：

Error running sage attention: out of resource: shared memory,
Required: 67584, Hardware limit: 65536. using pytorch attention instead.

67584 − 65536 = 2048。用 tile 大小粗算一下各段的份量，BLOCK_M=128 / BLOCK_N=64 / HEAD_DIM=128（這是估算不是量測，Triton 實際配置多少我沒有測）：

num_stages	Q	K	V	合計
4	16384	32768	65536	114688
2	16384	16384	32768	65536
1	16384	8192	16384	40960

num_stages=2 那格剛好落在 65536，而 Triton 實際要的是 67584——多出來的 2048 是什麼我沒查，估算只能告訴我「2 太貼、1 有餘裕」，而實測結果與這個方向一致。

而不能改 BLOCK_M 的理由前面講過，這裡補上判準：那個常數同時決定了 q_scale 這個張量的 shape（(qo_len + BLKQ - 1) // BLKQ）。如果一個常數決定了某個張量的形狀，它就不是排程參數。

SageAttention 的實際價值：不是快，是能不能跑

最後這組對照是這張卡上最乾脆的結論。同 workflow、n=3 取熱機中位：

組態	冷機	熱機
SageAttention 1.0.6	178	165
關掉，純 pytorch SDPA	213	💀 OOM

關掉之後第二發起 4 秒就死，日誌是 Got an OOM, unloading all loaded models。pytorch 的 mem-efficient SDPA 比 SageAttention 的 INT8 kernel 吃更多 VRAM，而熱機時模型還在卡上，空間不夠。

⚠️ 我在查這題的時候，網路搜尋兩次都把「SageAttention 在 2080 Ti 上快 16.8%」餵回給我當外部證據——那個數字的來源是本站八月那篇。查自己寫過的題目時，先確認命中的來源不是自己。而且那篇是 864×480 的單段 H3，跟這裡 1344×768 的兩段式不是同一個形狀；同一張卡、不同形狀，結論可以相反。

這台機器的執行環境

顯卡           RTX 2080 Ti 22G(改裝)· 計算能力 7.5(Turing)
系統           Linux · torch 2.6.0+cu124 · triton 3.2.0 · Python 3.12
ComfyUI        0.31.0 · comfy-kitchen 0.2.28 · sageattention 1.0.6
啟動旗標        --use-sage-attention --reserve-vram 2 --disable-pinned-memory
儲存           ext4 NVMe 實測 2.3 GB/s · 系統記憶體 128 GB
權重總量        53.97 GiB
輸出           1344×768 · 121 幀 · 24 fps · 含音訊
步數           草稿 4 / 精修 3

---

完整 workflow、啟動 adapter、轉檔腳本，以及那顆 13.2 GiB 的 heretic 文字編碼器（ConvRot W4A4，就我查到的範圍內是第一份公開的）都在 coolthor/H3-Super-Acceleration-Turing 的 TURING.md。

同一條產線在有餘裕的卡上：RTX 5090 上的方法詳解