The Memorilla README describes handing a frozen language model 16 memory tokens. Our installed environment occupied 8,257 MB. The token budget describes what reaches the decoder; the disk measurement describes the installed software environment. Neither establishes the hardware needed to run the model.
Memorilla is research code for training and evaluating learned memory over document collections. Its practical fit depends on whether you can run a CUDA workload, preserve the checkpoint-decoder pairing and evaluate answers against known references. Our sandbox checks cover repository setup and tests, not that model workload.
Memory reaches the decoder as learned embeddings
The Memorilla README describes gathering information from a document collection into a fixed number of query-dependent memory tokens for a frozen language model. The released memory checkpoints were trained with Qwen3-8B as the decoder and Qwen3-Embedding-4B as the encoder.
The evaluation guide says memory tokens enter the decoder as prompt embeddings. The decoder must be the one the checkpoint was trained with. An existing checkpoint therefore should not be treated as an interchangeable memory backend for an arbitrary hosted decoder API.
For an experiment, keep the checkpoint and decoder together and evaluate the combination. If changing decoders independently is an application requirement, resolve that integration constraint before adopting Memorilla. We did not measure the work needed to train a compatible replacement.
What happened when we ran it
Our Memorilla run installed 205 dependencies in 116 seconds, with an installed footprint of 8,257 MB. The build completed in 4 seconds. The test step succeeded in 43 seconds, and the supplied pytest summary records 121 passed, zero failed and 2 skipped. We ran commit d8f1889 on November 10, 2026.
The summary also labels the test total as 121 despite listing skipped cases separately. We cannot reconcile a unique total from that block, so we report its passing and skipped figures without turning them into a coverage claim.
The recorded configuration had 3 CPUs and 8 GB RAM. Its uv image label references Python 3.12 and Bookworm, but actual runtime and operating-system versions require raw toolchain logs. The checkout measured 3 MB, with 65 files and approximately 7,477 source lines. The scan found one CI workflow file, a tests directory and no Dockerfile. The supplied evidence does not identify which dependencies account for the installed disk use.
Our pip-audit result reported 136 known vulnerabilities. The audit summary records 9 vulnerable packages but does not name them or provide severity and exposure details. Inspect the exact environment before deployment. The total does not establish that every advisory is reachable through Memorilla, and passing tests do not resolve the audit finding.
Passing checks leave the GPU workload unverified
The README requires Linux with CUDA GPUs and Python 3.11, and says its recipes ran on NVIDIA H100 80GB GPUs. Its starter example requires one 80 GB GPU and downloads about 25 GB of models plus a 37 MB test set on first run. These figures come from the documentation, not our sandbox run.
The README separately describes development unit tests as CPU-only and requiring no network. A successful repository test step therefore does not establish successful GPU inference or training. The supplied run does not establish that released model assets were loaded or that an answer-quality benchmark was reproduced.
According to the README, evaluation does not require FlashAttention, and training can use PyTorch attention instead. We did not compare those paths. Hugging Face model loading, local memory-checkpoint loading and optional integrations are documented; our run does not establish a complete offline model deployment.
Evaluate on documents with known answers
The custom-data recipe expects Parquet splits with collection_id, question, answer and documents columns. The README says embeddings are computed on first use. A useful next step is to prepare a representative collection with known answers and evaluate the matching checkpoint-decoder combination against those references.
The evaluation guide documents closed-book, retrieval and full-context baselines. It also says their prompts differ from Memorilla's evaluation prompts. Record those protocol differences alongside any comparison. This review provides no independent evidence that upstream benchmark advantages transfer to your documents or definition of a correct answer.
The supplied repository metadata records a last push on November 9, 2026. The supplied metadata does not establish whether a tagged release exists. Neither that uncertainty nor recent repository activity establishes production support; support capacity and operational maturity remain unassessed.
Mem0 and MemoRAG offer different integration approaches
Mem0 documents adding and searching conversational memories through an application interface. Consider that approach when your application needs to store and retrieve memories rather than supply learned prompt embeddings to a paired decoder. Mem0's README says its managed-platform benchmark figures include proprietary optimizations unavailable in the open-source SDK. Those figures are not comparative results from this review.
MemoRAG uses query-specific clues recalled from memory to support evidence retrieval. Consider it when that retrieval method is what you want to study. We have no comparative installation, accuracy or latency measurements for either alternative.
Documentation earns 4/5 on this review's task-guidance rubric: 1 means entry guidance is missing; 2 covers installation only; 3 covers common tasks; 4 adds concrete data formats and operational restrictions; 5 also requires independently verified coverage of the documented model tasks. Memorilla documents custom-data fields, checkpoint pairing and evaluation protocols, but our run did not reproduce its GPU recipes. Begin with one collection with known answers, the matching decoder and an examined dependency environment.