-sdy-close-shardings
टेंसर को अलग-अलग हिस्सों में बांटने की प्रोसेस बंद कर देता है और डुप्लीकेट किए गए ऐक्सिस हटा देता है.
-sdy-constant-merger
एक जैसे कॉन्सटेंट को, मैच करने वाली शर्डिंग के साथ मर्ज करें.
एक जैसी शार्डिंग वाले कॉन्स्टेंट पर, लाइटवाइट सीएसई करता है.
इंपोर्ट पाइपलाइन, कॉन्स्टेंट को अलग-अलग हिस्सों में बांटती है और उनकी डुप्लीकेट कॉपी बनाती है, ताकि किसी कॉन्स्टेंट सब-कंप्यूटेशन के अलग-अलग इस्तेमाल के बीच, शार्डिंग का प्रॉपेगेशन न हो. अगर प्रोपेगेशन के बाद, कॉन्स्टेंट की एक ही तरह की शर्डिंग होती है, तो कंपाइल करने में लगने वाले समय को बचाने के लिए, यह पास उन्हें मर्ज कर देता है.
-sdy-drop-sharding-rules
रजिस्टर किए गए सभी ऑपरेशन से OpShardingRuleAttr
हटा देता है.
-sdy-insert-explicit-reshards
सभी ऑपरेशन के लिए काम करने वाली shardings बनाने के लिए, साफ़ तौर पर reshards डालता है.
काम करने वाली शर्डिंग का मतलब है कि ऑपरेशन, शर्ड किए गए ऑपरेंड को स्वीकार कर सकता है और फिर से शर्ड करने की ज़रूरत के बिना, शर्ड किया गया नतीजा दे सकता है. ध्यान दें कि ऑपरेशन के लिए, अब भी कम्यूनिकेशन की ज़रूरत पड़ सकती है, जैसे कि all-reduce या halo-swaps.
प्रॉपेगेशन के बाद भी, हो सकता है कि कुछ ऑपरेशन में काम न करने वाली शार्डिंग मौजूद हों.
ध्यान दें कि जब किसी ऐक्सिस (या सब-ऐक्सिस) का इस्तेमाल, एक से ज़्यादा टेंसर में एक-दूसरे से मेल न खाने वाले डाइमेंशन (जैसे, matmul फ़ंक्शन में नॉन-कंट्रैक्टिंग डाइमेंशन) को अलग-अलग हिस्सों में बांटने के लिए किया जाता है या जब कोई ऐक्सिस, एक टेंसर में डाइमेंशन को अलग-अलग हिस्सों में बांटता है, लेकिन दूसरे टेंसर में उससे मिलते-जुलते डाइमेंशन को नहीं बांटता है, तो कहा जाता है कि ऑपरेशन में, डाइमेंशन को अलग-अलग हिस्सों में बांटने से जुड़ी समस्या है. इसलिए, इस पास के बाद, ऑपरेशन बिना किसी रुकावट के किए जा सकते हैं.
यह पास, फिर से शर्ड करने वाले ऑपरेशन को साफ़ तौर पर इंजेक्ट करता है, ताकि हर ऑपरेशन के लिए, सभी ऑपरेंड और नतीजों में मिलते-जुलते डाइमेंशन एक ही तरह से शर्ड हो जाएं. साथ ही, हर ऐक्सिस (या सब-ऐक्सिस) का इस्तेमाल सिर्फ़ एक डाइमेंशन टाइप को शर्ड करने के लिए किया जा सकता है.
उदाहरण:
इनपुट:
mesh = <"x"=4, "y"=2>
%lhs : tensor<8x32xf32> {sdy.sharding=<@mesh, \[{"x"}, {"y"}\]>}
%rhs : tensor<32x16xf32> {sdy.sharding=<@mesh, \[{"y"}, {"x"}\]>}
stablehlo.dot %lhs, %rhs {sdy.sharding_per_value=<[<@mesh, \[{"x"}, {}\]>]>}
: (tensor<8x32xf32>, tensor<32x16xf32>) -> tensor<8x16xf32>
आउटपुट:
sdy.mesh = <"x"=4, "y"=2>
%lhs : tensor<8x32xf32> {sdy.sharding=<@mesh, \[{"x"}, {"y"}\]>}
%rhs : tensor<32x16xf32> {sdy.sharding=<@mesh, \[{"y"}, {"x"}\]>}
%0 = sdy.reshard %rhs <@mesh, \[{"y"}, {}\]> : tensor<32x16xf32>
stablehlo.dot %lhs, %0 {sdy.sharding_per_value=<[<@mesh, \[{"x"}, {}\]>]>}
: (tensor<8x32xf32>, tensor<32x16xf32>) -> tensor<8x16xf32>
ऊपर दिए गए उदाहरण में, lhs
और rhs
, दोनों को अक्ष "x" पर, अपने ऐसे डाइमेंशन के लिए शर्ड किया गया है जो कॉन्ट्रैक्ट नहीं करते. यह काम नहीं करता. पास, बिंदु वाले ऑपरेशन से पहले rhs
पर एक साफ़ तौर पर रीशर्ड डालता है, ताकि बिंदु वाले ऑपरेशन में काम करने वाली shardings हो.
-sdy-remove-sharding-groups
प्रोपगेशन के बाद, ShardingGroupOps को हटा देता है.
-sdy-reshard-to-collectives
ReshardOp को अलग-अलग Shardy कलेटिव ऑपरेशन में बदलता है.
यह reshard ऑपरेशन से मैच करता है और उन्हें अलग-अलग Shardy कलेटिव ऑपरेशन में फिर से लिखता है. इस पास के बाद, मॉड्यूल में कोई भी रीशर्ड ऑपरेशन नहीं रहता. इस पास में यह माना जाता है कि साफ़ तौर पर रेशार्ड किए गए डेटा को पहले ही डाला जा चुका है (sdy-insert-explicit-reshards
).
उदाहरण:
इनपुट:
mesh = <"x"=2, "y"=2, "z"=2>
%0 : tensor<16x2xf32> {sdy.sharding<@mesh, \[{"x", "y", "z"}, {}\]>
%1 = sdy.reshard %arg0 <@mesh, \[{"x"}, {}\]> : tensor<16x2xf32>
आउटपुट:
mesh = <"x"=2, "y"=2, "z"=2>
%0 : tensor<16x2xf32> {sdy.sharding<@mesh, \[{"x", "y", "z"}, {}\]>
%1 = sdy.all_gather \[{"y", "z"}, {}\] %arg0 out_sharding=<@mesh, \[{"x"}, {}\]> : tensor<16x2xf32>
ऊपर दिए गए उदाहरण में, टेंसर %0 : tensor<16x2xf32>
को \[{"x", "y", "z"}, {}\]
के तौर पर शेयर किया गया है. इसके बाद, reshard
ऑपरेशन में इसे \[{"x"}, {}\]
के तौर पर फिर से शेयर किया जाता है. पहले ऐक्सिस पर, रीशर्ड करने के बाद सफ़िक्स {"y", "z"}
हटा दिया जाता है. इससे हमें पता चलता है कि हमारे पास {"y", "z"}
का पूरा डेटा है. दूसरा डाइमेंशन नहीं बदला जाता.
-sdy-sharding-constraint-to-reshard
ShardingConstraintOp को ReshardOp में बदलता है.
-sdy-sink-data-flow-edges
सभी DataFlowEdgeOp
को अपने इनपुट में सिंक करता है.
हर DataFlowEdgeOp
की शर्डिंग को उसके इनपुट (एज के रूट टारगेट) पर ले जाता है और ऑपरेशन को उसके इनपुट से बदल देता है.
विकल्प
-sink-debug-sharding-origins : Whether to sink the debug sharding origins info. See `debug-sharding-origins` option in propagation for more info.
-sink-debug-propagation-edge-sharding : Whether to sink the debug propagation edge sharding info. See `debug-propagation-edge-sharding` option in propagation for more info.
-sdy-temp-explicit-reshards-for-optimizations
खास ऑप्टिमाइज़ेशन के लिए, साफ़ तौर पर रीशर्ड डालता है.
यह पास, तब तक के लिए है, जब तक हम डिफ़ॉल्ट रूप से sdy-insert-explicit-reshards
पास को चालू नहीं कर देते.
इससे, हमें ऑप्टिमाइज़ेशन के लिए, चुनिंदा ऑपरेशन पर साफ़ तौर पर रीशर्ड डालने की अनुमति मिलती है.
-sdy-update-non-divisible-input-output-shardings
इससे FuncOp के इनपुट/आउटपुट को बराबर हिस्सों में बांटा जाता है. साथ ही, बंटने लायक शर्डिंग की वजह से पैडिंग की ज़रूरत नहीं होती.
Shardy के उपयोगकर्ताओं को उम्मीद है कि फ़ंक्शन के इनपुट/आउटपुट को बराबर हिस्सों में बांटा जा सकता है/शर्ड किया जा सकता है, ताकि उन्हें अपने टेंसर को पैड करने की ज़रूरत न पड़े. प्रॉपेगेशन की वजह से, इनपुट/आउटपुट में ऐसे शर्ड हो सकते हैं जिन्हें बंटाया नहीं जा सकता. इसलिए, यह पास उन्हें ओरिजनल शर्डिंग के सबसे बड़े डाइमेंशन शर्डिंग प्रीफ़िक्स में अपडेट करता है, जो बराबर हिस्सों में बंट जाता है.