Fine-tuning is paid once; retrieval is paid on every request. That difference in shape, not the headline prices, is what decides which is cheaper for you.

Computed from this tool’s default settings — requests per day and the rest as most people start. Change them below for your own case.
At 1,000 requests a day, the retrieved context costs more than the fine-tune within 0.6 days. Fine-tuning is the cheaper shape here — but only if the knowledge is stable enough not to need redoing.
A one-off training cost against the per-request cost of retrieval.
At 1,000 requests a day, the retrieved context costs more than the fine-tune within 0.6 days. Fine-tuning is the cheaper shape here — but only if the knowledge is stable enough not to need redoing.
Every input moves the result for a reason. This is what each one does and where to find the value for your own machine.
| Setting | Default | What it changes |
|---|---|---|
| Requests per day | 1000 | Your own figure, starting from 1,000. Change it to match what you actually run. |
| Retrieved context per request | 3000 tokens | RAG pays this on every single request. Fine-tuning pays once. |
| Input price | 3 per 1M | Your own figure in per 1M, starting from 3. Change it to match what you actually run. |
| Fine-tune GPU hours | 8 hours | Your own figure in hours, starting from 8. Change it to match what you actually run. |
| GPU hourly rate | 0.69 per hour | Your own figure in per hour, starting from 0.69. Change it to match what you actually run. |
No lookup tables and no invented constants. Here is the arithmetic, so you can check it against your own numbers.
The two cost shapes are different in kind: fine-tuning is a fixed cost paid once, RAG is a recurring cost paid on every request as extra input tokens. So the answer is a break-even in requests, not a verdict.
Cost is not the only axis, and often not the deciding one. RAG updates the moment your documents change and can cite them; a fine-tune bakes knowledge in and has to be redone. Size the money here, then decide on freshness.
These are well-founded engineering estimates, not benchmark results. Your quantisation, runtime and context length all move the real number, and usable memory is an assumption rather than a specification. See the full methodology for every assumption behind these figures.
The three situations that bring people to this calculation.
Find the request volume where fine-tuning wins.
See what retrieved context costs at scale.
Weigh a one-off training cost against a recurring one.
Four steps, no account, nothing leaves your browser.
Start at the top of the panel. Every figure recalculates as you change it — there is no submit button, because watching the number move is the point.
4 further settings: retrieved context per request, input price, fine-tune gpu hours, gpu hourly rate. Defaults are the common case, so change only what differs for you.
The large figure answers the question. The table underneath shows how the answer changes across nearby settings, which is usually where the decision actually gets made.
The arithmetic is written out above. If a number looks wrong for your hardware, the assumptions are the first place to look — usable memory and quantisation are the two that vary most.
The questions people ask about this, answered without hedging.
At low volume, RAG — a fine-tune has to be paid for before it saves anything. At high volume the per-request context cost overtakes it, sometimes within days.
RAG, in most cases. It updates the moment your documents change, it can cite sources, and it does not need redoing when the base model is replaced.
For behaviour rather than knowledge — tone, format, following a house style, or a task the base model does badly. Facts belong in retrieval; behaviour belongs in weights.
Frequently the best answer: fine-tune for the format and behaviour you want, retrieve for the facts. They solve different problems.
All 50 run on the same arithmetic, so answers across them agree.
Different ways of asking the same question, all resolved above.
Sizing is only half the problem. Model Radar takes your hardware and shows which models actually run on it, ranked by what they are good at — the same arithmetic as this page, applied to every model worth running.