10 Contract Checks for Single-Tenant GPU Pricing
Single-tenant GPU pricing is the commercial model for capacity whose defined hardware and service boundaries are assigned to one customer rather than shared across tenants. The phrase does not reveal whether the entire server, network path, storage system, scheduler, or management plane is dedicated. It also does not show when billing starts or what operating work is excluded.
A contract should connect the price to a testable technical unit and a responsibility model. The ten checks below help procurement, infrastructure, security, and finance review the same offer. They are designed to expose ambiguity before workloads and data become difficult to move. Each answer should appear in the order form, service description, architecture schedule, or another binding document rather than only in sales correspondence.
Ten checks before accepting the price
| Decision or control | What it means in practice | Acceptance evidence |
|---|---|---|
| 1. Dedicated boundary | State whether dedication covers GPUs, full hosts, local storage, top-of-rack ports, shared storage, cluster control plane, monitoring, and administrator tooling. Price only becomes comparable when the isolation boundary is explicit. | Attach an architecture diagram and a list of every shared component. |
| 2. Capacity unit | Define GPU model, memory, count, host specification, interconnect, NICs, local storage, and topology. A generic GPU unit can conceal materially different performance and failure domains. | Tie each priced unit to a bill of materials and acceptance test. |
| 3. Activation and billing start | Identify whether charges begin at signature, hardware order, installation, customer acceptance, or production enablement. Separate one-time build work from recurring service periods. | Require dates, dependencies, and treatment of provider-caused delay. |
| 4. Metering and invoices | Specify billing granularity, minimum periods, idle treatment, rounding, maintenance credits, taxes, and the source records available for reconciliation. | Test a sample invoice calculation before the first production month. |
| 5. Included data services | Clarify storage capacity and performance, backup, snapshots, egress, cross-connects, public bandwidth, IP addresses, and data-transfer charges. GPU price alone rarely represents the complete data path. | Price the representative workload's monthly storage and network profile. |
| 6. Operations and support | List monitoring, patching, driver management, orchestration, incident response, replacement, capacity planning, and support hours. Assign exclusions to a named customer team and cost them. | Use a control-level responsibility matrix with response targets. |
| 7. Availability remedy | Document maintenance windows, component replacement targets, service measurement points, exclusions, and credits. A credit is not the same as recovery or reserved replacement capacity. | Review whether the remedy protects the workload's actual objective. |
| 8. Change rights | Define upgrade, downgrade, expansion, region change, configuration change, and workload transfer rules. Include lead times and price treatment for technology refresh. | Run a scenario in which the current GPU no longer fits the model. |
| 9. Security evidence | Identify access records, isolation tests, vulnerability reporting, data-location evidence, audit reports, and incident notification available to the customer. | Make evidence frequency, scope, and delivery format contractual. |
| 10. Exit obligations | Cover data export, key return or destruction, media sanitization, credential revocation, log retention, configuration handoff, termination charges, and transition assistance. | Require a time-bound exit plan with deletion or sanitization evidence. |
Compare offers on one service boundary
Create the workload bill
Document capacity, data, network, support, security, and availability requirements for one representative production scenario.
Map every charge
Connect recurring, usage, one-time, overage, support, and exit charges to the component or responsibility they cover.
Score contract evidence
Mark each requirement as binding, referenced, non-binding, or unanswered so verbal assurances do not become assumed scope.
Test change scenarios
Reprice growth, contraction, hardware refresh, prolonged outage, security investigation, and termination before choosing an offer.
Failure patterns to prevent
- Treating single-tenant as a complete isolation specification
- Comparing GPU rates with different support and data paths
- Leaving exit evidence and transition assistance undefined
Each failure should become a tested control, a funded remediation, or a time-bound risk decision with a named owner. A recommendation without evidence, authority, or a review trigger does not protect a production workload.
Authoritative technical basis
NIST SP 500-293 provides guidance for defining measurable cloud service agreement elements.
NIST SP 800-161 Rev. 1 provides cybersecurity supply-chain risk practices across acquisition and service lifecycles.
These sources define technical concepts and control expectations, but they do not guarantee a universal design. Apply them to the deployed workload, data classification, system boundary, contractual scope, and service objective. Record the document version and review date when a requirement becomes an acceptance criterion.
Where OneSource Cloud fits
OneSource Cloud can combine a dedicated infrastructure boundary with managed operations and customer-specific evidence. Buyers should translate that design into binding capacity, service, security, change, and exit terms using the ten checks above.
Relevant service paths include Private AI Infrastructure, Managed AI Infrastructure, and AI Storage Architecture. The final design should pass the article's workload and control checks; product labels, theoretical peaks, and broad compliance language are not acceptance evidence.
FAQ
What does single-tenant GPU pricing normally include?
There is no universal scope. It may cover only dedicated accelerators, a full server, or a wider managed environment. The quote should identify compute, host, network, storage, orchestration, monitoring, support, security evidence, and data transfer separately so the buyer can see what remains shared or customer-operated.
Is single-tenant GPU capacity always billed hourly?
No. Providers may use hourly usage, monthly reservation, fixed-term commitment, installation fees, minimum consumption, or blended structures. Ask when billing starts, how partial periods are handled, whether idle or maintenance time is charged, and how commitment costs appear when capacity is unavailable.
How can buyers compare two single-tenant GPU quotes?
Normalize both to the same capacity specification, topology, region, storage and network profile, service hours, operating responsibilities, security evidence, and availability objective. Then model effective cost under expected and downside utilization. A simple hourly-rate comparison is unreliable when the service boundaries differ.
Which exit terms matter most?
Focus on export format and timing, data-transfer charges, credential revocation, encryption-key handling, storage and media sanitization, log retention, configuration handoff, transition support, termination fees, and final evidence. The contract should specify owners and deadlines rather than relying on a general deletion promise.
Summary
A single-tenant GPU price is only meaningful when the dedicated boundary, capacity unit, operating scope, evidence, change rights, and exit duties are explicit. These ten checks turn a quote into a service that procurement and engineering can verify together.
Next step: Request a private AI infrastructure architecture review to map the workload, data path, controls, capacity, and operating ownership before procurement or production change.
Related Articles