Container & Kubernetes

KI-Modelle lokal betreiben: dein Betriebsstack auf eigener Linux-Hardware

Ein Modell per Ollama zu starten dauert zehn Minuten, ein belastbarer Inferenz-Dienst für mehrere Nutzende Wochen. Der Unterschied liegt in GPU-Auslastung, Monitoring und Zugriffsschutz, nicht im Modell selbst.

5 Kapitel mit allen Befehlen
DevOps-Engineer erklärt einem Kollegen Container-Dashboards am Stehtisch
KI-generiertDieses Bild wurde mit KI erzeugt · Yves Hoppe / KI / cmt
Seit 1997 am Markt Präsenz & Live-Online 4,9 aus 503 Google-Bewertungen Auch Inhouse für dein Team
Worum es geht

Warum der Sprung vom Prototyp in den Betrieb schiefgeht

Der Einstieg ist heute niedrig. llama.cpp, Ollama oder vLLM laufen nach kurzer Zeit, ein quantisiertes Modell antwortet, und im Meeting sieht das nach einer fertigen Lösung aus. Sobald aber zwanzig Kolleginnen und Kollegen gleichzeitig Anfragen stellen, kippt das Bild: der Speicher der GPU reicht für den KV-Cache nicht mehr, die Latenz schwankt, und niemand kann sagen, warum. Der Unterschied zwischen einem Demo-Server und einem produktiven Inferenz-Dienst liegt nicht im Modell, sondern im Betriebsstack darunter.

Dazu kommt die Hardware-Frage, die sich schlecht raten lässt. Entscheidend ist zuerst der Videospeicher, denn das Modell muss samt Kontext hineinpassen: grob gerechnet braucht ein Modell in 4-Bit-Quantisierung etwa halb so viele Gigabyte wie es Milliarden Parameter hat, dazu der KV-Cache, der mit Kontextlänge und Zahl paralleler Anfragen wächst. Erst danach werden Speicherbandbreite, PCIe-Anbindung, NVLink zwischen mehreren Karten und schlicht Netzteil und Kühlung im Rack relevant. Wer nur auf die Rechenleistung schaut, kauft am Bedarf vorbei.

Typische Fehler wiederholen sich: Treiber und Container-Toolkit werden per Hand installiert und beim nächsten Kernel-Update zerlegt es das Setup, weil DKMS oder Secure Boot nicht bedacht wurden. Modelle liegen unversioniert im Home-Verzeichnis statt in einer Registry. Es gibt keine Metriken zu Tokens pro Sekunde, GPU-Auslastung und Queue-Tiefe, also auch keine Grundlage für Kapazitätsplanung. Und der Datenschutzvorteil, wegen dem der ganze Aufwand betrieben wird, verpufft, wenn der Dienst ohne Authentifizierung, ohne Netzwerksegmentierung und ohne Protokollierung im Firmennetz hängt.

Miniatur-Szene: Hafen mit gestapelten Containern, ein Kran hebt einen davon an, daneben ein Steuerrad
KI-generiertDieses Bild wurde mit KI erzeugt · Yves Hoppe / KI / cmt

Der Stack für lokale KI-Modelle von unten nach oben

  1. 01 GPU und Serverhardware
  2. 02 Kernel, Treiber, CUDA
  3. 03 Container-Laufzeit
  4. 04 Serving-Engine
  5. 05 Orchestrierung und API
  6. 06 Monitoring und Absicherung
Was du mitnimmst

So sieht ein tragfähiger Stack für lokale KI-Modelle aus

Der Weg ist in der Praxis immer der gleiche, nur die Ausbaustufe unterscheidet sich. Von unten nach oben: Hardware, Treiber, Container-Laufzeit, Serving-Schicht, Orchestrierung, Beobachtbarkeit. Jede Ebene hat eigene Entscheidungen und eigene Stolpersteine.

Hardware am Modell dimensionieren, nicht umgekehrt

Rechne vom Zielmodell rückwärts: Parameterzahl, Quantisierung, gewünschte Kontextlänge und die Zahl gleichzeitiger Anfragen ergeben den nötigen VRAM. Erst dann entscheidest du zwischen einer großen Karte, mehreren kleinen mit Tensor-Parallelismus oder einem gemieteten Testsystem für die Vorabmessung. Denke Strom, Abwärme und Einbautiefe von Anfang an mit.

Treiberschicht reproduzierbar aufsetzen

NVIDIA-Treiber, CUDA-Runtime und das Container-Toolkit gehören in die Automatisierung, typischerweise per Ansible oder als Teil des Images. Achte auf DKMS beziehungsweise kABI-getrackte Pakete, auf signierte Module bei aktivem Secure Boot und auf ein Update-Fenster, in dem Kernel und Treiber gemeinsam getestet werden. Auf Kubernetes-Knoten übernimmt der GPU Operator einen Teil dieser Arbeit.

Serving-Engine passend zur Last wählen

Für einzelne Nutzer und Experimente genügen Ollama oder llama.cpp. Sobald mehrere Anfragen parallel laufen, spielen vLLM, TGI oder SGLang ihre Stärken aus, weil sie Continuous Batching und PagedAttention beherrschen und den KV-Cache deutlich effizienter verwalten. Beide Welten sprechen eine OpenAI-kompatible API, der Wechsel ist also kein Bruch für die Anwendungen.

Modelle wie Artefakte behandeln

Gewichte gehören versioniert abgelegt, mit Prüfsumme, dokumentierter Lizenz und einem definierten Weg ins Rechenzentrum. In abgeschotteten Umgebungen brauchst du eine Spiegel-Registry und einen Prozess für den Import, sonst blockiert die erste Aktualisierung wochenlang. Container-Images für die Serving-Schicht durchlaufen dieselbe Signatur- und Scan-Kette wie jede andere Anwendung.

Orchestrierung nur dort, wo sie sich rechnet

Ein einzelner Host mit Podman oder Docker Compose ist eine völlig legitime Lösung und spart viel Komplexität. Kubernetes lohnt sich, sobald du mehrere Knoten, Autoscaling, Mandantentrennung oder mehrere Modelle nebeneinander brauchst. Dann werden GPU-Scheduling, Node-Labels, Ressourcen-Limits und Model Serving über KServe zum eigentlichen Thema.

Messen, absichern, dokumentieren

Exportiere GPU-Metriken über DCGM nach Prometheus, visualisiere Latenz, Tokens pro Sekunde und Auslastung in Grafana und lege Alarme auf Speicherdruck und Queue-Tiefe. Sichere die API mit Authentifizierung und Netzwerksegmentierung ab und halte fest, welche Daten wie lange protokolliert werden. Genau das ist am Ende dein Datenschutz- und Souveränitätsargument gegenüber der Cloud.

Tutorial

Vom Modell-Download zum überwachten Inferenz-Dienst

Dieser Teil geht den Weg in der Reihenfolge, in der er im Betrieb tatsächlich anfällt: erst das Speicherbudget rechnen, dann die Treiberschicht reproduzierbar aufsetzen, danach die Serving-Engine als systemd-Dienst betreiben und absichern, zuletzt messen. Alle Befehle laufen auf einem einzelnen Linux-Server mit NVIDIA-Karte, weil dort die meisten Aufbauten starten und scheitern.

01

Zuerst rechnen: Wie viel VRAM zieht das Modell wirklich?

Die häufigste Fehlplanung besteht darin, den Speicherbedarf nur an der Modellgröße festzumachen. Die Gewichte sind der leicht berechenbare Teil, den Rest holen sich Kontextfenster und gleichzeitige Anfragen.

Die Gewichte belegen Parameterzahl mal Bytes je Parameter. In FP16 oder BF16 sind das zwei Byte, bei 8-Bit-Quantisierung eines, bei 4-Bit-Quantisierung etwa ein halbes. Dazu kommt der KV-Cache, der mit Kontextlänge und Zahl gleichzeitiger Anfragen wächst, plus Reserve für die Laufzeit. Rechne die Gewichte exakt und plane für den Rest großzügig.

Grober Bedarf der reinen Gewichte

QuantisierungBytes je Parameter8 Mrd. Parameter70 Mrd. Parameter
FP16 / BF162rund 16 GBrund 140 GB
8 Bit1rund 8 GBrund 70 GB
4 Bitetwa 0,5rund 4,5 GBrund 40 GB
Was die Karte hergibt und was gerade belegt ist
nvidia-smi --query-gpu=index,name,memory.total,memory.used,utilization.gpu,power.draw --format=csv

# Welcher Prozess hält wie viel VRAM?
nvidia-smi --query-compute-apps=pid,process_name,used_memory --format=csv

# Persistenzmodus an: der Treiber bleibt geladen, das spart Anlaufzeit
sudo nvidia-smi -pm 1

memory.total ist nicht dein Budget. Ziehe Reserve für Laufzeit und Fragmentierung ab und plane die Karte nicht bis zum letzten Gigabyte voll, sonst bricht der Dienst genau dann ab, wenn die Last steigt.

02

Treiber und Container-Laufzeit reproduzierbar aufsetzen

Die GPU-Schicht ist der Teil, der nach einem Kernel-Update ausfällt, wenn er von Hand zusammengesteckt wurde. Baue sie einmal über die Paketverwaltung und DKMS, dann überlebt sie Updates.

Treiber installieren und kontrollieren
# RHEL / Rocky / Alma: Bauvoraussetzungen und das CUDA-Repo von NVIDIA
sudo dnf install -y epel-release dkms kernel-devel-$(uname -r)
sudo dnf config-manager --add-repo \
  https://developer.download.nvidia.com/compute/cuda/repos/rhel9/x86_64/cuda-rhel9.repo
sudo dnf install -y nvidia-driver nvidia-driver-cuda

# Debian / Ubuntu
ubuntu-drivers devices              # zeigt die empfohlene Treiberserie
sudo apt install -y nvidia-driver-<serie>-server

# Nach dem Neustart prüfen
nvidia-smi
dkms status
lsmod | grep -E 'nvidia|nouveau'

lsmod darf nouveau nicht mehr anzeigen, die Sperre trägt der Paketinstaller normalerweise selbst ein. dkms status muss für jeden installierten Kernel installed melden, sonst ist die GPU nach dem nächsten Kernel-Update weg.

GPU in Container durchreichen
# Docker
sudo nvidia-ctk runtime configure --runtime=docker
sudo systemctl restart docker

# Podman über CDI
sudo nvidia-ctk cdi generate --output=/etc/cdi/nvidia.yaml
nvidia-ctk cdi list
podman run --rm --device nvidia.com/gpu=all <dein-image> nvidia-smi

Die CDI-Datei bildet die Gerätedateien des aktuell geladenen Treibers ab. Erzeuge sie nach jedem Treiberwechsel neu, sonst startet der Container mit der Meldung, dass ein Gerät fehlt, obwohl nvidia-smi auf dem Host einwandfrei läuft.

03

Die Serving-Engine als Dienst betreiben, nicht in einer Terminal-Sitzung

Ollama und vLLM lösen unterschiedliche Aufgaben. Ollama ist stark, wenn viele verschiedene Modelle bequem verfügbar sein sollen. vLLM nimmst du, wenn mehrere Leute gleichzeitig anfragen und der Durchsatz zählt.

Ollama über eine systemd-Ergänzung konfigurieren
sudo systemctl edit ollama

# /etc/systemd/system/ollama.service.d/override.conf
[Service]
Environment="OLLAMA_HOST=127.0.0.1:11434"
Environment="OLLAMA_MODELS=/srv/modelle"
Environment="OLLAMA_KEEP_ALIVE=30m"
Environment="OLLAMA_NUM_PARALLEL=2"

sudo systemctl daemon-reload
sudo systemctl restart ollama
systemctl show ollama -p Environment

OLLAMA_MODELS legt die Gewichte auf ein eigenes Dateisystem, damit dir das Wurzeldateisystem nicht volläuft. OLLAMA_KEEP_ALIVE bestimmt, wie lange ein Modell nach der letzten Anfrage im VRAM bleibt: zu kurz bezahlt jede Anfrage die Ladezeit, zu lang blockiert das Modell die Karte für alles andere.

vLLM mit ausdrücklichen Grenzen starten
vllm serve /srv/modelle/<modellverzeichnis> \
  --served-model-name intern-chat \
  --host 127.0.0.1 --port 8000 \
  --api-key "$VLLM_API_KEY" \
  --max-model-len 8192 \
  --gpu-memory-utilization 0.90 \
  --tensor-parallel-size 2

# Gegenprobe
curl -s localhost:8000/v1/models -H "Authorization: Bearer $VLLM_API_KEY"

--gpu-memory-utilization legt fest, welchen Anteil des VRAM die Engine für Gewichte und KV-Cache belegen darf, --max-model-len deckelt die Kontextlänge. --tensor-parallel-size verteilt ein Modell auf mehrere Karten und lohnt sich nur, wenn die Karten schnell genug miteinander verbunden sind.

Behandle die Gewichte wie jedes andere Artefakt: feste Version im Pfad, Prüfsumme daneben, kein Download aus dem laufenden Dienst heraus. Ein sha256sum beim Einspielen und ein Abgleich beim Start kosten nichts und beantworten später zuverlässig die Frage, welches Modell an einem bestimmten Tag geantwortet hat.

04

Zugriff absichern, bevor der erste Fachbereich anklopft

Der Endpunkt geht nie direkt ins Netz. Davor gehört ein Reverse-Proxy, der Authentifizierung, TLS und Begrenzungen übernimmt, und daneben die Antwort auf die Frage, was mit den Eingaben passiert.

/etc/nginx/conf.d/inferenz.conf
server {
    listen 443 ssl;
    server_name ki.intern.example;

    ssl_certificate     /etc/pki/tls/certs/ki.intern.example.crt;
    ssl_certificate_key /etc/pki/tls/private/ki.intern.example.key;

    location /v1/ {
        auth_basic           "Inferenz";
        auth_basic_user_file /etc/nginx/inferenz.htpasswd;

        proxy_pass http://127.0.0.1:8000;
        proxy_buffering off;        # sonst kommt das Streaming blockweise an
        proxy_read_timeout 300s;    # lange Antworten nicht abschneiden
    }
}

proxy_buffering off ist die Zeile, an der die meisten Aufbauten scheitern. Ohne sie sammelt nginx die Token und liefert sie in Blöcken aus, die Anwendung wirkt träge, obwohl das Modell längst schreibt. Basic Auth reicht intern für den Anfang, für mehr Nutzende gehört ein Token- oder OIDC-Gateway davor.

Bevor der Dienst freigegeben wird

  • Die Engine lauscht auf 127.0.0.1, nicht auf 0.0.0.0.Jede Engine ohne eigene Anmeldung ist im Netz ein offener Dienst. Die Bindung an die Loopback-Adresse ist die Schutzschicht, die auch dann noch hält, wenn eine Firewall-Regel versehentlich verschwindet.
  • Der GPU-Server steht in einem eigenen Netzsegment mit ausdrücklichen Freigaben.Ein Inferenz-Server hat viel Rechenleistung und meist weite Sicht ins Netz. Beides ist attraktiv für alles, was sich seitlich durch eine Umgebung bewegen will.
  • Prompts und Antworten werden nur protokolliert, wenn Zweck und Löschfrist feststehen.Eingaben aus Fachbereichen enthalten regelmäßig personenbezogene Daten. Ein Logfile mit vollständigen Prompts ist damit eine eigene Verarbeitung nach DSGVO und gehört mit Zweck, Rechtsgrundlage und Löschkonzept ins Verarbeitungsverzeichnis.
  • Es gibt eine Obergrenze je Aufrufer.Eine einzige Schleife in einem Testskript belegt sonst die gesamte Karte, und alle anderen bekommen Zeitüberschreitungen statt Antworten. Die Begrenzung setzt du im Proxy, nicht in der Anwendung.
  • Der Betrieb ist dokumentiert: Modellstand, Zweck, Zuständigkeit, technische Maßnahmen.Dass die Daten das Haus nicht verlassen, ist ein starkes Argument, ersetzt aber keine Dokumentation. Ohne beschriebene Zwecke, Rollen und Maßnahmen fehlt der Nachweis, den Datenschutzbeauftragte und Auditoren sehen wollen.
05

Messen, damit du die Grenzen vor den Nutzenden kennst

Ohne Zahlen bleibt jede Aussage zur Kapazität ein Gefühl. Drei Quellen reichen: die Karte selbst, die Metriken der Engine und ein Lasttest mit realistischen Anfragen.

Kennzahlen abgreifen
# Live-Blick auf Auslastung, Speicher, Takt und Leistungsaufnahme
nvidia-smi dmon -s pucm

# vLLM liefert Prometheus-Metriken direkt aus
curl -s localhost:8000/metrics | grep -E 'vllm:(num_requests|time_to_first_token|generation_tokens)'

# Für Prometheus im Cluster: dcgm-exporter stellt GPU-Metriken auf Port 9400 bereit
curl -s localhost:9400/metrics | head

nvidia-smi dmon zeigt je Sekunde eine Zeile und beantwortet die wichtigste Frage: Rechnet die Karte oder wartet sie auf Daten? Eine GPU-Auslastung von 30 Prozent bei spürbaren Wartezeiten heißt fast immer, dass Anfragen einzeln statt gebündelt verarbeitet werden.

Was du messen musst und wann es weh tut

KennzahlQuelleSchwelle setzen, wenn
Zeit bis zum ersten TokenMetriken der Enginedie Wartezeit deutlich über dem Wert aus dem Lasttest liegt
Tokens je SekundeMetriken der Engineder Durchsatz unter realer Last einbricht
Länge der WarteschlangeMetriken der Enginedie Schlange dauerhaft nicht mehr leer läuft
Belegter VRAMnvidia-smi, dcgm-exporterdauerhaft über 90 Prozent des verfügbaren Speichers
Temperatur und Leistungsaufnahmenvidia-smi, dcgm-exporterder Takt sinkt, die Karte drosselt also bereits
Gut zu wissen

Häufige Fragen zu lokalem KI-Betrieb

Noch etwas offen? Wir sind ohne Warteschleife für dich da.

Frag uns direkt
Welche GPU brauche ich, um ein Sprachmodell lokal zu betreiben?
Ausschlaggebend ist der Videospeicher. Als Faustregel belegt ein Modell in 4-Bit-Quantisierung ungefähr halb so viele Gigabyte, wie es Milliarden Parameter hat, dazu kommt der KV-Cache, der mit Kontextlänge und parallelen Anfragen wächst. Ein Modell mit 8 Milliarden Parametern läuft damit auf einer Karte mit 16 GB komfortabel, für 70 Milliarden Parameter brauchst du in der Regel mehrere Karten oder aggressive Quantisierung.
Reicht ein einzelner Server oder brauche ich Kubernetes?
Für ein Modell, eine überschaubare Nutzerzahl und ein Team, das den Host ohnehin betreut, ist ein einzelner Linux-Server mit Podman oder Docker die pragmatischere Wahl. Kubernetes wird sinnvoll, wenn mehrere Modelle nebeneinander laufen, GPUs über mehrere Knoten verteilt geplant werden müssen oder Abteilungen sauber getrennt gehören. Der Preis dafür ist zusätzliche Betriebskomplexität, die jemand tragen muss.
Ist ein lokal betriebenes Modell automatisch DSGVO-konform?
Nein. Der Betrieb im eigenen Rechenzentrum löst die Frage der Auftragsverarbeitung und des Drittlandtransfers, aber Zugriffskontrolle, Protokollierung, Löschfristen und die Rechtsgrundlage für die verarbeiteten Inhalte musst du weiterhin selbst regeln. Dazu kommt die Lizenz der Modellgewichte, die nicht bei jedem sogenannten offenen Modell eine uneingeschränkte kommerzielle Nutzung erlaubt.
Was ist der Unterschied zwischen Ollama und vLLM?
Ollama ist auf schnellen Einstieg und Einzelnutzung ausgelegt, verwaltet Modelle bequem und läuft auch auf bescheidener Hardware. vLLM ist eine Inferenz-Engine für den Serverbetrieb und holt über Continuous Batching und PagedAttention bei vielen parallelen Anfragen deutlich mehr Durchsatz aus derselben GPU. Da beide eine OpenAI-kompatible Schnittstelle anbieten, lässt sich später wechseln, ohne die Anwendungen umzuschreiben.
Wie überwache ich GPU-Auslastung und Antwortzeiten im Betrieb?
Der übliche Weg ist der DCGM-Exporter, der Auslastung, Speicherbelegung, Temperatur und Taktdrosselung als Prometheus-Metriken bereitstellt. Die Serving-Engines liefern zusätzlich Metriken zu Tokens pro Sekunde, Warteschlangenlänge und Time to First Token. In Grafana zusammengeführt ergibt das die Grundlage für Alarme und für die Frage, ob eine weitere Karte nötig ist.

Zuletzt geprüft am 26. Juli 2026.

Das sagen Teilnehmer

Echte Stimmen aus unseren IT-Kursen

Für den Einsteigerkurs ganz gut umgesetzt. Passt soweit und kann man ohne Bedenken weiter empfehlen.
Rückmeldung aus dem Kurs „Linux Grundkurs (LPI01)“
Der Trainer konnte die Inhalte sehr gut vermitteln. Ich habe dabei viel gelernt.
Rückmeldung aus dem Kurs „Monitoring mit Prometheus und Grafana - Grundkurs“
Persönlich für dich da

Deine Ansprechpartner

Du bist dir nicht sicher, welcher Kurs oder welches Level zu dir passt? Wir beraten dich persönlich und kostenlos.

Yves Hoppe

Yves Hoppe

Weiterbildung & Beratung

Hilft dir, aus dem Linux-Programm den passenden Kurs oder Lernpfad zu finden.

Norbert Jansen

Norbert Jansen

Beratung & Inhouse

Plant mit dir Inhouse-Trainings, die exakt auf eure Systemlandschaft und Distributionen zugeschnitten sind.

Nächster Schritt

Du willst den Stack nicht im Produktivbetrieb lernen

Im Kurs "Linux Administration für KI-Workloads mit GPUs" gehen wir Treiberinstallation, Container-Zugriff auf die GPU, Serving und Monitoring an echten Systemen durch. Wenn dein Ziel eher der Weg auf den Cluster ist, passen "KI-Apps containerisieren mit Podman, Docker & Kubernetes" und die KServe-Schulung zum Model Serving besser. Alle Kurse gibt es als Präsenztermin und Live-Online, und wenn du unsicher bist, welche Stufe zu deinem Vorhaben passt, sprich uns an. Wir schauen uns deine Ausgangslage an und sagen dir ehrlich, was du brauchst.