Practical reference
GPU cloud terminology mixes hardware, billing, capacity, networking, and workload performance. This glossary defines the terms the way they matter in an infrastructure decision so you can read provider listings and SaaS Sentinel tools without treating unlike evidence as equivalent.
Core rule
A GPU name alone does not define a comparable cloud offer. The same broad accelerator family can appear with different memory, form factor, GPU count, interconnect, region, market type, billing rules, surrounding CPU/RAM, and availability evidence. Use terminology to preserve those differences, not to collapse them into a single price table row.
Reference section
A normalized unit representing one GPU used for one hour. It is useful for comparing published compute rates, but it is not the same as total workload cost because utilization, throughput, storage, egress, taxes, support, and other charges may sit outside that number.
Capacity purchased without a long commitment at the provider's currently published on-demand terms. It is usually the cleanest baseline for comparing flexible cloud rates, but pricing alone does not prove that the requested GPU is provisionable in a specific region at a specific moment.
Discounted capacity that can be reclaimed or interrupted according to the provider's market and scheduling rules. It can lower compute cost substantially for fault-tolerant workloads, but the economic comparison should include checkpointing, restarts, lost work, queue delays, and deadline sensitivity.
Pricing tied to a time commitment, spend commitment, or reservation. A lower nominal rate is not automatically cheaper if utilization is uncertain or if the commitment reduces flexibility to switch GPU, provider, or region.
Capacity supplied through a marketplace or distributed host network rather than a uniform first-party fleet. It can offer low rates, but hardware consistency, networking, host reliability, storage, geography, and operational expectations may differ from managed cloud capacity.
A usage model where the provider abstracts instance lifecycle and bills around requests, execution, active worker time, or another managed unit. It should not be compared with a raw GPU-hour until the billing unit and workload behavior are normalized.
The minimum time increment used to charge compute, such as per second, minute, or hour. Granularity matters for short jobs because two providers with the same hourly price can produce different bills when minimums or rounding rules differ.
The cost of completing the actual workload after including the material assumptions that the headline compute price omits. Depending on the decision, this can include utilization, throughput, storage, egress, interruption risk, support, financing, or owned-hardware overhead.
Reference section
Evidence that a provider publishes a rate or catalog entry for an offer. It is pricing evidence, not a guarantee of current stock, quota, account eligibility, or successful provisioning.
Independent evidence that helps support an availability or capacity claim for an offer, region, or product. SaaS Sentinel deliberately keeps this separate from pricing evidence so a listed rate is never silently converted into a live-capacity claim.
The time SaaS Sentinel or its source pipeline actually observed a piece of evidence. It should not be confused with the date a provider says a price became effective, and it should never be advanced merely because a build or page refresh occurred.
The age of the latest qualifying evidence relative to the source's expected update interval. Freshness tells you how recently a value was checked; it does not by itself prove that the underlying market has not changed since the observation.
The most recent validated record retained when a source refresh fails or becomes unsafe. Keeping a last-known-good value prevents one broken parser or provider endpoint from silently deleting healthy historical knowledge, while freshness is degraded so the old value is not misrepresented as newly observed.
A data state used when a source or value changes in a way that cannot be published safely without further validation, for example an implausible price jump, unit change, missing identity field, or broken source format.
Reference section
Memory attached to the GPU. VRAM capacity can determine whether a model, batch size, optimizer state, or training configuration fits at all, so two cards from the same broad GPU family should not be treated as interchangeable when memory variants differ.
A common accelerator form factor and host interconnect. PCIe variants can differ from SXM or other platform-specific versions in power envelope, inter-GPU communication, system design, and performance characteristics.
NVIDIA's module/platform form factor used in high-end GPU systems. SXM systems often support higher power envelopes and tightly integrated multi-GPU interconnects, so a provider listing 'H100' or 'H200' without variant context may not be sufficient for a performance-equivalent comparison.
A high-bandwidth GPU interconnect technology used to move data directly between supported GPUs. It matters for workloads that scale across multiple accelerators and can make an 8-GPU node materially different from eight isolated single-GPU instances.
A high-performance networking technology commonly used for low-latency, high-bandwidth communication between nodes. Distributed training performance can depend heavily on network topology, so hourly GPU price alone may not predict multi-node time-to-completion.
The arrangement and connectivity of GPUs within and across nodes. Topology includes GPU count, local interconnects, host resources, and network fabric; it is part of the product being purchased, not merely an implementation detail.
Reference section
Useful work completed per unit of time, such as tokens per second, images per second, samples per second, or jobs per hour. Measured throughput is one of the strongest bridges between a cloud price and actual workload cost.
The share of purchased GPU time that is productively used by the workload. Low utilization can make a cheaper hourly instance more expensive per useful output than a higher-rate option that stays busy or completes work faster.
How much additional useful throughput is gained when more GPUs are added. Perfect linear scaling is rare; communication, synchronization, data loading, model parallelism, and software overhead can reduce the benefit of each additional GPU.
The elapsed time required to finish a bounded workload. For training, fine-tuning, rendering, simulations, and batch processing, this can matter more than hourly price because a more expensive GPU that finishes much sooner can have lower total cost and lower deadline risk.
A decision unit that expresses the cost of completing the thing the team actually cares about: a training run, batch job, million tokens, request volume, image set, or another workload-specific output. It is usually more actionable than cost per GPU-hour alone.
The degree to which a benchmark's model, precision, software stack, hardware configuration, batch shape, and other conditions match the workload being evaluated. A benchmark can be valid evidence without being transferable to every workload that uses the same GPU name.
Total cost of ownership. In a cloud-versus-owned GPU comparison, TCO includes more than hardware purchase price: utilization, energy, cooling, financing, depreciation, support, capacity planning, and the time horizon can all change the result.
Next step
Once the terms are clear, compare the exact market offers, inspect whether availability is separately evidenced, and then translate the hourly rate into the workload unit that matters to your team.