PM Task Arithmetic

Task Arithmetic is the "what did this LoRA learn, and can I add that to another one" merge. Instead of blending two adapters like SLERP does, it figures out each LoRA's task vector - the difference between that LoRA and the base model - adds those vectors up, and lays the sum back down on the base. It's delta-merging: you're combining the changes, not the models. If you have a solid character LoRA and a tiny style LoRA and you want the style bolted onto the character, this is the natural tool.

That framing comes straight from the node's description: computing task vectors by subtracting a base model, combining them as a weighted average, and adding the result back. It's the same math the "Model Merge" crowd has used on full checkpoints for years (and the same family of ideas that creates half the checkpoints on CivitAI), applied here to LoRA deltas. The pack merges in delta space, then refactors the merged dense delta back into a proper LoRA using randomized SVD - by default energy_rSVD, which picks a rank that keeps 99% of the delta's energy, so the saved LoRA stays efficient without losing much.

When to reach for it

Task Arithmetic shines when your LoRAs share a common ancestor - they were all trained from the same base model, which is the norm. The task vectors then point in comparable directions, and adding them is meaningful. Typical moves:

• Transfer one capability (a style, a character's likeness) onto a base you keep.
• Steer a model's behavior by adding a small task vector on top of a larger one.
• Combine a couple of compatible LoRAs when you want additive effects rather than a blended average.

The classic warning: it assumes the LoRAs aren't fighting. When you merge three or four LoRAs that edit the same weights in opposite directions, task vectors interfere and you get mush - that's exactly the failure mode the pack's TIES node exists to fix. For two or three compatible adapters, this is your workhorse; for a pile of conflicting ones, walk over to TIES or DARE.

The inputs that matter

Two knobs, both with sensible defaults:

• rescale_norm - the rescaling strategy, defaulting to "default" (auto-selects: L1 for methods that need it, none otherwise). The alternatives are explicit l1, l2, linf (L-infinity, which caps the max absolute value so nothing amplifies out of control), and none (no rescaling - can weaken the merge). For a first attempt, leave it on default.
• normalize - whether the contributing weights are normalized per tensor (default true). This is the standard Mergekit behavior and it keeps your per-LoRA strengths behaving like proportions rather than raw gains. Turn it off only if you have a reason.

The node's output is a MergeMethod value, not a merged LoRA. Wire it into the method input of PM LoRA Merger (Mergekit), and build the rest of the chain around that:

PM LoRA Stacker → PM LoRA Stack Decompose → PM Task Arithmetic
   → PM LoRA Merger (Mergekit) → PM LoRA Apply (or PM LoRA Save)

Installing

Task Arithmetic ships in larsupb/LoRA-Merger-ComfyUI ("LoRA Power-Merger ComfyUI"), the same pack as the other PM merge nodes. Install via ComfyUI Manager by searching for "LoRA Power-Merger", or manually:

cd ComfyUI/custom_nodes
git clone https://github.com/larsupb/LoRA-Merger-ComfyUI.git
cd LoRA-Merger-ComfyUI
pip install -r requirements.txt

Then restart ComfyUI. The requirements install mergekit from its GitHub repo (git+https://github.com/arcee-ai/mergekit.git) plus lxml, so make sure git and network are available in your ComfyUI environment - that's the dependency people usually trip on with this pack.

Where people get burned: skipping the Decompose node, or expecting the method node alone to output a usable LoRA. Keep the full chain wired and leave rescale_norm on default your first few times, and Task Arithmetic is about as predictable as merging gets. It's the one I reach for first when combining two LoRAs that shouldn't conflict.