LocalForge AILocalForge AI
LibraryBlogFAQ

How to Train a LoRA in ComfyUI

ComfyUI now includes a built-in Train LoRA node, so a training graph can live beside the inference workflows used to test the result. The node accepts a model, training latents, and positive conditioning, then exposes adapter rank, optimization, loss, precision, checkpointing, and continuation controls. It outputs the trained LoRA, loss history, and completed step count for downstream saving and review.

This guide explains the native node workflow rather than using ComfyUI only as a front end for Kohya, OneTrainer, or a custom training extension. The graph interface does not remove dataset, memory, or validation work. You still need to prepare rights-cleared images, create matching conditioning, choose a compatible base model, save intermediate artifacts, and compare fixed prompts. Built-in training is evolving, so pin the ComfyUI version and verify node fields against the current official documentation before reproducing a graph.

Quick Answer

Update to a ComfyUI build that contains the official Train LoRA node. Load the exact base model, prepare and batch training images, encode them into latents with the correct VAE, create positive conditioning from matching captions, and connect those inputs to Train LoRA.

Set a conservative rank, batch behavior, learning rate, optimizer, loss function, precision, seed, and step count. Enable gradient checkpointing when memory requires it. Send the LoRA output to the official saving path, record the loss map and completed steps, then load the saved adapter into a separate fixed-seed inference graph.

The node can train an adapter. It cannot tell you whether the dataset is lawful, captions are accurate, the model family matches, or the final checkpoint is flexible.

Confirm You Have the Built-In Node

Search the node menu for the official Train LoRA node and open its embedded documentation. The current official docs identify TrainLoraNode as a built-in node that creates LoRA weights from a model, latents, and conditioning.

If the node is absent:

  • check the installed ComfyUI revision;
  • review official update instructions;
  • restart after updating core and frontend components;
  • do not substitute a custom node with the same display name without reading its repository.

Save the ComfyUI commit or release with the workflow. Built-in training controls can change as the implementation matures.

Understand the Node Contract

The official node documentation lists three core training inputs:

  • model: the diffusion model that receives LoRA adapters;
  • latents: encoded training images;
  • positive conditioning: text conditioning aligned with those images.

It also exposes training controls including rank, learning rate, optimizer, loss function, training precision, LoRA precision, gradient checkpointing, seed, algorithm options, and an existing LoRA input for continuation.

Outputs include:

  • the trained LoRA model;
  • a loss history map;
  • total completed steps.

That contract makes graph wiring visible, but it puts responsibility on you to align each latent with the correct caption conditioning.

Choose the Base Model First

Train and test against one exact checkpoint family. Do not infer architecture from filename alone.

Before building the graph, record:

  1. checkpoint path or repository;
  2. architecture and variant;
  3. VAE;
  4. text encoders;
  5. license;
  6. intended inference checkpoint;
  7. compatible LoRA loading path.

SD 1.5, SDXL, FLUX, and other architectures have different components and memory needs. The Train LoRA node can only work with model objects and adapter targets supported by the current core implementation. Check official node and model documentation instead of assuming every model loaded by ComfyUI can be trained identically.

Prepare a Dataset Outside the Graph

Curate before importing images. Keep one target concept and vary details that should remain promptable.

Remove:

  • exact and near duplicates;
  • blurred or corrupted files;
  • unwanted signatures, watermarks, text, and borders;
  • anatomy or object errors;
  • misleading crops;
  • sources without sufficient rights.

Build close, medium, and wide coverage for a character. Vary subject matter and composition for a style. Cover defining sides and materials for an object.

Keep original files separate from processed training inputs. Save a manifest with filename, source, rights status, dimensions, hash, and caption review state.

Create Matching Conditioning

Each training image needs conditioning that describes its visible content and contains the chosen trigger where appropriate. The exact text-encoding nodes depend on the base architecture.

Use one stable trigger. Describe clothing, pose, expression, background, framing, lighting, materials, and other variable details. For style training, caption the depicted content so it does not become part of the style trigger.

Be careful with batches. Image order and caption-conditioning order must stay aligned. A graph that batches ten latents and repeats one caption can quietly teach the wrong assignment.

For a first proof:

  • use a small representative set;
  • make the image-caption mapping explicit;
  • inspect every processed image;
  • preview or log the caption paired with each latent;
  • avoid random transforms until the base mapping works.

Encode Images Into Latents

Load images, resize or crop them appropriately for the base model, then encode them with the matching VAE. Preserve aspect ratio where the graph supports a controlled bucketing path. Do not stretch every image into one shape.

Inspect the preprocessing result before VAE encoding. Automatic center crops can remove defining features. Upscaling a small image cannot recreate real detail.

Batch dimensions must be supported by the model and training node. Start conservatively. Mixed aspect ratios may require separate groups or an explicit bucket workflow rather than one heterogeneous batch.

Build the Minimal Training Graph

A readable first graph has six stages:

  1. Load the exact model, VAE, and text encoders.
  2. Load and preprocess a small image batch.
  3. Encode images into training latents.
  4. Encode matching captions into positive conditioning.
  5. Train through the built-in Train LoRA node.
  6. Save the LoRA and preserve loss and step outputs.

Keep validation in a separate branch or workflow. Separating training from evaluation reduces accidental changes and makes memory behavior easier to understand.

Name node groups clearly. Add workflow notes with the dataset revision, trigger, base hash, rank, learning rate, optimizer, steps, and ComfyUI commit.

Choose Conservative Node Settings

Rank

Rank controls adapter capacity and file size. Higher rank can model more variation but can also memorize a small dataset and consume more memory. Begin modestly and compare checkpoints.

Learning rate

Learning rate interacts with optimizer, batch, rank, dataset size, and number of steps. Do not copy a value from another architecture and change several other controls at once.

Optimizer

The official documentation currently lists choices including AdamW, Adam, SGD, and RMSprop. AdamW is a familiar baseline. A different optimizer requires a reason and a controlled comparison.

Loss function

The node exposes MSE, L1, Huber, and SmoothL1 options in current documentation. Use the default baseline unless you understand why another loss fits the objective. A lower loss value across different loss functions is not a fair quality comparison.

Precision

Training and LoRA dtypes affect fit, stability, and output. The current docs list BF16, FP32, and native behavior for training, with supported LoRA dtypes. Choose a mode supported by the GPU and base model.

Watch for non-finite loss, black samples, or corrupted weights. Do not assume lower precision is stable merely because it fits.

Gradient checkpointing

Enable it when activation memory is the limiting factor. It trades additional computation for reduced memory. Measure speed and complete the full save and validation cycle.

Seed and steps

Fix the seed for repeatable comparisons. Use a short step count for the first run. A graph that trains for hours before proving that captions and saves work is poorly staged.

Run an End-to-End Smoke Test

A useful smoke test must:

  1. load the intended model;
  2. encode representative image sizes;
  3. create matching conditioning;
  4. complete several optimization steps;
  5. produce finite loss history;
  6. save a LoRA file;
  7. reload that file;
  8. generate a validation image.

Monitor GPU memory during model load, latent creation, the first backward pass, saving, and inference. Close other GPU applications before measuring.

If the graph only returns a LoRA object in memory and never saves or reloads it, the pipeline is not proven.

Save Intermediate Adapters

Do not rely only on the final step. If the graph and node version support checkpoint intervals or continuation through existing_lora, save named stages with configuration records.

Be careful when continuing an existing adapter. Confirm:

  • it was created from the same architecture;
  • rank and algorithm are compatible;
  • total completed steps are recorded;
  • dataset and optimizer changes are intentional;
  • the original file remains backed up.

Continuing a LoRA is not the same as a clean comparison. For experiments, independent runs from the same base are easier to interpret.

Validate in a Separate ComfyUI Workflow

Build a fixed graph that loads the exact base, applies one candidate LoRA, and samples a prompt grid.

Test:

  • direct trigger recognition;
  • an unseen background;
  • new pose, clothing, material, or subject;
  • close, medium, and wide framing;
  • multiple LoRA strengths;
  • the base model without the adapter;
  • at least one prompt without the trigger.

Keep seed, sampler, steps, guidance, dimensions, and prompt text fixed. Save contact sheets labeled with checkpoint and strength.

The loss map helps detect divergence or unusual jumps, but it does not score identity, style fidelity, prompt obedience, anatomy, or leakage.

Common Graph Failures

Model is not compatible: verify that the current built-in node supports the architecture and adapter targets.

Latent and conditioning batches differ: inspect batch counts and the path that repeats or combines captions.

Out of memory on the first step: lower physical batch, reduce dimensions or rank, enable checkpointing, and close other GPU processes.

Loss becomes NaN: check precision, learning rate, input validity, and model-specific numerical guidance.

LoRA saves but has no visible effect: verify the trigger, caption alignment, training steps, adapter strength, and inference checkpoint family.

Outputs copy one image: remove duplicates, add variation, reduce exposure, lower capacity, or choose an earlier checkpoint.

Continuation behaves unpredictably: confirm the existing adapter, step count, algorithm, rank, base model, and dataset revision.

When to Use a Dedicated Trainer

Native ComfyUI training is useful when you value a visual data path, direct integration with validation graphs, and built-in node experimentation.

Use sd-scripts, Diffusers, SimpleTuner, OneTrainer, or another maintained dedicated trainer when you need:

  • mature dataset bucketing and metadata tooling;
  • distributed or cloud training;
  • architecture-specific quantization and offload;
  • extensive checkpoint scheduling;
  • experiment trackers and resumes;
  • a well-documented production configuration format.

A ComfyUI graph and a dedicated trainer can coexist. Export the adapter and test it in the same fixed ComfyUI evaluation workflow.

Reproducibility Checklist

Save:

  • workflow JSON;
  • ComfyUI commit and frontend version;
  • base model and VAE hashes;
  • dataset manifest and revision;
  • captions or conditioning source;
  • all Train LoRA node values;
  • image preprocessing dimensions;
  • GPU and software environment;
  • saved adapter files;
  • loss history;
  • completed steps;
  • validation prompts and outputs.

Remove private paths, access tokens, and sensitive metadata before sharing a workflow.

Bottom Line

ComfyUI's built-in Train LoRA node makes the training operation visible inside a graph, but the hard requirements remain the same: clean data, aligned conditioning, compatible architecture, stable memory, intermediate saves, and fixed validation.

Begin with a minimal graph and a short end-to-end test. Once it saves and reloads a valid adapter, scale the dataset or experiment with one setting at a time.

What to Do Next

FAQ

Can ComfyUI train a LoRA without custom nodes? +
Yes. Current ComfyUI includes an official built-in Train LoRA node that accepts a model, latents, and positive conditioning and outputs LoRA weights, loss history, and completed steps.
What data does the Train LoRA node require? +
It requires a compatible model, training latents encoded from images, and positive conditioning aligned with those images. Dataset curation and caption preparation happen elsewhere in the graph or before import.
Which optimizer should be used in ComfyUI? +
AdamW is a reasonable baseline among the currently documented choices. Change optimizer only as a controlled experiment because learning rate and convergence behavior can differ.
How should a ComfyUI-trained LoRA be tested? +
Load it in a separate fixed-seed workflow using the exact base model. Compare multiple checkpoints and strengths on new scenes, framing, attributes, and a base-only control.
Can training continue from an existing LoRA? +
The current node documents an existing LoRA input. Confirm architecture, rank, algorithm, base model, dataset revision, and prior steps before continuing, and keep the original file.
When is a dedicated trainer better than ComfyUI? +
Choose one for mature bucketing, distributed runs, architecture-specific quantization, extensive checkpoints, tracking, or production configuration management.