← All guides

Software stack · 6 min read

GPU architecture and framework compatibility

A supported GPU is not the same as an optimized GPU. Drivers, CUDA, framework builds, kernels, runtimes, and containers determine which hardware capabilities the application can actually use.

Architecture defines the available tools

Ampere, Hopper, Ada Lovelace, and Blackwell expose different compute capabilities, precision paths, media engines, partitioning features, and interconnect options. Newer hardware can add useful capabilities without automatically accelerating every existing application.

An application benefits only when its framework and kernels recognize the architecture and use the relevant execution path. A generic fallback may run correctly while leaving performance or efficiency unavailable.

The training framework is one layer

PyTorch, JAX, and TensorFlow sit above CUDA libraries, compiler components, collective communication libraries, and device kernels. The framework name alone does not define compatibility—the exact package build and its dependencies do.

Custom CUDA extensions deserve special attention. A container that works on an established Ampere system may need newer binaries, a rebuild, or updated dependencies before it is suitable for Hopper or Blackwell.

  • Framework and package version
  • CUDA runtime and toolkit version
  • NVIDIA driver branch
  • NCCL and distributed backend
  • Custom operators and compiled extensions
  • Precision and quantization requirements

Inference runtimes make separate choices

TensorRT-LLM, vLLM, SGLang, Triton-based servers, and framework-native serving can support different kernels, quantization formats, batching strategies, and parallel layouts. Their maturity on a specific GPU generation may differ from the underlying framework.

Benchmark the actual model, context length, batch behavior, and concurrency target. A runtime optimized for one deployment pattern may not be the best fit for another even on the same GPU.

Containers help, but do not erase the host contract

Containers can pin the framework, CUDA user-space libraries, and application dependencies. The host still supplies the kernel driver and must satisfy the requirements of the GPU and container stack.

For a new GPU generation, verify the minimum driver and CUDA requirements before assuming an older production image can move unchanged.

Build a compatibility brief

The fastest way to narrow a platform is to capture the current software environment alongside the workload.

  • Current GPU and driver output
  • Operating system and kernel
  • Container or environment file
  • Framework and runtime versions
  • Model repository and custom extensions
  • Required precision or quantization
  • Distributed training or serving topology

Reference material

Product capabilities vary by generation and exact SKU. Review the current manufacturer documentation during specification.

NVIDIA GPU architectures ↗NVIDIA Hopper architecture ↗NVIDIA MIG deployment considerations ↗PyTorch installation matrix ↗JAX installation guide ↗TensorFlow GPU installation guide ↗
Next guide · GPU planningHow much GPU memory does the workload need?