LTX 2.5 を 16GB VRAM で回す｜モデル一式28GiBが収まらない状態の所要・RAM・2段構成を実測（RTX 5080 / 5060 Ti 16GB）

16GB で LTX 2.5 は動くのか

RTX 5080 16GB で 4秒・10秒・30秒の3つの尺を生成し、いずれも最後まで完走した。メモリ不足による中断は一度も起きていない。解像度は 1216×672、サンプリングは 8ステップ・CFG=1 の蒸留設定だ。

ただし所要は尺で大きく違う。他のプロセスを止めて連続で取り直した回では、4秒が 106.2秒（5回）、10秒が 281.6秒（3回）、30秒が 707.8秒（3回）。時計に直すと、4秒の動画に約1分46秒、30秒の動画に約11分48秒かかった計算だ。

尺	他を止めて取り直した回	その回の最小〜最大	観測した全回	RAMのピーク
4秒 (97フレーム)	106.2秒（5回・幅 30.4秒）	102.8〜133.2秒	86.0〜508.6秒（29回）	44.1〜48.5GB
10秒 (241フレーム)	281.6秒（3回・幅 18.1秒）	274.0〜292.1秒	188.7〜440.8秒（10回）	45.9〜48.0GB
30秒 (721フレーム)	707.8秒（3回・幅 31.8秒）	698.5〜730.3秒	698.5〜730.3秒（3回）	50.6〜50.7GB

測定条件は RTX 5080 16GB（画面表示にも使用）／システムRAM 95.78GiB／ComfyUI v0.34.5／2026年9月測定。4秒と10秒は、他のプロセスを止めて連続して取り直した回と、観測した全回の範囲を分けてある。30秒だけは連続した取り直しがなく、別々の機会に取った3回で、4つの値すべてが同じ3回から出ている。

観測した全回の範囲には、同じ機体で別の重い処理が動いていた時間帯の回も入る。4秒の 508.6秒 がそれにあたる。RAM のピークは採取間隔が揃う回だけから出しているため、所要の回数とは母数が違う。

公式の必要 VRAM は 32GB と 16GB で割れている

公式ドキュメントのシステム要件は、最低要件として 32GB 以上の VRAM と 32GB のシステムメモリを挙げている。2026年9月時点の記載で、推奨構成はさらに上だ。

NVIDIA GPU with a minimum 32GB+ VRAM – more is better

一方、同じ提供元のモデルページの比較表は、最低 VRAM を Min VRAM: 16GB とし、どの GPU でも動くと記載している。こちらも 2026年9月時点で確認した記載である。

同じ提供元の資料でありながら、最低 VRAM の記載が 32GB 以上と 16GB で食い違っている。どちらか一方が誤りとは言えない。異なる構成や実行経路を想定している可能性はあるが、2026年9月7日に確認した範囲では、食い違いの理由を説明した記載は見つけられなかった。公式のモデルカードは、蒸留版の設定を 8ステップ・CFG=1 と記載したうえで、VRAM が少ない場合の対策として CPU 側への退避を挙げている。

測定に使ったのは、公式が配布するファイルそのものではない。第三者が公開している GGUF 量子化版の本体と、int8 のテキストエンコーダだ。公式の配布物はダウンロードに規約への同意が要り、公式が案内する低 VRAM 経路も別の方式にあたる。公式が挙げる最低 VRAM がどのファイル構成・どの実行経路を指すのかは確認していない。

測定に使ったモデルとワークフロー

LTX 2.5 側で使ったファイルは4つある。本体、テキストエンコーダ、そして映像用と音声用の VAE だ。

役割	ファイル	サイズ
本体 (拡散モデル)	LTX-2.5-Distilled-Q3_K_M.gguf	12.04GiB
テキストエンコーダ	gemma4-12b-with-proj-ltx-2.5-comfy-int8-convrot.safetensors	14.32GiB
映像のVAE	ltx-2.5-video-vae-bf16.safetensors	1.37GiB
音声のVAE	ltx-2.5-audio-vae-bf16.safetensors	0.34GiB

同じ名前でもサイズの違う配布物が存在するので、サイズが照合の手がかりになる。表の4つは丸めた値で、丸める前の合計が 28.06GiB。本体とテキストエンコーダのサイズは、この量子化・この配布元に固有の値だ。配布元へのリンクは載せていない。公式の配布は規約上ダウンロード前に同意が要るためだ。

このワークフローは映像と音声を同時に生成する。一式に音声の VAE が含まれるのはそのためだ。20ノードの構成を段ごとに分けると次のようになる。

段	使ったノード	設定
本体の読み込み	UnetLoaderGGUF	GGUF量子化された本体を読む
テキストの符号化	CLIPLoader と CLIPTextEncode	type は ltxv。肯定文と否定文の2本
latent の用意	EmptyLTXVLatentVideo と LTXVEmptyLatentAudio	映像と音声の latent を作り LTXVConcatAVLatent で連結
サンプリング	SamplerCustomAdvanced	ManualSigmas の 8ステップ / euler_ancestral / LTXVDualCFGGuider は映像も音声も 1.0
デコード	LTXVSeparateAVLatent と VAEDecodeTiled と LTXVAudioVAEDecode	映像と音声の latent を分けてからデコード。画面側のタイル 512・重なり 64、フレームのタイル 64・重なり 16
書き出し	VHS_VideoCombine と SaveAudio	24fps の H.264 と音声

表に出したノードのうち UnetLoaderGGUF と VHS_VideoCombine は ComfyUI 本体に含まれず、別途の導入が要る。ステップ数とガイダンスは、公式のモデルカードが記載する蒸留版の設定に合わせている。映像と音声のガイダンスはどちらも 1.0 だ。シグマ列そのものは公式のモデルカードに記載がなく、手で与えている。デコードは映像と音声で別のノードに分かれており、段別の所要は映像側だけを取っている。解像度と長さは測定条件ごとに差し替えているため、段構成の表には載せていない。ここに出したのは1段だけの構成で、公式が案内する2段構成、つまり一度作ってから解像度を上げ直す手順とは別の構成だ。

16GB に載っていないのに動く理由

ファイルの合計は 28.06GiB。対して、ComfyUI が起動時に認識した VRAM の総量は 15.92GiB だった。この値は測定機で ComfyUI が報告した総量で、GPU の公称容量そのものではない（公称は 16GB）。一式が同時に載る余地は無い。

実行時のログには、本体を全部は載せきれず 3198.56 MB ぶんをホスト側へ回したことが記録されている。1216×672・241フレームの回だ。

loaded partially; 9255.36 MB usable, 9234.68 MB loaded, 3198.56 MB offloaded, 20.67 MB buffer reserved, lowvram patches: 0

同じログには、続いて VAE を載せるために本体の一部を解放した記録も残る。これはこの構成・この実行経路での観測であり、すべての構成が同じ順に載せ替えるとは限らない。

載せ替えは生成中の VRAM 占有にも現れる。512×320・41フレームでは、プロンプトを毎回変える条件で GPU 上のメモリが 799MiB まで落ちてから積み直された。同じプロンプトを繰り返す条件では 12163MiB までしか落ちない。他の解像度でも同じ向きの差が出ている。

ここで入れ替えと呼んでいる現象には、3つの動きが混じっている。段の切り替えに伴う載せ替え、重みを毎回ホスト側から流し込む分、そしてプロンプトを変えたときのテキストエンコーダの載せ替えだ。重みを流し込む仕組みは、実装上 Nvidia の GPU で既定有効と記載されている。秒数として分離できたのは3つ目だけだ。転送の観測は、少なくともこの3つを含む転送をまとめて見ており、種類別には分離していない。

プロンプトを毎回変えると 6.46秒 増える

入れ替えの代償を秒で取り出すなら、基準となる生成時間が短い条件のほうが都合がよい。512×320・41フレームで、同じプロンプトを繰り返す条件と毎回変える条件を5回ずつ回した。

プロンプトの与え方	所要	条件内の幅	テキストエンコード	プロセスのRAM	生成中のVRAM最小値	回数
同じものを繰り返す	29.77秒	0.87秒	0.00秒	8.1GB	12163MiB	5回
毎回変える	36.23秒	8.09秒	4.45秒	34.7GB	799MiB	5回

差は 6.46秒 だった。うち 4.45秒 はテキストエンコード実行そのものだった。残る約 2.01秒 には、テキストエンコーダのロードや関連する転送・処理が含まれるが、この測定では内訳を分離していない。秒数はこの条件に固有で、基準時間の違う条件へ割合として持ち出すことはできない。

同じ比較を 1216×672・97フレームでも取った。中央値は繰り返す側が 105.0秒、毎回変える側が 106.2秒。ところが条件内の幅が 13.3秒 と 30.4秒 あり、差はその中に埋もれた。差が無いことを確かめたわけではなく、この振れ幅では取り出せなかった、というだけである。

プロンプトの与え方	所要の中央値	条件内の幅	プロセスのRAM	生成中のVRAM最小値	回数
同じものを繰り返す	105.0秒	13.3秒	23.7GB	9181MiB	5回
毎回変える	106.2秒	30.4秒	47.8GB	978MiB	5回

前世代との比較も同じ 512×320・41フレームで取った。LTX 2 19B の GGUF 構成では、同じ比較の差が 9.04秒 だった。

プロンプトの与え方	所要	条件内の幅	回数	構成
同じものを繰り返す	22.84秒	0.21秒	5回	LTX 2 19B の GGUF
毎回変える	31.88秒	2.46秒	5回	LTX 2 19B の GGUF

ただし、この 9.04秒 と 6.46秒 は同じ範囲を測っていない。測定した新しい構成では、同じプロンプトを繰り返す側でも転送が動き続けている状態が観測され、旧世代の側では同じ条件でほとんど観測されなかった。引き算の基準側が揃っていないので、差の大小を入れ替えの重さの比較として読むことはできない。ファイル構成そのものも違う。

構成	本体	テキストエンコーダ	その他	合計
測定した新しい方	12.04GiB	14.32GiB	1.71GiB	28.06GiB
比較に使った前世代 (LTX 2 19B の GGUF)	11.78GiB	6.80GiB	4.95GiB	23.53GiB

本体もテキストエンコーダも量子化も違い、新しいほうは映像と音声を同時に生成するのに対し、前世代の構成に音声の段は無い。ワークフローそのものが別だということになる。なお、LTX 1 と LTX 2.3 を同じ 16GB の GPU で測った結果は別記事にある。ここで比較に使っている LTX 2 19B とは別のモデルだ。

転送が動き続けている割合は尺に比例しない

段ごとに載せ替えているなら、GPU とホストの間では転送が続いているはずだ。PCIe の受信スループットを1秒ごとに1回だけ採り、毎秒1000MB を超えたサンプルの割合を尺ごとに集計した。各サンプルが表すのは直前およそ20ミリ秒ぶんのスループットで、サンプルとサンプルの間に起きた転送は観測できない。

尺	回数	転送が続いていたサンプルの割合	スループットの中央値	スループットのピーク
4秒 (97フレーム)	29回	58.4%	1667MB/s	54370MB/s
10秒 (241フレーム)	10回	83.1%	2048MB/s	51042MB/s
30秒 (721フレーム)	3回	5.4%	54MB/s	17306MB/s

もっとも高いのは 10秒の 83.1%、次いで 4秒の 58.4%、もっとも低いのが 30秒の 5.4% だった。尺が伸びるほど下がるわけでも、尺に比例して上がるわけでもない。閾値を 100 から 10000 まで振っても、3つの順序は変わらなかった。

この割合が表すのは、転送が動き続けている状態がどれだけ観測されたか、である。転送は生成の計算と並行して走るため、割合がそのまま所要への上乗せ分に対応するわけではない。1本の生成で合計どれだけ流れたかは測っていない。

回数も揃っていない。30秒は3回しか取っておらず、その3回が偶然そろった可能性は排除できていない（3回の割合は 5.2% から 6.4% に収まった）。ホスト側の確保を無効にした回は既定の構成ではないので、この集計から外してある。尺別の表に載せた4秒と10秒の回は別の機会に取ったもので、この集計には入っていない。30秒だけが同じ3回だ。

VRAM ではなく RAM を見る

解像度を 768×512 から 1216×672 へ上げたとき、何が動いて何が動かないかを並べた。

量	768×512のとき	1216×672のとき	解像度で動くか
GPU側に置けた分のピーク	15639MiB	15877MiB	動かない
ホスト側に置かれるGPUから見えるメモリ (モデル投入時)	12404MiB	12061MiB	動かない
ホスト側に置かれるGPUから見えるメモリ (生成中)	2002MiB	3365MiB	ほとんど動かない
プロセスが使うRAM	34.6GB	48.5GB	動く
生成中のVRAM最小値	837MiB	1033MiB	動かない

GPU 側に置けた量は 15639MiB と 15877MiB で、上限に張り付いたままだ。生成中の VRAM 最小値も 837MiB と 1033MiB で、解像度では動かない。大きく動いたのはプロセスが使う RAM だけで、34.6GB から 48.5GB へ伸びた。この増分が何にあたるかは分けて測っていない。解像度は2水準しか取っていないので、中間の挙動も分からない。

プロンプトの与え方でも RAM は動く。1216×672・97フレームでは、毎回変える側のプロセス RAM が 47.8GB、繰り返す側が 23.7GB で、差は 24.1GB あった。秒数としては振れ幅に埋もれた差が、メモリにははっきり出る。一方で本体側の載せ替えは繰り返す側でも起きており、そちらの生成中の VRAM 最小値も 9181MiB まで落ちている。テキストエンコーダの載せ替えが加わるかどうかの差であって、載せ替えが起きるか起きないかの差ではない。

VRAM の割り当てを絞ったときに所要がどう動くかは、別の切り口の測定にある。ComfyUI が RAM を大きく使う例としては、動画のアップスケールを測った記事もある。

ホスト側の確保を切ると RAM が減る（この機体で 15.0GB）

ComfyUI は既定で、ホスト側のメモリを固定して確保する。この確保は起動時に --disable-pinned-memory を付けると無効になる。1216×672・97フレームで、既定のままと無効にした場合を比べた。

設定	ホスト側のGPUから見えるメモリ (モデル投入時)	プロセスのRAM	所要の最小〜最大	回数
既定のまま	12061MiB	48.5GB	86.4〜116.2秒	5回
起動時に無効にする	914MiB	33.5GB	84.0〜94.1秒	3回

プロセスが使う RAM は 48.5GB から 33.5GB へ、15.0GB 減った。所要は既定のまま5回で 86.4〜116.2秒、無効にして3回で 84.0〜94.1秒。この回数では差を検出できず、速いとも遅いとも判定していない。ホスト側の確保の比較は、尺別の表とは別の機会に取り直したものだ。

あわせて、モデル投入時にホスト側へ置かれていた 12061MiB が 914MiB まで落ちている。この指標の大部分は、ホスト側の確保を有効にした実行経路に由来している。ただし 12061MiB 全体の内訳は分けて測っていない。ホスト側に置かれる分を、VRAM に収まりきらなかった残りとして読むことはできない。

確保できる量には天井がある。実装には、ホスト側に固定して置ける量を搭載メモリの 40%（Windows の場合）までとする記述がある。これは累計に対する上限で、超えそうになると古い分を解除して空ける仕組みだ。この機体の搭載 95.78GiB に対する 40% は約38GiB にあたり、モデル投入時の 12061MiB はそこに届いていない。上限に届いていない範囲では、搭載量から減り方を見積もることもできない。

測定は Windows で行っており、上限の決め方は環境によって違う。実装では、ホスト側に固定して置ける量の上限が搭載メモリの 40% に設定される。実際にその量を使うという意味ではなく、実際の登録量は増減する。

RTX 5060 Ti 16GB では 4秒の生成に約3分40秒

同じワークフローを、画面表示に使っていない RTX 5060 Ti 16GB でも動かした。4秒の生成にかかった時間は中央値 219.5秒、時計にすると約3分40秒だ。画面表示にも使っている RTX 5080 の中央値は 106.2秒（5回）で、こちらは約1分46秒にあたる。

GPU	所要の中央値	条件内の幅	サンプリングの最良	VAEデコードの最良
RTX 5080 (画面表示にも使用)	106.2秒	30.4秒	47.2秒	25.1秒
RTX 5060 Ti 16GB (画面表示に使わない)	219.5秒	1.6秒	91.8秒	118.2秒

段別に見ると、差の出方が偏っている。サンプリングの最良は 47.2秒 と 91.8秒。ところが映像側の VAE デコードの最良は 25.1秒 と 118.2秒 で、5080 の最良値に対して 4.7倍 だった。音声側のデコードはこの値に含めていない。突出しているのはデコードの段である。

2枚はどちらも GeForce RTX 50 シリーズだが、等級（チップとメモリ帯域）も接続方式も違い、片方は画面表示にも使っている。この差を単一の要因に帰することはできない。5080 側の段別は観測した最小値で、回数を揃えた中央値の比較でもない。この比較で RTX 5060 Ti 16GB から取ったのは 4秒だけだ。同じ GPU では、2段構成の比較で別の解像度と尺も測っている。

公式の2段構成をもとに比べると、総所要の中央値は2枚の GPU で逆を向いた

公式は、低い解像度で一度作ってから解像度を上げ直す2段構成のワークフローと、1段で作る構成の両方をサンプルとして配っている。ここまでの測定はすべて1段の側にあたる構成だ。最終の出力を 1280×704・121フレームで揃え、2段と1段の両方を2枚の GPU で回した。1段の側は 1280×704 で8ステップ、2段の側は 640×352 で8ステップ作ってから映像の latent を2倍に上げ、1280×704 で3ステップ回す。本体はここまでと同じ量子化版のままで、段構成だけを入れ替えている。2段構成では、上げ直しの段で使うモデルが1つ加わる。

GPU	構成	総所要	サンプリング	映像のデコード	RAMのピーク
RTX 5060 Ti 16GB (画面表示に使わない・3回)	2段	310.6秒	89.1秒	210.5秒	34.7GB
RTX 5060 Ti 16GB (画面表示に使わない・3回)	1段	294.5秒	123.3秒	161.6秒	46.5GB
RTX 5080 16GB (画面表示にも使用・5回)	2段	96.2秒	46.1秒	42.8秒	36.5GB
RTX 5080 16GB (画面表示にも使用・5回)	1段	111.9秒	64.2秒	39.5秒	47.2GB

サンプリングの削減は2枚とも出た。5060 Ti で 34.2秒、5080 で 18.1秒 短い。5080 では回ごとの値も重ならず、2段が 45.4〜47.0秒、1段が 59.3〜73.0秒 に分かれている。低い解像度で8ステップぶん作り、高い解像度では3ステップしか回さない、という構成の差と向きが合っている。

分かれたのはデコードの段だった。5060 Ti では2段が 48.9秒 長く、しかも回ごとの幅が 0.4秒 しかない。5080 では中央値の差が 3.3秒 で、回ごとの幅（2段 30.7〜59.5秒、1段 35.1〜68.8秒）に埋もれている。

結果として、総所要の中央値の向きが2枚で逆になった。5060 Ti は2段が 16.1秒 遅く、観測した3回では範囲が重ならなかった（2段 310.3〜311.3秒、1段 294.4〜296.5秒）。5080 は中央値で2段が 15.7秒 速い。ただしこちらは回ごとの範囲が重なっており（2段 83.8〜115.6秒、1段 102.9〜148.8秒）、総所要の差を確かめたとは言えない。5080 で確かなのはサンプリングの側だけだ。

5060 Ti でデコードが総所要に占めるのは1段で約55%、2段で約68% にのぼる。5080 では2段でも 45% 程度で、比重そのものが違う。今回2枚に共通して短くなったのはサンプリングで、5060 Ti ではその短縮ぶんをデコードの増加が上回った。

5060 Ti でデコードが伸びた理由は分けて測っていない。タイルの設定も出力の寸法も同じで、書き出された動画はどちらも 1280×704・121フレーム・24fps だった。デコードに入る時点で GPU に載っているモデルの量も、両構成でほぼ変わらない。2段構成は本体の常駐が多いが、1段構成では音声の VAE が先に載るぶんで釣り合っている。

一方で、プロセスが使う RAM のピークは2枚とも2段構成の方が低い。5060 Ti で 11.8GB、5080 で 10.7GB の差があり、どちらも回ごとの範囲が重ならない。ログに残る違いは、1段で 1280×704 を回したときに本体の重みが VRAM に入りきらず、845MB がホスト側へ退避されている点だ。2段構成では読み込みの時点で退避が出ない。退避された量そのものは 845MB で、観測した RAM の差 10.7〜11.8GB の10分の1にも満たない。この2つを直接つなげることはできない。VRAM のピークは4通りとも 15800〜16022MiB の範囲で、上限近くに張り付いている。RAM のピークが下がる向きは2枚で同じで、機体によって変わったのは時間の側だけだ。

2段構成でも、本体は1段目と2段目の間で降ろされない。上げ直し用のモデルを載せるために 533MB、2段目に入る前にさらに 435MB が押しのけられ、11485MB は載ったまま2段目へ進む。1段構成が同じ解像度を回すときの常駐は 11588MB で、ほとんど変わらない。モデルが5つに増えても、押しのけられたのは合わせて 968MB だ。

公式のサンプル一覧は、1段構成を Faster and lighter、2段構成を the better default when you care about spatial detail と説明している。速さについては、5060 Ti でその位置づけどおりになり、5080 では中央値の向きが逆になった。ディテールの側は測っていない。公式の構成に含まれるプロンプト強化のモデルは、プロンプトそのものを書き換えて比較が成立しなくなるため外した。本体も公式が指定する形式ではなく、記事の他の測定と揃えた量子化版だ。

動くことと出来上がりの良さは別で、分割の痕跡が数値に残っていた

完走したかどうかと、出来上がった動画が良いかどうかは別の話だ。ここまで測ってきたのは所要とメモリの側で、画の良し悪しは見ていない。その出来上がりの側で、ひとつだけ測れる形の指標がある。VRAM のピークを下げるために入れている設定が、出力に痕跡を残していないかだ。見たのは映像の VAE デコードをタイルに分割する設定だ。

公式のガイドは、2段構成の手順のなかでタイル分割に触れ、reduce peak VRAM at the cost of slightly slower decoding と書いている。そのページが調整先に挙げているのはタイルの数と重なりだ。フレーム方向の分割そのものは、公式が別に配っているノード (LTXVSpatioTemporalTiledVAEDecode の temporal_tile_length と temporal_overlap) で扱われている。ここで変えたのは ComfyUI 本体の VAEDecodeTiled の側だ。分割の幅は設定で決まる。以下では、タイルとタイルが切り替わる位置を継ぎ目と呼ぶ。実装上どこで切り替わるかの話で、目に見えるかどうかとは別だ。この測定の設定、つまりフレームのタイル 64・重なり 16 では、継ぎ目が 48フレームごと、24fps で 2.00秒ごとに来る。重なりはノードの既定が 8 で、そちらだと 56フレームごとだ。

継ぎ目が立つのはタイルとタイルが重なるところなので、1枚目が始まる 0秒と、最後のタイルが終わる 30秒には来ない。30秒・721フレームだと、フレームのタイル 64 で14か所、128 で6か所、256 では2か所になる。

同じ seed・同じプロンプト・同じ 1216×672 で30秒の動画を作り、フレームのタイルだけを 64・128・256 と変えて、設定ごとに1本ずつ書き出した。この構成は同じ seed なら別々の実行でも同じ画を返す。既定の設定で別々に回した2本を突き合わせると、721フレームすべてが画素まで一致した。したがって3本で違うのはデコードの分割だけだ。書き出された動画から隣り合うフレームの差の大きさを並べ、継ぎ目が来る位置の前後2フレームと、それ以外を比べた。フレームはグレースケールに落として縮小してから差を取っている。重なりは16フレームぶんあるので継ぎ目は点ではなく幅があり、窓の取り方を変えれば値も動く。

測った位置	タイル 64 の動画	タイル 128 の動画	タイル 256 の動画
タイル 64 の継ぎ目 (14か所)	0.978	1.005	1.002
タイル 128 の継ぎ目 (6か所)	1.048	1.016	1.051
タイル 256 の継ぎ目 (2か所)	1.110	1.136	1.104
継ぎ目と無関係な 55フレーム周期 (13か所)	1.032	1.032	1.026

1.0 なら継ぎ目の前後とそれ以外で動きの大きさが同じ、1.0 を下回れば継ぎ目の前後で動きが小さい。同じ継ぎ目の位置で3本を比べると、いちばん低いのは、その継ぎ目を持つ設定で作った動画になる。3通りともそうだった。継ぎ目と関係のない 55フレーム周期では、3本とも 1.03 前後で並ぶ。

ただし 1.0 を下回ったのは既定のタイル 64 だけで、その動画の継ぎ目で 0.978 だった。128 と 256 は自分の継ぎ目でも 1.0 を超えている。継ぎ目が6か所と2か所しかなく、この本数では小さな差を拾えない。はっきり出ているのは既定の設定だけだ。

この落ち込みが目で分かるかどうかは判定できなかった。注意して見ると不自然な箇所はあるが、それがタイル分割によるものかどうかまでは切り分けられない。下の2本は、上が継ぎ目 2秒ごと、下が 10秒ごとで、ほかの条件は同じだ。

測ったのは 1216×672・30秒・ひとつのプロンプトで、設定ごとに1本ずつ。指標は動きの大きさひとつ、対照に置いた周期も 55フレームの1つだけだ。使ったのはフレームのタイル 64 という既定値で、この尺と解像度を分割なしでデコードできるかは測っていない。

既定の設定では、VRAM のピークを下げるための分割が数値としては出力に届いている。それが見て分かる差になっているかは、この測定では決められない。完走したことと出来上がりが良いことは別だ、という一点までが言える範囲だ。

同じ設定でも所要が再現しないことがある

2枚の間では、同じ条件を繰り返したときの幅がはっきり違った。RTX 5060 Ti 16GB は5回繰り返して幅 1.6秒 に収まり、RTX 5080 は幅 30.4秒 だった。ただし原因は特定していない。等級も接続方式も違い、片方は画面表示にも使っているうえ、同じ GPU で画面表示のあり・なしを揃えた対照も取っていない。

幅は、他のプロセスを止めて取り直しても残った。4秒の連続5回は 102.8秒 から 133.2秒 まで振れている。同じ機体で別の重い処理が動いていた時間帯の回まで含めると、86.0秒 から 508.6秒 まで開く。後者には外部の負荷と重なった回が入っており、取り直した回の幅とは別のものだ。30秒は3回しか取っていないため、幅の大きさ自体も定まっていない。

この測定で見ていないこと

• 1080p 以上・4K での可否と所要
• 768×512 と 1216×672 の中間の解像度
• 目視による画質の評価と用途への向き不向き
• 音声の品質
• 2段構成を 1280×704 以外の解像度で回したときの向き
• プロンプト強化のモデルを含めた完全な公式構成
• 1本の生成で流れた転送の合計量
• 段の切り替え・重みの流し込み・テキストエンコーダの載せ替えを個別に分けた測定
• RTX 5060 Ti 16GB での 10秒・30秒
• Windows 以外の環境でのホスト側確保の挙動
• 別の量子化・別の配布物での再現

よくある疑問

システムメモリが 32GB の機体でも足りるのか

この測定からは決められない。測ったのは搭載 95.78GiB の機体で、ホスト側に固定して置ける量の上限は搭載RAM量に応じて変わる。搭載量が違えば確保のされ方そのものが変わるため、この機体の占有量をそのまま別の機体へ持ち出せない。手がかりになるのは、確保を無効にした回でもプロセスが使う RAM が 33.5GB（約 31.2GiB）あったことだ。32GB クラスの搭載容量に近く、さらに OS や他のプロセスのぶんも要る。ただし 32GB 搭載の機体では実測していないため、完走できるかどうかは判断できない。

同じ設定なのに所要が違うのはなぜか

この測定では分かっていない。切り分けられたのは、外部の重い処理と重なった回を除いても幅が残ること、そして同じワークフローでも別の GPU では幅がずっと小さかったこと、の2点までだ。単発の値をその構成の代表として扱えない条件がある、というところが範囲になる。

RTX 5080 と RTX 5060 Ti 16GB のどちらを選ぶか

どちらかを選ぶ根拠は、この測定には無い。4秒の生成にかかる時間は 5080 側が短く、繰り返したときの幅は 5060 Ti 側が小さかった。ただし2枚は等級も接続方式も違い、片方は画面表示にも使っている。2枚を比べたのは所要とメモリで、生成物の画質や用途への向き不向きは比較に入っていない。16GB クラスをどう選ぶかは、VRAM 16GB GPU を選ぶなら｜AI 用途別に比較で 5060 Ti・5070 Ti・5080 を用途別に並べている。

まとめ

第三者が公開している量子化版の一式（合計 28.06GiB）を 1216×672・8ステップ・CFG=1 で回した範囲では、16GB の GPU で 4秒から 30秒までの生成が完走した。モデル一式は VRAM に載りきらず、段ごとの載せ替えで動いている。

入れ替えの代償は、メモリの側にはっきり出た。プロンプトを毎回変える条件ではプロセスの RAM が 24.1GB 多く、解像度を上げて動いたのも RAM だけだった。ホスト側の確保を無効にすれば、この機体では 15.0GB 減る。

秒数として取り出せたのは 512×320 での 6.46秒 だけで、1216×672 では条件内の振れ幅に埋もれた。その振れの由来は分けられていない。転送が動き続けていた時間の割合も尺には比例せず、10秒がもっとも高かった。

公式の2段構成をもとにした比較も、2枚の GPU で同じ 1280×704 を作る条件で行った。サンプリングはどちらでも短くなり、RAM のピークもどちらでも低い。総所要は 5060 Ti で 16.1秒 遅く、5080 では中央値で 15.7秒 速い。分かれたのはデコードの段で、5060 Ti だけ 48.9秒 伸びた。

映像のデコードをタイルに分割する設定は、フレームのタイル 64・重なり 16 (重なりの既定は 8) で数値の差として出た。継ぎ目 14か所の前後で隣り合うフレームの差の比が 0.978、継ぎ目と関係のない周期では 1.032 だった。ほかの2設定は継ぎ目が6か所と2か所しかなく、判定できていない。完走したことと出来上がりが良いことは別だ。

この測定で大きく増えたのは、VRAM の使用量ではなくシステムRAM だった。メモリ不足による中断は一度も起きておらず、どこで足りなくなるかは測っていない。測った中でもっとも大きい解像度は 1280×704 だ。

参考資料

• LTX 公式ドキュメント System Requirements
• LTX-2.5 公式モデルページ
• Lightricks/LTX-2.5 モデルカード（Hugging Face）
• ComfyUI v0.34.5 model_management.py（ホスト側確保の実装）
• 測定に使った検証環境
• ComfyUI v0.34.5 cli_args.py（起動オプションの定義）
• ComfyUI v0.34.5 nodes.py（タイル分割の間隔の導出）
• ComfyUI v0.34.5 comfy/utils.py（タイル開始位置＝継ぎ目の導出）
• LTX 公式ドキュメント LTX ComfyUI Nodes（フレーム方向の分割ノード）
• ComfyUI issue #15595（LTX 2.5 のローダの既知問題）
• LTX 公式ドキュメント Two-Stage Generation（2段構成の手順）
• Lightricks ComfyUI-LTXVideo の 2.5 用サンプル一覧（1段構成と2段構成の位置づけ）