What AI Teams Need to Vet Before Trusting a GPU Cloud Vendor

Cloud procurement used to be a straightforward infrastructure decision. With GPU cluster growth across various clouds, from hyperscalers to neoclouds and DePIN solutions, that’s just no longer the case. 

Enterprise buyers now commit six- and seven-figure compute budgets to providers whose compliance posture, contractual protections, and operational reality vary enormously. This often happens in ways that aren't so obvious from a pricing page or a sales deck. 

This blog is your checklist covering five categories that technical buyers, security teams, and legal counsels will need to consider before signing anything. It covers data handling and residency, security certifications (including their scope), uptime and SLA terms, support model and escalation, and exit costs and portability. 

Each category gets measured against hyperscaler, neocloud, and decentralized GPU marketplace offerings. We’ll cut through the marketing hype and explore technical details and risk tolerance. 

But first, a quick word on numbers that you should have a firm grasp on before you start down this road. What's your data classification level for training data? What's your organization's minimum acceptable uptime for inference workloads? Do you need SOC 2 Type II today, or within 12 months? 

Everything that follows will help your team as you commit budget to cloud procurement. But knowing the answers to those three questions will cut your evaluation in half. 

Let’s get into it. 

Data handling and residency: Where does your data travel and live?

Most buyers tend to ask this question last but, really, it should be the first one they ask. GPU compute is effectively useless if your data lands somewhere that violates your privacy policy, customer contracts, or any applicable law.

Here are some of the right questions you would be asking any potential cloud procurement vendor:

• Where are your GPU nodes physically located? You want to know city and country, not just a region like "US-East."
• Can you guarantee that my training data never leaves a specific jurisdiction? This question is part of your data residency due diligence, and you’ll encounter strict regional laws like GDPR and HIPAA long before your push sensitive data sets into your pipeline. 
• What's your data-at-rest encryption standard? What manages the keys — you, or me? You want robust standards like AES-256, and confirm whether bring-your-own-key (BYOK) options are supported. 
• What happens to my data after a job completes? How long do artifacts persist? What's the deletion procedure and can it be audited? This enables you to understand the data retention lifecycle. You also confirm that lingering temporary files are securely sanitized instead of being left exposed in shared storage. 
• Do your workers or node operators have any access to customer data in-flight or at-rest? This is all about eliminating insider threat risks. You want to confirm strict zero-trust isolation and zero human access to raw workload volumes. 

For hyperscalers  like AWS, GCP, and Azure

Data residency is well-defined at the regional level. You can constrain workloads to us-east-1 or eu-west-1 and get contractual guarantees backed by years of audit history. You’ll also enjoy key management that is mature, such as AWS KMS, GCP CMEK. However, there is a tradeoff: cost and, in some configurations, egress billing can make data movement expensive.

For neoclouds like CoreWeave, Lambda Labs, and Vast.ai

Residency guarantees vary significantly by provider. Some have well-defined data center footprints; others aggregate supply from third-party colo operators where the fine print matters. If you want specifics, ask these questions:  "Is your infrastructure single-tenant from a network perspective?" and "Who owns the physical hardware?"

For decentralized GPU marketplaces like VOLT and others

This is where the tradeoffs are genuinely different and need to be stated plainly. A decentralized supply model aggregates compute from independent node operators distributed across many jurisdictions. This creates not only real flexibility for finding cost-effective capacity but also real complexity for data residency. 

If your workload requires that training data never leaves the EU, you need the vendor to demonstrate that geo-constrained job routing actually works and is contractually enforced, not just that its features in the vendor’s roadmap. Ask VOLT or any decentralized marketplace: "Can you restrict my jobs to node operators in specific countries, and is that enforced at the scheduler level or just at the preference level?" The honest answer may be "partially" or "with caveats". All of that’s useful information, not a disqualifier. But you need it before you sign.

There’s also the matter of certification scope on data handling. SOC 2 Type II covers the vendor's systems and processes but not every node in a distributed network unless those nodes are explicitly in scope. We cover this more in the next section.

What security certifications cover (and what they don't)

SOC 2 Type II is often treated as a binary: either a vendor has it or they don't. As with many things in life, the reality is more granular. Understanding the granularity is of prime importance, which is why we’ve put this table together as your security certification coverage quick reference.

Let’s boil this down into the critical question for any security certification claim: "Are your GPU nodes in scope for this audit, or just your control plane?"

For centralized providers with owned data centers, the answer is typically, “yes — the hardware is in scope.” For providers who aggregate third-party supply, the certification may cover the orchestration layer and the vendor's corporate security practices while excluding the underlying compute substrate. This is simply how audits work. But it means you cannot rely on a vendor's SOC 2 to certify the security posture of every node your job runs on.

For a decentralized marketplace, the network may have strong security controls at the scheduler, job dispatch, and data isolation layer, while individual node operators bring variable security posture. If your compliance team needs uniform certification coverage across every compute node, a decentralized model will require a more detailed conversation about how node selection and verification works. This kind of model will also demand a conversation about whether the vendor can provide node-specific audit artifacts on request.

To recap, here are some practical asks for your security certification review:

• Request the most recent SOC 2 Type II report. Ask specifically what systems are in scope.
• Ask whether GPU nodes are in or out of scope.
• Ask whether the vendor can provide a trust center or security whitepaper that describes their data isolation model technically, not just conceptually.
• Ask about penetration testing frequency and whether results are available to enterprise customers under NDA.

Uptime, SLAs, and what happens when they're missed

GPU cloud SLAs (service level agreements) are not all equal when it comes to uptime guarantees and what they look like. Indeed, the variance is larger than most buyers expect until they read the contract.

Here are some questions that will reveal what vendor’s real commitments are versus their marketing language:

• What is your stated uptime SLA, and does it apply to on-demand capacity or only to reserved/contracted capacity?
• How is "uptime" measured — control plane availability, individual job availability, or something else?
• What are the remedies if the SLA is missed? Credits only? What percentage of the affected month's spend?
• What exclusions apply? (Scheduled maintenance, force majeure, third-party provider outages?)
• Is there a status page with historical incident data I can review?

The hyperscaler model

AWS, Azure, and GCP typically offer 99.9% or higher SLAs on specific services, with defined credit structures. It’s usually 10–30% credit for availability below threshold, sometimes up to 100% for severe outages. The exclusions are well-documented and have been litigated through years of customer use. There is a practical downside you should know about: credits rarely cover your actual cost of downtime for a time-sensitive training run.

The neocloud model

Uptime varies widely. CoreWeave and Lambda Labs have published SLA terms. Smaller neoclouds may have informal commitments or month-to-month terms with no contractual SLA at all. This is not inherently disqualifying for dev/test workloads, but it's a meaningful risk for production inference.

The decentralized marketplace model

Decentralized GPU marketplaces feature a genuinely different SLA structure. Because compute is aggregated from many independent node operators, job-level resilience may be higher (if a node goes down, the scheduler can requeue). That said, contractual uptime guarantees for a specific capacity block are harder to make. If a vendor can only offer "best effort" for on-demand spot capacity, that may be fine for batch training but unacceptable for latency-sensitive inference endpoints.

Real-world costs of an SLA miss

Suppose you're running a 72-hour LLM fine-tuning job on 8x H100 nodes at $2.50/hr per GPU (a representative VOLT on-demand rate for H100 PCIe). That's $2.50 × 8 × 72 = $1,440 for the job. If the job fails at hour 60 due to a node failure with no checkpoint recovery, and the SLA credit covers 30% of that affected compute, you're getting back $432 against an actual loss of restoring 60 hours of compute at the same rate. 

While credits make procurement teams feel better, they don't make the CFO whole. Ask specifically about checkpoint-and-resume capabilities as a resilience feature that matters more than the SLA credit percentage.

Support Model: Who do you call when a training run stops in the middle of the night

As far as evaluation criterion go, this is an underrated one. GPU cloud support varies from "submit a ticket and wait" to "dedicated Slack channel with a named technical account manager." Which one you need depends on whether this is an experimental workload or production-critical infrastructure.

You’ll want a checklist for support evaluation that looks like this:

• Is there 24/7 support for production incidents, or business-hours only?
• What's the first response time commitment for a Severity 1 incident?
• Is enterprise-tier support a separate contract or included?
• Is there a technical account manager or dedicated point of contact?
• Can I reach an engineer, or only a tier-1 support queue?
• Does the vendor have a documented escalation path?

This small table is pragmatic framework for matching the workloads you have to the support you will need:

For hyperscalers, enterprise support tiers are well-defined but expensive. AWS Enterprise Support starts at 10% of monthly spend, which adds up fast on large GPU bills. For neoclouds and decentralized marketplaces, support models are less standardized, with some offering Discord or Slack community support as the primary channel. This works well for developer-friendly workloads but may not satisfy your procurement team's requirements for enterprise vendor accountability.

Exit and portability: How hard is it to leave for greener pastures?

Look, vendor rock-in is a real cost that most buyers underestimate when signing initial contracts. We’ve hammered this point time and again over the last few years. When you make lock-in calculations, look beyond switching fees and consider data migration costs, model portability, and how much of your workflow is coupled to vendor-specific tooling.

You’l want to to ask the following questions before committing to any vendor’s contract:

• What format are my model artifacts stored in? Can I download them in a standard format (ONNX, HuggingFace checkpoint) without vendor conversion?
• What are the egress costs for moving data out? (For hyperscalers, this can be $0.08–$0.09/GB — meaningful at scale.)
• Are any proprietary SDKs or APIs required for job submission, or do you support standard interfaces (Kubernetes, Ray, standard S3-compatible object storage)?
• Is there a contract minimum commitment that creates financial lock-in, and what's the termination clause?
• Can I export job logs and billing data for my own records?

The decentralized GPU model advantage

One genuine benefit of a marketplace model like VOLT is that the absence of proprietary hardware means your job specifications and model artifacts aren't coupled to vendor-specific accelerator features. If you can run on NVIDIA H100s at VOLT, you can run on NVIDIA H100s elsewhere. This is a real portability advantage compared to workflows tightly coupled to TPUs (Google) or Trainium (AWS), where migration requires architectural changes.

But that doesn’t mean there absolutely won’t be some costs associated with moving on from a distributed GPU marketplace. If a decentralized marketplace's job submission tooling uses a proprietary API or dashboard rather than standard Kubernetes job specs or Ray cluster configs, you can still accumulate operational lock-in even without proprietary hardware. Ask for the job submission interface's documentation and check whether it abstracts a standard interface or introduces its own.

Why VOLT already fits your checklist

VOLT's core structural advantage is that it aggregates GPU supply that has been systematically underpriced relative to hyperscaler equivalents. The same H100 PCIe capacity that runs $2.80–$3.50/hr on AWS or GCP is available at $1.49–$2.50/hr on VOLT's marketplace, depending on job type and reservation structure. For buyers whose workloads are training-oriented, batch-friendly, and don't require contractual data residency in a specific building, that cost differential is real money; and gives AI startups and LLM researchers some real budget leverage.

VOLT's decentralized supply model does come with some tradeoffs, including certification scope, node operator vetting, and data residency enforcement. They all require more due diligence than simply dropping a job into us-east-1 on AWS. Buyers who need clean SOC 2 node-level coverage today, or whose compliance team will not accept anything short of a hyperscaler-grade BAA, should have that conversation with VOLT's enterprise team directly. Until you do, don’t assume anything. 

What VOLT offers is a strong price-to-performance argument for buyers willing to do the diligence and whose workloads have flexibility on where compute runs. If that sounds exactly like what your team needs, then reach out to the VOLT team or start provisioning GPU compute today. 

Related Questions

What does SOC 2 Type II actually cover for a GPU cloud vendor?

SOC 2 Type II certifies that a vendor's internal controls over security, availability, processing integrity, confidentiality, and privacy meet AICPA Trust Services Criteria. This is for a defined set of systems, over a defined audit period (typically 6–12 months). What it does not automatically cover is third-party infrastructure that the vendor relies on but does not operate. For GPU cloud vendors who aggregate supply from independent node operators, the audit scope typically covers the control plane and the vendor's corporate systems. Whether individual GPU nodes are in scope is a question you should ask explicitly and confirm by reviewing the auditor's scope statement in the report itself, not just the vendor's summary.

How do I compare uptime SLAs across GPU cloud vendors when the definitions vary?

Start by asking three specific questions: 

1. What does "uptime" measure (control plane, job availability, or network availability)? 
2. What's the credit structure for a miss — percentage of affected compute, or percentage of monthly spend? 
3. What exclusions apply? 

Once you have those three answers from each vendor, you can compare apples to apples. Also check the vendor's public status page and historical incident log. A 99.9% SLA from a vendor with 4 major incidents in the past 12 months tells you something that the SLA term alone doesn't.

What GPU cloud SLA provisions matter most for production inference workloads?

For production inference, first-response time on Severity 1 incidents and the existence of 24/7 support coverage matter more than the raw uptime percentage. A vendor with 99.95% uptime but 8-hour support response windows will cost you more during incidents than a vendor with 99.9% uptime and a 30-minute Sev1 response commitment. Also prioritize whether the SLA covers the specific service you're using, as some vendors SLA their control plane but not spot or on-demand GPU capacity, which is where most inference workloads actually run.

How do I evaluate data residency for a decentralized GPU cloud?

Ask the vendor whether geo-constrained job routing is enforced at the scheduler level (meaning jobs cannot be dispatched to out-of-region nodes even if they're available) or whether it's a preference setting that can be overridden for capacity reasons. Ask for documentation of how node operator location is verified and updated. Ask whether you can audit which node operators executed your jobs after the fact. If the vendor cannot answer these questions clearly, treat that as a residency risk instead of necessarily a disqualifier. It’s just something to flag for your compliance team before committing data.

What's the right way to think about vendor lock-in for GPU cloud workloads?

Lock-in has two components: financial (minimum commitments, termination fees) and operational (proprietary tooling that makes migration expensive in engineering time). Financial lock-in is easy to evaluate: just read the contract. Operational lock-in is subtler, and you’ll know it if can you describe your entire job submission and artifact management workflow using only open standards (Kubernetes job specs, S3-compatible object storage, standard NVIDIA tooling)? If your answer requires the vendor's proprietary SDK or dashboard for any critical step, you have operational lock-in. Vendors who support standard interfaces reduce that risk regardless of their pricing model.