Hellomatik bate el récord del mundo en Raspberry Pi 5

Cuatro Raspberry Pi 5, unos 500 euros de hardware sin GPU utilizable, decodifican un modelo de 30.000 millones de parámetros a 15,143 tokens por segundo. La cifra está verificada tirada a tirada, se reproduce desde ficheros públicos y su techo es el ancho de banda de memoria antes que el código.

Qué medimos y qué récord es exactamente

Un modelo Mixture-of-Experts de 30B decodifica a 15,143 tokens por segundo en cuatro Raspberry Pi 5. A mayo de 2026, y hasta donde sabemos, no se ha publicado una cifra más rápida para este modelo en esta clase de hardware.

La cifra es posible por cómo está construido el modelo, no por lo rápidas que sean las placas. El modelo es Qwen3-30B-A3B, abierto y de tipo Mixture-of-Experts: guarda muchas redes especialistas pequeñas y activa unas pocas por token, así que de sus 30.000 millones de parámetros unos 3.000 millones trabajan en cada uno. Esa propiedad lo decide todo en hardware pequeño, porque los bytes leídos por token fijan la velocidad.

La medición es deliberadamente estrecha. La decodificación es la fase que escribe la respuesta, token a token. Su caudal aquí es de 15,143 tokens por segundo, en 20 ejecuciones y con un intervalo de confianza del 95% de ±0,097. Se usó el comando exacto que publicó el anterior poseedor del resultado.

Cada ejecución se verifica bit a bit: el hash SHA-256 de los tokens generados coincide con una referencia fija, a temperatura 0. Nada va con overclock. No se sacrifica calidad.

Récord del mundo significa aquí lo que significa en cualquier disciplina sin árbitro: el mejor resultado que alguien ha publicado. Y una invitación abierta a superarlo. El anterior mejor era el resultado #255 del repositorio de b4rtaz, con 13,04 tokens por segundo.

Ningún organismo certifica esta clase de medición. Lo que hace las veces de certificado es el rastro. La salida es bit a bit exacta, la configuración es pública y cualquiera con cuatro placas puede comprobarla.

La cifra previa se midió en placas de 8 GB y las nuestras son de 16 GB. Por eso el paper reporta también la comparación sin factor de confusión. En nuestras propias placas el framework sin modificar da 13,15 y la configuración optimizada da 15,143: un 15,2% sobre silicio idéntico. Las placas de 8 y de 16 GB comparten el mismo ancho de banda de memoria, que es el recurso que decide la velocidad de decodificación.

Hellomatik como laboratorio de inteligencia artificial

Mientras desarrollamos producto, el laboratorio trabaja sobre las mismas máquinas que después implantamos a los clientes, para conocer los límites del hardware que entregamos.

Esto es un requisito, no una preferencia: lo que va a una máquina en casa del cliente hay que prometerlo antes de instalarlo. Hellomatik hace una cosa: un agente que ha leído lo que la empresa ya tiene y contesta con ello. Sus documentos van a un espacio de conocimiento. Sus conversaciones llegan por dos sitios, el widget de chat en la web de la empresa y un número verificado de WhatsApp Business, y las dos entran por la misma bandeja.

Cada respuesta lleva sus fuentes encima. Al abrirla, el panel enseña los fragmentos exactos de los documentos con los que se construyó, y las filas de la base de datos conectada cuando la respuesta salió de ahí. Así quien la lee comprueba la afirmación antes de repetírsela a un cliente.

También actúa sobre lo que la empresa ya usa. Las plataformas que puede operar son veintiocho, de HubSpot y Mailchimp a Meta Ads y el perfil de Google, y construye las automatizaciones que los usan. Por ejemplo, en un perfil de Google Business no solo lee: lista las reseñas, redacta la respuesta a una y la publica como propietario. También informa de cuántas búsquedas, llamadas y peticiones de ruta trajo la ficha. En resumen, el agente trabaja dentro de las herramientas que la empresa ya paga. Todo eso vive normalmente en nuestros servidores.

Este trabajo existe por el otro caso: la clínica o la empresa que no deja salir sus documentos del edificio. La medición de arriba es lo que nos dice, antes de prometer nada, que una máquina así sostiene una conversación a velocidad de lectura pero no se traga un contrato largo. La Raspberry Pi 5 es la placa que nuestros clientes tienen más papeletas de tener ya, así que es donde practicamos.

Hellomatik opera como un laboratorio de inteligencia artificial. Investiga sobre sus propias unidades de ese mismo hardware: los límites de las máquinas y los métodos de optimización con modelos de este tamaño. Lo que sobrevive a ese filtro se aplica después a soluciones para empresas medianas y grandes. La investigación en sí corre sobre material público, y este estudio es ese filtro funcionando a la vista.

Este lo dirigió Daniel Correa Villa, cofundador de Hellomatik. Se publica como publica el laboratorio. El paper está en Zenodo, con un paquete de reproducibilidad que trae la configuración exacta. Un fork público con licencia MIT guarda los doce cambios de código con su razonamiento. Y lleva también los CSV crudos de los A/B decisivos. Publicar los fracasos junto a los aciertos es parte del método, y el paper documenta veintiséis configuraciones que no funcionaron.

Para una empresa que se plantea una implantación en sus instalaciones, eso significa que los números que damos llegan con el método y con la máquina sobre la que se midieron.

El hardware y las cinco restricciones

Cuatro placas idénticas, Ethernet Gigabit, sin GPU utilizable y cinco reglas que todo cambio tenía que obedecer.

El hardware merece el detalle porque cada número de abajo es una propiedad suya, no del software. Cada nodo es una Raspberry Pi 5: cuatro núcleos Cortex-A76 a 2,4 GHz y 16 GB de memoria LPDDR4X con un techo de fabricante de unos 17 GB/s. Las cuatro placas se hablan por Ethernet Gigabit con 0,226 ms de latencia entre ellas. No hay acelerador utilizable: la GPU de la Pi no expone cómputo para esta carga, y NPU no hay. Todo lo que sigue ocurre en CPU.

Una placa recibe la petición y sirve la API. Las otras tres guardan su parte de los pesos, y las cuatro se ponen de acuerdo en cada capa antes de que salga el token siguiente.

El clúster se comporta como un instrumento de laboratorio, no como un montaje de aficionado. Bajo carga sostenida las cuatro placas se mantienen entre 54,3 y 56,0 grados, lejos del umbral de estrangulamiento de 85, con cero eventos de throttling registrados. El nodo raíz usa 12 de sus 16 GB y cada worker unos 6,3, con margen para la caché de conversación que crece. La variación entre ejecuciones a configuración fija es del 0,52%, que es lo que permite medir efectos de un uno por ciento.

Cinco restricciones enmarcaron el trabajo, adoptadas como reglas de diseño: (1) salida bit a bit exacta, comprobada con el hash de los tokens generados contra una referencia fija; (2) sin overclock de CPU; (3) sin cambiar de modelo; (4) el kernel de serie del sistema operativo; (5) sin bajar la calidad, con el número de expertos intacto. Las restricciones descartan la mayoría de los atajos de la literatura. También hacen desplegable cada mejora superviviente, porque nada depende de un truco frágil.

Qué aportó cada capa

Ningún cambio aislado produjo el récord. Lo produjeron cinco palancas medidas, y la mayor fue elegir la arquitectura de modelo correcta.

El récord es una suma porque ningún cambio suelto dio nunca para tanto. La trayectoria está publicada en el paper, etapa a etapa, y arranca baja. Un modelo denso de 8B corría en este clúster a 5,70 tokens por segundo. Cambiar al modelo Mixture-of-Experts subió la base a 11,40, porque se mueven muchos menos bytes por token.

A partir de ahí el trabajo fue parches de código (ocho al framework, cuatro a los kernels de cómputo), ajuste del sistema operativo y un ajuste de firmware. El caudal sostenido llegó a 14,449. La medición final de decodificación, con el nodo limpio y sin nada más corriendo, da 15,143.

La trayectoria dice cuándo llegó cada mejora. La figura siguiente dice cuánto vale cada palanca por sí sola, medida aislada.

La figura se lee de izquierda a derecha como una lección de dónde vive la velocidad. La arquitectura domina: un modelo que lee 3 GB por token en vez de 5 le gana a cualquier retoque de código. La palanca del runtime es configuración más que código: tres hilos en vez de cuatro, con la interrupción de red fijada al núcleo liberado, y otro asignador de memoria.

La palanca de firmware es un ajuste, el entrelazado de memoria en el arranque, que subió el ancho de banda de lectura medido por nodo de 8,3 a 12,5 GB/s. Los doce parches de código, la parte que más parece ingeniería, aportan un 5,6% limpio pero modesto.

El 59% de arriba y el salto de 5,70 a 11,40 miden la misma palanca contra bases distintas. El porcentaje es el A/B aislado, con todo lo demás ya ajustado; el salto desde 5,70 se midió sobre la configuración de partida, sin nada más tocado.

Dos hallazgos van contra la sabiduría heredada. Por ejemplo, quitar los avisos manuales de precarga del bucle más caliente lo hizo más rápido, porque el predictor del propio chip acierta ese patrón de acceso mejor que los avisos. Reescribir un kernel de dos pasos como un solo paso añadió un 1,5% por mantener los valores en registros. Los dos sobrevivieron solo porque cada etapa se midió contra su propia base, bit a bit.

El grano fino está documentado commit a commit. Un parche arregló un desbordamiento de entero que convertía en silencio un lote de 256 en 0. La fusión de kernels eliminó 224 barreras de sincronización por token, cada una un punto donde los núcleos se paran a esperarse antes de seguir.

Subir el trozo de red de 4 a 16 KB dividió por cuatro las llamadas al sistema por rebanada de sincronización. El último cambio de barrera sustituyó la espera activa por el mecanismo de eventos de ARM: un 0,48% más rápido, estadísticamente significativo, y los núcleos que esperan se calientan menos.

El paper también documenta lo que la literatura consultada tenía mal. Por ejemplo, una mejora publicada de +5 a 40% resultó estar ya presente en la base de código, y una ganancia no se puede capturar dos veces. Otra, de +20 a 30% por un reempaquetado de instrucciones ARM, se deshizo al tocar el hardware, porque los núcleos de la Pi 5 no implementan esa instrucción.

Una pasada estructurada por los papers de sistemas recientes produjo unos quince candidatos más. Su efecto neto medido en este clúster fue cero. Las técnicas asumen un kernel más nuevo, rasgos de silicio que esta placa no tiene, o un reinicio o una recompilación que las restricciones vetaban.

El muro de memoria es el techo

La decodificación en este clúster espera al ancho de banda de memoria, y el perfilador lo enseña directamente.

El techo es físico porque los núcleos se pasan el rato esperando datos en vez de calculando, y los contadores de rendimiento de ARM lo sitúan sin ambigüedad. Durante la decodificación, el 49% de los ciclos de CPU se detienen esperando al subsistema de memoria, y cada nodo sostiene 11,4 de sus aproximadamente 17 GB/s.

La aritmética cierra: con unos 3 GB de pesos activos por token, cuatro nodos podrían llegar a unos 22,6 tokens por segundo si la memoria fuera el único coste. En su caudal sostenido, el clúster realiza el 64% de eso.

El perfilador también reparte el tiempo de cada token en cuatro destinos, y ese reparto explica la estrategia entera:

El lado de cómputo ya está en su límite de instrucciones, con 322 instrucciones vectoriales de producto escalar en el bucle caliente a 1,74 instrucciones por ciclo. Por eso todos los experimentos de cómputo del paper devuelven cero: los núcleos esperan a la memoria más que a la aritmética.

La mayor parte del hueco restante es sincronización: las cuatro placas se ponen de acuerdo en cada capa. Ese acuerdo cuesta unos 12,3 ms por token, el 17,7% del tiempo del token en el perfilado de la etapa 12 del paper. La parte de barreras es el único margen abordable por software que queda, y es lo que ataca el trabajo de solapamiento.

Dicho de otra forma: el código ya no es el límite. A partir de aquí quedan dos palancas honestas. Una es hardware con más ancho de banda de memoria. La otra es solapar comunicación con cómputo: la única dirección de software que queda, y está preparada en el repositorio (una integración estimada en 250 líneas).

Veintiséis configuraciones que no sobrevivieron

El paper documenta las veintiséis, y los fallos dibujan el terreno. Unas se midieron y fallaron; otras quedaron descartadas por una restricción o por la literatura, y la tabla dice cuál es cuál.

Los fallos se publican porque cada puerta cerrada es un día: dicha por adelantado, es un día que otro no gasta en abrirla.

Configuración	Resultado	Por qué
Llama 3.3 70B en el mismo clúster	0,15 tok/s	38 GB de pesos, 9,5 por nodo: caben a duras penas y la caché fuerza swap
Framework EXO	no arranca	requiere la pila MLX de Apple; ARM a secas no basta
prima.cpp	se cuelga	el descubrimiento de topología nunca termina en Pi 5
llama.cpp en modo RPC	~25 veces más lento	domina el coste de red por token (reportado en la literatura)
La GPU de la Pi (Vulkan)	inutilizable	driver solo de render, sin cómputo
Overclock de CPU a 2,7 GHz	excluido	descartado por restricción; la ganancia esperada era ~12%

La tabla enseña seis de las veintiséis; el paper las documenta todas. En resumen: en ARM Linux sin acelerador, el camino practicable hoy es el paralelismo de tensores sobre Ethernet. Es decir, cada placa guarda una porción de cada capa y las cuatro se ponen de acuerdo antes de que el token avance. La mayoría de las demás puertas están cerradas. Publicar las puertas cerradas es parte del resultado, porque cada una es una tarde que otro ya no tiene que perder.

Qué trae el repositorio

Todo lo necesario para reproducir el récord es público: el fork, los parches, los ficheros de servicio y los datos crudos.

Todo es público porque un récord que nadie puede repetir es una anécdota. El trabajo vive en el fork de distributed-llama de hellomatik-org, en la rama pi5-cluster, bajo la licencia MIT original. Los doce cambios de código van con su justificación, uno a uno. Cuatro unidades systemd (API, worker, governor de CPU, fijado de interrupciones) más un servicio de ajustes de runtime hacen que un clúster frío arranque directamente en la configuración del récord.

El lado de servicio habla el protocolo HTTP compatible con OpenAI, con un pequeño proxy que sanea a los clientes estrictos. En la práctica eso significa que las herramientas existentes se conectan al clúster como se conectarían a una API alojada, cambiando una URL base. El paquete de reproducibilidad en Zenodo empaqueta la configuración completa para descargar.

El repositorio también conserva el rastro. Un repositorio acompañante, ya archivado, registra la configuración de 13,82 tokens por segundo que precedió al fork consolidado. Los CSV crudos de los A/B decisivos (telemetría y barrera) están versionados en el fork, parte de ellos junto a las fuentes LaTeX del paper.

Para qué podría servir hoy un clúster así

El margen medido dice qué usos encajan: prompts cortos de entrada, respuestas en streaming de salida, un cliente cada vez.

El margen es estrecho porque las dos fases de una conversación no cuestan lo mismo. Quince tokens por segundo es una velocidad de streaming cómoda para quien lee mientras llega. El primer token aparece en medio segundo largo. Con prompts cortos el clúster sostiene una conversación sin sensación de lentitud. Lo que hoy no puede es tragarse documentos largos: el prefill cuesta unos dos minutos por cada dos mil tokens de entrada.

Dentro de lo medido hoy	Fuera, por ahora
Pregunta-respuesta sobre contexto corto, en las instalaciones	Documentos largos en el prompt (~2 min por 2.000 tokens)
Asistentes de mostrador o kiosco con prompts cortos	Cargas de agente con prompts de sistema grandes
Generación por lotes donde la latencia no importa	Varios usuarios simultáneos (mediciones de un solo cliente)
Desarrollo contra una API estilo OpenAI, sin conexión	Lo que exija cifras de energía certificadas

La tabla es lectura nuestra de las mediciones del paper, no una promesa de producto; el paper solo afirma lo que midió.

Para Hellomatik el valor de ese margen es el mapa que nos da en las conversaciones con clientes. Cuando una empresa mediana o grande pide respuestas que no salgan del edificio, podemos decir qué sostiene una balda de placas de 500 euros. Y qué no sostiene, y qué compra el siguiente escalón de hardware. Eso es el laboratorio aplicado: límites medidos en lugar de promesas de fabricante.

Los cuatro límites de este resultado

El récord es real y estrecho, y cuatro límites dicen exactamente cómo de estrecho.

Los límites van aquí porque el titular solo engañaría: un +16,1% no dice qué fase se midió. El primer límite es el lado de entrada. La decodificación es el récord. El prefill, la fase que lee el prompt antes de que aparezca el primer token, es lento: unos 2 minutos para un prompt de 2.000 tokens, y unos 20 minutos proyectados para 20.000. Un uso construido sobre prompts largos queda fuera de lo que este clúster sirve hoy.

El segundo: la comparación del titular cruza variantes de hardware, placas de 8 GB contra las nuestras de 16 GB. El ancho de banda es idéntico y la cadena sin confusión sobre nuestro propio silicio da +15,2%, pero el titular del +16,1% hereda ese matiz.

El tercero agrupa tres pequeños. El caudal se midió con un solo cliente. La energía no se midió directamente: unos 2 J por token es una estimación, no una lectura. Y la calidad frente al modelo denso se comprobó por coherencia, sin un benchmark formal.

El cuarto es la propia lectura. El resultado se lee como un estudio de techo para esta clase de hardware, verificado a mayo de 2026, no como la afirmación de que cuatro Raspberry Pi sustituyen a un servidor. A un precio parecido, un Mac Mini M4 decodifica esta clase de modelo más rápido, unos 25 tokens por segundo. El objetivo del laboratorio no eran los tokens por euro.

Un límite ha aparecido después de las mediciones. Los 500 euros del paper son lo que costó el hardware cuando el laboratorio lo compró. Una escasez de memoria ha subido la Raspberry Pi 5 de 16 GB de 120 a 305 dólares en la lista de la propia Raspberry Pi, unos 280 euros.

Cuatro placas a ese precio son 1.120 euros, que es una cuenta nuestra y no una cifra del paper. Las mediciones no se mueven. El argumento del precio, sí.

Nada de esto debilita el hallazgo. El límite físico de esta clase de placa de borde queda cartografiado, bit a bit, y el mapa es público.

Qué se lleva uno de este clúster

Cuatro placas que cuestan unos 500 euros en total corren un modelo abierto de 30.000 millones de parámetros a quince tokens por segundo. La distancia que queda hasta el techo teórico es una propiedad del silicio, no del software. Eso es lo que el laboratorio salió a aprender.

La parte transferible es el método: fijar restricciones duras primero, medir cada etapa contra su propia base y mantener la salida bit a bit exacta, para que ninguna mejora esconda una pérdida de calidad. Y luego publicar los fracasos junto a los aciertos. La configuración completa, los doce parches y los datos crudos son públicos bajo licencia MIT, y el paper nombra su siguiente palanca: solapar comunicación con cómputo, ya preparada en el repositorio.

Lo que Hellomatik se lleva a casa es la práctica. Cuando una solución tiene que vivir en una máquina física en las instalaciones de un cliente, queremos saber, con mediciones y no con opiniones, qué puede sostener esa máquina y qué no.

Referencias

1. 1.Correa Villa, D. (Hellomatik), Pushing Four Raspberry Pis to the Memory Wall: Bit-Exact 30B Mixture-of-Experts Inference, +16% over the Public Record. Mayo de 2026. Todas las cifras de rendimiento de este post salen de este paper (n=20, intervalos de confianza del 95%, mediciones de mayo de 2026). ↩
2. 2.Paquete de reproducibilidad: configuración, los doce parches, unidades systemd y scripts de despliegue (licencia MIT). Julio de 2026. ↩
3. 3.Techo público previo: 13,04 tok/s de decodificación, resultado #255 (Tadych) en el repositorio b4rtaz/distributed-llama, sobre cuatro Raspberry Pi 5 de 8 GB. ↩
4. 4.El fork usado en este trabajo: hellomatik-org/distributed-llama, rama pi5-cluster, derivado de b4rtaz v0.16.5. ↩
5. 5.Precios de la Raspberry Pi 5: la de 16 GB salió a 120 dólares (ene-2025) y subió a 145 (dic-2025), 205 (feb-2026) y 305 a fecha de escritura, por la escasez de LPDDR4X. ↩

Preguntas frecuentes

¿En qué sentido es un récord del mundo?

En el sentido que tiene la expresión en cualquier disciplina sin árbitro: nadie ha publicado una cifra de decodificación más rápida para este modelo en esta clase de hardware, y el anterior mejor resultado de 13,04 tokens por segundo queda batido por un 16,1%. Ninguna organización certifica resultados así. Lo que hay en su lugar es un rastro auditable: salida bit a bit exacta, la configuración exacta publicada y un paquete de reproducibilidad que cualquiera puede ejecutar. Un matiz viaja con el titular: la cifra anterior se midió en placas de 8 GB y las nuestras son de 16 GB. Sobre silicio idéntico la mejora es del 15,2%.

¿Puedo reproducirlo?

Sí. El fork es público bajo MIT, la rama es pi5-cluster, y el paquete de reproducibilidad incluye los doce parches, las unidades systemd, la configuración exacta y los datos crudos. Un clúster idéntico (cuatro Raspberry Pi 5) debería reproducirla; el paper no ha validado la cifra en otro hardware.

¿Son estos los modelos que usa Hellomatik en su producto?

No. El estudio usa modelos abiertos de investigación porque tienen resultados publicados contra los que comparar. Los modelos de nuestros agentes son un asunto aparte, y no los revelamos en esta línea de investigación.

¿Por qué Raspberry Pi y no un Mac Mini o una GPU?

A un precio parecido un Mac Mini M4 decodifica más rápido, en torno a 25 tokens por segundo. El objetivo no era el mejor tokens por euro: era el techo de esta clase de placa de borde, y un método de optimización que se transfiere a otras máquinas.

¿Qué lo haría más rápido?

Hardware con más ancho de banda de memoria, o solapar comunicación con cómputo (Async Tensor Parallelism), estimado en unas 250 líneas de integración sobre andamiaje ya presente en el repositorio. Las opciones que sacrifican calidad, como activar menos expertos o bajar la cuantización, que guarda cada peso en menos bits, quedaron fuera de alcance a propósito.

Quién lo ha hecho

Investigación e ingeniería

Daniel Correa Villa