Imagine your iOS medical consultation app needs to answer specific questions using a large language model. Full fine-tuning of Llama 3 8B would require an A100 cluster with 80 GB of VRAM and several days of training. But there's LoRA — Low-Rank Adaptation. It freezes the original weights and trains compact adapter matrices. A single A100 40GB handles it in hours, and the adapter weighs 50–300 MB instead of 16 GB. GPU rental savings reach 70–90%, which at a typical A100 rental cost of ~$1.5/hour translates into tens of thousands of dollars saved per project. We use this method for dozens of mobile projects — from legal chatbots to content generation.
Technical Aspects of LoRA
Principle of Operation
The original weight matrix W of size d × k remains unchanged. Instead, we train two low-rank matrices: A (size d × r) and B (size r × k), where r is the adaptation rank (usually 8–64). During inference, we compute: W_new = W + α · (A × B), where α is the scaling coefficient.
Key hyperparameters:
-
r(rank) — higher values mean more trainable parameters.r=16is a reasonable start. -
lora_alpha— typically equal to2rorr. Controls adaptation strength during merging. -
target_modules— which layers to adapt. For transformers:q_proj, v_proj, k_proj, o_projand optionallygate_proj, up_proj, down_proj. -
lora_dropout— regularization, 0.05–0.1 for small datasets.
| Rank (r) | Adapter Parameters | VRAM with QLoRA (4bit) | Recommended Application |
|---|---|---|---|
| 8 | ~0.5% of base | ~5.5 GB (8B) | Simple classification |
| 16 | ~1% | ~5.8 GB (8B) | Text generation |
| 32 | ~2% | ~6.3 GB (8B) | Instruction tasks |
| 64 | ~4% | ~7.2 GB (8B) | Complex scenarios |
Why LoRA Over Full Fine-Tuning?
Full fine-tuning requires enormous resources and time, with checkpoints tens of gigabytes large. LoRA delivers the same task-specific adaptation capability at a fraction of the cost. For mobile apps, this is especially important — you can iteratively improve the model quickly without downtime or retraining the entire base. This approach is described in the work QLoRA: Efficient Finetuning of Quantized Language Models.
Dataset Preparation and Training
Data Collection and Augmentation
Collect 300 to 500 labeled examples in "instruction → response" format. For domain adaptation (e.g., legal consultation), relevant, noise-cleaned dialogues are needed. We use synthetic augmentation via GPT-4 and manual quality checks. The dataset is split into train/validation (80/20) and tokenized with max_seq_length=2048.
QLoRA with Unsloth
Unsloth speeds up LoRA training by 2–5x compared to vanilla PEFT through custom CUDA kernels:
from unsloth import FastLanguageModel
import torch
model, tokenizer = FastLanguageModel.from_pretrained(
model_name="unsloth/Meta-Llama-3.1-8B-Instruct",
max_seq_length=2048,
dtype=torch.float16,
load_in_4bit=True # QLoRA: 4-bit quantization + LoRA
)
model = FastLanguageModel.get_peft_model(
model,
r=16,
target_modules=["q_proj", "v_proj", "k_proj", "o_proj",
"gate_proj", "up_proj", "down_proj"],
lora_alpha=32,
lora_dropout=0.05,
bias="none",
use_gradient_checkpointing="unsloth"
)
QLoRA is LoRA applied on top of 4-bit quantization of the base model. Llama 3 8B in 4-bit takes ~5 GB VRAM instead of 16 GB in fp16. Minimum GPU for QLoRA training is an RTX 3090 (24 GB) or a rented A100.
Integration: Server-Side or On-Device?
Server-Side Deployment (vLLM/Ollama)
After training, the adapter is saved separately from the base model. The base model is loaded on the server, and the adapter is applied at initialization or runtime. The mobile app interacts with an API endpoint — no model burden on the device.
# vLLM with LoRA adapter
vllm serve meta-llama/Llama-3.1-8B-Instruct \
--enable-lora \
--lora-modules my-adapter=/path/to/lora/adapter
On-Device (llama.cpp/Core ML)
If minimal latency, offline operation, or data privacy is required, consider on-device deployment. This is suitable for models up to 3B parameters with a LoRA adapter merged into GGUF Q4_K_M. For larger models or complex tasks, server-side deployment is preferable.
| Characteristic | Server-Side (vLLM/Ollama) | On-Device (llama.cpp/Core ML) |
|---|---|---|
| Latency | 100–500 ms (network) | 10–50 ms (local) |
| Device requirements | Any with internet | iPhone 14+ / Galaxy S23+, 6+ GB RAM |
| Model size on device | Not stored | 2–3 GB (GGUF Q4_K_M) |
| Adapter update | Instant | Requires app update |
| Infrastructure cost | GPU rental | Free after deployment |
On-device via llama.cpp / Core ML is only possible for small models with weight merging (merge + GGUF). For mobile devices, feasible options: Llama 3.2 3B or Phi-3.5-mini 3.8B with a LoRA adapter merged into GGUF Q4_K_M. The resulting model size is 2–3 GB, fitting within iPhone 14+ and Galaxy S23+ capabilities.
# Merging weights before export to GGUF
merged_model = model.merge_and_unload()
merged_model.save_pretrained("./merged-model")
# Next: llama.cpp convert + quantize → .gguf file
On iOS, such a GGUF is run via llama.swift or via MLModel (if converted to Core ML using coremltools). On Android — llama.cpp via JNI or MediaPipe LLM Inference API for Gemma models.
Process and Timeline
Work Stages
- Task analysis and dataset preparation — collection, cleaning, augmentation (1–2 weeks).
- Environment setup — choose base model, install Unsloth, PEFT (1–2 days).
- QLoRA training — run training on GPU with 4-bit quantization (from a few hours to 2 days).
- Adapter conversion — weight merging, quantization to GGUF (2–3 days).
- Integration into the app — server API via vLLM or on-device via Core ML/llama.cpp (2–4 days).
- Testing and optimization — quality checks, latency tuning, refinements (3–5 days).
Estimated Timeline
Dataset preparation — 1–2 weeks. Setup and training — 1–2 days. Conversion and testing — 2–3 days. Server API integration — 2–4 days. Full cycle — 2 to 4 weeks. Cost is calculated individually based on task complexity.
Common Mistakes and How to Avoid Them
Incorrect target_modules selection. If you adapt only q_proj, v_proj and skip MLP layers, effectiveness drops by 30–50%. For instruction-following tasks, always include gate_proj, up_proj, down_proj.
Too small a dataset. LoRA with 50–100 examples leads to overfitting: the model memorizes examples but does not generalize. A minimum of 300–500 diverse examples is needed.
Base weights not frozen during merging. After merge_and_unload(), verify that original weights haven't changed compared to the base model — this signals correct LoRA operation.
What We Offer
Service Scope
- Task analysis and dataset preparation (collection, cleaning, augmentation)
- Environment setup and training launch (Unsloth + PEFT, QLoRA)
- Adapter conversion (merge, quantization to GGUF)
- Integration: server API (vLLM/Ollama) or on-device (Core ML/llama.cpp)
- Performance testing and optimization
- Documentation and training for your team
We guide the project through all stages and guarantee results. Contact us to evaluate your project and get a consultation. Order a consultation — we will help you integrate an LLM into your mobile app quickly and efficiently.
Guarantees and Experience
- 6+ years of experience in mobile AI solution development
- Over 50 successful LLM fine-tuning projects
- Deep knowledge of the stack: Swift, Kotlin, Flutter, React Native, Unsloth, PEFT
- Individual approach and quality guarantee
Order LoRA adaptation service — and we'll help you integrate an LLM into your mobile app quickly and efficiently.