RTX A6000 vs. AMD Radeon AI PRO R9700: Qwen3.6 im LLM-Benchmark

Meine beiden NVIDIA RTX A6000 haben inzwischen fünf Jahre auf dem Buckel. Sie stammen aus der Ampere-Generation und unterstützen die neueren FP8-Formate moderner LLMs nicht mehr direkt in Hardware und leisten trotzdem in meinem Homelab täglich treue Dienste als souveräner KI-Server. Als Dr. Tristan Behrens auf LinkedIn von MIFCOM eine Workstation mit einer brandaktuellen AMD-GPU zum Testen bekam, war meine Neugier sofort geweckt: Wie schlägt sich meine betagte RTX A6000 gegen die AMD Radeon AI PRO R9700, also gegen das Neueste, was AMD aktuell im KI-Segment zu bieten hat?

Die Karte im Mittelpunkt ist die AMD Radeon AI PRO R9700 mit 32 GB VRAM auf RDNA4-Basis. Tristan hat sie mit Qwen3.6-35B-A3B getestet und kam auf beachtliche 134 Token pro Sekunde. Genau diese Zahl wollte ich auf meiner eigenen Hardware nachstellen: mit demselben Modell, derselben Q4-Quantisierung und so weit wie möglich denselben Bedingungen. Denn ein Benchmark ist für mich nur dann etwas wert, wenn er sauber nachvollziehbar ist.

Hier der Post von Tristan auf LinkedIn, auf den ich mich beziehe: Dr. Tristan Test – AMD Radeon AI PRO R9700. Und hier der Link zu MIFCOM, die die Workstation bereitgestellt haben: https://www.mifcom.eu/.

Wie immer geht es erst einmal darum, auf einem Ubuntu-System die Software so zu installieren, dass alles funktioniert und vor allem nachvollzogen werden kann. Los geht’s …

Schritt 1 — Voraussetzungen prüfen

Befehl: nvidia-smi

Befehl: nvcc --version

Befehl: cmake --version

Befehl: gcc --version

Wenn nvcc fehlt (häufig, weil vLLM/Ollama den Compiler nicht brauchen), Toolkit nachziehen — Version ≤ der von nvidia-smi angezeigten:

Befehl: sudo apt update

Befehl: sudo apt install -y build-essential cmake git libcurl4-openssl-dev ccache

CUDA-Toolkit, falls nvcc fehlt (Ubuntu 24.04, passe die Version ggf. an):

Befehl: sudo apt install -y nvidia-cuda-toolkit

Mit dem folgenden Befehl prüfst Du ob nvcc vorhanden ist und wo dieses liegt also unter welchem Pfad

Befehl: ls -l /usr/local/cuda/bin/nvcc

als Ausgabe solltest Du etwas angezeigt bekommen wie folgt.

ingmar@A6000:~/llama.cpp$ ls -l /usr/local/cuda/bin/nvcc
-rwxr-xr-x 1 root root 23099816 Oct 30 2024 /usr/local/cuda/bin/nvcc
ingmar@A6000:~/llama.cpp$

PATH setzen und nvcc verifizieren:

Befehl: export PATH=/usr/local/cuda/bin:$PATH

Befehl: export LD_LIBRARY_PATH=/usr/local/cuda/lib64:$LD_LIBRARY_PATH

Wenn Du möchtest kannst Du mit den beiden folgenden Befehlen den PATH dauerhaft setzen, damit du das nicht in jeder neuen Shell wiederholst:

Befehl: echo 'export PATH=/usr/local/cuda/bin:$PATH' >> ~/.bashrc

Befehl: echo 'export LD_LIBRARY_PATH=/usr/local/cuda/lib64:$LD_LIBRARY_PATH' >> ~/.bashrc

Jetzt prüfen wir ob die Version von nvcc auch wirklich angezeigt wird.

Befehl: nvcc --version

Jetzt sollte folgendes im Terminal Fenster zu sehen sein.

ingmar@A6000:~/llama.cpp$ nvcc --version
nvcc: NVIDIA (R) Cuda compiler driver
Copyright (c) 2005-2024 NVIDIA Corporation
Built on Tue_Oct_29_23:50:19_PDT_2024
Cuda compilation tools, release 12.6, V12.6.85
Build cuda_12.6.r12.6/compiler.35059454_0
ingmar@A6000:~/llama.cpp$

Ich habe wie folgt llama.cpp auf meinem NVIDIA dual RTX A6000 GPU Inferenz-Server eingerichtet.

Befehl: git clone https://github.com/ggml-org/llama.cpp

Befehl: cd llama.cpp

Befehl: cmake -B build -DGGML_CUDA=ON -DCMAKE_CUDA_ARCHITECTURES=86 -DCMAKE_CUDA_COMPILER=/usr/local/cuda/bin/nvcc -DLLAMA_CURL=ON

Befehl: cmake --build build --config Release -j

Wenn der Build ohne Fehler durchgelaufen ist, was er jetzt wirklich sollte, kannst Du diesen mit den folgenden Befehlen verifizieren.

Befehl: ./build/bin/llama-cli --version

Befehl: ls ./build/bin/ | grep -E 'llama-(server|bench|cli)'

Ein schneller test ob auch die GPU erkannt wird.

Befehl: CUDA_VISIBLE_DEVICES=0 ./build/bin/llama-cli --list-devices

Als Ergebnis kam bei mir im Terminal-Fenster folgendes:

Available devices:
CUDA0: NVIDIA RTX A6000 (48537 MiB, 42911 MiB free)

Modell laden & Server starten

Das GGUF (~20 GB) wird beim ersten Start automatisch nach ~/.cache/llama.cpp/ gezogen:

Befehl: CUDA_VISIBLE_DEVICES=0 ./build/bin/llama-server \
--hf-repo unsloth/Qwen3.6-35B-A3B-GGUF \
--hf-file Qwen3.6-35B-A3B-UD-Q4_K_XL.gguf \
-ngl 99 -c 262144 -np 1 -fa on \
--cache-type-k q8_0 --cache-type-v q8_0 \
--jinja \
--host 0.0.0.0 --port 11447 -a qwen3.6-35b

Smoke-Test

Jetzt möchte ich gerne wissen ob mein Setup auch wirklich funktioniert.

Befehl: curl http://localhost:11447/v1/chat/completions \
-H "Content-Type: application/json" \
-d '{"model":"qwen3.6-35b","messages":[{"role":"user","content":"Sag in einem Satz hallo."}]}'

Bei mir kam direkt eine Antwort zurück und hat mir auch einen Wert für die Decode-Rate im timings-Block geliefert.

predicted_per_second: 127.73

Speed-Test mit llama-benchy

Jetzt die eigentlich spannende Frage: Wie schnell ist die Q4-Variante von Qwen3.6-35B-A3B auf einer einzelnen RTX A6000? Zum Messen nehme ich mein bewährtes Werkzeug llama-benchy. Der Charme: Ich messe so, wie es als Nutzer über die API ankommt, und kann das Ergebnis direkt gegen meinen früheren BF16-Lauf über Ollama stellen.

Da llama-benchy per uvx startet, muss ich nichts dauerhaft installieren. Der Lauf geht gegen den llama.cpp-Endpoint auf Port 11447:

Befehl: uvx llama-benchy --base-url http://192.168.2.57:11447/v1 --model qwen3.6-35b --tokenizer Qwen/Qwen3.6-35B-A3B --depth 0 4096 8192 --latency-mode generation

Der Stolperstein bleibt der Tokenizer: Mein llama.cpp-Server meldet sich über den Alias qwen3.6-35b (gesetzt per -a). Das ist kein gültiger HuggingFace-Tokenizer-Name. Deshalb setze ich --tokenizer wieder explizit auf das kanonische Basis-Repo Qwen/Qwen3.6-35B-A3B. Die Quantisierung (hier Q4_K_XL) ändert nichts am Tokenizer, ich verweise also wie immer auf das offizielle Hersteller-Repo.

Mein Ergebnis auf einer NVIDIA RTX A6000 (Q4_K_XL)

Das Modell läuft hier als UD-Q4_K_XL-GGUF auf einer A6000, gepinnt per CUDA_VISIBLE_DEVICES=0, mit q8_0-KV-Cache und Flash-Attention.

llama-benchy 0.3.8 · 2026-06-27 · latency mode: generation · Modell: Qwen3.6-35B-A3B UD-Q4_K_XL · 1× RTX A6000

llama benchy Testlauf

Dann habe ich noch den folgenden Test laufen lassen um etwas mehr tiefe in den Ergebnissen zu erzielen.

Befehl: uvx llama-benchy --base-url http://192.168.2.57:11447/v1 --model qwen3.6-35b --tokenizer Qwen/Qwen3.6-35B-A3B --depth 0 32768 131072 260000 262144 --latency-mode generation

Mein Fazit zum Q4-Lauf

Spannend ist der direkte Vergleich auf derselben Hardware: In meinem früheren Beitrag lag dasselbe Modell unquantisiert in BF16 (über beide A6000 als Layer-Split via Ollama) bei rund 57 t/s im Decode. Die Q4-Variante auf einer einzelnen Karte erreicht hier 124 t/s und damit mehr als das Doppelte. Genau der Hebel, den ich damals als Vermutung formuliert hatte, ist jetzt mit einer Zahl belegt: Auf Ampere, wo FP8 mangels Hardware-Unterstützung kein Thema ist, ist die 4-Bit-Quantisierung der entscheidende Beschleuniger.

Auch das Prefill profitiert deutlich: Mit rund 2.977 t/s verarbeitet die Q4-Variante den Prompt fast doppelt so schnell wie die früheren ~1.500 t/s in BF16. Dadurch sinkt die Wartezeit bis zum ersten Token bei 8k Kontext auf etwa 3,6 Sekunden, gegenüber rund 7 Sekunden zuvor. Schön ist außerdem, dass die Decode-Rate über die Kontext-Tiefe stabil bleibt: von 124 t/s bei leerem Kontext auf 116 t/s bei 8k, also nur rund 7 % Abfall.

Den Anlass für diesen Test gab Tristans LinkedIn-Post zur AMD Radeon AI PRO R9700, die mit derselben GGUF-Q4-Konfiguration auf 134 t/s kam. Damit habe ich endlich eine belastbare Gegenzahl von NVIDIA-Seite: Meine A6000 landet mit 124 t/s (Peak 128) knapp darunter, also bei rund 93 % der Decode-Leistung der deutlich jüngeren RDNA4-Karte. Für eine Profikarte aus dem Jahr 2021 ist das ein bemerkenswert gutes Ergebnis und bestätigt Tristans Eindruck: Beide Karten sind solide Single-Player-Systeme für lokale, souveräne KI.