Mesh LLM – Verteiltes KI-Computing auf Basis von iroh

• Bündelt über mehrere Maschinen verteilte GPUs und Arbeitsspeicher zu einer Computing-Ressource und stellt lokale Ausführung, Weiterleitung an Peers und geteilte Ausführung über eine einzige OpenAI-kompatible API bereit
• Anfragen werden auf der lokalen GPU oder bei einem Peer verarbeitet, der das Modell geladen hat; Modelle, die nicht auf eine einzelne Maschine passen, können über mehrere Nodes hinweg als Pipeline-Stufen ausgeführt werden
• Der Plugin-basierte Katalog umfasst mehr als 40 Modelle, von 500-Millionen-Parameter-Modellen für Notebooks bis hin zu 235B-MoE-Modellen; Clients rufen unabhängig vom internen Batching nur localhost:9337/v1 auf
• Jeder Node betreibt einen iroh-Endpunkt, der einen Public Key als ID und einzige Netzwerkoberfläche nutzt, und baut ohne zentralen Server über NAT-Traversal, Hole Punching und Relay-Fallback authentifizierte QUIC-Verbindungen auf
• Mit einer etwa 18 MB großen Software lassen sich öffentliche Meshes oder private Deployments aufbauen; künftig soll die Abhängigkeit von geschlossenen Servern durch mobile Apps mit iroh Swift SDK und ACP-Unterstützung reduziert werden

---

Vorhandene Hardware statt externer Rechenzentren nutzen

• Die übliche Nutzung von LLMs hängt von GPU-Rechenzentren externer Anbieter und nutzungsbasierten APIs ab, sodass die Kosten mit steigender Nutzung wachsen
• Wenn Prompts an externe Dienste gesendet werden, können Nutzer die folgenden Faktoren nur schwer direkt kontrollieren
  • Zeitpunkt von Modell-Updates
  • Wohin Daten übertragen werden
  • Vom Modell genutzter Arbeitsspeicher und zugrunde liegende Hardware
  • Änderungen bei Preisen und Datenschutzrichtlinien
• Unternehmen und Dienste, die bereits GPUs im Büro, Lager oder unter dem Schreibtisch besitzen, benötigen eine Möglichkeit, mehrere Maschinen wie eine Computing-Ressource zu nutzen
• Mesh LLM ist dafür konzipiert, vorhandene GPUs und Arbeitsspeicher über beliebig viele Maschinen hinweg zu bündeln, größere Modelle auszuführen und Rechenressourcen teamintern privat oder öffentlich mit anderen zu teilen

Drei Wege zur Verarbeitung von Anfragen

• Wenn ein Standard-OpenAI-Client http://localhost:9337/v1 aufruft, entscheidet das Mesh, wo die Anfrage tatsächlich ausgeführt wird
• Eine Anfrage wird über einen der folgenden drei Wege verarbeitet
  • Ausführung des Modells auf der lokalen GPU der aktuellen Maschine
  • Weiterleitung der Anfrage an einen Peer, der das benötigte Modell bereits geladen hat
  • Pipeline-artige Aufteilung eines Modells, das nicht auf eine einzelne Maschine passt, über mehrere Maschinen hinweg
• Nutzer können mit einem einzelnen Node beginnen und bei Bedarf weitere hinzufügen; der OpenAI-Client muss weder das interne Routing noch die Art der geteilten Ausführung kennen

Plugin-Struktur und Modellkatalog

• Plugins deklarieren ihre Funktionen in einem Manifest, und die Runtime startet sie und routet Aufrufe
• Die Funktionen jedes Plugins werden über MCP, HTTP, Inferenz und Mesh-Events bereitgestellt
• Der Standardkatalog enthält mehr als 40 Modelle
  • Etwa 500-Millionen-Parameter-Modelle, die auf einem Notebook laufen können
  • Mixture-of-Experts-Modelle mit bis zu 235B Parametern

Geteilte Ausführung mit Skippy

• Der Split-Modus für große Modelle wird intern Skippy genannt
• Die Layer-Bereiche des Modells werden in Stufen aufgeteilt und auf die einzelnen Nodes verteilt
  • Ein Node übernimmt die Layer 0 bis 15
  • Der nächste Node übernimmt die Layer 16 bis 31
  • Weitere Layer werden auf die gleiche Weise bis zum Ende der Pipeline verteilt
• Da die in einer Stufe erzeugten Aktivierungen an die nächste Stufe weitergegeben werden, lassen sich auch Modelle ausführen, die nicht auf einzelne Maschinen passen, indem mehrere mittelgroße Maschinen kombiniert werden
• Der Aufteilungsprozess bleibt für den OpenAI-Client unsichtbar; der Client ruft weiterhin nur den lokalen Endpunkt auf

P2P-Netzwerk auf Basis von iroh

• Sowohl Nodes, die Modelle bereitstellen, als auch Nodes, die nur Anfragen senden, starten einen iroh-Endpunkt
• Der Endpunkt übernimmt drei Rollen
  • ID des Nodes
  • Public Key
  • Einzige Netzwerkoberfläche, die der Node nach außen freigibt
• iroh übernimmt ohne zentralen Server Hole Punching, NAT-Traversal und Relay-Fallbacks, um direkte und authentifizierte QUIC-Verbindungen zwischen Nodes an unterschiedlichen Standorten aufzubauen
• Für Nodes, die nicht direkt verbunden werden können, werden zwei iroh-Relays in verschiedenen Regionen betrieben, die einen nahegelegenen Ausweichpfad bereitstellen
• Da Maschinen über Public Keys adressiert und authentifizierte NAT-Traversal-QUIC-Verbindungen genutzt werden können, werden das Weiterleiten von Anfragen an Peers und das Senden von Aktivierungen an die nächste Pipeline-Stufe als dieselbe grundlegende Kommunikation mit jeweils anderer Endpunkt-ID behandelt

Protokolltrennung per QUIC ALPN

• Das gesamte Protokoll nutzt die ALPN-Aushandlung von QUIC und ist je nach Zweck in drei Bereiche unterteilt
  • mesh-llm/1: das grundlegende Mesh, einschließlich Gossip, Routing, HTTP-Tunnel und Plugin-Kanälen
  • mesh-llm-control/1: Control Plane des Besitzers für Einstellungssynchronisierung und Eigentumsnachweis
  • skippy-stage/2: latenzkritische Übertragung von Aktivierungen in geteilten Modellen
• In einer mesh-llm/1-Verbindung werden alle Aufgaben über bidirektionale QUIC-Streams übertragen; das erste Byte des Streams identifiziert den Typ
  • 0x01 GOSSIP: Peer-Ankündigungen einschließlich Modell, GPU, RTT und Funktionen
  • 0x04 TUNNEL_HTTP: an einen Peer weitergeleitete Inferenzanfrage
  • 0x05 ROUTE_REQUEST: Abfrage eines von einem Peer gehosteten Modells
  • 0x06 PEER_DOWN: Benachrichtigung über einen getrennten Peer
  • 0x07 PEER_LEAVING: Benachrichtigung über reguläres Beenden
  • 0x08 PLUGIN_CHANNEL: Plugin-RPC
  • 0x0e DIRECT_PATH_REQUEST: Teilen direkter Adressen für NAT-Traversal
• Eine einzelne Verbindung verarbeitet Gossip, Inferenz, Routenabfragen und Peer-Lifecycle-Events und demultiplext die einzelnen Streams über das führende Byte

Trennung von sicherem Transport und Mesh-Steuerung

• iroh stellt die sichere Transportschicht zwischen Maschinen bereit
• Mesh LLM baut darauf eine eigene Gossip-Schicht auf und kontrolliert die folgenden Richtlinien direkt
  • Wer am Mesh teilnehmen darf
  • Kompatible Versionen
  • Vertrauenswürdige Peers

Installation und künftige Unterstützung

• Durch Installation einer leichtgewichtigen Software von etwa 18 MB kann man an einem öffentlichen Mesh teilnehmen oder ein privates Deployment aufbauen
• Für Standard-OpenAI-Clients wird es über den Endpunkt localhost:9337/v1 bereitgestellt
• Es ist geplant, mit dem iroh Swift SDK mobile Apps zu entwickeln; außerdem wird Unterstützung für den neuen Agentenstandard ACP vorbereitet, damit auch andere Clients am Mesh teilnehmen können
• Das Projekt zielt darauf ab, P2P-Nutzung auszuweiten und Abhängigkeiten von geschlossenen Servern zu reduzieren
• Das Projekt ist über den Quellcode und die Mesh-LLM-Website verfügbar

iroh-Netzwerkbibliothek

• iroh ist eine Open-Source-Netzwerkbibliothek für Verbindungen zwischen Geräten; man kann vorbereitete Protokolle kombinieren oder eigene Protokolle auf einer einfachen Kommunikationsabstraktion aufbauen
• Sie läuft bereits auf Hunderttausenden Geräten in Produktionsumgebungen
• Es gibt Dokumentation, Quellcode und einen Discord-Kanal

[GN⁺]

Hacker-News-Kommentare

• Als ich auf dem ersten Bild die GPU-Systeme, Laptops, Server und Cloud-Knoten sah, wurde mir klar, wie wenig Rechenressourcen ich selbst habe. Ich habe weder einen Laptop mit 24 GB VRAM noch eine Workstation mit 96 GB, und selbst wenn ich die Gaming-PCs meiner Freunde alle zusammen einspannen würde, käme ich wohl nicht auf den gesamten VRAM auf dem Foto.
  Im Artikel wurde auch ein öffentliches Mesh-Netzwerk vorgestellt, aber ich konnte keine näheren Informationen dazu finden.

  • Die öffentliche Mesh-Adresse ist https://public.meshllm.cloud/.

• Auffällig ist der Mangel an Leistungsinformationen. Ich hatte erwartet, dass es deutlich langsamer wäre als jede andere Art, große Modelle auszuführen, einschließlich System-RAM oder Disk-Streaming. Consumer-Netzwerke sind selbst mit 10Gbps Ethernet im Vergleich zu lokalem RAM oder Festplatten sehr langsam, daher habe ich mich gefragt, ob ein gesplittetes Modell bei 1 Token/s oder weniger liegt.
  In der Modellliste stand bei Qwen 235B A22B jedoch „verifiziertes MoE 235B/22B mit 16 tok/s auf 2 Knoten“. Die Knotenspezifikationen und die Netzwerkverbindung wurden zwar nicht offengelegt, aber das ist eine ziemlich ordentliche Geschwindigkeit und kommt der angenehm interaktiven Nutzung recht nahe, auch wenn sie sie knapp verfehlt.

  • Es muss nicht unbedingt langsamer sein, in vielen Konfigurationen ist eher das Gegenteil zu erwarten. Wenn Gewichte in RAM oder NVMe ausgelagert werden, müssen bei jedem Token für jede Schicht riesige Gewichte von langsamem Speicher auf die GPU übertragen werden, sodass DRAM-Bandbreite oder Plattenlesegeschwindigkeit zum Flaschenhals werden.
    In einer verteilten Konfiguration bleiben die Gewichte im VRAM jedes Geräts und nutzen so die deutlich höhere Bandbreite des GPU-Speichers. Zwischen den Geräten werden nur Schichtausgaben übertragen, also Kilobytes statt Gigabytes an Gewichten, sodass der Netzwerkdurchsatz nicht zum Flaschenhals wird.
    Die eigentliche Einschränkung ist die Netzwerklatenz. Wenn man ein Modell auf 4 Geräte verteilt, fällt pro Token dreimal Netzwerklatenz an; bei 1 ms Latenz kommen also 3 ms pro Token hinzu. Selbst wenn man die Rechenzeit mit 0 annimmt, liegt das theoretische Maximum ohne spekulatives Decoding bei etwa 30 tok/s.
    Über das Internet ist die Latenz wahrscheinlich zu hoch, um praktikabel zu sein, aber in lokalen oder Unternehmensnetzwerken ist es mit spekulativem Decoding durchaus machbar. Beim Prefill oder Prompt-Processing akkumuliert sich die Latenz nicht, daher ist die verteilte Konfiguration dort mit hoher Wahrscheinlichkeit schneller.
  • Ich habe in meinem Home Lab 5 ms Latenz und Jitter zwischen den Geräten simuliert und gemessen. Split Inference funktioniert bei WAN-Latenzen auf Metropolniveau ziemlich gut, ist aber über globale WANs nicht besonders schnell.
    Das Ziel ist, mehrere Geräte ohne dediziertes RDMA- oder NVLink-Fabric zu bündeln, um große Modelle auf vorhandener Hardware bereitzustellen und sie mit anderen zu teilen. Derzeit arbeite ich daran, GLM 5.2 mit etwa 10 tok/s in derselben Split-Konfiguration auszuführen.
  • Die Leistung lässt sich relativ einfach grob abschätzen. Beim autoregressiven Decoding müssen pro Token ungefähr 2 × hidden_size × num_shards Byte über das Netzwerk übertragen werden; beim Prefill teilt man diesen Wert durch die Chunk-Größe.
  • Das entspricht ungefähr der Geschwindigkeit, die ich auf einem Framework 13 mit AMD Ryzen AI 9 HX 370 beim Ausführen von Qwen3.6-35B-A3B erreiche. Wenn dieselbe Geschwindigkeit auch bei einem viel größeren Modell herauskommt, wäre das beeindruckend.

• Mich interessiert verteilte Inferenz mit kleinen Sprachmodellen, die für einen bestimmten Zweck gebaut wurden, mehr als Coding-LLMs. Für Bildverarbeitung, Software-defined Radio (SDR) oder lokale Wetterbeobachtung könnte man sie einsetzen, sodass sie selbst auf gewöhnlicher Hardware laufen und dennoch verlässliche Ausgaben liefern.

  • Statt eines einzelnen Modells mit X aktiven Experten scheint eine Konfiguration sinnvoller, bei der 10 unterschiedliche kleine dichte Modelle auf 10 Servern laufen, jeweils mit spezifischen Informationen trainiert und über einen Router verbunden.

• Ich bin Mitwirkender an Mesh LLM und habe die skippy engine entwickelt, mit der sich große Modelle auf mehrere Knoten aufteilen lassen. Wenn es Fragen gibt, beantworte ich sie gern.

  • Es ist schön zu sehen, dass IPFS-nahe Technologien wieder auftauchen. Ich habe zwei Fragen dazu.
    Erstens: Wenn Rechenleistung auf diese Weise verteilt wird, kennen alle Teilnehmer des Rechengraphen die gerade verarbeitete Sequenz — wie geht ihr mit Datenschutz um? Zweitens: Gibt es Schutzmechanismen, damit böswillige Teilnehmer die Aktivierungen des Modells nicht manipulieren können?
  • Ich frage mich, was der Anreiz für die Teilnahme am öffentlichen Mesh ist. Wenn man 1/8 des VRAM beisteuert, der für ein bestimmtes Modell nötig ist, gibt es dann wenigstens eine Fairness-Garantie wie etwa 1/16 der Inferenznutzung?
  • Hätte eine Integration mit dem Colibri-Projekt, das vor ein paar Tagen veröffentlicht wurde, Vorteile?
  • Ich habe mir KV-Cache-Implementierungen nie im Detail angesehen, daher frage ich mich, ob effektiv pro Schicht unabhängige Caches betrieben werden.
    Falls ja, sollte sich das in Bezug auf Rechenaufwand und Datengröße sauber aufteilen lassen, und langsamer würde nur die Zeit, in der jede Schicht auf ihren Zug warten muss. Mit einer Pipeline könnte man dann auch mehrere Anfragen gleichzeitig ausführen.
    Gibt es Beispiele dafür, best-of-N mit einer N-stufigen Pipeline umzusetzen, bei der Anfragen jeweils um einen Schritt versetzt eingespeist werden?
  • Ich betreibe ein Labor mit vielen unterschiedlichen EPYC-Prozessoren und Modellen, und es ist beeindruckend, dass man sie auf diese Weise zu einem Ganzen verbinden kann.

• Bei der Suche nach LLMs mit ähnlichen Ansätzen im verteilten Computing bin ich auf AI Horde, kleinere Versuche rund um Aphrodite und auf verteiltes Training von Nous Research gestoßen.
  Davon scheint AI Horde am größten zu sein. Die API verwendet nicht das Chat-Completion-Format, sondern das Text-Completion-Format von KoboldCPP. Offenbar bevorzugen aktive Mitglieder der Community diesen Ansatz stark, weil mehr Steuerungsparameter offengelegt werden und die Ergebnisse beim Rollenspiel besser sind. Für andere Anwendungsfälle braucht man meist Tool Calling, daher bin ich mir nicht sicher, wofür das außerhalb von Rollenspiel taugt.
  Diese Woche habe ich begonnen, die OpenAI-Bridge zu verbessern, damit sie Chat-Templates und Response Parsing unterstützt. Wenn es in ein offizielles Release kommt, könnte man es auch fürs Coding nutzen, selbst wenn man dafür Rollenspiel-Modelle verwenden muss.
  Auch die Schutzmechanismen gegen Missbrauch sind ausgereifter. Um koordinierte Angriffe zu verhindern, werden Worker erst dann als vertrauenswürdig eingestuft, wenn sie eine kumulierte Uptime von einer Woche erreicht haben, und Nutzer können nur vertrauenswürdige Worker auswählen. Wer einen Worker betreibt, erhält kudos, die für Generierungen mit mehr als 512 Tokens genutzt werden können, und kostenlose Anfragen landen ganz hinten in der Warteschlange.

• Ich habe mich gefragt, was ein polymorphes Botnetz, das ein oder mehrere verteilte LLMs ausführt, tun könnte. Die Idee wäre, alle Hosts eines Botnetzes als Cluster-Rechenressourcen für LLMs zu verwenden und zugleich die Ausbreitungsmechanismen und Payloads jedes Botnetz-Clusters evolvieren zu lassen.
  Schlechte Varianten würden erkannt und entfernt, ineffektive Ausbreitungsmechanismen würden sich nicht verbreiten, aber die besten Versionen würden überleben und weiter wachsen. Das ist der hier vorgestellten Struktur ziemlich ähnlich, und QUIC arbeitet so dynamisch, dass es möglicherweise schwerer zu erkennen ist, als man denkt.

• Das Projekt https://query.mt/ verwendet schon seit einiger Zeit ein iroh-basiertes Mesh. Wer Mesh-Modelle auch auf dem Handy nutzen möchte, sollte es sich ansehen.

• Ich habe eine Weile damit gekämpft, mesh-llm zum Laufen zu bringen, aber unter den installierbaren llama.cpp-Builds gab es keinen, der auf meiner älteren GPU funktionierte. Es sah so aus, als könne man einen externen llama.cpp-Service davor schalten, aber auch diese Konfiguration habe ich nicht erfolgreich hinbekommen.
  Es ist ein sehr interessantes Projekt, aber es gibt noch einige unfertige Stellen.

  • Wenn du einen Bug-Report einreichst, würde ich gern mit dir zusammen daran arbeiten, es zum Laufen zu bringen.

• Ich dachte, dass so etwas möglich sein müsste, und habe ChatGPT vor etwa einem Jahr danach gefragt, aber die Antwort lautete, die Latenz sei zu hoch und mache es unmöglich. Damals hatte ich fast ein Jahr lang libp2p studiert und nach einem Projekt gesucht, in dem ich es einsetzen konnte.