Von einem Container zu Kubernetes: Modelle für echte

In KI & MLOps von Grund aufIch beschrieb meinen 24-Wochen-Plan: ein Notebook, dann ein getestetes Paket, eine verfolgte Pipeline, eine API mit FastAPI, einen Container und schließlich eine Bereitstellung in der Cloud mit Überwachung.

Ein Container ist ein großer Meilenstein. Aber ein einzelner Container auf einem Laptop ist nicht wie Modelle in Produktion laufen. Dieser Beitrag betrachtet den nächsten Schritt: Was ändert sich, wenn Sie das Modell auf Kubernetes verschieben und was anders ist, wenn das Modell ein großes Sprachmodell ist, das GPUs benötigt.

Wo mein Projekt steht

Das Kernprojekt des Plans ist ein klassisches Modell für maschinelles Lernen: scikit-learn, bedient von FastAPI, verpackt mit Docker. Für diese Art von Modell ist die Bereitstellung von Kubernetes nahe jedem anderen Webdienst. Ein Deployment, ein Service, Gesundheitsprüfungen, Ressourcenanfragen und ein HorizontalPodAutoscaler.

LLM ist eine andere Welt. Die Modelldateien sind Gigabyte groß, sie brauchen GPUs, sie laden langsam und eine Anfrage kann Sekunden dauern. Das ist, wo die interessanten DevOps Probleme sind.

Warum Docker allein nicht mehr ausreicht

Ein einzelner Behälter kann nicht:

• Größenordnung Mit Verkehr, oben oder unten.
• Wieder starten Selbst auf einer anderen Maschine, wenn die Maschine abfällt.
• Ausrollen Eine neue Modellversion wird allmählich eingeführt und wenn die Qualität sinkt, zurückgefahren.
• Teilen teure GPU-Maschinen zwischen Arbeitslasten.

Kubernetes kümmert sich um all das. Das Modell wird zu einer weiteren Arbeitsbelastung, mit denselben Leitungen, Überwachung und Sicherheit wie alles andere.

vLLM, KServe und die anderen Optionen

Der Servierstapel für LLMs auf Kubernetes hat in der Regel zwei Schichten.

Die Schlussfolgerungsmaschine Das Modell läuft tatsächlich:

• VLLM ist die beliebteste Open-Source-Engine. Es ist schnell dank intelligenter Speicherverwaltung und Batching und zeigt eine OpenAI-kompatible API.
• Umarmungsgesicht TGI, SGLang und NVIDIA Triton / TensorRT-LLM sind Alternativen mit unterschiedlichen Stärken.
• - Das ist Ollama. ist großartig für einen Laptop und für kleine Einrichtungen, weniger für starken Produktionsverkehr.

Die Servierplattform verwaltet die Engine auf Kubernetes:

• KServe Sie gibt Ihnen eine InferenceService Ressource: Sie beschreiben das Modell und die Laufzeit, und es behandelt Bereitstellung, Skalierung und Routing, einschließlich Skalierung bis Null.
• Die ist ein neueres Projekt, das sich auf verteilte LLM-Abschlüsse auf Kubernetes konzentriert, mit intelligenter Routing, die Anfragen an die Replik sendet, die wahrscheinlich die richtigen Daten im Cache haben.
• Oder einfach nur ein Einsatz VLLM ausführen, was ein sehr guter Anfang ist.

Eine minimale VLLM-Bereitstellung sieht so aus:

apiVersion: apps/v1
kind: Deployment
metadata:
  name: llm
spec:
  replicas: 1
  selector:
    matchLabels: { app: llm }
  template:
    metadata:
      labels: { app: llm }
    spec:
      containers:
      - name: vllm
        image: vllm/vllm-openai:latest   # pin a specific version in real use
        args: ["--model", "Qwen/Qwen2.5-1.5B-Instruct"]
        ports:
        - containerPort: 8000
        resources:
          limits:
            nvidia.com/gpu: 1
        readinessProbe:
          httpGet: { path: /health, port: 8000 }
          initialDelaySeconds: 60

Einem Model zu dienen, ist die einfache Demo. Die MLOps müssen es zuverlässig, kostengünstig und in großem Maßstab bedienen.

GPUs: Planung und Kosten

GPUs verändern die Ausführung von Kubernetes:

• Geräte-Plugins / GPU-Betreiber. Der NVIDIA GPU Operator installiert Treiber und das Gerätesplugin, damit die Pods die Anfrage stellen können nvidia.com/gpu.
• Dedicated Node Pools (Dedicated Node Pool) - Einrichtung von Netzwerken Die GPU-Workloads landen auf teuren Knoten.
• GPUs gemeinsam nutzen mit MIG (GPU-Spaltung in isolierte Teile) oder Zeitspaltung für kleinere Modelle.
• Dynamische Ressourcenzuteilung (DRA), jetzt stabil in Kubernetes, bietet eine flexiblere Möglichkeit, bestimmte Arten von GPUs und Geräten anzufordern.

Und Kosten: Ein untätiges GPU-Knoten kann mehr pro Tag kosten als eine ganze kleine Webanwendung pro Monat. Die Überwachung der GPU-Nutzung (der DCGM-Exporteur für Prometheus) ist nicht optional.

Skalierung nach Bedarf

CPU-basierte Autoskalierung funktioniert nicht gut für LLMs. Eine GPU kann vollständig beschäftigt sein, während die CPU inaktiv ist. Bessere Signale:

• Warteschlangenlänge oder anstehende Anfragen in der Schlußmaschine.
• Token pro Sekunde oder Zeit zum ersten Zeichen.
• KEDA kann auf diese Metriken von Prometheus skalieren.

Auch planen Langsamer Start- Ich weiß . Das Herunterladen und Laden eines Modells kann Minuten dauern. Das Caching von Modelldateien auf einem persistenten Volume oder Knotenlokalspeicher und die Aufbewahrung von mindestens einer warmen Replik macht das Skalieren viel schmerzfreier.

Was kommt als nächstes in der Serie?

Als nächstes auf meiner Liste: Überwachung des Modells in Produktion, einschließlich der Qualität seiner Antworten, nicht nur seiner Betriebszeit. Da kommen Werkzeuge wie Prometheus, Grafana und Evidently ins Spiel.

Meine Meinung: Kubernetes macht KI nicht einfach, aber es lässt KI-Workloads wie den Rest Ihrer Infrastruktur aussehen. Und das ist die halbe Schlacht.

Desly