Inferenz-Engines im Vergleich

Die Engine ist das Programm, das Gewichte in Tokens verwandelt: Sie lädt die Datei, fährt den Transformer-Forward-Pass und spricht oben drauf üblicherweise HTTP. Die gute Nachricht ist, dass fast jede Engine dasselbe Model auf derselben Hardware mit ungefähr derselben Geschwindigkeit fährt — die Engine-Wahl handelt von Workflow, Format-Unterstützung und Parallelität, nicht von rohen tok/s. Die schlechte Nachricht ist dieselbe: Benchmark-Shopping zwischen ihnen ist meist vergebliche Mühe.

Das Feld

Eine Anmerkung zur Abstammung: Ollama und LM Studio fahren beide llama.cpp unter der Haube. Sie mit llama.cpp zu vergleichen heißt, Verpackungen zu vergleichen, nicht Inferenz.

Außerdem wissenswert: llama.cpp liefert mehr als einen Server — Quantisierungs- und Konvertierungswerkzeuge, einen Benchmark-Testrahmen und Bindings für ein Dutzend Sprachen.

Vertiefungen

vLLM wurde aus der Paged-Attention-Einsicht geboren (siehe Parallelität): GPU-Speicher so behandeln, wie ein OS RAM behandelt, und weit mehr Anfragen passen hinein. Es ist die Standardantwort auf „Ich habe einen GPU-Server und echten Traffic“.

SGLang cached Präfixe über Anfragen hinweg (RadixAttention): Teilen sich 40 Agenten denselben zweiseitigen System-Prompt, wird der Prompt einmal verarbeitet, nicht 40-mal. Es ist auch bekannt für schnelles Constrained Decoding — siehe Strukturierte Ausgabe.

exllamav2 ist die geschärfte Klinge für genau eine Nische: ein einzelner Nutzer auf einer einzelnen NVIDIA-GPU, der die meisten tok/s pro Bit Quantisierung will. Die Server-Geschichte und die Hardware-Breite sind dünn; die Nische ist echt.

MLX ist Apples ML-Framework, gebaut für Unified Memory. Zum Zeitpunkt dieses Textes schlägt mlx-lm llama.cpps Metal-Pfad bei größeren Modellen oft — knapp genug, dass es sich auf einem Mac lohnt, beide zu probieren (mehr in Apple Silicon).

transformers ist die langsame, treue Referenz: Tut eine quantisierte Engine etwas Seltsames, beantwortet das Fahren desselben Modells durch sie die Frage „ist es die Engine oder das Model?“. Sie ist auch die Verrohrung unter Fine-Tuning-Werkzeugen (siehe Fine-Tuning).

Nach Bedarf wählen

Zwei Anmerkungen zur Tabelle:

• „Starten Sie mit“ heißt nicht „bleiben Sie bei“ — jede Desktop-Engine liest dasselbe GGUF, also kostet der Versuch einer zweiten fünf Minuten, keine Migration.
• Wenn Sie doch vergleichen, halten Sie alles konstant: gleiches Model, gleiches Quant, gleicher Prompt, Model schon warm.

Die Format-Spaltung spiegelt die Desktop-/Server-Spaltung

GGUF gegen Safetensors (siehe Modellformate) ist nicht bloß eine Container-Präferenz — es entscheidet über Ihre Engine. GGUF ist das Ein-Datei-, vorquanti­sierte, überall-laufende Format, und das gesamte Desktop-Ökosystem (llama.cpp, Ollama, LM Studio) ist darauf gebaut. Safetensors ist das Shard-Tensor-Format des Hugging-Face-Ökosystems; die Server-Engines mit hohem Durchsatz (vLLM, SGLang, transformers) konsumieren es, meist spontan quantisiert (AWQ/GPTQ-Varianten) statt vorverpackt.

Der echte Entscheidungsbaum ist also kurz: Desktop und Einzelnutzer → GGUF-Engines; Server und parallel → Safetensors-Engines. Alles andere ist Detail.

Wenn etwas „nicht laufen kann“, prüfen Sie zuerst das Format — die Hälfte von „Engine X kann Model Y nicht ausführen“ ist ein GGUF/Safetensors-Missverhältnis, keine Fähigkeitslücke.

Overhead ist nicht die Geschichte

Auf identischer Hardware mit identischem Quant landen Engines für Single-Stream-Decode grob innerhalb von 10–20% voneinander — oft, weil sie sich ein Backend teilen. Was Ihre erlebte Geschwindigkeit wirklich um Faktoren bewegt, nicht um Prozent:

• Ob das Model schon geladen ist — eine Kaltladung kostet Sekunden bis eine Minute.
• Ob die ganze Konversation jede Runde erneut gesendet wird — Kontextkosten, siehe Tokens.
• Ob Anfragen hintereinander in die Warteschlange gehen — siehe Parallelität.
• Ob Layer auf der GPU liegen — siehe Engine-Regler.

Gleiche GPU, gleiches 8B Q4_K_M, ein Stream (illustrativ, keine Specs):
llama.cpp / Ollama / LM Studio    ~130–145 tok/s   (dieselbe Engine darunter)
exllamav2 EXL2 ~4bpw              ~160–180 tok/s   (auf Decode getunter Loader)

Gleiche GPU, 8 gleichzeitige Chat-Streams:
llama-server serielle Warteschlange   jeder Stream wartet; Gesamtdurchsatz flach
vLLM                                  alle Streams nahe Single-Stream-Geschwindigkeit

Wählen Sie die Engine, die zu Ihrem Workflow passt, und investieren Sie Ihre Energie in I/O-Muster statt in Engine-Benchmarks.

Eine Datei, viele Engines

Ein GGUF, das Sie für Ollama heruntergeladen haben, läuft auch direkt in llama.cpp und in LM Studio — Engines konvertieren nicht und laden nicht erneut herunter; Sie lassen sie auf dieselbe Datei zeigen (Ollama kann einen lokalen Pfad mit einem einzeiligen Modelfile importieren). Dasselbe gilt serverseitig für Safetensors zwischen vLLM und SGLang. Praktische Konsequenz: Es gibt kein Vendor-Lock-In auf Dateiebene, und sich über eine Engine zu irren kostet Sie Minuten.

Deshalb drängt diese Seite ständig auf Workflow statt Benchmarks: Wenn sich Ihre Bedürfnisse ändern, ziehen die bereits heruntergeladenen Modelle mit Ihnen um.

Wann Sie Ollama entwachsen

Ollamas Defaults sind exzellent, bis sie es nicht sind. Wechseln Sie zu einer Serving-Engine, wenn:

• Sie anhaltende Parallelität über eine Handvoll Streams hinaus brauchen (siehe Parallelität).
• Sie Präfix-Caching über viele Agenten hinweg wollen, die einen System-Prompt teilen (SGLang).
• Sie AWQ/GPTQ-Safetensors-Quants direkt aus dem HF-Ökosystem serven müssen.
• Sie eine Produktfunktion vor dem Ausliefern lasttesten.
• Sie Multi-GPU-Tensor-Parallelismus brauchen, um ein großes Model über Karten zu verteilen.

Bis eine davon wahr ist, ist die Bequemlichkeit mehr wert als der Durchsatz.

Verwandt: Modellformate · Engine-Regler · Einen Endpunkt serven · Modellauswahl