
また新しいMiniMax H3の高速化ノードが出たので試して見ました。
TE-Speed-MiniMaxH3-OSSは、キャッシュを挟んで生成を速くするComfyUIのカスタムノードです。
ノードを置くだけでは動かず、ComfyUI本体側にパッチを当てる必要があるので、その手順と戻し方をまとめて紹介します。
TE-Speed-MiniMaxH3-OSSとは?
TE-Speed-MiniMaxH3-OSSは、MiniMax H3のOSS版を高速化するためのComfyUIカスタムノードです。
50層あるDiTブロックの後半部分の計算を、隣り合うステップ同士で使い回して省くというもの。
差が小さいところだけキャッシュを使うので、全ステップを完全に計算しなくても結果が大きく崩れにくくなっています。
repoでは、既定の設定でおよそ45%の高速化という数字が示されていて、対応しているのはMiniMax H3のOSS版のみ、ライセンスはLGPL-3.0です。
主な特徴
- MiniMax H3のOSS版向けの高速化ノード
- 隣り合うステップのsigma差が小さいときだけキャッシュを使う
- キャッシュを使う区間や強さをパラメータで調整できる
- ComfyUI本体のモデル定義にパッチを当てて動く(コマンド一つで元に戻せる)
- 既定設定でおよそ45%の高速化(repoの仕様値)
- ライセンスはLGPL-3.0

必要なもの
まずComfyUIが必要です。
インストールがまだの方はこちらを参考にしてみてください。

MiniMax H3の使い方はこちらで紹介してます。

ComfyUIでTE-Speed-MiniMaxH3-OSSを使う方法
インストール
ComfyUI-Managerには登録されていないので、custom_nodesにフォルダにクローンしてください。
cd ComfyUI\custom_nodes
git clone https://github.com/HELPMEEADICE/TE-Speed-MiniMaxH3-OSS次にこのノードはcustom_nodesに入れるだけでは動かず、付属の patch_model.py を実行して、ComfyUI本体側の model.py を書き換える必要があります。
※書き変わるファイル
ComfyUI\comfy\ldm\minimax\model.pyクローンしたら、そのフォルダの中で patch_model.py を実行します。
python patch_model.py基本ComfyUIを自動で探してくれるみたいですが、stabilitymatrix環境だとComfyUIを見つられませんでした。
この場合は、引数で–comfy-ui にルートフォルダを渡せば実行できます。
python patch_model.py --comfy-ui "ここにComfyUIのルートフォルダパス"
元に戻す方法
パッチを外したいときは、–revert を付けて実行すれば元に戻ります。
python patch_model.py --revert
python patch_model.py --revert --comfy-ui "ここにComfyUIのルートフォルダパス"元のファイルは model.py.te_speed.bak としてバックアップされるので、そこから戻すコマンドです。
ComfyUI本体をアップデートすると model.py が上書きされてパッチが外れるので、アップデート後に効かなくなったら、もう一度 patch_model.py が必要です。
ノードの接続
他の高速化と同じで、Load Diffusion Model の出力を TE-Speed-MiniMaxH3 (OSS) ノードに通すだけです。
そこから BasicScheduler と BasicGuider の両方に繋ぎます。
model -> TESpeedMiniMaxH3(OSS) -> BasicScheduler
\-> BasicGuider
よく分からないという方はrepoに Example_Workflow.json があるので、そちらを使ってみてください。
パラメータ
基本は既定値のままで問題ないそうです。
以下はrepoのパラメータをAIに解説してもらったものになります。
| パラメータ | 既定 | 説明 |
|---|---|---|
| processing_control_value | 0.12 | 隣り合うステップのsigma差がこの値より小さいとキャッシュを許可(0で全ステップ完全計算) |
| processing_percent_1 | 0.1 | キャッシュ窓の開始。最初の10%は必ず完全計算 |
| processing_percent_2 | 0.9 | キャッシュ窓の終了。最後の10%は必ず完全計算 |
| mcs | 2 | 連続でキャッシュできる最大ステップ数(0でキャッシュ無効) |
| device | auto | キャッシュした残差の置き場所。cpuにするとVRAMを節約できるが転送のぶん遅くなる |
| cache_depth | 0.75 | キャッシュ時に後方ブロックをどれだけ使うか。下げると画質寄り、上げると速度寄り |
実行と結果
生成結果はそれぞれ以下の通りでした。
| 位置 | 設定 | 生成時間 |
|---|---|---|
| 左 | デフォルトのworkflow | 6分3秒(363.42 seconds) |
| 右 | TE-Speed-MiniMaxH3-OSS | 3分33秒(213.19 seconds) |
まとめ
Spectrumが4分44秒、Patch Sol-Attnが4分22秒だったので、ノード単体で実行する場合は、TE-Speed-MiniMaxH3-OSSが一番処理が早かったです。
ただTE-Speed-MiniMaxH3-OSSはパッチを当てる必要があるので、そこだけ少し手間かもしれません。
ノードを複数組み合わせるならPatch Sol-Attn+EasyCache+SageAttentionが一番速かったので、速度を求める方はそっちの方が良さそうです。
以上TE-Speed-MiniMaxH3-OSSの使い方を紹介しました。
参考になれば幸いです。
別の高速化についてはこちらで解説しています。



