DOGMA SAM Mask CPU Checkpoint v12
Park the mask on CPU, unload before the next pass
- mask
- mask
- token
Six categories means six segmentation calls, and segmentation models are not small. Run them back to back and your VRAM fills up with the residue of every pass you've already finished - cached models, cached CUDA blocks, and masks still sitting on the GPU because nothing told them to leave. On a mid-range card the last two passes are where you find out.
SAM Mask Checkpoint v12 is the pacer node for that loop. Its docstring says it plainly: it moves a completed mask to CPU, unloads models, empties caches, and emits a token "used to serialize the next SAM call."
What it actually does
Given a mask and the unload_models boolean (default true), it:
- detaches the mask, converts to float, moves it to CPU, forces contiguous layout;
- calls
comfy.model_management.unload_all_models(); - runs
gc.collect(), thensoft_empty_cache(); - if CUDA is available, calls
torch.cuda.empty_cache()andtorch.cuda.ipc_collect().
Every GPU-side call is wrapped in a try/except, so on a CPU-only or unusual backend it degrades quietly rather than exploding.
Outputs: the same mask (now on CPU) and a token string. The token is the interesting part. It is a fixed sentence - "SAM mask cached on CPU; models/cache + CUDA cache unloaded before next SAM category." - and it exists to be wired into something. In ComfyUI, a connection is a dependency edge, and a string nobody reads is a legal way to say "do not start the next stage until this ran". It's a hack, and it's an intentional one; the execution scheduler replays nodes according to the graph, so the wire is the ordering primitive.
Inputs and outputs
mask (MASK) and unload_models (BOOLEAN, default true). Out: mask, token. In the reference chain, mask goes to the mask-normalizing node (DOGMASectorMasksV26 / DOGMASectorMasks4V354 or DOGMAResizeMaskToImageV15) and token goes into the next SAM stage purely as an ordering edge.
The cost you're buying
unload_all_models() is exactly what it says: all of them. If your graph has a Klein or Qwen checkpoint resident and you fire this node mid-graph, you've just evicted your diffusion model, and the next sampling call pays a full reload from disk. On a fast NVMe that's seconds; on a spinning disk or a network share you'll think ComfyUI hung.
So the placement rule is: use it between segmenter passes, never between a segmenter and a sampler that you wanted to keep hot. If your machine has the VRAM to hold everything, set unload_models to false and you keep the CPU offload and cache flushing without the reload tax - that's often the sweet spot for a 24GB card running SAM and a small edit model.
Install
Manager → search DOGMA Nodes → install, then restart ComfyUI. Manual:
cd ComfyUI/custom_nodes
git clone https://github.com/axior/ComfyUI-DOGMA-Nodes
Nothing to install beyond the pack - it uses only torch and ComfyUI's own model_management module, and the pack's requirements.txt declares no external dependencies. The segmenter itself is separate: SAM 3 through ComfyUI's native support or a community node pack, which is where the real install friction lives (some of those want Triton, and that's the usual Windows stumbling block). This node ships in DOGMA/Semantic Detailer.
DOGMA Nodes is by axior, the studio half of a Milan production team running commercial work through heavy ComfyUI mask chains - the kind of shop where "hundreds of inpaints per job" is normal, and where VRAM hygiene stops being a preference and becomes throughput.
Field notes
It doesn't shrink VRAM by itself. The mask leaving the GPU matters at 4K - a float mask at 4000x3000 is ~48MB, and a batch multiplies that - but the model unloading is where the big win is. If you're still OOMing, that's the flag to check first, or a segmenter checkpoint that's simply too large for your card (see the community INT8/INT4 SAM 3.1 quants for that problem).
The token is not data. Never wire it into a prompt or a filename. It's a lever, not information.
An empty unload_models reset. Since it defaults to true, a loaded workflow that's suddenly much slower than it used to be often means someone's checkpoint node went back to default after a UI reset. Check that first before you start hunting for a leak.
Inputs (2)
| Name | Type | Default | Description |
|---|---|---|---|
| mask | MASK | — | |
| unload_models | BOOLEAN | true | — |
Outputs (2)
| Name | Type | Description |
|---|---|---|
| mask | MASK | — |
| token | STRING | — |