技術 約13分で読めます

LTX-2とWan 2.2をM1 Max 64GBで動かせるのか調べた

AI 動画生成 LTX-2 Wan Apple Silicon 実験

M1 Max 64GBのMacBook Proで動画生成AIをローカルで回したい。候補はLTX-2とWan 2.2の2つ。どちらもオープンソースで、ローカル実行できるモデルとして注目されている。

実際に動かす前に、スペック要件とMac対応状況を調べた。Wan 2.2はGGUF形式で動いたが、2秒の動画に82分かかった。

LTX-2

Lightricksが開発した映像・音声同時生成モデル。映像と音声を別々に作って合成するのではなく、1回の推論で両方出てくるのが特徴。

  • パラメータ: 映像14B + 音声5Bのデュアルストリーム
  • 出力: FHD〜4K、25/50fps、6〜10秒（最大20秒）
  • 音声: 環境音、フォーリー、音楽、台詞を同時生成
  • ライセンス: オープンソース（GitHub、HuggingFace）

音声の制御

プロンプトで音声を細かく指定できる。公式プロンプトガイドによると:

  • 環境音: “rain falling on a tin roof” のように記述
  • 効果音: “footsteps on gravel” など
  • 音楽: “upbeat jazz piano in the background” など
  • 台詞: クォートで囲んで言語・アクセントを指定

modality-CFG（モダリティ別ガイダンス）で映像と音声の制御バランスも調整可能。テキストエンコーダにGemma 3を採用しており、多言語対応を謳っている。日本語台詞の品質は未検証。

Mac対応状況

公式のシステム要件はNVIDIA GPU前提（32GB+ VRAM推奨）だが、Apple Siliconでも動く。

パフォーマンス（既存の報告）

環境生成時間動画の長さ解像度
NVIDIA H100約2秒5秒768x512
Mac M3約5分数秒不明
Mac M1 16GB約15分約4秒不明

M1 Max 64GBならM1 16GBよりは速いはずだが、NVIDIAとは桁違い。

Wan 2.2

Alibabaが開発した動画生成モデル。品質の高さで定評がある。

  • モデル: 1.3B（軽量）と14B（フル）の2サイズ
  • 推奨VRAM: 1.3Bは6〜12GB、14Bは24GB+
  • 出力: 480p〜1080p
  • 音声: 非対応（映像のみ）

Mac対応状況

公式にはCUDA前提でMetal/MPS未サポート。ただし動かす方法はある。

  • 有志のフォークでMPS対応済み（M1 Proで動作報告あり）
  • ComfyUI経由だとFP8がMPS非対応でエラーになる → GGUF形式で回避可能
  • ComfyUIのissue #9255にApple Siliconの問題が報告されている

パフォーマンス（既存の報告）

環境モデル生成時間フレーム数解像度
NVIDIA RTX 3060 12GB14B約15分81フレーム840x420
Mac M1 Pro1.3B約10分8フレーム480p

M1 Proで8フレーム（25fpsなら約0.3秒）に10分。5秒の動画を作ろうとすると1時間超えの計算になる。

比較

LTX-2Wan 2.2
Mac対応MLX移植あり。比較的楽公式未対応。GGUF回避が必要
セットアップ難易度低めやや高い
音声同時生成対応非対応
生成速度（Mac）1.3秒動画に約7分（M1 Max 64GB, GGUF）2秒動画に82分（M1 Max 64GB, GGUF）
映像品質良いより高品質（特に14B）
モデルサイズ約42GB1.3B: 数GB / 14B: 数十GB

Macでとりあえず試すならLTX-2が圧倒的に楽。音声も同時に出るのでi2v用途として面白い。Wan 2.2は品質は高いが、Macだと実用的な速度で回すのは厳しく、本気で使うならNVIDIA GPUが欲しくなる。

実機テスト

Wan 2.2: GGUF形式で挑戦

当初は見送るつもりだったが、GGUF形式ならFP8問題を回避してMacでも動かせるという情報を見つけたので試してみる。

必要なのは以下の4つ。

カテゴリファイルサイズ
diffusion_modelswan2.2_t2v_high_noise_14B_Q4_K_S.gguf8.75 GB
diffusion_modelswan2.2_t2v_low_noise_14B_Q4_K_S.gguf8.75 GB
text_encodersumt5-xxl-encoder-Q8_0.gguf6.04 GB
vaewan_2.1_vae.safetensors242 MB

合計約24GB。モデルはbullerwins/Wan2.2-T2V-A14B-GGUF、テキストエンコーダはcity96/umt5-xxl-encoder-gguf、VAEはComfy-Org/Wan_2.2_ComfyUI_Repackagedから取得。

Wan 2.2の14Bモデルはhigh noiseとlow noiseの2ステップ構成になっている。ワークフロー上ではKSamplerAdvancedが2つ直列に繋がっていて、それぞれ別のチェックポイントから読み込んだモデルを使う。

  • 1段目 (high noise): step 0〜10、ノイズ追加あり。全体の構図とレイアウトを決める
  • 2段目 (low noise): step 10〜20、ノイズ追加なし。1段目の出力latentを受け取ってディテールを詰める

ノイズレベルが高い段階と低い段階で別々に最適化されたモデルを使うことで品質を上げる設計。だからGGUFも2ファイル必要になる。

量子化レベルはQ4_K_S。64GBあるからQ8_0でもメモリには載るが、まず動くか確認するのが先。

ComfyUI-GGUFノード

ComfyUI標準のモデルローダーはGGUFを読めない。city96/ComfyUI-GGUFをカスタムノードとしてインストールする必要がある。これを入れるとUnetLoaderGGUFとCLIPLoaderGGUFノードが追加される。

ワークフロー

ComfyUI公式のWan 2.2 T2V 14Bワークフローをベースに、モデルローダーをGGUF版に差し替えた。変更点:

  • UNETLoader × 2 → UnetLoaderGGUF × 2（ファイル名もGGUFに）
  • CLIPLoader → CLIPLoaderGGUF（umt5-xxl GGUF Q8_0に）
  • VAELoader → wan_2.1_vae.safetensorsに変更
  • 解像度を1280x704 → 832x480に下げ、フレーム数も57 → 33に削減（まず動くか確認するため）

VAEの罠

最初 wan2.2_vae.safetensors（1.41GB）を使ったら、80分のサンプリング完了後にVAEデコードでエラーになった。

RuntimeError: Given groups=1, weight of size [48, 48, 1, 1, 1],
expected input[1, 16, 9, 60, 104] to have 48 channels, but got 16 channels instead

wan2.2_vaeは48チャンネル入力を期待するが、T2Vのdiffusion modelは16チャンネルのlatentを出力する。公式ワークフローのノートにも「This model uses the wan 2.1 VAE」と明記されている。Wan 2.2はdiffusion modelだけ新しくなっていて、T2V/I2VのVAEは2.1のものを使う。正しいVAEは wan_2.1_vae.safetensors（242MB）。バージョン番号が揃ってないので注意。

結果: 動いた

VAEを修正して再実行したところ、エラーなく動画が生成された。

プロンプト: “a robot is running through a futuristic cyberpunk city with neon signs and darkness with bright HDR lights”

フェーズ時間
1段目 KSampler (high noise) 10ステップ41分40秒 (250s/step)
2段目 KSampler (low noise) 10ステップ39分21秒 (236s/step)
VAEデコード約1分41秒
合計1時間22分45秒

832x480、33フレーム（16fps = 約2秒）の動画に82分。動くことは動くが、実用的な速度とは言い難い。5秒の動画を作ろうとすると3時間を超える計算になる。

LTX-2: セットアップ

ComfyUIの公式テンプレート「LTX-2 i2v」を使用。ワークフロー読み込み時に以下のモデルのダウンロードを求められる。

カテゴリファイルサイズ
checkpointsltx-2-19b-dev-fp8.safetensors25.22 GB
text_encodersgemma_3_12B_it_fp4_mixed.safetensors8.8 GB
lorasltx-2-19b-distilled-lora-384.safetensors7.15 GB
lorasltx-2-19b-lora-camera-control-dolly-left.safetensors312 MB
latent_upscale_modelsltx-2-spatial-upscaler-x2-1.0.safetensors不明

合計で約42GB。チェックポイントだけで25GBあるので回線によっては待ちが長い。

事前調査ではFP8がMetal非対応という情報があったが、ComfyUI公式テンプレートがFP8チェックポイントを指定しているのでまずこれで試した。

FP8: 動かない

RuntimeError: Undefined type Float8_e4m3fn

55秒でエラー終了。やはりMetalにFloat8_e4m3fn型が実装されておらず、FP8チェックポイントはApple Siliconでは使えない。ComfyUI公式テンプレートがFP8を指定しているのはNVIDIA GPU前提のため。

LTX-2: GGUF形式で再挑戦

FP8がダメならWan 2.2と同じくGGUF形式で行く。Kijai/LTXV2_comfyがLTX-2のGGUF量子化モデルを配布している。

ただしLTX-2はWan 2.2よりもFP8問題の範囲が広い。チェックポイントだけでなく、テキストエンコーダ（Gemma 3 12B）の公式配布版 gemma_3_12B_it_fp4_mixed.safetensors にもFP8テンソルが含まれている。つまりモデル本体とテキストエンコーダの両方をGGUFに差し替える必要がある。

カテゴリファイルサイズ配布元
diffusion_modelsltx-2-19b-dev-Q4_K_S.gguf11 GBKijai/LTXV2_comfy
text_encodersgemma-3-12b-it-Q4_K_M.gguf6.8 GBunsloth/gemma-3-12b-it-GGUF
text_encodersltx-2-19b-embeddings_connector_distill_bf16.safetensors2.7 GBKijai/LTXV2_comfy
vaeLTX2_video_vae_bf16.safetensors2.3 GBKijai/LTXV2_comfy
lorasltx-2-19b-distilled-lora-384.safetensors7.1 GBLightricks/LTX-2

合計約30GB。Wan 2.2の24GBより多いが、64GBあれば問題ない。

Gemma 3もGGUF必須

最初 gemma_3_12B_it_fp4_mixed.safetensors で試したら、チェックポイントと全く同じエラーが出た。

RuntimeError: Undefined type Float8_e4m3fn

名前に「fp4_mixed」とあるが、内部にFP8テンソルが混在している。Macでは使えない。unsloth/gemma-3-12b-it-GGUFからGGUF版をダウンロードし、DualCLIPLoaderGGUFノード（type: ltxv）で読み込む。clip_name1にGemma 3 GGUF、clip_name2にembeddings connectorを指定する。

ComfyUI-GGUFはPR #402でGemma 3をサポート済み。最新版であれば問題ない。

ワークフロー構成

Wan 2.2と違い、LTX-2は1ステージ構成。KSamplerも1つで済む。

  • UnetLoaderGGUF → LoraLoaderModelOnly (distilled LoRA, strength 0.6) → ModelSamplingLTXV (max_shift 2.05, base_shift 0.95)
  • DualCLIPLoaderGGUF (type: ltxv): Gemma 3 GGUF + embeddings connector
  • LTXVImgToVideo: 入力画像からlatentを生成（i2v用）
  • KSampler: 25ステップ, cfg 5.5, euler, normal
  • VAELoader → VAEDecode: LTX2_video_vae_bf16.safetensors

公式ワークフローはdistilled LoRAをstrength 0.6で使用している。devモデル単体だと出力が不安定になるため、この LoRA は実質必須。

T2V テスト: 動いたが品質に難あり

まず512x288、33フレームのText-to-Videoで動作確認した。

フェーズ時間
KSampler 25ステップ6分7秒 (14.7s/step)
VAEデコード約47秒
合計6分54秒

Wan 2.2の82分に対して約12倍速い。ただし解像度が違う（512x288 vs 832x480）のでフェアな比較ではない。映像品質はネオンサインの街並みは生成できていたが、被写体のロボットがブレて判別不能だった。distilled LoRAなし・低解像度が原因と思われる。

I2V テスト

distilled LoRAを追加し、768x512に解像度を上げてImage-to-Videoでテストした。

フェーズ時間
KSampler 25ステップ約12分50秒 (30.8s/step)
VAEデコード約52秒
合計13分42秒

768x512、33フレーム（25fps = 約1.3秒）で13分42秒。T2Vの512x288（6分54秒）と比較すると、ピクセル数2.7倍に対して所要時間は約2倍。解像度を上げても線形には伸びない。

T2Vの出力（distilled LoRAなし、512x288）:

ネオンっぽい色の塊が上下に揺れてるだけ。被写体のロボットは影も形もない。CSSアニメーションで作れるレベルの動きに7分かかった。

I2Vの出力（distilled LoRA 0.6、768x512）:

strengthを0.7に下げてプロンプトも修正した2回目（13分50秒）も含めて、結果は全滅だった。

フレーム間のピクセル差分で動きを解析した結果:

テストフレーム間差分前半/後半の動き状態
T2V (LoRAなし, 512x288)14.514.5 / 14.4画面全体が上下に揺れるだけ。被写体不明
I2V 1回目 (strength 1.0)10.50.2 / 20.8前半静止→後半で突然崩壊
I2V 2回目 (strength 0.7)0.70.2 / 1.213分50秒かけてほぼ静止画

I2Vではstrength 1.0だと入力画像を固定しすぎて前半が完全に静止、途中から制御を失って破綻する。0.7に下げると今度はほぼ動かない。「ちょうどいい」範囲が極端に狭いか、そもそもこの量子化レベルでは動き生成が機能していない。

なぜこうなるか: 設定が公式と違った

上の結果を見て「GGUF量子化が原因では」と考えたが、そもそもワークフロー構成が公式と全然違っていた。原因の切り分けができていない状態。

公式I2Vワークフロー（Lightricks/ComfyUI-LTXVideoのLTX-2_I2V_Distilled_wLora.json）を精査したところ、サンプリングパイプラインが根本的に異なることがわかった。

項目自分のワークフロー公式ワークフロー
モデルdev + distilled LoRAdistilled（蒸留済みモデル直接使用）
サンプラーKSampler 25stepSamplerCustomAdvanced 2段構成
スケジューラnormalManualSigmas（ハードコードされたsigma値）
CFG5.51.0
I2V方式LTXVImgToVideoLTXVImgToVideoInplace × 2回

公式はグループノード内に2段パイプラインを隠している。Stage 1（8ステップ）でノイズ除去してからLTXVImgToVideoInplace(strength=1.0)で再条件付けし、Stage 2（3ステップ）で仕上げる構成。sigma値もManualSigmasでハードコードされていて、LTXVSchedulerは使っていない。

dev + LoRAで動かなかったのは当然で、sigma値が蒸留モデル用にチューニングされているのだから、別のモデルを突っ込んでも正しく動くわけがない。「量子化の劣化」以前の問題だった。

LTX-2: 公式ワークフロー準拠で再テスト

公式と完全に揃えた上でGGUFに差し替えた構成で再検証する。こうすればGGUF量子化とApple Silicon固有の問題だけが変数になる。

蒸留モデルのGGUF

公式はdistilled（蒸留済み）モデルを直接使う。devモデル + distilled LoRAではない。Kijai/LTXV2_comfyからltx-2-19b-distilled-Q4_K_M.gguf（12GB）をダウンロードした。

カテゴリファイルサイズ
diffusion_modelsltx-2-19b-distilled-Q4_K_M.gguf12 GB
text_encodersgemma-3-12b-it-Q4_K_M.gguf6.8 GB
text_encodersltx-2-19b-embeddings_connector_distill_bf16.safetensors2.7 GB
vaeLTX2_video_vae_bf16.safetensors2.3 GB

前回使ったltx-2-19b-dev-Q4_K_S.gguf（11GB）とdistilled LoRA（7.1GB）は不要になった。LoRAを外す分、ワークフローもシンプルになる。

公式2段パイプライン: MPSでNaN

公式I2Vワークフローのサンプリングパイプラインを忠実に再現し、モデルローダーだけGGUF版に差し替えた。

  • UnetLoaderGGUF: ltx-2-19b-distilled-Q4_K_M.gguf（LoRAなし）
  • DualCLIPLoaderGGUF (type: ltxv): Gemma 3 GGUF + embeddings connector
  • ResizeImagesByLongerEdge (768) → LTXVPreprocess (crf=33): 入力画像の前処理
  • LTXVImgToVideoInplace (strength=0.6): 初期I2V条件付け
  • Stage 1: ManualSigmas 1., 0.99375, 0.9875, 0.98125, 0.975, 0.909375, 0.725, 0.421875, 0.0（8ステップ）、CFGGuider cfg=1.0、SamplerCustomAdvanced
  • LTXVImgToVideoInplace (strength=1.0): Stage 1出力の再条件付け
  • Stage 2: ManualSigmas 0.909375, 0.725, 0.421875, 0.0（3ステップ）、CFGGuider cfg=1.0、SamplerCustomAdvanced（seed=420固定）
  • VAEDecode → 保存

公式との差分はモデルローダーのノード種別（UNETLoader/CLIPLoader → UnetLoaderGGUF/DualCLIPLoaderGGUF）とモデルファイル名のみ。パイプライン構造、sigma値、CFG、strength値はすべて公式と同一。

結果、サンプリング自体は8+3ステップ完走するが、VAEデコード時にRuntimeWarning: invalid value encountered in castが発生。出力は1フレームのゴミ画像（17KB）だった。diffusion modelの出力latentにNaN/Infが含まれており、VAEがデコードできていない。

dev GGUF + KSamplerの構成では同じMPS環境で33フレームの動画が出ていたので、GGUF+MPS自体が壊れているわけではない。SamplerCustomAdvanced + ManualSigmasの2段パイプラインがMPSバックエンドと互換性がないと考えられる。

KSampler単段に切り替え

公式パイプラインが動かないので、動作実績のあるKSampler単段構成でdistilledモデルを試した。

  • UnetLoaderGGUF → ModelSamplingLTXV → KSampler (10step, cfg 1.0, euler, normal)
  • LTXVImgToVideo (strength 0.7)
  • 768x512、33フレーム

NaNは出なくなり33フレーム生成された。

フレーム間差分は平均1.19。一部フレームでmax 10.3の動きがあるものの、全体としてはほぼ静止画に近い。dev GGUF + KSampler（CFG 5.5, 25ステップ）のT2Vではフレーム間差分14.5で実際に動いていたのと比べると、distilledモデル + CFG 1.0の組み合わせではKSamplerでの動き生成が機能していない。distilledモデルは公式の2段パイプライン向けにチューニングされており、KSamplerの単純なスケジューラでは期待通りに動かない。

LTX-2の結論

M1 Max 64GBでLTX-2を動かすにはGGUF形式が必須（FP8はMetal非対応）。GGUF + KSamplerの単純な構成なら動画は生成されるが、品質は実用レベルに達しない。公式推奨の2段SamplerCustomAdvanced + ManualSigmasパイプラインはMPSバックエンドでNaNを出して動かない。

構成動作品質
dev GGUF + KSampler T2V動く（7分）被写体が判別不能
dev GGUF + LoRA + KSampler I2V動く（14分）動きが破綻or静止
distilled GGUF + 公式2段パイプラインNaN（動かない）-
distilled GGUF + KSampler I2V動く（3分）ほぼ静止画

公式パイプラインがMPSで動かない以上、Mac上でLTX-2のまともな動画生成は現時点では難しい。NVIDIA GPU環境が必要。