गड़बड़ी का कोड: E3000

कैटगरी: कंपाइल करने में लगने वाला समय: SparseCore Allocation Failure

यह गड़बड़ी तब होती है, जब XLA:SparseCore कंपाइलर, मौजूदा SparseCore प्रोग्राम के लिए ज़रूरी मेमोरी स्पेस में मेमोरी का लगातार ब्लॉक असाइन नहीं कर पाता.

गड़बड़ी के मैसेज के उदाहरण:

INTERNAL:Failed to run pass pipeline. Hlo-Op: result.1:279:1: error: 'memref.alloca' op current allocation offset upper bound (140704 words) exceeds the legitimate user allocatable offset upper bound (131071 words) in memory space 201 when allocating 23440 words. result.1:279:1: note: see current operation: %232 = "memref.alloca"() <{operandSegmentSizes = array<i32: 0, 0>}> : () -> memref<23440xf32, 201>

XLA बैकएंड: टीपीयू

खास जानकारी

SparseCore (एससी), स्पार्स वर्कलोड के लिए खास प्रोसेसर है. यह डेटा को बेहतर तरीके से मैनेज करने के लिए, मेमोरी के खास क्रम पर निर्भर करता है. XLA कंपाइलर, हार्डवेयर की सीमाओं और उपयोगकर्ता के तय किए गए साइज़ के आधार पर, बफ़र का साइज़ तय करने और उन्हें स्टैटिक तौर पर असाइन करने की कोशिश करता है. इस गड़बड़ी से पता चलता है कि मेमोरी के इस हिस्से को असाइन करते समय, आउट ऑफ़ मेमोरी (ओओएम) की समस्या हुई है.

गड़बड़ी के मैसेज में आम तौर पर मेमोरी स्पेस का आईडी दिया जाता है. यहां मेमोरी स्पेस और उनके पूर्णांक एन्कोडिंग दिए गए हैं:

एससी और इसकी मेमोरी के क्रम के बारे में ज़्यादा जानने के लिए, SparseCore का दस्तावेज़ देखें.

डीबग करना

समस्या हल करने का तरीका इस बात पर निर्भर करता है कि मेमोरी के किस हिस्से में जगह नहीं है.

पहली स्थिति. एचबीएम मेमोरी का बंटवारा नहीं हो सका (मेमोरी स्पेस आईडी: 203)

यह गड़बड़ी तब होती है, जब SparseCore प्रोग्राम की ओर से अनुरोध किया गया कोई एक अस्थायी असाइनमेंट, उपलब्ध एचबीएम में फ़िट होने के लिए बहुत बड़ा होता है. स्टैंडर्ड एम्बेडिंग वर्कलोड और एससी ऑफ़लोड किए गए कलेक्टिव में, हर कोर के लिए बहुत बड़े पार्टीशन या गलत शार्डिंग स्पेसिफ़िकेशन की वजह से, कंपाइलर को बड़े बफ़र का अनुरोध करना पड़ सकता है.

सुझाई गई कार्रवाइयां:

• शार्डिंग की जांच करें: पक्का करें कि आपकी एम्बेडिंग टेबल और एससी इनपुट/आउटपुट टेंसर सही तरीके से बांटे गए/शार्ड किए गए हों. अगर कोई एक कोर बहुत ज़्यादा डेटा के लिए ज़िम्मेदार है, तो हो सकता है कि डेटा को सही तरीके से बांटा न जा सके.
• सीमाओं में बदलाव करना: max_ids_per_partition और max_unique_ids_per_partition की समीक्षा करें. अगर इन्हें ज़रूरत से ज़्यादा सेट किया जाता है, तो कंपाइलर, ज़रूरत से ज़्यादा मेमोरी रिज़र्व कर लेता है. सीमाएं, टेबल में कैसे दिखती हैं लेख पढ़ें.

परिदृश्य 2. डिवाइस के स्टोरेज में गड़बड़ियां (मेमोरी स्पेस आईडी: 0, 201, 202, 204)

Smem, TileSpmem, Spmem या सिंक फ़्लैग में मेमोरी असाइन करने में गड़बड़ियां आम तौर पर कंपाइलर की गड़बड़ियों या मेमोरी असाइन करने की रणनीति की सीमाओं की वजह से होती हैं. इनमें कंपाइलर, मेमोरी की सभी ज़रूरी शर्तों को पूरा नहीं कर पाता.

सुझाई गई कार्रवाइयां:

1. XLA ऑपरेशन में गड़बड़ी की वजह का पता लगाएं: गड़बड़ी की वजह बनने वाले खास एससी एचएलओ या मोज़ेक कर्नल की पहचान करने के लिए, इंटरमीडिएट कंपाइलर के रिप्रज़ेंटेशन जनरेट करें:
   • Dump SparseCore MLIR: फ़्लैग --xla_sc_dump_mlir_to=/path/to/dump को सेट करें. इससे SparseCore प्रोग्राम का एमएलआईआर जनरेट होता है. इससे आपको यह पता चलता है कि गड़बड़ी के मैसेज से कौनसा असाइनमेंट साइज़ मेल खाता है.
   • Dump Mosaic LLO: कस्टम कर्नल के लिए, --xla_mosaic_dump_to=/path/to/dump का इस्तेमाल करके, Mosaic से जनरेट किए गए सभी Low Level Optimizer (LLO) प्रोग्राम की जांच करें.
2. स्क्रैच साइज़ कम करें (Pallas के उपयोगकर्ताओं के लिए): अगर Mosaic कर्नल में गड़बड़ी होती है, तो अपने scratch_shapes कॉन्फ़िगरेशन की समीक्षा करें. पक्का करें कि आपके pltpu.SMEM अनुरोध, टीपीयू की खास जनरेशन के लिए हार्डवेयर की खास बातों के मुताबिक हों.
3. कलेक्टिव ऑफ़लोडिंग की सुविधा बंद करें: अगर यह गड़बड़ी, एससी ऑफ़लोड किए गए कलेक्टिव ऑपरेशन की वजह से आ रही है, तो एससी ऑफ़लोडिंग की सुविधाएं बंद करके देखें:
   • --xla_tpu_enable_sparse_core_collective_offload_all_gather=false
   • --xla_tpu_enable_sparse_core_collective_offload_all_reduce=false
4. बग की शिकायत करें: अगर ऊपर दिए गए चरणों से समस्या हल नहीं होती है, तो हो सकता है कि यह कंपाइलर से जुड़ा बग हो. कृपया गड़बड़ी की रिपोर्ट दर्ज करें.