Most GPU infrastructure conversations start in the wrong place. Teams ask about GPU models, memory bandwidth, and price per hour. These are reasonable things to know. They are not the questions that determine whether your infrastructure holds up six months into a production workload.

The questions that matter are the ones most providers hope you don't ask, because the honest answers expose the gap between what the spec sheet promises and what you actually get at 2am when a training run stalls or an inference pipeline starts returning inconsistent latency.

Before you sign a contract with any GPU infrastructure provider, dedicated or shared, here are 10 questions worth putting on the table.

1. Is the node exclusively mine, or shared with other tenants?

This is the most important question on the list, and the one most buyers skip. Shared GPU infrastructure means your workload competes for resources with other tenants on the same physical server. That competition affects memory bandwidth, thermal performance, and network throughput in ways that don't show up in a benchmark and aren't contractually guaranteed.

If your provider can't give you a clear, unambiguous yes to "is this node exclusively mine," the answer is no.

2. What happens to my performance when another tenant is running a heavy workload on the same server?

A follow-up to question one, and one that shared infrastructure providers rarely answer with a specific number. Ask for a contractual performance guarantee, minimum sustained GPU utilization, memory bandwidth floor, network throughput SLA. If the answer is "we do our best to ensure fair resource allocation," you have your answer.

3. What is the egress fee structure, and how is it calculated?

Egress fees are the most common source of invoice shock in GPU infrastructure. They are charged when data leaves the provider's network, for model checkpoints, dataset transfers, inference outputs, or anything that moves between your GPU environment and the outside world. Ask for the exact rate per GB, whether it applies to traffic between nodes in the same datacenter, and whether there are monthly caps or tiers.

If the answer requires a calculator and three follow-up emails, that cost will show up on your bill whether you understood it or not.

4. How is storage billed, and what happens when I exceed the included allocation?

GPU infrastructure contracts often include a base storage allocation. The overage pricing is where the surprise lives. Ask what happens when you exceed that allocation, whether it's billed per GB, whether there's a hard cap, and whether storage I/O is metered separately from storage capacity.

5. What is the process if I need to scale the number of nodes during my contract?

Some providers lock you into a fixed configuration for the duration of your contract. Others allow node additions but charge a premium for changes outside the original order. Ask whether scaling is possible mid-contract, what the lead time is, and whether adding nodes changes the pricing structure for your existing allocation.

6. What GPU driver and CUDA version is running on the node, and who controls updates?

This matters for teams with specific framework dependencies. CUDA versions are not always backward compatible, and a driver update pushed by your provider can break a carefully tuned training environment. Ask who controls update scheduling, whether you can pin to a specific driver version, and what the notification process looks like before any system-level change is applied to your node.

7. What is the network topology between my GPU nodes and my storage?

For distributed training or inference across multiple nodes, the bandwidth and latency between GPUs and storage is often the actual bottleneck, not the GPUs themselves. Ask about the interconnect between nodes (InfiniBand, RoCE, or Ethernet), the bandwidth between compute and storage layers, and whether that topology is dedicated or shared with other tenants.

8. What is your uptime SLA, and what happens if you miss it?

Most providers publish an uptime SLA. Fewer clearly define what constitutes downtime, how it's measured, and what compensation looks like when it's missed. Ask for the specific definition of a downtime event, the measurement methodology, and the credit structure for SLA breaches. A 99.9% SLA sounds solid until you calculate that it allows for 8.7 hours of downtime per year, and then ask what the credit is worth relative to what that downtime costs your team.

9. What does the support structure look like, and who do I contact when something breaks at 2am?

Enterprise AI workloads don't fail on business hours. Ask whether support is via ticket queue or direct channel, what the response time commitment is for critical incidents, and whether the person responding has direct access to your node's hardware configuration. The difference between "submit a ticket and we'll get back to you" and "here's a Slack channel with an engineer who knows your setup" is significant when a training run is failing.

10. What happens at the end of my contract term?

Data portability and offboarding terms are often buried in the contract and ignored during the sales process. Ask what happens to your data when the contract ends, whether there are fees for data extraction, and what the notice period is for non-renewal. If migrating away from the provider requires weeks of coordination and a significant egress bill, that's a lock-in mechanism that should factor into your evaluation.

These questions won't make every provider uncomfortable. A provider running dedicated infrastructure with transparent pricing and direct engineer support should be able to answer all of them without hesitation. The ones that can't, or that answer in generalities, are telling you something about what your experience will look like six months in.

If you want to run through these questions with our team, we're available. Talk to an engineer at www.1legion.com/contact-us.