CMK Pipe Create Refiner

A two-stage SDXL pipeline is, structurally, one sampler handing a latent to another sampler. In a hand-wired graph that's five or six wires and a start_percent you tune by feel. In CMK it's a single CMK_REFINER_PIPE.

CMK Pipe Create Refiner assembles that second stage: the refiner model, the VAE, both conditionings, the incoming latent, and the sampling parameters - then wraps it in one socket the Refiner module can consume.

The inputs

Required: model, vae, conditioning_pos, conditioning_neg, latent_image, seed, steps_1st_pass (default 20), steps (default 20), cfg (default 7.0), sampler, scheduler, and start_percent (default 80.0, range 0–100).

Optional, all forceInput strings and a stack: prompt_pos, prompt_neg, active_loras, lora_stack.

Two of these deserve a paragraph.

start_percent is the handoff point between first pass and refiner, expressed as a percentage of the total schedule. At 80.0, roughly the last fifth of the sampling schedule runs on the refiner model. Push it lower and the refiner does more of the work and you get more of the refiner's character; push it toward 95 and you're barely invoking it. The classic advice for base+refiner SDXL is to give the refiner the low-denoise tail and keep the composition on the base - which is what the default is doing.

steps_1st_pass next to steps is the tell that this pipe is built to be read by modern sampler nodes rather than a legacy KSampler. The pipe carries both the first pass's step count and the refiner's own, so downstream can report or log the pair rather than mystifying you with one number that only describes half a run.

The outputs and the shape of the pipe

One output: refiner_pipe (CMK_REFINER_PIPE). Inside, every key is prefixed refiner_ - refiner_model, refiner_vae, refiner_conditioning_pos, refiner_conditioning_neg, refiner_latent_image, refiner_seed, refiner_steps_1st_pass, refiner_steps, refiner_cfg, refiner_sampler, refiner_scheduler, refiner_start_percent, plus the prompt and LoRA fields.

The prefixing isn't fussiness. These pipe dicts get merged and passed around, and a model key colliding with a first-pass model key would be a silent catastrophe rather than a loud error. You can see the same discipline in the FaceProcess pipe, whose keys all start with face_.

There's also a fallback layer: create_refiner reads kwargs for refiner_* aliases if a positional value is missing. That's for subgraph plumbing, where values can arrive under their published names. It means you can occasionally get a pipeline working with a wire you didn't expect to matter - and equally, that a half-wired refiner can silently pick up a value from somewhere else. If your refiner behaves oddly, check for stray upstream connections before blaming the model.

Where refiner pipes come from besides here

More often than you'd think, the refiner pipe is built by CMK Pipe Peek KSampler Refiner Source, which pulls latent_image, seed, steps_1st_pass, the prompts, active_loras and lora_stack straight out of a CMK_SAMPLED_PIPE - the proprietary latent handoff the pack uses between sampler, InstantID and refiner instead of a plain IMAGE. That node exists so the refiner stage inherits the first pass's identity without you retyping a seed.

If you're following a CMK reference workflow and wondering where the prompt came from, that's usually your answer.

Install

ComfyUI Manager → search CMK Flow → install the CMKFlow entry → restart ComfyUI. Manual, with ComfyUI fully shut down:

git clone https://github.com/CMKFlow/cmk_nodes.git custom_nodes/cmk_nodes
python3 custom_nodes/cmk_nodes/scripts/install_cmk_requirements.py

Wait for CMK dependency check: OK. This node needs an SDXL refiner checkpoint in your checkpoints folder and nothing else; the pack's heavier requirements are for detection, faces and video.

Traps

start_percent is 0–100, not 0–1. It's a percentage. Passing 0.8 here gives you essentially no refiner at all, and the output will look like the first pass with extra steps - because it is.

steps caps at 200 on this node. Refiners don't want enormous step counts anyway, but if you're moving values between CMK nodes, expect clamping.

The caching behaviour applies. CMK keeps branch caches under ComfyUI/temp/cmk/ and marks them with revision identifiers, and boundary caches refuse a cache hit unless their dependency manifest matches the current branch revisions exactly. Change one branch and the merge updates while unchanged siblings come from cache. It's the pack's strongest feature and its most confusing one - a fresh restart always shows MISS → STORED on the first run, and that's expected.