L'infrastructure d'IA d'entreprise est passée de l'optimisation des modèles d'entraînement à leur déploiement, ce qui modifie la donne économique. L'entraînement représente un investissement initial limité. L'inférence, quant à elle, constitue une charge de travail de production continue, fonctionnant tant que le service est opérationnel, et dont la production est mesurée en jetons. C'est le problème de la tokenomics auquel sont confrontés les opérateurs d'IA : une fois les GPU installés et le budget énergétique défini, la rentabilité de l'entreprise dépend du nombre de jetons produits par le matériel.
Dans les charges de travail longues et complexes, le même contexte est traité de manière répétée par le modèle à mesure que les conversations s'allongent. Le GPU a déjà payé pour traiter ces jetons, mais lorsque le cache KV est vidé, le système doit préremplir ce contexte à nouveau. Cela oblige le système adverse à recalculer. À n'importe quelle échelle, il ne s'agit pas d'une erreur d'arrondi. Cela représente un coût réel, sous forme de consommation d'énergie, de temps GPU, d'allongement de la file d'attente ou de matériel supplémentaire.
La solution de facilité consiste à acheter davantage de ressources les plus coûteuses : plus de GPU, plus de DRAM. Or, le recalcul a déjà produit des données réutilisables. Le cache KV ne contient que des données ; son stockage et sa récupération sont peu coûteux, moyennant un léger surcoût de rechargement, compensé par le coût élevé du préremplissage évité. La question n'est donc plus de savoir s'il faut conserver le cache, mais où le placer, et c'est autant une question de coût que de performance. La VRAM est la ressource la plus rapide, mais aussi la plus rare ; une fois saturée, le serveur d'inférence commence à libérer de l'espace dans le cache. La DRAM permet d'acquérir de la marge de manœuvre, mais à un prix élevé et en constante augmentation. C'est là que la situation change : plus lente que la DRAM, certes, mais bien moins chère au téraoctet, avec une capacité suffisante pour conserver le contexte que les ressources plus rapides sont contraintes d'ignorer, ce qui fait la différence entre retraiter l'intégralité de la conversation et simplement la relire.
Pour mesurer l'impact, nous avons créé une charge de travail de test multi-itérations sur un serveur Dell PowerEdge XE7740, en maintenant constants le modèle, les GPU et la pile de serveurs. Le chiffre crucial pour le dimensionnement d'un système est ce qui se passe une fois les niveaux de mémoire saturés. Au-delà de ce seuil, la mémoire flash a maintenu environ 30 000 jetons par seconde, contre 17 000 pour la DRAM, conservant ainsi 94 % de son pic tandis que le niveau DRAM chutait à 42 %. Les deux niveaux de déchargement ont largement surpassé le niveau de référence basé uniquement sur la VRAM au pic (2.9 fois plus pour la DRAM et 2.2 fois plus pour la mémoire flash), mais ce pic correspond précisément au moment où le niveau DRAM est sur le point d'être saturé. La mémoire la plus coûteuse permet d'atteindre le pic ; la mémoire flash le maintient à mesure que le contexte augmente.
Avant de présenter les résultats, il convient de préciser ce qu'est le cache KV, pourquoi il se remplit et pourquoi les performances d'inférence commencent à s'effondrer lorsque le système ne dispose d'aucun autre emplacement moins coûteux pour le stocker.
Points clés à retenir
- La mémoire Flash supporte ce que la DRAM ne peut pas : Les trois configurations présentent des performances identiques jusqu'à ce que la saturation de la mémoire entraîne une expulsion des données. La VRAM sature en premier, puis la mémoire DRAM de 512 Go se remplit environ 45 minutes après le début de l'exécution et commence à être saturée. Au-delà de ce point, la mémoire flash maintient environ 30 000 jetons par seconde contre 17 000 pour la DRAM, conservant ainsi 94 % de sa capacité maximale tandis que celle de la DRAM chute à 42 %.
- Le déchargement permet de récupérer le débit perdu lors du recalcul : En période de pointe, le déchargement du cache KV a permis d'augmenter le débit total de service jusqu'à 2.9 fois par rapport à la configuration de référence utilisant uniquement la VRAM sur la couche DRAM et 2.2 fois sur la mémoire flash. Ce gain provient de l'absence de préremplissage, car le contexte déjà calculé par le GPU est relu depuis la couche de déchargement au lieu d'être reconstruit.
- Ce sont les utilisateurs réguliers qui ressentent le plus la différence : Dans le pire des cas, la latence initiale lors d'une session reprise était de 13.9 secondes avec la mémoire VRAM uniquement, contre 3.2 secondes avec la mémoire flash. Le déchargement du système permet de limiter cette latence à un délai acceptable pour un utilisateur interactif.
- La circulation des agents rend les expulsions coûteuses : Une semaine de trafic instrumenté Claude Code a montré 98.16 % de lectures en cache, avec seulement 0.02 % d'entrées réellement froides.
- Le déchargement KV est une charge de travail intensive en écriture qui exige des disques à haute endurance : Chaque jeton produit par le modèle crée une entrée KV, et la mise à jour continue du TTL réécrit la couche en permanence. À notre taux d'écriture soutenu, la grappe RAID 10 en miroir que nous avons testée représente environ 3.2 écritures par jour et par disque, contre environ 1.6 DWPD en RAID 0, ce qui correspond à la capacité de 3 DWPD du D7-PS1030. L'endurance, et non la capacité ou la vitesse, est la contrainte principale de la couche flash, et comme le cache est jetable, une utilisation aussi intensive d'un disque dédié à l'écriture est un compromis acceptable.
Comment fonctionne l'inférence
Les grands modèles de langage sont autorégressifs : chaque jeton de sortie est conditionné par tous les jetons précédents. Le mécanisme d'attention implémente ce conditionnement en calculant (pour chaque jeton de la séquence) un vecteur de requête (Q) qui est comparé aux vecteurs de clé (K) et de valeur (V) de chaque jeton précédent. La sortie de l'attention est une combinaison pondérée des valeurs, les poids étant issus des produits scalaires QK.
Lorsqu'une requête arrive, il est impossible d'y répondre tant que les tenseurs K et V ne sont pas disponibles pour chaque jeton. La première étape, le préremplissage, consiste pour le moteur à traiter la requête à travers le modèle en une seule passe parallèle et à écrire les tenseurs K et V résultants en mémoire. Le préremplissage est donc gourmand en ressources de calcul, et sa latence est proportionnelle à la longueur de la requête.
Une fois le préremplissage terminé, le moteur émet la réponse jeton par jeton. Chaque nouveau jeton relit les tenseurs K et V de tous les jetons précédents, calcule son attention et écrit ses propres tenseurs K et V en mémoire pour l'étape suivante. Cette seconde phase est le décodage. Elle est séquentielle et limitée par la bande passante mémoire, car la génération de chaque jeton nécessite le chargement en mémoire des tenseurs K et V mis en cache pour tous les jetons précédents et le calcul de l'attention sur ces tenseurs avant d'écrire les tenseurs K et V du nouveau jeton pour les étapes suivantes.
Les tenseurs K et V des deux phases constituent le cache KV. Sans ce cache, la génération du jeton n+1 impliquerait de recalculer les clés et les valeurs des n jetons précédents à chaque étape, ce qui représente une complexité quadratique. Grâce au cache, chaque nouveau jeton calcule uniquement ses propres tenseurs K et V et lit le reste en mémoire, de sorte que le coût par jeton reste linéaire.
À quoi ressemble le trafic agentique
On décrit souvent l'inférence comme étant limitée par la bande passante mémoire, car le décodage prédomine dans la partie visible de la réponse pour l'utilisateur. L'équilibre réel entre les deux phases dépend de la charge de travail. Une courte requête demandant un long texte sollicite fortement le décodage ; une longue requête interactive demandant une petite modification JSON sollicite fortement le préremplissage. La phase dominante détermine ce qui est mis à rude épreuve en cas de mauvaise gestion du cache.
La forme du problème de recalcul découle de cet équilibre, et le terme « agentique » recouvre un large éventail de modèles d'utilisation. La programmation agentique est actuellement l'un des modèles les plus populaires et représente une part importante des jetons utilisés dans les classements OpenRouter . Pour quantifier un cas représentatif, nous avons instrumenté Claude Code avec la journalisation OpenTelemetry (OTEL) et exporté une semaine de traces vers Grafana. La répartition de ce trafic de jetons par type est présentée ci-dessous. Remarque : cette utilisation de Claude Code se fait sur le modèle Claude Opus 4.8 avec une longueur de contexte de 1 million de mots, et plusieurs projets de programmation sont exécutés simultanément.
Les lectures du cache ont représenté 98.16 % du trafic total de jetons. La création de cache (un préfixe déjà vu étant prérempli suite à l'expiration de son entrée) a représenté 1.52 %. Les jetons de sortie ont représenté 0.30 %. Les jetons d'entrée réellement froids ont représenté 0.02 %.
Dans une charge de travail où 98 % du trafic est constitué de lectures de cache, l'éviction sans déchargement implique le préremplissage de la majeure partie du travail que le système s'apprêtait à effectuer. Le goulot d'étranglement se déplace de la bande passante de décodage, phase généralement optimisée, vers le calcul de préremplissage, déjà réalisé par le GPU lors d'itérations précédentes. De fait, il est fréquent d'observer, dans les architectures de service désagrégées, un plus grand nombre de processus de préremplissage que de processus de décodage à grande échelle, pour la même raison : le préremplissage constitue la phase de contrôle.
Le chiffre de 98 % représente le trafic d'un seul utilisateur. Une charge de travail de chat courte générerait davantage de trafic froid. Il en serait de même pour un système de récupération augmentée qui réinjecte différents documents à chaque échange. Cette tendance générale se vérifie lorsque les conversations sont longues, les préfixes stables et que les utilisateurs reviennent régulièrement au même contexte.
Où se trouve la cache et que se passe-t-il lorsqu'elle est pleine ?
Où se trouve concrètement ce cache, et que se passe-t-il lorsqu'il est plein ? Une fois les poids du modèle chargés, la VRAM restante est convertie en espace de cache KV, partitionné en blocs de taille fixe. Au démarrage, le moteur indique le nombre de jetons qu'il peut contenir. Ce pool est le seul emplacement possible pour le cache dans une configuration standard sans déchargement KV.
Les serveurs GPU sont coûteux et les jetons constituent le produit, l'objectif est donc de les alimenter en continu. Cela implique de maintenir le GPU chargé avec une petite file d'attente de requêtes à traiter afin d'éviter l'inactivité des ressources de calcul, tout en équilibrant cette file pour que la latence de réponse reste conforme aux objectifs de niveau de service (SLO). Toutes les requêtes n'utilisent pas la totalité de leur fenêtre de contexte ; de nombreuses paires clé-valeur (KV) terminées restent donc en cache dans la VRAM. Cependant, en cas de charge soutenue, ce cache se remplit et, une fois saturé, les entrées les plus anciennes sont supprimées pour libérer de l'espace.
Dans un monde idéal, chaque réponse serait traitée en une seule fois. Mais les modèles ne sont pas encore assez performants ; nous utilisons donc des boucles inter-agents, avec des échanges avec un utilisateur ou entre agents. À l'arrivée du tour suivant, si son identifiant clé-valeur n'est pas encore en cache, le moteur retraite l'intégralité de la conversation, y compris les nouveaux jetons. Le contexte de chaque tour précédent est à nouveau traité par le modèle, et le calcul déjà effectué par le GPU sur ces jetons est payé une deuxième, une troisième fois, et ainsi de suite, pour chaque tour suivant. Cette partie du processus représente un gaspillage de ressources.
Quels changements apporte le déchargement du cache KV ?
Au lieu d'évincer les données dès que la VRAM est pleine, le déchargement répartit progressivement les caches selon une hiérarchie : de la VRAM à la mémoire système, puis au SSD. Les données fréquemment utilisées restent en VRAM ; celles qui ne tiennent plus sont transférées vers la mémoire système, et si celle-ci est pleine, elles sont à leur tour transférées vers le SSD ou un stockage réseau. L'éviction réelle des données devient rare, car elle est pilotée par une durée de vie (TTL) définie par l'utilisateur plutôt que par la pression sur la mémoire.
Au tour suivant, au lieu de recalculer des dizaines de milliers de jetons de contexte, nous récupérons la paire clé-valeur depuis la RAM ou le stockage flash. Le rechargement depuis la mémoire système induit une légère latence, mais est bien plus rapide et économique que de recalculer le préremplissage. Le rechargement depuis un SSD NVMe est un peu plus lent qu'une lecture en DRAM, mais reste beaucoup plus rapide que le recalcul qu'il remplace. La capacité de stockage est relativement peu coûteuse ; la puissance de calcul du GPU, en revanche, ne l'est pas. Par conséquent, accepter une légère latence de rechargement en début de tour pour éviter un recalcul de plusieurs secondes est globalement avantageux.
Comment nous avons testé
Nous avons testé cette hypothèse dans notre laboratoire. La configuration du système était la suivante :
- Serveur : Dell PowerEdge XE7740
- GPU : 4x NVIDIA RTX PRO 6000 Blackwell Server Edition (96 Go)
- Mémoire système : 1 To DDR5 (16 x 64 Go DDR5 5200 MT/s)
- Stockage : 8 disques Solidigm PS1030 12.8 To E3.S (RAID 10)
- Pile de serveurs : vLLM 0.22.0 avec LMCache 0.5.0
- Modèle : MiniMax-M2.7
La plateforme de test est parfaitement adaptée à cette charge de travail. Le serveur Dell PowerEdge XE7740 est conçu spécifiquement pour l'inférence IA en entreprise. Ce châssis PCIe Gen5 prend en charge jusqu'à huit GPU double largeur. La configuration à quatre GPU que nous avons testée est l'une des plus populaires. Elle offre une capacité d'accélération suffisante pour un large éventail de déploiements d'inférence, tout en permettant une extension à huit GPU en fonction de la demande. Chaque carte NVIDIA RTX PRO 6000 Blackwell Server Edition dispose de 96 Go de mémoire GDDR7 ; ainsi, quatre cartes constituent un important pool de VRAM avant même que le cache ne soit sollicité. En interne, la couche de déchargement repose sur huit disques Solidigm D7-PS1030 de 12.8 To en RAID 10. Ces disques flash haute endurance Gen5 sont parfaitement adaptés aux écritures soutenues générées par une couche de cache KV. Enfin, le choix du modèle, MiniMax-M2.7, était, au moment du test, l'un des meilleurs modèles de codage ouverts qui s'intégraient à notre configuration à quatre GPU.
Nous avons testé trois configurations :
- Une configuration VRAM de base, vLLM standard sans déchargement, où tout ce qui tient dans la VRAM est mis en cache, et tout le reste est expulsé.
- Déchargement de LMCache vers la mémoire système, avec 512 Go alloués au déchargement.
- Déchargement LMCache vers la mémoire flash, avec la matrice RAID10 NVMe locale comme niveau de déchargement, précédée d'une mémoire tampon de transit de 64 Go de RAM.
Nous avons modélisé la charge de travail en nous basant sur le trafic réel de codage agentiel plutôt que sur un balayage de préfixes synthétiques fixes. Ce trafic est caractérisé par une préremplissage important et un décodage minimal, avec une réutilisation intensive des préfixes. Les sessions arrivent selon un processus de Poisson à un taux de λ = 2.5 sessions par minute. Chaque session s'exécute sur plusieurs tours. À chaque tour, le modèle reçoit un court ajout, généralement le résultat d'un outil ou d'une commande de 250 à 600 jetons, et occasionnellement la lecture d'un fichier de 1 500 à 3 500 jetons. Il répond par une brève réponse, généralement de 40 à 200 jetons d'appels d'outils ou un bref raisonnement, et occasionnellement un bloc de code de 400 à 900 jetons. La longueur des tours est variable de ±100 jetons. Les sessions croissent de manière monotone jusqu'à un plafond de contexte de 64 000 jetons, ce qui les place dans le régime de contexte profond, où l'ensemble de travail dépasse la capacité de la VRAM. La même charge initiale alimente les trois niveaux, chacun avec un temps de préchauffage du cache de 3 minutes.
Note concernant la configuration mémoire : le XE7740 était livré avec 2 To de DDR5, une configuration haut de gamme conçue pour couvrir un large éventail de projets, et dont le prix était antérieur à la flambée des prix de la mémoire en 2026, qui a rendu cette quantité de DRAM beaucoup plus coûteuse. La configuration d'origine était surdimensionnée par rapport aux besoins actuels d'une entreprise équipée de quatre GPU. Afin de la rendre plus réaliste, nous avons retiré 1 To de mémoire, en conservant une barrette DIMM par canal pour préserver un débit mémoire maximal.
Remarque méthodologique concernant la couche flash : les tests ont utilisé le backend disque local de LMCache avec son tampon de transit de 64 Go de RAM requis en amont de la baie. L’empreinte KV conservée sur la mémoire flash a largement dépassé la capacité totale de la DRAM hôte au cours des tests ; les résultats obtenus reflètent donc l’activité du disque plutôt que la mémoire hôte.
Performances
Débit sous charge
Débit total de service au fil du temps, à mesure que l'ensemble de travail KV dépasse la capacité de chaque niveau :
Chaque niveau de mémoire monte en charge simultanément pendant les 10 premières minutes, le temps que les caches se remplissent, sans différence notable de performances. Ensuite, à mesure que les niveaux de mémoire se remplissent, ils se séparent. Le niveau de base utilisant uniquement la VRAM stagne en premier : une fois la VRAM saturée, il se stabilise autour de 12 000 jetons par seconde. Chaque nouvelle session remplace une session précédente, et le cache déplacé doit être entièrement reconstruit au retour de cette session. Par conséquent, une plus grande partie du temps est consacrée au préremplissage et une moindre au décodage.
Les performances des serveurs DRAM et SSD continuent de dépasser largement ce seuil car, tant que leurs caches ne sont pas saturés, ils traitent la quasi-totalité des préfixes directement depuis la mémoire ou le disque, sans avoir à les recalculer. Le temps habituellement consacré au préremplissage est ainsi réinvesti dans la génération de nouveaux jetons.
En période de pointe, le déchargement a permis d'atteindre un débit de service total jusqu'à 2.9 fois supérieur à celui de la configuration de base sur la couche DRAM (+188 %) et 2.2 fois supérieur sur la couche flash (+122 %). Avant que l'ensemble de travail ne sature la VRAM, les performances des trois configurations sont très proches (à moins de 1 % près). Aucune éviction de mémoire n'a lieu, le déchargement n'a donc rien à récupérer. Le gain n'apparaît que lorsque la pression sur la mémoire entraîne une éviction, et il augmente avec la charge du serveur.
L'intérêt d'une couche de stockage plus importante se manifeste lorsque la mémoire DRAM est saturée. À cette charge, le cache RAM de 512 Go atteint sa saturation après environ 45 minutes d'exécution, et doit alors commencer à vider le cache. Les préfixes renvoyés sont incomplets et rechargés, soit précisément le recalcul que le cache était censé éviter. La couche SSD, avec sa marge de plusieurs téraoctets, n'atteint jamais cette limite. Au-delà de ce seuil, la mémoire flash maintient un débit d'environ 30 000 jetons par seconde, contre environ 17 000 pour la DRAM, soit un avantage de 75 % pour le SSD une fois la RAM saturée. Autrement dit, après saturation, la couche DRAM n'a fourni que 42 % de son débit maximal, tandis que la couche SSD en a fourni 94 %. Voici l'échelle de capacité sur laquelle repose tout l'exercice : la VRAM s'épuise en premier, le niveau de DRAM de 512 Go s'épuise plus tard, et un niveau de stockage mesuré en téraoctets plutôt qu'en gigaoctets ne s'épuise pratiquement jamais, il continue donc à fournir du contexte longtemps après que les niveaux plus rapides aient dû commencer à le supprimer.
Attention : le débit total indiqué (plusieurs dizaines de milliers de jetons par seconde) ne correspond pas à la vitesse de calcul des jetons par les GPU, mais plutôt au débit de traitement du niveau de déchargement. Le débit total comptabilise chaque jeton de préremplissage en entrée et chaque jeton de décodage en sortie de chaque requête. Grâce au cache, une requête réussie recharge la paire clé-valeur (KV) du préfixe depuis la mémoire DRAM ou flash, évitant ainsi un nouveau préremplissage sur le GPU.
Limiter le comptage aux jetons de sortie, soit la partie du débit sur laquelle un utilisateur attend réellement, donne une image plus claire :
Concernant les jetons de sortie, les trois niveaux suivent à nouveau la même tendance pendant le remplissage des caches, puis se séparent au point de basculement. Le niveau DRAM atteint un pic proche de 300 jetons par seconde, soit une augmentation de 75 % par rapport à la valeur de référence, avant de diminuer progressivement à mesure qu'il commence à vider les caches ; le niveau flash se maintient aux alentours de 250 jetons par seconde jusqu'à la fin de l'exécution, soit une augmentation de 46 % par rapport à la valeur de référence. Les performances des niveaux RAM et SSD restent globalement similaires (à environ 10 % près) jusqu'à saturation du niveau DRAM ; ensuite, l'écart se creuse.
Latence du premier jeton : ce que l’utilisateur attend
Le débit mesure la production totale de jetons. Le délai d'obtention du premier jeton mesure ce qu'un utilisateur constate : l'attente entre le moment où il clique sur « Envoyer » et celui où il reçoit le premier jeton. Nous le représentons graphiquement au cours de l'exécution, à sa médiane, à mesure que l'ensemble de travail augmente et que chaque niveau se remplit.
Tant que les caches sont actifs, les trois niveaux renvoient un premier jeton en une demi-seconde environ. Ensuite, leurs performances divergent, suivant l'évolution de leur débit. Le niveau de base est le premier à s'effondrer : son temps de réponse dépasse les 10 secondes dès le début de l'exécution, tandis que le niveau DRAM reste sous la barre de 1 seconde (TTFT) beaucoup plus longtemps, jusqu'à ce que ses 512 Go soient saturés aux alentours de la 45e minute. Sa latence chute alors brutalement lorsqu'il commence à vider et à recalculer les données. Le niveau SSD se dégrade le plus progressivement et affiche le temps de réponse le plus court des trois sur la seconde moitié de l'exécution.
Ce renversement de situation illustre parfaitement le débat sur la hiérarchisation. La DRAM est la plus rapide tant que l'ensemble de travail correspond à sa catégorie ; la mémoire flash devient la plus rapide lorsqu'elle n'y correspond plus, car elle conserve des informations contextuelles que la DRAM a commencé à supprimer.
Le problème du retour des utilisateurs
Les latences indiquées ci-dessus concernent les échanges au sein d'une session continue. Le cas d'un utilisateur qui reprend sa session est différent : une session s'interrompt en pleine conversation, reste inactive pendant environ quinze minutes, puis reprend là où elle s'était arrêtée. Nous l'avons modélisé avec un groupe d'utilisateurs qui sont devenus inactifs après une vingtaine d'échanges et ont été réactivés 15 minutes plus tard, un laps de temps suffisant pour qu'un serveur occupé traite d'autres requêtes via ses caches. Onze de ces réactivations ont eu lieu dans la fenêtre de mesure de chaque niveau. La charge de travail étant identique pour tous les niveaux, ce sont les mêmes onze sessions qui ont été réactivées à chaque exécution, permettant une comparaison directe des temps de reprise. Le graphique ci-dessous représente le temps médian d'émission du premier jeton pour chaque niveau lors d'un échange normal, comparé au temps de reprise. La barre d'erreur indique le temps de reprise le plus long de l'échantillon.
En moyenne, les chiffres confirment les prédictions des mécanismes, et les niveaux se classent dans l'ordre attendu. La DRAM arrive en tête : une session inactive reprend en 0.6 seconde, à peine plus que les 0.5 seconde d'une session normale. Le SSD se classe deuxième avec 0.8 seconde ; on sait qu'une lecture NVMe est plus lente qu'une lecture DRAM, et cela se reflète en partie dans ces résultats. La configuration de référence utilisant uniquement la VRAM est la plus lente avec 1.4 seconde ; faute de données à décharger, le préfixe de la session inactive a été supprimé de la mémoire GPU pour le trafic actif, et la première reprise doit le recalculer. Au mieux, l'écart total n'est que d'environ une seconde.
Le meilleur scénario n'est pas celui où le choix est fait. Le pire des onze temps de rechargement à chaque niveau est le suivant : 0.8 seconde sur DRAM, 3.2 secondes sur SSD et 13.9 secondes sur la configuration de référence. La tolérance d'une attente de quatorze secondes pour un premier jeton, ou son impact sur le niveau de service (SLO), dépend du service. Pour toute interaction, c'est la seconde option qui prévaut, et seuls les niveaux de déchargement maintiennent ce temps d'attente dans une limite acceptable pour l'utilisateur. Ce délai varie également selon le contexte, car le coût de recalcul est proportionnel à l'historique de l'utilisateur : dans les contextes plus approfondis du test de débit, le temps d'attente de référence dépasse largement 14 secondes, tandis que la DRAM et le SSD n'entraînent qu'un rechargement limité.
Choix et dimensionnement du cache KV
Les deux niveaux de déchargement surpassent largement le modèle de référence utilisant uniquement la VRAM, et leurs performances sont très proches. L'écart est faible car le gain de débit provient uniquement de la libération de VRAM, et la même quantité est libérée que le cache expulsé soit stocké en DRAM ou sur SSD. Le débit est indépendant du niveau de stockage d'origine du cache. La latence, en revanche, est sensible, car une lecture en DRAM est plus rapide qu'une lecture sur NVMe, mais les deux options restent peu coûteuses comparées au recalcul complet de la même paire clé-valeur.
Le choix entre les deux solutions repose sur un compromis entre le niveau de service (SLO) et le coût, qui dépend des optimisations de l'opérateur. Conserver l'intégralité du cache déchargé en RAM offre la meilleure latence, mais représente un investissement important pour un gain de latence relativement faible par rapport à la mémoire flash. La hiérarchisation constitue un compromis : une couche RAM plus petite absorbe les accès critiques en termes de latence, tandis qu'une couche de stockage supplémentaire héberge les caches moins sollicités, dont le temps de réponse n'est pas critique (quelques centaines de millisecondes).
On peut également considérer les caches clé-valeur en fonction de leur taille. Le dimensionnement du niveau de stockage dépend du débit maximal de jetons que le système peut supporter. L'espace de stockage nécessaire pour les caches clé-valeur correspond au débit multiplié par la durée de vie (TTL) des entrées du cache. Chaque jeton produit crée une entrée dans la clé-valeur ; le calcul se résume donc à multiplier le taux d'arrivée des jetons par leur durée de conservation. Les deux valeurs TTL par défaut en production sont de cinq minutes et d'une heure.
Calculons la taille du cache KV pour MiniMax-M2.7 en FP8, tel que testé ici. Avec un octet par élément KV, l'entrée par jeton est de 2 × 62 × 8 × 128 octets, soit environ 124 Kio. Ce calcul se généralise à tout transformateur d'attention par requêtes groupées : la taille du cache KV par jeton est égale au nombre de couches × le nombre de têtes KV × la dimension des têtes × 2 (pour K et V) × le nombre d'octets du type de données. Ainsi, un modèle avec plus de couches ou de têtes KV écrit proportionnellement plus d'informations par jeton. Dans les conditions de fonctionnement modérées (environ 4 200 jetons par seconde sur la couche RAM), une heure de rétention génère environ 15 millions de jetons en cache, ce qui, à 124 Kio par jeton, représente environ 1.8 To. Cela représente une quantité importante de DRAM et augmente le coût de compilation.
Dans cette optique, les exigences de SLO et le budget déterminent le choix du niveau de cache. Si le SLO est suffisamment souple pour que la latence de rechargement du niveau SSD reste inférieure, le second niveau de cache KV peut reposer uniquement sur le stockage, avec seulement la fine mémoire tampon RAM requise par les connecteurs en amont. Le coût du stockage est modeste : lors de nos tests, le trafic KV maximal a atteint 4.1 Go/s en écriture et 1.1 Go/s en lecture, pour un débit maximal mesuré par fio d'environ 114 Go/s. La matrice RAID 10 utilisée disposait d'une bande passante 28 fois supérieure, ce qui garantit que le stockage flash ne constitue pas un goulot d'étranglement, même lorsque le XE7740 exploite pleinement ses huit GPU et supporte une charge simultanée plus importante. Cette marge de manœuvre permet à l'opérateur de privilégier la capacité plutôt que la vitesse. Chaque téraoctet ajouté de D7-PS1030 étend la durée de vie (TTL) et l'ensemble de travail que le système conserve en résidence, et un cache résident plus grand signifie plus de recalculs évités et plus de jetons servis.
L'endurance est la contrainte qui définit ce niveau. Un cache de déchargement KV est très gourmand en écriture : chaque jeton produit par le modèle crée une entrée KV, et la mise à jour du TTL entraîne une réécriture continue du cache, de sorte que les disques sont constamment sollicités en écriture. Sur notre baie de huit disques, le débit d'écriture soutenu a atteint 1.9 Go/s. Avec la configuration RAID 10 que nous avons testée, la mise en miroir double la capacité absorbée par le support, ce qui correspond à environ 3.2 écritures par jour sur chaque disque de 12.8 To, légèrement au-dessus du débit soutenu de 3 écritures par jour (DWPD) du D7-PS1030. Pour un stockage principal, ce débit serait rédhibitoire, mais il est acceptable dans ce cas précis. Le cache est conçu pour être éphémère, et le mode de défaillance d'un disque usé est le recalcul, et non la perte de données. Le RAID 0 est sans doute plus adapté à ce niveau pour certains utilisateurs, car il répartit les données sur les huit disques afin d'éviter les écritures en double et réduit le débit du support à environ 1.6 DWPD, ce qui reste largement dans les limites autorisées. Dans les deux cas, la conclusion reste la même : cette charge de travail consomme l’endurance plus rapidement que tout autre élément du système, les disques haute endurance dédiés ne possèdent qu’une fraction de la capacité nécessaire à ce niveau de performance, et c’est cette combinaison qui fait d’un disque haute capacité axé sur l’écriture comme le PS1030 le choix idéal.
Jetons par dollar
La section consacrée aux performances a démontré que la mémoire flash conserve la majeure partie du débit et maintient la latence du premier jeton, contrairement à la DRAM, lorsque l'ensemble de travail dépasse la capacité de la mémoire. D'un point de vue commercial, le coût de la couche de stockage est un facteur déterminant. La solution la plus simple pour le recalcul consiste à augmenter le coût de cette DRAM onéreuse ; l'argument du déchargement n'est valable que si la couche de stockage est sensiblement moins chère par unité de capacité.
L'écart le plus évident réside dans la capacité, et non dans le prix. La couche de déchargement DRAM de 512 Go est celle qui s'est saturée et a commencé à vider le cache ; la couche flash, mesurée en téraoctets, est celle qui ne l'a pas fait. Aucun budget DRAM réaliste ne permet d'intégrer des dizaines de téraoctets de cache KV à proximité des GPU. Par conséquent, au-delà d'une certaine longueur de contexte, le choix ne se résume plus à opter pour une DRAM rapide ou une mémoire flash ; il s'agit plutôt d'un choix entre une mémoire flash et la suppression du contexte, cette suppression étant la principale cause de la perte de débit et de la latence.
En matière de prix, la mémoire flash d'entreprise est depuis longtemps vendue à une fraction du coût par téraoctet de la DRAM, un écart structurel qui découle de la conception multiniveaux et à cellules empilées en 3D de la NAND, contrairement à la conception à un transistor et un condensateur de la DRAM. La pénurie de mémoire prévue pour 2026 a fait grimper les deux prix de manière significative, et les prix contractuels de la NAND ont augmenté au moins aussi vite que ceux de la DRAM tout au long de l'année. Il ne s'agit donc pas d'une baisse de prix de la mémoire flash liée à la flambée du prix de la DRAM. Même aux niveaux actuels, l'écart de prix par téraoctet persiste, et la mémoire flash reste la seule solution offrant une capacité de cache à l'échelle du téraoctet à un coût compatible avec un budget de déploiement.
Le débit et le coût convergent. Au moment où la mémoire flash a pris l'avantage, elle traitait plus de jetons par seconde que la mémoire DRAM, et non moins. Elle ne sacrifie donc pas le débit au profit de la capacité, mais offre une capacité accrue sur un support moins coûteux par téraoctet. En termes de jetons par seconde et par dollar, l'avantage est considérable pour la mémoire flash, et il s'accroît avec la durée de conservation des données, car c'est précisément là que la DRAM atteint ses limites, contrairement à la mémoire flash.
La DRAM reste la mémoire la plus appropriée tant que l'ensemble de travail la prend en charge, et la fine mémoire tampon de transit RAM requise par les connecteurs se situe toujours en amont de la mémoire flash. Cependant, l'ajout de GPU ou de DRAM supplémentaires représente le coût le plus élevé par téraoctet pour obtenir les performances maximales uniquement nécessaires à la charge de travail, jusqu'à saturation du cache. Le déchargement ou la hiérarchisation vers la mémoire flash permet de conserver la majeure partie de ces performances tout en maintenant le contexte indéfiniment, à un coût par téraoctet abordable. La décision finale dépendra toutefois des exigences de niveau de service (SLO) de la charge de travail que l'opérateur optimise.
Conclusion
Pour les charges de travail d'inférence, la tokenomics est au cœur du débat. Le token est le produit, et le recalcul est un gaspillage : le GPU a déjà généré ce contexte et est contraint de le reconstruire. Le service agentique est le domaine où les enjeux sont les plus importants, car notre semaine de trafic instrumenté Claude Code a montré que 98.16 % des tokens étaient des lectures de cache, un contexte que le GPU avait déjà calculé et qu'il aurait autrement reconstruit à chaque éviction. Le déchargement du cache KV transforme le calcul de pré-remplissage, qui aurait servi à reconstruire cet historique, en nouveaux tokens. Sur le XE7740, cela s'est traduit par un débit de service total jusqu'à 2.9 fois supérieur à celui de la configuration de base utilisant uniquement la VRAM, sous forte charge, avec le modèle, les GPU et le moteur constants. Là où la mémoire DRAM était saturée et ramenait ses performances, la mémoire flash a maintenu ce débit avec une capacité que la DRAM ne peut égaler.
Cela ne remet cependant pas en cause le besoin de DRAM. Pour les charges de travail courtes et irrégulières, où une session s'ouvre, s'exécute brièvement et se ferme avant que son cache ne sature la mémoire, la DRAM est la solution optimale, et le déchargement du cache KV n'apporte que peu d'avantages. L'ensemble de travail est adapté, la latence est minimale et il n'y a rien à supprimer.
Nous considérons toutefois ce profil comme l'exception, où une couche DRAM suffit. La plupart des inférences en production s'exécutent désormais en continu et sur de longues périodes : agents multi-tours, contextes volumineux, concurrence stable, utilisateurs qui rejoignent la même session. Dans ce cas, l'ensemble de travail dépasse la capacité de la couche mémoire qu'un opérateur peut allouer, le cache est vidé et le GPU est remis à contribution pour reconstruire le contexte qu'il a déjà produit. Il s'agit du mode de défaillance le plus coûteux, et il est fréquent.
Pour ces charges de travail, le déchargement du cache KV vers la mémoire flash présente un double avantage. Il permet aux GPU de produire de nouveaux jetons au lieu de recalculer les anciens, ce qui correspond à l'efficacité de la tokenomics mesurée par cette opération. De plus, il place la capacité nécessaire sur le niveau de mémoire durable le plus rentable du système. L'avantage principal sur la configuration d'un serveur réside dans la réduction de la consommation de DRAM : un serveur utilisant la mémoire flash pour le cache peut être spécifié avec beaucoup moins de DRAM. Compte tenu du prix de la mémoire en 2026, il s'agit là d'une des économies les plus importantes du devis. Le jeton est le produit, et pour les charges de travail à contexte long qui dominent aujourd'hui le service de serveurs, la solution la plus efficace en termes de jetons est celle qui évite de payer pour produire deux fois les mêmes jetons ; cette solution passe par la mémoire flash.
Stockage SSD Solidigm pour l'IA
Ce rapport est sponsorisé par Solidigm. Tous les points de vue et opinions exprimés dans ce rapport sont basés sur notre vision impartiale du ou des produits à l'étude.
Amazon