Energy and speed per token on one mini PC: Vulkan against ROCm
Four local language models at four context lengths, three repeats each, on two software backends, measured at the wall plug and at the chip. I wrote the plan and my expectations down first and pushed them before the run.
Measured·Self-published, not peer reviewed·One machine·Run paired4, 12 to 13 October 2026
The machine is an AMD Ryzen AI MAX+ 395 mini PC with 128 GB of memory. It replaces the energy figures I published earlier, which were derived from reported power and speed, not measured per token. Idle, the whole box draws 18 W at the wall. Across the 48 Vulkan cells, energy per generated token (wall plug, net of idle) is 1.7 to 4.8 joules (96 cells were measured in all, on the two backends). 7 of my 8 written expectations held.
Speed. ROCm decoded more slowly than Vulkan in 16 of 16 cells, by 1 to 12%, and the repeat ranges of the two backends do not overlap in those cells. It was never faster.
Energy, 9B dense. ROCm used more energy per token than Vulkan: +8 to +20% across the four context lengths (wall plug, net of idle).
Energy, 12B dense. ROCm used about the same (the repeat ranges overlap in some cells) energy per token than Vulkan: -6 to +3% across the four context lengths (wall plug, net of idle).
Energy, 26B mixture. ROCm used about the same (the repeat ranges overlap in some cells) energy per token than Vulkan: -6 to -1% across the four context lengths (wall plug, net of idle).
Energy, 35B mixture. ROCm used less energy per token than Vulkan: -8 to -6% across the four context lengths (wall plug, net of idle).
Repeatability. Vulkan on the newer kernel, on another day, matched study 1 within 1.52% in every one of the 16 cells. Idle power was 17 W against 16.5 W.
Decode speed. Tokens per second as the prompt already in the cache grows from 64 to 32,768 tokens. The band is the lowest to highest of three repeats. All four panels share one scale.
Joules per generated token, net of idle. Filled dots are the wall plug, hollow dots the chip's own sensor, each from 64 tokens of context (small dot) to 32k (large). The chip sensor always reads lower than the plug, because it sees only the chip.
While decoding (Vulkan, 64 tokens of context). The whole box draws about 18 W idle. The chip package accounts for most of what is added. The rest is everything else in the box that the chip sensor does not see.
One measured cell, raw. The plug is read about once a second and the chip sensor ten times a second. Each dip is the gap between one 512-token request and the next. Energy per token is the area above the idle line inside the window, divided by the tokens generated in it.
ROCm decode speed as a share of Vulkan. A plain number means the repeat ranges of the two backends do not overlap. A dotted outline means they overlap, so I make no claim. ROCm here is the 7.1 runtime packaged in Ubuntu 26.04.
Each line below was written before the run and is reported whether it held or not. The first study's six expectations also held on both backends. Several of today's lines are not independent predictions, because I had seen the first study's results and one smoke test before writing them; the plan says so.
Wrong: P5. The server answered HTTP 500 on 12 requests with one model, after a reply containing bytes that are not valid text. The harness took those timings from the server's own log and the report counts them.
Anything about other hardware, other chips, discrete GPUs, other ROCm versions or packaging, or other builds of llama.cpp.
The accuracy of the wall watts. The plug is uncalibrated and reads whole watts; its own energy counter and the sum of its readings differ by 1.7%, but both come from the same plug.
Batched or concurrent serving. Everything is one stream at a time.
Quality of the output. The prompts are licence texts and the replies are not scored.
That anyone outside this project has repeated it.
Three earlier starts of this run were stopped after a few cells each because outside load reached the machine (requests from an unknown caller on the network, backup pushes from two other computers, a backup job on the machine itself). The last start had no failed cell and no contaminated cell. The whole account is in the repository's DEVIATIONS.md.
The plan, the harness, the raw wall-power and chip-power logs, every deviation from the plan and a standalone version of this report with a PDF are in github.com/RoamingPigs/strix-halo-energy. The files this page draws on are copies with a SHA-256 for each, taken from commit d82510a. Corrections to earlier energy figures are in the corrections log. Self-published by Cisco Caceres. No DOI exists.