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:
| Precision | Bytes per parameter |
|---|---|
| FP16 | 2 |
| INT8 | 1 |
| INT4 | 0.5 |
| GGUF Q4 | 0.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:
- Use a recommended model-to-hardware mapping when it matches the selected quantization, has enough recorded VRAM, and has a current published price.
- Otherwise choose the smallest hardware record with enough VRAM among currently priced tiers.
- 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:
| Preset | Hours per month | Approximate share of a 30-day month |
|---|---|---|
| Light | 120 | 17% |
| Medium | 360 | 50% |
| Heavy | 720 | 100% |
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 type | Meaning | isEstimate |
|---|---|---|
| Official price API | Direct from a provider's public price API, e.g. Azure Retail Prices API. | No |
| Official price calculator | From an official calculator or estimator page. | Usually no |
| Retail listing | A public product listing with a visible seller price. | No |
| Market reference | Third-party aggregate, marketplace, or channel reference price. | Sometimes yes |
| Linear estimate | Calculated by multiplying a single-GPU or single-node reference by a GPU count. | Yes |
| Quote pending | No 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.