कैटगरी: CompileTime: SparseCore No Viable Logical Replica Count
यह गड़बड़ी तब होती है, जब XLA:SparseCore कंपाइलर, लॉजिकल रेप्लिका की संख्या के ऐसे मान्य कॉन्फ़िगरेशन का पता नहीं लगा पाता है जिससे वर्कलोड को SparseCore की लोकल स्क्रैचपैड मेमोरी (Tilespmem) में फ़िट किया जा सके.
गड़बड़ी के मैसेज के उदाहरण:
XLA:TPU compile permanent error. Compilation failure: No viable logical replica count for the embedding table with metadata: max_nz_per_row = 141352, max_unique_nz_per_row = 8, feature_width = 8, sample_count = 204800 (last tried split factor for vector splitting = 1, last tried split factor for sample dimension splitting = 1, fixed_size_allocation_bytes = 410880, row_dependent_size_allocation_bytes = 1696224, total_spmem_size_bytes = 524288) ...
XLA बैकएंड: टीपीयू
खास जानकारी
यह गड़बड़ी, SparseCore के इस्तेमाल के उदाहरणों से जुड़ी है. खास तौर पर, लार्ज एम्बेडिंग मॉडल (एलईएम) के लिए.
लॉजिकल रेप्लिका की संख्या, कंपाइलर का एक इंटरनल पैरामीटर है. इससे यह तय होता है कि स्क्रैचपैड के लिए मेमोरी के बंटवारे को मैनेज करने के लिए, इनपुट बैच को कैसे बांटा जाता है. कंपाइलर, वर्कलोड को छोटे-छोटे हिस्सों (रेप्लिका) में बांटने की कोशिश करता है, ताकि हर हिस्से के लिए ज़रूरी इंटरमीडिएट बफ़र, SparseCore की सीमित स्क्रैचपैड मेमोरी में फ़िट हो सकें. आम तौर पर, लॉजिकल रेप्लिका की संख्या ज़्यादा होने पर, एक बार में डेटा के छोटे-छोटे बैच प्रोसेस किए जाते हैं. इससे, डेटा को मेमोरी में सेव करने का दबाव कम हो जाता है.
इस गड़बड़ी से पता चलता है कि अलग-अलग स्प्लिटिंग कॉन्फ़िगरेशन आज़माने के बाद भी, कंपाइलर को ऐसा सेटअप नहीं मिला जहां ज़रूरी बफ़र, Tilespmem मेमोरी में फ़िट हो सकें. बजट का साइज़ इन बातों के आधार पर तय किया जाता है:
sample_count: हर SparseCore को असाइन किए गए एम्बेडिंग लुकअप आईडी की संख्या. यह संख्या, बैच साइज़ से तय होती है.feature_width: एम्बेडिंग डाइमेंशन का साइज़.max_nz_per_row: सभी SparseCore में, एम्बेड किए गए ऐसे लुकअप आईडी की ज़्यादा से ज़्यादा संख्या जो यूनीक नहीं हैं.max_unique_nz_per_row: यूनीक एम्बेडिंग लुकअप आईडी की ज़्यादा से ज़्यादा संख्या.
डीबग करना
इस गड़बड़ी को ठीक करने के लिए, आपको SparseCore scratchpad पर मेमोरी का इस्तेमाल कम करना होगा.
1. मेटाडेटा के अनुमानों को बेहतर बनाना
कंपाइलर, max_nz_per_row और max_unique_nz_per_row के आधार पर मेमोरी असाइन करता है. अगर इन वैल्यू का अनुमान कम करके लगाया जाता है (यानी कि असल डेटा की ज़रूरत से बहुत ज़्यादा सेट किया जाता है), तो कंपाइलर ज़रूरत से ज़्यादा स्पेस रिज़र्व कर लेगा. इससे यह गड़बड़ी होगी. पक्का करें कि ये पैरामीटर, आपके डेटासेट के आईडी डिस्ट्रिब्यूशन को सही तरीके से दिखाते हों.
इन पैरामीटर के लिए सबसे सही वैल्यू तय करने के लिए, फ़ीडबैक के आधार पर ऑप्टिमाइज़ेशन (एफ़डीओ) लागू किया जा सकता है.
2. बैच का साइज़ कम करना
sample_count की वैल्यू, सीधे तौर पर आपके ग्लोबल बैच साइज़ से तय होती है. बैच का साइज़ कम करने से, हर SparseCore को हर चरण में प्रोसेस किए जाने वाले डेटा की मात्रा कम हो जाती है. इससे, ज़रूरी स्क्रैचपैड बफ़र का साइज़ कम हो जाता है.