Hy Memory 2.0 est disponible : Tencent a open-sourcé un rédacteur de mémoire, un framework et une app Mac en une seule livraison

Tencent Hunyuan a livré trois choses d'un coup cette semaine, et seulement deux d'entre elles sont installables aujourd'hui. Hy-Memory-30B-A3B est un modèle mixture-of-experts de 30 milliards de paramètres dont le seul rôle est d'écrire la mémoire — décider ce qu'un agent conserve, comment il le formule, et comment de nouvelles preuves écrasent les anciennes. Hy Memory 2.0 est le framework qui l'entoure : un paquet Python, hy-memory, couvrant la mémoire de conversation, de travail et de code. Et MemHub est l'application — un CLI et un produit macOS local-first qui extrait l'historique de conversation et les traces de code de dix outils d'IA différents pour les réunir dans un seul espace de mémoire sur votre propre disque. Le titre du billet d'annonce est que Hy-Memory-30B-A3B bat Claude Opus 5 sur les principaux frameworks de mémoire. C'est vrai dans la mesure où cela va, et la partie intéressante, c'est jusqu'où cela va : sur trois des quatre frameworks, la marge est inférieure à six dixièmes de point, et toute la comparaison repose sur un cinquième de chaque benchmark. Chaque panne et chaque rollback de fournisseur que nous avons recensés sont consignés dans l'Orca AI Incident Archive, qui contient l'ensemble complet des enregistrements aux côtés des entrées voisines de cet incident.

Tout ce qui suit est soit extrait du dépôt, du registre de paquets et du rapport technique propres à Tencent, soit présenté comme une déclaration de Tencent. Rien ici n’a été reproduit par qui que ce soit d’autre, car à l’heure de la rédaction, personne d’autre ne l’a exécuté.

Ce qui a réellement été livré, et quand

Les trois couches sont arrivées à environ 24 heures d'écart les unes des autres, et les notes de version indiquent avec une précision inhabituelle lesquelles sont terminées :

• Le modèle — tencent/Hy-Memory-30B-A3B a été publié sur Hugging Face le 15 octobre 2026 (09:52 UTC), sous licence Apache 2.0, avec le rapport technique, arXiv 2610.22196, soumis le même jour.

• Le framework — hy-memory==2.0.1 a été publié sur PyPI le 15 octobre 2026 à 17 h 24 UTC, et le monorepo a été mis en open source le jour même. Le tag de version v1.0.0 GitHub a été créé le 16 octobre à 08 h 44 UTC.

• L'application — les ressources de version de MemHub existent : une image disque macOS arm64 notariée de 303 Mo selon le décompte de GitHub, ainsi que des paquets d'exécution Linux arm64 et x64 de 245 Mo et 251 Mo. Windows est répertorié comme non pris en charge.

• L'écart — le changelog du projet lui-même indique que MemHub « n'a pas encore de version publique », que sa version source est la 1.0.0 (build 4), et que la publication sur npm comme les artefacts de GitHub Release sont tous deux encore en attente. Le paquet npm qu'il compte utiliser, memhub-cli, renvoie un 404 depuis le registre. Les images disque sont jointes à la version ; l'installateur en ligne de commande censé les récupérer n'est pas publié.

Ce dernier point mérite d’être lu deux fois, car c’est la différence entre un lancement et une version candidate. La version Apple est signée et notariée, ce qui représente un vrai travail, et la page de publication a recueilli une petite poignée de téléchargements. Mais le chemin d’installation documenté commence par un paquet npm qui n’existe pas au moment d’écrire ces lignes. Si vous envisagiez d’essayer MemHub cette semaine, prévoyez un checkout des sources plutôt qu’une installation en une ligne.

Hy-Memory-30B-A3B, le modèle

Le fichier de configuration est le document le moins romantique et le plus utile de toute la version. Il décrit une forme MoE standard et bien comprise plutôt que quelque chose d’exotique :

• Paramètres — 30 milliards au total, environ 3 milliards actifs par token, ce que signifie le suffixe A3B.

• Architecture — 48 couches, dont une est dense et 47 sont des MoE clairsemés ; 128 experts par bloc avec un routage top-8 plus un expert partagé ; taille cachée de 2 048 ; largeur intermédiaire d'expert de 768 ; 32 têtes d'attention contre 4 têtes clé-valeur avec normalisation requête-clé ; un routeur sigmoïde avec un terme de biais d'expert et un facteur d'échelle de 2,826.

• Contexte — 262 144 positions, avec une base RoPE de 11 158 840.

• Empreinte — 51 fragments safetensors, environ 60,1 Go en BF16. C’est la seule précision livrée par Tencent.

• Service — la fiche est rédigée autour de vLLM, testée avec la v0.31.0, derrière un point de terminaison compatible OpenAI, et elle cite également SGLang et Docker Model Runner comme environnements d’exécution pris en charge. Il n’est déployé par aucun fournisseur d’inférence, et l’index de recherche Hugging Face ne remonte aucun GGUF, aucune build FP8 ou NVFP4, ni aucun fine-tune.

Cette absence est l’obstacle pratique. Un fournisseur qui livre un checkpoint BF16 de 60 Go et rien d’autre vous dit où il s’attend à ce que le modèle tourne, et la réponse est une machine que vous possédez déjà ou louez dans un centre de données. Il n’existe aucun équivalent quantifié que quiconque puisse évaluer sur une station de travail.

Le modèle est piloté avec reasoning_effort : « no_think » et temperature 0.0 dans le guide de démarrage rapide de T​encent. Un composant d'écriture de mémoire se déclenche à chaque tour de conversation pour décider ce qu'il faut conserver, donc délibérer est un mauvais compromis : il doit être déterministe, produire des sorties courtes et être peu coûteux. Ce choix de conception est aussi l'argument le plus fort en faveur de l'existence même du modèle, car c'est exactement la charge de travail où un modèle de chat de pointe est le plus gaspilleur.

Le 55.49, lu comme il se doit

Tencent a entraîné le rédacteur sur trois frameworks de mémoire — Mem0, MemOS et son propre Hy-Memory — puis l’a évalué sur un quatrième, EverMemOS, qui avait été entièrement tenu à l’écart de l’entraînement. Mettre un harnais de côté est la bonne façon de tester une affirmation de transfert, et le transfert entre frameworks constitue toute la thèse de l’article.

Les résultats, qui sont ceux de Tencent et non reproduits :

• Hy-Memory-30B-A3B — 55,49 de moyenne macro sur les quatre harnais.

• Claude Opus 5 — 54,62.

• DeepSeek V4.1 Flash — 53,64.

• Tencent Hy3 — 51,63.

• Qwen3.6-35B-A3B — 50,37.

• Hy3-A3B Base — 47,66, le même modèle avant l’entraînement spécifique à la mémoire, c’est de là que provient le gain d’entraînement de 7,8 points mis en avant.

• Qwen3-30B-A3B — 44,37.

En distinguant par harnais, l'avantage se réduit. Face à Claude Opus 5, les marges sont de 54,02 contre 53,43 sur Mem0, 60,55 contre 60,53 sur Hy-Memory, 50,51 contre 50,50 sur MemOS, et 56,89 contre 54,04 sur EverMemOS. Trois de ces quatre sont du bruit statistique coiffé de lauriers — une avance de deux centièmes de point sur le harnais Hy-Memory n'est pas une avance. Toute la séparation entre un spécialiste à 3B actifs et un modèle de pointe tient au seul harnais qui a été exclu de l'entraînement, où l'écart est de 2,85 points et où l'affirmation est aussi la moins susceptible d'avoir été ajustée contre lui.

Deux détails de conception comptent autant que les chiffres. Chaque chiffre de la matrice principale repose sur un sous-échantillon fixe de 20 % plutôt que sur le benchmark complet, et l'évaluation ne fait varier que le rédacteur, en gardant fixes le harnais, les prompts, la configuration de récupération, le modèle de réponse et le juge. Ce second choix relève d'une bonne hygiène expérimentale — il isole la variable testée — mais il s'agit du harnais de Tencent et du juge de Tencent. Considérez le tableau comme une hypothèse assortie d'un dépôt, ce qui est plus que ce qui accompagne la plupart des affirmations d'un jour de lancement, et moins qu'un résultat.

Les chiffres du cadre sont l’affirmation la plus forte.

La comparaison des modèles est la citation que Tencent a mise dans le post. La comparaison des frameworks est celle qui changerait l'architecture d'un lecteur si elle se vérifie.

Sur le site de l'entreprise, Hy Memory 2.0 est classé premier parmi les frameworks de mémoire open source sur quatre benchmarks — devant Mem0, MemOS, EverOS, OpenViking, RepoMemory et une simple baseline RAG à fenêtre glissante — dans les trois scénarios qu'il couvre :

• Chat — 72,6 % sur LoCoMo, sur 1 527 questions non-adversariales.

• Working — 55,31 % de moyenne sur MemoryArena (une suite de planification de voyages et d’achats groupés), 10,2 points d’avance sur le framework suivant.

• Programmation — 64,2 % pour la réponse aux questions sur CodeMemoryBench et un taux de résolution de 35,6 %, ainsi qu’un taux de résolution de 28,3 % sur SWE-ContextBench.

• Empreinte — stockage en mémoire de 6,06 % des jetons d’entrée, contre 31,9 % à 41,2 % pour les frameworks auxquels elle est comparée.

C'est le chiffre d'empreinte qui mérite d'être repris. Les systèmes de mémoire échouent en production pour deux raisons : ils oublient les mauvaises choses et ils croissent sans limite. Une banque qui coûte six pour cent de la conversation qu'elle résume constitue une proposition opérationnelle différente de celle qui en coûte quarante, et c'est la dimension dont un public axé sur le routage et les coûts devrait se soucier, que le classement par exactitude survive ou non à l'examen. Le protocole d'évaluation est publié en parallèle : modèle de mémoire DeepSeek V4.1 Flash, modèle de réponse et de jugement GPT-5.6-sol, stockage mesuré en tokens de banque sur tokens d'entrée, la banque ne comptant que la mémoire générée.

Tencent recense également des déploiements internes — un test de rappel d’un assistant boursier avec une amélioration multi-sauts de 40 points, un plugin de base de connaissances et une évaluation des préférences d’une application d’actualités avec une moyenne de 91,68 sur 100 — dans les domaines de la finance, de l’actualité, de la gestion des connaissances, des agents de bureautique, du social et du jeu. Ce sont les propres métriques produit de l’entreprise, pas des benchmarks, et elles doivent être lues comme la preuve que le système tourne quelque part en conditions réelles, plutôt que comme la preuve qu’il surpasse quoi que ce soit.

MemHub est l'élément que la plupart des lecteurs pourraient réellement utiliser.

Le modèle a besoin de GPU. Le framework a besoin d'une équipe d'ingénieurs. MemHub a besoin d'un ordinateur portable.

Il s'agit d'un produit de bureau et en ligne de commande local-first qui regroupe l'historique des outils d'IA que vous avez déjà autorisés dans un seul environnement d'exécution géré et un seul répertoire de données — ainsi, une préférence que vous définissez dans un agent de codage est disponible pour le suivant. T​encent nomme dix intégrations prises en charge : WorkBuddy, Cursor, Codex, C​laude Code, OpenCode, OpenClaw, Q​wen Code, Pi, Hermes et D​eepSeek Harness. Le chemin de données indiqué est ~/.one-memory, avec SQLite pour les métadonnées de travail et de codage et ChromaDB ainsi que Kuzu comme stockages par défaut, et la documentation de sécurité précise explicitement que le produit ne collecte pas le contenu d'écran, les arborescences d'accessibilité, l'OCR, le presse-papiers ni l'audio en arrière-plan.

Les affirmations à propos desquelles il faut être sceptique sont celles qui concernent la suppression. La CLI distingue trois niveaux : la désinstallation du paquet npm ne supprime que la CLI ; memhub uninstall supprime les services, le runtime géré et les liens de la CLI, mais conserve votre mémoire ; et seule une commande distincte, memhub delete-data, supprime le stockage — après avoir arrêté le runtime et confirmé le chemin exact. C’est une meilleure conception que celle de la plupart des outils de cette catégorie, et c’est aussi la description du comportement prévu dans une version dont l’installateur n’est pas encore publié. Quiconque l’adopte pour un travail important devrait vérifier lui-même le chemin de suppression avant de lui confier quoi que ce soit que l’on ne voudrait pas voir conservé.

Ce qui n'est toujours pas confirmé, dit clairement.

• Aucun benchmark indépendant, quel qu’il soit. Aucune exécution de harnais tiers, aucun placement dans une arène, et rien de reproduit en dehors de T​encent.

• Aucune reproduction du tableau inter-harnais, et en particulier du résultat EverMemOS mis de côté, qui fait reposer toute la thèse de transfert sur une seule exécution d’un fournisseur.

• Aucune quantification, donc aucune empreinte mémoire mesurée inférieure à 60 Go et aucun parcours d’évaluation à l’échelle d’une station de travail.

• Aucun point de terminaison hébergé, et aucun fournisseur d’inférence mentionné sur la fiche du modèle.

• Aucun paquet npm publié pour MemHub, donc le chemin d'installation documenté ne fonctionne pas encore de bout en bout.

• Aucun chiffre de coût par conversation. L’écriture en mémoire est une charge de travail à haute fréquence et à sortie courte ; personne n’a publié le nombre de jetons par écriture ni ce que coûte réellement l’exploitation d’un assistant doté de mémoire par utilisateur et par mois.

Là où un routeur a sa place, et où il ne l'a pas

Soyez précis à ce sujet, car il serait facile d’exagérer. Hy-Memory-30B-A3B ne figure pas au catalogue d’OrcaRouter et nous ne l’hébergeons pas. La route vers l’écrivain est le checkpoint sur Hugging Face et votre propre matériel. Rien dans une couche de routage ne change cela.

Ce que couvre un routeur, c'est l'autre moitié du harnais. Un système de mémoire, c'est un chemin d'écriture et un chemin de lecture, et l'évaluation publiée par Tencent dit tout haut ce qu'est habituellement le chemin de lecture : celui qui écrit décide de ce qu'il faut stocker, et un modèle de frontière distinct relit la banque et répond. Dans la configuration de Tencent elle-même, il s'agit de DeepSeek V4.1 Flash pour le modèle de mémoire et de GPT-5.6-sol comme modèle de réponse et juge. OrcaRouter dessert les deux avec une seule clé, au prix catalogue et sans majoration, de sorte qu'un changement de prix d'un fournisseur est répercuté de notre côté le jour même, plutôt qu'à la prochaine reconduction de contrat.

Le DSL de routage est la pièce qui correspond spécifiquement à cette architecture. Il compose un point de terminaison auto-hébergé et un point de terminaison hébergé en un seul appel, ce qui correspond exactement à la forme d'un système de mémoire — un spécialiste bon marché sur le chemin d'écriture que vous exécutez vous-même, un modèle de pointe sur le chemin de lecture que vous louez. La même configuration rend la partie risquée survivable : pointez l'écrivain vers votre propre déploiement Hy-Memory-30B-A3B, gardez un modèle général derrière le basculement automatique, et un mauvais chemin d'écriture dégrade la réponse au lieu de faire tomber l'application. Ce schéma mérite d'être construit avant même que l'écrivain ne soit en fonctionnement, car il est identique que le chemin d'écriture soit un point de contrôle spécialisé ou un modèle général doté d'un prompt de mémoire.

Qui devrait agir, et qui devrait attendre

Si vous exécutez des agents avec une mémoire à long terme et que vous disposez déjà de GPU, le chemin d'écriture est l'endroit honnête pour passer une semaine : le checkpoint est Apache 2.0, et un writer de mémoire est le rare modèle dont vous pouvez mesurer la valeur sur votre propre trafic plutôt que sur le tableau de benchmark de quelqu'un d'autre. Si vous êtes un utilisateur plutôt qu'un opérateur, MemHub est le plus intéressant, et c'est aussi celui qu'il faut attendre jusqu'à ce que l'installateur existe et que quelqu'un en dehors de T​encent ait utilisé le chemin de suppression. Et si vous choisissez un modèle sur la base de l'annonce, la posture correcte est celle que la publication elle-même invite : 55,49 contre 54,62 est une égalité sur trois harnais et un écart réel sur le quatrième, et le quatrième est celui que personne n'a vérifié.