समाचारं

한어Русский языкEnglishFrançaisIndonesianSanskrit日本語DeutschPortuguêsΕλληνικάespañolItalianoSuomalainenLatina

imbue.com इत्यस्मात् चयनितम्

लेखकः इम्बुए टीम

मशीन हृदय संकलन

सम्पादक: पाण्डा

वयं जानीमः यत् एलएलएम विशाल-आँकडानां उपयोगेन बृहत्-स्तरीय-सङ्गणक-समूहेषु प्रशिक्षितः अस्ति मशीन-हर्ट्-इत्यनेन एलएलएम-प्रशिक्षण-प्रक्रियायाः सहायतायै, उन्नयनार्थं च बहवः पद्धतयः प्रौद्योगिकीश्च प्रवर्तन्ते । अद्य वयं यत् साझां कर्तुम् इच्छामः तत् एकः लेखः अस्ति यः अन्तर्निहितप्रौद्योगिक्याः गभीरं गत्वा एलएलएम-प्रशिक्षणार्थं प्रचालनतन्त्रमपि विना "नग्नधातुनां" समूहं कथं सङ्गणकसमूहे परिणतुं शक्यते इति परिचययति

अयं लेखः Imbue इति एआइ स्टार्टअप इत्यस्मात् आगतः यः यन्त्राणि कथं चिन्तयन्ति इति अवगत्य सामान्यबुद्धिं प्राप्तुं प्रयतते ।

अवश्यं, एलएलएम-प्रशिक्षणार्थं प्रचालनतन्त्रं विना "नग्नधातुस्य" समूहं सङ्गणकसमूहे परिणमयितुं सुलभा प्रक्रिया नास्ति, अन्वेषणेन परीक्षणेन च त्रुटिना च परिपूर्णा, परन्तु इम्बुए अन्ततः ७० अरबमापदण्डैः सह एलएलएम सफलतया प्रशिक्षितवान् And accumulated प्रक्रियायां बहवः उपयोगिनो अनुभवाः।

अयं लेखः स्वस्य एलएलएम-प्रशिक्षण-अन्तर्निर्मित-निर्माणस्य दलस्य सम्पूर्ण-प्रक्रियायाः गहन-परिचयं प्रदास्यति, तथा च निगरानीयता, निरीक्षणं, त्रुटि-शुद्धिकरणं च सुलभं कर्तुं तेषां लिखितानि अनेकानि साधनानि लिप्याः च साझां करिष्यति

यदि भवान् स्वस्य LLM प्रशिक्षणमूलसंरचनायाः निर्माणे रुचिं लभते अथवा LLM कथं निर्मितं इति जिज्ञासुः अस्ति तर्हि अयं लेखः पठितुं संग्रहीतुं च योग्यः अस्ति।

इम्बुए दलस्य लेखस्य मूलपाठः निम्नलिखितम् अस्ति ।

आमुख

अस्माकं शोधकर्तृणां अभियंतानां च लघुदलेन अस्माकं स्वस्य आधारभूतसंरचनायां 70 अरब-पैरामीटर्-प्रतिरूपस्य प्रशिक्षणं कतिपयान् मासान् व्यतीतवान्, तथा च अनुमान-सम्बद्धेषु कार्येषु शून्य-शॉट्-माडलात् अधिकं प्रदर्शनं कृतवान्

अद्य वयं आवश्यकं आधारभूतसंरचनं स्थापयितुं प्रक्रियां साझां कुर्मः: प्रारम्भिकसमूहं एकत्र स्थापयित्वा प्रचालनतन्त्रस्य संस्थापनात् आरभ्य प्रशिक्षणकाले त्रुटयः सम्मुखीभवन्ति तदा स्वचालितपुनर्प्राप्तिस्थापनपर्यन्तं वयं प्रत्येकं पदे सम्मुखीकृतानां आव्हानानां समाधानानाञ्च विस्तरेण वदामः। एतेषां शिक्षणानाम् अतिरिक्तं वयं मार्गे विकसिताः बहवः लिप्याः अपि विमोचयिष्यामः येन अन्येषां दलानाम् स्वस्य आदर्शप्रशिक्षणार्थं स्थिरमूलसंरचनायाः निर्माणं सुलभं भवति।

सम्पूर्णे प्रक्रियायां अस्माकं अभियंतानां दलेन वोल्टेज पार्क इत्यनेन सह सङ्गणकसमूहानां निर्माणं कृत्वा उत्पादन-अनुप्रयोगानाम् आधारस्य निर्माणं कृतम् । अस्मिन् सम्पूर्णे प्रक्रियायां निम्नलिखितम् अन्तर्भवति : १.

1. प्रत्येकं यन्त्रं विन्यस्यताम्

2. InfiniBand विन्यस्तं कुर्वन्तु

3. यन्त्रं पूर्णतया स्वस्थं भवति इति सुनिश्चितं कुर्वन्तु

4. सामान्यप्रशिक्षणसमस्यानां निदानं कुर्वन्तु

5. आधारभूतसंरचनासाधनानाम् उन्नयनम्

प्रत्येकं सोपानं अधः विस्तरेण वर्णितम् अस्ति ।

पृष्ठभूमिः - कथं निर्मितम्

गणनाकरणस्य अस्माकं लक्ष्यं बृहत्भाषाप्रतिमानैः सह द्रुतप्रयोगः सुनिश्चितः भवति । एतत् कर्तुं अस्माकं बहुसंख्यायां उच्चगति-GPU-इत्येतत्, एतेषां GPU-मध्ये च उच्च-गति-सञ्चारस्य आवश्यकता वर्तते ।

अयं लेखः ५११ सङ्गणकेषु प्रसारितेषु ४०८८ H100 GPUs, अथवा प्रतिसङ्गणके ८ GPUs इति समूहे केन्द्रितः भविष्यति । GPU युक्ताः ५११ सङ्गणकाः सन्ति इति कारणं अस्ति यत् केचन संयोजनानि Unified Fabric Manager नोड् कृते आरक्षितुं आवश्यकानि सन्ति, यस्य भूमिका InfiniBand संजालस्य प्रबन्धनं भवति ५११ GPU-सज्जित-होस्ट्-मध्ये प्रत्येकं GPU प्रत्यक्षतया ConnectX-7 संजालकार्ड्-सङ्गणकेन सह सम्बद्धं भवति, यत् InfiniBand-जालपुटे कस्यापि GPU-इत्यत्र ४०० Gbps-इत्यनेन आँकडानां प्रसारणं कर्तुं शक्नोति

अस्माकं InfiniBand संजाल टोपोलॉजी "पूर्णतया अ-अवरोधनम्" अस्ति, एतेन GPUs अधिकतमवेगेन परस्परं संवादं कर्तुं शक्नुवन्ति; एतत् कर्तुं वयं त्रिस्तरीयं InfiniBand संजाल आर्किटेक्चरं उपयुञ्ज्महे: त्रिस्तरीयं InfiniBand स्विचम् । समीचीनसंयोजनैः सह सम्पूर्णे जालपुटे एतत् उच्चस्तरं थ्रूपुट् प्राप्तुं शक्यते । निम्नलिखितचित्रे अस्य InfiniBand संजालस्य अवलोकनं दृश्यते ।

ध्यानं कुर्वन्तु यत् संजालस्य प्रशिक्षणकाले संचारः InfiniBand इत्यस्य माध्यमेन भवति, न तु Ethernet इत्यस्य माध्यमेन । यद्यपि एतानि यन्त्राणि ईथरनेट् इत्यनेन सह अपि सम्बद्धानि सन्ति तथापि अस्य जालस्य भूमिका दत्तांशसमूहाः, चेकपॉइण्ट् इत्यादीनां दत्तांशस्य परिवहनं भवति । यदि भवान् आँकडानां प्रेषणार्थं Ethernet इत्यस्य उपयोगं करोति तर्हि गतिः बहु मन्दः भविष्यति यतोहि दत्तांशः प्रथमं GPU तः CPU यावत् गमिष्यति ततः 100 Gbps गति Ethernet कार्ड् मार्गेण बहिः गमिष्यति यद्यपि RDMA over Converged Ethernet (RoCE) इति प्रौद्योगिक्याः उपयोगेन ईथरनेट्-माध्यमेन प्रशिक्षणं अपि सम्भवति, तथापि तदर्थं हार्डवेयर-सॉफ्टवेयर-पक्षयोः बहु अतिरिक्तं कार्यं आवश्यकं भवति, तथा च सामान्यतया InfiniBand इत्यस्मात् न्यूनं विश्वसनीयं भवति विस्तरेण कृपया एतत् पत्रं पश्यन्तु: https://arxiv.org/pdf/2402.15627

केवलं विन्यासस्य प्रबन्धनस्य च कृते उपयुज्यमानः गौणः ईथरनेट् अपि अस्ति, यः निम्नस्तरीययन्त्र-अन्तरफलकानां कृते BIOS (Basic Input Output System), विद्युत्-आपूर्तिः, अन्येषां नियन्त्रण-अन्तरफलकानां च प्रवेशं प्रदाति एतत् प्रबन्धनजालं विना अस्माभिः प्रत्येकं नोड् USB चालकस्य, कीबोर्डस्य, मॉनिटरस्य च माध्यमेन मैन्युअल् रूपेण सेट् अप कर्तव्यं स्यात् । शतशः यन्त्राणां परिस्थितीनां कृते एषः स्थायित्वं न भवति ।

अस्मिन् समूहे उच्च-प्रदर्शन-प्रशिक्षणं प्राप्तुं प्रत्येकं घटकं (InfiniBand, Ethernet, GPU, तथा च स्वयं नोड्स) निकट-सम्पूर्णतया कार्यं कर्तुं आवश्यकम् अस्ति । यदि तेषु १२,०००+ संयोजनेषु कश्चन अपि किञ्चित् अस्थिरः अस्ति तर्हि समग्रप्रशिक्षणधावनं मन्दं कर्तुं शक्नोति ।

अस्य लेखस्य शेषभागः कथं सर्वं सम्यक् स्थिरतया च चालयितुं शक्यते इति विषये अस्ति।

प्रक्रिया : नग्नधातुः पूर्णतया कार्यरतसमूहे कथं परिणमयितुं शक्यते

प्रत्येकं यन्त्रं विन्यस्यताम्

प्रबन्धनजालद्वारा क्लस्टरस्य प्रारम्भिकं ईथरनेट्-सम्बद्धतां स्थापयित्वा बेसबोर्ड-प्रबन्धननियन्त्रकस्य (BMC) अभिगमनप्रमाणपत्राणि प्राप्यन्ते BMC एकः समर्पितः सेवासंसाधकः अस्ति यः दूरस्थरूपेण होस्ट्-प्रणालीनां निरीक्षणं करोति तथा च प्रायः पृथक् संजालेन सह सम्बद्धः भवति । एतत् अस्मान् यन्त्रं व्यक्तिगतरूपेण तत्र आसन् इव चालयितुं शक्नोति, अपि च अतिरिक्तरूपेण हार्डवेयरस्वास्थ्यस्य, BIOS सेटिंग्स्, शक्तिप्रबन्धनस्य च एपिआइ प्रदाति ।

एतेषां घटकानां स्थाने वयं अस्माकं आस्तीनं गुठयित्वा समूहस्य स्थापनां आरभुं शक्नुमः ।

Step 0: प्रथमं यन्त्रं विन्यस्यताम्

वयं iDRAC (Dell's Baseboard Management Controller) इत्यस्य उपयोगेन सर्वरे Ubuntu 22.04 संस्थापयित्वा आरब्धाः ततः अन्यत् सर्वं अस्य ऑपरेटिंग् सिस्टम् इत्यस्य आधारेण सेट् कृतवन्तः । iDRAC इत्यस्य एकः क्षमता अस्ति यत् स्थानीयसङ्गणकात् ISO चित्राणां संस्थापनं बूटिङ्ग् च अनुमन्यते तथा च ब्राउजर् मार्गेण वर्चुअल् कन्सोल् प्रदातुं शक्यते । आदर्शतः, प्रक्रियायां एतत् एकमेव हस्तस्थापनं सोपानम् अस्ति ।

Step 1: प्रत्येकस्मिन् यन्त्रे ऑपरेटिंग् सिस्टम् संस्थापयन्तु

प्रथमं यन्त्रं विन्यस्तं कृत्वा, शेषसर्वरस्य विन्यस्तीकरणे सहायतार्थं उबण्टु इत्यस्य Metal-as-a-Service (MAAS) सॉफ्टवेयरं संस्थापयितुं गच्छन्तु । iDRAC बूट् तथा स्वचालनसाधनं Preboot Execution Environment Protocol (PXE) इत्यस्य उपयोगं करोति यत् प्रत्येकं यन्त्रं संजालतः बूट् कर्तुं निर्देशं ददाति तथा च PXE बूट् अनुरोधानाम् प्रतिक्रियां दातुं MAAS विन्यस्यति प्रारम्भिकजालपुटं कुर्वन् सर्वरः स्थानीयड्राइव् मध्ये किमपि संस्थापयितुं विना Dynamic IP Allocation Protocol DHCP मार्गेण MAAS इत्यस्मात् IP तथा प्रारम्भिकं कर्नेल् प्राप्नोति पुनरावर्तनीयानां प्रचालनतन्त्रस्थापनानाम् स्वचालितीकरणाय एतत् मूलभूतं वातावरणम् अस्ति । सैद्धान्तिकरूपेण अस्माभिः केवलं प्रथमस्य बूटस्य प्रतीक्षा कर्तव्या ततः सर्वं पालितं भविष्यति । परन्तु व्यवहारे BMC सह MAAS एकीकरणं अविश्वसनीयं भवति, अतः वयं प्रत्येकस्य यन्त्रस्य MAC पता (एकः अद्वितीयः भौतिकः हार्डवेयर-परिचयः) पूर्वमेव संग्रहीतुं iDRAC API इत्यस्य उपयोगं कुर्मः ।

अस्मिन् सम्पूर्णे प्रशिक्षणप्रक्रियायां प्रायः MAAS कशेरुकस्य ढेरस्य अधिकविश्वसनीयः घटकः भवति । तथापि आरम्भे अस्माभिः केचन विषयाः सम्मुखीकृताः ये अस्माकं सेटअपस्य अद्वितीयाः आसन् । यथा, प्रथमानि कतिपयानि यन्त्राणि विन्यस्यन्ते सति HTTPS प्रमाणपत्रसत्यापनसमस्यायाः कारणात् apt मार्गेण किमपि संस्थापयितुं असमर्थः अभवम् यतः घण्टाः एतावन्तः भिन्नाः आसन् । सम्बन्धितरूपेण, यतः MAAS सर्वरः बहुधा उत्तरदायी भवितुमर्हति (DHCP सर्वरः, IPs कृते होस्ट्नामानां समाधानार्थं DNS सर्वरः, होस्ट् तथा आधिकारिक Ubuntu संकुलसर्वरस्य मध्ये HTTP प्रॉक्सी, NTP सर्वरः, cloud-init configuration management , एकः भूमिः truth database इत्यस्य उपयोगः MAC address to IP to hostname to custom metadata इत्यस्य संयोजनाय प्रयुक्तः), अतः अस्माकं कृते एतासां समस्यानां समाधानं मूलकारणात् कठिनम् अस्ति । तदतिरिक्तं, MAAS विन्यासजीवनचक्रस्य शिक्षणवक्रस्य विषयः अस्ति, यतः डिजाइनस्य लक्ष्यं ग्रीनफील्ड् परिनियोजनस्य प्रबन्धनस्य जटिलतां नियन्त्रयितुं तथा च नोड्स तथा विभिन्नानां डिबग्/अस्वस्थमध्यवर्ती अवस्थानां क्रमिकप्रवासं नियन्त्रयितुं भवति

Step 2: भग्नयन्त्रस्य निदानं कुर्वन्तु

वयं पश्यामः यत् प्रायः १०% यन्त्राणि बूट् कर्तुं असफलाः अभवन्, अधिकतया सर्वरेण सह भौतिकसमस्यानां कारणात् । बृहत् GPU क्लस्टर् स्थापनार्थं एतत् सामान्यं परिदृश्यम् अस्ति । अस्माभिः सम्मुखीकृताः परिस्थितयः सन्ति: संजालकेबलाः अनुपलब्धाः अथवा अशुद्धरूपेण संयोजिताः, iDRAC मध्ये हार्डवेयर-समस्याः, क्षतिग्रस्ताः विद्युत्-आपूर्ति-एककाः, क्षतिग्रस्ताः NVME (अवाष्पशील-स्मृति-द्रुत) चालकाः, आन्तरिक-परिपथाः गम्यन्ते, तथा च संजाल-कार्डस्य अथवा GPU-प्रदर्शने विफलता वयं स्वयमेव एतेषां समस्यानां जाँचं कृतवन्तः, पुनर्परीक्षणार्थं केचन यन्त्राणि Dell -इत्यस्मै प्रत्यागत्य, आँकडा-केन्द्र-कर्मचारिणां कृते समुचित-कार्य-आदेशान् च प्रदत्तवन्तः । स्वयं क्लस्टरस्य विन्यासस्य एकः लाभः अस्ति यत् केषुचित् यन्त्रेषु परिपालनस्य प्रतीक्षया वयं तत्क्षणमेव स्वस्थयन्त्राणां उपयोगं कर्तुं शक्नुमः ।

चरण 3: न्यूनतमं व्यवहार्यं अवलोकनीयं यन्त्रम्

वयं प्रत्येकस्मिन् सर्वरे निम्नलिखितसेटिंग्स् कृत्वा अग्रे गच्छामः ।

1.Docker (सेवाः प्रशिक्षणकार्यं च चालयितुं सुलभं कर्तुं)

2. डाटा सेण्टर GPU चालकः

3. Prometheus node export tool (स्थिर हार्डवेयर/ऑपरेटिंग सिस्टम सूचकदत्तांशप्रवाहस्य निर्यातार्थं उपयुज्यते)

4.DCGM निर्यातसाधनम् (NVIDIA GPU तः अतिरिक्तसूचकदत्तांशस्य निर्यातार्थं उपयुज्यते, यथा GPU स्थितिः, घड़ी, उपयोगः)

5. सर्वेषां गैर-सञ्चालनप्रणालीचालकानाम् कृते RAIDZ ZFS पूलः, यत् यन्त्रं चालकं विफलं भवति चेदपि कार्यं निरन्तरं कर्तुं शक्नोति, तथैव निःशुल्कं पारदर्शकं संपीडनं अपि प्रदाति (एतत् विशेषतया सादे पाठदत्तांशसमूहानां पुनरावर्तनीयानां च लॉग्स् कृते उपयोगी भवति - तुल्यकालिकरूपेण एतस्य उपयोगः tool सामान्यतया अस्य साधनस्य उपयोगं न कर्तुं तुलने उपयोगयोग्यं स्थानं १० गुणान् यावत् वर्धयति)

ततः वयं मूलभूतं GPU निदानं चालयामः यत् GPU सामान्यतया सम्यक् कार्यं करोति वा इति निर्धारयितुं शक्नुमः - यत्किमपि न भवति तत् प्रायः कतिपयेषु घण्टेषु हार्डवेयर-समस्यां जनयिष्यति

अस्मिन् काले वयं सर्वेषु ४०० नोड्-मध्ये एकत्रैव संकुलं संस्थापयितुं प्रयतमाने बैण्डविड्थ्-अटङ्कानां सामनां कृतवन्तः । अस्माकं दत्तांशकेन्द्रे नियोजितानाम् अनेकघटकानाम् उच्चतापमानस्य अतितापनसचेतनाः प्रथमवारं प्राप्ताः। एतेषां प्रथमसमूहस्य तापनसमस्यानां समाधानं बहुधा फर्मवेयर-अद्यतनद्वारा कृतम् अस्ति ।

चरण 4: एक-नोड् GPU प्रशिक्षणम्

अग्रिमः सोपानः अस्ति यत् प्रत्येकं यन्त्रं स्वयमेव वास्तविकं GPU कार्यभारं सम्भालितुं शक्नोति इति सुनिश्चितं भवति । अनेके यन्त्राणि एतत् कर्तुं असमर्थाः सन्ति, समस्याः च सन्ति-

GPU-सम्बद्धाः त्रुटयः मूलतः GPU-कार्डं कार्ड-स्लॉट्-मध्ये पुनः सम्मिलितं कृत्वा निवारयितुं शक्यन्ते: 200-पाउण्ड्-सर्वरं रैक्-तः बहिः स्लाइड् कुर्वन्तु, कवर-GPU-योः मध्ये सर्वाणि केबल्-इत्येतत् निष्कासयन्तु, GPU-इत्येतत् निष्कासयन्तु, GPU-इत्येतत् पुनः संस्थापयन्तु, ततः केबल्-पुनः संयोजयन्तु तथा सर्वरं पुनः रैक् मध्ये धक्कायन्तु।

उबण्टु सर्वर लॉग्स् इत्यस्य अनुसारं GPU तथा PCIe बस अथवा नेटवर्क् कार्ड् इत्येतयोः मध्ये बहवः केबल् इत्यनेन एषा त्रुटिः निर्गतवती: "limited width: x4 < x16" । PCIe स्विच बस फर्मवेयर अद्यतनीकरणानन्तरं वयं पश्यामः यत् प्रायः एकचतुर्थांशं होस्ट् आन्तरिक PCIe केबल् पुनः सेट् आवश्यकम् - अनुमानतः यतोहि केस तथा GPU मध्ये केबल् अत्यन्तं नाजुकाः सन्ति, अर्थात् यदा कदापि GPU मध्ये अनुरक्षणं क्रियते , एते केबल् करिष्यन्ति धक्कायन्ते वा बहिः आकृष्यन्ते वा।

तत्र कतिपयानि विविधानि विच्छेदानि आसन् येन अनेकाः गणाः अपि प्रभाविताः अभवन् । Dell अस्मान् फर्मवेयर उन्नयनेन सह केचन समस्याः समाधानं कर्तुं साहाय्यं कृतवान्:

NVMe ड्राइव् इत्यनेन कोऽपि त्रुटिः न दृश्यते स्म किन्तु स्पृष्टे सति सम्पूर्णं यन्त्रं ताडयति स्म ।

Linux इत्यस्य अन्तर्गतं हार्डड्राइव् यादृच्छिकक्रमेण दृश्यन्ते, येन MAAS इत्यस्मिन् भ्रमः भवति तथा च ऑपरेटिंग् सिस्टम् गलत् ड्राइव् इत्यत्र संस्थापनं भवति ।

तापमानपठनं गलतं भवति, येन व्यजनः सर्वदा पूर्णवेगेन चालयति । कारणं NVIDIA चालकस्य समस्या भवितुम् अर्हति, यत् चालकसंस्करणस्य अवनयनेन समाधानं भवति ।

CPU इत्यस्य गतिशीलं स्केलिंग् नियन्त्रणात् बहिः गतः, कार्यरताः कोराः २ GHz यावत् सीमिताः अभवन् ।

प्रत्यक्षं GPU-GPU संचारं (GDR अथवा GPUDirect RDMA Peer Memory Client) सफलतया प्रयोक्तुं न शक्यते ।

InfiniBand विन्यस्तं कुर्वन्तु

Step 0: UFM संस्थापयन्तु

InfiniBand इत्यस्य एकः लाभः अस्य केन्द्रीकृतः डिजाइनः अस्ति, येन सम्पूर्णे जालपुटे एकं मस्तिष्कं भवति । अतः अस्माभिः केवलं सम्पूर्णे जालसंरचने ३२० जालस्विच् इत्यस्य एकेन उदाहरणेन सह व्यवहारः करणीयः । अस्माकं प्रथमं कार्यं आसीत् यत् कः स्विचः केषां यन्त्राणां संयोजनं करोति इति चिन्तयितुं, ततः तत् तारचित्रेण सह सम्बद्धं कृत्वा स्विचस्य भौतिकस्थानस्य आधारेण तेषां नामकरणं करणीयम्

Step 1: पुनः तारकरणम्

प्रारम्भे यूएफएम तान् ३२० स्विचान् ज्ञातुं असमर्थः आसीत्, किं पुनः ये होस्ट्-पटले उपस्थिताः भवितुम् अर्हन्ति स्म । अस्माकं दत्तांशकेन्द्रसहभागिभिः सह परामर्शं कृत्वा वयं पुष्टिं कृतवन्तः यत् स्विचः चालूः तारयुक्ताः च सन्ति, परन्तु तदपि तान् ज्ञातुं असमर्थाः आसन् । नेटवर्क् केबलिंग् सूचीं परीक्षित्वा वयं अवलोकितवन्तः यत् जालसंरचनायाः शीर्षस्तरीयः डिजाइनः अशुद्धः आसीत् : एकीकृतस्य स्थाने संरचना अष्टसु विच्छिन्नजालेषु विभक्तवती यत्र सामान्यमार्गमार्गः नासीत् पुनः तारीकरणानन्तरं वयं सर्वे भौतिकसंयोजनानि नूतनविन्यासेन सह सङ्गतानि इति सत्यापयितुं एकं जाँचपदं योजितवन्तः ।

चरण 2: दशसहस्राणि तापमानस्य अलार्म (सचेतना)

भौतिकतारीकरणसमस्यानां समाधानानन्तरं इन्फिनिबैण्ड् इत्यनेन संजालवस्त्रे सर्वेषां इन्फिनिबैण्ड् स्विच्-सम्बद्धाः सफलतया संयोजनानि स्थापितानि । परन्तु प्रायः प्रत्येकं स्विच् पोर्ट् अत्यधिकं तापमानं, कदाचित् ७०°C अधिकं, ज्ञापयितुं आरब्धवान्, यद्यपि ते दत्तांशं न प्रसारयन्ति स्म । वयं आविष्कृतवन्तः यत् एषः विषयः एकस्मिन् एव रैक् मध्ये स्विच्-मध्ये मुक्तस्थानात् उद्भूतः, येन उष्णवायुः पुनः अग्रे प्रवहति स्म । अस्माकं दत्तांशकेन्द्रस्य भागीदारः अस्मान् शीघ्रमेव समस्यायाः निदानं कृत्वा समुचितं समाधानं विकसितुं साहाय्यं कृतवान् ।

चरण 3: 1800 अलार्म

अनेकेषु पोर्ट्-मध्ये अपि उच्च-दोष-दराः सन्ति, अथवा सामान्य-दूषित-स्थितीनां मध्ये आगत्य आगत्य गच्छन्ति, यत् "फ्लैपिंग" इति कथ्यते । एते विषयाः तदा एव उत्पद्यन्ते यदा बन्दरगाहानां वास्तविकरूपेण उपयोगः भवति, अतः तेषां पूर्वमेव अन्वेषणं कठिनं भवति यतोहि अस्माकं सम्पूर्णसंरचनायां १०,००० अत्यन्तं अनावश्यकलिङ्काः सन्ति अस्माकं दत्तांशकेन्द्रस्य भागीदारः अलार्मस्य पोर्ट् स्वच्छं कर्तुं पुनः संस्थापयितुं च साहाय्यं कृतवान्, प्रतिस्थापनस्य प्रतीक्षया अवशिष्टान् अलार्म-ट्रांससीवरं निष्क्रियं कृतवन्तः ।

यद्यपि InfiniBand हार्डवेयरविफलतायाः प्रति लचीला भवति तथापि एकदा प्रायः १०% वस्त्रं विफलं भवितुं आरभते तदा अनुकूलमार्गनिर्देशनानि इत्यादीनि विशेषतानि नैमित्तिकरूपेण नष्टलिङ्कस्य लेखानुरूपं विश्वसनीयतया कार्यं न कुर्वन्ति

अस्मिन् काले वयं १०० तः २०० यन्त्राणां उपयोगेन बहु-नोड्-प्रशिक्षणं सफलतया चालितवन्तः । अस्माकं प्रक्रिया किञ्चित् तात्कालिकं भवति: वयं कदाचित् नोड्स् इत्यस्य यादृच्छिकसमूहं स्पिन अप कुर्मः, तेषां कार्यक्षमतां अवलोकयामः, ततः तेषां यथासंभवं चालयितुं प्रयत्नशीलाः स्मः । एषा पद्धतिः अस्मान् InfiniBand संजालसंरचनायाः विश्वसनीयं उपसमूहं अन्वेष्टुं शक्नोति, परन्तु अतीव कठिनं यतोहि प्रत्येकं समये प्रशिक्षणार्थं प्रयुक्तानां नोड्-समूहं परिवर्तयितुं आवश्यकं भवति, तस्मात् पूर्वनिर्धारितं InfiniBand-लिङ्कं परिवर्तयितुं शक्यते

Step 4: InfiniBand उन्मत्तवत् दहति

InfiniBand समस्यानां अधिकतया निदानं कर्तुं वयं सम्पूर्णस्य क्लस्टरस्य कृते कार्यभारं परिकल्पितवन्तः यत् एकत्रैव वस्त्रे प्रत्येकं पोर्ट् मार्गेण यथासम्भवं आँकडान् धक्कायति स्म इदं सम्पूर्णे क्लस्टर् मध्ये विशालं सर्व-कम-कार्यभारं चालयितुं भिन्नम् अस्ति, यत् Server PCIe Module (SXM) स्लॉट् मार्गेण GPU संचारार्थं NVLink इत्यस्य उपयोगेन व्यक्तिगत-नोड्स् मध्ये संचारस्य अनुकूलनार्थं NCCL इत्यस्य उपयोगस्य आवश्यकता भवति

अपि तु वयं क्रूरबलस्य उपायं स्वीकृत्य सहजतया सफलाः अभवम । UFM सचेतनानि निर्गन्तुं आरभेत यदा अधिकांश-पोर्ट्-मध्ये आँकडा-स्थानांतरण-मात्रा सैद्धान्तिक-क्षमतायाः ९७% अधिकं भवति, तथा च केचन स्विच् अस्थायीरूपेण अधः गमिष्यन्ति । अस्माभिः चिन्तितम् यत् प्रत्येकं बन्दरगाहं दिवसस्य अन्ते यावत् कृतवान् तत् पर्याप्तं दृढं आसीत्, शेषं च अक्षमम् अथवा मरम्मतं लम्बितम् अपसारितम् आसीत् ।

चरण 5: GPUDirect RDMA

CPU कम्प्यूटिंग् ओवरहेड् न कृत्वा GPU संचारस्य अनुमतिं दातुं वयं GPUDirect RDMA इति विशेषता सक्षमं कृतवन्तः, यत् InfiniBand संजालकार्ड् मध्ये प्रत्यक्षसञ्चारस्य अनुमतिं ददाति अस्मिन् द्वौ प्रमुखौ सोपानौ भवतः - १.

1. अतिरिक्तं कर्नेल् मॉड्यूल् आरभत

2. तत्कालं लम्बनं (तत्काल लटकनं) निवारयितुं PCIe अभिगमननियन्त्रणसेवा (ACS) अक्षमम् इति सुनिश्चितं कुर्वन्तु

Step 6: “gold” सर्वरं विस्तारयन्तु

नवीनतमं हार्डवेयरं उपयुज्य GPU क्लस्टरं निर्मातुं, प्रतिसप्ताहं भवतः यन्त्राणां प्रायः ३% विफलतायै एकः नियमः सज्जः भवितुम् अर्हति ।

परन्तु ज्ञातव्यं यत् प्रत्येकस्मिन् यन्त्रे विफलतायाः एकरूपः ३% सम्भावना नास्ति, परन्तु अल्पसंख्याकानां अचिकित्सितानां यन्त्राणां सम्यक् मरम्मतं यावत् न भवति तावत् पुनः पुनः विविधाः समस्याः भवन्ति एतेन एकस्मिन् जालसंरचने बहूनां यन्त्राणां लाभः प्रकाशितः भवति । अतः केवलं बृहत्-स्तरीय-प्रशिक्षणं चालयितुं यादृच्छिक-यन्त्राणि अन्वेष्टुं स्थाने, यथा whack-a-mole इत्यनेन किं भङ्गं भवति इति द्रष्टुं, अस्माकं दृष्टिकोणं विश्वसनीयत्वेन प्रसिद्धानां सर्वराणां स्केलिंग्-करणं, “सुवर्ण”-सर्वर्-इत्येतत्

Step 7: अनुरक्षणम्

InfiniBand इत्यस्य अनुरक्षणं मुख्यतया UFM अलार्म-प्रतिक्रिया, दोषपूर्णकेबल्-ट्रांससीवर-प्रतिस्थापनं, यदा कदा अधिककठिनदोषाणां (यथा स्विच-विफलता) निदानं च भवति प्रायः द्वौ कारकौ स्तः येन बृहत्-प्रमाणेन परिपालनं भवति- १.

1. फर्मवेयर-अद्यतनं, विशेषतः यदा क्लस्टरस्य केवलं आर्धं एव अपडेट् सम्पन्नं भवति, तदा UFM-स्थितिः दूषिता भवितुम् अर्हति तथा च सर्वेषु InfiniBand स्विचेषु UFM पुनः आरम्भस्य आवश्यकता भवति

2. GPU-पेटिकाः एकस्मिन् समये विशालरूपेण पुनः आरभ्यन्ते, येन UFM-स्थितौ बहूनां अपडेट्-प्रवेशः भवितुम् अर्हति तथा च UFM-सेवायाः पुनः आरम्भस्य आवश्यकता अपि भवितुम् अर्हति

यन्त्रं पूर्णतया स्वस्थं भवति इति सुनिश्चितं कुर्वन्तु

मार्गे वयं बहुविधाः उपायाः आविष्कृतवन्तः येन व्यक्तिगतयन्त्राणि विकारं कर्तुं वा प्रशिक्षणं मन्दं कर्तुं वा शक्नुवन्ति । एतेषु बहवः विफलताविधाः तत्क्षणं न दृश्यन्ते, अतः वयं होस्ट् पर्याप्तरूपेण स्वस्थः अस्ति वा इति परीक्षितुं स्वास्थ्यपरीक्षास्क्रिप्ट्-सङ्ख्यां लिखितवन्तः । वयम् अत्र कोडं प्रकाशितवन्तः: https://github.com/imbue-ai/cluster-health

ध्यानं कुर्वन्तु यत् एतेषु बहवः स्वास्थ्यपरीक्षाः अस्माकं रनटाइम् वातावरणस्य विशिष्टाः सन्ति तथा च अनिवार्यतया अन्तर्निहितहार्डवेयरेन सह सम्बद्धाः न सन्ति, न च अनिवार्यतया तेषां समाधानं स्वचालितं वा सुलभं भवति एतत् डिजाइनद्वारा आसीत् : अस्माकं यन्त्राणि प्रशिक्षणार्थं सज्जीकर्तुं समग्रलक्ष्यं प्राप्तुं वयं एकं प्रवेशबिन्दुम् इच्छामः यत् सीधा हाँ वा न वा इति उत्तरं दातुं शक्नोति, तथा च यत् किमपि संख्यायां सूक्ष्मविवरणानां सारांशं दातुं शक्नोति।

GPU स्वास्थ्यपरीक्षा

वयं GPU-सङ्ख्या सम्यक् अस्ति वा, ECC (Error Correction Code) चेक् सक्षमम् अस्ति, ECC त्रुटयः नास्ति इति च परीक्षितवन्तः । वयम् अपि परीक्षितवन्तः यत् NVLink टोपोलॉजी (यत् GPUs परस्परं संयोजयति) त्रुटिरहितं कार्यं करोति इति ।

डिस्क स्पेस स्वास्थ्य जाँच

वयं परीक्षितवन्तः यत् होस्ट् इत्यस्य डिस्कस्थानस्य उपयोगः ९५% अधिकः अस्ति वा इति ।

डॉकर स्वास्थ्य जाँच

वयं परीक्षितवन्तः यत् Docker GPU सम्बद्धेन सह कंटेनरान् चालयितुं शक्नोति (अर्थात्, NVIDIA Container Runtime सम्यक् कार्यं करोति) तथा च निरीक्षण/विश्लेषणसम्बद्धाः Docker कंटेनराः सक्रियः सन्ति तथा च समीचीनाः होस्ट् अनुमतिः सन्ति इति।

Dmesg स्वास्थ्य जाँच

वयं dmesg इत्यस्य जाँचं कृतवन्तः यत् हार्डवेयर Xids अथवा SXid त्रुटयः (NVIDIA GPUs अथवा inter-GPU NVIDIA स्विच् इत्यनेन कारणीभूताः दोषाः) सन्ति । वयं सर्वाणि dmesg log रेखाः अपि पठामः यत् ते सर्वाणि Common/Expected Log Lines इति सूचीयां वर्गीकृत्य स्थापयितुं शक्यन्ते इति सत्यापयितुं ।

iDRAC स्वास्थ्य जाँच

वयं यन्त्रे iDRAC त्रुटयः परीक्षितवन्तः, येन अघातकदोषसन्देशान् उपेक्षितम् । इदं Dell सङ्गणकानां विशिष्टं जाँचम् अस्ति, अतः अस्माकं मुक्तस्रोतसङ्केते इदं न समाविष्टम् ।

डिस्क स्वास्थ्य जाँच

वयं zpool संस्थापितम् अस्ति, Docker सम्यक् तया सह सम्बद्धः अस्ति, तथा च CPU -इत्येतत् लॉक् अप विना वस्तुतः तत् प्राप्तुं शक्नोति इति वयं परीक्षितवन्तः ।

InfiniBand स्वास्थ्य जाँच

वयं परीक्षितवन्तः यत् InfiniBand इत्यस्य त्रुटिदरः वर्धितः वा/अथवा चालकस्य फर्मवेयरः पुरातनः अस्ति वा इति।

Nvlink स्वास्थ्य जाँच

वयं यन्त्रे NVLink त्रुटयः परीक्षितवन्तः । व्यवहारे एतेन प्रशिक्षणविफलता न दृश्यते, परन्तु प्रशिक्षणं मन्दं कर्तुं शक्नोति ।

जीडीआर स्वास्थ्य जाँच

यन्त्रे GDR सक्षमः अस्ति वा इति वयं परीक्षितवन्तः ।

VBIOS स्वास्थ्यपरीक्षा

वयं GPU इत्यस्य VBIOS संस्करणं H100 baseboard firmware च अद्यतनम् इति परीक्षितवन्तः ।

चकमक पत्थर स्वास्थ्य जाँच

वयं flint तथा ​​hca_self_test इत्येतयोः उपयोगं कृतवन्तः यत् Mellanox OFED चालकः, नेटवर्क् कार्ड् फर्मवेयर, ट्रांसीवर फर्मवेयर च समीचीनसंस्करणानाम् अस्ति, तथा च ते NVIDIA चालकस्य कृते सम्यक् संकलिताः सन्ति वा इति परीक्षितुं

पीएसबी स्वास्थ्य जाँच

वयं PCIe उपकरणान् पृष्टवन्तः यत् GPU, PSB (PCIe Switch Bus) तथा नेटवर्क् कार्ड् इत्येतयोः मध्ये संयोजनस्य गतिः विस्तारः च अस्माभिः अपेक्षितं वा अस्ति वा इति। स्विच् फर्मवेयर अद्यतनम् अस्ति वा इति अपि वयं परीक्षितवन्तः । इयं लिपिः Dell इत्यनेन विकसिता, न तु Imbue इत्यनेन, अतः अस्मिन् समये वयम् एतत् साझां कर्तुं न शक्नुमः ।

एतेषां द्रुतस्वास्थ्यपरीक्षाणां अतिरिक्तं वयं केचन अधिकजटिलस्वास्थ्यपरीक्षाः अपि चालयामः, यथा-

PyTorch मार्गेण मैट्रिक्सगणनाम् आरभत, तथा च NVLink बैण्डविड्थं GPU गणनावेगं स्मृतिञ्च मापयन्तु । वयं InfiniBand तथा NVLink इत्येतयोः परीक्षणार्थं समुचितं GDR ध्वजान् सेट् कुर्मः ।

IB कार्ड् मार्गेण आँकडा प्रेषयितुं PCIe तथा InfiniBand कार्ड् बैण्डविड्थ् मापनार्थं ib_write_bw तथा –use_cuda इत्येतयोः उपयोगं कुर्वन्तु । एषा प्रक्रिया दीर्घकालं यावत् (प्रायः १५ निमेषान्) यावत् चलति स्म यत् फडफडमानं InfiniBand लिङ्क् प्राप्तम् इति सुनिश्चितं भवति स्म ।

NCCL आरम्भक्षमतां परीक्षितुं बहु-नोड् निदान-रन चालयन्तु तथा च यत् एतत् यादृच्छिकरूपेण स्थगितम् अस्ति वा इति। यदि विरामाः सन्ति तर्हि अस्माकं forked NCCL कोडः अतिरिक्तं logging योजयति । एतत् समस्यां ज्ञातुं १२ तः २४ घण्टाः यावत् समयः भवति, अतः वयं सामान्यतया केवलं नूतनेषु नोड्-मध्ये अथवा यदा समस्यायाः शङ्का भवति तदा एव एतत् चालयामः ।

कस्यापि GPU घण्टा थ्रोट्लिंग इवेण्ट् (अपेक्षितं gpu_idle तथा power_cap विहाय) कृते DCGM निर्यातं पश्यन्तु । एतासां शक्तिघटनानां जाँचार्थं, सर्वोत्तमः उपायः बहु-नोड्-प्रशिक्षणं चालयितुं भवति यत् सर्वाणि GPUs, InfiniBand कार्ड्स्, तथा च CPUs तथा disks एकत्रैव परीक्षते ।

सामान्यप्रशिक्षणविषयाणां निदानं कुर्वन्तु

एकदा हार्डवेयर सम्यक् कार्यं करोति तदा प्रशिक्षणं आरभ्यतुं शक्यते ।

अयं खण्डः अस्माकं समूहे बृहत्भाषाप्रतिरूपप्रशिक्षणं चालयितुं अस्माकं अनुभवस्य आधारेण केचन विशिष्टाः त्रुटिनिवारणपदार्थाः अन्वेषणं च साझां करिष्यति ।

स्टार्टअप इत्यत्र दुर्घटना

एकप्रकारेण, एषः सर्वोत्तमः दोषः यस्य सम्मुखीभवितुं शक्यते यतः एतत् (सैद्धान्तिकरूपेण) पुनरुत्पादनं पुनरावृत्तिः च सुलभम् अस्ति ।

वयं प्रथमं परीक्षितवन्तः यत् अस्माकं कोडः सम्यक् संस्करणं, विन्यासः, वातावरणचराः च चाल्यते इति । यद्यपि मूलभूतं तथापि अस्माभिः एतत् महत्त्वपूर्णं ज्ञातम् : स्टार्टअप प्रशिक्षणप्रक्रिया पुनः प्रजननीयं सुलभं च जाँचयितुं सुनिश्चितं करणीयम्। एकं कारणं यत् Docker इमेज कैशिंग् अथवा अपारदर्शकगुप्तविन्यासः इत्यादयः मध्यवर्ती अमूर्ताः भ्रमं जनयितुं शक्नुवन्ति ।

अन्यत् मूलभूतं जाँचं वयं कुर्मः यत् सर्वाणि यन्त्राणि ऑनलाइन सन्ति इति सुनिश्चितं कुर्मः तथा च उत्सर्जिताः स्टैक् ट्रेस् अथवा लॉग्स् सुलभतया सङ्गृह्य निरीक्षणं कर्तुं शक्यन्ते इति । वयं Loki, Prometheus, Grafana च सॉफ्टवेयर-स्टैक्-इत्यस्य उपयोगं कृतवन्तः, परन्तु कोऽपि उपयुक्तः लॉग्-सङ्ग्रहः अथवा ट्रैकिंग् SaaS-उपकरणं करिष्यति । यतो हि एते प्रशिक्षणधावनाः समकालिकाः वितरिताः च प्रकृतयः भवन्ति, प्रथमदोषः प्रायः असम्बद्धदोषाणां झरनाम् अयच्छति । अत्र स्वास्थ्यपरीक्षा अपि दूषितहार्डड्राइवः अथवा अनुपलब्धः अथवा अमान्यः GPU इत्यादीनां दोषाणां तत्क्षणं ज्ञातुं साहाय्यं कर्तुं शक्नोति ।

वयं एकं प्रणालीं निर्मितवन्तः यत् विफलतायाः सन्दर्भे स्वयमेव पुनः आरभते, यत् भिन्न-भिन्न-पुनरारम्भेभ्यः भ्रान्ति-दोषान् परिहरितुं log and error-सङ्ग्रहं अधिकं महत्त्वपूर्णं करोति वयं सम्मुखीभवन्ति केचन सामान्यदोषाः अत्र सन्ति-

1. "अग्रे क्रमः श्रेणीषु भिन्नः भवति: श्रेणी 0 43 मापदण्डान् सर्वान् एकत्रयति यदा तु श्रेणी 1228 सर्वान् 1 मापदण्डान् एकत्रयति" इत्यादीनि त्रुटयः अस्माभिः एतत् PyTorch इत्यस्य Fully Sharded Data Parallel (FSDP) कार्यान्वयनस्य विचित्रं विशेषता इति ज्ञातम्, यत् पुनः आरम्भेण सह समाधानं कृतम् ।

2. GPU Out of Memory (OOM) त्रुटिः, या एतादृशी दृश्यते: "CUDA out of memory. Tried to allocate..." अस्माकं विन्यासस्य कोडस्य च बहुवारं जाँचं कृत्वा तथा च हाले कोडसंशोधनं पूर्ववत् कृत्वा (काले अशुद्ध PyTorch उपकरणविनिर्देशानां कारणात् startup तथा च GPU#0 इत्यस्य अत्यधिकप्रयोगस्य परिणामेण), वयं एतानि समस्यानि निवारितवन्तः ।

3. CPU/RAM Out of Memory (OOM) त्रुटयः एतानि त्रुटयः त्रुटिवृत्तौ सुलभानि न भवन्ति तथा च सामान्यतया Docker पात्रस्य बहिः मेजबानस्य dmesg वृत्तान्तद्वारा ज्ञातुं शक्यन्ते । यदा OOM Killer इत्येतत् forked process अथवा network peer इत्येतत् स्थगयितुं आह्वयति तदा वयं द्रष्टुं शक्नुमः यत् ते मुख्यतया CalledProcessError अथवा ConnectionError इति रूपेण प्रकटिताः भवन्ति । यदा dmesg तः OOM Killer आह्वानं ज्ञायते तदा वयं केवलं स्वास्थ्यपरीक्षां परित्यज्य पेटीम् पुनः आरभ्यत इति प्राधान्यं दद्मः । वयं पर्याप्तस्य हस्तचलितकचरसङ्ग्रहस्य कृते अस्माकं कोडमार्गान् अपि परीक्षितवन्तः (अधः एतत् कथं निष्क्रियं कर्तव्यम् इति विभागः अस्ति), अपि च गणनां कर्तुं वा CPU इत्यत्र टेन्सर्-इत्येतत् स्थानान्तरयितुं वा किमपि अप्रत्याशितप्रयासः अस्ति वा इति अपि परीक्षितवन्तः

प्रशिक्षणकाले दुर्घटना

प्रथमा प्राथमिकता अस्ति यत् प्रणालीं स्वचालितं करणीयम् येन सा स्वयमेव सर्वाणि स्वास्थ्यपरीक्षाणि पुनः चालयितुं शक्नोति ततः यदि अस्वस्थः होस्ट् न लभ्यते तर्हि पुनः आरभ्यते । अस्माभिः केचन यादृच्छिकहार्डवेयरदोषाः सम्मुखीकृताः, यत्र Xid तथा SXid त्रुटयः सन्ति, एताः त्रुटयः सार्थकं पायथन् स्टैक् ट्रेस् उत्सर्जयित्वा विना रन क्रैश कर्तुं शक्नुवन्ति; केचन समस्याः, यथा पङ्क्तिपुनर्मानचित्रणं, पुनः आरम्भं कृत्वा पुनः प्राप्तुं शक्यन्ते । अन्येषु समस्यासु, यथा अशुद्धानि ECC त्रुटयः, प्रायः हार्डवेयर-रक्षणस्य अथवा प्रतिस्थापन-भागानाम् आवश्यकता भवति ।

तदतिरिक्तं वयं अवलोकितवन्तः यत् विकृतप्रशिक्षणदत्तांशः अपि दुर्घटनानां कारणं भवितुम् अर्हति । यथा, यदि कोर्पस् मध्ये अतीव विशालः एकः दस्तावेजः अस्ति तर्हि GPU अथवा CPU इत्यत्र स्मृतितः बहिः त्रुटिः भवितुम् अर्हति । एतस्याः समस्यायाः निवारणाय वयं पूर्णतया नियतात्मकं दत्तांशभारकं उपयुञ्ज्महे - प्रत्येकं दुर्घटना युगस्य अथवा चरणसङ्ख्यायाः सह बद्धः भूत्वा सहजतया पुनः प्रजननीयः भवति । वयं पश्यामः यत् दत्तांशभारनं निष्क्रियं कृत्वा अथवा नकलीदत्तांशं (यथा सर्वशून्यदत्तांशं) प्रतिस्थापयितुं त्रुटिस्य मूलकारणं दत्तांशः अस्ति वा इति पुष्टिं कर्तुं साहाय्यं करोति ।

अन्ते मेट्रिकसमुच्चयविधिना संजालस्य सामान्यनोड्स्वास्थ्यसांख्यिकीयस्य च अभिलेखनं अपि सहायकं भवितुम् अर्हति । संक्षिप्तं ईथरनेट्-विच्छेदः अथवा न्यून-डिस्क-स्थानं इत्यादयः विषयाः उपयोगिनो त्रुटिसन्देशरूपेण न दृश्यन्ते, परन्तु संगृहीतदत्तांशैः सह सहजतया सहसंबद्धाः भवितुम् अर्हन्ति ।

न स्टैक ट्रेस् सह लम्बयन्तु (पश्चात् समयसमाप्तेः समस्याः भवितुम् अर्हन्ति)

एतेषु विषयेषु सहायकसूचनायाः अभावात्, तेषां विश्वसनीयरूपेण पुनरुत्पादनस्य कठिनतायाः कारणात्, एतादृशानां दोषाणां निवारणं कुण्ठितं भवितुम् अर्हति

एकः स्मरणीयः प्रकारः दोषः एतादृशैः त्रुटिसन्देशैः सह भवति ।

Watchdog इत्यनेन सामूहिकसञ्चालनस्य समयसमाप्तिः गृहीता:WorkNCCL (SeqNum=408951, OpType=_ALLGATHER_BASE, ... , Timeout (ms)=600000) समयसमाप्तेः पूर्वं 600351 मिलीसेकेण्ड् यावत् चालितम्

तथा च प्रशिक्षणधावनस्य सर्वे GPU कार्यकर्तारः एतादृशान् त्रुटिसन्देशान् निर्गतवन्तः ।

अस्य अर्थः अस्ति यत् एकः वा अधिकः होस्ट् NCCL-सञ्चालनं सम्पूर्णं कर्तुं असफलः अभवत् अथवा NCCL तथा InfiniBand-संयोजनानि दुर्घटनानि अभवन्, येन अन्ये सर्वे होस्ट् एकस्मिन् समये टेन्सर-सञ्चालने अटन्ति यावत् NCCL_TIMEOUT समयसमाप्तिः न प्राप्यते दुर्भाग्येन एनसीसीएल सॉफ्टवेयर पुस्तकालयस्य प्रकृतेः कारणात् कस्य होस्ट् इत्यस्य समस्या अस्ति इति ज्ञातुं कठिनम् अस्ति ।

वयं NCCL सॉफ्टवेयर पुस्तकालयस्य लॉगिंग् इत्यत्र केचन परिवर्तनानि कृतवन्तः, अस्माकं forked संस्करणं पश्यन्तु: https://github.com/boweiliu/nccl । एतेन दुर्घटनायां क्रियमाणाः सन्देशाः वा कार्याणि वा अधिकतया प्रकाशयितुं शक्यन्ते, एवं च निर्धारयितुं शक्यते यत् कोऽपि होस्ट् अथवा GPU तस्य चालनं निवारयति इति ।

ध्यानं कुर्वन्तु यत् दुर्व्यवहारं कुर्वन्तः होस्ट्-परिचयार्थं प्रायः अस्माभिः चिन्तनीयं यत् के होस्ट् कतिपयान् लॉग्-सन्देशान् न जनयन्ति । एतादृशसन्देशाभावेन अस्मिन् होस्ट्-स्थः कार्यकर्ता पृष्ठतः पतितः अथवा दुर्घटितः इति सूचयति ।

अन्ये अप्रतिसादात्मकाः परिस्थितयः यत्र उपलब्धदोषसन्देशाः नास्ति, ते प्रायः हार्डवेयर-सम्बद्धैः समस्याभिः सह सम्बद्धाः भवन्ति, यथा पूर्वं उल्लिखिताः Xid/SXid/ECC त्रुटयः येन NVIDIA चालकं अथवा NVIDIA Docker संचारचालकं लॉक् अप भवति NCCL hangs इत्यस्य ड्राइवर-हैङ्ग्-इत्यस्मात् तथा च पायथन्-सङ्केते रेस-स्थितेः अथवा डेडलॉक्-इत्यस्य भेदं कर्तुं, वयं वास्तविकसमये सम्मुखीभूतानां स्थगित-प्रक्रियाणां त्रुटिनिवारणाय Py-Spy तथा GNU Project Debugger (GDB) इत्यादीनां साधनानां उपयोगं कुर्मः एकः विशिष्टः विषयः एतस्य दृष्टिकोणस्य उपयोगेन आविष्कृतः आसीत्: पायथन् थ्रेड् सेटिंग्स् मध्ये विन्यासदोषस्य कारणात्, वयं केषुचित् होस्ट् मध्ये अष्ट बहु-थ्रेड् NCCL GPU प्रक्रियाः सम्यक् प्रारम्भं कर्तुं असमर्थाः अभवम, येषु PyTorch इत्यस्मात् पूर्वं आरम्भसङ्केतपदे दौडस्य स्थितिः अभवत्

प्रशिक्षणस्य मन्दता (एमएफयू द्वारा मापिता) २.

साधनाभावेन एतादृशी समस्या पूर्वस्मात् अपि अधिकं कुण्ठितं भवति । Py-Spy, stack trace inspection, GDB इत्येतयोः उपयोगस्य अतिरिक्तं वयं NVIDIA Nsight तथा ​​profiling tools अपि नियोजितवन्तः, येषु केचन अत्यन्तं वितरितसेटिंग्स् मध्ये उपयोक्तुं कठिनाः सन्ति

दुर्भाग्यवशं पूर्वं प्रदर्शितस्य मॉडल् प्लवङ्गबिन्दुउपयोगस्य (MFU) अपेक्षया सामान्यमन्दतायाः अथवा न्यूनवेगस्य बहवः कारणानि सन्ति

प्रथमं, विन्यासस्य, कोडस्य, वातावरणचरस्य च बहुवारं जाँचः उपयोगी भवति । अस्माभिः अनुभवितानां त्रुटयः सन्ति यथा गलत् मॉडल् चालयितुं, गलत् बैच् आकारः, गलत् UFM अथवा NCCL सेटिंग्स्, CUDA_DEVICE_MAX_CONNECTIONS त्रुटयः । एतेन उप-अनुकूल-प्रदर्शनस्य परिणामः भविष्यति ।

वयं तत्क्षणिक (अर्थात् प्रति-बैच) MFU (स्मूथ् अथवा विण्डोड् औसतस्य अपेक्षया) मापनं अपि उपयोगी पश्यामः, यतः असम्मूथ् MFU वक्राः प्रायः समस्यावर्गाणां निदानं कर्तुं साहाय्यं कुर्वन्ति प्रशिक्षणस्य मन्दतां जनयन्ति ये समस्याः तेषु अन्तर्भवन्ति : १.

अत्यन्तं न्यून MFU (अपेक्षितस्य दशमांशात् न्यूनम्) तः तत्क्षणमेव प्रशिक्षणं आरभत, स्थिरं च भवतु

इदं अधिकतया InfiniBand संजालसम्बद्धतायाः हार्डवेयरसमस्या अस्ति, यथा T2 अथवा T3 स्तरस्विचस्य दुर्घटना । GPU तथा NIC इत्येतयोः मध्ये हार्डवेयर-समस्याः अपि एतां स्थितिं जनयितुं शक्नुवन्ति, यस्य कृते dmesg एतादृशी त्रुटिं प्रतिवेदयिष्यति: PCIe x16 lanes limited by...

अपेक्षितस्य MFU 30% तः तत्क्षणमेव प्रशिक्षणं आरभत, स्थिरं च धारयन्तु

एतत् एकस्मिन् होस्ट् (NVIDIA peer memory) अथवा GDR वातावरणचरस्य अशुद्धस्य GDR सेटिंग्स् इत्यस्य कारणेन भवितुम् अर्हति ।

अपेक्षितस्य एमएफयू इत्यस्य प्रायः ६०-८०% तः तत्क्षणमेव प्रशिक्षणं आरभत, स्थिरं च धारयन्तु

सर्वाधिकं सामान्यं कारणं दुर्बलं वा दोषपूर्णं वा InfiniBand लिङ्क् गुणवत्ता अस्ति, विशेषतः एकस्मिन् GPU मध्ये InfiniBand NIC-सम्बद्धा विफलता, यत् NCCL देशी NVLink मार्गेण यातायातस्य मार्गं कर्तुं प्रयतते तथा च तस्मिन् एव होस्ट् मध्ये अन्यस्मिन् GPU इत्यत्र NIC इत्यस्य उपयोगं करोति CPU throttling इत्यनेन अपि एतां समस्यां जनयितुं शक्यते, यत् केषुचित् होस्ट्-मध्ये BIOS सेटिंग्स् समायोजयितुं आवश्यकम् अस्ति ।

कतिपयानां दत्तांशसमूहानां संसाधने आकस्मिकं विशालं मन्दता (10x द्वारा न्यूनता) भवति, एतत् च बहुधा भवति

इदं मूलतः सर्वं चेकपोइण्ट् अथवा मूल्याङ्कनस्य विषये अस्ति - एतत् युगानां वा सोपानानां संख्यां जाँचयित्वा सत्यापितुं शक्यते । कष्टप्रदं यत् यदि भवान् MFU असामान्यः भवति तदा स्वचालितं अलार्मं स्थापयति तर्हि बहवः मिथ्या अलार्मः दृश्यन्ते ।

कतिपयदत्तांशसमूहानां संसाधनकाले आकस्मिकं विशालं मन्दता (10x पतनम्)

एतत् यादृच्छिकरूपेण तुल्यरूपेण च दुर्लभतया (प्रायः प्रत्येकं १५ निमेषेषु एकवारं) भवति, तदनन्तरं तत्क्षणमेव उत्तमं MFU प्रति पूर्णं पुनरागमनं भवति ।

सर्वाधिकं सामान्यं कारणं इदं प्रतीयते यत् अन्ये CPU-गहनकार्यभाराः चालित-होस्ट्-मध्ये निर्धारिताः भवन्ति । वयं पश्यामः यत् विशिष्टानि होस्ट्-परिचयार्थं प्रोफाइलिंग्-उपकरणानाम् निर्माणस्य अपेक्षया PID-द्वारा CPU-इत्यस्य मोटेन निरीक्षणं सुकरम् आसीत् । कारणं नैमित्तिकजालसंपर्कस्य समस्याः भवितुम् अर्हन्ति, यथा दत्तांशभारकस्य अटङ्काः । वयं कस्यापि गैर-NCCL-सङ्केतस्य कृते आँकडा-भारस्य, जाँच-बिन्दुस्य, मेट्रिकस्य च निरीक्षणं कृतवन्तः तथा च पायथन्-सङ्केत-समय-लॉग्-इत्येतत् योजितवन्तः, ये अतीव विश्वसनीयाः सिद्धाः अभवन् ।

MFU क्रमेण संचालनस्य समये मन्दं भवति, परन्तु प्रत्येकं पुनः आरम्भस्य अनन्तरं 100% यावत् पुनः आगच्छति

सैद्धान्तिकरूपेण कारणं स्विचे तापसङ्ग्रहः भवितुम् अर्हति, परन्तु एतत् कदापि न दृष्टम् । परन्तु वयं Python तथा NVIDIA profilers इत्येतयोः उपयोगं कृतवन्तः यत् कार्यक्षमतायाः क्षयस्य कारणं स्वचालितं कचरासंग्रहणं दृश्यते इति निर्धारयितुं ।

एतानि मन्दतानि त्रुटिनिवारणं कुर्वन्तः वयं ज्ञातवन्तः यत् थ्रूपुट् प्रायः समये समये पतति इति बाध्यते । यथा यथा प्रशिक्षणं प्रगच्छति तथा तथा एतस्य न्यूनतायाः प्रभावः वितरितगणनायां वर्धमानः भविष्यति । अनेन अस्माकं शङ्का अभवत् यत् पतनस्य कारणं स्वचालितकचरासंग्रहणेन सह सम्बद्धं भवेत् - एतत् अनुमानं यत् वयं विश्लेषणेन परीक्षणेन च सत्यापितवन्तः। यदा वयं स्वचालितं कचरासंग्रहणं निष्क्रियं कृत्वा सर्वेषु होस्ट्-मध्ये केवलं विशिष्टान्तरेषु कचरासंग्रहणं सेट् कृतवन्तः तदा एतत् थ्रूपुट् "ड्रॉप्" अन्तर्धानं जातम् ।

वयं ZeRO-3 इत्यस्य आधारेण समकालिकवितरितप्रशिक्षण-एल्गोरिदम् FSDP इत्यस्य उपयोगं कृतवन्तः । अवरोधनकार्यक्रमस्य समये कचरासंग्रहणं चालयति एकः श्रमिकप्रक्रिया अन्येषां सर्वेषां श्रमिकाणां मन्दीकरणं कर्तुं शक्नोति । यदि भवतः समीपे शतशः श्रमिकप्रक्रियाः सन्ति तर्हि एतेन महत्त्वपूर्णाः मन्दताः भवितुम् अर्हन्ति ।

प्रथमं प्रदर्शनं उत्तमं भवति, ततः अचानकं (अपेक्षितस्य ७०% यावत्) न्यूनीभवति, उच्चावृत्तौ (प्रत्येकं १५ सेकेण्ड् यावत्) निरन्तरं भवति ।

अस्माभिः अवलोकितं यत् एतत् NVIDIA GPUs इत्यत्र "clock throttling reasons" इत्यनेन सह सम्बद्धम् अस्ति, यत् NVIDIA DCGM कृते समुचितसेटिंग्स् इत्यनेन समाधानं कर्तुं शक्यते । तापसमस्याः (उच्चं GPU तापमानं वा होस्ट् शीतलनपंखाविफलता/प्रभावशीलतां न्यूनीकृता) अथवा विद्युत् आपूर्तिविफलता एतत् समस्यां जनयितुं शक्नोति । अपि च, यदा वयं CPU/RAM/डिस्क इत्यनेन सह सर्वाणि 8 GPU उपयोगानि 8x NIC InfiniBand उपयोगानि च max out कुर्मः, तदा विशिष्टविद्युत् आपूर्तिहार्डवेयरयुक्तानां अस्माकं केषाञ्चन होस्ट्-मध्ये वोल्टेज-समस्याः सन्ति, परन्तु केवलं तान् सर्वान् उपयुञ्जते (प्रायः केवलं On This only occurs during the वास्तविक प्रशिक्षण धावन)।

उत्तमं प्रदर्शनं किन्तु सामान्यतः अधिकः कोलाहलः (अपेक्षितस्य MFU 90% तः 100% पर्यन्तं उच्चावृत्तिः श्वेतशब्दविचरणम्)

इदं InfiniBand हार्डवेयर इत्यनेन सह अपि सम्बद्धम् अस्ति, परन्तु प्रायः T2 स्तरस्य न्यूनाधिक-अनावश्यक-होस्ट्-इत्यस्य अपेक्षया, संजाले उच्चतर-लिङ्क्-मध्ये किञ्चित् कार्यक्षमतायाः अवनति-अथवा जिटर-कारणात् भवति

दुर्भाग्यवशं, एतेषु बहवः समस्याः विशिष्टं होस्ट् प्रति सूचयितुं कठिनाः सन्ति, InfiniBand-सम्बद्धाः समस्याः च InfiniBand स्विच-प्रौद्योगिक्याः टोपोलॉजी-जागरूकत्वस्य कारणेन विशेषतया सूचयितुं कठिनाः सन्ति InfiniBand इत्येतत् InfiniBand fat-tree design इत्यस्मिन् समीपस्थानां होस्ट् इत्यस्य पक्षे प्रतीयते, यदा UFM असममितलिङ्क् गतिषु पैकेट् मार्गं स्थापयितुं शक्नोति ।

अत्र थ्रूपुट्-समस्यानां त्रुटिनिवारणार्थं सरलं सारांशं/फ्लोचार्ट्/पूर्णता-जाँचसूची अस्ति:

किं पूर्वं एषा व्यवस्था सम्यक् कार्यं कृतवती ?

अद्यतनकाले भवता के परिवर्तनाः कृताः (यथा कोडस्य विलयः, चालकानां अद्यतनीकरणं)?

भवता चालितः यजमानः स्वस्थः अस्ति वा ? किं भवतः सर्वाणि आश्रितानि सेवानि सामान्यतया चाल्यन्ते, यत्र तृतीयपक्षीय SaaS, यथा Docker Hub, GitHub इत्यादयः सन्ति?

किं भवान् निश्चयं कर्तुं शक्नोति यत् इदानीं भवान् यत् कोडं, वातावरणं, विन्यासः, संस्करणं, होस्ट् सूची, श्रेणीक्रमः, यादृच्छिकबीजं च चालयति तत् गतवारं इव एव अस्ति? (यदि एतादृशी जाँचः कार्यान्वितुं शक्यते स्म।)

समस्या पुनरुत्पादनीया वा ?

अन्यैः विषयैः सह कथं सम्बन्धः ? अन्याः प्रक्रियाः ? दैनिक crontab निर्धारितकार्यम्? मेजबानः वा DCGM अथवा UFM सूचकः?

किं भवतः साधनं एतानि मेट्रिकं सम्यक् मापयति?

किं कोडस्य स्ट्रिप्ड्-डाउन् संस्करणं चालयति (लघुमाडलस्य उपयोगेन, नकलीदत्तांशस्य उपयोगेन, रक्षणं वा लोडिंग् वा चेकपोस्ट् नास्ति) समस्या स्थास्यति?

आधारभूतसंरचनासाधनानाम् उन्नयनं कुर्वन्तु

एकदा भवन्तः उपर्युक्तानि पदानि सम्पन्नवन्तः तदा भवन्तः स्वस्य मॉडलस्य प्रशिक्षणं कुर्वन् उत्तमं प्रदर्शनं प्राप्तुं मार्गे भविष्यन्ति... न्यूनातिन्यूनं यावत् किमपि न भग्नं भवति।

अस्मिन् खण्डे सुसंगतप्रशिक्षणं सुनिश्चित्य प्रयुक्तानां केषाञ्चन साधनानां प्रणालीनां च परिचयः भवति, आदर्शरूपेण यथासम्भवं न्यूनं मानवहस्तक्षेपस्य आवश्यकता भवति । यतः वयं लघुदलः अस्मत्, अस्माकं समीपे हस्तमरम्मतं कर्तुं पर्याप्तं जनशक्तिः नास्ति, अतः वयम् अपि एतां प्रक्रियां यथाशक्ति स्वचालितं कर्तुम् इच्छामः ।

प्रशिक्षणकाले वयं प्रायः सर्वाणि समस्यानि यन्त्रस्य अथवा जालघटकस्य विफलतायाः कारणं भवितुम् अर्हन्ति । एतादृशाः विफलताः बृहत्-समूहेषु सामान्याः सन्ति, अतः अस्माकं उपायः अस्ति यत् विफलं यन्त्रं संजालघटकं च स्वयमेव अक्षमीकरणं कृत्वा मरम्मत-अनुरोधं प्रेषयितुं शक्यते

यन्त्रस्य विकारः

वयं एकं प्रणालीं विकसितवन्तः यत् यदि कश्चन रन दुर्घटना भवति तर्हि स्वयमेव अद्यतनतमात् चेकपोस्ट् तः पुनः आरभ्यते । अस्मिन् पुनः आरम्भप्रक्रियायां प्रत्येकं उपलब्धं यन्त्रं प्रथमं स्वास्थ्य-परीक्षणं भवति, ततः प्रत्येकं यन्त्रं तस्य उत्तीर्ण-स्वास्थ्य-परीक्षण-परिणामानां आधारेण वर्गीकृतं भवति, ततः स्वस्थतम-यन्त्रे प्रशिक्षणं पुनः आरभ्यत इति प्रयासः क्रियते;

संजालघटकविफलता

अस्माभिः अवलोकितानि सर्वाणि संजालविफलतानि UFM द्वारा ज्ञापितानि UFM इवेण्ट् लॉग् मध्ये लॉग् कृताः, अतः प्रतिक्रिया सरलम् आसीत्: UFM लॉग् विश्लेष्य समुचितं कार्यं कुर्वन्तु।

यूएफएम इवेण्ट् सिस्टम् अतीव जटिला अस्ति तथा च दर्जनशः इवेण्ट् प्रकाराः सन्ति । परन्तु व्यवहारे अस्माभिः ज्ञातं यत् केवलं कतिचन घटनाः समस्याप्रदाः आसन्, मुख्यतया लिङ्क् विफलताभिः अथवा उच्चचिह्नदोषप्रविधिभिः सह सम्बद्धाः । एतासां घटनानां पहिचानस्य अनन्तरं वयं UFM इवेण्ट् लॉग् इत्यस्य विश्लेषणार्थं स्क्रिप्ट् लिखितुं शक्नुमः, अद्यतनघटनाभिः सह सम्बद्धानि लिङ्कानि पोर्ट् च अक्षमयितुं शक्नुमः, एतेषां संजालघटकानाम् अनुरक्षणकार्यक्रमाणां अनुरोधं कर्तुं शक्नुमः, अनुरक्षणस्य समाप्तेः अनन्तरं च एतान् घटकान् पुनः सक्षमं कर्तुं शक्नुमः

स्थानीयदर्पणसञ्चिकातन्त्रम्

एतेषां बृहत्वितरितप्रशिक्षणानाम् कृते पूर्वमेव आविष्कृतं यत् क्लस्टरस्य ईथरनेट् च मध्ये दत्तांशविनिमयस्य गतिः प्रमुखः अटङ्कः अस्ति । साझा ईथरनेट्-संयोजनस्य बैण्डविड्थः प्रायः 10Gbit/s भवति;

अस्य कृते वयं अस्माकं क्लस्टरस्य अन्तः मेघसञ्चयस्य दर्पणरूपेण स्थानीयसञ्चिकातन्त्रं निर्मातुं निश्चयं कृतवन्तः, यत् मूलतः एकं संग्रहणस्थानं भवति यत् S3 तः पठितानां सञ्चिकानां परिमाणं न्यूनीकर्तुं शक्नोति क्लस्टर-मथनस्य लेखानुरूपं (अर्थात्, यदा यन्त्रं अक्षमं भवति अथवा अनुरक्षणकारणात् प्रतिस्थापितं भवति), अस्माकं समीपे प्रत्येकस्य सञ्चिकायाः ​​त्रीणि प्रतिकृतयः सन्ति तथा च क्लस्टर-मथनस्य समये कार्यक्षमतां अधिकतमं कर्तुं भारस्य समानरूपेण वितरितुं सुसंगत-हैशिंग्-उपयोगं कुर्वन्ति यतः क्लस्टर्-मध्ये डिस्क-स्थानं सीमितं भवति, अतः अस्माभिः सञ्चिकानां जीवनचक्रं निरीक्षितुं, सञ्चिकानां शुद्ध्यर्थं च साधनानि विकसितव्यानि आसन्, ये पुनः उपयोगिनो न आसन् ।

स्थानीय वितरित Docker रजिस्ट्री

वयं Kraken इत्यस्य उपयोगं कृतवन्तः, यत् Docker इमेज् बिन्दुतः बिन्दुपर्यन्तं स्थानान्तरणार्थं महान् मुक्तस्रोतसॉफ्टवेयरः अस्ति । अस्माकं कार्याणां जटिलतां कार्यान्वयनञ्च विचार्य अस्माकं कृते सॉफ्टवेयरस्य विषये प्रायः कोऽपि समस्या नासीत् । साधनस्य पताः https://github.com/uber/kraken इति

विभिन्नानि कार्यप्रदर्शननिरीक्षणसाधनानि

वयं पूर्वनिर्धारितं Torch विश्लेषकं तथा च Nvidia इत्यस्य Nsight Systems इत्येतत् स्थापयामः । उत्तरार्द्धं अस्मान् अग्रे/विपर्ययपास् तथा एनसीसीएल-सञ्चारस्य कृते आवश्यकं सटीकं समयं अवगन्तुं साहाय्यं करोति, अपि च अस्मान् निर्धारयितुं साहाय्यं करोति यत् दत्तः मॉडलस्य आकारः श्रमिकाणां संख्या च अटङ्कः भविष्यति वा इति। तथापि, Nsight Systems इत्यस्य उपयोगः किञ्चित् कठिनः अस्ति यतोहि अस्य Docker इत्यस्य विशेषाधिकारयुक्तविधाने चालनस्य आवश्यकता भवति, यत् कार्यप्रदर्शननिरीक्षणघटनाभिः सह सम्बद्धानि सुरक्षापरीक्षाणि अक्षमीकरणस्य आवश्यकता भवति, तस्य विन्यासस्य रक्षणाय च प्रायः सम्पूर्णप्रशिक्षणप्रक्रियायाः स्थगितीकरणस्य आवश्यकता भवति

तदतिरिक्तं मन्दप्रशिक्षणसमूहान् ज्ञातुं तेषां सम्भाव्यकारणानि अवगन्तुं च अस्माभिः साधनानि लिखितानि सन्ति । अस्माभिः एतत् उपयोगी इति ज्ञातम्। अत्यन्तं उपयोगी साधनं निरीक्षते यत् प्रत्येकं बैचः कियत्कालं गृह्णाति तथा च यदि कश्चन बैचः अत्यधिकं मन्दः अस्ति तर्हि परित्यजति - येन लघु हार्डवेयर अथवा सॉफ्टवेयर समस्याभिः सह होस्ट् अन्वेष्टुं सुलभं भवति

असफल-होस्ट्-स्थानानि ज्ञातुं यन्त्राणि भिन्न-भिन्न-समूहेषु विभज्यताम्

क्लस्टरस्य उपयोगस्य प्रथमेषु कतिपयेषु मासेषु (यदा स्वास्थ्यपरीक्षाः इदानीं इव सम्यक् न आसन्) वयं प्रायः एतादृशी स्थितिं प्राप्नुमः यत्र यन्त्रसमूहे प्रशिक्षणं कुर्वन् विफलता अभवत्, परन्तु कस्य यन्त्रस्य समस्या अस्ति इति स्पष्टं नासीत् । प्रश्न। दोषपूर्णान् होस्ट् अन्वेष्टुं वयं एतादृशानि साधनानि विकसितवन्तः येन यन्त्रसमूहस्य भिन्नसमूहेषु विभक्तिः सुलभा भवति तथा च प्रत्येकस्मिन् यन्त्रसमूहे लघुप्रशिक्षणं चालयितुं शक्यते ।

यथा, यदि ४८ यन्त्रेषु प्रशिक्षणं विफलं भवति तर्हि ८ यन्त्राणां ६ समूहेषु लघुतरं प्रशिक्षणं चालयन्तु, ततः ६ यन्त्राणां ८ समूहेषु लघुतरं प्रशिक्षणं चालयन्तु सामान्यतया द्वयोः चरणयोः एकः एव धावनः विफलः भविष्यति, येन अस्माकं विश्वासः भवति यत् उभयचरणयोः विफलं यन्त्रं दोषपूर्णम् इति निष्कर्षं निकासयितुं शक्नुमः ।

चिन्तनं तथा ज्ञाताः पाठाः

आधारभूतसंरचनायाः स्थापनायाः, परिपालनस्य च प्रक्रियायां वयं केचन उपयोगिनो पाठाः ज्ञातवन्तः - १.

एकः उपयोगी उपायः अस्ति यत् यन्त्राणां स्थानं स्वैप करणीयम् । रनटाइम् इत्यत्र आवश्यकतायाः अपेक्षया १०-२०% अधिकयन्त्राणां उपयोगः सहायकः भवितुम् अर्हति येन यन्त्रस्य विफलतायाः सन्दर्भे प्रशिक्षणं सुलभतया पुनः आरभ्यतुं शक्यते । प्रत्येकं यन्त्रं प्रत्येकं यन्त्रेण सह दृढतया सम्बद्धं भवति इति क्लस्टर-जालस्थापनं स्थापयित्वा तेषां यन्त्राणां किमपि कार्यरतं उपसमूहं उपयोक्तुं शक्नुमः ।

भवता सम्मुखीभूतानां प्रत्येकस्य हार्डवेयर-सॉफ्टवेयर-विफलतायाः परीक्षणं स्वचालितसमाधानं च लिखितुं मूल्यं भवति, यतः प्रशिक्षणे सम्मुखीभूता प्रत्येका समस्या पुनः भविष्यति तथैव प्रत्येकं अस्पष्टदोषसन्देशस्य कृते, त्रुटिं श्रेष्ठतया व्याख्यायमानं साधनं लिखितुं योग्यम् अस्ति ।

पुनरुत्पादनक्षमता उत्तमवैज्ञानिकसंशोधनस्य कुञ्जी अस्ति। अस्माभिः तत्क्षणमेव स्वीकृताः एकः बृहत् सिद्धान्तः आसीत् यत् "एकैकं वस्तु एकैकं परिवर्तयतु" इति सरलतमेषु विषयेषु अपि ।

विश्वासं कुर्वन्तु, परन्तु सत्यापनम् अपि कुर्वन्तु। यदा कदापि वयं बाह्यसाधनं आनयामः वा नूतनान् जनान् आनयामः (कम्पनीयाः अन्तः बहिः वा), तेषां दावानां द्विवारं परीक्षणं कुर्मः, विशेषतः यदि अनन्तरं पदानि तेषु दावासु निर्भरं भवति

सारांशं कुरुत

बृहत्भाषाप्रतिमानानाम् प्रशिक्षणार्थं आरम्भादेव जटिलमूलसंरचनायाः आवश्यकता भवति । वयं आधारभूतसंरचनायाः स्थापनायाः विवरणेषु गभीरं संलग्नतां प्राप्तुं चयनं कृतवन्तः यतोहि वयं मन्यामहे यत् वयं यत् प्रणालीं चालयामः तत् पूर्णतया अवगन्तुं महत्त्वपूर्णम् अस्ति, तथा च यतोहि वयं मन्यामहे यत् एतत् कर्तुं अधिकं कार्यक्षमम् अस्ति

इदानीं प्रक्रियायाः माध्यमेन गत्वा वयं प्रसन्नाः स्मः यत् वयम् एतत् उपायं स्वीकृतवन्तः - अस्माकं आधारभूतसंरचनायाः उपरि पूर्णं नियन्त्रणं कृत्वा अमूर्ततायाः प्रत्येकस्मिन् स्तरे सहजतया त्रुटिनिवारणस्य क्षमता च महत्त्वपूर्णं मूल्यं सिद्धम् अभवत् यद्यपि अस्याः प्रक्रियायाः कृते बहु पर्यवेक्षणस्य पुनरावृत्तेः च आवश्यकता आसीत् तथापि अस्मान् अन्तर्निहितकार्यप्रवाहस्य गहनबोधं प्राप्तुं, मेजबानस्वास्थ्यं सुनिश्चित्य साधनानां समुच्चयं निर्मातुं, प्रशिक्षणं निरन्तरं सुचारुरूपेण भवति इति सुनिश्चित्य प्रणालीं कथं स्वचालितं कर्तव्यमिति ज्ञातुं, अन्ततः च अनुमतिं दत्तवती build a Set of infrastructure यत् अस्मान् शीघ्रं पुनरावर्तनीयरूपेण च अत्याधुनिकभाषाप्रतिमानानाम् प्रशिक्षणं कर्तुं शक्नोति।

इयं आधारभूतसंरचनानिर्माणप्रक्रिया एआइ-एजेण्ट्-संशोधनार्थं निर्माणार्थं च अस्माकं मूलभूतपद्धतिं प्रतिबिम्बयति: विवरणानां अन्वेषणं, विद्यमानप्रक्रियासु निरन्तरं सुधारः, अस्माकं प्रेरितदलस्य अधिकचुनौत्यं निवारयितुं सक्षमं कर्तुं उपयोगीसाधनानाम्, प्रणालीनां च निर्माणं च।