File sizes and formats

A successful Ertas run produces a LoRA adapter, and optionally a GGUF bundle and a full safetensors model, each with a very different storage profile. The GGUF bundle is hundreds of MB to a few GB, depending on the base model, and is what you ship into an app. The LoRA adapter is tens of MB regardless of base size, and is what you keep as your source of truth. The full safetensors export is the largest, roughly fp16 size, and exists so you can keep training on the model.

This page lays out the size math, gives concrete estimates for the most common catalog models at Q4_K_M, and explains the storage-quota implications. For the upstream story of why GGUF is the shipped format, see GGUF overview. For the size-vs-quality trade-offs the quantization step controls, see Quantization.

What you download

A completed run produces two downloadable bundles in Hub. Both arrive as ZIP files via signed, time-limited download URLs.

The bundles live in Hub independently. Deleting a run record from the Runs tab does not delete the Hub entry; you delete artifacts from Hub directly. See Storage for the full life-cycle picture.

Do not confuse the full safetensors export (a complete 16-bit model, the largest artifact) with the LoRA bundle's adapter_model.safetensors (just the small adapter). The full export is what you continue training from; the adapter is what you re-merge in code. See Safetensors overview for how the three safetensors artifacts relate.

The Q4_K_M sizing rule of thumb

For models in the 3B-and-up range, Q4_K_M lands at roughly 0.6 bytes per parameter, including the K-quant family's per-block scale overhead:

gguf_size ≈ 0.6 * parameter_count   (models 3B and up)

Below 3B parameters, the embedding and unembedding tables (which scale with vocabulary size, not compute parameters) become a larger share of the total file. A 1B-class model with a large vocabulary like Gemma 3 or Llama 3.2 lands closer to 0.8 bytes per parameter; a sub-1B Qwen 2.5 lands closer to 1.0. The "0.6 rule" is the right anchor for the 3B-to-14B models that dominate Ertas fine-tuning, but it underestimates small models.

Other variables that shift the file size by a few percent:

• Which precision-sensitive matrices Q4_K_M keeps at higher precision (architecture-dependent).
• Bundled tokenizer size (Llama and Mistral are compact; Qwen's multilingual and Gemma's 256K-token vocab are larger).
• A small fixed GGUF metadata header.

The ZIP wrapper around model.gguf adds only a few MB for the Modelfile, install scripts, and README.txt. The bundle ZIP is essentially the same size as the model.gguf it contains.

Sizes for common catalog models

The table below lists Q4_K_M model.gguf sizes for the catalogue models. The measured figures are read from published Q4_K_M GGUFs of the corresponding base on Hugging Face, preferring the model's official uploader, plus Ertas's own export of Gemma 4 E2B. Your fine-tuned exports land within a few MB of these numbers.

Sizes marked with ~ are estimates from the parameter count rather than measurements of a published GGUF.

A few notes on the table:

• The "GPU tier to train" column is the gating constraint, not the file-size constraint. Free-plan accounts can train any T4 model on the list (training-time VRAM is a different question than inference-time file size). Two rows break the "under 5B means T4" pattern: Gemma 4 E2B, whose 5.1B total comes from Per-Layer Embedding tables on top of its 2.3B effective compute parameters, and Gemma 3 4B, which is under 5B but cannot train in bf16 on a T4 and falls back to fp32 at roughly double the memory. Both need A10G and a paid plan. Note that Gemma 3 4B still deploys as a 2.49 GB file like any other 4B model; only training is gated.
• The Quickstart bundle for a 3B-class model lands at roughly 2 to 3 GB end-to-end including the Ollama scripts, the README, and ZIP overhead. The figures above are the raw model.gguf; the ZIP is a fraction of a GB larger.
• Small models do not get smaller proportionally. Notice that the 0.5B and 1B rows hover around 0.5 to 0.8 GB, much larger than 0.6 * parameter_count would suggest. The embeddings dominate at this scale. If you are choosing a base for file-size reasons, picking a 1B over a 3B usually saves less space than you expect.
• For models not in this table, the models index carries the full catalog with licenses, notes, and (where measured) GGUF sizes.

LoRA adapter sizes

The LoRA adapter ZIP is dominated by two things: the adapter weights and the bundled tokenizer.

• Adapter weights (adapter_model.safetensors) are typically 10 to 30 MB at the Ertas default of rank 16, scaling roughly linearly with rank and the number of target modules. A rank 64 adapter with the full default target-module set is closer to 60 to 100 MB.
• Tokenizer files (tokenizer.json, tokenizer_config.json) are 1 to 15 MB depending on family.
• Chat template and config files together are under 100 KB.

The 25 to 50 MB total range covers nearly every default-config run. Bumping LoRA rank above 32 or expanding target modules can push the total over 100 MB, but that is the exception.

LoRA adapters are small enough that keeping every one you train indefinitely is a sensible default. The storage cost is negligible compared to the GGUFs, and the LoRA is the artifact you re-merge from when you want to try a different quantization level, swap in a newer base, or audit what changed between training runs.

Storage-quota math

The Free plan gives you 5 GB of model-artifacts storage in Hub. Builder, Pro, and Business plans grant more (see the pricing page for the current per-plan numbers).

Some quick math to make the 5 GB figure intuitive:

If you only need the LoRA for archival and want room for the next GGUF, delete the GGUF from Hub after downloading. You can rerun the same config with Convert to GGUF enabled later if you want the GGUF back.

What's next