A Technical Guide to Implementing a

LoRA Training Extension for Stable

Diffusion 2.0 in the AUTOMATIC1111
WebUI

Section 1: Foundational Concepts for SD2 LoRA

Training

The effective training of Low-Rank Adaptation (LoRA) modules for Stable Diffusion 2.0 (SD2)
models necessitates a deeper understanding of both the LoRA methodology and the specific
architectural shifts that differentiate SD2 from its predecessors. These changes are not
merely incremental; they represent fundamental alterations to the model's text
comprehension and training objectives, which have profound implications for any fine-tuning
process. This section establishes the theoretical groundwork required to navigate these
complexities.

1.1 The LoRA Method: A Mathematical Primer

Low-Rank Adaptation (LoRA) is a highly effective Parameter-Efficient Fine-Tuning (PEFT)

technique designed to adapt large pre-trained models to new tasks or data domains with
minimal computational overhead. The core innovation of LoRA is the freezing of the vast
majority of the pre-trained model's weights. Instead of updating billions of parameters, LoRA
injects a small number of new, trainable parameters into the model's architecture. This
approach can reduce the number of trainable parameters by a factor of 10,000 and the GPU
memory requirement by a factor of three, making fine-tuning accessible on consumer-grade
hardware.
The mathematical principle behind LoRA is elegant and efficient. For any given weight matrix
W0​in a neural network layer (e.g., an attention layer's query or value projection matrix), LoRA
posits that the update to this matrix during fine-tuning, ΔW, has a low intrinsic rank. Therefore,
instead of learning the dense matrix ΔW, LoRA approximates it with a low-rank decomposition.
This is expressed by factorizing ΔW into two much smaller matrices, B and A.
The mathematical formulation is as follows 1:
For a pre-trained weight matrix W0​∈Rd×k, its update is constrained:

W=W0​+ΔW=W0​+BA

where B∈Rd×r and A∈Rr×k. The rank, denoted by r, is a critical hyperparameter chosen such
that r≪min(d,k). During training, W0​remains frozen, and only the parameters of A and B are
updated via gradient descent. The modified forward pass for an input vector x becomes:

h=W0​x+ΔWx=W0​x+BAx

This structure means that the original model's weights are preserved, and the LoRA
adaptation acts as a residual adjustment.
At the start of training, the matrix A is typically initialized with a random Gaussian distribution,
while matrix B is initialized with zeros. This ensures that the initial update ΔW=BA is a zero
matrix, so the adapted model's behavior is identical to the base model's at the first step.1 To
stabilize training across different ranks, the output of the LoRA module,
ΔWx, is scaled by a factor, typically rα​, where α is another hyperparameter known as
lora_alpha.1

1.2 Architectural Divergence in Stable Diffusion 2.0

Training a LoRA for an SD2 model is not a simple matter of pointing a standard training script
at a new checkpoint. The architectural changes introduced in SD2 are substantial and require
specific handling in the training pipeline. The two most critical divergences are the change in
the text encoder and the introduction of a new training objective.

1.2.1 The Shift to OpenCLIP: From Private Knowledge to Public Data

The most impactful architectural change in Stable Diffusion 2.0 is the replacement of the text
encoder. Whereas SD 1.x models relied on OpenAI's proprietary CLIP model, SD2 models
utilize the open-source OpenCLIP text encoder. This change has far-reaching consequences
rooted in the underlying training data.
While the CLIP model architecture itself is open-source, the 400 million image-text pairs used
by OpenAI for its training are private and have never been released. This dataset is
understood to contain a wide and diverse range of concepts, including many specific artists,
celebrities, and pop culture references. In contrast, OpenCLIP was trained on a publicly
available dataset, a filtered subset of LAION-5B, which was specifically curated to remove
Not-Safe-For-Work (NSFW) content.
The practical implication of this "data divide" is that the foundational knowledge of the SD2
text encoder is fundamentally different from that of SD1.5. Many users have observed that
SD2 models struggle to generate images of specific artistic styles or well-known individuals
that SD1.5 could render with ease.2 This is not a flaw in the model but a direct consequence of
the different training data. The concepts were simply less prevalent, or absent, in the public
LAION subset compared to OpenAI's private dataset. For a developer creating a LoRA training
extension, this is a critical consideration. A LoRA trained on an SD2 model is not just
"adapting" a concept the model already knows; it may be teaching the model a concept from
a much lower baseline. This necessitates more careful dataset curation, more descriptive
captioning, and often requires training the text encoder's LoRA adapters in addition to the
U-Net's, a step that was sometimes optional for SD1.5.

1.2.2 Epsilon-Prediction vs. v-Prediction: Altering the Training Objective

The second major divergence is in the training objective itself. Most diffusion models,
including Stable Diffusion 1.5, are trained using an epsilon-prediction (or ε-prediction)
objective. In this standard paradigm, the model's U-Net is tasked with predicting the noise, ϵ,
that was added to an image at a specific timestep during the forward diffusion process. The
training loss is typically a Mean Squared Error (MSE) between the model's predicted noise and
the actual noise that was added.
Stable Diffusion 2.0 introduced models trained with an alternative objective known as
v-prediction (e.g., the 768-v-ema.ckpt model). This is not a minor tweak but a complete
re-formulation of the diffusion training target. As detailed in the paper "Progressive Distillation
for Fast Sampling of Diffusion Models," which introduced the v-objective, the model is trained
to predict the velocity (v) of the sample along the probability flow ODE trajectory, rather than
the noise (ε). This v target is a function of both the original image and the noise.
This distinction is paramount for fine-tuning. A model that was pre-trained with a v-prediction
objective must be fine-tuned using a v-prediction loss function. Attempting to fine-tune a
v-prediction model with a standard ε-prediction loss (or vice-versa) will result in training
failure, typically manifesting as a NaN (Not a Number) loss value or completely nonsensical
outputs. Therefore, a robust LoRA training extension for SD2 must be able to detect the type
of base model being used and dynamically switch its loss calculation between the
ε-prediction and v-prediction formulations.

Section 2: Anatomy of a Stable Diffusion WebUI

Extension

To implement a LoRA trainer, it must be packaged as an extension that the AUTOMATIC1111

Stable Diffusion WebUI can recognize and load. This requires a specific file and directory
structure, as well as an understanding of the WebUI's scripting and callback systems.
2.1 Core File Structure and Lifecycle

All WebUI extensions reside in their own dedicated subfolder within the main extensions/
directory of the WebUI installation. The WebUI automatically discovers and loads extensions
from this location upon startup. A well-structured extension for LoRA training should adopt
the following layout:

stable-diffusion-webui/​
└── extensions/​
└── my-sd2-lora-trainer/​
├── scripts/​
│ └── lora_trainer_script.py​
├── install.py​
├── preload.py​
├── javascript/​
│ └── custom.js​
├── style.css​
├── localizations/​
│ └── en.json​
└── metadata.ini​

The role of each key file and directory is as follows:

●​ scripts/: This is the most critical directory. The WebUI executes Python files within this
folder as user scripts. The main logic for the extension, including the UI definition and
the training process, will be housed in a Python file here, such as lora_trainer_script.py.
●​ install.py: This is an optional but highly recommended script that runs once when the
extension is first installed or when the WebUI is launched with the
--update-all-extensions flag. Its purpose is to manage Python dependencies. It can be
used to pip install required libraries like peft, diffusers, or bitsandbytes into the WebUI's
Python virtual environment, ensuring a seamless setup for the end-user without manual
command-line work.
●​ preload.py: This optional script is executed before the WebUI parses its primary
command-line arguments. It provides a hook to add new, extension-specific
command-line arguments to the WebUI's launcher.
●​ javascript/: Contains any custom JavaScript files that need to be loaded with the
WebUI's front end. This can be used for dynamic UI behaviors not achievable with
Gradio alone.
●​ style.css: A standard CSS file for applying custom styles to the extension's UI elements,
allowing for better visual integration and branding.
●​ localizations/: This directory holds JSON files for UI localization, enabling the
 translation of interface text into different languages.
●​ metadata.ini: An optional configuration file that can define a canonical name for the
extension and specify dependencies on other extensions, ensuring proper load order
and functionality.

2.2 Scripting and Integration Hooks

The integration of the extension's functionality into the WebUI is managed through specific
Python classes and callback mechanisms.
The primary Python file in the scripts/ directory must define a class that inherits from
modules.scripts.Script. This class serves as the main entry point for the extension's logic.
While this approach is suitable for simple scripts that appear in the "Scripts" dropdown menu
on the txt2img and img2img tabs, a complex function like LoRA training warrants a more
prominent and organized user interface.
For this purpose, creating a new top-level tab is the preferred method. This is achieved not
through the Script class directly, but by using the WebUI's callback system. Specifically, the
on_ui_tabs callback from modules.call_callbacks allows an extension to add a new tab to the
main interface. A function is registered with this callback, and when called, it receives a list of
the existing UI tabs. The function then constructs its own UI using a Gradio Blocks context and
returns it as a tuple containing the Gradio block, a string for the tab's title, and a unique
identifier. This creates a clean, dedicated space for the LoRA trainer, separate from the main
image generation workflows.
Even when creating a new tab, it is good practice to maintain a class structure inheriting from
modules.scripts.Script to organize the code. The key methods within this class that would be
implemented are:
●​ title(): Returns the display name of the script. While less relevant for a dedicated tab,
it's a required method of the base class.
●​ ui(is_img2img): This method is where the Gradio UI components are defined. For a
dedicated tab, the logic from this method would be moved into the function registered
with the on_ui_tabs callback.
●​ run(p, *args): This method contains the core backend logic that is executed when the
user initiates the process (e.g., clicks the "Start Training" button). The p argument is a
StableDiffusionProcessing object (less relevant for a training script), and *args captures
the values from the various Gradio UI components defined for the extension.

Section 3: Designing the User Interface with Gradio

The user interface (UI) is a critical component of the extension, serving as the bridge between
the user and the complex training backend. Since the AUTOMATIC1111 WebUI is built entirely
on the Gradio Python library, a solid understanding of Gradio is essential for creating a
functional and intuitive UI.

3.1 Principles of Gradio in the WebUI

For a sophisticated application like a LoRA trainer, the gradio.Blocks class is the appropriate
tool. Unlike the simpler gradio.Interface, which automatically generates a UI from a function,
gr.Blocks provides a low-level, fully customizable canvas. It allows for precise control over the
layout, visibility, and interactivity of each component, which is necessary for organizing the
numerous parameters involved in LoRA training.
To maintain consistency with the WebUI's existing design and to enhance usability,
parameters should be logically grouped using Gradio's layout elements. A recommended
structure would involve gr.Tabs to separate different training modes (if any), gr.Row and
gr.Column to align components, and gr.Accordion to collapse and hide advanced or less
frequently used settings. For example, a primary section could contain the essential paths for
the model and dataset, followed by collapsible accordions for "Training Parameters," "LoRA
Parameters," and "Advanced Settings."

3.2 Building the LoRA Training Tab: UI Component Mapping

The following table details the essential Gradio components for the LoRA training UI. It maps
each visual element to its corresponding backend parameter and explains its specific
importance in the context of training on Stable Diffusion 2.0 models. This table serves as both
a design blueprint and a developer checklist, ensuring that all critical options are exposed to
the user.
UI Component (Gradio) Label Purpose & SD2 Specificity &
Corresponding Rationale
Backend Parameter
gr.Dropdown Base Model Select the base .ckpt Critical. The user must
Checkpoint or .safetensors file select an SD2 model.
from the The backend should
models/Stable-Diffusio ideally verify the model
n directory. architecture upon
selection.
gr.Checkbox v2 Model Flags the model as a Essential. If this is not
Stable Diffusion 2.x checked for an SD2
architecture. This is a model, the wrong text
crucial switch that tells encoder will be loaded,
the backend to load leading to immediate
the OpenCLIP text training failure or
encoder instead of the nonsensical results.
 SD1.x CLIP encoder.
Corresponds to the
--v2 flag in kohya_ss
scripts.3
gr.Checkbox v_parameterization Enables the Essential for
v-prediction loss v-models. A mismatch
objective. This must between this setting
only be checked if the and the model's native
selected base model is training objective will
a v-prediction model cause the loss to
(e.g., 768-v-ema.ckpt). become NaN and the
Corresponds to the training to fail.
--v_parameterization
flag.3
gr.Textbox Image/Dataset Specifies the path to -
Directory the folder containing
the training images.
The folder should be
structured with
sub-folders like
10_myconcept to
define repeats and
class.
gr.Checkbox Train Text Encoder Determines whether to Highly
inject and train LoRA Recommended for
matrices in the text SD2. Due to
encoder's attention OpenCLIP's different
layers. The U-Net LoRA knowledge base
is almost always compared to SD1.5's
trained. CLIP, training the text
encoder is often vital
for the model to
properly learn and
associate new
concepts with their
trigger words.
gr.Slider Network Rank (dim) Sets the rank r of the -
LoRA matrices. Higher
ranks allow for more
complex adaptations
but increase file size
and VRAM usage.
 Common values range
from 4 to 128.
gr.Slider Network Alpha The scaling factor for -
the LoRA's output. It
modulates the strength
of the adaptation. A
common heuristic is to
set alpha to half of the
rank or simply to 1.
gr.Textbox Learning Rate Sets the learning rate -
for the optimizer. LoRA
training can often
tolerate higher learning
rates than full model
fine-tuning (e.g., 1e-4).
gr.Dropdown Optimizer Allows the user to -
select the optimization
algorithm. Popular
choices available in
training scripts like
kohya_ss include
AdamW8bit (for
memory efficiency),
Lion, and AdaFactor.
gr.Number Number of Epochs Defines the total -
number of times the
training process will
iterate over the entire
dataset.
gr.Number Batch Size The number of images -
to be processed in a
single training step.
This directly impacts
VRAM usage.
gr.Textbox Output LoRA Name Specifies the filename -
for the final trained
LoRA, which will be
saved as a .safetensors
file.
gr.Button Start Training The primary action -
button that triggers
the backend run
 method to begin the
training process.
gr.Textbox Status/Log Output A non-interactive (or -
interactive=False)
textbox used to display
real-time progress,
loss values, and any
error messages from
the training script,
providing crucial
feedback to the user.

Section 4: Implementing the LoRA Training Backend

With the UI defined, the next step is to implement the backend Python code that takes the
user's settings and executes the LoRA training process. This involves managing
dependencies, preparing data, loading the correct model components, injecting the LoRA
layers, running the training loop with the appropriate loss function, and saving the final
artifact.

4.1 Environment and Dependency Management (install.py)

To ensure the extension works out-of-the-box, an install.py script should be included to

handle dependencies. This script leverages the WebUI's launch module to install packages
into its dedicated environment. This prevents conflicts and absolves the user from manual
setup.

Python

# Example install.py​
import launch​
​
# A list of required packages for LoRA training​
required_packages =​
​
for pkg in required_packages:​
if not launch.is_installed(pkg.split('==')):​
 launch.run_pip(f"install {pkg}", f"Requirement for SD2 LoRA Trainer: {pkg}")​
​

This script checks if each package is installed and, if not, uses launch.run_pip to install it,
providing a descriptive message in the console. The peft library is particularly crucial as it
provides the core functionality for LoRA injection.

4.2 Data Preparation and Configuration

The training script must expect the dataset to be structured in a specific way. A common and
effective convention, used by tools like kohya_ss, is a root directory containing subfolders
named in the format [repeats]_[class]. For example, a folder named 20_mycharacter tells the
trainer to use the images within it, repeat each image 20 times per epoch, and associate them
with the class "mycharacter" for regularization purposes.
Captioning is equally important. Each image file (e.g., image01.png) should have a
corresponding text file (image01.txt) containing a description. When training a LoRA, the goal
is to associate a unique trigger word with the new concept. Therefore, the captions should
describe the variable elements of the image (pose, background, lighting) but should omit the
trigger word and the core, defining features of the subject. These omitted features are what
the LoRA will learn to associate with the trigger word when it is present in the prompt during
inference.

4.3 The Training Loop Logic (run method)

The run method of the script class is the engine of the extension. It orchestrates the entire
training process based on the UI inputs.

4.3.1 Loading the SD2 Model and Text Encoder

The first step within the run method is to load the correct model components. This is where
the v2 checkbox from the UI becomes critical. If checked, the script must load the model
using a configuration appropriate for Stable Diffusion 2.0, which crucially involves loading the
OpenCLIP-ViT/H text encoder and its corresponding tokenizer. If unchecked, it would fall back
to the SD1.x standard of a CLIP ViT-L/14 encoder.

4.3.2 Injecting LoRA Layers with PEFT

Once the base models (U-Net and text encoder) are loaded, the LoRA layers are injected
using the peft library. This process is a common point of failure if not configured correctly. The
developer must know the names of the specific modules within the model architecture to
which the LoRA matrices should be applied.
1.​ Create LoraConfig: A peft.LoraConfig object is instantiated, taking parameters from
the UI such as r (rank), lora_alpha, and target_modules.5
2.​ Specify target_modules: This is the most critical parameter. For the Stable Diffusion
U-Net, this is typically a list of strings like ['to_q', 'to_v', 'to_k', 'to_out.0'], targeting the
query, key, value, and output projection layers of the cross-attention blocks. If the text
encoder is also being trained, its specific attention module names must also be
included. An incorrect or incomplete list will result in a LoRA that does not train properly
because the trainable weights were never injected into the correct layers.
3.​ Add Adapter: The model.add_adapter(lora_config) method is called on both the U-Net
and, if selected, the text encoder to perform the injection.5

4.3.3 Executing the Training Process

The training loop itself is managed using Hugging Face's accelerate library, which simplifies
handling mixed-precision (like fp16) and multi-GPU training without extensive boilerplate
code.
The core of the loop is the loss calculation, which must be conditional based on the
v_parameterization UI checkbox.

Python

# Pseudocode for the conditional loss calculation within the training loop​
import torch.nn.functional as F​
​
# model_pred is the output of the U-Net​
# noise is the random noise added to the latents​
# latents is the noisy latent at the current timestep​
# scheduler is the noise scheduler (e.g., DDPM)​
​
if v_parameterization_from_ui:​
# For v-prediction models, the target is the velocity 'v'.​
# The scheduler provides a method to compute this target.​
target = scheduler.get_velocity(latents, noise, timesteps)​
else:​
# For standard epsilon-prediction models, the target is the noise itself.​
target = noise​
​
# The loss is the mean squared error between the model's prediction and the target.​
loss = F.mse_loss(model_pred, target, reduction="mean")​
​
# Backpropagate the loss​
accelerator.backward(loss)​

This conditional logic is the key to correctly supporting both types of SD2 models and
avoiding the common NaN loss issue. The remainder of the loop involves the standard steps
of stepping the optimizer and the learning rate scheduler.

4.4 Saving the Trained LoRA

After the training loop completes, the final step is to extract and save only the trained LoRA
weights. The PEFT library simplifies this. The resulting weights should be saved in the
.safetensors format. This format is the modern standard, offering security against arbitrary
code execution vulnerabilities present in the older pickle format (.pt or .ckpt files) and
providing faster loading times. The saved file will be placed in the models/Lora directory,
making it immediately available for use in the WebUI.

Section 5: Practical Guide and Best Practices

This section translates the preceding technical details into a practical, step-by-step workflow
and provides expert recommendations for achieving high-quality training results with Stable
Diffusion 2.0 models.

5.1 A-to-Z Implementation Walkthrough

1.​ Setup: Create a new folder for your extension inside the
stable-diffusion-webui/extensions/ directory.
2.​ Structure: Populate the folder with the necessary files: install.py for dependencies and
a scripts/ folder containing your main Python script.
3.​ Dependencies: Write the install.py script to automatically install peft, diffusers,
accelerate, and bitsandbytes.
4.​ UI Development: In your main script, use the on_ui_tabs callback to create a new tab.
Within the callback function, use gr.Blocks to design the UI, adding all the components
detailed in Section 3.2, including the critical v2 and v_parameterization checkboxes.
5.​ Data Preparation: Organize your training images into a folder with the [repeats]_[class]
naming convention (e.g., 30_newstyle). Write corresponding .txt caption files for each
image, describing their content without mentioning the core concept or trigger word.
6.​ Backend Logic: Implement the run method that is triggered by the "Start Training"
 button. This method will:
○​ Read all values from the Gradio UI components.
○​ Load the specified SD2 base model, making sure to load the OpenCLIP encoder
based on the v2 flag.
○​ Create a peft.LoraConfig with the correct target_modules for the U-Net and Text
Encoder.
○​ Inject the LoRA adapters into the models.
○​ Set up the data loader, optimizer, and accelerate.
○​ Execute the training loop, using the conditional loss function to switch between
epsilon-prediction and v-prediction.
○​ Log progress to the UI's status textbox.
7.​ Save Output: Upon completion, save the extracted LoRA weights as a .safetensors file
in the models/Lora directory.
8.​ Test: Restart the WebUI, navigate to your new training tab, fill in the parameters, and
start a training run. After it finishes, test the resulting LoRA in the txt2img tab.

5.2 Parameter Tuning for SD2 LoRA

Achieving optimal results requires careful tuning of several key hyperparameters.

●​ Learning Rate: A good starting point for the U-Net learning rate is often 1e-4. Since the
text encoder is more sensitive, a slightly lower rate, such as 5e-5 or 2e-5, is
recommended if it is being trained.
●​ Rank and Alpha: The network rank (r) determines the LoRA's capacity. For simple styles
or objects, a low rank of 8-16 may suffice. For complex characters with varied
appearances, a higher rank of 32, 64, or even 128 might be necessary. The network
alpha (α) scales the LoRA's influence. A common practice is to set alpha to half the rank
(e.g., rank=32, alpha=16) or to set alpha=1 for maximum simplicity. A higher alpha
relative to the rank can lead to stronger but potentially more overfit results.
●​ Optimizer Choice: While AdamW is a standard, using AdamW8bit from the
bitsandbytes library can significantly reduce VRAM usage with minimal impact on
quality. More advanced optimizers like Lion or AdaFactor may yield different results and
are worth experimenting with.
●​ Dataset Size and Epochs: The total number of training steps is a crucial factor. A
general rule of thumb is to aim for approximately 100-200 steps per training image. For
a dataset of 20 images, this would mean 2000-4000 total steps. The number of epochs
can then be calculated based on this target. For example, with 20 images and
repeats=10, one epoch is 200 steps. To achieve 2000 total steps, you would set the
number of epochs to 10.

5.3 Troubleshooting Common Issues

 ●​ OutOfMemoryError: This is the most common issue. To resolve it, try the following in
order: reduce the Batch Size to 1; enable Gradient checkpointing in the training options;
use an 8-bit optimizer like AdamW8bit; reduce the Network Rank; or, as a last resort, use
WebUI command-line arguments like --lowvram or --medvram.
●​ NaN Loss: A loss value that becomes NaN almost always indicates a fundamental
mismatch in the training configuration. The most likely cause is checking the
v_parameterization box for a standard epsilon-prediction model, or vice-versa. It can
also be caused by a learning rate that is too high, leading to numerical instability.
●​ Overfitting: Signs of overfitting include the LoRA generating the exact training images,
a loss of stylistic flexibility, or "burnt" and overly contrasted outputs. To mitigate this,
reduce the number of epochs or total training steps, lower the learning rate, add more
variety to the training data, or use regularization techniques like network dropout.
●​ LoRA Has No Effect: If the trained LoRA does not seem to influence the generated
image, the cause is likely one of the following: (1) The target_modules in the LoraConfig
were specified incorrectly, so no weights were actually trained. (2) The text encoder was
not trained, and the concept was too alien for the base model to learn through the
U-Net alone. (3) The trigger word used in the prompt during inference does not match
the concept trained.

Section 6: Conclusion and Future Directions

This document has provided a comprehensive technical guide for implementing a LoRA
training extension for Stable Diffusion 2.0 models within the AUTOMATIC1111 WebUI. The
analysis has underscored that successful implementation hinges on addressing the unique
architectural characteristics of SD2: the shift to the OpenCLIP text encoder and the
introduction of the v-prediction training objective. By correctly structuring the extension,
designing an intuitive Gradio interface that exposes these critical options, and implementing a
backend that conditionally handles different model types using the peft library, developers
can create a powerful and robust tool for the community.
The core takeaways are the necessity of a dual-path logic for both model loading (CLIP vs.
OpenCLIP) and loss calculation (ε-prediction vs. v-prediction), the critical importance of
correctly specifying target_modules for LoRA injection, and the value of providing users with
clear, actionable feedback through a well-designed UI.
The principles and techniques outlined here serve as a strong foundation for future
development. As the generative AI landscape continues to evolve, these methods can be
adapted to support more advanced PEFT techniques like LoCon or LoHa, which apply
low-rank adaptations to more layer types. Furthermore, new foundational models like Stable
Diffusion XL and Stable Diffusion 3 introduce their own architectural complexities, such as the
use of multiple text encoders simultaneously. A developer equipped with the understanding of
how to dissect and accommodate the architectural nuances of SD2 will be well-prepared to
tackle these future challenges, ensuring that powerful fine-tuning capabilities remain
accessible to the broader user base.

Bibliografia

1.​ arXiv:2106.09685v2 [cs.CL] 16 Oct 2021, accesso eseguito il giorno giugno 17,
2025, https://arxiv.org/abs/2106.09685
2.​ Stable Diffusion 1 vs 2 - What you need to know - AssemblyAI, accesso eseguito il
giorno giugno 17, 2025,
https://www.assemblyai.com/blog/stable-diffusion-1-vs-2-what-you-need-to-kn
ow/
3.​ GitHub - kohya-ss/sd-scripts, accesso eseguito il giorno giugno 17, 2025,
https://github.com/kohya-ss/sd-scripts
4.​ sd-scripts/train_network.py at main · kohya-ss/sd-scripts · GitHub, accesso
eseguito il giorno giugno 17, 2025,
https://github.com/kohya-ss/sd-scripts/blob/main/train_network.py
5.​ LoRA - Hugging Face, accesso eseguito il giorno giugno 17, 2025,
https://huggingface.co/docs/diffusers/main/training/lora