How to Rent a GPU Cluster: Fabric, Scheduling, and Acceptance Tests

Renting a single GPU server is a familiar evaluation: the card, the price, the provider's reputation. Renting a cluster is a different purchase wearing the same vocabulary — because at multi-node scale, the product you are buying is the fabric: the interconnect, its topology, and the scheduling that makes networked servers behave as one cluster. Providers differ enormously on exactly the dimension single-server rentals never test. This page covers the cluster-specific path: what to specify, how to verify the fabric delivers before you commit, and the acceptance evidence that proves health at delivery.

Prerequisites: Specify Fabric, Topology, and Scheduling

A cluster rental is a fabric purchase: specify interconnect type (true InfiniBand or RoCE, with behavior and tuning differing), topology and rail alignment for your job sizes, cross-node scheduling behavior for multi-node jobs, and NIC inclusion confirmed in the instance listing — because networked servers without these specifications are not a cluster, whatever the invoice calls them.

Provider documentation makes the last row surprisingly concrete — instance catalogs list InfiniBand inclusion explicitly per type, which means renting without checking is an unforced error. The fabric-type question is not brand snobbery: vendor guidance compares the two interconnects on behavior and tuning differences, and job communication profile decides which one your workloads actually need. The specification step is where verification starts — everything the next section tests should already be written down.

Verify RDMA Works Before You Commit

Verify in three steps: run NCCL with debug output and confirm P2P and RDMA transports appear rather than socket fallback; benchmark all-reduce to check bus bandwidth against the fabric's claim; and test per-node-pair bandwidth so one bad rail surfaces before your training job finds it — run on the actual rented nodes, before the commitment finalizes.

1. The NCCL transport check: community guidance is unambiguous — run multi-node work with NCCL debug output and read the transports: P2P and RDMA lines mean the fast path is live; TCP or socket fallback means it is not, whatever the spec sheet promised.
2. The all-reduce benchmark: standard collective benchmarks measure the bus bandwidth the fabric actually delivers, checked against its specification — the number that reveals half-configured fabrics.
3. The node-pair sweep: raw fabric tests between node pairs surface the bad rail, the misconfigured leaf, or the one node whose NIC negotiated down — findings while they are still findings.

The timing rule carries the leverage: these tests run on the actual rented nodes before the commitment finalizes, when problems are the provider's to fix and your leverage is maximum. Deviations from the fabric's specified bandwidth are findings, not tuning opportunities — a cluster that cannot demonstrate its fabric is a server rental at cluster prices, and the verification exists to catch exactly that.

Acceptance: Burn-In Evidence and Ongoing Checks

Acceptance rests on provider burn-in evidence and your own tests: structured per-node validation before delivery (reputable providers run dozens of checks), your verification results archived as the baseline, and ongoing fabric spot-checks on long rentals — so degradation during the term is measurable against delivery, not argued from memory.

• Burn-in evidence: provider documentation describes structured per-node validation covering GPU, CPU, storage, and fabric before delivery — ask what was tested and get the results, because reputable providers are proud of this answer.
• Your baseline: the section-two verification results, archived at delivery, become the reference every later check compares against.
• Ongoing spot-checks: on long rentals, periodic fabric re-runs catch degradation while it is still cheap — cables fail, rails drift, and clusters age.
• Ratings as screening: independent cluster-rating systems grade providers on fabric quality and reliability — a legitimate shortlist filter, and a poor substitute for your own tests, because ratings sample history rather than your delivery.

The acceptance record — burn-in results, your verification baseline, and the spot-check cadence — is the rental's contract with reality: it defines what healthy meant at delivery and makes every later disagreement a measurement instead of an opinion. For steady multi-node workloads that outgrow rental cycles, dedicated environments such as OneSource Cloud's private AI infrastructure are the committed alternative — with the same fabric questions asked at contract instead of at booking.

FAQ

Do we need InfiniBand, or is RoCE enough?

Depends on the job's communication profile: tightly-coupled large training wants every bit of fabric quality and tuning simplicity, where true InfiniBand earns its premium; looser workloads and smaller jobs often run well on RoCE — specify by measured collective patterns, not brand.

How do we know RDMA is actually working?

The debug check: run NCCL with debug output and read the transports — P2P and RDMA lines mean the fast path is live, TCP or socket fallback means it is not — then benchmark all-reduce against the fabric's claimed bandwidth for the number that matters.

Are provider cluster ratings useful?

As screening: independent ratings grade fabric quality and reliability well enough to shortlist — but the verification steps exist because your workload on your rented nodes is the only test that counts, and ratings sample history rather than your delivery.