Mesh LLM: GPUs über mehrere Rechner als eine OpenAI-kompatible API bündeln

Welches Problem Mesh LLM löst und für wen

Ein einzelnes Modell in der Größenklasse von Qwen3-8B passt auf viele Workstations. Sobald das Modell größer wird als der Speicher einer Maschine, beginnt die Bastelei: mehrere Prozesse, manuelle Layer-Aufteilung, selbstgeschriebene Router. Mesh LLM setzt genau dort an. Laut README bündelt das Projekt GPUs und Speicher über mehrere Rechner und stellt das Ergebnis als eine OpenAI-kompatible API unter http://localhost:9337/v1 bereit. Der Aufrufer sieht einen Endpunkt, nicht eine Reihe von Maschinen.

Die Zielgruppe lässt sich aus dem Befehlsraster ablesen. Es gibt einen Modus für die öffentliche Mesh (mesh-llm serve --auto), einen für eine private Mesh (mesh-llm serve --model Qwen3-8B-Q4_K_M), einen für reines lokales Serving ohne Netzwerk (--local-model-only) und einen Client-Modus ohne eigene Inferenz (mesh-llm client --auto). Das deckt zwei sehr unterschiedliche Nutzer ab: Betreiber, die eigene Hardware zusammenlegen, und Nutzer, die Rechenzeit aus einer fremden Mesh beziehen wollen. Wer nur eine API gegen ein lokales Modell braucht, ist mit dem direkten Modus besser bedient, weil dort QUIC, Discovery und Peer-Wartung gar nicht erst starten.

Wie Routing und Skippy-Splits zusammenspielen

Die Architektur folgt einer einfachen Reihenfolge. Zuerst prüft das System, ob ein einzelner Knoten das vollständige Modell hosten kann. Ist das der Fall, wird es lokal ausgeliefert, ohne dass Zwischenaktivierungen über das Netz gehen. Diese Regel steht im README an erster Stelle der Mesh-Beschreibung und ist die wichtigste Designentscheidung des Projekts: Verteilung ist der Ausnahmefall, nicht der Standard.

Passt das Modell nicht, greift Skippy. Der Koordinator plant zusammenhängende Layer-Bereiche, startet die nachgelagerten Stufen zuerst, wartet auf deren Bereitschaft und veröffentlicht erst dann die Route für Stufe 0. Diese Reihenfolge verhindert, dass Anfragen an eine Stufe gehen, die noch nicht geladen ist. Die Modellgewichte liegen dabei als Pakete vor: ein Repository enthält model-package.json plus GGUF-Fragmente, und jeder Peer lädt nur die Teile, die seiner Stufe zugewiesen sind. Das ist der eigentliche Mechanismus hinter dem Versprechen, große dichte Modelle über mehrere Boxen zu verteilen.

Für den Transport nutzt das Projekt QUIC mit Ende-zu-Ende-Verschlüsselung zwischen den Knoten, einschließlich Inferenz-Anfragen, Antworten und der Aktivierungen von Split-Modellen. Iroh-Relays leiten verschlüsselte Pakete weiter, ohne den Inhalt zu lesen. Das ist eine bewusste Trennung: Relays helfen bei der Erreichbarkeit, sind aber nicht Teil des Vertrauensmodells. Wer die Mesh über das offene Internet betreibt, sollte diesen Punkt kennen, weil er bestimmt, was ein Relay-Betreiber sehen kann und was nicht.

Installation und der erste Start

Die Installation läuft über ein Skript. Unter Linux und macOS per curl -fsSL https://raw.githubusercontent.com/Mesh-LLM/mesh-llm/main/install.sh | bash, unter Windows per irm https://raw.githubusercontent.com/Mesh-LLM/mesh-llm/main/install.ps1 | iex. Für Apple Silicon gibt es zusätzlich brew install Mesh-LLM/tap/mesh-llm. Versionierte Formeln, Ubuntu- und Arch-Pakete, Checksums, SBOMs und OCI-Images werden laut README aus dem separaten Repository Mesh-LLM/mesh-packaging erzeugt.

Nach der Installation folgt mesh-llm setup, unter Windows mesh-llm.exe setup. Der eigentliche Start ist dann ein einzelner Befehl: mesh-llm serve --auto. Laut README wählt dieser Befehl eine Backend-Variante, lädt bei Bedarf ein passendes Modell herunter, tritt der besten gefundenen öffentlichen Mesh bei, startet die lokale API auf Port 9337 und die Web-Konsole auf Port 3131. Wer die Oberfläche nicht will, hängt --headless an und behält die Management-API auf dem --console-Port.

Für eine private Mesh genügt mesh-llm serve --model Qwen3-8B-Q4_K_M. Wer sein eigenes Modell veröffentlichen will, ergänzt --publish, für einen Beitritt per Einladung --join <token>. Der Split-Modus wird über --split aktiviert, mit einer Modellangabe der Form hf://meshllm/<repo>@<rev>. Die Modellliste lässt sich mit curl -s http://localhost:9337/v1/models | jq '.data[].id' abfragen, ein Chat-Aufruf folgt dem üblichen OpenAI-Schema gegen /v1/chat/completions.

Der lokale Modus als eigener Betriebsweg

Der interessanteste Randfall ist --local-model-only. In diesem Modus startet Mesh LLM nur das OpenAI-Frontend und eine lokale Skippy-Runtime. QUIC, Discovery, Peer-Wartung, Split-Planung, Plugins, Release-Lookup, Web-Konsole und Management-API werden nicht gestartet. Das ist kein reduzierter Mesh-Modus, sondern ein anderer Betriebsweg, und das README ist an dieser Stelle ausdrücklich: Der Start schlägt fehl, wenn das vollständige Modell nicht in die erkannte lokale Kapazität passt oder --max-vram nicht ausreicht. Ein Rückfall auf verteiltes Serving findet nicht statt.

Diese Entscheidung ist richtig und unbequem zugleich. Richtig, weil ein stiller Wechsel in den verteilten Betrieb die Latenz und die Fehlerquellen schlagartig verändern würde, ohne dass der Aufrufer es merkt. Unbequem, weil man die Kapazitätsgrenze vor dem Start kennen muss. Dazu kommen zwei Einschränkungen, die leicht übersehen werden: Für --local-model-only müssen die Werte von --model, --gguf und --mmproj absolute Pfade sein und dürfen keine Symlinks enthalten. In Umgebungen, in denen Modelle über versionierte Symlink-Verzeichnisse eingebunden werden, bricht der Start deshalb ab, obwohl der Pfad auf der Kommandozeile korrekt aussieht.

Mixture-of-Agents: experimentell, und das steht auch so da

Ein Aufruf mit "model": "mesh" verteilt eine Anfrage parallel an alle im Mesh verfügbaren Modelle, führt die Antworten mit deterministischer Logik zusammen und gibt eine einzige OpenAI-kompatible Antwort zurück. Der Arbiter läuft laut README als Code und nicht als weiterer Modellaufruf; nur bei echtem Konflikt wird ein Reducer-LLM hinzugezogen. Tool-Aufrufe durchlaufen die gesamte Pipeline.

Das README kennzeichnet dieses Gateway ausdrücklich als experimentell und weist darauf hin, dass sich Verhalten, Routing-Heuristiken, Fehlerformate und Tuning-Parameter zwischen Versionen ändern können. Es empfiehlt, model: "mesh" als Vorschau zu behandeln und für stabile Semantik eine konkrete Modell-ID zu verwenden. Diese Warnung sollte man ernst nehmen. Ein Fan-out an alle Modelle im Mesh bedeutet, dass die Antwortzeit vom langsamsten beteiligten Knoten abhängt und die Kosten pro Anfrage mit der Zahl der Modelle skalieren. Für einen einzelnen Faktenabruf ist das ein schlechtes Geschäft. Interessant wird es dort, wo mehrere Modelle tatsächlich unterschiedliche Fehler machen und die Zusammenführung diese Fehler ausgleicht. Wer das nicht messen kann, sollte eine feste Modell-ID verwenden.

Verteilte Inferenz über fremde Hardware: die eigentliche Grenze

Ein Modell über mehrere Maschinen zu verteilen heißt, Aktivierungen zwischen den Stufen zu übertragen. Genau dieser Datenverkehr entscheidet über die Nutzbarkeit. Die Dokumentation nennt keine Zahlen zur Latenz oder zum Durchsatz, und das ist kein Zufall: Sie hängen von der Netzverbindung zwischen den Knoten ab, nicht vom Code. In einem lokalen Netz mit schneller Verbindung kann das aufgehen. Über eine öffentliche Mesh mit unbekannten Peers und Relay-Strecken ist der Engpass vorhersehbar.

Dazu kommt eine zweite Frage, die nichts mit Technik zu tun hat. Wer der öffentlichen Mesh beitritt, stellt seine Rechenzeit anderen zur Verfügung. Das README beschreibt die Entdeckung über Nostr für veröffentlichte Meshes, während private Meshes über Einladungstoken laufen. Es beschreibt nicht, welche Modelle oder Prompts über einen Knoten laufen können, der einer öffentlichen Mesh beigetreten ist. Wer diesen Punkt vor dem Start klären will, findet in docs/USAGE.md und docs/MESHES.md die Betreiberdokumentation, die dafür die naheliegende erste Anlaufstelle ist.

Für Betreiber mit eigener Hardware und kontrolliertem Netz ist der Split-Modus dagegen ein sinnvoller Weg, ein Modell zu betreiben, das auf keine einzelne Maschine passt. Der Preis ist die Abhängigkeit von allen beteiligten Stufen: Fällt eine Stufe aus, ist das Modell nicht mehr vollständig bedienbar.

Was man stattdessen einsetzen kann

Der naheliegende Vergleich ist llama.cpp mit dem eingebauten RPC-Backend. Beide Ansätze laden GGUF-Modelle und beide können Layer über mehrere Maschinen verteilen. Der Unterschied liegt in der Rolle des Netzwerks. llama.cpp bleibt ein Inferenzprozess mit einem RPC-Server, den man selbst startet, selbst absichert und selbst adressiert. Mesh LLM setzt darüber eine eigene Ebene: Discovery über Nostr, Einladungstoken, QUIC mit Ende-zu-Ende-Verschlüsselung, ein Routing nach dem model-Feld und eine Management-API. Man tauscht also Kontrolle gegen eingebaute Infrastruktur. Wer ohnehin schon einen Reverse Proxy, eine Authentifizierungsschicht und ein Monitoring für seine Dienste betreibt, für den ist der zusätzliche Stack von Mesh LLM mehr Bewegungsteil als Nutzen. Wer dagegen mehrere Maschinen ohne zentrale Orchestrierung zusammenbringen will, spart sich mit Mesh LLM genau die Teile, die llama.cpp nicht mitbringt.

Für den reinen Einzelmaschinenbetrieb ist der Vergleich noch deutlicher. Ein llama.cpp-Server mit einem Modell auf einer großen Maschine braucht keine Discovery, kein Routing und keine Peer-Wartung. Mesh LLM bietet für diesen Fall den Modus --local-model-only, der all das abschaltet. Wer diesen Modus nutzt, sollte sich fragen, warum er Mesh LLM statt eines schlankeren Servers einsetzt. Die Antwort ist meistens die einheitliche CLI und die Web-Konsole, nicht die Verteilung.

Wartung, Upgrades und Lizenz

Das Projekt bewegt sich schnell. Die letzten drei Releases sind v0.76.0-rc7, v0.76.0-rc8 und v0.76.0-rc9, alle als Release Candidate gekennzeichnet und im Abstand von wenigen Tagen veröffentlicht. Ein Betrieb auf einem RC bedeutet, dass ein Upgrade nicht nur Fehler beheben, sondern auch das Verhalten des MoA-Gateways verändern kann. Wer model: "mesh" produktiv nutzt, sollte die Version festnageln und die Release Notes vor jedem Sprung lesen.

Ein Upgrade selbst ist unkompliziert, weil die Installation über ein Skript oder ein Paket läuft. Die Deinstallation ist ebenfalls vorbereitet: mesh-llm uninstall --dry-run zeigt die geplanten Schritte, mesh-llm uninstall --yes führt sie aus. Standardmäßig bleiben die Konfigurations- und Identitätsdaten unter ~/.mesh-llm erhalten; erst --purge-config entfernt sie. Wer eine Maschine weitergeben will, muss diesen Schalter kennen, weil sonst die Mesh-Identität zurückbleibt.

Lizenzrechtlich steht das Projekt unter Apache-2.0. Diese Lizenz erlaubt kommerzielle Nutzung und Modifikation, verlangt aber die Beibehaltung der Urheberrechts- und Lizenzhinweise sowie eine Kennzeichnung geänderter Dateien. Der Name und die Marke sind davon nicht automatisch abgedeckt. Für die Modellgewichte gilt die Apache-2.0-Lizenz des Repositories nicht; hier gelten die Bedingungen des jeweiligen Modells, und bei Paketen der Form hf://meshllm/<repo>@<rev> lohnt ein Blick in das Paket-Repository. Das ist keine Rechtsberatung, sondern nur der Hinweis, dass zwei getrennte Lizenzfragen zu prüfen sind: die des Codes und die der Gewichte.

Redaktionelles Fazit

Mesh LLM passt für Teams, die bereits mehrere Maschinen mit GPUs besitzen und ein Modell gemeinsam nutzen wollen, ohne einen zentralen Inferenzserver aufzusetzen. Wer ein einzelnes Modell mit stabiler Latenz und reproduzierbaren Ergebnissen braucht, sollte zuerst prüfen, ob --local-model-only auf einer ausreichend großen Maschine genügt. Vor dem produktiven Einsatz sind drei Dinge zu verifizieren: ob die Zielversion noch ein Release Candidate ist oder als stabil markiert wurde, ob die QUIC-Verbindung zwischen den Knoten die nötige Bandbreite liefert, und ob die Lizenz- und Datenschutzangaben der öffentlichen Meshes zu den eigenen Anforderungen passen.

Offizielle Quellen

1. License: Apache-2.0
2. Mesh-LLM/mesh-llm on GitHub
3. Project website
4. README
5. Releases