Maru, moteur de stockage du cache KV haute performance développé par xcena-dev, permet aux instances d’inférence de Grands Modèles de Langage (LLM) de partager leur cache KV en utilisant la mémoire partagée. Cette approche vise à minimiser la latence, un point critique lorsque les modèles deviennent de plus en plus gourmands en contexte. L’outil cherche à éliminer les goulots d’étranglement structurels causés par les copies de données lors de l’utilisation de systèmes basés sur le transfert.

La philosophie de Maru repose sur l’absence de copies inutiles. Sur les nœuds équipés de CXL (Compute Express Link), la librairie permet aux différentes instances de lire et d’écrire directement dans la mémoire CXL partagée ; seuls des métadonnées légères transitent entre les composants. Les systèmes traditionnels, qu’ils soient médiatisés par le CPU ou directs GPU, exigent que le récepteur alloue des tampons temporaires et déplace les données via l’interconnexion, ce que Maru supprime entièrement.

Pour les architectures ne disposant pas de CXL, Maru propose une alternative via le backend remote_cxl. Dans ce cas, le cache KV réside dans la mémoire CXL de nœuds mémoire, mais les nœuds GPU sans CXL y accèdent en utilisant le réseau RDMA (Remote Direct Memory Access). Un agent CXL à distance sur chaque nœud mémoire est nécessaire pour mapper les régions et les enregistrer auprès de la carte réseau du nœud, permettant aux travailleurs d’accéder aux données via une opération RDMA unidirectionnelle.

Adapter le partage au matériel disponible

Le choix du pool de mémoire est donc conditionné par l’infrastructure. Le pool CXL est accessible aux nœuds connectés via un commutateur CXL. Le pool RDMA cible spécifiquement la mémoire CXL des nœuds mémoire, accessible par des nœuds GPU sans connexion CXL directe. Ce mécanisme permet à un nœud A de stocker le cache qu’il calcule, tandis que les nœuds B et C le chargent au lieu de recalculer l’intégralité des informations.

Cette mutualisation a des implications directes sur l’efficacité. En évitant la duplication des caches KV pour chaque instance, on maximise l’utilisation de la mémoire disponible, augmentant la capacité effective du cache. De plus, sur les nœuds CXL, l’élimination des transferts massifs de données réduit la consommation d’énergie, car cela diminue l’usage des contrôleurs réseau et du processeur.

Les enjeux de bande passante et de latence dans l’inférence

L’optimisation du cache KV est un sujet récurrent dans l’écosystème des LLM. Des discussions récentes lors de meetups spécialisés ont souligné que, même après avoir réduit la charge de calcul grâce au réemploi du cache, la bande passante mémoire peut devenir le facteur limitant. Lors du KVCache Meetup Korea 2026, des intervenants ont abordé la différence entre le temps jusqu’au premier jeton (TTFT) et le temps par jeton produit (TPOT), montrant comment les goulots d’étranglement varient selon les phases d’inférence.

Maru attaque ce problème en transformant la contrainte de bande passante réseau, qui dégrade la performance à mesure que la longueur des contextes et le nombre de consommateurs augmentent, en une contrainte de bande passante mémoire partagée, plus prévisible sur les systèmes CXL. D’autres projets, comme celui de FuriosaAI, évaluent le coût de transfert contre le bénéfice du réemploi, montrant que l’accès au cache distant peut être plus rapide que le recalcul pour des prompts de taille donnée.

Le déploiement de Maru nécessite des prérequis matériels spécifiques, incluant l’OS Ubuntu 24.04 LTS ou supérieur, Python 3.12+, et, pour le mode RDMA, une carte réseau RDMA (RoCE ou InfiniBand) sur chaque nœud. Le moteur est structuré autour de plusieurs composants : un MaruHandler intégré aux instances LLM, un serveur de métadonnées Python, et un gestionnaire de ressources C++ pour piloter la mémoire CXL.

Sources

• GitHub – xcena-dev/maru: High-Performance KV Cache Storage Engine on CXL Shared Memory for LLM Inference, github.com
• KVCache Meetup Korea 2026: Event Recap, PyTorch, 3 novembre 2026