Published result
| Metric | MemVanta | pinned llama.cpp |
|---|---|---|
| Peak RSS | 3.80 GiB | 7.24 GiB |
| Prompt processing | 2.70 tok/s | 12.82 tok/s |
| Token generation | 1.81 tok/s | 8.03 tok/s |
The memory result is scoped to the tested model, settings, host, and pinned comparison runtime. llama.cpp is substantially faster in this benchmark.
What this benchmark is designed to answer
The benchmark asks a narrow systems question: can the same quantized GGUF workload be executed with lower resident-memory usage while keeping the workload matched across runtimes? MemVanta and the comparison runtime use the identical model artifact, CPU-only execution, matched workload settings, repeated measured runs after warm-up, and a pinned comparison-runtime revision.
Peak RSS is the headline metric because the project is memory-first. Prompt-processing and token-generation throughput are published beside it so the cost of the lower-memory design remains visible.
How to interpret the 47.54% figure
The reported reduction is a peak-RSS comparison for this published OpenLLaMA 7B v2 Q4_0 experiment. It is not a universal claim that every model, machine, context size, or quantization will use 47.54% less memory.
MemVanta also publishes constrained-memory cgroup experiments, but those are secondary systems evidence. A lowest successful tested memory ceiling is not the same as a minimum physical-RAM requirement.
Try the runtime, then reproduce the comparison
If you are new to MemVanta, first verify real text generation with a supported GGUF model. For a benchmark reproduction, keep the model artifact, runtime revisions, workload settings, and raw run evidence controlled.