vLLM vs Ollama: Wann sich der Wechsel lohnt

vLLM vs Ollama: Welche Lösung passt zum Einsatz?

Für einen Laptop, einen privaten Assistenten oder einen kleinen internen Dienst, der bereits schnell genug antwortet, bleibt Ollama die passende Wahl. vLLM empfiehlt sich für einen gemeinsam genutzten GPU-Dienst mit dauerhaft gleichzeitigen Anfragen oder wenn sich die verteilte Inferenz gezielt steuern lassen muss. Ein Servername allein ist kein Grund für einen Wechsel.

Ollama bündelt das Herunterladen, Konfigurieren und Bereitstellen von Modellen in einem kompakten Arbeitsablauf. vLLM ist eine Inferenz-Engine, deren Schwerpunkt auf der Planung vieler Anfragen und der Verwaltung des dafür benötigten Arbeitsspeichers liegt. Beide sind nicht das Modell selbst: Beim Wechsel derselben Anwendung zwischen den Engines ändert sich, wie ihr Modell ausgeführt wird.

Für die Entscheidung zählen vier Dinge: die maximale Zahl gleichzeitiger Anfragen, der verfügbare GPU-Speicher, das konkrete Modellartefakt und die zugesagte Antwortlatenz. Die Zahl registrierter Nutzer sagt darüber wenig aus. Ein kleines Entwicklerteam mit Coding-Agenten kann mehr gleichzeitige Arbeit erzeugen als eine deutlich größere Gruppe, die nur gelegentlich Fragen stellt.

Softwarekosten und Dokumentation wurden am 12. Oktober 2026 geprüft. Dieser Vergleich beruht auf der Dokumentation und einer durchgerechneten Kostenanalyse; für den Artikel wurde kein Inferenz-Benchmark durchgeführt. Ollamas aktuelle Preisseite führt die lokale Nutzung als kostenlos auf. Die Projektlizenz von vLLM erlaubt die Nutzung ohne Softwaregebühr. Ollama-Preise, vLLM-Lizenz.

Die Funktionsangaben folgen der offiziellen Ollama-Dokumentation zu parallelen Anfragen, der vLLM-Funktionsübersicht und dem vLLM-Leitfaden zur Skalierung. Die Wertungen sind redaktionelle Einschätzungen dieser dokumentierten Fähigkeiten, keine Rangliste gemessener Geschwindigkeiten.

LLM lokal betreiben: Nutzerzahl, GPUs und Modellgröße abwägen

Die folgenden Situationen helfen bei der Wahl des ersten Testkandidaten. Sie sind keine Kapazitätsgarantien. Mit „Nutzern“ sind hier Menschen oder Agenten gemeint, deren Anfragen sich zeitlich überschneiden; die Bereiche sind Planungsbeispiele. Ein 8B-Modell hat ungefähr acht Milliarden Parameter, also gespeicherte Zahlenwerte, die das Modell definieren.

Die Modellgröße allein reicht für eine GPU-Kaufentscheidung nicht aus. Ein idealisiertes dichtes 8B-Modell mit 4 Bit pro Gewicht benötigt allein für die Gewichte mindestens 4 GB; bei einem 70B-Modell sind es 35 GB. Die Rechnung lautet Parameter × Bits ÷ 8, in dezimalen Bytes. Metadaten der Quantisierung, Tensoren mit höherer Präzision, die Laufzeitumgebung und der Gesprächsspeicher kommen hinzu. Keiner der beiden Werte ist eine VRAM-Empfehlung.

Deshalb ist „Das Modell wurde geladen“ ein schwaches Abnahmekriterium. Die Gewichte können in den Speicher passen, während für die offenen Gespräche der Nutzer trotzdem Platz fehlt. Zuerst lässt sich mit dem Leitfaden zu lokalen Coding-Modellen der passende Checkpoint auswählen; anschließend wird der Betrieb für die erwartete Last ausgelegt.

Installation und Hardware: Ollama erleichtert den Einstieg

Ollama hat den Vorteil, wenn zunächst ein brauchbares Modell auf vorhandener Hardware laufen soll. Desktop-Downloads und Kommandozeile reduzieren die Zahl der Entscheidungen bei der Einrichtung. Für Linux ist dieser Installationsweg dokumentiert:

curl -fsSL https://ollama.com/install.sh | sh
ollama run llama3.2

Falls der Server noch nicht läuft, startet ihn ollama serve. Der Linux-Leitfaden beschreibt außerdem einen Dienst für den Systemstart. Für Anfragen anderer Nutzer eignet sich ein dauerhaft laufender Dienst besser als ein offenes Terminal.

Ollama unterstützt die GPU-Beschleunigung auf Apple-Geräten über Metal, ausgewählte AMD-Hardware über ROCm, NVIDIA-GPUs sowie weitere Windows-/Linux-Geräte über Vulkan. Auf der NVIDIA-Seite wird derzeit Compute Capability 5.0 oder höher vorausgesetzt; die Treiberanforderungen unterscheiden sich bei älteren Karten. Maßgeblich ist der Abgleich der konkreten Karte und des Betriebssystems mit Ollamas Hardwareliste.

vLLM hat den Vorteil, wenn die Installation den Grundstein für eine verwaltete Inferenzumgebung legt. Die aktuelle NVIDIA-Schnellstartanleitung nutzt eine isolierte Python-Umgebung. Mit installiertem uv und einem kompatiblen GPU-Treiber ist folgende Befehlsfolge dokumentiert:

uv venv --python 3.12 --seed
source .venv/bin/activate
uv pip install vllm --torch-backend=auto

Diese Einrichtungsbefehle stammen aus der Dokumentation und wurden für diesen Vergleich nicht ausgeführt. Für AMD und Intel gelten andere Backend-Anleitungen. vLLM-Schnellstart.

Der NVIDIA-Installationsweg von vLLM setzt Linux und Compute Capability 7.5 oder höher voraus. Native Windows-Installationen werden auf diesem Weg nicht unterstützt; die Dokumentation verweist Windows-Nutzer auf WSL. NVIDIA ist jedoch nicht die einzige Hardwareoption: Die Installationsübersicht umfasst auch AMD ROCm, Intel XPU, CPU-Varianten und Apple Silicon über das von der Community gepflegte Plugin vLLM-Metal. GPU-Anforderungen, Installationsübersicht.

Die Apple-Variante verwendet MLX und dafür optimierte Modelle. Sie sollte als eigenes Backend geprüft werden; das Verhalten eines CUDA-Servers lässt sich nicht einfach voraussetzen. Für Arbeitsabläufe auf dem Mac bleibt Ollama der einfachere Einstieg. Geht es vor allem um die Arbeitsumgebung auf dem Desktop, hilft der separate Vergleich von Ollama und LM Studio.

vLLM vs Ollama: Leistung bei parallelen Anfragen

Für dauerhaft gleichzeitige Anfragen ist vLLM die naheliegendere Ausgangswahl, weil seine dokumentierten Scheduling-Funktionen genau diese Last adressieren. Durchsatz bezeichnet die insgesamt erledigte Arbeit pro Zeiteinheit. Das ist etwas anderes als die Frage, wie schnell eine einzelne Antwort erscheint.

vLLM führt Continuous Batching auf, das neue Arbeit aufnimmt, während laufende Anfragen fortschreiten. Hinzu kommt PagedAttention zur Verwaltung des Key/Value-Caches während der Texterzeugung. Dieser meist als KV-Cache bezeichnete Speicher ist der Arbeitsspeicher des Modells für die Token eines Gesprächs. vLLM-Funktionsübersicht.

Chunked Prefill zerlegt das Einlesen eines langen Prompts in kleinere Arbeitspakete, die sich Rechenzeit mit der laufenden Antwortgenerierung teilen können. Prefix Caching verwendet bereits berechnete Ergebnisse für übereinstimmende Prompt-Anfänge erneut, etwa für einen wiederholten System-Prompt. Das beschleunigt die Prompt-Verarbeitung; neue Antwort-Token müssen weiterhin erzeugt werden. Scheduling und Optimierung, Grenzen des Prefix Cachings.

Auch Ollama unterstützt parallele Anfragen

Ollama dokumentiert sowohl parallele Anfragen pro Modell als auch mehrere gleichzeitig geladene Modelle, jeweils im Rahmen des verfügbaren Speichers. OLLAMA_NUM_PARALLEL steuert die parallelen Anfragen, OLLAMA_MAX_LOADED_MODELS die geladenen Modelle. OLLAMA_MAX_QUEUE begrenzt die Warteschlange; ein überlasteter Server kann HTTP 503 zurückgeben. Die aktuelle FAQ nennt für parallele Anfragen den Standardwert 1. Ollama-Einstellungen für parallele Anfragen.

Bei einem kleinen Support-Assistenten kann es bereits reichen, mehr gleichzeitige Anfragen zuzulassen. Eine längere Warteschlange schafft allerdings keine zusätzliche Rechenleistung. Sie kann lediglich dazu führen, dass Kunden länger auf das erste Token warten. Entscheidend ist die angestrebte Antwortzeit, nicht die größte Warteschlange, die der Server akzeptiert.

Langer Kontext kann die Speicherreserve für weitere Nutzer aufbrauchen

Vor dem Vergleich der Engines muss die Kontextlänge ausdrücklich festgelegt werden. Ollamas eigene Seite zur Kontextlänge beschreibt speicherabhängige Standardwerte, während die FAQ weiterhin einen festen Standard nennt. Dieser Widerspruch ist ein weiterer Grund, die tatsächlich wirksamen Einstellungen zu prüfen, statt identische Werte auf Laptop und Server anzunehmen. ollama ps zeigt den geladenen Kontext und die Verteilung auf CPU/GPU an. Ollama-Hinweise zur Kontextlänge.

Eine Beispielkonfiguration mit vier parallelen Gesprächen zu je 8,192 Token reserviert Kapazität für 32,768 Kontext-Token. Gegenüber einem einzelnen Gespräch mit 4,096 Token ist das die achtfache gesamte Kontextkapazität, nicht der achtfache RAM-Bedarf des gesamten Prozesses. Modellgewichte und andere Speicherbelegungen wachsen nicht im selben Verhältnis. Ollamas Dokumentation zu parallelen Anfragen erklärt diesen Kontextmultiplikator.

Auch vLLM stößt an Speichergrenzen. Der Optimierungsleitfaden warnt, dass zu wenig Platz im KV-Cache zu Verdrängung und erneuter Berechnung führen kann, was die Latenz verschlechtert. Mögliche Antworten sind weniger gleichzeitige Sequenzen, kleinere Token-Budgets pro Batch oder zusätzliche GPUs. Ein leistungsfähigerer Scheduler kann keinen Speicher schaffen, den die Maschine nicht hat.

Ein Wechsel ist dann angezeigt, wenn der Dienst trotz sinnvoller Abstimmung unter repräsentativer Spitzenlast seine Zielwerte verfehlt. Gemessen werden sollten die Zeit bis zum ersten Token, die Zeit bis zur vollständigen Antwort, erfolgreiche Anfragen, das Wachstum der Warteschlange und Fehler. Neben dem Median gehört auch ein hohes Perzentil der Antwortzeiten in den Vergleich, denn gerade die langsamen Fälle fallen Nutzern auf. vLLM stellt dafür Metriken für den Produktivbetrieb bereit.

Modellrevision, Präzision, Prompt-Längen, Ausgabelimits und Lastprofil müssen vergleichbar sein. Wer ein kleines quantisiertes Ollama-Modell einem größeren vLLM-Checkpoint mit hoher Präzision gegenüberstellt, vergleicht zwei Bereitstellungen und misst nicht isoliert die Engines.

Quantisierte Formate: Auch das Modell muss den Wechsel mitmachen

Ollama hat bei einem vorhandenen lokalen Modellpaket den Vorteil, vLLM bei der gezielten Wahl eines hardwaregerechten Formats für den Inferenzbetrieb. Quantisierung speichert Modellwerte mit geringerer Präzision und senkt so den Speicherbedarf. Dateicontainer, Quantisierungsverfahren und Ausführungs-Backend werfen jeweils eigene Kompatibilitätsfragen auf.

Ollama dokumentiert den Import von Safetensors-Gewichten sowie von GGUF-Modellen als Einzeldatei oder auf mehrere Dateien verteilt. GGUF ist ein häufig für lokale Inferenz verwendetes Modelldateiformat. Laut aktuellem Ollama-Importleitfaden muss die GGUF-Quantisierung vor dem Import erfolgen, nicht währenddessen. Die Create-API nennt separat nvfp4 als Beispiel für Quantisierung beim Import. Daraus folgt keine Zusage, dass jede Architektur und jede GPU diesen Weg unterstützt. Ollama-Importleitfaden, Create-API.

Für den KV-Cache nennt Ollama außerdem f16, q8_0 und q4_0. Das sind Cache-Einstellungen, keine beliebig übertragbare Liste von Formaten für Modellgewichte. Ein quantisierter Cache setzt Flash Attention voraus. Ollama-Dokumentation zum Cache.

vLLM führt AWQ/GPTQ, FP8, INT8, INT4, MXFP4/MXFP8, NVFP4 und weitere Quantisierungsintegrationen auf. Die Unterstützung unterscheidet sich je nach Implementierung und Hardware. „Unterstützt 4-Bit“ reicht deshalb als Beschaffungsgrundlage nicht aus. Entscheidend ist die konkrete Kombination aus Checkpoint und Kernel. vLLM-Dokumentation zur Quantisierung, Formatübersicht.

Ein Tokenizer übersetzt Text in die Token-IDs, die das Modell verarbeitet. Änderungen an Gewichten, Tokenizer, Chat-Formatierung oder Quantisierung können Antworten, Tool-Aufrufe und Speicherverbrauch verändern. Regressionstests gehören deshalb in die Planung, auch wenn der Name der Modellfamilie gleich bleibt.

Mellum2.1 zeigt, warum die verfügbaren Modellpakete zählen

Die Ankündigung von Mellum2.1 durch JetBrains am 8. Oktober 2026 veranschaulicht das Muster einer Veröffentlichung, die zuerst auf Server ausgerichtet ist: Laut Beitrag sollten GGUF-Versionen für Ollama, llama.cpp und LM Studio in Kürze folgen. Die Modellseite zur Veröffentlichung enthält eine Anleitung für den Betrieb mit vLLM. Zu den Startintegrationen gehören vLLM und SGLang, ein weiterer Inferenzserver. JetBrains-Beitrag zur Veröffentlichung, Modellseite zur Veröffentlichung.

Diese Lücke zum Veröffentlichungsstart ist bereits kleiner geworden: Bei der Prüfung am 12. Oktober enthielt das offizielle GGUF-Repository von JetBrains quantisierte Dateien zum Download. Das „in Kürze“ aus dem Ankündigungsbeitrag beschreibt also nicht die heutige Verfügbarkeit. Für die Praxis bedeutet das: Erst das aktuell verfügbare Artefakt und die Anleitung für seinen Betrieb prüfen, bevor allein wegen eines neuen Modells die Engine gewechselt wird. Offizielle GGUF-Dateien.

OpenAI-kompatible Server: Client behalten, Verhalten prüfen

Beide dokumentieren einen OpenAI-kompatiblen Server. Ein gleich aufgebauter Request garantiert jedoch kein gleiches Verhalten. Ollamas lokale Basis-URL lautet http://localhost:11434/v1/; das vLLM-Beispiel verwendet http://localhost:8000/v1. Nutzt die Anwendung Ollamas native Schnittstelle /api/chat, erfordert der Wechsel eine API-Anpassung und nicht nur einen anderen Port. Ollama-Kompatibilität, vLLM-Serverdokumentation.

Nach der Installation von vLLM auf kompatibler Hardware stellt beispielsweise der folgende Befehl das Modell aus dem dokumentierten Serverbeispiel bereit, mit ausdrücklich gesetzter Kontextgrenze und einem Modellnamen für die Anwendung:

vllm serve NousResearch/Meta-Llama-3-8B-Instruct \
  --host 127.0.0.1 \
  --port 8000 \
  --max-model-len 8192 \
  --served-model-name app-model

Dies ist ein Einrichtungsbeispiel. Es verwendet weder denselben Checkpoint wie der vorherige Ollama-Befehl noch stellt es eine Empfehlung zur Dimensionierung im Produktivbetrieb dar. Mit --served-model-name kann der Client einen festen Modellnamen behalten, während sich die Bereitstellung ändert. vLLM-Engine-Argumente.

Chat-Templates übersetzen die Rollen der Nachrichten in das Eingabeformat des Modells und sollten beim Wechsel geprüft werden. Sampling-Parameter sind ausdrücklich festzulegen. vLLM kann die Standardwerte aus der generation_config.json eines Repositorys übernehmen; --generation-config vllm schaltet diese Übernahme ab. Das Auswerten von Tool-Aufrufen, strukturierte Ausgaben, Streaming, Abbrüche und Fehlerbehandlung müssen anhand der tatsächlichen Anfragen der Anwendung verglichen werden.

Die Authentifizierung gehört zum Wechsel dazu. Ollamas lokales Kompatibilitätsbeispiel ignoriert den vom Client gesetzten API-Schlüssel. vLLM unterstützt einen API-Schlüssel, weist in seiner Sicherheitsdokumentation aber darauf hin, dass dieser nicht jeden Endpunkt schützt. Das Backend sollte privat bleiben; Authentifizierung, TLS und Zugriffsbeschränkungen für Routen gehören an den Zugang zum Dienst. Grenzen des API-Schlüssels bei vLLM.

Ein weiterer Wechselaufwand entsteht, wenn die Anwendung häufig zwischen Basismodellen umschaltet: Die vLLM-FAQ beschreibt dafür separate Serverinstanzen und eine Routing-Schicht. Ein API-Alias lädt kein anderes Modell. Für ein wenig genutztes internes Tool kann Ollamas Verwaltung mehrerer geladener Modelle der bequemere Arbeitsablauf sein. vLLM-Einschränkung bei mehreren Modellen.

Kosten beim LLM-Hosting: Gleiche Last, anderer Betriebsaufwand

Keine der Engines gewinnt durch einen günstigeren Token-Tarif beim eigenen Hosting: Es gibt keine Token-Rechnung der Engine. Ollamas kostenpflichtige Cloud-Tarife sind ein eigenständiger Dienst und keine Voraussetzung für das Bereitstellen lokaler Modelle. Der Leitfaden zu Ollamas Preisen erklärt diese Unterscheidung; aktuelle Cloud-Angebote stehen auf der oben verlinkten Preisseite des Anbieters.

Bei eigener Hardware gehören Strom, anteilige Hardwarekosten und Arbeitszeit in die Monatsrechnung. Bei gemieteter Hardware bilden die angebotenen Maschinenstunden den Ausgangspunkt; hinzu kommen Speicher, Netzwerk und Betrieb. Effizientere Inferenz spart erst dann Geld, wenn sie den Ressourcenbedarf senkt, abrechenbare Laufzeit verkürzt oder einen bezifferbaren geschäftlichen Nutzen schafft.

Eine Budgetrechnung unter gleichen Annahmen

Die folgenden Werte sind ausdrückliche Budgetannahmen, keine Anbieterpreise oder Benchmark-Ergebnisse: eine GPU für $1 pro Stunde, 730 Stunden im Monat und 100,000 erfolgreiche Aufträge. Jeder Auftrag umfasst 2,000 Prompt-Token und 1,000 Ausgabe-Token. Modell, Quantisierung, Qualitätsmaßstab und Latenzziel sind für beide Engines gleich.

Erfüllen beide die Vorgaben auf einer durchgehend gemieteten GPU, kostet die Rechenleistung jeweils $730 pro Monat, also $0.0073 pro erfolgreichem Auftrag und pro 1,000 Ausgabe-Token. Bei der Berechnung je Ausgabe-Token bleibt die Prompt-Arbeit konstant; es handelt sich nicht um einen Mischpreis für Eingabe und Ausgabe.

Für den vLLM-Betrieb werden nun zwei zusätzliche Betriebsstunden pro Monat zu angenommenen $100 pro Stunde sowie einmalig vier Stunden für die Migration angesetzt:

• Ollama-Referenzbetrieb: $730 laufend, ohne die bei beiden anfallenden gemeinsamen Kosten.
• vLLM auf derselben Hardware: $930 laufend beziehungsweise $0.0093 pro 1,000 Ausgabe-Token.
• vLLM im ersten Monat einschließlich Migration: $1,330 beziehungsweise $0.0133 pro 1,000 Ausgabe-Token.

Diese Stundenansätze sind durch eigene Schätzungen zu ersetzen. Sie sagen nicht aus, wie lange eine Migration tatsächlich dauert. Gemeinsame Betriebsarbeiten, Speicher, Netzwerkgebühren und Steuern sind auf beiden Seiten ausgenommen.

Ab wann rechnet sich der Wechsel?

Bei diesem Stundensatz muss vLLM mehr als 200 GPU-Stunden pro Monat einsparen, um den angenommenen zusätzlichen Betriebsaufwand auszugleichen. Sollen auch die gesamten $400 Migrationsaufwand bereits im ersten Monat wieder eingespielt werden, steigt die Schwelle auf mehr als 600 eingesparte GPU-Stunden.

Ein Beispiel für den Dauerbetrieb: Der eigene Lasttest ergibt, dass Ollama zwei identische GPU-Replikate benötigt, vLLM dagegen eines, um dieselbe Last bei derselben Zielantwortzeit zu bewältigen. Dann betragen Ollamas Rechenkosten $1,460; bei vLLM bleiben Rechenkosten und zusätzlicher Betriebsaufwand zusammen bei $930. Unter dieser Voraussetzung werden $530 pro Monat gespart, sodass sich die $400 für die Migration nach etwa 0.75 Monaten amortisieren.

Das ist eine Wirtschaftlichkeitsrechnung, keine Behauptung, dass vLLM den GPU-Bedarf halbiert. Benötigen beide dieselbe Hardware und rechtfertigt kein anderer Nutzen den Wechsel, ergibt sich aus den Softwaregebühren niemals ein Vorteil für vLLM. Eine allgemeingültige Nutzerzahl, ab der sich der Wechsel rechnet, lässt sich nicht seriös angeben.

Checkliste für den Wechsel von Ollama zu vLLM

Den Wechsel über eine rückschaltbare Route durchführen, nachdem Modell und API-Verhalten geprüft sind. Die heruntergeladenen Gewichte sind nur ein Teil dessen, worauf die Nutzer angewiesen sind.

Ein Wechsel sollte warten, wenn Ollama die Zielwerte bereits erfüllt, für das benötigte Modell noch kein validierter vLLM-Betrieb vorliegt oder lediglich ein funktionierendes Paket gegen ein unbekanntes Backend getauscht würde. Auch Ollama auf Laptops und vLLM auf einem gemeinsam genutzten Server können sinnvoll sein, sofern die Unterschiede getestet werden und nicht einfach von identischem Verhalten in Entwicklung und Produktion ausgegangen wird. Eine breitere Auswahl bieten die Ollama-Alternativen.

Der nächste Schritt ist konkret: die repräsentative Spitzenlast erfassen, eine akzeptable Antwortzeit festlegen und diese Last auf dem vorgesehenen Server nachspielen, bevor zusätzliche Kapazität gekauft wird.

Häufige Fragen

Mit der Checkliste zur Prüfung betrieblicher KI-Arbeitsabläufe lässt sich auswählen, welcher private Arbeitsablauf einen gemeinsam genutzten Modellserver verdient. Der Newsletter informiert anschließend über weitere Änderungen bei den Tools.