Browse this section

Planning a GPU workload

A GPU configuration must fit the software as well as the dataset. Accelerator memory, number of devices, CPU, host RAM and storage throughput can each limit performance. A model that fits in memory for inference may need substantially more resources for training.

Include these details in your request

  • Framework and version, driver or CUDA requirements, model size, numerical precision and expected batch size.
  • Whether the workload is training, inference, rendering or another task, plus expected concurrency and run duration.
  • Dataset size, where it will be stored, how it reaches the GPU instance and whether sensitive information is involved.
  • Required GPU model and count, licence needs, region preference, backup requirements and acceptable startup or maintenance windows.

Ask for a representative workload test when practical. Do not infer dedicated GPU access, device partitioning or included software licences from the plan name alone; the final quote must identify the supplied accelerator and allocation model.

Was this guide helpful?

Related guides

Instance disks, persistent volumes and snapshots

A cloud deployment can combine different storage types. An instance disk, an attached volume and a snapshot are separate resources with different lifecycle and recovery behaviour. Record wh…

Requesting a cloud resize or capacity change

A larger instance can provide more resources, but the available resize paths and downtime depend on the platform, family and storage layout. Scaling also affects pricing and may require a d…

Need help applying this to your service?

Tell us your service reference and what you need to achieve. Never include passwords or private keys in a ticket.

Contact support →
← All knowledgebase topics