Sub-batching Model

Tile generation is a batching problem: you're not inpainting one image, you're inpainting colors**4 tiles (times however many candidates), and a sampler will happily try to shove the whole batch through the UNet at once. That's how you find your VRAM ceiling. Sub-batching Model is the pack's memory valve - it patches the model so the UNet processes the batch in chunks of subbatch_size instead of all at once. Same results, a fraction of the peak memory.

What it does

It clones your model and patches its apply_model path with a chunked wrapper: incoming batch tensors are split into pieces of subbatch_size, each piece is denoised, and the outputs are re-joined. The implementation is careful in two ways. First, it uses add_object_patch rather than a full function-replacement patch, which the author notes is deliberate so it composes with other patches like RollingKSampler's. Second, if the batch doesn't divide evenly by your subbatch_size, it quietly shrinks the chunk size until it does - so you can set 8 and never worry about the last straggler. There's a slight memory cost to doing math in chunks, but that's the whole point: you trade a little speed for fitting the job on the card you actually have.

The default of 8 matches the pack's CLI default (--diffusion_batch_size 8), which was tuned against the SD2 inpainting model this workflow expects. Drop it lower (4, 2) if you're still OOMing; raise it if you're on a big card and want the speed back.

Inputs and outputs

• model (MODEL) - your checkpoint
• subbatch_size (INT, default 8) - tiles processed per UNet chunk

Output is a single MODEL - wire it into your KSampler or RollingKSampler in place of the original.

Installing and notes

Standard pack install: git clone https://github.com/samsartor/content_aware_tiles into ComfyUI/custom_nodes (or ComfyUI Manager → "content_aware_tiles") and restart. No model downloads.

The mental model is "VRAM insurance," not a quality knob. You should get near-identical outputs at any chunk size, so if results change when you toggle it, something else is wrong. It's also genuinely useful beyond this pack - any workflow that batches many latents through one UNet can use it, and pairing it with SubBatchVAE covers both ends of the pipeline. As with everything here: research-pack code, no community threads, readable ~15-line node if you want the exact patch mechanics. The bundled workflow wires this, SubBatchVAE, and RollingKSampler together - copy that pattern and you're set.