Independent Hailo-8 Bench — Notes from Real Hardware

K16 bench readout

Stored hardware evidence from native-Ubuntu runs on the K16. Verified data only — every figure below is recorded bench output, not a projection. Hailo HEF compile + on-device load is now verified — see the gate result below.

Native telemetry

3 / 3

RAPL · thermal · cpufreq
exposed on native Ubuntu

Selectivity

PASS

normal/heavier rejected 5/5
tuned/lighter promoted

Sweep boundary

13 / 16

selective normal/tuned
intensity pairs

Load soak

SAFETY

6/6 burn workers · tuned
blocked by safety gate

Recorded run logic

WSL2 capacity chain

5/5 phase passnon-native telemetry · CV max 0.0022

Native Ubuntu telemetry

RAPL · thermal · cpufreqreal x86 bench surface

Selectivity — normal/heavier

rejected 5/5efficiency gate

Selectivity — tuned/lighter

promotedafter repeatability cleared

Cold-reboot reproducibility

reproducedreview-fixed parser, raw preserved

Parameter sweep

13/16 selectiveboundary map, not universal pass

Load soak under pressure

safety dominancenegative control, not a promotion

Claim firewall

Public now

K16 evidence + equipment

Verified

HEF compile + Pi load — 185 FPS / 927 frames / int8

Blocked

secrets, thresholds, internal access

Blocked

unmeasured Hailo FPS / latency

Blocked

inactive / non-bench hardware

Parameter sweep boundary

16 normal/tuned intensity pairs tested on native Ubuntu. Green = recorded selective behavior (normal rejected all five cycles, tuned promoted). Amber = review case where the normal phase did not reject all five — marked honestly, not hidden. The tuned phase promoted in every case.

1.25 / .50sel

1.25 / .40sel

1.25 / .35review

1.25 / .30sel

1.50 / .50sel

1.50 / .40sel

1.50 / .35sel

1.50 / .30sel

1.75 / .50sel

1.75 / .40sel

1.75 / .35review

1.75 / .30sel

2.00 / .50review

2.00 / .40sel

2.00 / .35sel

2.00 / .30sel

■ 13 selective ■ 3 review normal intensity / tuned intensity

The rig

The bench hardware. Slots fill as each correct photo is placed with its verified caption.

Network rack

—

Victus HQ

—

Victus HQ

—

GeForce 5070 Ti CUDA Torque close up

—

GMKtec K16 — close up

—

GMKtec K16 — close up

—

Hailo-8 close up with Bestoss 1TB NVMe SSD

HAILO-8 Close up / BESTOSS 1TB NVMe SSD

—

The full CUDA Copperhead Snake rig

—

The K16 Testing Monitor

—

Pironman 5 Pro Max Face up close

—

Pironman 5 Pro Max Screen Close Up

Ubuntu Terminal loaded on screen

The whole entire set-up

—

SunFounder Rev:1.3 Hailo camera

—

Bench hostGMKtec K16 · native Ubuntu
TelemetryRAPL · thermal · cpufreq
Edge targetPi 5 + Hailo-8 · 26 TOPS
Compile archx86_64
WorkstationHP Victus · WSL2
AccelerationeGPU rig

Test pipeline · K16 → Pi gate

The discipline is the product: unsupported paths fail early at a validation gate, verified results are publishable, the production Pi runtime is never modified, and the compile environment matches the Pi — never the reverse.

Read the Pi 5 first

Record HailoRT version, Hailo board identity, the Frigate container runtime, and the correct hailo8 hardware arch flag. The compile target is pinned to these.

Preflight the K16

Confirm x86_64, AVX/AVX2, Python compatibility for the selected DFC, free disk and RAM — before installing anything.

Install the matching DFC in isolation

Pin the Dataflow Compiler to the version that matches the Pi runtime, via the official compatibility table. Do not make the Pi match the compiler.

Select a supported clean model

Choose from the compiler's own supported list. YOLOX-family targets are the clean starting point if supported by that exact DFC version.

Compile once, record, stop on failure

Record exact output. Stop on any uncleared failure — no patch-looping.

Load on the Pi through an isolated test config

Copy the HEF to a non-default path; run a separate Frigate test config. The live config and model cache are never touched.

Publish only verified outcomes

Compile result, load result, FPS/latency if measured, exact environment, and failure text if it fails.

Field notes

Written only after a verified event. No SEO filler, no untested fixes presented as solutions.

Verified

K16 native Ubuntu exposes RAPL; WSL2 does not

On native Ubuntu the K16 exposed RAPL power, thermal, and CPU-frequency telemetry, making it a real x86 hardware bench. The earlier WSL2 runs validated capacity and repeatability only — they are labeled non-native telemetry, not hardware-power evidence.

Verified

Selectivity: normal rejected 5/5, tuned promoted after repeatability

The native run rejected the normal/heavier condition across all five cycles at the efficiency gate and promoted the tuned/lighter condition only after repeatability cleared. A selective result, not always-on promotion.

Verified

Parameter sweep: 13 of 16 pairs selective

Sixteen normal/tuned intensity pairs were tested; thirteen produced selective behavior, with the tuned phase promoting in every case. Shown as a boundary map, not a universal pass.

Control

Load soak blocked tuned promotion under safety gate

Under sustained load with six burn workers completed, the tuned condition was blocked by the safety gate. This is a safety-dominance negative control — deliberately not presented as a performance promotion.

Verified

Hailo HEF compile + Pi load — 185 FPS

yolov8s compiled to HEF on the K16 (Dataflow Compiler 3.30.0, Hailo-8), version-matched to the Pi 5 HailoRT runtime (firmware 4.20.0), then loaded on the Pi’s Hailo-8 through an isolated runtime check — separate from the production detector. Result: 185.15 FPS across 927 frames, int8, with zero version mismatch. This is a gate-calibration build (128-image calibration set, optimization level 1); production-accuracy recompilation and Frigate-detector integration are the next verified steps, not yet claimed.