If I Buy GPUs to Self-Host GLM and DeepSeek, How Many Years Until They Pay Back?

Open-weight models such as Kimi K3, GLM-5.2, and DeepSeek-V4-Flash have reached capabilities very close to top-tier closed-source models. In many everyday development and routine business scenarios, quite a few teams are already putting them to use.

In settings that do not require physical isolation for strict compliance, everyone eventually confronts a very practical choice: use the vendor’s monthly subscription seats, call the cloud API directly, or buy GPUs and set up self-hosted nodes?

If you buy your own hardware and self-host, how long does it take to break even?

Pundits give wildly divergent answers to the self-hosting payback period — some say two months, some say over a year, and some say more than twenty years. None of these calculations are actually wrong; the core discrepancy lies in misaligned baselines: self-hosting itself has no fixed physical payback period. How fast or slow it recovers its cost depends entirely on which cloud billing product you are using it to replace.

Pure Single Requests: Baseline Without Caching

Setting aside the discount from prefix caching (Prompt Cache) and looking only at the cold-start baseline where every request is an independent invocation, self-hosting replaces the standard full-list-price cloud API on a pay-as-you-go basis.

Start with GLM-5.2. In enterprise deployments, this scenario typically uses an 8×H200 node. This is dictated by the model’s parameter scale: GLM-5.2 has roughly 753B total parameters and 40B active parameters; FP8/W4A16 weight memory usage approaches 750 GB, and together with the KV Cache generated during 1M-context inference, the total node VRAM overhead exceeds 1 TB. Equipping 8 H200 GPUs (141 GB HBM3e each, 1,128 GB total high-bandwidth VRAM) and running 8-way tensor parallelism (TP8) over NVLink yields high-throughput operation. The planned procurement cost for one such standard 8×H200 node is approximately $400,000.

At the U.S. EIA commercial electricity rate ($0.1354/kWh, including facility power at PUE=1.2), the annual electricity cost for this node is roughly $14,200. Based on Phala test data under an 8K-input, 1K-output workload, the node’s aggregate throughput reaches 733 output tok/s.

In the cloud API’s full-list pricing, GLM input is $1.40/M and output is $4.40/M. Converted at an 8:1 input-to-output ratio, each 1M output tokens corresponds to a cloud API list price of $15.60. Under the assumption of 24-hour full-load operation, the annual token output of an 8×H200 node translates to roughly $360,600 in theoretical cloud API list-price equivalent (note: this figure is the theoretical equivalent obtained by multiplying full-load capacity by the list price and does not represent cash outflows the team would necessarily have incurred). After deducting the $14,200 electricity cost, the hardware payback period is 1.15 years.

The hardware requirements for a desktop-class multi-GPU setup (taking DeepSeek-V4-Flash as an example) are entirely different.

DeepSeek-V4-Flash adopts the Flash MoE architecture (roughly 284B total parameters, 13B active parameters), with official FP8 weights occupying about 159.6 GB of VRAM. Using two 96 GB RTX PRO 6000 Blackwell desktop-class GPUs (192 GB total VRAM across two cards) allows the official weights to reside entirely in VRAM along with KV Cache operation, at a hardware cost of $32,500.

The whole-machine power consumption is roughly 0.85 kW. At the residential electricity rate ($0.1844/kWh), the annual electricity cost is $1,373. According to a public LinkedIn running record, the system achieves a prefix read speed of 10,000 in/s and 697 decode/s, yielding a serially converted aggregate throughput of roughly 447 output tok/s (note: this is a serial conversion value for the prefix and generation phases computed separately, not an end-to-end measured figure).

DeepSeek’s cloud full-list pricing is $0.14/M for input and $0.28/M for output. At the 8:1 ratio, each 1M output tokens corresponds to an API list price of $1.40. Full-load annual output translates to roughly $19,800 in theoretical API billing equivalent. After deducting the electricity cost, the payback period is 1.77 years.

In this cold-request baseline scenario, the payback period for these two representative cases benchmarked against public API list prices falls within a range of 1.15 to 1.77 years.

Agent Scenarios: The Multiplier Effect of Cloud Cache Unit Pricing

The picture changes once we enter multi-turn agent interaction scenarios. Multi-turn conversations carry very long conversation histories, and every interaction re-reads the content of preceding turns.

Here, we cannot simply reuse the throughput data from the no-caching scenario above, because Prompt Cache (prefix caching) changes not only billing but also the physical operating speed of the GPU. In very long conversations, if the prefix has to be re-read from scratch each time, the compute latency becomes very high. Once a cache hit occurs, the GPU can directly reuse the KV Cache already in VRAM, and the prefix read completes almost instantly — the machine’s entire throughput profile is fundamentally different from the cold-start case. We must therefore use measured or projected data specifically designed for long-context cache replay.

Referring to the LMSYS SGLang replay test using a fixed OpenHands replay dataset, a typical agent task involves 13 conversation turns, with an average of 80,000 logical input tokens and 220 output tokens per turn, yielding a logical input-to-output ratio on the order of 300 to 400:1 (roughly 363.64:1).

Cloud APIs universally offer Prompt Cache discounts for this kind of long-context usage. Assume 92% of logical input tokens hit the cache and are billed at the cheaper cache price, with only 8% billed as fresh input.

At this point, the cloud API’s discounted cache unit price becomes the core lever that widens or narrows the payback period.

Compare the two providers’ cloud cache unit prices: - Z.AI pricing: GLM cached input is $0.26/M. - DeepSeek API pricing: DeepSeek cached input is $0.0028/M.

GLM’s cloud cache unit price is nearly 93 times that of DeepSeek. This price differential directly bifurcates their respective payback periods:

For GLM-5.2, to remain aligned with the LMSYS official SGLang measured dataset (which reports 500 output tok/s throughput on an 8×B300 node), the hardware is an 8×B300 node, with a third-party DGX B300 complete system used as an economic substitute reference (planned cost $400k–$500k, whole-machine power 14.5 kW, including facility power at PUE=1.2, annual electricity roughly $20,600).

On the cloud API side, GLM uncached input is $1.40/M and cached input is $0.26/M. Under the assumption that 92% of input is billed at the cache rate, the blended average input unit price drops to $0.3512/M (an overall reduction of approximately 74.9% from the full input unit price). Combined with the 363.64:1 input-to-output ratio, the theoretical API fee corresponding to generating 1M output tokens is $132.11. The full-load annual token output of this B300 node would cost roughly $2,083,100 at cloud theoretical API list price. After deducting the $20,600 electricity cost, the hardware payback period is 0.19 to 0.24 years (2.3 to 2.9 months).

For DeepSeek-V4-Flash, in the absence of an equivalent OpenHands replay test, a staged projection estimate is used: under the same assumption of 92% prefix reuse (serially converted throughput of approximately 230 output tok/s), because DeepSeek’s official cache price is extremely cheap ($0.0028/M), the blended input unit price under 92% cloud caching is only $0.013776/M, meaning the theoretical cost of running long-context workloads in the cloud is already inherently very low. The annual token output of the dual-GPU node corresponds to only roughly $38,400 in theoretical cloud billing. After deducting the electricity cost, the payback period is 0.88 years (roughly 10.5 months).

The logic is crystal clear: the cheaper the cloud API’s cache unit price, the lower the cost of running long-context workloads in the cloud; the smaller the differential you save by buying hardware to replace the cloud bill, and correspondingly the slower the self-hosted hardware payback.

Subscription Seat Benchmark: The Arithmetic Truth Under Equivalent Quota

If the team does not usually use the API and instead purchases monthly subscription seats for employees (such as Coding Plan Max), running the self-hosting numbers yields a result entirely different from the API lens.

A single Coding Plan Max seat costs $1,344 per year. If you directly compare a $400k–$500k 8×B300 node against one subscription seat, the node’s annual electricity cost ($20,600) already exceeds the seat’s annual fee, yielding a negative annual net return (−$19,294).

Such a comparison ignores usage alignment: the token quota allowed per single subscription seat has an upper bound (the normal ceiling for a single seat is roughly 8,000 uses per week), and the usage volume permitted by one seat is far lower than the full-load output capacity of an entire node. To make a fair comparison, usage on both sides must be equalized — that is, calculate how many subscription seats, at the quota ceiling, would be needed to produce the total token output of this node.

At 500 tok/s full load, a single 8×B300 node produces 302 million output tokens per week (roughly 10.5K protocol segments of 13-turn OpenHands conversations). Referring to the quota deduction rules in the DevPack FAQ (daily 4-hour peak period at 3× deduction, 20-hour normal period at 2× deduction, yielding a weekly weighted deduction coefficient of approximately 2.1667×), the node’s output capacity, when mapped into the subscription system, consumes roughly 229,100 quota uses per week.

According to the DevPack documentation, the normal weekly quota ceiling for a single Max seat is roughly 8,000 uses. Digesting this node’s full-load capacity mathematically requires at least 29 Max subscription seats.

The annual subscription cost for 29 seats is $38,976. After deducting the node’s annual electricity cost of $20,600, the actual amount saved each year is only $18,338. Against a $400k–$500k hardware investment, the payback period under the equivalent-quota lens instantly stretches to 21.8 to 27.3 years (roughly 22 to 27 years).

This reveals the fundamental difference in pricing mechanisms between API billing and flat-rate subscription plans: cloud APIs charge linearly by usage, whereas monthly subscription seats embed a large bundled discount into the per-person pricing. Using self-hosted hardware to replace monthly subscription seats stretches the payback period from a few months under the API lens to over twenty years.

Summary and Calculation Panorama

How long self-hosted hardware takes to pay back has never been determined by the price of the GPUs themselves; it depends on the characteristics of your business workload and which cloud billing model you are using it to replace.

Below, the physical parameters, operational electricity costs, and payback period estimates across different scenarios are compiled into a summary table for reference during architecture selection and procurement evaluation:

Note that the above estimates assume 24-hour full-load node operation and include only hardware procurement and basic electricity costs (the theoretical API list-price equivalent merely represents the theoretical equivalent obtained by multiplying full-load capacity by the list price and does not represent realized cash savings). In actual deployment, hidden costs such as rack rental, network bandwidth, operations labor, and downtime redundancy must also be factored in.

The true starting point for evaluating self-hosting ROI is understanding your team’s real context repetition rate, the cloud cache discount unit price, and whether you are replacing API billing or flat-rate subscription seats.