GPU
GPU Serving Payback Calculator
GPU serving payback uses only source-backed catalog inputs for speed and list prices: measured output tokens/s from the GPU throughput table, revenue rates from official price records, and vendor TDP for power. Hardware purchase CAPEX is not in the ByteCosts catalog - you enter a verified quote. Payback days = (hardware + setup − residual) ÷ (rate-card revenue − electricity − ops) per day. If CAPEX or positive net revenue is missing, daily revenue still computes but payback stays undefined.
Open the live GPU Serving Payback calculator - Payback days from serving revenue →
Why this matters now
Self-host ROI posts often mix measured TPS with invented CAPEX or unscoped list prices; this tool keeps those layers separate and labeled.
ByteCosts already stores measured throughput and official token rates - this calculator only combines them with your capital quote.
Example scenario
Pick a catalog scenario such as MiniMax-M3 on H100 or H200, or gpt-oss-120b on H200/B200. Throughput and the benchmark I/O shape come from data/gpu/gpu-throughput.json with a public source URL. List rates prefer first-party records (for example MiniMax paygo or Amazon Bedrock gpt-oss-120b). Enter your server purchase price to turn net daily revenue into payback days.
What the inputs mean
- Source-backed scenario: One row from the measured GPU throughput catalog, paired with a preferred official price record for the same model id.
- Hardware purchase price: Your CAPEX quote. ByteCosts does not invent workstation or server MSRPs.
- Utilization: Planner fraction of the day spent at the measured sustained output rate (same class of knob as other GPU tools; not measured in the throughput file).
- Electricity $/kWh: Optional. Defaults to excluding power cost until you set a local rate. TDP watts default from the vendor GPU spec.
What the result means
Headline CAPEX payback in days when capital and positive net revenue exist. Supporting stats: tokens/day, gross revenue, power+ops, net/day, and provenance links for throughput, pricing, and TDP.
Assumptions
- Output tokens/s is the catalog totalTokensPerSec (generation throughput) at the source workload shape - not a roofline estimate.
- Input tokens/day use the source workload input/output ratio unless you override the ratio (then treat results as planning-only).
- Prefill tokens/s is unused unless the catalog provides it or you enter a measured prefill rate (serial mode).
- List rates are serving revenue scenarios, not a guarantee you can sell capacity at that price.
- Purchase CAPEX, electricity rate, and utilization remain user or planner inputs.
Where the prices come from
Revenue rates are taken from committed price-records with a first-party preference order per model, each carrying sourceUrl and lastCheckedAt. Throughput rows always carry sourceUrl and sourceConfidence. No values are taken from social posts.
Formula and methodology
Active seconds/day = 86,400 × utilization. Output tokens/day = active seconds × measured output tok/s. Input tokens/day = output × (source input tokens ÷ source output tokens). Gross revenue = input×blended list input rate + output×list output rate (per 1M). Net/day = gross − energy − ops/day. Payback days = net capital ÷ net/day when both are positive.
Interpretation guide
- Compare alternatives with the same workload assumptions.
- Stress-test output-heavy, retry-heavy, cache-miss, and power-user cases before committing budget.
- Verify source links and production logs before using the estimate for billing decisions.
Limitations before production billing decisions
Treat ByteCosts calculations as planning estimates, not final billing totals. Real invoices can differ because token mix, retry rate, cache hit rate, rate limits, taxes, gateway fees, regional pricing, and negotiated discounts change the effective cost.
Verify the provider source before production billing decisions, then compare the estimate with your own logs or invoice once production traffic is live.
Frequently asked questions
Where do the numbers come from?
Output tok/s and workload shape: data/gpu/gpu-throughput.json (measured only). List rates: data/index/price-records.json with first-party preference. TDP: data/gpu/gpu-specs.json vendor pages. CAPEX and $/kWh: you enter them. Nothing is copied from social media posts.
Why is hardware price empty?
The GPU pricing index tracks rental $/GPU-hour, not server purchase MSRP. Inventing a DGX or workstation price would be unsourced. Enter a quote you trust to compute payback days.
How is this different from Hardware vs API Payback?
Hardware vs API Payback models cost avoided (you stop paying a host). GPU Serving Payback models revenue if you serve at a published list rate after power and ops.
Do you have separate prefill and decode speeds?
Only when the throughput catalog includes them. Current measured rows report output generation tok/s at a stated I/O shape; prefill is null unless sourced. You may enter a measured prefill rate to switch to serial prefill+decode accounting.
What if my utilization or electricity is wrong?
They are planner inputs. Leave electricity at 0 to exclude power; set your utility rate to include it. Utilization is the share of the day at the measured sustained rate - document the assumption with any shared result.
GPU Serving Payback Calculator. ByteCosts. https://bytecosts.com/tools/gpu-serving-payback/