Day 24｜MiniMax-H3 地端影片生成：h3-ui 與四步蒸餾版的三段對決

2026 iThome 鐵人賽

DAY 24

AI Engineering

128GB 統一記憶體的三十天：DGX Spark 地端 LLM 與生成式 AI 部署實戰系列第 24 篇

18th鐵人賽

ivanusto

2026-09-06 13:52:03

353 瀏覽

分享至

影片生成是地端最貴的工作

生圖一張幾秒到幾十秒，影片一段動輒幾分鐘到十幾分鐘，而且每改一次提示詞就要重來。雲端服務的計價方式在這影片生成領域的費用最高，地端 AI 的價值也在這裡有更顯著的發揮。MiniMax-H3 是目前開放權重裡少數帶同步音訊的影片模型，本週 2026 IFA 上 NVIDIA 特別點名了它與 FastVideo 合作的四步蒸餾版 FastH3，宣稱和MiniMax-H3 原版相比，效能提升七倍。

今天剛好本系列文繼地端 AI 產圖後，下一個主題剛好是產影片，就來驗這個七倍吧。簡單的實測心得是這樣，同一台 DGX Spark、同一段提示詞、同一個種子，把四步蒸餾版跑起來的方式有三種，其中最慢的方式，其執行時間多達最快的 18 倍：

路徑	秒
FastH3 融合式（vLLM-Omni、4 步、107 幀）	114.2
FastH3 原生（FastVideo、權重在本機 NVMe、124 幀）	308.2
原版 H3（vLLM-Omni、20 步、107 幀）	418.8
FastH3 原生（FastVideo、權重在 NAS、124 幀）	2057.5

同一款模型的蒸餾檢查點，換個引擎差 2.7 倍，換個儲存位置再差 6.7 倍。七倍在哪裡 ? 消失在哪裡 ? 我們繼續往下看。

為什麼要三段的測試設定呢 ?

段	引擎	檢查點	步數	目的
原版 H3	vLLM-Omni nightly	MiniMax-H3 FL2VA，線上 FP8	20	h3-ui 的日常預設檔位
FastH3 融合式	vLLM-Omni nightly	同上，載入時融合 Dense/Data-Free LoRA	4	同引擎，隔離「蒸餾步數」的效果
FastH3 原生	FastVideo 0.2.1	FastH3-4-step-Preview-v1-VSA-DataFree	5	換引擎，看 VSA 稀疏注意力與新引擎值多少

中間那一段是關鍵設計。如果只比原版對 FastVideo，實測到的是「蒸餾加換引擎」的混合效果，分不出誰貢獻了什麼。用 vLLM-Omni 把同一組 LoRA 融合進去跑四步，就能單獨看 NVIDIA 這次和 FastVideo 合作出蒸餾模型的價值。

採用同一個四步排程 vLLM-Omni 送 steps=4、FastVideo 送 steps=5，一個數 DiT forward，一個數 sigma 點，檢查點自帶的設定檔兩個數字都寫了（transformer_forwards 4、num_inference_steps 5），實際做的事一樣。幾何是 960×576、107 幀（17 乘 6 加 5，落在 H3 的因果 VAE 格上）、24 fps、seed 1101，FastVideo 那段用它預設的 124 幀。

FastH3 是 FastVideo 對 MiniMax-H3 做的四步 DMD2 學生模型。vLLM-Omni 是在載入時把 --lora-path 指的 adapter 融進 checkpoint，不是可以逐請求切換的 LoRA，所以融合過的伺服器是換了一套請求契約。
在一台 GB10、線上 FP8、全計算、960x576、4.4 秒、seed 1101 的條件下，這個 adapter 把 50 步的 1034 秒縮到 114 秒，768x448 則是 63 秒。

原版路徑：vLLM-Omni 與 h3-ui

除了可以使用 Day 23 文章中的 ComfyUI跑這個 H3 影片的生成外，MiniMax-H3 在 vLLM-Omni 上也有官方支援，它把影片生成包成 HTTP 服務，但服務端沒有介面，每次生成都要自己組請求、自己管種子、自己記錄參數。用一個星期之後我做了 h3-ui（github.com/ivanusto/h3-ui）放 GitHub 上，這是單檔案、純 Python 標準庫、零相依的專案，h3-ui 只做四件事，佇列（一次丟十個提示詞去睡覺）、種子（明確顯示、可鎖定、可重用）、可重現的 sidecar（每支影片旁邊一個同名 JSON 記錄提示詞、種子、幾何、步數、模型版本，這樣的好處是，一個月後如果再看到好的影片產出，能夠儘快地原樣重生，跟 Day 5 的 MANIFEST 是同一種強迫症）、繁中介面（方便繁體中文用戶操作）。

也因此，剛好今天所有的逐項測試紀錄，都是因為有這個 sidecar 機制，剛好能夠順利完成，本文就不採用昨天的 ComfyUI 來測試了，但加上 Turbo 的 Lora 效果也會很快，同樣也能夠測試今天的主題，合先敘明。

那個上游 bug：`/health` 說沒事，但它已經死了

實作中也發現小 bug，想稍微講一下。我碰到生成較長影片時，服務突然不再回傳結果，佇列卡住，但 /health 回 200，日誌沒有錯誤。追了很久才發現 vLLM-Omni 有一個寫死的常數 _ASYNC_OUTPUT_TIMEOUT 是 30 秒，H3 的單步去噪在 Spark 上超過 30 秒是常態（今天測試到每步 18.85 秒，長幾何就會超過），逾時之後負責送回結果的 result-pump 執行緒安靜地死掉，主行程活著、健康檢查活著，就是永遠等不到結果。

我回報到上游，正式修正合併前社群有 build-time 修補的做法，h3-ui 的 README 記錄了整件事與繞路方式。其中，heathy check 看的是行程不是功能（Day 18 說別用推論請求當健康檢查，這裡是反面教材，行程級的檢查會在功能已死時繼續說沒事，而且今天 FastVideo 那段又給了一個新例子）、寫死的逾時是為某種硬體假設的（30 秒對資料中心 GPU 合理，對 273GB/s 的機器不合理）、開源的正確用法是回報而不是只繞路。

環境建置的小問題

另外，環境建置時也碰到一些小問題，幾個比較重要的如下。

一、官方的 Spark 安裝指令在這台機器上編不起來，而且錯誤訊息完全指錯方向。 FastVideo 的 kernel 在 CMake 階段報 glibc 標頭檔裡五個識別字未定義（__Float32x4_t 之類），看起來像系統壞了。真正的原因是 CMake 撿到 Ubuntu 24.04 的 nvidia-cuda-toolkit 套件放在 /usr/bin/nvcc 的 CUDA 12.0，不是 /usr/local/cuda 的 13.0，即使 PATH 順序是對的。12.0 的前端不認得 GCC 13 的 Neon 與 SVE 內建型別，於是報在 glibc 上。修法是明確指定：

export CUDACXX=/usr/local/cuda/bin/nvcc
export CUDA_HOME=/usr/local/cuda CUDAToolkit_ROOT=/usr/local/cuda
export CMAKE_ARGS="-DCMAKE_CUDA_COMPILER=/usr/local/cuda/bin/nvcc"

這是本系列文第三次踩到同一款地雷（Day 14 編 Flash-Next 分支、Day 22 的 WSL、再加上今天的 Day 24），所以這需要變成固定提醒，也就是呢，DGX OS 上任何要編 CUDA 的東西，先確認 nvcc 是哪一款，發行版套件那款會靜默蓋掉你以為在用的那款。

二、.env 一個值沒加引號。 H3_REQUEST_LORA_LABEL=Turbo, 4 denoiser steps 被 bash source 讀時把 4 當指令執行，整支腳本 exit 127。h3-ui 自己的解析器吃得下，所以這個壞掉從加上 turbo 檔位之後確實是需要修改的，剛好今天看到有順便改掉。

產圖速度測試對決

原版 H3：profiler 打開之後，固定成本 41.2 秒

量測	值
冷啟總計	1700 秒（權重 1235.5 秒）
暖機單支	420.17 秒
夜市提示詞	418.8 秒
峰值記憶體	71.0 GB
輸出	960×576、107 幀、24 fps、AAC 32 kHz 立體聲

暖機與正式兩支相差 0.3%，vLLM-Omni 的編譯成本在啟動時付掉，第一支請求不比後面的貴。

回應標頭的 X-Stage-Durations 只回一個 419.6 秒，從文字編碼到 MP4 封裝全混在一起，這是設定導致的。H3 的 pipeline 有掛 profiler mixin，只是預設關著，加上 --enable-diffusion-pipeline-profiler 重跑同一支，拆解就出來了：

階段	秒
encode_prompt（文字編碼）	2.21
diffuse（去噪 20 步）	376.99
decode（VAE 解碼）	37.11
未歸屬（封裝等）	1.89
合計	418.2

開 profiler 的那支與不開的差 0.14%，幾乎不花額外成本。這張表直接給出兩個數字，每步 18.85 秒（376.99 除以 20），固定成本 41.2 秒（文字編碼加解碼加封裝）。另外，只用兩支端到端時間解一次方程（418.8 等於 F 加 20k，114.2 等於 F 加 4k）得到每步 19.04 秒、固定成本 38.0 秒，跟 profiler 實測差 1% 與 8%，推算法站得住，但有實測就用實測。

FastH3 融合式：3.67 倍，不是 5 倍，而且每一步反而更貴

三段提示詞（夜市、海岸、廟會）114.2、114.2、113.0 秒，離散度 1%，峰值記憶體 72.9 GB（多的那一點是融合進去的 adapter），對原版是 3.67 倍。步數比是 20 比 4 也就是 5 倍，差在哪裡？同樣打開 profiler，同提示詞同幾何同種子，兩條 vLLM-Omni 路徑並排：

階段	原版 20 步	FastH3 融合 4 步	比
encode_prompt	2.21	2.21	1.00
diffuse	376.99	82.92	4.55
decode	37.11	36.67	1.01
未歸屬	1.89	1.69
合計	418.2	123.5	3.39

（兩支都是冷啟後第一支，融合式暖啟後是 114.2 秒，端到端才是 3.67 倍，原版冷暖無差。）

兩件事從這張表可清楚地呈現出來。

省先是固定成本兩邊幾乎相同，41.2 對 40.6 秒。文字編碼一樣 2.21 秒，VAE 解碼 37.11 對 36.67，它由引擎與幾何決定，跟排程無關，蒸餾一秒也砍不到。原版 20 步裡它佔約 10%，四步版裡佔約 36%。蒸餾能砍的只有去噪那一塊，砍得越乾淨，剩下的固定成本就越顯眼，這就是倍率隨分母縮小而衰減的原因。

蒸餾的每一步反而比較貴。原版每步 18.85 秒，四步版每步 20.73 秒，貴 10%，融合進去的 dense delta 與 VSA 壓縮閘不是免費的。所以去噪的加速是 4.55 倍而不是步數比的 5 倍，這 9% 的差額不打開 profiler 完全看不見。

FastH3 原生：`/health` 又說謊了，而且每一支都重讀權重

伺服器 15 秒回報就緒，記憶體只用 6 GB，模型根本還沒進來，lazy_module_load 把 VAE 與 transformer 全部延後。在第一個請求長達 1845.7 秒。好在它的階段拆解是三段裡唯一真正細的：

階段	第一支（秒）
conditioning（Qwen3-VL）	653.6
denoising	915.6
video decoding	263.2
audio decoding	7.9
合計	1845.6

第二支不但沒變快，反而 2057.5 秒。日誌看得一清二楚，每一個請求都重新從儲存讀一次 Qwen3-VL 的 14 片權重，再讀一次 DiT 的 14 片。官方文件那句「reloads Qwen3-VL and the DiT between phases of each request」，字面就是這個意思，在 GB10 上不是留在主機記憶體，是真的重讀。

儲存位置：同一份權重，換個地方放

今天最乾淨的一組結果，同一提示詞、同一引擎、同一權重，只把 text_encoder 與 transformer 從 NAS 複製到本機 NVMe：

階段	權重在 NAS	權重在本機 NVMe	倍率
conditioning	819.7	20.7	39.6
denoising（含 DiT 重載）	990.3	106.4	9.3
video decoding	230.2	171.0	1.3
合計	2057.5	308.2	6.68

每片權重從 41 到 60 秒變成 1.4 秒。308.2 秒對得上官方公布的 374 到 393 秒，也就是說官方數字成立，2057 秒完全是儲存位置造成的。Day 13 給過兩個判斷問題，FastVideo 是那個極端案例，每請求重載讓「權重放哪裡」從開機一次性成本，變成每一支影片都要付的成本，放 NFS 可行，但每支需要多付更多時間成本。

兩個引擎的 VAE 解碼差四倍，這就是 2.7 倍的來源

拆解到齊之後，一個先前看不見的差異就浮現出來，同一段影片，vLLM-Omni 的解碼 37.11 秒，FastVideo 170.98 秒。幀數 107 對 124 只解釋 1.16 倍，剩下的四倍是引擎差異。開場那張表裡同一款蒸餾檢查點在兩個引擎差 2.7 倍（114.2 對 308.2），去噪兩邊都不到一百秒，差距幾乎全在解碼那一段。

而在 FastVideo 這邊，權重搬回本機後最大的一塊就是 VAE 解碼 171 秒，比去噪的 106 秒還大。這印證了官方對 GB10 的說法，少步數模型的瓶頸是解碼不是注意力，解碼是頻寬受限工作，273GB/s 在這裡現形。官方的 TAEH3 預覽解碼器在 1344×768 把解碼從 68 秒降到 2.4 秒，照比例，這 171 秒是下一個該動的地方。

倍率的四個口徑

宣稱	來源	硬體與基準	本機實測
7 倍	NVIDIA IFA 部落格	未指明	3.67 倍（同引擎、20 步對 4 步）
最高 14 倍	Hao AI Lab	單張 B200，Dense FA4 為基準	達不到
3.92 倍	NVIDIA Sol Engine	DGX Spark，另一套引擎	未測
12.25 倍	步數比 49 對 4	理論上限，不含載入與解碼	本機步數比 5 倍（20 對 4）

14 倍的基準是 B200 上的 49 次 DiT forward，分母越大倍率越漂亮，我們的分母是 20 步，步數比只剩 5，每步再貴 10% 變 4.55，加上砍不掉的 41 秒固定成本就是 3.67。每一個倍率都是真的，差別只在分母與基準，看倍率先問基準是什麼，Day 13 講記憶體頻寬時說過，今天再提醒一次囉。

熱：起跑溫度決定一切

我的部署腳本有一道冷卻閘門（等 GPU 降到門檻才開跑）與一支看門狗（zone 溫度連續超過 88 度太久就中止），這兩樣是先前一次渲染讓整台機器斷電之後加的。今天一次操作失誤讓閘門被跳過：

起跑 GPU 溫度	最長連續 zone 88 度以上	結果
55 度（走完冷卻閘門）	225 秒	正常完成 418.8 秒
73 度（閘門被誤殺）	330 秒	看門狗在 330 秒中止，404.8 秒功虧一簣

同一支渲染，起跑溫度差 18 度，連續熱浸透時間差 47%。負載下峰值 GPU 87 度、zone 95 度、89.45 W，先前斷電那次是 zone 平均 91、連續浸透 417 秒，第二支已經走到那條線的三分之二。差別在於前面 28 分鐘的慢速載入（就是 NAS 那段）已經讓機殼熱浸透。決定一支長渲染安不安全的不是它自己的負載，是它開跑時機殼已經多熱，這個故事呢，留給之後的維運篇展開。

音訊驗證

三段輸出都用 ffprobe 逐檔驗過，全部帶 AAC、32 kHz、立體聲，長度與畫面一致。FastVideo 那段值得一提，Spark 的 serving 設定寫 t2v，檢查點自帶的設定寫 t2av，兩份設定互相矛盾，所以只好來看輸出檔有沒有正確的聲音，還好實測 5.152 秒立體聲音軌，音訊正常。

四步蒸餾真的有加速，但沒有官方宣稱的那麼高

四步蒸餾在這台機器上的真實價值是 3.67 倍，不是七倍，差額一半在蒸餾砍不到的 41 秒固定成本，一半在每一步反而貴 10% 的 adapter 開銷，而固定成本裡最大的 VAE 解碼正是頻寬受限機器的弱項。三段的分工因此很清楚：日常迭代用 vLLM-Omni 融合式，114 秒一支、權重常駐、階段不重載。FastVideo 原生段留給它的 profiler 與 VSA 生態，但權重務必放本機 SSD，而且要等它把每請求重載這件事處理掉。

h3-ui 這類工具的價值今天也再確認了一次，昂貴的生成要變成可管理的生成，靠的是佇列、種子與 sidecar，不是靠模型變快。