आपका training run CUDA out of memory error के साथ क्रैश हो जाता है। बताइए आप क्या क्या जांचेंगे।

मेमोरी खाने वालों को क्रम से देखिए: batch size और sequence length, backward pass के लिए रखी गई activations, optimizer state, और बदलते shapes से आया fragmentation। जल्दी वाले इलाज हैं छोटा batch और effective batch बचाने के लिए gradient accumulation, gradient checkpointing, bf16, और मेमोरी के लिहाज से किफायती optimizer। यह भी जांचिए कि आप ऐसे tensors तो जमा नहीं कर रहे जो अब भी computation graph ढो रहे हैं।

सबसे पहले मैं देखता हूं कि वह तुरंत मरता है या कुछ सौ steps के बाद, क्योंकि ये अलग बग हैं। तुरंत मरना क्षमता की समस्या है, बढ़ता जाना लीक है। क्षमता के लिए मैं तोड़कर देखता हूं कि असल में क्या टिका हुआ है: weights, gradients, optimizer state (Adam के साथ वह दो अतिरिक्त copies हैं), और backward pass के लिए सहेजी गई activations। transformer पर आम तौर पर activations हावी होती हैं, और वे batch size गुणा sequence length के हिसाब से बढ़ती हैं, तो पहले वही knobs हैं। मैं batch घटाता हूं और effective batch वही रखने के लिए gradient accumulation इस्तेमाल करता हूं, जिसकी कीमत wall clock में है, और कुछ नहीं। फिर gradient checkpointing, जो backward के दौरान activations दोबारा निकालता है और मोटे तौर पर तीस प्रतिशत ज्यादा compute देकर बड़ी मेमोरी बचत लेता है। उस पर bf16 activation का आकार आधा कर देता है। अगर वह steps के साथ बढ़ता है तो कोई चीज graph पकड़े हुए है। क्लासिक है logging के लिए कच्चा loss tensor किसी list में जोड़ना, जो हर step का computation graph जिंदा रखता है, और इलाज है उस पर item बुलाना। मैं हर सौ steps पर allocated और reserved memory प्रिंट करके पुष्टि करता हूं, क्योंकि ऊपर चढ़ती साफ सीढ़ी ही पहचान है।