14.10.2025
René Herzer
Die zentrale Frage bei der KI-Hardware-Beschaffung lautet: "Welche Hardware soll ich kaufen?" Die Antwort hängt maßgeblich von einem oft übersehenen Faktor ab: dem VRAM-Bedarf der GPU. Dieser Leitfaden erklärt, warum VRAM der entscheidende Dimensionierungsfaktor ist und wie er korrekt berechnet wird.
Warum VRAM die Hardware-Entscheidung bestimmt
Bei traditioneller Server-Hardware stehen CPU, RAM und Storage im Fokus. Bei KI-Systemen ist die GPU mit ihrem VRAM der limitierende Faktor. Anders als bei anderen Anwendungen muss das komplette KI-Modell vollständig in den GPU-Speicher geladen werden.
Die Hardware-Hierarchie bei KI:
VRAM (kritisch): Bestimmt, welche Modelle überhaupt laufen
GPU-Performance: Beeinflusst Antwortgeschwindigkeit
CPU/RAM: Unterstützende Komponenten
Storage: Für Dokumente und Betriebssystem
Praktische Konsequenz: Eine €30.000 H100 mit 80GB VRAM kann ein 70B-Modell ausführen, während eine €3.000 RTX 4090 mit 24GB VRAM bei demselben Modell versagt - unabhängig von der sonstigen Hardware-Ausstattung.
Concurrent User: Realistische Nutzungsplanung
Ein häufiger Planungsfehler ist die Gleichsetzung von Gesamtnutzern mit gleichzeitigen Nutzern (Concurrent Users). Die tatsächliche Gleichzeitigkeit ist deutlich geringer.
Concurrent User Faustregeln
Büroumgebung (Standard-Arbeitszeiten):
• 10 Gesamtnutzer → 2-3 concurrent users
• 50 Gesamtnutzer → 8-12 concurrent users
• 100 Gesamtnutzer → 15-25 concurrent users
• 500 Gesamtnutzer → 50-100 concurrent users
Intensivnutzung (Forschung, Analyse-Teams):
• 10 Gesamtnutzer → 4-6 concurrent users
• 50 Gesamtnutzer → 15-25 concurrent users
• 100 Gesamtnutzer → 30-50 concurrent users
Call Center / Support (kontinuierliche Nutzung):
• 10 Gesamtnutzer → 6-8 concurrent users
• 50 Gesamtnutzer → 30-40 concurrent users
• 100 Gesamtnutzer → 60-80 concurrent users
Nutzungsmuster analysieren
Typische Nutzungsverteilung über den Tag:
• 09:00-11:00: Peak-Zeit (80% der Tagesnutzung)
• 11:00-14:00: Moderate Nutzung (40% der Tagesnutzung)
• 14:00-17:00: Zweiter Peak (60% der Tagesnutzung)
• Außerhalb: Minimale Nutzung (5-10%)
Größenanpassung für verschiedene Szenarien:
• Konservativ: Größe für 80% der Spitzenlastnutzung
• Ausgewogen: Größe für 60% der Spitzenlastnutzung mit Warteschlangen
• Kostenoptimiert: Größe für 40% der Spitzenlastnutzung mit längeren Wartezeiten
VRAM-Berechnung: Die entscheidenden Faktoren
Die theoretischen Grundlagen sind wichtig, aber für präzise Berechnungen wird die Verwendung eines VRAM-Rechners empfohlen. Dieser berücksichtigt alle relevanten Parameter und deren Wechselwirkungen.
VRAM-Kalkulator nutzen →
Mit diesem Tool können verschiedene Konfigurationen durchgespielt und der exakte VRAM-Bedarf ermittelt werden. Die folgenden Abschnitte erklären die einzelnen Parameter des Kalkulators:
1. Modellgröße und Quantisierung
Modell-Parameter bestimmen den Grundbedarf:
• 3B Parameter: ~6 GB (FP16) oder ~3 GB (INT8)
• 7B Parameter: ~14 GB (FP16) oder ~7 GB (INT8)
• 13B Parameter: ~26 GB (FP16) oder ~13 GB (INT8)
• 70B Parameter: ~140 GB (FP16) oder ~70 GB (INT8)
Quantisierung reduziert VRAM-Verbrauch:
• FP16: Volle Präzision, höchste Qualität, maximaler VRAM-Verbrauch
• INT8: Halbierter VRAM-Verbrauch, 2-5% Qualitätsverlust
• INT4: Viertel VRAM-Verbrauch, 5-10% Qualitätsverlust
Produktive Systeme nutzen typischerweise INT8-Quantisierung für optimales Verhältnis von Qualität und Ressourcenverbrauch.
2. Context Window (Sequence Length)
Das Context Window definiert die maximale Anzahl von Tokens (Wörtern/Zeichen), die das Modell gleichzeitig verarbeiten kann.
Typische Context-Größen und Anwendungsfälle:
• 2K Tokens: ~1 Seite Text, einfache Fragen
• 8K Tokens: ~4 Seiten Text, mittlere Dokumente
• 32K Tokens: ~15 Seiten Text, ausführliche Analysen
• 128K Tokens: ~60 Seiten Text, sehr umfangreiche Dokumente
VRAM-Impact: Der VRAM-Verbrauch steigt exponentiell mit der Context-Größe durch den KV-Cache.
Beispiel DeepSeek-R1 3B:
• 2K Context: 8,02 GB VRAM
• 8K Context: ~12 GB VRAM
• 32K Context: ~20+ GB VRAM
3. Batch Size (Gleichzeitige Verarbeitung)
Die Batch Size entspricht der Anzahl concurrent users und bestimmt, wie viele Anfragen parallel verarbeitet werden können.
Batch Size-Auswirkungen:
• Batch Size = 1: Ein Nutzer, minimale Latenz
• Batch Size = 8: Acht parallele Anfragen, moderate Latenz
• Batch Size = 32: Maximaler Durchsatz, höhere Latenz pro Anfrage
VRAM-Verbrauch steigt linear: Jede zusätzliche parallele Anfrage erhöht den VRAM-Bedarf für Aktivierungen.
Praktisches Beispiel (13B-Modell, 8K-Context):
• 1 concurrent user: 15 GB VRAM
• 4 concurrent users: 18 GB VRAM
• 8 concurrent users: 22 GB VRAM
• 16 concurrent users: 30 GB VRAM4.
KV-Cache-Quantisierung
Der KV-Cache speichert bereits verarbeitete Tokens zur Performance-Optimierun.
KV-Cache-Optionen:
• FP16: Standard-Präzision, höchster VRAM-Verbrauch
• INT8: 50% VRAM-Reduktion, minimaler Qualitätsverlust
• INT4: 75% VRAM-Reduktion, merklicher Qualitätsverlust
Praktische Berechnungsbeispiele
Beispiel 1: Kleine Organisation (25 Gesamtbenutzer)
Nutzungsanalyse:
• 25 Gesamtbenutzer (Büroumgebung)
• 5--8 concurrent users (Peak-Zeit)
• Dokumente bis 5 Seiten (8K Context)
• Standard-Qualitätsanforderungen
VRAM-Konfiguration:
• Modell: 13B Parameter (INT8)
• Context: 8K Tokens
• Batch Size: 8 (für Peak-Nutzung)
• VRAM-Bedarf: ~22 GB
• GPU-Empfehlung: NVIDIA L4 (24 GB)
Beispiel 2: Mittlere Organisation (100 Gesamtbenutzer)
Nutzungsanalyse:
• 100 Gesamtbenutzer (gemischte Nutzung)
• 20-25 concurrent users (Peak-Zeit)
• Dokumente bis 15 Seiten (32K Kontext)
• Hohe Qualitätsanforderungen
VRAM-Konfiguration:
• Modell: 70B Parameter (INT8)
• Context: 32K Tokens
• Batch Size: 24 (für Peak-Nutzung)
• VRAM-Anforderung: ~45 GB
• GPU-Empfehlung: NVIDIA L40S (48 GB)
Beispiel 3: Große Organisation (500 Gesamtbenutzer)
Nutzungsanalyse:
• 500 Gesamtbenutzer (intensivnutzung)
• 80-100 concurrent users (Peak-Zeit)
• Sehr umfangreiche Dokumente (128K Kontext)
• Höchste Qualitätsanforderungen
VRAM-Konfiguration:
• Modell: 70B Parameter (FP16)
• Kontext: 128K Tokens
• Batch Size: 32 pro GPU
• VRAM-Anforderung: ~75 GB pro GPU
• GPU-Empfehlung: 3× NVIDIA H100 (80 GB) im Cluster
Architektur-Flexibilität bei der Dimensionierung
Moderne KI-Plattformen ermöglichen flexible Verteilung der Komponenten:
Monolithische Architektur:
• LLM, RAG und Management auf einem Server
• Geringste Hardware-Anforderungen
• Limitierte Skalierbarkeit
Verteilte Architektur:
• LLM-Server: Dediziert für Textgenerierung
• RAG-Server: Speziell für Dokumentenverarbeitung
• Management-Server: Web-Interface und Orchestrierung
Hybride-Ansätze:
• RAG und Management auf einem Server
• LLM auf dediziertem Server
• Optimaler Kosten-Nutzen-Verhältnis
Die Architektur-Entscheidung beeinflusst die VRAM-Berechnung erheblich, da bei verteilten Systemen die Ressourcen spezifischer dimensioniert werden können.
Häufige Berechnungsfehler
Concurrent Users unterschätzen:
• Problem: Nur durchschnittliche Nutzung berücksichtigt
• Lösung: Peak-Zeiten analysieren und entsprechend dimensionieren
Context Window überschätzen:
• Problem: 128K Context geplant, nur 8K tatsächlich genutzt
• Lösung: Realistische Dokumentenlängen analysieren
Quantisierung nicht berücksichtigen:
• Problem: FP16-Kalkulation ohne Prüfung von INT8-Alternativen
• Lösung: Qualitätsanforderungen realistisch bewerten
Fehlender Sicherheitspuffer:
• Problem: Exakte Kalkulation ohne Reserven
• Lösung: 15-25% Puffer für unvorhergesehene Anforderungen
VRAM-Optimierungsstrategien
Quantisierungsoptimierung:
• Modell-Weights: INT8 für Produktivumgebungen
• KV-Cache: INT8 für VRAM-Effizienz
• Activations: FP16 für numerische Stabilität
Context-Management:
• Sliding Window: Automatisches Entfernen alter Tokens
• Document Chunking: Aufteilung langer Dokumente
• Intelligent Caching: Vorberechnung häufiger Anfragen
Batch-Optimierung:
• Dynamic Batching: Anpassung der Batch Size je nach Last
• Sequence Packing: Zusammenfassung kurzer Anfragen
Validierung der Berechnung
Cloud-Testing vor Hardware-Beschaffung:
• Stundenweise Miete von GPU-Instanzen (€2-4/Stunde)
• Test mit realistischen Daten und Nutzungsmustern
• Messung von VRAM-Verbrauch und Performance-Metriken
• Validierung verschiedener Konfigurationen
Monitoring-Metriken:
• VRAM-Auslastung unter verschiedenen Lasten
• Antwortzeiten bei unterschiedlichen Batch Sizes
• Durchsatz bei verschiedenen Context-Größen
• Qualitätsbewertung bei verschiedenen Quantisierungsgradenn
Checkliste für Hardware-Dimensionierung
Nutzungsanalyse:
• Gesamtanzahl der Nutzer ermittelt
• Concurrent Users basierend auf Nutzungstyp berechnet
• Peak-Zeiten und Nutzungsmuster analysiert
• Wachstumsprojektionen für 12-24 Monate erstellt
Anforderungsanalyse:
• Typische und maximale Dokumentenlängen ermittelt
• Qualitätsanforderungen spezifiziert
• Performance-Anforderungen (Latenz vs. Durchsatz) geklärt
• Verfügbarkeitsanforderungen definiert
VRAM-Berechnung:
• Modellgröße basierend auf Qualitätsanforderungen gewählt
• Quantisierung für Produktivumgebung berücksichtigt (INT8)
• Context Window basierend auf realen Dokumenten dimensioniert
• Batch Size für Peak-Concurrent-Users kalkuliert
• Sicherheitspuffer von 15-25% eingeplantt
Validierung:
• Cloud-Test mit berechneter Konfiguration durchgeführt
• Performance unter realistischer Last gemessen
• VRAM-Verbrauch unter verschiedenen Szenarien dokumentiert
• Alternative Konfigurationen evaluiert
Dokumentation:
• VRAM-Anforderungen für Hardware-Spezifikation dokumentiert
• Architektur-Entscheidungen (monolithisch vs. verteilt) getroffen
• Skalierungsoptionen für zukünftige Erweiterungen geplant
• Begründung der Dimensionierung für Stakeholder vorbereitet
Fazit
Die Hardware-Dimensionierung für On-Premise KI beginnt mit der korrekten VRAM-Berechnung. Durch systematische Analyse der Nutzungsmuster, realistische Modellierung der Concurrent Users und gründliche Validierung durch Cloud-Tests lassen sich kostspielige Fehlentscheidungen vermeiden.
Die Investition von einigen hundert Euro in Cloud-Tests kann Fehlkäufe im fünfstelligen Bereich verhindern und stellt sicher, dass die beschaffte Hardware den tatsächlichen Anforderungen entspricht.
Bleiben Sie auf dem Laufendem