Hetzner's GEX44 GPU Server at €184/Month: The Break-Even Utilization vs A10/L4 Rental — and the CAPH Catch

€184 a month buys a dedicated NVIDIA RTX 4000 SFF Ada card with 20GB of ECC GDDR6 — enough VRAM to run a 7B-14B parameter model comfortably, or a 32B model at 4-bit quantization. Hetzner has sold that spec, under the name GEX44, at the same price since well before its June 15, 2026 pricing overhaul, which left GPU servers untouched while cloud and dedicated CPU lines jumped as much as 176%. On paper that makes GEX44 the one line item on Hetzner's rate card that got cheaper, relatively speaking, this year.

But "€184/month, unchanged" only answers half the question a team provisioning a GPU node pool actually has. The other half is: unchanged relative to what, and at what usage level does owning that box actually beat renting the same GPU-class capacity by the hour from AWS or GCP? Run the math, and the answer splits sharply by which rental option is on the other side of the comparison — and against one of them, GEX44 never wins at all.

The Break-Even Table​

Converting Hetzner's flat monthly rate into an hourly-equivalent number makes the comparison legible: €184/month ($210 at a ~1.14 EUR/USD rate as of July 2026) divided across a 730-hour month works out to $0.288/hour if the box runs continuously. Below is what it costs to rent the closest hyperscaler equivalent — a single mid-range inference GPU, A10G on AWS or L4 on GCP — by the hour, and the utilization percentage at which GEX44's flat rate crosses over to cheaper than paying per hour for the same class of capacity:

Against AWS's on-demand rate, GEX44 only needs to be busy about a third of the day to already be the cheaper option — run it past that threshold and every additional hour of use is essentially free capacity you already paid for. Against GCP's on-demand rate the bar is a bit higher, just over 40% utilization, still well within what a genuinely production inference service should be hitting. Against AWS spot, GEX44 needs to be running two-thirds of the month before it pays off — a real commitment, but one an always-on tenant workload clears easily.

Against GCP spot at $0.223/GPU-hour, though, the math never crosses. Run the GEX44 box literally every hour of every day — 100% utilization, the best case a fixed-cost box can post — and that's $210/month. The identical 730 hours of GCP spot L4 capacity costs $163. There is no utilization level at which owning beats renting GCP's cheapest published rate; the box loses money against that comparison point from hour zero.

On the caveats built into this table: these are July 2026 US-region snapshot prices, and both on-demand and especially spot rates move — spot in particular has no floor and fluctuates with regional capacity, sometimes by 20-30% week to week. The GPUs aren't spec-identical either: A10G and L4 both carry 24GB of VRAM against the RTX 4000 Ada's 20GB, and L4's newer Ada architecture gives it a real efficiency edge over the older-generation A10G. If anything, that skews the comparison in GEX44's favor less than a flatter reading suggests — a reader paying strictly for VRAM headroom gets even more of it per rental dollar than this table shows.

Sizing Utilization From a Real Workload​

The break-even percentages only mean something once they're translated into an actual request pattern, because "40.7% utilization" isn't a number anyone sets directly — it falls out of how busy the GPU actually is.

Take a concrete case: a tenant running a 7B-parameter model for RAG-augmented chat, serving a business-hours-weighted traffic pattern rather than a flat rate around the clock. A single RTX 4000 Ada-class card, batching two to four concurrent requests, comfortably handles a sustained 2-3 requests per second at the token lengths a typical chat-with-retrieval turn uses — a few hundred input tokens plus a few hundred generated. At an average 4-6 seconds of GPU-busy time per request, realistic for a 7B model at that batch size, a service fielding a modest 15,000 requests per day keeps the GPU actively generating for roughly 20-25 of the day's 24 hours once queuing and batching overlap are accounted for.

Spread that same request volume unevenly across a business-hours-weighted day instead of a flat rate, and busy-time drops to something more like 8-10 hours during the compressed peak window. That's still comfortably north of the ~7 hours/day (29%) needed to clear the AWS on-demand break-even, and close to the ~10 hours/day (41%) GCP on-demand line.

That's the useful reading of the break-even table: a genuinely low-traffic side project — a few hundred requests a day, GPU busy maybe an hour or two — never approaches even the lowest 28.6% threshold and is better served renting on-demand or spot capacity outright. A service with real, sustained daily traffic clears the on-demand break-even almost by default, because "busy enough to justify existing as a hosted service" and "busy enough to justify an owned GPU" turn out to be close to the same bar.

Why the Raw $/Hour Comparison Undersells Spot's Catch​

None of that makes GCP spot the obvious default, and the reason is the same one that applies to every spot-pricing comparison on this kind of list: spot capacity comes with no SLA and no guarantee it's there when a workload needs it. AWS and GCP can reclaim a spot instance with as little as a two-minute warning when their own capacity gets tight, and GPU spot pools — already the most contested inventory on both clouds — are reclaimed more aggressively than general-purpose compute.

That distinction matters enormously for the workload this comparison is actually about. A batch job, a nightly fine-tuning run, or a queue of asynchronous embedding jobs can absorb a preemption and retry — the $/hour savings are real and nearly free to capture. A small-model inference or RAG service sitting behind a tenant-facing API cannot: a preempted spot instance mid-request is a dropped connection, and rebuilding the queue logic to gracefully migrate live inference traffic off a reclaimed GPU is its own engineering project, not a pricing footnote. The break-even table above compares dollar-for-dollar against capacity with two very different reliability guarantees, and the cheaper number only wins the comparison a reader actually cares about if their workload can tolerate losing the GPU without warning.

The CAPH Catch: GEX44 Isn't a Cloud VM​

There's a second asymmetry the dollar figures don't capture, and it matters specifically for a Cluster-API-managed fleet. Hetzner's regular cloud servers — the CX and CCX lines a CAPH-provisioned control plane or worker node pool typically runs on — are Hetzner Cloud API resources: a HCloudMachine request goes out, and a node is running in seconds.

GEX44 isn't in that catalog. It's a Hetzner Robot dedicated server, provisioned through an entirely different account system with its own ordering flow, and it can take hours to days to actually show up rather than the seconds a cloud VM takes. Cluster API Provider Hetzner (CAPH) does support this path — it's reached general availability and is in production use — but it's a structurally different resource type, HetznerBareMetalHost, requiring its own management-cluster wiring and, unlike a fungible HCloudMachine, a one-to-one relationship to a physical box someone has to actually order ahead of time.

Autoscaling a GEX44 node pool the way a CPU node pool autoscales — spin up a fresh node the moment demand crosses a threshold — isn't how the underlying inventory works. A tenant's inference workload spiking past the break-even utilization threshold doesn't get an extra GPU node ten seconds later; it gets one whenever the next Robot server order clears provisioning.

What This Means for a Self-Hosted PaaS's GPU Roadmap​

Put the numbers and the provisioning model together and the guidance for a self-hosted platform's GPU node pool design gets specific rather than directional. GEX44-backed node pools are a genuinely good default for tenants running always-on small-model inference or RAG services clearing the 28-40% utilization range against on-demand hyperscaler pricing — which describes most production inference workloads serving live traffic, since a service worth keeping around at all is usually busier than a third of the day. For that tenant, a flat-rate owned GPU is the right primitive, and the CAPH bare-metal provisioning lead time is a one-time cost paid when the node pool is first sized, not a recurring one.

The GEX44 default breaks down for two tenant shapes: genuinely bursty, spiky demand that never approaches the break-even threshold — training runs, batch embedding jobs, anything that can tolerate preemption — and workloads specifically chasing the absolute cheapest hourly rate available, where GCP spot's $0.223/hour undercuts even a fully-utilized owned box. Neither of those is a case for standing up a managed GPU rental layer on top of a self-hosted platform — that would just re-create the per-GB, per-hour markup this list keeps finding on the hyperscaler side of every other comparison. It's a case for routing that specific workload to hyperscaler spot capacity directly and reserving the owned GEX44 node pool for the always-on tenant traffic the break-even math actually favors.

Bex.co is the open-source, AI-native Render alternative — push a git repo, get a running HTTPS service on machines you own, provisioned through Cluster API onto the same Hetzner fleet this post priced against hyperscaler GPU rental. Star the repo on GitHub or deploy your first app today.