AI Cost Calculator: How It Works | How Much To Run AI

See the exact formulas, constants, matching rules, and price data boundary used by How Much To Run AI.

Last updated: 2026-08-06

The calculator combines a few deployment choices into a planning estimate. The current flow is:

model + precision + deployment + usage + exchange rate
                         ↓
       VRAM estimate + published-hardware match
                         ↓
          price observations + runtime assumptions
                         ↓
       upfront cost + monthly breakdown + conclusion

This is a simplified estimate. More info explains the scope and limitations in full.

Step 1: Choose a model and precision

Each model record includes an ID, name, series, displayed parameter size, and MoE flag. Seeded records may also include a Hugging Face model ID. The selected precision maps to these current bytes-per-parameter constants:

PrecisionBytes per parameter
FP162
INT81
INT40.5
GGUF Q40.55

Some MoE records also include active-parameter metadata. The calculation still uses total paramSizeB, not active parameters. This page does not calculate license, context-window, checkpoint-size, or framework compatibility.

Step 2: Estimate VRAM and match hardware

The service calculates required VRAM with:

required VRAM (GB) = paramSizeB × bytesPerParam × 1.2

The 1.2 value is a fixed runtime reserve. In this implementation, it is a simplified factor for weight residency and basic runtime overhead. It does not measure KV cache, activations, context length, or concurrency.

Here are a few examples using the current formula:

7B FP16:  7 × 2 × 1.2   = 16.8 GB
7B INT4:  7 × 0.5 × 1.2 =  4.2 GB
32B FP16: 32 × 2 × 1.2  = 76.8 GB
32B INT4: 32 × 0.5 × 1.2 = 19.2 GB

These examples show the formula; they do not guarantee that a deployment will fit. Actual memory can be higher because of KV cache, activations, unquantized layers, framework workspace, replication or sharding, context length, concurrency, and safety margin. For MoE models, the calculation uses total parameters because it assumes all expert weights must be resident.

The matcher uses this order:

  1. Use a recommended model-to-hardware mapping when it matches the selected quantization, has enough recorded VRAM, and has a current published price.
  2. Otherwise choose the smallest hardware record with enough VRAM among currently priced tiers.
  3. For cloud requests, return no match when the required VRAM exceeds the current 640 GB single-priced-instance ceiling.

The 640 GB figure is the current catalog and matching boundary for aggregate memory. Multiple GPUs do not automatically form one shared memory pool. The matcher also does not validate tensor parallelism, expert parallelism, sharding, topology, or interconnect.

Step 3: Apply the deployment path and price data

Cloud

For a cloud deployment, the service uses the currently published observations for the matched hardware and calculates:

cloud monthly compute = hourly price × selected monthly hours

After currency normalization, the range uses the lowest observed minimum and highest observed maximum. Cloud electricity is treated as part of the rental price. The monthly result still includes the fixed operations-labor estimate.

Local

For a local deployment, the service uses the published local hardware price range and applies the current full-system multiplier:

one-time local system estimate = observed hardware price × 1.4

The 1.4 multiplier is a budget assumption for the GPU, chassis, CPU, RAM, PSU, and similar items when a complete BOM is unavailable. It is not a confirmed cluster topology or supplier quote. Some multi-GPU entries are also linear estimates rather than directly purchasable systems, so read their price condition.

Step 4: Apply usage and operating assumptions

The usage presets represent these monthly runtime values:

PresetHours per monthApproximate share of a 30-day month
Light12017%
Medium36050%
Heavy720100%

These hours only scale the cost model. They do not model QPS, token volume, batching, utilization, latency, or capacity.

For local deployment, the current electricity formula is:

GPU TDP (kW) × monthly hours × 0.65 CNY/kWh × PUE 1.2

The displayed electricity range is approximately 90%–110% of that result. GPU TDP is a proxy, not measured wall power. CPU, memory, storage, fans, networking, PSU efficiency, average load, and facility conditions are outside this calculation. PUE is used as a simple planning factor, not a full system-level facility model.

Operations labor is calculated as:

15,000–25,000 CNY/month × 0.15 FTE
= 2,250–3,750 CNY/month

For a local deployment, the depreciation reference uses the maximum one-time estimate divided over 36 months. It is a comparison reference, not accounting depreciation or resale-value modeling. The default exchange rate is 1 USD = 7.2 CNY; the calculator lets the user override it within the API's accepted range.

Step 5: Read the result

Depending on deployment and available data, the result can show:

  • Estimated VRAM and the recommended hardware record.
  • One-time local deployment cost.
  • Monthly compute, electricity, operations labor, and total cost.
  • Local depreciation reference and, where possible, a cloud comparison.
  • Price source/provider, resource identifier, region, currency, billing unit, update time, condition, and source link when available.
  • Freshness badges based on the published price observations.
  • A conclusion for the selected scenario.

The service sums monthly cost in CNY and then shows it in both supported currencies. A missing price record or unavailable cloud tier is returned as unavailable data. The service does not invent a price.

Price source labels and estimate flag

Each published price observation now carries a sourceType and an isEstimate flag. They appear in the calculator result so you can judge the reliability of each line item:

Source typeMeaningisEstimate
Official price APIDirect from a provider's public price API, e.g. Azure Retail Prices API.No
Official price calculatorFrom an official calculator or estimator page.Usually no
Retail listingA public product listing with a visible seller price.No
Market referenceThird-party aggregate, marketplace, or channel reference price.Sometimes yes
Linear estimateCalculated by multiplying a single-GPU or single-node reference by a GPU count.Yes
Quote pendingNo public price is available; the range is a channel quote placeholder or awaiting a formal vendor quote.Yes

When isEstimate is shown, the price is an extrapolation or reference, not a confirmed vendor quote. Multi-GPU local entries in particular are often linear estimates and do not represent a verified, directly purchasable system with the correct topology, power, cooling, and support.

The result also shows the provider, resource identifier, region, currency, billing unit, update time, condition, and source link when available. Always read the condition and follow the source link before using a number in a budget or procurement decision.

Price data boundary and freshness

Only observations marked published, not expired, and attached to an active data source reach the public calculation response. The response includes the observation's source/provider, resource identifier, region, currency, billing unit, condition, observed time, source type, estimate flag, and optional URL.

The UI does not normalize tax, storage, network, support, reservation, spot, or negotiated-contract inclusions. Read the conditions and source links before treating a range as a quote.

Formula version and limitations

These formulas match the current implementation constants and behavior. They are not a substitute for production load testing or capacity planning. See More info for the full scope and its limits.

Start with the calculator

Open the calculator, choose a model and deployment scenario, and use the result to start a budget and architecture conversation.