ComfyUIのPartial Executionとは｜必要な分岐だけ実行して検証を速くする

Partial Executionは、選択した出力ノード（Save ImageやPreview Imageなど）に必要な上流ノードだけを実行し、Workflowの残りの分岐を動かさない機能です。実行するノードの数を減らして検証の待ち時間を短くするもので、GPUの計算そのものが速くなるわけではありません。

情報確認日：2026年8月22日（日本時間）

結論：「出力ノードを1つ選んで、その枝だけ回す」が Partial Execution

この記事のUI名称は、docs.comfy.orgのPartial Execution解説（2026年8月時点）に基づきます。同ページではfrontendのversionが1.23.4より後、場合によっては1.24.x系が必要と案内されているため、手元の画面にボタンが出ないときは先にfrontendのversionを確認してください。

Partial Executionでできること

ComfyUIは、Workflow全体を順番に実行しているのではなく、「出力ノード」から上流にさかのぼって必要なノードを集め、それだけを実行しています。ソース（execution.py）では、OUTPUT_NODE属性を持つノードが実行の起点で、通常の実行ではWorkflow内の出力ノードすべてが起点になります。Partial Executionは、この起点を「選択した出力ノードだけ」に絞る機能です。

Load Checkpoint ─┬─→ CLIP Text Encode ─┐
                 │                      ├─→ KSampler (A: LoRAなし) ─→ VAE Decode ─→ Save Image (A)
                 │                      │
                 └─→ Load LoRA ─→ ...   └─→ KSampler (B: LoRAあり) ─→ VAE Decode ─→ Save Image (B)

通常の実行        : Save Image (A) と (B) の両方が起点 → 両方の枝を実行
Partial Execution : Save Image (B) だけを選んで実行 → Bの枝と共通部分だけを実行、Aの枝は実行しない

公式解説の表現では「開始ノードから出力ノードまでのWorkflowの枝だけを実行する」機能です。server側のAPIでは、/promptに送るJSONのpartial_execution_targetsに出力ノードのIDを入れると、validate_promptがその一覧にある出力ノードだけを起点にします。frontendのボタンは、この指定をUIから行う入口です。

実行対象をどう決めるか

Partial Executionの対象にできるのは出力ノードだけです。公式解説でも「選択中のノードはPreviewやSaveのような出力ノードである必要がある」と明記されています。KSamplerやVAE Decodeを選んでも、その途中までを実行する操作はできません。

そのため、一部だけ検証したいWorkflowは「検証したい地点に出力ノードを置く」設計にしておきます。最も使いやすいのがPreview Imageで、fileを保存せずに結果を見られます。

Previewノードを多く置いても、選ばなければ実行されないため負担にはなりません。「Workflow全体を回して最後の1枚を見る」から「見たい地点のPreviewだけを回す」に、実行の単位を変えるのがこの機能の使い方です。

分岐Workflowで一部だけ実行する

手順は、出力ノードを選ぶ → Selection Toolboxに現れるアイコンを押す、の2つです。公式解説では、出力ノードを選択するとtoolboxに青い三角形のアイコンが表示され、それを押すと部分実行が始まる、と説明されています。

所要時間の文字列はmain.pyで「Prompt executed in {:.2f} seconds」（600秒を超えるときはHH:MM:SS形式）と定義されています。実行されたノードは、実行中に各ノードの枠が順に光ることと、コンソールの出力から確認できます。

全実行と部分実行を比べる記録表

この記事で再現してほしい比較です。結果は環境とWorkflowで変わるため、数値は書きません。

見るべき点は「実行されたノード数」です。部分実行でBを選んだときにA側のKSamplerが動いていなければ、機能は期待どおりに働いています。所要時間は、実行されなかったKSamplerのサンプリング時間の分だけ短くなるはずで、それ以上には縮みません。最後の行（無変更で2回目の全実行）は、次節のキャッシュの働きを見るためのものです。

キャッシュと再計算の関係

Partial Executionと混同しやすいのが、ComfyUIが元々持っている出力キャッシュです。READMEには「前回の実行から変わった部分だけが実行され、同じグラフを2回送ると1回目だけが実行される」とあります。これは各ノードの出力を保持し、入力が変わっていないノードの再計算を飛ばす仕組みで、Partial Executionとは独立に働きます。

キャッシュの方式は起動オプションで選べます。comfy/cli_args.pyには、RAMの空きに応じて保持量を決める--cache-ram（既定）、従来の積極的なキャッシュ--cache-classic、件数上限付きの--cache-lru N、毎回すべてのノードを実行する--cache-noneが定義されています。--cache-noneで起動すると、上の記録表の「無変更で2回目」も全ノードが再実行されるはずで、キャッシュの効果を切り分けて観察できます。

パラメータを変えたときに再計算される範囲

KSamplerのCFGだけを変えて再実行すると、再計算されるのはKSamplerとその下流（VAE Decode・Save Image）だけで、Load CheckpointやCLIP Text Encodeはキャッシュから再利用されます。実行中にどのノードの枠が光るかを見れば、再計算の範囲が分かります。promptを変えるとCLIP Text Encodeから下流が、checkpointを変えるとほぼ全体が再計算されます。

この「変えた地点から下流だけ」という性質と、Partial Executionの「選んだ枝だけ」を組み合わせると、検証1回あたりの実行範囲を最小にできます。

比較検証に使う

一変数比較では、同じ上流を共有し、比較したい設定だけが違う枝を並べたWorkflowが便利です。たとえばLoad LoRAのstrengthを4段階比べるなら、Load Checkpointの後に4本のLoad LoRA → KSampler → VAE Decode → Preview Imageを並べ、seedとpromptは共通にします。

• 1本ずつPreview Imageを選んでPartial Executionすれば、気になる枝だけを先に見られる
• 4本すべてを見たいときは通常のQueueで全実行する。共通部分はキャッシュで1回しか計算されない
• 1本の設定を直して再実行すると、その枝のKSampler以降だけが再計算される

比較の前提になるseedの固定と「同じseedでも変わる条件」はComfyUIでSeedを固定する方法、Steps・CFG・Denoiseを1つずつ動かす考え方はComfyUIのKSamplerを理解するで扱っています。Partial Executionは、それらの比較を「待ち時間を短くして回す」ための道具であり、比較の設計そのものは変わりません。

誤解しやすい注意点

Partial Executionは「実行しないノードを増やす」機能で、「実行するノードを速くする」機能ではありません。次の点は、この機能では解決しません。

生成速度そのものの計測や、GPU・設定による速度差の比較は別記事で扱います。Partial Executionで短くなるのは「実行されなかったノードの分」だけ、と覚えておけば、効果を過大にも過小にも見積もらずに済みます。

よくある質問

まとめ

Partial Executionは、選択した出力ノードに必要な上流だけを実行する機能です。Workflowの検証したい地点にPreview Imageを置き、そのノードを選んでSelection Toolboxのアイコンを押せば、関係ない枝を動かさずに結果を見られます。

出力キャッシュ（変わっていないノードの再計算を省く）と組み合わせると、1回の検証で実行される範囲を最小にできます。ただし1ノードあたりの速度は変わらないため、短くなるのは実行されなかったノードの分だけです。2分岐Workflowで全実行と部分実行のノード数・所要時間を一度記録しておくと、自分の環境での効き方が具体的に分かります。