Research-backed calculator guide

Local LLM Electricity Cost Calculator: Watts, Hours and Your Tariff

Calculate the electricity cost of local LLM inference from measured watts, active and idle hours, your tariff, and an optional cooling or facility multiplier.

A local LLM electricity cost calculator should begin with the power entering the machine, not the model name. The same model can cost very different amounts to run on a laptop, a desktop GPU, or a multi-GPU server. Your bill also depends on how long the system is actively generating, how long it remains powered but idle, and the all-in price on your electricity bill.

monthly kWh = ((active watts × active hours/day) +
               (idle watts × idle hours/day)) × days/month ÷ 1,000
monthly electricity cost = monthly kWh × tariff ($/kWh)

For a quick estimate, measure the complete system at the wall. If a wall meter says 420 W while the local LLM is generating and 65 W while the server is waiting, with 5 active hours and 19 idle hours per day, a 30-day month uses 100.05 kWh. At a tariff of $0.18/kWh, the electricity cost is $18.01 for the month. That is the running electricity cost only. It excludes hardware purchase or depreciation, software subscriptions, repairs, internet service, and the value of your time.

Do not substitute a GPU's advertised TGP for whole-system input without saying so. NVIDIA defines TGP as electrical power drawn by the GPU under maximum load, including the GPU core, onboard memory, and supporting graphics-card circuitry. It is not the same measurement boundary as a wall-meter reading for the PC, power supply, storage, fans, monitor, or other equipment. ^[1] If your input is GPU telemetry, label it as such and apply an explicit system-overhead assumption. If your input is measured at the wall, do not add that same overhead again.

For a broader ownership comparison, use the Self-hosted GPU inference cost calculator. It can help place electricity beside hardware and utilization assumptions, while this guide keeps the electricity calculation auditable.

What the calculator should measure

1. Choose a measurement boundary

There are three common inputs, and they answer different questions.

Wall draw is the best input for a household bill. A plug-in power meter or smart plug measures the electricity consumed by the connected system, including the power supply's conversion losses and the machine's fans, drives, memory, and CPU. If the meter is upstream of several machines, record what else is connected so the result is not attributed to the LLM alone.

GPU telemetry is useful for engineering trends. NVIDIA's tools can report GPU power and power limits, and its documentation distinguishes a limit from the actual reading. ^[2] GPU telemetry is not a complete bill estimate because the rest of the system still uses power. Convert it to an estimated wall input only with a stated factor or, better, validate it against a wall meter during the same workload.

Nameplate or TGP is a planning ceiling, not a measured monthly bill. It can be a reasonable upper-bound scenario when you have no meter, but it may overstate or understate typical generation. A GPU may spend much of its time waiting on memory, request scheduling, or user input rather than at its maximum rating.

2. Separate active and idle time

Active hours are the time when the workload is generating, pre-filling, embedding, or otherwise making the accelerator work. Idle hours are powered-on time when the server is waiting. They matter for an always-on Ollama server because a model can remain loaded while requests are infrequent.

If you only know total powered-on hours, use one average wall draw and say that it is an average. If you can observe the workload, keep at least two states. For a more realistic production profile, add a third state such as batch, sleep, or standby. The general formula is the sum of each state:

monthly kWh = days/month ÷ 1,000 ×
              Σ(state watts × state hours/day)

A 24/7 machine has 24 powered hours per day, but it does not necessarily have 24 active inference hours. Treating all 24 hours as peak draw is a stress case, not a neutral default.

3. Use the tariff on your bill

Enter dollars per kilowatt-hour, not dollars per watt and not the price of a kilowatt-hour before fees if your bill charges a different all-in rate. BLS explains that its electricity price series are built from collected prices and include service charges, consumption charges, credits or additional charges, and taxes; rates can also vary by season and rate schedule. ^[4] That is why a national average is only a placeholder. For a United States estimate, divide the relevant bill total by the billed kWh when appropriate, or enter your utility's time-of-use rate for the hours you actually run the model.

Record whether the tariff is flat, time-of-use, or a blended average. If peak and off-peak rates differ, calculate each period separately rather than hiding the difference in one rounded number. Keep the currency and unit visible: $0.18/kWh is not interchangeable with 18/kWh.

4. Decide whether cooling or facility overhead belongs in the result

A household wall-meter result already includes the electricity drawn by the measured equipment. Do not multiply it by a data-center overhead factor unless you are intentionally estimating unmetered cooling or facility energy.

For a server-room estimate based on IT load, use an explicit multiplier such as a documented PUE assumption. For example, a 1.20 multiplier means 20% additional facility energy on top of the IT load. It is an assumption, not a universal constant. For a home office, cooling is more difficult: every watt consumed by the computer becomes heat, but the extra air-conditioning energy depends on the HVAC system, weather, thermostat, and whether the room would have been cooled anyway. Report direct machine electricity separately, then show cooling as an optional scenario.

Worked example

Assume a developer measures one local inference workstation at the wall. During an Ollama or vLLM generation run, it draws 420 W. Between requests, it draws 65 W. The workload runs 5 hours actively and remains powered for the other 19 hours each day. The billing period is modeled as 30 days, and the reader enters an all-in residential tariff of $0.18/kWh.

The core result is $18.01 per month because the input is a wall-meter reading. The $21.61 figure is a separate scenario that adds 20% facility energy; it is not a better answer for a home plug meter. The $4.50 per million tokens is also a derived unit cost, not a provider quote. It changes with output volume even when the electricity bill stays roughly the same.

If the same workstation is active for 10 hours per day at 420 W and idle for 14 hours at 65 W, its monthly energy becomes (0.420 × 10 + 0.065 × 14) × 30 = 137.70 kWh. At the same tariff, the direct cost becomes $24.79. If the tariff rises to $0.30/kWh, the original 100.05 kWh profile costs $30.02. These scenarios show why hours and tariff can matter as much as hardware selection.

From electricity cost to local AI unit cost

Electricity is only one layer of local inference economics. To compare a local LLM with an API or hosted GPU, keep the layers separate:

monthly local run cost = electricity + maintenance + software + other operations
monthly fully loaded cost = monthly local run cost + hardware amortization
cost per million tokens = monthly cost ÷ monthly tokens in millions

This guide calculates only the first term. Hardware amortization requires a purchase price, useful life, expected resale value, and utilization policy. Maintenance may include replacement fans, storage, repairs, and a support reserve. If you are comparing models or API rates, the Model pricing comparison page is the better place to normalize provider units; do not quietly mix a local electricity-only figure with a cloud price that includes hardware or support.

For a RAG workload, electricity may be shared across generation, embedding, reranking, and a vector database. The RAG, embedding and vector database cost calculator can help separate those components. For a custom agent, include orchestration and review effort rather than treating every token as the entire cost; the AI agent development cost estimator covers that broader planning context.

Measurement and reporting checklist

1. Measure at the wall for at least one representative active window and one idle window.
2. Record model, quantization, context length, concurrency, batch size, and whether a monitor or peripherals were included.
3. Capture active and idle hours from logs rather than assuming every powered hour is inference.
4. Copy the tariff unit and rate from the bill, including whether taxes and fixed charges are included.
5. If using GPU telemetry, state the GPU-versus-wall boundary and the conversion assumption.
6. Recalculate after changing power limits or keep-alive behavior. NVIDIA documents power-limit controls and actual power readings as distinct concepts, so a cap is not proof of a constant draw. ^[2]
7. For repeatable workloads, store monthly prompt and generation token counters. vLLM exposes prompt-token, generation-token, request, latency, and queue metrics through its monitoring surface, which can help pair energy records with workload volume. ^[3]

Assumptions, exclusions, and limitations

This worksheet assumes watts are an average over each state, hours are representative, and the month is 30 days. Real power can spike, especially when a model loads or several requests run concurrently. A short measurement may miss those transitions. If the machine is behind a UPS, measure the UPS input when the objective is the utility bill; measuring only DC output omits conversion losses.

The estimate excludes capital cost, depreciation, resale value, labor, cooling unless explicitly added, network equipment outside the measured boundary, and carbon accounting. It also does not decide whether a local model is cheaper than an API. That comparison requires matching model quality, latency, throughput, availability, privacy requirements, and the cost unit. A low electricity bill does not prove a low total cost, and a high-wattage workstation can still be economical for a heavily utilized workload. Treat every result as an estimate until it is reconciled to a bill or meter.

FAQ

How do I calculate the electricity cost of running a local LLM?

Convert watts to kilowatts, multiply active watts by active hours and idle watts by idle hours, add the energy states, multiply by the number of days, then multiply by your tariff in dollars per kWh. The result is direct electricity cost. Use measured wall draw when the question is “what will appear on my bill?” and label GPU telemetry as a partial measurement.

What is the Ollama electricity cost for an always-on server?

There is no single Ollama electricity price. Ollama is the software layer; the bill comes from the host hardware, its active and idle draw, the keep-alive policy, and the tariff. Measure the server while a model is generating and while it is waiting. If the model stays loaded, idle draw may be higher than an unloaded system, so use a separate idle reading instead of assuming near-zero power.

Should I use GPU TDP or TGP in a GPU LLM power consumption cost estimate?

Use a measured wall reading where possible. TGP is a GPU electrical-power metric, while TDP is a thermal-design concept and neither automatically represents the entire computer. NVIDIA describes TGP as including the graphics card's core, memory, and supporting circuitry, but it does not include every component between the wall and the model process. ^[1] If you have only a GPU value, add a documented system-overhead assumption and call the result an estimate.

Does leaving a local LLM server on 24/7 cost more than running it only during work hours?

Usually, yes, because idle hours still consume power. The exact difference is the idle wattage multiplied by the hours avoided and your tariff. Shutting down for 12 hours at 65 W saves 0.065 × 12 = 0.78 kWh per day, or 23.4 kWh over a 30-day month. At $0.18/kWh, that is $4.21 before considering startup time or convenience.

Should I include air-conditioning in the local AI electricity cost?

Show it as a separate scenario unless your meter measures the whole facility. The workstation's electrical energy becomes heat, but the extra cooling energy varies with HVAC efficiency, weather, thermostat settings, and whether the room was already being cooled. A PUE-style multiplier can be useful for a server facility, but it should be visible and not silently applied to a wall-meter result.

Can I calculate electricity cost per million local-LLM tokens?

Yes. Divide the monthly electricity cost by monthly output tokens expressed in millions. For example, $18.01 divided by 4 million tokens is $4.50 per million tokens. Include the token-count source and workload period. If your traffic doubles while the machine's monthly electricity is similar, this unit cost falls; that does not mean the machine became more energy-efficient.