LoRA or LoRa? Two Technologies, One Name, Nothing in Common

One is a technique for fine-tuning a neural network on a rented GPU for a few hundred dollars. The other is a radio protocol that gets a battery-powered sensor fifteen kilometres to a gateway on a coin cell.

They are spelled LoRA and LoRa. Case is the only difference. They share no history, no underlying technology, and no purpose.

I'm writing this because I've now watched a conversation about a wearable device go for several minutes with half the room discussing the radio and half discussing the fine-tuning, and nobody noticing. If your project involves both hardware and machine learning — which, increasingly, everything does — this collision is coming for you.

LoRa — the radio

LoRa stands for Long Range. It's a physical-layer modulation scheme, originally from Cycleo and now owned by Semtech, and it exists to solve a specific and difficult problem: getting a tiny amount of data a very long way on almost no power.

The trick is chirp spread spectrum. Instead of transmitting a symbol as a fixed frequency, LoRa sweeps the frequency up or down across the channel — a chirp. A receiver correlating against that known sweep can dig a signal out from below the noise floor. That's the whole magic: you trade data rate for sensitivity, and you get a link budget that ordinary narrowband modulation can't approach.

What that buys, roughly:

Range: a couple of kilometres in a dense city, tens of kilometres with clear line of sight.
Data rate: on the order of 0.3 to 50 kbps. This is not a typo. You are sending a temperature reading, not a photo.
Power: years on a small battery, because the radio is asleep almost all the time.
Bands: unlicensed sub-GHz ISM spectrum — 868 MHz in Europe, 915 MHz in the US, 433 MHz in some regions. Which means regional duty-cycle limits you have to design around.

LoRaWAN is the layer above it — the MAC and network specification maintained by the LoRa Alliance, covering device classes, addressing, join procedures and encryption. In casual speech people say "LoRa" for both, which is a second, smaller ambiguity living inside the first.

Where you'll meet it: utility meters, agricultural sensors, cattle trackers, parking bays, industrial telemetry. Anything that needs to say a few bytes, occasionally, from somewhere annoying, for years.

LoRA — the fine-tuning technique

LoRA stands for Low-Rank Adaptation, from a 2021 paper by Hu et al. at Microsoft. It's a way to specialise a large model without retraining it.

Classic fine-tuning updates every weight in the model. For anything modern that means a long run on serious hardware, and — the part people underestimate — a complete modified copy of the model to store for every domain you adapt to. Ten customers, ten full models.

LoRA takes a different route. It freezes the original model entirely and trains a small correction alongside it.

The insight is in the name. If you wanted to learn a correction to a 1024×1024 weight matrix, that's about a million numbers. But you don't have to learn it as one dense matrix. You can learn two skinny ones — say 1024×8 and 8×1024 — and use their product as an approximation. That's about 16,000 numbers instead of a million, and the "8" is the rank. Low rank, hence the name.

In practice trainable parameters land around 0.1% to 1% of the model.

Why that's enough: adapting a model to a domain is a small change relative to everything it already knows. A speech model that already understands English doesn't need to relearn English to stop mangling drug names. It needs a nudge. A small change admits a small correction, and the low-rank form is a bet that the useful correction lives in a far smaller space than the full weight matrix.

What it buys you:

Cost. Hours on one rented GPU rather than a cluster for days. In the range of a few hundred dollars per run for a small model, not tens of thousands.
A tiny artifact. An adapter is megabytes, against hundreds of megabytes for a full model copy. You ship one base model and a small per-customer download on top. "Your ward's vocabulary, ten megabytes" is a very different conversation than "we trained you a model."
Reversibility. The base model is untouched. A bad adapter is simply not loaded. That's a meaningfully different risk profile from having overwritten your weights.

The analogy I use: classic fine-tuning is rebuilding the engine. LoRA is a tuning chip you plug in — cheap to make, tiny to ship, and removable when it turns out to be wrong.

The third meaning nobody warns you about

There's a wrinkle. In the image-generation world especially, "a LoRA" became a noun.

People say "download this LoRA" or "I'm running three LoRAs" — meaning the adapter file, not the technique that produced it. It's the same drift that turned "a diff" into a thing you email rather than a program you run.

So in the wild, LoRA can mean:

the training technique,
the specific artifact it produces,

and the reader has to work out which from context. Usually easy. Occasionally not, and it's worth knowing that the ambiguity exists rather than assuming you've misunderstood something.

Telling them apart in a meeting

The honest answer is that the domain gives it away immediately, and the only reason this ever confuses anyone is that some projects contain both.

It's the radio if the conversation involves gateways, antennas, spreading factors, duty cycles, battery life, coverage maps, sub-GHz, or LoRaWAN.

It's the fine-tuning if the conversation involves adapters, rank, base models, training runs, GPUs, datasets, or merging.

The one place it genuinely collides is a battery-powered device that does something clever with a model — a wearable, a sensor with on-device inference, anything at the edge. Say "the radio" or "the adapter" once at the start of the meeting and you'll save yourself ten minutes later.

If someone asks about "LoRa in the pendant," they mean the radio. Nobody puts a fine-tuning technique in a pendant.

Two things LoRA doesn't do

Since the technique is the one people are more likely to be sold on, two limits worth having in hand.

It doesn't necessarily give you hot-swappable adapters in production. That's the pitch — one base model, many adapters, switch at runtime — and it's true in a PyTorch serving stack. But if you're running on an embedded inference runtime like ONNX, the usual path is to merge the adapter back into the weights and re-export, which means you ship a merged model per customer rather than swapping adapters live. Still cheap, still small to train. Less elegant than the diagram in the deck.

It fixes vocabulary and style, not physics. This is the one that actually costs people money. If a speech model keeps mangling clinical terms, LoRA is a good answer — that's a vocabulary problem. If the model is failing because the microphone is badly placed and the audio is genuinely hard to hear, no adapter will save you, because the information isn't in the recording. The fix is the hardware, or a bigger model, and you find out which by listening to a week of real recordings before you spend anything on training.

The general form of that, which applies well beyond speech: diagnose what kind of wrong you have before you buy a fix for it. Adapting a model can't add information that never reached it.

So

LoRa gets a few bytes a long way on very little power. LoRA gets a large model to speak your domain for a few hundred dollars and a ten-megabyte file.

They have nothing to do with each other, and the only thing they share is that both are usually the cheap rung on a ladder — the thing to try before you build the expensive version.

Say which one you mean. It costs you one extra word.