Mistral AI इंजीनियर्स ने BPFtrace का उपयोग करके vLLM में मेमोरी लीक का असली कारण खोजा

MistralMistral
Mistral AI के इंजीनियर्स ने Mistral Medium 3.1 के साथ अलग-थलग (disaggregated) सर्विंग के दौरान vLLM में मेमोरी लीक की जांच की। Python टूल्स, Heaptrack और BPFtrace का उपयोग करने के बाद, उन्होंने पाया कि लीक glibc के syscall रैपर के माध्यम से डायरेक्ट mmap कॉल के कारण हुआ था, न कि हीप आवंटन के कारण।
Mistral AI की टीम ने अपने फ्रंटियर मॉडल Mistral Medium 3.1 के साथ विघटित (disaggregated) सर्विंग के प्री-प्रोडक्शन परीक्षण के दौरान vLLM में एक संदिग्ध मेमोरी लीक की जांच की। यह लीक विशिष्ट परिस्थितियों में सिस्टम मेमोरी में प्रति मिनट 400 MB की स्थिर वृद्धि के रूप में प्रकट हुआ: vLLM, Mistral Medium 3.1, और ग्राफ कंपाइलेशन सक्षम होने पर, केवल NIXL का उपयोग करके Prefill/Decode विघटित सेटअप के decode पक्ष पर। Memray और Guppy 3 जैसे प्रारंभिक Python टूल ने कोई लीक नहीं दिखाया, और Heaptrack ने केवल पीक RSS में विसंगति का खुलासा किया। /proc/<pid>/maps की निगरानी के लिए pmap का उपयोग करके, उन्होंने बदलते पतों के साथ बढ़ते अनाम मेमोरी मैपिंग देखे, जो mremap या बार-बार mmap/munmap चक्रों की विशेषता है। सटीक कारण का पता लगाने के लिए, उन्होंने सिस्टम कॉल को ट्रेस करने के लिए BPFtrace का उपयोग किया, जिससे पता चला कि आवंटन glibc के syscall रैपर (syscall+29) के माध्यम से प्रत्यक्ष mmap कॉल के ज़रिए किए गए थे। इससे पता चला कि लीक हीप प्रबंधन के बाहर था, जिसकी पहचान के लिए निम्न-स्तरीय ट्रेसिंग की आवश्यकता थी।
स्रोत: Mistral AI — मूल
इस विषय पर हमारी पिछली पोस्ट ↓
ताज़ा समाचार