【検証】8GB VRAMの普通のPCで話題のMiniMax H3は動くのか？RTX 3050の限界に挑んだ結果

前回の記事で、話題の動画生成AI「MiniMax H3」を使う方法を7パターン紹介しました。

今回はその実践編。「12GB VRAMでも動く」と言われるH3を、あえてそれ未満のマシンで動かしたらどうなるのか。人柱になってきました。

検証機のスペックはこちら。

CPU Core i7-12700KF

メモリ 32GB

GPU RTX 3050（VRAM 8GB）

Windows 11 Pro

ゲーミングPCとしてはよくある構成です。H3の推奨ラインはVRAM 12GB以上、RAM 64GB以上。つまりVRAMもRAMも足りていません。「うちのPCもこれくらいだけど、動くの？」という人のための検証です。

先に結論を言います。動きました。それも、HD解像度の音楽つき動画まで完走しました。ただし、限界は別の形でやってきます。詳しくは後半で。

壁その① 1ヶ月前に入れたComfyUIですら「古い」

まず既存のComfyUI（Windows Portable版）を起動してバージョンを確認しました。

ComfyUI version: 0.27.0

H3を動かすにはComfyUI 0.30.0以上が必要です。
この環境、実は2026年7月に更新したばかり。
それでもH3には古い。この世界、1ヶ月離れると浦島太郎になります。

さらに起動ログには不穏な警告が2つ出ていました。

1つ目は「pytorch with cu130 or higher」が必要という警告。
H3の量子化処理の高速版はCUDA 13世代が前提で、古いままだと遅いフォールバック動作になります。

2つ目が致命傷で、「DynamicVRAM support requires Pytorch version 2.8 or later」。低VRAMでH3を動かす鍵である動的VRAMオフロードが、PyTorch 2.8以降でないと使えません。
この環境は2.6。VRAM 8GBでオフロードなしは、始まる前から終わっています。

つまりComfyUI本体、PyTorch、CUDAの三段更新が必要という状態でした。

壁その② 更新用batが「静かに」失敗する

Portable版には update_comfyui.bat という更新スクリプトが同梱されています。これを実行したところ、一見成功したように見えて、実は失敗していました。

ログをよく見ると、新しいバージョン（frontend 1.48.6など）をダウンロードして古いものをアンインストールしたのに、最後の「Successfully installed」には古いバージョン番号（1.45.20など）が並んでいる。
矛盾しています。
途中には「Failed to remove contents in a temporary directory」という警告も。埋め込みPython環境の更新が中途半端に転んだ状態です。

エラーで止まってくれれば気づけますが、これは正常終了したフリをする。一番タチの悪い失敗です。
昔からPortable版を使っている人は、同じ罠にハマる可能性が高いと思います。

ここで方針転換しました。古い環境を修復するより、新規で入れ直したほうが早い。

転機 最新のデスクトップ版が優秀すぎた

ComfyUIには現在、公式のインストーラー付きデスクトップアプリ「Comfy Desktop」があります。これを新規インストールしてみたところ、想定外の展開になりました。

インストール時にCloudかLocalかを選び（今回は無料で使えるLocal）、インストール先を指定して進むと、初期セットアップの中に「Choose a starter workflow」という画面が出てきます。そこに、

MiniMax H3が「Recommended」として最初から選択されているんです。サイズ約53GB。チェックを入れてInstallを押すだけで、モデルのダウンロードから配置まで全部インストーラーがやってくれます。

これ、事前に調べていた導入手順だと「モデル4ファイル（拡散モデル、テキストエンコーダ、映像VAE、音声VAE）を自分でダウンロードして、それぞれ正しいフォルダに配置する」という一番ミスりやすい工程だった部分です。それが丸ごと消えました。

インストール後にバージョンを確認すると、

ComfyUI 0.30.2、PyTorch 2.12.1+cu130。Portable版で立ちはだかった三段の壁が、新規インストール一発で全部消えていました。

2026年8月時点で、H3の導入は「インストーラーの指示に従うだけ」まで簡単になっています。
手動配置の解説記事を書くつもりだったのに、その必要がなくなってしまった。

ということは、です。導入のハードルが消えた今、残る壁はただ1つ。マシンスペックだけ。

いざ生成テスト

セットアップが終わると、H3のテキストから動画のワークフローが開きます。

構成はシンプルで、解像度を決めるセレクター、プロンプトと各種設定が入ったメインノード、保存ノード。
テンプレートにはアクション映画の逃走シーンを丸ごと指定した英語のサンプルプロンプトが最初から入っていて、カット割りをタイムコードで指定し、音声（風、足音、環境音、音楽の盛り上がるタイミングまで）を文章で指示する形式になっています。
今回は品質ではなく生存確認が目的なので、プロンプトはこのサンプルのまま使いました。

1発目は最小構成。解像度セレクターを0.2メガピクセル（608x352）、長さ2秒に設定して実行。

一番死ぬ確率が高いと踏んでいたモデル読み込みとサンプリング開始を、8GB VRAMが生き延びました。そして約4分後、動画が出てきました。

再生してみて驚いたのは音です。映像に音楽が乗っている。
プロンプトの音声指示が効いて、BGM付きの動画が一発で出てくる。
これがH3の音声同時生成です。編集ソフトを一度も開いていないのに、です。

ここから条件を上げていきました。結果がこちら。

生成時間の一覧（5秒動画、24fps、キューの実測値）

608x352（0.2MP）2秒 232秒（約4分）
https://x.com/yukiGPTs/status/2085270548716953797

608x352（0.2MP）5秒 416秒（約7分）
https://x.com/yukiGPTs/status/2085270700731023756

864x480（0.4MP）5秒 886秒（約15分）
https://x.com/yukiGPTs/status/2085270835741491645

1280x736（0.9MP）5秒 3082秒（約51分）
https://x.com/yukiGPTs/status/2085270959586770978

全部完走です。OOM（メモリ不足クラッシュ）は一度も起きませんでした。

数字を眺めると面白い傾向が見えます。
尺を2秒から5秒に伸ばしても時間は1.8倍程度。
ところが解像度を上げると、0.2MPから0.4MPで2倍、0.4MPから0.9MPで3.5倍と、生成時間が跳ね上がる。
H3の処理コストは尺よりも解像度に強く支配されています。

白状すると、最後の1280x736はかなり劣悪な条件で走らせています。ブラウザを閉じられない事情があって、開始時点でメモリ使用率93%、Chromeだけで約8GB食っている状態でした。

それでも落ちなかった。VRAMから溢れた分をRAMへ、RAMから溢れた分をSSDのページファイルへと逃がしながら、51分かけて完走しました。ComfyUIの動的VRAMオフロードは相当に優秀です。

結論 「落ちない」。限界は生成時間という形でやってくる

RTX 3050、8GB VRAM、32GB RAMという推奨未満のマシンで、MiniMax H3は動きました。それもHD解像度（1280x736）の音楽つき動画まで。

ただし限界は、クラッシュではなく時間という形で現れます。SNS用の下書きやプロンプト実験なら608x352の7分で十分回せますが、1280x736は1本51分。
1日かけても10本ちょっとしか作れません。「動く」と「量産できる」の間には、まだ距離があります。

それでも、この検証で使ったお金は0円です。API課金なし、サブスクなし、かかったのは電気代だけ。
3日前まで一部の人しか触れなかった最先端の動画生成AIが、8GBのグラボで、無料で、音楽つきの動画を吐き出す。とんでもない時代になりました。

じゃあ、高解像度を実用的な速度で量産したい場合はどうするか。グラボを買い替える前に、試す価値のある方法があります。
1時間数百円で最強クラスのGPUを借りて動かすやり方です。

次回はそのRunPod導入編。今回と同じく、実際に一から検証して書きます。

さらにその先で、こうした環境構築そのものを不要にする仕組みを自分で開発することにしました。
RunPodの検証は、その開発の第一歩でもあります。

続報を見逃したくない人はフォローをどうぞ。