Du möchtest ein Sprachmodell lokal betreiben.

Die erste Reaktion liegt nahe:

Welche Grafikkarte brauche ich?

Die Frage ist berechtigt.

Aber sie kommt eigentlich einen Schritt zu früh.

Denn zuerst müsste man wissen:

Welches Modell?

Welche Quantisierung?

Wie lang soll der Kontext sein?

Wie viele Nutzer greifen gleichzeitig darauf zu?

Soll nur Text erzeugt werden?

Oder auch Bilder?

Soll das Modell interaktiv chatten oder nachts zehntausende Dokumente verarbeiten?

Erst danach lässt sich sinnvolle Hardware auswählen.

Der wichtigste Grundsatz für lokale KI lautet deshalb:

Anwendungsfall
↓
Modell
↓
Speicherbedarf
↓
Geschwindigkeitsanforderung
↓
Hardware

und nicht:

teure GPU kaufen
↓
danach überlegen,
welches Modell darauf laufen könnte

Bei KI ist Speicher oft wichtiger als rohe Rechenleistung

Gaming-PCs werden häufig anhand von Bildrate und Grafikleistung verglichen.

Bei lokalen Sprachmodellen tritt eine andere Frage sehr früh in den Vordergrund:

Passt das Modell überhaupt in den verfügbaren Speicher?

Bei klassischen PCs mit separater Grafikkarte besitzen CPU und GPU unterschiedliche Speicherbereiche. NVIDIA beschreibt dieses Modell ausdrücklich als Host-Speicher auf CPU-Seite und Device-Speicher auf GPU-Seite; bei mehreren diskreten GPUs besitzt zudem jede GPU ihren eigenen Speicher. (NVIDIA Docs)

Damit entstehen zwei zentrale Größen:

RAM
→ Arbeitsspeicher des Computers

und:

VRAM
→ Speicher der Grafikkarte

Beide sind wichtig.

Aber für schnelle GPU-Inferenz ist der verfügbare VRAM häufig die erste harte Grenze.

Die sechs wichtigsten Hardwarebausteine

Ein typischer lokaler KI-Rechner besteht aus denselben Komponenten wie ein gewöhnlicher PC:

CPU
GPU
RAM
SSD
Mainboard
Netzteil

Dazu kommen:

Kühlung
Gehäuse
Netzwerk

Der Unterschied liegt nicht darin, dass KI völlig andere Computer benötigt.

Der Unterschied liegt darin, welche Komponente zum Engpass wird.

Bei einem Office-PC ist vielleicht die GPU fast irrelevant.

Bei einem Gaming-PC zählt hohe Grafikleistung.

Bei einem lokalen LLM-System sind häufig:

VRAM-Kapazität
+
Speicherbandbreite
+
geeignete Rechenleistung

besonders wichtig.

Die GPU übernimmt die eigentliche Parallelrechenarbeit

Sprachmodelle führen sehr viele Matrixoperationen aus.

Solche Berechnungen lassen sich stark parallelisieren.

Genau dafür eignen sich GPUs.

Im CUDA-Programmiermodell arbeitet die CPU als Host und die GPU als paralleler Beschleuniger; Rechenkerne werden auf der GPU ausgeführt, während die CPU unter anderem Programmsteuerung und Datentransfers übernimmt. (NVIDIA Docs)

Sehr vereinfacht:

CPU
→ steuert
→ vorbereitet
→ koordiniert

GPU
→ führt sehr viele
   mathematische Operationen parallel aus

Das erklärt, warum eine starke GPU ein Sprachmodell gegenüber reiner CPU-Inferenz massiv beschleunigen kann.

Die GPU ist aber nicht nur ein Rechenchip

Für lokale KI muss man zwei Eigenschaften getrennt betrachten:

Wie schnell kann die GPU rechnen?

und:

Wie viel Speicher besitzt sie?

Eine GPU kann sehr schnell sein, aber nur relativ wenig VRAM besitzen.

Eine andere Karte kann langsamer rechnen, aber wesentlich mehr Speicher bieten.

Für einen bestimmten KI-Anwendungsfall kann die zweite Karte dadurch nützlicher sein.

Ein einfaches Beispiel

Angenommen, Modell A benötigt während deiner gewünschten Konfiguration ungefähr:

18 GB GPU-Speicher

GPU X:

12 GB VRAM

GPU Y:

24 GB VRAM

Selbst wenn GPU X in bestimmten Benchmarks sehr schnell ist, passt das Modell nicht vollständig hinein.

GPU Y kann dadurch für genau diesen Einsatz wesentlich geeigneter sein.

Das ist einer der fundamentalen Unterschiede zwischen Kaufentscheidungen für Gaming und lokale KI.

Was liegt eigentlich im VRAM?

Zunächst müssen die Modellgewichte gespeichert werden.

Dazu kommen abhängig von Modell, Engine und Einstellungen weitere Daten.

Konzeptionell:

VRAM
├── Modellgewichte
├── KV-Cache
├── temporäre Tensoren
├── Laufzeitpuffer
└── gegebenenfalls weitere Modelle

Inference-Engines reservieren deshalb nicht einfach nur exakt die Dateigröße des Modells. vLLM behandelt den KV-Cache beispielsweise ausdrücklich als eigenen GPU-Speicherbereich und erlaubt, die dafür verfügbare GPU-Speichermenge separat zu steuern. (vLLM)

Modellgröße allein reicht deshalb nicht für die Speicherplanung

Eine Modelldatei ist:

10 GB

Das bedeutet nicht automatisch:

10-GB-GPU reicht.

Zusätzliche Laufzeitdaten benötigen ebenfalls Platz.

Besser ist:

Modellgewichte
+
Kontext / KV-Cache
+
Laufzeitreserven
=
tatsächlicher Speicherbedarf

Die konkrete Größe hängt stark vom verwendeten Modell und der Inference-Software ab. (vLLM)

Der KV-Cache macht lange Kontexte teuer

Während ein autoregressives Sprachmodell Text erzeugt, werden Informationen aus den bereits verarbeiteten Tokens zwischengespeichert.

Dieser Speicher wird üblicherweise als KV-Cache bezeichnet.

Je mehr Kontext gleichzeitig gehalten werden muss, desto größer kann dieser Bereich werden. llama.cpp weist in seiner aktuellen Multi-GPU-Dokumentation ausdrücklich darauf hin, dass der KV-Cache ungefähr mit der Kontextgröße wächst und bei Speicherproblemen eine reduzierte Kontextgröße den VRAM-Bedarf senken kann. (GitHub)

Das bedeutet:

kleiner Kontext
↓
weniger KV-Cache

großer Kontext
↓
mehr KV-Cache

Darum ist „Welches Modell passt?“ keine vollständige Frage

Die bessere Frage lautet:

Welches Modell passt mit meiner gewünschten Quantisierung, Kontextlänge und Parallelität?

Ein Modell kann beispielsweise bei:

8.000 Tokens

komfortabel laufen.

Mit:

128.000 Tokens

kann dieselbe Hardware plötzlich an ihre Speichergrenze gelangen.

Wie stark, hängt von der konkreten Modellarchitektur und Engine ab. Moderne Server-Engines wie vLLM verwalten den KV-Cache deshalb explizit als wesentlichen Teil ihrer Speicherplanung. (vLLM)

Mehr gleichzeitige Nutzer brauchen ebenfalls mehr Speicher

Ein einzelner Chat:

1 laufende Sequenz

ist etwas anderes als:

20 Nutzer
→ 20 parallele Sequenzen

Jede aktive Anfrage benötigt Laufzeitzustand.

vLLM verknüpft deshalb die verfügbare KV-Cache-Kapazität ausdrücklich mit der maximal möglichen Parallelität und weist darauf hin, dass mehr gleichzeitig verarbeitete Sequenzen zusätzlichen Cache-Speicher benötigen. (vLLM)

Damit wird aus:

Passt das Modell?

eine zweite Frage:

Wie viele Nutzer kann es
gleichzeitig bedienen?

Ein Desktopchat und ein KI-Server brauchen deshalb andere Reserven

Desktop:

1 Nutzer
↓
1 Anfrage
↓
Modell

Server:

Nutzer A ─┐
Nutzer B ─┼→ Modellserver
Nutzer C ─┤
...       ┘

Bei einem Server sollte man nicht die gesamte Speicherplanung auf den knappsten möglichen Einzelbetrieb optimieren.

Reserven werden wichtiger.

Wie lässt sich der Speicherbedarf der Modellgewichte grob abschätzen?

Ein stark vereinfachtes Modell lautet:

Parameterzahl
×
Bits je Parameter
÷
8
=
ungefähre Bytezahl

Beispiel:

8 Milliarden Parameter
×
16 Bit
÷
8
≈
16 GB

Das ist nur eine Größenordnung für die Gewichte und kein vollständiger Laufzeitbedarf.

Bei 8 Bit sinkt diese grobe Rechnung

8 Milliarden
×
8 Bit
÷
8
≈
8 GB

Bei 4 Bit:

8 Milliarden
×
4 Bit
÷
8
≈
4 GB

Reale Quantisierungsformate benötigen zusätzlich Metadaten und unterscheiden sich im Detail. Die grundsätzliche Wirkung stimmt jedoch: niedrigere Präzision reduziert den Speicherbedarf. Die Transformers-Dokumentation beschreibt Quantisierung entsprechend als Darstellung von Gewichten beziehungsweise Aktivierungen mit niedrigeren Präzisionen, damit größere Modelle mit geringerem Speicherbedarf geladen werden können. (Hugging Face)

Genau deshalb ist Quantisierung für Heim-KI so entscheidend

Ohne Quantisierung könnte ein Modell beispielsweise nur auf sehr teurer Hardware komfortabel laufen.

Mit 8- oder 4-Bit-Verfahren kann es möglicherweise auf wesentlich zugänglicherer Hardware eingesetzt werden. Hugging Face dokumentiert etwa 8- und 4-Bit-Quantisierung als Verfahren zur erheblichen Reduzierung des Speicherbedarfs großer Modelle. (Hugging Face)

Aber:

kleinere Quantisierung
≠
kostenloser Speichergewinn

Es können Qualitäts- und Performanceunterschiede entstehen.

Deshalb bekommt Quantisierung einen eigenen Artikel.

VRAM ist deshalb häufig die erste Dimensionierungsgröße

Wenn du bereits weißt:

gewünschtes Modell
+
Quantisierung
+
Kontext

kannst du ungefähr bestimmen:

Welchen VRAM-Bereich brauche ich?

Danach wird gefragt:

Welche GPU bietet in diesem Bereich
ausreichend Geschwindigkeit?

Das ist häufig sinnvoller als der umgekehrte Weg.

Viel VRAM macht eine langsame GPU aber nicht automatisch gut

Nehmen wir eine hypothetische Karte:

48 GB VRAM
aber geringe Rechenleistung

und eine andere:

24 GB VRAM
aber sehr hohe Rechenleistung

Passt dein Modell in 24 GB, kann die zweite deutlich attraktiver sein.

Braucht dein Modell 35 GB, scheidet sie möglicherweise aus.

Damit entstehen zwei Schwellen:

1. Genug Speicher?

erst danach:

2. Genug Geschwindigkeit?

Gaming-Benchmarks beantworten diese Frage nur teilweise

Gaming misst andere Arbeitslasten.

Eine Grafikkarte kann für Spiele hervorragend positioniert sein.

Das bedeutet nicht automatisch, dass sie bei:

LLM-Inferenz,

Training,

Bildgenerierung

im gleichen Verhältnis abschneidet.

Für KI sollte man idealerweise Benchmarks der tatsächlich verwendeten Modelle und Software betrachten.

Softwarekompatibilität ist genauso wichtig wie Hardwareleistung

Eine GPU ist nur dann nützlich, wenn deine gewünschte Inference-Software sie sinnvoll unterstützt.

Das CUDA-Ökosystem ist ein wichtiger Grund für die breite Unterstützung von NVIDIA-Hardware in vielen Machine-Learning-Werkzeugen. PyTorch besitzt beispielsweise eine eigene umfassende CUDA-Ausführungsschicht und verwaltet GPU-Tensoren explizit pro CUDA-Gerät. (PyTorch Docs)

Andere Hardwareplattformen können ebenfalls unterstützt werden.

Aber:

Unterstützt Plattform X grundsätzlich?

ist nicht dieselbe Frage wie:

Unterstützt genau meine Engine,
mein Modell und meine Funktionen
Plattform X gut?

Software zuerst prüfen

Bevor du Hardware kaufst:

Welche Inference Engine?
↓
Welche Backends?
↓
Welche Funktionen?
↓
Welche GPU?

Besonders wichtig wird das bei:

Multi-GPU,

Quantisierung,

Flash Attention,

bestimmten Modellarchitekturen.

Die CPU ist bei lokaler KI nicht unwichtig

Eine starke GPU reduziert nicht die CPU auf einen bedeutungslosen Nebenprozessor.

Die CPU übernimmt weiterhin unter anderem:

Anwendungslogik,

Tokenisierung,

Netzwerk,

Dateiverarbeitung,

Orchestrierung,

Datenbankarbeit,

Teile der Inferenz je nach Engine.

CUDA selbst beschreibt das typische System ausdrücklich als heterogene Kombination aus Host-CPU und GPU-Beschleuniger. (NVIDIA Docs)

Wie stark muss die CPU sein?

Das hängt vom System ab.

Bei:

gesamtes LLM vollständig auf GPU

ist eine absolute Spitzen-CPU häufig weniger entscheidend als:

GPU

und:

VRAM.

Bei:

starkem CPU-Offloading

wird sie wichtiger.

Bei:

CPU-only-Inferenz

wird sie zentral.

CPU-only-KI ist durchaus möglich

Lokale LLM-Engines können Modelle teilweise oder vollständig über CPU und System-RAM ausführen.

llama.cpp unterstützt beispielsweise ausdrücklich die Wahl, wie viele Modell-Layer in VRAM liegen sollen; verbleibende Teile können auf dem Host verarbeitet werden. Die aktuelle Dokumentation warnt gleichzeitig, dass weniger GPU-Offloading die Inferenz deutlich verlangsamen kann. (GitHub)

Damit entsteht ein Kontinuum:

CPU-only
↓
teilweise GPU
↓
vollständig GPU

CPU-only kann für kleine Modelle sinnvoll sein

Zum Beispiel:

gelegentliche Nutzung,

kleines quantisiertes Modell,

Batchjob ohne Zeitdruck,

Embeddingaufgabe,

Entwicklungsumgebung.

Wenn eine Antwort fünfmal länger dauert, aber nur zweimal täglich gebraucht wird, kann das vollkommen ausreichend sein.

Für interaktiven Chat wird Geschwindigkeit wichtiger

Ein Nutzer stellt eine Frage.

Dann wartet er.

2 Sekunden

fühlen sich anders an als:

40 Sekunden

bis überhaupt die Antwort sichtbar wird.

Bei interaktiven Anwendungen sollte daher nicht nur geprüft werden:

Läuft es?

Sondern:

Läuft es angenehm?

RAM ist der zweite große Speicherpool

Der normale Arbeitsspeicher übernimmt bei einem lokalen KI-System zahlreiche Aufgaben.

RAM
├── Betriebssystem
├── Inference Engine
├── Modellanteile
├── Dateiverarbeitung
├── Datenbanken
├── Vektorsuche
├── n8n
└── weitere Dienste

Besonders wenn Teile eines Modells nicht im GPU-VRAM liegen, kann zusätzlicher System-RAM wichtig werden. NVIDIA beschreibt CPU- und GPU-Speicher bei diskreten CUDA-Systemen als getrennte Speicherbereiche, zwischen denen Daten übertragen werden können. (NVIDIA Docs)

Genug RAM bedeutet nicht dieselbe Geschwindigkeit wie genug VRAM

Angenommen:

Modell passt nicht in 16 GB VRAM

aber:

64 GB System-RAM vorhanden

Dann kann eine geeignete Engine möglicherweise Teile des Modells im RAM halten.

Das ermöglicht die Inferenz.

Aber die CPU beziehungsweise der Datentransfer zwischen Host und GPU kann zum Geschwindigkeitsengpass werden. NVIDIA weist ausdrücklich darauf hin, dass Zugriffe über Verbindungen zwischen Host- und GPU-Speicher höhere Latenz beziehungsweise geringere effektive Performance besitzen als Daten, die direkt im geeigneten lokalen Speicher liegen. (NVIDIA Docs)

„Es läuft“ und „es läuft schnell“ sind deshalb zwei verschiedene Fragen

Mit ausreichend RAM kann man möglicherweise ein überraschend großes Modell starten.

Aber:

Modell passt

heißt noch nicht:

Modell ist angenehm nutzbar

Gerade bei lokalen Experimenten ist dieser Unterschied wichtig.

Ein sinnvoller RAM-Puffer verhindert Konkurrenz zwischen Diensten

Ein KI-Server betreibt vielleicht gleichzeitig:

Linux
PostgreSQL
n8n
Vector DB
LLM Server
Reverse Proxy
Monitoring

Dann sollte nicht jeder letzte Gigabyte Arbeitsspeicher bereits für das Modell verplant sein.

Betriebssystem und andere Dienste brauchen Reserven.

Wie viel RAM braucht man konkret?

Eine allgemeingültige Zahl gibt es nicht.

Für die Dimensionierung hilft eher:

größtes Modell im RAM
+
weitere Dienste
+
Dateiverarbeitung
+
Reserve

Wenn CPU-Offloading geplant ist, wird der erste Teil deutlich wichtiger.

Wenn sämtliche Modelle vollständig in VRAM liegen, kann der System-RAM stärker nach den übrigen Diensten dimensioniert werden.

Apple Silicon funktioniert anders

Bei klassischen Desktop-GPUs sind System-RAM und GPU-VRAM getrennt.

Apple Silicon verwendet dagegen eine Unified Memory Architecture, bei der CPU und GPU denselben physischen Speicher nutzen. Apple beschreibt MLX ausdrücklich als für dieses gemeinsame Unified-Memory-Modell ausgelegt. (Apple Developer)

Konzeptionell:

klassischer PC

CPU → RAM
GPU → VRAM

gegen:

Apple Silicon

CPU ─┐
     ├→ Unified Memory
GPU ─┘

Unified Memory hat für lokale Modelle interessante Folgen

Ein System mit beispielsweise viel gemeinsamem Speicher kann Modelle aufnehmen, für die auf einem klassischen PC eine diskrete GPU mit entsprechend großem VRAM erforderlich wäre.

Das bedeutet aber nicht:

64 GB Unified Memory
=
64 GB diskreter High-End-VRAM

Architektur, Speicherbandbreite, Rechenleistung und Software unterscheiden sich grundlegend.

Die Zahl allein lässt sich nicht direkt vergleichen.

Der Vorteil ist vor allem der gemeinsame Adressraum

Apple betont für MLX, dass CPU und GPU denselben physischen Speicher verwenden und damit kein klassisches getrenntes Host-/Device-Speichermodell nötig ist. (Apple Developer)

Das kann lokale Modellnutzung sehr komfortabel machen.

Für die Kaufentscheidung sollten dennoch reale Modellbenchmarks auf der gewünschten Hardware herangezogen werden.

Die SSD beeinflusst nicht primär die Tokenberechnung

Sobald ein Modell vollständig im Arbeitsspeicher beziehungsweise VRAM liegt, berechnet nicht die SSD die Tokens.

Trotzdem ist sie wichtig.

Modelle müssen zunächst geladen werden.

Dazu kommen:

Modelldateien
RAG-Dokumente
Datenbanken
Logs
Backups
Bildmodelle
Trainingsdaten

KI-Systeme brauchen überraschend viel Speicherplatz

Ein paar Modelle:

5 GB
15 GB
30 GB

Dann verschiedene Quantisierungen.

Eine Bildmodellbibliothek.

RAG-Dokumente.

Backups.

Aus:

500 GB reichen locker

wird schnell:

SSD fast voll

Darum sollte Speicherkapazität nicht zu knapp geplant werden.

Eine schnelle SSD verkürzt vor allem Lade- und Datenprozesse

Wenn ein Modell von:

SSD
↓
RAM
↓
VRAM

geladen wird, beeinflusst die Datenträgergeschwindigkeit die Startzeit.

Ebenso bei:

großen Dokumentbeständen,

Vektordatenbanken,

Trainingsdaten.

Während der eigentlichen Inferenz sind dagegen GPU-Speicher und Rechenleistung viel unmittelbarer relevant.

NVMe ist für einen KI-Rechner meist die naheliegende Wahl

Moderne NVMe-SSDs bieten hohe Bandbreite und niedrige Latenz.

Das ist besonders angenehm bei:

großen Modelldateien,

häufigen Modellwechseln,

großen Datenbeständen.

Man muss dafür aber nicht zwangsläufig die schnellste verfügbare Enterprise-SSD kaufen.

Die SSD sollte zum realen Datenaufkommen passen.

Ein separates Laufwerk kann sinnvoll sein

Zum Beispiel:

SSD 1
→ Betriebssystem und Anwendungen

SSD 2
→ Modelle und KI-Daten

Das erleichtert:

Kapazitätsplanung,

Backups,

spätere Erweiterung.

Es ist aber keine technische Pflicht.

Das Mainboard entscheidet über Erweiterbarkeit

Für einen einfachen Ein-GPU-Rechner ist die Auswahl relativ unkompliziert.

Sobald du an:

2 GPUs
3 GPUs
mehrere NVMe-SSDs
10-Gbit-Netzwerk

denkst, wird das Mainboard wichtig.

Es bestimmt unter anderem:

Steckplätze,

elektrische PCIe-Anbindung,

physische Abstände,

M.2-Konfiguration.

Ein großer Steckplatz bedeutet nicht automatisch volle PCIe-Bandbreite

Ein Slot kann mechanisch:

x16

aussehen.

Elektrisch aber beispielsweise:

x4

angebunden sein.

Für eine zweite KI-GPU sollte deshalb das Mainboardhandbuch geprüft werden.

Was ist PCI Express überhaupt?

PCI Express verbindet unter anderem:

GPU,

Netzwerkkarten,

NVMe-Geräte

mit dem System.

Für eine diskrete GPU ist PCIe die wichtige Verbindung zwischen:

CPU / RAM
↔
GPU / VRAM

NVIDIA beschreibt beispielsweise Host-GPU-Transfers und Peer-Zugriffe zwischen GPUs ausdrücklich als Kommunikation über geeignete Interconnects wie PCIe beziehungsweise schnellere GPU-Verbindungen, sofern vorhanden. (NVIDIA Docs)

Wenn das Modell komplett auf einer GPU liegt, ist PCIe oft weniger dominant

Das Modell wird geladen.

Danach findet viel der eigentlichen Berechnung innerhalb der GPU statt.

Die CPU muss nicht für jede Rechenoperation den gesamten Modellbestand neu übertragen.

Deshalb kann eine GPU bei reiner Inferenz auch auf einer schmaleren PCIe-Anbindung überraschend gut funktionieren.

Offloading verändert diese Situation

Wenn während der Inferenz häufig Daten zwischen:

RAM
↔
VRAM

bewegt werden müssen, wird die Verbindung wichtiger.

Dasselbe gilt bei bestimmten Multi-GPU-Strategien.

NVIDIA weist darauf hin, dass Zugriffe auf nicht lokal angebundenen Speicher über PCIe oder ähnliche Interconnects deutlich weniger performant sein können als Daten im direkt angebundenen GPU-Speicher. (NVIDIA Docs)

Multi-GPU macht PCIe deutlich interessanter

Mit zwei Grafikkarten entsteht beispielsweise:

GPU 1
↕
PCIe / Interconnect
↕
GPU 2

Wenn ein einzelnes Modell über beide Karten verteilt wird, müssen abhängig von der verwendeten Parallelisierungsstrategie Daten zwischen ihnen ausgetauscht werden.

Wie viel Kommunikation erforderlich ist, hängt stark vom Verfahren ab. (GitHub)

Zwei GPUs ergeben nicht einfach einen gemeinsamen VRAM-Pool

Angenommen:

GPU 1
16 GB

GPU 2
16 GB

Es wäre verführerisch zu sagen:

32 GB VRAM

Das ist als grobe Gesamtkapazität zwar rechnerisch verständlich.

Technisch besitzt aber jede diskrete GPU ihren eigenen Speicher. NVIDIA beschreibt bei Multi-GPU-Systemen ausdrücklich getrennte GPU-Speicherbereiche pro Gerät. (NVIDIA Docs)

Die Software muss das Modell daher bewusst verteilen.

Ein Modell kann dennoch über mehrere GPUs verteilt werden

Aktuelle Engines wie llama.cpp unterstützen mehrere Split-Verfahren und können Modellgewichte beziehungsweise Cache-Daten über mehrere GPUs verteilen. Die aktuelle llama.cpp-Dokumentation nennt unter anderem Layer-, Row- und experimentelle Tensor-Splits. (GitHub)

Damit kann beispielsweise ein Modell verwendet werden, das auf keine einzelne Karte passt.

großes Modell
↓
├── GPU 1
└── GPU 2

Das ist aber nicht dasselbe wie eine einzelne 32-GB-GPU

Bei einer einzelnen GPU liegen:

alle benötigten Daten
→ lokaler VRAM

Bei mehreren Karten können:

Zwischenergebnisse
→ zwischen GPUs

übertragen werden müssen.

Dadurch entstehen zusätzliche Latenz und Kommunikationsaufwand.

Es gibt unterschiedliche Multi-GPU-Strategien

Eine einfache Variante ist:

Layer 1–20
→ GPU 1

Layer 21–40
→ GPU 2

Das entspricht grob einem Pipeline- beziehungsweise Layer-Split.

llama.cpp verwendet einen Layer-Split aktuell als kompatiblen Standardweg, bei dem zusammengehörige Schichten und ihr KV-Cache auf verschiedene GPUs verteilt werden. (GitHub)

Tensor Parallelism funktioniert anders

Dabei wird nicht nur das Modell schichtweise getrennt.

Teile derselben Rechenoperation werden auf mehrere GPUs verteilt.

eine Modellschicht
↓
├── GPU 1
└── GPU 2

Danach müssen Ergebnisse wieder kombiniert werden.

Das kann gute Parallelität ermöglichen.

Erfordert aber stärkere Kommunikation zwischen den GPUs.

llama.cpp bezeichnet seinen aktuellen Tensor-Split ausdrücklich als stärker vom GPU-Interconnect abhängig; vLLM weist ebenfalls darauf hin, dass zusätzliche Tensor-Parallelität Synchronisationsaufwand verursachen kann. (GitHub)

Multi-GPU kann zwei völlig verschiedene Ziele haben

Ziel A:

größeres Modell

Ziel B:

mehr gleichzeitige Anfragen

Das sind nicht dieselben Probleme.

Ein großes Modell über zwei GPUs

Modell
↓
GPU 1 + GPU 2

Das ist Modellparallelität.

Zwei Kopien eines kleinen Modells

GPU 1
→ Modell A
→ Nutzergruppe 1

GPU 2
→ Modell A
→ Nutzergruppe 2

Das ist eher Datenparallelität beziehungsweise replizierte Serving-Kapazität.

vLLM unterstützt beispielsweise Data-Parallel-Deployments, bei denen Modellgewichte auf mehreren GPU-Instanzen repliziert werden, um unabhängige Anfragen beziehungsweise Batches parallel zu verarbeiten. (vLLM)

Zwei GPUs können deshalb auch unabhängig voneinander sinnvoll sein

Beispiel:

GPU 1
→ interaktiver Chat

GPU 2
→ nächtliche Contentverarbeitung

Kein Modell muss über beide verteilt werden.

Die Karten erledigen unterschiedliche Aufgaben.

Das kann bei heterogenen Workloads wesentlich einfacher sein.

Oder jede GPU übernimmt ein anderes Modell

GPU 1
→ großes Sprachmodell

GPU 2
→ Embeddings / Reranker

oder:

GPU 1
→ Text

GPU 2
→ Bildgenerierung

Bei einem vielseitigen KI-Server kann das attraktiver sein als die Karten immer zu einem einzelnen Modell zusammenzuschalten.

Unterschiedliche GPUs können kombiniert werden

Bestimmte Engines können Modelle auch ungleichmäßig auf GPUs mit unterschiedlicher Speicherkapazität verteilen.

llama.cpp erlaubt beispielsweise explizite Aufteilungsverhältnisse über mehrere GPUs. (GitHub)

Konzeptionell:

24-GB-GPU
→ größerer Modellanteil

12-GB-GPU
→ kleinerer Modellanteil

Aber:

Je unterschiedlicher die Karten sind, desto wichtiger werden Tests.

Die langsamere GPU kann den Prozess bremsen

Bei eng gekoppelten Berechnungen müssen die beteiligten Geräte aufeinander warten.

Eine sehr schnelle und eine deutlich langsamere GPU ergeben deshalb nicht automatisch:

schnell + langsam
=
noch schneller

Abhängig vom Split können:

Rechenleistung

oder:

Interconnect

zum Engpass werden.

Multi-GPU sollte deshalb nicht das erste Ziel sein

Wenn ein gewünschtes Modell komfortabel auf eine einzelne GPU passt, ist:

1 GPU

häufig die einfachere Architektur.

Weniger:

Konfiguration,

Kommunikation,

Strom,

Kühlungsprobleme.

Mehrere GPUs werden besonders interessant, wenn ein konkreter Grund existiert.

Ein guter Grund für Multi-GPU: Modell passt nicht

llama.cpp nennt genau dies als einen der Hauptgründe für Multi-GPU: Die Modellgewichte können über mehrere Beschleuniger verteilt werden, damit nicht auf vergleichsweise langsameren System-RAM ausgewichen werden muss. (GitHub)

Zweiter guter Grund: mehr Durchsatz

Viele Nutzer.

Viele Batchjobs.

Dann können mehrere GPUs mehr parallele Arbeit ermöglichen.

Je nach Engine kann das durch:

Model Replicas,

Tensor Parallelism,

Pipeline Parallelism

umgesetzt werden. (vLLM)

Das Netzteil wird bei KI schnell ernst

Eine starke GPU kann unter Last viel elektrische Leistung aufnehmen.

Zwei GPUs:

noch mehr.

Dazu:

CPU,

Laufwerke,

Lüfter.

Das Netzteil muss genügend Leistung und geeignete Anschlüsse besitzen.

Nicht exakt auf dem Papiermaximum dimensionieren

Wenn alle Komponenten theoretisch zusammen beispielsweise:

750 W

erreichen können, wäre ein exakt:

750-W-Netzteil

ohne Reserve keine besonders elegante Planung.

Netzteile sollten nicht ausschließlich nach addierten Nennwerten ausgewählt werden.

Herstellerempfehlungen, Anschlüsse und Lastspitzen müssen ebenfalls berücksichtigt werden.

Stromanschlüsse sind genauso wichtig wie Watt

Eine GPU benötigt bestimmte Stromstecker.

Bei mehreren Karten:

mehrere davon.

Ein Netzteil kann nominell genug Watt besitzen und trotzdem ungeeignete beziehungsweise zu wenige Anschlüsse haben.

Das sollte vor dem Kauf geprüft werden.

Dauerlast unterscheidet sich von kurzem Gaming

Ein lokaler KI-Server kann:

Stunden

oder:

Tage

unter hoher Last rechnen.

Damit werden:

Netzteilqualität,

Temperaturen,

Luftstrom

wichtiger.

Kühlung ist nicht nur eine Komfortfrage

Ein Grafikprozessor wird heiß.

Eine zweite GPU direkt darunter ebenfalls.

Ist zwischen beiden kaum Abstand:

GPU 1
████████

GPU 2
████████

kann die obere beziehungsweise untere Karte schlechter Luft erhalten.

Dann steigen:

Temperaturen,

Lüfterdrehzahl,

Lautstärke.

Consumer-GPUs können sehr breit sein

Moderne Kühler belegen oft deutlich mehr als die Breite eines einzelnen Steckplatzes.

Zwei vorhandene PCIe-Slots bedeuten deshalb nicht automatisch:

Zwei große GPUs passen physisch hinein.

Vor Multi-GPU-Käufen sollte man prüfen:

Slot-Abstand
GPU-Dicke
GPU-Länge
Gehäuseplatz

Gehäusegröße ist bei KI-Workstations nicht nebensächlich

Ein kompaktes Gaminggehäuse kann hervorragend für eine einzelne GPU funktionieren.

Für:

2 dicke GPUs
+
viele Laufwerke
+
starke Kühlung

kann es ungeeignet sein.

Ein größerer Tower kann praktische Vorteile bieten.

Luftstrom sollte geplant sein

Vereinfacht:

kühle Luft hinein
↓
CPU / GPUs
↓
warme Luft hinaus

Nicht:

zwei GPUs
↓
heiße Luft
↓
zirkuliert im Gehäuse

Ein KI-Server unter Dauerlast ist letztlich auch eine kleine Heizung.

Wärme muss aus dem Raum verschwinden

Der Rechner kann intern hervorragend gekühlt sein.

Trotzdem werden beispielsweise:

500 W elektrische Leistung

am Ende weitgehend als Wärme im Raum landen.

In einem kleinen Arbeitszimmer wird das bemerkbar.

Lautstärke gehört zum Einsatzprofil

Rechenzentrum:

Lautstärke zweitrangig.

Server im Wohnzimmer:

nicht.

Workstation neben dem Arbeitsplatz:

ebenfalls relevant.

Hardwaredimensionierung sollte deshalb auch die Umgebung berücksichtigen.

Power Limits können für KI interessant sein

Eine GPU muss nicht zwangsläufig permanent mit maximal möglicher Leistungsaufnahme betrieben werden.

Bei manchen Workloads kann ein reduziertes Power Limit:

Strom sparen,

Temperatur senken,

Lautstärke reduzieren

bei vergleichsweise geringem Leistungsverlust.

Die konkrete optimale Einstellung ist jedoch hardwareabhängig und sollte gemessen werden.

Effizienz kann wichtiger sein als Spitzenleistung

GPU A:

100 Token/s
bei hoher Leistungsaufnahme

GPU B:

85 Token/s
bei deutlich geringerem Verbrauch

Welche besser ist, hängt davon ab:

Einmalige interaktive Nutzung?

24/7-Server?

Strompreis?

Die schnellste Hardware ist nicht automatisch die wirtschaftlichste.

Für einen Server zählt Durchsatz pro Watt

Wenn eine Maschine täglich Millionen Tokens erzeugt, wird:

Tokens pro Sekunde

allein weniger aussagekräftig.

Interessant wird:

Tokens
÷
Energie

beziehungsweise die Gesamtkosten pro erledigter Aufgabe.

Ein Gaming-PC und ein KI-Server können deshalb unterschiedlich optimiert sein

Gaming:

hohe Einzel-GPU-Leistung
gute Bildrate
kurze Nutzungsspitzen

KI-Server:

viel VRAM
Dauerlast
mehrere Nutzer
Stabilität
Speicherkapazität
Energieeffizienz

Es gibt große Überschneidungen.

Aber die Prioritäten unterscheiden sich.

Braucht KI ECC-Speicher?

ECC kann bestimmte Speicherfehler erkennen beziehungsweise korrigieren und ist bei professioneller Server- und Workstation-Hardware verbreitet.

Für:

kritische wissenschaftliche Berechnungen,

lange Trainingsläufe,

Unternehmensserver

kann zusätzliche Zuverlässigkeit wertvoll sein.

Für einen privaten lokalen Chatserver ist ECC dagegen keine zwingende Voraussetzung.

Consumer-Hardware kann für lokale KI ausgesprochen attraktiv sein

Wenn das Ziel lautet:

lokale LLMs ausprobieren,

RAG betreiben,

Content automatisieren,

einzelne Nutzer bedienen,

können gewöhnliche Desktopkomponenten vollkommen ausreichend sein.

Man braucht keinen Rackserver, nur weil die Maschine „KI-Server“ heißt.

„Server“ beschreibt zunächst die Funktion

Ein normaler Desktop kann:

HTTP API
↓
anderen Geräten
KI bereitstellen

Damit ist er funktional ein Server.

Ob er:

Rackgehäuse,

Servermainboard,

ECC,

redundantes Netzteil

braucht, hängt vom tatsächlichen Zuverlässigkeitsbedarf ab.

Eine Workstation ist häufig der Mittelweg

Desktop-Hardware
+
großes Gehäuse
+
starke GPU
+
viel RAM
+
mehrere Laufwerke

Das kann für lokale KI ein sehr attraktives Setup sein.

Leistungsfähig genug.

Trotzdem einfacher und günstiger als professionelle Rechenzentrums-Hardware.

Wann lohnt professionelle GPU-Hardware?

Unter anderem wenn Anforderungen entstehen wie:

sehr großer VRAM

viele parallele Nutzer

professioneller Dauerbetrieb

Rackintegration

Supportverträge

hohe Zuverlässigkeit

spezielle Multi-GPU-Verbindungen

Dann kann Enterprise-Hardware Vorteile besitzen.

Für ein kleines Projekt sollte man nicht mit Enterprise-Hardware beginnen

Ein häufiger Fehler:

Ich will irgendwann vielleicht ein großes Modell nutzen, also brauche ich sofort einen riesigen GPU-Server.

Besser:

realen Workload messen
↓
Engpass identifizieren
↓
gezielt erweitern

Lokale KI lässt sich sehr gut schrittweise aufbauen.

Drei Hardwareprofile helfen beim Denken

Nicht als starre Kaufempfehlung, sondern als Architekturmodelle.

Profil A
Einzelplatz

Profil B
Workstation

Profil C
zentraler KI-Server

Profil A: der lokale Einzelplatz

1 Nutzer
↓
kleines oder mittleres Modell
↓
1 GPU oder CPU

Ziel:

Experimentieren.

Chat.

kleine Automatisierungen.

Hier sind Einfachheit und geringe Investitionskosten besonders wichtig.

Profil B: die KI-Workstation

1–wenige Nutzer
↓
größere Modelle
↓
1–2 GPUs
↓
viel RAM

Zusätzlich:

RAG.

Bildgenerierung.

Entwicklung.

Batchjobs.

Das ist für ambitionierte Selbsthoster häufig eine sehr flexible Klasse.

Profil C: zentraler KI-Server

mehrere Anwendungen
↓
API Gateway
↓
Queues
↓
mehrere Modelle / GPUs

Hier werden zusätzlich wichtig:

Monitoring,

Zugriffsschutz,

Ausfallsicherheit,

Skalierung.

Die Hardware ist nur noch ein Teil der Gesamtarchitektur.

Hardwaredimensionierung sollte immer bei der Aufgabe beginnen

Beispiel A:

Supportmails
→ 1 von 10 Kategorien

Dafür kann ein kleines Modell reichen.

Du brauchst vielleicht keine riesige GPU.

Beispiel B

komplexe Fachtexte
→ hochwertige Langformartikel

Ein größeres Modell kann sinnvoll sein.

Speicherbedarf steigt.

Beispiel C

100.000 Artikel
→ Embeddings

Hier ist Textgenerierung gar nicht das Hauptproblem.

Durchsatz des Embeddingmodells wird wichtiger.

Beispiel D

interaktiver KI-Assistent
für 30 Mitarbeiter

Nun zählt zusätzlich:

Parallelität.

Queue-Länge.

Zeit bis zur ersten Antwort.

Ein einzelnes Modell kann passen, aber nicht genügend Anfragen gleichzeitig bedienen.

Das gleiche Modell kann also völlig unterschiedliche Hardware brauchen

Ein Nutzer:

16 GB reichen möglicherweise.

Viele Nutzer:

mehr Cache
+
mehr Durchsatz
+
vielleicht mehrere GPUs

Die Modellbezeichnung allein reicht nicht zur Dimensionierung.

Welche Rolle spielt die Kontextlänge?

Stell dir zwei Anwendungen vor.

A:

Prompt:
500 Tokens

B:

Prompt:
80.000 Tokens

Dasselbe Modell.

Dieselbe GPU.

Die Anforderungen unterscheiden sich deutlich, weil der Kontext zusätzliche Berechnung und KV-Cache-Kapazität benötigt. vLLM behandelt KV-Cache-Größe und maximale Parallelität deshalb explizit als eigene Servingparameter. (vLLM)

RAG kann Hardware sparen

Statt:

gesamtes Handbuch
→ 100.000 Tokens

kann RAG vielleicht:

5 relevante Abschnitte
→ 5.000 Tokens

in den Kontext legen.

Weniger Kontext bedeutet:

weniger Rechenarbeit

und typischerweise:

weniger KV-Cache-Bedarf.

Damit wird gute Wissensarchitektur zu Hardwareoptimierung.

RAG kann deshalb günstiger sein als einfach mehr VRAM

Man könnte auf ein Kontextproblem reagieren mit:

größere GPU kaufen

oder:

bessere Retrievalstrategie

Manchmal ist die zweite Lösung eleganter.

Hardware sollte schlechte Softwarearchitektur nicht unnötig kompensieren.

Das Gleiche gilt für Batchjobs

Du möchtest 100.000 Texte klassifizieren.

Möglichkeit A:

großes Modell.

Möglichkeit B:

kleines Modell, das für diese Aufgabe ausreichend gut ist.

Wenn das kleine Modell dieselbe notwendige Qualität liefert:

weniger VRAM
+
mehr Durchsatz
+
weniger Strom

Die Modellwahl ist deshalb Teil der Hardwareoptimierung.

„Größer ist besser“ ist bei KI-Hardware eine teure Denkweise

Größeres Modell.

Mehr VRAM.

Mehr GPU.

Mehr Strom.

Mehr Kosten.

Vielleicht erzielt ein kleineres Modell bereits:

98 Prozent der benötigten Qualität.

Dann kann die riesige Hardware wirtschaftlich unsinnig sein.

Evals sollten deshalb vor dem Hardwarekauf stehen

Teste beispielsweise:

Modell A
Modell B
Modell C

mit deinen realen Aufgaben.

Messe:

Qualität
Geschwindigkeit
Speicher

Dann kaufst du Hardware für das kleinste Modell, das die Aufgabe ausreichend erfüllt.

Quantisierung sollte ebenfalls getestet werden

Beispiel:

Modell Q8

gegen:

Modell Q6

gegen:

Modell Q4

Vielleicht ist der Qualitätsunterschied bei deinem Anwendungsfall kaum relevant.

Dann kann die kleinere Variante wesentlich weniger VRAM verlangen.

Speicherbandbreite wird nach dem VRAM zur wichtigen GPU-Eigenschaft

LLM-Inferenz muss große Mengen Modellgewichtsdaten bewegen.

Deshalb ist nicht ausschließlich die Zahl der Recheneinheiten entscheidend.

Auch die Geschwindigkeit, mit der die GPU auf ihren Speicher zugreifen kann, beeinflusst die Leistung.

Das ist ein Grund, warum Karten mit gleichem VRAM nicht automatisch gleich schnell bei LLMs sind.

Ein einzelner „KI-Leistungswert“ existiert daher nicht

Eine GPU besitzt:

VRAM-Kapazität.

Speicherbandbreite.

Rechenleistung in verschiedenen Zahlenformaten.

Architekturmerkmale.

Softwareunterstützung.

Ein sinnvoller Vergleich muss den konkreten Workload berücksichtigen.

Bild-KI kann andere Anforderungen besitzen

Ein Textmodell verhält sich nicht identisch zu einem Diffusions- beziehungsweise Bildmodell.

Wenn ein Rechner gleichzeitig:

Text,

Bild,

Video

verarbeiten soll, müssen verschiedene Workloads berücksichtigt werden.

Eine GPU, die perfekt für deinen LLM-Server ist, muss nicht für jeden anderen KI-Workload optimal sein.

Fine-Tuning verändert die Anforderungen massiv

Bisher sprechen wir hauptsächlich über:

Inference

also:

fertiges Modell verwenden

Training beziehungsweise Fine-Tuning braucht zusätzliche Speicherbereiche für:

Aktivierungen,

Gradienten,

Optimierungszustände.

Der Speicherbedarf kann daher deutlich über reiner Inferenz liegen.

Eine GPU, auf der ein Modell läuft, kann es nicht automatisch trainieren

Beispiel:

Modell läuft
→ 12 GB

daraus folgt nicht:

Training
→ ebenfalls 12 GB

Das sind unterschiedliche Arbeitslasten.

Quantisierte Fine-Tuning-Verfahren wie QLoRA wurden gerade entwickelt, um den Speicherbedarf solcher Anpassungen deutlich zu reduzieren. Die Transformers-Dokumentation beschreibt 4-Bit-Quantisierung ausdrücklich auch im Zusammenhang mit QLoRA. (Hugging Face)

Hardware für Fine-Tuning sollte deshalb separat geplant werden

Wenn dein Ziel nur lautet:

lokales Modell benutzen

musst du nicht unnötig Hardware für Training kaufen.

Wenn Fine-Tuning geplant ist:

andere Rechnung.

Mehr RAM kann bei Fine-Tuning ebenfalls wichtig werden

Datenaufbereitung.

Datensätze.

Checkpointing.

Offloading.

Training ist insgesamt speicher- und I/O-intensiver als ein einzelner Chat.

Das wird beim konkreten Fine-Tuning-Setup separat gemessen.

Für einen KI-Rechner ist Aufrüstbarkeit wertvoll

Lokale KI entwickelt sich schnell.

Heute:

ein Modell.

Morgen:

größerer VRAM-Bedarf.

Deshalb kann ein System attraktiv sein, das später:

mehr RAM,

zweite SSD,

zweite GPU

aufnehmen kann.

Aber für theoretische Erweiterbarkeit sollte man nicht unverhältnismäßig viel bezahlen

„Vielleicht irgendwann drei GPUs“ kann sonst heute zu:

riesigem Mainboard,

riesigem Netzteil,

riesigem Gehäuse

führen, das nie genutzt wird.

Die Wahrscheinlichkeit der Erweiterung sollte realistisch eingeschätzt werden.

Eine zweite GPU ist eine ganz konkrete Entscheidung

Vorher prüfen:

Passt sie physisch?

Genug PCIe-Anbindung?

Genug Netzteilleistung?

Genug Anschlüsse?

Genug Kühlung?

Unterstützt die Software meinen gewünschten Split?

Erst wenn alle Fragen beantwortet sind, ist Multi-GPU wirklich geplant.

Unterschiedliche Aufgaben können unterschiedliche Upgradepfade haben

Zu wenig Modellkapazität:

mehr VRAM

Zu geringe Batchleistung:

zweite GPU

Zu wenig Dateispeicher:

größere SSD

CPU-Offload zu langsam:

stärkere CPU / mehr GPU-Offload

Es gibt keinen universellen KI-Upgrade-Knopf.

Monitoring zeigt den echten Engpass

Beispiel:

GPU:

99 %

VRAM:

70 %

Dann könnte mehr Rechenleistung helfen.

Anderes System:

GPU:

60 %

VRAM:

99 %

Nun ist eher Speicher die Grenze.

Oder die GPU langweilt sich

GPU:

20 %

aber:

CPU:

100 %

Vielleicht liegt zu viel Inferenz auf der CPU.

Oder Datenvorbereitung ist langsam.

Oder die Anwendung liefert der GPU nicht genügend Arbeit.

Ohne Monitoring wäre ein GPU-Upgrade möglicherweise Geldverschwendung.

Deshalb erst messen, dann kaufen

Workload
↓
Monitoring
↓
Engpass
↓
Upgrade

Das ist dieselbe vernünftige Methode wie bei normalen Servern.

Ein KI-Server braucht auch Netzwerk

Wenn nur lokal am selben PC gearbeitet wird:

wenig relevant.

Wenn zehn Geräte zugreifen:

Netzwerk wird Teil der Architektur.

Clients
↓
LAN
↓
KI-Server

Textanfragen selbst erzeugen typischerweise keine riesigen Datenmengen.

Bei:

großen Dateien,

Bildern,

Videos,

Modellübertragung

kann Netzwerkbandbreite jedoch wichtiger werden.

Gigabit-Ethernet kann für viele Textanwendungen reichen

Ein Prompt und eine Textantwort sind relativ klein.

Du brauchst nicht automatisch:

100-Gbit-Netzwerk

für einen internen Chatserver.

Bei:

großen RAG-Dokumenten,

zentralem Storage,

mehreren Servern

können schnellere Netze interessant werden.

WLAN funktioniert ebenfalls, ist aber weniger vorhersehbar

Für Chat:

oft problemlos.

Für:

große Modellfiles,

Server-Backups,

viele parallele Dateitransfers

ist kabelgebundenes Netzwerk häufig angenehmer.

Ein lokaler KI-Server kann trotzdem aus dem Internet erreichbar sein

Zum Beispiel über:

VPN.

Das ändert die Hardwareanforderungen kaum.

Aber die Sicherheitsanforderungen steigen.

Wie bereits unter lokale KI beschrieben, sollte eine Inference-API nicht unnötig offen im Internet stehen.

Die Hardware muss zur Betriebsdauer passen

Desktop:

ein paar Stunden täglich

Server:

24/7

Beim Dauerbetrieb werden Eigenschaften wichtiger wie:

Stromverbrauch,

Temperatur,

Lüfterqualität,

Datenträgerhaltbarkeit,

Monitoring.

Ein lokaler Server muss nicht immer laufen

Automatisierungen finden nur nachts statt?

Dann könnte die Maschine:

bei Bedarf starten

oder:

nur zu bestimmten Zeiten aktiv sein.

Das spart Strom.

Ob automatisches Ein- und Ausschalten praktisch ist, hängt vom Workflow ab.

Modellladezeit gehört dann zur Rechnung

Wenn der Server für jede einzelne Anfrage erst:

booten
↓
Modell laden
↓
antworten

muss, wird die Nutzererfahrung schlecht.

Für seltene Batchjobs kann das trotzdem völlig sinnvoll sein.

Der beste Rechner für Chat ist nicht zwingend der beste Batchserver

Chat optimiert:

niedrige Latenz

Batch:

hoher Durchsatz

Multi-GPU-Konfigurationen können je nach Parallelisierungsstrategie diese Ziele unterschiedlich gut unterstützen; llama.cpp unterscheidet beispielsweise Layer- und Tensor-Splits ausdrücklich auch nach ihren Performancecharakteristika, während vLLM für hohe Servinglast verschiedene Formen von Tensor-, Pipeline- und Data-Parallelität anbietet. (GitHub)

Für Hardwarevergleiche sollte deshalb der richtige Benchmark gewählt werden

Nicht:

Irgendein KI-Benchmark

sondern möglichst:

mein Modell
+
meine Quantisierung
+
meine Kontextgröße
+
meine Engine

Dann erhältst du eine Zahl, die für deine Anwendung Bedeutung hat.

Tokens pro Sekunde sind für LLMs nützlich

Eine häufige Kennzahl lautet:

Tokens / Sekunde

Sie beschreibt ungefähr, wie schnell die Ausgabe generiert wird.

Aber sie ist nicht die einzige relevante Größe.

Zeit bis zum ersten Token ist für Chat besonders wichtig

Ein Modell kann anschließend:

50 Tokens/s

erzeugen.

Wenn es vorher:

30 Sekunden

für einen riesigen Prompt benötigt, wirkt die Anwendung trotzdem langsam.

Daher sollte man unterscheiden:

Prompt / Prefill

und:

Token Generation

Multi-GPU- und Serving-Systeme optimieren diese Phasen teilweise unterschiedlich. llama.cpp beschreibt in seiner Multi-GPU-Dokumentation beispielsweise unterschiedliche Eigenschaften von Pipeline- und Tensor-Parallelismus bei Prefill und Token-Generation. (GitHub)

Durchsatz wird für Server wichtiger

Ein Modell antwortet einem Nutzer:

sehr schnell.

Aber sobald Nutzer zwei dazukommt:

alles blockiert.

Dann ist Einzelrequest-Geschwindigkeit nicht genug.

Für einen Server interessiert zusätzlich:

Anfragen pro Sekunde

Tokens pro Sekunde über alle Nutzer

maximale parallele Sequenzen

Batchfähigkeit ist eine Software- und Hardwarefrage

Eine geeignete Serving Engine kann mehrere Anfragen bündeln beziehungsweise effizient parallel verarbeiten.

Das kann die GPU besser auslasten.

Benötigt aber ebenfalls Speicher für parallele Sequenzen. vLLM koppelt deshalb Batch- und Concurrency-Einstellungen explizit an den verfügbaren KV-Cache-Speicher. (vLLM)

Mehr VRAM kann dadurch auch mehr Durchsatz bedeuten

Nicht nur:

größeres Modell

sondern:

mehr gleichzeitige Kontexte

können von zusätzlichem Speicher profitieren.

Das ist besonders bei Servern wichtig.

Warum VRAM einen eigenen Artikel braucht

Wir haben nun bereits mehrere unterschiedliche Verbraucher:

Modellgewichte

KV-Cache

Kontext

Parallelität

temporäre Daten

Dazu:

Quantisierung

und:

Multi-GPU

Das lässt sich nicht sinnvoll auf:

8 GB klein, 16 GB gut, 24 GB besser

reduzieren.

Darum behandeln wir VRAM als nächsten eigenständigen Grundlagenartikel.

Vor dem Hardwarekauf sollte ein Modell ausprobiert werden

Wenn möglich:

auf vorhandener Hardware.

Cloud-GPU für einen kurzen Test.

geliehene Maschine.

kleinere Variante.

Damit lässt sich herausfinden:

Ist die Modellqualität überhaupt ausreichend?

Es wäre ärgerlich, für ein bestimmtes 30B-Modell Hardware zu kaufen und danach festzustellen:

Ein 8B-Modell löst die Aufgabe genauso gut.

Hardware sollte nicht das Experiment vorwegnehmen

Ein sehr guter Ablauf:

1. Aufgabe definieren
↓
2. Testdaten erstellen
↓
3. Modelle vergleichen
↓
4. Quantisierungen vergleichen
↓
5. benötigten Speicher messen
↓
6. gewünschte Geschwindigkeit definieren
↓
7. Hardware wählen

Das minimiert Fehlkäufe.

Ein einfaches Planungsschema

Frage 1:

Was soll die KI tun?

Frage 2:

Welches kleinste Modell
erfüllt die Qualitätsanforderung?

Frage 3:

Wie viel Speicher braucht
dieses Modell in meiner Konfiguration?

Frage 4:

Wie viele Nutzer / Jobs gleichzeitig?

Frage 5:

Welche Geschwindigkeit brauche ich?

Erst jetzt:

GPU auswählen.

CPU danach dimensionieren

Braucht die Anwendung:

viel Offloading?

umfangreiche Datenverarbeitung?

gleichzeitige Dienste?

Wenn nein:

muss die CPU nicht zwingend der teuerste Prozessor am Markt sein.

RAM danach dimensionieren

System
+
Dienste
+
Offloading
+
Reserve

Nicht:

genau genug,
damit es gerade startet

SSD danach dimensionieren

Modelle
+
Daten
+
Datenbanken
+
Logs
+
Wachstum

und gegebenenfalls:

Backups separat.

Mainboard danach

Ein GPU:

einfach.

Zwei GPUs:

Slot- und Laneplanung.

Drei GPUs:

bereits deutlich anspruchsvoller.

Netzteil und Kühlung zuletzt – aber nicht als Nebensache

Wenn feststeht:

welche GPUs,

welche CPU,

wie viele Laufwerke,

kann das Netzteil sinnvoll dimensioniert werden.

Gehäuse und Kühlung müssen diese Komponenten auch physisch und thermisch beherrschen.

Ein minimalistischer lokaler KI-Rechner

Konzeptionell:

CPU
↓
genug RAM

1 GPU
↓
genug VRAM

1 schnelle SSD

Mehr braucht ein großer Teil privater lokaler KI-Anwendungen prinzipiell nicht.

Ein KI-Server für mehrere Dienste

CPU
↓
viel RAM

GPU 1
GPU 2

mehrere SSDs

schnelles Netzwerk

Monitoring

Dann kommen Infrastrukturthemen stärker ins Spiel.

Eine universelle „beste KI-Hardware“ gibt es nicht

Der Nutzer mit:

kleinem 7B-Chatmodell

hat andere Anforderungen als jemand mit:

großem Modell über zwei GPUs

und wieder andere als:

100 gleichzeitige API-Nutzer

Deshalb sind pauschale Hardwarelisten schnell irreführend.

Der wichtigste Hardwarewert hängt von der Aufgabe ab

LLM passt nicht:

VRAM

LLM ist zu langsam:

GPU-Leistung / Speicherbandbreite

CPU-Offload langsam:

CPU / RAM-Bandbreite

Modell lädt langsam:

SSD

zwei GPUs kommunizieren langsam:

Interconnect / PCIe

Server blockiert bei vielen Nutzern:

GPU-Kapazität / Servingarchitektur

Hardware sollte als System betrachtet werden

Eine riesige GPU an:

zu wenig RAM,

schlechter Kühlung,

knappem Netzteil

ist kein guter KI-Server.

Ebenso ist:

128 GB RAM

keine Lösung, wenn das gewünschte Modell für interaktive Nutzung fast vollständig über eine langsame CPU laufen muss.

Die Komponenten müssen zusammenpassen.

Was du dir über KI-Hardware merken solltest

Für lokale KI ist die Grafikkarte häufig die wichtigste Komponente.

Aber die eigentliche Kaufentscheidung beginnt nicht bei der GPU.

Sie beginnt beim Anwendungsfall.

Aufgabe
↓
Modell
↓
Quantisierung
↓
Kontext
↓
Parallelität
↓
Hardware

Bei diskreten GPUs sind CPU-RAM und GPU-Speicher getrennte Bereiche. Jede GPU besitzt ihren eigenen Device-Speicher; bei mehreren GPUs entsteht daher nicht automatisch ein gemeinsamer großer VRAM-Pool. (NVIDIA Docs)

Für schnelle LLM-Inferenz ist besonders wichtig:

Passt das Modell
mitsamt Laufzeitdaten
in den VRAM?

Der Speicherbedarf besteht nicht nur aus:

Modellgewichten

sondern zusätzlich beispielsweise aus:

KV-Cache

temporären Daten

Serving-Reserven

Inference-Engines wie vLLM verwalten den KV-Cache deshalb ausdrücklich als eigenen GPU-Speicherbereich. (vLLM)

Die Kontextlänge beeinflusst diesen Bedarf.

mehr Kontext
↓
mehr Cache
↓
mehr Speicher

Auch parallele Nutzer erhöhen den Speicherbedarf für laufende Sequenzen. (vLLM)

Quantisierung reduziert den Speicherbedarf der Modellgewichte, indem niedrigere numerische Präzision verwendet wird. Moderne Frameworks unterstützen dafür unter anderem 8- und 4-Bit-Verfahren. (Hugging Face)

Dadurch ergibt sich eine wichtige Reihenfolge:

genug VRAM?
↓
ja
↓
wie schnell ist die GPU?

Nicht:

welche GPU ist im Gaming
am schnellsten?

Die CPU bleibt wichtig für:

Orchestrierung

Datenverarbeitung

Offloading

CPU-Inferenz

aber sie ist bei vollständig GPU-residenten Sprachmodellen häufig nicht die erste Dimensionierungsgrenze.

Der RAM wird wichtig für:

Betriebssystem

Dienste

Datenbanken

RAG

CPU-Offloading

und sollte ausreichend Reserve besitzen.

Bei Apple Silicon existiert eine andere Architektur: CPU und GPU teilen denselben physischen Unified Memory, statt wie bei typischen diskreten GPU-Systemen jeweils getrennte RAM- und VRAM-Bereiche zu besitzen. (Apple Developer)

Die SSD bestimmt vor allem:

Modellspeicher

Ladezeiten

Datenbestände

RAG-Daten

Backups

nicht unmittelbar die Geschwindigkeit jedes erzeugten Tokens.

Bei Multi-GPU gilt:

16 GB + 16 GB

können softwareseitig für ein größeres Modell gemeinsam nutzbar gemacht werden.

Sie werden aber nicht physisch zu:

einer 32-GB-GPU

Mehrere Engines können Modelle über GPUs verteilen; llama.cpp unterstützt aktuell beispielsweise Layer- und Tensor-Split-Verfahren. (GitHub)

Je nach Split entsteht zusätzliche Kommunikation.

GPU 1
↔
GPU 2

Deshalb kann die Geschwindigkeit der Verbindung zwischen den GPUs relevant werden. Tensorparallelität ist typischerweise kommunikationsintensiver als eine einfache schichtweise Verteilung. (GitHub)

Mehrere GPUs können aber auch unabhängig voneinander arbeiten.

GPU 1
→ Modell / Nutzergruppe A

GPU 2
→ Modell / Nutzergruppe B

Das kann für hohe Serverlast einfacher und effizienter sein; Serving-Systeme wie vLLM unterstützen dafür auch replizierte Data-Parallel-Deployments. (vLLM)

Und schließlich gehören zu einem KI-Rechner ganz gewöhnliche technische Grundlagen:

ausreichendes Netzteil

geeignetes Mainboard

genügend Platz

guter Luftstrom

passende SSD-Kapazität

sinnvolle Netzwerkverbindung

Eine lokale KI-Maschine ist kein exotischer Computer.

Sie ist ein normaler Rechner mit ungewöhnlich speicher- und rechenintensivem Workload.

Die wichtigste praktische Erkenntnis lautet deshalb:

Kaufe nicht möglichst viel KI-Hardware. Kaufe die Hardware, die zu deinem kleinsten ausreichend guten Modell und deinem tatsächlichen Nutzungsszenario passt.