monkA healthtech team stopped paying for GPUs it wasn’t using.
A healthtech team kept GPUs running because a cold start took twenty minutes. Monk keeps the models warm across approved regions, finds available capacity and starts a pod in about a minute. When the work ends, the pod goes.
- Customer
- Healthtech company, name withheld
- Workload
- Custom voice and video models, real-time inference
- Infrastructure
- RunPod and Cloudflare R2, on the customer’s own accounts
Warm the region
A CPU pod costing cents an hour copies the current models from R2 onto that region’s network volume and verifies them.
Start where the stock is
Monk reads live GPU availability, picks a region from the customer’s approved list and starts the pod on the warm volume.
Delete the pod
Work stops, the pod goes, GPU billing stops. The volume stays warm for the next start.
Why nobody turned it off
Three RunPod facts combine badly for anyone running a large model. Network volumes are pinned to one datacenter, so a pod somewhere else cannot mount them. Capacity for a given GPU type changes by the minute: over six weeks of building this, every GPU type we had marked as working came back “no instances available” at least once. And stopping a pod does not reserve its GPU, so a restart can fail because the host filled up in the meantime.
Loading the environment in a cold region takes about twenty minutes: several models plus a few hundred gigabytes of pre-generated data. That is short enough to sound tolerable and long enough to rule out starting a pod on demand. Finding an available GPU by hand took another ten minutes or so each time. The rational move was to hold the machine they had and pay for the idle half.
A warm cache makes the pod disposable
Cloudflare R2 holds the datasets, weights and checkpoints. A small manifest points at the current state, and it only moves forward once the data behind it has landed, so nothing ever points at a checkpoint that does not exist.
Each region keeps its own copy on a network volume, refreshed by a CPU pod that costs cents an hour. Warming a region spends CPU time instead of GPU time. When a GPU pod starts there, everything it needs is already on local disk.
Monk’s placement entity reads live GPU stock and the datacenters that support the volume type, then chooses from the regions the customer approved. The ten-minute hunt takes about a second. A scheduler or a coding agent drives the whole cycle through a small up, down and status wrapper that speaks JSON.
The RunPod and Cloudflare keys never enter the agent’s context, pods carry an ownership marker so Monk will not terminate anything it did not create, and every destructive action waits for a named human.
What it costs against the always-on bill
Absolute figures stay with the customer. Indexed to their always-on pod, the modeled result is about 45% off. Keeping four regions warm costs 8 to 13% of the gross saving.
The saving grows at a lower duty cycle. At genuine round-the-clock production traffic it disappears on this line, and the value moves to being able to serve from whichever region has capacity.
About 45% lower at this customer’s target duty cycle, including warm-cache overhead. Inputs confirmed September 2026; not a general savings guarantee.
| Line | Index |
|---|---|
| Always-on multi-GPU pod, 24/7 | 100 |
| GPU time at the customer’s target duty cycle | 50 |
| Warm volumes in four regions | about 1 |
| Cache refresh compute and R2 storage | 3 to 5 |
| Total with Monk | about 55 |
What changed for the team
“No instances available” in one region is now a routing decision instead of an outage. Four to eight developers ship without a DevOps hire.
The stack is described in Monk templates that live alongside the source, so the people who eventually inherit the platform run the same templates. For a buyer with a compliance review, the useful parts are the ones Monk does by default: approvals by a named human in a separate interface, credentials kept out of the model’s context, and an audit trail of who approved what.
Explore the implementation.
Put your GPU workload in motion.
Connect the compute, data and placement rules in your own accounts.