Hardware für lokale LLMs: GPU-Server richtig auslegen

Wer ein Sprachmodell im eigenen Haus betreiben will, stellt meist zuerst die Frage nach der Grafikkarte. Diese Reihenfolge führt oft in die Irre: Eine Komponentenliste sagt wenig, solange nicht feststeht, welches Modell wie viele Personen mit welchen Dokumentlängen bedienen soll. Dieser Leitfaden legt die Hardware deshalb vom Anwendungsfall her aus. Stand: Oktober 2026.

Wovon hängt der Hardwarebedarf eines lokalen LLM ab?

Drei Größen bestimmen den Bedarf: die Modellgröße, die Zahl gleichzeitig arbeitender Nutzer und die Kontextlänge je Anfrage. Die ersten beiden Größen wirken auf den GPU-Speicher, die dritte auf Speicher und Rechenzeit. Alles Weitere, etwa Netzteil oder Gehäuse, folgt erst danach.

Praktisch heißt das: Notieren Sie vor jeder Beschaffung drei Zahlen.

• Modell: Welche Parameterzahl und welche Genauigkeit (BF16, FP8, 4 Bit) brauchen Sie für die Aufgabe?
• Gleichzeitige Nutzer: Nicht die Zahl der Mitarbeitenden, sondern die Zahl der Anfragen, die im selben Moment laufen. Bei einem Team von 50 Personen sind das oft nur wenige.
• Kontextlänge: Wie viel Text geht pro Anfrage hinein? Ein kurzer Chat braucht wenige tausend Token, eine Analyse mehrerer Verträge ein Vielfaches.

Aus diesen drei Angaben lässt sich der Speicherbedarf berechnen, bevor Sie eine Karte vergleichen. Das spart Fehlkäufe, weil der Speicher die harte Grenze ist: Was nicht hineinpasst, läuft nicht.

Wie viel GPU-Speicher brauchen die Modellgewichte?

Die Gewichte belegen etwa Parameterzahl mal Bytes pro Parameter. Ein Modell mit 72 Milliarden Parametern braucht in BF16 (2 Byte) rund 144 GB, in FP8 (1 Byte) rund 72 GB und mit 4-Bit-Gewichten grob 36 GB. Dazu kommen Reserven für Laufzeit und Cache.

Das ist eine Überschlagsrechnung, keine Herstellerangabe. Die tatsächliche Parameterzahl, das Dateiformat und der Aufwand der Inferenz-Software verschieben die Werte etwas. Für die Planung reicht sie, solange Sie Puffer einrechnen.

Die Inferenz-Software vLLM unterstützt laut Dokumentation zur Quantisierung unter anderem FP8, AWQ, GPTQ sowie INT4- und INT8-Verfahren. Quantisierung verkleinert den Speicherbedarf, geht aber auf Kosten der Genauigkeit. Wie stark sich das auf Ihre Aufgabe auswirkt, zeigt nur ein Test mit eigenen Fragen und Dokumenten.

Was ist der KV-Cache und warum wächst er mit Nutzern und Kontext?

Der KV-Cache speichert für jede laufende Anfrage Zwischenwerte aller bisherigen Token, damit das Modell nicht jedes Mal von vorn rechnen muss. Er wächst linear mit der Kontextlänge und gilt je Anfrage einzeln. Zehn parallele Anfragen brauchen zehnmal so viel Cache, die Gewichte teilen sich alle.

Die Größe lässt sich aus der Modellkonfiguration ableiten. Pro Token werden Schlüssel und Werte für jede Schicht gespeichert:

KV-Bytes je Token = 2 × Schichten × KV-Köpfe × Kopfgröße × Bytes je Wert

Die Konfiguration von Qwen2.5-72B-Instruct nennt 80 Schichten, 8 KV-Köpfe, 64 Attention-Köpfe und eine Hidden Size von 8192. Daraus folgt eine Kopfgröße von 128. Bei BF16-Werten ergibt das 2 × 80 × 8 × 128 × 2 = 327.680 Byte, also 320 KiB je Token. Das kleinere Qwen2.5-7B-Instruct hat 28 Schichten, 4 KV-Köpfe und 28 Attention-Köpfe bei einer Hidden Size von 3584, ebenfalls Kopfgröße 128. Das sind 56 KiB je Token.

Hochgerechnet auf realistische Kontexte ergibt sich für das 72-Milliarden-Modell:

Die Tabelle zeigt, warum lange Dokumente die Planung dominieren können: Bei 32.000 Token pro Anfrage übersteigen zehn parallele Nutzer allein mit dem Cache den Speicher einer einzelnen Karte. Die Werte gelten für einen Cache mit 2 Byte je Wert (BF16).

Wie rechne ich vom Anwendungsfall zur GPU-Größe?

Addieren Sie Gewichte, KV-Cache für die geplante Parallelität und eine Reserve für Laufzeit und Aktivierungen. Das Ergebnis ist der Mindestspeicher. Die Summe sollte unter dem nutzbaren Speicher der Karte oder des Kartenverbunds liegen, nicht knapp darauf.

Ein durchgerechnetes Beispiel: Ein Team will ein Modell mit 72 Milliarden Parametern in FP8 betreiben, mit bis zu 8 gleichzeitigen Anfragen à 8.000 Token.

1. Gewichte: rund 72 GB.
2. KV-Cache: 8 × 2,5 GiB, also rund 20 GiB.
3. Reserve: ein Puffer für Laufzeit, CUDA-Kontext und Aktivierungen, den Sie nach eigener Messung festlegen.

Bereits ohne Reserve liegt die Summe bei rund 92 GB. Damit ist klar: Eine Karte mit 48 GB scheidet aus, eine Karte mit 96 GB wäre knapp, und ein Verbund aus zwei Karten oder ein kleineres Modell bietet Luft. Dieselbe Rechnung mit einem 7-Milliarden-Modell in BF16 ergibt etwa 14 GB plus 8 × 8.000 × 56 KiB, also gut 3 GiB, und passt auf fast jede Profikarte.

Die vLLM-Dokumentation beschreibt, was bei zu knappem Cache passiert: Reicht der Platz nicht für alle Anfragen im Batch, kann das System Anfragen vorübergehend verdrängen und später neu berechnen, was die Antwortzeit verlängert. Als Gegenmittel nennt sie unter anderem, den für den Cache reservierten Speicheranteil zu erhöhen oder die Zahl paralleler Anfragen zu begrenzen.

Welche GPU-Klassen kommen in Frage?

Für den Betrieb im eigenen Haus kommen im Kern drei Klassen in Betracht: Profikarten mit 48 bis 96 GB, Rechenzentrumskarten mit HBM-Speicher und Verbünde mehrerer Karten. Entscheidend sind Speichergröße, Speicherbandbreite, Leistungsaufnahme und Formfaktor, nicht die Rechenleistung allein.

Die folgenden Herstellerangaben stammen von den Produktseiten (Abruf Oktober 2026):

Quellen: L40S, RTX PRO 6000, H100. Leere Felder bedeuten, dass die jeweilige Seite die Angabe nicht liefert. Prüfen Sie vor einer Beschaffung die aktuellen Datenblätter, Lieferbarkeit und die Kühl- und Stromanforderungen Ihres Serverraums.

Zwei Dinge fallen auf. Erstens liegt die Speicherbandbreite der H100-Varianten laut Herstellerseiten mit 3,35 bis 3,9 TB/s deutlich über den 864 GB/s der L40S. Zweitens decken Karten mit 80 bis 96 GB bereits Modelle in der 70-Milliarden-Klasse in FP8 knapp ab, mit wenig Platz für Cache.

Warum ist die Speicherbandbreite für die Geschwindigkeit entscheidend?

Beim Erzeugen jedes Tokens muss die GPU im Kern alle Gewichte einmal aus dem Speicher lesen. Die Geschwindigkeit einer einzelnen Anfrage ist deshalb nach oben begrenzt durch Speicherbandbreite geteilt durch Modellgröße in Byte. Die Rechenleistung ist in dieser Phase meist nicht der Engpass.

Eine Überschlagsrechnung mit den oben genannten Bandbreiten:

• 72 GB Gewichte (FP8) auf einer H100 SXM mit 3,35 TB/s: obere Grenze von etwa 46 Token pro Sekunde für eine einzelne Anfrage.
• 36 GB Gewichte (4 Bit) auf einer L40S mit 864 GB/s: obere Grenze von etwa 24 Token pro Sekunde.

Das sind theoretische Obergrenzen. In der Praxis liegen reale Werte darunter, weil auch der KV-Cache gelesen wird und Software-Overhead anfällt. Der Gegenpol ist das Batching: Werden mehrere Anfragen gemeinsam verarbeitet, teilen sie sich das Lesen der Gewichte. Der Gesamtdurchsatz steigt dann stark, während jede einzelne Anfrage etwas langsamer wird. Wie viele Nutzer ein Server tatsächlich schafft, ist ein eigenes Thema und hängt von Messungen mit Ihrer Last ab.

Wann braucht man mehrere GPUs?

Mehrere GPUs sind nötig, wenn das Modell samt Cache nicht auf eine Karte passt oder wenn eine Karte den Durchsatz nicht schafft. Die gängige Technik ist Tensor-Parallelität: Sie verteilt die Parameter jeder Schicht auf mehrere Karten.

Die vLLM-Dokumentation beschreibt es so: Tensor-Parallelität verteilt die Modellparameter innerhalb jeder Schicht auf mehrere GPUs. Das senkt den Speicherbedarf je Karte und schafft Platz für Cache, bringt aber Synchronisationsaufwand mit. Daraus folgen Planungsregeln:

• Zwei Karten mit je 48 GB sind nicht gleich eine Karte mit 96 GB. Die Verbindung zwischen den Karten (Bus, ggf. NVLink) beeinflusst die Geschwindigkeit.
• Die Zahl der Karten muss zur Modellarchitektur und zur Inferenz-Software passen; prüfen Sie die Anforderungen der gewählten Software vor der Beschaffung.
• Mehr Karten bedeuten mehr Strom, mehr Wärme und mehr Ausfallstellen.

Alternativ lassen sich mehrere unabhängige Instanzen betreiben, jede auf einer eigenen Karte. Das ist robuster, setzt aber voraus, dass das Modell auf eine Karte passt.

Was gehört außer der GPU zum Server?

Eine GPU allein macht keinen Server. Plausibel sind ausreichend Arbeitsspeicher für das Laden der Modelle, schnelle NVMe-Speicher für Modelldateien, passende PCIe-Anbindung, ein Netzteil mit Reserve und eine Kühlung für die Dauerlast.

Wichtige Punkte im Einzelnen:

• Arbeitsspeicher und Festplatte: Modelle liegen als große Dateien vor und werden beim Start geladen. Planen Sie Platz für mehrere Modellversionen ein.
• Strom und Kühlung: Die Leistungsangaben der Karten (siehe Tabelle) gelten pro Karte. Mehrere Karten in einem Gehäuse lassen sich nur mit passender Luftführung oder Wasserkühlung dauerhaft betreiben.
• Formfaktor: Die Server- und die Workstation-Ausführung einer Karte unterscheiden sich in Bauform und Leistungsaufnahme (siehe Tabelle); klären Sie Einbauplatz und Luftführung vorab.
• Netzwerk: Greifen mehrere Abteilungen auf den Server zu, ist die Netzwerkanbindung und die Absicherung des Zugriffs Teil der Planung.
• Betrieb: Monitoring von Auslastung, Speicher und Temperatur, Updates der Treiber und der Inferenz-Software sowie ein Plan für Ausfälle.

Für Datenschutzfragen gilt: Ein lokaler Betrieb vermeidet die Weitergabe an externe Dienste, ein Verfahren lässt sich damit grundsätzlich datenschutzkonform betreibbar gestalten. Das hängt aber von Zugriffsrechten, Protokollierung und Löschkonzept ab und ersetzt keine rechtliche Prüfung. Zum Zusammenhang von Hardware und digitaler Souveränität gibt die Seite Souveräne KI einen Überblick.

Wie gehe ich Schritt für Schritt vor?

Beginnen Sie mit dem Anwendungsfall, rechnen Sie den Speicher aus, testen Sie auf Mietware oder einer Leihkarte und beschaffen Sie erst danach. Diese Reihenfolge verhindert, dass Hardware gekauft wird, die zum späteren Modell nicht passt.

1. Anwendungsfall festhalten: Welche Aufgabe, welche Textlängen, wie viele gleichzeitige Anfragen zu Spitzenzeiten?
2. Modell wählen: Mit dem kleinsten Modell beginnen, das die Aufgabe in einem eigenen Test löst. Größere Modelle brauchen auch größere Hardware.
3. Speicherbedarf rechnen: Gewichte plus KV-Cache plus Reserve, wie oben gezeigt.
4. Genauigkeit entscheiden: BF16, FP8 oder 4 Bit gegen Qualität testen, nicht annehmen.
5. Kandidaten vergleichen: Speichergröße, Bandbreite, Leistungsaufnahme, Formfaktor und Lieferbarkeit anhand aktueller Datenblätter.
6. Last messen: Das gewählte Modell unter realistischer Last auf einer gemieteten oder geliehenen GPU testen und Antwortzeiten mit parallelen Anfragen erfassen.
7. Reserven festlegen: Wachstum bei Nutzerzahl und Kontextlänge einplanen; ein Server soll nicht schon beim Start am Limit laufen.
8. Betrieb planen: Monitoring, Updates, Backup der Modelldateien, Zuständigkeiten.

Welche Grenzen und Risiken gibt es?

Die Rechnungen in diesem Artikel sind Planungshilfen, keine Garantien. Echte Werte hängen von Modell, Software-Version, Treiber und Last ab. Hardware veraltet zudem schnell: Neue Modellarchitekturen und Quantisierungsverfahren verschieben die Anforderungen.

• Qualitätsverlust durch Quantisierung: Kleinere Gewichte sparen Speicher, können aber Genauigkeit kosten. Ohne eigenen Test ist das nicht abschätzbar.
• Wachsende Anforderungen: Längere Kontexte und mehr Nutzer nach dem Start sprengen eine knapp ausgelegte Karte.
• Lieferzeiten und Verfügbarkeit: Datenblätter nennen keine Lieferbarkeit; fragen Sie diese beim Händler an.
• Betriebsaufwand: Ein eigener GPU-Server verlangt Wartung und Know-how. Ob sich das gegenüber einem externen Dienst lohnt, ist eine Kostenfrage, die vom Einzelfall abhängt.
• Nicht jeder Anwendungsfall braucht ein großes Modell: Für viele klar umrissene Aufgaben genügt ein kleines Modell, das auf eine einzelne Karte passt.

Wie fange ich an?

Starten Sie klein: Formulieren Sie den Anwendungsfall in drei Zahlen, rechnen Sie den Speicher durch und testen Sie das Modell auf einer einzelnen GPU, bevor Sie in einen Verbund investieren. So lernen Sie, wie viel Last wirklich anfällt.

Hilfreich ist ein Pilot mit wenigen Nutzern und echten Dokumenten. Messen Sie dabei Speicherauslastung, Antwortzeit und die Zahl gleichzeitiger Anfragen. Mit diesen Werten wird die Ausbauplanung belastbar. Für den Einstieg in Agenten, die auf lokalen Modellen laufen, finden Sie auf der Seite KI-Agenten eine Übersicht der Einsatzfelder, und die Entscheidung zwischen eigenem Server und externer API ist in erster Linie eine Rechnung aus Last, Datenschutzanforderungen und Betriebsaufwand.