Modelle auf eigener Hardware auszuführen, ist spätestens seit 2024 keine Bastler-Nische mehr, sondern eine gängige Ingenieursentscheidung. Datenschutzvorgaben, Kosten pro Token, Latenz und Offline-Anforderungen treiben Teams zur lokalen Inferenz. Doch „lokale KI“ umfasst drei grundverschiedene Werkzeuge: Ollama, vLLM und Docker Model Runner: und die falsche Wahl kostet Wochen. Dieser Leitfaden vergleicht sie ehrlich: wofür jedes Tool gedacht ist, wo es versagt, und liefert einen Entscheidungsrahmen, den Sie am Montag anwenden können.
Was Sie am Ende entschieden haben werden
- Ob lokale Inferenz für Ihre Arbeitslast überhaupt die richtige Wahl ist
- Ollama für Laptops und schnelles Prototyping
- vLLM für produktives Hochdurchsatz-Serving auf GPUs
- Docker Model Runner für container-native, OCI-verpackte Modelle
- Wie Sie Hardware dimensionieren und die klassische VRAM-Falle vermeiden
Info
Warum überhaupt lokal?
Drei ehrliche Gründe: Daten, die Ihr Netzwerk rechtlich nicht verlassen dürfen, vorhersagbare Kosten bei hohem Volumen und niedrige Latenz beziehungsweise Offline-Fähigkeit. Trifft nichts davon zu, ist eine gehostete API meist günstiger und weniger aufwendig. Seien Sie ehrlich zu sich selbst, in welchem Lager Sie stehen, bevor Sie in GPUs investieren.
Die drei Werkzeuge im Überblick
Sie sind weniger Konkurrenten als vielmehr Werkzeuge für unterschiedliche Aufgaben. Sie zu verwechseln, ist die Wurzel der meisten schlechten Entscheidungen im Bereich lokaler KI.
Ollama ▸ Single-machine, dev-friendly, "brew install and go"
Best for: laptops, prototypes, single-user tools
vLLM ▸ GPU inference server built for throughput & concurrency
Best for: production serving, many concurrent users
Docker Model Runner ▸ Run models as OCI artifacts in your container workflow
Best for: teams standardised on Docker/Kubernetes| Dimension | Ollama | vLLM | Docker Model Runner |
|---|---|---|---|
| Am besten für | Laptops & Prototyping | Hochdurchsatz-Serving | Container-native Teams |
| Nebenläufigkeit | Niedrig (Einzelnutzer) | Hoch (Continuous Batching) | Hängt von der Laufzeitumgebung ab |
| Einrichtungsaufwand | Minimal | Mittel (GPU-Operationen) | Gering, wenn Docker bereits genutzt wird |
| Hardware | Laptop / einzelne GPU | Echte GPUs | Überall, wo Docker läuft |
| API | OpenAI-kompatibel | OpenAI-kompatibel | Docker-Workflow / OCI |
Ollama: der Standard für Entwickler-Laptops
Ollama ist der einfachste Einstieg in lokale Modelle. Eine Installation, ein Befehl, und Sie haben ein chatfähiges Modell sowie einen OpenAI-kompatiblen Endpunkt auf localhost. Es kümmert sich um Modelldownloads, Quantisierungsformate und Speicherverwaltung und läuft problemlos auf dem Unified Memory eines MacBook oder einer bescheidenen GPU.
# Install, pull a model, and chat — three lines.
curl -fsSL https://ollama.com/install.sh | sh
ollama pull llama3.3
ollama run llama3.3
# It also serves an OpenAI-compatible API on localhost:11434
curl http://localhost:11434/v1/chat/completions \
-d '{"model":"llama3.3","messages":[{"role":"user","content":"hi"}]}'✓ Vorteile
- Triviale Einrichtung; hervorragende Entwicklererfahrung
- OpenAI-kompatible API ermöglicht einfache App-Integration
- Hervorragend auf Apple Silicon und einzelnen GPUs
- Riesige Bibliothek sofort nutzbarer quantisierter Modelle
✕ Nachteile
- Für eine einzelne Maschine gebaut, nicht für hochgradig nebenläufiges Serving
- Durchsatz bricht bei vielen gleichzeitigen Anfragen ein
- Weniger Kontrolle über Batching und GPU-Speicher-Tuning
- Nicht das, was Sie hinter einem stark frequentierten Produktionsendpunkt haben wollen
Tipp
Nutzen Sie Ollama zum Prototyping, nicht zum Skalieren
Es ist das perfekte Werkzeug, um zu validieren, dass ein lokales Modell für Ihre Aufgabe gut genug ist. Verwechseln Sie nur nicht „funktioniert super auf meinem Laptop“ mit „bereit, tausend Nutzer zu bedienen“: das ist vLLMs Job.
vLLM: Produktionsdurchsatz
vLLM ist eine Serving-Engine, die für eines konstruiert wurde: die meisten Tokens pro Sekunde aus Ihren GPUs herauszuholen, während sie viele gleichzeitige Anfragen bearbeitet. Seine Haupttechniken: Continuous Batching und PagedAttention: erlauben es, weit mehr gleichzeitige Anfragen auf eine GPU zu packen als naives Serving, genau das, was Sie hinter einer echten API brauchen.
pip install vllm
# Serve a model with an OpenAI-compatible endpoint, tuned for throughput.
vllm serve meta-llama/Llama-3.3-70B-Instruct \
--tensor-parallel-size 2 \
--max-model-len 8192 \
--gpu-memory-utilization 0.90✓ Vorteile
- Modernster Durchsatz durch Continuous Batching
- Effiziente KV-Cache-Speichernutzung mit PagedAttention
- Skaliert über mehrere GPUs (Tensor-Parallelität)
- OpenAI-kompatibler Server passt in bestehende Clients
✕ Nachteile
- Braucht echte GPUs: kein Laptop-Werkzeug
- Mehr Konfigurations- und Betriebswissen erforderlich
- Overkill für Einzelnutzer oder geringes Volumen
- Kapazitätsplanung, Autoscaling und Monitoring liegen bei Ihnen
höherer gleichzeitiger Durchsatz durch Continuous Batching im Vergleich zu einem Serving, das Anfragen einzeln abarbeitet
Docker Model Runner: container-native Modelle
Docker Model Runner behandelt Modelle als vollwertige OCI-Artefakte: Sie pullen und starten ein Modell ähnlich wie ein Container-Image, und es integriert sich in die Docker-Tooling- und Compose-Workflows, die Ihr Team bereits nutzt. Für Organisationen, die auf Container standardisiert sind, bedeutet das, dass Modelle in derselben Registry, Versionierung und Deployment-Pipeline leben wie alles andere, was einen echten betrieblichen Gewinn darstellt.
# Models as OCI artifacts, managed through the Docker workflow.
docker model pull ai/llama3.3
docker model run ai/llama3.3 "Explain paged attention in one sentence."
# Wire it into Compose alongside your app services.
docker model list✓ Vorteile
- Modelle versioniert und verteilt wie Container-Images
- Fügt sich nahtlos in bestehende Docker/Compose/Registry-Workflows ein
- Konsistente Paketierung von lokal über CI bis Produktion
- Reduziert die betriebliche Frage „Wo lebt das Modell?“
✕ Nachteile
- Jüngstes der drei: Ökosystem noch in der Reifephase
- Nur dann die beste Wahl, wenn Sie bereits voll auf Docker setzen
- Serving-Leistung hängt von der zugrunde liegenden Laufzeitumgebung ab
- Weniger Stellschrauben als eine dedizierte Engine wie vLLM
Der Entscheidungsrahmen
Reduzieren Sie es auf die Frage, die jedes Werkzeug am besten beantwortet:
Prototyping oder Einzelnutzer auf einem Laptop?
Nutzen Sie Ollama. Sie sind in Minuten produktiv und können Modelle frei austauschen.
Serving für viele gleichzeitige Nutzer auf GPUs?
Nutzen Sie vLLM. Durchsatz und Speichereffizienz sind seine gesamte Daseinsberechtigung.
Auf Container standardisiert und Modelle sollen in dieselbe Pipeline?
Nutzen Sie Docker Model Runner, damit Modelle demselben Build-, Registry- und Deployment-Ablauf folgen wie Ihre Services.
Unsicher, ob sich lokal überhaupt lohnt?
Prototypisieren Sie mit Ollama, messen Sie Qualität und Kosten und entscheiden Sie sich erst dann für GPU-Serving, wenn eine gehostete API nachweislich der falsche Kompromiss ist.
Hardware dimensionieren ohne Tränen
Der häufigste Fehler bei lokaler KI ist, den VRAM zu unterschätzen. Eine grobe Faustregel: Ein Modell benötigt etwa seine Parameteranzahl in Bytes mal der Präzision, plus Spielraum für den KV-Cache, der mit Kontextlänge und Gleichzeitigkeit wächst. Ein quantisiertes (4-Bit-)Modell ist weitaus genügsamer als volle Präzision, weshalb Quantisierung beim lokalen Serving die Norm ist.
Warnung
Die VRAM-Falle
Ein „7B-Modell“ klingt klein, bis man merkt, dass Gewichte in voller Präzision plus ein KV-Cache für lange Kontexte und mehrere gleichzeitige Nutzer den Speicher einer Consumer-GPU sprengen können. Planen Sie den KV-Cache ein, nicht nur die Gewichte: er ist es, der unter Last den VRAM tatsächlich erschöpft. Quantisieren Sie und messen Sie mit Ihrer echten Kontextlänge und Gleichzeitigkeit.
Profi-Tipp
Benchmarken Sie immer mit Ihren tatsächlichen Prompts, Kontextlängen und Gleichzeitigkeit: nicht mit der Heldenzahl eines Anbieters. Tokens pro Sekunde bei einem 50-Token-Prompt sagen nichts darüber aus, wie das System bei 6.000 Tokens mit zwanzig Nutzern reagiert. Messen Sie die Arbeitslast, die Sie tatsächlich ausführen werden.
Das Fazit
Lokale KI ist 2026 auf jeder Skala ein gelöstes Problem: Sie müssen nur das Werkzeug zur Aufgabe passend wählen. Greifen Sie zu Ollama zum Erkunden und Prototypisieren, zu vLLM für das Serving im großen Maßstab und zu Docker Model Runner, um Modelle in Ihrem Container-Workflow zu halten. Entscheiden Sie ehrlich, ob Sie überhaupt lokale Inferenz benötigen, dimensionieren Sie Ihren VRAM für echte Last und benchmarken Sie mit Ihrem eigenen Traffic. Wenn Sie das tun, erhalten Sie die Privatsphäre, Kostenkontrolle und Latenz, die Sie ursprünglich zur lokalen Lösung getrieben haben.
! Häufige Fehler, die es zu vermeiden gilt
-
✕VRAM nur für die Modellgewichte dimensionieren.
✓Planen Sie auch den KV-Cache ein: er wächst mit Kontextlänge und Gleichzeitigkeit und ist es, was die GPU normalerweise erschöpft.
-
✕Ollama hinter eine stark frequentierte Produktions-API setzen.
✓Nutzen Sie Ollama zum Prototypisieren; bedienen Sie echte Gleichzeitigkeit mit vLLM, das für Durchsatz gebaut ist.
-
✕Der Helden-Tokens-pro-Sekunde-Zahl eines Anbieters vertrauen.
✓Benchmarken Sie mit Ihren echten Prompts, Kontextlänge und Gleichzeitigkeit, bevor Sie Hardware festlegen.
-
✕Lokal gehen, wenn eine gehostete API günstiger und einfacher wäre.
✓Betreiben Sie lokale Inferenz nur für Privatsphäre, vorhersagbare hohe Volumenkosten oder Offline-/Niedriglatenz-Anforderungen.
? Häufig gestellte Fragen
Ist Ollama gut genug für die Produktion? +
Für Einzelnutzer oder interne Tools mit geringem Volumen ja. Für viele gleichzeitige Nutzer bricht sein Durchsatz ein: dafür ist vLLM gebaut. Nutzen Sie Ollama zum Prototypisieren und zur Qualitätsvalidierung.
Was macht vLLM schneller als naives Serving? +
Kontinuierliches Batching und PagedAttention ermöglichen es, weit mehr gleichzeitige Anfragen auf einer GPU zu packen und den KV-Cache-Speicher effizient zu nutzen, was den Durchsatz drastisch erhöht.
Wie viel GPU-Speicher benötige ich? +
Etwa die Modellgröße bei Ihrer gewählten Präzision (quantisiertes 4-Bit ist weitaus genügsamer als volle Präzision) plus Spielraum für den KV-Cache, der mit Kontextlänge und gleichzeitigen Nutzern skaliert. Messen Sie bei Ihrer echten Arbeitslast.
Kann ich alle drei Werkzeuge zusammen nutzen? +
Ja, und viele Teams tun es: Ollama auf Entwickler-Laptops, vLLM hinter der Produktions-API und Docker Model Runner, um das gewählte Modell konsistent über beide hinweg zu paketieren und zu versionieren.
Bieten diese eine OpenAI-kompatible API an? +
Ollama und vLLM bedienen beide OpenAI-kompatible Endpunkte, sodass der meiste bestehende Client-Code mit kaum mehr als einer Basis-URL-Änderung gegen ein lokales Modell funktioniert.
Erfolg
Mischen und kombinieren
Erfahrene Teams nutzen oft alle drei: Ollama auf Entwickler-Laptops, vLLM hinter der Produktions-API und Docker Model Runner, um das gewählte Modell konsistent zwischen ihnen zu paketieren und auszuliefern. Sie ergänzen sich, statt sich gegenseitig auszuschließen.
Kommentare
0Noch keine Kommentare. Teile als Erste oder Erster deine Gedanken.