KRXY

Platform

Model library

A catalogue identifier is not a benchmark, and a larger model is not assumed to be better. Each profile keeps its runtime, its published results and their limits. Unpublished candidates stay in the administration area until a journal entry or artifact confirms them.

Qwen2.5

Qwen2.5-Instruct 1.5B, CPU GGUF

qwen2.5-1.5b-instruct:q4_k_m

Runtime
llama.cpp on CPU. Node 01, and Node 02 when its CPU service is ready
Context
not recorded
Quantisation
Q4_K_M
Format
GGUF, Q4_K_M

Part 4 records this pinned CPU build being made available on the first node next to the Hailo deployment: a different artifact, running through different software. In Part 5 it was a control. On the frozen hold-out it had 12 whole-answer passes and 4 failures across 23 paired cases, with the shortest median node execution time of the three deployments, 3.623 s.

Part 5 role

Control

Passes

12 of 23

Failures

4 of 23

Median time

3.623 s

Evaluation statusPublished record

In Part 5 it ran on the same Raspberry Pi as the Hailo deployment, so that comparison is between runtimes on one machine, not between nodes. The remaining cases were left for review rather than given an automatic verdict. Synthetic tasks, one repetition and no independent human judging. In Part 6 a short routing check on this build returned two output tokens while Node 02 was offline; that showed routing, not speed. The journal does not state a context length for this build.

Source · Building KRXY, Parts 4, 5 and 6.

Qwen2.5

Qwen2.5-Instruct 1.5B, Hailo HEF

qwen2.5-instruct:1.5b

Runtime
hailo-ollama on Node 01, the only node with Hailo hardware
Context
2,048 tokens
Quantisation
Q4_0
Format
HEF, Q4_0

Part 2 records this catalogue id on the first node. The compiled context was 2,048 tokens and the pull log recorded 2,359,716,464 bytes. KRXY did not train the model. In Part 5 it remained the default deployment because a larger CPU candidate did not meet the promotion rule. That keeps the default unchanged. It does not make this the best-scoring model.

Part 5 role

Default

Passes

7 of 23

Failures

13 of 23

Median time

6.756 s

Evaluation statusPublished record

The manifest licence field was empty. On the Part 5 frozen hold-out (23 paired synthetic cases, temperature 0, a 256-token output budget, one repetition) it had 7 whole-answer passes and 13 failures, the weakest of the three deployments compared, with a median node execution time of 6.756 s. The verdicts are automated checks on those tasks only. Time to first token, throughput, power and accelerator memory were not measured.

Source · Building KRXY, Parts 2, 4, 5 and 6.

Qwen2.5

Qwen2.5-Instruct 3B, CPU candidate

Runtime
llama.cpp on CPU. Node 01, and Node 02 for the two-node tests
Context
not recorded
Quantisation
Q4_K_M
Format
GGUF, Q4_K_M

Added on 26 October 2026 as a candidate, not a replacement for the default. On the Part 5 frozen hold-out it had the most whole-answer passes, 14 of 23 paired cases, but also 6 failures, and a median node execution time of 8.496 s. It cleared the pass-count and length-stop conditions of the promotion rule and failed the failure-count and execution-time conditions, so it was not promoted. It remains selectable. In Part 6 the same pinned build ran on both Pis: about 83.8 s of compute on Node 01 and 82.6 s on Node 02 for a 512-token prompt, and two overlapping jobs reached about 12.2 output tokens per second of batch throughput.

Part 5 role

Candidate

Passes

14 of 23

Failures

6 of 23

Median time

8.496 s

Evaluation statusPublished record

The Part 5 runbook records that the process was started by hand and its prepared systemd unit was not enabled; Part 6 lists aligning live services with startup units as further work. Part 6 states the Q4_K_M quantisation. The journal does not state its context length. The Part 5 verdicts are automated checks on synthetic tasks only. The Part 6 512-token runs all stopped at the length limit, so they measure compute time for a fixed budget, not answer quality.

Source · Building KRXY, Parts 5 and 6.