Raspberry Pi 5: offline Model 0 hardware test results

[Santiagocetran]

Raspberry Pi test report

25 September 2026 · DevNet develop (1cec823)

What we learned

The Raspberry Pi 5 completed the reference Model 0 client, auditor, and aggregator jobs offline. It looks capable of running these small jobs, but we have not yet shown that it can participate in a live testnet round or handle larger models.

The Pi has 8 GB of RAM, a 64 GB microSD card, 64-bit Debian 13, and Wi-Fi. Docker built and ran the ARM64 DIN node and worker images. dincli version, system init, and the five-count worker example all worked.

Final repeat test

We ran ten cycles back to back. Each cycle trained a client model on 6,000 generated examples for ten epochs, audited it against 2,000 MNIST holdout examples, combined two groups of three model files, then combined those two results. This used the repository's Model 0 service code inside Docker workers without network access.

All 50 jobs completed successfully in 4 minutes 50 seconds. Fresh audit and aggregation outputs were checked after every cycle. The aggregation math matched the expected averages.

Job	Runs	Average time per job	Peak worker-process RAM
Client training	10	15.54 s	313 MiB
Auditor	10	3.53 s	233 MiB
Aggregator, first stage	20	3.20 s	214 MiB
Aggregator, second stage	10	3.21 s	214 MiB

The highest sampled temperature was 56.5°C. The Pi reported no throttling, used no swap, and had at least 7.1 GiB available RAM during sampling. Test folder sizes stayed stable; about 48 GB remained free on the root filesystem. Times include starting each worker container.

What still needs proving

• Memory isolation: Docker discarded the requested 4 GB worker limit because this Pi booted with the memory cgroup disabled. The RAM figures above measure the main worker process, not the entire container. The requested two-CPU limit was not separately verified.
• Real participation: No wallet, RPC, IPFS transfer, live round, or round deadline was tested. Model-owner preparation was not measured.
• Model quality and scale: Generated client data made the auditor reject the model, as expected. That says nothing about training quality. The auditor used copies of one model; aggregator inputs were small variations. Larger models may behave differently.

An initial auditor fixture failed because a Python-serialized dataset object was incompatible with the worker's Python version. A plain tensor-and-label fixture fixed it. We checked the audit output itself because the worker can say ok even when the auditor records a scoring error.

Next: Enable and verify Docker memory limits, then test the Pi against a real testnet round and its deadlines. If future models are larger than Model 0, benchmark those separately.

References: Testnet readiness issue #166 · Model 0 guide · DIN node runbook

@umeradl