适配器配置

This is the node that decides what kind of training you're about to do, and it's the one you'll touch on nearly every workflow. Diffusion-Pipe can either train a LoRA - a small adapter that rides on top of a frozen base model - or full fine-tune the entire model. AdapterConfigNode is the switch between the two, and it's the first thing to set correctly because everything downstream (VRAM, training time, what you're allowed to ship) hangs off that choice.

What it does

The node takes your adapter choices and packages them into a single ADAPTER_CONFIG output. That wires into the adapter_config input on GeneralConfig, which is the hub node that assembles the whole training run. It's an optional input there, but if you leave it disconnected you get no adapter at all - and for most people a LoRA is the entire point of this pack.

The one input that really matters is adapter_type. Set it to lora and you're training a low-rank adapter: a few hundred MB of weights, dramatically lower VRAM, fast to iterate on. Set it to none and the pack switches to full fine-tuning of the base model - orders of magnitude more memory, way longer runs, and generally something you only do when you genuinely need to reshape the base itself. The author's own framing (in the tooltip, which you can trust here) is exactly that: lora for LoRA training, none for full fine-tune.

The rest of the inputs only apply when you pick lora:

• rank (default 16, range 4–1024) - controls how many parameters the LoRA gets and therefore how much it can express. Rank 16 is the sensible starting point for modern architectures. The KB's LoRA-training notes are worth remembering here: the old SDXL instinct of crank-the-rank is gone - Flux-era models do fine at 16, and bigger isn't automatically better.
• dtype (default bfloat16) - the data type of the LoRA weights. Leave it alone unless you have a reason; bf16 is the safe default on consumer cards.
• init_from_existing (optional) - a full path to an existing training run's weights, e.g. /data/diffusion_pipe_training_runs/something/epoch50, so a new run starts from those weights instead of scratch. This is your resume-and-tweak workflow.

When you pick none, the node returns an empty config and rank/dtype are ignored.

How it works under the hood

Look at the source and it's refreshingly honest: the node just builds a small dict like {"adapter": {"type": "lora", "rank": 16, "dtype": "bfloat16"}} and passes it along. GeneralConfig merges that into the TOML file that the real diffusion-pipe trainer reads when the Train node launches the subprocess. No magic, no model loading - it's a config serializer, and it can't explode on its own. If something looks wrong later, the problem is upstream (your paths) or downstream (your hyperparameters), not this node.

Installing the pack

The README is emphatic that this is the Linux/WSL2 version - on bare Windows it will not train (there's a separate Diffusion_pipe_in_ComfyUI_Win repo for that). The install is clone-based because of the git submodules that carry the actual training code:

cd ~/comfy/ComfyUI/custom_nodes/
git clone --recurse-submodules https://github.com/TianDongL/Diffusion_pipe_in_ComfyUI.git
git submodule init
git submodule update   # skip this and training will not work

Then a dedicated conda environment (comfyui_DP, Python 3.12), PyTorch built for your CUDA, and pip install -r requirements.txt - deepspeed is the heavy one. Full details are in the pack README, and a ready-to-import example workflow lives in example_workflows/.

Where people get burned

The classic first-run mistake is path formatting. Inside WSL2, this pack expects Windows-style drive-letter paths (Z:/... or F:/...) rather than /mnt/f/... - the author has had to explain this exact swap in the wild. And init_from_existing must be a full path to an epoch folder, not a loose filename. If training silently starts from the default config instead of your settings, re-check how you filled paths in the config nodes feeding GeneralConfig.