Kapazitätsplanung für lokale LLMs: Was IT-Leiter wissen müssen

Wer zum ersten Mal einen LLM-Server plant, greift oft zu den gewohnten Metriken: CPU-Kerne, Festplattenkapazität, Netzwerkdurchsatz. Das sind nicht die falschen Fragen, aber sie sind auch nicht die entscheidenden. Wer einen lokalen Large Language Model-Betrieb aufbauen will, denkt primär in VRAM, Speicherbandbreite und Kontextlänge. Dieser Artikel erklärt, warum, und zeigt anhand konkreter Zahlen, wie Sie Ihren Bedarf realistisch einschätzen.

Warum LLM-Sizing anders funktioniert

Klassisches Server-Sizing folgt einer vertrauten Logik: mehr Anfragen brauchen mehr CPU-Kerne, mehr Daten brauchen mehr Speicher, mehr parallele Verbindungen brauchen mehr RAM. LLM-Inferenz bricht diese Logik an einem entscheidenden Punkt auf.

Das Modell selbst, also die Millionen oder Milliarden von Gewichten, muss vollständig in den GPU-Speicher (VRAM) geladen werden, bevor die erste Anfrage beantwortet werden kann. Ist das Modell zu groß für den verfügbaren VRAM, läuft es nicht. Nicht langsam, sondern gar nicht. Das ist der erste Unterschied zu klassischer Server-Infrastruktur.

Der zweite Unterschied betrifft die Speicherbandbreite. Bei der Textgenerierung liest die GPU bei jedem generierten Token einmal alle Modellgewichte durch. Ein 70B-Modell in Q4-Quantisierung hat 40 GB Gewichte. Je mehr Bandbreite die GPU zur Verfügung stellt, desto schneller passiert dieser Lesezyklus, und desto mehr Tokens pro Sekunde werden generiert.

Der dritte Unterschied ist der KV-Cache. Während einer Konversation speichert das Modell Zwischenergebnisse (Key-Value-Pairs) für jeden verarbeiteten Token im VRAM. Ein längeres Gespräch, ein größerer Kontext, mehr parallele Nutzer: der KV-Cache wächst dynamisch und kann schnell mehrere Gigabyte pro aktivem Nutzer belegen.

Die drei zentralen Planungsgrößen

Bevor Sie Hardware auswählen, brauchen Sie drei Inputs.

Erstens, die Anzahl gleichzeitiger Nutzer. Gemeint sind nicht Gesamtnutzer pro Tag, sondern Spitzenlasten: wie viele Personen erwarten Sie, die im selben Zeitfenster eine Antwort generieren lassen? Für interne Unternehmensanwendungen liegt diese Zahl oft zwischen 5 und 50.

Zweitens, die Ziellatenz. Soll die Ausgabe flüssig im Chat erscheinen, brauchen Sie 20 bis 40 Tokens pro Sekunde. Für automatisierte Batch-Verarbeitung ohne Echtzeit-Feedback genügen auch 10 tok/s.

Drittens, die Modellgröße. Die entscheidet maßgeblich über den VRAM-Bedarf, bestimmt aber auch die Qualität der Ausgabe. Kleinere Modelle sind schneller und günstiger, können aber bei komplexen Aufgaben an Grenzen stoßen.

VRAM-Berechnung: Das entscheidende Fundament

Die Grundformel für den VRAM-Bedarf setzt sich aus drei Teilen zusammen: Modellgewichte plus KV-Cache pro Nutzer plus Overhead für Framework und Aktivierungen.

Modellgewichte hängen von Parameteranzahl und Quantisierungsstufe ab. Als Faustregel gilt:

Bei FP16 (volle Präzision, 2 Byte pro Parameter) kostet ein 7B-Modell rund 14 GB, ein 70B-Modell rund 140 GB.

Bei Q8 (8-Bit-Quantisierung, 1 Byte pro Parameter) halbieren sich diese Werte: 7 GB bzw. 70 GB.

Bei Q4 (4-Bit-Quantisierung, 0,5 Byte pro Parameter) halbieren sie sich nochmals: rund 3,5 GB für 7B, rund 35 bis 40 GB für 70B.

In der Praxis sieht das so aus:

Llama 3.1 8B in Q4: ca. 5 GB VRAM für die Gewichte. Eine einzelne GPU mit 24 GB VRAM reicht hier für Entwicklung und leichten Produktionseinsatz.

Llama 3.3 70B in Q4: ca. 40 GB VRAM. Damit ist dieses Modell auf einer einzelnen GPU mit 48 GB VRAM betreibbar, braucht aber kaum Puffer für Cache und Overhead. Zwei GPUs sind für produktiven Einsatz empfehlenswert.

Llama 3.1 405B in Q4: ca. 230 GB VRAM. Hier kommen Sie ohne Multi-GPU-Setup nicht aus.

KV-Cache kommt obendrauf. Für ein 70B-Modell mit 4K Kontextlänge belegt eine einzige aktive Sitzung typischerweise 1 bis 4 GB zusätzlichen VRAM. Bei 20 parallelen Nutzern sind das 20 bis 80 GB, die reserviert sein müssen.

Framework-Overhead (vLLM, Ollama, TGI) belegt zusätzlich 2 bis 8 GB VRAM für Aktivierungen, Scheduler und interne Puffer.

Quantisierung: Qualität gegen Speicher abwägen

Quantisierung ist kein Kompromiss, den man verstecken sollte. Es ist eine bewusste Engineeringentscheidung mit gut verstandenen Trade-offs.

FP16 bietet maximale Präzision und eignet sich für Finetuning oder Evaluierungen, bei denen numerische Genauigkeit zählt. Der Speicherbedarf ist doppelt so hoch wie Q8.

Q8 ist eine gute Wahl, wenn qualitative Ausgaben geprüft werden sollen oder wenn das Modell in der Nähe einer Entscheidungsgrenze arbeitet. Der Qualitätsverlust gegenüber FP16 ist gering.

Q4 in der Variante Q4_K_M (eine Mischung aus 4-Bit- und 6-Bit-Quantisierung für kritische Schichten) ist für die meisten Unternehmensanwendungen die pragmatische Wahl. Zusammenfassungen erstellen, E-Mails verfassen, Dokumente analysieren, Daten strukturieren: Q4_K_M liefert dabei Ergebnisse, die sich von FP16 kaum unterscheiden. Der VRAM-Bedarf liegt bei etwa einem Viertel von FP16.

Für mathematisch intensive Aufgaben oder Codegenerierung mit sehr strengen Korrektheitskriterien kann Q8 gerechtfertigt sein. Für alles andere: Q4_K_M.

Tokens pro Sekunde: Die operative Kennzahl

Kapazitätsplanung endet nicht beim Speicher. VRAM bestimmt, ob ein Modell läuft. Tokens pro Sekunde bestimmen, ob es brauchbar ist.

Für interaktive Anwendungen (Chat-Interfaces, Assistenten, Suchergänzung) gelten 20 bis 40 tok/s als komfortabel. Unter 15 tok/s beginnt die Ausgabe zögerlich zu wirken, was bei internen Nutzern schnell zu Akzeptanzproblemen führt.

Für Batch-Verarbeitung ohne Echtzeit-Feedback (nächtliche Dokumentenanalysen, Datentransformation, Klassifizierung) reichen 10 tok/s.

Die Tokens-pro-Sekunde-Rate hängt direkt von der GPU-Speicherbandbreite ab. Eine RTX PRO 6000 Blackwell mit 1.792 GB/s Speicherbandbreite generiert bei einem 70B-Q4-Modell deutlich schneller Text als ältere Karten, weil die neuere GPU auch effizienter mit den Gewichten umgeht.

Gleichzeitige Nutzer und intelligentes Batching

Naiv betrachtet könnte man denken: ein Modell, eine Anfrage gleichzeitig. Das stimmt nicht. Moderne Inferenz-Frameworks wie vLLM nutzen Continuous Batching, um mehrere Anfragen zu bündeln.

Dabei werden Anfragen, die sich in verschiedenen Generierungsphasen befinden, zusammengelegt. Während Nutzer A auf Token 150 wartet, beginnt Nutzer B seine Anfrage. Das Framework fügt diese Anfragen zusammen und verarbeitet sie in einem GPU-Durchlauf.

In der Praxis bedeutet das: 4 GPUs der Klasse RTX PRO 6000 mit insgesamt 384 GB VRAM können bei einem 70B-Modell realistisch 20 bis 50 gleichzeitige Nutzer bedienen, abhängig davon, wie lange die typischen Konversationen sind und wie stark die Anfragen zeitlich gestaffelt eintreffen.

Bei stark gleichzeitigen Lasten (alle 50 Nutzer senden exakt zur selben Zeit) sind die Grenzen enger. Das ist aber in der Praxis selten. Unternehmensanwendungen zeigen in der Regel gut verteilte Anfragemuster.

Host-RAM: Unterschätzte Ressource

VRAM ist das Nadelöhr, aber Host-RAM spielt eine unterstützende Rolle, die nicht ignoriert werden sollte.

Betriebssystem und Framework brauchen ihre eigenen Reserven. vLLM allein benötigt mehrere Gigabyte RAM. Hinzu kommen Preprocessing (Tokenisierung, Anfragewarteschlangen) und Systemdienste.

Bei sehr großen Kontextfenstern oder extrem vielen parallelen Anfragen kann der KV-Cache den VRAM überfluten und in den Host-RAM ausgelagert werden. Das verlangsamt die Inferenz drastisch, verhindert aber einen Absturz.

192 GB DDR5 ECC sind für die meisten produktiven Setups mit 70B-Modellen eine solide Basis. Mit weniger als 64 GB riskiert man, dass Framework und Betriebssystem um dieselben Ressourcen konkurrieren.

Storage: Ladezeiten im Produktionsbetrieb

Ein Modell muss nicht nur Platz haben, es muss auch schnell geladen werden. Das betrifft vor allem zwei Szenarien: der initiale Start nach einem System-Neustart und das Wechseln zwischen mehreren Modellen.

Ein Llama 3.3 70B in Q4 ist rund 40 GB groß. Bei einem einzelnen NVMe mit 7 GB/s sequentiellem Durchsatz dauert das Laden etwa 6 Sekunden. Bei einem NVMe-RAID mit 59,3 GB/s Lesedurchsatz sind es unter einer Sekunde. Wenn Modelländerungen im laufenden Betrieb passieren oder Dienste häufig neu gestartet werden, ist dieser Unterschied betrieblich relevant.

Für 405B-Modelle (ca. 230 GB) macht der Unterschied zwischen 7 GB/s und 59,3 GB/s einen Unterschied von über 30 Sekunden gegenüber unter 4 Sekunden.

4 TB NVMe-Kapazität erlaubt, mehrere Modelle gleichzeitig vorzuhalten, ohne zwischen Disk-Pools zu wechseln.

Skalierungsstrategie: Messen vor Kaufen

Die häufigste Fehlerquelle bei LLM-Sizing ist, ohne Baseline zu kaufen. Weder Überkaufen (teure GPU-Cluster für 5 interne Nutzer) noch Unterkaufen (zu wenig VRAM für das Modell, das der Use Case erfordert) ist vertretbar.

Der empfohlene Ansatz ist schrittweise: Definieren Sie zunächst das Modell, das Ihre Anforderungen erfüllt. Schätzen Sie dann die Spitzenlast an gleichzeitigen Nutzern. Berechnen Sie VRAM-Bedarf (Gewichte plus KV-Cache-Reserve plus Overhead). Starten Sie mit einer Konfiguration, die diese Last mit 30 Prozent Puffer abdeckt. Messen Sie nach 4 bis 8 Wochen Betrieb Auslastung, Latenz und Fehlerrate. Skalieren Sie dann auf Basis realer Daten.

Für die meisten mittelständischen Unternehmen mit internen Anwendungen liegt der sinnvolle Einstieg bei Modellen zwischen 8B und 70B Parametern. Ein 8B-Modell reicht für einfache Assistenzaufgaben und strukturierte Datenverarbeitung. 70B-Modelle adressieren anspruchsvollere Analysen, komplexe Instruktionen und mehrsprachige Anwendungen.

Empfehlung von Badische Rechenwerke

Der BRW-B01 wurde als produktionsreifer LLM-Server konzipiert, der die häufigsten Sizing-Engpässe von vornherein vermeidet.

Die Hardware im Überblick: 4 RTX PRO 6000 Blackwell mit je 96 GB VRAM (zusammen 384 GB), AMD EPYC Genoa mit 32 physischen Kernen, 192 GB DDR5 ECC, 4 TB NVMe in RAID-Konfiguration mit 59,3 GB/s sequentiellem Lesedurchsatz.

Was das in der Praxis bedeutet: Ein Llama 3.3 70B in Q4 belegt 40 GB der 384 GB VRAM und lässt 344 GB für KV-Cache und Overhead. Das genügt für 50 oder mehr gleichzeitige Nutzer mit komfortabler Reserve. Alternativ lassen sich zwei Modelle gleichzeitig betreiben, etwa ein 70B-Modell für komplexe Anfragen und ein 8B-Modell für einfache Aufgaben.

Ein Llama 3.1 405B in Q4 (ca. 230 GB) läuft auf diesem System mit rund 150 GB Puffer für KV-Cache. Damit ist selbst das derzeit größte öffentlich verfügbare Open-Source-Modell produktiv betreibbar.

Das Gesamtsystem ist ab 75.000 € zzgl. MwSt. erhältlich. Wir helfen Ihnen, Ihren konkreten Bedarf zu kalkulieren: Anforderungen, Nutzerzahl und Modellpräferenz reichen als Ausgangspunkt.

Kontakt aufnehmen