Runware Accelerator Options

This is the node that turns the "every model runs on Runware's GPUs" pitch into a speed dial. It's a builder - it doesn't generate anything itself. It outputs a RUNWARE_ACCELERATOROPTIONS value that you wire into a model node's acceleratorOptions socket (33 model nodes in the pack accept it), and it tells the cloud inference engine to skip redundant work during the denoising schedule. On a pay-per-request service, faster inference is cheaper inference, and the trade is always the same: speed now, quality tax later. This node is where you decide how much tax you'll pay.

The techniques are the familiar caching family from the local-comfy world, just exposed as request parameters instead of node internals: TeaCache, DB Cache (CacheDiT), First Block Cache, and DeepCache. All four share the same idea - transformer steps compute very similar things at consecutive timesteps, so cache an intermediate result and reuse it. Different models and architectures take to different ones, which is why the pack exposes all four rather than picking for you.

The settings you'll actually touch

• teaCache + teaCacheDistance - the mainstream one. Distance default 0.5 (0–1); lower values prioritize quality, higher values prioritize speed. Turn it on, leave the distance alone, that's the 80% case.
• deepCache + deepCacheInterval - the classic skip-every-other-step accelerator. Interval 2 means skip every other step, 3 means skip two of three. It's the most aggressive and the easiest to overshoot.
• cacheStartStepPercentage / cacheEndStepPercentage (+ their absolute-step equivalents) - the smartest knob in the box. Caching matters most mid-schedule; if you start caching late and stop before the end, the model gets the exact steps that define structure and detail for free. This is the "release the shortcut once composition has formed" lesson from ControlNet, applied to caching.
• cacheMaxConsecutiveSteps (1–5, default 3) - a safety valve that forces a fresh computation before the cache gets too stale.

dbCache, fbCache and their thresholds are there if a particular model responds well to them; don't start there.

How the gating works

Every optional field that has a _value twin uses this pack's off-by-default gate pattern: the boolean toggle (cacheStartStep) is off, and the paired value widget (cacheStartStep_value) only gets sent when you flip it on. Off means "use the model's default" - so a default request never trips a validation rule. It's a bit of UI you'll only truly understand after the third time you hit it, but once you do, it's consistent across every builder in this pack.

Output and wiring

Output is RUNWARE_ACCELERATOROPTIONS. Wire it into any model node's acceleratorOptions socket.

Install

The whole pack, once:

cd ComfyUI/custom_nodes
git clone https://github.com/Runware/ComfyUI-Runware
pip install -r ComfyUI-Runware/requirements.txt

Restart and add your Runware API key (Settings → Runware API key or RUNWARE_API_KEY).

The honest take

Start with teaCache alone, watch what the quality does on your images, and only stack DeepCache on top if the speed is worth it. The cached steps are exactly the steps that define fine detail, so this is the rare builder where the default of "everything off" is genuinely the correct baseline - the "use the model's default" philosophy isn't just laziness. You don't pay for these knobs directly, but you pay for the results, and worse results at higher speed is the only outcome you're ever optimizing against here.