# MemT-1.0: Native AI Memory, Storage Gains and Deployment Limits

MemTensor puts persistent memory inside the model, but the useful question is what developers give up when they stop keeping the full conversation.

By Paras Madan | 2026-10-20


MemTensor introduced MemT-1.0 in a technical report submitted on October 19, 2026. The model family maintains an evolving internal memory rather than relying only on an expanding conversation. For developers building long-running agents, the appeal is retaining useful history without carrying the entire history into every interaction.

The distinction matters because remembering a preference and retrieving an exact earlier statement are different requirements. MemT makes that tradeoff worth examining, rather than making the need for external records disappear.

## How MemT-1.0 memory works

The [official repository](https://github.com/MemTensor/MemT-1.0) describes a memory block alongside the model's attention. A dynamic local memory holds information across interactions, while trained projections and gates control how information enters, leaves and is read from that memory.

During generation, the memory readout contributes to the attention output. At turn or segment boundaries, Gated DeltaNet-2 updates the memory. This is a learned representation, not a text summary appended to the prompt.

Two models are listed. Nano uses Qwen3.6-35B-A3B as its backbone, with 36 billion total parameters, 3 billion active parameters and a 10-million-element dynamic memory state. Flash builds on DeepSeek-V4-Flash, with 288 billion total parameters, 17 billion active parameters and a 336-million-element dynamic state.

Those active-parameter counts describe computation, not the total weight storage needed to serve the models. The smaller name should not be read as a promise that Nano is a lightweight laptop model.

## What the speed and storage numbers mean

The [technical report](https://arxiv.org/html/2610.26825v1) reports a 1.86-times end-to-end inference speedup for Nano at a 128K-token history, with approximately 66-times less persistent state than full-context KV caching. These are the authors' measurements, not independent production results.

**The storage comparison is per-trajectory state, not total GPU memory.** Shared model weights and other shared components are excluded. The timing test also uses a specific workload, including a 512-token query and 128-token response. Nano is slower with short histories and gains ground as history grows.

The paper acknowledges that strong textual-memory systems remain ahead overall, especially when detailed retrieval from long histories matters. A fixed-size representation can lose earlier details as new information is added. Its coding experiments also use externally retrieved experience; native memory does not eliminate that retrieval step.

For an application team, this suggests a more useful evaluation than asking whether the model “has memory.” Test whether it retains the particular information your product depends on after many unrelated interactions. A compact state is only valuable if its omissions are acceptable.

## How developers can run it

The [inference guide](https://github.com/MemTensor/MemT-1.0/blob/main/inference/README.md) supplies an SGLang-based server and Python client. It requires Linux, NVIDIA CUDA and Python 3.11 or newer. Example configurations use two GPUs for Nano and eight for Flash, but these are starting configurations, not universal minimum hardware requirements.

The documented serving path uses complete, matching BF16 checkpoints and tokenizer assets. Several usual serving optimizations, including radix caching and CUDA graphs, must be disabled. Teams should benchmark this implementation rather than assuming familiar SGLang throughput carries over.

Memory reading is enabled by default. Enabling memory writes commits conversation turns after a reply and clears their plaintext context. Sessions can save and restore memory snapshots without replaying the earlier transcript.

That creates a practical design question: which information belongs in model memory, and which must remain in an independently inspectable record? For a support assistant, remembering communication preferences might be useful. An order number or a contractual statement should still have a reliable source of truth.

## Check the license before planning a product

The repository's original software uses the [PolyForm Noncommercial License 1.0.0](https://github.com/MemTensor/MemT-1.0/blob/main/LICENSE). The project explicitly says commercial use of that software requires separate licensing from the authors. Model weights and third-party materials have their own applicable terms, rather than automatically inheriting the repository license.

So this is a research and evaluation opportunity, not a blanket permission to put the released stack into a commercial service.

The useful next step is a workload-specific comparison: persistent-state size, answer quality, latency and the cost of correcting a remembered mistake. Better memory should make an agent easier to operate, not simply make its history harder to inspect.

I’m Paras. I work at the intersection of AI, engineering and distribution.

I help technical founders turn launches and complex product ideas into clear stories that developers and founders want to read and share.

[Book a 30-minute call](https://cal.com/paras-madan/30min).