GPU supply constraints are not an abstraction for European infrastructure teams right now. Nvidia allocations are tight, lead times are long, and the question of whether you can shift inference or training workloads onto AMD or Intel hardware without rewriting everything has moved from academic to urgent. The honest answer is: sometimes yes, often partially, and occasionally not at all. Which outcome you get depends on the specific tool, the specific framework, and how far your code reaches into Nvidia-specific internals.

This post maps the portability landscape as it actually stands in mid-2026, covering AMD ROCm, Intel oneAPI, Spectral Compute SCALE, and ZLUDA. We will be direct about where each approach works, where it breaks, and what that means for teams running GPU inference without Nvidia in a European cloud context.

The four portability approaches and what they actually do

These tools solve the same problem from four different angles, and conflating them leads to bad architectural decisions.

AMD ROCm and HIP

ROCm is AMD’s full open-source GPU compute platform. HIP is the CUDA-compatibility layer inside it: a translation API that maps CUDA calls to AMD’s backend so that code can compile for either vendor. AMD’s HIPIFY tools automate much of this translation. hipify-clang parses CUDA syntax and converts it to HIP at the source level; hipify-perl handles simpler substitutions but catches fewer errors.

HIPIFY handles a broad range of CUDA runtime API calls, kernel launch syntax, and standard library functions where a HIP equivalent exists. What it cannot handle is anything that has no AMD counterpart: CUDA libraries with no HIP equivalent, and architecture-specific features like inline PTX (Nvidia’s virtual assembly language), which still require manual porting. For production use, AMD’s own documentation directs teams to ROCm 7.2.4; version 7.13.0 is a technology preview only.

The practical payoff is real for inference workloads. PyTorch, vLLM, and SGLang all carry official ROCm support in 2026. MLPerf Inference 6.0 results from April 2026 show AMD’s MI355X posting server inference scores within single-digit percentage points of Nvidia’s B200 for standard LLM inference. TensorRT-LLM and FlashAttention 3 do not yet have ROCm support, which matters if your stack depends on them.

Intel oneAPI and SYCLomatic

Intel’s approach is architecturally different. Rather than translating CUDA to a vendor-specific backend, oneAPI is built on SYCL, a C++-based programming model governed by open industry standards. The premise is that standards-based code can outlive any single hardware generation.

SYCLomatic, the open-source migration tool on GitHub, converts existing CUDA code to SYCL. Intel’s own documentation claims 90 to 95 percent of a CUDA codebase ports successfully out of the box. There is a caveat worth noting: the Intel DPC++ Compatibility Tool, the binary distribution of this capability, was deprecated in the 2025.3 release and will be removed in a future version. Future work is directed to the SYCLomatic open-source community. Teams building on this path should plan accordingly.

Using oneAPI against AMD or Nvidia hardware requires installing vendor-specific plugins from Codeplay. The SYCL model is the most standards-pure of the options here, but it requires the most integration work to reach non-Intel targets.

Spectral Compute SCALE

SCALE takes a different bet entirely. Rather than translating your code away from CUDA, it functions as a drop-in replacement for NVCC, the Nvidia CUDA compiler, using Clang and LLVM underneath. You keep your CUDA codebase; SCALE compiles it for AMD hardware transparently through a virtual environment called scalenv that shadows nvcc.

Instead of porting programs away from CUDA, SCALE offers a vendor-neutral platform that allows users to keep their existing codebases.

Spectral Compute was founded in 2018 and released the first public beta of SCALE in July 2024. Version 1.4.2, released in October 2025, supports AMD GPUs; Nvidia and other accelerators are on the roadmap. A peer-reviewed ACM paper reports SCALE covers the majority of the CUDA API, reflecting around 60 percent coverage across four AMD GPU microarchitectures and thirteen popular frameworks. Spectral Compute’s own benchmarks claim 5.94 times faster execution than HIP on AMD hardware, though these are vendor-published figures rather than independently verified results. The important current limitation: SCALE does not yet cover enough of the CUDA API to port large frameworks like PyTorch. The company raised a $6 million seed round in November 2025.

ZLUDA

ZLUDA is the most unusual option. It operates on the compiled binary rather than the source, meaning you do not need your source code and you inherit all of nvcc’s optimisations. It started at Intel in 2020, moved to AMD, and is now maintained by two independent developers. Version 5, released in October 2025, can run llama.cpp but is far from general coverage. There is also a legal question: the CUDA license appears to prohibit translating output generated by the CUDA SDK to target non-Nvidia platforms. Teams considering ZLUDA for production should get legal review first.

Where CUDA portability actually breaks

The failure modes cluster around a few patterns that are worth naming explicitly.

  • PTX and low-level intrinsics. Inline PTX is Nvidia’s virtual assembly language. Any kernel that uses it cannot be automatically translated by any of these tools. Manual rewriting is required.
  • Libraries without AMD or Intel equivalents. If your pipeline depends on a CUDA library that has no ROCm or SYCL counterpart, HIPIFY and SYCLomatic cannot help. You need a replacement library or a rewrite.
  • Large framework dependencies. SCALE’s 60 percent CUDA API coverage is meaningful for targeted workloads but not yet sufficient for PyTorch or similar full-stack frameworks. ROCm is the more mature path for those.
  • Custom CUDA kernels tuned for Nvidia microarchitecture. Kernels written to exploit specific Nvidia hardware behaviour (warp sizes, memory hierarchy details) may compile on AMD but perform poorly or produce incorrect results without tuning.

What this means for GPU inference without Nvidia in Europe

The realistic picture for European enterprises in 2026 is this: if your inference workload runs on PyTorch with standard transformer architectures and you are not depending on TensorRT-LLM or FlashAttention 3, AMD Instinct hardware with ROCm is a credible production path. MLPerf numbers support that. If your stack is more bespoke, you need to audit your CUDA dependencies carefully before assuming portability.

The connectivity layer matters more than it might seem when you are mixing hardware across providers. We operate 44 points of presence across Europe and the Middle East, with direct peering to AWS, Azure, GCP, Oracle, and Cloudflare at all sites. For teams running hybrid inference pipelines where some workloads stay on Nvidia capacity at a hyperscaler and others move to alternative GPU infrastructure, that peering fabric keeps the data paths short and the latency predictable, which matters when you are orchestrating across heterogeneous accelerator pools.

The procurement question behind the technical one

GPU portability is ultimately a risk management question. CUDA lock-in is real: the ecosystem depth, the library coverage, and the tooling maturity still favour Nvidia significantly. But the supply situation and the cost trajectory mean that treating Nvidia as the only viable path is itself a risk.

The pragmatic approach is to audit your workloads against the ROCm compatibility matrix, identify which components have hard CUDA dependencies (PTX kernels, unsupported libraries, TensorRT-LLM), and separate workloads that can move from those that cannot. Run the portable workloads on AMD hardware where supply and cost make sense. Keep the non-portable ones on Nvidia. Build your orchestration layer to treat the two pools as interchangeable where the underlying workloads actually are.

None of the portability tools are magic. HIPIFY automates a lot and still requires manual review. SCALE is promising but incomplete. ZLUDA carries legal risk. The teams that will navigate this well are the ones who start with an honest inventory of their CUDA dependencies rather than assuming portability and discovering the gaps in production.