In this article
An AMD compatibility report should name the card, OS, driver, backend, model and tested context. “Radeon works” is too broad to reproduce.
For Ollama on AMD, check the exact card, operating system and supported backend together. A Radeon family name is not enough. Confirm device discovery and actual workload placement with a small test before interpreting CPU execution as a general failure of AMD support.
Record the complete hardware combination
Save the full GPU name, VRAM, operating system, driver and Ollama version. Use the official hardware documentation for the supported route. Closely named cards can differ, and a result on Linux does not automatically apply to Windows.
Keep the initial device occupancy in the report. A machine already running graphics or another compute task has a different memory margin from an idle test. This detail matters when another person tries to reproduce your result on the same hardware later.
Distinguish ROCm and Vulkan
These are different software paths with their own requirements and capabilities. Do not switch between them silently and continue calling the result one unchanged configuration. Record the backend actually loaded and consult the relevant platform instructions.
If the documented path fails, inspect backend loading in the server log first. A device-selection problem, missing dependency and insufficient memory require different responses. Avoid beginning with unsupported overrides copied from a different card; first establish what the supported configuration does.
Confirm where inference runs
Load a small control model, run ollama ps and compare the reported placement with system monitoring. Use a short known request and an explicit moderate context so the test has a clear interpretation.
Then repeat with the target artifact. If the small model uses the accelerator while the larger one is split, the next question is memory and placement rather than basic device visibility. Save exact model tags and output behaviour, not just a screenshot of a GPU activity chart.
Evaluate memory separately from support
Context, simultaneous requests and other applications consume resources beyond the model file itself. Mixed CPU/GPU operation can be a supported outcome; judge whether it meets the task’s latency and quality requirements instead of labelling it broken without measurements.
For a useful comparison, change one dimension at a time and retain the last working configuration. Record the discovery log, backend version, model, context and a control answer. That provides a concrete statement about what this particular card can already do, without promising compatibility for every AMD system or treating system RAM as equivalent to additional VRAM.
Turn the check into a practical next step
An AMD compatibility report should name the card, OS, driver, backend, model and tested context. “Radeon works” is too broad to reproduce.
For the documented details, consult the primary documentation; configuration reference. Continue with ollama cpu gpu split and ollama context length setting.