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 files
verified files
Working memory
Active model parts
E03E11E24E—
sized for this device
Apple Silicon
Run the model
local execution
Why this works
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 memory+Selectedparts load as needed
How Overfit works
A larger model, loaded in parts.
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.
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.
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.
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.
Before you rely on it
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
Advanced behavior
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.
What stays local
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.
Safety checks
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
01Strict package geometry and bounds validation
02File fingerprints and per-expert checksums
03Independent native validation at launch
04Bounded I/O queues and staging memory
05Automatic prefetch reduction under pressure
06Thermal and memory-pressure monitoring
07Early termination before an unsafe memory condition
08Preservation of any partial answer already generated
What to expect
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
Supported models
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.