🖥️Load LLM LoRA

If you're used to LoRA in the image-generation sense - a small adapter file that nudges a checkpoint toward a style or character - this is the same idea applied to language models. Load LLM LoRA takes an already-loaded local LLM and patches a LoRA adapter onto it, so you get the fine-tuned behavior (a specific persona, a domain-specific tone, an instruction-tuned variant) without needing a full separate copy of the base model's weights on disk.

Why this exists

Full fine-tuning a language model means storing a complete new set of weights, which for anything above a few billion parameters is a lot of disk and a lot of VRAM to swap in and out. LoRA fine-tuning trains a small set of low-rank adapter matrices instead and leaves the base model untouched - you load the (much larger) base model once, then apply a (much smaller) LoRA file on top to get the specialized behavior. That's exactly the split this node encodes: it doesn't load a model itself, it modifies one you've already loaded.

Inputs and output

There are three required fields, and they're simple by design. model takes the already-loaded model object - this comes from this pack's Local LLM Loader node, the one that pulls a transformers-format model from a local path or a Hugging Face repo ID. lora_path is a plain string pointing at the LoRA adapter you want applied; the pack doesn't validate or browse for this file for you, so it's on you to get the path right. is_enable is the usual toggle this pack uses everywhere - flip it off and the node passes the model through unmodified, which is handy for A/B comparing base-vs-LoRA behavior without rewiring the graph.

The output is a single model, same CUSTOM type as the input, now with the LoRA patched in - and the node is flagged as an output node, meaning it's meant to be a natural endpoint in a loader chain rather than something you'd branch off from repeatedly. From here that model goes wherever a local LLM object is expected downstream - this pack's LLM node for actually running inference, for instance.

Where it fits

This only makes sense alongside the distributed-format local loader - models stored as a folder of transformers weights, not the GGUF single-file format. GGUF models loaded through this pack's GGUF loaders are a different object type entirely and don't go through this node; LoRA support for those is handled differently (and, per the wider llama.cpp ecosystem, is generally shakier). If your workflow is built around GGUF for VRAM reasons, this specific node isn't the one you want.

Installing it

It ships with the full pack, not standalone:

• ComfyUI Manager: search "comfyui_LLM_party", install, restart ComfyUI.
• Manual: cd ComfyUI/custom_nodes && git clone https://github.com/heshengtao/comfyui_LLM_party, then pip install -r requirements.txt inside your ComfyUI Python environment, restart.

Because this node operates on transformers-format models, make sure the transformers install (pulled in by the pack's requirements) actually succeeded - it's one of the heavier dependencies in requirements.txt, and on constrained environments it's worth checking your pip install log for it specifically rather than assuming everything came through clean.

Common issues

The most likely failure is a path problem, not a code problem: lora_path is a raw string with no validation, so a typo, a relative path resolved from the wrong working directory, or pointing at a folder instead of the actual adapter file will fail at execution time rather than at graph-build time. Point it at the LoRA's own directory or file the way you'd point any local-loader node - absolute paths save you the guessing.

The second thing to watch for is architecture mismatch. A LoRA adapter is trained against a specific base model's weight shapes; feeding it a model object loaded from a different base model than the one the LoRA was trained on will either error out or, worse, silently produce garbage output that looks like a bug somewhere else in your graph. If output quality craters right after adding this node, that mismatch - not the node itself - is the first thing to rule out.