Methodology

How GPU prices are calculated

Prices are medians of current asking prices, not sold prices. Each of the three markets is calculated on its own, and every round records the median, the quartiles and the number of valid samples:

Each device has its own model-matching rules, and candidate listings are then reviewed by our in-house algorithm: it checks the model and VRAM, excludes mining cards, accessories, proxy-purchase offers, complete systems and mislabeled products, and removes outlier prices. Listings with an unclear price, seller or stock status are not counted.

When there are fewer than 3 valid samples, no price is published for that round and the page shows it as empty. A consistency check also runs before publication: clearly abnormal results are kept out of the price history, and the last valid price is carried forward. Prices update every 6 hours, and price charts keep the full history.

How the price index is calculated

The GPU price index is calculated separately for each market in its native currency. It includes every device with a valid price history, counting one unit per model. The base period is set to 100: the index is the current sum of each model's median price divided by the base-period sum, times 100.

New models are linked into the index at their price on the day they are added, so an addition is never counted as a price increase. When a model is temporarily missing a quote, its last valid price is carried forward. The time range selected on the chart only changes the display and never resets the base period. When there is no matching data point from 24 hours earlier, the 24-hour change is not shown.

View the GPU price index

How RAM prices are calculated

RAM is tracked by spec bucket, not by brand or part number. A bucket is generation × speed × capacity per stick × server or desktop, for example DDR5-6000 32GB. RAM is a standardized commodity: the price gap between brands at the same spec is far smaller than the gap between specs, so aggregating by bucket is steadier than aggregating by model.

Every price in the ranking is a per-stick price. Kits are divided by stick count first, so "32GB (16GB×2)" counts as two 16GB sticks and goes into the 16GB bucket. Listings whose stick count cannot be determined are excluded rather than assumed to be one stick, so a kit total is never mistaken for a single-stick price and never pulls the median up. ECC is not a separate tier: a DDR5 listing that only says ECC usually means on-die ECC and is treated as a regular stick.

Desktop sticks and server sticks (RDIMM / LRDIMM) are in separate buckets: they do not fit the same motherboards and do not trade in the same market.

Max memory = capacity per stick × stick count. It is the capacity of the reference configuration, not the limit of every motherboard. Bandwidth is theoretical: in practice it is limited by the CPU, the motherboard and how the slots are populated, and filling every slot does not guarantee the rated speed. Collection, publication thresholds, the 24-hour change and exchange rates work the same way as for GPUs in all three markets.

How much VRAM does an LLM need: the formula

Whether a card can run a model depends on whether three things fit in VRAM together: the model weights, the KV cache, and the runtime overhead of the inference framework itself.

Bytes per parameter depend on the quantization level. The 1.05 factor covers fixed costs such as GGUF metadata and unquantized embedding layers. Values for each quantization level:

When the repository has a GGUF file for a quantization level, the calculation uses the file's actual size instead of the formula above; the formula applies only to levels without a file. For models whose expert layers are natively 4-bit (DeepSeek V4, Kimi K2.6 and later, gpt-oss), the 8-bit file is only about half the formula estimate, so only the file size is accurate; the bytes read per token in the speed estimate are scaled by the same ratio.

In the VRAM tables on model pages, weights marked "GGUF" are the measured file sizes in the repository, and those marked "est." are estimated from parameter count with the formula above. For models listed only from verified files, levels without a verified file show a dash and are not estimated.

KV cache size formula

The 2 stands for the separate K and V copies, and each element takes 2 bytes in FP16. The formula assumes every layer stores a full K and V for every token, so it only applies to standard multi-head attention (MHA / GQA). Hybrid attention, MLA, sliding windows and similar architectures are covered in the next section.

KV cache exceptions: hybrid attention, MLA and sliding windows

Many newer models do not store a full KV at every layer, and plugging them straight into the formula above overestimates their KV cache by anywhere from a few times to dozens of times. We work layer by layer from each model's official config.json and count only the part that grows with context, in four groups:

• Hybrid linear attention: Most layers use linear attention (Gated DeltaNet, KDA and similar), which keeps one fixed-size state per layer that does not grow with context. Only a few full-attention layers (commonly 1 in every 4) store KV. We count only the full-attention layers; the fixed state of the linear layers is usually just a few hundred MB and is included in the runtime overhead.
• MLA latent attention: Each layer caches just one compressed latent vector per token (usually 512 dimensions, plus 64 for positional encoding) instead of separate K and V for each attention head. We count by the size of the latent vector. DeepSeek Sparse Attention (DSA) is also in this group.
• Compressed attention: The DeepSeek V4 series compresses every 4 or 128 adjacent tokens into a single KV entry, and only the most recent 128 tokens are kept as is. We count by each layer's compression ratio and ignore the most recent 128 tokens, which take only a few MB. For versions with officially published figures, we use those figures directly.
• Sliding window: Most layers only look at a fixed-length span of the most recent tokens (the window; Llama 4's chunked attention counts too), so their KV stops growing once it reaches the window length, and only a few global layers grow with context. We count the two parts separately. By default, llama.cpp, Ollama and vLLM all allocate VRAM for these layers only up to the window length.

Model	KV cache at 32K context	Generic formula
GLM 5.3 FlashHybrid linear attention	0.4 GB	96.6 GB
Kimi Linear 48B A3BHybrid linear attention	0.3 GB	8.2 GB
Kimi K3Hybrid linear attention	0.9 GB	224.7 GB
Qwen3.5 9BHybrid linear attention	1.1 GB	4.3 GB
Qwen3.6 27BHybrid linear attention	2.1 GB	8.6 GB
Qwen3.6 35B A3BHybrid linear attention	0.7 GB	2.7 GB
Qwen3.8 27BHybrid linear attention	2.1 GB	8.6 GB
Qwen3.8 Flash NextHybrid linear attention	0.8 GB	3.2 GB
Qwen3.8 2.4T A95BHybrid linear attention	3.1 GB	12.3 GB
DeepSeek V3.2MLA latent attention	2.3 GB	196.5 GB
GLM 4.7 FlashMLA latent attention	1.8 GB	31.5 GB
GLM 5.2MLA latent attention	2.9 GB	125.6 GB
GLM 5.3MLA latent attention	2.9 GB	125.6 GB
Hy4 previewMLA latent attention	2.9 GB	5.2 GB
Kimi K2MLA latent attention	2.3 GB	98.2 GB
Kimi K2.5MLA latent attention	2.3 GB	98.2 GB
Kimi K2.6MLA latent attention	2.3 GB	98.2 GB
Kimi K2.7 CodeMLA latent attention	2.3 GB	98.2 GB
DeepSeek V4 FlashCompressed attention	0.2 GB	2.9 GB
DeepSeek V4 ProCompressed attention	0.3 GB	4.1 GB
DeepSeek V4.1 FlashCompressed attention	< 0.1 GB	2.7 GB
Gemma 4 E4BSliding window 512 tokens	0.6 GB	2.8 GB
Gemma 4 12BSliding window 1,024 tokens	0.9 GB	12.9 GB
Gemma 4 26B A4BSliding window 1,024 tokens	0.9 GB	8.1 GB
Gemma 4 31BSliding window 1,024 tokens	3.5 GB	32.2 GB
gpt-oss 20BSliding window 128 tokens	0.8 GB	1.6 GB
gpt-oss 120BSliding window 128 tokens	1.2 GB	2.4 GB
gpt-oss Safeguard 20BSliding window 128 tokens	0.8 GB	1.6 GB
Llama 4 Scout 17B 16ESliding window 8,192 tokens	2.8 GB	6.4 GB
Muse Spark OpenSliding window 2,048 tokens	2.5 GB	8.3 GB

The "Generic formula" column plugs the layer count, KV head count and head dimension from config.json straight into the formula above, for comparison. We count KV cache in FP16; with FP8 or 4-bit KV quantization enabled at deployment, actual usage is even lower.

Will the model fit in VRAM?

Calculated for a single card with no CPU offload. Unified-memory devices are counted at their full memory size, without deducting the macOS limit on GPU memory use.

Model sizes and memory requirements are given in decimal GB (10⁹ bytes), so they match the file sizes on Hugging Face download pages. Rated GPU and RAM capacities are counted in 1024³ bytes, so a 24GB card holds about 25.8 GB. Both sides are converted to the same unit before the fit check, which is why a requirement slightly above the rated figure can still fit.

Tables on GPU and model pages use three statuses:

• Runs: Fits fully in VRAM; speed is estimated from VRAM bandwidth.
• Needs RAM offload: MoE only: expert weights sit in system RAM, so speed is estimated from 70 GB/s RAM bandwidth.
• Too big: Won’t fit on one card at this quantization, even with RAM offload.

How to estimate inference speed (tokens/s)

Generation speed is mainly limited by memory bandwidth: for every token generated, the active weights and part of the KV cache have to be read from VRAM once. Estimates assume llama.cpp with a single user (single stream):

Bandwidth utilization is 0.73 for every device; fixed overhead is 1.4 ms for dense models and 4.7 ms for MoE models.

The coefficients are calibrated against published llama.cpp benchmarks. These are estimates: real speeds vary with software version, drivers and settings, and longer contexts run slower. This is an estimate of generation (decode) speed and does not include prompt processing (prefill) time.

Multi-GPU and multi-unit setups

Multi-GPU setups are estimated for vLLM tensor parallelism with 1 / 2 / 4 / 8 identical cards. The model weights and the KV cache for a 32K context are split evenly across the cards, each card adds 1.1GB of runtime overhead, and the result is compared with 90% of each card’s VRAM, which is vLLM’s default. The check only looks at memory and ignores whether attention heads divide evenly across the cards, so treat it as a first filter. Whether a model actually runs also depends on vLLM support.

Speed is estimated from one card’s bandwidth; it is not multiplied by the number of cards and does not account for traffic between cards. The total price is the median price of one card times the number of cards and covers the GPUs only, not the motherboard, power supply or case. The interconnect is listed for reference only: cards with NVLink show its bandwidth in the spec table, and the rest communicate over PCIe. The multi-GPU section on GPU pages lists models released from 2026 with at least 50B parameters; the multi-GPU table on model pages lists the GPUs commonly used in multi-GPU builds and the machines that can be clustered, sorted by total price from low to high.

Unified-memory machines cannot take a second card, so most count as one unit. Machines that can be clustered are counted by unit, each using 90% of its memory; speed is based on one unit’s bandwidth, and the total price covers the units only. DGX Spark links over its network ports, with up to three units connected directly and four needing a switch. The 512GB Mac Studio M3 Ultra links over Thunderbolt 5 cables and runs distributed inference with MLX or exo rather than vLLM.

How expert-offload builds are picked

The "What PC or server build do you need to run … locally?" section on each model page gives one build in each of five classes: a home desktop (RTX 5070 + DDR5), dual Xeon E5 (V100 32GB), EPYC DDR4 (RTX 3090 or 4090), EPYC DDR5 (RTX 5090), and, for the largest models, multiple RTX PRO 6000s on dual EPYC DDR5. Within each class we compare GPU models, card counts up to eight, and single versus dual socket, and pick the build with the most generation speed per unit of money; for the largest-model class we pick the fastest build first and use speed per price only to break ties. The GPUs hold the attention, shared experts and KV cache first, then as many expert layers as the remaining VRAM fits; the rest of the experts go to system RAM, filled with the cheapest layout that leaves 10% headroom. If the GPUs can hold the whole model, that is not expert offloading, so it is left to the model page's single- and multi-GPU tables.

Speeds assume software tuned for CPU + GPU hybrid inference, such as ktransformers or ik_llama.cpp; the llama.cpp commands on the model pages run somewhat slower. Dual-socket platforms are estimated at 1.6× one socket: SGLang + KTransformers split the experts across both CPUs so each reads its local memory, measured up to about 63% faster, while plain llama.cpp runs barely faster on two sockets than on one.

The reference build price is the live median price of the GPUs and RAM plus reference prices for the CPU, motherboard and power supply. Reference prices are kept per market: used prices for eBay and Xianyu, new prices for Amazon.co.jp, and new prices for power supplies everywhere. Where a market has no price, we convert the eBay price in US dollars. Reference prices are reviewed every month.

The build cards on the DDR4 and DDR5 pages show theoretical bandwidth: a dual-socket build adds up both CPUs, and with all four slots filled many desktop motherboards have to lower the memory speed to stay stable, so real bandwidth is below the theoretical figure.

Worked example: Qwen3.8 27B on GeForce RTX 4090

Take the Q4_K_M version of Qwen3.8 27B on GeForce RTX 4090 (24 GB of VRAM, 1,008 GB/s of bandwidth) and apply the formulas above step by step:

Qwen3.8 27B falls under "Hybrid linear attention" above, so its KV cache counts only the layers that grow with context and is much smaller than that of a standard model of the same size.

With the same model on the same card, whether it fits often comes down to context length: the longer the context, the larger the KV cache. At 8K context, the estimated generation speed is about 43 tokens/s.

Full results for every quantization level:Qwen3.8 27B · GeForce RTX 4090

Price per GB

Price per GB = median price ÷ capacity, in currency per GB: GPUs are divided by VRAM capacity, RAM by capacity per stick. It is used in the RAM price ranking. Prices are converted to USD before dividing, which gives the same result as dividing first and converting afterwards.

Exchange rates

Prices are recorded in their original currency and converted for display at the daily rate, with USD as the base. Rates are updated daily; when the day's rate is unavailable the most recent valid rate is used and the footer says so. This page is using rates from Oct 21, 2026, source open.er-api.com.

Spec and model data sources

GPU specs come from vendors' official spec pages and datasheets and are cross-checked against Wikipedia's GPU lists; compute figures are always dense (without sparsity). The few values a vendor has not published are derived from public specs and noted in the device description. 57 devices are currently covered.

Model parameters come from the public configuration of each official Hugging Face repository, quantized weight sizes use actual GGUF file sizes, and Ollama tags come from the official library. The catalog currently contains 9 families and 45 versions; new models are added regularly after verification.

Changelog

Prices update every 6 hours and exchange rates daily; the update time shown on a page is the time of the last successful update. Newly added GPUs, new features and fixes to our calculations are listed below:

1. Oct 18, 2026Redesigned build cards: GPU, RAM, CPU, motherboard and power supply are listed separately, and model pages recommend the best-value build in each of five platform classes.
2. Oct 15, 2026Model pages' single- and multi-GPU tables now pick devices by model size, and launch commands add NVFP4 and MLX variants.
3. Oct 14, 2026Improved Xianyu collection: popular GPUs now pick up noticeably more live Xianyu listings, so their prices are steadier.
4. Oct 13, 2026New DDR4 and DDR5 RAM price pages: per-stick prices, price per GB and trends for 22 desktop and server memory specs, plus three server builds for running local LLMs from system RAM.
5. Oct 10, 2026Added Mac Studio M5 Ultra 96GB. Mac spec sheets now list CPU and GPU core counts, memory speed, storage options, weight, model identifier and part number.
6. Oct 9, 2026Added “Share image” to the Share menu on GPU pages: create a price-trend card for that GPU in one click, then copy or download it, or save it straight to your phone.
7. Oct 5, 2026Improved the copy on GPU detail pages, model detail pages and family pages.
8. Oct 5, 2026Recalibrated generation-speed estimates against public llama.cpp measurements, with one set of coefficients for all devices.
9. Oct 5, 2026Model sizes and VRAM needs are now shown in decimal GB, matching Hugging Face download pages.
10. Oct 2, 2026GPU pages now show “eBay deals” under the price chart when the eBay market is selected: hand-picked listings from trusted sellers that link straight to eBay.
11. Sep 28, 2026Added Tesla T10.
12. Sep 27, 2026Launched accounts: log in with Google or an email code, add GPUs to your watchlist from the rankings on the home page, and set price alerts on GPU pages to get an email when the price reaches your target.
13. Sep 24, 2026Redesigned model pages with single-GPU, multi-GPU and expert-offload builds; family pages add VRAM tables for each version.
14. Sep 24, 2026Fixed the VRAM calculation: quants with a published GGUF file now use the file's actual size.
15. Sep 24, 2026Fixed the KV cache calculation: layers that keep no KV are no longer counted, lowering long-context VRAM needs for some models.
16. Sep 24, 2026Added rental prices to GPU pages: on-demand rental per hour, monthly cost at 4, 8 or 24 hours a day, and payback time for buying the card.
17. Sep 23, 2026Added RTX 3060 12GB, RTX 4060 Ti 16GB and Tesla P40.
18. Sep 22, 2026Added A100 80GB PCIe, L40S and H100 PCIe.
19. Sep 19, 2026Added RTX PRO 5500, RTX A6000, RTX 6000 Ada and the modded RTX 4090D 48GB.
20. Sep 13, 2026Launched the price index page.
21. Sep 11, 2026Started tracking DDR4 and DDR5 RAM prices.
22. Sep 9, 2026Added prices from Amazon.co.jp in Japan.
23. Sep 4, 2026VRAMGlass launched, tracking GPU prices on Xianyu and eBay.

Corrections and feedback

If a price, spec or formula looks wrong, send us an email with the page in question and a source link. Once verified, we will correct it promptly and note the change on this page.

hello@vramglass.comX @vramglass