Private KI-Infrastruktur: Modelle auf Ihren eigenen Daten betreiben

Die meisten Unternehmen, die mit generativer KI experimentieren, beginnen mit einer öffentlichen API. Schwierig wird es, wenn die nützliche Arbeit echte Daten betrifft: Verträge, Support-Tickets, Quellcode, Patientenakten, Finanzberichte. Ab diesem Punkt lauten die Fragen nicht mehr „kann das Modell das“, sondern „wohin gehen diese Daten, wer kann sie sehen, und können wir das später nachweisen“.

Eine private KI-Umgebung beantwortet diese Fragen, indem sie die Modelle, die Retrieval-Schicht und die unterstützenden Dienste in einer Infrastruktur betreibt, die Sie kontrollieren. Prompts, Dokumente und Ausgaben bleiben innerhalb einer definierten Grenze, unter Ihren Zugriffsrichtlinien und in Ihren Logs.

Was „private KI“ tatsächlich bedeutet

Ein privates KI-Deployment hat drei Eigenschaften. Erstens läuft die Inferenz auf Rechenleistung, die Ihnen exklusiv zugeordnet oder für Sie isoliert ist, nicht auf einem geteilten Multi-Tenant-Dienst, bei dem Ihre Prompts zusammen mit dem Traffic anderer Kunden verarbeitet werden. Zweitens werden Ihre Daten und Ihre Modellgewichte an Orten gespeichert, die Sie wählen, und nicht ohne Zustimmung anderswohin kopiert. Drittens wird jeder Zugriff auf das System authentifiziert, autorisiert und in Logs erfasst, die Ihnen gehören.

Ein Single-Tenant-Server im Rechenzentrum eines Anbieters, ein dedizierter GPU-Knoten oder ein isoliertes Cluster können die Definition erfüllen, sofern Vertrag und technische Kontrollen das absichern. Ausgeschlossen ist ein Setup, sobald es einen Pfad gibt, auf dem Daten standardmäßig die Grenze verlassen, etwa ein gehosteter Modellendpunkt, der Prompts für Training oder Missbrauchsprüfung speichert, oder ein Plugin, das einen nicht freigegebenen Drittanbieterdienst aufruft.

Die Referenzarchitektur

Fast jede private KI-Umgebung, ob sie einen einzelnen internen Chatbot oder ein Dutzend produktiver Workloads bedient, besteht aus denselben fünf Ebenen.

• GPU-Rechenleistung. Die Beschleuniger, die die Modellinferenz und bei Bedarf das Fine-Tuning ausführen. Dies ist in der Regel die teuerste Ebene und diejenige mit den knappsten Kapazitäten.
• Model Serving. Software, die Modellgewichte lädt, Anfragen in Batches bündelt und eine API bereitstellt. Gängig sind vLLM und NVIDIA Triton Inference Server, in der Regel mit Kubernetes orchestriert.
• Vektorspeicher und Retrieval. Eine Datenbank mit Embeddings, die es dem Modell ermöglicht, Fragen anhand Ihrer Dokumente zu beantworten, ohne es neu zu trainieren. Zu dieser Ebene gehört auch die Ingestion-Pipeline, die Inhalte in Abschnitte zerlegt, in Embeddings umwandelt und indexiert.
• Zugriffskontrolle. Anbindung an das Identitätsmanagement, rollenbasierte Berechtigungen und Netzwerkrichtlinien, die festlegen, wer welche Modelle und welche Dokumentensammlungen abfragen darf.
• Protokollierung und Monitoring. Aufzeichnungen von Anfragen, Antworten, Retrieval-Ergebnissen, administrativen Aktionen und Ressourcennutzung, aufbewahrt nach einer festgelegten Richtlinie.

Darunter Standardinfrastruktur: CPU-Server für Anwendung und Aufnahmejobs, Block- oder Object Storage für Rohdokumente und Modelldateien, Backups und ein privat adressiertes Netzwerk mit einem kontrollierten Zugangspunkt.

GPU-Rechenleistung dimensionieren

Der GPU-Speicher ist die erste Grenze, die Sie prüfen sollten, denn ein Modell, das nicht in den Speicher passt, läuft nicht mit brauchbarer Geschwindigkeit. Eine praktische Faustregel: Modellgewichte benötigen bei 16-Bit-Präzision etwa 2 Bytes pro Parameter, bei 8 Bit etwa 1 Byte und bei 4-Bit-Quantisierung rund ein halbes Byte. Ein Modell mit 8 Milliarden Parametern benötigt daher bei 16 Bit etwa 16 GB, ein Modell mit 70 Milliarden Parametern bei 16 Bit etwa 140 GB oder bei 4 Bit rund 35 bis 40 GB.

Die Serving-Engine hält außerdem für jede aktive Anfrage einen Key-Value-Cache, und dieser Cache wächst mit der Kontextlänge und der Zahl gleichzeitiger Nutzer. Planen Sie eine Reserve von 30 bis 50 Prozent über dem Speicherbedarf der Gewichte ein und validieren Sie das anschließend mit einem Lasttest mit Ihren realen Prompt-Längen.

Schätzen Sie die gleichzeitigen Anfragen in der Spitze, die durchschnittliche Eingabe- und Ausgabelänge und die akzeptable Antwortzeit. Batch-Workloads tolerieren Warteschlangen und bevorzugen weniger, größere GPUs bei hoher Auslastung. Interaktive Workloads brauchen genug Kapazität, um die Latenz in der Spitze vorhersehbar zu halten, was mehrere kleinere Knoten hinter einem Load Balancer bedeuten kann.

Entscheiden Sie schließlich, ob Sie überhaupt Trainingskapazität brauchen. Das Fine-Tuning eines großen Modells benötigt typischerweise ein Mehrfaches des Speichers, den die Inferenz desselben Modells braucht. Es lohnt sich daher, den Business Case zu bestätigen, bevor Sie dafür dimensionieren.

Open-Weight-Modelle und Model Serving

Open-Weight-Modelle, deren trainierte Parameter zum Download veröffentlicht werden, machen einen privaten Betrieb praktikabel. Inzwischen gibt es mehrere Modellfamilien in Größen von wenigen Milliarden bis zu mehreren hundert Milliarden Parametern, für allgemeinen Chat, Code, mehrsprachige Aufgaben und Embeddings.

Bewerten Sie anhand Ihrer eigenen Aufgaben mit einem festen Testset aus 100 bis 500 repräsentativen Prompts und bewerteten Antworten. Vergleichen Sie Genauigkeit, Latenz bei Ihrer Zielparallelität und Speicherbedarf bei der geplanten Präzision. Ein kleineres Modell, das mit gutem Retrieval korrekt antwortet, ist oft die bessere Wahl als ein größeres Modell, das doppelt so viele GPUs benötigt.

Lesen Sie vor allem anderen die Lizenz. Open-Weight bedeutet nicht immer Open Source. Manche Lizenzen beschränken die kommerzielle Nutzung ab einer bestimmten Nutzerbasis, untersagen bestimmte Anwendungen oder verlangen eine Namensnennung.

Für das Serving bietet eine Engine wie vLLM Continuous Batching und eine effiziente Cache-Verwaltung, was den Durchsatz gegenüber einer naiven Bearbeitung Anfrage für Anfrage deutlich verbessert. Triton ist nützlich, wenn Sie eine Mischung aus Modelltypen, etwa ein Embedding-Modell, einen Reranker und einen Generator, hinter einer gemeinsamen Schnittstelle bereitstellen.

Retrieval: Vektorspeicher und Datenpipeline

Retrieval-Augmented Generation ist das Muster, auf das sich die meisten privaten Deployments stützen. Das Modell antwortet aus Ihren Inhalten, ohne dass diese Inhalte jemals Teil der Modellgewichte werden.

Eine Million Chunks mit Vektoren von 1.024 Dimensionen, gespeichert als 32-Bit-Gleitkommazahlen, belegen etwa 4 GB reine Vektordaten, vor Index-Overhead und Originaltext. Die Optionen reichen von einer PostgreSQL-Erweiterung wie pgvector, die sich für Teams eignet, die bereits PostgreSQL betreiben, über dedizierte Engines wie Qdrant oder Milvus für größere Bestände bis zu den Vektorfunktionen von OpenSearch und Elasticsearch, wo bereits eine Stichwortsuche im Einsatz ist.

Die Pipeline ist wichtiger als die Datenbank. Wenn ein Nutzer eine Datei im Dokumentenmanagementsystem nicht öffnen darf, darf der Assistent sie ihm nicht zitieren. Zuverlässig lässt sich das durchsetzen, indem Sie Zugriffsmetadaten mit jedem Chunk speichern und zur Abfragezeit filtern, statt darauf zu vertrauen, dass das Modell Informationen zurückhält.

Zugriffskontrolle, Protokollierung und Data Governance

Binden Sie Ihren bestehenden Identity Provider über SAML oder OpenID Connect an, damit Eintritte, Wechsel und Austritte an einer Stelle abgewickelt werden. Definieren Sie Rollen, die realen Verantwortlichkeiten entsprechen: wer welche Modelle abfragen darf, wer Dokumentensammlungen hinzufügen darf, wer neue Modellversionen deployen darf und wer Logs lesen darf. Halten Sie administrativen Zugriff vom Nutzerzugriff getrennt und verlangen Sie für beide Multi-Faktor-Authentifizierung.

Platzieren Sie auf Netzwerkebene GPU-Nodes, Vektorspeicher und Storage auf privaten Adressen ohne eingehenden Internetzugang. Stellen Sie ein einziges API-Gateway bereit, das TLS terminiert, jede Anfrage authentifiziert und Rate Limits anwendet. Blockieren Sie ausgehenden Traffic von Modellservern standardmäßig und erlauben Sie nur die konkret benötigten Ziele, etwa einen internen Paket-Mirror.

Der Betrieb braucht Metriken wie GPU-Auslastung, Warteschlangenlänge, Latenz und Fehlerraten. Sicherheits- und Compliance-Teams brauchen einen Audit-Trail: wer was gefragt hat, welche Dokumente abgerufen wurden, welche Modellversion geantwortet hat und was zurückgegeben wurde. Prompts und Antworten können selbst sensible Daten enthalten. Behandeln Sie den Log-Speicher daher mit denselben Kontrollen wie die Quelldaten, verschlüsseln Sie ihn, beschränken Sie den Zugriff und legen Sie eine Aufbewahrungsfrist fest, die Ihrer Richtlinie entspricht, statt alles unbegrenzt aufzubewahren.

Klassifizieren Sie die Daten, die Sie nutzen wollen, legen Sie fest, welche Klassen in welchen Umgebungen zulässig sind, und dokumentieren Sie, wo jeder Datensatz physisch liegt. Halten Sie Evaluierung und Experimente von der Produktion getrennt, mit einem Prüfschritt, bevor ein neuer Datensatz oder ein neues Modell dorthin wechselt. Wenn Sie Fine-Tuning betreiben, bewahren Sie die Trainingsdaten, die resultierenden Gewichte und eine Dokumentation des Prozesses auf, denn ein feinabgestimmtes Modell kann Fragmente seiner Trainingsdaten wiedergeben und muss ebenso sorgfältig gesteuert werden wie die Daten selbst.

Fragen an einen Infrastrukturanbieter

Ob Sie GPU-Server, ein verwaltetes Cluster oder eine vollständig betriebene Plattform kaufen: Die Antworten auf die folgenden Fragen entscheiden darüber, ob die Umgebung wirklich privat ist.

• Mandantenmodell. Sind GPUs, Server und Speicher uns zugeordnet oder werden sie mit anderen Kunden geteilt? Falls geteilt: Wie wird die Isolation auf Hardware-, Hypervisor- und Netzwerkebene durchgesetzt?
• Standort. In welchem Land und in welchem Rechenzentrum befinden sich jeder Server und jede Kopie unserer Daten, einschließlich der Backups? Können Daten ohne unsere Zustimmung verlagert werden?
• Hardwarezusage. Welches GPU-Modell in welcher Stückzahl wird genau angeboten, und wie lang ist die bestätigte Lieferzeit? Was passiert, wenn sich die Lieferung verzögert?
• Zugriff durch Mitarbeitende des Anbieters. Welche Mitarbeitenden des Anbieters können auf unsere Systeme zugreifen, unter welchen Umständen, und wie wird dieser Zugriff protokolliert und an uns berichtet?
• Verantwortlichkeiten. Wer patcht Betriebssystem, Treiber und Serving-Software? Wer überwacht die GPUs, reagiert auf Hardwareausfälle und stellt aus Backups wieder her?
• Netzwerk. Welche Portgeschwindigkeit und welches Transferkontingent sind enthalten? Zur Orientierung: Ein 1-Gbps-Port überträgt bei Volllast rund 10 TB pro Tag, was beim Laden großer Dokumentenbestände oder Modelldateien eine Rolle spielt.
• Ausstieg. Wie erhalten wir zum Vertragsende unsere Daten, Gewichte und Logs zurück, und wie wird die Löschung verbleibender Kopien bestätigt?
• Preise. Ist der Preis für eine festgelegte Konfiguration monatlich fix, und welche Posten, etwa zusätzlicher Speicher, Transfer oder Supportstunden, werden separat abgerechnet?

Checkliste für den privaten KI-Betrieb

Nutzen Sie die folgende Liste während der Planung und noch einmal vor dem Go-live.

• Anwendungsfälle dokumentiert: Nutzer, Spitzen-Nebenläufigkeit, Prompt-Länge, Ziellatenz.
• Jede Datenquelle klassifiziert, mit freigegebenen Umgebungen pro Klasse.
• Open-Weight-Kandidaten anhand eines festen internen Testsets bewertet. Lizenzen geprüft und dokumentiert.
• GPU-Speicher für Gewichte und KV-Cache in der Spitze, mit 30 bis 50 % Reserve, per Lasttest validiert.
• Serving-Stack gewählt (z. B. vLLM oder Triton auf Kubernetes), Versionen und Prüfsummen fixiert.
• Vektorspeicher dimensioniert; die Aufnahme deckt Aktualisierung, Löschung und Berechtigungsmetadaten ab.
• Identity Provider integriert, Rollen definiert, MFA für Nutzer und Admins verpflichtend.
• Privates Netzwerk, ein authentifiziertes Gateway, ausgehender Traffic der Modellserver standardmäßig blockiert.
• Audit- und Betriebsprotokolle: verschlüsselt, zugriffsbeschränkt, per Richtlinie aufbewahrt.
• Evaluierung und Produktion getrennt, mit Freigabeschritt.
• Dokumente, Indizes, Konfiguration und Modelldateien gesichert. Wiederherstellung getestet.
• Schriftliche Antworten des Anbieters: Mandantentrennung, Standort, Personalzugriff, Verantwortlichkeiten, Ausstieg.

Wie Vonahost unterstützen kann

Vonahost stellt KI-Infrastruktur für private Bereitstellungen bereit, bei denen Daten und Modelle in der Umgebung des Kunden bleiben und auf Standardwerkzeugen wie PyTorch, vLLM, Triton und Kubernetes laufen. GPU-Kapazität wird pro Projekt angeboten, wobei GPU-Modell, Anzahl und Lieferzeit schriftlich bestätigt werden. Unterstützende Workloads wie Ingestion, Applikationsserver und Vektordatenbanken können auf Single-Tenant-Dedicated-Servern mit AMD EPYC und lokalem NVMe oder Netzwerk-Blockspeicher laufen, in der Region Ihrer Wahl.

Jedes Angebot von Vonahost nennt Konfiguration, Standort, Verantwortlichkeiten und Monatspreis in US-Dollar. Sie wählen das Land jedes Servers, und Daten werden nicht ohne Ihre Zustimmung verlagert.