# CPU LLM study: data dictionary / dictionnaire des données

Snapshot: 7 October 2026. Local experiments ran from 4 to 7 October on a dual Xeon Gold 6230 CPU server. These are performance measurements, not a comprehensive model-quality benchmark.

## Files

- `benchmarks.csv`: 2,372 aggregate test rows, 1,233 distinct attempted configuration IDs: 1,219 successful, 12 failed, 2 unsupported. Fourteen model/quant variants. Includes BOTH kernel eras; do not compare them as a controlled A/B.
- `concurrency.csv`: three exploratory concurrency levels for two resident Qwen3-Next-80B replicas, one per socket. C=1/2/4 use 6/12/24 tasks and different output lengths. Not an isolated one-server-versus-two-server experiment. Invalid TTFT measurements are intentionally omitted.
- `chart-data.json`: the original aggregate CSV rows selected for every chart. Config IDs, exact commands, filters, standard deviations and requested options remain attached. Concurrency values come from the separate serving experiment.
- `manifest.json`: row/configuration counts and SHA256 checksums.

## Aggregate CSV fields

- `config_id`: configuration identifier. A single configuration can yield separate prefill and decode rows. Rows are not independent configurations.
- `timestamp`, `kernel_release`: provenance. Main charts use only `7.0.14-20-pve`; the 122B's older-kernel results remain downloadable but are excluded from that ranking.
- `model_id`, `model_name`, `model_quant`: exact campaign model and quant identifiers. No quant-quality equivalence is established.
- `runtime`, `build_commit`, `backends`: runtime provenance. `unknown` commits are unknown, not a pinned source version.
- `hf_repo`, `hf_revision`: model source where recorded.
- `phase`: experiment stage, not a claim of a full Cartesian configuration grid. Tested axes differ by model and runtime.
- `threads`, `threads_reported`: requested and runtime-reported worker counts. `physical` placement means a permitted core set, not 40 simultaneously active workers.
- `placement`: `auto` leaves scheduling and memory policy to the OS. `node0`/`node1` combine physical CPU binding and local memory binding. `cross` binds a split CPU set and interleaves memory. `physical` permits cores 0-39 and interleaves memory.
- `load_mode`: requested loading policy. Requested `mlock` is NOT proof locking succeeded inside an unprivileged LXC. Memory-mapped page-cache placement may confound locality experiments; the NUMA charts use private `none` loading.
- `batch_size`, `ubatch_size`: batch and microbatch token counts.
- `kv_k`, `kv_v`: KV-cache data types. Smaller KV data is not guaranteed faster at retained context.
- `fa_requested`, `fa_actual`, `repack_requested`, `repack_actual`: requested and reported attention/repack modes. Empty actual fields are not false or zero.
- `depth_tokens`, `prompt_tokens`, `gen_tokens`, `test_type`: retained-context depth and benchmark workload. Pure prefill, empty-context decode, retained-context decode and served API throughput are distinct metrics.
- `mean_tok_s`, `stddev_tok_s`: arithmetic mean and sample standard deviation of timed token rates. The charts show means, NOT the fastest individual repetition.
- `repetitions`: measured repetitions for that aggregate row. Summing this column yields 7,074 recorded repetitions, including the Qwen3.6 extension. This does not count unique semantic tasks or API correctness cases.
- `model_bytes`, `model_params`: reported model size and parameter count.
- `peak_rss_gib`: process peak resident memory in GiB, NOT GGUF file size or total machine/cgroup memory. Prefill/decode rows from one run may repeat the same peak.
- `wall_s`: configuration process wall time in seconds, NOT first-token latency.
- `protocol_version`, `status`, `error`, `command`: experiment protocol, outcome, failure and exact invocation. Local filesystem paths are retained for reproducibility; adapt them to your installation.

Blank fields mean unknown or not applicable, never fabricated zeros. Failed attempts remain in the export.

## Concurrency fields

`C` is the number of simultaneous clients; `batches` the batch count; `tasks_done` the task count; `wall_s_total` total elapsed wall time; `tasks_per_hour` completed tasks scaled to an hour; `aggregate_tok_s` total output tokens divided by elapsed wall time; `total_tokens` recorded output tokens; `latency_p95_s` observed request wall-latency percentile. Small samples and changing outputs limit extrapolation. Queueing/oversubscription is observed; memory-bandwidth saturation as the sole cause was not independently instrumented.

## Français

Le CSV contient des mesures réelles et conserve les échecs. Une ligne correspond à un test agrégé, pas à une configuration distincte. Les graphiques utilisent les moyennes et les écarts-types, uniquement sur le noyau 7.0.14. Les politiques NUMA modifient ensemble le placement CPU et mémoire : elles n'isolent pas le seul effet du pinning CPU. Le test à deux répliques est exploratoire, avec un faible nombre de tâches et des réponses de longueurs différentes. Il ne démontre pas un doublement strict du débit, ni une accélération de chaque réponse. Les champs vides restent inconnus. Le mode `mlock` indique une demande, pas une preuve de verrouillage mémoire.