Ein Token ist ein Speicherzugriff, keine Rechenaufgabe

Gerade kauft gefühlt jeder Entwickler einen Mac mini mit Unified Memory, um lokale Sprachmodelle zu betreiben. Das Marketing funktioniert hervorragend: ein leises Aluminiumgehäuse, ein Speicher für CPU und GPU, kein Treiber-Theater. Die technische Realität dahinter ist deutlich unspektakulärer.

Autoregressive Generierung bei einer Batch Size von 1 hat exakt einen physischen Flaschenhals, und das sind nicht die Teraflops. Um ein einziges Token zu erzeugen, muss die Maschine sämtliche aktiven Gewichte des Modells einmal komplett aus dem Speicher in die Register schaufeln. Danach fällt genau ein Token heraus. Dann beginnt derselbe Durchlauf für das nächste Token von vorn.

Das Verhältnis von Rechenoperationen zu geladenen Bytes ist dabei erbarmungswürdig. Pro Gewicht fällt im Kern eine Multiplikation mit einer Addition an. Die arithmetische Intensität liegt damit bei ungefähr zwei Operationen pro geladenem Wert, während moderne Beschleuniger erst bei mehreren hundert Operationen pro Byte in ihr Rechenlimit laufen. Übersetzt: Die Recheneinheiten warten. Sie warten fast die gesamte Zeit.

Wer eine Hardware-Entscheidung für lokale Inferenz trifft, braucht keine Benchmark-Sammlung, sondern eine Division. Die theoretische Obergrenze der Generierungsgeschwindigkeit ist:

# Obergrenze der Decode-Rate bei Batch Size 1
tokens_pro_sekunde = (Speicherbandbreite_GBs * Effizienz) / Modellgroesse_GB

# Beispiel: 20 GB Gewichte auf 120 GB/s, 70 % erreichbare Bandbreite
#   (120 * 0.7) / 20 = 4.2 Tokens/s   -> und das ist die OBERGRENZE

Drei Dinge sind an dieser Formel wichtig. Erstens ist sie eine Obergrenze, kein Benchmark: Was tatsächlich herauskommt, liegt darunter, nie darüber. Zweitens ist der Effizienzfaktor keine Willkür, sondern die real erreichbare gegenüber der auf dem Datenblatt stehenden Bandbreite. Je nach Speichertyp, Kernel und Zugriffsmuster liegt er grob zwischen 60 und 85 Prozent; ich rechne hier durchgängig konservativ mit 70 Prozent.

Drittens steht im Nenner die Modellgröße im Speicher, nicht die Parameterzahl. Ein Modell mit 32 Milliarden Parametern belegt in 4-Bit-Quantisierung rund 20 GB, in FP16 dagegen über 60 GB. Quantisierung ist deshalb kein reiner Speicherspartrick, sondern die direkteste verfügbare Geschwindigkeitsschraube: Halbe Größe bedeutet in diesem Regime schlicht doppelte Geschwindigkeit.

Dazu kommt der KV-Cache, der mit jedem Token wächst und bei jedem Schritt mitgelesen werden muss. Bei kurzen Chats fällt er kaum ins Gewicht, bei 32k Kontext wird er zu einem eigenen Bandbreitenposten und erklärt, warum lange Kontexte spürbar zäher generieren als kurze.

Setzt man die Datenblattwerte in die Formel ein, entsteht ein Bild, das mit der Preisliste wenig zu tun hat. Unten lässt sich die Modellgröße umschalten. Balken mit Schraffur bedeuten: Das Modell passt nicht in den nutzbaren Speicher, die Plattform fällt für diese Größe komplett aus.

Die Rangfolge ist unabhängig vom Modell immer dieselbe, weil sie ausschließlich von einer einzigen Spezifikationszeile abhängt. Ein Beschleuniger mit HBM2 liegt bei etwa 1 TB/s. Ein Basis-Mac-mini liegt mit seiner 128 Bit breiten Anbindung bei rund 120 GB/s. Das ist ein Faktor von etwa acht, und dieser Faktor landet bei Batch Size 1 fast unverändert auf der Tokenrate.

Die Werte in der Spalte „Speicher für Modell“ sind nicht die Kapazität, sondern das, was nach Framebuffer, Laufzeit und KV-Cache realistisch für Gewichte übrig bleibt. Auf dem Mac begrenzt macOS die der GPU zugestandene Menge; anheben lässt sich das über iogpu.wired_limit_mb, allerdings auf Kosten des Systems.

Interessant wird die Tabelle erst, wenn man die Beschaffungsseite danebenlegt. Rechenzentren mustern gerade in großer Zahl Beschleuniger der Generation um 2018 aus. Diese Karten sind aus Betreibersicht wertlos, weil sie für Training zu langsam und für moderne Datentypen zu alt sind. Ihr HBM2-Stack interessiert sich für diese Einordnung allerdings nicht: Er liefert weiterhin rund 1 TB/s, und das ist exakt die Eigenschaft, auf die es bei lokaler Inferenz ankommt.

Worauf beim Kauf zu achten ist

Diese Karten sind für den Einbau in ein Rack konstruiert, nicht für einen Tower unter dem Schreibtisch. Daraus folgen drei Dinge, die regelmäßig übersehen werden.

Es gibt einen Grund, warum das nicht jeder macht, und er hat nichts mit Physik zu tun. Diese Hardware ist End of Life, und zwar nicht nur im Sinne von „kein Support mehr“, sondern im Sinne von „fällt aus den offiziellen Build-Matrizen heraus“.

Auf AMD-Seite hat der ROCm-Stack die Vega-Generation (gfx906) aus der Support-Matrix genommen. Auf Nvidia-Seite ist Volta (sm_70) den Weg über Deprecation in CUDA 12 zur Entfernung in CUDA 13 gegangen. Praktisch heißt das: Ein pip install liefert unter Umständen ein Wheel, das für deine Karte überhaupt keinen Code enthält, und der Fehler taucht erst zur Laufzeit als kryptischer Kernel-Fehler auf.

# Erste Frage vor jeder Fehlersuche: kennt der Build meine Architektur ueberhaupt?
python3 -c "import torch; print(torch.cuda.get_arch_list())"
# Fehlt sm_70 in der Liste, ist die Karte fuer dieses Wheel schlicht nicht vorhanden.

# AMD: welche GPU-Architektur meldet die Karte?
rocminfo | grep -i gfx
rocm-smi --showproductname

Der pragmatische Weg führt deshalb nicht über die großen Framework-Wheels, sondern über Engines, die man selbst gegen die eigene Architektur baut. Für llama.cpp ist das ein Einzeiler, sobald man das Zielkürzel kennt.

# llama.cpp gegen gfx906 bauen, statt auf ein passendes Wheel zu hoffen
cmake -B build -DGGML_HIP=ON -DAMDGPU_TARGETS=gfx906 -DCMAKE_BUILD_TYPE=Release
cmake --build build --config Release -j $(nproc)

# Fallback, wenn ROCm zickt: das Vulkan-Backend kennt keine Support-Matrix.
# Etwas langsamer, dafuer unabhaengig vom Herstellerstack.
cmake -B build-vk -DGGML_VULKAN=ON -DCMAKE_BUILD_TYPE=Release

# Gegenprobe: erreicht die Karte real die Bandbreite aus Abschnitt 03?
./build/bin/llama-bench -m modell.gguf -p 512 -n 128

Bei vLLM wird es unbequemer. Die Engine ist auf moderne Architekturen ausgelegt: FlashAttention verlangt Ampere oder neuer, und die schnellen Kernels für 4-Bit-Gewichte setzen ebenfalls neuere Compute Capabilities voraus. Auf einer V100 lässt sich vLLM mit älteren Attention-Backends betreiben, auf einer gfx906-Karte ist der Aufwand in der Regel größer als der Gewinn. Wer Batch-Serving mit vielen parallelen Nutzern braucht, ist mit dieser Hardware am falschen Platz. Wer einen einzelnen lokalen Assistenten will, ist mit llama.cpp ohnehin besser bedient.

Es gibt eine Alternative zum Beschleuniger, und sie folgt exakt derselben Logik. Bandbreite entsteht auch aus Breite: Eine aktuelle Epyc-Generation adressiert zwölf Speicherkanäle und kommt damit rechnerisch in den Bereich von 600 GB/s allein über den Systemarbeitsspeicher. Das ist die halbe HBM2-Klasse, aber mit einem entscheidenden Unterschied: Der Speicher ist nicht auf 32 GB begrenzt, sondern auf mehrere hundert Gigabyte ausbaubar. Modelle, die auf keiner bezahlbaren Karte laufen, laufen hier.

Der Haken liegt nicht im Datenblatt, sondern in der Topologie. Die zwölf Kanäle liefern ihre Bandbreite nur, wenn alle Kanäle bestückt sind und wenn der Prozess auf den Kernen läuft, die lokal an den benutzten Speicher angebunden sind. Wer ein Modell blind lädt, verteilt die Gewichte quer über die NUMA-Knoten und liest sie anschließend zu einem großen Teil über den Interconnect statt aus dem lokalen Speicher. Das kostet Bandbreite und treibt die Latenz nach oben, und zwar so deutlich, dass die teure Plattform am Ende hinter einer Desktop-Kiste landen kann.

# Wie sieht die Topologie ueberhaupt aus?
lscpu | grep -i numa
numactl --hardware

# Prozess auf einen Knoten festnageln, Speicher lokal allokieren
numactl --cpunodebind=0 --membind=0 ./llama-server -m modell.gguf

Bis hierhin gewinnt die 200-Euro-Karte jeden Vergleich. Das liegt daran, dass bisher nur der Anschaffungspreis in der Rechnung stand. Sobald der Betrieb dazukommt, dreht sich ein Teil des Bildes, und wer das verschweigt, verkauft genauso unsauber wie das Marketing, gegen das dieser Text argumentiert.

Strom ist der größte Posten

Eine Instinct-Karte hat eine TDP im Bereich von 300 Watt, dazu kommt eine Serverplattform, die auch im Leerlauf nicht bei null steht. Ein Gerät mit Apple-Silicon spielt in einer anderen Liga, und das ist keine Marketingaussage, sondern Messtechnik.

Die daraus folgende Aussage ist unbequem und trotzdem richtig: Im Dauerbetrieb kostet die Karte im ersten Jahr mehr Strom, als sie in der Anschaffung gekostet hat. Wer eine 200-Euro-Karte kauft und die Kiste dann 24/7 durchlaufen lässt, hat den Preisvorteil nach etwa einem Jahr aufgebraucht.

Es gibt zwei wirksame Gegenmittel. Das erste ist ein Power-Limit. Weil die Last bandbreitengebunden ist und die Recheneinheiten ohnehin warten, kostet ein deutlich abgesenktes Power-Limit erstaunlich wenig Tokenrate. Das zweite ist, die Maschine nicht durchlaufen zu lassen, sondern bei Bedarf zu wecken.

# AMD: Leistungsaufnahme deckeln und den Effekt gegen llama-bench messen
rocm-smi --setpoweroverdrive 200
rocm-smi --showpower --showtemp

# Nvidia: dasselbe Spiel
nvidia-smi -q -d POWER
nvidia-smi -pl 200

Wo die Unified-Memory-Kiste tatsächlich gewinnt

Und dann gibt es Fälle, in denen die Entscheidung schlicht andersherum ausfällt. Drei davon sind wichtig.

Kapazität. Ein 70B-Modell in 4 Bit belegt rund 43 GB. Auf einer einzelnen 32-GB-Karte läuft es nicht, egal wie schnell ihr Speicher ist. Ein Gerät mit 64 GB Unified Memory führt es aus, langsam zwar, aber es führt es aus. Genau das zeigt Abbildung 1 im 70B-Modus. Die Gegenmaßnahme sind zwei Karten mit Layer-Split, was den Preisvorteil zwar halbiert, ihn aber nicht aufhebt.

Prompt-Verarbeitung. Das Einlesen eines langen Prompts ist compute-gebunden, nicht bandbreitengebunden. Hier zählen Rechenwerke und moderne Datentypen, und hier spielt die alte Karte einen Teil ihres Vorsprungs wieder zurück. Wer ständig 30k-Token-Kontexte einliest, misst ein anderes Rennen als der, der kurze Fragen stellt.

Mehrere Nutzer. Sobald Anfragen gebatcht werden, teilen sich mehrere Sequenzen denselben Gewichtsdurchlauf. Die arithmetische Intensität steigt, die Last verschiebt sich Richtung Rechenleistung, und der ganze Ansatz dieses Artikels verliert seine Gültigkeit. Für einen Team-Endpunkt gelten andere Regeln, dazu mehr auf der Seite zu GPU- und HPC-Infrastruktur.

Konkret, damit die Diskussion nicht abstrakt bleibt. Das ist der Zuschnitt, den wir für einen privaten oder team-internen Inferenz-Knoten bauen, wenn Datensouveränität die Anforderung ist und das Budget nicht bei einem Fertiggerät landen soll.

Der letzte Punkt ist der wichtigste und wird am häufigsten ausgelassen. Rechne vor dem Kauf aus, welche Tokenrate die Physik zulässt, und miss nach dem Aufbau, welche du tatsächlich bekommst. Liegt das Ergebnis weit unter der Rechnung, ist nicht die Hardware zu langsam, sondern der Stack falsch gebaut: falsche Architektur im Build, Gewichte im falschen NUMA-Knoten, ein Teil der Layer auf der CPU, ein Power-Limit zu tief. Alle vier Fehler sind ohne die Vergleichszahl unsichtbar.