---
title: "PTX, Cubin and Fatbin: What GPU Architectures Does the Software Artifact Cover?"
description: "Leviathan Systems — Technical content Published 2026-10-20; updated 2026-10-20."
canonical: "https://www.leviathansystems.co/articles/cuda-ptx-cubin-fatbin-gpu-architecture-coverage"
last-updated: "2026-10-20"
---

# PTX, Cubin and Fatbin: What GPU Architectures Does the Software Artifact Cover?

Leviathan Systems — Technical content
Published 2026-10-20; updated 2026-10-20.

For a GPU refresh, establish whether the supplied device code has a documented execution route on the destination architecture. A cubin supplies GPU binary code for a stated SM target; retained PTX supplies virtual code that may be compiled for an eligible destination by the driver. A fatbin packages the code versions actually included. Its name and the application's CUDA version do not establish target coverage. Evaluate the native and PTX routes separately, then resolve the application's remaining dependencies.

## Identify what PTX, cubin and fatbin each supply

PTX is an intermediate instruction representation for a virtual GPU architecture. A target such as compute_80 describes the GPU capabilities assumed by that code. A cubin contains GPU binary code for a real SM target, such as sm_86. These labels describe device-code targets rather than the host driver's release number.

The compiler can retain different translations of the GPU code in a fatbin, embedded in an executable or library. At runtime, an appropriate translation is selected for the GPU. A fatbin can hold native images, PTX or a combination; the word fatbin does not establish that any particular fallback was included.

For a hardware purchase, the useful question is which supplied code version covers the destination. A newer server cannot supply a missing version merely by having CUDA installed.

References: [N2](https://docs.nvidia.com/cuda/cuda-compiler-driver-nvcc/index.html)

## Read the ordinary cubin rule in its supported direction

For the ordinary unsuffixed 8.x targets used here, NVIDIA documents binary compatibility within the same compute-capability major version when the GPU's minor version is at least the cubin's target minor version. Thus sm_86 code has the documented 8.6-to-8.9 route. The reverse direction does not follow, and an 8.x cubin does not acquire 9.0 binary compatibility.

NVIDIA's binary-compatibility promise requires unmodified binaries produced by NVIDIA tools. The supplier's target declaration must concern the delivered artifact.

References: [N1](https://docs.nvidia.com/cuda/cuda-programming-guide/01-introduction/cuda-platform.html), [N3](https://docs.nvidia.com/cuda/ada-compatibility-guide/index.html)

## PTX adds a compilation route with its own requirements

Retained ordinary PTX can provide a route across a compute-capability major-version change. NVIDIA's Hopper guide explicitly describes 8.x PTX reaching 9.0 through just-in-time compilation. This differs from executing an 8.x cubin on 9.0: the driver produces destination GPU binary code from the PTX.

Two requirements remain separate. The virtual architecture describes the GPU features assumed by the code. The PTX language version identifies the instruction-language revision the compiler must understand. A compute_80 label does not, by itself, identify that language revision or establish that an older driver understands the supplied PTX.

NVIDIA's minor-version compatibility guide specifically warns about PTX use with older drivers. Its Driver API also distinguishes an unsupported PTX toolchain from the absence of a suitable kernel image. A driver/Toolkit compatibility claim therefore cannot replace an explanation of the actual PTX and destination requirements.

References: [N4](https://docs.nvidia.com/cuda/parallel-thread-execution/index.html), [N5](https://docs.nvidia.com/deploy/cuda-compatibility/minor-version-compatibility.html), [N6](https://docs.nvidia.com/cuda/hopper-compatibility-guide/index.html), [N7](https://docs.nvidia.com/cuda/cuda-driver-api/cuda_driver_api/group__CUDA__TYPES.html)

## Compare one native image with a fatbin that also retains PTX

Consider two hypothetical payloads for the same set of custom GPU kernels. Payload A contains only an unmodified, NVIDIA-tool-generated sm_86 cubin. Payload B's fatbin contains that native image and a separate ordinary compute_80 PTX rendition of those kernels. These are stipulated contents for an educational comparison, not inspected binaries, certified product pairings or instructions for producing a build.

On a compute-capability 8.6 or 8.9 target, A has the native-image route described above. On 8.0, its native target is too high within the major version. On 9.0, the major version differs. With no other code supplied for these kernels, A has no eligible image for those two destinations under the stated rules.

B retains A's native route on 8.6 and 8.9. Its separately retained compute_80 PTX adds a possible JIT route on 8.0 and 9.0, subject to the actual driver understanding that PTX and the other software requirements being satisfied. B does not contain an sm_80 cubin merely because it contains compute_80 PTX.

The buyer consequence becomes clear in a proposed move from 8.9 to 9.0. A's only image loses its binary-compatibility basis; B supplies another route to assess. Adding PTX has not changed the sm_86 image's compatibility. It has supplied a different input from which destination code may be generated. Neither payload establishes coverage for external libraries, model artifacts or the complete application's required result.

References: [N3](https://docs.nvidia.com/cuda/ada-compatibility-guide/index.html), [N6](https://docs.nvidia.com/cuda/hopper-compatibility-guide/index.html), [N7](https://docs.nvidia.com/cuda/cuda-driver-api/cuda_driver_api/group__CUDA__TYPES.html)

## Keep architecture and family suffixes in the target

The ordinary example does not extend automatically to suffixed targets. The PTX ISA restricts architecture-specific targets ending in a, such as sm_90a, to that architecture. Family-specific PTX targets ending in f can reach eligible later targets within the same family, rather than arbitrary later GPUs.

Preserve the complete target designation in the supplier's explanation. Dropping the suffix can change which compatibility rule applies to the proposed refresh.

References: [N4](https://docs.nvidia.com/cuda/parallel-thread-execution/index.html)

## A cubin can still require runtime target work

Section 1.3.4.4 of the CUDA Programming Guide, updated September 10, 2026, describes driver-managed intra-family binary compatibility for CC 10.0 and later. The driver re-finalizes an off-target cubin for another guaranteed-compatible architecture in that family. On-target execution needs no further finalization. Cubins for CC 9.x and earlier are ineligible for runtime re-finalization.

Off-target finalization adapts an existing cubin; PTX JIT compiles virtual code into binary code. Finalization can increase module load time. A supplied cubin therefore does not establish that all runtime target work has been avoided, and neither route supplies a startup-time guarantee.

References: [N1](https://docs.nvidia.com/cuda/cuda-programming-guide/01-introduction/cuda-platform.html)

## Turn kernel coverage into a useful refresh decision

Coverage must follow the code the intended application needs. One compatible native image or one retained PTX version does not establish that every required kernel in every dependency has a usable destination route. NVIDIA describes kernel-launch failure where neither compatible cubin nor PTX is available. The relevant supplier explanation must therefore connect the actual application release and required libraries to the destination, rather than exhibit one favorable target label.

Ask the appointed application owner to explain the proposed change in those terms: which supplied code remains usable, which code depends on JIT or off-target finalization, and which dependency remains unresolved. This makes a refresh decision possible without prematurely demanding a rebuild or declaring the complete system supported.

Keep that conclusion at its proper scope. The related CUDA guide addresses the host driver, Toolkit and container relationship. The ONNX/TensorRT guide addresses graph reuse and qualified engine support. GPU-code coverage answers neither of those decisions by itself, nor does it establish numerical correctness or workload performance on the destination. Those results need the application owner's agreed evidence.

References: [N6](https://docs.nvidia.com/cuda/hopper-compatibility-guide/index.html), [N7](https://docs.nvidia.com/cuda/cuda-driver-api/cuda_driver_api/group__CUDA__TYPES.html)

## Connect the selected hardware to its physical refresh

If the supported hardware choice leads to equipment replacement or redeployment, use Leviathan's complete physical deployment service and the project-inquiry links below to discuss receiving, rack integration, agreed hardware QA, onsite installation, cabling and physical handoff records. Bring a nonconfidential equipment summary, destination, target window and the physical interface required by the appointed application team.

Artifact inspection, software rebuilding and application validation stay with the separately appointed software provider. The physical inquiry defines the installation package for the selected equipment; it does not offer those software services.

References: [L1](https://www.leviathansystems.co/services/turnkey-gpu-deployment)

## Primary sources

- [N1 — NVIDIA CUDA Programming Guide: The CUDA platform](https://docs.nvidia.com/cuda/cuda-programming-guide/01-introduction/cuda-platform.html). Checked 2026-10-20. Binary-provenance conditions and CC 10.0-and-later finalization in sections 1.3.4.1 and 1.3.4.4. Updated September 10, 2026.
- [N2 — NVIDIA CUDA Compiler Driver 13.4: GPU Compilation](https://docs.nvidia.com/cuda/cuda-compiler-driver-nvcc/index.html). Checked 2026-10-20. Virtual/real architectures, embedded fatbinaries and runtime code selection.
- [N3 — NVIDIA Ada Compatibility Guide 13.4: Application Compatibility](https://docs.nvidia.com/cuda/ada-compatibility-guide/index.html). Checked 2026-10-20. Ordinary 8.x cubin direction and explicit 8.6-to-8.9 compatibility; the example uses architecture labels without certifying products.
- [N4 — NVIDIA PTX ISA 9.4: PTX Module Directives](https://docs.nvidia.com/cuda/parallel-thread-execution/index.html). Checked 2026-10-20. Sections 11.1.1–11.1.2 distinguish language version, target features, architecture-specific targets and family-specific targets.
- [N5 — NVIDIA CUDA Compatibility: Minor Version Compatibility](https://docs.nvidia.com/deploy/cuda-compatibility/minor-version-compatibility.html). Checked 2026-10-20. PTX caveat for older drivers and separate library dependencies. Updated September 9, 2026.
- [N6 — NVIDIA Hopper Compatibility Guide 13.4](https://docs.nvidia.com/cuda/hopper-compatibility-guide/index.html). Checked 2026-10-20. Section 1.2 explains 8.x PTX reaching 9.0, per-kernel code selection and missing-code failure.
- [N7 — NVIDIA CUDA Driver API Reference 13.4: Data types used by CUDA driver](https://docs.nvidia.com/cuda/cuda-driver-api/cuda_driver_api/group__CUDA__TYPES.html). Checked 2026-10-20. Definitions distinguish no suitable kernel image from an unsupported PTX toolchain; no error was observed for a real application.
- [L1 — Leviathan Systems: Complete Physical Deployment](https://www.leviathansystems.co/services/turnkey-gpu-deployment). Checked 2026-10-20. Receiving, rack integration, agreed hardware QA, installation and cabling scope; software commissioning is outside standard inclusions.

## Related Leviathan resources

- [CUDA driver, Toolkit and container compatibility](/articles/cuda-driver-toolkit-container-compatibility-buying)
- [ONNX models and TensorRT engines: assess artifact reuse](/articles/onnx-model-versus-tensorrt-engine-portability)
- [Preinstalled GPU software and customer-specific commissioning](/articles/gpu-server-preinstalled-software-vs-site-commissioning)
- [Scope complete physical deployment for the selected equipment](/services/turnkey-gpu-deployment)
- [Discuss a physical GPU refresh and application-team handoff](/contact?service=turnkey-gpu-deployment&from=%2Farticles%2Fcuda-ptx-cubin-fatbin-gpu-architecture-coverage)

## Plan the physical installation for your GPU refresh

Share a nonconfidential equipment summary, site, target window and required physical handoff to discuss the installation scope and availability.

[Discuss the scope](/contact?service=turnkey-gpu-deployment&from=/articles/cuda-ptx-cubin-fatbin-gpu-architecture-coverage)