Research-backed calculator guide

Local LLM Workstation Cost Calculator: Build Budget, Amortization and Throughput

Estimate a local LLM workstation's full cost from hardware, power, utilization, maintenance, useful life, resale, and achievable throughput.

What a local LLM workstation cost calculator should include

Start with the workload rather than a parts list. Record the model family, quantization, context length, expected concurrency, operating hours, and latency target. Quantization stores weights at lower precision to reduce memory requirements, but the choice has accuracy and runtime trade-offs; Hugging Face documents fp32, fp16/bf16, int8, int4, and several hardware-specific methods.^[3] A workstation that cannot hold the weights plus runtime overhead and context cache is not a low-cost workstation. It is an unusable purchase or a machine that relies on slower offload.

Next, separate four financial layers:

1. Capital: GPU or accelerator, CPU, motherboard, RAM, storage, chassis, power supply, cooling, and assembly.
2. Power: average wall draw, operating hours, electricity price, and any additional cooling burden that you choose to model.
3. Operations: maintenance reserve, replacement parts, storage growth, monitoring, backups, and paid engineering time.
4. Capacity: measured or conservatively estimated throughput, concurrency, warm-up behavior, and the percentage of the month the machine is actually useful.

Do not use a graphics card's maximum board power as the whole system's average. For example, NVIDIA lists the GeForce RTX 5090 with 32 GB of GDDR7, 575 W total graphics power, and a 1,000 W required system power recommendation for a specified configuration.^[1] Those figures help with memory and PSU planning; they are not an inference-meter reading. Measure the complete system at the wall under your own model and context workload before replacing the estimate with a measured value.

A serving stack also changes capacity. vLLM describes continuous batching, PagedAttention, prefix caching, quantization support, and distributed parallelism as serving features.^[2] That means a production server may process more concurrent work than a single interactive session, but you should benchmark the exact model, quantization, prompt mix, and concurrency. Treat published or estimated tokens per second as an input to sensitivity analysis, not as a promise.

Build budget: price the complete machine

A local LLM PC build budget should include every part required to reach a working inference endpoint. GPU-only arithmetic understates cost and can create a false payback case. Include the power supply with appropriate headroom, memory for model loading and host-side tasks, fast storage for model files, cooling, case clearance, and a reasonable replacement reserve.

Use a replacement reserve even when you expect the hardware to last. A simple method is to add a monthly maintenance amount for fans, drives, cables, and unexpected downtime. For a production service, add a second-machine or cloud-failover reserve instead of assuming a single workstation has an SLA. If engineering time matters, value setup and monthly maintenance at the team's loaded hourly rate. Keep that labor line separate from electricity so a technical team can see which assumption drives the decision.

For a unified-memory machine, do not treat total system memory as entirely available to the model. The operating system, runtime, context cache, and other applications need headroom. For a discrete GPU, the same principle applies to VRAM: model weights are only one item. Context length, KV cache, adapters, and runtime overhead consume memory too. A lower-bit model may fit where full precision does not, but fitting is not the same as meeting a latency or quality requirement.^[3]

Core formulas for workstation amortization

Let:

• H = purchase price in USD;
• R = expected resale value in USD at the end of the horizon;
• L = useful life in months;
• P = average wall draw in watts;
• U = operating hours per month;
• E = electricity price in USD per kWh;
• M = monthly maintenance and software reserve in USD.

Then:

Monthly amortization = (H − R) ÷ L

Monthly electricity = (P ÷ 1,000) × U × E

Monthly operating cost = electricity + M

Monthly full TCO = amortization + monthly operating cost

For a rental or API comparison, model the alternative separately. A rented-GPU baseline is rental rate per hour × comparable hours. An API baseline is input tokens × input rate + output tokens × output rate, with cache, retries, and any minimums included if they apply. Do not compare a local system's full TCO with an API's input-only price.

The simple payback period against a rental baseline is:

(H − R) ÷ (alternative monthly cost − monthly operating cost)

This formula is only meaningful when the denominator is positive and the alternative provides comparable model quality, capacity, availability, and data controls. If the denominator is zero or negative, buying does not pay back on direct cash cost under those assumptions. Privacy, offline operation, latency, or model control may still justify the purchase, but that is a different decision criterion.

Worked cost example

Consider a team that expects 160 hours of inference availability per month. It is comparing a complete $3,600 tower with a $1.20/hour comparable rented-GPU baseline. The US electricity input is $0.18/kWh. These are illustrative inputs for a worksheet, not current vendor quotes.

The cloud-equivalent baseline is 160 × $1.20 = $192 per month. The local system's net capital is $3,600 − $600 = $3,000; spread over 36 months, that is $83.33 per month. Power is (650 ÷ 1,000) × 160 × $0.18 = $18.72. Add a $40 reserve for maintenance, storage replacement, and routine operations. Full monthly TCO is therefore $83.33 + $18.72 + $40 = $142.05.

On direct cash assumptions, the local option is $49.95 below the rental baseline when capital is amortized. For a capital payback view, compare the $3,000 net capital with the alternative's $192 less local operating cost of $18.72 + $40 = $58.72: $3,000 ÷ ($192 − $58.72) = 22.5 months. That result is sensitive to hours. At 40 hours per month, the rental baseline falls to $48, while the local machine still has its capital and reserve costs. Utilization is doing most of the work.

Throughput must be checked separately. If a measured benchmark is 35 generated tokens per second, 160 hours offers a theoretical ceiling of 35 × 3,600 × 160 = 20.16 million tokens. Applying a 70% usable-capacity factor for queueing, warm-up, failed requests, and headroom yields 14.11 million usable tokens per month. Full TCO divided by that capacity is about $10.07 per usable million tokens. A different model or concurrency profile can change the measured speed, so record the benchmark conditions next to the result.

Original input/output worksheet

The following table shows how the same formulas behave across four illustrative tiers. USD, 36-month life, stated resale, and $0.18/kWh are assumptions. “Usable tokens” uses the deliberately conservative capacity factor shown in the row; it is not a benchmark claim.

The table is a comparison scaffold, not a buying list. Replace every price, draw, speed, and resale input with an invoice, wall-meter reading, benchmark run, or conservative estimate. For a GPU-heavy deployment, the official board specification is useful for sizing the power supply, while your measured wall draw belongs in the electricity formula.^[1]

Read the result without overclaiming

A low monthly TCO does not automatically mean a good deployment. Check whether the chosen hardware can load the intended model at the required context length. Check time-to-first-token, sustained generation speed, concurrent users, and failure behavior. A larger quantized model may fit but fail your quality bar; a smaller model may be more economical because it meets the task with less power and more throughput.

Use the Self-hosted GPU inference cost calculator for a model-specific cost-per-token view. If the alternative is a hosted model, use the Model pricing comparison to keep input and output units separate. For a retrieval workload, include embedding, vector storage, and retrieval costs with the RAG, embedding and vector database cost calculator. A local workstation can remove one line item while leaving the rest of the application economics unchanged.

Avoid three common mistakes. First, do not annualize a maximum power rating as if it were average draw. Second, do not divide hardware price by tokens per second without accounting for hours, idle time, context, and failures. Third, do not assume resale value: enter zero if you cannot defend a resale estimate. You can also model a pessimistic case with shorter useful life, higher electricity, lower utilization, and 20% less throughput.

FAQ

How much does a local LLM workstation cost?

A useful answer is a range driven by model fit and utilization, not one sticker price. In the worksheet above, illustrative complete systems range from $800 for a small machine to $12,000 for a multi-GPU server. Those figures are scenario inputs, not vendor quotes. The correct budget includes the full system, storage, power supply, cooling, maintenance reserve, and any backup or failover requirement.

Is electricity the biggest local AI cost?

Usually not for a lightly used workstation. In the single-GPU example, 650 W for 160 hours at $0.18/kWh costs $18.72, while amortization is $83.33 and the maintenance reserve is $40. Electricity becomes more important with 24/7 operation, high tariffs, multiple GPUs, or additional room cooling. Use wall draw and actual hours rather than the GPU's maximum rating.

How do I calculate workstation amortization for LLM inference?

Subtract defensible expected resale from the purchase price, then divide by the number of useful months. A $3,600 system with $600 resale over 36 months contributes (3,600 − 600) ÷ 36 = $83.33 per month. If resale is uncertain, run both a zero-resale and a base-case scenario. Amortization is an accounting-style planning allocation; it is not a claim about tax treatment.

Should I compare local cost with an API or rented GPU?

Compare against the alternative that provides equivalent capacity and quality. For a rented GPU, use comparable hours and include storage or egress where relevant. For an API, separate input and output tokens, cache behavior, retries, and any minimums. A local workstation has capital risk and maintenance; an API has variable usage cost and provider dependency. The calculator should expose those assumptions instead of hiding them in one blended number.

How does quantization affect the budget?

Quantization can reduce memory requirements by storing weights at lower precision, but it may alter quality, supported runtimes, and performance. It can let a model fit on a smaller device, yet context cache and runtime overhead still need space. Use a quantization method that meets your quality bar, then benchmark the selected model and precision on the intended hardware.^[3]

What is a realistic throughput assumption?

Use a measured run with the exact model, quantization, prompt length, context, batch or concurrency setting, and runtime. If you have no measurement, label the number as an estimate and apply a capacity haircut. vLLM supports serving features such as continuous batching and PagedAttention, so multi-user throughput can differ from single-user speed.^[2] Never present a theoretical tokens-per-second number as a guaranteed service level.

When does a local AI server pay back?

It pays back only when the comparable alternative's monthly cost exceeds local operating cost by enough to recover net capital within the chosen horizon. In the worked example, $3,000 of net capital divided by $133.28 of monthly cash-cost difference gives about 22.5 months. Low utilization, a cheaper API, lower throughput, or unplanned maintenance can lengthen or eliminate payback.