System design

MemVanta architecture: memory-first CPU LLM inference

The runtime is organized so throughput optimizations do not silently turn into full-model residency or weaken correctness evidence. Storage, memory policy, numerical kernels, and trained-model execution are kept as separate concerns.

1. GGUF container and mapped storage

The GGUF layer validates container structure, metadata limits, tensor ranges, and quantized byte sizes. Model access is backed by memory mapping, while the tensor-store layer exposes bounded slices rather than requiring an unconditional full-model copy.

The parser is intentionally more architecture-neutral than the trained-model execution path. That distinction matters: being able to validate a GGUF file does not imply that MemVanta can execute that model family.

2. Explicit memory policy

Bounded caching, asynchronous prefetching, adaptive look-ahead policy, and runtime telemetry are separated so each layer has a clear responsibility. The adaptive controller receives completed observation windows and changes prefetch depth without owning storage itself.

This separation makes the policy easier to test deterministically and helps prevent benchmark-specific behavior from leaking into the storage layer.

3. Quantized numerical kernels

MemVanta contains compact quantization primitives and trained-model tensor kernels, including optimized CPU paths. Reusable worker-pool parallelism is separated from the model graph so CPU execution can be improved without redefining memory ownership.

Optimized release paths are accepted only when deterministic correctness remains green. Performance work is evaluated with memory and throughput together.

4. Trained-model execution and KV state

The current trained-model graph is Llama-family focused. Paged KV cache and tokenizer logic live alongside that graph today, while future architecture expansion is intended to move model-specific behavior behind smaller interfaces rather than growing a single monolithic execution path.

Validation layers

  1. Correctness: Release/Debug builds, sanitizer lanes, parser limits, FP16 coverage, concurrency stress, and fuzz smoke.
  2. ISA portability: native x86, portable x86 dispatch, macOS, and ARM64 cross/QEMU validation.
  3. Container validation: non-Llama GGUF parsing is tested without turning that into an execution-support claim.
  4. Model correctness: deterministic Llama-family checks and pinned external-reference/tokenizer comparisons.
  5. Performance evidence: repeated same-machine, same-workload A/B runs with peak RSS and throughput published together.

See the design under measurement