Starting with a misconception
The first thing someone hears when the weights for a model like Gemma 4 are released is "now I can fine-tune it." The next thing they learn is that full fine-tuning of a 27B model on a solo budget is not realistic. You're looking at hundreds of GPU hours on rented cloud infrastructure, numbers that make even research teams hesitate.
That framing, unfortunately, causes people to give up on personalization entirely. But LoRA and QLoRA make "personal customization" of Gemma 4 reachable. I've run both 9B and 27B LoRA / QLoRA training runs for small workflow improvements in my own projects, and it fits on a consumer or modest cloud GPU.
This article is the practical sibling to the many getting-started tutorials that already exist. I won't cover benchmarks. The focus is on the parts that public recipes don't spell out: the data prep details, the evaluation, and the step of turning the finished adapter into something you actually use inside Antigravity.
LoRA / QLoRA — a quick re-centering
LoRA (Low-Rank Adaptation) freezes the original model weights and learns small additive "deltas" on each attention and sometimes feedforward layer. You end up training 0.1%–1% of the parameters of the full model, which collapses memory and compute demands dramatically.
QLoRA extends this by keeping the base weights in 4-bit quantized form while training the LoRA adapters at normal precision. Memory drops further, which is how 70B-class models become possible on a single consumer GPU. For Gemma 4 at 9B or 27B, a consumer card is plenty.
My rough rules for choosing between them:
- A 24GB card (RTX 4090, L4, etc.) handles 9B with plain LoRA comfortably
- 27B typically needs QLoRA even on 24GB
- If inference will run quantized, train with QLoRA so the runtime distribution matches
Data preparation is 80% of the work
Whether fine-tuning works is mostly decided by the data. When people ask me "I followed the recipe but results aren't better," nine times out of ten the dataset is the problem.
Pick the granularity of a single sample
Decide what one training example is. For an instruction-following model like Gemma 4, it's usually one input + one desired output. If either side is excessively long or structurally complex, training gets unstable.
I keep single examples under ~1,500 tokens total, with outputs under ~600 tokens. Beyond that, gradient variance grows and convergence suffers.
Consistency defines the model's new personality
The most important dataset property is consistency. If you're training for summarization, every example should target the same length, same viewpoint selection, same tone. When consistency drifts, the model learns a noisy average and can end up worse than the base Gemma 4.
The lesson I keep relearning: a small, consistent dataset beats a large, inconsistent one. 2,000 coherent examples will beat 10,000 scattered ones.
Synthetic data — useful, but with caveats
You can use Gemini 2.5 Pro or Claude to synthesize training data when you're short on time. It works, but models trained on purely synthetic data inherit the teacher model's stylistic tics and failure modes, which you may not want.
My preferred hybrid: hand-craft about 300 canonical examples, then generate another 1,500 synthetic ones from them. The hand-crafted core defines the target behavior; the synthetic data fills in volume without overwhelming the direction.
Practical training settings
Here are the settings I've arrived at through a few failed runs.
Keep the LoRA rank (r) modest
Rank controls the expressive capacity of your deltas. Higher r learns more complex adjustments but overfits faster. You'll see tutorials with r=64; for a 2,000-example dataset, start at r=8 or r=16.
My rule of thumb: stay at r=16 until your data crosses about 10k examples. Raising r improves learning speed but often hurts generalization.
Learning rate and batch size
A learning rate of 2e-4 with an effective batch size of 16–32 is the safe default for LoRA. QLoRA introduces extra noise from 4-bit quantization of the base — lowering to 1e-4 often stabilizes things.
Start at 3 epochs and watch the validation curve. Instead of complicated early stopping, stop as soon as validation loss starts rising. This simple rule is reliable for small datasets.
Which modules to target
For Gemma-family models, start with q_proj, k_proj, v_proj, o_proj. If capacity allows, add gate_proj, up_proj, down_proj on the FFN side. Extending to FFN often helps with small datasets.
# Rough PEFT config
from peft import LoraConfig
lora_config = LoraConfig(
r=16,
lora_alpha=32,
target_modules=[
"q_proj", "k_proj", "v_proj", "o_proj",
"gate_proj", "up_proj", "down_proj",
],
lora_dropout=0.05,
bias="none",
task_type="CAUSAL_LM",
)Treat these as starting values. r and target_modules should get tuned against your own validation data.
Don't skip evaluation
When training completes successfully, there's a natural urge to declare victory. Resist it. Whether the adapter is actually useful is decided in the evaluation that follows.
Test on inputs not in the training set
Basic but often skipped. Checking outputs for training samples only verifies memorization. Prepare a few dozen held-out inputs and see whether the expected behavior transfers.
Pair-compare with the base Gemma 4
Feed the same prompts to your adapted model and the base Gemma 4, and compare outputs side by side. You'll occasionally find that the adapter has changed the format as intended (correct summary length), but degraded the content choice. Those are failures the training loss wouldn't catch.
Do the comparison blind: hide which output came from which model. It's embarrassingly easy to overrate your own adapter otherwise.
Classify the failures
Collect outputs you didn't like and classify the failure modes: "too long," "ignored instruction," "thin content," and so on. This catalog tells you how to improve the dataset next round.
Fine-tuning rarely finishes in one pass. A few rounds of "classify failures → add examples that directly address them" is the rhythm that actually produces a useful adapter.
Wiring the adapter into Antigravity
Once you have a trained adapter, deploying it usefully is its own design problem. Get this part wrong and the whole effort becomes a training log with no downstream impact.
Deploy the adapter separately from the base
One of LoRA's advantages is deployment flexibility — the base model can be shared, and you swap task-specific adapters (summarization, classification, translation) on the same runtime. I run this under vLLM's LoRA support, which accepts an adapter selector at request time.
Keep the base model loaded once and route tasks to the adapter they need.
Call from Antigravity agents via OpenAI-compatible API
For Antigravity agents, the cleanest integration is exposing your tuned model through an OpenAI-compatible endpoint. vLLM serves this out of the box, and Antigravity can register it as a custom endpoint.
Mixing model sources in an agent workflow — "use the custom model for summarization, Gemini for multimodal, Claude for code" — lets each task hit the best option. The fine-tuned model's role should be the place that needs your voice, your taxonomy, your judgment — things the generic models cannot provide.
Version the adapters
Adapters drift subtly between training runs. Tag each adapter with its dataset and config, and store them together so you can roll back when something regresses.
I use GitHub Releases: the adapter files plus the exact training-config YAML go in as a single release artifact. It's unglamorous, but it makes "take me back to last month's adapter" a one-command operation.
A minimal first loop
Here's the smallest end-to-end cycle for someone starting today.
Week one — dataset only. Hand-craft 200 examples of "how I want Gemma 4 to respond." No synthetic data yet. These 200 examples will anchor everything that follows.
Week two — one training run. Apply LoRA to Gemma 4 9B using just those 200 examples. Start with the defaults listed above: r=16, lr=2e-4, 3 epochs. Training itself is 1–2 hours on a cloud GPU.
Then evaluate carefully. Prepare 30 held-out inputs and compare against the base Gemma 4. If direction is right, grow the dataset with synthetic data. If direction is wrong, rebuild the dataset rather than tuning hyperparameters — redoing the data is usually what improves things.
Run this cycle two or three times and you'll have an adapter that earns its place in your workflow. Going from being a model user to being a model tailor is a quiet shift, but it changes how you relate to AI tooling. Antigravity is a convenient home for the tailored model to live in day to day — I hope this is enough to make the first cycle seem approachable.