Jina Adapter LoRA Loader

The Jina Adapter LoRA Loader is the odd node in this pack, and you'll know it the second you look at its inputs: it takes a MODEL and a JINA_ADAPTER, and it returns both, patched. A normal ComfyUI LoRA loader touches one thing; this one touches two - the SDXL UNet and the Jina adapter - because the whole point is that a single LoRA file can carry two sets of weights, and this node is built to apply both halves in one go.

That's a narrower job than it sounds. It's not a general-purpose LoRA loader - it's the node for LoRAs that were trained on this Jina adapter's weights, and for the rare "one file, style both" case. If you're just trying to drop a random SDXL style LoRA into your workflow, use the regular LoraLoader and move on. This node is for when someone (probably you, after a training run) hands you a LoRA with lora_te keys and expects it to reach into the adapter's layers.

How it works

The pack's own adapter is built for this: jina_to_sdxl_adapter_v2.py contains an ExplicitMultiheadAttention with separate, unfused q_proj/k_proj/v_proj/out_proj linear layers, written specifically "to ensure LoRA compatibility" - fused attention modules are a pain to patch with LoRA deltas, so the author made the adapter LoRA-friendly from day one.

At run time the node (jina_load_lora.py) does two passes over the LoRA file:

1. The standard UNet pass, via ComfyUI's own comfy.sd.load_lora_for_models(model, None, lora_dict, model_weight, 0). If model_weight is 0, that half is skipped.
2. An adapter pass that scans the LoRA dict for keys matching ^lora_te\d*_(.+), maps each stem to a real module in the adapter (seq_projection.0/.4, pooled_projection, attention_blocks.N.attn.{q,k,v,out}_proj, the MLP layers, attention_pooler.attn.*), then adds delta = up @ down × (alpha/rank) × adapter_weight straight into a deep copy of the adapter's weights. If adapter_weight is 0, that half is skipped.

So model_weight steers the UNet half and adapter_weight steers the adapter half. Both default to 1.0, range −10 to 10, step 0.01. Set both to 0 and the node is a pass-through that just logs "Bypassed."

The inputs that matter

• model - your SDXL checkpoint output (from CheckpointLoaderSimple), straight in.
• jina_adapter - the output of Jina Adapter Loader (Advanced).
• lora_name - the picker over your standard ComfyUI/models/loras folder. Note this is the plain LoRA list, so this node does see every LoRA you own - it just only fully applies ones that contain adapter keys.
• model_weight / adapter_weight - the two halves, independent.

Outputs: model and jina_adapter (both patched, so wire them exactly where the originals went) plus info - and the info string is the diagnostic. It reports how many adapter modules were found, how many applied, and any that failed to apply, listed by name.

Troubleshooting that actually helps

The most common "it did nothing" case is right there in the info output: Found 0 adapter LoRA modules. That means the LoRA has no lora_te keys, so the adapter half silently did nothing while the UNet half may have applied. Check the info string before you assume the node is broken. Failed modules also show up by name (module path not found, no weight attribute), which is exactly what you want when an adapter's layer names drift between versions - if your adapter file is newer or older than the LoRA was trained against, the stems won't match and the info string tells you which layers fell through.

The pack's map_stem_to_module_name also shows its hand on naming: it strips text_model_, llm_adapter_, and model_ prefixes, which tells you the expected key format is the lora_te text-encoder style with those prefixes. If your training produced different names, expect failures here.

Install

Same as the rest of the pack:

cd ComfyUI/custom_nodes
git clone https://github.com/lRemixl/ComfyUI_JinaCLIP_SDXL_Adapter

Restart. The pack has no requirements.txt (ComfyUI's stock torch/transformers/safetensors/einops cover it), and your LoRA goes in the standard models/loras folder. One tip for first use: drop the info output into a text/display node on your first run so you can actually see the applied-module counts - with two patch targets in one node, that string is your only visibility into whether both halves landed.