Xinference: ein Inferenz-Server für LLMs, Speech und multimodale Modelle

Welches Problem Xinference löst und für wen es gedacht ist

Ein Team, das heute ein LLM ausliefern will, steht vor einer Auswahl, die sich ständig verschiebt. vLLM für hohen Durchsatz, llama.cpp für den Laptop, SGLang für bestimmte Sampling-Muster, dazu getrennte Wege für Whisper bei Speech und Diffusers bei Bildmodellen. Jede dieser Bibliotheken hat ihre eigene API, ihre eigenen Startparameter und ihre eigene Fehlerkultur. Xinference setzt eine Ebene darüber und verspricht laut README, dass man GPT gegen ein beliebiges LLM tauscht, indem man eine einzige Zeile Code ändert. Adressiert sind damit Forschende, Entwickler und Data Scientists, die Modelle lokal oder auf eigener Hardware betreiben wollen, ohne für jedes Backend eine eigene Serving-Schicht zu schreiben. Der Themenkatalog des Repositories (vllm, sglang, llamacpp, transformers, diffusers, whisper) zeigt, dass der Anspruch nicht nur Textmodelle betrifft, sondern auch Speech Recognition und multimodale Modelle. Wer ausschließlich einen einzigen Endpunkt für ein einzelnes Modell braucht, ist hier überversorgt; der Nutzen entsteht erst, wenn mehrere Modelltypen oder mehrere Backends parallel verwaltet werden müssen.

Wie die Serving-Schicht aufgebaut ist

Xinference ist in Python geschrieben und startet als Server, der Modelle als sogenannte Built-in-Modelle kennt und über eine einheitliche API bereitstellt. Die Dokumentation beschreibt den Start über ein Kommandozeilenwerkzeug, das den Server hochzieht; Modelle werden anschließend über die API oder ein Web-Interface geladen. Im Hintergrund wird nicht ein eigener Inferenz-Kern implementiert, sondern auf bestehende Engines zurückgegriffen. Das README nennt vLLM, SGLang, llama.cpp (über die eigene Bindung xllamacpp), transformers und diffusers als Backends. Für llama.cpp pflegt das Xinference-Team mit xllamacpp eine eigene Python-Bindung, die laut README Continuous Batching unterstützt. Für vLLM nennt das README einen geteilten KV-Cache über mehrere Replicas hinweg (PR #2732). Zwei weitere Punkte aus der Liste der Hot Topics sind architektonisch relevant: Auto Batch, bei dem mehrere gleichzeitige Anfragen automatisch gebündelt werden (PR #4197), und verteilte Inferenz über mehrere Worker (PR #2877). Beides deutet darauf hin, dass Xinference als Orchestrierungsschicht über den Engines arbeitet, nicht als Ersatz für sie. Die Konsequenz: Die Leistungsgrenzen und Eigenheiten der Engines schlagen durch. Ein Konfigurationsproblem in vLLM wird nicht dadurch gelöst, dass es durch Xinference aufgerufen wird.

Installation und erster Start

Das README verweist für Self-Hosting auf die Installationsseite der Dokumentation und nennt das PyPI-Paket xinference. Der übliche Weg ist eine Installation über pip, gefolgt vom Start des Servers. Die genauen Kommandos und die verfügbaren Flags stehen in der Installationsdokumentation unter inference.readthedocs.io; das README selbst gibt kein vollständiges Startbeispiel wieder, sondern verlinkt dorthin. Für Container-Umgebungen existiert ein Docker-Image unter dem Namen xprobe/xinference auf Docker Hub, wie das Docker-Pull-Badge im README belegt. Beim Start ist zu beachten, dass Xinference Abhängigkeiten wie vLLM, SGLang oder llama.cpp einbindet. Diese Pakete bringen eigene Anforderungen an CUDA, PyTorch und Python mit, und Konflikte zwischen ihnen sind der wahrscheinlichste Grund, warum eine Installation scheitert. Wer das Projekt ausprobiert, sollte die Installationsseite der Dokumentation als verbindliche Quelle für die Versionsmatrix behandeln und nicht die README-Kurzfassung. Welche Modelle nach dem Start sofort verfügbar sind, hängt von der Built-in-Liste ab; diese wird im README über die Hot-Topics-Einträge laufend erweitert.

Das Modellangebot wächst schneller als die Dokumentation

Die Liste der zuletzt aufgenommenen Modelle im README ist lang und gemischt: Kimi-K3, GLM-5.2, GLM-Image, DeepSeek-V4-Flash, mehrere Weltmodelle (Matrix-Game-3.0, HY-WorldPlay, Astra), Bildmodelle (Krea 2, HiDream-O1, Ideogram4), Audio (ACE-Step 1.5, Breeze-TTS-2) und Embedding-Modelle (WeMM-Embedding in 2B, 4B und 9B). Diese Breite ist der eigentliche Verkaufsargument des Projekts, aber sie ist auch ein Risiko. Jeder Eintrag ist ein eigener Integrationspfad mit eigenen Abhängigkeiten, eigenen Quantisierungen und eigenen Hardware-Anforderungen. Ein 397B-Modell wie Ornith-1.5-397B lässt sich nicht auf derselben Maschine betreiben wie ein 2B-Embedding-Modell. Die README-Liste sagt nichts darüber aus, welche Kombinationen gleichzeitig auf einer einzelnen GPU laufen können. Wer plant, mehrere dieser Modelle parallel zu betreiben, muss die Speicher- und Backend-Anforderungen selbst aus den jeweiligen Modellkarten ableiten. Die Geschwindigkeit, mit der neue Modelle aufgenommen werden (mehrere Pull Requests pro Woche, wie die Hot-Topics-Einträge zeigen), bedeutet außerdem, dass die Dokumentation einzelner Modelle hinterherhinken kann.

Grenzen und Fälle, in denen Xinference das falsche Werkzeug ist

Xinference ist eine Abstraktionsschicht, und Abstraktion kostet. Wer die volle Kontrolle über die Engine-Parameter eines vLLM-Deployments braucht, etwa spezifische PagedAttention-Konfigurationen oder eigene Sampling-Pipelines, wird durch die Zwischenschicht eingeschränkt. Das README beschreibt die verteilte Inferenz über Worker (PR #2877) und den geteilten KV-Cache über Replicas (PR #2732), aber beide Punkte sind als Pull Requests referenziert, nicht als ausführlich dokumentierte Betriebsmodi. Ob diese Funktionen für den eigenen Anwendungsfall ausgereift genug sind, lässt sich aus dem Material nicht beurteilen. Ein zweiter Punkt: Die OpenAI-kompatible API ist eine Nachbildung. Das README nennt sie als Ziel, aber nicht jede OpenAI-Funktion wird von jedem Backend gleich unterstützt. Wer auf spezielle Parameter wie bestimmte Tool-Calling-Formate oder strukturierte Ausgaben angewiesen ist, muss pro Modell und Backend prüfen, ob sie durchgereicht werden. Drittens: Für ein einzelnes Modell mit maximalem Durchsatz ist ein direkt konfigurierter vLLM-Server die einfachere Wahl, weil eine Fehlerebene weniger existiert. Xinference lohnt sich, wenn die Vielfalt der Modelle oder Backends der eigentliche Schmerzpunkt ist.

Alternative: vLLM direkt betreiben

Die naheliegende Alternative ist, vLLM ohne Xinference zu betreiben. Der Unterschied liegt in der Zuständigkeit. vLLM ist eine Inferenz-Engine für LLMs, die auf Durchsatz und Speichereffizienz optimiert ist. Sie bringt einen eigenen OpenAI-kompatiblen Server mit, kennt aber nur Textmodelle und kümmert sich nicht um Speech oder Diffusionsmodelle. Xinference nutzt vLLM als eines von mehreren Backends und ergänzt darum herum Modellverwaltung, Multi-Backend-Auswahl und eine einheitliche API über Modelltypen hinweg. Wer also nur ein LLM ausliefert und dessen Parameter vollständig kontrollieren will, ist mit vLLM direkt besser bedient: weniger bewegliche Teile, klarere Fehlermeldungen, direkter Zugriff auf die Engine-Konfiguration. Wer dagegen Whisper für Transkription, ein Diffusionsmodell für Bilder und ein LLM für Text gleichzeitig betreiben will, müsste ohne Xinference drei getrennte Server mit drei APIs betreiben. Genau dieser Fall rechtfertigt die zusätzliche Schicht. Eine zweite Alternative ist llama.cpp direkt, insbesondere auf Hardware ohne CUDA. Xinference bindet llama.cpp über xllamacpp ein, sodass man hier zwischen direktem Betrieb und der komfortableren Verwaltung wählen kann.

Wartung, Lizenz und Versionspflege

Das Repository steht unter Apache-2.0, einer permissiven Lizenz, die kommerzielle Nutzung und Modifikation erlaubt, solange Lizenz- und Urheberrechtshinweise erhalten bleiben. Das ist für den Einsatz in Unternehmen unkompliziert, ersetzt aber keine Rechtsberatung, insbesondere wenn man die Software weiterverbreitet oder als Teil eines eigenen Produkts anbietet. Wartungsseitig ist das Projekt aktiv: Die letzten Releases v3.3.0, v3.2.0 und v3.1.0 liegen laut Repository-Angaben im Abstand von jeweils etwa zwei Wochen, der letzte Push datiert auf September 2026. Allerdings weist das README selbst auf Breaking Changes hin: Xinference 3.0.0 wird mit Migrationshinweisen und Breaking Changes angekündigt. Wer von einer 2.x-Version aktualisiert, muss die Release Notes lesen, bevor er das Upgrade einspielt. Dazu kommt die Abhängigkeitskette: Xinference bindet vLLM, SGLang, transformers und diffusers ein, und deren Major-Updates können das Verhalten der eigenen Deployment-Pipeline verändern, ohne dass Xinference selbst eine neue Version veröffentlicht. Ein Upgrade-Pfad, der nur die Xinference-Version pinnt und die Backend-Versionen frei laufen lässt, ist damit nicht reproduzierbar. Wer den Server produktiv betreibt, sollte die Backend-Versionen ebenfalls fixieren und vor jedem Upgrade die Release Notes von Xinference und der genutzten Engine lesen.

Redaktionelles Fazit

Xinference passt zu Teams, die mehrere Modelltypen (LLM, Speech, multimodal) hinter einer einheitlichen API betreiben und dafür keine eigene Serving-Schicht bauen wollen. Wer nur ein einzelnes Modell mit maximalem Durchsatz ausliefern muss, fährt mit einem spezialisierten Server wie vLLM direkter, weil Xinference die Backend-Auswahl und das Modell-Handling als zusätzliche Abstraktionsebene dazwischenlegt. Vor dem Einsatz sollte man prüfen, ob das konkrete Zielmodell in der Built-in-Liste steht und ob die eigene Python- und CUDA-Version zu den in der Installationsdokumentation genannten Anforderungen passt, da Xinference Abhängigkeiten wie vLLM, SGLang oder llama.cpp einbindet und deren Versionskonflikte erbt.

Offizielle Quellen

1. License: Apache-2.0
2. Project website
3. README
4. Releases
5. xorbitsai/inference on GitHub