SwarmLLM
nehanth
Splits a 27B model's layers across browser tabs on different devices over WebRTC, so no single machine holds the whole model.
What is SwarmLLM?
A JavaScript/WebGPU engine that distributes an LLM's layers across multiple devices, each peer holding a slice of layers, passing only a roughly 10 KB activation vector to the next device over WebRTC. It runs a custom WGSL kernel stack (around 50 kernels) with 4-bit quantization and speculative decoding entirely in the browser, with no server and no installation.
| Fact | Value |
|---|---|
| Maintainer | nehanth |
| GitHub stars | 435 (as of 2026-09-23) |
| Forks | 62 |
| License | MIT |
| License type | OSI-open |
| Category | Local inference and "what runs on my machine" |
| Status | Rising |
| Edition | 2026-09 |
| Last verified | 2026-09-23 |
SwarmLLM in depth
Running a large language model has always assumed one machine holds the whole thing, which locks out anyone whose single device, laptop, phone, or desktop, is not individually powerful enough. SwarmLLM, built by Nehanth Narendrula, questions that assumption by splitting a model's layers across multiple browser tabs on different devices, connected over WebRTC with no server and no installation required. The project's own framing captures the idea directly: every device brings a slice, together they run the whole model. A demo pairing a MacBook and an iPhone to run a 27B model is the clearest illustration of what the project is actually trying to prove.
The engineering is built from scratch rather than borrowed. SwarmLLM ships a custom WebGPU engine written in roughly 50 WGSL kernels, its own GGUF parser to load quantized weights, and a WebRTC mesh layer, room.js, that handles signaling and peer connections across networks. Each peer processes its slice of layers and only passes a small activation vector, around 10 KB, to the next device in the chain, rather than shipping raw weights or full hidden states. Four-bit quantization and speculative decoding with multi-token prediction reduce both memory and per-token latency, and the project gates every optimization on a golden-test suite intended to keep numerical results bit-exact.
The natural fit is technically curious users experimenting with pooling personal devices, a laptop plus a phone, or a household's collection of underused hardware, to run a model too large for any single one of them, entirely inside the browser with nothing to install. Because it needs no server, it also suits people who want to try distributed inference without standing up infrastructure. It is not yet aimed at production workloads; the room-based, ad hoc connection model (visit swarmllm.ai/room to start or join) reads as an experiment you run deliberately rather than an always-on service.
The caveats are substantial and mostly acknowledged by the project's own issue tracker. Only one release exists so far (v0.2.0), and the 2,048-token context window is explicitly flagged internally as needing to grow, with a hard 400-token answer cap still in place. Reliability depends on every participating device staying connected: open issues describe worker tabs dropping under memory pressure or when a browser tab is backgrounded, and data-channel congestion control adding real latency per hop. The throughput figures, 9 tokens per second without speculative decoding and 16 with it on a GB10, or 10.7 tokens per second in the MacBook-plus-iPhone demo, are the project's own benchmarks on its own hardware.
The verdict: SwarmLLM is a genuinely novel and well-engineered answer to a question most local-inference projects do not even ask, whether several personal devices can jointly run a model none of them could run alone. Adopt it as an experiment if you are comfortable in a pre-1.0, browser-based, ad hoc environment and want to see distributed inference working today. It is too early for anything resembling production use, given the single release, the openly documented context and reliability limits, and throughput numbers that remain unverified outside the project's own testing.
Pros & Cons
Pros
- Genuine from-scratch engine: custom WGSL kernels, a GGUF parser and a WebRTC mesh protocol, backed by a golden-test suite the project says gates every optimization
- No install and no server - runs in the browser, pooling idle devices (laptop + phone) to hold a model neither could run alone
- MIT, active daily commits with structured, labelled issues (P1/P2, milestones)
Cons
- Very early: one release (v0.2.0), and the 2048-token context window is explicitly flagged by the project's own issue tracker as too short
- Peer-to-peer WebRTC inference depends on the reliability and bandwidth of every participating device - the project's own issues note dropped worker tabs under memory pressure and backgrounding
- Throughput numbers (9-16 tok/s depending on speculative decoding, a demo of 10.7 tok/s across a MacBook and iPhone) are the project's own benchmarks on specific hardware, not independently reproduced
License
MIT (OSI-open)
When it is interesting
Experiments in pooling multiple personal devices to run a model too large for any one of them, entirely in the browser.
When it is too early
Anything needing a stable API, long context, or reliable production throughput - this is pre-1.0 and the maintainers' own issues describe real reliability gaps.
This repo featured in the 2026-09 edition of the Open-Source AI Radar.
oMLX
jundot
macOS-native LLM inference server for Apple Silicon with continuous batching and SSD-tiered caching.
TurboFieldfare
drumih
Streams a 26B-parameter MoE model's experts from SSD to run Gemma 4 on an 8 GB Apple Silicon Mac.
apfel
Arthur-Ficial
Expose the on-device Apple Intelligence model on macOS 26 as a zero-setup OpenAI-compatible local API.