{
  "schema": "fak.cpu-serve-bench.v1",
  "machine_id": "cpu-server-a",
  "host_class": "256-thread x86_64, ~1 TB RAM, no GPU",
  "model": "GLM-5.2-UD-Q4_K_M (~433 GB on disk, 11 shards)",
  "rung": "B3 (real mid/large checkpoint, CPU host) — see docs/notes/GLM52-NATIVE-THROUGHPUT-AND-BENCHMARK-PLAN-2026-06-25.md",
  "ok": false,
  "headline": "NO usable throughput tok/s obtained on this CPU host. fak-native all-resident CPU serve WEDGED on host RAM at gateway-init (#974). The llama.cpp mmap baseline (CPU-only build, -ngl 0) RAN (memory-safe, no wedge) but its 433 GB warmup paged in from NFS at ~0.11-0.17 GB/s (same order as fak's load => the slow load is NFS-I/O-bound, not dequant — supports the #975 correction) and pure-CPU decode of the 753B MoE proved impractical (a single -n 32 rep did not finish in >30 min compute; decode <<0.05 tok/s, memory-bandwidth-bound). HONEST: the real data here is the load-curve + the cross-engine I/O-bound load witness + the negative 'pure-CPU 753B serving is not practical' finding; NOT a clean decode tok/s.",
  "engines": {
    "fak-native": {
      "engine": "fak-native CPU (reference path, FAK_Q4K=1 direct-resident-Q4_K loader)",
      "ok": false,
      "status": "wedged",
      "prefill_tok_per_sec": null,
      "decode_tok_per_sec": null,
      "error": "all-resident serve exhausted host RAM at gateway-init and wedged the box before bind",
      "detail": {
        "resident_peak_gb": 458,
        "on_disk_gb": 433,
        "note_resident_gt_disk": "fak's resident-Q4_K structures duplicate/expand some tensors, so resident (~458 GB) exceeds the on-disk GGUF (~433 GB)",
        "hugepages_reserved_gb": 512,
        "hugepages_reclaimable": false,
        "normal_alloc_cap_gb": 495,
        "available_at_wedge_gb": 2,
        "fork_failure": "at ~2 GB available the host (incl. out-of-band control plane) could no longer fork(); fak never reached a usable bind",
        "load_curve_measured": [
          {"wall": "0m38s", "resident_gb": 7.2, "inst_gb_per_s": 0.19},
          {"wall": "~8m", "resident_gb": 45, "inst_gb_per_s": 0.09},
          {"wall": "~21m", "resident_gb": 95, "inst_gb_per_s": 0.065},
          {"wall": "~36m", "resident_gb": 149, "inst_gb_per_s": 0.060},
          {"wall": "~48m", "resident_gb": 213, "inst_gb_per_s": 0.090},
          {"wall": "~69m", "resident_gb": 343, "inst_gb_per_s": 0.10},
          {"wall": "~80m", "resident_gb": 379, "inst_gb_per_s": 0.057},
          {"wall": "~91m", "resident_gb": 416, "inst_gb_per_s": 0.057},
          {"wall": "~101m", "resident_gb": 450, "inst_gb_per_s": null}
        ],
        "load_curve_finding": "resident-Q4_K CPU load measured at ~0.06-0.10 GB/s => a ~95 min full load on this host; the parallel-quant-load + resident-Q5/6_K levers did not bring the pure-CPU serve under 10 min here. The rate is the measured datum; the bottleneck CAUSE is NOT witnessed (see load_curve_cause).",
        "load_curve_cause": {
          "status": "unwitnessed-inferred",
          "note": "the ~0.06-0.10 GB/s rate's bottleneck (dequant CPU work vs demand-read/page-fault I/O across the 433 GB GGUF on NFS) was NOT measured on this wedged run: the load-path summary (resident=N dequant=N) requires the #975 LoadProfiler, which this pre-bind wedge never emitted.",
          "correction": "an earlier draft attributed the slow rate to 'dequant-bound' load and to 'mixed Q5_K/Q6_K experts taking the slow dequant path'. #975 established the CPU loader already routes Q4_K + Q5_K/Q6_K experts resident by info.Type (no slow Q8/dequant fallback path), so that attribution is NOT supported; an I/O-bound load (#974-B mmap / demand-paged weights reading 433 GB off NFS) is at least as likely.",
          "resolve_by": "re-run on a host without the ~512 GB hugepage co-tenant and capture the #975 load-path witness (resident=N dequant=N) to settle dequant-vs-I/O."
        },
        "blocked_by": "#974 (CPU-path memory-fit pre-flight + mmap/demand-paged CPU weights); re-runnable on a host WITHOUT the ~512 GB hugepage co-tenant",
        "provenance": "measured 2026-06-27 on cpu-server-a; fak built from origin/main ed4dc8dc; see docs/notes/GLM52-FAK-NATIVE-CPU-SERVE-MEMORY-WEDGE-2026-06-27.md"
      }
    },
    "llama": {
      "engine": "llama.cpp CPU-only build (mmap, -ngl 0), built on-host with -DGGML_CUDA=OFF (the prebuilt llama-server was a CUDA build; this CPU host has no libcudart.so.12, so it could not run — a fresh CPU-only build was required, ~2 min)",
      "ok": false,
      "status": "load-measured; pure-CPU decode impractical (no completed tok/s rep within budget)",
      "prefill_tok_per_sec": null,
      "decode_tok_per_sec": null,
      "mmap_pagein_gb_per_sec": "~0.11-0.17 (the 433 GB warmup page-in from NFS, measured by RSS growth) — the SAME order as fak's resident-Q4_K load (~0.06-0.10 GB/s), so the slow ~70-95 min load is NFS-read-bound for this access pattern, NOT a fak-dequant-specific cost. This is the cross-engine witness supporting the #975 load_curve_cause correction (I/O-bound, not dequant-bound).",
      "decode_finding": "pure-CPU (ngl 0) decode of the 753B GLM-5.2 MoE is impractically slow on this host: a single llama-bench config (-t 128 -p 128 -n 32 -r 1) did NOT complete its 32-token measured decode within >30 min of compute after the warmup paged the model in (decode well under ~0.05 tok/s), memory-bandwidth-bound across the 8 NUMA nodes, allocating ~200-256 GB of anonymous compute buffers (used 564->800 GB). This is an honest BOUND from a witnessed long-running bench, NOT a fabricated tok/s.",
      "context": "the published llama.cpp 753B baseline (2.62 tok/s single / 4.84 agg @ conc 2) used GPU attention + --n-cpu-moe expert offload on an 8-GPU host, NOT pure CPU; pure-CPU (no GPU) serving of this 753B model is far slower and is not a practical serving config.",
      "provenance": "measured 2026-06-27 on cpu-server-a; CPU-only llama.cpp built on-host; bench ran >2 h including the ~70 min NFS warmup page-in",
      "note": "llama.cpp via mmap is the memory-SAFE path (it never hits the fak-native RAM wedge), but on this NFS-only host it is not load-fast, and pure-CPU decode of a 753B MoE is not throughput-practical. An exact tok/s needs GPU+CPU offload or a far smaller config."
    }
  },
  "correctness": {
    "status": "not-measured",
    "note": "fak's differentiator column (bit-exact / cosine-1.0 / argmax vs reference) requires both engines actually serving the same model on this host; deferred until a throughput run completes"
  },
  "safety_reuse": {
    "status": "gap-identified",
    "note": "the GPU path guards an over-size model with a FitTooBig plan (fitAndPlanServeGGUF...OnDevice); the CPU reference path has no equivalent pre-flight (cmd/fak/serve.go loadServeInKernelModel loads unconditionally) — filed as #974. fak's safety/reuse pitch (capability gate + tamper-evident journal + cross-session KV reuse) is unaffected but unmeasured here."
  },
  "next_steps": [
    "Capture the llama.cpp mmap (-ngl 0) prefill/decode tok/s across a 64/128/256 thread sweep on cpu-server-a (the comparison baseline).",
    "#974-A: add a CPU-path memory-fit pre-flight (refuse cleanly, don't wedge).",
    "#974-B: mmap/demand-paged CPU weights, OR run the all-resident fak-native path on a host without the hugepage co-tenant, to obtain the fak-native CPU decode/prefill tok/s.",
    "Then fill both engines' tok/s + the correctness column here to satisfy #976's acceptance."
  ]
}
