vLLM vs. Ollama vs. TGI: Inference-Frameworks für GPU-Server in der Praxis

vLLM vs. Ollama vs. TGI: die Kandidaten im Überblick

Alle drei Frameworks stellen ein Sprachmodell als API bereit, verfolgen aber unterschiedliche Ziele.

vLLM: für Durchsatz und viele gleichzeitige Nutzer

vLLM ist ein Open-Source-Inference-Server, der auf effiziente Auslastung der GPU unter Last ausgelegt ist. Die wichtigsten Eigenschaften:

• PagedAttention: Der KV-Cache wird in Blöcken verwaltet, ähnlich dem virtuellen Speicher eines Betriebssystems. Das reduziert Verschnitt und erlaubt mehr parallele Anfragen im selben VRAM.
• Continuous Batching: Neue Anfragen werden laufend in die Verarbeitung aufgenommen, statt auf das Ende eines Stapels zu warten.
• Breite Modell- und Quantisierungsunterstützung sowie Tensor-Parallelisierung über mehrere GPUs.
• Betriebsfreundlich: OpenAI-kompatible API und Prometheus-Metriken wie Time to First Token oder KV-Cache-Auslastung.

Die Kehrseite: vLLM reserviert beim Start standardmäßig einen Großteil des GPU-Speichers und verlangt mehr Konfiguration als Ollama – etwa bei Kontextlänge, Speicheranteil und Quantisierung. Weitere Optimierungshebel beschreibt der Beitrag KI-Inference optimieren: Latenz und Throughput.

Ollama: Einfachheit zuerst

Ollama macht den Einstieg in lokale LLMs sehr leicht: Ein Befehl lädt ein Modell, ein weiterer startet es. Technisch basiert Ollama auf llama.cpp und nutzt quantisierte GGUF-Modelle.

• Stärken: schnelle Installation, großer Modellkatalog, geringe Einstiegshürde, läuft auch auf Workstations und Notebooks.
• Parallelität: Ollama begrenzt die Zahl gleichzeitig verarbeiteter Anfragen pro Modell (einstellbar über OLLAMA_NUM_PARALLEL), weitere Anfragen landen in einer Warteschlange. Höhere Werte sind möglich, vergrößern aber den reservierten Kontextspeicher entsprechend.
• Sicherheit: Ollama bindet sich standardmäßig nur an die lokale Adresse. Wer den Dienst im Netz verfügbar macht, sollte ein Gateway mit Authentifizierung vorschalten.

Für Entwicklung, Tests und kleine Teams ist Ollama eine gute Wahl. Für Dienste mit vielen gleichzeitigen Nutzern stößt es früher an Grenzen als Frameworks, die konsequent auf Batching ausgelegt sind.

TGI: solide Technik, aber im Wartungsmodus

Text Generation Inference (TGI) von Hugging Face war lange eine etablierte Option für produktives LLM-Serving, mit Continuous Batching, Token-Streaming und Multi-GPU-Unterstützung. Hugging Face hat TGI jedoch in den Wartungsmodus versetzt: Angenommen werden nur noch kleinere Fehlerbehebungen, Dokumentationsverbesserungen und leichte Wartungsarbeiten. Das Projekt empfiehlt selbst, künftig auf vLLM, SGLang oder lokale Engines wie llama.cpp zu setzen.

Für bestehende TGI-Installationen heißt das: kein akuter Handlungsdruck, aber eine Migration sollte eingeplant werden – neue Modellarchitekturen und Optimierungen kommen dort nicht mehr hinzu.

So führen Sie einen aussagekräftigen Benchmark durch

Veröffentlichte Benchmark-Zahlen sind selten übertragbar: Sie hängen von GPU, Modell, Quantisierung, Kontextlänge, Framework-Version und Lastprofil ab. Deshalb nennen wir hier bewusst keine pauschalen Werte, sondern die Methodik, mit der Sie belastbare eigene Ergebnisse erhalten.

1. Realistisches Lastprofil festlegen: Wie lang sind typische Eingaben (bei RAG oft mehrere Tausend Tokens) und Antworten? Wie viele Nutzer arbeiten gleichzeitig?
2. Gleiche Bedingungen schaffen: identisches Modell, möglichst gleichwertige Quantisierung, gleiche maximale Kontextlänge, gleiche Treiberversion. GGUF-Quantisierung bei Ollama und AWQ bei vLLM sind nicht exakt vergleichbar – dokumentieren Sie das.
3. Die richtigen Kennzahlen messen: Time to First Token, Inter-Token-Latenz, Gesamtdurchsatz in Tokens pro Sekunde, jeweils als Median und P95 – nicht nur Mittelwerte.
4. Last stufenweise erhöhen: 1, 4, 16, 64 gleichzeitige Anfragen. Interessant ist der Punkt, an dem die Latenz für Nutzer inakzeptabel wird.
5. Aufwärmen und wiederholen: Den ersten Lauf verwerfen, mehrere Durchläufe mitteln.
6. Qualität prüfen: Schnell ist wertlos, wenn die Antworten durch Quantisierung schlechter werden. Testen Sie mit eigenen Beispielfragen.

Hilfreiche Werkzeuge sind das Benchmark-Kommando von vLLM (vllm bench serve) oder allgemeine Lasttest-Tools gegen die OpenAI-kompatiblen Endpunkte, sodass alle Frameworks mit derselben Last getestet werden.

Einordnung für typische Hardware

• Verda GPU S (RTX 4000 SFF Ada, 20 GB): Hier laufen Modelle der 7–8B-Klasse gut. Bei wenigen Nutzern ist Ollama einfach und ausreichend; sobald ein Team parallel arbeitet, spielt vLLM seine Batching-Vorteile aus.
• Verda GPU L (RTX PRO 6000 Blackwell, 96 GB): Mit großen Modellen und vielen gleichzeitigen Anfragen ist ein auf Durchsatz ausgelegtes Framework wie vLLM die naheliegende Wahl, weil der große VRAM für KV-Cache und Batching genutzt werden kann.

Wie viel Speicher Sie für Modell und Kontext einplanen sollten, beschreibt der VRAM-Guide.

Praktische Empfehlung

• vLLM für produktive Dienste mit mehreren Nutzern, RAG-Anwendungen und API-Betrieb
• Ollama für Entwicklung, Prototypen, Einzelarbeitsplätze und kleine Teams
• TGI nur noch in Bestandsinstallationen, mit geplantem Umstieg
• SGLang als weitere aktiv entwickelte Alternative prüfen, besonders bei komplexen, mehrstufigen Anfragen

Auf unseren Managed KI-Servern richten wir das passende Framework für Ihren Anwendungsfall ein und betreiben es. Mit dem Local LLM Secure Gateway sichern Sie den Zugriff zusätzlich ab – unabhängig davon, welche Engine darunter läuft.