The short answer: two providers quoting the same ₹/GPU-hour figure can charge very different amounts for the same job if one meters by the second and the other rounds every session up to a full hour. For long, continuous runs the difference is small. For short, bursty or interactive work it can be a multiple of the sticker price, and it never shows up in the headline rate.
Three billing models you will meet
Providers generally fall into three groups. Per-second or per-minute metering charges for the time an instance is actually running, so a 20-minute job costs one third of the hourly rate. Per-hour metering rounds usage up to the next full hour, sometimes per session and sometimes per billing cycle. Monthly-only commitments quote an hourly-looking figure that is really a monthly total spread over roughly 730 hours; that model is covered in this site's reserved vs on-demand analysis. Which group a listing belongs to is stated on each provider's own pricing page, and it is worth confirming rather than assuming.
Worked example with a hypothetical rate
The numbers below use an illustrative round rate of ₹100 per GPU-hour. It is not any provider's price; it exists only to show how the arithmetic behaves. Substitute the live rates from the compare table.
- One 20-minute job. Per-second billing: about ₹33. Hourly rounding: ₹100. The hourly model costs three times as much for the same compute.
- Six 20-minute jobs spread across a day, each in a fresh session. Per-second billing: 2 hours of usage, ₹200. Hourly rounding per session: 6 billed hours, ₹600.
- A 61-minute training run. Per-second billing: roughly ₹102. Hourly rounding: 2 billed hours, ₹200. Crossing an hour boundary by one minute nearly doubles the charge.
- A 10-hour continuous run. Both models bill about ₹1,000. Granularity stops mattering once runtime is long and lands close to a whole hour.
The pattern is that rounding penalises many short sessions and near-boundary runtimes, and is close to neutral for long single runs. A team that mostly does overnight fine-tuning has little exposure; a team that spins up instances for quick experiments has a lot.
Where idle time hides
Granularity is only half the story. Metering usually counts the time an instance is running, not the time the GPU is busy. A notebook left open for eight hours with three hours of real compute is billed for eight, under either model. Stopping instances promptly, using auto-shutdown where a provider offers it, and checking whether a stopped instance still accrues charges for attached storage are all separate from the hourly rate and worth confirming in each provider's documentation. Storage and data movement are billed on their own lines; see the notes on egress and data-transfer structures for that side of the bill.
Minimum charges and startup time
Some listings apply a minimum billable period, for example a first-minute or first-hour minimum, or bill from the moment an instance is requested rather than from when it is ready. Startup, image pull and dataset download time are therefore part of what you pay for even if the GPU is idle during them. For short jobs, this overhead can outweigh the difference between two providers' quoted rates, so it belongs in any comparison of short-job cost.
A comparison checklist for short or bursty workloads
- Find the stated metering unit (second, minute, hour or month) on each provider's pricing page.
- Check whether rounding applies per session or per billing period.
- Look for a minimum billable duration and when the meter starts and stops.
- Estimate your own session pattern: number of sessions per week and typical length.
- Compute cost as billed hours multiplied by rate for each provider, not rate alone, then add GST as applicable.
Does granularity change GST or DPDP treatment?
No. GST is levied on the billed amount, so a rounding difference carries through to the taxable value, but the billing unit does not change the tax category or invoicing requirements; the GST invoicing guide covers those. Likewise, data-residency and DPDP obligations attach to where and how personal data is processed, not to how the compute is metered.
Bottom line
A lower headline rate with hourly rounding can cost more than a higher rate metered by the second, and the reverse holds for long continuous runs. Neither model is inherently better; the right comparison depends on session length and frequency. Use the cost calculator with your own usage pattern, and see the wider list of checks in what a ₹/GPU-hour figure hides.