1.6 KiB
name, description, metadata
| name | description | metadata | ||
|---|---|---|---|---|
| npu-setting-clamps-memory | MSI BIOS NPU/AI options clamp DDR5 to 5/6 of XMP on mainframe, and the NPU is unusable by the inference stack anyway |
|
On mainframe (MSI PRO Z890-P WIFI, Core Ultra 9 285K), enabling the BIOS NPU / "AI performance" options clamps memory to 5333 MT/s even with XMP Profile 1 correctly selected and reporting 6400. Turning them off restores 6400. Measured 2026-09-22, both directions.
Why: 5333 is exactly 6400 x 5/6, and is NOT a JEDEC bin (those are
multiples of 400: 4800/5200/5600/6000/6400). A failed memory training falls
back to a JEDEC bin -- this box fell back to 5200 pre-XMP. A non-JEDEC
fraction of the target means a ratio is being imposed, not a fallback taken.
Arrow Lake's NPU sits on the SoC tile with the memory controller, so an
SoC-side ratio change reaches DRAM. Cost: 102.4 -> 85.3 GB/s, a 16.7% loss of
the bandwidth local inference is bound by.
The setting is strictly negative here despite its marketing. llama.cpp in
this stack ships libggml-cuda.so plus CPU variants and has NO OpenVINO,
SYCL, Level Zero or NPU backend; intel_vpu loads with zero users. There is
no code path that can dispatch to the NPU, so it contributes nothing while
taking memory bandwidth.
How to apply: leave the NPU/AI BIOS options OFF. If DRAM ever reads a
non-JEDEC speed, suspect an imposed ratio (check SoC/NPU/fabric settings)
rather than memory instability. llmbench host-state records ram_mts and
xmp_enabled every run, so the history is queryable. See mainframe-bad-core.