LTX-2 ローカル vs クラウド: ComfyUI vs WaveSpeed (速度、コスト、プライバシー)

40秒の待機時間。それが小さなきっかけでした。LTX-2クラウドでバッチを開始して、マグカップを満たしに席を立ちました。戻ってくると、1つのジョブが曖昧なエラーで失敗していて、それが私のせいなのか、プリセットのせいなのか、サービスのせいなのか判断できませんでした。その小さな一時停止が心に残りました。翌朝、同じプリセットをローカルで実行したところ、メールアプリがシンクを完了する前に終了しました。このコントラストが本論文のテーマです：LTX-2 ローカル対クラウド。機能リストではなく、日常の中で各環境がもたらす、あるいは取り除く負担についてです。

2026年1月初旬に、16インチMacBook Pro（M2 Pro、32GB RAM）と小型UbuntuボックスRTX 4090、米国地域のLTX-2クラウドでテストしました。ハードウェアとリージョンによって数値は変わりますが、トレードオフは一貫した形で現れました。モデルの技術的詳細については、LTX-2研究論文をご覧ください。

クイック判断テーブル（ユースケース別のローカル対クラウド）

前後で切り替えを繰り返す前に、あれば良かったと思える高速パスです。

ユースケース	選択	正しいと感じた理由
単一プレビュー、タイトなフィードバックループ	ローカル	キューイングなし、高速反復、プリセットとプロンプトのデバッグが容易。
確実な期限付きの大規模バッチ	クラウド	並列ジョブ、優れたスループット、調整後の監視が少なくて済む。
機密データ（PII、未公開アセット）	ローカル	アップロードなし：保存期間とアクセスをデフォルトで管理できます。
変動の多いワークロード（ある週は重い、他の週は静か）	クラウド	バースト課金：机の下でアイドル状態のGPUをうならせる必要がない。
オフラインまたはネットワーク不安定	ローカル	明らかですが、Wi-Fiが調子が悪くなった瞬間から重要になります。
チーム共有と再現性	クラウド	集中管理されたプリセット、ログ、権限は「私のマシンでは動く」問題を減らします。
実験的な操作（カスタムビルド、エッジフラグ）	ローカル	バージョンをピン留めし、ブランチをテストし、すぐにロールバックできます。

これほど分裂すると予想していませんでした。しかし1週間後、デフォルトではローカルでプレビューし、200以上の項目はクラウドに送信していました。

速度：ローカルハードウェア対クラウドスループット

確かに、速度は私にとって2つの異なる感覚に分かれました。

ローカルは1回限りの場合、素早く感じました。 M2 Proでは、単一のLTX-2ジョブは約1～2秒で開始し、フローに留まるのに十分な速さで完了しました。4090ボックスでは、ウォームになると基本的に瞬時でした。
クラウドはボリュームの場合、安定していました。 最初のジョブは時々5～15秒キューで待機しましたが、50個の並列ジョブがそれを平滑化しました。スループットがレイテンシに勝ちました。

現場からの小さな注記：コールドスタートは認めるより重要です。ローカルキャッシュ、重みから中間ファイルまで、繰り返しの実行をより軽く感じさせました。キャッシュを削除するまで気づきませんでしたが、突然すべてがぐいぐい引っ張られました。クラウドでは、そのレイヤーを管理できなかったため、スケールと引き換えに小さなスタート税を受け入れました。

驚いたことに：最速の単一プレビューは常にローカルでした。1,000項目の最速時間は常にクラウドでした。ピボットポイントは私の場合150～250項目でした。それ以上になると、コマンドを入力してサービスに任せるとその午後が救われました。それ以下なら、ローカル実行を開始することが仕事に留まります。

コスト：電気 + 減耗対クレジット

落ち着いた会計士のように、誇大広告者ではなく、これを値付けしてみました。

ローカルコストはこんな感じです：

初期ハードウェア（またはマンスリーリース）
電気（私の4090リグはアイドル時~~90W、負荷時~~420W）
減耗とメンテナンス（ファン、ストレージ、時折のドライバウサギ穴）

クラウドコストはこんな感じです：

ジョブあたりまたはトークンあたりのクレジット
アセットを保持している場合の可能性のあるエグレス/ストレージ
バッチが急増する場合のオーバーエージ

私のメモからの2つの簡単なスケッチ：

200項目バッチ、各ジョブ~1分： ローカルはMacで~~220分の壁時計時間を取りました（GPUなし）、基本的に電気を除いて無料です。クラウドは並列性で~~8～12分で消費し、クレジットコストは期限が迫った週に正当化するのが簡単でした。より多くの実装ヒントはGitHubで利用できます。
継続的なしぶき（1日20～30項目）： ローカルが勝ちました。ボックスを準備して置くことは、コストを一度吸収することを意味しました。クラウドクレジットは実行を押すたびに小さな認知コストを追加しました。高価ではなく、ただ存在しただけです。

単一の「より安い」があると思いません。すでに有能なハードウェアを所有していて、ワークロードが安定している場合、ローカルは財布に優しいです。ボリュームが変動の多い場合、バースト容量の支払いは机下のスペースヒーター購入に勝ります。ローカルが無料に近い月と、クラウドが明らかにより賢い月がありました。

プライバシー：データ保有期間とチーム権限

これは私にとってシンプルでした。機密なら、LTX-2をローカルで実行します。クラウドを不信していないからではなく、ファイルがどこに存在するかを説明できるからです。

ローカル：

アップロードなし。アーティファクトは私のディスクまたは私のネットワークシェアに留まります。
独自の保持ルールに合わせることができます：X日後に自動削除、保存時に暗号化、そしてそれで終わりです。

クラウド：

優れたチームコントロールがデフォルトで含まれています：役割、プロジェクト境界、および私の記憶に依存しないログ。
保持はポリシーベースです。それは良いことですが、それでもベンダーとの契約です。ドキュメントを読んで、デフォルト値を確認してください。一部のサービスはログとアーティファクトを予想より長く保持します。

小規模チーム全体でのコラボレーションのために、クラウドはより安全に感じました。プライバシーの意味ではなく、「正規プリセットを失わない」という意味で。未公開アセットまたはPIIを含むものについて、ローカルは私の肩を落としたままにしました。両方ともうまくできます。一般的なオープンウェイツとベンチマークについては、Papers With Codeを参照できます。

安定性：依存関係更新とノードクラッシュ

ドライバアップデートで午後を失いました。それがローカル実行の正直な部分です。機能するときは素晴らしい。1つの依存関係がバンプされ、別のものが遅れると、あなたはSREです。

ローカル安定性フィールドノート：

できるだけピン留めします。コンテナ、環数ファイル、必要に応じてOSアップデートさえも。
「既知の良い」プリセット+バージョンリストを保持します。プロジェクトの隣に、コミットハッシュと主要フラグを記載した短いテキストファイルを保持します。
大規模バッチ中に時々クラッシュを予期します。めったに壊滅的ではありませんが、流れを壊します。

クラウド安定性フィールドノート：

より少ないサプライズ：より多くのブラックボックス。ジョブは通常完了し、そうでない場合、エラーメッセージはヘルプフルより礼儀正しいことがあります。
ベンダーアップグレードは何の儀式もなく進行します。速度が向上するときは素晴らしい：変更が出力をシフトさせるときは厄介です。

どちらも完全に落ち着いているわけではありません。ローカルはレバーと追加の家事を与えます。クラウドはより少ないレバーと少ない家事を与えます。その週にどの種類の割り込みを受け入れるかに基づいて選択します。

ベストハイブリッドアプローチ（ローカルプレビュー+クラウドバッチ）

最終的に私に習着したのは、シンプルなリズムでした：

ローカルでドラフトとプレビュー。 私はエッジケースを反映する小さなサンプルセット、10～20項目を保持します。出力が1回ではなく2回正しく見えるまで反復します。
クラウドでバッチ。 正確なプリセットをエクスポートし、タイムスタンプ付きジョブ名で実行します。ログの最初の5%を監視してから、去ります。

これが正しいと感じた理由：

ローカルプレビューはレイテンシをほぼゼロに保ちます。コンテキスト切り替えなしでプロンプト、重み、またはパラメータを微調整できます。
クラウドバッチは私のマシンを無料に保ちます。書き続けるか、蓋を閉じて外に出ることができます。

役に立った2つの小さなコツ：

私は「プレビュースセット」を修正しました。初期段階では、入力を切り替え続けて何が変わったかを失いました。固定セットでは、改善が本当かどうか知っています。
すべての大規模実行の前にプリセットをスナップショットします。軽微なバージョンバンプでさえ出力を押すことができます：スナップショットは差分を明らかにします。

ジョブが少ない週では、特にオフラインまたは移動中の場合、ローカルにすべてを保持することもあります。本番週では、クラウドと戦いません。LTX-2 ローカル対クラウドの要点は忠実性ではなく、目前の仕事の摩擦を減らす環境を選ぶことです。それがWaveSpeedを構築した理由です - キューを監視することなくローカルプレビューとクラウドバッチ実行を処理するために。それは私たちのチームが毎日使用するものです。

マイグレーションチェックリスト（ワークフロー/プリセット転送）

LTX-2ローカルとクラウド間の移動は、手順を書き下げるとスムーズでした。これは私が今使用するチェックリストです。退屈です、それが機能する理由です。

プリセットパリティ

手動コピーの代わりに、プリセットをエクスポート/インポートします。直接エクスポートが利用できない場合、プリセットをJSON/YAMLとしてバージョン管理に保存します。
バージョンをピン留めします。モデル/ビルドID、任意の拡張機能バージョン、および関連フラグをメモします。
決定性が重要な場合は、シード/ランダムネス設定を記録します。

アセットパス

パスを正規化します。ローカルの絶対パスはクラウドに存在しません：相対パスを使用するか、既知のバケットまたはプロジェクトフォルダにアセットを事前アップロードします。
コーデックと形式を確認します。ここでのミスマッチはパイプラインを静かに壊します。

環境

環境変数とシークレットを個別にドキュメント化します。シークレットをプリセットにベイクしません。
ハードウェアの仮定を合わせます。ローカルプリセットが特定のメモリフットプリントを期待する場合、クラウドで最初に小さいバッチをテストします。

検証

ミニバッチ（完全セットの1～5%）を実行し、入力ごとに出力を比較します。
各環境での最初の成功実行のログを保持します。後で何かがドリフトするとき、それらはベースラインになります。

ロールバック

両側に「最後の既知の良い」プリセットを保持します。日付と「CUDA更新前」または「リリースv1のシードロック」のような短いメモで名前を付けます。これは10分静かに時間がかかり、最初に何かあなたの下でシフトする時は報酬を払い戻します。時々ステップを忘れることもあります：チェックリストはそれを許します。