A used card’s listing usually gives two things: the model name and how much VRAM it has. Neither decides whether current local-inference software will run on it. That question is settled by the card’s architecture, its compute capability number, the driver version its platform can supply, and (on AMD) its gfx target string.
Support floors are exactly what bites on the second-hand market, because cards on sale today sit comfortably above them. An older card can fail one of them while looking fine on paper, which is why this check matters for a used card and barely at all for a new one.
Start with compute capability
Every NVIDIA GPU carries a compute capability number that follows from its architecture. NVIDIA publishes the lookup table at CUDA GPUs, which is the place to resolve a model name into a number.
The change that matters most for older cards happened in the CUDA Toolkit. The CUDA Toolkit release notes record, in the Release 13.0 section, that cuFFT “Removed support for Maxwell, Pascal, and Volta GPUs, corresponding to compute capabilities earlier than Turing”, and that cuSPARSE “Dropped support for pre-Turing architectures (Maxwell, Volta, and Pascal)”. That is an architecture-level statement, and it is the reason a card that built and ran happily against a toolkit from a few years ago may not build against a current one.
The same release notes are also useful for what they do not say. Under “Deprecated or Dropped Features” for the toolkit version the page currently documents, CUDA Toolkit 13.3 Update 1, section 2.6.2 “Architectures” contains a single entry: None. Nothing newer has been added to the cut in that release.
Ollama’s floor is a separate, lower one
This is the easiest thing to get wrong. The CUDA Toolkit’s dropped-architecture statement concerns building against NVIDIA’s own toolkit. It is not Ollama’s requirement, and Ollama’s is lower.
The Ollama GPU documentation states: “Ollama supports Nvidia GPUs with compute capability 5.0+ and driver version 550 and newer.” It adds a second condition for the lower end of that range: “Nvidia GPUs with compute capability 5.0 through 6.2 require driver version 570 or newer.”
So for an NVIDIA card destined for Ollama there are two numbers to verify, not one. The compute capability comes from NVIDIA’s table. The driver version is a question about the platform you intend to run on, and the 5.0 through 6.2 band carries the stricter of the two driver requirements. A card can clear the compute-capability bar and still be blocked because the driver branch installable on that machine sits below what the documentation asks for. These are two different projects making two different statements, and satisfying one says nothing about the other.
What llama.cpp asks for
llama.cpp does not state a compute-capability minimum of its own, so no floor should be read into its build documentation. What that document does say, under “Non-Native Builds”, is that after disabling GGML_NATIVE the “resulting binary should run on all CUDA GPUs with optimal performance, though some just-in-time compilation may be required”. By default it builds for whatever hardware is attached at build time.
Where the document points at NVIDIA’s table is narrower than it first appears, and worth reading in context. The reference sits under “Override Compute Capability Specifications”, a troubleshooting section that opens “If nvcc cannot detect your gpu, you may get compile warnings”. The fix it describes is to look up the compute capability of each device and list the values manually in CMAKE_CUDA_ARCHITECTURES. That is a build-configuration step for a card the toolchain fails to identify, not a supported-hardware check, and quoting it as general buying guidance would overstate it.
Two further details from that document affect how a marginal card can be used. Backends are not mutually exclusive: “you can build llama.cpp with both CUDA and Vulkan support by using the -DGGML_CUDA=ON -DGGML_VULKAN=ON options”. And offload control is finer than it looks: “The GPU may still be used to accelerate some parts of the computation even when using the -ngl 0 option. You can fully disable GPU acceleration by using --device none.” Those are the flags that isolate a suspect card when testing whether it contributes at all.
AMD: two vendor documents that disagree
For AMD cards the picture is genuinely unresolved, and that is the most important thing to know before buying an older Radeon. Ollama’s documentation, under the heading “Ollama supports the following AMD GPUs via the ROCm library:”, includes RX 6000-series consumer cards in its list. It also sets a driver requirement: “Ollama requires the AMD ROCm v7 driver on Linux. You can install or upgrade using the amdgpu-install utility from AMD’s ROCm documentation”.
AMD’s own ROCm compatibility matrix, whose page title states “ROCm 7.14.0 compatibility matrix”, tells a narrower story for that generation. Its architecture table lists RDNA 4 entries such as “AMD Radeon RX 9070 XT (gfx1201)” and “AMD Radeon RX 9060 (gfx1200)”, and RDNA 3 entries such as “AMD Radeon RX 7900 XTX (gfx1100)” and “AMD Radeon RX 7600 (gfx1102)”. Under RDNA 2 it lists only “AMD Radeon PRO W6800 (gfx1030)” and “AMD Radeon PRO V620 (gfx1030)”, which are workstation and datacenter parts rather than the consumer RX 6800 and RX 6900 cards.
The two documents, fetched the same day, do not agree about RDNA 2 consumer cards, and neither is restated here as the correct one. The safe move is to check both before relying on either, and to treat a card that appears in one list but not the other as something to test rather than assume.
A second layer on the AMD side lives on that same AMD page. The framework-support table’s vLLM row gives version 0.23 with Python 3.14 (requires PyTorch 2.11.0), scoped to gfx targets gfx950, gfx942, gfx1201, gfx1200, gfx1100, gfx1101, gfx1102, gfx1152, gfx1151 and gfx1150. That list does not include gfx1030, the target for the W6800 and V620 cards that do appear in the general compatibility matrix on the same page. In other words, “supported by ROCm” and “supported by the specific framework you intend to run on ROCm” are two different questions with two different answers.
So write down the card’s gfx target, because that string is the key both documents index on, and check it in all three places: the general matrix, the relevant framework row, and Ollama’s list.
Fallbacks when a card is not officially supported
Both projects document escape hatches, and both describe them as things to try rather than as support guarantees. Ollama notes that “Additional AMD GPU support is provided by the Vulkan Library”, a second path independent of the ROCm list. For ROCm itself, Ollama’s documentation says “If you have an unsupported AMD GPU you can experiment using the list of supported types below”, and gives the mechanism: “you would set HSA_OVERRIDE_GFX_VERSION="10.3.0" as an environment variable for the server”.
llama.cpp documents the same override for its HIP backend. Its build doc says the HIP path “provides GPU acceleration on HIP-supported AMD GPUs. Make sure to have ROCm installed”, and then: “If your GPU is not officially supported you can use the environment variable HSA_OVERRIDE_GFX_VERSION set to a similar GPU, for example 10.3.0 on RDNA2 (e.g. gfx1030, gfx1031, or gfx1035) or 11.0.0 on RDNA3.”
For the Vulkan route, llama.cpp’s setup instructions are per platform rather than universal. Windows users are told to “Download and install the Vulkan SDK with the default settings”, Linux users are pointed at LunarG’s own getting-started guide for the tarball SDK, and Docker users are told the opposite: “You don’t need to install the Vulkan SDK. It will be installed inside the container.” The document states no minimum SDK, API or driver version anywhere, so none should be inferred from it. If the plan for a used card depends on one of these paths working, that dependency is worth acknowledging before the purchase rather than after.
The pre-purchase checklist
- Get the exact model name, not just the family, and resolve it to an architecture and compute capability using NVIDIA’s table.
- For NVIDIA, check whether that architecture is pre-Turing, since the CUDA Toolkit release notes record support for Maxwell, Pascal and Volta being removed at Release 13.0.
- For Ollama on NVIDIA, confirm compute capability 5.0 or higher and driver 550 or newer, and driver 570 or newer if the capability falls in the 5.0 through 6.2 band.
- Confirm that driver branch is installable on the machine the card is going into, not just that it exists.
- For AMD, record the gfx target and check it against Ollama’s list, AMD’s compatibility matrix, and the specific framework row if something like vLLM is part of the plan.
- Decide in advance whether an unsupported-card override or the Vulkan path would be acceptable, since both are documented as experimental.
- Check the llama.cpp build doc for the backend combination to compile, and remember that
--device noneproves whether a card contributes at all.
Where a listing does not state these facts, every item above has to be derived from the model name before the card arrives. That derivation is the difference between a card that runs current local-inference software and one that turns into a compatibility project.