GPU Support Matrix: CUDA, ROCm, SYCL and Vulkan

Whether a given card runs local AI comes down to one identifier — its compute capability on NVIDIA, its gfx target on AMD — and whether the runtime you want was built for that identifier. Find yours in the tables below and read across. The biggest recent break is CUDA 13.0: NVIDIA's release notes state that "Architecture support for Maxwell, Pascal, and Volta is considered feature-complete. Offline compilation and library support for these architectures have been removed in CUDA Toolkit 13.0 major version release," which makes Turing (compute capability 7.5) the floor for anything built against CUDA 13. On the AMD side there is no guessing either: the ROCm compatibility matrix names its supported gfx targets explicitly, and cards outside that list reach ROCm through HSA_OVERRIDE_GFX_VERSION or skip it entirely for Vulkan. Intel goes through SYCL and the PyTorch XPU path.

This page is a compatibility reference and nothing else. There are no tokens per second on it, no rankings, and no "fastest card" verdicts — every cell is a support status taken from vendor or project documentation, linked at the bottom. Compatibility is the question that blocks a purchase or explains a failure; speed is a different page.

Two version notes so you know how fresh this is. The CUDA statements are from NVIDIA's CUDA Toolkit release notes, currently at 13.3 Update 1. The AMD rows are from the ROCm compatibility matrix for ROCm 7.14.0, dated 2026-07-16. Both move; check yours before you spend money.

How Do I Find My Card's Compute Capability or gfx Target?

Read it off the machine rather than matching a marketing name — the same product name has meant different silicon before.

NVIDIA. The driver will tell you directly, no toolkit needed:

nvidia-smi --query-gpu=name,compute_cap,driver_version --format=csv

AMD. rocminfo prints an agent block per device; the gfx target is on the Name: line for the GPU agent:

rocminfo | grep -i gfx
rocm-smi --showproductname

If you searched for "AMD equivalent of nvidia-smi", rocm-smi is it — same job, different flags, and it ships with ROCm rather than with the display driver.

Intel. With oneAPI installed, sycl-ls enumerates every SYCL device the runtime can see and labels the backend for each:

sycl-ls

Anything, via Vulkan. vulkaninfo --summary lists the devices the Vulkan loader found, which is the fastest way to confirm a fallback path exists:

vulkaninfo --summary

Apple Silicon. There is no capability number to look up; the question is which Metal-capable chip you have and how much unified memory it addresses. That is a sizing question rather than a compatibility one — see our unified memory tier table and MLX vs CUDA.

Which NVIDIA Architectures Still Build on CUDA 13?

Compute capability to card mapping from NVIDIA's CUDA GPUs list and Ollama's published supported-GPU table; the CUDA 13.0 column from NVIDIA's release notes, which say CUDA 13.0 "supports all NVIDIA architectures from Turing through Grace Blackwell."

"Removed in 13.0" does not mean the card is dead. NVIDIA's own note is that these architectures can still be targeted with a CUDA 12.x toolkit — what disappeared is the ability of the 13.x toolchain to compile for them and the 13.x libraries' support for them. In practice that pushes older cards onto whatever prebuilt binaries a project still ships. Ollama, for example, documents support for "Nvidia GPUs with compute capability 5.0+ and driver version 550 and newer," with the added condition that "Nvidia GPUs with compute capability 5.0 through 6.2 require driver version 570 or newer" — so a GTX 1080 Ti is still a supported Ollama target even though CUDA 13 will not build for it. If you are running a Pascal-era card, that driver-version line is the one to check first, and our Tesla P40 guide covers the wider set of quirks on that generation.

The 12.x-to-13.x split is also why "it worked last month" happens after an update: the package you pulled moved to a CUDA 13 build and quietly stopped covering your architecture.

Which AMD GPUs Does ROCm Officially Support?

From the ROCm 7.14.0 compatibility matrix. "Officially supported" here means AMD lists and tests the target — it is not a statement that unlisted cards fail.

Two things worth pulling out of that table.

Consumer RDNA 2 is thinner than it looks. AMD's only RDNA 2 entry is gfx1030, and it names workstation parts. Ollama's own AMD list is broader here — it includes the RX 6950, 6900 and 6800 among its ROCm-supported Linux cards, which all share the gfx1030 target — but the smaller RDNA 2 dies do not, and those are exactly the cards that end up setting an override.

The APUs are first-class now. gfx1151 — Strix Halo, the Ryzen AI Max+ 395 in the 128GB mini PCs — is a listed, supported target rather than a community hack. That is the single biggest change for people buying a unified-memory box instead of a discrete card. Setup detail lives in our AMD ROCm local LLM setup guide, and the hardware side in the Strix Halo guide.

Note also that AMD scopes the OS support tightly for the non-Instinct parts: "AMD Radeon PRO and AMD Radeon GPUs only support Ubuntu 24.04.4, Ubuntu 22.04.5, RHEL 10.1, and RHEL 9.7." A card being on the gfx list does not mean your distribution is.

What Works on Intel Arc and Intel iGPUs?

Intel's path is SYCL (through oneAPI) for llama.cpp, and the PyTorch XPU device for anything built on PyTorch. llama.cpp's SYCL documentation states: "SYCL backend supports Intel GPU Family: Intel Data Center Max Series, Intel Flex Series, Arc Series, Intel Built-in Arc GPU, Intel iGPU in Core CPU (11th Generation Core CPU and newer)."

One thing to know before you plan around SYCL: it is Intel-only now. llama.cpp's SYCL docs record, in the 2026.02 release notes, "Remove support for Nvidia & AMD GPU, because the oneAPI plugin for Nvidia & AMD GPU is unavailable: download/installation channels are out of work." SYCL was briefly a cross-vendor route; treat it as an Intel backend.

For Ollama specifically, Intel GPUs arrive through Vulkan rather than SYCL — the docs say "Additional GPU support on Windows and Linux is provided via Vulkan" and point Linux users at Intel's client driver documentation for the prerequisite packages. Card-level detail for the two most common Arc parts is in our Arc A770 guide and the Arc B580 guide.

Which Runtime Supports Which Vendor?

The vendor tables above tell you whether a driver stack claims your card. This one tells you whether the thing you actually run was built for it. All four rows are from each project's own installation documentation.

The asymmetry in that table is the useful part. vLLM is the strictest: compute capability 7.5 or higher rules out every Pascal and Volta card outright, so a 1080 Ti box that serves happily under Ollama is simply not a vLLM machine. llama.cpp is the loosest, with more backends than any other project here — if a piece of silicon runs local models at all, llama.cpp probably has a path to it. Ollama sits in between, with a documented Vulkan route out when ROCm will not cover a card. Setup guides for the two server runtimes: Ollama and vLLM; the image-generation side is in the ComfyUI guide.

When Is Vulkan the Right Answer?

Vulkan is the compatibility escape hatch, and it is officially supported rather than a side project: llama.cpp documents a Vulkan backend available on Windows, Linux, macOS and Docker (it needs the Vulkan SDK at build time), and Ollama documents Vulkan as the route to "additional GPU support on Windows and Linux," naming Intel GPUs and AMD parts beyond the ROCm list.

Reach for it when:

• Your AMD card is not on the ROCm gfx list and you would rather not run an override.
• You are on Intel and do not want a full oneAPI installation.
• You are on Windows, where the ROCm story is narrower than on Linux — Ollama's Windows AMD list stops at RX 7000 and the PRO W7000 series.
• You need a second, weaker GPU to be visible at all.

The tradeoff is that Vulkan is a portability layer, not a vendor-tuned compute stack, so vendor-specific optimisations do not follow you across. This page makes no claim about what that costs; that is a measurement, and we are not publishing one we did not take.

My Card Is Not on the List. What Now?

In order of how likely each is to work:

1. AMD: set the gfx override. Ollama's documentation gives the mechanism and an explicit example — set HSA_OVERRIDE_GFX_VERSION="10.3.0" as an environment variable for the server, which reports an unlisted RDNA 2 part as gfx1030. The version string uses an x.y.z form that maps onto the gfx number. This is a supported-enough path that the vendor-adjacent docs describe it, but it is still telling ROCm your card is a different card.
2. NVIDIA pre-Turing: stay on CUDA 12.x. Do not chase a CUDA 13 build. Pin the runtime that still ships 12.x binaries and make sure the driver clears the version floor the project asks for.
3. Try Vulkan. One vulkaninfo --summary tells you whether the device is even visible, and both llama.cpp and Ollama can use it.
4. Fall back to CPU. For small models this is genuinely usable, and it removes the entire compatibility question. What it costs you in memory is covered in our VRAM requirements reference.

If you are still choosing between vendors rather than rescuing a card you own, the tradeoffs are laid out in AMD vs NVIDIA vs Intel for AI.

What This Page Does Not Tell You

• Supported is not the same as fast, and not the same as working. Vendor support tables describe what is tested and shipped. They cannot tell you that a given quantisation, attention kernel or custom node will run on your combination. The only honest test is your own machine.
• These lists move on a release cadence, not a yearly one. ROCm 7.14.0 is dated 2026-07-16 and CUDA is at 13.3 Update 1 as this is written. A row here can go stale in weeks. Every source is linked below precisely so you can check rather than trust.
• No performance data appears on this page by design. Cross-vendor throughput comparisons need identical models, quantisations, context lengths and batch settings on hardware we control. We do not have every architecture in this matrix, so there are no numbers here rather than invented ones.
• Data-centre rows are included for completeness. MI300-class and H100-class hardware is in the tables because the gfx and compute-capability values are the same identifiers you will see in error messages, not because these are recommendations.

FAQ

What compute capability do I need for CUDA 13?

Turing, compute capability 7.5, or newer. NVIDIA's CUDA 13.0 release notes state that support for Maxwell, Pascal and Volta is feature-complete and that "Offline compilation and library support for these architectures have been removed in CUDA Toolkit 13.0 major version release," and that CUDA 13.0 "supports all NVIDIA architectures from Turing through Grace Blackwell." Older cards are not bricked — they remain targetable with a CUDA 12.x toolkit and with prebuilt binaries from projects that still ship 12.x builds.

Does my GTX 1080 Ti still work with Ollama?

By Ollama's own published requirements, yes. It documents support for compute capability 5.0 and above with driver 550 or newer, and adds that compute capabilities 5.0 through 6.2 require driver 570 or newer. A GTX 1080 Ti is compute capability 6.1, so it falls in that band and the driver version is the thing to verify. vLLM is a different story — it requires compute capability 7.5 or higher, which excludes Pascal entirely.

What is the AMD equivalent of nvidia-smi?

rocm-smi, which ships with ROCm. rocm-smi --showproductname gives you the card, and rocminfo gives you the gfx target you need to match against the ROCm compatibility matrix. The gfx string, not the retail name, is what every error message and support table is actually keyed on.

Is my Intel Arc A770 supported for local LLMs?

It is listed among the verified devices for llama.cpp's SYCL backend, alongside the A750, A730M and the B580. For Ollama the route is different: Intel GPUs come in through Vulkan on Windows and Linux rather than SYCL, and the Linux path needs Intel's client GPU driver packages installed first.

My AMD card is not in the ROCm list. Is that the end of it?

No, but be clear about what you are doing. The documented workaround is HSA_OVERRIDE_GFX_VERSION, which tells ROCm to treat your device as a different gfx target — Ollama's docs use HSA_OVERRIDE_GFX_VERSION="10.3.0" as the worked example. It commonly works for cards that are close relatives of a supported target and does nothing useful for ones that are not. Vulkan is the alternative that requires no lying to the driver.

Can I mix an NVIDIA and an AMD GPU in one machine?

Not within a single CUDA or ROCm process — those are separate compute stacks with separate builds. Vulkan is the only backend in this matrix that enumerates devices from multiple vendors through one API, and whether a given runtime will actually schedule work across two heterogeneous devices is a per-project question, not a driver one.

Sources

• NVIDIA CUDA Toolkit Release Notes — deprecated architectures, CUDA 13.0 removals, current toolkit version
• NVIDIA CUDA GPUs — Compute Capability — architecture to compute-capability mapping
• AMD ROCm Compatibility Matrix — supported gfx targets, ROCm 7.14.0
• ROCm Linux system requirements — per-GPU LLVM targets and supported distributions
• Ollama GPU documentation — compute-capability and driver floors, AMD Linux and Windows lists, Vulkan, HSA_OVERRIDE_GFX_VERSION
• llama.cpp SYCL backend documentation — verified Intel devices, removal of NVIDIA and AMD SYCL support
• llama.cpp build documentation — full backend list
• vLLM GPU installation — compute capability 7.5 floor, ROCm gfx list and version floors, XPU status
• ComfyUI README — AMD, Intel, Apple and other accelerator install paths