Des ingénieurs de Mistral AI découvrent la véritable cause d'une fuite mémoire dans vLLM grâce à BPFtrace
Mistral
Des ingénieurs de Mistral AI ont enquêté sur une fuite mémoire dans vLLM lors d'un service désagrégé avec Mistral Medium 3.1. Après avoir utilisé des outils Python, Heaptrack et BPFtrace, ils ont découvert que la fuite était causée par des appels mmap directs via la fonction d'encapsulation d'appels système de glibc, et non par des allocations de tas.
L'équipe de Mistral AI a enquêté sur une fuite mémoire suspectée dans vLLM lors de tests de préproduction d'une configuration de service dissocié avec leur modèle de pointe Mistral Medium 3.1. La fuite se manifestait par une augmentation régulière de 400 Mo par minute de la mémoire système dans des conditions spécifiques : avec vLLM, Mistral Medium 3.1 et la compilation de graphe activée, uniquement du côté du décodage de la configuration dissociée Préremplissage/Décodage utilisant NIXL. Les outils Python initiaux comme Memray et Guppy 3 n'ont montré aucune fuite, et Heaptrack n'a révélé qu'un écart dans le RSS de pointe. En utilisant pmap pour surveiller /proc/<pid>/maps, ils ont observé des mappings mémoire anonymes croissants avec des adresses changeantes, caractéristiques de mremap ou de cycles répétés de mmap/munmap. Pour identifier la cause précise, ils ont utilisé BPFtrace pour tracer les appels système, révélant que les allocations étaient effectuées via des appels directs à mmap à travers le wrapper d'appel système de glibc (syscall+29). Cela a montré que la fuite se situait en dehors de la gestion du tas, nécessitant un traçage de bas niveau pour l'identifier.
Source: Mistral AI —
original
