Model File Memory Mapping: How Shared Pages Reduce Duplicate RAM Use

Memory-mapped model files can reduce duplicate RAM use because processes reference the same clean file-backed pages through the operating system page cache.

Loading two local model workers does not always require two complete copies of the weight file in physical memory. With memory mapping, each process receives virtual addresses tied to file offsets, and pages are loaded on demand. The operating system can satisfy identical clean pages from one cached physical copy while keeping each process’s private runtime state separate.

Memory Mapping Connects Virtual Addresses to File Offsets

A mapped file appears inside a process address space without an application reading the entire file into a separate heap buffer. Accessing an absent page triggers a fault; the kernel loads or finds the corresponding file-backed page and updates the process page table.

The Linux memory-mapping manual documents MAP_SHARED and MAP_PRIVATE mappings and the relationship between mapped updates and the underlying object. Read-only model weights commonly remain clean file-backed data, making them eligible for page-cache reuse. This distinction remains important under realistic household operating conditions.

Demand paging can shorten startup and limit resident memory when only part of a model is touched. It can also shift cost into first access, so cold-page faults and storage latency may appear during inference instead of during an explicit load phase.

The Page Cache Can Serve Several Processes Once

Two processes can map the same model inode and offsets into different virtual address spaces. When both read the same clean page, the kernel can map the same cached physical page into both page tables. Virtual mappings are separate; the underlying resident data can be shared.

Linux documentation for page mapping data explains how userspace can inspect page mappings and page-frame information, subject to access restrictions. These interfaces help show whether apparently separate virtual regions refer to shared physical pages. The intermediate state should remain visible during later diagnosis and review.

This is why adding per-process RSS can overstate total physical use: a shared page appears resident in each process. Proportional set size distributes shared pages across mappings and is usually more useful when estimating the combined footprint of model workers.

Private State and Dirty Pages Still Multiply

KV caches, activations, allocator arenas, tokenizer buffers, and request state are created per worker or per session. Writing through a private mapping triggers copy-on-write, creating an anonymous page that can no longer share the clean file-backed copy. Different file versions also prevent reuse.

The Linux smaps manual classifies private, shared, clean, dirty, and smaps manual for each mapping. Those categories explain why two workers sharing weights can still show substantial incremental memory as concurrency and context length increase.

The boundary is that mapping reduces duplicate clean weights, not total inference memory. Network-mounted model files can also produce unstable fault latency, and compressed or transformed loaders may allocate a second unpacked representation that defeats expected sharing.

Featured

ZimaCube 2 Personal Cloud Home NAS

ZimaCube2

$799.00 - $2,499.00

Buy Now

Compare One Worker With Two Mapped Workers

Start from a cold cache, launch one model worker, run a fixed prompt, and record startup time, page faults, RSS, PSS, and private dirty memory. Launch a second identical worker and repeat without changing the model file or loader flags.

Relate the result to the compression tradeoffs in compression tradeoffs: smaller files help storage, while mapping benefits depend on the in-memory representation actually used. Inspect each model mapping in smaps rather than relying on one process total.

Pass if the second worker adds far less weight memory than the first while producing the same output and acceptable cold latency. If PSS nearly doubles, check file identity, writable mappings, decompression, and hidden copies before assuming mmap is ineffective.