Die meisten Programme für private LLMs bleiben an derselben Stelle stehen. Der Pilot funktioniert, eine einzelne GPU-Maschine bedient ein Team gut genug, und dann fragt jemand, wie ein zweiter Geschäftsbereich Zugang bekommt, wie Prompts revisionssicher protokolliert werden und was beim Neustart des Knotens passiert. Ab diesem Punkt geht es nicht mehr um Modelle, sondern um eine Infrastrukturfrage, für die das KI-Team üblicherweise nicht besetzt ist.
Der brauchbare Rahmen im Jahr 2026 lautet: Das eine private Deployment gibt es nicht. Es gibt drei Topologien, und sie unterscheiden sich darin, wer die Hardware hält, nicht darin, was die Software tut. On-Premises heißt, Modell, Daten und Serving laufen auf eigenen Maschinen innerhalb der eigenen Netzgrenze. Private Cloud, meist eine isolierte VPC, heißt, die Inferenz läuft in Cloud-Infrastruktur unter Ihrem IAM, Ihren Netzwerkkontrollen und Ihrem Logging, ohne geteilte Mandanten auf dem Inferenzpfad. Hybrid heißt beides, mit einer Routing-Schicht, die entscheidet, welche Anfrage wohin geht.
Alle drei sitzen unter derselben Control Plane: einem API-Gateway für Authentifizierung und Routing, einer Observability-Schicht, die Prompts, Antworten und GPU-Metriken erfasst, und einer Retrieval-Ebene, falls interne Dokumente im Spiel sind. Diese Control Plane richtig zu bauen wiegt schwerer als die Wahl der Topologie, denn sie ist es, die Ihnen später einen Topologiewechsel erlaubt, ohne jede konsumierende Anwendung neu zu schreiben.
Die drei Topologien und ihr jeweiliger Preis
On-Premises gibt Ihnen physischen Gewahrsam. Nichts verlässt das Gebäude, und das ist die einzig vertretbare Position für Air-Gapped-, exportkontrollierte und verteidigungsnahe Arbeit, zunehmend auch für Organisationen, deren Rechtsposition zur Datenresidenz keinen Cloud-Anbieter in der Kette duldet. Der Preis: Sie besitzen jetzt Hardwarebeschaffung, Kapazitätsplanung, Patching, Hochverfügbarkeit und GPU-Betrieb. Das sind echte Disziplinen mit echten Personalstellen, und sie sind der Grund, warum On-Prem-Piloten häufig besser aussehen als On-Prem-Produktion.
Private VPC ist in der Praxis der Unternehmensstandard, aus guten Gründen. Sie bekommen Isolation, eigene Logging- und Identitätsgrenze und elastische Kapazität, die nicht an einem in Monaten gemessenen Beschaffungszyklus hängt. Sie geben physische Kontrolle auf und übernehmen die Arbeit, Mandantentrennung und Egress-Kontrolle gegenüber Ihren eigenen Prüfern nachzuweisen. Für die meisten regulierten Unternehmen ist dieser Tausch richtig.
Hybrid ist der Ort, an dem Organisationen mit gemischtem Risiko landen. Sensible Workloads bleiben privat, Lastspitzen und risikoarmer Verkehr dürfen anderswohin, und die Routing-Policy wird zu einem geführten Artefakt. Der Preis ist Komplexität genau dort, wo Fehler teuer sind: Datenklassifizierung und Policy-Durchsetzung am Gateway.
Ein viertes Muster verdient eine eigene Nennung, weil es echtes Geld spart. Split-Tier-Inferenz hält kleine, volumenstarke Modelle auf privater Infrastruktur für die erste Stufe, also Klassifizierung, Extraktion und Routing, und reserviert große Modelle für den kleinen Anteil an Anfragen, die schweres Reasoning brauchen. Das meiste Token-Volumen im Unternehmen ist nicht schwierig. Wer seine private Ebene für die schwierigen 5 % dimensioniert, lässt private KI teurer erscheinen, als sie ist.
Der Referenzstack, Schicht für Schicht
Ein produktiver privater Stack hat fünf Schichten, und jede kennt eine überschaubare Zahl an Entscheidungen, die tatsächlich getroffen werden.
- Infrastruktur. GPU-Server oder ein GPU-Cluster, mit Netzwerk- und Storage-Pfaden, die für GPU-Verkehr statt für allgemeine Workloads dimensioniert sind. Hier unterdimensionieren Erstdeployments am häufigsten, weil die Aufmerksamkeit den Karten gilt und nicht dem, was sie speist.
- Serving-Runtime. vLLM ist die übliche Wahl für Serving mit hoher Nebenläufigkeit und vielen Nutzern, vor allem wegen des Umgangs mit dem KV-Cache unter Last. TensorRT-LLM ist die Option, wenn Sie maximale Effizienz aus NVIDIA-Hardware ziehen wollen und einen schwereren Build- und Optimierungsschritt akzeptieren. SGLang passt, wenn Ausführungsorchestrierung, strukturierte Ausgaben oder agentischer Kontrollfluss der schwierigere Teil des Problems sind. Ollama und llama.cpp bleiben vernünftig für Einzelnutzer und Edge-Fälle, sind aber nicht die Form einer geteilten Produktivebene.
- Gateway und Sicherheit. Ein Reverse Proxy oder API-Gateway (NGINX, Envoy, Traefik, Caddy) terminiert TLS und übernimmt Auth, Routing und Rate Limiting. Die Authentifizierung integriert sich in das, was Sie ohnehin betreiben: Active Directory, Okta oder Entra ID. Netzsegmentierung und dedizierte VLANs sind in gehärteten Deployments Standard, beim Bau billig und im Nachrüsten teuer.
- Observability. Prompt- und Antwortlogs, GPU-Auslastung, Latenzperzentile, Queue-Tiefe und Fehlerraten, exportiert in das, was Ihr Unternehmen bereits nutzt. Prometheus und Grafana sind die übliche Paarung. Behandeln Sie das als Produktivanforderung und nicht als Phase-zwei-Thema, denn ohne diese Daten können Sie weder Kapazitäts- noch Incident-Fragen beantworten.
- Retrieval. Für Wissensanwendungen steht ein Vector Store wie Milvus, Qdrant, Weaviate, pgvector oder Chroma neben der Inferenzebene. Halten Sie ihn architektonisch getrennt vom Serving. Retrieval ist der Ort, an dem dokumentbezogene Zugriffsrechte durchgesetzt werden, und es skaliert auf einer anderen Kurve als Inferenz.
Mandantenfähigkeit: Wählen Sie Ihren Blast Radius
Sobald ein zweites Team Zugang will, treffen Sie eine Isolationsentscheidung, ob Sie es bemerken oder nicht.
- Geteilter Cluster mit isolierten Namespaces nutzt GPUs am effizientesten und ist am schwersten korrekt abzusichern. Die Isolation entsteht aus Kubernetes-Namespaces, Network Policies, mandantenbezogener Authentifizierung und Quota-Durchsetzung. Das funktioniert, wenn ein Plattformteam bereits mandantenfähige Infrastruktur betreibt.
- Geteilte Control Plane mit dedizierter Data Plane gibt den Mandanten ein gemeinsames Gateway, gemeinsame Observability und Orchestrierung, während jeder eigene Inferenzknoten oder einen eigenen Node Pool bekommt. Das ist der übliche Kompromiss, und wir empfehlen ihn, wenn Geschäftsbereiche unterschiedliche Datenklassifizierungen, aber denselben operativen Eigentümer haben.
- Dedizierter Stack je Mandant bedeutet getrennte Cluster, getrennten Storage und getrennte Logs. Das kostet am meisten und ist richtig für eigenständige Rechtsträger, für einen regulierten Bereich innerhalb einer größeren Gruppe oder dort, wo der Compliance-Umfang eines einzelnen Mandanten sonst alles andere anstecken würde.
Was immer Sie wählen, die Mindestkontrollen sind dieselben: Authentifizierung, Autorisierung, mandantenbezogene Rate Limits, Logging und Netzsegmentierung. Die Quota-Durchsetzung verdient besondere Aufmerksamkeit, denn auf geteilten GPUs ist der Batch-Job des einen Teams der Latenzvorfall des anderen.
Was das Gateway tatsächlich entscheidet
Das LLM-Gateway ist das Teil, das die meisten Teams zuletzt bauen und zuerst bauen sollten. Es routet nach Modell, nach Mandant, nach Prompt-Sensibilität, nach Latenzklasse und nach Fallback-Policy. Darum herum sammeln produktive Deployments Prompt-Templates, Retrieval-Pipelines, semantische Caches, Guardrail- und DLP-Prüfungen sowie Budgetdurchsetzung je Anwendung.
Der Grund, es früh zu setzen: Es ist der einzige Ort, an dem Policy durchsetzbar statt beratend ist. Sensibilitätsklassifizierung, Modell-Allowlists und Egress-Regeln leben dort. Rufen Anwendungen die Inferenzendpunkte direkt auf, wird jede neue Anwendung zu einer eigenen Compliance-Prüfung, und ein Modell- oder Topologiewechsel bedeutet, jeden Aufrufer zu ändern.
Wie Sie entscheiden, und wo Sie anfangen
Arbeiten Sie die Kriterien der Reihe nach ab. Datensensibilität und regulatorischer Geltungsbereich stehen vorn: Muss die Umgebung getrennt oder exportkontrolliert sein, sind Sie On-Prem, und der Rest der Entscheidung folgt daraus. Ist Compliance gefordert, genügen Cloud-Kontrollen aber Ihrer Aufsicht und Ihrer Rechtsabteilung, bringt Sie die private VPC schneller in Produktion. Prüfen Sie dann ehrlich die operative Reife. Fehlen heute GPU-Betrieb, Observability und Plattform-Engineering-Kapazität, verzehrt On-Premises das Programm, bevor es etwas liefert.
Kosten und Auslastung kommen als Nächstes. On-Prem ist bei dauerhaft hoher Auslastung günstiger, aber erst nachdem Sie Beschaffungsvorlaufzeiten und Betriebsaufwand geschluckt haben; es belohnt also stetige Last und bestraft unsichere Nachfrage. Verfügbarkeit ist die letzte Hürde: Zwei Inferenzserver hinter einem Load Balancer sind die Grundlinie, und alles darunter ist ein Pilot, wie immer Sie es nennen.
Nach unserer Erfahrung ist der schnellste belastbare Start ein Deployment in einer privaten VPC mit vLLM hinter einem Gateway, einem Vector Store und vollständiger Telemetrie ab Tag eins, dimensioniert für Ihren tatsächlichen Erststufen-Workload statt für den anspruchsvollsten. Bringen Sie das mit echten Nutzern in Produktion, messen Sie Token-Volumen und Latenz je Anwendung, und lassen Sie diese Zahlen die On-Prem-Entscheidung treiben. Hardware zu kaufen, bevor Produktivdaten vorliegen, ist der Weg zu ungenutzten GPUs und einer Modellebene, die nicht zu dem passt, was die Leute von ihr verlangen.
Häufige Fragen
Ist On-Premises bei regulierten Daten immer die richtige Antwort?
Nein. On-Premises ist richtig, wenn die Daten Ihre physische Grenze nicht verlassen dürfen, wenn Exportkontrollrecht greift oder wenn die Umgebung tatsächlich getrennt betrieben wird. Für die meisten regulierten Workloads liefert eine isolierte Cloud-VPC unter eigenem IAM, eigener Netzwerkpolicy und eigenem Logging die benötigte Compliance-Position bei deutlich geringerer Betriebslast. Entscheidend ist nicht Sensibilität im Abstrakten, sondern ob Ihre rechtliche oder sicherheitstechnische Lage physischen Gewahrsam über die Hardware verlangt. Wenn nicht, führt die private VPC meist schneller in Produktion.
Brauchen wir Kubernetes für einen privaten LLM-Stack?
Nicht am ersten Tag. Ein einzelner GPU-Knoten mit vLLM hinter einem Reverse Proxy ist ein legitimes Produktivdeployment für ein einzelnes Team, und wir haben genau diese Form mehrfach in Betrieb gebracht. Kubernetes rechnet sich, sobald mehrere Modelle, mehrere Mandanten, rollierende Upgrades und Knotenausfälle einzuplanen sind. Wenn Ihr Plattformteam Kubernetes ohnehin betreibt, nutzen Sie es. Wenn nicht, verdoppeln Sie mit der gleichzeitigen Einführung von Orchestrator und Inference-Stack die Zahl der Dinge, die beim ersten Rollout scheitern können.
Wie behandeln wir Anfragen, die wirklich ein Frontier-Modell brauchen?
Routen Sie sie, und zwar explizit. Das Muster ist ein Gateway, das jede Anfrage nach Datensensibilität und Aufgabentyp klassifiziert, regulierten und volumenstarken Verkehr auf privater Infrastruktur hält und eine definierte, freigegebene Teilmenge an eine Managed API weiterleitet. Die Control Plane braucht Klassifizierungsregeln, Modell-Allowlists und Egress-Kontrollen, damit die Routing-Entscheidung durchgesetzt und nicht bloß dokumentiert ist. Was dieses Muster bricht, ist ein impliziter Fallback: Erreicht überlaufender Verkehr bei einem Kapazitätsvorfall still einen öffentlichen Endpunkt, ist Ihre Datengrenze Dekoration.