MLC LLM: LLM-Inferenz als Compiler-Problem

Ein Compiler, kein Loader

Die meisten LLM-Runtimes laden ein vorkonvertiertes Gewichtsformat und führen es auf einem festen Satz von Kernel-Pfaden aus. MLC LLM beschreibt sich selbst als Compiler und Deployment-Engine und geht den umgekehrten Weg: Das Modell wird zusammen mit den Zielbeschleunigern übersetzt, bevor es läuft. Das ist eine andere Fehlerklasse. Ein Ladefehler tritt zur Laufzeit auf, ein Kompilierfehler beim Build. Wer den Build einmal durchlaufen hat, bekommt dafür ein Artefakt, das auf dem gewählten Backend ohne Zwischenschicht läuft. Die Zielgruppe sind entsprechend nicht Anwender, die ein Chat-Modell starten wollen, sondern Teams, die ein Modell auf mehreren Geräteklassen ausliefern und dabei nicht für jede Plattform eine eigene Inferenzschicht pflegen wollen.

Was die Plattformtabelle tatsächlich zusagt

Das README listet die unterstützten Kombinationen in einer Matrix. Auf Linux und Windows sind Vulkan und ROCm für AMD-GPUs vermerkt, Vulkan und CUDA für NVIDIA, Vulkan für Intel. Auf macOS laufen Metal-Pfade für AMD-dGPU, Apple-GPU und Intel-iGPU. Im Browser werden WebGPU und WASM genannt, auf iOS und iPadOS Metal auf A-Serie-GPUs, auf Android OpenCL auf Adreno und auf Mali. Diese Matrix ist der Kern der Projektentscheidung, nicht die Beschreibung. Sie sagt nicht, dass alle Backends gleich schnell oder gleich vollständig sind. Sie sagt, welche Kombinationen überhaupt vorgesehen sind. Wer eine GPU-Klasse außerhalb dieser Zeilen plant, baut gegen etwas, das im Material nicht zugesagt wird. Eine Leistungsaussage lässt sich aus der Matrix nicht ableiten, und das README macht auch keine.

MLCEngine als gemeinsame Laufzeit

Der kompilierte Code läuft auf MLCEngine, das laut README eine einheitliche Inferenz-Engine über den genannten Plattformen ist. Entscheidend ist die Schnittstelle: MLCEngine bietet eine OpenAI-kompatible API, erreichbar über einen REST-Server, über Python, über JavaScript sowie über iOS und Android. Dieselbe Engine und derselbe Compiler liegen darunter. Der praktische Gewinn liegt in der Client-Seite. Eine Anwendung, die gegen die OpenAI-API geschrieben ist, kann gegen den lokalen REST-Server zeigen, ohne die Aufrufe umzuschreiben. Der Verlust liegt in der Abstraktion selbst: Was zwischen Client und Modell normalisiert wird, lässt sich nicht mehr pro Backend von Hand justieren. Wer pro Plattform eigene Kernel-Tuning-Parameter setzen will, arbeitet gegen diese Schicht.

Installation und der erste Build

Das README verweist für den Einstieg auf die Dokumentationsseiten llm.mlc.ai/docs/install/mlc_llm und get_started/quick_start statt Befehle im Repository selbst zu nennen. Das ist eine bewusste Auslagerung, hat aber eine Folge: Die Installationsschritte liegen nicht im Repository-Material, das hier vorliegt, und lassen sich daraus nicht wiedergeben. Faktisch heißt das für die Bewertung, dass der Einstieg über die Dokumentation erfolgen muss und nicht über eine im README abgedruckte Befehlsfolge. Die Lizenz ist Apache-2.0, angegeben über das LICENSE-File im Repository. Für die Weitergabe eigener Anwendungen ist das eine permissive Ausgangslage. Rechtlich verbindlich ist der Lizenztext selbst, nicht die Kurzangabe im Badge.

Die Compiler-Abhängigkeit als Wartungsposten

MLC LLM ruht auf TVM und auf zwei Verfahren aus der TVM-Forschung: TensorIR als Abstraktion für automatische Tensor-Programm-Optimierung und MetaSchedule für Tensor-Programm-Optimierung mit probabilistischen Programmen. Beide sind im README über die zitierten Paper belegt. Das ist keine Fußnote, sondern die eigentliche Wartungslast. Wer den Build reproduzieren will, muss die Toolchain-Versionen von TVM und der Relax-Ebene mit der von MLC LLM abstimmen. Der Release-Stand verstärkt das: Als jüngster Eintrag ist v0.1.dev0 vom 29. April 2023 verzeichnet, ein Entwicklungs-Tag. Wer auf nummerierte Releases setzt, findet hier keinen Anker. Die Lizenzangabe Apache-2.0 bezieht sich auf dieses Repository; die Abhängigkeiten bringen eigene Lizenzen mit, die separat zu prüfen sind. Rechtsberatung ist das nicht.

Wann MLC LLM das falsche Werkzeug ist

Der Build-Schritt ist die Grenze. Wenn ein Modell in wenigen Minuten auf einer einzelnen Maschine laufen soll und Portabilität keine Rolle spielt, ist ein Runtime-Projekt ohne Kompilierung der kürzere Weg. Ebenso, wenn das Zielgerät in der Plattformmatrix fehlt: Für eine GPU-Klasse außerhalb der genannten Zeilen gibt es laut README keine zugesagte Unterstützung. Ein dritter Fall ist die Modellseite. Die Kompilierung setzt voraus, dass die Modellarchitektur im Projekt bekannt ist. Ein sehr neues oder ungewöhnliches Modell, für das noch keine Unterstützung existiert, lässt sich nicht durch einen Schalter zum Laufen bringen. Das Material im README enthält keine Liste unterstützter Modelle und keine Aussage darüber, wie schnell neue Architekturen aufgenommen werden. Wer das vor der Entscheidung wissen muss, muss die Dokumentation prüfen, nicht das README.

Der Unterschied zu llama.cpp

llama.cpp ist der naheliegende Vergleich, weil beide lokale LLM-Inferenz auf heterogener Hardware anstreben. Der Unterschied liegt im Zeitpunkt der Übersetzung. llama.cpp liest ein Gewichtsformat und führt es über handgeschriebene Kernel-Pfade aus, mit Backends wie Metal, CUDA und Vulkan. MLC LLM kompiliert das Modell für den Zielbeschleuniger, gestützt auf TVM. Daraus folgen unterschiedliche Kostenprofile. Bei llama.cpp fällt der Aufwand beim Modellformat an, bei MLC LLM beim Build. Der zweite Unterschied ist die API-Oberfläche: MLC LLM stellt eine OpenAI-kompatible Schnittstelle über REST, Python, JavaScript, iOS und Android bereit, mit derselben Engine darunter. Wer bereits gegen die OpenAI-API entwickelt, muss weniger anpassen. Wer ein einzelnes Backend von Hand optimieren will, hat bei llama.cpp mehr Angriffsfläche. Ein Geschwindigkeitsurteil lässt sich aus dem vorliegenden Material für keine der beiden Seiten ableiten, und beide Projekte zitieren keine vergleichbaren Zahlen im README.

Wer einsteigen sollte und was zuerst zu klären ist

Der Fall, für den MLC LLM gebaut ist, ist die Auslieferung desselben Modells an mehrere Geräteklassen, ohne pro Klasse eine eigene Inferenzschicht zu schreiben. Der Browser-Pfad über WebGPU und WASM sowie die mobilen Pfade über Metal und OpenCL sind der Teil, den andere Runtimes in dieser Breite nicht abdecken. Wer dagegen ein einzelnes Modell auf einem einzelnen Server betreiben will, trägt den Compiler-Build ohne Gegenwert. Vor dem ersten Commit zu prüfen sind drei Dinge: ob die eigene GPU-Zeile in der Plattformmatrix steht, ob der Build gegen die passende TVM-Version reproduzierbar ist, und ob die eigene Anwendung mit der OpenAI-kompatiblen Oberfläche von MLCEngine auskommt oder eigene Backend-Parameter braucht. Alle drei Punkte lassen sich aus dem Repository-Material beantworten, ohne ein Modell zu kompilieren.

Redaktionelles Fazit

Wer ein Modell auf mehreren Backends gleichzeitig betreiben will, findet in MLC LLM einen Engine mit einheitlicher API und Apache-2.0-Lizenz. Wer eine fertige Binärdatei erwartet, die ein Modell ohne Build-Werkzeuge lädt, sollte zu einem Runtime-Projekt greifen. Vor dem Einsatz zu prüfen: ob der Ziel-Backend in der Plattformtabelle des Repositories auftaucht, ob das gewählte Modell Konvertierungsunterstützung hat, und ob der eigene Build-Prozess die Abhängigkeit auf den mlc-ai/relax-Fork des TVM-Compilers akzeptiert.

Offizielle Quellen

1. License: Apache-2.0
2. mlc-ai/mlc-llm on GitHub
3. Project website
4. README
5. Releases