What the calculator evaluates
LLMGauge accepts a hardware profile, a catalog model, and a quantization candidate. It estimates weight memory from cataloged model or file-size inputs, applies named overhead assumptions, and compares the result with available memory.
The recommendations workflow sends the same hardware profile through the same compatibility engine for each catalog candidate. The GPU comparison workflow asks for one model and an explicit system RAM amount, then evaluates each catalogued discrete GPU with the existing representative-quantization policy. It does not use a separate formula or a hidden ranking model.
Context targets and supported KV-cache estimates
A context target is optional and must be entered or selected explicitly. Both workflows offer 4,096, 8,192, 16,384, and 32,768 token presets; they are quick choices, not defaults. LLMGauge does not infer a target from a model's published default or maximum. In recommendations, the target is evaluated against each model's own documented maximum. A target above that maximum makes the estimate unavailable, and the maximum does not mean the user's hardware can run that context.
For supported sourced architectures, LLMGauge estimates the FP16 key-value (KV) cache using 2 × transformer layers × KV heads × head dimension × 2 bytes × target context tokens, divided by 2^30 to get GiB. The supported text-only Llama catalog entries are Llama 3.1 8B Instruct, Llama 3.2 1B and 3B Instruct, and Llama 3.3 70B Instruct. Other supported entries are dense Qwen3 4B, 8B, 14B, and 32B, Qwen3-30B-A3B-Instruct-2507, and Qwen3-Coder-30B-A3B-Instruct. Cache estimates remain unavailable for other architectures.
Displayed cache sizes are rounded for readability; fit decisions use the underlying unrounded values. An unavailable estimate is not treated as zero.
When the cache enters the fit decision
Cache memory is counted only when the chosen execution settings establish its placement: explicit CPU execution counts it in system RAM; an explicit full-GPU choice with CUDA or Vulkan and a discrete GPU counts it in VRAM; Apple unified-memory mode counts it in its single memory pool.
Automatic, partial-offload, and otherwise unverified placements remain visible as advisory cache estimates but are excluded from fit accounting. The application does not know how a particular runtime allocates the cache.
What the result categories mean
These labels describe memory planning, not speed, quality, driver compatibility, or a guarantee that a particular downloaded file will run.
- GPU-capable: the estimate fits the available dedicated GPU memory under the current policy.
- Partial offload: the full estimate does not fit dedicated VRAM, but the combined memory picture allows a conservative split between GPU and system memory.
- CPU-only: the model is planned for system memory without relying on a discrete GPU, including the current conservative treatment of integrated graphics.
- Unsupported: the candidate exceeds the available memory pools or has no valid quantization candidate that fits.
Why an estimate is not a guarantee
Real requirements vary with the exact model file, quantization conversion, target context, runtime version, backend, driver, operating system, display use, and other programs competing for memory. A documented context maximum is not a prediction that the selected hardware can use it.
LLMGauge uses sourced catalog metadata and explicit assumptions. It does not benchmark your computer, verify that a backend supports a model, or promise a particular memory allocation or performance.
Use the result as a starting point, then verify the exact model and runtime on your own system. Leave extra memory headroom when a result is close to the boundary.