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.
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.
| Merkmal | Wert |
|---|---|
| Maintainer | nehanth |
| GitHub-Stars | 435 (Stand 2026-09-23) |
| Forks | 62 |
| Lizenz | MIT |
| Lizenztyp | OSI-open |
| Kategorie | Lokale Inference und "was läuft auf meiner Maschine" |
| Status | Aufsteigend |
| Edition | 2026-09 |
| Zuletzt geprüft | 2026-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.
oMLX
jundot
macOS-nativer LLM-Inference-Server für Apple Silicon mit Continuous Batching und SSD-gestütztem KV-Cache.
TurboFieldfare
drumih
Streamt die Experten eines 26B-Parameter-MoE-Modells von der SSD, um Gemma 4 auf einem 8-GB-Apple-Silicon-Mac laufen zu lassen.
apfel
Arthur-Ficial
Das On-Device-Apple-Intelligence-Modell auf macOS 26 als Zero-Setup-OpenAI-kompatible lokale API verfügbar machen.