Arch is deepseek4, not the dflash reported on the HF model card, which is
the DSpark sidecar's metadata

KV cache is q8_0 for both K and V. cache-type-v never allocates anything on
this arch (DSV4 is K-only) but llama-context.cpp compares the two values for
LLM_ARCH_DEEPSEEK4 and refuses to create the context when they differ, so the
q5_0 K / q4_1 V pair used by the Qwen dual-GPU entries is startup-fatal here.
q8_0 K also gets the Hadamard rotation. Total KV at ctx 262144 is 942 MiB

fit = on with no n-cpu-moe. Measured weights: 137.06 GiB routed experts,
2.02 GiB shared, 11.67 GiB non-expert, so non-expert plus shared is 13.69 GiB
and fits 24 GB alongside the KV with room for an expert layer or two. Pinning
-ncmoe 43 would strand VRAM, and any -ot/--cpu-moe aborts fit

cache-ram is 16384, not the 51200 used by the smaller entries, because ~137 GiB
of experts stay resident in host RAM and load-mode = dio shares no page cache

Sampling follows DeepSeek: temp 1.0, top-p 0.95, top-k disabled. reasoning_effort
is reachable only via chat-template-kwargs and emits no block when unset

No chat-template-file pin: the GGUF ships Unsloth's fixed template, which passes
the same DSV4 detection heuristic as the bundled file and additionally restores
reasoning_content on tool calls

DSpark drafter is left out. It requires fit off plus full offload of target and
drafter, and has an open decode-time CUDA abort (#26554)

Add AGENTS.md notes and CHANGELOG 1.40.0

fit's default margin is 1024 MiB, which is tuned for Linux and carries no WDDM
or framebuffer allowance. fit itself measures rather than guesses: it does a
no_alloc load plus a real graph reservation, so its KV figure is byte-exact at
942 MiB and its compute figure is a genuine gallocr measurement. What it cannot
see is the CUDA VMM scratch pool, the lazy cuBLAS workspace and CUDA graph
instances, none of which are reported to memory_breakdown()

At the default margin fit kept blk.0 and blk.1 routed experts on the GPU, since
all 43 layers carry 3.188 GiB of routed experts and none are dense. That left
only 1368 of 23139 usable MiB. The whole ~19 GiB weight set is a single
cudaMalloc because the CUDA buffer type declares no max_size, WDDM commits it
lazily, and the failure surfaced as an OOM inside cudaEventSynchronize during
the async upload rather than at the allocation itself

3072 leaves 3497 MiB and moves one more expert layer to the CPU, about 2.3% more
expert traffic. 6144 is worse, not better: it collapses -ngl to 38 and starts
stranding whole layers. --fit-target writes only params.fit_params_target and
never mparams, so it cannot abort fit the way -ngl, -ncmoe and -ot do

Also correct the AGENTS.md claim that load-mode = dio enables DirectIO. On
Windows llama_file::impl ignores use_direct_io and read_alignment stays 1, so
dio only disables mmap; the staging buffers are 4 x 1 MiB of pinned host memory
and it costs no VRAM, so it was never implicated in this OOM

The CUDA error was a host-memory failure wearing a device-memory costume.
Without no_host, make_cpu_buft_list prepends the CUDA_Host buffer type to the
CPU buffer list, so every CPU-resident tensor lands in page-locked memory. For
this model the loader reports a single CUDA_Host model buffer of 137046.96 MiB,
i.e. a 133.8 GiB cudaMallocHost on a 192 GB box

The reservation succeeds, so ggml_cuda_host_malloc's clean-failure fallback to
an ordinary CPU buffer never fires. The failure happens later, while the pages
are committed during the read, and surfaces as CUDA error: out of memory inside
cudaEventSynchronize in the async upload path. That is why it looked like a VRAM
problem and why neither fit-target nor load-mode moved it

Verified: with no-host the same config loads in ~144 s at 18650 MiB VRAM and
about 124 GiB of ordinary host RAM

fit-target = 3072 is kept, but demoted to what it actually is: a WDDM safety
margin. The previous commit message and AGENTS.md note claimed it fixed the OOM,
which was wrong. At the 1024 MiB default fit leaves only 1368 of 23139 usable
MiB for the CUDA VMM scratch pool, the lazy cuBLAS workspace and CUDA graph
instances, none of which it can measure; 3072 leaves 3497 MiB and costs one
extra expert layer on CPU

Applies to any entry that pushes tens of GiB of experts to CPU, not only this
one. GGML_CUDA_NO_PINNED=1 is the env-var equivalent