Local LLM Cost per Million Tokens: A Useful Estimate

The short answer to local llm cost per million tokens is this: there is no single number. A local setup has a mostly fixed monthly cost, so cost per token depends heavily on utilization. If your machine generates few tokens, each token carries more of the hardware bill. If it stays busy, the same hardware cost gets spread across more tokens, and the unit cost drops.

A useful estimate is:

cost per 1M tokens = amortized hardware cost per month ÷ monthly tokens + electricity cost per month ÷ monthly tokens

You can also write electricity directly as power × hours × price. This post shows both formulas, uses clear assumptions, and compares example totals with official API prices from OpenAI and Gemini. These are worked examples, not benchmark measurements.

How do you estimate local LLM cost per million tokens?

Start with two buckets: hardware and energy.

1. Hardware amortization

For a local inference box, most cost is paid upfront. Spread that cost over a useful life.

Monthly hardware cost = system purchase price ÷ useful life in months

Then spread that monthly cost over actual output.

Hardware cost per 1M tokens = monthly hardware cost ÷ monthly tokens in millions

2. Electricity

Electricity depends on power draw, runtime, and your local rate.

Monthly electricity cost = average wall power in kW × active hours per month × electricity price per kWh

Then:

Electricity cost per 1M tokens = monthly electricity cost ÷ monthly tokens in millions

Put together:

Local cost per 1M tokens = (system price ÷ life months + kW × hours × $/kWh) ÷ monthly token output in millions

This estimate is simple, but it captures the main truth. A local LLM does not have a stable per-token price unless you also specify how much you use it.

If you want a quick worksheet, use the /local-llm-estimator/ or the broader /calculator/.

Why does utilization matter so much for local token cost?

Utilization matters because hardware cost is fixed whether the machine works or sits idle.

Suppose a box costs $6,000 and you amortize it over 24 months. That gives $250 per month in hardware cost before electricity. If you only generate 5 million tokens that month, hardware alone is $50 per 1M tokens. If you generate 100 million tokens, hardware falls to $2.50 per 1M tokens.

Nothing magical happened. You just spread the same fixed cost across more output.

This is why local economics look great for steady internal workloads and much worse for occasional use. It is also why token cost estimates posted online often disagree. People change one hidden variable: tokens produced per month.

Utilization is not only “GPU busy percent.” For cost, the practical question is simpler:

How many billable tokens does the machine produce over the period used for amortization?

That number depends on model choice, quantization, concurrency, prompt length, idle time, and whether the system is reserved for peak demand. If you are still sizing hardware, these guides help frame likely deployment options: best local LLM by RAM, best local LLM by GPU, and quantization in plain English.

What formulas should you use for amortization and electricity?

Here is a practical version you can reuse.

Let:

• P = system purchase price
• L = useful life in months
• T = monthly tokens produced
• W = average wall power in watts during generation
• H = active generation hours per month
• R = electricity rate in dollars per kWh

Then:

Monthly amortization = P / L

Monthly electricity = (W / 1000) × H × R

Cost per 1M tokens = ((P / L) + ((W / 1000) × H × R)) / (T / 1,000,000)

You can also estimate by tokens per active hour instead of monthly tokens:

• S = tokens generated per active hour

Then monthly tokens are T = S × H, so:

Cost per 1M tokens = ((P / L) / (S × H / 1,000,000)) + (((W / 1000) × H × R) / (S × H / 1,000,000))

This form shows something useful. If active hours rise but throughput stays similar, the electricity cost per token stays roughly stable, while amortization per token falls because the machine produces more total tokens over the month.

For electricity rates, the US average in 2025 was 17.30 cents per kWh residential and 13.41 cents per kWh commercial. For a power anchor, Nvidia lists the RTX 5090 at 575W TGP and recommends a 1000W system power supply. Those figures are not the same as actual wall draw during inference, so any wall-power number below is an assumption for examples.

What does a worked local cost example look like?

Below are illustrative examples only. They are not benchmark measurements. I am not asserting any specific tokens-per-second result for any model.

Assumptions for one example system:

• System price: $6,000 assumption
• Useful life: 24 months assumption
• Average wall power during generation: 700W assumption
• Electricity price: $0.173/kWh residential using the 2025 US average
• Monthly active hours: 240 hours assumption
• Monthly hardware cost: $250
• Monthly electricity cost: 0.7 × 240 × 0.173 = $29.06

Total monthly cost in this example is $279.06.

Now vary only utilization:

This table is the key point. The electricity part moves a little. The hardware part moves a lot. That is why utilization dominates.

If you are building around larger memory footprints, the same pattern applies. The absolute numbers shift with system price. See best local LLMs for 64GB RAM, best local LLMs for 128GB RAM, and this 64GB local AI rig parts list.

How do these local estimates compare with OpenAI and Gemini prices?

Official API prices provide a clean reference point.

OpenAI lists these standard prices on its API pricing page:

• GPT-5.6 Sol: $5 per 1M input and $30 per 1M output
• GPT-5.6 Terra: $2.50 input and $15 output
• GPT-5.6 Luna: $1 input and $6 output
• Batch: 50% off those rates

Google lists on the Gemini API pricing page:

• Gemini 3.5 Flash paid: $1.50 per 1M input and $9 per 1M output
• Batch: $0.75 input and $4.50 output

A direct comparison is tricky because local usage does not separate input and output pricing. You pay for time, power, and hardware whether the tokens are prompt tokens or generated tokens. Still, the examples are useful.

Using the table above, the same local system could range from $55.81 to $2.79 per 1M total tokens depending on utilization. That means:

• At low utilization, local can be much more expensive than API pricing.
• At high utilization, local can land in the same broad range as some paid API token rates.
• Whether that is attractive depends on your input/output mix, duty cycle, and hardware spend.

This is why simple claims like “local is cheaper” or “API is cheaper” fail. They skip utilization. For broader API context, compare with /blog/openclaw-api-costs-compared/ and /blog/openclaw-costs-guide/.

When is a local LLM cheaper per million tokens?

A local LLM tends to be cheaper when these conditions hold:

1. You keep the machine busy. More tokens per month reduce amortization per token.
2. Your hardware cost is controlled. Lower capex improves the floor.
3. Your electricity rate is moderate. This helps, but usually matters less than utilization.
4. You need predictable volume. Fixed-cost systems reward stable demand.

A local LLM tends to be worse when:

1. Demand is bursty or occasional.
2. You overbuy hardware for a future workload that never arrives.
3. The machine stays reserved but idle.
4. You compare local total tokens to API input-only prices.

A good practical step is break-even modeling. If your workload is uncertain, estimate a low, medium, and high token month. Then compare each case with API pricing. This guide can help with the power side: local LLM electricity cost break-even.

What should you watch out for when using these estimates?

Three common mistakes distort local token economics.

First, mixing rated power with actual draw. Nvidia’s 575W TGP for RTX 5090 is a board power figure, not a measured full-system inference draw. Use your own wall-meter assumption if possible.

Second, ignoring idle time. If the box is on all day but active only a few hours, your real electricity cost may be higher than the simplified active-only formula.

Third, treating examples as benchmarks. This post does not provide measured token throughput. It shows how cost moves once you plug in your own throughput and utilization assumptions.

If you need financial guardrails for API use while you compare options, see /blog/openclaw-spending-limits/.

What should you read next?

• Best Local LLM by RAM
• Best Local LLM by GPU
• Best Local LLMs for 64GB RAM
• 64GB Local AI Rig Parts List
• Local LLM Electricity Cost Break-Even
• Quantization in Plain English
• Local LLM Estimator
• Calculator