Mesh LLM im Test: Ein großes LLM auf mehreren Rechnern ausführen?

Ja. Mesh LLM kann ein unterstütztes großes Sprachmodell über mehrere Rechner ausführen, wenn keine Maschine allein genug Speicher hat. Die Skippy-Runtime weist ausgewählten Peers zusammenhängende Layer-Bereiche zu. Jeder Peer lädt die GGUF-Fragmente seiner Stage, während Aktivierungen für jedes erzeugte Token durch die Pipeline wandern. Die Anwendung spricht weiter nur mit http://localhost:9337/v1.

Für die Kaufentscheidung fehlt noch ein Satz: Gemeinsame Kapazität bedeutet nicht automatisch gemeinsame Geschwindigkeit. Jede zusätzliche Stage bringt Netzwerkkommunikation in den seriellen Decode-Pfad. Der langsamste Peer kann die gesamte Pipeline begrenzen. Mesh LLM ist besonders interessant, wenn das benötigte Modell auf keine einzelne Maschine passt. Passt es bereits lokal, ist der einzelne Host meist schneller und zuverlässiger.

Dieser Review bildet Projekt und Primärdokumentation vom 18. Juli 2026 ab. Wir trennen dokumentierte Funktionen, veröffentlichte Benchmarks und Aussagen, die du auf deiner Hardware erst belegen musst.

Was ist Mesh LLM?

Mesh LLM ist eine Apache-2.0-Runtime für verteilte LLM-Inferenz. Jeder Node stellt dieselbe OpenAI-kompatible API bereit. Das Mesh kann ein Modell lokal ausführen, eine komplette Anfrage an einen passenden Peer routen oder ein Modell mit Skippy über mehrere Peers teilen.

1. Lokal: Das aktuelle Gerät führt das ganze Modell aus, wenn es passt. Kein Netzwerk-Overhead.
2. Peer Routing: Die komplette Anfrage geht an einen Rechner, der das Modell bereits anbietet.
3. Stage Split: Mehrere Rechner führen unterschiedliche Layer-Bereiche derselben Anfrage aus.

Die Anwendung sieht nur Modellname, Request und Response. Placement, Peer-Auswahl, Downloads, Readiness und Recovery bleiben trotzdem echte Infrastrukturaufgaben.

Wie teilt Skippy ein LLM auf mehrere Rechner?

Der dokumentierte Skippy-Ablauf ist eine Pipeline:

1. Der Coordinator löst Modell oder Layer-Paket auf.
2. Der Topology Planner wählt geeignete Peers und zusammenhängende Layer-Bereiche.
3. Die letzte Stage lädt zuerst, danach die vorgelagerten Stages.
4. Jeder Peer lädt gemeinsame Metadaten und nur seine Layer-Dateien.
5. Stage 0 wird erst geroutet, wenn alle benötigten Stages bereit sind.
6. Prompt und Aktivierungen laufen nach hinten, das vorhergesagte Token zurück in den OpenAI-Stream.

Bei 48 Layern könnte Rechner A die Layer 0 bis 15 übernehmen, B die Layer 16 bis 31 und C die Layer 32 bis 47 plus Output Head. Es laufen nicht drei unabhängige Modelle. Es ist ein Inferenzpfad mit zwei Netzwerkgrenzen.

Layer-Pakete enthalten Manifest, gemeinsame Artefakte, Hashes und einzeln auflösbare GGUF-Fragmente. Für produktionsnahe Tests empfiehlt das Projekt unveränderliche Hugging-Face-Revisionen und Zertifizierung gegen Größen, SHA, Manifest, fehlende Dateien und echte /v1-Antworten. Ein beliebiges GGUF ist nicht automatisch ein sicherer Multi-Node-Split.

Ist Mesh LLM nur Load Balancing?

Nein. Load Balancing verteilt vollständige Anfragen auf vollständige Modellkopien. Ein Skippy-Split schickt dieselbe Anfrage durch mehrere Rechner.

Drei 24-GB-GPUs werden deshalb nicht zu einer wörtlichen 72-GB-GPU. Software macht kombinierte Kapazität nutzbar. Memory Bandwidth, Rechenleistung und Fehlerrisiko bleiben verteilt.

Wie viel Performance kostet verteilte Inferenz?

Das hängt von Modell, Split und Netzwerk ab. Die Projekt-Benchmarkseite nennt ihre Werte selbst einen Reality Check, keine Zusage. Für GLM-4.7-Flash Q4 mit 17 GB auf M4 Max und Mac mini M4 über WLAN meldet sie:

Das Modell passte bereits auf einen Rechner. Der Test zeigt daher Overhead, ohne den eigentlichen Kapazitätsvorteil zu liefern. Er beweist weder einen universellen Skippy-Verlust noch einen aktuellen Vergleich aller Backend-Pfade. Die richtige Schlussfolgerung lautet: Erwarte keinen linearen Speedup.

Das Planner-Dokument liefert ein besseres Modell. Bei beispielhaften 10 ms pro Stage-Transfer entsteht für zwei Stages ein Netzwerkboden von 20 ms pro Token, für drei 30 ms und für vier 40 ms, noch vor Compute. Der Topology Planner bevorzugt deshalb weniger physische Hops, sobald der Speicher reicht.

Was entscheidet über die reale Geschwindigkeit?

• Latenz pro Stage: Autoregressives Decode wiederholt die Übergabe für jedes Token. Kabel-LAN und überlastetes WLAN sind zwei verschiedene Produkte.
• Langsamste Stage: Eine schwache GPU, CPU-Offload, Thermik oder Hintergrundlast begrenzt die Pipeline.
• Kontext und Cache: Gewichte sind nur ein Teil. KV- oder recurrent state wächst mit Context und Concurrency.
• Wire-Datentyp: f16 ist der konservative Standard. q8 wird nur je Familie und Split freigegeben, weil manche Architekturen Exactness-Tests nicht bestanden.
• Verfügbarkeit: Schlafender Laptop, Neustart oder WLAN-Wechsel unterbrechen einen erforderlichen Stage-Pfad.

Die Support-Matrix nennt für geprüfte Artefakte Split-Punkte, Wire-Typen, Cache-Policy und Topologiegrenzen. „Die Architektur läuft in llama.cpp“ und „dieser Split ist zertifiziert“ sind verschiedene Aussagen.

Welche Modelle und Hardware werden unterstützt?

Die Matrix enthält geprüfte Artefakte aus Familien wie Qwen, Llama, DeepSeek, GLM, Gemma, Phi, Granite, Hunyuan, Mamba, RWKV und Falcon sowie ausgewählte multimodale Modelle. Support variiert nach Quantisierung, Projektor, Cache, Wire-Typ und Split-Grenze. Nutze das empfohlene Artefakt und prüfe Paket plus Runtime.

Das Haupt-README dokumentiert Release-Bundles für macOS und Linux mit Metal, CPU, CUDA, ROCm und Vulkan. Windows kann aus dem Quellcode gebaut werden, während das veröffentlichte Windows-Release dort aktuell als deaktiviert beschrieben ist. Prüfe die Assets der konkreten Version.

Wie privat ist ein Mesh?

Private Meshes starten mit Invite Token. Veröffentlichte Meshes nutzen Nostr zur Discovery. Der LAN-Modus mit mDNS vermeidet Nostr-Relays, öffentliche iroh-Relays und öffentliche STUN-Prüfung. Discovery ist jedoch nicht Trust.

Die Security-Dokumentation beschreibt Owner Keys, Allowlists, signierte Bootstrap Tokens und Release Attestation. Sie nennt auch die Grenze: Eine signierte Attestation belegt Build-Herkunft, nicht einen unveränderten Prozess, ein sicheres Betriebssystem oder vertrauenswürdige Hardware.

Für vertrauliche Prompts brauchst du ein privat betriebenes Mesh, klare Owner- und Admission-Policy, geschützte Tokens, eingeschränkte Listener und geprüfte Logs. Öffentliche Discovery ist kein Confidential Computing.

Mesh LLM vs. Exo, llama.cpp RPC und vLLM

Dieser Artikel beantwortet die Kapazitäts- und Topologiefrage. Für die Finanzentscheidung nutze unseren Break-even-Vergleich lokaler Modelle gegen APIs. Für die Modellauswahl dient der Open-Weight-LLM-Vergleich. So entscheidet nicht die interessanteste Runtime automatisch über die Geschäftsarchitektur.

Wer sollte Mesh LLM testen?

Sieben Schritte für einen belastbaren Pilot

1. Definiere 30 bis 100 echte Prompts, Context, Output, Concurrency und Qualitätsrubrik.
2. Messe den besten Einzelrechner: TTFT, tok/s, Peak Memory, Task Success, Strom und Fehler.
3. Wähle ein geprüftes Artefakt mit unveränderlicher Revision und prüfe seine Lizenz.
4. Beginne mit zwei verkabelten Nodes. Füge nur aus Speichergründen weitere Stages hinzu.
5. Teste realistischen Context und Concurrency, nicht nur einen „OK“-Prompt.
6. Unterbrich einen Peer absichtlich und prüfe Erkennung, Withdrawal, Recovery und Client-Fehler.
7. Vergleiche Kosten pro erfolgreicher Aufgabe inklusive Engineering, Strom, Abschreibung, Redundanz und API-Fallback.

Die Entscheidung braucht am Ende messbare Grenzen: größtes passendes Modell, kleinste ausreichend schnelle Stage-Anzahl, Failure Budget, Trust Boundary und Fallback. Unsere Twinsoft-AI-Fallstudie und der Leitfaden zur Tech-Stack-Auswahl folgen demselben Prinzip.

Quellen und Methode

Architektur, Befehle, API, Artefakte, Support, Security und Benchmarks stammen aus dem Mesh-LLM-Repository sowie den oben verlinkten Primärdokumenten zu Skippy, Planner, Familienstatus und Mesh-Trust. Wir haben die Hardware-Benchmarks nicht reproduziert. Alle Projektfakten wurden am 18. Juli 2026 geprüft. Flüchtige Zahlen wie Stars, Release-Anzahl und Familienanzahl lassen wir bewusst weg.