Conduit Batch Optimizer
Let VRAM pick your batch size
- model
- batch_size
- analysis
Conduit Batch Optimizer answers a question you've probably answered by guessing: how many images should I batch at once without running out of VRAM? It reads your GPU's free memory, estimates how much one image costs at your target resolution, and hands back a batch size plus an explanation of its reasoning. It's a small, self-contained utility node - and one of the genuinely functional ones in this pack.
How it works
At run time it grabs torch.cuda's total and allocated memory, computes free VRAM, and estimates per-image cost with a deliberately rough formula: about 2 GB base plus 0.5 GB per 512×512 equivalent of pixels. Then it applies your chosen mode:
- auto (default) - batch sized to use ~70% of free VRAM. The safe all-rounder.
- max_throughput - batch sized to fill all of free VRAM. Fastest if you never hit a memory spike, and the most likely to OOM.
- memory_saver - batch sized to ~50% of free VRAM, leaving headroom for other things sharing the card.
- deterministic - forces batch size 1, because batch 1 is what makes outputs reproducible and the pack's caches sane. This is the mode to use when you're debugging or caching.
The optional model input is accepted but not actually consulted by the calculation - it's there for future refinement. Outputs are batch_size (an INT you wire into your EmptyLatentImage's batch count) and analysis (a STRING explaining the math, e.g. Auto: batch=3 (using 70% of 11.2GB free)).
The honest version
This is a heuristic, not a benchmark. The "2 GB base + 0.5 GB per 512²" estimate is a coarse guess that doesn't know your model size, your sampler, or your attention implementation - a 24 GB model at 1024×1024 costs a lot more than the formula suggests, so the returned batch size is a starting point, not a guarantee. The right way to use it: let it give you a number, wire it in, and if you hit an OOM, step down or switch to memory_saver. It's the fastest way to get from "guessing" to "a number that's probably close," and the analysis string at least tells you what it was thinking.
Where it fits
Batch size is a real VRAM lever - the troubleshooting knowledge base's core warning is that RAM can't substitute for VRAM because PCIe transfer is ~11x slower than GPU memory bandwidth, so over-batching that spills to system RAM costs you more than it saves. A node that keeps you under that cliff, and one that enforces batch 1 when you're doing reproducible runs, is more useful than it sounds. Pair it with ConduitEmbeddingCache when you're batching many prompts, and with the Latent Cache when you're re-running identical configs.
Install
cd ComfyUI/custom_nodes
git clone https://github.com/joe002/comfyui-conduit-optimizer
Or ComfyUI Manager → search "comfyui-conduit-optimizer" → restart. No model downloads; PyTorch 2.0+ only, and you'll see [CONDUIT] v1.1.0 loaded: 13 optimization nodes in the log.
Common issues
About the only trap is treating the number as gospel. The formula doesn't see your model, so a "batch=4" on a lean SDXL setup could be "batch=1" on a heavy Flux quant. And remember deterministic mode isn't an optimization - it's a reproducibility tool that deliberately reduces throughput, so don't complain when it returns 1.
Inputs (3)
| Name | Type | Default | Description |
|---|---|---|---|
| mode | COMBO | 4 options: auto, deterministic, max_throughput, memory_saver | |
| target_resolution | COMBO | 5 options: 512, 768, 1024, 1536, 2048 | |
| modelopt | MODEL | — |
Outputs (2)
| Name | Type | Description |
|---|---|---|
| batch_size | INT | — |
| analysis | STRING | — |