Le simplex a réduit de 44 % le trafic mémoire par token

Ce qu’apportent l’étirement d’adresses et le simplex

Ce qui retient l’attention ici n’est pas la géométrie pour elle-même, mais un résultat concret : dans l’expérience décrite, un simplex 4D requiert cinq accès à des cellules, contre neuf pour un cube 2D. Le trafic par token passe d’environ 111 Ko à 61 Ko, soit une baisse de 44 %.

Au moment de la discussion, la source primaire de ces chiffres était un message de l’auteur de l’expérience dans une communauté technique sur Telegram. Il ne s’agit ni d’un benchmark publié ni d’un travail de recherche achevé ; ces résultats doivent donc être considérés comme le compte rendu d’un prototype actuel, et non comme une propriété universelle de la mémoire simplex.

La première optimisation est encore plus simple : les adresses de lecture et d’écriture sont multipliées par un même facteur, ce qui élargit l’espace d’adressage disponible. Pour 1 024 paires, la métrique initiale se situait entre 0,69 et 0,73 ; avec un étirement à γ = 2, elle est montée à 0,998–0,999. Pour 4 095 paires, elle est passée de 0,04–0,05 à 0,94–0,95 avec γ = 4.

Selon l’auteur, cet étirement n’augmente pas la charge de calcul. Le coût se paie en mémoire, puisqu’il faut davantage de cellules. Ce n’est donc pas une optimisation gratuite de l’ensemble du système, mais un échange entre capacité physique et placement d’adresses plus favorable.

Remplacer le cube par un simplex cible un autre poste de coût. Lorsque la dimension augmente, un schéma cubique accroît rapidement le nombre de cellules à lire, tandis que la variante simplex testée offre un voisinage d’accès plus compact. L’auteur fait également état d’une extrapolation nettement meilleure sans étirement et d’un plafond légèrement supérieur avec celui-ci.

Les limites du gain

Le résultat semble important sur le plan de l’ingénierie, mais sa portée reste étroite : le gain concerne une architecture mémoire et une méthode d’adressage précises. Le chiffre de 44 % ne peut pas être généralisé à toute mémoire neuronale ou à toute recherche vectorielle.

Il faut d’abord examiner non seulement le trafic, mais aussi le budget mémoire total, la latence d’accès et le comportement face à des requêtes bruitées. L’auteur note déjà que le schéma simplex tolère moins bien le bruit dans les adresses, y compris les paraphrases, et utilise légèrement plus de mémoire. C’est là qu’une baisse élégante du nombre de lectures peut se heurter à la distribution réelle des requêtes.

Le test suivant, un simplex 6D, était encore en cours de calcul lors du message. L’attente théorique était optimiste, mais aucun résultat n’apparaît dans les données source ; il serait donc prématuré de lui attribuer un gain supplémentaire.

Le point le plus intéressant n’est pas un chiffre record, mais la forme du compromis : moins de mouvements de données en échange de davantage de stockage et, potentiellement, d’une moindre robustesse au bruit. L’avenir de l’approche dépendra non de la géométrie sur le papier, mais de la conservation de cet équilibre avec des adresses hétérogènes et des requêtes reformulées.

Nous avons déjà analysé l’impact des configurations de Claude Opus 4.6 sur le coût du contexte et le choix d’architecture. Cela complète la discussion sur des moyens plus efficaces d’organiser la mémoire des LLM.