MemT-1.0-Nano garde la mémoire d'un chat dans un fichier de 41,9 MB, et il a répondu juste à 9 questions sur 9 après un rechargement

Modèle et fichiers

• MemTensor/MemT-1.0-Nano, sha 30fe0b22422c4cc4c87475f98db5c8baa5c1a902, créé le 2026-10-15, dernière modification le 2026-10-20T05:49:52Z, non restreint, Apache-2.0. 26 fragments safetensors plus memt_block.safetensors, configuration_memt.py, modeling_memt.py et tech_report.pdf. 70,3 GB téléchargés. 18 765 téléchargements et 123 likes le 2026-10-26.
• Fiche : 36B au total, 3B actifs, 451M paramètres de mémoire entraînables, 10M d'état de mémoire dynamique. library: transformers, tag custom_code.
• config.json : model_type memt_qwen3_5_moe, MemTQwen3_5MoeForCausalLM. Backbone qwen3_5_moe : 40 couches avec full_attention_interval 4 (10 en attention complète, 30 en attention linéaire, GatedDeltaNet), hidden 2048, 256 experts dont 8 par token, 16 têtes d'attention, 2 têtes KV, head_dim 256, vocabulaire 248 320, max_position_embeddings 262 144. Bloc memt : gdn_version stable_gdn2, memory_update_mode token, num_memory_heads 16, chunk_tokens 2048.
• Publication : article le 19 octobre 2026, poids et code le 20 octobre.
• Modèle frère MemTensor/MemT-1.0-Flash : backbone DeepSeek-V4-Flash, 288B au total, 17B actifs, 3,61B paramètres de mémoire entraînables, 336M d'état de mémoire dynamique, tag de licence HF mit.
• Licences : poids sous Apache-2.0 (fiche HF). Tout le code original de MemTensor/MemT-1.0 sur GitHub, memt-sglang compris, est sous PolyForm Noncommercial 1.0.0 ("Commercial use of the repository software is not permitted"). L'article est sous CC BY-NC-SA 4.0.

API de session (modeling_memt.py au sha épinglé)

• chat(query, *, memory=None, enable_memory=False, enable_thinking=None, return_dict=False). Avec enable_memory=True, l'historique en texte du tour est inscrit dans l'état de mémoire puis abandonné. Les autres tours restent dans la session comme historique en texte.
• save_state(path, *, overwrite=False) refuse par défaut d'écraser un fichier existant, vide les tours en texte et écrit des tenseurs FP32 en safetensors avec le format de métadonnées memt-memory-v1 plus un hash d'identité (config, template de chat, vocabulaire).
• Les sessions sont protégées par un threading.RLock.
• L'état est un dict de 10 tenseurs FP32 [1, 16, 256, 256], un par couche d'attention complète : 10 x 16 x 256 x 256 x 4 B = 41 943 040 B. Fichier mesuré : 41 944 024 B, soit environ 984 B d'en-tête et de métadonnées.

Version condensée du Quick Start de la fiche (Python 3.11+, PyTorch 2.11.0 compilé pour CUDA 13, 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

Calcul du stockage (le nôtre, pas une mesure)

Cache KV simple de ce backbone : 10 couches d'attention complète x 2 têtes KV x 256 x 2 (K et V) x 2 B (bf16) = 20 480 B par token. L'état de 41,9 MB équivaut au KV d'environ 2 048 tokens. À 131 072 tokens, le KV pèse 2,68 GB, 64 fois l'état (la fiche et l'article disent environ 66 fois, en taille logique par trajectoire qui exclut les poids partagés). En dessous d'environ 2 000 tokens d'historique, le fichier est plus gros que le KV qu'il remplace. Les états d'attention linéaire (GatedDeltaNet) existent dans les deux cas et ne sont pas comptés. L'article note aussi que le stockage de DenseRAG coûte moins cher que l'état fixe de Nano sur les historiques courts et ne le dépasse qu'à mesure que les enregistrements s'accumulent.

Notre installation

• Une NVIDIA A100-SXM4-80GB sur notre cloud, driver 595.91.07, CUDA 13.2, disque de conteneur de 170 GB (deux autres configurations A100 étaient en rupture de stock à ce moment-là). Poids sur le disque du conteneur, jamais sur un volume réseau.
• Un manager InferenceKey local construit depuis main, relié au worker par des tunnels. La production n'a jamais été touchée.
• Backend Python sur mesure memt-1-0-nano 0.1.1 : Transformers 5.12.1 avec trust_remote_code, PyTorch 2.11 (CUDA 13). setup() télécharge la révision épinglée avec snapshot_download, puis charge par repo id plus révision avec dtype=torch.bfloat16, device_map={"": 0} (tout le modèle sur le GPU 0, sans débordement silencieux sur le CPU) et attn_implementation="sdpa". Décodage glouton (do_sample=False), max_new_tokens 256 par défaut.
• task_type text2text, process() uniquement. Les opérations passent dans extra_body.memt = {"op": "remember" | "ask" | "save" | "close" | "load" | "status", "session": ..., "text" | "name": ...} sur /v1/chat/completions. Le texte de chat simple marche aussi (remember: ..., save: <name>, forget, load: <name>, tout le reste est une question). Chaque réponse renvoie un JSON avec la réponse, le nombre de tokens, les secondes, les tokens/s, memory_updated, plaintext_messages_kept, la taille et le sha256 du fichier, et la VRAM.

Déploiement pas à pas

Depuis l'exemple du SDK (commit ef656124 sur 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

• Il faut un driver NVIDIA pour CUDA 13 (580+), une carte de 80 GB, environ 90 GB de disque local, Python 3.11 à 3.13 sur le worker.
• Variables d'environnement optionnelles : MEMT_MAX_NEW_TOKENS (256 par défaut), IK_KEEP_ALIVE=1 pour garder le workload après l'exécution, MEMT_LOAD_IN_8BIT=1 (bitsandbytes ; voir l'échelle, ça échoue), MEMT_GPU_CAP_GIB (torch.cuda.set_per_process_memory_fraction, pour émuler une carte plus petite), MEMT_REVISION.
• main.py écrit chaque requête, réponse, nombre de tokens et temps dans outputs/memory-test.json.

La démo de 65 secondes : retenir, enregistrer, fermer, charger et demander, depuis un client en terminal face au worker.

Délai de disponibilité

Mesures

Test de mémoire, exécution 2 (bf16 ; les secondes sont du temps GPU dans le backend, l'aller-retour ajoute 0,3 à 1,1 s) :

Les tokens d'entrée passent de 27 à 210 dans la session restaurée parce que les tours de question restent comme historique en texte. La première vérification par mots-clés de main.py a compté la date de rentrée comme ratée parce qu'elle attendait "9 september" ; à la lecture, c'est juste, et la vérification commitée est plus souple.

Test d'entrée longue (bf16, MEMT_MAX_NEW_TOKENS=96) : un remember de 1 467 tokens d'entrée, réponse "Noted.", 4,02 s, texte gardé 0. Enregistrement 0,66 s, 41 944 024 B. Chargement 1,35 s. Cinq sur cinq retrouvés : code du frigo 5832 (1,55 s), propriétaire Rui Matos avec un loyer le 3 (2,01 s), police PT-77-0912 (1,76 s), gâteau Silva le 14 novembre, trois étages au citron (2,45 s), technicien de secours Marta avec un téléphone finissant par 4410 (2,21 s).

Client de la démo : remember de 58 tokens, "Noted." en 1,4 s ; enregistrement 0,68 s ; chargement 1,41 s ; "BX-4471" en 2,0 s (prompt de 21 tokens) ; "Forno Azul bakery in Porto" en 1,7 s (prompt de 58 tokens).

Vitesse : environ 9 à 10 tokens/s en décodage (128 tokens en 12,72 s) avec les kernels GatedDeltaNet de référence de PyTorch (flash-linear-attention et causal-conv1d non installés) et generate de HF. Sans réglage.

Mémoire GPU, bf16 : 65,4 GiB alloués après le chargement, pic alloué de 65,45 à 65,55 GiB pendant les requêtes, 67 605 MiB sur la carte au repos après le chargement, pic de la carte à 68 117 MiB (nvidia-smi, échantillons toutes les 1 s). Le récit donne ces valeurs en GiB (pic de 66,5 GiB ; le chargement 8 bits demandait 63,67 GiB).

Échelle de VRAM

Pourquoi le 8 bits réduit à peine : les 256 experts fusionnés par couche sont des paramètres 3D, pas des nn.Linear, donc bitsandbytes les laisse en bf16 (environ 2 GiB gagnés). Pas essayé : une vraie carte de 48 GB, H100, déchargement sur CPU, fp8, quantifications de la communauté (aucune de MemTensor au moment du test). Le plus petit qui a passé : une A100 de 80 GB en bf16.

La voie SGLang des auteurs (non testée)

• memt-sglang (import memt_sglang) dans MemTensor/MemT-1.0 : mémoire de session native sur SGLang 0.5.16. Épingle 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, backends triton pour l'attention, l'attention linéaire et le MoE, snapshots dans ./memt-state, port 30000. Le guide dit que ces réglages n'ont "not been deeply optimized".
• Contraintes : exécution eager sur un seul nœud, safetensors BF16 non quantifiés uniquement ; le chunked prefill, le radix cache, l'overlap scheduling et les graphes CUDA doivent rester désactivés ; le lanceur rejette trust_remote_code.
• Les snapshots sont des .safetensors côté serveur sous --state-directory. Routes : GET /memt/identity, GET /memt/capabilities, POST /memt/control, POST /generate avec un RID MemT. Baux (TTL de 1 à 3600 s, 300 par défaut), transactions et époques ; un redémarrage du serveur demande une nouvelle session plus l'import d'un snapshot. Les snapshots HF et les exports du serveur sont interchangeables pour le même modèle et le même tokenizer.
• La documentation ne dit pas si Nano tient sur une seule carte de 80 GB par cette voie, ni quel débit elle donne, et nous ne l'avons pas testé.
• Nous n'avons trouvé aucun support de MemT dans vLLM. Le lanceur memt-sglang est l'intégration propre aux auteurs, pas SGLang d'origine.

Chiffres de l'article (non reproduits)

arXiv 2610.26825, "MemT-1.0: Towards Memory-Native Evolution", MemTensor Team, v1 le 19 octobre 2026, v2 le 20 octobre. 34B tokens d'entraînement, pré-entraînement continu plus post-entraînement, Gated DeltaNet-2 avec une mise à jour stable de la mémoire au niveau du token, Mixture-of-Storage.

• Tableau 2, 11 benchmarks de mémoire, moyenne : MemT-1.0-Flash 50,6, MemT-1.0-Nano 47,0, Temp-LoRA 38,1 (meilleure autre méthode paramétrique). Mémoire en texte sur le 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 sur LongMemEval-S 32,6 contre Full Context 76,8 et MemOS 80,8 ; sur BEAM-1M 35,8 contre MemOS 71,3.
• Tableau 3, capacités générales dans le réglage avec bruit, écart face à 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, moyenne -0,9.
• Section 6.5, inférence HF sur deux GPU, concurrence 1, historiques BEAM : plus lent que le contexte complet sur les historiques courts, à peu près égal à 32K, accélérations de bout en bout d'environ 1,20x à 64K, 1,86x à 128K et 3,99x à 256K. TTFT de la question (temps jusqu'au premier mot de la réponse) d'environ 104 à 112 ms contre environ 257 ms (128K) et 445 ms (256K) pour le contexte complet.
• Sections 4.3 et 6.6 : état par trajectoire environ 33 fois plus petit que le contexte complet à 64K et 66 fois à 128K.

Problèmes restants et statut

1. Le chargement depuis le chemin de snapshot du cache HF échoue avec trust_remote_code. from_pretrained(<snapshot dir>) lève FileNotFoundError: ... models--MemTensor--MemT-1.0-Nano/blobs/configuration_memt.py, parce que Transformers suit le lien symbolique modeling_memt.py jusque dans blobs/ et y résout l'import relatif. Statut : corrigé dans le backend 0.1.1 en chargeant par repo id plus révision.
2. Le 8 bits ne tient pas sur une carte plus petite (échelle ci-dessus). Statut : pas de contournement ; il faut une quantification officielle ou une quantification qui tienne compte des experts.
3. Modifier config.env sur un workload de backend sur mesure en cours ne fait rien. Le manager envoie reload_backend et le worker logue reload_backend handle_load_model failed: unknown backend memt-1-0-nano ; l'ancien backend continue de servir. Contournement : supprimer le workload et relancer main.py. Statut : ouvert.
4. La création manuelle d'une machine GPU ignore le réglage de disque. Le handler code en dur DEFAULT_POD_DISK_GB = 100 et ne lit plus RUNPOD_CONTAINER_DISK_GB. 70,3 GB de poids plus un venv torch, c'est juste sur 100 GB. Statut : patché localement pour ce test seulement, ouvert.
5. Le testeur de chat du panneau ne sait pas piloter un backend process() uniquement (il fait du streaming). La démo a utilisé un client en terminal. Statut : connu, ouvert.
6. Le fichier d'état ne peut pas passer par l'API (41,9 MB face à une limite de résultat de 8 MB). Statut : voulu pour l'instant ; il reste sur le disque du worker et l'API renvoie la taille et le sha256.
7. Les tunnels entre notre manager de test et le worker sont tombés une fois ; une boucle de supervision les a reconnectés sans redémarrer le worker.

Limites

Neuf questions de rappel plus un témoin, sur nos propres faits inventés (deux de plus dans le client de la démo), décodage glouton, requêtes une à la fois. La session HF utilise un verrou par session et le backend sérialise les requêtes, donc le débit multi-utilisateur est inconnu. Un seul type de carte. Aucun benchmark de l'article n'a été reproduit, et notre 64 fois est un calcul, pas une mesure. Nous n'avons mesuré ni le temps de relecture ni la mémoire de carte par session face à une référence en contexte complet. L'endpoint hébergé d'InferenceKey n'est pas testé : tout a tourné sur un manager de test local.

Crédits

MemTensor a construit MemT-1.0, entraîné le bloc de mémoire, écrit l'API de session, l'intégration SGLang et l'article, et publié les poids de Nano sous Apache-2.0. L'équipe Qwen a fait Qwen3.6-35B-A3B, le backbone de Nano. Hugging Face Transformers fait tourner le code sur mesure des auteurs. Nous avons repéré le modèle dans la vidéo d'actualité d'AI Search du 25 octobre, et r/LocalLLaMA en parlait dans un fil du 22 octobre. Notre part : le backend sur mesure, le déploiement sur InferenceKey, la correction du chargement, les tests de mémoire et les mesures.

Sources

• Fiche du modèle MemTensor/MemT-1.0-Nano, config.json, modeling_memt.py à 30fe0b22
• Collection MemT-1
• MemTensor/MemT-1.0 sur GitHub, start_memt_nano.sh
• Article, arXiv 2610.26825
• Vidéo d'actualité d'AI Search, 2026-10-25, chapitre MemT 1.0 à partir de 38:33
• Exemple du SDK, commit ef656124