Inference-Engines
Server und Engine
Die Nutzung eines Modells (LLMs) zur Inference kann grundsätzlich in zwei Komponenten unterteilt werden: Die Inference-Engine und der Inference-Server. Die Inference-Engine kümmert sich um das Laden des Modells, den Aufruf des Modells zur Next-Token-Prediction, sowie das Stapeln der Anfragen (Batching), während der Inference Server die Weiterleitung der Benutzeranfragen übernimmt.
Die Inference-Engine kann eine Vielzahl von Optimierungstechniken unterstützen. Im Kern handelt es sich um Python- oder C++-Bibliotheken. Sie sorgen für das Stapeln der Anfragen (Batching), die von den Benutzern an den Chatbot gerichtet werden, sowie für die Generierung der Antworten auf diese Anfragen.
Der Inference-Server übernimmt die Orchestrierung der HTTP/gRPC-Anfragen, die von den Benutzern eingehen. Die Server nehmen die Benutzer-Anfragen entgegen und stellen sie in die Warteschlange, bis sie sie an die Inference-Engine weiterleiten, die dann die Antwort generiert.
Anmerkung: Einige LLM-Gateways fungieren als Server.
Metriken
Es gibt zwei wesentliche Metriken, die unser Verständnis von der Leistung des Systems und der Benutzererfahrung prägen. Das sind Durchsatz und Latenz. Diese werden in der Regel vom Server gemessen und zurückgeliefert.
| Metrik | Auswirkung |
|---|---|
| Latenz | Latenz spiegelt die Zeit wider, die der Server und das Modell benötigen, um die vollständige Ausgabe in der Ausgabesequenz zu erzeugen. Wenn wir die erzeugte Ausgabe an den Endbenutzer streamen, bezieht sich die Latenz speziell auf die Zeit, die der Inferenzserver benötigt, um das allererste Token zu erzeugen. Diese Zeit für die Erzeugung des ersten Tokens wird auch als „time to first token“ (TTFT) bezeichnet. |
| Durchsatz | Der Durchsatz gibt an, wie viele Nutzer unser System effektiv bedienen kann. Der Durchsatz steht für die Anzahl der vom Inferenzserver pro Sekunde generierten Token während der zahlreichen Anfragen der Benutzer. Je höher der Durchsatz ist, desto besser kann unser System auf Benutzeranfragen eingehen und reagieren. |
Auf was solle man achten
Bei der Auswahl von Inference Server und Inference Engine sind folgende Eigenschaften relevant, die sich auf Durchsatz und Latenz auswirken:
Inference-Engine:
- Speicher-Management (KV-Cache): FIFO und Speicherreservierung
- Stapelverarbeitung von Anfragen (Batching)
- Modellspezifische Optimierung (Paged Attention)
- Quantisierung: Fähigkeit quantisierte Modelle zu nutzen
Inference-Server:
- HTTP/gRPC-APIs: z.B. OpenAI API
- Verwaltung der Anfrage-Warteschlangen (Queuing)
- Multi-Modell-Unterstützung
- Multi-Engine-Unterstützung
Gängige Inference Server / Engines
Open-Source (und Open-Weight) Modelle können in unterschiedlichen Binärformaten vorliegen:
- PyTorch Format: PyTorch-Modellgewichte werden mit dem Pickle-Dienstprogramm von Python in einer bin-Datei gespeichert.
- Safetensors Format: Safetensors ist ein von Hugging Face entwickeltes sicheres und schnelles Dateiformat zum Speichern und Laden von Tensoren.
- Quantisierte Modelle: GGUF
Nicht jede Inference-Engine kann jedes Modell Speicher-Format verwenden.
Ollama
Ollama ist ein in der Programmiersprache Go programmierter OpenAI kompatibler Server, der die Inference-Engine llama.cpp nutzt. llama.cpp ist eine in C/C++ geschriebene Inference-Engine. llama.cpp kann Modelle ausführen, welche im GGUF Dateiformat vorliegen. GGUF ist ein binäres Dateiformat für Inference mit der Tensor-Bibliothek für maschinelles Lernen GGML.
llama-cpp-python
Die Python-Bindings llama-cpp-python für llama.cpp stellen ebenfalls einen OpenAI API-Schema kompatiblen Web-Server zur Verfügung.
vLLM
vLLM ist eine High-Performance Inference-Engine, die speziell für den produktiven Einsatz von großen Sprachmodellen entwickelt wurde. Aufgrund seiner herausragenden Performance und Effizienz wurde vLLM als Standard-Engine für die Referenzarchitektur ausgewählt.
Warum vLLM? Die technischen Vorteile:
-
PagedAttention (Effizientes Speicher-Management): Das Hauptproblem bei LLM-Inference ist der Speicherbedarf für den Key-Value (KV) Cache, der mit der Länge der Konversation wächst. Traditionelle Engines reservieren Speicherblöcke "auf Verdacht", was zu massiver Fragmentierung und Verschwendung von VRAM führt (oft 60-80% Verschnitt). vLLM nutzt PagedAttention, eine Technik, die vom virtuellen Speichermanagement in Betriebssystemen inspiriert ist. Der KV-Cache wird in nicht-zusammenhängende Blöcke aufgeteilt. Dies erlaubt eine nahezu vollständige Auslastung des GPU-Speichers und ermöglicht deutlich größere Batch-Größen (mehr gleichzeitige Nutzer).
-
Continuous Batching: vLLM wartet nicht, bis alle Anfragen in einem Batch fertig sind (was bei unterschiedlich langen Antworten ineffizient wäre). Sobald eine Anfrage beendet ist, wird der frei gewordene Slot sofort für eine neue Anfrage genutzt. Dies erhöht den Durchsatz drastisch.
-
Performance: In Benchmarks liefert vLLM oft einen 2x bis 24x höheren Durchsatz als HuggingFace Transformers (TGI) oder andere Standard-Implementierungen, bei gleicher Hardware.
-
OpenAI-Kompatibilität: vLLM liefert einen API-Server mit, der vollständig kompatibel zur OpenAI-API (
/v1/chat/completions) ist. Das erleichtert die Integration in bestehende Tools (wie LangChain oder das LLM-Gateway) enorm. -
Verteilte Inferenz (Tensor Parallelism): Große Modelle (z.B. Llama-3-70B), die nicht auf eine einzelne GPU passen, können mittels Ray-Integration nahtlos auf mehrere GPUs verteilt werden.
-
Unterstützung für Quantisierung: Unterstützt moderne Quantisierungsverfahren wie AWQ, GPTQ, SqueezeLLM und FP8 KV-Cache, um Speicherbedarf weiter zu senken.
OpenLLM
OpenLLM ist ein Inference-Server welcher entweder Pytorch als Backend or vLLM als Inference-Engine verwendet. Ist ein Modell nicht für vLLM verfügbar, dann wird es mit dem Pytorch Backend geladen.
Weitere Inference-Server
- Text Generation Interface (TGI) von Hugging Face
- TorchServe
- Ray Serve
- Nvidia TensorRT-LLM (TRTLMM)
Neue Entwicklungen
Hugging Face arbeitet an einem neuen TGI Multi-Backend, das alle wesentlichen Inference-Engines kapseln soll.
