Describe the workload
Share what the cluster will run: model or application type, training or inference pattern, expected concurrency, data size, run duration and any deadline. Explain whether the work depends on multiple GPUs communicating closely or can run as separate jobs. Include the software framework, orchestration environment and any operating-system or driver constraints you already know.
For confidential workloads, describe the requirements without sending credentials, sensitive datasets or secrets in an initial enquiry. Agree on an appropriate channel before exchanging restricted technical or commercial material.
Specify the system you want reviewed
List the GPU family and the number of GPUs or nodes you are targeting. Say whether that quantity is a firm requirement or an initial planning estimate. Ask the provider to state the validated system shape: GPUs per node, CPU and host memory, local storage, management components and any shared-storage assumptions.
Record the exact product name and source for hardware specifications. Products in the same accelerator family can be packaged in different systems, and a vendor’s reference architecture does not establish what a particular provider has configured or can supply. For example, NVIDIA’s DGX B300 guide describes one specific eight-GPU system and its own ports and physical requirements; those details should not be copied onto a different cluster design.
Make network and storage needs explicit
Describe how nodes need to communicate, which traffic matters most, and whether your jobs require shared storage. Include dataset size, read/write pattern, checkpoint size and where data will enter and leave the service. Ask for the proposed compute, storage and management paths, plus any bandwidth, latency, oversubscription or data-transfer limits that affect your workload.
Do not treat a network label or link speed as a performance guarantee. Topology, configuration, contention and the application all matter. If collective communication is important, agree on a representative validation method and the conditions under which it will run. NVIDIA documents NCCL diagnostics and tests for checking communication correctness; a successful diagnostic is a useful system check, not a promise of application throughput.
Define access, data and operations
Ask how users authenticate, how administrative access is separated, how images and packages are installed, and who manages operating-system updates. Describe your identity, logging, data-retention and security requirements. Confirm which party handles backups, monitoring, incident response, support escalation and maintenance windows. Put any compliance requirement in writing and ask what evidence is available; do not infer a certification from a product or platform name.
Confirm the commercial and delivery terms
Before treating a capacity request as a reservation, ask the provider to identify the reserved unit, term, billing basis, minimum commitment, included services, exclusions, quote-validity period and cancellation or change terms. Ask which event starts the term and which charges may apply before workload acceptance.
Request a written statement of the configuration, service location if relevant, current availability, earliest target date and dependencies. Treat an estimate as an estimate until the parties document the applicable commitment. Do not assume that a public product page or a selected term has reserved capacity.
Agree on acceptance before deployment
Write down the checks that matter to your workload. These may include inventory and health checks, GPU-to-GPU communication, storage access, network reachability, image launch and a representative application smoke test. Set the test inputs, expected results, responsible party, evidence, time window and process for resolving a failed check.
Keep infrastructure checks distinct from application performance targets. Agree on any benchmark and its conditions in advance; results depend on workload, software, data, configuration and test method. Specify the handover point and the support path after acceptance.
Request preparation
Bring these details to the first review. Mark anything you still need to resolve.
- Workload, framework and target date
- GPU family and target quantity, with required versus preferred clearly marked
- Node or rack requirements, if known
- Network and storage needs, including data movement
- Software, access and security requirements
- Requested term, location preference and support expectations
- Acceptance checks and any firm performance requirement
Configuration, site fit, availability and timing need confirmation for your request.
Discuss GPU capacity