Man wählt nicht zuerst eine Inferenz-Engine aus. Man entscheidet sich für eine Hardware-Strategie, eine Workload-Form und ein Serving-Modell. Die Engine folgt daraus.
Das ist der nützlichste Ansatz, um über LLM-Inferenz-Engines nachzudenken.
Seriennotiz: Dies ist Teil 3 meiner Serie über selbst gehostete LLMs / Lokale KI.
- Teil 1: GPU-Speicher-Mathematik für LLMs (Ausgabe 2026).
- Teil 2: Speicherbandbreite für Lokale KI-Hardware (Ausgabe 2026).
Diese beiden Teile erklären die Hardware-Kapazitäts- und Bandbreiten-Mathematik.
Dieser Teil erklärt die Software-Ebene, die diese Hardware in nutzbare Inferenz verwandelt.
Engines
Diese Werkzeuge dienen unterschiedlichen Zwecken / befinden sich auf unterschiedlichen Ebenen
- Lokale Portabilität
- Consumer-CUDA
- Apple-Unified-Memory-Workflows
- Quantisierte Inferenz
- Produktions-Serving
- Verteiltes Orchestrieren
- Anbieteroptimierte Rechenzentrumsausführung
Ein nützliches mentales Modell:
Die Inferenz-Engine ist nicht "das Modell". Sie ist der Verkehrspolizist, der Speicherverwalter, der Kernel-Dispatcher, der Scheduler, der Cache-Buchhalter, der Parallelitätsplaner, die API-Oberfläche und manchmal das Deployment-Framework.
Die beste Engine passt zu deiner Speicherhierarchie, deinem Interconnect, deinem Quantisierungsformat, deinen Latenz- und Durchsatz-Zielen, deiner Modellarchitektur und deiner operativen Reife.
Der einseitige Entscheidungsleitfaden
- Laptop / Edge / exotische Hardware → llama.cpp
- Mac-zentrierte Workflows → MLX / MLX-LM
- Einzelne RTX für lokale Inferenz → ExLlamaV2
- 2-4+ NVIDIA / CUDA GPUs → ExLlamaV3
- Allgemeines Produktions-Serving → vLLM
- Langer Kontext / MoE / Routing → SGLang
- NVIDIA Maximalleistung → TensorRT-LLM
- Cluster-Orchestrierung → NVIDIA Dynamo
Der Rest dieses Leitfadens erklärt warum.
Was eine Inferenz-Engine tatsächlich tut
Eine Inferenz-Engine lädt Gewichte, tokenisiert Eingaben, führt den Forward-Pass aus, sampelt Token, verwaltet den KV-Cache und streamt Ergebnisse. Ernsthafte Engines kümmern sich auch um Batching, Scheduling, Prefix-Caching, Quantisierung, parallele Ausführung, API-Serving, Metriken und verteilte Ausführung.
Der Workload hat zwei Phasen:
Prefill liest den Prompt und baut den initialen KV-Cache auf. Es ist rechenintensiv.
Decode generiert ein Token nach dem anderen und liest dabei wiederholt Gewichte und den KV-Cache. Es ist speicherbandbreitenbegrenzt. Die Decode-Geschwindigkeit folgt eher der Speicherbandbreite als der Spitzenrechenleistung.
Diese Unterscheidung erklärt fast alles:
- Kurzer Prompt, lange Antwort: Decode dominiert → Speicherbandbreite und Batching sind wichtig.
- Langer Prompt, kurze Antwort: Prefill dominiert → Attention-Kernel und Chunked-Prefill sind wichtig.
- Viele Nutzer: Scheduler-Qualität ist wichtig → kontinuierliches Batching, Cache-Paging, Fairness.
- Langer Kontext: KV-Cache dominiert → Paged-Attention, KV-Quantisierung, Offloading.
- MoE: Experten-Routing dominiert → Experten-Parallelität, Interconnect, gruppierte GEMMs.
- Multi-Node: Interconnect dominiert → NVLink, RDMA, Pipeline-Parallelität, Disaggregation.
PagedAttention hat die KV-Cache-Fragmentierung angegangen. FlashAttention hat IO-bewusstes Tiling verwendet, um den HBM (High Bandwidth Memory) Verkehr zu reduzieren. Spekulatives Decoding entwirft günstige Token und verifiziert sie parallel. Das wiederkehrende Thema: Inferenzleistung ist Speicherbewegung plus Scheduling.
Die wahren Engpässe
- Speicherbandbreite, nicht nur VRAM-Größe. VRAM bestimmt, ob etwas passt. Bandbreite bestimmt die Decode-Geschwindigkeit. Der M3 Ultra von Apple bietet bis zu 819 GB/s Unified-Memory-Bandbreite. Der H100 SXM von NVIDIA listet 3,35 TB/s GPU-Speicherbandbreite. Unified Memory erlaubt dir, Modelle unterzubringen, die nicht in den Consumer-VRAM passen. HBM erlaubt dir, sie schneller zu bedienen, wenn das Modell passt. Passen ist nicht Geschwindigkeit. Kapazität ist nicht Bandbreite.
- KV-Cache-Wachstum. Der KV-Cache wächst mit Batch-Größe und Kontextlänge. Workloads mit langem Kontext können den Speicher erschöpfen, selbst wenn die Gewichte passen. PagedAttention partitioniert den KV-Cache in Blöcke, erhöht die Auslastung und unterstützt größere Batches.
- Interconnect. Sobald ein Modell GPU-Grenzen überschreitet (multi-GPU), zahlst du Kommunikationskosten. Tensor-Parallelität benötigt häufige All-Reduce-Kollektive. Pipeline-Parallelität kommuniziert an Stufengrenzen. Experten-Parallelität benötigt All-to-All-Verkehr für MoE. Die Dokumentation von vLLM merkt an, dass ohne NVLink die Pipeline-Parallelität die Tensor-Parallelität übertreffen kann.
- Scheduler-Qualität. Ein guter Scheduler entscheidet, welche Anfragen in den Batch kommen, wie Prefill und Decode den Beschleuniger teilen, ob lange Prompts kurze Decodes blockieren und wie man Verhungern (Starvation) vermeidet. Batching zu unterstützen ist nicht dasselbe, wie sich wie ein produktionsreifer Scheduler zu verhalten.
- Laufzeit-Overhead. CUDA-Graphen, Kernel-Fusion, Sampling-Overhead, Tokenizer-Overhead, HTTP-Overhead, LoRA-Wechsel und strukturiertes Decoding sind alle relevant. Im großen Maßstab bilden die lästigen 2%-Overheads eine Gewerkschaft und erfordern Aufmerksamkeit (Wortspiel beabsichtigt?).
Die Engine-Familien
Es gibt vier große Familien:
Portable lokale Laufzeiten: llama.cpp, MLC LLM, ONNX Runtime GenAI, OpenVINO, Ollama-artige Werkzeuge. Sie kümmern sich darum, "es hier zum Laufen zu bringen".
Apple/Unified-Memory-Laufzeiten: MLX und MLX-LM. Sie kümmern sich darum, "großen gemeinsamen Speicher und den Apple-Stack gut zu nutzen".
Consumer-CUDA-Quantisierungs-Engines: ExLlamaV2 und ExLlamaV3. Sie kümmern sich darum, "meine 3090/4090/5090-Kiste mit niedrig-bitigen Gewichten zum Schreien zu bringen".
Produktions-Serving-Engines: vLLM, SGLang, TensorRT-LLM, TGI, LMDeploy. Sie kümmern sich um gleichzeitige Nutzer, KV-Cache, Batching, Parallelität, Beobachtbarkeit und Kosten pro Token.
Dann gibt es noch Orchestrierungsschichten wie Dynamo, die über den Engines sitzen und Flotten, disaggregiertes Prefill/Decode, Routing und Autoscaling koordinieren.
llama.cpp: der König der Portabilität
llama.cpp ist die Antwort, wenn die Hardware exotisch, eingeschränkt, offline, CPU-lastig, Edge-orientiert oder kein ordentlicher NVIDIA-Rechenzentrumsknoten ist.
Es unterstützt Apple Silicon via ARM NEON, Accelerate und Metal; x86 via AVX/AVX2/AVX512/AMX; RISC-V; Low-Bit-Quantisierung; CUDA; AMD via HIP; MUSA; Vulkan; SYCL; und CPU+GPU-Hybrid-Offloading. Deshalb besitzt llama.cpp die "Bring es einfach zum Laufen"-Spur.
Der HTTP-Server ist leistungsfähiger als ein "Spielzeug-Lokal-Runner". llama-server bietet OpenAI-kompatible Routen, Anthropic Messages API-Kompatibilität, Re-Ranking, kontinuierliches Batching, multimodale Unterstützung, JSON-Schema-Einschränkungen, Funktionsaufrufe, spekulatives Decoding und eine Weboberfläche.
Die entscheidende Einschränkung: llama.cpp ist nicht für ernsthaftes Multi-Node-Produktions-Serving gedacht. Sein RPC-Backend wird ausdrücklich als Proof-of-Concept dokumentiert, fragil und unsicher.
Fazit: Verwende llama.cpp, wenn Portabilität, Offline-Betrieb, GGUF oder Hybrid-Offloading wichtiger sind als Flotten-Serving.
NICHT verwenden mit Multi-GPUs
MLX und MLX-LM: die Apple Silicon Waffe
MLX ist Apples Array-Framework für Apple Silicon, und MLX-LM ist das darauf aufbauende LLM-Paket. Es ist ein Mac-zentrierter ML-Stack.
Die entscheidende Hardware-Tatsache ist Unified Memory. Apple Silicon gibt CPU und GPU direkten Zugriff auf denselben Speicherpool. MLX-Arrays leben im Unified Memory, und du wählst das Gerät, wenn du die Operation ausführst, anstatt Arrays zwischen getrennten Speicherbereichen zu verschieben.
Dies verändert den Kompromiss bei der lokalen Inferenz. Bei einem System mit diskreter GPU lautet die Frage "Passt es in den VRAM?". Bei einem M-Series Mac mit großem Unified Memory wird daraus "Passt es in den Speicher, und kann das Speichersystem die GPU schnell genug füttern?". Große quantisierte Modelle können auf Maschinen laufen, auf denen dasselbe Modell auf einer 24 GB Consumer-GPU unmöglich wäre.
Allerdings ist es auch langsamer.
MLX-LM fügt Hugging Face Hub-Integration, Quantisierung, LoRA und vollständiges Fine-Tuning, verteilte Inferenz und ein großes MLX Community-Modell-Ökosystem hinzu. MLX ist nicht mehr Mac-exklusiv: es bietet CUDA- und CPU-only-Pakete für Linux. Verteilte Kommunikation unterstützt MPI, Ring over TCP, JACCL für RDMA über Thunderbolt und NCCL für CUDA.
Der MLX-LM-Server selbst warnt, dass er für die Produktion nicht empfohlen wird, da er nur grundlegende Sicherheitsprüfungen implementiert.
Fazit: Verwende MLX für Mac-zentrierte ML- und LLM-Workflows. Für öffentliches Serving mit hoher Parallelität beginne mit einem echten Serving-Stack.
ExLlamaV2 und V3: Consumer-CUDA, abgestimmt und schnell
ExLlamaV2 ist die lokale CUDA-Quantisierungs-Engine für Leute, die eine Consumer-NVIDIA-GPU über ihrem Gewicht schlagen lassen wollen. Es unterstützt Paged-Attention, dynamisches Batching, Prompt-Caching, KV-Cache-Deduplizierung, Batch-Generierung, Streaming und spekulatives Decoding. Das Schlüsselwort ist lokal. Es macht quantisierte Modelle auf modernen CUDA-GPUs schnell, besonders auf Consumer-Karten.
Beste Einsätze: Eine Kiste mit RTX 3090/4090/5090, lokaler Codierungs-Assistent, lokaler Chat, EXL2-quantisierte Modelle und Prosumer-Workstation-Nutzung.
ExLlamaV3 erweitert die Philosophie in Richtung Multi-GPU und MoE-lokale Inferenz. Es fügt das EXL3-Quantisierungsformat basierend auf QTIP hinzu, flexible Tensor-Parallel- und Experten-Parallel-Inferenz für Consumer-Hardware, einen OpenAI-kompatiblen Server durch TabbyAPI, kontinuierliches dynamisches Batching und multimodale Unterstützung.
V3 ist überzeugend, wenn du 2-4+ Consumer-NVIDIA-GPUs hast oder lokales MoE willst. Erwarte Einschränkungen: Einige Modelle unterstützen Tensor- oder Experten-Parallelität in ExLlamaV3 nicht.
Fazit: ExLlamaV2 ist die Enthusiasten-Engine für lokale CUDA. ExLlamaV3 ist die Grenze für Multi-GPU (2-4) lokale Setups. Erwarte rauere Kanten für bessere Fähigkeiten.
vLLM: der standardmäßige Open-Source-Produktionsserver
vLLM ist die erste Engine, die die meisten Teams für ernsthaftes Open-Source-LLM-Serving evaluieren sollten.
Es bietet PagedAttention-basiertes KV-Speichermanagement, kontinuierliches Batching, Chunked-Prefill, Prefix-Caching, CUDA/HIP-Graphen, umfangreiche Quantisierung (FP8, MXFP8/MXFP4, NVFP4, INT8, INT4, GPTQ, AWQ, GGUF), optimierte Attention- und GEMM/MoE-Kernel, spekulatives Decoding, torch.compile und disaggregiertes Prefill/Decode/Encode.
Es ist auch flexibel: Tensor-/Pipeline-/Daten-/Experten-/Kontext-Parallelität, Streaming, strukturierte Ausgaben, Tool-Aufrufe, OpenAI-kompatible und Anthropic Messages APIs, gRPC, Multi-LoRA und Unterstützung für NVIDIA, AMD, x86/ARM/PowerPC CPUs, plus Plugins für TPUs, Gaudi, Ascend, Apple Silicon und mehr.
Die Dokumentation von vLLM merkt an, dass Multi-Node-Deployments typischerweise Ray verwenden, und ohne NVLink kann Pipeline-Parallelität Tensor-Parallelität schlagen. Die Falle ist anzunehmen, dass vLLM die Notwendigkeit von Systemdenken beseitigt. Du musst immer noch Batching, Kontextlänge, GPU-Speicherauslastung, Parallelitätsanordnung und Routing tunen. vLLM gibt dir eine sehr gute Engine; es erfordert immer noch gutes Systemdesign.
Fazit: Wenn jemand sagt "wir müssen offene Modelle in der Produktion bereitstellen", ist vLLM der standardmäßige Startpunkt.
SGLang: vLLMs systemdenkender Cousin
SGLang ist das, was du verwendest, wenn der Serving-Workload hässlich ist: strukturierte Ausgaben, langer Kontext, MoE, Disaggregation und Routing.
Es bietet RadixAttention-Prefix-Caching, Prefill-Decode-Disaggregation, spekulatives Decoding, kontinuierliches Batching, Paged-Attention, Tensor-/Pipeline-/Experten-/Daten-Parallelität, strukturierte Ausgaben, Chunked-Prefill und Multi-LoRA-Batching. Es unterstützt NVIDIA, AMD, Intel Xeon, Google TPUs, Ascend NPUs und mehr.
SGLangs Unterscheidungsmerkmal ist die Serving-Architektur. Seine Prefill-Decode-Disaggregation trennt das rechenintensive Prefill vom speicherintensiven Decode in spezialisierte Instanzen und überträgt den KV-Cache zwischen ihnen. Dies verhindert, dass lange Prefill-Batches den Decode unterbrechen und die Token-Latenz in die Höhe treiben.
Fazit: SGLang ist für Teams, deren Engpass nicht mehr "können wir das Modell ausführen?" ist, sondern "können wir es unter feindlichem Verkehr ausführen, ohne Latenz, Speicher und Kosten in die Höhe zu treiben?"
TensorRT-LLM: Maximale NVIDIA-Leistung
TensorRT-LLM ist der NVIDIA-Maximalleistungs-Stack. Er ist optimiert, spezialisiert, leistungsstark und gibt nicht vor, portabel zu sein.
Er bietet Python-APIs zum Bauen von TensorRT-Engines mit hochmodernen Optimierungen, plus Python- und C++-Laufzeiten. Er enthält benutzerdefinierte Kernel für Attention, GEMMs und MoE; Prefill-Decode-Disaggregation, Wide Expert Parallelism, spekulatives Decoding; und eine High-Level-Python-API, die in NVIDIA Dynamo und Triton Inference Server integriert ist.
B200-GPUs können FP4-Gewichte mit optimierten Kerneln laden. H100 und später unterstützen FP8-Quantisierung, die die Leistung verdoppeln und den Speicherverbrauch im Vergleich zu 16 Bit bei minimalem Genauigkeitsverlust halbieren kann.
Wo er glänzt: H100/H200/B200/GB200/GB300-Klassen-Flotten, NVIDIA-only-Rechenzentren, FP8/FP4-Deployment, Multi-Node-Serving und MoE im großen Maßstab. Wo er umständlich ist: AMD-, Apple- oder Intel-Portabilität; sich schnell ändernde experimentelle Modelle; kleine lokale Setups; und Teams, die "funktioniert auf allem" brauchen.
Fazit: Wenn du dich für NVIDIA entschieden hast und dir absolute Leistung wichtig ist, gehört TensorRT-LLM in den Vergleich. Du tauschst Portabilität gegen Leistung. Abgestimmte Spezialisierung, aber weniger Funktionen.
Der Rest des Feldes
TGI ist Hugging Faces Produktionsserver mit Tracing, Metriken, Tensor-Parallelität und kontinuierlichem Batching. Verwende es, wenn HF-Integration und Einfachheit wichtig sind.
MLC LLM ist die Compiler-zentrierte universelle Deployment-Engine mit OpenAI-kompatiblen APIs über REST, Python, JavaScript, iOS und Android. Am besten für "LLMs überall hin ausliefern", besonders Browser, Mobilgeräte und native Apps.
ONNX Runtime GenAI implementiert die vollständige generative Schleife über ONNX Runtime und betreibt Foundry Local, Windows ML und das VS Code AI Toolkit. Es unterstützt CPU, CUDA, DirectML, TensorRT-RTX, OpenVINO, QNN, WebGPU und AMD GPU. Am besten für App-Deployment und ONNX-Workflows.
OpenVINO GenAI ist die Intel-optimierte Geschichte für Xeon-CPUs, Arc-GPUs, Core Ultra und NPUs. Es bietet OpenAI-kompatibles Serving mit kontinuierlichem Batching und Paged-Attention. Am besten für Intel-Hardware.
LMDeploy ist ein CUDA-zentriertes Toolkit mit TurboMind für Leistung und PyTorch für Zugänglichkeit. Am interessantesten für CUDA-Nutzer, die eine Alternative zu vLLM/SGLang/TensorRT-LLM suchen.
NVIDIA Dynamo ist eine verteilte Orchestrierungsschicht über Engines wie vLLM, SGLang und TensorRT-LLM und unterstützt Disaggregation, intelligentes Routing und mehrstufiges KV-Caching. Verwende es, wenn Single-Engine-Serving nicht mehr ausreicht.
Hinweis: Verwende NICHT Ollama.
Hardware-Strategie-Rezepte
CPU-only-Server: Zuerst llama.cpp. OpenVINO für Intel Xeon. ONNX Runtime GenAI für App-/ONNX-Deployment.
MacBook / Mac Studio: MLX / MLX-LM für Mac-native Workflows. llama.cpp für GGUF-Portabilität.
Einzelne RTX 3090 / 4090 / 5090: ExLlamaV2 für EXL2-lokale Inferenz. llama.cpp für GGUF oder Portabilität. vLLM, wenn mehrere Nutzer bedient werden.
Doppel- oder Vierfach-Consumer-RTX-Kiste: ExLlamaV3 für Multi-GPU-quantisierte Inferenz oder MoE. vLLM, wenn Serving-Verhalten wichtig ist. SGLang, wenn Routing oder Long-Context-Muster getestet werden.
8×H100 / H200-Knoten: Beginne mit vLLM oder SGLang. Vergleiche TensorRT-LLM, wenn NVIDIA-only und Leistung das Tuning rechtfertigt. Verwende Dynamo, wenn Multi-Node-Orchestrierung notwendig wird.
B200 / GB200 / GB300-Klassen-Infrastruktur: Vergleiche TensorRT-LLM, SGLang und vLLM. Füge Dynamo für Flotten-Orchestrierung, KV-bewusstes Routing und Autoscaling hinzu.
AMD MI300 / MI325 / MI350 / MI355: Beginne mit vLLM oder SGLang auf ROCm. Vermeide die Annahme, dass NVIDIA-Benchmarks sauber übertragbar sind.
Intel Xeon / Core Ultra / Arc: OpenVINO GenAI oder OpenVINO Model Server. ONNX Runtime GenAI, wenn App-Einbettung wichtig ist.
Browser, Mobilgerät, App-nativ: MLC LLM / WebLLM oder ONNX Runtime GenAI.
Benchmarking: was messen
Schlechter Benchmark: "Ich habe 180 tok/s erreicht."
Guter Benchmark beinhaltet:
Modell: genaues Modell, Architektur, Parameteranzahl, aktive MoE-Parameter.
Gewichte: dtype, Quantisierungsformat, Gruppengröße, Kalibrierung.
Engine: Version, Commit, Backend, Flags.
Hardware: GPU-SKU, Speicherkapazität, Bandbreite, Interconnect, CPU, RAM.
Workload: Eingabe-/Ausgabelängenverteilungen, Parallelität, Streaming, gemeinsame Präfixe, strukturierte Ausgabe.
Metriken: TTFT, TPOT, Ende-zu-Ende-Latenz, p50/p95/p99, Token pro Sekunde, Anfragen pro Sekunde, GPU-Speichernutzung, KV-Cache-Trefferquote, Prefill-Durchsatz, Decode-Durchsatz, Kosten pro 1M Token.
Benchmarking-Regeln:
- Vergleiche Engines niemals nur mit Single-User-Token pro Sekunde.
- Teste deine tatsächliche Prompt- und Ausgabeverteilung.
- Teste mit realistischer Parallelität.
- Trenne Prefill von Decode.
- Verfolge p95 und p99, nicht nur Durchschnitte.
- Messe den Speicherspielraum bei der Zielkontextlänge.
- Teste die Cache-Wiederverwendung, wenn deine App wiederholte Präfixe hat.
- Benchmarke strukturierte Ausgaben separat; Grammatik fügt Overhead hinzu.
- Benchmarke LoRA und Multi-LoRA separat.
- Teste erneut nach Treiber-, CUDA-, ROCm-, Modell- oder Engine-Upgrades.
Häufige Fehler
Wahl allein nach VRAM-Kapazität. VRAM bestimmt, ob etwas passt. Bandbreite und Scheduler bestimmen die Geschwindigkeit. Eine Maschine mit großem Unified Memory kann riesige Modelle aufnehmen, aber ein H100 decodiert schneller, wenn das Modell passt, aufgrund der viel höheren HBM-Bandbreite.
Verwendung von Tensor-Parallelität bei schwachem Interconnect. Ohne NVLink oder NVSwitch, teste Pipeline-Parallelität. Die vLLM-Dokumentation weist darauf für L40S-ähnliche Setups hin.
Ignorieren des KV-Cache. Langer Kontext und Parallelität können den KV-Cache zum limitierenden Faktor machen. PagedAttention, Prefix-Caching, KV-Quantisierung und Disaggregation sind im großen Maßstab nicht optional.
Behandlung lokaler Engines als Produktionsserver. Der llama.cpp-Server ist fähig. Der MLX-LM-Server ist praktisch. Ollama ist angenehm, sollte aber NICHT VERWENDET WERDEN.
Produktion bedeutet jedoch Sicherheit, Beobachtbarkeit, Gegendruck, Routing, Autoscaling und SLA-Verhalten. MLX-LM selbst warnt, dass sein Server nicht für die Produktion empfohlen wird.
Annahme, dass jedes Quantisierungsformat portabel ist. GGUF, EXL2, EXL3, AWQ, GPTQ, FP8, FP4, MLX-Formate und ONNX sind nicht austauschbar. Das richtige Format ist das, für das deine Engine optimierte Kernel hat.
Ignorieren der Modellarchitektur. Dichte Modelle, MoE, hybride Attention, multimodale Modelle und Varianten mit langem Kontext belasten unterschiedliche Teile der Engine. Breite Unterstützung bedeutet nicht, dass jede Optimierung gleich gut funktioniert.
Vertrauen auf Benchmark-Diagramme ohne Workload-Form. Ein Diagramm für Llama 3.1 8B bei 1K Eingabe / 128 Ausgabe sagt wenig über einen Coding-Agenten mit 80K Kontext, der auf Qwen 3.6 27B / Gemma 4 26B-A4B läuft, oder einen RAG-Dienst mit 500 gleichzeitigen Nutzern.
Die meinungsstarke finale Karte
Lokaler KI-Nutzer: LM Studio oder Harbor für Bequemlichkeit. llama.cpp für Kontrolle. MLX auf dem Mac. ExLlamaV2/V3 für CUDA-lokale Leistung.
Bauen eines lokalen Agenten: Jedes sollte funktionieren, aber angesichts dessen, was die meisten verwenden; llama.cpp für Portabilität. MLX, wenn die Nutzer auf Apple Silicon sind. vLLM, wenn Produktions-Serving lokal simuliert wird.
Bedienen eines internen Teams: Beginne mit vLLM. Verwende SGLang, wenn strukturierte Ausgaben, langer Kontext, Multi-LoRA, MoE oder Routing wichtig sind.
Bedienen von Kunden im großen Maßstab: Vergleiche vLLM, SGLang und TensorRT-LLM. Wenn Routing und Disaggregation wichtig sind, verdienen SGLang und Dynamo Aufmerksamkeit.
NVIDIA-Rechenzentrum: TensorRT-LLM für maximale Leistung. vLLM für Flexibilität. SGLang für komplexes Serving. Dynamo für Flotten-Orchestrierung.
Apple Silicon: MLX für native Entwicklung. llama.cpp für GGUF. Unified Memory ist eine Kapazitäts-Superkraft mit Bandbreiten-Kompromissen, nicht HBM.
Edge, App, Browser oder Windows-nativ: llama.cpp, MLC LLM, ONNX Runtime GenAI oder OpenVINO, abhängig vom Stack.
Abschließendes Prinzip
Inferenz-Engines haben Konsequenzen.
Wähle die Engine, nachdem du diese beantwortet hast:
- Welche Hardware habe ich tatsächlich?
- Passt das Modell in schnellen Speicher, oder nur in System-/Unified-Memory?
- Ist Decode oder Prefill der Engpass?
- Welche Kontextlänge und Parallelität sind relevant?
- Sind Prompts geteilt genug für Prefix-Caching?
- Ist das Modell dicht, MoE, multimodal oder hybrid?
- Brauche ich lokale Bequemlichkeit, Produktions-Serving oder Flotten-Orchestrierung?
- Welches Quantisierungsformat hat optimierte Kernel auf meiner Ziel-Engine?
- Ist mein Interconnect PCIe, NVLink, NVSwitch, Ethernet, RDMA oder Thunderbolt?
- Optimiere ich für Latenz, Durchsatz, Kosten, Privatsphäre, Portabilität oder Entwicklungsgeschwindigkeit?
Die Engine folgt den Antworten.
Bis zum nächsten Mal.
-Ahmad
