b4rtaz/distributed-llama: LLM-Inferenz über mehrere Heimgeräte verteilen

Welches Problem die Verteilung löst und für wen sie gedacht ist

Ein Modell wie Llama 3.3 70B in der Q40-Quantisierung belegt laut README-Tabelle 40 GB. Diese Menge passt nicht in die RAM-Ausstattung eines typischen Laptops oder eines einzelnen Mini-PCs. Der Ansatz des Projekts besteht darin, die Gewichte und den Zustand des neuronalen Netzes über mehrere Geräte aufzuteilen, sodass jedes Gerät nur einen Teil halten muss. Die README formuliert das Ziel direkt: mehr Geräte bedeuten schnellere Inferenz. Die Zielgruppe sind damit Betreiber, die bereits mehrere Rechner besitzen und deren RAM sich addieren lässt, ohne dass ein einzelnes Gerät das gesamte Modell tragen muss. Das können Arbeitsstationen im Heimnetz sein, Mini-PCs oder Einplatinenrechner. Die README verweist ausdrücklich auf einen Anleitungsartikel für Raspberry Pi und auf einen Beitrag, der Llama 3.3 70B auf vier Mac Mini M4 Pro mit je 24 GB RAM beschreibt. Wer ein einzelnes Gerät mit genügend Speicher besitzt, hat keinen Grund, diesen Aufwand zu betreiben.

Root, Worker und die Aufteilung des Netzes

Die Architektur besteht aus zwei Rollen. Der Root-Knoten lädt das Modell und die Gewichte, verteilt sie an die Worker und synchronisiert den Zustand des Netzes. Er ist zugleich selbst ein Worker und verarbeitet einen eigenen Abschnitt des Netzes. Ein Worker-Knoten verarbeitet nur seinen Abschnitt und benötigt laut README keine Konfiguration, die sich auf das Modell bezieht. Das ist eine bewusste Arbeitsteilung: Die Modellkenntnis liegt an einer Stelle, die Worker bleiben austauschbar. Die Kommunikation läuft über Ethernet, wobei das Projekt nach eigener Beschreibung auf Tensor-Parallelismus und schnelle Synchronisation setzt. Der Root-Knoten braucht etwas mehr RAM als die Worker, weil er zusätzlich die Koordination trägt. In der schematischen Darstellung der README lauschen die Worker auf Port 9999, während der Root unter einer eigenen Adresse ohne Portangabe erscheint. Der Datenfluss folgt also einem Stern: Der Root verteilt und sammelt, die Worker rechnen und antworten. Diese Stern-Topologie ist der Grund, warum die Skalierung an eine Zweierpotenz gebunden ist.

Die 2^n-Regel und die KV-Head-Obergrenze

Die README nennt zwei Einschränkungen, die den praktischen Einsatzrahmen bestimmen. Erstens lässt sich das System nur auf 1, 2, 4 und allgemein 2^n Knoten betreiben. Drei Rechner, die ohnehin vorhanden sind, lassen sich nicht einfach zusammenschließen; man müsste einen vierten hinzufügen oder einen weglassen. Zweitens ist die maximale Knotenzahl gleich der Anzahl der KV-Heads im Modell. Diese zweite Grenze ist die schärfere, weil sie nicht von der eigenen Hardware abhängt, sondern von der Modellarchitektur. Wer ein Modell mit wenigen KV-Heads wählt, kann die Knotenzahl nicht beliebig steigern, selbst wenn genügend Geräte vorhanden wären. Beide Regeln stehen in der README unter dem Abschnitt zu bekannten Einschränkungen, jeweils mit einem Verweis auf ein Issue. Das sind keine Randfälle, sondern Ausschlusskriterien, die vor dem Aufbau eines Clusters geprüft werden müssen.

Quantisierung: nur zwei Kombinationen sind dokumentiert

Das Projekt unterstützt laut README nur zwei Kombinationen aus Modellquantisierung und Float-Typ für die Synchronisation. Erlaubt sind ein q40-Modell mit dem Buffer-Float-Typ q80 sowie ein f32-Modell mit f32 als Buffer-Float-Typ. Das schränkt die Auswahl erheblich ein. Wer ein Modell in einer anderen Quantisierung vorliegen hat, muss es zuerst konvertieren. Die README verweist dazu auf einen eigenen Leitfaden zur Konvertierung von Hugging-Face-Modellen. Der Buffer-Float-Typ beschreibt die Genauigkeit, mit der die Knoten ihren Zustand untereinander abgleichen. Dass q40-Modelle mit q80 synchronisiert werden, ist ein Kompromiss: Die Gewichte liegen kompakt vor, die Zwischenergebnisse werden mit höherer Genauigkeit ausgetauscht. Die README begründet diese Wahl nicht, sie listet sie nur als Fakt. Das ist eine Stelle, an der die Dokumentation dünn bleibt.

Erste Schritte: ein Befehl für den Root-Knoten

Der schnellste Weg führt über ein Python-Skript. Die README nennt als Voraussetzungen Python 3 und einen C++-Compiler. Der Befehl lädt Modell und Tokenizer herunter. Für Llama 3.1 8B Instruct Q40 mit 6,32 GB lautet er python launch.py llama3_1_8b_instruct_q40. Für Llama 3.3 70B Instruct Q40 mit 40 GB lautet er python launch.py llama3_3_70b_instruct_q40. Weitere Einträge der Tabelle decken Llama 3.2 in den Größen 1B und 3B, DeepSeek R1 Distill Llama 8B sowie mehrere Qwen-3-Varianten von 0,6B bis 30B A3B ab. Die Tabelle enthält bei mindestens einem Eintrag einen Punkt am Ende des Befehls, was beim Kopieren zu beachten ist. Nach dem Start stehen vier Unterbefehle zur Verfügung: dllama inference für einen einfachen Benchmark, dllama chat für einen CLI-Chat, dllama worker für einen Worker-Knoten und dllama-api für einen API-Server. Die Argumente sind je nach Unterbefehl unterschiedlich. inference, chat und api akzeptieren --model, --tokenizer, --buffer-float-type, --workers mit durch Leerzeichen getrennten ip:port-Adressen und --max-seq-len. Letzteres dient laut README dazu, den RAM-Verbrauch zu senken. inference, chat, worker und api akzeptieren --nthreads, wobei die README ausdrücklich warnt, keinen höheren Wert als die Anzahl der CPU-Kerne zu setzen. worker und api akzeptieren zusätzlich --host und --port. inference allein akzeptiert --prompt und --steps.

Grenzen jenseits der Topologie

Die README beschreibt die Synchronisation als schnell, ohne eine Latenz oder einen Durchsatz zu nennen. Wer wissen will, ob sich der Aufbau für seine Geräte lohnt, findet in der Dokumentation keine Zahlen, die das vorab beantworten. Das ist eine echte Lücke, weil der Nutzen der Verteilung direkt von der Netzwerkanbindung abhängt. Ein Gigabit-Ethernet-Switch, über den vier Knoten ihren Zustand austauschen, ist kein InfiniBand-Interconnect. Das Projekt positioniert sich entsprechend für Heimgeräte, nicht für Rechenzentren. Ein weiterer Punkt: Der Root-Knoten trägt eine doppelte Last, weil er sowohl Koordination als auch eigene Berechnung übernimmt. Die README erwähnt den höheren RAM-Bedarf, sagt aber nichts über die CPU-Last. Wer den Root auf dem schwächsten Gerät im Verbund laufen lässt, sollte das bewusst tun. Schließlich ist die Konfiguration der Worker bewusst schlank gehalten, was bedeutet, dass Fehlerdiagnose überwiegend am Root stattfindet. Die README gibt dazu keine Hinweise.

Abgrenzung zu llama.cpp mit RPC

Der naheliegende Vergleich ist llama.cpp, das ebenfalls eine verteilte Ausführung über das RPC-Backend anbietet. Der Unterschied liegt im Ansatz. llama.cpp ist primär eine lokale Inferenz-Engine mit breiter Modell- und Backend-Unterstützung, und die Verteilung ist eine Erweiterung davon. distributed-llama ist von vornherein um die Verteilung herum gebaut: Der Root lädt das Modell und schiebt Gewichte an die Worker, die selbst keinerlei Modellkonfiguration kennen. Diese Trennung ist im Code sichtbar und in der README beschrieben. Wer bereits llama.cpp nutzt und nur gelegentlich zwei Rechner verbinden möchte, bleibt bei seinem Werkzeug. Wer einen dauerhaften Verbund aus mehreren gleichartigen Geräten plant und die Modellverwaltung zentral halten will, findet hier ein Modell, das genau darauf zugeschnitten ist. Die Kehrseite ist die geringere Flexibilität: Die 2^n-Regel und die zwei erlaubten Quantisierungskombinationen gibt es bei llama.cpp in dieser Form nicht.

Wartung, Lizenz und was vor dem Aufbau zu prüfen ist

Das Projekt steht unter der MIT-Lizenz, was die kommerzielle Nutzung und Änderung erlaubt, solange der Lizenztext beibehalten wird. Das ist eine der permissivsten freien Lizenzen und stellt für die meisten Anwender keine Hürde dar. Die Release-Historie zeigt drei Veröffentlichungen zwischen Oktober 2025 und Februar 2026, die jüngste als v0.16.5. Die README dokumentiert daneben eine Reihe funktionaler Erweiterungen aus 2025, darunter Vulkan-Unterstützung, die als experimentell bezeichnet wird, sowie Qwen-3-MoE-Unterstützung auf CPU und Vulkan. Ein refaktoriertes Codebasis wurde im Februar 2025 zusammengeführt. Das deutet auf ein aktiv entwickeltes Projekt hin, ohne dass sich daraus etwas über Stabilität im eigenen Betrieb ableiten ließe. Upgrade-Kosten entstehen vor allem durch die enge Kopplung von Modellformat und Buffer-Float-Typ: Ändert sich eine der beiden erlaubten Kombinationen, muss das Modell neu konvertiert werden. Vor dem Aufbau eines Clusters sind drei Dinge zu klären. Erstens, ob die geplante Knotenzahl eine Zweierpotenz ist. Zweitens, ob sie die Anzahl der KV-Heads des gewählten Modells nicht überschreitet. Drittens, ob das Modell in q40 oder f32 vorliegt, weil andere Quantisierungen laut README nicht unterstützt werden. Wer diese drei Punkte bejaht, kann mit python launch.py beginnen.

Redaktionelles Fazit

Wer mehrere Rechner mit ausreichend RAM besitzt und ein Modell betreiben will, das auf einem einzelnen Gerät nicht in den Speicher passt, findet hier einen MIT-lizenzierten C++-Ansatz, der ohne Cloud auskommt. Wer ein einzelnes Gerät mit genügend RAM oder eine GPU mit ausreichend VRAM hat, sollte nicht zur verteilten Variante greifen, weil der Netzwerk-Overhead und die Topologie-Beschränkung auf 2^n Knoten keinen Vorteil bringen. Vor dem ersten Start ist zu prüfen, ob die Knotenzahl eine Zweierpotenz ist und ob die Anzahl der Knoten die Anzahl der KV-Heads im Modell nicht überschreitet, denn das sind die beiden harten Ausschlusskriterien aus der README.

Offizielle Quellen

1. b4rtaz/distributed-llama on GitHub
2. Issues
3. License: MIT
4. README
5. Releases