LoRA Adapter Size in MB: Picking Rank for Edge

LoRA adapters are becoming the standard way to customize AI models for specific domains, and increasingly the standard deployment interface for AI hardware. But not all LoRA adapters are created equal. The adapter you train for a cloud GPU with 80 GB of VRAM is not the adapter you should deploy to a phone with 4 GB of AI budget.

This guide covers how to optimize LoRA adapter architecture for edge hardware constraints: how rank, target modules, and training decisions affect adapter size, inference speed, and output quality.

LoRA Adapter Anatomy

A LoRA adapter works by adding two small matrices (A and B) to specific layers of the base model. Instead of modifying the original weight matrix W directly, LoRA computes:

W' = W + (B × A)

Where:

• W is the frozen base model weight (stays in the base model, not in your adapter)
• A is a matrix of shape (original_dim × rank)
• B is a matrix of shape (rank × original_dim)
• rank (r) controls how much information the adapter can encode

The adapter file contains only the A and B matrices for each targeted layer. The base model stays frozen.

Three levers control adapter size and quality:

1. Rank (r): How many dimensions the adapter has. Higher rank = larger adapter = more expressive.
2. Target modules: Which layers of the model get adapter matrices. More layers = larger adapter = broader adaptation.
3. Alpha (α): A scaling factor that controls how strongly the adapter influences the base model. Typically set to 2× rank.

Rank: The Primary Size-Quality Lever

Rank is the single most important parameter for edge optimization.

The practical insight: For most domain-specific tasks (classification, extraction, Q&A, structured output), r=16 captures the vast majority of fine-tuning benefit. Going from r=16 to r=64 typically yields less than 2% accuracy improvement while quadrupling adapter size.

For edge deployment, start with r=8 or r=16. Test quality. Only increase rank if quality is insufficient.

Diminishing Returns Are Real

Research consistently shows that LoRA's effectiveness per parameter drops as rank increases. The first 8 dimensions of the adapter capture the most important adaptations. Dimensions 9-16 capture refinements. Dimensions 17-64 capture progressively more subtle patterns.

For a task like "classify customer support tickets into 10 categories," r=8 is often sufficient. For a task like "generate legal contract clauses in a specific firm's style," r=32 may be needed to capture the stylistic nuance.

Target Modules: The Breadth-Depth Tradeoff

Beyond rank, you choose which model layers receive adapter matrices. The two common approaches:

Attention Only (Default)

Apply LoRA to the query (q_proj), key (k_proj), value (v_proj), and output (o_proj) projection matrices in the attention mechanism.

Adapter size: Smaller (attention layers are a fraction of total parameters) Quality: Good for most tasks, especially those involving attention pattern changes (what the model "focuses on") Best for edge: This is the go-to for memory-constrained deployments

All Linear Layers

Apply LoRA to attention projections AND the feed-forward network layers (gate_proj, up_proj, down_proj).

Adapter size: roughly 3x larger than attention-only Quality: Better for tasks requiring deep knowledge adaptation (terminology, domain facts, output format) Best for: Production deployments where quality is prioritized over size

The Hybrid Approach

For edge optimization, a smart middle ground:

• Apply LoRA at r=16 to attention layers (small, captures attention patterns)
• Apply LoRA at r=8 to feed-forward layers (captures knowledge, at lower rank)

This gives you broad adaptation without the full size cost of high-rank everywhere. Ertas lets you configure target modules visually when setting up a fine-tuning run.

Adapter Size Estimation

Before you train, estimate your adapter size to confirm it fits your edge target:

Formula:

Size ≈ 2 × rank × layer_dim × num_target_layers × bytes_per_param

For a typical 8B model (4096-dim) with LoRA on attention (4 layers per transformer block, 32 blocks):

• r=8: ~2 × 8 × 4096 × 128 × 2 bytes ≈ 16 MB
• r=16: ~2 × 16 × 4096 × 128 × 2 bytes ≈ 32 MB
• r=32: ~2 × 32 × 4096 × 128 × 2 bytes ≈ 64 MB

Those figures are attention-only, and they run a little high because the shortcut treats the key and value projections as full-width. On a grouped-query model like Llama 3.1 8B, where key and value project to 1024 rather than 4096, the exact attention-only figures are closer to 14 MB, 27 MB and 55 MB. Targeting all the linear layers multiplies this by roughly 3, because the feed-forward matrices are far wider than the attention ones, which is how you get the table at the top of this article.

These are small numbers. Even r=32 on all layers fits comfortably in any deployment target: the constraint is more about inference speed than storage.

What Rank Costs You at Inference

Whether rank affects inference speed at all depends on one decision you make at export time.

Merged adapters are free. Folding the adapter back into the base weights, W' = W + BA, produces a model with exactly the same shape and layer count as the original. Rank leaves no trace in the merged weights, so an r=64 merge runs at precisely the speed of an r=4 merge, and both run at the speed of the untuned base. This is what a GGUF export does, and it is why the size table above is a storage question rather than a latency one for most edge deployments.

Unmerged adapters cost you per token. Keeping A and B separate means every targeted module does two extra small matrix multiplies on every forward pass. The extra arithmetic is minor next to the base model's. What actually costs you is memory traffic: decoding a token is bandwidth-bound, and the adapter weights are additional reads competing for the same bandwidth. That is the cost the r=32 note above is pointing at.

Two consequences worth planning around:

• Target-module count matters more than rank. Doubling rank doubles the size of each extra matmul. Going from attention-only to all linear layers roughly triples the number of them, and adds the widest matrices in the block. If you are keeping adapters unmerged and latency is tight, cut target modules before you cut rank.
• Merge unless you need to swap. The reason to stay unmerged is runtime specialisation: one base model in memory, many adapters swapped per request or per tenant. That is a real architecture and it is what the dedicated-silicon and multi-tenant cases below are built on. If you ship one specialisation per binary, merge it and stop thinking about rank entirely.

Edge Hardware Constraints

Different edge targets have different bottlenecks:

Dedicated Silicon (Taalas HC1)

Constraint: On-chip SRAM for adapter weights Recommendation: r=8 to r=16, attention-only. The base model is hardwired; adapter weights load into fast SRAM. Keep adapters small for rapid swapping between specializations.

Smartphones / Tablets

Constraint: Memory budget (2-6 GB for AI), battery life Recommendation: r=4 to r=8, attention-only, on a small base model (3B or smaller). Consider LoRA-Edge techniques for extreme compression.

Apple Silicon Macs

Constraint: Unified memory (shared with OS and apps) Recommendation: r=16 to r=32, all linear layers acceptable. Apple Silicon has enough memory for larger adapters. Optimize for quality, not size.

Consumer GPUs

Constraint: VRAM (8-24 GB, shared with base model and KV cache) Recommendation: r=16 to r=32, all linear layers. GPU VRAM is the bottleneck, but adapter size is tiny compared to the base model. The adapter's contribution to total memory is marginal.

Edge Servers / Industrial

Constraint: Often generous memory, but reliability and swap speed matter Recommendation: r=32, all linear layers. Optimize for quality. If serving multiple clients, keep adapters at r=16 to enable more simultaneous adapter slots.

Quality Validation for Edge Adapters

A smaller adapter trades potential quality for deployment fitness. You must validate that the trade-off is acceptable.

Build an Eval Dataset First

Before training any adapter, build an evaluation dataset of 50-100 representative inputs with expected outputs. This is your quality benchmark. See our guide on building eval datasets from real conversations.

Compare Adapter Variants

Train the same dataset at r=8, r=16, and r=32. Run all three through your eval dataset. If r=8 and r=16 score within 2-3% of each other, deploy r=8 to the edge; the quality difference won't matter in production.

Ertas supports running multiple fine-tuning experiments in parallel and comparing results side-by-side on the canvas, making this comparison straightforward.

Test at Target Quantization

Your eval should test the adapter on the quantized base model, not the full-precision version. A small adapter on a Q4_K_M base model behaves differently than the same adapter on F16. Always validate on the stack you'll actually deploy.

The Multi-Adapter Strategy

For agencies and SaaS products deploying to edge hardware, the optimal pattern is a library of task-specific adapters:

Base adapter (r=16): General domain knowledge. Loaded once when the device boots.

Task adapters (r=8): Specific capabilities (classification, extraction, generation, tool-calling). Swapped in as needed.

Client adapters (r=8): Per-client customizations on top of the base. Only relevant for multi-tenant agency deployments.

This layered approach keeps each individual adapter small while achieving deep specialization through composition. The total memory footprint is the base model + one or two small adapters, well within edge constraints.

Getting Started

1. Decide your target hardware and its memory budget
2. Start with r=16, attention-only (the safe default)
3. Fine-tune on Ertas: configure rank and target modules visually
4. Export and test on target hardware
5. If quality is sufficient, try r=8; smaller adapters swap faster and leave more memory for context
6. If quality is insufficient, try all linear layers before increasing rank

The adapter you optimize for edge deployment today works on any hardware that supports the base model + LoRA, from a phone to a dedicated inference chip. Invest in getting the adapter right, and the deployment target becomes interchangeable.

References: LoRA-Edge: Tensor-Train-Assisted LoRA for Edge Devices, Index.dev: LoRA vs QLoRA 2026.