MemT-1.0-Nano speichert das Gedächtnis eines Chats in einer 41,9-MB-Datei und beantwortete nach dem Neuladen 9 von 9 Fragen

Modell und Dateien

• MemTensor/MemT-1.0-Nano, sha 30fe0b22422c4cc4c87475f98db5c8baa5c1a902, angelegt 2026-10-15, zuletzt geändert 2026-10-20T05:49:52Z, nicht gated, Apache-2.0. 26 Safetensors-Shards plus memt_block.safetensors, configuration_memt.py, modeling_memt.py und tech_report.pdf. 70,3 GB heruntergeladen. 18.765 Downloads und 123 Likes am 2026-10-26.
• Model Card: 36B gesamt, 3B aktiv, 451M trainierbare Gedächtnisparameter, 10M dynamischer Gedächtniszustand. library: transformers, Tag custom_code.
• config.json: model_type memt_qwen3_5_moe, MemTQwen3_5MoeForCausalLM. Backbone qwen3_5_moe: 40 Layer mit full_attention_interval 4 (10 mit voller Attention, 30 mit linearer Attention, GatedDeltaNet), hidden 2048, 256 Experten mit 8 pro Token, 16 Attention-Heads, 2 KV-Heads, head_dim 256, Vokabular 248.320, max_position_embeddings 262.144. memt-Block: gdn_version stable_gdn2, memory_update_mode token, num_memory_heads 16, chunk_tokens 2048.
• Release: Paper am 19. Oktober 2026, Gewichte und Code bis zum 20. Oktober.
• Geschwistermodell MemTensor/MemT-1.0-Flash: Backbone DeepSeek-V4-Flash, 288B gesamt, 17B aktiv, 3,61B trainierbare Gedächtnisparameter, 336M dynamischer Gedächtniszustand, HF-Lizenz-Tag mit.
• Lizenzen: Gewichte Apache-2.0 (HF-Card). Der gesamte Originalcode in MemTensor/MemT-1.0 auf GitHub, inklusive memt-sglang, steht unter PolyForm Noncommercial 1.0.0 ("Commercial use of the repository software is not permitted"). Das Paper steht unter CC BY-NC-SA 4.0.

Session-API (modeling_memt.py beim festgelegten sha)

• chat(query, *, memory=None, enable_memory=False, enable_thinking=None, return_dict=False). Mit enable_memory=True wird der Klartextverlauf des Turns in den Gedächtniszustand übernommen und verworfen. Andere Turns bleiben als Klartextverlauf in der Sitzung.
• save_state(path, *, overwrite=False) überschreibt eine vorhandene Datei standardmäßig nicht, übernimmt die Klartext-Turns und schreibt FP32-Tensoren als Safetensors mit dem Metadatenformat memt-memory-v1 plus einem Identitäts-Hash (Config, Chat-Template, Vokabular).
• Sitzungen sind durch ein threading.RLock geschützt.
• Der Zustand ist ein Dict aus 10 FP32-Tensoren [1, 16, 256, 256], einer pro Layer mit voller Attention: 10 x 16 x 256 x 256 x 4 B = 41.943.040 B. Gemessene Datei: 41.944.024 B, also etwa 984 B Header und Metadaten.

Gekürzt aus dem Quick Start der Model Card (Python 3.11+, PyTorch 2.11.0 für CUDA 13 gebaut, pip install transformers==5.12.1 accelerate==1.15.0 safetensors==0.8.0):

import torch
from transformers import AutoModelForCausalLM, AutoTokenizer

repo = "MemTensor/MemT-1.0-Nano"
tokenizer = AutoTokenizer.from_pretrained(repo, trust_remote_code=True)
model = AutoModelForCausalLM.from_pretrained(
    repo,
    trust_remote_code=True,
    dtype=torch.bfloat16,
    device_map="auto",
    attn_implementation="sdpa",
)

session = model.create_session(tokenizer)
session.chat("<facts to remember>", enable_memory=True, enable_thinking=False)
session.save_state("memmy_memory.safetensors")
session.close()

restored = model.create_session(tokenizer, state="memmy_memory.safetensors")
print(len(restored.messages))  # 0

Speicherrechnung (unsere, nicht gemessen)

Einfacher KV-Cache dieses Backbones: 10 Layer mit voller Attention x 2 KV-Heads x 256 x 2 (K und V) x 2 B (bf16) = 20.480 B pro Token. Der Zustand mit 41,9 MB entspricht dem KV von etwa 2.048 Tokens. Bei 131.072 Tokens ist der KV 2,68 GB groß, das 64-Fache des Zustands (Model Card und Paper nennen etwa das 66-Fache, als logische Größe pro Trajektorie ohne geteilte Gewichte). Unter etwa 2.000 Tokens Verlauf ist die Datei größer als der KV, den sie ersetzt. Die Zustände der linearen Attention (GatedDeltaNet) gibt es in beiden Fällen, sie sind nicht mitgezählt. Das Paper merkt außerdem an, dass der Speicher von DenseRAG bei kurzen Verläufen billiger ist als Nanos fester Zustand und ihn erst überholt, wenn sich Einträge ansammeln.

Unser Setup

• Eine NVIDIA A100-SXM4-80GB in unserer Cloud, Treiber 595.91.07, CUDA 13.2, 170 GB Container-Platte (zwei andere A100-Konfigurationen waren zu dem Zeitpunkt nicht verfügbar). Gewichte auf der Container-Platte, nie auf einem Netzwerk-Volume.
• Ein lokaler InferenceKey-Manager, gebaut aus main, über Tunnel mit dem Worker verbunden. Die Produktion wurde nie angefasst.
• Custom Python Backend memt-1-0-nano 0.1.1: Transformers 5.12.1 mit trust_remote_code, PyTorch 2.11 (CUDA 13). setup() lädt die festgelegte Revision mit snapshot_download herunter und lädt dann über Repo-ID plus Revision mit dtype=torch.bfloat16, device_map={"": 0} (ganzes Modell auf GPU 0, kein stilles Auslagern auf die CPU) und attn_implementation="sdpa". Greedy Decoding (do_sample=False), max_new_tokens standardmäßig 256.
• task_type text2text, nur process(). Operationen reisen in extra_body.memt = {"op": "remember" | "ask" | "save" | "close" | "load" | "status", "session": ..., "text" | "name": ...} auf /v1/chat/completions. Einfacher Chat-Text funktioniert auch (remember: ..., save: <name>, forget, load: <name>, alles andere ist ein Ask). Jede Antwort liefert JSON mit der Antwort, Token-Zahlen, Sekunden, Tokens/s, memory_updated, plaintext_messages_kept, Dateigröße und sha256 sowie VRAM.

Deployment Schritt für Schritt

Aus dem SDK-Beispiel (Commit ef656124 auf main):

git clone https://github.com/inferencekey/inferencekey-sdk
cd inferencekey-sdk/examples/memt-nano-memory-state-custom-backend-private-nvidia
cp .env.example .env          # INFERENCEKEY_SDK_TOKEN, INFERENCEKEY_API_KEY,
                              # INFERENCEKEY_PROJECT, IK_WORKER_ID, and for the
                              # upload INFERENCEKEY_TENANT_ID, INFERENCEKEY_USER_TOKEN
python -m venv .venv && . .venv/bin/activate
pip install maturin requests
( cd ../../bindings/python && maturin develop --release )
python publish.py             # once: packages backend.py; uploads only if TENANT_ID and USER_TOKEN are set
python main.py                # deploy, remember x2, save, close, load, ask x4, control ask

• Braucht einen NVIDIA-Treiber für CUDA 13 (580+), eine 80-GB-Karte, etwa 90 GB lokale Platte und Python 3.11 bis 3.13 auf dem Worker.
• Optionale Env-Variablen: MEMT_MAX_NEW_TOKENS (Standard 256), IK_KEEP_ALIVE=1, um den Workload nach dem Lauf zu behalten, MEMT_LOAD_IN_8BIT=1 (bitsandbytes; siehe Leiter, es scheitert), MEMT_GPU_CAP_GIB (torch.cuda.set_per_process_memory_fraction, um eine kleinere Karte zu emulieren), MEMT_REVISION.
• main.py schreibt jede Anfrage, Antwort, Token-Zahl und Zeitmessung nach outputs/memory-test.json.

Die 65-Sekunden-Demo: merken, speichern, schließen, laden und fragen, aus einem Terminal-Client gegen den Worker.

Zeit bis bereit

Messungen

Gedächtnistest, Lauf 2 (bf16; Sekunden sind GPU-Zeit im Backend, der Round Trip kommt mit 0,3 bis 1,1 s dazu):

Die Input-Tokens wachsen in der wiederhergestellten Sitzung von 27 auf 210, weil Ask-Turns als Klartextverlauf bleiben. Die erste Schlüsselwortprüfung von main.py wertete das Einschulungsdatum als Fehler, weil sie "9 september" erwartete; beim Lesen ist es richtig, und die committete Prüfung ist lockerer.

Test mit langem Input (bf16, MEMT_MAX_NEW_TOKENS=96): ein remember mit 1.467 Input-Tokens, Antwort "Noted.", 4,02 s, Klartext behalten 0. Speichern 0,66 s, 41.944.024 B. Laden 1,35 s. Fünf von fünf erinnert: Kühlraumcode 5832 (1,55 s), Vermieter Rui Matos mit Miete am 3. (2,01 s), Police PT-77-0912 (1,76 s), Torte für Silva am 14. November, dreistöckig mit Zitrone (2,45 s), Ersatztechnikerin Marta mit einer Telefonnummer, die auf 4410 endet (2,21 s).

Demo-Client: remember mit 58 Tokens, "Noted." in 1,4 s; Speichern 0,68 s; Laden 1,41 s; "BX-4471" in 2,0 s (Prompt mit 21 Tokens); "Forno Azul bakery in Porto" in 1,7 s (Prompt mit 58 Tokens).

Tempo: etwa 9 bis 10 Tokens/s Decode (128 Tokens in 12,72 s) mit den PyTorch-Referenzkerneln für GatedDeltaNet (flash-linear-attention und causal-conv1d nicht installiert) und HF generate. Nicht getunt.

GPU-Speicher, bf16: 65,4 GiB alloziert nach dem Laden, 65,45 bis 65,55 GiB Spitze alloziert während der Anfragen, 67.605 MiB auf der Karte im Leerlauf nach dem Laden, 68.117 MiB Spitze auf der Karte (nvidia-smi, Samples alle 1 s). Der Haupttext nennt diese Werte in GiB (66,5 GiB Spitze; das 8-Bit-Laden forderte 63,67 GiB an).

VRAM-Leiter

Warum 8 Bit kaum verkleinert: Die 256 fusionierten Experten pro Layer sind 3D-Parameter, kein nn.Linear, deshalb lässt bitsandbytes sie in bf16 (etwa 2 GiB gespart). Nicht ausprobiert: eine echte 48-GB-Karte, H100, CPU-Offload, fp8, Quantisierungen aus der Community (zum Testzeitpunkt keine von MemTensor). Das Kleinste, was bestand: eine A100 mit 80 GB in bf16.

Der SGLang-Weg der Autoren (nicht getestet)

• memt-sglang (import memt_sglang) in MemTensor/MemT-1.0: natives Sitzungsgedächtnis auf SGLang 0.5.16. Pinnt PyTorch 2.11.0, Transformers 5.12.1, flashinfer-python[cu13] 0.6.14, sglang-kernel 0.4.5. PolyForm Noncommercial 1.0.0.
• inference/start_memt_nano.sh: CUDA_VISIBLE_DEVICES=0,1, --tp-size 2 --ep 1 --dp-size 1, --max-prefill-tokens 16384, --max-sessions-per-rank 6, --max-inflight-commits-per-rank 2, --min-kv-tokens 2048, --max-total-tokens 65536, --max-running-requests 8, --mem-fraction-static 0.60, --dtype bfloat16, Triton-Backends für Attention, lineare Attention und MoE, Snapshots in ./memt-state, Port 30000. Laut Anleitung sind diese Einstellungen "not been deeply optimized".
• Einschränkungen: Eager Execution auf einem einzelnen Node, nur unquantisierte BF16-Safetensors; Chunked Prefill, Radix Cache, Overlap Scheduling und CUDA Graphs müssen deaktiviert bleiben; der Launcher lehnt trust_remote_code ab.
• Snapshots sind serverseitige .safetensors unter --state-directory. Routen: GET /memt/identity, GET /memt/capabilities, POST /memt/control, POST /generate mit einer MemT-RID. Leases (TTL 1 bis 3600 s, Standard 300), Transaktionen und Epochen; ein Neustart des Servers braucht eine neue Sitzung plus einen Snapshot-Import. HF-Snapshots und Server-Exporte sind für dasselbe Modell und denselben Tokenizer austauschbar.
• Ob Nano damit auf eine 80-GB-Karte passt und welchen Durchsatz es hat, ist nicht dokumentiert und wurde nicht getestet.
• Wir haben keine vLLM-Unterstützung für MemT gefunden. Der Launcher von memt-sglang ist die eigene Integration der Autoren, kein Standard-SGLang.

Zahlen aus dem Paper (nicht reproduziert)

arXiv 2610.26825, "MemT-1.0: Towards Memory-Native Evolution", MemTensor Team, v1 19. Oktober 2026, v2 20. Oktober. 34B Trainings-Tokens, fortgesetztes Pre-Training plus Post-Training, Gated DeltaNet-2 mit einem stabilen Gedächtnis-Update auf Token-Ebene, Mixture-of-Storage.

• Tabelle 2, 11 Gedächtnis-Benchmarks, Durchschnitt: MemT-1.0-Flash 50,6, MemT-1.0-Nano 47,0, Temp-LoRA 38,1 (beste andere parametrische Methode). Text-Gedächtnis auf dem Backbone Qwen3.6-35B-A3B: MemOS 68,5, Full Context 66,3, Mem0 66,0, OpenViking 65,4, DenseRAG 56,5, Graphiti 45,7. Nano auf LongMemEval-S 32,6 gegen Full Context 76,8 und MemOS 80,8; auf BEAM-1M 35,8 gegen MemOS 71,3.
• Tabelle 3, allgemeine Fähigkeiten im Noise-Setting, Delta gegenüber Qwen3.6-35B-A3B: MMLU-Pro -1,6, GPQA Diamond -1,5, IFEval +3,3, LongBench v2 -2,0, BigCodeBench-Hard +2,0, LiveCodeBench v6 -5,8, Durchschnitt -0,9.
• Abschnitt 6.5, HF-Inferenz auf zwei GPUs, Concurrency 1, BEAM-Verläufe: langsamer als Full Context bei kurzen Verläufen, etwa gleich bei 32K, End-to-End-Speedups von etwa 1,20x bei 64K, 1,86x bei 128K und 3,99x bei 256K. Query-TTFT (Zeit bis zum ersten Wort der Antwort) etwa 104 bis 112 ms gegenüber etwa 257 ms (128K) und 445 ms (256K) für Full Context.
• Abschnitte 4.3 und 6.6: Zustand pro Trajektorie etwa 33-mal kleiner als Full Context bei 64K und 66-mal bei 128K.

Offene Probleme und Status

1. Laden aus dem Snapshot-Pfad des HF-Caches scheitert mit trust_remote_code. from_pretrained(<snapshot dir>) wirft FileNotFoundError: ... models--MemTensor--MemT-1.0-Nano/blobs/configuration_memt.py, weil Transformers dem Symlink von modeling_memt.py nach blobs/ folgt und den relativen Import dort auflöst. Status: in Backend 0.1.1 behoben, indem es über Repo-ID plus Revision lädt.
2. 8 Bit passt nicht auf eine kleinere Karte (Leiter oben). Status: kein Workaround; braucht eine offizielle Quantisierung oder eine Quantisierung, die die Experten berücksichtigt.
3. Eine Änderung von config.env an einem laufenden Custom-Backend-Workload bewirkt nichts. Der Manager schickt reload_backend, und der Worker loggt reload_backend handle_load_model failed: unknown backend memt-1-0-nano; das alte Backend bedient weiter. Workaround: den Workload löschen und main.py neu ausführen. Status: offen.
4. Das manuelle Anlegen einer GPU-Maschine ignoriert die Platten-Einstellung. Der Handler hat DEFAULT_POD_DISK_GB = 100 fest eincodiert und liest RUNPOD_CONTAINER_DISK_GB nicht mehr. 70,3 GB Gewichte plus ein Torch-venv sind auf 100 GB knapp. Status: nur für diesen Test lokal gepatcht, offen.
5. Der Chat-Tester im Dashboard kann ein Backend mit nur process() nicht ansteuern (er streamt). Die Demo lief über einen Terminal-Client. Status: bekannt, offen.
6. Die Zustandsdatei kann nicht über die API reisen (41,9 MB gegenüber einer Ergebnisgrenze von 8 MB). Status: vorerst so gewollt; sie bleibt auf der Platte des Workers, und die API liefert Größe und sha256.
7. Die Tunnel zwischen unserem Test-Manager und dem Worker sind einmal abgerissen; eine Supervisor-Schleife hat sie wieder verbunden, ohne den Worker neu zu starten.

Grenzen

Neun Erinnerungsfragen plus eine Kontrolle zu unseren eigenen erfundenen Fakten (zwei weitere im Demo-Client), Greedy Decoding, Anfragen eine nach der anderen. Die HF-Sitzung nutzt einen Lock pro Sitzung, und das Backend serialisiert die Anfragen, deshalb ist der Durchsatz mit mehreren Nutzern unbekannt. Ein Kartentyp. Kein Benchmark aus dem Paper wurde reproduziert, und unser 64-Fach ist eine Rechnung, keine Messung. Wir haben weder die Zeit fürs erneute Lesen noch den Kartenspeicher pro Sitzung gegen eine Full-Context-Baseline gemessen. Der gehostete InferenceKey-Endpoint ist ungetestet: Das hier lief auf einem lokalen Test-Manager.

Credits

MemTensor hat MemT-1.0 gebaut, den Gedächtnisblock trainiert, die Session-API, die SGLang-Integration und das Paper geschrieben und die Nano-Gewichte unter Apache-2.0 veröffentlicht. Das Qwen-Team hat Qwen3.6-35B-A3B gemacht, Nanos Backbone. Hugging Face Transformers führt den Custom Code der Autoren aus. Wir haben das Modell im News-Video von AI Search vom 25. Oktober entdeckt, und auf r/LocalLLaMA gab es am 22. Oktober einen Thread dazu. Unser Teil: das Custom Backend, das Deployment auf InferenceKey, der Fix fürs Laden, die Gedächtnistests und die Messungen.

Quellen

• Model Card von MemTensor/MemT-1.0-Nano, config.json, modeling_memt.py bei 30fe0b22
• MemT-1-Collection
• MemTensor/MemT-1.0 auf GitHub, start_memt_nano.sh
• Paper, arXiv 2610.26825
• News-Video von AI Search, 2026-10-25, Kapitel zu MemT 1.0 ab 38:33
• SDK-Beispiel, Commit ef656124