CPU, GPU AND RAM

Legacy GPUs for LLMs and rendering: experimental versus supported

In this article
THE QUICK TAKE

Older NVIDIA and Radeon GPUs can require legacy software or conditional backend experiments. Missing current certification is different from universal inability to compute.

Avoid both blanket rejection and blanket compatibility

A used GPU should not be declared suitable from capacity alone, nor impossible merely because it is absent from a current framework list. Identify the exact model, architecture and software generation first. A card may retain a viable controlled rendering or small-model experiment while lacking an actively supported production-serving route. The catalogue gives detailed profiles to the more relevant families and groups low-capacity variants. Older GTX 750/900 and GTX 1050-class desktop families need their own exact capacity and driver checks; this is not a claim of exhaustive partner-board coverage.

The CUDA toolkit generation is a real boundary

NVIDIA’s CUDA 13 change explanation describes the removal of offline compilation support for pre-Turing architectures. That is why an older CUDA-capable card cannot simply be assigned the newest build instructions. A deliberately compatible toolkit and driver route may still be needed for Maxwell, Pascal or Volta work. The legacy compute inventory identifies architectures; it does not certify today’s application packages. Preserve build options and versions so an experimental result can actually be reproduced.

Current vLLM and Cycles have different hardware floors

The current vLLM requirements set the NVIDIA hardware floor at compute capability 7.5, excluding Volta and earlier from that current route. The checked Cycles GPU manual uses a lower NVIDIA CUDA/OptiX hardware baseline, subject to driver and feature requirements. Thus a renderer candidate is not automatically a serving candidate. Do not infer RT cores, Tensor cores or modern numerical kernels from a large legacy memory capacity. Render a real scene and test an actual model separately, reporting the exact software path used for each.

Pre-RDNA Radeon needs an explicit experimental status

Older Vega, Polaris and Instinct GCN hardware must not inherit the current RDNA Cycles HIP eligibility rule. Nor does presence in a hardware table prove a current ROCm compatibility-matrix entry. A llama.cpp Vulkan route can be investigated only when the installed driver exposes the needed features, device discovery succeeds and the exact model passes correctness and residency tests. This conditional experiment is different from an official supported ROCm LLM deployment. Keep the backend name and every unresolved limitation visible in the result.

Lifecycle scope and operational cost still matter

A support end date can belong to a specific vGPU or enterprise software product rather than every possible CUDA application. Preserve that scope when discussing maintenance. An older passive board also needs the designed airflow, suitable power delivery and an inspected physical condition. Measure whole-system consumption and completed workload instead of assuming used hardware is efficient because its purchase price is low. Keep controlled experiments separate from a supported service inventory, and do not convert successful startup into a throughput, reliability or income promise.

Related articles: GPU compatibility for LLM inference and Cycles rendering, A GPU inference benchmark you can trust. GPU catalogue.

← All articles