TL;DR

オープンウェイトで公開された MiniMax H3 のImage-to-Videoを、RTX A6000 48GB で動かした
ComfyUIを推論バックエンド、FastAPIをジョブ管理API、HTML/CSS/JavaScriptをUIにして、画像とプロンプトを投げられるWebアプリにした
量子化済みモデル一式は約40GB。384x672、約5.2秒、24fpsの動画生成に 約288秒、GPUメモリ約29GB だった
CUDAの互換性よりも、ComfyUI APIの動画出力がvideosではなくimagesに入る問題で最後に詰まった
サーバーは外部公開せず、127.0.0.1で待ち受けてSSHポートフォワーディング経由で利用している

MiniMax H3のweights公開と同日にComfyUI側にも対応が入ったので、さっそく動かしました。

ComfyUIの画面をそのまま使うだけなら比較的簡単ですが、今回は「画像を選ぶ・動きを文章で指定する・待つ・動画を見る」だけのWebアプリとして使えるところまで持っていきます。

この記事は2026年8月4日時点の検証記録です。公開直後のモデル・ComfyUIを扱っているため、ファイル名やノード仕様は今後変わる可能性があります。

MiniMax H3とは

MiniMax H3は、動画と音声を一体で生成できるオープンウェイトの動画生成モデルです。ComfyUIの公開時アナウンスでは、Text-to-Video、Image-to-Video、First/Last Frame、Reference-to-Videoなどのworkflowが案内されています。

今回使うのは、1枚の参照画像とテキストから動画を作る Image-to-Video (I2V) です。

公式weights: https://huggingface.co/MiniMaxAI/MiniMax-H3
ComfyUI向けweights: https://huggingface.co/Comfy-Org/MiniMax-H3
ComfyUI workflow: https://docs.comfy.org/tutorials/video/minimax/minimax-h3

ComfyUI向けの小型構成では、modulation weightのpruning、int8 convrot量子化、custom kernelなどにより、full precisionよりメモリ使用量を抑えています。とはいえ、テキストエンコーダー、diffusion model、video/audio VAEを合わせると、保存だけで約40GB必要でした。

構成

今回の構成は次の通りです。

MacBook / Browser
    |
    | SSH local port forwarding
    v
FastAPI :7860 (127.0.0.1)
    |
    | POST /prompt, GET /history/{prompt_id}
    v
ComfyUI :8190 (127.0.0.1)
    |
    v
MiniMax H3 / RTX A6000 48GB

項目	構成
GPU	NVIDIA RTX A6000 48GB
OS	Linux
ComfyUI	0.30.0
Python	3.12
PyTorch	2.5.1+cu121
Web API	FastAPI + Uvicorn
Frontend	Vanilla HTML/CSS/JavaScript
接続	SSH local port forwarding

Webアプリを推論サーバーと分けた理由は、ComfyUIを「workflow実行エンジン」として扱いたかったからです。ノードをGUIで検証した後、そのworkflowをAPI形式のJSONに落とせば、UIは用途に合わせて自由に作れます。

1. ComfyUIとモデルを用意する

ComfyUIをcloneし、仮想環境へ依存関係を入れます。

git clone https://github.com/Comfy-Org/ComfyUI.git
cd ComfyUI
python3 -m venv .venv
.venv/bin/python -m pip install -r requirements.txt

今回はGPUドライバがCUDA 13系PyTorchを扱えなかったため、CUDA 12.1版へ合わせました。

.venv/bin/python -m pip install \
  torch==2.5.1 torchvision torchaudio \
  --index-url https://download.pytorch.org/whl/cu121

使ったモデルファイルは次の4つです。

models/
├── diffusion_models/
│   └── minimax_h3_fl2va_pruned_int8_convrot.safetensors
├── text_encoders/
│   └── qwen3vl_32b_minimax_h3_nvfp4_awq.safetensors
└── vae/
    ├── minimax_h3_video_vae_fp16.safetensors
    └── minimax_h3_audio_vae_fp32.safetensors

ファイル名や配置先は更新される可能性があるので、実際にはComfyUI公式workflowページのリンクを確認するのが確実です。

起動は次の通りです。

.venv/bin/python main.py \
  --disable-auto-launch \
  --listen 127.0.0.1 \
  --port 8190 \
  --lowvram

0.0.0.0ではなく127.0.0.1で待ち受けます。認証なしのComfyUIを、そのまま共有サーバーのネットワークへ露出させないためです。

2. ComfyUI workflowをAPI用JSONにする

I2V workflowの主要部分は次の流れです。

LoadImage
  -> MiniMaxH3ImageToVideo
  -> SamplerCustomAdvanced
  -> Video VAE Decode
  -> Audio VAE Decode
  -> CreateVideo
  -> SaveVideo

FastAPI側では、入力画像名、prompt、解像度、フレーム数、seed、出力先だけをリクエストごとに差し替えます。

def workflow(image_name, prompt, width, height, length, seed, job_id):
    return {
        "1": {
            "class_type": "LoadImage",
            "inputs": {"image": image_name},
        },
        "6": {
            "class_type": "MiniMaxH3ImageToVideo",
            "inputs": {
                "clip": ["3", 0],
                "vae": ["4", 0],
                "first_frame": ["1", 0],
                "prompt": prompt,
                "width": width,
                "height": height,
                "length": length,
            },
        },
        # sampler / decode nodesは省略
        "15": {
            "class_type": "SaveVideo",
            "inputs": {
                "video": ["14", 0],
                "filename_prefix": f"h3-web/{job_id}",
                "format": "mp4",
                "codec": "h264",
            },
        },
    }

フレーム数を`17k+5`へ合わせる

MiniMax H3のノードでは、長さを任意の整数にするのではなく、workflowが受け付ける系列長へ合わせる必要がありました。24fpsで指定秒数に近いフレーム数を求め、17k+5の形へ切り上げます。

def frame_count(seconds: int) -> int:
    frames = max(5, round(seconds * 24))
    return frames + (5 - frames % 17) % 17

5秒指定の場合は124 framesとなり、出力は約5.17秒でした。

3. FastAPIで非同期ジョブにする

動画生成には数分かかります。HTTPリクエストを開いたまま待つ設計にはせず、生成要求でjob IDを即座に返し、ブラウザがstatusをpollingする形にしました。

@app.post("/api/generate")
async def generate(
    background_tasks: BackgroundTasks,
    image: UploadFile = File(...),
    prompt: str = Form(...),
    preset: str = Form("portrait"),
    seconds: int = Form(5),
    seed: int = Form(26080401),
):
    job_id = uuid.uuid4().hex
    # MIME type、15MB上限、Pillowで画像実体を検証
    # ComfyUI/inputへ保存

    jobs[job_id] = {"status": "queued", "progress": 0}
    background_tasks.add_task(run_generation, job_id, ...)
    return jobs[job_id]

バックグラウンドではComfyUIの/promptへworkflowを送信し、返ってきたprompt_idのhistoryをpollingします。

queued = await client.post(
    "http://127.0.0.1:8190/prompt",
    json={"prompt": workflow_json, "client_id": f"h3-web-{job_id}"},
)
prompt_id = queued.json()["prompt_id"]

while True:
    await asyncio.sleep(5)
    history = (
        await client.get(f"http://127.0.0.1:8190/history/{prompt_id}")
    ).json()
    if history:
        # outputを取り出してcompleteへ更新
        break

GPU 1枚へ同時に複数jobを投げないよう、asyncio.Lockで生成部分を直列化しています。本格運用ならRedisとworker queueへ分けるところですが、自分用の単一GPU環境ではこれで十分です。

4. 最後に詰まった: 動画なのに`images`へ入る

推論logには次のように出て、MP4も保存されていました。

Prompt executed in 287.50 seconds

ところがWeb側は永遠にgeneratingのまま。historyを直接見ると、原因はこれでした。

{
  "outputs": {
    "15": {
      "images": [
        {
          "filename": "..._00001_.mp4",
          "subfolder": "h3-web",
          "type": "output"
        }
      ],
      "animated": [true]
    }
  }
}

SaveVideoの出力なのでvideosを想定していましたが、手元のComfyUI 0.30.0ではMP4もimages配列に格納されていました。両方を許容して解決しました。

save_output = record.get("outputs", {}).get("15", {})
outputs = save_output.get("videos") or save_output.get("images", [])

5. Web UI

UIには次の項目だけを出しました。

参照画像のdrag & drop
動き・カメラ・維持したい要素を書くprompt
portrait / square / landscape
5秒 / 8秒 / 10秒
seed
生成statusと動画preview/download

また、人物画像の利用を想定して、本人または権利者の許可を得た画像であることの確認と、生成結果がAI生成である旨の表示を入れています。

6. 外部公開せずSSH tunnelで使う

FastAPIもlocalhostだけで起動します。

uvicorn app:app --host 127.0.0.1 --port 7860

Mac側からSSH local port forwardingを張ります。

ssh -N -L 7860:127.0.0.1:7860 <gpu-server>

これで手元のブラウザから次へアクセスできます。

http://127.0.0.1:7860

GPUサーバー側でpublic portを開ける必要はありません。個人利用や検証段階なら、認証・TLS・reverse proxyを急いで作るより、SSH tunnelに閉じ込める方が管理しやすいです。

実際の生成例: 架空の芸人に漫才をさせる

静止画からどの程度動かせるのかを見るため、以前Geminiで生成した架空の芸人2人の画像を参照フレームにしました。実在人物の写真や声は使っていません。

入力画像

promptには、役割、台詞、画角、維持したい要素、AI生成表示をまとめて指定しました。

明確なAI生成パロディ映像。舞台上の二人が日本語でテンポよく漫才をする。
左の男性が落ち着いたツッコミ、右の男性が陽気なボケ。
本人の声は模倣せず、二人とも架空の自然な日本語男性合成音声。
右「どうもー、生成AI漫才です！」
左「コンビ名みたいに言うな」
右「今日はGPUを三分だけ借りました」
左「動画より短いやないか！」
観客の自然な笑い声。固定カメラ、自然な口の動き、
人物・衣装・舞台・マイクを維持。
画面左上に小さく AI生成パロディ と常時表示。

出力（10.1秒、GIF版は無音）

音声付きMP4を開く

672x384、24fps、20 stepsで生成し、約8分でした。5秒・384x672の試行より時間が延びているので、当然ながら「尺を2倍にすると同じ時間で済む」わけではありません。

中間フレームでも人物、衣装、舞台、中央のマイクは維持されました。一方、長い台本を一度に正確に読ませる用途ではなく、短い発話単位に分割した方が制御しやすいです。2〜3分の漫才を作るなら、10〜15秒のshotを複数生成し、音量と間を調整して結合する構成になります。

実測結果

同一条件で、Web UIからupload、workflow投入、生成完了検知、MP4 downloadまで確認しました。

項目	結果
GPU	RTX A6000 48GB
入力	人物を含む縦長JPEG 1枚
出力解像度	384x672
出力尺	5.167秒
fps	24
映像codec	H.264
音声codec	AAC stereo
sampling steps	20
推論時間	287.50秒
確認したGPUメモリ使用量	約29GB
出力サイズ	約477KB

これは高解像度性能のbenchmarkではなく、「48GB GPU 1枚でWebアプリとして一連の経路が動くか」のsmoke testです。解像度・尺・offload・量子化方式を変えれば、時間とメモリ使用量は大きく変わります。

おわりに

MiniMax H3を動かすだけならComfyUIの公式workflowで十分です。一方、他の人が繰り返し使う道具にするには、upload validation、job queue、完了検知、output配信、network境界まで含めて設計する必要があります。

今回の実験では、A6000 48GB 1枚で、量子化済みI2Vを約29GBのGPUメモリ、約5分で実行できました。そして一番時間を使ったのはモデル本体ではなく、ComfyUI APIのimages/videos差分でした。

参考