--- title: "Mesh LLM Test: LLM auf mehreren Rechnern" canonical: https://wavect.io/de/blog/mesh-llm-distributed-inference-multiple-computers/ language: de description: "Mesh LLM im Test: Wie Skippy ein LLM auf mehrere Rechner verteilt, echte Benchmarks, Netzwerk-Limits, Security, Alternativen und Pilotplan." image: "https://wavect.io/img/general/bak/open_graph_preview.jpg" --- [**Zurück**](/de/blog/overview/) [![Kevin Riedl](/img/team/kevin.webp)](/de/team/kevin-riedl/) [Kevin Riedl](/de/team/kevin-riedl/) https://linkedin.com/in/wsdt 13 min Lesezeit · 18. Juli 2026 [**Weiter**](/de/blog/ai-vendor-security-questionnaire-eu/) # Mesh LLM im Test: Ein großes LLM auf mehreren Rechnern ausführen? TL;DR Mesh LLM kann ein unterstütztes LLM über mehrere Rechner ausführen, wenn keine Maschine genug Speicher hat. Skippy weist Peers zusammenhängende Layer-Bereiche zu, jeder lädt nur die GGUF-Fragmente seiner Stage, und für jedes Token wandern Aktivierungen über die Stage-Grenzen. Clients nutzen weiter eine OpenAI-kompatible API unter localhost:9337/v1. Das ist Pipeline Model Parallelism, kein normales Load Balancing, und kombiniert Kapazität ohne eine Beschleunigung zu garantieren. Im eigenen Reality-Check sinkt ein Modell, das bereits lokal passt, von 68 tok/s solo auf 21 mit zwei Nodes und 12-13 mit drei. Latenz, langsamste Stage, Context Cache, Familien-Policy und Peer-Verfügbarkeit entscheiden. Der stärkste Business Case ist ein privates Low-Latency-Mesh, wenn das benötigte Modell knapp auf keine vorhandene Maschine passt. Starte mit zwei verkabelten Nodes, geprüftem unveränderlichem Artefakt, echten Workload-Evals, Ausfalltests und Kosten pro erfolgreicher Aufgabe. **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. | Frage | Aktuelle Antwort | Geschäftliche Bedeutung | | --- | --- | --- | | Welches Problem löst es? | Lokale, geroutete und verteilte Inferenz hinter einer API | Vorhandene Rechner nutzen, bevor du einen größeren Host kaufst. | | Wie wird geteilt? | Zusammenhängende Layer-Stages mit Aktivierungsübergaben | Eine Anfrage läuft durch mehrere Rechner. Das ist Model Parallelism, kein normales Load Balancing. | | Artefakte | GGUF und paketierte Layer-Fragmente | Support hängt von Runtime, Artefakt und geprüfter Split-Grenze ab. | | Client-Schnittstelle | OpenAI-kompatibles `/v1` auf Port 9337 | Oft reicht eine neue Base URL statt neuer App-Orchestrierung. | | Netzwerk | QUIC über iroh, Tokens, Nostr oder LAN-Discovery | Einfachere Verbindung, aber Latenz und Vertrauen bleiben deine Verantwortung. | | Lizenz | Apache 2.0 | Runtime kommerziell permissiv, Modelllizenz separat prüfen. | | Produktionsnachweis | Vielversprechend, aber wenige generalisierbare Split-Benchmarks | Vor produktiver Nutzung ist ein begrenzter Pilot Pflicht. | ## Was ist Mesh LLM? [Mesh LLM ist eine Apache-2.0-Runtime für verteilte LLM-Inferenz](https://github.com/Mesh-LLM/mesh-llm). 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](https://github.com/Mesh-LLM/mesh-llm/blob/main/docs/SKIPPY_SPLITS.md) 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.** | Muster | Was bewegt sich? | Ziel | | --- | --- | --- | | Load Balancing | Komplette Anfrage zu einer Modellkopie | Concurrency und Verfügbarkeit | | Peer Routing | Komplette Anfrage zum Modell-Host | Verteiltes Modellinventar nutzen | | Pipeline Split | Zwischenaktivierungen zwischen Layer-Stages | Ein Modell in kombinierten Speicher einpassen | | Tensor Parallelism | Teilergebnisse innerhalb vieler Layer | Layer-Berechnung parallelisieren | 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](https://github.com/Mesh-LLM/mesh-llm/blob/main/docs/BENCHMARKS.md). Für GLM-4.7-Flash Q4 mit 17 GB auf M4 Max und Mac mini M4 über WLAN meldet sie: | Konfiguration | Gemeldet | Relativ zu Solo | | --- | --- | --- | | Solo, ohne Mesh | 68 tok/s | 100 % | | Zwei Nodes, 85/15 | 21 tok/s | 31 % | | Drei Nodes, 62/31/8 | 12 bis 13 tok/s | 18 bis 19 % | 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](https://github.com/Mesh-LLM/mesh-llm/blob/main/docs/skippy/TOPOLOGY_PLANNER.md), 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](https://github.com/Mesh-LLM/mesh-llm/blob/main/docs/skippy/FAMILY_STATUS.md) 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](https://github.com/Mesh-LLM/mesh-llm/blob/main/docs/MESHES.md) 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 | Option | Bester Fit | Unterschied | | --- | --- | --- | | Mesh LLM | Heterogene Rechner, GGUF-Pakete, operator-kontrolliertes Mesh | Lokal, Routing und Layer-Splits hinter einer API | | Exo | Apple-Silicon-Cluster mit schneller Thunderbolt-Verbindung | Starker MLX-Fokus, Pipeline und Tensor Parallelism; siehe [Projektvergleich](https://github.com/Mesh-LLM/mesh-llm/blob/main/docs/EXO_COMPARISON.md) | | llama.cpp RPC | Technische Teams mit eigener Topologie | Niedrigere Ebene, mehr manuelle Orchestrierung | | vLLM oder SGLang | Produktive GPU-Server mit Datacenter-Netzwerk | Stärker für Durchsatz und Betrieb homogener Infrastruktur | | API Gateway | Routing zu vollständigen lokalen oder Cloud-Backends | Macht ein zu großes Einzelmodell nicht über mehrere Maschinen passend | Dieser Artikel beantwortet die Kapazitäts- und Topologiefrage. Für die Finanzentscheidung nutze unseren [Break-even-Vergleich lokaler Modelle gegen APIs](/de/blog/local-models-vs-apis-break-even-eu-2026/). Für die Modellauswahl dient der [Open-Weight-LLM-Vergleich](/de/blog/open-weight-llm-comparison-2026/). So entscheidet nicht die interessanteste Runtime automatisch über die Geschäftsarchitektur. ## Wer sollte Mesh LLM testen? | Situation | Urteil | Warum | | --- | --- | --- | | Zwei bis vier ungenutzte Workstations im schnellen LAN | **Guter Pilot** | Klare freie Kapazität und messbares Netzwerk | | Benötigtes Modell ist knapp zu groß für jeden Host | **Stärkster Use Case** | Zwei Stages können Qualität ohne Neukauf erhalten | | Private Forschung oder Batch mit flexibler Latenz | **Guter Fit** | Kapazität und Kontrolle zählen mehr als Interaktivität | | Modell läuft bereits gut auf einem Host | **Lokal bleiben** | Split fügt Overhead und Fehlerpfade hinzu | | Kunden-API mit harter SLA | **Erst belegen** | Last, Ausfall, Recovery und Tail Latency testen | | Sensible Daten auf unbekannten Public Peers | **Nicht verwenden** | Discovery und Build-Signatur beweisen keinen Host Trust | ## 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](/de/case-studies/twinsoft-ai/) und der [Leitfaden zur Tech-Stack-Auswahl](/de/software-development-guide/how-to-choose-a-tech-stack-for-mvp/) folgen demselben Prinzip. ## Quellen und Methode Architektur, Befehle, API, Artefakte, Support, Security und Benchmarks stammen aus dem [Mesh-LLM-Repository](https://github.com/Mesh-LLM/mesh-llm) 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. ## Häufige Fragen ### Kann Mesh LLM GPUs aus mehreren Rechnern kombinieren? Ja. Skippy verteilt für unterstützte Artefakte zusammenhängende Modell-Layer auf Peers und leitet Aktivierungen weiter. Das schafft gemeinsame Kapazität, aber keine wörtliche Shared-Memory-GPU. ### Ist Mesh LLM normales Load Balancing? Nein. Load Balancing schickt eine vollständige Anfrage an eine vollständige Modellkopie. Ein Skippy-Split führt dieselbe Anfrage nacheinander durch mehrere Layer-Stages. ### Macht verteilte LLM-Inferenz die Ausgabe schneller? Nicht automatisch. Sie kann ein größeres Modell passend machen, fügt aber serielle Netzwerkübergaben hinzu. Wenn das Modell lokal passt, ist ein Rechner meist schneller. ### Welche API bietet Mesh LLM? Jeder Node stellt eine OpenAI-kompatible API unter http://localhost:9337/v1 bereit. ### Lädt jeder Rechner das ganze Modell? Bei Paket-Splits lädt jeder Peer gemeinsame Artefakte plus die Layer-Dateien seiner Stage. ### Kann Mesh LLM über das Internet laufen? Ja, über iroh und Relay-Fallback. Die interaktive Split-Performance hängt jedoch von jeder Stage-Latenz ab. Ein kabelgebundenes LAN ist der bessere Start. ### Ist Mesh LLM für vertrauliche Unternehmensdaten geeignet? Nur in einem privat und kontrolliert betriebenen Mesh mit Owner- und Admission-Policy, geschützten Tokens, eingeschränkten Listenern und geprüften Logs. Public Discovery allein reicht nicht. ### Wann sollte ein Unternehmen lieber eine größere GPU kaufen? Bevorzuge einen Host, wenn er Qualität, Context, Concurrency, Latenz und Verfügbarkeit erfüllt. Teste ein Mesh, wenn das benötigte Modell jeden Host überschreitet und schnelle freie Rechner vorhanden sind. ## Fazit Mesh LLM stellt die richtige Kapazitätsfrage: Welches Modell können diese Rechner gemeinsam ausführen? Skippy kann zusammenhängende Layer-Stages verteilen, nur benötigte Paket-Fragmente laden und die Anwendung auf einer OpenAI-kompatiblen API halten. Die Grenze bleibt Physik. Decode läuft seriell durch Stages, Latenz wiederholt sich pro Token, der langsamste Peer bestimmt das Tempo und jeder benötigte Node vergrößert die Failure Domain. Nutze Mesh LLM, wenn kombinierter Speicher ein sonst unmögliches Modell freischaltet. Bleib lokal, wenn es bereits passt. Lass einen gemessenen Zwei-Node-Pilot entscheiden, ob freie Hardware wirklich günstiger ist als eine größere Maschine oder ein Hosted Endpoint. ## Das könnte dich auch interessieren.. [**Wann lokale Modelle APIs schlagen** Berechne Auslastung, Engineering, Latenz, Governance und Fallback, nachdem die Topologie den Workload-Test besteht.](/de/blog/local-models-vs-apis-break-even-eu-2026/) [**AI Enablement vs. generische KI-Beratung** Vergleiche messbare Produktionsumsetzung mit Beratung, die bei Slides endet.](/de/compare/ai-enablement-vs-generic-ai-consultancy/) Modelle und Infrastruktur ## In diesem Cluster weiterlesen [Mit dem Grundlagenartikel starten**LLMs in der EU selbst hosten: Wann sich Open Weights wirklich rechnen**](/de/blog/self-hosting-llms-eu-cost/) - [Gemini Robotics 2: Ganzkörpersteuerung und die Pilotentscheidung](/de/blog/gemini-robotics-2-whole-body-control/) - [pdf-inspector im Test: PDFs vor OCR lokal routen](/de/blog/pdf-inspector-ocr-routing/) - [Lokaler multimodaler KI-Coding-Assistent: Sprache, OCR und Datenschutz](/de/blog/local-multimodal-ai-coding-assistant/) - [DeepSeek V4 Flash 0731 auf einem KI-PC: Was funktioniert?](/de/blog/deepseek-v4-flash-0731-local-ai-pc/) - [Gemma 4 kostenlos mit Unsloth und Colab tunen](/de/blog/fine-tune-gemma-4-free-unsloth-colab/) Postfach, ohne Lärm ## Folge der Arbeit, die für dich zählt Du bekommst eine kurze E-Mail, wenn wir etwas Neues veröffentlichen. Folge dem ganzen Blog oder nur den Themen, die dich interessieren. [**Zurück**](/de/blog/overview/) [![Kevin Riedl](/img/team/kevin.webp)](/de/team/kevin-riedl/) [Kevin Riedl](/de/team/kevin-riedl/) https://linkedin.com/in/wsdt 13 min Lesezeit · 18. Juli 2026 [**Weiter**](/de/blog/ai-vendor-security-questionnaire-eu/) Neue Beiträge per E-Mail × × Neue Beiträge per E-Mail Eine kurze E-Mail, wenn wir etwas veröffentlichen. Kostenlos, ohne Tracking. ## Structured Data ```json { "@context": "https://schema.org", "@graph": [ { "@id": "https://wavect.io/#organization", "@type": [ "Organization", "ProfessionalService", "LocalBusiness" ], "employee": [ { "@id": "https://wavect.io/team/kevin-riedl/#person", "@type": "Person", "jobTitle": "Managing Director", "name": "Kevin Riedl", "url": "https://wavect.io/team/kevin-riedl/", "worksFor": { "@id": "https://wavect.io/#organization", "@type": [ "Organization", "ProfessionalService", "LocalBusiness" ] } }, { "@id": "https://wavect.io/team/christof-jori/#person", "@type": "Person", "jobTitle": "Managing Director", "name": "Christof Jori", "url": "https://wavect.io/team/christof-jori/", "worksFor": { "@id": "https://wavect.io/#organization", "@type": [ "Organization", "ProfessionalService", "LocalBusiness" ] } } ], "founder": [ { "@id": "https://wavect.io/team/kevin-riedl/#person", "@type": "Person", "jobTitle": "Managing Director", "name": "Kevin Riedl", "url": "https://wavect.io/team/kevin-riedl/", "worksFor": { "@id": "https://wavect.io/#organization", "@type": [ "Organization", "ProfessionalService", "LocalBusiness" ] } }, { "@id": "https://wavect.io/team/christof-jori/#person", "@type": "Person", "jobTitle": "Managing Director", "name": "Christof Jori", "url": "https://wavect.io/team/christof-jori/", "worksFor": { "@id": "https://wavect.io/#organization", "@type": [ "Organization", "ProfessionalService", "LocalBusiness" ] } } ], "legalRepresentative": [ { "@id": "https://wavect.io/team/kevin-riedl/#person", "@type": "Person", "jobTitle": "Managing Director", "name": "Kevin Riedl", "url": "https://wavect.io/team/kevin-riedl/", "worksFor": { "@id": "https://wavect.io/#organization", "@type": [ "Organization", "ProfessionalService", "LocalBusiness" ] } }, { "@id": "https://wavect.io/team/christof-jori/#person", "@type": "Person", "jobTitle": "Managing Director", "name": "Christof Jori", "url": "https://wavect.io/team/christof-jori/", "worksFor": { "@id": "https://wavect.io/#organization", "@type": [ "Organization", "ProfessionalService", "LocalBusiness" ] } } ], "name": "Wavect GmbH", "subjectOf": { "@id": "https://wavect.io/verified-claims.json#dataset", "@type": "Dataset", "creator": { "@id": "https://wavect.io/#organization", "@type": [ "Organization", "ProfessionalService", "LocalBusiness" ] }, "description": "A machine-readable registry of quantitative and qualitative claims published by Wavect, with review dates, localized page appearances and public third-party citations where available.", "inLanguage": "en", "isAccessibleForFree": true, "license": "https://creativecommons.org/licenses/by/4.0/", "name": "Wavect verified publication claims", "url": "https://wavect.io/verified-claims.json" }, "url": "https://wavect.io/" }, { "@id": "https://wavect.io/team/kevin-riedl/#person", "@type": "Person", "jobTitle": "Managing Director", "name": "Kevin Riedl", "sameAs": [ "https://www.wikidata.org/wiki/Q139796365", "https://www.linkedin.com/in/wsdt", "https://github.com/wsdt" ], "url": "https://wavect.io/team/kevin-riedl/", "worksFor": { "@id": "https://wavect.io/#organization", "@type": [ "Organization", "ProfessionalService", "LocalBusiness" ] } }, { "@id": "https://wavect.io/team/christof-jori/#person", "@type": "Person", "jobTitle": "Managing Director", "name": "Christof Jori", "sameAs": [ "https://www.wikidata.org/wiki/Q139796367", "https://www.linkedin.com/in/jocr77/", "https://github.com/jo-chris" ], "url": "https://wavect.io/team/christof-jori/", "worksFor": { "@id": "https://wavect.io/#organization", "@type": [ "Organization", "ProfessionalService", "LocalBusiness" ] } }, { "@id": "https://wavect.io/#website", "@type": "WebSite", "inLanguage": [ "en", "de", "es", "zh" ], "name": "Wavect", "potentialAction": { "@type": "SearchAction", "query-input": "required name=search_term_string", "target": { "@type": "EntryPoint", "urlTemplate": "https://wavect.io/search/?q={search_term_string}" } }, "publisher": { "@id": "https://wavect.io/#organization", "@type": [ "Organization", "ProfessionalService", "LocalBusiness" ] }, "url": "https://wavect.io/" }, { "@id": "https://wavect.io/de/blog/mesh-llm-distributed-inference-multiple-computers/#webpage", "@type": "WebPage", "dateModified": "2026-07-18", "inLanguage": "de", "isPartOf": { "@id": "https://wavect.io/#website", "@type": "WebSite" }, "lastReviewed": "2026-07-18", "url": "https://wavect.io/de/blog/mesh-llm-distributed-inference-multiple-computers/" } ] } ``` ```json { "@context": "https://schema.org", "@type": "BlogPosting", "abstract": "Mesh LLM kann ein unterstütztes LLM über mehrere Rechner ausführen, wenn keine Maschine genug Speicher hat. Skippy weist Peers zusammenhängende Layer-Bereiche zu, jeder lädt nur die GGUF-Fragmente seiner Stage, und für jedes Token wandern Aktivierungen über die Stage-Grenzen. Clients nutzen weiter eine OpenAI-kompatible API unter localhost:9337/v1. Das ist Pipeline Model Parallelism, kein normales Load Balancing, und kombiniert Kapazität ohne eine Beschleunigung zu garantieren. Im eigenen Reality-Check sinkt ein Modell, das bereits lokal passt, von 68 tok/s solo auf 21 mit zwei Nodes und 12-13 mit drei. Latenz, langsamste Stage, Context Cache, Familien-Policy und Peer-Verfügbarkeit entscheiden. Der stärkste Business Case ist ein privates Low-Latency-Mesh, wenn das benötigte Modell knapp auf keine vorhandene Maschine passt. Starte mit zwei verkabelten Nodes, geprüftem unveränderlichem Artefakt, echten Workload-Evals, Ausfalltests und Kosten pro erfolgreicher Aufgabe.", "articleBody": " Blog-Übersicht/AI und Agents/Modelle und Infrastruktur Mesh LLM im Test: Ein großes LLM auf mehreren Rechnern ausführen? TL;DR Mesh LLM kann ein unterstütztes LLM über mehrere Rechner ausführen, wenn keine Maschine genug Speicher hat. Skippy weist Peers zusammenhängende Layer-Bereiche zu, jeder lädt nur die GGUF-Fragmente seiner Stage, und für jedes Token wandern Aktivierungen über die Stage-Grenzen. Clients nutzen weiter eine OpenAI-kompatible API unter localhost:9337/v1. Das ist Pipeline Model Parallelism, kein normales Load Balancing, und kombiniert Kapazität ohne eine Beschleunigung zu garantieren. Im eigenen Reality-Check sinkt ein Modell, das bereits lokal passt, von 68 tok/s solo auf 21 mit zwei Nodes und 12-13 mit drei. Latenz, langsamste Stage, Context Cache, Familien-Policy und Peer-Verfügbarkeit entscheiden. Der stärkste Business Case ist ein privates Low-Latency-Mesh, wenn das benötigte Modell knapp auf keine vorhandene Maschine passt. Starte mit zwei verkabelten Nodes, geprüftem unveränderlichem Artefakt, echten Workload-Evals, Ausfalltests und Kosten pro erfolgreicher Aufgabe. 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. Mesh LLM für eine technische KaufentscheidungFrageAktuelle AntwortGeschäftliche Bedeutung Welches Problem löst es?Lokale, geroutete und verteilte Inferenz hinter einer APIVorhandene Rechner nutzen, bevor du einen größeren Host kaufst. Wie wird geteilt?Zusammenhängende Layer-Stages mit AktivierungsübergabenEine Anfrage läuft durch mehrere Rechner. Das ist Model Parallelism, kein normales Load Balancing. ArtefakteGGUF und paketierte Layer-FragmenteSupport hängt von Runtime, Artefakt und geprüfter Split-Grenze ab. Client-SchnittstelleOpenAI-kompatibles /v1 auf Port 9337Oft reicht eine neue Base URL statt neuer App-Orchestrierung. NetzwerkQUIC über iroh, Tokens, Nostr oder LAN-DiscoveryEinfachere Verbindung, aber Latenz und Vertrauen bleiben deine Verantwortung. LizenzApache 2.0Runtime kommerziell permissiv, Modelllizenz separat prüfen. ProduktionsnachweisVielversprechend, aber wenige generalisierbare Split-BenchmarksVor produktiver Nutzung ist ein begrenzter Pilot Pflicht. 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. Lokal: Das aktuelle Gerät führt das ganze Modell aus, wenn es passt. Kein Netzwerk-Overhead. Peer Routing: Die komplette Anfrage geht an einen Rechner, der das Modell bereits anbietet. 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: Der Coordinator löst Modell oder Layer-Paket auf. Der Topology Planner wählt geeignete Peers und zusammenhängende Layer-Bereiche. Die letzte Stage lädt zuerst, danach die vorgelagerten Stages. Jeder Peer lädt gemeinsame Metadaten und nur seine Layer-Dateien. Stage 0 wird erst geroutet, wenn alle benötigten Stages bereit sind. 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.", "articleSection": "Engineering", "author": { "@id": "https://wavect.io/team/kevin-riedl/#person", "@type": "Person", "name": "Kevin Riedl", "sameAs": [ "https://www.wikidata.org/wiki/Q139796365", "https://www.linkedin.com/in/wsdt", "https://github.com/wsdt" ], "url": "https://wavect.io/team/kevin-riedl/" }, "dateModified": "2026-07-18", "datePublished": "2026-07-18", "description": "Mesh LLM kann ein unterstütztes LLM über mehrere Rechner ausführen, wenn keine Maschine genug Speicher hat. Skippy weist Peers zusammenhängende Layer-Bereiche zu, jeder lädt nur die GGUF-Fragmente seiner Stage, und für jedes Token wandern Aktivierungen über die Stage-Grenzen. Clients nutzen weiter eine OpenAI-kompatible API unter localhost:9337/v1. Das ist Pipeline Model Parallelism, kein normales Load Balancing, und kombiniert Kapazität ohne eine Beschleunigung zu garantieren. Im eigenen Reality-Check sinkt ein Modell, das bereits lokal passt, von 68 tok/s solo auf 21 mit zwei Nodes und 12-13 mit drei. Latenz, langsamste Stage, Context Cache, Familien-Policy und Peer-Verfügbarkeit entscheiden. Der stärkste Business Case ist ein privates Low-Latency-Mesh, wenn das benötigte Modell knapp auf keine vorhandene Maschine passt. Starte mit zwei verkabelten Nodes, geprüftem unveränderlichem Artefakt, echten Workload-Evals, Ausfalltests und Kosten pro erfolgreicher Aufgabe.", "headline": "Mesh LLM im Test: Ein großes LLM auf mehreren Rechnern ausführen?", "image": "https://wavect.io/img/blog/headers/header_mesh-llm-distributed-inference-multiple-computers.svg", "inLanguage": "de", "mainEntityOfPage": { "@id": "https://wavect.io/de/blog/mesh-llm-distributed-inference-multiple-computers/", "@type": "WebPage" }, "publisher": { "@id": "https://wavect.io/#organization", "@type": [ "Organization", "ProfessionalService", "LocalBusiness" ] }, "url": "https://wavect.io/de/blog/mesh-llm-distributed-inference-multiple-computers/", "wordCount": 2061 } ``` ```json { "@context": "https://schema.org", "@type": "BreadcrumbList", "itemListElement": [ { "@type": "ListItem", "item": "https://wavect.io/de/", "name": "Startseite", "position": 1 }, { "@type": "ListItem", "item": "https://wavect.io/de/blog/overview/", "name": "Blog-Übersicht", "position": 2 }, { "@type": "ListItem", "item": "https://wavect.io/de/blog/topics/ai-agents/", "name": "AI und Agents", "position": 3 }, { "@type": "ListItem", "item": "https://wavect.io/de/blog/clusters/models-infrastructure/", "name": "Modelle und Infrastruktur", "position": 4 }, { "@type": "ListItem", "item": "https://wavect.io/de/blog/mesh-llm-distributed-inference-multiple-computers/", "name": "Mesh LLM Test: LLM auf mehreren Rechnern | ", "position": 5 } ] } ``` ```json { "@context": "https://schema.org", "@type": "FAQPage", "mainEntity": [ { "@type": "Question", "acceptedAnswer": { "@type": "Answer", "text": "Ja. Skippy verteilt für unterstützte Artefakte zusammenhängende Modell-Layer auf Peers und leitet Aktivierungen weiter. Das schafft gemeinsame Kapazität, aber keine wörtliche Shared-Memory-GPU." }, "name": "Kann Mesh LLM GPUs aus mehreren Rechnern kombinieren?" }, { "@type": "Question", "acceptedAnswer": { "@type": "Answer", "text": "Nein. Load Balancing schickt eine vollständige Anfrage an eine vollständige Modellkopie. Ein Skippy-Split führt dieselbe Anfrage nacheinander durch mehrere Layer-Stages." }, "name": "Ist Mesh LLM normales Load Balancing?" }, { "@type": "Question", "acceptedAnswer": { "@type": "Answer", "text": "Nicht automatisch. Sie kann ein größeres Modell passend machen, fügt aber serielle Netzwerkübergaben hinzu. Wenn das Modell lokal passt, ist ein Rechner meist schneller." }, "name": "Macht verteilte LLM-Inferenz die Ausgabe schneller?" }, { "@type": "Question", "acceptedAnswer": { "@type": "Answer", "text": "Jeder Node stellt eine OpenAI-kompatible API unter http://localhost:9337/v1 bereit." }, "name": "Welche API bietet Mesh LLM?" }, { "@type": "Question", "acceptedAnswer": { "@type": "Answer", "text": "Bei Paket-Splits lädt jeder Peer gemeinsame Artefakte plus die Layer-Dateien seiner Stage." }, "name": "Lädt jeder Rechner das ganze Modell?" }, { "@type": "Question", "acceptedAnswer": { "@type": "Answer", "text": "Ja, über iroh und Relay-Fallback. Die interaktive Split-Performance hängt jedoch von jeder Stage-Latenz ab. Ein kabelgebundenes LAN ist der bessere Start." }, "name": "Kann Mesh LLM über das Internet laufen?" }, { "@type": "Question", "acceptedAnswer": { "@type": "Answer", "text": "Nur in einem privat und kontrolliert betriebenen Mesh mit Owner- und Admission-Policy, geschützten Tokens, eingeschränkten Listenern und geprüften Logs. Public Discovery allein reicht nicht." }, "name": "Ist Mesh LLM für vertrauliche Unternehmensdaten geeignet?" }, { "@type": "Question", "acceptedAnswer": { "@type": "Answer", "text": "Bevorzuge einen Host, wenn er Qualität, Context, Concurrency, Latenz und Verfügbarkeit erfüllt. Teste ein Mesh, wenn das benötigte Modell jeden Host überschreitet und schnelle freie Rechner vorhanden sind." }, "name": "Wann sollte ein Unternehmen lieber eine größere GPU kaufen?" } ] } ```