What the record says
BACKEND-GATE-CPU-LLAMACPP (backend matrix) records the CPU-vs-llama.cpp floor as closed on one host:
Current 20-core/i8mm position: at OR ahead of llama.cpp on every axis — peak RSS 1.01x (parity), prefill 1.18-1.26x ahead, decode at parity — that host-specific gate is closed.
and separately open on the four-core Cortex-A76/RPi5 arm (0.461x prefill / 0.653x decode).
Both recorded arms are AArch64.
The gap
Every lever that moved the gate from "11.6x decode / 33.5x prefill / 2.65x RSS behind" to parity-or-ahead is either Arm-specific or was only ever measured on Arm:
QUANT-GGUF-CIQ-GEMM G6 — Arm i8mm quant tierQUANT-GGUF-CIQ-GEMM G7 — q8_0 repack-at-load, crossed prefill parityQUANT-GGUF-KEEPQ-LOADER L7 — the RSS close, whose residual was "a q8_0 repack-source double-count on Arm"KERNEL-CPU-A76-Q8-DOT — AArch64 SDOT / AAPCS64 leaf
The only x86_64 datapoint in the record is the 2026-07-10 B4 decision measurement (54-75x decode / ~1,480x prefill / 2.7x RSS behind), plus a 2026-07-22 note that "the x86 1-thread arm reproduces B4 within 4.8-5.5%". Both predate the entire compute-in-quant track.
So: on the most common CPU ISA vllm.cpp ships for, nobody knows where the floor sits. The gate is recorded as closed for an ISA-specific configuration and there is no honest x86_64 number to put next to it.
Ask
Measure the x86_64 arm of BACKEND-GATE-CPU-LLAMACPP on the same B4 vehicle (Qwen3.5-2B-UD-Q8_K_XL.gguf, single-stream, same file for both engines), all three axes with values and ratios, correctness established first, and record it — including any axis below floor as an open gap with a named next hypothesis. No GPU involved.
Owning row: BACKEND-GATE-CPU-LLAMACPP / BACKEND-CPU (backend matrix), punch-list item 13 of ROAD-V1-D1 in roadmap-v1-completion.
What the record says
BACKEND-GATE-CPU-LLAMACPP(backend matrix) records the CPU-vs-llama.cpp floor as closed on one host:and separately open on the four-core Cortex-A76/RPi5 arm (0.461x prefill / 0.653x decode).
Both recorded arms are AArch64.
The gap
Every lever that moved the gate from "11.6x decode / 33.5x prefill / 2.65x RSS behind" to parity-or-ahead is either Arm-specific or was only ever measured on Arm:
QUANT-GGUF-CIQ-GEMMG6 — Arm i8mm quant tierQUANT-GGUF-CIQ-GEMMG7 — q8_0 repack-at-load, crossed prefill parityQUANT-GGUF-KEEPQ-LOADERL7 — the RSS close, whose residual was "a q8_0 repack-source double-count on Arm"KERNEL-CPU-A76-Q8-DOT— AArch64 SDOT / AAPCS64 leafThe only x86_64 datapoint in the record is the 2026-07-10 B4 decision measurement (54-75x decode / ~1,480x prefill / 2.7x RSS behind), plus a 2026-07-22 note that "the x86 1-thread arm reproduces B4 within 4.8-5.5%". Both predate the entire compute-in-quant track.
So: on the most common CPU ISA vllm.cpp ships for, nobody knows where the floor sits. The gate is recorded as closed for an ISA-specific configuration and there is no honest x86_64 number to put next to it.
Ask
Measure the x86_64 arm of
BACKEND-GATE-CPU-LLAMACPPon the same B4 vehicle (Qwen3.5-2B-UD-Q8_K_XL.gguf, single-stream, same file for both engines), all three axes with values and ratios, correctness established first, and record it — including any axis below floor as an open gap with a named next hypothesis. No GPU involved.Owning row:
BACKEND-GATE-CPU-LLAMACPP/BACKEND-CPU(backend matrix), punch-list item 13 ofROAD-V1-D1in roadmap-v1-completion.