# 5.10 Self-Hosted GPU Payback Calculator

This script answers one practical question: if you buy GPUs to self-host an open-weight model, how many years will it take to pay back the hardware given your usage, your hardware quote, and the cloud API prices you pay today?

It runs a straightforward break-even calculation: take the annual cloud spend your hardware replaces, subtract annual electricity, and divide the upfront hardware purchase price by those annual net savings to get the simple payback period. Depending on what your local hardware is replacing, you can benchmark annual cloud spend in three ways (`compare` in `scenarios.py`):

- `api`: Computes how many output tokens the server generates in a year at full load (or at a given utilization rate) and values those tokens at pay-as-you-go cloud API list prices, accounting for your input-to-output token ratio and prefix-cache hit rate.
- `subscription`: Benchmarks against the annual cost of flat-rate subscription seats.
- `my_bill`: Benchmarks directly against the actual monthly API invoice you pay today. For most individual builders and small teams, this row is closest to reality.

## What You Need

Any computer with Python 3.8 or newer. The script uses only the Python standard library, requires no third-party packages, and makes no API calls or GPU runs.

## How to Run

```bash
cd 5_10_payback
python3 payback.py              # Run the six baseline scenarios plus your MY_SETUP
python3 payback.py --load 0.25  # Set utilization to 25% for the metered API scenarios
```

## What You Should See

The first six scenarios reproduce the baseline table from the July 2026 analysis [*If I Buy GPUs to Self-Host GLM and DeepSeek, How Many Years Until They Pay Back?*](https://yage.ai/share/self-host-glm-deepseek-payback-en-20260729.html):

| Scenario | 100% Load (24/7) | 25% Utilization |
|---|---|---|
| GLM-5.2, 8×H200, $400K, pay-as-you-go API, cold requests (uncached) | 1.15 years | 4.62 years |
| DeepSeek-V4-Flash, 2×RTX PRO 6000, $32.5K, pay-as-you-go API, cold requests (uncached) | 1.77 years | 7.07 years |
| GLM-5.2, 8×B300, $400K–$500K, API with cache discount, agent workload (92% cached input) | 0.19–0.24 years | 0.78–0.97 years |
| DeepSeek-V4-Flash, 2×RTX PRO 6000, $32.5K, API with cache discount, agent workload (92% cached input) | 0.88 years | 3.51 years |
| GLM-5.2, 8×B300, 1 Coding Plan Max subscription seat | Never pays back | Never pays back |
| GLM-5.2, 8×B300, 29 capacity-matched subscription seats | 21.8–27.3 years | Same as 100% load (seat count is converted from full-load capacity) |

After those six rows, the script also prints the seventh template row, `MY_SETUP` (a sample $3,000 RTX 5090 desktop drawing 0.6 kW at $0.18/kWh for 8 hours/day and replacing a $150/month API bill), which pays back in 2.02 years (24.2 months).

Reference console logs recorded on 2026-10-23 are included in `sample_output/`: `sample_output/full_load_20261023.txt` (100% 24/7 load) and `sample_output/load25_20261023.txt` (25% utilization). Because this calculator is pure arithmetic rather than a language-model inference run, there are no separate English-run files in `sample_output/`; both `.txt` logs contain Chinese console labels, while every dollar figure, token count, and payback number matches what `python3 payback.py` and `python3 payback.py --load 0.25` print in English.

Three patterns stand out in this table. First, changing the cloud billing benchmark on the exact same server shifts the payback period from two or three months out to more than twenty years. Second, the cheaper a cloud provider prices cached input tokens, the harder it is for self-hosting to pay back: GLM-5.2's cached input price is roughly 93 times DeepSeek-V4-Flash's, so at the same 92% prefix-cache hit rate, the GLM server breaks even in under 3 months while the DeepSeek workstation takes more than 10 months. Third, the baseline figures assume the machine runs at 100% load 24 hours a day, 365 days a year; dropping utilization to 25% multiplies the metered-API payback period by about four. How busy your machine actually stays usually matters more than the GPU purchase price.

## Using Your Own Numbers

Open `scenarios.py` and edit `MY_SETUP` at the bottom: fill in your GPU or full system purchase quote (`hardware_usd`), full-load system power draw in kW (`power_kw`), local electricity rate per kWh (`usd_per_kwh`), daily active hours (`hours_per_day`), and the actual monthly API spend you pay today for the work moving local (`monthly_api_bill_usd`). If you prefer to estimate from hardware throughput instead, change `compare` to `'api'` and fill in `output_tok_per_s` (measured on your own hardware with the Section 5.7 benchmark script), `input_per_output`, `cache_hit_rate`, and the cloud API prices. You can also copy any dictionary in `SCENARIOS` to add a new comparison row.

Keep a few common blind spots in mind when interpreting the result. Always use measured throughput under your real workload rather than advertised single-stream peak numbers. For `my_bill`, enter only the portion of your monthly API invoice that a local model can genuinely replace; tasks that still need a frontier cloud model remain on your cloud bill. When utilization is below 100%, the script estimates electricity from full-load power draw multiplied by active hours and does not include idle standby power. Finally, the calculator counts only upfront hardware and electricity: data-center rack space, networking, engineering maintenance labor, downtime redundancy, depreciation, and resale value are all excluded, so your real payback period will be longer.