Per-minute GPU billing: what a rented GPU pod really costs and how to keep idle time near zero

How the meter works

Every GPU type on FastInfra GPU Cloud has an hourly price; the pod is metered per minute from the moment it is running until you stop or terminate it. A pod that runs 47 minutes bills 47/60 of the hourly rate. There is no minimum duration and no commitment, and usage is deducted from the same prepaid credits that pay for API tokens, so one balance covers both. The current rates for all 49 GPU types are read from the live catalog:

From hourly rate to monthly reality

Hourly prices look small; multiplied out they are not. A month has about 730 hours, so a single H100 at $3.12/hr left running continuously is roughly $3.12 × 730 per month. The table below applies three utilisation patterns to that arithmetic.

Per-minute billing only pays off if you actually stop the pod between those windows. A nightly batch job that someone forgets to terminate becomes an always-on pod at eight times the budgeted cost.

Where idle time hides

• Provisioning and image pulls. Billing starts when the pod is running; a 10 GB container image pulled on every start is paid-for minutes. Bake dependencies into the image and keep models on a persistent volume.
• Model loading. Loading 70B weights takes minutes. Keep inference pods warm during traffic windows rather than cold-starting per request.
• Low batch utilisation. An inference server handling one request at a time uses a fraction of the GPU. Continuous batching (vLLM, TGI) lifts tokens per second several-fold on the same card.
• Forgotten pods. The most expensive failure mode. Tag pods by owner and set a reminder or a scripted shutdown.

Stop versus terminate

Stopping a pod ends GPU metering but keeps its disk so you can resume with your environment intact; depending on the plan, persistent storage may bill separately at a much lower rate. Terminating releases everything and ends all charges. The right habit is: stop between sessions on the same day, terminate at the end of a project, and keep anything you need to survive termination (checkpoints, datasets) on a volume or in object storage rather than on the pod's root disk. The GPU pods section of the docs lists the lifecycle calls so shutdown can be automated from a CI job or a cron.

Break-even against paying per token

The hosted API bills per token with zero idle cost. A pod bills per minute regardless of load. To compare, convert the pod to a per-token price at your throughput:

pod_cost_per_1M_tokens = hourly_rate / (tokens_per_second × 3600) × 1,000,000

An 80 GB card serving a 70B int4 model with continuous batching at 1,200 output tokens per second aggregate produces about 4.3M tokens per hour; at $3.12/hr that is roughly $3.12 ÷ 4.3 per million output tokens if the pod is saturated. At 10% utilisation the effective price is ten times higher. Compare that with the same model's price on the pricing page, where the median paid chat model is $0.882 per million output tokens. The rule that falls out: steady, high-volume traffic on one model favours a pod; bursty, multi-model or low-volume traffic favours the API.

Reducing the bill without changing hardware

1. Quantise to int4 or int8 so the model fits a cheaper card tier.
2. Use continuous batching and a sensible max-num-seqs so the GPU is busy, not waiting on the network.
3. Right-size context: a 128K max-model-len reserves cache you may never use.
4. Schedule: scale inference pods down overnight if traffic allows; run batch jobs back to back on one pod rather than on several in parallel.
5. Measure: log tokens per second and GPU utilisation; a card below 40% utilisation is a candidate for a smaller tier or for consolidation.

A worked month

A team runs nightly embedding jobs (3 hours on one card), a daytime internal assistant (10 hours on weekdays, one card) and occasional sizing tests (20 hours). That is about 330 GPU-hours. On the same card at one hourly rate the month costs rate × 330, roughly 45% of the always-on figure, with the only discipline being that the assistant pod is stopped at night and the batch pod is terminated when the job ends. Both are one line in a script. The GPU cloud guides cluster covers the sizing side of the same decision.

Budgeting GPU time alongside API tokens

Because pods and API usage draw from the same prepaid balance, the console gives one view of both. Use it to set two alerts: a balance threshold that leaves at least a day of normal spend, and a daily GPU-hours figure above your plan. The second alert is what catches a forgotten pod within hours rather than at the end of the month. For teams splitting work between hosted models and their own pods, tag each pod by project so the GPU line of the bill can be attributed the same way per-key API usage is.

A simple monthly review closes the loop: list pods by total hours, compare each against its utilisation, and move anything under 40% busy either to a smaller card on the GPU Cloud page or back to per-token pricing on the pricing page. The GPU pods API exposes the lifecycle calls, so the review can be a script rather than a meeting.