Eine Inference Engine ist eine spezialisierte Laufzeit-Software, die ein trainiertes Large Language Model (LLM, das Sprachmodell hinter Chat- und Textdiensten) auf Grafikkarten-Hardware (GPUs) ausführt. Sie optimiert Speicherverwaltung, das Bündeln vieler Nutzer-Anfragen (Batching) und die zentrale Rechenoperation des Modells (Attention) so, dass Durchsatz und Kosten pro Textbaustein (Token) deutlich besser liegen als bei einer Ausführung im Trainings-Framework. Typische Vertreter im LLM-Umfeld sind vLLM, NVIDIA TensorRT-LLM, SGLang und Hugging Face Text Generation Inference; llama.cpp deckt den CPU- und Consumer-GPU-Fall über das GGUF-Format (kompaktes Dateiformat für lokal ausgeführte Modelle) ab.
Was ist eine Inference Engine?
Ein LLM wird nach dem Training als Datei mit Modellgewichten (den gelernten Parametern des Modells) verteilt, meist im Safetensors- oder GGUF-Format oder als vorkompilierter TensorRT-Plan. Um daraus einen produktiven Dienst zu machen, wird eine Laufzeit benötigt, die diese Gewichte in den Speicher der Grafikkarte (GPU) lädt, eingehende Anfragen in Rechen-Pakete (Tensor-Batches) umsetzt, die zentrale Rechenoperation des Modells (Attention) über die Recheneinheiten der GPU verteilt und die erzeugten Textbausteine (Tokens) an die Anwendung streamt. Genau diese Laufzeit ist die Inference Engine.
Der Begriff hat sich als eigene Software-Kategorie etabliert, weil eine naive Ausführung im Trainings-Framework wie [PyTorch](https://pytorch.org/) oder TensorFlow für den produktiven LLM-Betrieb nicht ausreicht. Der KV-Cache wird pro Anfrage statisch belegt, Anfragen werden sequenziell verarbeitet, und die GPU bleibt schlecht ausgelastet. Inference Engines lösen das mit spezialisierten Verfahren: paginierter KV-Cache und PagedAttention in vLLM, Continuous Batching (mehrere Anfragen teilen sich denselben Vorwärtslauf und werden im laufenden Schritt neu zusammengestellt), Speculative Decoding, Kernel-Fusion und kompilierte Attention-Kernel wie FlashAttention. Das Ergebnis ist ein erheblich höherer Durchsatz pro GPU und eine niedrigere Latenz pro Anfrage.
Eine Inference Engine leistet in der Regel: Modell-Laden mit Quantisierung (INT8, FP8, INT4 über AWQ oder GPTQ), Tensor-Parallelismus über mehrere GPUs, eine OpenAI-kompatible HTTP-API, Streaming-Ausgabe, Unterstützung für Tool-Calls und strukturierte Outputs, LoRA-Adapter zur Laufzeit sowie Prometheus-Metriken zu Auslastung und Token-Durchsatz. Was sie typischerweise nicht mitbringt, sind Autoscaling, Zugriffskontrolle, Rate-Limiting, Multi-Tenant-Routing oder eine Kostenaggregation über mehrere Modelle. Diese Aufgaben liegen in der Schicht darüber (Model Serving, LLM Gateway) oder beim Managed-Inference-Anbieter.
Abgrenzung: Model Serving, Framework, Anbieter, Optimierung
Der Begriff „Inference Engine" wird häufig mit benachbarten Bausteinen des LLM-Stacks vermischt. Die wichtigsten Abgrenzungen:
| Nachbar-Begriff | Verhältnis zur Inference Engine |
|---|---|
| Model Serving | Deployment-Schicht über der Engine mit Endpoint-Verwaltung, Autoscaling, Traffic-Routing und Versionierung (KServe, Databricks Model Serving, Ray Serve). Betreibt in der Regel eine Inference Engine als Backend. |
| Framework (PyTorch, TensorFlow) | Allzweck-Bibliothek für Training und Inferenz. Nicht auf hohen Durchsatz für viele parallele LLM-Anfragen ausgelegt. Die Inference Engine sitzt zwischen Framework und Endpoint. |
| Inference-Anbieter | Managed-Angebote wie Amazon Bedrock, Azure OpenAI, Google Vertex AI, Together, Fireworks oder Groq. Betreiben intern eigene oder Open-Source-Engines; die Engine ist für den Nutzer nicht direkt sichtbar. |
| Batch-Inferenz | Betriebsform (endlicher Datensatz, geplanter Lauf). Kann von einer Inference Engine ausgeführt werden, ist aber selbst kein Software-Baustein, sondern ein Ausführungsmodus. |
| Inference-Optimierung | Sammelbegriff für Techniken wie Quantisierung, KV-Cache-Optimierung oder Speculative Decoding. Die Engine ist der Ort, an dem viele dieser Techniken implementiert werden. |
Beispiel: vLLM als Backend für einen internen LLM-Dienst
Ein typischer Einsatz sieht so aus: Ein Team betreibt Llama-3.3-70B als internen Chat- und Extraktions-Dienst auf zwei H100-GPUs. [vLLM](https://github.com/vllm-project/vllm) lädt die Gewichte mit AWQ-Quantisierung, verteilt sie per Tensor-Parallelismus auf beide GPUs und exponiert einen OpenAI-kompatiblen Endpoint. Continuous Batching bündelt Anfragen von rund vierzig gleichzeitigen Nutzern zu gemeinsamen Vorwärtsläufen, PagedAttention hält den KV-Cache seitenweise vor und verhindert die Fragmentierung, an der ein Vanilla-Setup bei variabler Anfrage-Länge scheitert.
Durchsatz (Tokens pro Sekunde), Time-to-First-Token und Kosten pro Million Tokens werden gemessen und mit einer [TensorRT-LLM](https://github.com/NVIDIA/TensorRT-LLM)-Variante desselben Modells verglichen, um die Engine-Wahl zu belegen. Darüber liegt eine Model-Serving-Schicht, die Autoscaling und Blue-Green-Deployments übernimmt, sowie ein LLM-Gateway für Rate-Limiting, Auslastungs-Reporting und Kostenumlage. Auf Consumer-Hardware ohne Rechenzentrums-GPU tritt an dieselbe Stelle typischerweise [llama.cpp](https://github.com/ggml-org/llama.cpp) mit einem quantisierten GGUF-Modell.
Inference Engine im eigenen Unternehmen umsetzen?
Wir zeigen, wie sich das in deiner Systemlandschaft konkret abbilden lässt.
Auswahl-Entscheidung zwischen vLLM, TensorRT-LLM, SGLang und TGI im LLMOps-Cluster
Model ServingDeployment-Schicht mit Autoscaling und Endpoint-Verwaltung über der Engine
Inference-OptimierungTechniken wie Quantisierung, KV-Cache-Optimierung und Speculative Decoding
Batch-InferenzBetriebsform ohne wartenden Aufrufer als Gegenstück zur Real-Time-Inferenz
KV-Cachingzentrale Speicher-Optimierung innerhalb einer Inference Engine
Attention-Mechanismusder Rechenschritt, den PagedAttention und FlashAttention optimieren