vLLM, SGLang, TensorRT-LLM, llama.cpp und Ollama: welche Serving-Engine für welche Aufgabe

OpenAI-kompatible API, Versionen, Lizenzen und Ports

vLLM, SGLang, TensorRT-LLM, llama.cpp und Ollama stellen Modelle mit offenen Gewichten hinter einer OpenAI-kompatiblen HTTP-API bereit, sodass eine IDE-Erweiterung, ein Chat-Frontend oder eine Anwendung, die für diese API geschrieben wurde, jede von ihnen nutzen kann, und zwar für die Endpunkte, die die jeweilige Engine implementiert. Sie unterscheiden sich darin, wie sie Anfragen zu Batches bündeln, welche 4-Bit- und 8-Bit-Formate sie auf welcher GPU ausführen, wie sie ein Modell auf mehrere GPUs aufteilen und wie sie sich mit ihren Voreinstellungen verhalten. Die Release-Versionen unten entsprechen dem Stand vom 5. November 2026; Flags und Voreinstellungen stammen aus der Dokumentation, den Release-Seiten und dem Quellcode des jeweiligen Projekts, Stand 23. September 2026.

READMEs, Dokumentation, Quellcode, PyPI und GitHub-Release-Seiten der Projekte, abgerufen am 23. September 2026; Versionen am 5. November 2026 erneut geprüft. SGLang, trtllm-serve, llama-server und Ollama lauschen nur auf dem lokalen Rechner, sofern man nichts anderes einstellt. Das eigene Container-Image von Ollama setzt jedoch OLLAMA_HOST=0.0.0.0:11434, und der dokumentierte Aufruf docker run mit -p 11434:11434 gibt den Port auf allen Adressen des Hosts frei; ein so eingerichteter Server macht also eine API ohne Authentifizierung von außen erreichbar. Ollama vor 0.35.0 ist zudem von CVE-2026-103663 betroffen (GHSA-w8p2-phwr-px3r, veröffentlicht am 8. Oktober 2026): Über eine Path-Traversal-Lücke in /api/pull kann jeder, der die API erreicht, eine Datei außerhalb des Modellspeichers ablegen. Als kritisch (CVSS 9,4) gilt sie, wo der Ollama-Dienst nach /usr/lib/ollama schreiben darf, weil die Datei dann nach einem Neustart als root läuft, sonst mit 6,9. Nutzen Sie 0.35.0 oder neuer und halten Sie Port 11434 vom Netz fern. vLLM lauscht auf allen Schnittstellen, sofern --host nicht gesetzt ist; Release 0.31.0 behob eine als hoch eingestufte Lücke zur Codeausführung bei Servern mit --trust-remote-code, die vLLMs Advisory GHSA-h3rc-6mm3-gc2m vom 6. Oktober 2026 beschreibt (CVSS 8.1, betroffen sind die Versionen 0.7.3 bis vor 0.31.0; die Release Notes zu 0.31.0 erwähnen sie nicht), 0.32.0 weitere, niedriger eingestufte Lücken; betreiben Sie einen gemeinsamen Endpunkt daher mit 0.31.0 oder neuer, besser mit 0.33.0 vom 2. November 2026, dem aktuellen Release (Stand November 2026), dessen CUDA-13.0-Builds einen Treiber ab R580 brauchen. Seit 0.32.0 lässt vLLM standardmäßig keine CORS-Origins mehr zu, Browser-Clients auf einem anderen Origin brauchen daher --allowed-origins; außerdem verlangt es Python 3.11 oder neuer und behandelt max_tokens als Obergrenze statt als Reservierung. Für TensorRT-LLM hat NVIDIA am 27. Oktober 2026 ein Sicherheitsbulletin veröffentlicht (CVE-2026-65119, CVE-2026-24269, CVE-2026-65120, alle mit der Einstufung High), behoben in 1.3.0rc25 und neuer; als betroffene Version nennt das Bulletin 1.3.0rc24.

Die dokumentierten Schnellstart-Befehle lauten vllm serve Qwen/Qwen2.5-1.5B-Instruct; das Modul von SGLang mit --model-path und einem Modellnamen; trtllm-serve, gefolgt von einem Modellnamen auf Hugging Face; llama-server -m mit einer GGUF-Datei (der Schnellstart im Haupt-README nutzt inzwischen llama serve); und ollama serve, dessen OpenAI-kompatible Routen unter /v1 liegen.

Wie jede Engine Batches bildet und den Cache verwaltet

vLLM speichert den Key/Value-Cache mit PagedAttention, das sein Paper von 2023 als „inspiriert von den klassischen Techniken des virtuellen Speichers und des Pagings in Betriebssystemen“ beschreibt, in Blöcken fester Größe und plant die Anfragen mit Continuous Batching und Chunked Prefill ein. Prefix Caching ist in aktuellen Releases standardmäßig aktiv, sodass Anfragen, die mit denselben Token beginnen, zwischengespeicherte Blöcke wiederverwenden.

SGLang bildet ebenfalls kontinuierlich Batches auf Basis eines seitenweise verwalteten Caches und ergänzt RadixAttention, das Prompt-Präfixe in einem Radix-Baum hält und über Anfragen hinweg wiederverwendet. Agenten, Retrieval-Pipelines und Chats über mehrere Runden erzeugen genau solche gemeinsamen Präfixe.

TensorRT-LLM (NVIDIAs aktuelle Dokumentation schreibt es TensorRT LLM) nutzt In-Flight-Batching und einen seitenweise verwalteten KV-Cache mit Wiederverwendung von Blöcken. PyTorch ist seit Release 1.0 sein Standard-Backend. Die stabile Version 1.2.1 installiert noch trtllm-build und akzeptiert --backend tensorrt; die Vorabversionen 1.3 und 1.4 streichen beides, und NVIDIAs Dokumentation stellt fest, dass das TensorRT-Engine-Backend entfernt wurde (die Release Notes führen die Änderung unter Release 1.2, obwohl die Setup-Datei von Release 1.2.1 trtllm-build noch registriert): PyTorch ist das einzige Ausführungs-Backend, und trtllm-serve lädt einen Hugging-Face-Checkpoint „ohne separaten Schritt zur Checkpoint-Konvertierung oder zum Engine-Build“. Anleitungen, die auf trtllm-build aufbauen, beschreiben daher einen Arbeitsablauf, den NVIDIA auslaufen lässt.

llama.cpp ist eine C/C++-Engine für GGUF-Dateien, mit Integer-Quantisierung von 1,5 bis 8 Bit und „hybrider CPU+GPU-Inferenz, um Modelle, die größer als die gesamte VRAM-Kapazität sind, teilweise zu beschleunigen“: --n-gpu-layers legt fest, wie viele Schichten auf die GPU kommen, und --n-cpu-moe hält die Expertengewichte der ersten N Schichten im Systemspeicher. llama-server bildet kontinuierlich Batches über eine feste Zahl von Slots.

Ollama fügt als zusätzliche Schicht Modell-Downloads und die Verwaltung des Lebenszyklus hinzu. Im Mai 2025 schrieb Ollama, es habe sich „bei der Modellunterstützung bisher auf das Projekt ggml-org/llama.cpp gestützt“, und kündigte eine neue Engine auf Basis der Tensorbibliothek GGML an, beginnend mit multimodalen Modellen; sein README führt llama.cpp weiterhin als Backend.

Welche Formate auf welcher GPU laufen

FP8-Arithmetik beginnt sowohl in den Tabellen von TensorRT-LLM als auch in denen von vLLM mit Ada, und FP4-Arithmetik braucht Blackwell. Die Engines dokumentieren das unterschiedlich: TensorRT-LLM veröffentlicht eine Matrix je Architektur, die Tabelle von vLLM endet bei Hopper, SGLang nennt SM-Bereiche, und die Release Notes von vLLM behandeln SM120 und SM121. Auf älteren Generationen laden vLLM und SGLang FP4-Checkpoints dennoch, und zwar über Marlin-Kernel, die die Gewichte in 4 Bit halten und in 16 Bit rechnen. Unser Leitfaden zu den Formaten erklärt die Formate selbst.

Quantisierungsmatrix, Deployment-Leitfaden für gpt-oss und Release Notes von TensorRT-LLM (Dokumentationsseite am 5. Oktober 2026 auf dem Stand 1.3.0rc29 und damit der stabilen Version 1.2.1 voraus), Hardwaretabelle zur Quantisierung, Build-Datei und Release Notes zu 0.30.0 von vLLM, Quantisierungsleitfaden von SGLang und NVIDIAs DGX-Spark-Playbooks, abgerufen am 23. September 2026. Beta ist NVIDIAs Bezeichnung für TensorRT-LLM auf DGX Spark, validiert für eine festgelegte Liste von Modellen. GGUF-Dateien laufen in llama.cpp und Ollama auf allen vier Generationen; Ollama führt die Compute Capabilities 8.9, 9.0, 12.0 und 12.1 auf.

Auf Hopper lassen sich FP4-Gewichte laden, gerechnet wird aber in 16 Bit: Der gpt-oss-Leitfaden von TensorRT-LLM kombiniert auf der H200 über sein Triton-MoE-Backend MXFP4-Gewichte mit BF16-Aktivierungen, und die Performance-Tabelle von TensorRT-LLM führt gpt-oss-120b auf einer H200 als FP8. Wir liefern die GPUs aus der Tabelle oben und bauen KI-Server mit ihnen auf Bestellung, etwa den Inferenzknoten mit vier Karten der RTX PRO 6000 Server Edition. Nennen Sie uns Modell und Nutzerzahl, und wir schlagen eine Konfiguration vor.

Tensor-, Pipeline- und Experten-Parallelismus über GPUs und Server

vLLM unterstützt Tensor-, Pipeline-, Daten- und Experten-Parallelismus (--tensor-parallel-size, --pipeline-parallel-size, --enable-expert-parallel); über mehrere Knoten nennt seine Dokumentation Ray als Standard-Laufzeitumgebung und zeigt außerdem eine Multiprocessing-Konfiguration mit --nnodes und --node-rank. Seine Empfehlung lautet: Tensor-Parallelismus, wenn ein Modell auf einen Knoten passt, zusätzlich Pipeline-Parallelismus über Knoten hinweg und auf GPUs ohne NVLink Pipeline- statt Tensor-Parallelismus, mit der L40S als Beispiel. Das gilt für jede RTX-PRO-Blackwell-Karte, denn keine davon hat NVLink.

SGLang nimmt --tp, --pp-size und --ep entgegen, und --nnodes verteilt den Tensor-Parallelismus auf mehrere Maschinen. TensorRT-LLM nimmt --tp_size, --pp_size und --ep_size entgegen und startet Läufe über mehrere Knoten mit trtllm-llmapi-launch unter Slurm.

llama.cpp verteilt standardmäßig Schichten und KV-Cache auf die GPUs (--split-mode layer) und arbeitet sie als Pipeline ab. row teilt die Gewichte zeilenweise auf, der als experimentell gekennzeichnete Modus tensor teilt Gewichte und KV-Cache; in beiden rechnen die GPUs parallel, und none hält das Modell auf einer GPU. Über mehrere Maschinen hinweg ist die einzige Option, die wir gefunden haben, ein RPC-Backend, das sein README „fragil und unsicher“ nennt und das nicht „in einem offenen Netzwerk oder in einer sensiblen Umgebung“ betrieben werden soll. Ollama legt ein Modell auf eine GPU, wenn es dort hineinpasst, und verteilt es andernfalls auf alle; wir haben in seiner Dokumentation keinen Modus für mehrere Maschinen gefunden. Unser Leitfaden zu einem Modell auf mehreren GPUs behandelt die PCIe- und NVLink-Seite.

Parallelitätsgrenzen, GPU-Speicher, Metriken und LoRA-Adapter

Quellcode und Dokumentation von vLLM 0.30.0, Serverargumente und LoRA-Leitfaden von SGLang, Referenz und LoRA-Leitfaden zu trtllm-serve, README und Quellcode von llama-server, FAQ, Seite zur Kontextlänge und Modelfile-Referenz von Ollama, September 2026.

Auf einem gemeinsam genutzten Server wirken sich die Voreinstellungen von Ollama am stärksten aus. Jedes Modell verarbeitet eine Anfrage nach der anderen, bis OLLAMA_NUM_PARALLEL erhöht wird, der Server stellt bis zu 512 Anfragen in die Warteschlange, bevor er weitere ablehnt, und jeder parallele Slot fügt Kontextspeicher hinzu: „Ein Kontext von 2K mit 4 parallelen Anfragen ergibt einen Kontext von 8K“. Die Seite zur Kontextlänge setzt den Standardwert nach VRAM: 4K unter 24 GiB, 32K von 24 bis 48 GiB und 256K ab 48 GiB. Die FAQ nennt noch 4.096; setzen Sie OLLAMA_CONTEXT_LENGTH also ausdrücklich. Das README von llama-server nennt für -np den Standard -1, also auto, und der Quellcode des Servers setzt dann vier Slots mit einem gemeinsamen KV-Puffer. Der Speicheranteil von vLLM stieg mit Release 0.20.0 vom April 2026 von 0,9 auf 0,92; seit diesem Release zählt auch der Speicher für CUDA Graphs dazu. Der Anteil gilt je Instanz, was wichtig wird, wenn sich zwei Instanzen eine Karte teilen. Unser Artikel zur gemeinsamen Nutzung eines DGX Spark zeigt, was diese Einstellungen auf einer Maschine bedeuten.

NVIDIA NIM: Engines, von NVIDIA fertig verpackt

NIM ist NVIDIAs paketierte Form einer solchen Engine, mit APIs nach Industriestandard. NVIDIAs Produktseite zu NIM, aktualisiert am 28. August 2026, spricht von großen Sprachmodellen, die von TensorRT-LLM, vLLM oder SGLang unterstützt werden. Die Dokumentation zu NIM for LLMs 2.0.12, aktualisiert am 18. September 2026, weicht davon ab: NIM LLM „baut auf vLLM auf“, und „Der Multi-Backend-Container (vLLM, TensorRT-LLM und andere) wird durch einen dedizierten vLLM-Container ersetzt.“ Die Release Notes zu 2.0.13 hoben das enthaltene vLLM auf 0.28.0 an und ergänzten zusammen mit der Support-Matrix modellspezifische Container, unter anderem für GLM-5.2, die SGLang als Inferenz-Backend nutzen. Release 2.1.4, Stand 5. November 2026 das neueste in NVIDIAs Release Notes (aktualisiert am 23. Oktober 2026), wechselt auf vLLM 0.30.0 und SGLang 0.5.20 und behebt 28 Sicherheitslücken in den Images für vLLM und SGLang. NVIDIAs DGX-Spark-Playbook beschreibt eine OpenAI-kompatible Schnittstelle und verlangt einen NGC-API-Schlüssel. Entwicklung und Tests sind über NVIDIAs Developer Program kostenlos. Für den Produktivbetrieb verlangt NVIDIAs NIM-FAQ, zuletzt geändert am 6. August 2026, eine Lizenz für NVIDIA AI Enterprise. NVIDIAs Seite „NIM Offerings“, aktualisiert am 15. Oktober 2026, führt den NIM Certified Feature Branch dagegen als „unter den geltenden Lizenzbedingungen kostenlos“ und verlangt die Subscription für den Production Branch; lassen Sie deshalb im Angebot festhalten, auf welcher NIM-Variante ein produktiver Server beruht. NIM passt dort, wo diese Lizenz ohnehin vorhanden ist, wie bei der H200 NVL, zu der eine Lizenz für fünf Jahre gehört, und wo ein unterstützter Stack mehr zählt als die eigene Wahl der Engine; die Open-Source-Engines selbst brauchen keine Lizenz für AI Enterprise. Unsere Seite zu NVIDIA AI Enterprise behandelt die Lizenz.

Welche Engine für welche Aufgabe

Wenn Sie allein auf einer GPU oder einem DGX Spark Modelle ausprobieren, nutzen Sie Ollama oder llama.cpp: Beide verarbeiten GGUF-Dateien, bieten einfache Downloads und CPU-Offload, wenn ein Modell größer ist als der GPU-Speicher. Bevor andere es nutzen, erhöhen Sie OLLAMA_NUM_PARALLEL oder wechseln Sie zu einem Server mit Batching.

Für einen gemeinsamen Endpunkt eines Teams oder einer Anwendung eignen sich vLLM oder SGLang. Beide bilden kontinuierlich Batches, verwenden zwischengespeicherte Präfixe wieder, exportieren Prometheus-Metriken, bedienen mehrere LoRA-Adapter gleichzeitig und verteilen Modelle auf mehrere GPUs und Maschinen. Bei Agenten und Retrieval, wo Prompts lange Präfixe teilen, zählt diese Wiederverwendung am meisten; Entwicklerteams verweisen wir auf unseren Leitfaden zu einem privaten Coding-Assistenten.

Wir können den Endpunkt im Rahmen unseres Services Private AI/ML bei Ihnen vor Ort mit vLLM oder NVIDIA AI Enterprise einrichten. Schreiben Sie uns, welchen Endpunkt Sie planen; das erste Gespräch ist kostenlos.

Wenn Ihnen NVIDIAs veröffentlichte Zahlen und eine dokumentierte Formatmatrix wichtig sind, nehmen Sie TensorRT-LLM. NVIDIA misst damit die Werte für seine Performance-Tabellen je GPU und veröffentlicht eine Formatmatrix je Architektur; auf DGX Spark ist die Unterstützung als Beta gekennzeichnet. vLLM und SGLang führen FP4 auf RTX PRO Blackwell ebenfalls nativ aus.

Auf der H200 NVL und anderen Hopper-Karten setzen Sie FP8 oder INT4 über AWQ oder GPTQ ein. Die Matrix von TensorRT-LLM führt für Hopper weder NVFP4 noch MXFP4, und wo sich FP4-Gewichte doch laden lassen, in vLLM, SGLang oder auf dem gpt-oss-Pfad von TensorRT-LLM, läuft die Arithmetik in 16 Bit.

Für einen unterstützten Stack mit Vertrag gibt es NIM, das laut seiner Dokumentation für Sprachmodelle ab Release 2.0 intern vLLM ausführt und in einigen modellspezifischen Containern SGLang.

Wir haben keinen Vergleich dieser Engines gefunden, der über Modelle, GPUs und Prompt-Längen hinweg Bestand hat, und wir zitieren keinen: Testen Sie Ihr eigenes Modell mit Ihren eigenen Prompt-Längen.

Was wir liefern

Wir liefern die GPUs, auf denen diese Engines laufen, vom DGX Spark und den RTX-PRO-Blackwell-Workstation-Karten bis zur RTX PRO 6000 Server Edition, L4, L40S und H200 NVL, separat oder in nach Auftrag gebauten KI-Servern, unter einem EU-Vertrag und auf einer Rechnung, mit Herstellergarantie. Nennen Sie uns die Engine, die Präzision und die Kontextlänge, die Sie gewählt haben, und wir konfigurieren den Server dafür, auf Wunsch mit installiertem Betriebssystem, Treibern, CUDA und einer Container-Runtime. Ist NIM Teil des Plans, kommt die Lizenz für NVIDIA AI Enterprise in dasselbe Angebot.

FAQ