Private LLMs · Eigene Infrastruktur, Deutschland, Air-Gap
Private LLMs im Unternehmen bereitstellen
Ihr Sprachmodell läuft dort, wo Ihre Daten bleiben dürfen: im eigenen Rechenzentrum, als LLM-Hosting in einer von Ihnen gewählten Umgebung in Deutschland oder ganz ohne Internetverbindung. SKAFFON baut die Plattform und übergibt oder betreibt sie.
- Modellwahl, Sizing, Plattform, Betrieb
- OpenAI-kompatible Schnittstelle (vLLM)
- Keine offene GPU-Cloud
01Ausgangslage
Die Datengrenze entscheidet, nicht die Mode
Der Anlass für ein privates LLM ist fast immer eine Datengrenze: Vertragsdokumente, Quellcode, Personal- oder Patientendaten, Konstruktionsunterlagen. Wo diese Daten nicht an einen externen Modellanbieter gesendet werden dürfen oder sollen, bleibt das Modell im eigenen Betrieb.
Dazu kommen planbare Kosten bei hoher, gleichmäßiger Nutzung, Unabhängigkeit von Preis- und Modellwechseln und der Wunsch, Zugriffe selbst zu protokollieren. Für IT-Leitung und CTOs zeigt diese Seite, wie Modellwahl, Hardware, Schnittstelle und Betrieb zusammenhängen.
02
Eigene Plattform oder reiner API-Schlüssel?
SKAFFON vermietet keine offene GPU-Cloud. Wir bauen eine Plattform für Ihre Anforderungen und übergeben oder betreiben sie.
Dann lohnt sich das Gespräch
- Ihre Daten dürfen nicht oder sollen nicht an einen Cloud-Modellanbieter gehen.
- Sie erwarten hohe, gleichmäßige Nutzung und wollen die Kosten planen.
- Sie wollen Zugriffe selbst protokollieren und Modellwechsel selbst steuern.
Dann brauchen Sie uns nicht
- Ihre Daten dürfen ohnehin an einen Cloud-Modellanbieter gehen und Sie brauchen nur einen API-Schlüssel.
- Sie suchen offene GPU-Miete oder einen reinen Modell-API-Dienst.
- Ihr Nutzungsvolumen ist so gering, dass eine eigene GPU-Plattform nicht wirtschaftlich zu betreiben ist.
03
Mit diesen Angaben beginnt die Auslegung
Aus diesen Eingaben und Randbedingungen entstehen Modellkandidaten und Hardwareumfang.
- Aufgabe: Chat, Zusammenfassung, Klassifikation, Extraktion, Codeassistenz, Retrieval-gestützte Antworten (RAG)
- Erwartete Nutzerzahl und Gleichzeitigkeit, Längen von Prompt und Antwort
- Datenklassen, Standortvorgaben, Anforderungen an Protokollierung und Löschung
- Vorhandene Identity-Lösung und Kubernetes-Plattform
- Lizenzanforderungen an Modelle (Nutzungsbedingungen prüfen wir pro Modell mit Ihnen)
04Sizing
Von 70 Milliarden Parametern zur GPU-Zahl
Die Dimensionierung folgt einer festen Rechenkette. Das Beispiel nutzt angenommene Werte: Es ist ein Rechenbeispiel, kein Benchmark und keine Messung von SKAFFON. Durchsatz und Latenz müssen auf Ihrer Hardware gemessen werden.
- 01
Gewichte
Schritt 1Speicherbedarf = Parameterzahl × Bytes pro Parameter. In 16 Bit (FP16/BF16) sind das 2 Byte, in 8 Bit 1 Byte, in 4 Bit etwa 0,5 Byte plus Zusatzdaten für Skalierungsfaktoren. 70 Milliarden Parameter brauchen in 16 Bit 70 × 10⁹ × 2 Byte = 140 GB, in 8 Bit 70 GB; ein Modell mit 8 Milliarden Parametern braucht in 16 Bit 16 GB. Ob eine niedrigere Präzision für Ihre Aufgabe qualitativ genügt, ist zu testen.
- 02
KV-Cache
Schritt 2Beim Generieren speichert die Engine pro Token Schlüssel und Werte aller Schichten: 2 (K und V) × Schichten × KV-Heads × Head-Dimension × Bytes pro Wert. Angenommen: 80 Schichten, 8 KV-Heads, Head-Dimension 128, KV-Cache in 16 Bit. Das ergibt 2 × 80 × 8 × 128 × 2 Byte = 327.680 Byte, etwa 320 KiB pro Token. Diese Werte stehen in der Konfigurationsdatei (
config.json) des jeweiligen Modells. Bei 32 gleichzeitigen Sequenzen mit je 8.192 Token sind das 262.144 Token × 327.680 Byte, rund 86 GB. - 03
Summe und Reserve
Schritt 3Gewichte plus KV-Cache plus Arbeitsspeicher für Aktivierungen und Laufzeit. Die Engine reserviert nur einen Teil des GPU-Speichers: In vLLM begrenzt
--gpu-memory-utilizationlaut Dokumentation den Anteil des GPU-Speichers für den Modell-Executor. Bei 90 Prozent von 80 GB stehen 72 GB je GPU zur Verfügung. - 04
GPU-Anzahl
Schritt 4Variante A (16 Bit): 140 GB + 86 GB = 226 GB, geteilt durch 72 GB ergibt rechnerisch 3,1, also mehr als drei GPUs. Da vLLM verlangt, dass die Zahl der Attention-Heads durch die Tensor-Parallel-Größe teilbar ist, werden in der Praxis 4 GPUs gewählt. Variante B (Gewichte in 8 Bit, gleiche 86 GB KV-Cache): 70 + 86 = 156 GB, mehr als zwei GPUs. Halbiert man die Gleichzeitigkeit auf 16 Sequenzen, braucht der KV-Cache 43 GB, die Summe sinkt auf 113 GB, und zwei GPUs reichen rechnerisch.
05
Fünf Stellhebel und was sie kosten
Gleichzeitigkeit, Kontextlänge und Präzision sind die drei Hebel mit der größten Wirkung; sie werden mit Ihnen vor der Hardwareentscheidung festgelegt.
| Stellhebel | Wirkt auf | Gegenseite |
|---|---|---|
| Niedrigere Gewichtspräzision | VRAM für Gewichte | mögliche Qualitätseinbußen, zu testen |
| Kleineres Modell | VRAM, Kosten, Latenz | Leistungsfähigkeit je Aufgabe |
| Kürzere Maximalkontexte | KV-Cache | Anwendungsfälle mit langen Dokumenten |
| Weniger Gleichzeitigkeit | KV-Cache | Wartezeiten bei Spitzenlast |
| Mehr GPUs (Parallelität) | verfügbarer Speicher | Kommunikationsaufwand, Kosten |
06
Wenn ein Server genügt, entfällt die Netzwerkfrage
Laut vLLM-Dokumentation genügt eine GPU, wenn das Modell darauf passt; passt es auf einen Server mit mehreren GPUs, wird Tensor-Parallelität verwendet; ist das Modell für einen Server zu groß, kombiniert man Tensor- und Pipeline-Parallelität über mehrere Knoten.
Tensor-Parallelität erzeugt viel GPU-zu-GPU-Verkehr, deshalb zählen NVLink im Server und für Multi-Node-Betrieb ein schnelles Netzwerk. Für GPUs ohne NVLink, wie die L40S, nennt die Dokumentation Pipeline-Parallelität als Option mit geringerem Kommunikationsaufwand. Wer ein Modell auf einen Server begrenzen kann, vermeidet die Netzwerkfrage ganz.
Anfragen pro Sekunde rechnen wir nicht, wir messen sie
Wie viele Anfragen laufen und wie schnell die Antworten kommen, hängt von Engine-Konfiguration, Batching, Hardware und Last ab. Die Rechenkette beantwortet das nicht; der PoC misst es mit Ihrem Lastprofil.
07Architektur
So sitzt das Modell innerhalb Ihrer Datengrenze
08
vLLM, KServe oder NIM: der Serving-Stack
Als Inference-Engine setzen wir vLLM ein, das über OpenAI-kompatible Schnittstellen angesprochen werden kann, sodass vorhandene Clients wenig Anpassung brauchen. Unter Kubernetes bildet KServe Modelle als Ressourcen ab; die Dokumentation beschreibt vLLM als Backend und OpenAI-kompatible Routen für Chat Completions und Embeddings.
Für große Sprachmodelle gibt es neben dem InferenceService die Ressource LLMInferenceService, die auf llm-d aufbaut; welche passt, stimmen wir mit der zum Projektzeitpunkt aktuellen Version ab.
Alternativ kommt NVIDIA NIM in Frage, das Modelle als vorbereitete Container bereitstellt, mit dokumentierter Air-Gap-Bereitstellung. Für den produktiven Einsatz verlangt NVIDIA laut Produktdokumentation eine NVIDIA-AI-Enterprise-Lizenz; diese Lizenzkosten gehören in die Entscheidung zwischen NIM und vLLM.
09
Davor, daneben, dahinter: die übrigen Bausteine
Vor der Engine liegen Zugriffsschicht mit Authentifizierung, Ratenbegrenzung und Audit-Log, dahinter die Datenhaltung, daneben die GPU-Telemetrie.
Engine
- vLLM
- NVIDIA NIM
Kubernetes-Serving
- KServe
- LLMInferenceService
- llm-d
Zugriff
- Keycloak oder Ihre Identity-Lösung
- Ratenbegrenzung
- Audit-Log
Datenhaltung
- PostgreSQL
Telemetrie
- DCGM-Exporter
- Prometheus
PostgreSQL hält Nutzungsprotokolle und bei RAG Vektordaten. Identity über Keycloak oder Ihre vorhandene Lösung.
10
Eigenes Haus, deutsche Region oder Air-Gap
Auswahl und Vertragsform klären wir im Projekt.
-
Eigene Infrastruktur
Daten und Modell verlassen Ihr Netz nicht.
-
Umgebung in Deutschland
Betrieb auf Infrastruktur, die Sie wählen und vertraglich absichern: Ihr eigenes Rechenzentrum, Colocation in Deutschland oder eine deutsche Cloud-Region wie STACKIT eu01 (STACKIT-Regionen).
-
Air-Gap
Keine Verbindung zum Internet. Gewichte, Images und Updates kommen über kontrollierte Übergabewege (geprüfte Medien oder eine Schleuse) und werden vor dem Einsatz geprüft. Zugangsdaten für Modell-Repositories gehören nicht in die Laufzeitumgebung; Gewichte werden vorab beschafft und lokal abgelegt.
11
Prompt Injection und RAG-Rechte sind ein anderes Thema
Die Datengrenze endet an der Plattform. Die Absicherung der Anwendung darüber (Prompt Injection, Datenabfluss über Ausgaben, Rechtekonzept bei RAG) ist ein eigenes Thema im Bereich Cybersecurity.
12
Fünf Arbeitspakete vom Modelltest bis zum Alarm
-
Modellwahl
Kandidaten für Ihre Aufgabe, Lizenzprüfung, Vergleichstest auf Ihren Beispieldaten.
-
Sizing
Rechenkette wie oben mit Ihren Parametern.
-
Plattform
Kubernetes mit GPU Operator, Serving-Stack, API-Zugang, Identity. Mehr in der Kubernetes-Beratung.
-
Monitoring
GPU-, Serving- und Nutzungsmetriken, Alarme.
-
Betrieb
Update-Prozess für Modelle und Engine, Runbooks, Übergabe an Ihr Team oder Betrieb durch SKAFFON.
13
Fünf Stationen bis zum produktiven Modell
Bestimmend für den Aufwand sind Zahl der Modelle, Gleichzeitigkeit und Kontextlängen, Standort und Air-Gap-Anforderung, Integration (Identity, Dokumentquellen, Anwendungen) und Betriebsumfang. Preisangaben machen wir ohne diese Eingaben nicht.
- 01
Workshop und Anforderungen
Aufgabe, Datenklassen, Standort und Lastprofil festlegen.
- 02
Modellvergleich und Sizing
Kandidaten testen und die Rechenkette mit Ihren Werten durchlaufen.
- 03
PoC mit Lastmessung
Durchsatz und Latenz auf der Zielhardware mit Ihrem Lastprofil messen.
- 04
Produktivsetzung
Monitoring und Zugriffskonzept einrichten.
- 05
Betrieb oder Übergabe
Die Plattform übernimmt Ihr Team oder SKAFFON betreibt sie.
14
Wenn die Frage größer oder kleiner ist als ein Modell
-
Technische KI-Beratung
Wenn Architektur und Make-or-Buy noch offen sind, beginnt der Weg hier.
-
GPU-Cluster
Die Hardwareschicht: GPUs, NVLink und Netzwerk.
-
GPU- und KI-Infrastruktur
Der Überblick über den gesamten Bereich.
Welche Daten dürfen Ihr Haus nicht verlassen?
Schicken Sie uns Aufgabe, Datenklassen und gewünschten Standort.