MiniMax-H3をMacで動かしてみた

最近、MiniMax-H3という動画生成モデルが公開されました。開発元はMiniMaxAI、330億パラメータのモデルで、映像と音声を1回で同時に作れるのが特徴です。

画像や動画の生成は、Macが苦手とされてきた領域です。この種の処理はNVIDIAのGPUを前提に作られていることが多く、Macでは動かないか、動いても実用にならないと言われてきました。それでも手元で完結するなら試す価値はあると思い、MiniMax-H3がMacでも動かせるのかを検証してみました。

結果から書くと、動きました。しかも音声つきです。ただ、そのままでは動かない落とし穴が1つあり、そこを越えるのに一番時間がかかりました。

使った環境はM5 Max・メモリ128GB・macOS 26.6.2、ComfyUIのバージョンは0.35.1です。環境によって結果は変わりますので、1つの参考として見ていただければと思います。

MiniMax-H3とは何か

MiniMax-H3は、動画と音声を1回の推論で同時に作るモデルです。

ここが従来の動画生成AIと違うところです。これまでの多くのモデルは、映像だけを作ります。音は後から別途つけることになる。効果音を探してきて、タイミングを合わせて、音楽を重ねる。あの作業です。

H3はそれを一度にやります。「雨上がりの夕暮れの街」と書けば、映像と一緒に雨上がりの環境音が出てくる。「足音を速く」と書けば、その足音が映像の動きと合った位置に入る。出力は最大24fps・約15秒です。

つまり、映像と音を別の工程として考えなくてよくなるということです。ここが面白いと思って試してみました。

先に結論：どれくらいの時間で何が作れたか

細かい手順の前に、実測値を出しておきます。そのほうが「やるかどうか」を判断しやすいと思うからです。

条件（8ステップ・高速化LoRAあり）	実行時間
608×352・2.33秒	93.7秒
864×480・2.33秒	203.0秒
864×480・5.17秒	414.6秒（約7分）
864×480・2.33秒（画像から動かす）	199.9秒

864×480・5秒の動画が約7分でできる、というのが今回の実用ラインでした。

なお、その日の1本目にはモデルの読み込み時間が加わります。ダウンロードしたファイルは合計で約44GBあり、そのうち36GBほどをメモリへ読み込むためです。上の表の1行目と2行目がそれにあたります。2本目以降は読み込みが済んでいるので、その分だけ速くなります。

出力は映像がH.264の864×480、音声がAAC・32kHzのステレオです。無音ではなく、実際に波形の入った音が出ています。指示したカット割り（ショット1、ショット2……）も、書いたとおりに切り替わりました。

実際に出てきたものを載せておきます。表の3行目、864×480・5.17秒・約7分かかったものです。

ちなみに、この表の数字を他の方の報告と比べてみます。私が見かけた範囲では、M4 Pro・64GBで608×352・5秒・10ステップが約18分、M4 Max・128GBで480p・15秒が約1時間30分とのことでした。ステップ数などの条件が違うので単純比較はできませんが、世代が上がった分だけ速くなっているようです。

つまずいた1点：そのままでは動かない

さて、ここからが本題です。

手順どおりにモデルを置いてワークフローを開き、実行ボタンを押すと、生成が始まった直後にこう言って止まります。

The operator 'aten::_int_mm' is not currently implemented for the MPS device.

「その演算はMac用に実装されていません」という意味です。私の環境だけの問題ではないはずです。原因はComfyUI本体のコードにあるので、0.35.1をMacで動かす限り、同じところで止まると考えられます（将来のバージョンで直れば出なくなります）。

なぜ起きるのか

少し中身の話をします。難しければ飛ばしていただいて構いません。

AIの計算を速くする仕組みの中に、NVIDIAのGPU専用のものがあります。Macには無いので、使ってはいけない。ComfyUIはそれを分かっていて、「Macならこの高速化は使わない」という判定を持っています。

ところが、その高速化を呼び出す関数のうち1つだけが、その判定を見ていませんでした。MiniMax-H3の内部構造がちょうどその関数を通るので、開始と同時に落ちる。そういう筋でした。

つまり、Macに対応していないのではなく、対応の判定が1箇所だけ抜けていたということです。

直し方は1行

comfy/ops.py の条件式に、判定を1行足すだけです。

    if (comfy.model_management.in_training
            or not isinstance(weight, QuantizedTensor)
            or weight._layout_cls != "TensorWiseINT8Layout"
            or not comfy.model_management.supports_int8_compute(x.device)   # ← この行を追加
            or getattr(weight._params, "transposed", False)):
        return linear(INPUT_ACT_EAGER[input_act](x))

これで動くようになりました。原因が分かってしまえば1行ですが、そこに辿り着くまでが長かったです。

ただし注意点があります。 これはComfyUI本体のファイルなので、本体を更新すると消えます。更新したあとに同じエラーが出たら、まずこのパッチが残っているかを疑ってください。私はバックアップを取ったうえで、この症状が出たら再適用する、と手順書に書き残しました。

修正後はサーバーの再起動が必要です。ComfyUI Desktopの場合、プロセスを落としても自動では戻ってこないので、アプリを起動し直してください。

分かったこと：所要時間はだいたい見積もれる

今回いちばん実用的だった発見はこれです。

生成時間は「画素数 × フレーム数」におおむね比例します。

最初は表の数字から当たりを付けただけだったので、モデルを読み込み済みにした状態で測り直しました。

• フレーム数の軸：56枚から124枚へ2.21倍にすると、時間は297.3秒→628.6秒で2.11倍
• 解像度の軸：608×352から864×480へ、画素数を1.94倍にすると、時間は約110秒→195.4秒で1.78倍（別の日に測ったときは2.17倍でした）

比べるときは、同じ軸の2つを同じ状態で測っています。上下で秒数の水準が違うのは、後で書くとおりマシンの状態が違うためです。

どちらも比のとおりぴったりにはなりませんが、±15%ほどの幅には収まります。ですので、きっちり比例するというより、待ち時間を見積もれる程度には比例する、と受け取ってください。

同じ条件でも1.5倍変わることがある

測り直している途中で、ばらつきの原因を1つ見つけました。別のAIモデルをメモリに載せたままだと、生成時間が大きく延びます。私の環境では言語モデルが35GB分載ったままになっていて、864×480・2.33秒が195.4秒から297.3秒へ、1.5倍に延びていました。

ローカルでAIを動かしていると、前に使ったモデルがメモリに残っていることがあります。時間を比べるときは、まずそれを解放してから測るほうが確かです。

見積もりの目安

以下は実測から作った目安です。その日の1本目には、これにモデルの読み込み時間が加わります。

解像度	2秒	5秒
608×352	約1.5〜2分	約3.5〜4分
864×480	約3〜3.5分	約7分
1344×768（テンプレートの既定値）	約8分	約17分

ここで気をつけたいのが最後の行です。公式テンプレートの既定値は1344×768・5秒になっていて、それをそのまま実行すると約17分かかる計算になります。最初の1本でこれをやると、動いているのか止まっているのか分からないまま待つことになります。

ですので、初回は必ず小さく始めてください。608×352・2秒・高速化LoRAありなら、モデルの読み込みを含めても2分ほどで終わります。まずそれで最後まで通ることを確認してから、上げていくほうが早く進みます。

その1分半で出てきたものがこちらです。小さいサイズでも、動きと音が最後まで通っているかは十分に確認できます。

なお、指定した秒数はそのまま通りません。フレーム数が「17の倍数に5を足した数」に切り上げられる仕組みになっているためで、2秒と指定すると56フレーム（2.33秒）、5秒なら124フレーム（5.17秒）になります。秒数を入れれば自動で計算されるので、少し長くなる、とだけ覚えておけば十分です。

画像から動かす、続きを作る

テキストから動画を作る以外に、開始画像を指定して動かすこともできます。

これは別のワークフローに切り替える必要がある、と思っていたのですが、違いました。同じ仕組みの中で「開始画像」が任意の入力になっていて、画像を繋げばそのまま画像からの生成になります。繋がなければテキストからの生成です。時間も変わりませんでした。

指定した画像がどれくらい忠実に使われるのかも測ってみました。出来上がった動画の1フレーム目と、渡した画像の画素の差を計算したところ、平均で4.37。これは動画に変換したときの誤差の範囲で、渡した画像がほぼそのまま1フレーム目になっていると言えます。

面白かったのはこの先です。出来上がった動画の最後の1枚を、次の生成の開始画像として渡すと、続きが作れます。実際に5秒のクリップの最終フレームから2.3秒を継ぎ足してみたところ、登場人物も街並みも光の向きも保たれたまま、動きが自然に続きました。

つまり、短いクリップしか作れないモデルでも、繋いでいけば長くできるということです。1本あたり7分かかることを考えると現実的な使い方かどうかは別として、仕組みとしては成立していました。

プロンプトの書き方

H3は映像と音声を一緒に作るので、指示も1つの文章にまとめて書きます。

私が使っている形はこうです。

（全体のトーン・画づくり・レンズ・色）

Scene overview: 何が起きている場面か

Storyboard:
[0s-1.5s] Shot 1: 開始の画とカメラアングル
[1.5s-3s] Shot 2: カットの切り替わりと被写体の動き
[3s-5s] Shot 3: 締めの画

Camera: カットの切り替え方
Audio: 環境音、効果音、音楽
（入れたくないもの：文字、字幕、ロゴなど）

ショットごとに時刻で区切るのがコツでした。ここを書かずに雰囲気だけを渡すと、カットが切り替わらずに1カットで終わったり、逆に細かく切れすぎたりします。時刻を書くと、そのとおりに切り替わりました。

日本語のセリフを言わせることもできて、その場合は本文の中に <d>[Japanese] セリフ本文</d> の形式で書きます。

ただし、プロンプト自体は英語のほうが安定します。私は日本語で内容を考えてから、英語に直したものを渡しています。この翻訳はAIにやらせればよいので、手間にはなりません。

考察：「試す」には十分、「量産」には向かない

ここまで良いことを書いてきましたが、正直な評価も書いておきます。

高速化の仕組みがNVIDIA専用である以上、Macでは本来の速度は出ません。エミュレーションで動いているだけです。私が見かけた報告では、NVIDIAのRTX 5060 Ti（16GB）で8秒の動画が10分とのことでした。条件が揃っていないので数字をそのまま並べることはできませんが、画素数と長さを揃えて比べれば、こちらが不利なのは間違いないと思います。

ではやる意味がないかというと、そうは思いませんでした。

理由は2つあります。1つは、待ち時間が計算できること。7分かかると分かっていれば、その間に別の作業をすればいいだけです。何分かかるか分からない待ち時間と、7分と分かっている待ち時間は、同じ7分でも性質が違います。

もう1つは、手元で完結することです。枚数を気にせず試せますし、作ったものがどこにも送られません。1本ずつ丁寧に作るなら、この性質のほうが効いてくる場面はあると思います。

つまり、「量産する道具」としては厳しいが、「試す道具」としては十分というのが今回の結論です。これは人それぞれの使い方によるので、1つの見方として受け取っていただければと思います。

まとめ

長くなったので、要点を並べておきます。

• MiniMax-H3は映像と音声を1回で同時に作るモデルで、音を後からつける工程が要らなくなる
• Macでは本体に1行の修正が必要（ComfyUI 0.35.1時点）。しないと開始直後に止まる。そして本体を更新すると消える
• 生成時間は画素数×フレーム数におおむね比例するので、事前に見積もれる。864×480・5秒で約7分。ただし他のモデルをメモリに載せたままだと1.5倍ほど延びる
• 公式テンプレートの既定値は重すぎる。初回は608×352・2秒から
• 開始画像は任意の入力なので、同じワークフローのまま画像から動かせる。最終フレームを渡せば続きも作れる

そして何より、動いたときに音が一緒に出てきたのが単純に面白かったです。映像だけが出てくるのと、雨の音と足音がついてくるのとでは、受ける印象がずいぶん違いました。

次回は、ここで作った素材を実際に何かの形にまとめるところまでやってみたいと思います。