LTX-2.3 ComfyUI セットアップ：2ステージパイプライン、VRAM修正＆Gemmaエンコーダー

やあ、みんな。Doraです。切り替えるつもりはなかったんですよ。ComfyUIでのLTX-2セットアップは快調に動いていたし、「新しいから」という理由だけで変える気にはなれないタイプなので。でも先週（2026年3月）、LTX-2.3についての小さな注記をずっと目にしていました：コヒーレンスの改善、新しいテキストエンコーダー（Gemma 3 12B）、そして二段階パス——VRAMを犠牲にせずに鮮明な画像を約束するものでした。

静かな朝を使って、ワークフローを移行してみました。 実際に何が変わったか、どこでつまずいたか、そして作業が楽になった部分をまとめます。インストール手順を探している方：ちゃんと書いてありますが、本当に役立つのは**LTX-2.3 ComfyUIワークフロー**を日々構築していく中で気づいたトレードオフの部分です。

ComfyUIにおけるLTX-2.3の違い（LTX-2セットアップとの比較）

LTX-2.3 ComfyUIは大きな飛躍というより、信頼性への小さな一歩という感じです。このモデルはテキストエンコーダーとしてGemma 3 12Bを期待しており、推奨されるパスは二段階パイプラインです：ベースコヒーレンスのために半解像度で生成し、次にLTX専用アップサンプラーで潜在変数をアップスケールします。実際には、これにより二つのことが変わりました：

適度なステップ数でプロンプトがよりまとまりを持ちました。Stage 1を25〜35ステップの範囲に収めると、「モヤっとした」ディテールが減りました。
ステージの境界を守って一度に全解像度を無理やり処理しようとしない限り、VRAMの急激な増加は思っていたより少なかったです。

また、古いLTX-2ノードはほとんど動作しましたが、LTX-2.3は独自のサンプラー/潜在アップサンプラーノードを好みます。チェックポイントを入れ替えるだけでは不十分でした。最初につまずいたのはそこです。

必要なファイルとフォルダ構成

何度か失敗した後にたどり着いたセットアップはこちら。凝ったものではなく、赤いエラーボックスを止めるための最小限のものです。

チェックポイントのオプション（dev / fp8 / distilled + distilled LoRA）

dev：試行錯誤に向いています。少し重めですが、プロンプトがブレても許容範囲が広い印象でした。
fp8：VRAMに優しい。12GBカードでは、fp8のおかげでデコード時のOOMなしにバッチサイズ1を維持できました。品質はわずかに落ちますが、SNSやマーケティング素材には大きな問題ではありません。
distilled + distilled LoRA：テストでは製品ライクなショットで最もクリーンな出力でしたが、実際にLoRAを読み込んでウェイトを設定する（0.6〜0.8が私には合いました）ことを忘れないようにする必要があります。LoRAが有効でない場合、結果はdevに近い見た目になりました。

すべてのチェックポイントはComfyUI/models/checkpointsに置きました。LoRAはComfyUI/models/lorasに保管し、ベースチェックポイントと同じ語幹で命名してペアを素早く見つけられるようにしました。

Gemma 3 12Bテキストエンコーダー：ダウンロードと配置

LTX-2.3はGemma 3 12Bテキストエンコーダーを必要とします。ノードスタックによって、PyTorchウェイトか**GGUFファイル**（llama.cpp対応ノード向け）のどちらかを使います。両方試しました。

PyTorchルート：ComfyUI/models/clipに配置（一部のノードはここを自動検出します）。ノードが別のフォルダを要求する場合は、ドキュメントに従ってください。無理に抗わないこと。
GGUFルート：ComfyUI/models/llm（またはノード固有のtext_encodersフォルダ）に配置。Q4_K_Mが私には最適でした：Q3はメモリをより節約できますが、長いプロンプトでのニュアンスが失われました。

迷ったら、ノードの「?」ヘルプかREADMEを開きましょう。フォルダ名は重要です。

アップスケーラーモデル：いつ含めるか

LTX潜在アップサンプラーを使用している場合、外部画像アップスケーラーは必要ありません。とはいえ、非LTX画像用に**4x ESRGAN**とSDXL x2潜在アップスケーラーをComfyUI/models/upscale_modelsに保管していました。LTX-2.3では、組み込みのLTXVLatentUpsamplerがエッジやテキスト状の形状においてESRGANより優れた結果を出しました。

二段階パイプラインの解説

Stage 1をスキップしようとし続けていました。それは間違いでした。二段階パスは結局、理解しやすくVRAMにも優しいものでした。

Stage 1：半解像度でのベースコヒーレンス

目標サイズの半分で生成します（例：最終1280×768に対して640×384）。このステージで構図と被写体のディテールが決まります。25〜35ステップ、CFGは控えめ（4〜6）、バッチサイズ1。手の形、レイアウト、色かぶりなど何かおかしければ、ここで修正する方がコストが低いです。

気づいたこと：プロンプトを簡潔にして、スタイルアンカーを最大1〜2個に絞ると「ブレ」が減りました。LTX-2.3は焦点を絞った言葉に応えてくれるようです。

Stage 2：シャープネスのための潜在アップスケーリング（LTXVLatentUpsampler）

次に、Stage 1の潜在変数をLTXVLatentUpsamplerに渡します。これにより構図を再計算せずにエッジが鮮明になり、細かいディテールが復元されます。アップサンプリングには通常15〜20ステップ使います。魔法の消しゴムではありません：ベースが間違っていれば、アップサンプラーはただその間違いをより鮮明にするだけです。

Dev + Distilled LoRA vs フルDistilled：どちらを使うか

Dev + Distilled LoRA：見た目を探索しているときのデフォルト。少し柔軟性があります。LoRAストレングスを0.7前後に設定し、テクスチャがオーバーフィットしていると感じたら微調整します。
フルDistilled：バッチで速く一貫した出力が必要なとき。プロンプトに対してよりシビアですが、精神的な負担が減ります——実行ごとのサプライズが少なくなります。

行き詰まったら、Stage 1にdev（ゆるめ）、Stage 2にdistilled（タイト）を試してみてください。その組み合わせが、あるムーディーなポートレートセットを救ってくれました。

Gemma 3 12Bエンコーダーの設定：VRAM管理

Gemma 3 12Bが主な懸念点だと思っていました。実際にはそれほど大変ではなく、ただ制限が必要なだけです。

VRAMが逼迫しているときエンコーダーをCPU/RAMにオフロードする

12GBカードでは、テキストパスのためにGemmaエンコーダーをCPUにオフロードしました。実行ごとに数秒追加されましたが、Stage 1中のOOMが止まりました。ノードが**mixed-deviceロード**をサポートしている場合、アテンション層をGPUに、残りをCPUに設定しましょう。感覚的には：速くなるわけではないけれど、落ち着く——アイデアの途中でハードクラッシュしなくなります。

—novramフラグとその他の起動時の修正

ComfyUIをコマンドフラグで起動している場合、—novramがモデル切り替え時のメモリスパイクを滑らかにするのに役立ちました。さらに：

テスト実行の合間に大きなモデルの「keep loaded」を無効にしました。
無駄なグラジェントを避けるために、小さなカスタムinitでtorch.set_grad_enabled(False)を設定しました（セットアップが許可する場合）。
小さめのセーフティネットを使用：LoRAを重ねることがわかっているときは16ビットまたはfp8チェックポイントを使いました。

コンシューマーGPU向けの低VRAMストラテジー（12GB / 16GB / 24GB）

試した3台のマシン（RTX 3060 12GB、4070 12GB、4090 24GB）で効果があったこと：

GGUFクォンタイズモデル：Q3 vs Q4のトレードオフ

Q3：最低メモリ、最速ロード。ただしプロンプトのニュアンスが失われ、記述子の繰り返しが増えました。
Q4：少し重めですが、コヒーレンスが目に見えて改善します。12〜16GBカードには私のおすすめ。24GBではクォンタイズをスキップするか、利用可能ならQ5を使います。

メモリスパイクを減らすためのVAEオフロード

OOMに最もよく当たるのはデコード時です。VAEをCPUにオフロードするか、軽量なVAEを使うと、Stage 2の終わりのスパイクが減りました。12GBでは、前のノードでバッチ処理をしていても、最終デコードをシングル画像（バッチなし）に設定しました——ドラマが少なくなります。

その他の小さな改善点：

Stage 1では解像度を控えめに：後でアップスケールします。
複数のガイダンスのトリックを重ねることは避けましょう。CFG一つ、LoRA一つずつ。

初回実行時のよくあるエラーと修正方法

定番の赤いボックスにはひと通り遭遇しました。これらが定着した修正方法です。

ロード後のMissing Nodeエラー

ComfyUIがLTX-2.3ノードを見つけられない場合は、**カスタムノードリポジトリ**を更新して再起動してください。一部のLTXノードは新しいComfyUIコアも必要とします。あるしつこいエラーは、ノードのキャッシュフォルダを削除して起動時に再ビルドさせることで修正できました。

デコード中のOOM

二つの手段が即効でした：チェックポイントをfp8に切り替えるか、VAEをCPUにオフロードすること。また、最終ステージのバッチを1に下げましょう。それでもクラッシュする場合は、目標解像度を半分にして、残りを外部画像アップスケーラーに任せましょう。

Gemmaエンコーダーのクラッシュ

これはたいていフォルダの不一致か、ノードが好まないクォンタイズファイルが原因でした。ノードのREADMEに記載されているソースからGemma 3 12Bを再ダウンロードし、チェックサムを確認して、ノードが期待する場所（clip vs llm）に置きました。Q4は動作しました：Q3は4070上で最新のllama.cpp対応ビルドに更新するまで読み込みに失敗することがありました。

FAQ

LTX-2.3 ComfyUIノードは別途インストールが必要ですか？

通常はそうです。モデルだけを更新するだけでは不十分です。最新のLTXノードリポジトリをプルして、新しいサンプラーと潜在アップサンプラーが登録されるようにComfyUIを再起動してください。

既存のLTX-2ワークフローをLTX-2.3チェックポイントで使用できますか？

部分的には可能です。レイアウトは再利用できましたが、LTX-2.3サンプラーとLTXVLatentUpsamplerに入れ替え、プロンプトを**Gemma 3 12B**に向ける必要がありました。その後は、ほとんどのコントロールが正常に動作しました。

ComfyUIでLTX-2.3を実行するための最小VRAMは？

fp8またはGGUF Q4エンコーダー、半解像度のStage 1、VAEオフロードで、12GBでシングル画像の実用的な実行ができました。16GBではよりスムーズです。24GBでは、PyTorchのまま素早く進められます。

二段階パイプラインは単一段階より速いですか、遅いですか？

実時間は似たようなものになりますが、軽く感じます。全解像度のやり直しに費やす時間が減ります。Stage 1でアイデアを固め、Stage 2でそれを磨く。12GBカードでは、作業を続けられるかクラッシュするかの違いでもあります。

LTX-2.3 ComfyUIに「興奮した」わけではありませんでした。どちらかといえば「安心した」という感じです。画像が求めた通りに早く仕上がるようになり、ワークフローがVRAMと戦わなくなりました。二段階パスはこれからも使い続けるつもりです。静かで、ちゃんと動く。

関連記事：