Le contexte réutilisé des sessions IA peut peser sur la mémoire GPU

En termes simples

La recherche

Ce que montrent les preuves

• La mémoire mobilisée par les sessions

  Cette étude opérationnelle des systèmes cherche à déterminer comment les systèmes de service doivent gérer l’état du cache clé-valeur (KV) conservé entre les appels d’une session. Les appels suivants peuvent réutiliser les calculs effectués à partir du contexte précédent, mais garder cet état en mémoire GPU mobilise de la capacité pendant l’inactivité d’une session.

  Les auteurs analysent quatre charges de travail Microsoft M365 en production et relisent leurs séquences d’appels pour étudier la pression sur la mémoire et l’état local à chaque déploiement.

• Estimer l’ampleur de la mémoire

  Les estimations en octets reposent sur la configuration publique du cache KV de Llama-2-70B, car celle des modèles en production est confidentielle. Selon cette hypothèse, l’état KV estimé d’une session Deep Research au 99e centile atteint 81,6 Gio, davantage que les 80 Go de mémoire d’un GPU H100.

  Dans une estimation distincte, conserver l’état maximal de chaque session Research admissible pendant toute sa durée de vie observée donne un plafond de 501,8 To pour l’ensemble du parc. Ces chiffres ne concernent que le cache KV estimé, pas l’allocation réelle des GPU.

• Tester une limite d’inactivité

  Les auteurs relisent ensuite l’intégralité de la trace Research admissible en appliquant une limite d’inactivité : après une heure sans activité, l’état KV de taille maximale d’une session est évacué. L’occupation maximale estimée pour l’ensemble du parc passe de 501,8 To à 140,8 To, tandis que la part des appels nécessitant une reconstruction passe de 4,07 % à 4,53 %.

  Ces pourcentages portent sur les appels de cette trace. La comparaison indique que conserver l’état maximal pendant de longues périodes d’inactivité gonfle l’estimation où tout reste en mémoire, alors que la hausse des reconstructions dans cette relecture reste modeste avec ce réglage.

• Des copies récupérables réduisent les reconstructions

  Une autre relecture teste des règles de gestion mémoire sur les 176 007 appels de l’heure la plus chargée de Research, répartis entre 9 486 sessions, avec un budget commun de 4,7 To. Les appels nécessitant une reconstruction représentent 62,9 % sous la règle LRU, qui évacue l’état utilisé le moins récemment, et 31,1 % sous FNU, qui évacue celui dont le prochain accès est le plus éloigné en s’appuyant sur une connaissance du futur.

  Conserver l’état évacué sous forme d’une copie int4 plus compacte ramène ce taux à 13,6 %. Comme MRR évacue dans le même ordre que LRU, son avantage par rapport à LRU montre l’effet de garder une copie compacte et récupérable au lieu de détruire l’état.

  Son avantage sur FNU avec ce budget vient du fait qu’elle peut faire tenir davantage d’état, et non de sa connaissance du futur ; avec le budget le plus serré testé, FNU affiche un taux de reconstruction inférieur. Ce résultat vaut pour cette relecture et ce budget ; il ne tient compte ni de la qualité des réponses ni du coût de restauration des copies.

• Le placement crée un seuil distinct

  Enfin, une relecture avec mémoire illimitée modifie la façon d’identifier les objets du cache. Lorsque l’état reste local à un déploiement, identifier les objets par la session et le déploiement fait passer la proportion minimale de reconstructions au premier accès de 5,4 % à 20,2 % des appels pendant la même heure de Research.

  Les auteurs interprètent ce résultat comme un problème de placement distinct de la pression sur la mémoire : une capacité accrue ne peut pas éliminer les reconstructions dues à l’indisponibilité de l’état sur un autre déploiement.