Every number below is a real file size, read off the Hugging Face API this morning.
Every number below is a real file size, read off the Hugging Face API this morning.
A LoRA file size is set by its rank and by how many layers it was attached to. It tells you nothing whatsoever about what the LoRA learned.
In one popular repository there are two character LoRAs. Different people, different training images, different results. One is 109.06 MB. The other is 109.06 MB.
Not roughly the same. The same, to the hundredth of a megabyte, because file size in a LoRA is a property of the shape of the adapter and not of anything it learned.
Every size on this page was read off the Hugging Face API this morning, so you can check any of them yourself.
A fine tune rewrites the model's weights. A LoRA does not. It leaves the base model alone and stores a small correction alongside it, and the correction is stored in a very specific shape.
For a weight matrix of size d by k, LoRA stores two smaller matrices instead: one of size d by r and one of size r by k, where r is the rank. At generation time those two are multiplied back together and added to the original weight. Pick r of 16 against a 1280 by 1280 attention matrix and you are storing 1280 times 16 twice, which is 40,960 numbers instead of 1,638,400. That is the entire trick.
Two consequences fall straight out of that arithmetic and they explain almost every file size you will ever see.
Double the rank and you double the parameter count, exactly. There is no compression step, no dependence on how varied the training set was, no dependence on how many steps you trained for. A rank 32 LoRA over the same target layers is precisely twice the size of a rank 16 one.
Trainers know this, which is why rank is often written into the filename. One distillation repository publishes four adapters with rank64 in the name:
| File | Size |
|---|---|
| i2v high noise, rank 64 | 605.25 MB |
| i2v low noise, rank 64 | 705.22 MB |
| t2v high noise, rank 64 | 585.10 MB |
| t2v low noise, rank 64 | 585.10 MB |
Same rank on all four. Three different sizes. If rank were the whole story those numbers would be identical, and they are not, which brings us to the second consequence.
A LoRA is not one adapter. It is one adapter per targeted module, and the target list is a choice made at training time. Attach to the attention query and value projections only and you get one file size. Attach to query, key, value and output, plus the feed forward blocks, and you get a much larger one at the same rank.
That is why the four files above differ. Same rank, different numbers of modules wrapped. The 705.22 MB file is not better trained than the 585.10 MB one. It is wider.
The same effect shows up across base models. The LCM technique published for two different bases:
| Adapter | File | Size |
|---|---|---|
| LCM LoRA for SDXL | pytorch_lora_weights.safetensors | 375.61 MB |
| LCM LoRA for SD 1.5 | pytorch_lora_weights.safetensors | 128.39 MB |
Same team, same method, same filename. The SDXL version is 2.93 times larger, because the SDXL UNet is wider and has more attention blocks to attach to. Nothing about the SDXL adapter is smarter. There is simply more model underneath it.
Nothing to the file size, and quite a lot to the output.
Alpha is a scaling term. The adapter's contribution is multiplied by alpha divided by rank before it is added back to the base weight. It is one number in the metadata, it costs no storage, and it decides how loudly the LoRA speaks.
The practical consequence is the one people trip over. If you train at rank 32 with alpha 32, the scale factor is 1. If you then retrain at rank 64 and leave alpha at 32, the scale factor drops to 0.5 and the same training run will look weaker, not stronger, despite the file being twice the size. Raising rank without raising alpha turns the adapter down.
This is why "which rank should I use" has no answer on its own. Rank sets capacity. Alpha over rank sets strength. They have to be discussed together.
Given all of the above, here is the honest list of what you can and cannot infer from a LoRA's size before you download it.
| Question | Can size answer it? |
|---|---|
| Roughly what rank was used | Yes, if you know the base model |
| Roughly how many modules were targeted | Yes, in combination with rank |
| Which base model it is for | Usually, by rough magnitude |
| How strong it will be | No. That is alpha and your own weight setting |
| How well it was trained | No. Nothing in the file records dataset or steps |
| How many images it was trained on | No. Not stored in the tensors at all |
Which is why two portraits of two completely different people land on 109.06 MB apiece. Same rank, same targets, same base. The bytes describe the container, not the contents.
Stop treating a bigger LoRA as a better LoRA. A 400 MB adapter is a wide one, and width mostly buys you the ability to change more of the model at once, which is as often a liability as a feature: a wide, strongly scaled character LoRA is exactly the thing that starts rewriting your backgrounds and your lighting along with your face.
If a LoRA is overpowering everything else in your prompt, lower the weight at load time before you go looking for a different file. If it barely registers, check whether it was trained at high rank with low alpha before assuming the training failed.
And if two files in a listing are the same size to the decimal, that is not a duplicate upload. That is two adapters built to the same shape.