Research-backed calculator guide

Quantization ROI: Quality, Throughput, and Cost on One Frontier

Calculate LLM quantization cost per token by combining quality thresholds, measured throughput, GPU count, utilization, and serving overhead.

What “cost per token” should include

For self-hosted inference, a practical unit-cost formula is:

all-in hourly cost = (GPU count × GPU $/hour) + fixed hourly overhead
usable tokens/second = measured sustained tokens/second × utilization factor
cost per 1M output tokens = all-in hourly cost × 1,000,000
                           ÷ (usable tokens/second × 3,600)

The utilization factor is an explicit planning assumption, not a vendor quote. Use it when the benchmark throughput is a peak or lab number and your production traffic will not keep the deployment equally busy. If throughput was already measured under your intended production traffic shape, do not apply the factor a second time. That distinction prevents a common error: making a quantized model look cheap by using an optimistic tokens-per-second number and then making it look expensive by discounting it twice.

“Output tokens” also needs a definition. Decode throughput and prefill throughput behave differently. A long prompt can make prefill the bottleneck, while a long generated answer can make decode the dominant meter. Measure both if your service has materially different prompt and completion lengths. Include retries, rejected requests, warm-up, and idle capacity when they are real parts of the serving design. Exclude one-time quantization or calibration work from steady-state cost unless you are calculating a migration payback period; if you include it, show it separately.

Quantization can lower memory pressure, but the realized speedup depends on kernels, hardware, batch size, and whether dequantization overhead offsets the reduced data movement. NVIDIA’s TensorRT documentation lists INT8, weight-only INT4, FP8, and FP4 support and explains that lower-precision representations can reduce memory footprint and accelerate computation. ^[3] That is a capability statement, not a promise that every model gets the same throughput. The deployment benchmark remains the authority for your workload.

How to build the quality-throughput-cost frontier

Start with an unquantized reference. BF16 or FP16 is not “true quality”; it is simply the baseline against which the quantized candidates are compared. Use a held-out evaluation set that reflects production tasks: customer intents, languages, tool calls, structured outputs, code, or reasoning cases. Track a primary score and failure rates that matter operationally. A single aggregate score can hide a severe regression in a high-value slice.

Next, set a hard quality gate. For example, require a candidate to retain at least 98% of baseline score and keep structured-output failures below 1%. The exact threshold is a business and product decision. Do not convert a vendor’s phrase such as “minimal accuracy impact” into your threshold without measuring your own prompts. Oracle’s production article is useful because it describes benchmarking server throughput, request-level behavior, quality recovery, and Pareto analysis together, but its reported figures are tied to its models and deployment conditions. ^[4]

Then measure throughput under a declared traffic shape. Record concurrent requests, batch size, prompt-token distribution, generated-token distribution, maximum context, and whether the number is aggregate across all GPUs. A quantized model can win on single-stream latency and lose on server throughput, or improve decode while hurting prefill. Compare the same metric at the same operating point.

Finally, plot cost against quality and mark constraints. A candidate below the quality gate is infeasible even if its cost per token is excellent. Among feasible candidates, remove dominated options: if candidate A costs more and has lower quality and lower throughput than candidate B under the same test, A has no economic reason to remain. Keep candidates with different strengths when the workload may change, such as an FP8 option that protects quality and an INT4 option that is cheaper for a low-risk traffic slice.

The software path matters. Hugging Face’s selection guide identifies bitsandbytes as easy to use but says speedup is not guaranteed, while GPTQ and AWQ can provide good 4-bit accuracy with upfront calibration. ^[2] vLLM’s compatibility table also shows that support varies across Volta, Turing, Ampere, Ada, Hopper, AMD, Intel, and CPU targets. ^[1] Therefore, “INT4” is not a complete benchmark identity. Record the format, weight/activation scheme, calibration method, kernel or engine, GPU architecture, and software versions.

Worked cost example

Assume a team serves one model with the same prompt mix and a 98% quality-retention gate. The numbers below are illustrative estimates, not vendor quotes. GPU price is assumed at $3.20 per GPU-hour, fixed host and platform overhead is $0.80 per deployment-hour, and the planning utilization factor is 70%. Throughput is a measured lab estimate at the declared workload before applying that planning factor.

For BF16, all-in hourly cost is (4 × $3.20) + $0.80 = $13.60. Effective throughput is 120 × 0.70 = 84 tokens/second. Its estimated unit cost is $13.60 × 1,000,000 ÷ (84 × 3,600) = $44.97 per million output tokens.

For FP8, the same calculation is ((2 × $3.20) + $0.80) × 1,000,000 ÷ (190 × 0.70 × 3,600) = $15.04. It passes the 98% gate, so it is the recommended point in this illustrative frontier. It is about 66.6% cheaper than BF16 under these assumptions, calculated as 1 - 15.04 / 44.97.

INT4 appears cheaper at $6.90 per million output tokens, but its 97.4% quality score fails the declared gate. Calling it the “winner” would turn a unit-cost calculation into a quality regression. It could become viable for a separate low-risk traffic slice with a lower acceptance bar, or after calibration and kernel changes improve the measured score. A research system such as FireQ illustrates why implementation details matter: its INT4-FP8 design combines quantized weights and activations with scaling and specialized kernels, and reports throughput comparisons alongside accuracy evaluation. ^[5]

The example also shows why GPU count alone is not enough. FP8 uses twice as many GPUs as INT4 but remains the feasible choice because quality is a constraint. If the workload becomes prompt-heavy, repeat the test with prefill latency and prompt-token throughput rather than reusing the decode number. If traffic falls below the assumed 70% utilization, every candidate’s cost rises; a warm pool, autoscaling policy, or shared deployment may change the ranking.

For a broader infrastructure estimate, pair this guide with the Self-hosted GPU inference cost calculator. Use the Model pricing comparison when the alternative is a hosted API, and use the RAG, embedding and vector database cost calculator when retrieval adds material per-request cost. If quantization is part of a larger build, the AI agent development cost estimator can keep one-time engineering work separate from recurring inference TCO.

Common mistakes in a quantization ROI calculation

Treating bits as a speed guarantee. Four-bit weights may reduce memory, but a kernel can spend time packing, unpacking, or dequantizing. Benchmark the deployed engine, not only the checkpoint size.

Using a benchmark score without a quality gate. A 1-point average improvement or decline may conceal a failure on tool calls, safety behavior, or a key language. Segment the evaluation and retain the worst important slice.

Comparing different operating points. Do not compare FP8 at batch 16 with INT4 at batch 1 and call the result a universal frontier. Keep concurrency, context, output length, and latency target visible.

Ignoring fixed capacity. A one-GPU deployment can have a lower variable cost but still require a second warm replica for availability. Model the production topology, including idle replicas and failover, when making a capacity decision.

Mixing vendor quotes with estimates. A GPU list price, a cloud rental price, and an internal blended rate are different inputs. Label each one, date changing prices, and show whether tax, egress, storage, platform fees, and engineering amortization are included.

Confusing macro price trends with your TCO. Historical price trends can frame the question, but they do not replace a current benchmark for your model, GPU, traffic, and quality bar.

FAQ

Is INT4 always cheaper than FP8 per token?

No. INT4 often has a lower memory footprint, but cost per token depends on GPU count, throughput, utilization, kernel efficiency, and fixed overhead. More importantly, an INT4 candidate that misses the task-quality gate is not a feasible replacement. Compare only candidates that meet the same quality and latency requirements, or label a lower-quality deployment as a different product tier.

Should quality be measured as accuracy or as a retained percentage?

Use both when possible. Retained percentage, such as quantized score ÷ BF16 score, makes cross-model comparisons easier. Absolute score and slice-level failures preserve operational meaning. A candidate can retain 98% of a high baseline and still fail a critical structured-output or tool-use test. Set the gate from the user outcome, then report the baseline and quantized scores beside it.

Does lower precision reduce latency as well as memory?

It can, but it is not guaranteed. Lower-precision arithmetic and less data movement may help, while dequantization, unsupported kernels, or a workload that is compute-bound rather than memory-bound can reduce or erase the benefit. NVIDIA documents several supported low-precision data types, and vLLM documents hardware-specific compatibility; neither means every model and workload will have the same speedup. ^{[1] [3]} Measure prefill, decode, time to first token, and sustained throughput separately.

How should I include utilization in cost per token?

State whether throughput is a peak benchmark or an observed production rate. If it is peak throughput, multiply by a planning utilization factor such as 70% to model the average usable rate. If the throughput already comes from the intended production traffic and includes idle periods, do not discount it again. Also model reserved warm capacity and failover separately when those are required for the service-level objective.

Should calibration and migration work be included in quantization ROI?

Include it when you are calculating payback, but keep it separate from steady-state cost per token. A useful migration view is one-time quantization, evaluation, and rollout cost ÷ monthly steady-state savings, with the quality and rollback risk shown beside the result. Calibration can affect quality and throughput, so the final production benchmark should use the exact calibrated artifact and serving engine rather than an uncalibrated prototype.