Apple M4 Pro via Ollama, five 3-9B models: 0.09-0.25 J/output token system-level, 4.4-11.6 mJ/token package-level, spanning a 2.6x range by model size alone

Same GreenBench setup: Apple M4 Pro 12C/16GPU MacBook Pro Mac16,8, 48 GB unified, 273 GB/s, macOS 15.4, Ollama v0.21.2 (llama.cpp), powermetrics package power at 2 s intervals paired with per-call timing, 10 W system estimate for the system-level column. Models all Q4_K_M. The aggregate value 59.0 tok/s is Qwen 2.5 7B, the paper's recommended accuracy-efficiency compromise; per-model throughput is 175 (Llama 3.2 3B, cited as the latency-oriented pick), 115.2, 91.1 (Phi-3 3.8B), 59.0 and 45.8 (Mistral 7B) and 42.0 (Gemma 2 9B) tok/s. Energy basis: generation phase of each request; package and system reported separately rather than summed.

RECORDED FOR THE SPREAD, WHICH IS THE USEFUL PART: holding hardware, engine and precision constant, the model alone moves energy per token by 2.6x (0.09 to 0.25 J/tok system, 4.4 to 11.6 mJ/tok package). So a per-token energy figure without its model named is not a hardware property. ALSO NOTE THE PACKAGE/SYSTEM RATIO IS ABOUT 20-50x, which is the real headline for anyone budgeting edge inference: on Apple silicon the SoC package is a small fraction of system draw, so a package-level measurement systematically understates what a wall meter would show. The paper's own cross-platform table puts a published H100 7B baseline at ~4.0 J/tok but flags it as ESTIMATED as 400 W / 100 tok/s - an estimate, not a measurement, so it is deliberately NOT recorded here as an H100 joules figure. Small models (3-3.8B) gave 2.6-4.2x higher throughput and up to 62% less energy per token than the 7-9B models. LOAD-CONDITION AUDIT (bq- 2026-10-04). SCENARIO: NOT STATED by the source - absent, not inferred. A throughput figure with no scenario cannot be placed against an MLPerf Offline or Server number (they are different measurements; on identical hardware the Offline-minus-Server difference is negative in 5 of 9 systems measured). ABSENT CONDITIONS (3 of 7 checked: model, hardware, batch-or-concurrency, input length, output length, engine version, warmup): - batch/concurrency: unrecoverable from nrg2-arxiv-greenbench-apple-silicon - would need the achieved in-flight batch or the --max-concurrency value - input length: unrecoverable from nrg2-arxiv-greenbench-apple-silicon - would need the run's ISL or the prepared dataset's input-length profile - warmup: unrecoverable from nrg2-arxiv-greenbench-apple-silicon - would need the raw harness log's warmup phase or the benchmark command line (loadgen min_duration/min_query_count, or trtllm-bench --warm_up N / --num_runs N) None of these were filled in. A plausible value is worse than an absent one: it would be trusted. ENERGY-FIELD BACKFILL 2026-10-05 (schema authority pass, agent w5-schema). energy_basis / power_w / power_scope / power_cap / clock_lock_mhz / thermal_state were all DRAFTED and shipped UNUSED: before this commit zero records in the repo set power_w, power_scope or thermal_state, and the joules figures travelled as prose inside `unit` while metric enum member joules_per_token had zero records. They are populated here from facts this record already documented. WHY power_w IS NULL: no mean node draw was integrated from the powermetrics trace; the per-token joules were derived directly from package power and timing. WHY THIS RECORD IS NOT RE-LABELLED joules_per_token: it measures five models and the interesting quantity is the spread, not any one model's energy. Filing one model's J/tok into `value` would hide the other four. The record keeps its throughput metric and carries the energy in energy_basis, which is what the field is for. ROOFLINE SWEEP 2026-10-05 (agent w6-benchmarks, whole-corpus batch-1 decode pass): VALUE UNCHANGED, one of the five models in this record EXCEEDS the decode roof of the part its own methodology names. Measured against the M4 Pro at 273 GB/s - NOT against apple-m4-max at 546 GB/s, which is what accelerator_ids points at: Llama 3.2 3B at Q4_K_M is 1.939 GB of weights, so roof = 273e9/1.939e9 = 140.9 tok/s against the recorded 175.0 for that model = 124.2% of roof. The other four pass: Phi-3 3.8B 91.1 vs 118.4 (77.0%), Qwen2.5 7B 59.0 vs 59.3 (99.4%), Mistral 7B 45.8 vs 62.5 (73.3%), Gemma 2 9B 42.0 vs 48.9 (85.8%). The excess is largest on the SMALLEST model, which is the signature of a per-token byte estimate that is too low rather than a mis-transcribed throughput. Root cause, the limits of the finding, and the rule that a bpw assumption is not good enough on unified memory are in data/gotchas/bench-greenbench-apple-set-exceeds-its-own-part-roof.json. CONFIDENCE NOT CHANGED: the numbers are as the source states them and the source is cited; what is new is that one of them is now known to be arithmetically tight against its own hardware, which is a reason to distrust it, not a reason to edit it. FORMAT_ID BACKFILL 2026-10-08 (w10-bench-formatid): format_id was null and is now 'gguf-q4-k-m'. EVIDENCE, quoted from this record's own text: methodology: "Models all Q4_K_M" - stated for the five models this record measures. NO NUMBER CHANGED - value, metric and unit are untouched; this adds metadata, it does not re-measure. The value was NOT taken from a model name, from a sibling record, or from outside knowledge. Left null everywhere the record's own unit/methodology does not name a format for this run: 60 of the 150 records in data/benchmarks/ are still null and each one has its reason, because a null with a reason is correct and a guessed value is not.