Research

The question

What changes when a second, differently equipped Raspberry Pi joins? Node 02 had no Hailo accelerator. If the scheduler matched deployments rather than hardware names, it should still accept a CPU job for the same pinned model.

Conditions

• Two Raspberry Pi 5 nodes, one with Hailo and one CPU-only
• Pinned Qwen2.5 3B Q4_K_M, temperature 0, two CPU threads and one generation slot per Pi, a 512-token output limit, PWM fans fitted on both Pis
• Each answer was still generated on one Pi

Before the comparison

28 October 2026: Node 02 stopped answering on the local network while the 3B model file was being copied. A later boot recorded an ext4 orphan-cleanup message, consistent with an unclean unmount. The cause was not established. While Node 02 was offline, requests were still served by Node 01.

An opt-in test gave markup and styling to separate child jobs. They overlapped by about 27.9 s. The assembled page was missing the expected .contact-submit CSS selector, and a repair job did not produce a valid result. The repair added about 111 s, and the whole task took about 153 s, slower than one node producing the complete page.

Thermal readings

• Node 01: Fan about 3,003 RPM at the start and about 9,500 RPM during generation. One sample reached 81.8°C and latched the historical soft-temperature-limit flag. Active throttling bits were clear when checked.
• Node 02: Fan about 1,742 RPM at the start and about 5,300 RPM during generation. 70.8°C in a mid-job sample, with no throttling flag.

What Part 6 does not claim

• The 28 October outage was not explained.
• The 512-token responses were truncated at the limit.
• Splitting one contact-form task failed its validation contract and added time.
• The first simultaneous admission returned node_busy. The retry fix came afterwards and is not part of these results.
• Remote restart and shutdown existed in the API but were not exercised by upgraded agents.
• No distributed training was run. Both Pis served published pretrained weights.

Why answers are measured

Part 4 could deliver a request to the right model. It could not say whether the reply was any good. Parameter count, speed and the fact that a model runs on the hardware are not evidence of a correct answer, so Part 5 compares the answers themselves.

Method

A run sends the same cases to each selected deployment, stores the returned text with its settings, and records pass, fail or review. When the scoring rules were corrected, the stored answers were not overwritten. The promotion rule was written before the hold-out answers were read.

Conditions

• One Raspberry Pi, three deployments of pretrained models
• 24 frozen cases: 6 email, 6 extraction, 6 correction and 6 technical
• Temperature 0, a 256-token output budget, one repetition per case
• 72 requests, 71 completed. One Hailo case returned no_eligible_node, so the paired comparison uses the other 23 cases.

Promotion rule for the 3B candidate

• More whole-answer passes than both controls: met
• No more failures than the better control: not met
• No more length stops: met
• Median execution time no more than twice CPU 1.5B (7.246 s): not met

The 3B candidate was not promoted. The default stayed on Hailo, and the 3B deployment remained selectable as a candidate. A larger model improved some answers and was still the wrong default under the criteria chosen for this project.

Earlier comparison, 25 October 2026

12 synthetic tasks per deployment, one repetition, scored again after the rules were corrected without overwriting the stored answers.

Weaknesses found

• The Hailo deployment, still the default, had the fewest passes and the most failures.
• The 3B candidate was the slowest of the three by median time.
• A 256-token chat default cut off a long 3B reply. Interactive chat now defaults to 1,024 tokens; evaluations keep 256.
• A job marked completed was not always a complete answer.

Limitations

• Small synthetic task sets and one repetition per case.
• Automated verdicts, without independent human judging of every reply.
• One machine, so this compares runtimes, not nodes. Not a general ranking of models.
• Not measured: time to first token, decoding throughput, power consumption, accelerator memory.

What it does not show, and what comes next

These results say nothing about distributed learning or execution across machines. No training was run and there was no second provider. The next step named in Part 5 is a second Raspberry Pi without the Hailo accelerator, to test the compatibility and scheduling rules from Part 4. Part 6 records that node; see two physical nodes above.