# GPU compatibility for LLM inference and Cycles rendering

CUDA, ROCm and a renderer backend answer different compatibility questions. Check the exact GPU, software version and workload before assigning a node.

Author: Retrivium team
Updated: 2026-11-02
Canonical URL: https://retrivium.ai/journal/gpu-llm-renderer-compatibility-matrix/
Language: en

## Separate three layers of compatibility

A GPU may execute general compute kernels while remaining unsuitable for a particular inference engine or renderer. Start with hardware identity, then check the engine's supported installation path, and finally validate the intended workload. These layers should be recorded separately. An architecture name is useful evidence about device generation; it does not certify a model's attention implementation, a quantization kernel or a renderer plugin. A successful device-enumeration command demonstrates discovery rather than sustained correctness, memory fit or production stability.

## NVIDIA: a vLLM floor is not every kernel

Current [vLLM NVIDIA installation requirements](https://docs.vllm.ai/en/stable/getting_started/installation/gpu/) use compute capability 7.5 or later as the hardware floor. Volta, Pascal and Maxwell therefore need a different deliberately compatible inference route; they should not be advertised as current vLLM targets from VRAM alone. Blackwell also needs an appropriate build, runtime and driver, despite being newer than the minimum. Check the selected model and numerical format. A [llama.cpp build path](https://github.com/ggml-org/llama.cpp/blob/master/docs/build.md) can be evaluated independently, but its build instructions are not a universal per-card certification.

## AMD: exact ROCm SKU and operating system matter

The [ROCm compatibility matrix](https://rocm.docs.amd.com/en/latest/compatibility/compatibility-matrix.html) is versioned and distinguishes devices and operating environments. A hardware-reference table is not the same as that support matrix. Radeon, Instinct and integrated APUs must retain their own identities. Being able to compile HIP code does not prove that an inference framework supplies the required attention or quantization kernels. For an unlisted legacy device, describe a Vulkan experiment only as conditional on driver features, device discovery and successful model tests, rather than quietly relabelling it officially supported ROCm inference.

## Cycles CUDA, OptiX and HIP have different boundaries

The checked [Blender 5.2 LTS GPU manual](https://docs.blender.org/manual/en/latest/render/cycles/gpu_rendering.html) sets CUDA and OptiX hardware eligibility at NVIDIA compute capability 5.0 or later; OptiX also has its driver requirement. HIP uses an AMD RDNA 1 or later baseline. Thus a legacy NVIDIA card can cross the renderer's hardware floor while missing current vLLM requirements, and an Instinct CDNA compute device is not automatically a Cycles HIP candidate. These are eligibility boundaries, not frame-time promises. Other rendering engines need their own current support evidence.

## Keep the acceptance record workload-specific

Record device identity, driver, runtime, engine version, selected backend, model or scene revision and numerical settings. First compare correctness with a reference, then measure memory peaks and sustained behaviour. Keep inference and rendering results separate even on one machine. A new driver, framework or scene feature can require another targeted check. Mark an unresolved combination as unresolved rather than borrowing a neighbouring card's result. The catalogue uses these boundaries to explain candidates; it does not claim that all listed hardware has been deployed or benchmarked by Retrivium.

Related articles: [A GPU inference benchmark you can trust](/journal/inference-benchmark-method/), [RAM and VRAM: which memory matters for an AI server?](/journal/ram-vs-vram/). [GPU catalogue](/journal/nvidia-amd-gpu-catalog/).