KRXY · independent research
Exploring decentralised AI, distributed learning and collaborative computing across independent edge devices.
Research directions
Getting a model to answer, checking whether the answers are any good, and learning across machines are different problems. Each is labelled with how far the public record actually goes.
A request still goes to a node that can run the requested model. A third Pi joined in Part 10. An experimental pool can divide one small model's inference across two Pis. That pool is operator-controlled, not the ordinary chat path.
Part 5 compared three deployments on one Pi. Part 9 ran the same 24-case hold-out across two Pis for three CPU models. A larger or newer model was not automatically better, and the Hailo deployment stayed the default.
Two Pis have trained a tiny arithmetic model together, including after a worker rejoined and after an emulated slow or cut link. A trusted coordinator still mixes the updates. This is not training of the hosted Qwen models.
Implemented
Three Raspberry Pi 5 nodes, one with Hailo and two CPU-only. Ordinary chat still admits one job per Pi. An experimental pool can reserve two CPU nodes for one generation, and it is not a public default.
Measured
Two Pis trained a small arithmetic model and a restarted worker could rejoin before the target (Part 7). One Qwen3 1.7B generation was faster across two Pis: 1.61× decode in a command-line comparison and 1.37× through the streamed API (Part 10). Part 9 did not change the default model.
Bounded
The learning result is a tiny arithmetic task with a trusted coordinator, not a language model. Prompt-phase cancellation and an admission-deadlock fix were tested off the fleet and were not deployed on the Pis in Part 12.
Inside KRXY
A closer look at the hardware, software and experiments behind our decentralised AI research.
How KRXY works
Select a component or a step to see what the journal documents about it. This is a reading aid, not a live map.
Readable by anyone
Not exposed by this website
Independently operated hardware
Data flow, as documented
Selected component
implemented on three nodes · Parts 4 to 12
Receives jobs and chooses a node that is online and able to run the requested model. Part 6 placed overlapping jobs on two Pis and found an admission race. Part 7 added a bounded retry. Part 10 can reserve two CPU nodes together for one experimental pooled generation. Part 12 found a database deadlock on that path; the lock-order fix was tested off the fleet and was not deployed on the Pis in that entry.
The public website and the private control plane are separate. Nothing on this page is live, and node addresses or credentials are never published.
Recorded milestones
Each step links to the journal entry that records it. Work dates are shown where the entry gives them.
The research question, a heterogeneous Raspberry Pi design and a phased roadmap. None of it had been tried on real hardware yet.
A Raspberry Pi 5 with an AI HAT+ 2 booted, kept its identity across a reboot and returned one short prompted answer. No training step was run.
A node agent that identifies itself and reports health, rather than an anonymous machine on a network.
Being online was no longer enough: a node had to be able to run the requested model. The same entry says there was still one physical Pi.
Part 4 got a request to the right model; Part 5 asked whether the answer was any good. A frozen hold-out compared a 3B CPU candidate with two 1.5B deployments. It passed more cases but missed the promotion rule, so the default stayed on Hailo. Still one physical Pi.
A second Raspberry Pi 5 without Hailo joined. Paired Qwen2.5 3B jobs finished in about the wall time of one, roughly twice the batch throughput, but no single answer got faster. Splitting one answer across both Pis failed its validation. No training was run.
A roughly 0.86-million-parameter arithmetic model was trained from random weights. In E0008, two physical Pis reached the learning target after a killed worker rejoined, at 2.42×, 1.95× and 2.22× the one-Pi time across three seeds. A trusted coordinator still mixed the updates. The hosted Qwen models were not trained.
The same small model kept a full-budget throughput advantage when the training link was emulated: about 1.7× at 20 Mbit/s and about 1.4× at 5 Mbit/s, and it survived a two-minute cut. The good-link time-to-target gate failed on one seed. Qwen3.5 2B and 4B were installed as experimental CPU runtimes and were not scored yet.
The same 24-case hold-out ran 72 attempts across two Pis. Qwen3.5 4B passed 14, Qwen3.5 2B passed 11, and the CPU Qwen2.5 1.5B control passed 12. Neither new model became the default. Hailo Qwen2.5 1.5B stayed the default.
A third Raspberry Pi joined, with a private Ethernet link for Pi-to-Pi research traffic. Splitting one Qwen3 1.7B generation across two Pis reached 1.61× decode throughput in a command-line comparison and 1.37× through the streamed API. The first platform pool could answer, then failed to drain and to cancel, and was switched off.
Closing a CPU chat could stop generation. In the checked case the slot was released only after the node confirmed the stop, about 0.31 seconds later. Hailo could not interrupt an accepted job. A stale pool record moved from DRAINING to a verified STOPPED. The pool stayed disabled.
On two Pis, closing a pooled stream stopped native generation at a token boundary. Both boards stayed reserved until cleanup was confirmed, about 0.2–0.4 seconds after cancellation. A drain during a live job reached a verified STOPPED state. A long prompt before the first token still ran for 138 seconds, and one admission deadlocked. Fixes for both were tested off the fleet and were not deployed on the Pis in this entry.
Part 12 leaves prompt-phase cancellation and the database lock-order fix implemented and tested, but not yet validated on the Pis during ordinary pooled chat. The experimental pool is not a public model.
Research funding
What the research has cost so far and the voluntary support received, kept as separate figures.
Total Research Expenditure
£1,926.82
Running total. No budget has been set, so no percentage is shown.
Research Support Received
£445.00
Running total. No target has been set, so no percentage is shown.
Development journal
14 min readBuilding KRXY
On 9–10 November KRXY tests distributed-llama cancellation on two Raspberry Pis, verifies live draining and develops a fix for prompt-phase cancellation…
10 min readBuilding KRXY
KRXY fixes streaming cancellation, confirms CPU early stop in 0.31 s, and safely reconciles an inference pool from DRAINING to STOPPED on three Raspberry…
14 min readBuilding KRXY
KRXY adds a third Raspberry Pi, its own chat UI and private Ethernet, then measures 1.61x CLI and 1.37x streamed inference gains, with thermal and…
Plan, labelled as a plan
One physical node
A job leaves and a result comes back
More than one participant
Scheduling and recovery
Measurement
Learning experiments
No approved public Control Centre contract. This site does not call private platform APIs.
Contact the project