STACKIT · GPU und KI-Betrieb
GPU Kubernetes und KI-Infrastruktur auf STACKIT
Welches Modell läuft auf welcher GPU, und wer verantwortet Treiber, Updates und Ausfälle? SKAFFON beantwortet das vor der Bestellung, baut die Umgebung als Code und betreibt sie auf Wunsch.
- GPU-Server, SKE-Nodepools, AI Model Serving
- Aufbau als Code, Operator-Version fixiert
01Dokumentierte Typen
A100, L40S, H100: was STACKIT an GPU-Servern führt
Stand der Prüfung 13.11.2026, laut STACKIT-Dokumentation zu Maschinentypen und Produktseite Compute Engine GPU. Alle drei Typen führt STACKIT in der Region eu01, die laut STACKIT-Regionenübersicht in Deutschland liegt; die Maschinentypen der Region eu02 in Österreich enthalten keine GPU-Typen, und auch die Produktseite listet die GPU-Server nur für EU01. GPU-Workloads planen wir deshalb in eu01.
-
n1: NVIDIA A100 80 GB
1, 2 oder 4 GPUs je Server. Der Typ mit vier GPUs ist laut Dokumentation auf Anfrage über ein Help-Center-Ticket erhältlich.
-
n2: NVIDIA L40S 48 GB
1, 2 oder 4 GPUs je Server.
-
n3: NVIDIA H100 HGX 80 GB
Die Dokumentation führt den Typ n3.104d.g8 mit 8 GPUs und 104 vCPU; die Produktseite listet n3-Server zusätzlich mit 1, 2 und 4 GPUs. Beim Arbeitsspeicher des 8-GPU-Typs nennen die beiden Seiten unterschiedliche Werte (1900 und 1728 GB), den verbindlichen Wert holen wir vor der Dimensionierung bei STACKIT ein.
02Betrieb
GPU-Server lassen sich nicht live migrieren
Wartung bedeutet bei diesen Maschinentypen eine Unterbrechung. Für Dienste mit Verfügbarkeitsanspruch ist das eine Architekturfrage und kein Betriebsdetail: mehrere Server, Lastverteilung und ein Update-Ablauf, der einen Server nach dem anderen aus dem Verkehr nimmt.
Deshalb legen wir diese Punkte vor dem Aufbau fest, nicht nach dem ersten Wartungsfenster.
03
Drei Wege auf STACKIT: wer trägt die Verantwortung für den Modellbetrieb?
Die Wahl hängt an einer Frage: Wollen Sie die Modellbereitstellung selbst verantworten? Ein Standardmodell hinter einer API reicht oft für den Einstieg. Eine eigene Serving-Plattform lohnt sich, wenn Modelle, Daten oder Latenzanforderungen das verlangen.
04
GPU-VM, SKE-Nodepool oder AI Model Serving im Vergleich
| Kriterium | Compute Engine GPU (VM) | GPU-Node-Pool in SKE | AI Model Serving |
|---|---|---|---|
| Was Sie bekommen | virtuelle Server mit 1 bis 8 GPUs | Kubernetes-Nodes mit GPU, Scheduling über Kubernetes | verwaltete Bereitstellung von KI-Modellen (laut STACKIT mit Fokus auf LLMs wie Llama und Mistral) |
| Kontrolle über Stack und Modelle | volle Kontrolle, volle Verantwortung | hohe Kontrolle, Betrieb über Kubernetes | Modellauswahl und Betrieb durch STACKIT; Spielraum laut Modellliste |
| Betriebsaufwand | Treiber, Runtime, Updates auf der VM | GPU Operator, Node-Pool-Updates, Modell-Serving-Stack | gering; Anbindung und Nutzung |
| Passt, wenn | einzelne Jobs, Training, feste Umgebung | mehrere Modelle und Teams, Plattform auf Kubernetes, eigene Serving-Software | Standardmodelle über API genügen, wenig Plattformaufwand gewünscht |
| Mehrere Teams/Mandanten | Trennung über eigene VMs | Namespaces, Netzwerkrichtlinien, Quotas | laut Dienstbeschreibung gemeinsam genutzte Modelle ohne Datenaustausch zwischen Projekten oder Kunden; Zugriff über Auth-Tokens je Projekt |
| Eigene Modelle/Fine-Tuning | ja | ja | laut FAQ nur Open-Source-Modelle aus dem STACKIT-Portfolio, weitere Modelle auf Anfrage über das Help Center |
Details zum Aufbau privater Modell-Plattformen: Private LLMs und LLM Inference.
05Rechenbeispiel
Vom Modell zur GPU: Speicherbedarf der Gewichte
Faustregel: Parameterzahl mal Bytes pro Parameter. Dazu kommen Zwischenspeicher für die Eingabekontexte (KV-Cache) und Laufzeit-Overhead, die vom Workload abhängen und hier nicht beziffert werden. Die Rechnung ist deshalb eine Untergrenze, kein Sizing.
- 01
16 GB: eine L40S genügt zum Testen
8 Mrd. Parameter, 16 Bit8 × 10⁹ × 2 Byte = 16 GB. Das passt auf eine L40S (48 GB) mit Reserve für den Cache; ein Server vom Typ n2 mit einer GPU reicht zum Testen.
- 02
140 GB: mehr als eine 80-GB-GPU
70 Mrd. Parameter, 16 Bit70 × 10⁹ × 2 Byte = 140 GB. Das passt nicht auf eine einzelne 80-GB-GPU. Es braucht mindestens zwei A100 80 GB (160 GB) allein für die Gewichte, praktisch mehr wegen des Caches, also Typen mit vier oder acht GPUs, oder eine geringere Genauigkeit der Gewichte.
- 03
Parallelität hängt an der Anbindung
Mehrere GPUs je ModellInnerhalb eines Servers hängt die Geschwindigkeit an der GPU-Verbindung, zwischen Servern an der Netzwerkanbindung. Ob Ihre Konstellation damit trägt, messen wir an Ihrem Modell, nicht an einer Tabelle.
06
Die Serving-Software bleibt Ihre Wahl
vLLM etwa bietet einen OpenAI-kompatiblen Server und Verfahren wie Continuous Batching und verteilte Inferenz über mehrere GPUs. Welche Software zu Ihrem Modell passt, entscheiden wir gemeinsam mit Ihnen im Lasttest.
07SKE
GPU-Nodepools in SKE: was die Anleitung festlegt
Die SKE-Anleitung zu NVIDIA-GPUs ist die Grundlage unseres Entwurfs. Vier Randbedingungen prägen ihn.
- Der NVIDIA GPU Operator installiert und verwaltet die Treiber, unterstützt derzeit nur Node-Pools mit Ubuntu; Treiber sind nicht in Images vorinstalliert.
- Die Operator-Version sollte fixiert werden, damit Treiber, CUDA und Kubernetes-Version zueinander passen.
- GPU-Pods fordern
nvidia.com/gpuan; ein Taint hält andere Workloads fern, mindestens ein weiterer Pool ohne Taint soll existieren. - Betriebssystem-Updates ersetzen Nodes schrittweise, danach kann die Treiberinstallation auf dem neuen Node fehlschlagen. PodDisruptionBudgets brauchen mindestens zwei Instanzen;
maxUnavailable: 0wird ignoriert und erzwingt das Upgrade.
08
Unsere Standardmaßnahmen für einen GPU-Pool
Aus den Randbedingungen folgt, was wir in jedem Entwurf festlegen. Den laufenden Betrieb beschreibt Managed GPU und KI-Plattformen.
- GPU-Pool getrennt von den allgemeinen Pools
- Operator-Version als Teil des Codes
- Update-Test des Treibers vor der Produktivfreigabe
- Überwachung der GPU-Zustände mit dem DCGM-Exporter und Prometheus
09
Teams und Daten trennen, bevor GPUs geteilt werden
Die Trennung erfolgt auf zwei Ebenen: in STACKIT über Projekte, Netzwerke und Rechte (siehe Landing Zone), im Cluster über Namespaces, Netzwerkrichtlinien und Zugriffskontrolle. GPU-Sharing zwischen Mandanten ist eine eigene Risikoentscheidung. STACKIT stellt GPUs in Maschinentypen mit einer festen Zahl je Server bereit: 1, 2, 4 oder 8 (Stand: 13.11.2026). Laut NVIDIA lassen sich A100 und H100, auch in HGX-Systemen, per Multi-Instance GPU (MIG) in bis zu sieben Instanzen teilen; die L40S führt NVIDIA dort nicht. Ob MIG auf einem STACKIT-Server mit A100 oder H100 aktiviert werden kann, prüfen wir in der Testmigration, bevor wir eine Aufteilung einplanen.
Die Produktseite von AI Model Serving nennt für alle Modelle die Region eu01, die laut Regionenübersicht in Deutschland liegt. Daten aus den Anfragen werden laut FAQ weder gespeichert noch zum Training von Modellen verwendet. Die Modelle sind Shared Models, die alle Kunden gemeinsam nutzen, ohne Datenaustausch zwischen Projekten oder Kunden; Ratenlimits begrenzen die Nutzung. Der Zugriff läuft über eine OpenAI-kompatible Inference-API mit Auth-Tokens je Projekt. Sie entstehen im Portal oder per API mit dem Token eines Benutzers oder Service-Accounts, haben eine optionale Laufzeit, gelten für alle Shared Models und lassen sich nach dem Erstellen nicht erneut abrufen. Wo die Tokens liegen, wer sie erneuert und welche Daten an das Modell gehen dürfen, legen wir im Entwurf fest.
Die Zuordnung zu Maschinentypen ersetzt keinen Lasttest.
Ob ein Modell auf der gewählten GPU mit Ihren Anfragen trägt, zeigt erst die Messung mit Ihrem Modell, Ihrer Serving-Software und Ihrer Last. Wir sehen sie als Teil der Abnahme, nicht als Zusatz.
10Kosten
Was die GPU-Kosten bestimmt
STACKIT rechnet GPU-Server laut Produktseite nutzungsabhängig ab; aktuelle Preise stehen dort. Wir empfehlen, die Last über einen Zeitraum zu messen, bevor ein Dauerbetrieb dimensioniert wird, und GPU-Pools bei schwankender Last mit Autoscaling zu betreiben.
-
Typ und Zahl der GPUs
Von der einzelnen L40S bis zum Server mit acht H100.
-
Laufzeit
Nur während der Nutzung oder dauerhaft.
-
Auslastung
Gemessene Last statt geschätzter Spitzen.
-
Speicher
Für Modelle und Daten.
-
Betriebsumfang
Nur Aufbau oder auch laufender Betrieb.
11
Vom Modellwunsch zur abgenommenen GPU-Plattform
- 01
Workload und Daten klären
Inferenz oder Training, Modellgrößen, Parallelität, Datenklassen.
- 02
Weg wählen und Zugriff entwerfen
Wahl nach Entscheidungsraster, Entwurf von Netzwerk und Zugriff.
- 03
Als Code aufbauen
Terraform/OpenTofu und GitOps, Operator-Version fixiert.
- 04
Mit Ihren Modellen abnehmen
Abnahme mit einem vorab vereinbarten Testplan.
- 05
Betrieb festlegen
Betrieb durch Ihr Team oder durch SKAFFON, je nach Vereinbarung.
12
GPU auf STACKIT: Wo unsere Arbeit endet
Dafür sind wir zuständig
- GPU-Umgebungen auf STACKIT für Inferenz und Modellbetrieb
- GPU-Node-Pools in SKE mit fixiertem Operator
- Laufender Betrieb der Plattform auf Wunsch
Dafür sind wir nicht zuständig
- Cluster mit Interconnect-Anforderungen, die STACKIT nicht belegt: Besser passt der Aufbau eigener GPU-Cluster.
- Modelltraining als Dienstleistung oder Data-Science-Beratung: Wir bauen und betreiben die Infrastruktur, Modellentwicklung ist nicht Gegenstand.
- GPU-Preise oder Kapazitätszusagen: Die kommen von STACKIT.
13
Häufige Fragen
Kann ich GPU-Server und Kubernetes kombinieren?
Ja, GPU-Node-Pools in SKE sind dokumentiert; Voraussetzung ist Ubuntu als Node-Image.
Welche GPUs gibt es?
Laut STACKIT A100 80 GB, L40S 48 GB und H100 HGX 80 GB, jeweils in definierten Maschinentypen der Region eu01 in Deutschland. Die aktuelle Liste steht in der STACKIT-Dokumentation.