DyPE_KSampler

This is the node that does the thing the pack exists for. DyPE_KSampler takes the assembled pipeline from DyPE_Condition, runs the actual denoising loop at whatever absurd resolution you ask for, and hands you a latent. Everything before it is setup; everything after it is just decoding.

The "KSampler" name is doing a lot of work it doesn't own. This is not the ComfyUI native KSampler and it doesn't share its knobs - there's no sampler/scheduler dropdown, no denoise. It's a thin front-end over a diffusers pipeline, which is the whole point: the pack bypasses ComfyUI's sampling core so it can run its own DyPE-patched transformer with a YARN-style RoPE schedule that's scaled by the current denoising timestep. Early steps (noisy, high-frequency content being roughed in) get aggressive position extrapolation; later steps relax. That timestep-awareness is the "dynamic" in DyPE, and it's how these models push past their training resolution without the usual collapse into repeating tiles - the failure you've seen a dozen times when someone queues a 2048×2048 on a 1024-native model in stock ComfyUI.

The trade-off, from the community threads that actually stress-tested it: at true 4K the coherence starts to slip - extra fingers, warped anatomy - and the honest sweet spot for most people landed around 2048–2560 on the long edge. Native high-res beats upscaling for fine detail, but it's still harder to control. Treat 4096 as "show me what it can do," not "this is my daily driver."

The inputs that matter

• model (MODEL) - the pipeline out of DyPE_Condition. It will not accept a native ComfyUI model, so don't try.
• width / height - 256 to 4096, step 16, default 2048. Multiples of 16 matter; the code resizes otherwise.
• positive / negative (CONDITIONING) - from the stock CLIPTextEncode nodes. The KSampler reaches into the conditioning to pull prompt_embeds and the pooled output, so load your CLIP the normal way (DualCLIPLoader for Flux, CLIPLoader for the others). Feed an unCLIPConditioning into positive and it'll use those clip-vision embeds as IP-Adapter image conditioning.
• steps (default 20) - drop it hard if you're on a distilled model; Krea with the turbo LoRA is comfortable in single digits.
• cfg (default 3.5) - routed straight to the model's guidance_scale for Flux 1, Klein, and Z-Image; Qwen is the odd one out, feeding true_cfg_scale instead because its pipeline asks for it that way.
• offload (default true) and num_blocks_per_group (default 1) - the VRAM escape hatches. With offload on it uses diffusers' block-level group offloading (1 block per group = maximum granularity, slowest); with it off it falls back to whole-model CPU offload. At 4096×4096 you will want this on.

One output, LATENT, into a VAE decoder - see DyPE_Encoder for the Flux 2 Klein case, or the native VAEDecode/VAEDecodeTiled for the rest.

Installing

ComfyUI Manager (search "ComfyUI_DyPE"), or:

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

Heavy deps: diffusers, transformers, accelerate, sentencepiece, opencv-python, omegaconf; Klein wants diffusers 0.37+.

Where people get burned

• Model name matters more than any knob. FLUX.1 Krea-dev is the reference path; Kontext is not supported, and the README notes Krea's "scaled" variants don't work either.
• No sampler dropdown means no way to experiment with schedulers - the pack picks the scheduler per model. If you came here to tune, this is not that node.
• The pack clears ComfyUI's loaded-model cache before sampling, so every run pays a reload cost, and memory that was freed gets re-allocated. On a 12GB card, budget for it.
• Patent pending, per the README: fine to play with locally, but commercial use needs a license from the authors. Worth knowing before you build a product on it.