एलएचएस लागत मॉडल

संक्षेप में;

इस पेज पर, Latency Hiding Scheduler के इस्तेमाल किए गए लागत मॉडल के बारे में बताया गया है. अगर आपको मॉडल को ट्यून करने में दिलचस्पी है, तो सीधे ट्यूनिंग सेक्शन पर जाएं.

लेटेंसी छिपाने वाला शेड्यूलर (एलएचएस), कंपाइलर पास होता है. यह एचएलओ डीएजी को इस तरह से शेड्यूल करता है कि वॉल टाइम कम से कम हो.

इसके फ़ैसले, यूनीफ़ाइड कॉस्ट मॉडल के आधार पर लिए जाते हैं. यह मॉडल, परफ़ॉर्मेंस टेबल और विश्लेषण मॉडल का इस्तेमाल करता है. खास तौर पर, XLA, GEMM और फ़ास्ट-इंटरकनेक्ट कलेक्टिव के लिए परफ़ॉर्मेंस टेबल एम्बेड करता है. साथ ही, अन्य मामलों के लिए ऐनलिटिकल नेटवर्किंग और फ़्यूज़न कॉस्ट मॉडल का इस्तेमाल करता है. दस्तावेज़ के बाकी हिस्से में, इन सुविधाओं के काम करने के तरीके के बारे में बताया गया है.

परफ़ॉर्मेंस टेबल – आईसीआई कलेक्टिव

परफ़ॉर्मेंस टेबल में दो मुख्य कॉम्पोनेंट होते हैं: कलेक्टर और इंटरपोलेटर.

कलेक्टर

कलेक्टर, C++ की मदद से बनाया गया एक टूल है. यह कलेक्टिव ऑपरेशन के लिए परफ़ॉर्मेंस टेबल जनरेट करता है. यह अलग-अलग एचएलओ ऑप्स की परफ़ॉर्मेंस को मेज़र करता है. जैसे, all-gather, all-reduce) को स्टैटिक तौर पर तय किए गए पैरामीटर स्पेस में लागू किया जा सकता है.

यह कैसे काम करता है

यह टूल, किसी क्लस्टर के लिए सामूहिक कार्रवाइयों, ट्रांसफ़र के साइज़, और ट्रांसफ़र की स्कीम की रेंज पर स्वीप करता है. यह जनरेट किए गए एचएलओ को चलाने और परफ़ॉर्मेंस मेट्रिक इकट्ठा करने के लिए, मौजूदा मल्टी-होस्ट एचएलओ रनर इंफ़्रास्ट्रक्चर और ExecutionProfile डेटा का इस्तेमाल करता है.

डेटा कलेक्शन पैरामीटर

लेटेंसी टेबल, इन पैरामीटर के क्रॉस-प्रॉडक्ट के लिए इकट्ठा की जाती हैं:

  • कलेक्शन का टाइप:
    • all-reduce
    • all-gather
    • reduce-scatter
  • ट्रांसफ़र का साइज़:
    • लॉगरिद्मिक स्केल, 1024 बाइट से लेकर 2 जीबी तक (उदाहरण के लिए, 1024B, 2048B, 4096B, ...)
  • ट्रांसफ़र स्कीम:
    • rail-aligned
    • non-rail-aligned

यह स्वीप, एक ही नोड वाले उन क्लस्टर के लिए चलाया जाता है जिनमें 2, 4, और 8 डिवाइस होते हैं.

आउटपुट

कलेक्शन रन का नतीजा, .pbtxt फ़ॉर्मैट में एक लेटेन्सी टेबल होती है. हर प्लैटफ़ॉर्म के लिए, इसका साइज़ करीब 116 केबी होता है.

इंटरपोलेटर

इंटरपोलेटर, कंपाइलर का वह कॉम्पोनेंट होता है जो जनरेट की गई परफ़ॉर्मेंस टेबल का इस्तेमाल करता है. इससे कंपाइलेशन के दौरान, रनटाइम के अनुमान मिलते हैं.

इंटरनल डेटा स्ट्रक्चर

शुरुआत में, इंटरपोलेटर, परफ़ॉर्मेंस टेबल को मैप में प्रोसेस करता है. इस मैप में, (collective_type, transfer_scheme) के टपल को कुंजी के तौर पर इस्तेमाल किया जाता है.

हर कुंजी से जुड़ी वैल्यू, 2D यूक्लिडियन प्लेन होती है. यह प्लेन, दो ऐक्सिस के आधार पर नेटवर्क थ्रूपुट (कलेक्टर के ज़रिए मेज़र किया गया) को इंडेक्स करता है:

  1. ट्रांसफ़र का साइज़.
  2. इसमें शामिल डिवाइसों की संख्या.

लुकअप और इंटरपोलेशन

जब कंपाइलर को कोई सामूहिक कार्रवाई मिलती है, तो इंटरपोलेटर यह तरीका अपनाता है:

  1. यह मैप की के तौर पर ऑपरेशन के (collective_type, transfer_scheme) का इस्तेमाल करके, सही 2D थ्रूपुट प्लेन की पहचान करता है.
  2. इसके बाद, यह उस 2D प्लेन में वेटेड एवरेज रिट्रीवल (यूक्लिडियन दूरी के आधार पर) का इस्तेमाल करता है. इसमें ऑपरेशन के (transfer_size, num_devices) को क्वेरी पॉइंट के तौर पर इस्तेमाल किया जाता है.
  3. इस लुकअप का नतीजा, एक यूनीक नेटवर्क थ्रूपुट वैल्यू होती है.

वजह: थ्रूपुट और एक्सट्रैपलेशन

इस सिस्टम को, रॉ लेटेंसी के बजाय नेटवर्क थ्रूपुट को सेव करने के लिए डिज़ाइन किया गया है. इस डिज़ाइन की मदद से, टेबल में मौजूद नहीं होने वाले ट्रांसफ़र साइज़ के लिए परफ़ॉर्मेंस का अनुमान लगाना आसान हो जाता है.

अगर लेटेंसी टेबल, नेटवर्क बैंडविड्थ के S साइज़ पर सैचुरेट होने की जानकारी देती हैं, तो उस समय थ्रूपुट T को ज़्यादा से ज़्यादा माना जाता है. S' > S साइज़ के किसी भी नए ग्रुप के लिए, रनटाइम का अनुमान इस तरह लगाया जा सकता है:

\[\text{EstimatedTime}(S') = \frac{S'}{T_{\text{saturated} } }\]

इससे मॉडल, किसी भी साइज़ के कलेक्शन के लिए परफ़ॉर्मेंस का अनुमान लगा सकता है. भले ही, वह Collector की ओर से मेज़र किए गए 2GiB के ज़्यादा से ज़्यादा साइज़ से बड़ा हो.

  • ज़्यादा से ज़्यादा थ्रूपुट का अनुमान कम लगाना.
  • इसलिए, बड़े ट्रांसफ़र के लिए रनटाइम का अनुमान ज़्यादा लगाएं.

आम तौर पर, XLA:GPU टीमें परफ़ॉर्मेंस टेबल मैनेज करती हैं. हालांकि, अगर उपयोगकर्ता खुद टेबल उपलब्ध कराने का फ़ैसला करता है, तो टेबल जनरेट करने वाले उपयोगकर्ता की यह ज़िम्मेदारी है कि वह यह पक्का करे कि टेबल में सही जानकारी दी गई हो. साथ ही, टारगेट किए गए हार्डवेयर के लिए, बैंडविड्थ-सैचुरेटेड क्षेत्र में मेज़रमेंट शामिल किए गए हों.

परफ़ॉर्मेंस टेबल – GEMM

कलेक्टिव के सिस्टम की तरह ही, GEMM की लेटेन्सी टेबल को दो कॉम्पोनेंट इस्तेमाल करते हैं: कलेक्टर और इंटरपोलेटर.

कलेक्टर

कलेक्टर एक C++ टूल है. यह सामान्य मैट्रिक्स मल्टिप्लिकेशन (GEMM) के लिए परफ़ॉर्मेंस टेबल बनाता है. यह HLO dot op लेवल पर मैट्रिक्स मल्टिप्लिकेशन की परफ़ॉर्मेंस को मेज़र करता है.

यह कैसे काम करता है

यह टूल, GEMM डाइमेंशन (बैच, दो नॉन-कॉन्ट्रैक्टिंग, और एक कॉन्ट्रैक्टिंग डाइमेंशन) और डेटा टाइप के स्टैटिक स्पेस पर स्वीप करता है.

  • डिफ़ॉल्ट डेटा टाइप: LHS = bf16,f32, RHS = bf16,f32, OUT = bf16,f32.
  • इन्फ़्रास्ट्रक्चर: यह HLO op profiler का फिर से इस्तेमाल करता है.

कलेक्शन पैरामीटर

लेटेंसी टेबल, इन डाइमेंशन के क्रॉस-प्रॉडक्ट के लिए इकट्ठा की जाती हैं:

  • batch: {1, 2, 4}
  • m (बिना अनुबंध वाला): {256, 512, ..., 4096}
  • n (बिना अनुबंध वाला): {256, 512, ..., 4096}
  • k (छोटा करना): {256, 512, ..., 4096}

आउटपुट और स्टोरेज

पूरे स्वीप से .pbtxt लेटेंसी टेबल जनरेट होती है. इसका इस्तेमाल इंटरपोलेटर कर सकता है.

इंटरपोलेटर

इंटरपोलेटर, कंपाइलर का वह कॉम्पोनेंट है जो जनरेट की गई टेबल का इस्तेमाल करके, GEMM की परफ़ॉर्मेंस का अनुमान लगाता है.

वजह: फ़्लॉप्स सैचुरेशन

इकट्ठी की गई लेटेंसी टेबल की मदद से इंटरपोलेटर, हर एंट्री के लिए FLOPS को फिर से बना सकता है:

\[\text{FLOPS} = \frac{2 \times b \times m \times n \times k}{\text{runtime} }\]

एक अहम जानकारी यह है कि फ़्लॉप, एक तय पॉइंट पर सैट्यूरेट हो जाते हैं. इसका मतलब है कि हार्डवेयर, किसी तय मैट्रिक्स शेप के बाद पीक फ़्लॉप तक पहुंच जाता है. इस सैचुरेशन की वजह से, अनुमान लगाने के उसी तरीके का इस्तेमाल किया जा सकता है जिसका इस्तेमाल कलेक्टिव के लिए किया जाता है.

लुकअप और इंटरपोलेशन

इंटरपोलेटर, टेबल के डेटा से 4D यूक्लिडियन स्पेस बनाता है. परफ़ॉर्मेंस का अनुमान लगाने के लिए, यह 4D स्पेस में वेटेड-ऐवरेज इंटरपोलेशन करता है. अगर किसी डेटा टाइप के लिए कोई टेबल नहीं है, तो अनुमान के तौर पर हर डाइमेंशन को बाइट की संख्या के हिसाब से सामान्य किया जाता है.

एनालिटिकल कॉस्ट मॉडल - डीसीएन

एस-कर्व कलेक्टिव कॉस्ट मॉडल

एस-कर्व मॉडल, पूरी तरह से विश्लेषण करने वाला नेटवर्किंग रूफ़लाइन मॉडल है.

खास जानकारी

इस मॉडल को, नेटवर्क की तय की गई प्रॉपर्टी के आधार पर, सामूहिक कार्रवाइयों की परफ़ॉर्मेंस का अनुमान लगाने के लिए डिज़ाइन किया गया है.

मॉडल के इनपुट

मॉडल को दो कैटगरी के इनपुट की ज़रूरत होती है:

  1. फ़िक्स्ड नेटवर्क प्रॉपर्टी (उपयोगकर्ता के तय किए गए):

    • कलेक्शन लॉन्च करने का ओवरहेड
    • एनआईसी की स्पीड
    • आरटीटी (राउंड ट्रिप टाइम)

    डिफ़ॉल्ट रूप से, XLA किसी प्लैटफ़ॉर्म का अपने-आप पता लगाता है. साथ ही, सबसे सामान्य आर्किटेक्चर के लिए वैल्यू का इस्तेमाल करता है. उपयोगकर्ता इन प्रॉपर्टी को कॉन्फ़िगर कर सकता है. ज़्यादा जानकारी के लिए, ट्यूनिंग सेक्शन देखें.

  2. हर कलेक्टिव के लिए इनपुट:

    • कलेक्शन का टाइप (जैसे, AllGather, ReduceScatter)
    • ट्रांसफ़र का साइज़
    • कम्यूनिकेशन में शामिल नोड की संख्या

इंटिग्रेशन

एस-कर्व मॉडल को XLA:GPU में इंटिग्रेट किया गया है. इसका इस्तेमाल Hopper और Blackwell पर किया जा रहा है.

विश्लेषणात्मक लागत मॉडल - फ़्यूज़न

अन्य कर्नल के लिए, हम GPU परफ़ॉर्मेंस कॉस्ट मॉडल का इस्तेमाल करते हैं, ताकि सही रनटाइम का अनुमान लगाया जा सके. इसके बारे में ज़्यादा जानने के लिए, यहां क्लिक करें.

ट्यूनिंग

सही XLA फ़्लैग जारी करके, S-curve मॉडल को ट्यून किया जा सकता है. ज़्यादातर मामलों में, डिफ़ॉल्ट कॉन्फ़िगरेशन काफ़ी अच्छा होता है. हालांकि, अन्य मामलों में मॉडल कंट्रोल को दिखाया जाता है.

export NIC_SPEED_GBPS=... # NIC speed per GPU in Gigabytes
export GPUS_PER_NODE=... # Num of GPUs per cluster interconnected with fast network (e.g. NVLINK)
export XLA_FLAGS=--xla_gpu_analytical_latency_estimator_options="nic_speed_gbps=$NIC_SPEED_GBPS,gpus_per_node=$GPUS_PER_NODE"