In this article
Radeon RX 6700 XT is an official RDNA 2 card with 12 GB GDDR6 and a 230 W board specification.
Radeon RX 6700 XT is an official RDNA 2 card with 12 GB GDDR6 and a 230 W board specification. Practical evaluation begins with reproducible device and backend checks rather than borrowing another machine result.
Official variants and the memory boundary
The table follows AMD materials for this model. It describes dedicated device memory, not system RAM. A “not verified” entry preserves a source gap; a neighboring configuration cannot supply the missing specification.
| AMD variant | Dedicated memory | Board power |
|---|---|---|
| 12 GB | 12 GB GDDR6 | 230 W |
Establish the LLM software path
Radeon RX 6700 XT is absent from the checked ROCm Core SDK 10.1.0 GPU list. Support for a neighboring model cannot be transferred through a shared generation or a similar name. For a separate experiment, the llama.cpp build documentation describes a Vulkan backend. That route requires a suitable driver, detection of the actual device, and validation of the selected GGUF; Vulkan in a specification does not establish that every operation works. Save tensor-placement logs and compare output with a reference run before concluding that the GPU is actually involved. This is not a claim of current official ROCm support for this card.
A practical scenario for this model
Consider an experimental Vulkan run that fails after detecting the card. Separate device detection, reading the GGUF, and executing the first request into different stages. Preserve the driver and binary versions, complete model revision, and last successful action. A reference file that loads before an operation fails represents a different failure class from a device absent from the system. Avoid changing the driver, quantization, and context simultaneously because the resulting experiment becomes difficult to explain. A small fixed fixture is useful precisely because it can be repeated after one change. The 12 GB capacity does not determine which stage should succeed, and assuming sufficient memory cannot repair an unsupported operation. The record should describe an observed boundary rather than guess at the whole card capability.
Validate Blender Cycles separately
RDNA 2 meets the HIP hardware floor in the Blender Cycles 5.2 LTS manual: RDNA 1 or newer. This renderer requirement is independent of ROCm LLM support; validate the actual driver, build, and scene on the intended machine.
Use a separate small scene and HIP log to validate Cycles. Success in another Vulkan application can help diagnose a driver but cannot replace renderer-specific validation.
Preserve a machine-level acceptance record
The table gives AMD board-power specifications, not measured whole-computer consumption. Check the power supply, connectors, card dimensions, and airflow path for the actual system separately. Board power cannot establish inference speed.
Preserve the RX 6700 XT stage sequence, including successful steps. This localizes faults without the vague conclusion “GPU does not work” or a promise about an untested model.
The acceptance artifact should connect board identity, software versions, model revision, and the workload actually exercised. After any of those changes, the old result describes its original run rather than establishing compatibility of the new configuration.
Related reading
llama.cpp GPU layers: verify partial model offloading; Idle render farms: assessing a second GPU workload; NVIDIA and AMD GPU catalogue for LLM inference and server rendering.