Skip to main content
AI Tool Radar
OSI-openLokale Inference und "was läuft auf meiner Maschine"

SwarmLLM

nehanth

Verteilt die Layer eines 27B-Modells über Browser-Tabs auf verschiedenen Geräten via WebRTC, sodass keine einzelne Maschine das ganze Modell halten muss.

435 Stars(Stand 2026-09-23)Auf GitHub ansehenHomepage

Was ist SwarmLLM?

Eine JavaScript/WebGPU-Engine, die ein LLM schichtweise über mehrere Geräte verteilt, jedes hält nur eine Scheibe der Layer, und nur ein rund 10-KB-Aktivierungsvektor wandert zwischen den Peers via WebRTC. Ein eigener WGSL-Kernel-Stack (rund 50 Kernel) mit 4-Bit-Quantisierung und spekulativem Decoding läuft direkt im Browser, ohne Server und ohne Installation.

SwarmLLM auf einen Blick
MerkmalWert
Maintainernehanth
GitHub-Stars435 (Stand 2026-09-23)
Forks62
LizenzMIT
LizenztypOSI-open
KategorieLokale Inference und "was läuft auf meiner Maschine"
StatusAufsteigend
Edition2026-09
Zuletzt geprüft2026-09-23

SwarmLLM im Detail

Ein großes Sprachmodell laufen zu lassen, hat bisher immer vorausgesetzt, dass eine einzelne Maschine das komplette Modell trägt, was alle ausschließt, deren einzelnes Gerät, Laptop, Handy oder Desktop, dafür allein nicht stark genug ist. SwarmLLM, gebaut von Nehanth Narendrula, stellt genau diese Annahme infrage, indem es die Layer eines Modells über mehrere Browser-Tabs auf verschiedenen Geräten verteilt, verbunden via WebRTC, ohne Server und ohne Installation. Die eigene Formulierung des Projekts bringt die Idee auf den Punkt: Jedes Gerät bringt eine Scheibe mit, zusammen laufen sie das ganze Modell. Eine Demo, die ein MacBook und ein iPhone koppelt, um ein 27B-Modell laufen zu lassen, zeigt am klarsten, was das Projekt eigentlich beweisen will.

Die Technik ist von Grund auf selbst gebaut statt geliehen. SwarmLLM liefert eine eigene WebGPU-Engine mit rund 50 WGSL-Kerneln, einen eigenen GGUF-Parser zum Laden quantisierter Gewichte und eine WebRTC-Mesh-Schicht namens room.js, die Signaling und Peer-Verbindungen über Netzwerke hinweg handhabt. Jeder Peer verarbeitet seine Scheibe der Layer und gibt nur einen kleinen Aktivierungsvektor von rund 10 KB an das nächste Gerät in der Kette weiter, statt rohe Gewichte oder vollständige Hidden States zu verschicken. 4-Bit-Quantisierung und spekulatives Decoding mit Multi-Token-Vorhersage senken sowohl Speicherbedarf als auch Latenz pro Token, und das Projekt sichert jede Optimierung über eine Golden-Test-Suite ab, die numerische Ergebnisse bit-exakt halten soll.

Am besten passt es zu technisch neugierigen Nutzern, die damit experimentieren, eigene Geräte zu bündeln, einen Laptop plus ein Handy, oder ungenutzte Hardware im Haushalt, um ein Modell laufen zu lassen, das für keines allein zu groß wäre, komplett im Browser und ohne Installation. Weil kein Server nötig ist, passt es auch zu Leuten, die verteilte Inference ausprobieren wollen, ohne Infrastruktur aufzusetzen. Es zielt noch nicht auf Produktions-Workloads; das Raum-basierte, spontane Verbindungsmodell (swarmllm.ai/room besuchen, um zu starten oder beizutreten) liest sich eher wie ein bewusst gestartetes Experiment als wie ein Dauerdienst.

Die Einschränkungen sind erheblich und werden vom eigenen Issue-Tracker des Projekts größtenteils selbst benannt. Bisher gibt es nur ein Release (v0.2.0), und das 2.048-Token-Kontextfenster wird intern explizit als wachstumsbedürftig markiert, mit einer noch bestehenden harten 400-Token-Antwortgrenze. Die Zuverlässigkeit hängt davon ab, dass jedes teilnehmende Gerät verbunden bleibt: offene Issues beschreiben abbrechende Worker-Tabs unter Speicherdruck oder wenn ein Browser-Tab in den Hintergrund wechselt, sowie Staukontrolle auf dem Datenkanal, die pro Hop echte Latenz hinzufügt. Die Durchsatzzahlen, 9 Tokens pro Sekunde ohne spekulatives Decoding und 16 damit auf einem GB10, oder 10,7 Tokens pro Sekunde in der MacBook-plus-iPhone-Demo, sind eigene Benchmarks des Projekts auf eigener Hardware.

Das Fazit: SwarmLLM ist eine wirklich neuartige und solide gebaute Antwort auf eine Frage, die die meisten Local-Inference-Projekte gar nicht stellen, ob mehrere eigene Geräte gemeinsam ein Modell tragen können, das keines allein tragen könnte. Greif als Experiment zu, wenn du dich in einer Pre-1.0-, browserbasierten, spontanen Umgebung wohlfühlst und heute schon verteilte Inference in Aktion sehen willst. Zu früh ist es für alles, was nach Produktionseinsatz aussieht, angesichts des einzigen Releases, der offen dokumentierten Kontext- und Zuverlässigkeitsgrenzen und Durchsatzzahlen, die außerhalb der eigenen Tests des Projekts unverifiziert bleiben.

Vor- & Nachteile

Pros

  • Echte Eigenentwicklung von Grund auf: eigene WGSL-Kernel, ein GGUF-Parser und ein WebRTC-Mesh-Protokoll, abgesichert durch eine Golden-Test-Suite, die laut Projekt jede Optimierung absichert
  • Kein Install und kein Server, läuft im Browser und bündelt ungenutzte Geräte (Laptop + Handy) zu einem Modell, das keines allein tragen könnte
  • MIT, aktive tägliche Commits mit strukturierten, gelabelten Issues (P1/P2, Milestones)

Cons

  • Sehr früh: ein Release (v0.2.0), und das eigene Issue-Tracking des Projekts markiert das 2048-Token-Kontextfenster selbst als zu kurz
  • Peer-to-Peer-WebRTC-Inference hängt an Zuverlässigkeit und Bandbreite jedes teilnehmenden Geräts, eigene Issues des Projekts nennen abbrechende Worker-Tabs unter Speicherdruck und im Hintergrund
  • Durchsatzangaben (9-16 Tok/s je nach spekulativem Decoding, eine Demo mit 10,7 Tok/s über MacBook und iPhone) sind eigene Benchmarks des Projekts auf spezifischer Hardware, nicht unabhängig reproduziert

Lizenz

MIT (OSI-open)

Wann interessant

Experimente, mehrere eigene Geräte zu bündeln, um ein Modell laufen zu lassen, das für keines allein zu groß wäre, komplett im Browser.

Wann zu früh

alles, was eine stabile API, langen Kontext oder verlässlichen Produktions-Durchsatz braucht, das Projekt ist Pre-1.0, und die eigenen Issues der Maintainer beschreiben echte Zuverlässigkeitslücken.

Dieses Repo war in der Ausgabe 2026-09 des Open-Source-KI-Radars.