In diesem Beitrag
SwarmLLM Test 2026: Kann ein Browser ein 27B-LLM auf Smartphone und Laptop verteilen?
SwarmLLM zeigt technisch glaubwürdig, dass Browser-Tabs gemeinsam ein großes Sprachmodell auf sehr unterschiedlichen Geräten ausführen können. Ein MacBook kann den Großteil der Layer halten, ein iPhone einen kleinen Slice. WebGPU rechnet lokal, WebRTC transportiert den Hidden State zwischen den Geräten. Für den Nutzerraum braucht es weder Python noch einen nativen Inferenz-Daemon.
Die Käuferfrage ist nicht, ob die Demo funktioniert. Entscheidend ist, ob diese Architektur auch mit Latenz, Browser-Support, Peer-Vertrauen, Ausfällen und Supportkosten gewinnt. Unser aktuelles Urteil ist bewusst eng: für Trusted-Device-Experimente und echte Memory-Capacity-Probleme pilotieren, aber noch nicht als produktive Inferenzplattform behandeln.
Das öffentliche SwarmLLM-Repository steht unter MIT-Lizenz und dokumentiert eine eigene WebGPU-Engine plus WebRTC-Room-Runtime. Die Leitdemo vom September 2026 zeigt Qwen 3.8 27B auf MacBook und iPhone. SwarmLLM ist unabhängige Open-Source-Arbeit von Nehanth Narendrula und kein Wavect-Produkt.
Was macht SwarmLLM technisch?
SwarmLLM nutzt Pipeline Model Parallelism zwischen Browsern. Statt das gesamte Modell auf jedes Gerät zu laden, erhält jedes Gerät einen zusammenhängenden Bereich von Transformer-Layern. Der Host behält Tokenizer, Embeddings, finale Normalisierung, LM Head und Sampler. Während der Generierung wandert eine Zwischenaktivierung in Modellreihenfolge durch die Peers und kehrt zur Token-Auswahl zum Host zurück.
Der praktische Nutzen ist Capacity Pooling. Qwen 3.8 27B umfasst im aktuellen Setup ungefähr 15 GB Q4_0-Gewichte. Ein Smartphone kann das nicht vollständig ausführen, aber einen kleinen Layer-Bereich beitragen, während ein stärkeres Notebook den Großteil trägt.
Wie läuft ein Token durch die Geräte?
Die veröffentlichte SwarmLLM-Architektur beschreibt für Qwen 3.8 einen Hidden State mit 5.120 Elementen. Als f16 gepackt sind das ungefähr 10 KB. Jeder Peer rechnet seinen Layer-Bereich und reicht den aktualisierten State weiter, bis der Host LM Head und Sampling ausführt.
Prompt -> Host Embed -> Laptop-Layer -> Smartphone-Layer -> Host LM Head -> nächster Token
Prefill lässt sich bündeln, autoregressives Decode braucht wiederholte Umläufe. SwarmLLM kombiniert deshalb gebatchten Prefill mit Qwens Multi-Token-Prediction, damit ein Netzwerklauf mehrere Kandidaten prüfen kann. Damit wird das Netzwerk selbst zu einem Teil der Inferenz-Engine.
SwarmLLM vs Mesh LLM, Browser-AI und klassisches Self-Hosting
Wavect hat bereits einen Mesh-LLM-Test für die breitere Multi-PC-Distributed-Inference-Entscheidung. Dieser Artikel besitzt absichtlich eine engere Suchintention: Browser-native P2P-LLM-Inferenz über heterogene Smartphones, Laptops und PCs mit minimaler Installationshürde.
| Ansatz | Modellplatzierung | Trade-off |
|---|---|---|
| SwarmLLM | Layer-Slices über Browser-Geräte | Sehr niedrige Join-Hürde, Browser und Netzwerk werden Runtime-Abhängigkeiten |
| Mesh LLM | Layer-Stages über Rechner | Mehr Setup, stärker für eine stabile private Multi-PC-Mesh |
| WebLLM / Transformers.js | Ganzes Modell in einem Browser | Einfachere Topologie, begrenzt durch den Speicher eines Geräts |
| Ollama / llama.cpp / vLLM | Native lokale oder Server-Runtime | Mehr Installation, klarere Betriebsverantwortung |
| Cloud API | Provider-Infrastruktur | Kein lokales Kapazitätsproblem, dafür Provider- und Datenpfad-Trade-offs |
Für Single-Device-Browser-Inferenz nutze den Transformers.js Browser-AI-Guide. Für die ökonomische Local-vs-API-Frage gibt es unsere Break-even-Analyse für lokale Modelle und APIs.
Was beweisen die Benchmarks?
Das Benchmark-Log ist aussagekräftiger als ein Launch-Clip, weil Hardware, Promptformen, Transportänderungen und negative Scaling-Ergebnisse dokumentiert sind. Auf einem NVIDIA GB10 meldet das Projekt ungefähr 9 tok/s Plain Decode und rund 16 tok/s mit Speculative Decoding. Ein MacBook Pro in Chrome wird solo mit ungefähr 6,7 tok/s plain und 10,8 tok/s spekulativ geführt.
MacBook plus iPhone braucht eine klare Evidenzgrenze. Die Demo-Beschriftung vom 7. September nennt 10,7 tok/s für 400 Tokens. Die strukturierte Performance-Tabelle nennt weiterhin 7,7 tok/s und das detaillierte Log dokumentiert 7,7 tok/s für den Real-Device-Test vom 4. September. 10,7 tok/s sollten daher aktuell als späteres Demo-Ergebnis gelesen werden, nicht als universelle Baseline.
Noch wichtiger: mehr Geräte bedeuten nicht automatisch mehr Geschwindigkeit. Ein Drei-Geräte-Emulator erreichte ungefähr 10,4 tok/s, eine Sechzehn-Geräte-Topologie fiel selbst lokal ohne Netzwerklatenz auf rund 3,8 bis 4,7 tok/s. Jeder zusätzliche Hop verursacht Pack-, Upload-, Readback- und Forwarding-Kosten.
SwarmLLM poolt zuerst Kapazität. Geschwindigkeit ist bedingt. Ein kommerzieller Pilot muss die eigene Hardware, Browser, Netzwerke und Prompts messen.
Sicherheit: P2P heißt nicht privat vor Peers
Das Security-Dokument zieht eine wichtige Grenze. WebRTC-Transport ist verschlüsselt und der Signaling-Broker trägt keinen Modelltraffic. Die Zwischenaktivierungen sind aber keine Verschlüsselung. Das Projekt warnt ausdrücklich, dass Activation-Inversion Prompt-Inhalte rekonstruieren kann. Jeder Room-Teilnehmer sollte deshalb als potenziell in der Lage betrachtet werden, Prompt-Informationen zu lesen.
Remote Compute wird ebenfalls noch nicht verifiziert. Ein defekter oder bösartiger Peer könnte manipulierte Aktivierungen liefern, ohne dass der Host heute die korrekte Berechnung beweist. Für Produktion lautet das Trust-Modell daher: Geräte und Personen, denen du die Konversation ohnehin anvertrauen würdest.
WebGPU ermöglicht No-Install und begrenzt es zugleich
SwarmLLM hängt von WebGPU-Support ab. MDN markiert WebGPU weiterhin als eingeschränkt verfügbar und nicht als Baseline. Normale Web-Nutzung braucht einen Secure Context. SwarmLLM nennt Chrome auf macOS als getesteten Host. Safari auf dem iPhone kann einen kleinen Slice beitragen, Safari auf dem Mac kann bei großen 27B-Slices unter Speicherdruck neu laden, Firefox und Linux Chromium sind weniger getestet.
Für Unternehmen gehören Browser-Policies, GPU-Treiber, Speicherdruck und Smartphone-Thermik deshalb in die Hardware-Matrix.
Was WebRTC löst und was nicht
WebRTC Data Channels übertragen Binärdaten direkt zwischen Peers und schützen RTCDataChannel-Traffic mit DTLS. Das passt gut zu Hidden-State-Frames, ohne eigene TCP-Ports zu öffnen.
WebRTC entfernt aber weder NAT noch Relay-Bedarf, Paketverlust oder Latenz. Eine produktionsnahe Architektur braucht Regeln für Signaling, TURN oder Relay, Telemetrie, Verbindungsfehler und Corporate Firewalls.
Wie produktionsreif ist SwarmLLM?
Die klarste Antwort liefert die Multi-Turn-Context-Roadmap. Sie dokumentiert, dass jeder Send den Modellzustand aktuell zurücksetzt, das 512-Token-Context-Limit noch nicht sicher durchgesetzt wird und Antworten bei 400 Tokens stoppen. Echte Gesprächshistorie, größere Context-Fenster, sichtbare Token-Zähler und sichereres Overflow-Verhalten sind geplant.
Peer-Recovery, Compute-Auditing und mehr Modelle stehen ebenfalls auf der Roadmap. Das macht SwarmLLM stark für Forschung und Pilotierung, aber noch zu früh als kundenkritische Kernabhängigkeit.
Wer sollte jetzt pilotieren?
| Situation | Entscheidung | Grund |
|---|---|---|
| Browser-native Local-AI-Forschung | Pilotieren | Einsehbare Architektur und geringe Einstiegshürde |
| Labor, Unterricht oder Hackathon mit Trusted Devices | Pilotieren | No-Install-Teilnahme ist ein echter Vorteil |
| Modell liegt knapp über Single-Device-Speicher | Vergleichen | Memory Pooling kann helfen, native Splits können einfacher sein |
| Vertraulicher Produktionsassistent | Warten oder isolieren | Peer-Trust und Recovery brauchen stärkere Kontrollen |
| Öffentlicher Swarm mit Fremden | Heute nicht | Aktivierungen sind nicht privat und Compute ist nicht verifiziert |
14-Tage-Pilot
- Zehn realistische Prompts und Zielantworten einfrieren.
- RAM, GPU, OS, Browser-Version und WebGPU für jedes Gerät dokumentieren.
- Single-Device-Baseline für Prefill, Decode, Speicher und Thermik messen.
- Peers einzeln hinzufügen und Capacity-vs-Hop-Effekt protokollieren.
- WLAN, alternative Netzwerkpfade und Cross-Network testen.
- Peer-Tab schließen, Smartphone schlafen legen und Netzwechsel provozieren.
- Keine sensiblen Prompts verwenden.
- Setup-, Fehler- und Supportzeit in TCO aufnehmen.
- Kill-Kriterium setzen: gewinnt eine native Runtime bei Geschwindigkeit, Security und Support, wird sie gewählt.
Wo Wavect ins Bild kommt
Browser-Inferenz ist eine Technologieentscheidung. Wavects AI Enablement deckt Workload-Evaluation, Modellauswahl, Local-vs-API-Architektur, Privacy-Grenzen, Gerätekompatibilität, Observability, Fallbacks und Produktionsübergabe ab. Die Twinsoft-AI-Case-Study zeigt das größere Muster: brauchbare AI entsteht durch das System um das Modell.
Wenn Cloud-Kosten der Treiber sind, vergleiche SwarmLLM mit unserem EU-Kosten-Guide für selbst gehostete LLMs. Spare Hardware ist nach Engineering, Support und Ausfallkosten nicht automatisch kostenlos.
Browser-Swarm-Inferenz auf echter Hardware testen
Du willst SwarmLLM gegen native Distributed Inference und einen klassischen lokalen oder Cloud-Stack vergleichen? Wavect kann Benchmark, Security-Grenzen und Produktionsentscheidung auf deinen echten Workload ausrichten.
Sinnvolle Service-Wege:
Fazit
SwarmLLM ist eines der interessantesten Browser-native Inferenzprojekte 2026, weil es eine ernsthafte WebGPU-Engine mit einem praktischen No-Install-WebRTC-Room verbindet. Die technische Evidenz ist stärker als das virale Demo allein vermuten lässt.
Die Grenzen sind ebenso klar: Multi-Turn ist unfertig, Context Handling unreif, Peer-Ausfälle sind problematisch, Remote Compute ist nicht verifiziert und Aktivierungen sind nicht vor Room-Mitgliedern vertraulich.
Für vertrauenswürdige Teams auf vorhandener Hardware ist ein kontrollierter Pilot sinnvoll. Für Produktion gilt: Löst Browser-native Teilnahme ein echtes Deployment-Problem, das eine stabile native Runtime oder API nicht löst? Wenn nein, gewinnt die einfachere Architektur.