GPU cluster rental checklist

Published 1 October 2026

A complete request makes supplier offers easier to compare. Use this checklist before asking for a dedicated GPU cluster, whether you already know the accelerator you need or want to evaluate alternatives.

1. Define the job and the required result

Describe the workload, framework and expected run length. Include the GPU count you have tested, memory requirements and any scaling results you can share. Explain the deadline or performance target that makes a configuration acceptable.

Separate requirements from preferences. A fixed data location or software dependency can rule out an offer; a preferred GPU generation may be negotiable if another system passes your test.

2. Specify the allocation

Request the exact GPU model and form factor, GPUs per server, number of servers, host memory, CPU architecture and local storage. Clarify whether you need exclusive physical servers, full GPUs in virtual machines or another tenancy model.

“Dedicated,” “bare metal” and “reserved” answer different questions. Ask separately about resource isolation, access to the machine and the commercial commitment. A fixed-term reservation does not, by itself, describe the hardware you receive.

3. Describe the fabric and storage

For one distributed workload, specify that the requested nodes must be connected as a usable cluster. Ask for network technology, NIC count and speed, topology, oversubscription and whether the relevant paths are shared.

Keep three things separate: connectivity among GPUs, communication between nodes, and the path to storage. NVIDIA’s NCCL documentation treats communication topology and network configuration as distinct checks. NVIDIA networking troubleshooting

Give the supplier dataset size, storage capacity and expected checkpoint size. Ask how long initial data transfer will take, where checkpoints persist and what happens to stored data at the end of the rental.

4. Agree on delivery and acceptance

State the preferred start, latest useful start and rental term. Ask whether capacity is operational, awaiting commissioning or dependent on a future hardware delivery.

Define a bounded acceptance test: representative workload, node count, software versions, performance target and test duration. Request GPU health information and suitable communication tests alongside it. Agree how failed nodes, failed acceptance and delivery delays will be handled before billing begins.

5. Name the operational owner

Confirm who provisions access, who supports hardware and networking, and who handles your software environment. Ask for support hours, escalation contacts, maintenance notice and the process for replacing a failed GPU or node.

For location or security requirements, request evidence that applies to the actual service and facility. Record approved locations for compute, storage and backups. Have the appropriate people on your team review any contractual or compliance requirements.

Copyable request brief

• Workload and framework:
• Required result or deadline:
• GPU model, acceptable alternatives and memory needs:
• GPU count and GPUs per node:
• Single-node, independent nodes or connected cluster:
• Fabric and storage requirements:
• Compute and data-location constraints:
• Preferred and latest start dates:
• Rental term and expansion options:
• Tenancy and access requirements:
• Acceptance test and support requirements:
• Budget range, currency and required billing unit:

You do not need every field settled before starting a conversation. Mark unknowns explicitly so suppliers can explain their assumptions.

Share the brief with RackShore to explore supplier matches. RackShore handles introductions; the supplier is responsible for your contract, billing and infrastructure support.