LTX-2からLTX-2.3へのアップグレード：互換性、LoRAの破損、マイグレーションガイド（2026年）

こんにちは、Doraです。アップグレード週間を計画していたわけではありません。ただ、クライアント向けデッキの古いプロンプトを再実行したかっただけです。同じシード、同じ設定、表向きは「同じ」モデル——でも実際は違いました。LTX-2.3がフォルダに入っており、画像は一段クリーンで、少しリテラルな印象になっていました……そして私のLoRAで強化したスタイルが消えていました。その小さなズレが私をウサギの穴へと引き込みました。2026年3月の数日間、いつも使っているComfyUIパイプラインとバッチ作業で使っているマネージドAPIを使って、LTX-2からLTX-2.3へのアップグレードをテストしました。実際に何が変わり、何が変わらず、そしてデモではなくリアルな仕事をする上でどこに摩擦が生じるかをお伝えします。

LTX-2と2.3の間で実際に変わったこと

マーケティングの主張は省いて、既存のワークフローに影響を与えた部分だけを見ていきます。

プロンプトがよりリテラルに解釈される。2.3では「左/右」「前景/背景」などの位置ヒントがより一貫して反映されることに気づきました。プロダクトレイアウトには便利ですが、LTX-2のルーズさに依存していたアート系プロンプトには少し硬すぎます。
デフォルトでコントラストと彩度が高くなる。私のニュートラルライティングプリセットが2.3ではよりパンチのある仕上がりになりました。ガイダンスを〜0.5〜1.0下げ、ポスト処理でコントラストを下げる頻度が減りました。
バージョン間でシードは1:1ではない。同じシードを使っても、LTX-2.3は私の実行では〜10〜12ステップ以降に乖離していきました。古いジョブからピクセル単位で安定した再レンダリングが必要な場合は、期待しないでください。
アスペクト比の処理がより賢くなった。2.3では正方形以外のサイズ（例：1024×1536）が歪んだ要素なく反映されるようになりました。LTX-2で使っていたキャンバスのハックをいくつか省けるようになりました。
サンプラーのデフォルトが変わった。2.3で推奨されるスケジューラ（とそのステップカーブ）により、同じ精細さを得るのに必要なステップが減りました。スイートスポットが〜28〜32ステップから〜22〜26ステップに移動しました。 同じGPUでスループットが少し改善しました。

どれもドラマチックな変化ではありません。でも、パイプラインを少し、時には嬉しい方向に曲げるには十分で……そして厳密な再現性、特にLoRAに依存している部分を壊すには十分です。

モデルサイズの現実確認：ローカルデプロイへの影響

24 GBの4090と8 GBのラップトップGPUで両バージョンを実行しました。ここはリリースノートでもっと強調してほしい部分です：実際にカードが保持できる上限と、まだ余裕があるかどうか。

VRAMとストレージの比較（dev / fp8 / 両バージョンにわたるdistilled）

私が観察したことと実際に重要だったこと：

Dev/フルチェックポイント：4090では、LTX-2とLTX-2.3の両方の「dev」ビルドが読み込まれましたが、2.3は実行時のVRAMが少し重く（同じサンプラー/ステップでの私の実行では約+0.5〜1.2 GB）なりました。高解像度生成のためのヘッドルームが少ない場合、そのマージンは重要です。8 GBカードでは、オフロードなしにフルdevビルドを動かすのは現実的ではありませんでした。
FP8/量子化バリアント：テストでは、fp8の2.3ビルドはフル精度に比べてVRAMを〜25〜35%解放しましたが、非常に少ないステップで非常に精細なディテールを押し出すときに少し脆くなるコストがかかりました。日常的な1K出力では気になりませんでした。積極的に合成またはクロップする場合は気になるかもしれません。デプロイにおけるFP8量子化の実用的な利点については、NVIDIAの公式ガイドの効率的な低精度AIトレーニングを参照しました。
Distilled：2.3のdistilledチェックポイントは実用的な中間地点として機能しました。ストレージフットプリントが小さく、ウォームスタートが明らかに速く、エッジのマイクロディテールで小さなトレードオフがあります。ソーシャル向け画像や社内ドキュメントには、フル2.0よりdistilled 2.3を選びます。
ディスクフットプリント：2.0バリアントに対して2.3バリアントではわずかに増加します。大きくはありませんが、スクラッチドライブをきれいに保つために古い実験的なLoRAを削除する必要がありました。

現場からの小さなメモ：VRAMのヘッドルームが〜2 GB未満になったとき、2.3でタイル高解像度パス中に時々OOMが発生しました。タイルのオーバーラップを下げるか、fp8を使うと安定しました。

ComfyUIワークフローの互換性：まだ動くもの、更新が必要なもの

ComfyUIのセットアップをほぼそのままにしてチェックポイントを交換しました。テスト中のワークフロー互換性を確保するために、主に公式のComfyUIリポジトリを参照しました。

スムーズに動いたもの：

conditioning → sampler → VAE decodeの基本的なtext-to-imageグラフ。グラフを再構築せずに2.3ローダーを入れ替えてレンダリングできました。
一般的なサンプラー（例：DPM++ファミリー）は問題なく動作しました。新しいカーブに合わせてステップとガイダンスを調整しただけです。
潜在アップスケーラーを使った高解像度ワークフローも動作しましたが、ディテールを失うことなく第2ステージのステップを〜20%短縮しました。

更新が必要だったもの：

LoRAインジェクションノード：私のLTX-2 LoRAは2.3にきれいに接続できませんでした。ノードが接続を許可しても、結果がおかしくなり、スタイルが崩れたり消えたりしました。詳細は後述します。
チェックポイントパスとフォーマット：テストした2.3チェックポイントは異なるフォルダ名と若干異なるコンフィグ参照で出荷されていました。Checkpoint Loaderノードのパスを更新し、VAEペアリングを確認する必要がありました。
パラメータのデフォルト：古い「ハウス」プリセット（CFG 6.5、ステップ〜30）は2.3でハーシャーなコントラストを生成しました。CFGを〜5.5に、ステップを〜24に下げることで好みのバランスに戻りました。
ネガティブプロンプト：長いネガティブリストへの依存が減りました。2.3はネイティブで特定のアーティファクトを回避するようになりました（手が製品ポーズで少し改善しました）。プロンプトのオーバーヘッドを削減するためにネガティブを削減しました。

ノードの変更、チェックポイントパス、パラメータの違い

ノードの変更：コア生成に新しいカスタムノードは必要ありませんでしたが、メタデータの不一致を避けるためにモデルローダーノードを新しいComfyUIビルドに更新しました。ComfyUIが数ヶ月遅れている場合は、まず更新してください——奇妙なエラーを防げます。
チェックポイントパス：2.0と2.3のフォルダは分けておいてください。 バッチジョブが間違ったファイルを掴まないように、明確な命名スキーム（model_name/version/precision）を使っています。
パラメータの違い：2.3はCFGの変動に対してより敏感なようでした。小さな変化（〜0.5）が2.0よりも大きな視覚的インパクトを持ちました。また、ステップが少なくても同様のディテールが得られました：1K画像で〜26を超えると、テストでは逓減収益でした。

LoRAの互換性：既存のLoRAが直接移行できない理由

これが最大のサプライズで、LTX-2でスタイルライブラリを構築している場合は最も高くつきます。

私のLTX-2 LoRAは意味のある形では引き継ぎできませんでした。簡単に言うと：ベースモデルの変化（埋め込み空間、アテンションブロック、時には正規化とVAEの変化）により、学習されたデルタがきれいにマッピングできません。強制することもできますが、奇妙な色かぶり、形状のドリフト、または恐ろしい「全部がベージュのプラスチックになる」現象と戦うことになります。スタイルがLoRAに大きく依存している場合は、公式のHugging Face LoRAトレーニングガイドに従って再トレーニングし、LTX-2.3を新しいベースモデルとして扱うことをお勧めします。

実用的な観点から：見た目がLoRAに依存している場合は、LTX-2.3を新しいベースとして扱い、再トレーニングを計画してください。

再トレーニングが必要なものと推定コスト

私が維持したもの：

データセット：クリーニングされてキャプション付けされたセットを再利用しました（スタイルに応じて約300〜800枚の画像）。2.3では生の量よりも良いキャプションの方が効果的でした。
設定：彩度の過度な焼き付けを避けるために、2.0で使った学習率よりも低い値にしました。Rank/dimは同様でしたが、トレーニングステップを〜10〜15%下げました。
検証：古いプロンプトではなく、新しいベースプロンプトで数百ステップごとに検証しました。古いプロンプトは間違ったターゲットに向かってバイアスをかけていました。

コスト、大まかな人間的な言葉で：

時間：中規模セットで単一の4090での1 LoRAあたり約3〜5時間、検証と小さな再起動を含みます。Distilled 2.3ベースはさらに速くトレーニングできました。
クラウド：レンタルする場合、2026年3月時点で24 GBクラスのGPUに$0.80〜$1.60/時間を予算してください。1回のクリーンな再トレーニングは$3〜$10の範囲になり、さらに時間がかかります。もちろん、より大きなセットとより多くの実験はコストを上げます。

最初は時間の節約になりませんでした。でも2〜3回実行した後、私の2.3 LoRAはプロンプトでのガードレールが少なくなり、将来のバッチでの精神的労力が減りました。

APIユーザー：注意すべきエンドポイントとパラメータの違い

マネージドAPIでは、ltx-2.3対ltx-2の違いは小さいながらも重大でした：

バージョン管理されたモデル：2.3は多くの場合、明示的なモデルまたはバージョンパラメータの背後に置かれています。「latest」に依存している場合は、テストが完了するまで2.0にロックしてください。
デフォルトが変わった：プロバイダーでガイダンス、ステップ数、セーフティレベルが変化しました。CFGを〜10〜15%下げるまで、私のLTX-2プリセットは2.3でより高いコントラストの画像を生成しました。
シードのタイプ：あるAPIは2.3でシードを32ビットから64ビット整数に移行しました。無害に見えますが、私の古いラッパーはシードを文字列として型付けしていました。それらが暗黙的に無視されていました。
ネガティブプロンプトとウェイト構文：**トークナイザー/ウェイトのフォーマットを確認してください。**あるプロバイダーは構文解析を厳格化しました：古い「(keyword:1.2)」構文はスペースが必要でした。
レートリミットとバッチング：私のキューでは2.3はリクエストごとにわずかに速くなりましたが、バッチ同時実行の上限は変わりませんでした。短いスパイクを避けるためにジョブをずらしました。

迷った場合は、プロバイダーのリリースノートを確認し、バージョン間で同じプロンプト/シードをテストしてください。似た構成は期待できますが、同一のピクセルは期待しないでください。

LTX-2にとどまることがまだ意味を持つ場合

誰もが新しいおもちゃが好きですが、理由なく動いているシステムを再構築することはしません。いくつかのプロジェクトでLTX-2にとどまったのは：

厳密な再現性が必要な場合。監査、規制されたワークフロー、または過去のモデルバージョンに紐付いたクライアントのサインオフのために、同じシード、同じピクセルが必要。
LoRAへの大きな投資がある場合。ライブラリが深く多様な場合、再トレーニングコスト（時間、注意、ドルだけでなく）が積み重なります。
エッジまたは低VRAMの制約がある場合。8 GBのマシンが2.0スタックをかろうじて保持している場合、2.3の追加ヘッドルームニーズによりオフロードに追い込まれる可能性があります。
チームトレーニングコスト。プロンプトとプリセットがドキュメントとチュートリアルに焼き付けられている場合、2.3は小さいながらも累積的な変更を強制します。千の切り傷による死は現実のものです。

一方、新しく始める場合や、すぐに使えるプロンプトの厳密な準拠が好きな場合、2.3の方が操作しやすく感じました。