llama.cpp 'invalid argument: --no-mmap': Use --load-mode Correctly
If llama.cpp rejects --no-mmap, verify the binary and wrapper first. Current upstream deprecated the old flag in favor of --load-mode none, while wrappers and older builds may parse it differently.
Approximately 3 min read
The parser error invalid argument: --no-mmap happens before model loading. First check which executable receives the option:
command -v llama-server
llama-server --version
llama-server --help | grep -E "load-mode|no-mmap|mmap|mlock"
For a GUI or service, inspect its launch command and bundled binary as well. A shell installation and an application bundle can expose different options.
Choose the option your binary accepts
Upstream discussion #26469 identifies --load-mode none as the replacement for disabling mmap in the newer interface:
llama-server -m model.gguf --load-mode none
The associated environment setting is LLAMA_ARG_LOAD_MODE=none. Use it only where the invoked binary supports that interface.
| Help output | Next step |
|---|---|
Lists --load-mode |
Use --load-mode none for the no-mmap intent |
Lists only --no-mmap |
Use the older interface documented by that binary |
| Lists neither | Check the package, fork, wrapper, and executable path |
| Direct launch accepts the option; application rejects it | Inspect the application’s own parser and generated command |
Avoid supplying both old and new forms. A wrapper may reject an argument before llama.cpp sees it, even when the underlying executable would accept it.
If neither form works, save the version and help output:
llama-server --version
llama-server --help > llama-help.txt
Then check whether the executable came from a release package, container, self-built checkout, fork, or GUI bundle. That identifies which documentation applies.
mmap and locked memory solve different problems
With mmap, the operating system maps the GGUF file into the process address space and supplies file-backed pages as they are accessed. Disabling it changes the loading and residency path. It can affect startup time, RAM pressure, page faults, and CPU-resident model workloads.
Locking memory addresses a different question: whether resident pages may be paged out. Consequently, --load-mode mlock is not a substitute for --load-mode none. Upstream issue #26110 discusses why that distinction matters for large CPU-offloaded MoE models.
Changing the loading policy also leaves the model architecture and required tensor names unchanged. A missing tensor, unsupported architecture, or KV-cache allocation failure needs its own diagnosis.
Check that the loading change helped
Once the command parses, compare two launches of the same binary and GGUF: the default loading policy and --load-mode none. Keep context, GPU placement, batch settings, and prompts fixed.
Record whether loading succeeds, load time, RAM use, swap or pageout activity, and generation speed. Include both a cold start and a subsequent start when storage caching could affect the result.
If only the application launch fails, include its generated command alongside the successful direct command in a bug report. That comparison locates the failure much more precisely than changing the model or repeatedly adjusting GPU layers.