PyramidFlow Model Loader
The checkpoint dropdown and the fp8 trap
- compile_args
- pyramidflow_model
PyramidFlow Model Loader is the first node in any PyramidFlow workflow. It loads the diffusion transformer that does the actual denoising, and it's where you pick both the checkpoint and - critically - the precision it runs in. If you've ever loaded a model, you've basically got this one. But two settings here can quietly ruin your results, and they're worth talking about before you click anything.
The node reads from ComfyUI/models/diffusion_models, and the dropdown lists whatever's in there (subfolders count, which is why the examples use a pyramidflow subfolder). Download the files from Kijai/pyramid-flow-comfy on HuggingFace - for the current Flux-era pack that's the pyramid_flow_miniflux checkpoints, plus a 768 version if you want the higher-res variant. The loader even auto-detects which architecture you dropped in by peeking at the checkpoint keys: pos_embed. keys mean the old mmdit architecture, otherwise it builds the miniflux (Flux) transformer. You can't really pick the wrong file.
The inputs that matter
precision- defaultbf16, and the README is unusually blunt about the alternatives: "Fp8 severely reduces quality and is not recommended, only use it if you must." This is the trap. On most modern ComfyUI packs fp8 is a free lunch; here it visibly degrades the output. Start atbf16and only reach forfp8_e4m3fnorfp8_e4m3fn_fastif you're hard against VRAM.fp16andfp32exist if you want a specific comparison.enable_sequential_cpu_offload- defaultfalse, and the tooltip reads like a warning label: "saves VRAM but is MUCH slower, do not use unless you have to." If you're under 7GB or so and bf16 won't fit, this is the emergency hatch, not the daily driver. It offloads the model layer-by-layer to CPU and you'll feel every one of those transfers.compile_args(optional) - the output of PyramidFlow Torch Compile Settings. Wire it in and the loader torch.compiles the selected layers while loading, instead of you doing it afterward. Nice when it works, ignored entirely when you're just trying to get a render out.
The output
One output, pyramidflow_model (PYRAMIDFLOWMODEL), and it wires straight into the model input on PyramidFlow Sampler. That's the entire graph: loader → sampler, with Text Encode feeding the prompt.
Install and the usual rough edges
Same pack story as the rest of Kijai's wrappers: ComfyUI Manager → search "PyramidFlow Wrapper", or
cd ComfyUI/custom_nodes
git clone https://github.com/kijai/ComfyUI-PyramidFlowWrapper
then restart. Requirements come from the pack's requirements.txt - diffusers, accelerate, sentencepiece, timm, numpy<=1.26.4 - and ComfyUI Manager or a fresh start handles them. Models go to ComfyUI/models/diffusion_models (or a pyramidflow subfolder inside it).
One real-world gotcha, grounded in the pack's own history: when Kijai refactored this pack from SD3 to the Flux "miniflux" architecture, users on older ComfyUI builds immediately hit a folder_paths.get_full_path_or_raise crash right here in this node. The fix was updating ComfyUI, and it's still the first thing to try if the loader errors on a freshly cloned pack. And a friendly warning for 2026: this is a late-2024 video model that's effectively dormant now. The workflow will run, but don't expect the polish of current-generation video models - and don't let the bf16 default seduce you into thinking it'll be fast, because at 7GB VRAM it's "runs," not "flies."
Inputs (4)
| Name | Type | Default | Description |
|---|---|---|---|
| model | COMBO | The name of the checkpoint (model) to load. | |
| precision | COMBO | bf16 | 5 options: fp8_e4m3fn, fp8_e4m3fn_fast, fp16, fp32, bf16 |
| enable_sequential_cpu_offload | BOOLEAN | false | Enable sequential cpu offload, saves VRAM but is MUCH slower, do not use unless you have to |
| compile_argsopt | PYRAMIDFLOW_COMPILEARGS | Optional torch.compile arguments |
Outputs (1)
| Name | Type | Description |
|---|---|---|
| pyramidflow_model | PYRAMIDFLOWMODEL | — |