LLM selbst hosten in einem SaaS-Produkt: GPU-Server für KI-Funktionen, Mandanten und EU-Datenresidenz

LLM selbst hosten in einem SaaS-Produkt: wann es passt

Ein europäisches SaaS-Unternehmen, das KI-Funktionen für seine Kunden ergänzt, kann das LLM selbst hosten und die KI-Funktionen im Produkt selbst betreiben, mit offenen Modellen auf eigenen GPU-Servern, on-premise oder in einem EU-Rechenzentrum, wenn Kunden EU-Datenresidenz verlangen und keine Modell-API eines Dritten im Datenpfad wollen. Maßgeblich für die Auslegung ist je Funktion die Zahl der Anfragen, die in der Spitzenminute gleichzeitig in Bearbeitung sind, gemessen an einem Latenzziel für jede Funktion, nicht die Zahl der Nutzer oder Mandanten.

Verarbeitet ein SaaS-Unternehmen personenbezogene Daten im Auftrag seiner Kunden, ist es in der Regel deren Auftragsverarbeiter, und nach Artikel 28 Absatz 2 DSGVO „nimmt keinen weiteren Auftragsverarbeiter ohne vorherige gesonderte oder allgemeine schriftliche Genehmigung des Verantwortlichen in Anspruch“. Bei einer allgemeinen Genehmigung informiert der Auftragsverarbeiter den Verantwortlichen über einen hinzukommenden Auftragsverarbeiter, „wodurch der Verantwortliche die Möglichkeit erhält, gegen derartige Änderungen Einspruch zu erheben“. Ein Anbieter einer Modell-API, der Prompts mit personenbezogenen Daten erhält, wäre in der Regel ein solcher hinzukommender Auftragsverarbeiter. Server, die das SaaS-Unternehmen kontrolliert, setzen keinen Anbieter einer Modell-API auf die Liste der Unterauftragsverarbeiter; ob ein Rechenzentrumsbetreiber oder ein Dienstleister mit Zugriff auf diese Server Auftragsverarbeiter ist, hängt von diesem Zugriff ab.

GPU-Server für KI-Funktionen auslegen: Spitzenanfragen je Funktion

Multiplizieren Sie für jede Funktion die Ankunftsrate in der Spitzenminute mit der Zeit, die eine Anfrage in Bearbeitung bleibt, vom Eingang bis zu ihrem letzten Token. Diese Zeit folgt aus dem Latenzziel und der Länge der Antwort, und beide unterscheiden sich je Funktion.

Beispielziele aus unserem Latenz-Leitfaden; Formen der Anfragen und Serving-Muster sind unsere Beispiele und mit Ihren Prompts zu testen.

Unser Leitfaden zu Latenzzielen für LLMs erklärt die Zeit bis zum ersten Token (TTFT) und die Zeit pro Ausgabe-Token (TPOT). Der Benchmarking-Leitfaden von NVIDIA schreibt, dass die TTFT im Allgemeinen die Netzwerklatenz einschließt; die Modellserver gehören deshalb in die Nähe der Anwendungsserver, die sie aufrufen.

Rechenbeispiel: drei KI-Funktionen auf zwei GPU-Servern

Das Beispiel dient der Veranschaulichung: ein Dokumentenmanagement-Produkt mit 300 Geschäftskunden und 40.000 Endnutzern. In seiner Spitzenminute erhält der Assistent 60 Anfragen, eine pro Sekunde. Eine Antwort von 400 Token braucht bei den Zielwerten 1 + 399 × 0,1 s, etwa 41 s, also sind etwa 41 Anfragen in Bearbeitung. Die Zusammenfassungsfunktion erhält 30 Anfragen pro Minute, und 250 Token nach einem ersten Token bei 2,5 s brauchen etwa 27 s, was etwa 14 hinzufügt. Ein nächtlicher Extraktionsjob läuft außerhalb der Arbeitszeit unter einem eigenen Rate Limit. Die interaktive Spitze liegt bei etwa 55 Anfragen in Bearbeitung; wer die p95-Ziele als Zeit je Anfrage ansetzt, rechnet eher zu hoch.

Alle Funktionen laufen hier auf gpt-oss-120b mit einem festgelegten Kontext von 32K und einem KV-Cache in 16 Bit. Nach den Schätzungen in unseren Auslegungsleitfäden bleibt damit Platz für etwa 19 Gespräche je RTX PRO 6000 Server Edition und 55 je H200 NVL, mit einer Kopie des Modells je Karte. Die Kunden erwarten, dass die Funktion bei einem Serverausfall verfügbar bleibt, also muss jeder der beiden Server die Spitze allein tragen, und unsere Beispielrichtlinie lässt die Spitze höchstens 80 Prozent dieser Kapazität nutzen.

Veranschaulichendes Beispiel und unsere Schätzungen: eine Spitze von 55 Anfragen in Bearbeitung; Sitzungen von gpt-oss-120b bei 32K mit einem KV-Cache in 16 Bit, 19 je RTX PRO 6000 und 55 je H200 NVL, wie in unseren Kapazitätsleitfäden; 80 Prozent sind eine Beispielgrenze.

Der Speicher setzt eine Grenze, ein Lasttest mit Ihren eigenen Prompts bei 55 Anfragen in Bearbeitung die andere: Die Kapazität eines Servers ist der niedrigere der beiden Werte.

Wir prüfen Rack, Strom und Luftstrom, bevor wir ein Angebot erstellen. Schicken Sie uns Ihre Funktionen und deren Anfragen in der Spitzenminute über das Formular unten.

Multi-Tenant-LLM-Serving: Mandanten auf geteilten GPUs trennen

Die meisten Mandanten teilen sich eine Modellinstanz, und ihre Trennung beruht auf den Schichten um diese Instanz herum. Ein Gateway vor den Modellservern gibt jedem Mandanten eigene Schlüssel, Token-Kontingente und eine Mandanten-ID in jedem Logeintrag, sodass der Bulk-Job eines Mandanten den Assistenten eines anderen nicht verdrängen kann. Wie Schlüssel, Budgets und das Query-Log funktionieren, beschreibt unser Leitfaden zu einem LLM-Gateway mit Schlüsseln, Budgets und Protokollierung.

Eine geteilte Instanz teilt auch ihren Prefix-Cache. Die Designdokumentation von vLLM vom 23. Juni 2026 beschreibt einen cache_salt je Anfrage, „sodass nur Anfragen mit demselben Salt gecachte KV-Blöcke wiederverwenden können“, als Schutz gegen Timing-Angriffe, die aus Latenzunterschieden auf gecachte Inhalte schließen. Ihr Sicherheitsleitfaden, abgerufen am 10. Oktober 2026, sagt: „Behandeln Sie den Salt als Geheimnis“, und empfiehlt zufällige Werte „statt vorhersagbarer Kennungen wie eines Benutzernamens oder einer Konto-ID“. Lassen Sie das Gateway ein zufälliges Geheimnis je Mandant halten, es bei jeder Anfrage setzen und jeden Salt überschreiben, den ein Client mitschickt. Derselbe Leitfaden nennt cache_salt „keine Isolationsgrenze“; Mandanten, die voneinander isoliert sein müssen, erhalten deshalb eine eigene Instanz.

Bezahlt ein Mandant für ein Modell, das an seine eigene Terminologie angepasst ist, bedient vLLM LoRA-Adapter auf einem Basismodell, und seine Modellliste führt gpt-oss als unterstützt. Adapter „lassen sich effizient pro Anfrage mit minimalem Overhead bereitstellen“, und eine Anfrage wählt einen über den Parameter model. max_loras, die Zahl der Adapter in einem Batch, steht standardmäßig auf 1; setzen Sie den Wert auf die Zahl der Mandantenadapter, die gleichzeitig genutzt werden. Adapter in einen laufenden Server zu laden erfordert VLLM_ALLOW_RUNTIME_LORA_UPDATING, das laut vLLM „nicht in der Produktion verwendet werden sollte, es sei denn, es handelt sich um eine isolierte, vollständig vertrauenswürdige Umgebung“; laden Sie Mandantenadapter deshalb beim Start und rollen Sie sie aus wie einen Modellwechsel.

Der MIG User Guide von NVIDIA, aktualisiert am 11. September 2026, nennt bis zu 7 MIG-Instanzen auf der H200 NVL und bis zu 4 auf jeder Edition der RTX PRO 6000 Blackwell, jede mit „getrennten und isolierten Pfaden durch das gesamte Speichersystem“. Die kleinsten Profile sind 1g.24gb auf der RTX PRO 6000 und 1g.18gb auf der H200 NVL, die NVIDIAs Seite zur H200 mit 16,5 GB je Instanz angibt, genug für das Embedding-Modell eines Mandanten oder ein Modell mit einigen Milliarden Parametern; gpt-oss-120b braucht ganze Karten. Alle MIG-Instanzen nutzen den Treiber des Hosts; Mandanten, die einander nicht vertrauen dürfen, gehören deshalb in getrennte virtuelle Maschinen mit einer durchgereichten GPU oder einer vGPU. L40S und L4 stehen nicht in der Liste der MIG-fähigen GPUs von NVIDIA.

Dokumentation von vLLM zu Sicherheit, Prefix-Caching und LoRA; MIG User Guide von NVIDIA und dessen Seite der unterstützten GPUs, abgerufen am 10. Oktober 2026; die Zuordnung zu Mandantenprofilen ist unser Beispiel.

Verfügbarkeit und Modellwechsel, ohne Kunden zu stören

Zwei Knoten, von denen jeder die Spitze trägt, hinter Health Checks, sind das Minimum für eine KI-Funktion, die den Ausfall eines Servers übersteht; zwei Standorte decken auch den Ausfall eines Raums ab. Unser Leitfaden zur LLM-Hochverfügbarkeit mit zwei GPU-Knoten behandelt die Health Checks und das Update jeweils eines Knotens nach dem anderen.

Kunden bauen auf das Ausgabeformat und den Ton eines Modells, ein Modellwechsel ist deshalb ein Release. --revision in vLLM nimmt „einen Branch-Namen, einen Tag-Namen oder eine Commit-ID“ entgegen und pinnt damit die genauen Gewichte vom Hugging Face Hub, --tokenizer-revision tut dasselbe für den Tokenizer, und --served-model-name legt „den oder die in der API verwendeten Modellnamen“ fest. Geben Sie jeder Modellversion einen eigenen Namen und halten Sie einen mitwandernden Alias nur für Mandanten, die automatischen Upgrades zugestimmt haben.

1. Pinnen Sie das neue Modell per Commit oder über ein versioniertes Verzeichnis in einer lokalen Modellablage und betreiben Sie es als separate Instanz unter einem neuen Namen.
2. Lassen Sie den Evaluierungssatz jedes Mandanten, seine Prompts und erwarteten Ausgabeformate, gegen die alte und die neue Version laufen.
3. Trainieren Sie die LoRA-Adapter der Mandanten auf dem neuen Basismodell neu, denn ein Adapter gehört zu dem Basismodell, auf dem er trainiert wurde.
4. Kündigen Sie den Wechsel mit einem Zeitraum an, in dem beide Versionen laufen, und stellen Sie Mandanten in Etappen über das Gateway um.
5. Entfernen Sie die alte Version, sobald kein Mandantenschlüssel sie mehr aufruft.

Datenresidenz für KI in SaaS: eigene Racks oder ein EU-Rechenzentrum

Wer selbst hostet, entscheidet, wo Prompts, Ausgaben, der KV-Cache, das Query-Log und alle Daten für das Fine-Tuning liegen. Die Server können in Racks stehen, die das SaaS-Unternehmen selbst betreibt, oder als dedizierte Server in einem EU-Rechenzentrum. Im zweiten Fall verlagern sich die Fragen darauf, wer Root- und BMC-Zugriff hat und wo Logs und Backups gespeichert werden, wie unser Leitfaden zu privater LLM-Inferenz in einem EU-Rechenzentrum ausführt. GPU-Instanzen zu mieten ist ein dritter Weg, den unser Artikel Cloud-GPU mieten oder eigener GPU-Server mit eigenen Servern vergleicht.

In unserem Service Private AI/ML laufen die Modelle auf Ihren Servern oder auf dedizierter Hardware in einem Tier-3-Rechenzentrum in Litauen, und nichts geht an öffentliche Dienste, solange Sie es nicht ausdrücklich freigeben. Nennen Sie uns, wo die Daten Ihrer Mandanten bleiben müssen.

KI-Verordnung und Data Act: Pflichten für SaaS mit KI-Funktionen

Anbieter ist nach Artikel 3 Nummer 3 der KI-Verordnung eine Person oder Stelle, die ein KI-System entwickelt oder entwickeln lässt und es „unter ihrem eigenen Namen oder ihrer Handelsmarke in Verkehr bringt oder das KI-System unter ihrem eigenen Namen oder ihrer Handelsmarke in Betrieb nimmt, sei es entgeltlich oder unentgeltlich“. Ein SaaS-Unternehmen, das einen auf einem offenen Modell aufgebauten Assistenten unter eigenem Namen anbietet, kann unter diese Definition fallen. Seine Geschäftskunden, die die Funktion nutzen, sind Betreiber nach Artikel 3 Nummer 4. Seit dem 2. August 2026 verlangt Artikel 50 von Anbietern, Systeme für die direkte Interaktion mit Menschen so zu gestalten, dass diese erfahren, dass sie mit einem KI-System interagieren, es sei denn, dies ist offensichtlich, und erzeugten Text in einem maschinenlesbaren Format zu kennzeichnen, außer soweit die Systeme „eine unterstützende Funktion für die Standardbearbeitung ausführen“. Für generative Systeme, die vor dem 2. August 2026 in Verkehr gebracht wurden, legt die durch die Verordnung (EU) 2026/1744 geänderte KI-Verordnung für diese Kennzeichnung den 2. Dezember 2026 fest (Artikel 111 Absatz 4).

Das Kapitel der Datenverordnung (Data Act) zum Anbieterwechsel bindet Anbieter von Datenverarbeitungsdiensten, und ihr Erwägungsgrund 81 nennt Infrastructure as a Service (IaaS), Platform as a Service (PaaS) und Software as a Service (SaaS). Exportierbare Daten sind nach Artikel 2 Nummer 38 „die Eingabe- und Ausgabedaten einschließlich Metadaten“, die durch die Nutzung des Kunden generiert werden; Zusammenfassungen und extrahierte Felder, die für einen Kunden gespeichert sind, können deshalb darunter fallen, sofern sie nicht durch Rechte des geistigen Eigentums geschützt sind oder ein Geschäftsgeheimnis des Anbieters oder Dritter darstellen. Ab dem 12. Januar 2027 dürfen Anbieter keine Wechselentgelte mehr erheben (Artikel 29 Absatz 1), außer für Dienste, die größtenteils für einen einzelnen Kunden gebaut sind und nicht im größeren kommerziellen Maßstab angeboten werden (Artikel 31 Absatz 1). Mit Stand 6. Oktober 2026 war der Digital-Omnibus-Vorschlag der Kommission, der dieses Kapitel ändern soll, nicht angenommen. Welche Rolle und welche Pflichten für ein bestimmtes Produkt und einen bestimmten Vertrag gelten, ist eine rechtliche Bewertung für Ihre Rechtsabteilung.

Was wir liefern

Wir bauen KI-Server auf Bestellung mit 2 bis 8 GPUs je Knoten, ausgelegt nach Modellgröße und gleichzeitigen Nutzern, mit Herstellergarantie, unter einem EU-Vertrag und auf einer Rechnung. Die Karten für KI-Funktionen in einem SaaS-Produkt sind die RTX PRO 6000 Server Edition mit 96 GB, die H200 NVL mit 141 GB HBM3e und NVLink-Bridges sowie die L40S und die L4 für kleinere Modelle, aus unserem Sortiment professioneller NVIDIA-GPUs. Die Plattform darüber, mit privaten LLMs, einem Query-Log und Hosting auf dedizierter Hardware in einem Tier-3-Rechenzentrum in Litauen, ist unser Service Private AI/ML, mit Engineering von unserem Engineering-Partner Vixen.UNO und Support unter einem vereinbarten SLA.

FAQ