Easycacheという高速化ノードがComfyUIネイティブに実装された話

ComfyUIの更新ログを見ていると、上のEasycacheの実装がすすめられていました。2025/8/23に実装されています。

このEasycacheは、動画生成などの高速化に関連する技術の様です。

上のように「Teacache」が比較として挙げられていますが、それよりも高速化が出来ています。

１月ごろから、このあたりの高速化関連の技術がComfyUIに実装され、FbcacheやMagcacheなどもこれらに該当します。

ここにきて、何が違うの？と思われる方が出てきますよね。

これらの技術について、論文やスクリプトを解析してGeminiに聞いてみました。

この3つに共通しているのはキャッシュを再利用する事で推論速度を早める点です。

ただ、そのキャッシュの計算をする所がそれぞれ違うということになります。

以下にGeminiにまとめてもらったインフォグラフィックを提示しておきます。

高速化ノードがネイティブに実装されるというのは有用だからだと思いますし、モデルの対応などのアップデートも期待されるので、ありがたいところです。FbcacheもMagcacheも開発者が追加してくれないと使えない問題がったので・・・・・

例えばQwenImage editモデルは、Magcacheでは対応できていませんが、Easycacheは対応していたりします。
Wab2,2モデルも同様です。

Easycacheの設定値

以下の部分に言及があります。

カスタムノードは以下になります。

Flux Kontext w/ 40 stepsの設定

threshold: 0.2, start_percent: 0.15, end_percent: 0.95
この設定で、Skipped 21/40 steps (2.11x speedup)となり、半分ぐらい生成がスキップされています。

生成結果に差が無いらしい

Qwen Image Edit w/ 20 stepsの場合

threshold: 0.1, start_percent: 0.2, end_percent: 0.95
kipped 9/20 steps (1.82x speedup)

WAN2.2 14B First Frame w/ 20 steps (10 per sampler)

First Sampler
threshold: 0.10, start_percent: 0.15, end_percent: 1.0
Second Sampler
threshold: 0.10, start_percent: 0.0, end_percent: 0.95

注

私がQwen Image editモデルで使用してみた感じだと、上の設定だと画像の乱れが発生して上手くいきませんでした。
resmultistep + betaと8step loraを使用

デフォルトの設定だと2ステップ分がスキップされていました。
生成時間は短くなるのですが、スキップした分だけ質の低下が起きているようです。
以下の様に終わりの時間を早めて、スキップするステップ数を１ステップにしたところ改善しました。

１ステップだけだと1.14倍の速度上昇になります。

SDXLに使用したところ、スキップが発生しませんでした。設定を変える必要がありそうです。

今回の高速化と全く違う話ですが、以下のClownsharkサンプラーをインストールしていると、Kサンプラーからも、追加されたサンプラーが選べるようになっていました。res_2mは生成時間が倍近くになりますが、画像の質は高いものが出るようになっています。

ClownsharkBatwing/RES4LYF