MiniMax H3の条件付けを使い回すと速くなるか｜VRAM 16GB実測、縮むのはプロセスを立て直したときだけ

MiniMax H3 を VRAM 16GB のカードで回すと、ComfyUI のプロセスを立て直すたびにテキストエンコーダの読み込みが挟まる。同じプロンプトで seed だけ変えて枚数を出す使い方だと、この読み込みは同じ結果を作り直しているように見える。条件付け (conditioning) をディスクに保存しておいて次の実行から読ませる手は ComfyUI-LTXVideo のノードで組めるので、実際に何秒縮むのか、そして出力が同じままなのかを RTX 5080 16GB と RTX 5060 Ti 16GB の2枚で測った。MiniMax H3 の導入手順・必要なファイル・ライセンスの条件はMiniMax H3をVRAM 16GBで動かす｜ComfyUIでの導入手順とRTX 5080・5060 Ti実測にまとめてある。

同じプロセスで続けて出すなら何もしなくてよい

答えは使い方で割れる。ComfyUI を立ち上げたまま続けて出すのか、1本ごとにプロセスを立て直すのか (生成のたびに ComfyUI を終了する回し方や、他のモデルやアプリと GPU を取り合うので毎回落とす回し方が該当する) で、条件付けの保存が意味を持つかどうかが変わった。

測ったのは4条件で、二つの軸の組み合わせになる。ComfyUI を立ち上げたまま続けて出すか、1本ごとに立て直すか。そして条件付けを毎回テキストエンコーダで作るか、ディスクに保存したものを読むか。ワークフロー上の違いは、条件付けを作るノードを、保存しておいたファイルを読むノードに差し替えるところだけになる。生成の中身はどの条件でも同じで、864×480・56フレーム・20ステップを、同一のプロンプトで seed だけ変えて回している。RTX 5080 と RTX 5060 Ti は同じ1台に挿さっているが、この測定では別々に使った。2枚を挿した機体で2枚目が使われるかどうかの切り分けは複数GPUが認識されても使われない時の切り分け｜Windows+OCuLinkで2枚目が使われる条件にまとめてある。

RTX 5060 Ti で4条件を3本ずつ測った値を条件ごとに並べる。

条件	所要	モデルの載せ直し要求	GPU全体ピーク
同じプロセスで続けて出す 1本目	143.939秒	4本	15,428MiB
同じプロセスで続けて出す 2本目	132.891秒	0本	15,270MiB
同じプロセスで続けて出す 3本目	132.774秒	0本	15,302MiB
1本ごとに立て直す 1本目	142.312秒	4本	15,460MiB
1本ごとに立て直す 2本目	141.321秒	4本	15,556MiB
1本ごとに立て直す 3本目	141.630秒	4本	15,652MiB
立て直す＋条件付けをディスクから 1本目	134.987秒	3本	15,428MiB
立て直す＋条件付けをディスクから 2本目	134.852秒	3本	15,492MiB
立て直す＋条件付けをディスクから 3本目	134.848秒	3本	15,556MiB
同じプロセス＋ディスクから 1本目	134.903秒	3本	15,556MiB
同じプロセス＋ディスクから 2本目	132.613秒	0本	15,236MiB
同じプロセス＋ディスクから 3本目	132.711秒	0本	15,236MiB

同じプロセスで続けて出す経路では、2本目と3本目のモデルの載せ直し要求が0本になっている。テキストエンコーダを読み直さずに次の実行へ入っており、ここに条件付けの保存を足しても所要は 132.613秒・132.711秒 と、何もしない場合の 132.891秒・132.774秒 に重なる。この使い方に対しては、手を加える動機が測定値の側から出てこなかった。なお載せ直し要求の本数は要求が何本立ったかの数であって、実際に何バイト読んだかを表すものではない。エンコードをやり直した形跡が所要の側にも出ていない。同じプロセスの経路では1本目だけがモデルの読み込みを含むので、2本目以降とは分けて読む必要がある。立て直す経路は3本とも読み込みを含む。

1本ごとにプロセスを立て直す経路では様子が変わる。3本とも載せ直し要求が4本立ち、所要は 141.321〜142.312秒。条件付けをディスクから読ませると載せ直し要求は3本に減り、所要は 134.848〜134.987秒 に落ちた。同じ seed 同士で引くと1本あたり 6.47〜7.33秒 縮んでおり、中央値同士の差は 6.78秒 で、総時間に対してはおよそ5%にあたる。

RTX 5080 では同じ結論が出なかった。表示出力を兼ねるカードで、4条件を同じ1セッションの中で4本ずつ測っている。

条件	所要	中央値	群内の幅	モデルの載せ直し要求
1本ごとに立て直す	87.65 / 70.01 / 70.95 / 70.60秒	70.78秒	17.64秒	毎回4本
立て直す＋条件付けをディスクから	67.70 / 70.36 / 63.30 / 62.98秒	65.50秒	7.38秒	毎回3本
同じプロセスで続けて出す (2本目以降)	61.75 / 61.18 / 66.54秒	61.75秒	5.36秒	0本
同じプロセス＋ディスクから (2本目以降)	67.40 / 70.88 / 90.12秒	70.88秒	22.72秒	0本

群内の幅が 5.36〜22.72秒 あり、条件同士の中央値の差と同じ大きさになっている。つまり RTX 5080 側は、経路を変えて何秒縮んだという読み方に耐えない。この幅は同じ条件を繰り返したときの振れであって、経路の違いを表す量ではない。16本のうち 87.65秒 と 90.12秒 の2本が幅の大半を作っており、残りは 61.18〜70.95秒 に収まる。87.65秒 の回は ComfyUI を立てた時点の使用量が 1,468MiB とこのセッションで最も多かったが、90.12秒 の回はモデルが載ったままの回で、2本が何で伸びたのかは切り分けていない。表示出力を兼ねているカードなので他のアプリの状態が乗りうる、というところまでしか言えない。RTX 5080 について言えるのは、この測定では経路による差を検出できなかった、というところまでになる。RTX 5080 側は表示出力を兼ねており、実行の直前の GPU 使用量も 914〜1,468MiB の幅で動いていた。ただしこの2枚は型番のほかに接続形態 (PCIe x16 と OCuLink) と表示出力の有無も同時に違っており、この測定では振れの原因を切り分けていない。どの差によるものかは特定できない。この RTX 5080 の環境では、5%前後の差を判定するのに、経路を変える前に同じ条件を何本か回して振れ幅を見ておく必要があった。

16GB のカードで気になるのは VRAM の側だが、RTX 5060 Ti では、テキストエンコーダを読み込まなくなっても空きは増えなかった。RTX 5060 Ti の GPU 全体ピークは経路によらず 15,236〜15,652MiB に収まり、総量 16,311MiB の内側で動いている。条件付けをディスクから読ませた行でも、テキストエンコーダを毎回読み直す行でも、ピークの水準は同じ帯に並ぶ。この値はベースライン込みの GPU 全体の使用量で、モデル単体の増分ではない。VRAM の空きと所要時間の関係そのものはComfyUIで使えるVRAMを絞ると画像・動画生成は遅くなるかで別に扱っている。

ここまでで条件付けの保存を見送る判断に落ちる場合、見る先は所要時間の大半を占めるサンプリングの側になる。ステップ数そのものを減らす手段の実測はMiniMax H3 Turbo LoRAは何倍速い？｜ComfyUIで4〜8ステップ・RTX 5080/5060 Ti実測にある。なお first_frame に画像を渡す使い方をしている場合は、保存を入れる入れないに関わらず、画像を渡す実行で何が起きたかの節には目を通しておきたい。エラーで止まらない食い違いになる。

エンコーダが作っているものは、ディスク上では430,280バイトしかない

以下はこの記事で使ったプロンプト1件についての値になる。縮み幅が数秒に留まる形は、保存されるものの中身を見ると輪郭が見えてくる。条件付けのファイルを safetensors のヘッダから読み、あわせて、テキストエンコーダを載せてエンコードするまでの所要も測った。

項目	値
テキストエンコーダのファイル	15.69GB (Qwen3-VL-32B の NVFP4 AWQ 版)
テキストエンコーダを載せてエンコードするまでの所要	RTX 5080 で4.687秒 / RTX 5060 Ti で5.054秒
保存された条件付け (画像なし)	430,280バイト
その中身 (画像なし)	conditioning_data_0 という bfloat16 のテンソル1本のみ、形は [1, 42, 5120]
保存された条件付け (画像を1枚渡した場合)	4,659,400バイト

15.69GB のファイルを読み込んで動かすテキストエンコーダが、このプロンプトについて作った条件付けのファイルは 430,280バイト だった。中の bfloat16 テンソル自体は 430,080バイト で、残りは safetensors のヘッダなどになる。ここでの 15.69GB はディスク上に置かれたファイルの大きさで、GPU の使用量として観測した MiB の値とは別の量になる。ファイルの大きさと VRAM 上の占有は同じ数字にならないので、混ぜずに読む必要がある。

保存と読み込みに使ったノードは ComfyUI-LTXVideo が提供しているもので、保存側が LTXVSaveConditioning、読み込み側が LTXVLoadConditioning にあたり、ComfyUI の画面には LTXV Save Conditioning / LTXV Load Conditioning という表示名で並ぶ。リポジトリには conditioning_saver.py と conditioning_loader.py が置かれている。ComfyUI の画面で探すときはファイル名ではなくノード名で当たることになる。2026年9月5日に確認したリポジトリの構成で、測定にはこのノードパックを導入した ComfyUI 0.31.1 を使った。入れる判断に落ちた場合に触るのはこの2つのノードで、ノードパックそのものは末尾の参考資料にあるリポジトリ、MiniMax H3 側の準備は導入手順の記事にあたることになる。

保存で省けるのは、テキストエンコーダをメモリに載せる工程と、プロンプトをエンコードする工程だけになる。この2工程だけを実行した run の所要は RTX 5080 で 4.687秒、RTX 5060 Ti で 5.054秒だった。どちらもテキストエンコーダの読み込みを含む値で、すでに載っている状態での再エンコードだけを取り出した値ではない。生成とは別に走らせた run の値なので、生成での縮み幅 (RTX 5060 Ti で 6.47〜7.33秒) と一致する量ではない。サンプリングは1秒も減らない。条件付けの保存はサンプリングそのものを速くする手段ではなく、サンプリング前のテキストエンコーダの読み込みとプロンプトのエンコードを省く手段になる。

同じ領域には、第三者が公開しているリポジトリ minimax-h3-speedup という別の実装もある。同リポジトリは、自リポジトリが minimax/cache の下に H3SaveConditioning / H3LoadConditioning / H3SaveLatentAV / H3LoadLatentAV の4ノードを提供していると述べており、そこで報告されている秒数はこの自前ノードによるものだと説明している。この記事が測ったのは ComfyUI-LTXVideo の汎用ノードのほうで、実装は別のものになる。

縮むのはサンプリング以外の部分だけで、この機材ではそこが短い

条件付けの保存が削る先はサンプリング以外の部分に限られるので、その部分が総時間の何割を占めているかで上限が決まる。ComfyUI の進捗表示が出す20ステップぶんのサンプリング時間と、同じ条件の総時間の中央値から、サンプリング以外に回っている時間を出した。

カード	条件	サンプリング	総時間	サンプリング以外	割合
RTX 5060 Ti	毎回立て直す	1分58秒 (5.94秒/ステップ)	141.630秒	23.6秒	16.7%
RTX 5060 Ti	ディスクから	1分58秒 (5.94秒/ステップ)	134.852秒	16.9秒	12.5%
RTX 5080	毎回立て直す	54秒 (2.74秒/ステップ)	70.780秒	16.8秒	23.7%
RTX 5080	ディスクから	54秒 (2.74秒/ステップ)	65.500秒	11.5秒	17.6%

この機材ではサンプリング以外が 12.5% から 23.7% の範囲に収まっていた。図に出した RTX 5060 Ti は 12.5〜16.7% で、23.7% は RTX 5080 の行の値になる。ただし RTX 5080 の2行は、群内の幅が 7.38〜22.72秒 ある測定の中央値から出したものになる。2行の差を経路による縮みとして読むことはできず、サンプリング以外が総時間に占める水準を見るための値になる。サンプリング時間は進捗表示の経過 (1分58秒 と 54秒) を使っている。同じ表示に出る秒/ステップから 5.94×20=118.8秒、2.74×20=54.8秒 として引き直すと、4つの割合はいずれも1ポイントほど下へ動く。加えて RTX 5080 の総時間は同じ条件でも群内の幅が大きい。境界にどれだけ近いかを論じられる精度ではないので、おおよその水準として読むところまでになる。サンプリング以外の内訳 (モデルの読み込み・エンコード・VAE デコード・動画の書き出し) は、この測定では分けていない。なぜこの機材でサンプリング以外が短く収まっているのかも測っていないため、原因には踏み込まない。

この記事の機体はシステムRAM が ComfyUI の起動時報告で 98,075MB あり、テキストエンコーダと DiT が同時に載らないという制約は当てはまらない。minimax-h3-speedup の報告と重ねて言えるのは、サンプリング以外が占める割合の向きが逆になっている、という一点だけだった。機材・尺 (124フレームと56フレーム)・実装・ベースラインの4つが違っており、どの違いが差を生んだのかはこの測定からは言えない。秒数同士を並べて比べられる関係でもない。手元へ当てはめられるかという観点では、この 950秒 から 204秒 はテキストエンコーダと DiT が同時に載らずモデルを毎回捨てていた構成での値になる。システムRAM に余裕があってモデルを抱えたままにできる機体では、同じ倍率をそのまま持ち込む根拠にはならない。

同じ手順は手元でも取れる。ComfyUI の進捗表示に出る20ステップぶんのサンプリング秒と、実行全体の所要の差が、条件付けの保存で削れる時間の上限にあたる。ここが総時間の1割前後しかない構成なら、保存を入れても総時間はその範囲でしか動かない。

画像を渡さない使い方なら、同じカードで作った条件付けで出力は変わらない

速くなるかどうかとは別に、出力が変わらないかどうかが判断の前提になる。同一 seed で通常経路とキャッシュ経路の出力を作り、フレーム単位で突き合わせた。比較の方法には注意点がひとつある。動画ファイル全体のハッシュでは判定できない。ComfyUI はワークフローをメタデータに埋め込むので、同じ経路で作っても書き出し名が違えばファイル全体は変わってしまう。そこで実データ部分 (mdat) だけを取り出し、映像56枚・音声73枚をフレーム単位で比べた。

比較	映像	音声
RTX 5060 Ti: 通常経路 と 同じカードで作った条件付け (seed 3本)	3本とも 0 / 56 が不一致	3本とも 0 / 73 が不一致
RTX 5080: 通常経路 と 同じカードで作った条件付け	0 / 56 が不一致	0 / 73 が不一致
RTX 5080: 通常経路 と 別のカードで作った条件付け	56 / 56 が不一致	73 / 73 が不一致
同じ経路の 常駐 と 立て直し (両カード)	0 / 56 が不一致	0 / 73 が不一致

RTX 5060 Ti では seed 3本すべてで映像・音声とも不一致が0枚、RTX 5080 でも映像56枚・音声73枚が一致した。同じ経路の常駐と立て直しの間でも一致している。画像を渡さない使い方であれば、同じカードで作った条件付けを読ませても出力は1フレームも変わらなかった、という結果になる。ただしこの限定は外せない。画像を渡す使い方では、同じカードで作った条件付けでも全フレームが変わった。

一致したことは品質が同じという意味ではない。測ったのはフレームが一致するかどうかの二値であって、品質の評価はしていない。一致という観測が支えているのは、経路を変えても同じデータが出てくるということだった。

保存内容も確認した。minimax-h3-speedup は、ComfyUI-LTXVideo の汎用ノードが保存するのはテンソルと attention mask だけだと述べている。実際に保存されていたファイルのキーは conditioning_data_0 の1本だけで、attention mask にあたるキーは無かった。430,280バイトという大きさも、ほぼテンソル1本ぶんで説明が付く。

別のカードで作った条件付けを読ませると、全フレームが変わった

条件付けのファイルは2枚のカードで共有できそうに見えるが、中身は一致しなかった。同じプロンプトの条件付けを各カードで2回ずつ、別プロセスとして保存し、float32 へ上げて要素ごとに比較した。要素数は 215,040 (= 1 × 42 × 5120) になる。

比較	違う要素	最大の差
RTX 5080 で2回	0 / 215,040	0
RTX 5060 Ti で2回	0 / 215,040	0
RTX 5080 と RTX 5060 Ti の間	344 / 215,040	0.0625
参考: 値の範囲	—	−80 〜 15,424

同じカードで作ったもの同士は、別プロセスで作っても要素がすべて一致した。カードをまたぐと 215,040 要素のうち 344 要素が違い、その最大の差は 0.0625 だった。この 0.0625 が大きいか小さいかはここでは評価しない。差が出た344要素そのものの値の大きさとは比べていないため、比率としての意味を付けられない。

出力の側では、RTX 5060 Ti で作った条件付けを RTX 5080 で読ませた実行が、通常経路と映像56枚・音声73枚のすべてで不一致になった。ただし測ったのは一致するかどうかの二値で、絵がどれくらい違うのかは測っていない。別の動画になったとまでは言えず、言えるのはデータが一致しなくなったところまでになる。出力の比較は seed 1本で、同じカードでの比較 (RTX 5060 Ti で seed 3本) より本数が少ない。測った向きも RTX 5060 Ti で作った条件付けを RTX 5080 で使う一方向だけで、逆向きは測っていない。カードの組み合わせも1組だけになる。どちらのカードの出力が正しいという話でもない。

運用に落とすと、同じデータをあとから再現したい場合は、条件付けのファイルをカードごとに分けて持つ形になる。1枚のファイルを2枚のカードで共有する運用は、この測定の範囲では再現性を保てなかった。2枚のカードを併用する構成そのものはComfyUI マルチGPU運用ガイドで扱っている。

画像を渡すi2vでは、エラーにならないまま1枚目が別物になった

ここまでは画像を渡さない使い方の話になる。同じワークフローの first_frame に画像を1枚つないだ状態で、汎用ノードで保存した条件付けを読ませると、結果の性質が変わった。RTX 5060 Ti で seed 771000 を使い、出力1枚目と入力画像を同じ大きさに揃えて画素ごとの差 (0〜255) を取った。各条件1本ずつの測定で、RTX 5060 Ti の3本ずつ・RTX 5080 の4本ずつに比べて本数が少ない。

条件	所要	モデルの載せ直し要求	1枚目と入力画像の平均絶対誤差	同 最大
通常経路 (画像を渡してエンコード)	160.049秒	4本	3.796	67
ディスクから読んだ条件付け	142.762秒	3本	61.925	251
ディスクから読んだ条件付けの実行結果	エラーにならず成功として返る	—	—	—
両者のフレーム比較	—	—	映像 56/56・音声 73/73 が不一致	—

所要は通常経路の 160.049秒 に対しディスクから読んだ側が 142.762秒 だが、この差を縮み幅として読むことはできない。1枚目が入力画像と揃っていない以上、2本は同じ処理を終えていない。通常経路でも出力は VAE を通るため、1枚目と入力画像の差は0にはならない。その水準が平均絶対誤差 3.796 で、対照として読む値になる。ディスクから読んだ条件付けでは同じ指標が 61.925 まで上がり、最大の差も 67 から 251 へ動いた。1枚目が入力画像と揃っていない、という症状として観測できる。実行そのものはエラーを返さず、成功として返ってくる。

この症状の機構について、minimax-h3-speedup は説明を置いている。ComfyUI-LTXVideo の汎用の条件付け保存・読み込みノードはテンソルと attention mask しか保存せず、H3 が i2v / flf2v で付けるキーフレームを黙って落とすため、i2v の実行が静かに t2v になる、というものになる。同リポジトリの記載であり、この記事で測ったのは症状の側 (実行が成功として返ること、1枚目が入力画像と揃わないこと) までになる。

測定環境と、測っていないこと

ここまでの数字はすべて2026年9月5日に測定した値になる。機材は RTX 5060 Ti 16GB と RTX 5080 16GB の2枚で、基準点が異なる。RTX 5060 Ti は OCuLink 接続で表示出力を持たず、総量 16,311MiB、ComfyUI を起動する前の GPU 全体使用量は 0MiB、立て直す実行の直前は 114MiB だった。RTX 5080 は PCIe x16 接続で表示出力を兼ねており、総量 16,303MiB、ComfyUI 起動前の GPU 全体使用量が 1,233MiB、各実行の直前で 914〜1,468MiB。RTX 5080 側の値は、この起動前と実行直前の使用量を含んだ状態で読むことになる。

ソフトウェアは ComfyUI 0.31.1 で、MiniMax H3 のノードが追加された 0.30.0 より後の版にあたる。モデルは MiniMax H3 fl2va pruned fp8_scaled、テキストエンコーダは Qwen3-VL-32B の NVFP4 AWQ 版。ワークフローは 864×480・56フレーム・20ステップ、sampler は res_multistep、scheduler は simple で、同一プロンプトの seed だけを変えている。機体のシステムRAM は ComfyUI の起動時報告で 98,075MB。所要は ComfyUI の実行イベント (execution_start と execution_success) の時刻差で、サンプリング時間だけは進捗表示から読んでいるため秒単位の分解能になる。RTX 5060 Ti は4条件を3本ずつ、RTX 5080 は4条件を同じ1セッションの中で4本ずつ測った。

版について1点補足する。測定に使った 0.31.1 の後に 0.32.0・0.33.1・0.34.0 が出ている。0.32.0 のリリースノートには MiniMax-H3 の VAE 最適化とピークメモリの修正があり、この記事が測っている所要時間と GPU のピーク使用量に重なる。0.34.0 には H3 の特殊トークンを語彙へ追加する変更があり、こちらは条件付けのトークン数 (この記事では42) と保存されるバイト数に重なる。いずれも2026年9月5日に確認したリリースノートの記載で、これらの版で値がどう動くかは測っていない。なお 0.34.0 では、embedding: 構文で MiniMax H3 の prompt embedding を読み込む対応も入っている。これはこの記事で測った条件付け全体の保存・再利用とは別の仕組みで、この記事では測っていない。また、条件付けとして何を保存するかを決めているのは ComfyUI 本体ではなく ComfyUI-LTXVideo の実装なので、版の話は ComfyUI と ComfyUI-LTXVideo で別に見る必要がある。

測っていない次元を挙げておく。

• 生成品質。フレームが一致するかどうかの二値しか測っていない
• 他の解像度・尺・ステップ数
• システムRAM が少ない機材での挙動
• ファイルキャッシュを落とした状態での読み込み
• ComfyUI と ComfyUI-LTXVideo の別の版 (両者は別に見る必要がある)
• 2枚のカードを同時に動かした場合
• キーフレームまで保存する仕組み
• カードの組み合わせ。測ったのは RTX 5080 と RTX 5060 Ti の1組だけ
• カードをまたいだときに出力がどれくらい違うか (一致しないことまでしか測っていない)
• プロセスを立て直しても読み直しが短時間で済んでいる理由

まとめ

使い方ごとに判断が分かれる。

• 同じプロセスで続けて出す: 手を加える理由が測定値から出てこなかった。RTX 5060 Ti の2本目以降は載せ直し要求が0本で、条件付けの保存を足しても所要は重なっている
• 1本ごとにプロセスを立て直す: RTX 5060 Ti では1本あたり 6.47〜7.33秒 縮んだ。RTX 5080 は群内の幅が条件間の差と同じ大きさで、この測定では差を検出できていない
• 2枚のカードを使い分ける: 条件付けのファイルはカードごとに分けて持つ形になる。別のカードで作ったものを読ませた実行は、通常経路と映像56枚・音声73枚のすべてで一致しなくなった
• 画像を渡す: 汎用ノードで保存した条件付けを読ませると、実行は成功として返るのに1枚目と入力画像の平均絶対誤差が 3.796 から 61.925 へ動いた。エラーで止まらないため、出力を見比べるのが確かな手がかりになる (この測定では所要が 160.049秒 から 142.762秒 へ短くなり、モデルの載せ直し要求も1本減っていた)。i2v で回しているなら、この汎用ノードでの保存は選ばない、が結論になる (キーフレームまで保存する仕組みは測っていない)

条件付けの保存は、生成そのものを短くする手段ではない。削れるのはテキストエンコーダの読み込みとエンコードの工程で、その工程を含むサンプリング以外の部分が総時間に占める割合が上限になる。この機材ではサンプリング以外が 12.5% から 23.7% の範囲で、実際に縮んだのは RTX 5060 Ti で総時間のおよそ5%だった。

よくある質問

保存した条件付けはどのくらいの容量になるか

画像を渡さない場合で 430,280バイト、画像を1枚渡した場合で 4,659,400バイト だった。中身を確かめたのは画像なしのほうで、conditioning_data_0 という bfloat16 のテンソル1本、形は [1, 42, 5120] だった。画像ありのファイルは大きさしか測っておらず、大きいことがキーフレームまで保存されていることを意味するわけではない。この記事のプロンプトでの値で、プロンプトが長くなればトークン数が増えてファイルも大きくなる。テキストエンコーダのファイル (15.69GB) とは桁が違う量になる。

プロンプトを変えたらどうなるか

条件付けはプロンプト1件について作られるものなので、プロンプトを変えれば作り直しになる。テキストエンコーダを載せてエンコードするまでの所要は RTX 5080 で 4.687秒、RTX 5060 Ti で 5.054秒 だった (どちらも読み込みを含む値で、すでに載っている状態での再エンコードだけを取り出した値ではない)。プロンプトを毎回変える使い方では、保存したファイルを読ませる先がそもそも無い。同じプロンプトで seed だけを振る使い方が前提になる。

2枚のカードで同じファイルを使い回してよいか

出力を揃えたい場合は分けることになる。RTX 5080 と RTX 5060 Ti で作った条件付けは 215,040 要素のうち 344 要素が違っており、別のカードで作ったものを読ませた実行は通常経路と映像56枚・音声73枚のすべてで一致しなかった。ただし測った向きは RTX 5060 Ti で作ったものを RTX 5080 で使う一方向だけ、カードの組み合わせも1組だけになる。どちらが正しいという判定もしていない。

エラーが出ないなら気付けないのではないか

画像を渡す使い方では、実行が成功として返るのに1枚目が入力画像と揃わなかった。はっきり判別できたのは出力1枚目と入力画像を見比べたときで、平均絶対誤差は通常経路の 3.796 に対して 61.925 だった。この結果は ComfyUI-LTXVideo の汎用ノード (LTXVSaveConditioning) で保存した条件付けを読ませた場合のもので、キーフレームまで保存する仕組みは測っていない。

参考資料

• minimax-h3-speedup (条件付けとラテントのディスクキャッシュ) — https://github.com/pepikir/minimax-h3-speedup
• ComfyUI-LTXVideo — https://github.com/Lightricks/ComfyUI-LTXVideo