このページは、MiniMax H3 を手元で動かしていて当方が実際に遭遇した症状を、原因と対処つきで並べた早見表です。症状から引けるようにしてあります。新しく分かったことがあれば行を足し、原因が確定したら「確かさ」を書き換えます。
最終更新: 2026年10月7日
目次
読み方
- すべて当方の環境で起きたことです。同じ症状でも、原因が別のこともあります。
- 「確かさ」の欄で、どこまで分かっているかを分けています。
| 確かさ | 意味 |
|---|---|
| 確定 | 条件を1つだけ変えた比較か、ログ・記録で原因を確認した |
| 有力 | 状況からそう判断しているが、比較で確かめきれていない |
| 未解決 | 原因が分かっていない。分かっていることだけ書いている |
- 環境の略し方: 「Mac」=MacBook Pro M5・32GB、「デスクトップ」=RTX 5060 Ti 16GB・Windows、「クラウド」=RunPod。
最初に見る2点
当方の経験では、絵や動きが崩れたときの主な原因は、機材の性能やデータの量ではなく、次の2つでした。ほかの行を当たる前に、まずここを確かめるのが早道です。
- プロンプトの書き方。 あいまいな記述、「〜しない」という否定の表現、推敲の途中で壊れた文。否定の表現は書かないほうが良い、というのが当方の結論です。
- 参照動画の中身。 表示上のfpsではなく実際のコマ数と、プロンプトに書いた時刻とのずれ。
1. 落ちる・止まる・始まらない
スクロールできます
| 症状 | 原因 | 対処 | 確かさ |
|---|---|---|---|
| 生成を投げて約30秒後にMacが固まり、数分後に再起動した | 32GBのメモリに合計約40GBのモデルを載せようとした(本体18.5GiB+テキストエンコーダ18.4GiB+VAE約5GB)。エラーで止まらず、GPU側の障害として機械ごと落ちる | 実行前に、使うモデルのファイルサイズを足して搭載メモリと比べる。テキストエンコーダをCPUに置く設定は、CPUとGPUがメモリを共有するMacでは逃げ道にならない | 確定 |
| デスクトップで、15秒+参照動画の生成が41分後にメモリ不足で落ちた | テキストエンコーダをCPUに置いていたため前処理に約41分かかり、そのあと本体を読む時点でVRAMの空きが約950MBしかなかった | ComfyUI を0.36.0に上げ、テキストエンコーダを nvfp4 版、本体を int8_convrot 版に替え、参照動画を縮小版(288×512)にした。同じ0.6MP・15秒・参照動画ありが37分55秒で完走した | 有力(複数の変更を同時に行った) |
| 生成が止まり、GPU使用率0%のまま応答がなくなる | プロンプトが長すぎる。969語で、遅くなるのではなくGPUごと固まった(96GBの機体でもVRAM約9割まで逼迫) | 768語以内に収める(768語は1.0MP・20stepで2本完走)。外から状態を監視し、「VRAM約9割・GPU 0%・応答なし」が出たら早めに止める。768〜969語の間は試していない | 確定(固まったのは1例) |
| プロンプトを短くしたいが、情報を減らしたくない | — | 時刻の区間をまとめて減らすより、1文ずつを短い命令文に締めるほうが短くなった(13区間を保ったまま768語) | 確定(1例) |
| 拡大(SeedVR2)で、5秒は通るが15秒はメモリ不足で落ちる | 復元結果の全コマ分を、GPU上に一括で確保する作りになっている。必要量がコマ数と出力解像度だけで決まる | Real-ESRGAN(x4plus で4倍→0.5倍に戻す)に替える。15秒が26分07秒で通る。ただしメインメモリを最大57.6GB使う | 確定 |
| コマ補間のあと、そのまま拡大に流すと ComfyUI ごと落ちる | 補間で2倍に増えた約720コマを、一度に4倍拡大へ通した | 生成・補間・拡大を別々に実行する | 確定(1例) |
| h3.c が寸法のエラーで始まらない | 解像度が32の倍数でない | 672×928、800×1056 のように32の倍数にする | 確定 |
| h3.c が起動時にオプションのエラーで止まる | SSDストリーミングと int8 系のオプションを同時に指定した | 併用しない。32GBのMacではSSDストリーミングを優先する | 確定 |
This gguf file is incompatible with llama.cpp! と出る | 古いワークフロー(GGUF用のローダー)を、新しい環境で開いた | 新しい構成のワークフローを使う | 確定 |
| クラウドで、機体は動いているのに ComfyUI だけ応答しなくなる(課金は続く) | 分かっていない。メモリ不足で強制終了されたか、ターミナルの切断に巻き込まれた可能性 | ComfyUI をターミナルから切り離して起動する(setsid nohup)。再起動の前にログを確認する | 未解決 |
2. LoRA まわり
スクロールできます
| 症状 | 原因 | 対処 | 確かさ |
|---|---|---|---|
| LoRA を繋いだのに効いていない。エラーは出ない | 読み込むノードの種類が LoRA のファイル形式と合っておらず、適用が0件だった。LightX2V Turbo 8step v1.0 を MiniMaxH3TurboLoRA ノードで読むと起きる | 標準の LoraLoaderModelOnly で読み込む。実行ログの適用件数で確かめる(正常なら 208 patches attached、この不具合では 0 patches attached) | 確定 |
| 高速化 LoRA を使っているのに、雲状のノイズや指定外の内容が出る | 上の「適用0件」のまま、少ないstep数で焼いていた可能性 | まず適用件数を確かめる | 有力 |
| 人物 LoRA を入れたら、途中から帽子をかぶる・モヤがかかる・崩れる | はっきりしない。6〜8stepの試し焼きで起きており、設定に無理があった可能性がある | 20stepで焼き直した1本では出なかった。評価は本番と同じ設定で行う | 未解決 |
| Mac の h3.c で、LoRA のノードを挟んでも何も変わらない | h3.c は ComfyUI のモデルを受け取らず、モデルのフォルダを直接読む | BF16モデルの複製に LoRA をあらかじめ合成して渡す | 確定 |
| 4step用の蒸留 LoRA で、step数を増やしても良くならない | 4step用に学習されているためと考えている。6→8stepにした1本で、動きは良くならなかった | そのLoRAの想定step数で使う。品質が要るなら蒸留なしの20stepにする | 有力(1例) |
| 蒸留 LoRA を4stepで回すと、二重写しやブロック状の崩れが出る(FastH3 Dense) | 変換の過程で時刻に関する部分が落ちるため、と変換ツールの作者が説明している | 6stepで使う(作者の推奨どおり) | 症状は確定(1題材)・原因は作者の説明 |
LoRA ごとの詳しい記録は LoRA一覧表 にあります。
3. 人物・手・顔が崩れる
スクロールできます
| 症状 | 原因 | 対処 | 確かさ |
|---|---|---|---|
| 5秒の動画で、手の指が癒着する・本数がおかしい | step数が足りない。4step(Turbo LoRAあり)では崩れ、20step(LoRAなし)では正常だった | step数を増やす。0.4MPと1.0MPの両方で同じ結果 | 有力(step数とLoRAの有無が同時に違う) |
| 15秒の動画の途中で、手だけが崩れる | プロンプトの文が壊れていた。推敲の途中で主語がすり替わり、手に布の動きを指示していた | 手についての指示2文を削ったら、同じseedのまま崩れが消えた。長いプロンプトでは、体の部位への指示を1文ずつ読み直す | 確定 |
| 長い動画(15秒)で崩れる | 当方は当初、尺やデータの量が原因と考えた。調べた結果、主な原因はプロンプトだった(あいまいな記述、否定の表現、壊れた文)。h3.c では実装の不具合も2つ見つけて直した(下の2行)が、それが崩れの原因だったとは確かめていない | まずプロンプトを見直す。体の部位への指示と否定の表現を1文ずつ読み直す | 有力(手の崩れについては確定) |
| 3枚目の参照画像が効いていない | ワークフローの配線が、画像を2枚までしか生成ノードに届けていなかった。画面上は3枚登録されている | 参照をまとめて渡す接続に直す。実行ログの 3 picture(s) で届いた枚数を確かめる | 確定 |
| 同じ入力・同じseedなのに、毎回少し違う絵が出る(h3.c) | テキスト処理の並列計算で、足並みを揃える処理が1か所抜けていた | h3.c の公開リポジトリの Issue #52・PR #63 に当たる1行の修正を当てる。8条件を13回ずつ試し、修正前は6条件で揺れ、修正後はすべて一致した | 確定 |
| 人物が、参照動画に映っている人に置き換わる | 「この人物を保つ」という宣言がプロンプトにない。または参照動画を被写体として定義している | キャラクターシートの人物を fully_preserved で宣言する。参照動画は動きの出どころとしてだけ定義する | 確定 |
| 頭の飾りやお団子が、巨大な塊になる | キャラクターシートの3面(正面・背面・顔)の縮尺が揃っていないためと見ている。step数を6から8に上げた1本で起きた | 縮尺を揃えたシートを作り直す | 有力(1例) |
| 完成した動画が、顔のぼけた状態で始まる | 分かっていない。キャラクターシートの立ち姿の顔をぼかしてあり、それが外見として取り込まれた可能性がある | プロンプトを変えた1本では改善した(どの変更が効いたかは確かめていない)。当方は別の題材で、「顔のアップが唯一の顔の参照で、ぼかしはシートの注記」と書く方法を使っている | 未解決 |
| 静止画で、人物の顔立ちが安定しない・全身が入らない | 生成エンジンの違い。SDXL base とZ-Image Turbo で、同じプロンプトの結果が大きく違った | 静止画はエンジン選びを先に見直す | 有力(1プロンプト・各4枚) |
4. 背景・画面がおかしい
スクロールできます
| 症状 | 原因 | 対処 | 確かさ |
|---|---|---|---|
| 白背景の画像を渡しているのに、毎回違う場所が出る | プロンプトに背景のことを1語も書いていなかった。参照画像を渡すだけでは出ない | 背景を参照として定義し、保つと宣言し、本文でも背景を書く | 有力 |
| 先頭・末尾の画像から生成すると、背景に花柄などが現れる | 1〜2文の短いプロンプトだった | 公式の構造化された書式で書き直す。同じseedで、余計な要素が消えた | 確定 |
| 先頭・末尾の画像から15秒を生成すると、中盤だけ暗くなる | 分かっていない。両端の画像から遠い中盤で崩れる形。疎アテンションの keep_percent を10から50に上げても変わらず、時間だけ38%増えた | keep_percent は10のままにする。尺を短くする案と、否定の列挙をやめる案は未検証 | 未解決 |
| 人物の上半身に、雲のようなしみが出続ける | プロンプトに霧・煙・もやに関する記述があった(「霧や煙はない」という否定形を含む) | 霧・煙・もやの語を、否定形も含めてプロンプトから消す。これで解消した | 有力(複数箇所を同時に変更) |
| 画面に紙吹雪のような細かい粒が出る(h3.c) | 映像を復元するときのタイルが大きい | タイルを256にする。粒が約13%減った(復元の時間は約3割増える)。完全には消えていない | 有力 |
| 「〜しない」と書いたものが、かえって画面に出る | 否定の列挙に含まれる名詞に引っ張られる | 肯定形で書く(「カメラは固定」「画面には人物と背景だけ」) | 有力 |
| 0.6MP前後で、画面の中央が白くにじむ | 解像度が低い | 0.8MP以上にする | 有力 |
5. 動き・尺・音
スクロールできます
| 症状 | 原因 | 対処 | 確かさ |
|---|---|---|---|
| 15秒を指定したのに、20秒の動画ができる | 動画を保存するノード(VHS_VideoCombine)の loop_count が1になっていた | loop_count を0にする | 確定 |
| 参照動画どおりに動かない | 「参照動画のとおりに踊る」と書いただけだった。または、動画を見ずに振り付けを文章で創作した | 参照動画の実際の動きを、何秒に何をするかの形で書く | 確定 |
| 前半(1.5〜5.5秒あたり)の動きだけ遅れる | 参照動画の切り出し位置と、プロンプトに書いた時刻が0.79秒ずれていた | 動きが最大になる瞬間(回転など)の時刻を、動画とプロンプトの両方で測って合わせる | 確定 |
| 参照動画のfpsを上げても、動きが良くならない | 24fpsと表示される動画の中身が、実質10fpsだった(360コマ中、絵が変わるのは151コマ) | 表示を信用せず、隣り合うコマを比べて実際のコマ数を数える | 確定 |
| 動きがカクつく | 4コマ周期で動きの量が不均等になる。モデルが内部で時間方向を圧縮していることに由来する | RIFE で2倍に補間する。急な変化は約6割減った。周期そのものは残る | 確定(周期は未解消) |
| コマ補間のあと、スロー再生になる | 出力のfpsが24のまま | 2倍に補間したら48fpsで書き出す | 確定 |
| 10秒の動画で、動作が前倒しに詰まる | 15秒用の時刻で書いたプロンプトを、そのまま10秒に使った | プロンプトの時刻を尺に合わせて組み直す | 有力 |
| 参照動画の音が引き継がれない | 参照動画に音が入っているだけでは、音声の参照として扱われない | プロンプトで音声を fully_copy と宣言する | 確定 |
| 速い動きで滲む・難しい動作で崩れる | step数が少ない。4stepでは、しゃがむ動作と顔の寄りで崩れ、8stepで解消した | step数を増やす | 確定(1題材) |
6. 遅い
スクロールできます
| 症状 | 原因 | 対処 | 確かさ |
|---|---|---|---|
| クラウドやデスクトップで、生成前の処理に16〜40分かかる | テキストエンコーダをCPUで動かす設定(SelectCLIPDevice が cpu)になっていた | default にする。A40で全体が27分08秒→10分47秒。デスクトップでは、量子化版(nvfp4)に替えてこの設定をやめ、約41分→約5秒 | 確定 |
| Mac で、解像度を上げると急に遅くなる | メモリが足りず、SSDへの退避(スワップ)が常時出入りしている | 載せる量を減らす(軽いテキストエンコーダ、枝刈り版のモデル)。または h3.c のSSDストリーミングを使う | 確定 |
| 参照動画つきの生成が重い・メモリ不足になる | 参照動画はコマの列がそのまま計算に乗る。原寸(720×1280)の参照動画は、メモリ不足の一因だった | 縮小版(288×512)を使う。参照動画を短く切る効果は、測定が1組しかなく結論を保留している | 有力 |
| 尺を伸ばすと、時間が比例以上に伸びる | 仕様。Mac は10秒→15秒(コマ数1.49倍)で1.91倍、デスクトップ(参照動画あり)は5秒→15秒で約5.6倍 | 試行は短い尺で行い、本番だけ長くする | 確定 |
| 同じ設定で焼き直したら、時間が丸ごと無駄になった | デスクトップの構成は完全に決定的で、同じseed・同じプロンプトなら全コマが画素単位で同じになる | 焼き直すときは、seedか何か1つを必ず変える | 確定 |
| 「低解像度で20step」のほうが「高解像度で4step」より速い、と思っていた | 0.2MPのときだけ成り立つ。0.4MP・20stepは、1.0MP・4stepより遅い | 0.4MP以上では、20stepで買っているのは品質だけと考える | 確定 |
所要時間の数字は 実測早見表 にまとめています。
7. 記録・保存・ダウンロード
スクロールできます
| 症状 | 原因 | 対処 | 確かさ |
|---|---|---|---|
| 「raw」という名前の出力が、妙に画質が悪い | 保存の圧縮設定がCRF100だった。名前がrawでも無圧縮ではない | 比較には仕上げ側(CRF19)を使う | 確定 |
| どの設定で焼いたか、あとから分からない | — | ComfyUI が動画に埋め込むワークフローを読み出す(ffprobe -show_entries format_tags=workflow)。保存ノードの save_metadata を有効にしておく | 確定 |
hf download で、意図しないファイルが落ちてくる | --include に複数のパターンを並べると、2つ目以降がファイル名として解釈される | パターンごとにコマンドを分ける | 確定 |
| Windows で、ダウンロードが止まっているように見える | Windows は、書き込み中のファイルのサイズ表示を更新しない | ファイルサイズではなく、ネットワークの受信量で進捗を見る | 確定 |
| 画面上は線が繋がっているのに、実際は効いていない | 見た目の配線と、実行時に届く値は別。プロンプトの線が切れたまま、空の文章で焼いていた例もある | ワークフローの定義ファイルをAIに読ませ、どの経路が生きているかを監査する | 確定 |
配線の監査については ワークフロー設計の回 に書きました。
関連記事
- 振付トレースの症状と対処の経緯: 第8回・第9回
- Mac の15秒が安定するまで: 第6回
- 人物 LoRA の再評価: 第7回
- 実走したプロンプトの原文と全設定値: 振付トレース完全レシピ(有償)
- Mac で量子化なしの動画を焼く手順: 完全手順書(有償)
関連ページ
更新履歴
- 2026年10月7日 公開
本ページの内容は、記載した時点の当方環境での実測と観察に基づきます。モデル・ツールの更新で、原因や対処が変わることがあります。本ページ中の人物に関する言及は、すべてAI生成キャラクターについてのものです。