ComfyUI LoRA Stacking Guide for NSFW Generations

A single LoRA is rarely enough for production NSFW work. You need a character LoRA for face consistency, a style LoRA for the visual treatment, an anatomy LoRA for explicit fidelity, and maybe an unlock LoRA if you are using a base model that needs help. That stack of three or four LoRAs has to work together without one canceling out another or producing a messy averaged result. Most people stack LoRAs by throwing them all in at default weights and hoping for the best. That is why their outputs look like a blender hit them. Stacking LoRAs well is a craft skill, and here is the exact process I use to get clean output from complex stacks.

Quick Answer: In ComfyUI, chain LoRA Loader nodes or use the LoRA Stacker from Efficiency Nodes. A typical stack sets unlock LoRA at 0.7, character LoRA at 0.8, style LoRA at 0.6, anatomy LoRA at 0.5. Each LoRA has both model and CLIP weights. Lower CLIP weight (0.4-0.6) if prompts feel scrambled. Test one LoRA at a time, then add more incrementally. Conflict between two LoRAs trying to do similar things is the most common failure.

Why One LoRA Is Rarely Enough

Look, the reason you cannot get production NSFW output from a single LoRA is that LoRAs are specialists. A character LoRA encodes facial features and body proportions but does not know what good skin texture looks like. A style LoRA encodes lighting and color treatment but does not know your character's face. An anatomy LoRA fills explicit-content gaps but does not have opinions about composition. Each LoRA carries information in a narrow band, and good output requires multiple bands working together.

The math of why this works. A LoRA modifies the base model's weights in a low-rank decomposition, which means it nudges the model's behavior in a specific direction while leaving most of the model unchanged. Stacking multiple LoRAs combines their nudges, and as long as the nudges are in roughly orthogonal directions, the combined effect is the union of their individual capabilities.

Where stacking goes wrong is when two LoRAs nudge in similar directions. If you load two photoreal-skin LoRAs at full strength, they are both pushing the model toward photoreal skin, and the combined effect is "over-photoreal skin" which usually means waxy or over-detailed. This is the most common stacking failure and it happens whenever creators load LoRAs without thinking about what each one is actually doing.

The right mental model. Picture each LoRA as a vector in style space. Stacking LoRAs adds the vectors. If two vectors point in similar directions, you get an overcooked result in that direction. If they point in different directions, you get a balanced combination. Stack diverse LoRAs, not redundant ones.

For NSFW work specifically, the typical production stack covers four bands:

• Unlock band: Helps base model produce explicit content (mainly for Flux)
• Character band: Locks in specific face/body features
• Style band: Controls visual treatment (photoreal, cinematic, fashion)
• Anatomy band: Improves explicit-content fidelity

These are orthogonal enough that all four can stack without major conflicts. Adding more LoRAs beyond these typically introduces redundancy and degrades output.

Model Weight vs CLIP Weight

Every ComfyUI LoRA Loader has two weight parameters called strength_model and strength_clip. Most tutorials gloss over the difference between them. Knowing the difference is the unlock for serious stacking.

strength_model controls how much the LoRA modifies the UNet (the diffusion model itself). This is the visual influence. Higher strength_model means the LoRA's visual signature shows up more strongly in the output. This is what most people think of as "LoRA strength."

strength_clip controls how much the LoRA modifies the text encoder (CLIP). This affects how the model interprets prompts. Higher strength_clip means the LoRA biases prompt understanding toward whatever the LoRA was trained on.

For most cases, you want strength_model and strength_clip at roughly the same value. The model and the text encoder need to agree about what the LoRA wants. If they diverge too far, you get scrambled output where the model is rendering one thing while the text encoder thinks you asked for another.

But there are specific cases where you want them different:

• Character LoRAs: Often benefit from slightly lower CLIP weight (0.6-0.7 vs 0.8 model weight) because the CLIP modification can over-emphasize character-name trigger words and make prompts feel constrained.
• Style LoRAs: Sometimes benefit from higher CLIP weight to push the model to interpret prompts in the LoRA's style vocabulary.
• Anatomy LoRAs: Usually want lower CLIP weight (0.4-0.5) to avoid the model over-emphasizing anatomy in the prompt interpretation.
• Unlock LoRAs: Want strength_model at 0.7-0.8 and strength_clip at 0.5-0.6 because over-cranking CLIP starts mangling prompt semantics.

A common 2026 starting point that works:

• strength_model: 0.8
• strength_clip: 0.6

This is a slight imbalance that gives visual influence without scrambling prompts. Tune from there based on what your stack feels like.

LoRA Stacker Node Setup

For stacking 3+ LoRAs cleanly, the LoRA Stacker node from Efficiency Nodes is the right tool. It bundles multiple LoRA Loader operations into a single node, which keeps your graph readable. Install Efficiency Nodes through the ComfyUI Manager. The node appears as "LoRA Stacker" in the loaders category.

The LoRA Stacker node has:

• lora_count: number of LoRA slots to expose (set to your stack size)
• mode: "simple" or "advanced" (simple uses one weight per LoRA, advanced separates model and CLIP)
• For each slot: lora_name (dropdown of available LoRAs), strength (or strength_model and strength_clip in advanced mode)

For NSFW work I always use advanced mode because the model/CLIP weight distinction matters. Simple mode is fine for casual experimentation but limits your tuning options.

The node outputs a single LORA_STACK that you connect to a downstream node that applies all stacked LoRAs at once. The standard pattern is:

1. CheckpointLoader → output model and clip
2. LoRA Stacker → input lora_count and per-LoRA settings → output LORA_STACK
3. Apply LoRA Stack → inputs model, clip, LORA_STACK → outputs modified model and clip
4. KSampler with the modified model and clip

This stays clean visually even with 5+ LoRAs in the stack. Compared to chained LoRA Loaders (where each loader is a separate node), the Stacker approach is significantly more readable for production workflows.

The other stacker option worth knowing is the multi-lora-stack from ShmuelRonen, which has a more dynamic interface and can swap LoRAs at runtime. Useful for experimental workflows but the standard Efficiency Nodes Stacker is what I use for production.

Recipe: Unlock + Character + Style + Anatomy

The four-band stack that covers most production NSFW work. Settings are starting points; tune based on your specific LoRAs and base model.

For Pony Realism v2.2 or similar Pony-base SDXL:

LoRA 1 (Unlock, optional for Pony):
  lora_name: pony_nsfw_unlock.safetensors (if needed)
  strength_model: 0.4 (Pony already knows NSFW)
  strength_clip: 0.3

LoRA 2 (Character):
  lora_name: <your_character>.safetensors
  strength_model: 0.85
  strength_clip: 0.7

LoRA 3 (Style):
  lora_name: photoreal_skin.safetensors
  strength_model: 0.6
  strength_clip: 0.5

LoRA 4 (Anatomy):
  lora_name: anatomy_detail.safetensors
  strength_model: 0.5
  strength_clip: 0.4

Total combined model weight: 2.35. This sits in the safe range for SDXL family models. Above 3.0 you start risking output degradation. Below 1.5 you are probably under-using the stack.

For RealVisXL V5 (no built-in NSFW priors):

LoRA 1 (Unlock):
  lora_name: realvis_nsfw.safetensors
  strength_model: 0.75
  strength_clip: 0.55

LoRA 2 (Character):
  lora_name: <your_character>.safetensors
  strength_model: 0.8
  strength_clip: 0.65

LoRA 3 (Style):
  lora_name: cinematic_lighting.safetensors
  strength_model: 0.55
  strength_clip: 0.5

LoRA 4 (Anatomy):
  lora_name: anatomy_detail.safetensors
  strength_model: 0.55
  strength_clip: 0.4

Total combined model weight: 2.65. Slightly higher because RealVisXL needs more push from the unlock LoRA to compete with its photoreal-portrait training bias.

For Flux Dev or Flux Schnell:

LoRA 1 (Unlock, critical):
  lora_name: flux_nsfw_unlock.safetensors
  strength_model: 0.85
  strength_clip: 0.65

LoRA 2 (Character):
  lora_name: <your_flux_character>.safetensors
  strength_model: 0.8
  strength_clip: 0.7

LoRA 3 (Style):
  lora_name: flux_photoreal.safetensors
  strength_model: 0.5
  strength_clip: 0.45

Three LoRAs total because Flux has a smaller LoRA ecosystem and stacking more often introduces conflicts. Total combined model weight: 2.15.

The patterns above are starting points. The real work is sweeping individual weights and seeing what works for your specific LoRA combinations and base model.

Conflict Patterns and How to Diagnose

Recognizing conflict patterns is the difference between guessing and tuning. Here are the most common failures and what they look like in output.

Style competition (most common): Two LoRAs trying to do similar things. Output looks "muddy" or "overcooked." Specific signs include skin that looks waxy, lighting that feels artificial, and oversaturated colors.

Fix: Reduce one of the competing LoRAs to 0.4-0.5 strength_model, or remove it entirely.

Character drift from style LoRA: Character LoRA's face being overridden by an aggressive style LoRA. Specific signs include face shape changes between generations with the same prompt, ethnicity drift, and expression flattening.

Fix: Lower style LoRA strength_model to 0.4-0.5. Increase character LoRA strength_model to 0.9. Drop style LoRA's strength_clip to 0.3-0.4 specifically.

Anatomy over-emphasis: Anatomy LoRA pulling too hard on body details. Specific signs include cartoonishly exaggerated anatomy features, body parts that look obviously LoRA-injected, and prompts about non-anatomy details getting ignored.

Fix: Anatomy LoRA strength_model to 0.4 max. CLIP weight specifically should be very low (0.3-0.4) for anatomy LoRAs because the CLIP modification is what makes the LoRA over-emphasize features in prompts.

Unlock LoRA bleeding into SFW content: Unlock LoRA biasing all generations toward NSFW even when prompt does not call for it. Specific signs include every generation tending toward explicit even with prompts that should be SFW, and the model adding NSFW elements unprompted.

Fix: Unlock LoRA strength_model to 0.6 max. If you do mixed SFW/NSFW work, build separate workflows for each and use unlock LoRA only in the NSFW workflow.

Color shift across stack: Multiple LoRAs trained on different color treatments. Output has inconsistent color temperature across generations. Specific signs include skin that looks pink in one generation and yellow in the next, with the same prompt.

Fix: Identify which LoRA is most opinionated about color (usually a style or photoreal LoRA). Lock that LoRA to a moderate weight (0.5-0.6) and tune the others around it.

The diagnostic approach for any conflict. Disable all LoRAs except one. Generate. Add the next LoRA. Generate. Compare. The LoRA whose addition broke the output is the conflict source. Lower its weight or remove it.

Weight Sweep Procedure

Systematic weight tuning beats guessing. The procedure I use:

1. Fix the seed. Pick one seed that produced acceptable output and lock it for the whole sweep. This isolates LoRA effects from seed variance.

2. Establish baseline. Generate with all LoRAs at "reasonable starting weights" (the recipe above). Save this as the baseline.

3. Sweep one LoRA at a time. Vary one LoRA's strength_model across a range (typically 0.3, 0.5, 0.7, 0.9). Keep all other LoRAs at baseline weights. Generate at each setting.

4. Pick the best setting for that LoRA. Look at the four outputs. Pick the one where this LoRA's contribution is strongest without breaking the overall output. Lock that weight.

5. Move to the next LoRA. Repeat the sweep with the next LoRA in the stack, keeping the previously-tuned LoRA locked at its best weight.

6. Iterate if needed. Sometimes tuning LoRA 3 reveals that LoRA 1's setting needs adjustment. Don't be afraid to circle back.

This procedure takes 20-40 generations for a four-LoRA stack but the result is a tuned stack that consistently produces what you want. Versus the "throw all LoRAs in at 1.0" approach that produces messy output 60 percent of the time, the time investment pays back fast.

For automating this in ComfyUI, the XY Plot extension lets you batch-generate across a parameter sweep automatically. Set the sweep axes to two LoRA strengths and generate the full grid in one batch. Much faster than manual sweeps.

For more on weight balancing across complex stacks, my Pony Realism vs RealVisXL writeup discusses how LoRA compatibility differs between the two ecosystems, which affects what stacks are even possible. If you are running stacks on 8 GB VRAM, the low-VRAM setup guide covers how many LoRAs you can practically load before hitting OOM.

Saving Stack Presets

Once you have a tuned stack, save it as a preset. ComfyUI has multiple ways to do this:

Save the entire workflow as JSON. Right-click on canvas, save workflow. This preserves the LoRA stack along with everything else (sampler, prompts, ControlNet, etc.). Reload as a template when you need this stack.

Save just the stack as a node template. Select the LoRA Stacker node, right-click, save as template. This saves just the stack configuration, which you can drop into any workflow.

Use the ComfyUI Manager workflow library. Save tuned workflows there for easy reuse across projects.

For production work, I maintain about 8-10 named stack presets covering common use cases:

• Photoreal Portrait
• Photoreal Full Body
• Cinematic Lifestyle
• Editorial Fashion
• Anime Portrait
• Anime Full Body
• Multi-Character Scene
• Hero Image (Maximum Detail)

Each preset has its own tuned stack and I switch between them based on what I am making. This is far faster than re-tuning for every project.

Three Reusable NSFW Stacks

Three complete stack presets that cover common production scenarios. Use as-is or as starting points for your own tuning.

Stack 1: Photoreal Lifestyle Portrait (RealVisXL base)

1. realvis_nsfw_v3: model 0.7, clip 0.55
2. <character>: model 0.85, clip 0.7
3. cinematic_lighting: model 0.5, clip 0.5
4. detailed_skin: model 0.45, clip 0.4

Best for single-subject portrait or upper-body, controlled lighting, photoreal aesthetic. Avoid for explicit-anatomy focused work (the unlock LoRA is moderate, not aggressive).

Stack 2: Explicit Full Body (Pony Realism base)

1. <character>: model 0.85, clip 0.7
2. photoreal_skin_pony: model 0.65, clip 0.5
3. anatomy_v2: model 0.55, clip 0.4
4. (optional) pose_detail: model 0.4, clip 0.35

Best for anatomy-focused explicit content, full body coverage, photoreal style. Pony Realism does not need an unlock LoRA. Avoid for portrait-focused work (the anatomy LoRA is over-emphasized for face-only crops).

Stack 3: Anime NSFW (NoobAI XL or Illustrious base)

1. anime_nsfw_unlock: model 0.7, clip 0.55
2. <character>: model 0.85, clip 0.7
3. anime_style: model 0.5, clip 0.45
4. detailed_eyes: model 0.4, clip 0.35

Best for anime-style NSFW with character consistency. The style LoRA is the personality of the output, so choose based on your aesthetic target (more painterly, more cell-shaded, etc.). Avoid for photoreal work.

All three of these are starting points. Run weight sweeps to dial in based on your specific LoRAs. Saving each as a preset means you can iterate per-project without re-tuning the base.

For zero-management LoRA workflows, lewdly.ai routes prompts through pre-tuned stacks server-side. The user describes what they want and the platform applies the right LoRAs at the right weights. This is the right level of abstraction if managing LoRA stacks is not how you want to spend your time. Full disclosure I help build it.

Frequently Asked Questions

How many LoRAs can I stack at once on SDXL? Practically 4-5 LoRAs at moderate weights. Past 5, conflicts and quality degradation become severe. Some workflows technically support 8+ LoRAs but the output rarely matches what you would get from a smaller, well-tuned stack.

What is the difference between LoRA Stacker and chained LoRA Loaders? Functionally similar but visually different. LoRA Stacker bundles multiple LoRAs into a single node for cleaner graphs. Chained LoRA Loaders are explicit per-LoRA nodes. Both produce equivalent output. Stacker is better for 3+ LoRAs, individual Loaders are fine for 1-2.

Why does my output look messy with multiple LoRAs? The most common cause is two LoRAs trying to do similar things at high weights. Disable LoRAs one at a time to find the conflict. Lower or remove the LoRA that breaks the output. Total combined model weight above 3.0 is also a common cause.

Should strength_clip always equal strength_model? Usually no. A slight reduction in strength_clip (0.6-0.7 vs 0.8 model) helps prevent prompt scrambling. For anatomy LoRAs specifically, much lower CLIP weight (0.3-0.4) prevents over-emphasis. For character LoRAs, lower CLIP weight prevents over-fixation on character-name trigger words.

Can I mix Pony LoRAs and SDXL LoRAs in the same stack? Technically yes, practically no. The latent spaces are different and the LoRAs were trained on different underlying models. You can use Pony LoRAs at reduced weights on a Pony-base model that already shares the latent space. Mixing across ecosystems usually produces artifacts.

What about LoRA merging instead of stacking? LoRA merging combines multiple LoRAs into a single LoRA file. This produces equivalent effects to stacking at runtime but with lower VRAM usage during sampling. Worth doing for stable production stacks. The merge tools (in ComfyUI Manager or via the kohya scripts) handle this. Once merged, the combined LoRA loads as a single LoRA with one weight.

How do I know if a LoRA is conflicting with another? Generate with each LoRA individually and compare to the stack output. If the stack output is missing the visible signature of one LoRA, that LoRA is being suppressed by something else in the stack. If the stack output has weird artifacts not present in any individual LoRA, two LoRAs are amplifying each other.

Does LoRA order matter in a stack? In most stacker implementations, no. LoRAs are combined as a sum of their weight modifications and the order does not change the result. Some legacy chained-loader implementations have minor order effects but they are negligible.

Can I disable a LoRA without removing it from the workflow? Yes. Set its strength_model to 0 and strength_clip to 0. The LoRA is loaded but contributes nothing. This is useful for A/B testing. Just remember to reset weights when you want it back in the mix.

What is the maximum strength I can set? Most LoRA Loaders accept values 0-2.0 or even higher. Above 1.0 over-emphasizes the LoRA past what it was trained for and usually produces artifacts. Stay in the 0.3-1.0 range for production work. The 1.0+ range is for experimentation only.

The Right Mental Model

LoRA stacking is composition, not addition. Think of each LoRA as an instrument in an ensemble. A solo violin is interesting on its own. Three violins playing the same line is just louder, not better. A violin, viola, and cello playing complementary parts is music. The same principle applies to LoRA stacks. Diverse LoRAs serving different roles is music. Redundant LoRAs at high weights is noise.

The biggest lesson from two years of stacking LoRAs in production NSFW workflows. Disciplined weight tuning beats expensive hardware. A well-tuned three-LoRA stack on a moderate base model produces better output than a sloppy six-LoRA stack on the best hardware. The work that goes into the tune is what determines the ceiling, not the LoRA count or the gear.

For people who want clean output without managing the tune themselves, that is exactly what lewdly.ai's server-side LoRA routing handles. The platform picks stacks and weights based on prompt analysis and the user does not have to think about any of this. For most users that is the right abstraction layer. For technical users who want full control, the manual ComfyUI workflow described here is the way.

Reference resources include the Efficiency Nodes ComfyUI GitHub for the LoRA Stacker node, the multi-lora-stack repo for an alternative implementation, and the Civitai LoRA documentation which has community guides on specific LoRA combinations that work well.