Shard: Wie ein Open-Source-Projekt dezentrale KI-Inferenz auf Consumer-GPUs neu definiert

Ein 744-Milliarden-Parameter-Modell mit ~30 Tokens pro Sekunde – nicht im Rechenzentrum, sondern über sechs RTX PRO 6000 GPUs verteilt auf verschiedene US-Bundesstaaten. Das Open-Source-Projekt Shard zeigt, dass dezentrale KI-Inferenz kein Forschungstraum mehr ist, sondern praktisch funktioniert. Und es könnte die Art, wie wir große Sprachmodelle betreiben, grundlegend verändern.

Was ist passiert?

Im Juni 2026 veröffentlichte der Entwickler „leyten“ das Projekt Shard – eine Pipeline-Parallel-Engine für LLM-Inferenz, die große Modelle über mehrere Consumer-GPUs auf verschiedenen Maschinen verteilt. Der Clou: Die GPUs müssen nicht im selben Raum, nicht einmal im selben Land stehen. Sie kommunizieren über das offene Internet.

Der bislang eindrucksvollste Lauf: GLM-5.2 mit 744 Milliarden Parametern (NVFP4-Quantisierung, ~410 GB) lief mit rund 30 Tokens pro Sekunde auf sechs NVIDIA RTX PRO 6000 Blackwell-GPUs in sechs verschiedenen US-Bundesstaaten. Ein weiterer Meilenstein: gpt-oss-120B erreichte ~40 Tok/s auf nur drei RTX 4090 Consumer-Karten plus einem Koordinator – ebenfalls über WAN.

Zum Vergleich: Das letzte nennenswerte Projekt in dieser Richtung, Petals aus dem Jahr 2022, erreichte etwa 1-5 Tok/s für vergleichbare Setups. Shard liefert also eine 15- bis 20-fache Verbesserung. Der Code steht unter Apache-2.0-Lizenz auf GitHub.

Wie funktioniert das technisch?

Die Grundidee ist Pipeline-Parallelität: Ein Modell wird in aufeinanderfolgende Layer-Blöcke zerlegt. Jede GPU hält einen Block und reicht die Aktivierungen an die nächste weiter – ein Ring aus „Stage Nodes“. Ein separater Koordinator (der selbst keine Modell-Layer hält) treibt die Generierung mit einem kleinen Draft-Modell an.

Drei technische Durchbrüche machen die Geschwindigkeit möglich:

1. Speculative Decoding über WAN: Der Koordinator schlägt mit einem kleinen Draft-Modell mehrere Tokens vor. Das verteilte Hauptmodell verifiziert alle Vorschläge in einer einzigen Ring-Durchquerung. Ein Roundtrip committed mehrere Tokens – das amortisiert die Netzwerklatenz.
2. Ring-Pipelining mit Direct Return: Der letzte Knoten (Tail) sendet Ergebnisse direkt an den Koordinator zurück, statt sie durch alle Zwischenstationen zu relayen. Das halbiert effektiv die Return-Latenz.
3. CUDA-Graphed Forward-Pass: Der Vorwärtsdurchlauf jeder Stage wird als CUDA-Graph vorcompiliert und als Einheit replaed. Ergebnis: 4-5× weniger Launch-Overhead pro Durchlauf, bitgenaue Ausgabe.

Der Scheduler wählt GPUs nach Latenz-Clustern aus, nicht einfach nach verfügbarer VRAM. Eine Erkenntnis aus der Praxis: Den Koordinator in die Region des Schwarms zu platzieren, brachte eine 50-prozentige Verbesserung (174 → 102 ms Ring-Latenz).

Was die Zahlen wirklich bedeuten

30-40 Tok/s klingen im Vergleich zu kommerziellen APIs (OpenAI, Anthropic liefern 60-100+ Tok/s) zunächst bescheiden. Der entscheidende Kontext: Diese Geschwindigkeit wird nicht in einem kontrollierten Rechenzentrum mit NVIDIA H100/H200 im NVLink-Verbund erreicht, sondern auf Consumer-Hardware über das öffentliche Internet.

Für die Einordnung: Ein 744B-Modell auf einem einzelnen H100-Server zu betreiben, erfordert mindestens 8-16 GPUs mit NVLink – ein Setup, das mehrere hunderttausend Euro kostet. Shard erreicht vergleichbare Funktionalität mit gemieteten Consumer-GPUs für etwa 5 US-Dollar pro Stunde. Der Kostenunterschied ist nicht linear – er ist eine Größenordnung.

Die Geschwindigkeit ist zudem prompt-abhängig: Bei Code-Generierung (deterministischere Muster) erreicht Shard 24-25 Tok/s warm; bei kreativen Texten etwa 18-19 Tok/s. Das ist vergleichbar mit der Lesegeschwindigkeit eines Menschen – also durchaus alltagstauglich.

Die Architektur dahinter: c0mpute und Shard

Shard ist die technische Engine, c0mpute.ai das darüberliegende Netzwerk. Die Idee: Jeder kann seine GPU dem Netzwerk zur Verfügung stellen und wird pro generiertem Token in USDC bezahlt. Modelle laufen unzensiert und ohne Content-Filter in der Inferenz-Pipeline.

Die Sicherheitsarchitektur setzt auf mehrere Ebenen:

• Content-Addressing: Jedes Modell wird mit einem signierten Manifest ausgeliefert, das die Hashes aller Shards enthält. Ein Knoten verifiziert jeden heruntergeladenen Chunk kryptografisch. Ein bösartiger Peer kann keine manipulierten Gewichte einschleusen.
• Signierte Receipts: Jeder Inferenz-Lauf produziert einen verifizierbaren Beleg mit GPU-UUIDs, IP-Adressen, Latenzmessungen und Output-Hashes. Externe können die Echtheit eines Laufs unabhängig prüfen.
• Per-Node Identity: Jeder Knoten authentifiziert sich mit seinem eigenen Schlüssel. Kein geteiltes PSK mehr – ein Knoten ohne gültigen Token kann nicht beitreten.

Die Roadmap ist ambitioniert, aber ehrlich kommuniziert: Trustless Verification (betrügerische Knoten zuverlässig erkennen) wird als „genuine research“ eingestuft – kein gelöstes Problem. Privacy (Aktivierungen, die ein Knoten sieht) wird phasenweise angegangen, beginnend mit Boundary-Layer-Pinning: Embedding und Final Layer nur auf vertrauenswürdigen Knoten.

Was bedeutet das für Deutschland und Europa?

Für den deutschen und europäischen KI-Standort ist Shard aus drei Gründen relevant:

1. Souveränität: Europäische Unternehmen könnten große Open-Source-Modelle auf eigener, geografisch verteilter Infrastruktur betreiben – ohne Abhängigkeit von US-Cloud-Anbietern. Der AI Act fordert für bestimmte Anwendungen Datenlokalisierung; Shard macht das technisch praktikabler.
2. Kosteneffizienz: Statt Millionen in Rechenzentrums-Hardware zu investieren, könnten Unternehmen und Forschungseinrichtungen vorhandene GPU-Kapazitäten bündeln. Deutschland hat eine hohe Dichte an leistungsfähigen Consumer- und Prosumer-GPUs in Universitäten, Mittelstand und bei Privatanwendern.
3. Open-Source-Ökosystem: Shard ist Apache-2.0-lizenziert. Europäische KI-Initiativen wie OpenFabric oder nationale Sprachmodell-Projekte könnten die Engine als Inference-Backend adaptieren. Kein Vendor-Lock-in, keine proprietären Lizenzen.

Die Kehrseite: Europas fragmentierte Internet-Infrastruktur mit teils höheren Latenzen zwischen Ländern könnte die Performance im Vergleich zu US-Clustern dämpfen. Das ist jedoch ein gradueller, kein fundamentaler Unterschied.

Praxis-Check: Was Entwickler und Unternehmen jetzt tun können

1. Repo klonen und lokal testen: Shard läuft auf jeder Linux-Maschine mit NVIDIA-GPU (ab RTX 3090). Der Einstieg ist dokumentiert unter github.com/leyten/shard. Für erste Tests reichen zwei GPUs im selben Netzwerk.
2. GPU-Kapazität inventarisieren: Unternehmen mit verteilten Standorten oder Remote-Mitarbeitern mit leistungsfähigen Workstations sollten prüfen, welche ungenutzte GPU-Kapazität vorhanden ist. Shard kann auch „nebenbei“ auf Workstations laufen, die primär für andere Aufgaben genutzt werden.
3. Anwendungsfälle identifizieren: Wo im Unternehmen werden heute externe KI-APIs genutzt, bei denen Datenschutz, Kosten oder Latenz ein Problem sind? Interne Code-Assistenz, vertrauliche Dokumentanalyse und Chat-Systeme für sensible Daten sind naheliegende Kandidaten.
4. Nicht blind investieren: Das Projekt ist jung. Trustless Verification ist ungelöst, die Node-Stabilität über Tage nicht garantiert, und die Dokumentation ist technisch anspruchsvoll. Wer jetzt evaluiert, sollte das mit einem Research-Mindset tun, nicht als Produktions-Rollout.

Was die Skeptiker sagen – und was dran ist

Nicht jeder ist überzeugt. Die kritischen Punkte:

• „Das funktioniert nur mit handverlesenen GPUs“: Die demonstrierten Läufe nutzten RTX PRO 6000 Blackwell-Karten mit 96 GB VRAM – keine typischen Consumer-GPUs. Der Schwarm aus RTX 4090 (24 GB) benötigt mehr Knoten und leidet unter mehr Netzwerk-Hops. Ein 120B-Modell läuft darauf, ein 744B-Modell wäre mit 24-GB-Karten nicht praktikabel.
• „Die Fault-Tolerance fehlt“: Fällt ein Knoten mitten in der Inferenz aus, bricht die Anfrage ab. KV-Cache-Migration über Knoten hinweg ist ungelöst. In einem Netzwerk aus flüchtigen Consumer-GPUs passiert das häufiger, als man denkt.
• „Privacy ist eine Illusion“: Jeder Knoten sieht die Aktivierungen, die er verarbeitet. Aus einzelnen Layer-Aktivierungen lassen sich keine vollständigen Texte rekonstruieren, aber das Restrisiko ist real. Das Team selbst stuft Privacy als „Phase 6″ ein – also weit hinten auf der Roadmap.
• „Die ökonomischen Anreize sind unklar“: Wer stellt seine GPU für ein paar Cent pro Stunde zur Verfügung, wenn Strom und Abnutzung mehr kosten? Das c0mpute-Netzwerk existiert bereits für Single-GPU-Inferenz – aber ob die Token-Ökonomie für Swarm-Workloads aufgeht, ist offen.

Diese Einwände sind berechtigt und teilweise ungelöst. Sie machen Shard nicht wertlos – sie definieren, wo das Projekt heute steht: ein beeindruckender technischer Beweis, dass dezentrale LLM-Inferenz kein theoretisches Konzept mehr ist, aber noch vor der Produktionsreife.

Fazit

Shard ist der bislang überzeugendste Beweis, dass dezentrale KI-Inferenz auf Consumer-Hardware praktisch funktioniert. Die Kombination aus WAN-optimiertem Speculative Decoding, CUDA-Graphed Forward-Passes und latenzbewusstem Scheduling liefert Geschwindigkeiten, die vor einem Jahr noch undenkbar waren.

Für Entwickler und Unternehmen ist jetzt der richtige Zeitpunkt, das Projekt zu evaluieren – nicht blind zu deployen. Die technische Grundlage steht. Was noch fehlt, ist die Betriebssicherheit für den Produktiveinsatz. Aber die Richtung ist klar: Die Ära, in der große KI-Modelle nur in zentralisierten Rechenzentren laufen konnten, geht zu Ende.

Der Shard-Code ist Open Source auf GitHub. Die Dokumentation findet sich unter c0mpute.ai. Wer selbst testen will: Zwei RTX 3090/4090 im selben Netzwerk reichen für erste Experimente.