Local model paging · Mac

Noema Overfit

Use larger models on compatible devices.

Overfit loads only the parts of a compatible mixture-of-experts model needed for each response. The remaining files stay in local storage, so the complete model does not need to fit in memory. This adds capacity, not a guarantee of speed.

Live execution pathLocal storage → unified memory → Metal

Local storage

Model filesverified files

Working memory

Active model partssized for this device

Apple Silicon

Run the modellocal execution

Only part of the model is active at a time.

A mixture-of-experts model is made from many specialist parts, but each token uses only a small subset of them. Loading every part into memory is often unnecessary.

Overfit keeps shared parts in memory and stores the rest in a verified local package. That can make a compatible model runnable on a device where its full files would not fit, with performance determined by the device, storage, context, and model itself.

Commonparts stay in memorySelectedparts load as needed

A larger model, loaded in parts.

  1. 01

    1 · Prepare

    Prepare the model package.

    On Mac, Noema converts a compatible mixture-of-experts GGUF into a `.noema-paged` package. The conversion changes how the files are stored and loaded; it does not retrain, prune, or replace the model.

    • A core model file with the parts needed throughout a response.
    • Separate files for the model’s specialist parts.
    • A manifest that verifies each file before it is used.
  2. 02

    2 · Set the working set

    Reserve memory for this device.

    At launch, Noema decides how much of the model can stay in memory. More available memory means fewer reads from storage; less memory leaves more room for the conversation and the rest of the app.

    • The working set is calculated for the current device and memory state.
    • Models that fit normally use the standard local loading path.
  3. 03

    3 · Load what is needed

    Read only the active model parts.

    When a response needs a part that is not already in memory, Noema reads it from local storage, verifies it, and makes it available to the model.

    • Related reads can be combined to reduce storage overhead.
    • Frequently used parts can stay available without allowing memory use to grow without limit.
  4. 04

    4 · Run locally

    Generate the response on Apple silicon.

    Noema runs the model with its native Apple-silicon runtime and reuses model parts that are already available when possible.

    • Long prompts are processed in bounded groups.
    • Generation reuses model parts already in the working set when possible.

Test the actual device.

The Canary Test runs the exact package on the actual device and reports whether the experience is interactive, slow, better on another device, or unsupported. Results can change when the package, device, storage, or app build changes.

What it measures

  • 01Storage bandwidth
  • 02Time to first token
  • 03Generation speed
  • 04Latency percentiles
  • 05Long stalls
  • 06Bank hit rate
  • 07Page misses
  • 08Peak memory

Possible result

  • Interactive on this device
  • Runs, but slowly
  • Too slow for this device
  • Use a Mac through Constellation
  • Not supported

Follow-up prompts can reuse prior work.

After a successful conversation, Noema can save a local checkpoint and reuse an unchanged system prompt and conversation prefix on a matching future launch.

Checkpoints are tied to the exact model and settings. If a checkpoint cannot be used, Noema falls back to normal prompt processing.

The model and conversation stay on your device.

  • Model files remain in local storage.
  • Prompts and responses remain on the device.
  • No cloud inference service is required.
  • Saved prompt states remain local and tied to their configuration.

If the device is not a good fit, Noema may suggest using a Mac through Constellation. That remains a separate choice.

Invalid or incomplete files are rejected.

Noema verifies package structure and file checksums before using model parts. Memory, storage, and thermal safeguards limit work under pressure.

View technical safeguards
  1. 01Strict package geometry and bounds validation
  2. 02File fingerprints and per-expert checksums
  3. 03Independent native validation at launch
  4. 04Bounded I/O queues and staging memory
  5. 05Automatic prefetch reduction under pressure
  6. 06Thermal and memory-pressure monitoring
  7. 07Early termination before an unsafe memory condition
  8. 08Preservation of any partial answer already generated

More capacity, with tradeoffs.

A model that fits completely in memory will usually start faster, generate faster, and use less energy. Overfit is useful when access to a larger model matters more than minimum latency.

01Storage throughput02Available memory03Model architecture04Quantization05Experts per token06Prompt length07Bank hit rate08Thermal state09Speculative decoding

Compatibility is limited.

The current runtime supports paged packages for Qwen 3, Qwen 3.5, Qwen 3.6, Gemma 4,Poolside Laguna S 2.1 and Laguna XS 2.1, and DeepSeek V4 Flash 0731. It is not a generic mechanism for dense models or arbitrary GGUF architectures.

DeepSeek V4 Flash is available as a complete package in the Noema collection. For Laguna, download a compatible official GGUF and use Create Paged Package in Stored on macOS. Package creation, context limits, and auxiliary or multimodal workflows can still vary by model.

Pre-built packages are published in the NoemaAI-labs/Noema-Overfit repository on Hugging Face. Poolside Laguna source GGUFs are linked above for Mac package creation.

Run compatible models locally.

Local execution with measurable limits.