LMDeploy: TurboMind und PyTorch Engine im Vergleich

Zwei Engines, ein Ziel: LLMs schnell und komprimiert servieren

LMDeploy löst ein konkretes Problem: Große Sprachmodelle sind zu groß und zu langsam für produktive Inferenz. Das Toolkit kombiniert Quantisierung, effiziente Batch-Verarbeitung und Serving in einem Paket. Entwickelt wurde es von den Teams hinter MMRazor und MMDeploy, beides Projekte aus dem OpenMMLab-Ökosystem. Die Zielgruppe sind Ingenieure, die eigene LLM-Services betreiben wollen, ohne von Grund auf Kernel zu schreiben. Die README nennt zwei Engines: TurboMind, eine Hochleistungs-Engine mit CUDA-Kerneln, und die PyTorch Engine, die komplett in Python geschrieben ist. Die PyTorch Engine senkt die Einstiegshürde für Experimente, während TurboMind für maximale Geschwindigkeit optimiert ist. Diese Zweiteilung ist ungewöhnlich. Die meisten Projekte setzen auf eine Engine. LMDeploy bietet beide an, was Flexibilität schafft, aber auch doppelte Wartung bedeutet.

TurboMind: Persistent Batching und blockierter KV-Cache

TurboMind ist das Herzstück von LMDeploy. Die README listet zentrale Techniken: persistent batch, also kontinuierliches Batching, blockierten KV-Cache, dynamisches Split-and-Fuse, Tensor-Parallelismus und eigene CUDA-Kernel. Diese Kombination soll laut Projektangaben bis zu 1.8x höheren Durchsatz als vLLM erreichen. Die Kernel unterstützen FlashAttention-2, Split-K Decoding und Paged Attention. Seit 2023 gibt es W4A16-Inferenz, also 4-bit Gewichte mit 16-bit Aktivierungen. Die 4-bit Inferenz soll 2.4x schneller sein als FP16. Die README verweist auf OpenCompass, um die Quantisierungsqualität zu bestätigen. Ein wichtiger Punkt: Die Kernel sind auf NVIDIA-GPUs ab V100 getestet, wie die MXFP4-Unterstützung zeigt. Wer andere Hardware nutzt, muss auf die PyTorch Engine ausweichen. Die Engine hat eine lange Entwicklungsgeschichte, von Llama-2 über DeepSeek bis Qwen3.5. Die Performance-Zahlen stammen aus den Projektmitteilungen, nicht aus unabhängigen Tests.

PyTorch Engine: Python pur und Ascend-Support

Die PyTorch Engine wurde im Januar 2024 eingeführt. Sie ist komplett in Python geschrieben und soll Entwicklern schnelle Experimente ermöglichen. Die README nennt explizit den Support für Huawei Ascend mit Graph Mode, der die Inferenzgeschwindigkeit verdoppeln soll. Diese Engine unterstützt auch Vision-Language-Modelle wie InternVL2 und LLaVA-Next. Für Unternehmen mit Ascend-Hardware ist das ein klarer Vorteil. Allerdings: Die PyTorch Engine erreicht nicht die rohe Leistung von TurboMind. Die README berichtet von 1.3x schnellerer Inferenz auf Llama3-8B durch CUDA Graph, aber das ist ein Einzelwert. Die Engine ist eher für Flexibilität gedacht, nicht für Höchstleistung. Ein Entwickler, der neue Modelle schnell testen will, profitiert von der Python-Umgebung. Wer maximale Performance braucht, sollte TurboMind wählen. Die Dokumentation empfiehlt nicht explizit, welche Engine für welchen Fall besser ist, aber die Beschreibung lässt das Muster erkennen.

Installation und erste Schritte: pip install lmdeploy

Die Installation ist einfach: `pip install lmdeploy` reicht laut README für die PyPI-Version. Seit April 2026 sind Wheel-Uploads wieder möglich, nachdem PyPI das Speicherkontingent erweitert hat. Die neueste Version ist v0.16.0 vom August 2026. Für die Nutzung gibt es einen Quick Start Guide in der Dokumentation. Die README nennt keine spezifischen Befehle für das Serving, verweist aber auf die API-Server-Dokumentation. Ein typischer Ablauf: Modell von HuggingFace laden, mit LMDeploy in ein effizientes Format konvertieren, dann über den API-Server bereitstellen. Die Quantisierung erfolgt über AWQ für 4-bit oder über llm-compressor für 4-bit symmetrische und asymmetrische Quantisierung. Die letzte Option wurde im Februar 2026 hinzugefügt. Für KV-Cache-Quantisierung gibt es eine eigene Anleitung. Das Toolkit unterstützt auch Multi-Model-Deployment über einen Proxy-Server. Die Installation setzt CUDA-fähige GPUs voraus, zumindest für TurboMind. Auf Windows läuft TurboMind nur mit Tensor-Parallelismus von 1, wie die README aus dem Jahr 2023 zeigt.

Grenzen und Fehlermodi: Wo LMDeploy das falsche Werkzeug ist

LMDeploy ist nicht für jede Umgebung geeignet. Die README zeigt, dass TurboMind stark auf NVIDIA-GPUs optimiert ist. Wer AMD-GPUs oder Apple Silicon nutzt, findet keine Unterstützung. Die PyTorch Engine unterstützt Ascend, aber nicht alle Modelle. Die README verweist auf eine Liste unterstützter Modelle, ohne sie vollständig zu zeigen. Das ist eine echte Einschränkung: Wenn das eigene Modell nicht in der Liste steht, muss man auf vLLM oder andere Tools ausweichen. Ein weiterer Punkt: Die Performance-Zahlen in der README sind Eigenangaben. Sie stammen aus Projektmitteilungen, nicht aus unabhängigen Benchmarks. Ein Ingenieur sollte diese Zahlen nicht als Garantie sehen. Die Quantisierung kann Qualitätseinbußen verursachen, auch wenn OpenCompass die Qualität bestätigt. Für rechenintensive Anwendungen mit exakten Anforderungen könnte FP16 die bessere Wahl sein. Auch die Integration mit DeepSeek-Techniken wie FlashMLA und DeepGemm ist neu und könnte Fehler enthalten. Die README erwähnt keine bekannten Probleme, aber die schnelle Release-Frequenz von v0.14.0 bis v0.16.0 in zwei Monaten deutet auf aktive Entwicklung hin.

Alternativen: vLLM und der Unterschied im Ansatz

Die README nennt vLLM mehrfach als Vergleich. vLLM ist ein etabliertes Serving-Framework mit eigener PagedAttention-Implementierung. Der Unterschied liegt in der Architektur: vLLM setzt auf eine einzige Engine, die kontinuierliches Batching und Paged KV-Cache nutzt. LMDeploy bietet mit TurboMind und PyTorch Engine zwei Pfade. vLLM hat ein breiteres Modell-Ökosystem und wird von vielen Cloud-Anbietern unterstützt. LMDeploy punktet mit der Integration von Quantisierung direkt im Toolkit. Die README behauptet, dass LMDeploy 1.8x schneller ist als vLLM, aber das ist eine Projektangabe. Ein realer Unterschied: LMDeploy unterstützt Ascend, vLLM primär NVIDIA. Für Teams, die auf Ascend setzen, ist LMDeploy die bessere Wahl. Für Teams, die maximale Kompatibilität mit vielen Modellen brauchen, bleibt vLLM der Standard. Es gibt auch andere Alternativen wie TensorRT-LLM, aber die README erwähnt sie nicht. Die Wahl hängt von der Hardware und dem Bedarf an Quantisierung ab.

Wartung und Lizenz: Apache-2.0 und aktive Entwicklung

Die Lizenz ist Apache-2.0, was kommerzielle Nutzung erlaubt, solange man die Lizenzbedingungen einhält. Das ist ein klarer Vorteil gegenüber restriktiveren Lizenzen. Die Entwicklung ist aktiv: Der letzte Push war am 19. August 2026, und es gibt regelmäßige Releases. Die README zeigt eine lange Historie von Verbesserungen, von W4A16 bis MXFP4. Das deutet auf ein gepflegtes Projekt hin. Allerdings: Die Abhängigkeit von spezifischen CUDA-Kerneln bedeutet, dass Updates auf neue GPU-Generationen Zeit brauchen. Ein Team, das LMDeploy übernimmt, muss die Release-Notes verfolgen. Die Integration mit externen Projekten wie DLSlime und Mooncake für DeepSeek zeigt, dass das Projekt auf Kooperationen setzt. Das kann Vorteile bringen, aber auch Komplexität. Die Dokumentation ist umfangreich, mit separaten Guides für Quantisierung, Ascend und API-Server. Ein Wartungsaufwand entsteht vor allem bei der Modellunterstützung: Neue Modelle erfordern oft Engine-Updates. Wer ein Modell nutzt, das nicht in der Liste steht, muss entweder warten oder selbst Code beitragen.

Redaktionelles Fazit

Wer LLMs auf NVIDIA-GPUs serviert und hohe Durchsatzraten braucht, findet in LMDeploy eine ernsthafte Option. Die README nennt 1.8x höheren Durchsatz als vLLM und 2.4x schnellere 4-bit Inferenz gegenüber FP16. Wer auf Ascend oder reine Python-Umgebungen angewiesen ist, sollte die PyTorch Engine wählen. Wer keine Quantisierung braucht und ein größeres Ökosystem bevorzugt, bleibt bei vLLM. Vor der Adoption sollte man prüfen, ob das eigene Modell in der Supported Models Liste steht und ob die CUDA-Kernel mit der eigenen GPU-Generation kompatibel sind. Die Apache-2.0 Lizenz erlaubt kommerzielle Nutzung, aber die Abhängigkeit von spezifischen Kernel-Versionen kann Wartungskosten verursachen.

Offizielle Quellen

1. Official documentation
2. Official README
3. Project repository
4. Release notes