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

Fünf Engines, eine API

Alle fünf Engines 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. Unterschiedlich ist, 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 was sie tun, bevor jemand eine Voreinstellung ändert. Die folgenden Versionen, 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. 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. vLLM lauscht auf allen Schnittstellen, sofern --host nicht gesetzt ist.

Die dokumentierten Einstiege sind kurz: 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 aktuellen Vorabversionen der Version 1.3 streichen beides, und NVIDIAs Dokumentation stellt fest, dass das TensorRT-Engine-Backend entfernt wurde: 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 einen Weg, der ausläuft.

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 auf dem Stand 1.3.0rc28 und damit der neuesten Version auf PyPI 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.

Mehrere GPUs und mehrere Server

vLLM unterstützt Tensor-, Pipeline-, Daten- und Experten-Parallelismus (--tensor-parallel-size, --pipeline-parallel-size, --enable-expert-parallel), mit Ray als Standard-Laufzeitumgebung über mehrere Knoten. 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 Schichten und Cache standardmäßig auf die GPUs (--split-mode layer, als Pipeline), mit row und einem experimentellen Modus tensor als Alternativen. Ü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ät, Metriken und 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 gemeinsam genutzten Maschinen überraschen die Voreinstellungen von Ollama am meisten. 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, während die FAQ noch 4.096 nennt; setzen Sie OLLAMA_CONTEXT_LENGTH also ausdrücklich. llama-server nutzt für seine vier automatischen Slots einen 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.“ NVIDIAs DGX-Spark-Playbook beschreibt eine OpenAI-kompatible Schnittstelle und verlangt einen NGC-API-Schlüssel. NVIDIAs Bedingungen sehen kostenlosen Zugang für Entwicklung und Tests über das Developer Program vor und für den Produktivbetrieb eine Lizenz für NVIDIA AI Enterprise. 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

Ein Entwickler, eine GPU oder ein DGX Spark, Modelle ausprobieren: Ollama oder llama.cpp, für GGUF-Dateien, 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.

Ein gemeinsamer Endpunkt für ein Team oder eine Anwendung: 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.

NVIDIAs veröffentlichte Zahlen und eine dokumentierte Formatmatrix: 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.

H200 NVL und andere Hopper-Karten: FP8 oder INT4 über AWQ oder GPTQ. 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.

Ein unterstützter Stack mit Vertrag: NIM, das laut seiner Dokumentation für Sprachmodelle ab Release 2.0 intern vLLM ausführt.

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

Eurokommerz liefert die GPUs, auf denen diese Engines laufen, EU-weit mit Herstellergarantie, vom DGX Spark und den RTX-PRO-Blackwell-Workstation-Karten bis zur L4, L40S und H200 NVL, einzeln oder in nach Auftrag gebauten KI-Servern. Wir konfigurieren den Server für die Engine, die Präzision und den Kontext, die Sie wählen, und liefern Lizenzen für NVIDIA AI Enterprise, wo NIM Teil des Plans ist.

FAQ