Every VRAM guide on this site assumes an NVIDIA graphics card. That assumption breaks two ways: a reader with an AMD Radeon already on the desk, and a reader who is shopping for a card and seeing Intel Arc prices. Both can run local models. Neither is treated as a first-class case by the official tools.
Verified August 2026 against Ollama’s GPU documentation, llama.cpp’s backend docs, and Intel’s IPEX-LLM project page.
Ollama Supports a Long List of AMD Cards, Zero Intel Cards
Ollama’s GPU documentation splits the world cleanly in two. For AMD it states: “Ollama supports the following AMD GPUs via the ROCm library”, and it names them by product line. For Intel it lists no discrete GPU models at all and only links out to Intel’s own driver page. The practical reading is that, as of this writing, picking up Ollama and running it against an AMD Radeon is a documented path, and picking it up against an Intel Arc is not.
The AMD list is long and reaches back several generations. The current Ollama GPU page names these consumer Radeon RX models for Linux: 9070 XT, 9070 GRE, 9070, 9060 XT, 9060 XT LP, 9060, 7900 XTX, 7900 XT, 7900 GRE, 7800 XT, 7700 XT, 7700, 7600 XT, 7600, 6950 XT, 6900 XTX, 6900 XT, 6800 XT, 6800. It also lists the Radeon PRO W7900 through W6800 and V620, the Radeon AI PRO R9700 and R9600D, the Ryzen AI Max and HX lines, and Instinct accelerators from MI100 up to MI350X. The Windows list is a strict subset: consumer cards stop at the RX 7600, and the Ryzen AI and Instinct parts are absent.
The driver floor on Linux is “the AMD ROCm v7 driver on Linux”, installed via AMD’s amdgpu-install utility; on Windows the page requires “an AMD ROCm v7 / HIP7-capable driver stack”. Cards outside that list still have an escape hatch: the HSA_OVERRIDE_GFX_VERSION environment variable, which Ollama documents in the same page, lets the runtime pretend an older unsupported card is a supported one.
llama.cpp’s HIP Backend Is Where the AMD List Comes From
The AMD support you see in Ollama is not magic. It is the HIP backend in llama.cpp - AMD’s CUDA-compatible API - exposed behind Ollama’s wrapper. The build flag is -DGGML_HIP=ON, and the targets are AMD’s LLVM “gfx” codes, e.g. gfx1030 for an RX 7600-class part. The same doc spells out the override: “use 10.3.0 on RDNA2 or 11.0.0 on RDNA3”, which is what lets a card that AMD’s official stack no longer ships for keep working in practice.
Two practical warnings from that page. First, HSA_OVERRIDE_GFX_VERSION is “not supported on Windows”, so the workaround is Linux-only. Second, the unified-memory flag (GGML_CUDA_ENABLE_UNIFIED_MEMORY=1) is for integrated parts and “hurts performance for non-integrated GPUs”. If you have a discrete Radeon and the model still spills into system RAM, that switch is a likely reason.
Vulkan Is the Cross-Vendor Path That Actually Works
When the ROCm or SYCL path is unavailable, llama.cpp and Ollama both fall back to Vulkan, and the Ollama GPU docs are explicit that “Vulkan is enabled by default when the backend is installed”. This is the one path that names both AMD and Intel in the same sentence: “Linux AMD GPU Instructions” and “Linux Intel GPU Instructions” are linked side by side from the same Vulkan section.
The cost is operational, not technical. Ollama notes that “Vulkan requires additional capabilities or running as root to expose this available VRAM data”, with sudo setcap cap_perfmon+ep /usr/local/bin/ollama as the fix. On mixed systems where the iGPU is unstable, the same page says to point GGML_VK_VISIBLE_DEVICES at the discrete card. And on some Linux distributions the ollama user needs to be added to the render group for AMD Vulkan to work. None of these are deal-breakers, but they are the kind of detail that, if missed, presents as “Vulkan doesn’t see my card”.
Vulkan also tends to lag the vendor-specific stacks on raw throughput, because it is a generic graphics API being asked to do matrix math. The tradeoff is real portability for some lost speed, and any card from any vendor that ships a working Vulkan driver can be expected to run.
Intel’s Discrete Cards Are a Different Story
Intel discrete GPUs - Arc A770, A750, A580, B580 and the rest of the A- and B-series - are supported by llama.cpp’s SYCL backend, not by Ollama’s GPU page. The page lists them explicitly: “Intel Data Center Max Series” (Max 1550 and 1100 verified), “Intel Flex Series, Arc Series” (Flex 170, Arc A770, A730M, A750), “Intel Arc B-Series” (Arc B580), and the built-in Arc GPUs inside Meteor Lake, Arrow Lake and Lunar Lake processors. Verified oneAPI releases for the SYCL backend are 2024.1, 2025.1, 2025.2.1 and 2025.3.3, with the note that “syclcompat” needs “oneAPI 2025.0 or newer”.
The two readings of that asymmetry both matter. The good reading is that the underlying engine supports Intel and the work is just to build the right binary - Windows binaries ship the SYCL runtime in the package, so end-users do not need to install oneAPI themselves. The bad reading is Ollama’s omission: a user with an Arc card who tries Ollama first gets a CPU-only experience with no diagnostic telling them why. Intel’s IPEX-LLM project exists to bridge this, and its README names “Intel Arc A770 or B580” and “Intel Max 1550” as targets - but the same project page records that “Project was archived by owner on Jan 28, 2026”, so the build path now sits on whatever IPEX-LLM 2.2.0 released.
The other honest limit on Intel is the iGPU floor. llama.cpp’s SYCL page states that “if the iGPU has less than 80 EUs, the inference speed will likely be too slow for practical use”, and that “llama-2-7b.Q4_0 requires at least 8.0GB for integrated GPU and 4.0GB for discrete GPU”. Those numbers are from llama-2-7b Q4_0 specifically, but the shape - iGPU needs roughly twice the memory and wants a generous execution-unit count - is what to plan against.
What to Decide Before You Buy or Build
Match the card to the runtime, not the other way round. If you want Ollama’s one-line setup and an AMD card, the Ollama GPU list is the answer. If you have an Intel Arc and want a packaged install, IPEX-LLM 2.2.0 is the project to start from, with the caveat that it is now in read-only archive status. If you want a single binary that talks to anything with a Vulkan driver, llama.cpp built with -DGGML_VULKAN=ON is the most portable bet, at the cost of accepting the throughput tax.
If the card is already on the desk, the CPU-only guide is the fallback that always works: Ollama’s FAQ explains how to confirm whether a model loaded on the GPU or fell back to CPU (via the 100% GPU vs 100% CPU columns in ollama ps), so a card the official lists refuse to talk to at least surfaces that mismatch instead of failing silently. The reverse-hub for shopping by VRAM is the VRAM tier index, and the quantization choices that decide how much of any card gets used are in which quantization format to use.
If the card is still in the box, the existing what to check before buying a used GPU for local AI page is the closer read - it pins the CUDA and ROCm versions by name and lists the gotchas that have already broken this site’s recommendations in past passes.
Bottom Line
Local AI on AMD works through Ollama today, on a long list of consumer Radeon cards from the RX 6800 onwards and on the Radeon PRO and Ryzen AI lines alongside them, with the driver floor at ROCm v7 on Linux. Local AI on Intel discrete GPUs works through llama.cpp’s SYCL backend or through the IPEX-LLM project, neither of which is the path Ollama’s ollama run command takes out of the box. Vulkan is the cross-vendor layer that both ecosystems share, with documented but unexceptional setup steps.
The honest gap this page names, rather than a benchmark chart, is that the AMD path is officially supported and the Intel path requires building, that Intel’s primary installer project went into read-only archive in January 2026, and that integrated graphics on either vendor are slower than the headlines suggest. None of that changes the headline: an AMD or Intel machine is a workable local-AI box. It just changes which sentence you have to read first.