Selfhosting von KI-Modellen in deinen Kubernetes-Clustern

KI ist heutzutage in aller Munde. Während einige Organisationen die Möglichkeit haben, extern gehostete Modelle von z. B. Anthropic, Google, ... zu nutzen, haben andere diese Optionen vielleicht nicht. Es gibt verschiedene Möglichkeiten, KI-Modelle auf der eigenen Hardware oder Infrastruktur von z. B. AWS, OVHCloud, IONOS, Hetzner zu hosten. In diesem Artikel richten wir alles ein, was du brauchst, um ein Open-Weight-KI-Modell (qwen3-30b) auf einem Kubernetes-Cluster zu hosten, das GPU-Nodes nutzt, um die Modelle auszuführen.

Warum Kubernetes?

Das Ausführen großer Sprachmodelle auf jedweder Infrastruktur ist eine schwierige Aufgabe. Du fragst dich also vielleicht, warum du dir die Mühe machen solltest, es in Kubernetes auszuführen? Warum den Container nicht einfach auf einer VM oder direkt auf der Hardware ausführen?

Kubernetes ist in vielen Branchen weit verbreitet und oft die erste Wahl für Unternehmen, die Anwendungen selbst ausführen müssen und mehr Kontrolle darüber haben wollen, wo ihre Daten liegen.

Es lässt sich zudem am einfachsten umziehen. Wenn du deine Workloads von AWS zu OVH migrieren möchtest und alles, was du hast, in Kubernetes läuft, wirst du es mit Sicherheit leichter haben, deine Anwendungen und Workloads zu verschieben, als wenn du sie auf EC2-Instanzen, Bedrock, Lambda, Aurora etc. laufen lässt.

Warum GPU-Nodes? (und VRAM-Mathematik)

Obwohl es möglich ist, KI-Modelle auf jedem Compute-Node mit ausreichend Arbeitsspeicher auszuführen, gibt es enorme Performance-Unterschiede. Das gilt sowohl für die gesamte Antwortzeit als auch für die TTFT (Time to First Token). Wenn dein Modell nur auf deiner CPU läuft, musst du wahrscheinlich eher kleine Modelle mit höherer Quantisierung verwenden oder in Kauf nehmen, auf deine Antworten zu warten. Wenn du eine GPU verwendest, solltest du dir die Mühe machen zu berechnen, wie groß das Modell und der Kontext sein dürfen, damit sie in den VRAM der GPU passen. Nur wenn du das gesamte Modell darin unterbringen kannst, erreichst du die beste Performance und holst das Beste aus deinen Modellen heraus. Mit dem llama-server (der in diesem Setup verwendet wird) kannst du auch Teile deines Modells aus dem VRAM der GPU auslagern (über das -ngl-Flag), aber das wird deine Performance ebenfalls stark beeinträchtigen. Es gibt jedoch Modelle, die für diesen Anwendungsfall besser optimiert sind. MoE-Modelle (Mixture of Experts) scheinen in diesem Kontext besser abzuschneiden.

Hier ist die Berechnung, die für dieses Setup verwendet wurde: Wir nutzen eine AWS-g5.2xlarge-Instanz, die eine NVIDIA A10G-GPU mit 24 GB VRAM bietet. Das Qwen3-30B-A3B-Modell benötigt in der 4-Bit-quantisierten Version etwa 19 GB VRAM. Da es sich um ein MoE-Modell handelt, haben wir einen kleinen KV-Cache. Daher kommen wir mit einer Kontextgröße von 32k aus und haben immer noch genügend Spielraum (Headroom) im VRAM.

Architektur

Um über ein einfaches „Hello World“-Setup hinauszugehen, integrieren wir kagent — ein CNCF-Sandbox-Projekt, das eine Open-Source-Agenten-Runtime direkt in Kubernetes einbringt. Dies ermöglicht es uns, über Model Context Protocol (MCP) Server und eine übersichtliche Web-UI in natürlicher Sprache mit unserem Cluster zu interagieren.

Die folgende Abbildung zeigt einen High-Level-Überblick über die Ressourcen, die wir hier haben.

Internet
    │ HTTP:80
    ▼
AWS ALB  (provisioned by AWS LBC from Ingress managed in OpenTofu)
    │
    ▼
kagent UI  (CPU system node, namespace: kagent, port 8080)
    │
kagent Engine ──HTTP──► llama-server.llama-server.svc.cluster.local
                                    │
                                    ▼
                         Llama-Server pod (GPU node, g5.2xlarge)
                           nvidia.com/gpu: 1 (A10G, 24 GB VRAM)
                           EBS gp3-retain PVC (model weights, 100 Gi default)

Wir werden OpenTofu verwenden, um diesen gesamten Stack bereitzustellen, und nutzen die AWS-, Kubernetes- und Helm-Provider für die Ressourcen. kagent und llama-server werden über den Helm-Provider und ihre jeweiligen Helm-Charts bereitgestellt.

Wenn du nur ein KI-Modell in deinem Cluster haben möchtest, kannst du dir das gesamte kagent-Setup sparen und nur den llama-server bereitstellen.

Wie bringt man dieses Setup zum Laufen?

Du findest den notwendigen Code hier.

Voraussetzungen

Wir verwenden OpenTofu, um diesen Stack auf AWS bereitzustellen, da dies der einfachste Weg ist, um für ein Beispiel zu einem vernünftigen Preis Zugriff auf einen Kubernetes-Cluster und GPU-Nodes zu erhalten.

Wir benötigen einige Ressourcen in AWS, um mit OpenTofu zu starten, z. B. einen Bucket für den State und eine DynamoDB-Tabelle für den Lock-State.

1BUCKET=my-kagent-tfstate   # muss global eindeutig sein
2TABLE=my-kagent-tflock
3REGION=us-east-1
4
5aws s3api create-bucket --bucket $BUCKET --region $REGION
6
7aws s3api put-bucket-versioning \
8  --bucket $BUCKET \
9  --versioning-configuration Status=Enabled
10
11aws s3api put-bucket-encryption \
12  --bucket $BUCKET \
13  --server-side-encryption-configuration \
14    '{"Rules":[{"ApplyServerSideEncryptionByDefault":{"SSEAlgorithm":"AES256"}}]}'
15
16aws dynamodb create-table \
17  --table-name $TABLE \
18  --attribute-definitions AttributeName=LockID,AttributeType=S \
19  --key-schema AttributeName=LockID,KeyType=HASH \
20  --billing-mode PAY_PER_REQUEST \
21  --region $REGION

Erstelle die Backend-Konfiguration und passe sie an deine Bedürfnisse an

1cp infra/backend.hcl.example infra/backend.hcl
2# Bearbeite infra/backend.hcl — setze bucket und dynamodb_table auf die obigen Werte.

Initialisieren und Erzeugen der Provider-Lock-Datei

1cd infra
2tofu init -backend-config=backend.hcl
3
4# Erzeuge die Lock-Datei und committe sie (einmalig oder nach Provider-Upgrades).
5tofu providers lock \
6-platform=linux_amd64 \
7-platform=linux_arm64 \
8-platform=darwin_arm64 \
9-platform=darwin_amd64
10git add .terraform.lock.hcl && git commit -m "chore: add provider lock file"

Zugriff auf den API-Endpunkt einschränken (empfohlen)

Der öffentliche EKS-API-Endpunkt ist standardmäßig auf 0.0.0.0/0 eingestellt. Da wir nicht möchten, dass jeder darauf zugreifen kann, beschränken wir den Zugriff auf unsere eigene IP und setzen sie auf unsere Egress-IP, bevor wir den Cluster freigeben:

1# Finde deine Egress-IP heraus
2curl -s https://checkip.amazonaws.com
3
4# In infra/terraform.tfvars anpassen
5allowed_public_access_cidrs = ["203.0.113.42/32"]

Plan überprüfen

Wir können den folgenden Befehl verwenden, um zu sehen, was OpenTofu für uns erstellen wird:

1tofu plan -var-file=terraform.tfvars

Nicht alle Ressourcen fallen unter das kostenlose Kontingent (Free Tier) von AWS, daher fallen durch die Bereitstellung Kosten an!

Plan anwenden

Wenn alles gut aussieht, können wir den folgenden Befehl verwenden, um OpenTofu alle benötigten Ressourcen erstellen zu lassen:

1tofu apply -var-file=terraform.tfvars

Das Deployment kann eine ganze Weile dauern, also sei geduldig und hol dir einen Kaffee.

Auf deine Ressourcen zugreifen

Du kannst dein lokales kubectl mit diesem Befehl für den Cluster-Zugriff konfigurieren und die URL für den Zugriff auf kagent abrufen:

1$(tofu output -raw kubeconfig_command)
2
3# ALB-Hostname (~60 Sek. nach dem Apply, bis AWS ihn bereitgestellt hat)
4tofu output kagent_ui_hostname

Jetzt kannst du auf die bereitgestellte URL zugreifen und die kagent-UI überprüfen oder mit dem normalen kubectl prüfen, ob der llama-server bereitgestellt ist und die GPU nutzt:

1$(tofu output -raw kubeconfig_command)
2
3# Alle Nodes bereit — GPU-Nodes zeigen nvidia.com/gpu=true
4kubectl get nodes -L nvidia.com/gpu,workload-type,role
5
6# Llama-server auf einem GPU-Node
7kubectl get pods -n llama-server -o wide
8
9# kagent-Komponenten auf System-Nodes
10kubectl get pods -n kagent -o wide

KI-Modelle hosten

Das Hosten eigener Open-Weight- oder gar Open-Source-Modelle kann schwierig sein, und für viele Unternehmen ist es die damit verbundenen Kosten für die Implementierung und Wartung dieser Ressourcen in einem sich schnell verändernden Umfeld wahrscheinlich nicht wert. Wenn du jedoch keine öffentlichen Dienste nutzen kannst, um Zugriff auf KI-Modelle zu erhalten, kann dies ein Weg sein, um dennoch von KI in deiner Umgebung zu profitieren. Closed-Weight-Modelle schneiden immer noch besser ab, aber Open-Weight-Modelle holen langsam auf – Open Weight vs. Closed Weight Vergleich.

Ausblick: Die Zukunft des agentischen Plattformbetriebs

Der Betrieb von Open-Weight-Modellen im eigenen Haus erfordert anfänglichen Entwicklungsaufwand, aber die Autonomie, die er für die Unternehmensinfrastruktur bringt, ist beträchtlich. Indem du dein maßgeschneidertes LLM-Deployment in ein operatives Runtime-Framework wie kagent einbindest, verlagert sich der Fokus von einfachen Chatbot-Interaktionen hin zu echter agentischer Automatisierung. Plattform- und DevOps-Ingenieure können diese lokalisierten Modelle nutzen, um Live-Cluster-Metriken zu interpretieren, Konfigurationsanomalien aufzuspüren und Fehler in der Plattforminfrastruktur sicher zu beheben – ohne dass auch nur ein einziges Byte sensibler Daten deine Firewall-Grenzen verlässt.

Tipp zur Kostenoptimierung:

Um die Cloud-Kosten in Sandbox- oder Entwicklungsumgebungen niedrig zu halten, kombiniere diese Konfiguration mit Karpenter. Damit kannst du deine teuren GPU-Node-Groups automatisch auf null herunterskalieren, wenn keine aktiven Inferenzanfragen auf deinen Cluster treffen.