Llama Stack: Enterprise-KI-Plattform auf Kubernetes

TL;DR

• Llama Stack ist der Versuch, Generative-AI-Workloads so zu standardisieren, wie Kubernetes Container standardisiert hat: eine gemeinsame API, austauschbare Provider.
• Inference, Vector-IO, Agents, Guardrails und Evaluation werden über dieselbe Schnittstelle angesprochen — Implementierungen (Ollama, vLLM, Chroma, Weaviate, MCP) bleiben austauschbar.
• Distributions bündeln Provider-Sets: lokal starten, später per Konfiguration auf Produktion umschalten — ohne App-Code umzuschreiben.
• MCP-Tool-Groups halten Agent-Code von Tool-Implementierungen entkoppelt — analog zu Inference-Providern.
• Ziel: eigene GenAI-Plattform betreiben, ohne jedes Backend von Grund auf zu verdrahten.

Das Chaos nach dem ersten LLM-Call

Am Anfang wirkt GenAI einfach: ein Call zum lokalen oder Cloud-Modell — fertig Inference. Dann kommen die Enterprise-Anforderungen:

• RAG über Vector-Datenbanken
• Agentic Flows mit API-Calls (häufig über MCP)
• Evaluation, ob die App tut, was sie soll
• Guardrails, damit keine Daten leaken

Jede Schicht bringt vendor-spezifische SDKs mit. Teams verdrahten Ollama lokal, vLLM in Prod, Chroma im PoC, Weaviate später — und die Anwendung kennt jedes Detail. Das skaliert nicht.

Llama Stack zieht die Schichten hinter eine gemeinsame API. Die API weiß nicht, wie Inference läuft — sie definiert, wie man danach fragt. Provider erledigen die Arbeit.

Das Kubernetes-Muster für GenAI

Kubernetes definiert Standards für Container und lässt Runtimes, Storage und CI/CD von Vendors kommen. Llama Stack wiederholt das Muster für Generative AI — nicht nur für Llama-Modelle, sondern für Engines wie Ollama, vLLM und weitere Inference-Provider.

Anwendungscode spricht die Stack-API. Provider und Distributions wechseln per Konfiguration.

# Skizze: Llama Stack als Deployment hinter dem Cluster-Service
apiVersion: apps/v1
kind: Deployment
metadata:
  name: llama-stack
spec:
  replicas: 2
  selector:
    matchLabels:
      app: llama-stack
  template:
    metadata:
      labels:
        app: llama-stack
    spec:
      containers:
        - name: stack
          image: llamastack/distribution-server:latest
          ports:
            - containerPort: 8321
          env:
            - name: INFERENCE_PROVIDER
              value: vllm
            - name: VLLM_URL
              value: http://vllm.inference.svc:8000

Distributions: von Laptop zu Produktion

Distributions sind vorkonfigurierte Provider-Pakete:

• Lokal: Ollama + leichte Vector-DB — schnell starten
• Remote/Cloud: Drittanbieter-APIs per Key — Edge oder Mobile testen
• Enterprise: vLLM auf GPU-Nodes, produktive Vector-DB, Guardrails

Der typische Pfad: lokal mit Ollama entwickeln, in Produktion eine Zeile Konfiguration auf vLLM umstellen — ohne Source-Code der App zu ändern. Hardware-Support und Vertragsbindung entscheiden über das Provider-Set, nicht über Rewrite-Projekte.

Das passt zu Teams, die RAG und Model Serving auf Kubernetes betreiben und Lock-in vermeiden wollen.

Agents und MCP ohne Tool-Spaghetti

Sobald RAG reicht nicht mehr: Agents sollen CRM aktualisieren, Slack posten, Datenbanken abfragen. Llama Stack registriert Tool-Groups, die auf MCP-Server zeigen — analog zu Inference-Providern.

Agent-Workflow
    │
    ├─ Inference-Provider (vLLM)
    ├─ Vector-Provider (Weaviate)
    └─ Tool-Groups
          ├─ MCP: Postgres
          └─ MCP: Slack

Der Agent-Code bleibt von der konkreten Tool-Implementierung entkoppelt. Workflows können Prompt-Chaining, manuelle Orchestrierung oder autonome ReAct-Agents nutzen — die Plattform liefert die Bausteine.

Security-seitig gehören dazu Keyless Identity für MCP-Agents und Identity Chaining — die Stack-API ersetzt keine Zero-Trust-Architektur.

Betrieb auf Kubernetes

Llama Stack läuft lokal mit Docker/Podman und skaliert in den Cluster:

apiVersion: v1
kind: Service
metadata:
  name: llama-stack
spec:
  selector:
    app: llama-stack
  ports:
    - name: http
      port: 8321
      targetPort: 8321
---
# Inference-Backend getrennt betreiben (GPU)
apiVersion: v1
kind: Service
metadata:
  name: vllm
  namespace: inference
spec:
  selector:
    app: vllm
  ports:
    - port: 8000

Empfehlung für Plattform-Teams:

1. Stack und Engine trennen — Llama Stack orchestriert, vLLM inferiert.
2. Distribution versionieren — gleiche API, nachvollziehbare Provider-Pins.
3. Eval und Guardrails von Tag eins mitnehmen — sonst wird Safety zum Nachtrag.
4. Netzwerk-Policies zwischen Stack, Vector-DB und MCP-Servern setzen.

Fazit

Llama Stack ist keine weitere Chat-UI. Es ist der Versuch, Enterprise-GenAI portabel und austauschbar zu machen: eine API, viele Provider, Distributions für Laptop bis Rechenzentrum.

Wer heute Ollama-Demos und morgen GPU-Inference betreibt, spart sich den Rewrite — und kann RAG, Agents und Guardrails auf derselben Plattform wachsen lassen. Auf Kubernetes wird daraus eine betreibbare Schicht über Inference und GPU-Workloads.

FAQ

Nur für Meta-Llama-Modelle? Nein. Die Idee ist provider-agnostisch — Ollama, vLLM und andere Engines sind vorgesehen.

Ersetzt Llama Stack LangChain? Es standardisiert Plattform-APIs; Orchestrator-Frameworks können darüber laufen. Der Wert liegt in austauschbaren Backends, nicht in einem einzigen App-Framework.

Brauche ich Kubernetes zwingend? Nein zum Start (Container reichen). Für Enterprise-Betrieb mit GPU, HA und Policies ist Kubernetes das natürliche Fundament.

Verwandte Artikel

• Kubernetes AI & Machine Learning
• LLM-D: Verteilte Inference auf Kubernetes
• Keyless Identity für MCP-Agents
• Kubernetes AI at Scale