【DGX Spark実機】動画生成AIをローカルで動かす手順──専有VRAMのないGB10(128GB・aarch64)にLTX-2.3を入れ、10秒動画を116秒で出すまで

この記事でわかること

• 専有VRAMという区分を持たない統合メモリ機(DGX Spark / GB10・128GB・aarch64)でも、LTX-2.3のローカル動画生成は動きます。本記事の所要時間はすべて筆者環境での一次実測であり、第三者が検証できる公開情報源はありません。再現条件は2026-07-18計測、LTX-2.3 22B distilled 1.1、量子化fp8-cast、24fps、Image-to-Videoで、1本あたり512×960・10秒(241フレーム)が116秒、704×1216・10秒(241フレーム)が182秒でした
• 導入に必要なディスクは重みだけで約71.5GB(SI表記)。aarch64向けのwheelは公式に明記されていませんが、PyPIのltx-pipelinesとtorch 2.13.0はそのまま入りました
• ComfyUI-LTXVideoが書く「32GB+ VRAM」という要件が、統合メモリ機では何に対応するのか。実測のMemFree推移の落ち込みで答えます
• 導入時に実際に出た3つのエラー(循環インポート・SiglipVisionModel・metaテンソル)と、システムごと落ちたOOMの原因・対処
• LTX-2.3の重みライセンスと商用利用の線引き(年間売上1,000万ドルの閾値)

1. なぜローカルなのか、この記事は誰向けか

クラウドの動画生成サービスは、たたむときは一斉にたたまれます。OpenAIはSoraをローンチから約半年で終了し、ディズニーとの提携も解消しました(/posts/openai-sora-shutdown-disney-deal/)。従量課金とアップロード制限に加えて、そもそもサービスが来年もある保証がない。これがローカル実行を選ぶ実務的な理由です。

この記事は次の条件に当てはまる人向けです。

• Linux + NVIDIA GPU環境を自分で管理できる
• 重み約71.5GBを置けるディスクがある
• 1本あたり2〜4分の待ちを許容できる

そして、この記事が特に扱うのは専有VRAMを持たない統合メモリ機です。DGX Spark(GB10)やApple Silicon系のように、CPUとGPUが同じ物理メモリを共有する構成では、「VRAM 16GB / 24GB / 32GB」という一般的な物差しがそのまま使えません。ここが検索上位のページで空白になっている部分です。

なお本記事はモデル比較記事ではありません。LTX-2.3が他の動画生成モデルより良いかどうかは扱わず、「入れて回す」ことだけを扱います。

2. 検証環境

この表のカーネル・Python・PyTorch・CUDA関連の各バージョンは、いずれも筆者環境で実際に解決された構成の記録であり、公開情報源で第三者が検証できる性質のものではありません。ディストリビューション名とバージョン文字列は今回の記録に残っていないため、カーネル版のみを載せます。x86 + 単体GPUの比較機は手元にないので、他環境との横並び比較はこの記事では行いません。

版差についてひとつ注意があります。LTX-2公式リポジトリの現行推奨はLTX-2.5で、READMEのダウンロード例もLightricks/LTX-2.5を指しています(GitHub Lightricks/LTX-2、2026-09-08確認)。一方でComfyUI-LTXVideo側は同梱ワークフローがLTX-2.3とLTX-2.0で、2026-09-08時点のドキュメントにLTX-2.5の記載はありません。今回の実測はLTX-2.3です。

3. LTX-2.3とは

Lightricksが公開している動画生成モデルで、Hugging Faceのモデルカードでは「a DiT-based audio-video foundation model designed to generate synchronized video and audio within a single model」と説明されています(Lightricks『LTX-2.3 Model Card』、Hugging Face、2026-09-08確認)。映像と音声を1つのモデルで同時に出す点が構造上の特徴です。

系譜としては、旧世代のLTX-Video v0.9.8系からLTX-2系へ開発の主軸が移り、現在はLTX-2.5が最新という並びになります(GitHub Lightricks/LTX-Video、2026-09-08確認)。ライセンスはコードと重みで別で、LTX-VideoリポジトリのコードはApache-2.0、0.9.8系の重みはLTX-Video Open Weights License配下です(2026-09-08確認)。動画・音声・行動予測を単一バックボーンへ寄せる流れは他社にもあり、Black Forest LabsのFLUX 3も同じ方向です(/posts/flux-3-multimodal-flow-model-video-audio-action-2026/)。

今回使ったのは8ステップのdistilled版で、CFGを使わないためネガティブプロンプトは効きません。生成は2段構成です。第1段が最終解像度の半分で拡散し、そこにx2のspatial upscalerを掛けて第2段に渡します。

4. できることとできないこと

できること。

• Text-to-Video、およびImage-to-Video(静止画を先頭フレームの条件にする)
• 映像と同期した音声の同時生成
• 解像度は32の倍数。ただし第1段が半分の解像度になるため、実質64の倍数を渡す必要があります
• フレーム数は8の倍数プラス1のみ有効です。$N$ をフレーム数、$k$ を自然数として

モデル仕様として公開されているのはこの $N = 8k + 1$ という条件だけで、$k$ の上限やfpsの固定はここには含まれません。今回のアプリでは24fps固定とし、指定の尺から求めたフレーム数を「最も近い上側の有効値へ切り上げる」規約を自前で置いています。この規約のもとで計算すると、7秒は169フレーム($8 \times 21 + 1$)、10秒は241フレーム($8 \times 30 + 1$)、12秒は289フレーム($8 \times 36 + 1$)になります。切り下げを選べば161・233・281となり値が変わるとおり、丸め方向はアプリ側の実装上の選択であってモデルの仕様ではありません。いずれにせよUI側で丸めておかないとパイプラインに弾かれます。

できないこと、および今回の構成での制約。

• distilled版はネガティブプロンプト非対応
• 拡散途中のステップ単位の進捗は取れません(パイプラインにステップコールバックがないため、進捗表示はモデルロード→生成→エンコードの粗い3段階になります)
• 長尺は1本では伸びません。今回のアプリでは、前シーンの最終フレームを次シーンのImage-to-Video条件にして連鎖生成し、後でMP4を連結しています。この方式はフレーム1枚しか引き継がないため、シーンをまたぐと被写体の同一性が完全には保たれません
• モデルカードには「When generating audio without speech, the audio may be of lower quality」という限界が明記されています(Lightricks『LTX-2.3 Model Card』、Hugging Face、2026-09-08確認)

5. 導入手順

5-1. 依存パッケージを入れる

公式リポジトリの手順はuv sync --extra nattenです(GitHub Lightricks/LTX-2、2026-09-08確認)。nattenは映像VAEの最速バックエンドで、READMEにはLinux + CUDA専用、WindowsとmacOSでは自動フォールバックすると書かれています。

今回はリポジトリをcloneせず、PyPIのltx-pipelinesを直接入れる経路を取りました。

uv init ltx-studio && cd ltx-studio
uv add ltx-pipelines huggingface-hub imageio-ffmpeg accelerate
uv sync

成功したときの見え方: uv syncが77パッケージを解決し、ltx-core==1.0.0とltx-pipelines==1.0.0、torch==2.13.0が入ります。以下は筆者環境での1回の実行結果で、回線速度とキャッシュ状態に依存する値です(公開情報源では検証できません)。実際のログでは解決に753ms、ビルド準備に27.93秒、インストール本体は116msでした。ダウンロード量が大きいのはCUDAランタイム側で、nvidia-cublasが517.7MiB、nvidia-cudnn-cu13が424.0MiB、torch本体が407.4MiBです。

aarch64について、LTX-2公式リポジトリが挙げる対応プラットフォームはLinux+CUDA / Windows / macOSで、ARM64・aarch64・DGX・Jetsonへの言及はありません(2026-09-08確認)。ただし今回の環境では、上記の依存一式がaarch64向けwheelとしてそのまま解決・インストールされ、ソースビルドは発生しませんでした。「非対応と書かれている」のではなく「言及がない」という状態です。

5-2. 重みを取得する

必要なのは3点です。

hf download Lightricks/LTX-2.3 ltx-2.3-22b-distilled-1.1.safetensors --local-dir models
hf download Lightricks/LTX-2.3 ltx-2.3-spatial-upscaler-x2-1.1.safetensors --local-dir models
hf download google/gemma-3-12b-it-qat-q4_0-unquantized --local-dir models/gemma-3-12b

筆者環境での実測の内訳をSI表記(1GB = 10^9バイト)に揃えると、distilled本体が46.1GB、Gemma-3-12Bのシャード5本が合計約24.4GB、spatial upscalerが約1.0GBで、合計およそ71.5GBです(2進表記に揃えるなら約66.5GiB)。du -hなどの2進表記とSI表記を混ぜると合計が合わなくなるので、単位系は揃えて読んでください。参考までに、LTX-2公式リポジトリがLTX-2.5一式に示す総量はおよそ66GiBです(2026-09-08確認)。数十GB単位のダウンロードなので、切断で止まらないようバックグラウンド実行を推奨します。

nohup .venv/bin/python scripts/download_models.py > logs/download.log 2>&1 &

ここで最初に詰まります。Gemma-3-12BはHugging Face上でライセンス同意が必要で、未同意のまま叩くと403が返ります。ブラウザでgoogle/gemma-3-12b-it-qat-q4_0-unquantizedのページを開き、Agreeを押してから再実行してください。

もうひとつ、Gemmaはシャード分割されているため、部分ダウンロードのまま起動すると後段で落ちます(後述のエラー2・3の正体がこれです)。model.safetensors.index.jsonのweight_mapに載っている全シャードが揃っているかを、起動前にチェックするコードを入れておくと事故が減ります。

import json
from pathlib import Path

root = Path("models/gemma-3-12b")
index = json.loads((root / "model.safetensors.index.json").read_text())
shards = set(index["weight_map"].values())
print(all((root / s).exists() for s in shards))

成功したときの見え方: Trueが出れば揃っています。

6. 最初の1本を出す

公式CLIはuv run python -m ltx_pipelines.distilledにパスを並べる形ですが、ここではPython APIを直接叩く最小構成を載せます。今回のアプリが実際に呼んでいるコードそのものです。

from ltx_pipelines.distilled import DistilledPipeline
from ltx_core.quantization import QuantizationPolicy
from ltx_core.model.video_vae import TilingConfig, get_video_chunks_number
from ltx_pipelines.utils.media_io import encode_video

pipe = DistilledPipeline(
    distilled_checkpoint_path="models/ltx-2.3-22b-distilled-1.1.safetensors",
    gemma_root="models/gemma-3-12b",
    spatial_upsampler_path="models/ltx-2.3-spatial-upscaler-x2-1.1.safetensors",
    loras=[],
    quantization=QuantizationPolicy.fp8_cast(),
)

tiling = TilingConfig.default()
video, audio = pipe(
    prompt="a cat walking slowly across a wooden floor",
    seed=42, height=960, width=512, num_frames=241, frame_rate=24,
    images=[], tiling_config=tiling, enhance_prompt=False,
)
encode_video(video=video, fps=24, audio=audio, output_path="out.mp4",
             video_chunks_number=get_video_chunks_number(241, tiling))

注意点がひとつあります。ltx_core.quantizationをltx_core.loaderより先にimportすると循環インポートで落ちます。上のコードのようにDistilledPipelineを先にimportしてください(エラー1の再発防止)。

成功したときの見え方: 標準出力に8ステップのtqdmバーが出て、続いて3ステップのバーが出ます。最後に次の行が出れば完了です。

Image-to-Videoにする場合はimagesに条件画像を渡します。

from ltx_pipelines.utils.args import ImageConditioningInput
images = [ImageConditioningInput(path="start.png", frame_idx=0, strength=1.0)]

enhance_prompt=TrueにするとGemmaがプロンプトを拡張します。品質は上がりますが所要時間も伸びます(実測は次章)。

7. ComfyUI経路を使う場合

GUIから入りたい場合はComfyUI-LTXVideoが用意されています。導入はComfyUI Managerから「LTXVideo」を検索してインストールし、再起動するだけです(GitHub Lightricks/ComfyUI-LTXVideo、2026-09-08確認)。LTX-2.3向けにT2V、I2V、IC-LoRA、Dub-It、HDR、Pixel Upscaler、T2Aの8本のサンプルワークフローが同梱されており、LTX-2.0系のレガシーワークフローも7本残っています。

今回この経路は実行していません。 以下は同リポジトリのドキュメント記載であって、DGX Sparkでの動作確認結果ではありません。

• 最小要件は「CUDA-compatible GPU with 32GB+ VRAM」
• ディスクは「100GB+ free disk space for models and cache」
• VRAMが足りない場合はlow_vram_loaders.pyのローダーノードを使う。これは実行順を固定してオフロードを行い、32GB VRAMに収める設計と説明されています
• 併せてComfyUI起動時のpython -m main --reserve-vram [X](Xは予約するGB数)が案内されています
• モデルの配置先はmodels/checkpoints、models/loras、models/text_encoders/gemma-3-12b-it-qat-q4_0-unquantized、models/latent_upscale_models

どちらから入るべきか。ワークフローを組み替えたい、ノードUIで試行錯誤したいならComfyUI経路です。今回のように自作アプリへ組み込む、あるいはメモリの使われ方を自分で制御したい場合は、公式CLI/Python API経路のほうが手を入れやすいと感じました。

8. 実測結果

以下は筆者環境(DGX Spark GB10 / 統合メモリ128GB / aarch64)での一次実測で、2026-07-18に取得したものです。公開情報源による裏取りはできないため、あくまで1台の記録として読んでください。計測方法は、サーバー起動後の最初のジョブについて、パイプラインロード開始のログ行からVideo savedのログ行までの実時間を取ったものです。したがって表の「ジョブ全体」には、約71.5GBのチェックポイントの初回ロード時間が含まれます。再現条件はいずれもImage-to-Video、モデルはLTX-2.3 22B distilled 1.1、量子化はfp8-cast、24fpsです。

この表で読み取れるのは、第1段の拡散ステップだけを削っても全体はさほど縮まないということです。第1段の8ステップは最大でも36秒しかかかっていないのに、ジョブ全体は97〜229秒かかっています。ただしこの比較は母集団が揃っていません。前述のとおり「ジョブ全体」には初回のパイプラインロード(約71.5GBの読み込み)が含まれ、一方で第2段の拡散ステップ時間は今回計測も控除もしていないため、差分の内訳を厳密に切り分けたことにはなりません。差分に含まれるのは、初回パイプラインロード、第2段の拡散、VAEのデコード、x2アップスケール、動画エンコード、そして後述するチェックポイントの再読込です。少なくとも「第1段のステップ数を減らせば比例して速くなる」という直感はこの構成では当たりません。

最下段の1216×704・7秒が、同じ画素数で尺の短い条件にもかかわらず704×1216・10秒より遅かった件については、プロンプト拡張が有効だったことと、この実行中にページキャッシュの追い出しが3回(15.3GB / 7.6GB / 39.0GB)走っていることが候補として挙がります。ただしこれはn=1の観測で、拡張なし・追い出しなしの1216×704の対照実行を取っていないため、どちらがどれだけ効いたのかは分離できていません。総画素数が同じでも縦横が入れ替わればタイリングやアテンションの形状依存で所要時間が変わりうる点も、今回は切り分けられていません。メモリ圧迫下では時間が伸びる傾向がある、という程度の読み方に留めてください。

メモリは「VRAM何GB」ではなく何を見るのか

統合メモリ機なので専有VRAM使用量は測れません。代わりに/proc/meminfoのMemFreeの推移を見ます。以下の値はいずれも筆者環境の実行ログから拾ったもので、外部の公開情報源では検証できません。

生成のピーク時のMemFreeの落ち込みは、実行ログ中のMemFree最大値110.8GBを基準にすると約27〜30GBでした。ただしこれはOS・常駐プロセス・サーバー本体を含むシステム全体の落ち込みです。表の1行目が示すとおりパイプラインロード直後の時点ですでに約1.6GB落ちているので、生成ジョブ固有の増分として読むならその分を引いた約25〜28GBのほうが妥当です。基準にした110.8GBはあくまで実行ログ中のMemFree最大値であってOSから見えるメモリ総量ではなく、追い出しきれなかったページキャッシュが混入する余地も残るため、いずれも概算として扱ってください。

この値をComfyUI-LTXVideoが書く「32GB+ VRAM」と並べると桁も水準も近くはあります。ただし後者はComfyUI + 同リポジトリのカスタムノードという別実装・別の量子化条件の要件で(しかもlow_vram_loaders.pyでオフロードした場合に32GBに収まる、という目標値としても登場します)、今回のltx-pipelines 1.0.0 + QuantizationPolicy.fp8_cast()経路とは同じワークロードではありません。第7章に書いたとおりComfyUI経路は実行していないので、これは同一の物差しでの比較ではなく、あくまで桁が近いという事後的な一致です。統合メモリ機で「専用GPUカードの容量」を「生成中に空けておくべき常駐メモリ」と読み替える見立ては、n=1の観測から導いた作業仮説として扱ってください。なお64GB機での測定は行っておらず、ページキャッシュの肥大挙動やNVRMの確保挙動が他機でGB10と同じかどうかも未検証のため、他容量の機材で足りるかどうかはこの記事では判断できません。

なお、公称と実測が食い違うのは動画モデルに限りません。量子化後のサイズが公称と合わない話は/posts/qwen3-8-27b-open-weights-16gb-local-benchmarks-2026/で扱っています。

9. つまずいた箇所と対処

導入日(2026-07-18)に筆者環境で実際に出たものだけを並べます。メッセージ・発生時刻・後述のメモリ値はすべて筆者環境のログからの引用で、公開情報源では検証できません。

2番目と3番目は別のメッセージですが原因は同じで、Gemmaの部分ダウンロードです。エラー文面だけ見るとtransformers側の互換性問題に見えるので、まずシャードの完全性を疑ってください。

システムごと落ちたOOMの対処

これがこの環境で最も厄介な問題でした。順を追うとこうです。

1. LTX-2.3のチェックポイントは、初回ロード時にテキストエンコーダ(Gemma-3-12B、約24.4GB)を含む一式が読み込まれ、さらに2段生成のステージ切替のたびにdiffusion transformerとspatial upscalerの側がディスクから再読込されます(切替のたびに約71.5GB全量を読み直すわけではありません)。読み込まれたファイルはカーネル側にページキャッシュとして残り、後述のfadviseで解放できました。プロセス側でmmapの保持状況を確認したわけではないため、機序の断定ではなく観測された挙動として書いています
2. ジョブを重ねるうちキャッシュが約87GBまで肥大し、MemFreeが2.2GBまで落ちました。このときMemAvailableは83GBあり、カーネル的には「回収すれば空く」状態でした
3. それでもNVRMの確保は失敗しました。この1回の観測から言えるのは「MemAvailableが十分に見えてもNVRMの確保は失敗しうる」までで、失敗要因としては連続領域や特定ゾーンの要求、断片化、回収を伴う再試行を行わないアロケーション実装など複数の候補があり、切り分けはできていません。GB10固有の性質かどうかも他アーキテクチャとの対照観測がなく判断できません。実務上の対処としてはMemFreeを監視値に採るのが安全でした
4. とどめは1216×704・12秒(289フレーム)のジョブでした。アップスケール段階の開始でステージ切替が起き、巨大な再読込と新規確保が衝突してフリーズしました。筆者環境で試した範囲では、それまでの成功実績は6秒(145フレーム)までです

対策として入れたのは次の4点です。いずれもroot権限は不要です。

• ページキャッシュの明示的な追い出し: posix_fadvise(POSIX_FADV_DONTNEED)をモデルファイルと動画ファイルに対して発行します。advisoryなので安全で、筆者環境の実測では1回で66.7GBが即時解放されました(MemFreeが109.2GBまで回復)。解放量はそのときのページキャッシュの状態に依存するため、再現する値ではありません
• 生成前ガード: MemFreeが16GBを下回っていたら回収を試み、それでもダメならジョブ側をエラーにしてマシンを守ります
• 常駐ジャニター: MemFreeが24GBを割ったら即座に追い出します。ステージ切替中の急落をここでカバーします。筆者環境の実行ログでは、MemFreeが23.2GBまで落ちた直後に38.4GBを解放して39.3GBへ戻す動きが記録されています(こちらも解放量はキャッシュの状態次第です)
• 断片化緩和: 起動時にPYTORCH_CUDA_ALLOC_CONF=expandable_segments:Trueを設定します

export PYTORCH_CUDA_ALLOC_CONF=expandable_segments:True

加えて、生成ジョブは絶対に同時1本にしてください。統合メモリ機で並列生成を走らせるのはメモリ枯渇フリーズへの最短経路です。今回はワーカースレッド1本での直列処理、キュー取り出しの原子化(UPDATE ... RETURNING)、そしてflockによるプロセス跨ぎのロックという三重で保証しました。

カーネル側の予備領域を増やす手もありますが、これはsudoが必要なため今回は未適用です。

echo 'vm.min_free_kbytes = 1048576' | sudo tee /etc/sysctl.d/99-gb10-mem.conf
sudo sysctl --system

10. ケース別の回し方

短尺素材を量産する。512×960・10秒が116秒、704×1216・10秒が182秒なので、単純に3600秒を割れば前者で31本、後者で20本弱という計算になります。ただしこの2つの数字は第8章の定義どおり初回パイプラインロードを含むジョブの実時間で、2本目以降の定常時間を測ったものではありません。第9章に書いたステージ切替ごとの再読込、常駐ジャニターによる追い出し、生成前ガードといったジョブ間のオーバーヘッドも入っていないので、実際の連続稼働本数はこれより減ります。あくまで桁を掴むための参考値です。SNS向けの縦位置素材を数を打って選ぶ用途なら、512×960で回して当たりだけ高解像度で再生成するのが時間効率の点で妥当でした。

静止画に動きを付ける。ImageConditioningInputにframe_idx=0、strength=1.0で渡します。今回の実測ジョブはほぼすべてこの経路です。渡す画像の解像度は生成解像度に合わせて64の倍数へ丸めておかないと弾かれます。

尺を伸ばす。1本のジョブで12秒(289フレーム)を狙うのは、この環境ではガード整備後も最重量級で、実際にフリーズの引き金になりました。安全なのは、シーンを区切って連鎖生成し、後で連結する方法です。前シーンの最終フレームを次シーンのImage-to-Video条件に渡します。ただし引き継がれるのはフレーム1枚だけなので、シーンをまたぐと被写体の細部は変わります。長い尺を1本の連続ショットとして完成させる用途には向きません。

反復生成を回す。seedを固定してプロンプトだけ変える、あるいはプロンプトを固定してseedを振る。distilled版はネガティブプロンプトが効かないので、除きたい要素は「書かない」ことで対処するしかありません。

11. かかるもの(ディスク・時間)と後片付け

クラウドサービスとの費用比較は、比較対象の料金体系を一次資料で確認していないため、この記事では行いません。この記事で保証できるのは「1本あたり何分か」「ディスクを何GB使うか」までです。

後片付け

不要になったら次の順で消せます。作業ディレクトリの外には何も置いていません。

rm -rf models/
rm -rf .venv/
rm -rf ~/.cache/huggingface/hub/models--Lightricks--LTX-2.3
rm -rf ~/.cache/huggingface/hub/models--google--gemma-3-12b-it-qat-q4_0-unquantized

--local-dirを指定してダウンロードした場合でも、~/.cache/huggingface側にキャッシュが残ることがあります。ディスクが戻らないときはここを確認してください。PYTORCH_CUDA_ALLOC_CONFをシェル設定に書いた場合はその行も消します。

12. ライセンスと商用利用

LTX-2.3の重みは「LTX-2 Community License Agreement」の下で配布されています(Hugging Face Lightricks/LTX-2.3、2026-09-08確認)。ライセンス本文(LICENSE-2、2026年1月5日版)を読んだ範囲での要点は次のとおりです。GitHubのLICENSE索引によると、LTX-2.3にはこの版が適用され、2026年8月11日以降に公開されたLTX-2.5系には条件の異なる「LTX-2.x Community License(LICENSE-2_x)」が適用されます(GitHub Lightricks/LTX-2 LICENSE、2026-09-08確認)。以下はLTX-2.3の条件です。

• 商用利用は条件付きで許可されています
• ただし年間売上1,000万ドル以上の事業者は「Commercial Entities」と定義され、商用展開には別途Lightricksとの有償ライセンス契約が必要です
• 売上は子会社・関連会社などを合算して判定されます(第1条)。また、売上規模にかかわらず、Lightricksの商用製品・サービスと直接競合する製品・サービスにLTX-2やその派生物を使うには、別途商用ライセンスが必要です(Attachment A 第20項)。閾値未満なら禁止用途以外は自由、という読み方はできません
• LTX-2.3のライセンス本文(LICENSE-2)には非本番環境での試験・評価・研究開発に関する明示的な免除規定は見当たりません。年間売上1,000万ドル以上の事業者は利用形態にかかわらずLightricksへの確認が必要です。なお2.5以降のLICENSE-2_xには、商用事業者による非本番環境での試験・評価・非商用の研究開発を除外する規定があるため、版によって条件が異なります(GitHub LICENSE-2_x、2026-09-08確認)(Hugging Face Lightricks/LTX-2.3 LICENSE、2026-09-08確認)
• 輸出管理の遵守条項があり、制裁対象国や制限対象リストに該当する場合はアクセスできません
• 禁止用途がAttachment Aに列挙されています(マルウェア生成、なりすまし・ディープフェイク、医療助言、差別的用途、軍事・兵器開発、安全機構の回避など)
• 明示的なクレジット表記の義務は見当たりませんでしたが、著作権表示の保持と、生成物が機械生成であることの明示が求められます

条文の解釈が事業判断に直結する場合は、要約ではなく原本(リポジトリ内のLICENSE-2_x)を読み、必要なら法務に確認してください。オープンウェイトの動画モデルでライセンスの地域条件が問題になった例は/posts/minimax-h3-open-weights-42gb-license-territories-2026/で扱っています。

なお、テキストエンコーダに使うGemma-3-12BはGoogleの別ライセンスです。LTX側の条件とは独立に確認が必要です。

13. よくある質問

VRAM 16GBや24GBのカードでも動きますか

今回の環境では専有VRAMを持たないため、その点は実測で答えられません。分かっているのは2つです。ComfyUI-LTXVideoは最小要件を32GB+ VRAMと明記していること、そしてこの環境での生成中のMemFreeの落ち込みが約27〜30GBだったことです。16GBや24GBのカードで動かす場合は、low_vram_loaders.pyのローダーノードとComfyUIの--reserve-vramを使うことが公式に案内されていますが、その効果はここでは検証していません。

DGX SparkとLTX-2を結び付けた公式情報はありますか

NVIDIAの日本語ブログ(2026年1月7日公開)がLTX-2について書いているのは「最大 20 秒間の 4K ビデオ」を生成するという点です(NVIDIA 2026-01-07)。一方、RTX 50シリーズのNVFP4フォーマットで約3倍高速・VRAM 60%削減、NVFP8で約2倍高速・40%削減という数値はLTX-2単体の測定値ではなく、ComfyUIにおける精度フォーマット対応全体の効果として述べられたものです(英語版原文は「All combined, performance is 3x faster and VRAM is reduced by 60% with RTX 50 Series’ NVFP4 format」)(NVIDIA 2026-01-07)。同じ節ではLTX-2のほかFLUX.1、FLUX.2、Qwen-Image、Z-Imageが並んで挙げられており、LTX-2はその対応モデルの一つという位置づけです。

DGX Sparkについては、この日本語ブログでは別項(デスクトップ型AIスパコン)として扱われ、LTX-2と結び付ける記述は本文に見当たりません。ただしDGX Spark/DGX Stationを主題とする別の公式ブログ(2026年1月5日)には、LTX-2の公開に触れた記述があります(NVIDIA 2026-01-05)。「DGX Spark上でLTX-2が動作する」と明言した公式記述は2026-09-08時点で確認できませんでした。

LTX-2.5ではなくLTX-2.3を選ぶ理由はありますか

公式リポジトリの現行推奨はLTX-2.5です。今回2.3を使ったのは、ComfyUI-LTXVideoの同梱ワークフローが2.3中心で、実行系のサンプルが揃っていたためです。公式リポジトリにはLTX-2.3も同一パイプラインで動作する旨の記載があります。新規に始めるなら2.5から入るのが素直で、その場合はhf downloadのリポジトリ名とファイル名が変わります。

生成した動画に音声が入っていないのですが

LTX-2.3は映像と音声を同時に生成しますが、モデルカードには発話を含まない音声の品質が下がる場合があるという注意があります。また、無音のクリップと音声付きのクリップをffmpegで連結すると壊れることがあります(この挙動について一次資料での裏取りは行っていません)。筆者環境での対処としては、無音側にanullsrcで無音トラックを付与してから連結しました。

ffmpeg -i silent.mp4 -f lavfi -i anullsrc=r=48000:cl=stereo -shortest -c:v copy -c:a aac fixed.mp4

システムのffmpegが無い環境でも大丈夫ですか

以下は筆者環境での作業記録です(外部の公開情報源で検証できるものではありません)。筆者環境にはffmpegもffprobeも入っていませんでしたが、imageio-ffmpegの同梱バイナリで全処理(フレーム抽出、サムネイル、正規化、連結)をまかなえました。バイナリのパスはimageio_ffmpeg.get_ffmpeg_exe()で取得できます。ffprobeが無いため、音声の有無と解像度はffmpeg -i input.mp4をstderrに吐かせ、Stream #0:1: Audio行の有無とStream #0:0: Video行の解像度表記から判定しました。

14. まとめ

• 専有VRAMを持たない統合メモリ機(DGX Spark / GB10・128GB・aarch64)で、LTX-2.3のローカル動画生成は動きます。筆者環境での一次実測(2026-07-18、Image-to-Video、fp8-cast、24fps)は512×960・10秒が116秒、704×1216・10秒が182秒でした
• 公式が挙げる対応プラットフォームにaarch64の記載はありませんが、ltx-pipelines 1.0.0とtorch 2.13.0はaarch64 wheelでそのまま入りました。「非対応」ではなく「言及がない」状態です
• ComfyUI-LTXVideoの「32GB+ VRAM」を、統合メモリ機で「生成中に空けておくべき常駐メモリ」と読み替える見立ては、桁が近いという事後的な一致に基づく作業仮説です。実測のシステム全体のMemFreeの落ち込みは約27〜30GB(ジョブ増分としては約25〜28GB)ですが、ComfyUI経路は実行しておらず同じワークロードの比較ではありません
• 第1段の拡散ステップは最大36秒で、ジョブ全体97〜229秒の主役ではありません。ただしこの全体値には初回パイプラインロードが含まれ、第2段の拡散ステップは未計測なので、内訳を厳密に切り分けたものではありません
• この環境で最も危険なのはページキャッシュ肥大によるシステムフリーズです。MemAvailableが十分に見えてもNVRMの確保は失敗しうるため監視値はMemFreeを採り、posix_fadviseでキャッシュを追い出し、生成は同時1本に固定してください(失敗の機序そのものは1回の観測からは特定できていません)
• 商用利用は条件付きで可能ですが、年間売上1,000万ドル以上の事業者は別途有償ライセンスが必要です。事業利用の前に原本を確認してください

15. 関連記事

• /posts/minimax-h3-open-weights-42gb-license-territories-2026/ — ローカル動画モデルの重みサイズと、ライセンスに書かれた地域条件を読み解いた記事です
• /posts/qwen3-8-27b-open-weights-16gb-local-benchmarks-2026/ — 量子化後のサイズが公称と食い違い、想定したカードに載らなかった事例です
• /posts/openai-sora-shutdown-disney-deal/ — クラウド動画生成サービスがローンチ半年で終了した経緯です