Parallax: verteilte LLM-Inferenz über Lattica, SGLang, vLLM und MLX LM

Welches Problem Parallax adressiert und für wen

Ein Modell, das nicht in den Speicher einer einzelnen Maschine passt, lässt sich auf zwei Arten betreiben: man mietet eine größere Instanz, oder man verteilt die Gewichte über mehrere Geräte. Parallax wählt den zweiten Weg und nennt als Ziel, einen AI-Cluster auf einer Menge verteilter Knoten aufzubauen, unabhängig von deren Konfiguration und physischem Standort. Die README formuliert das als Hosting lokaler LLMs auf persönlichen Geräten. Die Zielgruppe sind damit Betreiber mit mehreren eigenen Maschinen, nicht Einzelpersonen mit einer GPU. Wer nur eine Workstation besitzt, gewinnt durch die Verteilungsschicht nichts, weil die Backends SGLang und vLLM bereits ohne sie laufen. Interessant wird das Projekt erst, wenn Knoten mit unterschiedlicher Hardware oder an verschiedenen Orten zusammenarbeiten sollen. Die README nennt als eines der Kernfeatures ausdrücklich Cross-Platform-Unterstützung, was sich in der Backend-Aufteilung wiederfindet: GPUs laufen über SGLang und vLLM, Macs über MLX LM.

Lattica als P2P-Schicht und was die Backend-Trennung bedeutet

Die README beschreibt die Backend-Architektur in drei Zeilen: P2P-Kommunikation über Lattica, GPU-Backend über SGLang und vLLM, Mac-Backend über MLX LM. Das ist die zentrale Designentscheidung des Projekts. Parallax implementiert keine eigene Inferenz-Engine, sondern setzt eine Verteilungs- und Routing-Schicht über bestehende Engines. Die Modell-Shards werden über Pipeline-Parallelismus aufgeteilt, das heißt die Schichten des Netzwerks liegen auf verschiedenen Knoten und die Aktivierungen wandern zwischen ihnen. Der Datenfluss geht also nicht über einen zentralen Koordinator, der die gesamte Anfrage hält, sondern über die Lattica-Verbindungen zwischen den Knoten. Für Macs nennt die README zusätzlich Paged KV Cache Management und Continuous Batching, was auf eine eigene Anpassung an die MLX-Seite hindeutet. Bemerkenswert ist, dass die GPU-Seite auf zwei verschiedene Engines verteilt ist. Die README erklärt nicht, wann SGLang und wann vLLM zum Einsatz kommt. Diese Lücke ist relevant, weil sich die beiden Engines in Konfiguration und Speicherverhalten unterscheiden und der Betreiber wissen muss, welche er im Fehlerfall debuggt.

Installation und Start: was die README konkret vorgibt

Der Quick Install besteht aus vier Zeilen. Zuerst wird das Repository geklont, dann wechselt man hinein, führt ./install.sh aus und aktiviert die erzeugte virtuelle Umgebung mit source .venv/bin/activate. Der Start erfolgt über parallax serve -m Qwen/Qwen3.5-0.8B. Das ist ein HuggingFace-Modellbezeichner, kein lokaler Pfad, das Modell wird also beim Start heruntergeladen. Das gewählte Beispielmodell ist mit 0,8B Parametern klein genug für einen einzelnen Knoten, was für einen ersten Test sinnvoll ist, aber nichts über das Verhalten bei den großen Modellen aus der Tabelle aussagt. Die Installation legt ein .venv im Projektverzeichnis an statt eines systemweiten Environments, was die Deinstallation vereinfacht. Ob install.sh Abhängigkeiten wie CUDA-Treiber oder MLX prüft und wie es mit fehlenden Backends umgeht, geht aus dem Material nicht hervor. Wer den Cluster über mehrere Maschinen spannen will, muss zusätzlich die verlinkten Dokumente zu Installation und Quick Start lesen, da die README selbst keine Konfigurationsschlüssel für die Knotenkopplung nennt.

Unterstützte Modelle und die Grenze der README-Tabelle

Die Modelltabelle listet sieben Anbieter: DeepSeek mit V3.2 und R1, MiniMax mit M3 und M2.7, Z AI mit GLM-5.2, GLM-5.1 und GLM-4.7, Moonshot AI mit Kimi-K2-Thinking und Kimi-K2-Instruct-0905, Qwen mit Qwen3.6-35B-A3B, OpenAI mit gpt-oss-120b und gpt-oss-safeguard-120b sowie StepFun mit Step-3.5-Flash. Auffällig ist die Heterogenität: von MoE-Modellen mit sparsamer Aktivierung über reasoning-orientierte Varianten bis zu einem Sicherheitsmodell für Moderations-Workflows. Die Tabelle nennt aber nur Modellnamen und Verweise auf HuggingFace-Sammlungen und Blogs der Anbieter. Sie sagt nicht, welche Speicheranforderungen gelten, wie viele Knoten ein Modell mindestens braucht oder ob ein Modell auf der Mac-Seite überhaupt lauffähig ist. Wer Parallax für eines dieser Modelle plant, muss diese Angaben aus den Modellkarten selbst ziehen. Die Liste ist damit eine Orientierung, keine Kapazitätsplanung.

Wo Parallax das falsche Werkzeug ist

Der offensichtlichste Fehlfall ist der einzelne Knoten. Wenn das Modell in den Speicher einer Maschine passt, bringt die Pipeline-Aufteilung nur zusätzliche Latenz durch die Aktivierungsübertragung zwischen den Stufen, ohne Speicher zu sparen. Der zweite Fehlfall ist ein latenzkritischer Dienst. Pipeline-Parallelismus bedeutet, dass eine Anfrage sequenziell durch alle Stufen läuft. Bei Knoten an verschiedenen physischen Standorten addiert sich die Netzwerklaufzeit zwischen den Stufen zur Inferenzzeit. Die README nennt die Standortunabhängigkeit als Feature, sagt aber nichts über Latenzgarantien oder Timeouts. Der dritte Fehlfall ist ein Team ohne Betriebserfahrung mit verteilten Systemen. Ein Fehler in einem Shard legt die gesamte Pipeline still, und die Fehlersuche verteilt sich über mehrere Maschinen und zwei verschiedene GPU-Backends. Wer diese Betriebslast nicht tragen will, fährt mit einer einzelnen großen Instanz und vLLM besser.

Der Vergleich mit vLLM und SGLang ohne Verteilungsschicht

vLLM und SGLang sind die naheliegenden Alternativen, und Parallax nutzt sie selbst als GPU-Backend. Der Unterschied liegt nicht in der Inferenz, sondern in der Topologie. vLLM und SGLang betreiben Tensor-Parallelismus innerhalb eines Knotens über NVLink oder PCIe, also mit sehr kurzen Wegen zwischen den GPUs. Parallax setzt Pipeline-Parallelismus über Lattica ein, um Knoten zu verbinden, die gerade nicht über eine schnelle lokale Verbindung verfügen. Das sind zwei verschiedene Antworten auf dieselbe Speichergrenze. Tensor-Parallelismus skaliert besser, verlangt aber eine Maschine mit vielen GPUs. Pipeline-Parallelismus akzeptiert langsamere Verbindungen, kostet dafür Latenz pro Anfrage. Wer mehrere GPUs in einem Gehäuse hat, sollte deshalb bei vLLM oder SGLang bleiben und Parallax nicht dazwischenlegen. Interessant wird Parallax erst, wenn die Hardware nicht in ein Gehäuse passt, etwa weil ein Mac mit MLX LM als Knoten mitwirken soll. Diese Kombination aus GPU-Backends und MLX LM findet sich in den genannten Alternativen nicht.

Wartung, Releases und Lizenz

Das Repository steht unter Apache-2.0, was kommerzielle Nutzung, Änderung und Weitergabe erlaubt, sofern Lizenz- und Urheberrechtshinweise erhalten bleiben und Änderungen gekennzeichnet werden. Die Lizenz enthält eine ausdrückliche Patenterteilung. Rechtlich verbindlich ist der Lizenztext selbst, nicht diese Zusammenfassung. Die Release-Historie zeigt v0.1.0 vom 11. November 2025, v0.1.1 vom 26. November 2025 und v0.1.2 vom 2. Dezember 2025, also drei Versionen im Abstand von jeweils etwa zwei Wochen. Der letzte Push liegt laut Repository-Metadaten im Juli 2026, das Projekt ist nicht archiviert. Aus dieser Abfolge lässt sich eine schnelle frühe Entwicklungsphase ablesen, aber kein Stabilitätsversprechen. Wer Parallax produktiv einsetzt, muss mit Änderungen an Konfiguration und Verhalten zwischen Minor-Versionen rechnen und die Upgrades selbst testen. Ein Upgrade-Pfad oder eine Kompatibilitätszusage zwischen Versionen wird im vorliegenden Material nicht beschrieben. Die Abhängigkeit von Lattica als separatem Repository bedeutet zusätzlich, dass zwei Projekte im Blick behalten werden müssen.

Redaktionelles Fazit

Sinnvoll ist Parallax für Betreiber, die mehrere eigene Maschinen mit unterschiedlicher Hardware zu einem Inferenz-Verbund zusammenfassen wollen und dabei einen Mac als Backend-Knoten akzeptieren. Wer eine einzelne GPU betreibt, sollte bei vLLM oder SGLang bleiben, weil Parallax diese Backends ohnehin nur um die Verteilung herumlegt. Vor dem ersten Produktivlauf ist zu prüfen, welche Modelle in der README-Tabelle tatsächlich aufgeführt sind und ob der eigene Knoten-Mix von der Pipeline-Aufteilung profitieren kann.

Offizielle Quellen

1. GradientHQ/parallax on GitHub
2. Issues
3. License: Apache-2.0
4. README
5. Releases