llama.cpp, vLLM oder SGLang? Die richtige Inference-Engine für dein Unternehmen

Wer einen GPU-Server kauft und ein Sprachmodell darauf betreibt, denkt meistens zuerst an die Hardware. Wie viel VRAM, wie viele GPUs, welche Karte. Das ist wichtig, aber es ist nur die halbe Geschichte. Die Software die das Modell tatsächlich ausführt, die sogenannte Inference-Engine, entscheidet darüber wie viel von der vorhandenen Rechenleistung wirklich beim Nutzer ankommt. Falsch gewählt, verschenkt man die Hälfte der Performance. Richtig gewählt, skaliert dasselbe Setup auf ein Vielfaches der Nutzerzahl.

Dieser Artikel erklärt die drei Engines die in der Praxis relevant sind: llama.cpp, vLLM und SGLang. Was sie intern anders machen, wo jede Engine ihre Stärken hat, und welche für welchen Unternehmenseinsatz die richtige Wahl ist.

Was eine Inference-Engine überhaupt tut

Ein Sprachmodell besteht aus Milliarden von Gewichten, also Zahlen die während des Trainings gelernt wurden. Um eine Antwort zu generieren, muss das Modell diese Gewichte für jeden generierten Token einmal vollständig durch den Speicher lesen. Das ist keine Rechenaufgabe im klassischen Sinne, sondern vor allem eine Speicherbandbreiten-Aufgabe. Wie schnell die GPU Daten aus dem VRAM lesen kann, bestimmt wie schnell Tokens generiert werden.

Die Inference-Engine ist die Software die diesen Prozess orchestriert. Sie lädt das Modell in den Speicher, nimmt Anfragen entgegen, verteilt die Arbeit auf die verfügbaren GPUs und gibt die Ergebnisse zurück. Klingt simpel, ist es aber nicht: Je nachdem wie die Engine Anfragen bündelt, den Speicher verwaltet und parallele Requests behandelt, kann der Unterschied im Durchsatz ein Vielfaches betragen.

llama.cpp: Portabilität vor allem

llama.cpp wurde 2023 von Georgi Gerganov in C++ geschrieben und hat seitdem eine riesige Community aufgebaut. Das Ziel war von Anfang an: Modelle überall lauffähig machen, mit möglichst wenig Abhängigkeiten. Das ist gelungen. llama.cpp läuft auf NVIDIA-GPUs, AMD-GPUs, Apple Silicon, reiner CPU, und in Hybridkonfigurationen wo Teile des Modells auf der GPU und Teile im RAM liegen.

Das Format das llama.cpp verwendet heißt GGUF. Alle gängigen Open-Source-Modelle sind in diesem Format verfügbar, typischerweise in verschiedenen Quantisierungsstufen von Q2 bis Q8.

Die Kernlimitation von llama.cpp liegt in der Verarbeitung paralleler Anfragen. Die Engine verarbeitet Anfragen sequenziell: Eine Anfrage kommt rein, wird abgearbeitet, dann kommt die nächste. Wenn zehn Mitarbeiter gleichzeitig tippen, wartet Nutzer 2 bis 10 auf Nutzer 1. Dieses Queuing-Modell führt dazu, dass der Gesamtdurchsatz bei mehr gleichzeitigen Nutzern kaum wächst. Mit einem etwas größeren Batch bei der Prompt-Verarbeitung gewinnt man noch 20 bis 30 Prozent, dann ist die Grenze erreicht. Wer mit llama.cpp 60 Token pro Sekunde bei einem User erzielt, kommt auch bei zehn gleichzeitigen Usern nicht wesentlich über 75 bis 80 Token pro Sekunde Gesamtdurchsatz.

Dafür hat llama.cpp eine Fähigkeit die keine andere Engine in dieser Form bietet: CPU-Offloading. Wenn das Modell nicht vollständig in den VRAM passt, können einzelne Layer auf die CPU ausgelagert werden. Das bringt einen Geschwindigkeitsabzug, macht aber Modelle lauffähig die sonst gar nicht starten würden.

Ollama ist im Wesentlichen ein Wrapper um llama.cpp mit einer entwicklerfreundlichen Oberfläche. Model-Management ähnlich wie Docker, einfache Installation, automatisches Modell-Switching. Dafür zahlt man etwa 10 bis 15 Prozent Overhead gegenüber rohem llama.cpp. Für Einzelnutzer und Entwicklungsumgebungen ist Ollama die bequemste Option.

CPU-Offloading: Wann es hilft und wann nicht

Wenn ein Modell knapp nicht in den VRAM passt, kann llama.cpp mit dem Flag -ngl (number of GPU layers) einzelne Schichten auf die CPU auslagern. Rein technisch funktioniert das so: Die Gewichte für diese Layer liegen im RAM, bei jeder Berechnung werden sie über PCIe zur GPU transportiert, dort verarbeitet, und das Ergebnis zurückgeschrieben.

Der Geschwindigkeitsverlust ist erheblich. Auf einer reinen CPU ohne GPU-Unterstützung generiert ein 7B-Modell typischerweise 1 bis 2 Token pro Sekunde. Das ist für interaktive Nutzung kaum verwendbar. Bei Hybridbetrieb, also Attention-Layer auf GPU und Expert-FFN auf CPU, ist es deutlich besser, aber immer noch spürbar langsamer als vollständig auf GPU.

Für MoE-Modelle gibt es eine interessante Besonderheit: Da bei diesen Architekturen pro Token nur ein Bruchteil der Experten aktiv ist, hält sich der PCIe-Overhead beim Auslagern der Expert-FFN-Schichten in Grenzen. Es gibt sogar spezialisierte Anleitungen dafür wie man MoE-Modelle auf CPU+GPU-Systemen aufteilt und dabei noch akzeptable Geschwindigkeiten erzielt. Das ist aber immer eine Notlösung. Wer ein Modell produktiv für zehn oder mehr Nutzer betreiben will, braucht es vollständig im VRAM.

Ein typisches Szenario wo CPU-Offloading tatsächlich sinnvoll ist: Ein 140-GB-Modell in Q4 auf einem System mit 96 GB VRAM. Wenn man die letzten 10 bis 15 Prozent der Layer auf die CPU auslagert, läuft das Modell, mit einem Abzug von vielleicht 25 bis 35 Prozent Geschwindigkeit. Für einen einzelnen Nutzer der gelegentlich komplexe Dokumente analysiert, kann das ausreichen. Für zwanzig gleichzeitige Nutzer im Bürobetrieb nicht.

vLLM: Gebaut für Produktion

vLLM entstand 2023 aus dem Sky Computing Lab der UC Berkeley und hat sich seitdem zum De-facto-Standard für produktive LLM-Deployments entwickelt. Das Kernkonzept heißt PagedAttention.

Um zu verstehen warum das wichtig ist, muss man kurz wissen was der KV-Cache ist. Wenn ein Modell eine Antwort generiert, speichert es für jeden bereits verarbeiteten Token einen Eintrag im sogenannten Key-Value-Cache. Das spart das Neuberechnen aller vorherigen Token bei jedem neuen Schritt. Ohne KV-Cache würde jeder neue Token exponentiell teurer. Der KV-Cache wächst mit der Kontextlänge, und er belegt VRAM.

Traditionelle Engines reservieren für jede Anfrage einen zusammenhängenden Block VRAM, auch wenn die Antwort kürzer wird als erwartet. Das verschwendet 60 bis 80 Prozent des KV-Cache-Speichers durch Fragmentierung. vLLM löst das wie ein Betriebssystem virtuellen Speicher verwaltet: Der KV-Cache wird in kleine Seiten aufgeteilt, die dynamisch zugeteilt und nach Abschluss einer Anfrage sofort wiederverwendet werden. vLLM erreicht damit unter 4 Prozent Speicherverschwendung.

Das ermöglicht Continuous Batching. Anstatt auf eine ganze Gruppe von Anfragen zu warten bevor die GPU arbeitet, fügt vLLM neue Anfragen in den laufenden Batch ein sobald eine andere fertig ist. Der Scheduler arbeitet auf Token-Ebene, nicht auf Request-Ebene. Die GPU ist dadurch fast durchgehend ausgelastet.

Das Ergebnis: Während llama.cpp bei zehn gleichzeitigen Nutzern kaum über 75 bis 80 Token pro Sekunde kommt, aggregiert vLLM dieselben zehn Anfragen zu einer einzigen GPU-Operation und erreicht insgesamt 480 bis 500 Token pro Sekunde auf einem vergleichbaren System. Unter Volllast liefert vLLM laut Benchmarks auf H100-GPUs rund 12.500 Token pro Sekunde, bei bis zu 35-fachem Request-Durchsatz im Vergleich zu llama.cpp.

vLLM unterstützt echtes Tensor Parallelism über mehrere GPUs. Das bedeutet nicht, dass jede GPU andere Layer bekommt (das wäre Pipeline Parallelism, wie es llama.cpp macht), sondern dass jede Matrixmultiplikation auf alle GPUs gleichzeitig aufgeteilt wird. Alle GPUs rechnen parallel an jedem Layer. Das skaliert nahezu linear mit der GPU-Anzahl.

Eine Einschränkung von vLLM: Es gibt kein CPU-Offloading. Das Modell muss vollständig in den VRAM passen, entweder auf einer einzelnen Karte oder über mehrere Karten per Tensor Parallelism verteilt.

SGLang: Wenn Kontext geteilt wird

SGLang kommt aus demselben akademischen Umfeld wie vLLM, mit einer anderen Kernfrage: Was wenn viele Anfragen denselben Kontext teilen?

Bei einem internen Unternehmensassistenten hat fast jede Anfrage denselben System-Prompt. Bei einem RAG-System teilen sich viele Anfragen denselben Dokumentkontext. Bei Agenten-Workflows wiederholen sich Prefixe. SGLang erkennt diese gemeinsamen Prefixe automatisch und speichert ihren KV-Cache in einer Radix-Baum-Struktur, die per RadixAttention wiederverwendet wird. Wenn zehn Nutzer denselben System-Prompt schicken, muss der nur einmal verarbeitet werden.

In Benchmarks auf H100-Hardware erreicht SGLang rund 16.200 Token pro Sekunde, also etwa 29 Prozent mehr als vLLM. Der Unterschied ist bei workloads mit viel Prefix-Sharing noch größer: Bei RAG-Pipelines und Multi-Turn-Gesprächen wurden bis zu 6-fache Throughput-Vorteile gemessen. DeepSeek hat SGLang offiziell als empfohlene Engine für ihre Modelle bezeichnet, der DeepSeek V3.2 läuft damit 3,1-mal schneller als auf vLLM.

Das Tradeoff ist Komplexität. SGLang hat eine kleinere Community, weniger Dokumentation, und bei exotischen Modellarchitekturen oder Hardware-Setups mehr potenzielle Reibungspunkte als vLLM. Wer auf Stabilität und breite Modellkompatibilität angewiesen ist, fährt mit vLLM als Standard besser.

Ein Hinweis für alle die TGI (Text Generation Inference von Hugging Face) kennen: TGI befindet sich seit Dezember 2025 im Maintenance-Modus. Hugging Face empfiehlt offiziell vLLM oder SGLang für neue Deployments.

Multi-GPU: Pipeline vs. Tensor Parallelism

Wer ein Modell betreibt das größer ist als eine einzelne Karte, braucht mehrere GPUs. Aber wie sie zusammenarbeiten ist entscheidend.

llama.cpp macht Pipeline Parallelism: GPU 1 bekommt die ersten Layer, GPU 2 die nächsten, und so weiter. Das erlaubt das Modell zu starten, aber es ist sequenziell. GPU 2 wartet bis GPU 1 fertig ist. Der Geschwindigkeitsgewinn gegenüber einer einzelnen GPU ist minimal, man gewinnt hauptsächlich Speicher.

vLLM und SGLang machen Tensor Parallelism: Jede Matrixoperation wird auf alle GPUs gleichzeitig aufgeteilt. Alle GPUs rechnen parallel, das Ergebnis wird zusammengeführt. Bei vier GPUs verarbeitet jede ein Viertel jedes Layers gleichzeitig. Das skaliert nahezu linear: vier GPUs, annähernd vierfacher Durchsatz.

Für MoE-Modelle wie MiniMax-M2.5, Kimi K2.5 oder DeepSeek V3.2 ist das besonders relevant, weil diese Modelle ohnehin nur einen Bruchteil ihrer Parameter pro Token aktivieren. Der Kommunikationsoverhead zwischen den GPUs über PCIe ist bei MoE deutlich geringer als bei Dense-Modellen, weil nur die aktiven Experten kommunizieren müssen.

Welche Engine für welchen Einsatz

Die Frage ist nicht welche Engine technisch die beste ist, sondern welche zum konkreten Use Case passt.

Ollama macht Sinn für Entwickler, Tests und Einzelnutzer die ein Modell ausprobieren wollen. Installation in Minuten, keine Konfiguration, Modelle on-the-fly wechseln. Sobald mehr als drei bis fünf Nutzer gleichzeitig aktiv sind, stößt man an die Grenzen.

llama.cpp direkt kommt dort ins Spiel wo CPU-Offloading gebraucht wird: ein Modell das knapp nicht in den VRAM passt, oder ein Setup wo auch ohne GPU gearbeitet werden muss. Für Single-User-Deployments mit vollständiger GPU-Auslastung ist llama.cpp kompetitiv zu vLLM.

vLLM ist der Produktionsstandard für Multi-User-Deployments. Breiteste Modell- und Hardware-Kompatibilität, reife Community, gute Dokumentation. Wer ein Unternehmen mit 20 oder mehr gleichzeitigen Nutzern versorgt, kommt hier auf die besten Ergebnisse ohne viel Konfigurationsaufwand.

SGLang ist die Wahl wenn der Workload viel gemeinsamen Kontext hat: interne Chatbots mit konstantem System-Prompt, RAG-Systeme wo viele Anfragen denselben Dokumentkontext teilen, Agenten-Pipelines mit repetitiven Prefixen. Der 29-prozentige Throughput-Vorteil gegenüber vLLM ist real und bei prefix-lastigen Workloads noch deutlich größer. Wer DeepSeek-Modelle betreibt, sollte SGLang als erste Wahl evaluieren.

Szenario	Empfehlung
Einzelnutzer, Testing, Entwicklung	Ollama
Modell passt knapp nicht in VRAM	llama.cpp mit Offloading
5 bis 50 gleichzeitige Nutzer, stabiles Setup	vLLM
Multi-Turn-Chat, RAG, Agenten mit shared context	SGLang
DeepSeek-Modelle im Produktionsbetrieb	SGLang

Was das für die Hardware-Planung bedeutet

Die Wahl der Engine beeinflusst direkt wie viel VRAM du wirklich brauchst. Bei llama.cpp kannst du mit CPU-Offloading ein zu großes Modell notdürftig lauffähig machen. Bei vLLM und SGLang gibt es diesen Ausweg nicht: Das Modell muss vollständig in den VRAM passen, sonst startet der Server nicht.

Dafür verwalten vLLM und SGLang den verfügbaren VRAM deutlich effizienter. Durch PagedAttention und dynamische KV-Cache-Vergabe können wesentlich mehr gleichzeitige Nutzer auf demselben VRAM bedient werden als bei einer naiven Implementierung. Das bedeutet in der Praxis: Wer mit vLLM oder SGLang plant, kann bei gleichzeitiger Nutzerzahl mit weniger VRAM auskommen als die rohen Modellgrößen vermuten lassen.

Wie viel VRAM für welche Konfiguration tatsächlich gebraucht wird, hängt von Modellgröße, Quantisierung, Kontextlänge und gleichzeitiger Nutzerzahl ab. Das schauen wir uns im nächsten Artikel konkret an.

Wenn du unsicher bist welche Kombination aus Hardware, Modell und Engine für deinen Use Case die richtige ist, beraten wir dich gerne kostenlos. Schreib uns unter office@inhausi.at oder nutze unseren Konfigurator als Ausgangspunkt.