Key details

  1. SwarmLLM is MIT-licensed and runs one LLM across multiple browser tabs by splitting model layers among devices.
  2. The current 27B configuration uses Qwen 3.8 27B in a roughly 15GB Q4_0 GGUF.
  3. A hidden-state activation of about 10KB per token moves between peers over WebRTC.
  4. The project recorded a September 7, 2026 MacBook+iPhone demo and reports 400 generated tokens at 10.7 tokens/s.
  5. On an NVIDIA GB10, the project reports 9.0 tok/s plain decode, 16.1 tok/s speculative decode and 44 tok/s prefill.
  6. Its same-machine llama.cpp comparison reports 8.0 tok/s decode but 377 tok/s prefill, making prompt ingestion a major current performance gap.
  7. A MacBook+iPhone split benchmark reports 7.7 tok/s speculative decode; an internet-spanning host/peer room is reported at 3.5–6 tok/s.
  8. Chrome on macOS is the tested host browser; iPhone Safari can contribute a small layer slice, while Firefox and Linux Chromium remain untested by the project.
  9. The repository includes golden tests and benchmark scripts, but BTN found no independent performance validation during this research pass.

What builders should take away

  1. Treat browser-distributed inference as a memory-pooling technique first. It can make a larger model fit across existing hardware even if it does not outperform a strong native runtime end-to-end.
  2. Measure prompt prefill as well as decode. Fast token generation can hide a poor interactive experience when long prompts take much longer to ingest.
  3. For trusted home or team environments, WebRTC removes much of the installation and networking friction of native distributed runtimes; for untrusted peers, assume conversation and activation privacy are weak.
  4. Expect browser memory pressure and WebGPU implementation differences to be first-order deployment constraints, especially on mobile devices.
  5. If experimenting with the project, run its published golden tests and benchmark harness on your own hardware rather than treating the author's token/s figures as portable.
  6. The architectural idea may matter even if this implementation remains small: splitting weights by layer while sending compact activations between browsers is a different local-inference trade-off from routing full requests between machines.

What changed

SwarmLLM is an early open-source runtime that distributes one large language model across multiple browser tabs rather than requiring the full model on one machine. Each participating device downloads only a slice of model layers and executes those layers through a from-scratch WebGPU/WGSL inference engine. For Qwen 3.8 27B, the project passes a 5,120-element f16 hidden state — roughly 10KB per generated token — between peers over direct WebRTC connections. The project recorded a September 7 demo running the 27B model across a MacBook and iPhone on the same Wi-Fi and reports 400 generated tokens at 10.7 tokens/s. It also publishes reproducible benchmark scripts and golden tests, but the performance figures remain project-reported rather than independently validated.

Why it matters

Local-model deployment usually assumes one device can fit the entire model or that a native distributed runtime is installed across several machines. SwarmLLM explores a much lighter operational boundary: a browser URL becomes the distributed runtime, and ordinary devices contribute memory and GPU capacity by holding model layers. If the approach proves robust, it could make large local models usable in homes, classrooms, labs or small teams by pooling hardware already present rather than buying one larger accelerator. The trade-offs are equally important: every generated token still traverses the peer chain, browser support is uneven, prompt prefill is substantially slower than native llama.cpp in the project's own GB10 benchmark, and peers in a room are not a privacy boundary from one another.

One model is split by layer across devices

SwarmLLM assigns contiguous model-layer slices to participating devices. The host embeds the current token into a 5,120-element hidden state, sends roughly 10KB of f16 activation data to the first peer, and the activation moves through each layer-owning device before returning to the host for final normalization, sampling and the next token.

The browser is the distributed runtime

The engine is written around WebGPU with roughly 50 WGSL kernels, while peer communication uses WebRTC. Participants can join a room by opening a URL and downloading only the layers assigned to their device. No central inference server performs model computation, although ordinary web infrastructure is still used to deliver the application and establish connections.

The 27B demo pools devices that cannot hold the model individually

The current flagship configuration uses Qwen 3.8 27B in a roughly 15GB Q4_0 GGUF. The September 7 demo splits the model across a MacBook and an iPhone on the same Wi-Fi. The project reports 10.7 tokens/s for that recorded run and separately reports 7.7 tokens/s for a 62-layer-plus-2-layer MacBook/iPhone benchmark.

Decode looks promising; prefill remains a clear weakness

On an NVIDIA GB10, SwarmLLM reports 9.0 tokens/s plain decode and 16.1 tokens/s with speculative decoding, compared with 8.0 tokens/s for the project's native llama.cpp comparison on the same GGUF. But its reported prefill is only 44 tokens/s versus 377 tokens/s for llama.cpp on that machine. The project's own documentation calls prefill the known gap.

Network latency is amortized rather than eliminated

The runtime uses batched prompt prefill and multi-token prediction/speculative decoding so one network lap can carry more useful work. The project reports 3.5–6 tokens/s for a host-and-peer room across the internet, showing that wide-area operation is possible in its tests while also making network quality part of inference latency.

A room is private from a server, not necessarily from its peers

The project says no server sees the conversation or performs inference, but it explicitly warns that room participants share the conversation and that mid-model activations should not be considered private against a determined peer. This is therefore a peer-trust architecture, not a cryptographic privacy boundary between participants.

Browser support is still narrow

Chrome on macOS is the project's tested browser host. Safari on iPhone can join and hold a small slice, while Safari on Mac can reload under memory pressure for large slices. Firefox and Linux Chromium with WebGPU are currently listed as untested by the project. A Deno 2 headless path is also supported.

What to watch next

  • Independent reproductions of the 27B performance numbers on macOS, Windows and Linux browsers.
  • Whether prompt prefill approaches native runtimes as the WebGPU GEMM and recurrent-model paths mature.
  • Support for additional model architectures and quantization formats.
  • Whether browser vendors improve WebGPU memory behavior enough to make phones and tablets more useful as large layer holders.
  • Security work around peer authentication, room membership and leakage from intermediate activations.
  • Whether larger local-inference projects adopt browser-native layer splitting or comparable WebRTC transport ideas.

Still unclear

  • All quoted performance numbers are published by the SwarmLLM project and were not independently reproduced during this BTN pass.
  • The repository is very early and small, so APIs, compatibility and performance can change quickly.
  • The author's same-machine llama.cpp comparison is useful but does not constitute a broad benchmark across hardware, model formats or runtime tuning.
  • The statement that 'nothing leaves the room' means no inference server receives the data; it does not make other room participants unable to observe the conversation or infer information from activations.
  • Browser and mobile support is currently narrower than the project's cross-device architecture might suggest.

Sources

Direct reading behind this dossier.

1 sources

Discussion

Discussion is reader-contributed. Comments are not part of the BTN dossier or its editorial evidence.

0 visible comments

Join the discussion

Keep comments useful and relevant. Reader contributions may be moderated and are not BTN editorial evidence.

Sign in to comment