Skip to main content
Deployments consume GPU credit while their replicas are running. Billing is metered per replica: each GPU box charges from its launch (warmup included) until it’s terminated, so a deployment that scales from 1 to 3 replicas and back pays for exactly the box-minutes that ran.

​
Billing cadence

Charges accrue per minute while any replica is up. When you call stop — or a min_replicas: 0 deployment parks itself — Veri settles each replica up to the moment its GPU was freed.

​
Billing states

​
Avoiding idle bills

A deployment with min_replicas of 1 or more (the default) keeps its warm floor running until you stop it — that’s what you asked for, so there’s no idle auto-stop on those. Options, from most to least automatic:
  1. Create with min_replicas: 0 — the deployment parks itself (scaled_to_zero, $0) after its idle window (scale_to_zero_window_seconds, default 1 hour) and wakes on the next request. Expect a multi-minute cold start on the first request after parking.
  2. Add idle_delete_after_days — a parked deployment with no traffic for that many days is auto-stopped for good.
  3. Wrap deployments in try/finally — guarantees stop even if your code errors:
  4. Monitor active deployments — regularly list deployments and stop anything no longer in use.
  5. Set up the low-balance webhook — Stripe will email at configurable balance thresholds

​
Comparison vs training jobs

Training jobs run for a fixed duration and stop themselves. Deployments run until you stop them. If you only need to evaluate a trained model, consider running an eval (which uses an existing deployment briefly) and stopping the deployment immediately after.

​
Where to go next

Hosting & GPU sizing

Pick the right GPU before deploying.

OpenAI compatibility

What works, what doesn’t.

Deployments API

create / stop endpoints.

Deployment analytics demo

Planned walkthrough for request, token, latency, and replica metrics.