LoRA
The paper introduced Low-Rank Adaptation, a parameter-efficient way to adapt pretrained models by freezing the base weights and training low-rank update matrices.
Metadata
| Field | Value |
|---|---|
| Paper | LoRA: Low-Rank Adaptation of Large Language Models |
| Authors | Edward J. Hu, Yelong Shen, Phillip Wallis, Zeyuan Allen-Zhu, Yuanzhi Li, Shean Wang, Lu Wang, Weizhu Chen |
| Year | 2021 preprint; 2022 conference |
| Venue | ICLR 2022 |
| arXiv | 2106.09685 |
| OpenReview | nZeVKeeFYf9 |
| Code | microsoft/LoRA |
| Status | full note started |
One-Line Takeaway
LoRA freezes a pretrained weight matrix and learns a low-rank update:
where:
Only and are trained.
Question
Full fine-tuning updates every parameter:
For a large pretrained model, this is expensive because each task may require storing and optimizing a full copy of the model.
The architecture question is:
LoRA answers by changing the adaptation path, not the pretrained base model.
Main Claim
For large pretrained Transformers, downstream adaptation can be parameter-efficient when the weight updates are constrained to a low-rank subspace.
For a linear layer:
LoRA changes the forward pass to:
Here:
| Symbol | Meaning |
|---|---|
| frozen pretrained weight | |
| trainable down projection | |
| trainable up projection | |
| rank | |
| scaling hyperparameter | |
| update scale |
The durable claim:
Architecture Contract
| Item | Contract |
|---|---|
| Base model | pretrained Transformer or other neural model |
| Frozen weights | original matrix is not updated |
| Trainable weights | low-rank matrices and |
| Insert location | usually attention projections and sometimes MLP projections |
| Forward form | |
| Initialization | commonly random and , so at start |
| Merge option | can be merged for inference |
| Main benefit | far fewer trainable parameters and optimizer states |
| Main risk | rank/location choices limit adaptation capacity |
LoRA is not a new backbone. It is an adaptation block attached to existing backbone layers.
Low-Rank Update
A full update to a matrix:
has:
parameters.
LoRA parameterizes the update as:
with:
The trainable parameter count becomes:
When is small:
This is the core compression.
Forward Pass
For input:
the frozen path is:
The LoRA residual path is:
The output is:
This is a residual adaptation:
Initialization
LoRA commonly initializes:
and initializes randomly.
At step 0:
So the model starts exactly as the pretrained model:
This matters because the adapter path should not destroy pretrained behavior before learning begins.
Where LoRA Is Inserted
In a Transformer attention block:
LoRA can be applied to one or more projection matrices:
The important implementation question is:
Common choices include:
| Target | Effect |
|---|---|
| common efficient setting in the paper | |
| larger adaptation capacity | |
| MLP up/down projections | changes feed-forward transformation |
| embeddings or output head | task/domain specific, less universal |
Merge For Inference
Because LoRA is linear, the update can be merged:
Then inference uses:
This avoids extra inference latency compared with adapter modules that add new nonlinear layers in the forward path.
However, merging has an operational consequence:
| Serving Mode | Tradeoff |
|---|---|
| merged weights | fastest for one task, task-specific checkpoint |
| separate adapters | flexible multi-task serving, extra adapter management |
| hot-swapped adapters | cheap storage per task, runtime routing complexity |
Relation To Full Fine-Tuning
Full fine-tuning updates:
where can be full-rank.
LoRA constrains:
This is a bias:
The bias is useful when:
- the pretrained model already contains most needed capability;
- the task update is small relative to the base model;
- memory and storage matter;
- multiple task-specific variants are needed.
It can fail when:
- the task is far from pretraining;
- rank is too low;
- LoRA is inserted into the wrong layers;
- data requires changing representations that the chosen matrices cannot affect enough.
Relation To Adapters
Adapters usually add bottleneck modules:
LoRA instead modifies existing linear maps with a low-rank residual:
| Axis | Adapter Modules | LoRA |
|---|---|---|
| insertion | new modules between layers | low-rank update inside existing linear layers |
| nonlinearity | often yes | no, linear residual path |
| mergeability | usually not into one original matrix | mergeable into |
| inference latency | can add latency | can be zero after merge |
| capacity | depends on bottleneck and nonlinearity | depends on rank and target matrices |
This is why LoRA is often treated as an architecture component rather than only an optimizer trick.
Relation To Linear Algebra
LoRA is directly connected to low-rank factorization.
If the adaptation update has low intrinsic rank:
then a factorized parameterization:
can represent the important directions with fewer trainable parameters.
The key assumption:
This is not guaranteed by the method. It is a modeling hypothesis that should be checked by rank sweeps and task performance.
Evidence Pattern
The paper supports LoRA with:
| Evidence | What It Supports |
|---|---|
| parameter count comparison | trainable state is much smaller |
| memory comparison | optimizer state and gradients are reduced |
| quality on RoBERTa, DeBERTa, GPT-2, GPT-3 | low-rank updates can match strong baselines |
| rank analysis | adaptation appears rank-deficient in studied settings |
| latency comparison | merged LoRA avoids adapter-style inference overhead |
The important reading point is that LoRA’s value is a three-way claim:
Any one metric alone is incomplete.
Practical Reading Checks
| Question | Why |
|---|---|
| Which matrices receive LoRA? | target location controls adaptation capacity |
| What rank is used? | rank controls parameter count and expressivity |
| What is ? | scaling changes update magnitude |
| Is dropout used on the LoRA path? | affects regularization |
| Are base weights frozen? | otherwise it is not pure LoRA adaptation |
| Are adapters merged at inference? | affects latency and checkpoint semantics |
| Are multiple adapters composed? | composition can change behavior unexpectedly |
| Is the baseline full fine-tuning or another PEFT method? | determines what claim is being made |
Why It Belongs In Architecture Papers
LoRA is not a model family like Transformer or CNN, but it is a reusable architecture-level modification:
It belongs here because many modern papers assume:
- LoRA fine-tuning;
- QLoRA-style quantized base plus LoRA adapters;
- task-specific adapter merging;
- LoRA on attention projections;
- LoRA on diffusion U-Nets or vision models.
Without a LoRA note, later implementation and paper reviews become ambiguous about what actually changed in the model.
Limits
- Low rank can underfit tasks requiring broad weight changes.
- Rank and target module choices are hyperparameters.
- LoRA does not reduce forward activation memory by itself.
- Frozen base model quality is still the main dependency.
- Merging adapters is simple for one task, but multi-adapter serving has operational complexity.
- LoRA can make evaluation misleading if adapter, base, and data provenance are not recorded.
The concise limitation:
What To Remember
- LoRA freezes pretrained weights and trains low-rank residual updates.
- The core equation is .
- Trainable parameter count is instead of .
- It is usually applied to attention projection matrices.
- The update can be merged into the base weight for inference.
- LoRA is an adaptation block, not a replacement for a strong pretrained model.