Independent Edge-AI Bench
The GMKtec K16 runs the compile and test pipeline on native Ubuntu with real RAPL, thermal, and CPU-frequency telemetry. The Raspberry Pi 5 with full Hailo-8 runs isolated edge-load checks. Published numbers are measured, bounded, and labeled — nothing is claimed before it is recorded.
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.
RTX 5070 Ti (Copperhead) — detection & CUDA capability gate. The eGPU is physically attached to the K16. Before any benchmark, the Blackwell sm_120 compute kernels are proven live with a real CUDA matmul — detection alone is not proof.
| Arch | Blackwell (sm_120) |
| Cores | 8,960 CUDA |
| VRAM | 16GB GDDR7 |
| Bus | 256-bit |
| Boost | 2,497 MHz |
| TDP | ~300 W |
| Arch | RDNA 4 |
| Cores | 4,096 / 64 CU |
| VRAM | 16GB GDDR6 |
| Bus | 256-bit |
| Boost | 3,060 MHz |
| TDP | 304 W |
RTX 5070 Ti: verified, benchmarked below. RX 9070 XT: manufacturer spec, incoming hardware — not yet tested. Side-by-side is a roadmap, not a measured result.
giraffstack@Architrov:~$ nvidia-smi --query-gpu=name,driver_version,memory.total,temperature.gpu --format=csv name, driver_version, memory.total [MiB], temperature.gpu NVIDIA GeForce RTX 5070 Ti, 595.71.05, 16303 MiB, 35 giraffstack@Architrov:~$ python3 -c "import torch; ... ; x@x on cuda" torch: 2.11.0+cu128 device: NVIDIA GeForce RTX 5070 Ti capability: (12, 0) CUDA matmul OK - sm_120 kernels live, result sum: 2000339456.0
Test 1 — device detection + sm_120 CUDA capability gate · recorded bench output
RTX 5070 Ti (Copperhead) — yolov8s fp16 @ 640, single-stream batch=1, raw PyTorch forward pass. This is the GPU running naive: one frame at a time, no batching, no engine optimization. The number it posts — and why it’s lower than you’d expect — sets up the two improvements that follow (TensorRT optimization, and batch scaling).
giraffstack@Architrov:~$ python3 bench_single.py # live throughput : 0.0 FPS mean latency : 0.00 ms GPU power : 0.0 W
giraffstack@Architrov:~$ python3 bench_single.py # yolov8s fp16 @ 640, batch=1 model : yolov8s.pt (fp16) resolution : 640 x 640 iterations : 300 (after 30 warmup) mean latency : 5.77 ms throughput : 172.7 FPS GPU power : 66.2 W mean / 73.8 W peak
Test 2a — single-stream raw PyTorch baseline · recorded bench output
RTX 5070 Ti (Copperhead) — the optimized GPU artifact. Same yolov8s, compiled to a TensorRT engine (the CUDA equivalent of a Hailo HEF), FP16, tuned to this exact card. The payoff: a 3.3x jump over raw PyTorch, same silicon. Five runs with cooldown; median reported, full spread shown.
giraffstack@Architrov:~$ python3 trt_bench.py # 5 runs + cooldown artifact : yolov8s.engine (TensorRT 11.1, FP16) median FPS : 0.0 FPS latency : 0.00 ms perf/watt : 0.0 FPS/W
giraffstack@Architrov:~$ yolo export model=yolov8s.pt format=engine half=True TensorRT: building FP16 engine as yolov8s.engine TensorRT: export success, saved as 'yolov8s.engine' (23.2 MB) Engine generation completed in 14.09 seconds. run 1: 565.5 FPS | run 2: 563.1 | run 3: 587.5 | run 4: 465.0 | run 5: 466.3 MEDIAN: 563.1 FPS | 49.3 W | 11.09 FPS/W | range 465-588
Test 3 - yolov8s TensorRT engine - end-to-end, 5 runs + cooldown - recorded bench output
RTX 5070 Ti (Copperhead) — the compute ceiling. A raw fp16 matmul (8192×8192) pushes the silicon flat-out: 97 TFLOPS at 300 W peak. This is the number that explains the batch sweep — inference only ever reached 235 W, so it was bandwidth-bound, never compute-bound. The ALUs had more to give; yolov8s just couldn’t feed them fast enough.
giraffstack@Architrov:~$ python3 matmul_tflops.py # 8192x8192 fp16, 3 runs run 1: 0.0 TFLOPS run 2: 0.0 TFLOPS run 3: 0.0 TFLOPS MEAN: 97.0 TFLOPS | 213.7 W mean / 300.0 W peak | 454 GFLOPS/W
Test 4 - raw fp16 matmul compute ceiling - 3 runs - recorded bench output
RTX 5070 Ti (Copperhead) — yolov8s fp16 @ 640, batch sweep 1→128, three runs per batch. The finding is the shape: throughput peaks at batch=16 then declines while power keeps climbing — the GPU saturates at 16, and bigger batches only add latency. Not VRAM-bound; compute-bound.
giraffstack@Architrov:~$ python3 sweep.py # yolov8s fp16 @ 640, 3 runs/batch batch img/s GPU W img/s/W 1 172.7 66.2 2.62 8 1150.2 181.9 6.61 16 1175.2 235.6 4.99 <- peak 32 1098.7 253.9 4.33 64 1016.4 258.8 3.93 128 982.0 264.7 3.71 PEAK THROUGHPUT: 1175.2 img/s at batch=16 (235.6W)
Test 2b — yolov8s CUDA batch sweep · mean of 3 runs each · recorded bench output
The A_SW anomaly engine, validated on real hardware (native Ubuntu, Live USB). 16 normal/tuned intensity pairs, each run five cycles. Green = selective (normal phase rejected all five, tuned promoted). Amber = review (normal did not reject all five) — marked honestly, not hidden. 13 of 16 selective is more credible than a clean 16; the boundary is where the method earns trust.
Three silicon targets, same yolov8s workload, all measured on real hardware. The result is not a single winner — it is two different races. The optimized GPU wins raw throughput; the edge accelerator wins efficiency by a wide margin at a fraction of the power. The right tool depends on what you are optimizing for.
| TARGET | PRECISION | FPS | POWER | FPS / W | BEST FOR |
|---|---|---|---|---|---|
| TensorRT (5070 Ti) | fp16 | 563 | 49 W | 11.5 | max throughput |
| Raw torch (5070 Ti) | fp16 | 173 | 66 W | 2.6 | baseline |
| CUDA peak (5070 Ti) | fp16 | 1175 | 236 W | 5.0 | batch=16 server |
| Hailo-8 (edge) | int8 | 220 | 3.25 W | 67.7 | efficiency / edge |
giraffstack@Architrov:~$ python3 summarize.py # cross-target rollup throughput winner : TensorRT @ 0 FPS efficiency winner : Hailo-8 @ 0.0 FPS/W efficiency edge : 0.0x vs optimized GPU, at 15x less power
Cross-target comparison - all values measured on real hardware. FPS bases differ slightly: Hailo = hailortcli streaming, TensorRT = end-to-end predict, raw torch = forward pass. Reported as measured, not normalized.
Idle-state GPU telemetry from the K16 / RTX 5070 Ti, captured with nvidia-smi dmon over 5 one-second samples on native Ubuntu. Recorded baseline — every figure below is measured output, not a projection. This is the resting floor the load benches climb from.
giraffstack@Architrov:~$ nvidia-smi dmon -c 5 # idle telemetry, 5 samples # gpu pwr gtemp sm mem mclk pclk 0 3 35 0 0 405 180 0 4 35 0 0 405 180 0 5 35 0 0 405 180 0 4 35 0 1 405 180 0 4 35 0 0 405 180
Idle-state baseline - RTX 5070 Ti on the K16, native Ubuntu, nvidia-smi dmon, 5 one-second samples. Reported as measured, not normalized.
Load-state telemetry from the K16 / RTX 5070 Ti during a live llama3.1:8b generation, captured with nvidia-smi dmon on native Ubuntu. The idle→load delta below is the proof of engagement: clocks ramp 34x, power climbs 6–10x, while temp holds nearly flat. Compute throughput is measured separately at 143.35 tok/s. Recorded output, not a projection.
giraffstack@Architrov:~$ nvidia-smi dmon -c 8 # during llama3.1:8b generation # gpu pwr gtemp sm mem mclk pclk 0 30 36 2 0 13801 2505 0 30 36 0 0 13801 2490 0 29 36 0 0 13801 2490 0 29 36 0 0 13801 2490 0 29 36 0 0 13801 2490 0 29 36 0 0 13801 2490 0 29 36 0 0 13801 2490 0 29 36 0 0 13801 2490
Load-state telemetry - RTX 5070 Ti on the K16 during llama3.1:8b generation. Clocks and power are the sustained-load measure; sm reads low because dmon 1s cadence undersamples sub-second token bursts - throughput (143 tok/s) is the compute proof. Reported as measured, not normalized.
Concurrent multi-model VRAM footprint on the K16 / RTX 5070 Ti, measured with ollama ps and nvidia-smi dmon on native Ubuntu. Two production models held resident at once, both 100% on GPU — no CPU spillover. Recorded output, not a projection.
giraffstack@Architrov:~$ ollama ps # two models held resident NAME SIZE PROCESSOR CONTEXT llama3.1:8b 5.3 GB 100% GPU 4096 llama3.2:latest 2.6 GB 100% GPU 4096 giraffstack@Architrov:~$ nvidia-smi dmon -c 1 # both loaded # gpu pwr gtemp mclk pclk 0 73 43 13801 2895
Concurrent multi-model VRAM footprint - RTX 5070 Ti on the K16, native Ubuntu. Model sizes and GPU placement from ollama ps; power/temp/clocks from nvidia-smi dmon. Two production models resident simultaneously at 7.9 GB of 15.9 GB. Reported as measured, not normalized.
Raw compute throughput on the K16 / RTX 5070 Ti, measured directly with PyTorch 2.12 (cu128) on native Ubuntu — not inference, but bare matrix-multiply (GEMM) FLOPS. An 8192×8192 FP16 matmul, 3 warmup then 50 timed iterations, CUDA-synchronized. This is the silicon's raw compute ceiling, distinct from the img/s inference numbers elsewhere. Recorded output, not a projection.
giraffstack@Architrov:~$ python3 gemm_bench.py # raw FP16 GEMM TFLOPS FP16 GEMM 8192x8192: 95.4 TFLOPS (11.52 ms/op) device: NVIDIA GeForce RTX 5070 Ti capability: (12, 0)
Raw compute throughput - RTX 5070 Ti on the K16, native Ubuntu, PyTorch 2.12 cu128. 8192x8192 FP16 GEMM, 3 warmup + 50 timed iterations, CUDA-synchronized. FLOPs = 2n³ per op. Reported as measured, not normalized.
Two measurements on the K16 / RTX 5070 Ti, native Ubuntu. Left: device memory bandwidth via PyTorch 2.12 (1 GB float32 copy). Right: a 60-second thermal soak under sustained llama3.1:8b load, sampled with nvidia-smi dmon every 5 seconds — the final sample caught the full compute burst at 250 W / 60°C. Recorded output, not a projection.
giraffstack@Architrov:~$ python3 bw_bench.py # torch memory bandwidth device-to-device copy: 771.2 GB/s (2.78 ms/op) device: NVIDIA GeForce RTX 5070 Ti giraffstack@Architrov:~$ nvidia-smi dmon -c 12 -d 5 # 60s thermal soak, llama3.1:8b # gpu pwr gtemp sm mem mclk pclk 0 17 43 0 0 810 495 0 42 44 0 0 13801 2880 0 31 44 0 0 13801 2490 0 30 44 0 0 13801 2490 0 35 44 0 0 13801 2505 0 31 45 0 0 13801 2490 0 250 60 91 80 13801 2865
Torch memory bandwidth + 60s thermal soak - RTX 5070 Ti on the K16, native Ubuntu. Bandwidth: 1 GB float32 device copy, PyTorch 2.12 cu128. Soak: nvidia-smi dmon, 12 samples over 60s under sustained llama3.1:8b load; peak sample 250 W / 60°C / sm 91%. Reported as measured, not normalized.
The fourth silicon target — queued, not yet tested. A 67-TOPS Tensor-core edge module that slots between the 3 W Hailo-8 and the 300 W desktop GPU. Where does it land on the throughput-vs-efficiency map? That is the next benchmark. Everything below is manufacturer spec; no workload has run on it yet.
| Accelerator | Hailo-10H NPU |
| AI performance | 40 TOPS (INT4) |
| On-board RAM | 8 GB LPDDR4X (dedicated) |
| Power | ~2.5 W active inference |
| Interface | PCIe Gen 3 · Pi 5 HAT+ |
| New capability | local LLMs / VLMs on-chip |
| GPU | 1,024-core Ampere · 32 Tensor cores |
| AI performance | 67 TOPS (INT8, Super) · 40 TOPS base |
| CPU | 6-core Arm Cortex-A78AE |
| Bandwidth | 102 GB/s |
| Power | 7-25 W configurable |
| Status | awaiting hardware |
Specs from NVIDIA. No measurement has been taken on this device. This card is a roadmap placeholder, clearly labeled as future work.
industrial edge-AI platform. The platform we're building toward — what we are working towards as the next frontier of edge-AI chips and deployments.
No benchmark or test is claimed. Clearly labeled future work.
The bench hardware. Slots fill as each correct photo is placed with its verified caption.













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.
Written only after a verified event. No SEO filler, no untested fixes presented as solutions.
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.
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.
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.
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.
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 the gate-calibration build (128-image calibration set, optimization level 1). The production-accuracy recompilation is now complete and verified (see below); Frigate-detector integration remains the next step, not yet claimed.
yolov8s recompiled on the K16 as a production-accuracy build: optimization level 2 with 4-epoch Quantization-Aware Fine-Tuning, calibrated on the COCO val2017 set (5000 images), single-context allocation. Compiled against Dataflow Compiler 3.30.0, version-matched to the Pi 5 HailoRT runtime (firmware 4.20.0), then loaded on the Pi’s Hailo-8 through the same isolated runtime check — separate from the production detector. Result: 220 FPS, int8, zero version mismatch, stable across three independent runs (219.94 / 220.02 / 220.29 FPS over 11,013 total frames). That is ~19% faster than the gate-calibration build while also being accuracy-tuned. HEF SHA256 97a1ece3…0b7e.
What the HEF? leads a workbench stacked with real hardware: a GMKtec K16 compile host with an RTX 5070 Ti “Copperhead” eGPU, a Raspberry Pi 5 running a Hailo-8 accelerator, and an HP Victus command machine.
Edge-AI hardware is genuinely hard to get working, and the people who know how tend to either keep it to themselves or charge enterprise rates to explain it. What the HEF? exists to close that gap. The method is simple: don’t claim a number until you’ve recorded it, don’t publish a result you can’t reproduce, don’t dress up an estimate as a measurement. Every figure here came off a real device, version-matched and verified.
The goal isn’t to be the biggest — it’s to produce results you can actually trust, and help the next person get their own setup running without the four-figure consulting invoice.
A HEF is a Hailo Executable Format file — the compiled, quantized model that actually runs on a Hailo accelerator. Getting a model to that file, version-matched and running at the speed the datasheet promised, is where most people get stuck.
So the name is half the format, half the feeling: “what the HEF?” — the thing you say at hour three of a compile that won’t cooperate. This bench is the answer to that question.
All content, benchmarks, code, scripts, and materials on this site are the property of GiraffStack, Inc. and are provided for informational purposes only.
Benchmark figures reflect results measured on specific hardware under specific conditions and are not guarantees of performance on any other system. Products and services are provided as-is, without warranty of any kind. GiraffStack, Inc. is not liable for any damages arising from the use of information or materials provided.
“Hailo,” “Raspberry Pi,” “NVIDIA,” and other hardware names are trademarks of their respective owners and are used here for identification only.
This site collects only the information you choose to provide — for example, when you contact us by email or submit setup details for a service.
Information you send is used solely to respond to your inquiry or deliver the service requested. We do not sell, rent, or share your information with third parties. We do not run advertising trackers.
For any privacy questions or to request deletion of information you’ve sent, contact reach@giraffstack.com.