Skip to main content
Flash provides access to a wide range of NVIDIA GPUs through both pool-based and specific GPU selection. This page lists all available GPU types and explains how to use them.

GPU selection methods

Flash offers two ways to specify GPU hardware:
  1. GPU pools (GpuGroup): Select from predefined pools of similar GPUs grouped by architecture and VRAM.
  2. Specific GPU types (GpuType): Target exact GPU models when you need precise hardware characteristics.
You can use either method or mix both for advanced fallback strategies.

GPU pools

The GpuGroup enum provides access to GPU pools. Each pool contains specific GPU models grouped by architecture and VRAM capacity.

Available GPU pools

Using GPU pools

Specific GPU types

The GpuType enum provides access to specific GPU models. Use these when you need exact hardware characteristics. A single GpuType requests that exact card — this is the only form guaranteed to pin workers to a specific GPU model. If you pass a list of GpuType values, placement is advisory at the pool/VRAM-tier level instead. See GPU selection behavior for details.

Available GPU types

Using specific GPU types

When you pass a list, the Flash SDK converts each GpuType to its GPU pool (GpuGroup) when it creates the endpoint, excluding any pool members you didn’t list. Placement within the selected pools is advisory: workers may be scheduled on a different card with equivalent VRAM rather than one of the exact models you listed, and list order is not preserved. Pass a single GpuType when your workload requires an exact GPU model.

Advanced fallback strategies

Combine GpuGroup and GpuType for robust availability:

GPU selection behavior

Single GPU type: Passing a single GpuType requests that exact GPU model. This is the only form guaranteed to pin workers to a specific card. Flash waits for that model to become available, and jobs stay in queue until capacity is free.
Single GPU pool: Passing a single GpuGroup requests any card in that pool.
A list of GPU types or pools: A list requests any one of the listed options. It is not an ordered preference: the SDK does not preserve list order, and placement within the selected pools is advisory — workers may be scheduled on a different card with equivalent VRAM rather than one of the exact models you listed. Be aware of this when benchmarking or when your workload depends on a specific GPU model.
GpuGroup.ANY: Flash selects the first available GPU based on current capacity.
There is currently no API field that reports which GPU model a worker was actually placed on. The endpoint configuration reflects what you requested, not where workers ran, so GPU substitution is invisible in the API. To verify placement, query the GPU from inside the worker (for example, with nvidia-smi).
For production: Pass a single GpuType when you need a specific card for predictable cost and performance. For development: Use GpuGroup.ANY for fastest iteration.

Multi-GPU workers

Request multiple GPUs per worker using gpu_count:

Handling unavailability

If requested GPUs are unavailable, jobs stay in queue:
Solutions:
  1. Add fallback options: Use multiple GPU types.
  2. Use broader selection: Switch to GpuGroup.ANY.
  3. Contact support: For capacity guarantees, contact Runpod support.
Last modified on August 25, 2026