Nodes/ComfyUI-J/🤗 Diffusers XL Pipeline
ComfyUI Node

🤗 Diffusers XL Pipeline

SDXL through the Diffusers wrapper, despite what the README's TODO list says

By Jannchie·Created 2 years ago·Updated about a year ago· 98
🤗 Diffusers XL Pipeline
    • pipeline
    ◄ckpt_name▾►
    â—„vae_name-â–º
    â—„scheduler_name-â–º
    â—„use_tiny_vaedisableâ–º

    Small honest correction before anything else: this pack's README lists "Stable Diffusion XL support" as an unchecked TODO item. This node exists, ships, and is functionally identical field-for-field to the SD1.5 loader. The docs just haven't caught up with the code - trust what's actually in the node list, not the checklist at the bottom of the README.

    What it is

    The SDXL counterpart to DiffusersPipeline, same idea, same fields, different checkpoint family underneath. Load an SDXL checkpoint and get back a DIFFUSERS_PIPELINE object that every other ComfyUI-J node - the Compel prompt embedder, ControlNet units, the Generator - consumes identically regardless of whether it came from this node or the SD1.5 one. That's the whole point of routing everything through one pipeline type: the rest of your graph doesn't need to know or care which base model is underneath.

    Under the hood, SDXL pipelines run two text encoders instead of one (that's an SDXL architecture fact, not something specific to this node), which is part of why SDXL checkpoints are bigger and slower to load than SD1.5 ones. This node doesn't expose anything different for that - it's handled internally by Diffusers' own SDXL pipeline class, same as loading and prompting an SDXL model through the Diffusers Python API directly would be.

    The inputs and outputs that matter

    • ckpt_name (required) - pulls from your existing checkpoints folder, same as the SD1.5 loader. Point it at an SDXL checkpoint; nothing in the node itself validates that you did, so loading an SD1.5 file here (or vice versa on the other pipeline node) will produce broken or nonsensical output rather than a clear error.
    • vae_name (optional, default -) - override the baked-in VAE. SDXL checkpoints usually bundle a working VAE already; only reach for this if you have a specific reason.
    • scheduler_name (optional, default -) - the same 18-option DPM++/Euler list as the SD1.5 pipeline. SDXL is still a DDPM-style architecture like SD1.5, so DPM++ 2M Karras remains a genuinely safe default here rather than something you have to second-guess.
    • use_tiny_vae (optional, default disable) - fast approximate decode for quick iteration, same trade-off as on the SD1.5 node: faster previews, softer detail.

    Output: pipeline (DIFFUSERS_PIPELINE), same type as the SD1.5 loader outputs, wired the same way into everything downstream.

    Installing it

    This is one node inside the ComfyUI-J pack, not a separate install. ComfyUI Manager: search ComfyUI-J, install, restart. Manual path:

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

    Same caveat as the SD1.5 node applies here too - that pip install step brings in the Diffusers library as a second SD implementation living alongside ComfyUI's own, in the same unisolated Python environment as every other custom node's dependencies. If you're installing this on a machine already loaded with other packs, keep an eye out for transformers/accelerate version churn afterward.

    Where people get burned

    Same core limitation as the rest of the pack: no LoRA support, and SDXL is where LoRA usage is arguably even more common than SD1.5 since so many SDXL finetunes and style packs ship as LoRAs rather than full checkpoints. If your workflow depends on stacking a couple of SDXL LoRAs, this pack has no node for it - you'd be back to ComfyUI's native loader chain for that part.

    The other real trap is VRAM. SDXL checkpoints are meaningfully heavier than SD1.5, and this node's width/height defaults live on the downstream Generator node rather than here, so nothing on this specific loader warns you about resolution. Load an SDXL checkpoint expecting SD1.5-class memory usage and you'll find out the hard way. And since this node's fields are a carbon copy of the SD1.5 pipeline's, it's easy to build a workflow, swap the checkpoint from SD1.5 to SDXL, and forget that everything downstream - resolution defaults, ControlNet models, textual inversions - needs to match the new architecture too. Nothing here cross-checks that for you.

    CategoryJannchie

    Inputs (4)

    NameTypeDefaultDescription
    ckpt_nameCOMBO0 options:
    vae_nameoptCOMBO-1 options: -
    scheduler_nameoptCOMBO-18 options: DPM++ 2M, DPM++ 2M Karras, DPM++ 2M SDE, DPM++ 2M SDE Karras, DPM++ SDE, DPM++ SDE Karras, +12
    use_tiny_vaeoptCOMBOdisable2 options: disable, enable

    Outputs (1)

    NameTypeDescription
    pipelineDIFFUSERS_PIPELINE—