En este artículo
SwarmLLM Review 2026: ¿Puede un navegador ejecutar un LLM 27B entre móvil y portátil?
SwarmLLM demuestra de forma técnicamente creíble que varias pestañas del navegador pueden cooperar para ejecutar un único modelo grande sobre dispositivos muy distintos. Un MacBook puede alojar la mayoría de las capas, un iPhone aportar un tramo pequeño, WebGPU ejecuta cada slice localmente y WebRTC mueve el hidden state entre dispositivos. El usuario no necesita instalar Python ni un daemon nativo de inferencia para entrar en la sala.
La pregunta para un comprador no es si la demo funciona. Funciona. La pregunta útil es si esta arquitectura sigue ganando cuando importan latencia, soporte de navegador, confianza entre peers, recovery y coste operativo. Nuestra conclusión actual es deliberadamente estrecha: pilotar para experimentos de Browser AI con dispositivos de confianza y para problemas reales de memoria agregada, pero todavía no tratarlo como infraestructura de inferencia de producción.
El repositorio público de SwarmLLM usa licencia MIT y documenta un motor WebGPU propio junto con un runtime de salas WebRTC. Su demo principal de septiembre de 2026 ejecuta Qwen 3.8 27B entre un MacBook y un iPhone. SwarmLLM es trabajo open source independiente de Nehanth Narendrula, no un producto de Wavect.
¿Qué hace exactamente SwarmLLM?
SwarmLLM usa pipeline model parallelism entre navegadores. En lugar de cargar el modelo completo en cada dispositivo, asigna rangos contiguos de capas transformer a los participantes. El host conserva tokenizer, embeddings, normalización final, LM head y sampler. Durante la generación, una activación intermedia recorre los dispositivos en el orden del modelo y vuelve al host para elegir el siguiente token.
La promesa principal es sumar capacidad. Qwen 3.8 27B ocupa aproximadamente 15 GB de pesos Q4_0 en el setup publicado. Un móvil no puede ejecutar el modelo completo, pero sí contribuir unas pocas capas mientras un portátil más potente aloja la mayor parte.
¿Cómo viaja un token por los dispositivos?
La arquitectura publicada de SwarmLLM describe para Qwen 3.8 un hidden state de 5.120 elementos. Empaquetado en f16 son unos 10 KB. Cada peer ejecuta sus capas, reenvía el estado actualizado y el último tramo vuelve al host para LM head y sampling.
prompt -> host embed -> capas del portátil -> capas del móvil -> LM head del host -> siguiente token
El prefill del prompt puede agrupar trabajo. El decode autoregresivo necesita vueltas repetidas. SwarmLLM combina prefill por lotes con multi-token prediction de Qwen para verificar varios candidatos por vuelta. En este diseño, la red forma parte del motor de inferencia.
SwarmLLM vs Mesh LLM, Browser AI y self-hosting clásico
Wavect ya tiene una review de Mesh LLM que cubre la intención más amplia de distribuir un LLM entre varios ordenadores. Este artículo posee una intención distinta y más estrecha: inferencia LLM P2P directamente en navegador entre móviles, portátiles y PCs heterogéneos con casi cero fricción de instalación.
| Enfoque | Distribución del modelo | Trade-off |
|---|---|---|
| SwarmLLM | Slices de capas entre navegadores | Entrada muy fácil, navegador y red pasan a ser dependencias del runtime |
| Mesh LLM | Etapas de capas entre ordenadores | Más setup, mejor encaje para una malla privada estable |
| WebLLM / Transformers.js | Modelo completo en un navegador | Topología simple, limitada por la memoria de un dispositivo |
| Ollama / llama.cpp / vLLM | Runtime nativo local o servidor | Más instalación, ownership operativo más claro |
| Cloud API | Infraestructura del proveedor | Sin problema de memoria local, con trade-offs de proveedor y datos |
Para inferencia en un solo navegador, consulta la guía de Transformers.js. Para decidir económicamente entre local y API, consulta local models vs APIs.
¿Qué demuestran los benchmarks?
El registro de benchmarks es más útil que el vídeo viral porque documenta hardware, prompts, cambios de transporte y resultados negativos de escalado. En una NVIDIA GB10, el proyecto publica unos 9 tok/s de decode normal y cerca de 16 tok/s con speculative decoding para Qwen 3.8 27B Q4_0. Un MacBook Pro solo en Chrome aparece cerca de 6,7 tok/s normal y 10,8 tok/s especulativo.
El dato MacBook más iPhone necesita contexto. La demo del 7 de septiembre dice 10,7 tok/s para una respuesta de 400 tokens. La tabla estructurada de rendimiento todavía muestra 7,7 tok/s para MacBook Pro más iPhone y el bench log registra 7,7 tok/s en la prueba real del 4 de septiembre. Por ahora, 10,7 tok/s debe leerse como evidencia de una demo posterior, no como baseline universal.
El log también demuestra algo más importante: añadir dispositivos no significa acelerar linealmente. Un emulador con tres dispositivos llegó a unos 10,4 tok/s, mientras una topología de dieciséis bajó a aproximadamente 3,8 a 4,7 tok/s incluso sin latencia de red, porque cada hop añade empaquetado, upload, readback y forwarding.
SwarmLLM agrega capacidad antes que velocidad. Un piloto comercial debe reproducir resultados con tu hardware, tus versiones de navegador, tu red y tus prompts.
Seguridad: P2P no significa privado frente a los peers
La documentación de seguridad es especialmente clara. El transporte WebRTC está cifrado y el broker de signaling no transporta tráfico del modelo. Sin embargo, las activaciones intermedias no son cifrado. El propio proyecto advierte que ataques de activation inversion pueden reconstruir información del prompt y recomienda asumir que cualquier participante de la sala podría leerlo.
Tampoco existe todavía verificación del cómputo remoto. Un peer defectuoso o malicioso podría devolver activaciones manipuladas sin que el host demuestre que esa etapa se calculó correctamente. Para producción, el modelo de confianza correcto es: dispositivos y personas a los que ya entregarías la conversación.
WebGPU permite el no-install y también lo limita
SwarmLLM depende del soporte de WebGPU. MDN todavía lo marca como disponibilidad limitada y no Baseline, y el uso web normal exige secure context. SwarmLLM describe Chrome en macOS como su host probado. Safari en iPhone puede aportar un slice pequeño, Safari en Mac puede recargar bajo presión de memoria con un slice grande de 27B, y Firefox o Linux Chromium tienen menos pruebas publicadas.
En una empresa, políticas de navegador, drivers GPU, presión de memoria y térmicas móviles forman parte de la matriz de compatibilidad.
Qué resuelve WebRTC y qué no
Los WebRTC data channels transportan datos binarios arbitrarios entre peers y protegen el tráfico RTCDataChannel con DTLS. Es un mecanismo natural para las activaciones sin abrir puertos TCP personalizados.
WebRTC no elimina NAT, relay, pérdida de paquetes ni latencia. Un diseño de producción sigue necesitando política de signaling, estrategia TURN o relay, observabilidad y comportamiento claro ante firewalls corporativos.
¿Qué madurez tiene SwarmLLM en septiembre de 2026?
La respuesta más útil está en la roadmap de contexto multi-turn. Documenta que cada Send resetea actualmente el estado del modelo, el límite de contexto de 512 tokens todavía no se aplica de forma segura y las respuestas se detienen en 400 tokens. Historial multi-turn real, contextos mayores, contadores visibles y manejo seguro del overflow siguen planificados.
Recovery de peers, auditoría de cómputo y soporte de más modelos también siguen en roadmap. Son límites importantes para una dependencia de producción y, a la vez, hacen del proyecto un candidato interesante para un piloto controlado.
¿Quién debería pilotarlo?
| Situación | Decisión | Motivo |
|---|---|---|
| Investigación de Local AI en navegador | Pilotar | Arquitectura inspeccionable y fácil de demostrar |
| Laboratorio, aula o hackathon con dispositivos de confianza | Pilotar | La participación sin instalación es una ventaja real |
| Modelo ligeramente mayor que la memoria de una máquina | Comparar | La memoria agregada puede ayudar, un split nativo puede ser más fácil de operar |
| Asistente de producción con datos confidenciales | Esperar o aislar | Peer trust y recovery necesitan más controles |
| Swarm público con desconocidos | No usar hoy | Las activaciones no son privadas y el cómputo no está verificado |
Piloto comercial de 14 días
- Congela diez prompts reales con longitudes representativas.
- Registra RAM, GPU, OS, navegador y soporte WebGPU de cada dispositivo.
- Mide baseline de un solo dispositivo: prefill, decode, memoria y térmicas.
- Añade peers uno a uno y separa capacidad ganada de hops añadidos.
- Compara misma Wi-Fi, otras redes y salas cross-network.
- Cierra pestañas, duerme un móvil y cambia de red durante una respuesta.
- Usa prompts no sensibles durante la evaluación.
- Incluye incompatibilidades y soporte humano en el TCO.
- Define kill criterion: si un runtime nativo es más rápido, seguro y operable, úsalo.
Dónde encaja Wavect
La inferencia en navegador es una decisión tecnológica. El trabajo de AI Enablement de Wavect cubre evaluación de workloads, selección de modelos, arquitectura local vs API, privacidad, compatibilidad de dispositivos, observabilidad, fallbacks y handover. El caso Twinsoft AI muestra el principio más amplio: el valor viene del sistema alrededor del modelo.
Si la motivación son los costes cloud, compara SwarmLLM con nuestra guía de costes de self-hosting LLM en Europa. Los dispositivos disponibles no son infraestructura gratis cuando sumas ingeniería, soporte y fallos.
Prueba inferencia browser-swarm en tu hardware real
¿Necesitas comparar SwarmLLM, inferencia distribuida nativa y un stack local o cloud convencional? Wavect puede diseñar el benchmark, los límites de seguridad y la decisión de producción alrededor de tu workload.
Rutas de servicio útiles:
Veredicto
SwarmLLM es uno de los proyectos de inferencia browser-native más interesantes de 2026 porque combina un motor WebGPU serio con una sala WebRTC sin instalación. La evidencia técnica publicada es bastante más fuerte que una demo viral por sí sola.
Los límites también están claros: multi-turn incompleto, contexto inmaduro, recovery pendiente, cómputo remoto sin verificar y activaciones no confidenciales frente a miembros de la sala.
Para equipos de confianza que exploran Local AI sobre hardware existente, merece un piloto controlado. Para producción, la pregunta decisiva es: ¿la participación desde navegador resuelve un problema de deployment que un runtime nativo estable o una API no resuelven? Si no, gana la arquitectura más simple.