The Same GPU Container Tag on Arm and x86: Which Image Actually Runs?

The application still executes CPU code

GPU acceleration does not remove the application's host process. NVIDIA's CUDA compiler documentation separates host code, compiled with a host C++ compiler, from GPU device functions. It describes embedding compiled device code in the host object. The host executable therefore remains part of the software delivery even when the GPU performs the central calculation.

Docker explains that containers share the host kernel and require architecture-compatible code for native execution. Packaging an existing x86 executable in a container does not turn it into an Arm executable.

Grace provides a relevant enterprise example. NVIDIA's Generic Linux Install Guide, last updated July 16, 2025, identifies AArch64 as the Linux architecture for Grace systems. It separately distinguishes distributions capable of running from distributions NVIDIA had tested and prevalidated. That dated platform guidance establishes neither support for a particular enterprise application nor the contents of its container.

References: [N1][D1][N2]

What one tag can select

The OCI Image Index Specification version 1.1.1 describes a higher-level index referring to platform-specific manifests. Its platform fields identify the operating system and CPU architecture, with an optional CPU variant. The architecture values amd64 and arm64 correspond to x86-64 and 64-bit Arm; amd64 is not a declaration that the image uses an AMD GPU.

An individual image manifest identifies its configuration and filesystem layers. Separate architecture variants can therefore supply different executables and native libraries while remaining under one application tag. Some data or other layers may be shared; the mechanism does not require every file to differ.

Docker documents automatic selection of the host-architecture variant when pulling a multi-platform image. On a Linux x86-64 host, that can be linux/amd64; on an Arm64 host, linux/arm64. The common tag identifies the multi-platform delivery, rather than proving that both hosts execute identical CPU binaries.

If the offered delivery contains only an amd64 image, there is no supplied native arm64 variant to select. A multi-platform description of a base image also leaves a further question: does the finished application delivery include the required variant?

References: [O1][O2][D1]

Keep CPU architecture, GPU code and the driver separate

NVIDIA's compiler documentation treats GPU compute capability and GPU code generation separately from host compilation. The selected application still needs device code appropriate to the proposed GPU. An arm64 image label does not describe that GPU coverage, and applicable GPU code does not make an amd64 host executable native to Arm.

The driver relationship is another question. NVIDIA's CUDA compatibility overview identifies the GPU driver and, where applicable, dynamically linked library requirements for executing a built application. An architecture-matching image does not settle those relationships.

Have the supplier connect three statements: which CPU platform the application executes on, which GPU targets its build supports, and which driver/runtime conditions apply. The related CUDA compatibility article develops the third question. Here the substitution decision turns on whether the actual software deliverable follows the proposed CPU architecture.

References: [N1][N3]

Compare a native release, a rebuild and an emulated route

A native release gives the buyer an identified arm64 application deliverable with a supplier support basis for the proposed environment. Ask whether that support covers the complete application, including any compiled extensions, plugins, helper executables and native libraries. A supported framework or base image is only one component of that assessment.

A source-based rebuild is a different delivery position. The supplier needs to establish access and rights to the necessary source, available dependencies, the resulting release and who will maintain it. Source availability alone does not establish a supplied, supported arm64 application. The proposal should identify who delivers the rebuilt artifact and when it becomes available for evaluation.

An emulated route is different again. Docker explicitly qualifies its cross-architecture execution restriction with an emulation exception. That prevents a blanket conclusion that x86 code can never execute on an Arm host. It does not establish support for this GPU application. An emulation proposal needs its own application-supplier support basis, component assessment and workload evidence, including any performance requirement. General emulation documentation cannot provide those application-specific conclusions.

References: [D1]

Four replacement hosts, two different software offers

Consider a fictional enterprise moving one containerized analysis application from four x86 GPU hosts to four proposed Arm GPU hosts. The offers below are invented to compare software-delivery evidence. They describe no actual system, supplier or test result.

Offer A retains the application's existing tag and supplies only its existing linux/amd64 image. Its summary says that the GPU application is containerized and the server quantity remains four. It identifies neither an arm64 application release nor an alternative execution route. The unchanged tag and equipment count do not establish a native application delivery for the proposed Arm hosts. The buyer's next question is which deliverable A actually proposes to support there.

Offer B retains the same application tag but identifies a multi-platform index with amd64 and arm64 entries. It identifies the selected arm64 manifest by digest and provides the component requirements for that variant. Its fictional support statement covers the defined application release, native preprocessing component, framework and runtime dependencies in the proposed Arm environment. It also states the applicable GPU-build and driver requirements, with workload validation still pending.

B gives the buyer an architecture-specific basis to assess. It does not demonstrate that the application produces acceptable outputs or achieves the required throughput on the proposed systems. Four hosts is an equipment quantity; it establishes neither equivalent capacity nor the same executable population.

Suppose A responds that it can rebuild from source. A now proposes a rebuild, whose resulting artifact and support need evaluation. Suppose instead it proposes emulation. That route needs the separate assessment described above. Either response changes what the buyer is comparing; neither should be silently treated as the native release B identified.

The useful distinction is therefore precise: A initially leaves the Arm delivery unidentified, while B identifies a candidate native delivery and its requirements. Workload evidence remains a separate requirement for the selected offer.

Tie the evidence to the selected variant

Ask the application supplier for the release and image reference, the intended operating-system/CPU platform, and the selected image-manifest digest. For a multi-platform delivery, also retain the parent index digest and its relationship to that child manifest. OCI defines a digest as an identifier of content. Identifying the parent collection and identifying the selected image are different levels of the same evidence chain. A single-platform delivery may have no parent index.

Then connect that identity to the support statement and component requirements. Include application-specific native code and any required components supplied separately or obtained at startup. This is a request for the supplier's assessment of the delivered application, rather than an assumption that a platform label audits every file.

Any workload result offered for comparison should identify the image variant, host environment, GPU and relevant software conditions. Agree the functional and performance criteria with the application's owner. A result from the previous x86 delivery may inform the requirement, but it does not demonstrate the behavior of the proposed Arm delivery. Keep existing evidence and planned validation visibly separate.

References: [O1][O3]

Connect the software decision to the physical project

Once the proposed application delivery has an assessable architecture basis, carry the selected complete server configuration into physical planning. The related server-substitution article owns the review of rack, facility, connection and material changes. Retaining four hosts does not close those dependencies either.

Leviathan can discuss a defined physical rack assembly and installation package with equipment identity and agreed handoff records. Application rebuilding, software configuration and workload validation remain with the appointed software team. Use the related rack-assembly service and project inquiry to share the nonconfidential equipment configuration, proposed site, physical tasks and receiving team when that work is needed alongside the software assessment.

References: [L1]