08 अग॰ 2025·8 मिनट
जेफ डीन: गूगल पर एआई को स्केल करने वाले इंजीनियर
जेफ डीन के करियर और उन प्रणालियों पर व्यावहारिक नज़र जो गूगल को एआई स्केल करने में मदद मिली—MapReduce, Bigtable, और आधुनिक एमएल इन्फ्रास्ट्रक्चर से मिलने वाले सबक।
जेफ डीन के करियर और उन प्रणालियों पर व्यावहारिक नज़र जो गूगल को एआई स्केल करने में मदद मिली—MapReduce, Bigtable, और आधुनिक एमएल इन्फ्रास्ट्रक्चर से मिलने वाले सबक।
जेफ डीन एआई के लिए इसलिए मायने रखते हैं क्योंकि कई “ब्रेकथ्रू” जिनसे लोग आधुनिक मशीन लर्निंग जोड़ते हैं, तभी उपयोगी बनते हैं जब वे विशाल डेटा पर भरोसेमंद, बार-बार और सस्ते रूप में चल सकें। उनकी सबसे प्रभावशाली कामों में से बहुत कुछ एक वादे-मुकम्मल-प्रणाली के बीच के गैप में रहता है—एक ऐसी प्रणाली जो लाखों उपयोगकर्ताओं को सर्व कर सके।
जब टीमें कहती हैं कि वे “एआई को स्केल” करना चाहती हैं, वे सामान्यतः कई सीमाओं का संतुलन कर रही होती हैं:
स्केल पर एआई किसी एक मॉडल के बारे में कम और एक असेंबली लाइन के बारे में ज़्यादा है: पाइपलाइंस, स्टोरेज, वितरित एग्ज़ीक्यूशन, मॉनिटरिंग, और स्पष्ट इंटरफेस जो कई टीमों को बिना एक-दूसरे पर ठोकर मारे काम करने दें।
यह कोई सेलिब्रिटी प्रोफ़ाइल नहीं है और न ही यह दावा कि किसी एक व्यक्ति ने गूगल का एआई “आविष्कृत” किया। गूगल की सफलता बड़ी टीमों और शोधकर्ताओं से आई, और कई प्रोजेक्ट्स सह-लेखित और सह-निर्मित थे।
इसके बजाय यह पोस्ट उन इंजीनियरिंग पैटर्न्स पर केंद्रित है जो बार-बार उन प्रणालियों में दिखते हैं जिनमें जेफ डीन ने योगदान दिया या उनका रूप-रेखा तय करने में मदद की—MapReduce, Bigtable, और बाद का एमएल इन्फ्रास्ट्रक्चर। उद्देश्य ऐसे विचार निकालना है जिन्हें आप लागू कर सकें: विफलता के लिए डिजाइन कैसे करें, वर्कफ़्लोज़ को कैसे मानकीकृत करें, और प्रयोगों को नायाब हीरोइक घटनाओं की बजाय रोज़मर्रा का काम कैसे बनाएं।
यदि आपका मकसद वास्तविक ट्रैफ़िक और वास्तविक सीमाओं में जीवित रहने वाली मशीन लर्निंग भेजना है, तो सिस्टम का परिप्रेक्ष्य असली कहानी है—और जेफ डीन का करियर उस धागे को फॉलो करने के लिए उपयोगी है।
जेफ डीन ने गूगल में तब शामिल हुए जब वह अभी भी खुले इंटरनेट पर “प्रोडक्शन” का मतलब परिभाषित कर रहा था: कुछ ही सेवाएँ, तेज़ी से बढ़ती यूजर बेस, और उम्मीद कि खोज परिणाम हर बार तुरंत दिखेंगे।
सर्च-युग का गूगल उन सीमाओं का सामना कर रहा था जो किसी भी स्केल टीम को परिचित लगेंगी:
इसने एक व्यावहारिक मानसिकता को जन्म दिया: मानो फेल्यर होंगे, रिकवरी के लिए डिजाइन करो, और प्रदर्शन सिस्टम स्तर पर काम करे—एक सर्वर को हाथ से ट्यून करके नहीं।
क्योंकि सर्च हर क्वेरी पर कई मशीनों को छूता है, छोटी-छोटी अक्षमताएँ तेजी से गुणा हो जाती थीं। उस दबाव ने ऐसे पैटर्न को तरजीह दी जो:
जब गूगल बाद में बड़े पैमाने पर डेटा प्रोसेसिंग और मशीन लर्निंग में विस्तार हुआ, ये प्राथमिकताएँ सुसंगत रहीं: अनुमानित प्रदर्शन, ऑपरेशनल सुरक्षा, और आंशिक आउटेज सहने वाले डिज़ाइन।
डीन के प्रभाव से जुड़ा एक आवर्ती थीम है लीवरेज। हर नई स्केल चुनौती को फिर से शुरू करने के बजाय, गूगल ने आंतरिक बिल्डिंग ब्लॉक्स—साझा सिस्टम्स—में निवेश किया जो कई टीमों को कम विशेषज्ञों के साथ तेज़ी से शिप करने देते थे।
यह प्लेटफ़ॉर्म माइंडसेट तब निर्णायक बनता है जब आपके पास दर्जनों (फिर सैंकड़ों) टीमें हों। यह केवल एक सिस्टम को तेज़ बनाने के बारे में नहीं है; यह पूरी संगठन को बिना हर बार मूल को फिर से आविष्कृत किए तेज़ सिस्टम बनाने के काबिल बनाने के बारे में है।
जब कोई वर्कलोड एक मशीन से बाहर निकलता है, पहली बाधा आम तौर पर "अधिक CPU" नहीं होती। यह उस दूरी का बढ़ना होता है जो आप जो गणना करना चाहते हैं और जो आपका सिस्टम सुरक्षित रूप से समन्वय कर सकता है, के बीच होता है। ट्रेनिंग और सर्विंग एआई सिस्टम एक साथ सब कुछ पर दबाव डालते हैं: कम्प्यूट (GPU/TPU समय), डेटा (थ्रूपुट और स्टोरेज), और विश्वसनीयता (जब कुछ अनिवार्य रूप से फेल हो तो क्या होता है)।
एक अकेली सर्वर फेल होना असुविधा है। एक फ़्लीट में, यह सामान्य है। जैसे-जैसे जॉब्स सैकड़ों या हजारों मशीनों में फैलते हैं, आप पूर्वानुमानित दर्द बिंदुओं से मिलते हैं: स्ट्रैग्लर्स (एक धीमा वर्कर सबको रोकता है), नेटवर्क कंटेंशन, असंगत डेटा रीड्स, और कैस्केडिंग रीट्राइज़ जो मूल समस्या को बढ़ा देते हैं।
शार्डिंग डेटा और काम को संभालने योग्य हिस्सों में बाँट देता है ताकि कोई एक मशीन गला सितारा न बन सके।
रिप्लिकेशन कई प्रतियाँ रखता है ताकि फेल्यर डाउनटाइम या डेटा लॉस में न बदलें।
फॉल्ट टॉलरेंस आंशिक विफलता मानकर रिकवरी के लिए डिजाइन करता है: टास्क्स को रीस्टार्ट करना, शार्ड्स पुनः असाइन करना, परिणाम सत्यापित करना।
बैकप्रेशर ओवरलोड को रोकता है—जब कंज्यूमर टिक नहीं पाते तो प्रोड्यूसर्स को धीमा करना—जो कतारों, पाइपलाइनों और ट्रेनिंग इनपुट के लिए महत्वपूर्ण है।
स्केल पर, एक ऐसा प्लेटफ़ॉर्म जिसका कई टीमें सही ढंग से उपयोग कर सकती हैं, एक बिस्पोक हाई-परफॉर्मेंस सिस्टम से ज़्यादा मूल्यवान होता है जिसे केवल उसके लेखक ही चला सकें। स्पष्ट डिफ़ॉल्ट्स, सुसंगत APIs, और अनुमाननीय विफलता मोड्स आकस्मिक जटिलता को कम करते हैं—खासकर जब उपयोगकर्ता शोधकर्ता हों जो तेजी से इटरेट कर रहे हों।
आप शायद इन तीनों में से किसी एक को ही अधिकतम कर पाते हैं। आक्रामक कैशिंग और असिंक्रोनस प्रोसेसिंग प्रदर्शन बढ़ाती हैं पर सटीकता जटिल कर सकती हैं। कड़ा कंसिस्टेंसी और वैलिडेशन सटीकता बढ़ाते हैं पर थ्रूपुट घटा सकते हैं। ऑपरेबिलिटी—डीबगिंग, मैट्रिक्स, सुरक्षित रोलआउट—अक्सर यह निर्धारित करती है कि क्या एक सिस्टम प्रोडक्शन से टकराने पर बच पाएगा।
इस तनाव ने वही इन्फ्रास्ट्रक्चर आकार दिया जिसमें जेफ डीन ने लोकप्रियता बढ़ाने में मदद की: ऐसे सिस्टम जो सिर्फ कम्प्यूट को ही नहीं, बल्कि विश्वसनीयता और मानव उपयोग को एक साथ स्केल कर सकें।
MapReduce एक सरल विचार है जिसका असाधारण प्रभाव हुआ: एक बड़े डेटा जॉब को कई छोटे टास्क्स (“map”) में तोड़ो, क्लस्टर पर समानांतर चलाओ, फिर आंशिक परिणामों को मिलाओ (“reduce”)। यदि आपने कभी मिलियनों दस्तावेज़ों में शब्द गिने हैं, लॉग्स को उपयोगकर्ता द्वारा ग्रुप किया है, या सर्च इंडेक्स बनाए हैं, तो आप पहले ही MapReduce का मानसिक संस्करण कर चुके हैं—बस गूगल के स्केल पर नहीं।
MapReduce से पहले, इंटरनेट-स्केल डेटासेट्स को प्रोसेस करना अक्सर कस्टम वितरित कोड का काम होता था। वह कोड लिखने में कठिन, ऑपरेट करने में नाज़ुक और गलतियों के लिए आसान था।
MapReduce ने एक महत्वपूर्ण मान्यता की: मशीनें फेल होंगी, डिस्क मरेंगी, नेटवर्क हिचकिचाएगा। सिस्टम ने फेल्यर्स को दुर्लभ अपवाद मानने के बजाय उन्हें नियमित माना। टास्क्स को फिर से चलाया जा सकता था, मध्यस्थ परिणाम फिर से बनाए जा सकते थे, और कुल मिलाकर जॉब बिना हर क्रैश को इंसान द्वारा मॉनिटर किए पूरा हो सकता था।
यह फेल्यर-फर्स्ट मानसिकता बाद में एमएल के लिए मायने रखती थी, क्योंकि बड़े ट्रेनिंग पाइपलाइंस में वही तत्व—विशाल डेटासेट्स, कई मशीनें, और लंबे चलने वाले जॉब्स—ज़रूरी होते हैं।
MapReduce ने सिर्फ कम्प्यूट तेज़ नहीं किया; इसने उसे मानकीकृत किया।
टीमें डेटा प्रोसेसिंग को एक दोहराने योग्य जॉब के रूप में व्यक्त कर सकती थीं, साझा इन्फ्रास्ट्रक्चर पर चला सकती थीं, और लगातार व्यवहार की उम्मीद कर सकती थीं। हर समूह के अपने क्लस्टर स्क्रिप्ट, मॉनिटरिंग, और रीट्राय लॉजिक आविष्कार करने की जगह, वे एक सामान्य प्लेटफ़ॉर्म पर निर्भर रहते थे। इससे प्रयोग तेज़ हुए (किसी फ़िल्टर के साथ जॉब को फिर से चलाएँ), परिणाम पुनरुत्पाद्य हुए, और “हीरो इंजीनियर” का फैक्टर घटा।
इसने डेटा को एक उत्पाद बनने में भी मदद की: एक बार पाइपलाइंस भरोसेमंद हो गईं, आप उन्हें शेड्यूल कर सकते थे, वर्शन कर सकते थे, और डाउनस्ट्रीम सिस्टम्स को आउटपुट आत्मविश्वास से सौंप सकते थे।
कई संस्थाएँ अब Spark, Flink, Beam, या क्लाउड-नेटिव ETL टूल्स का उपयोग करती हैं। वे अधिक लचीले (स्ट्रीमिंग, इंटरैक्टिव क्वेरीज़) हैं, पर MapReduce के मूल सबक अभी भी लागू होते हैं: समानांतरता को डिफॉल्ट बनाइए, रीट्राय के लिए डिजाइन कीजिए, और साझा पाइपलाइन टूलिंग में निवेश कीजिए ताकि टीमें डेटा गुणवत्ता और मॉडलिंग पर समय लगा सकें—क्लस्टर सर्वाइवल पर नहीं।
मशीन लर्निंग की प्रगति केवल बेहतर मॉडलों के बारे में नहीं है—यह सही डेटा को सही जॉब्स तक सही पैमाने पर लगातार पहुँचाने के बारे में भी है। गूगल में, डीन ने जिस सिस्टम-माइंडसेट को बढ़ाया उसने स्टोरेज को "बैकएंड प्लम्बिंग" से उठाकर एमएल और एनालिटिक्स की कहानी का प्रथम श्रेणी हिस्सा बना दिया। Bigtable उन प्रमुख बिल्डिंग ब्लॉकों में से एक बन गया: एक स्टोरेज सिस्टम जो विशाल थ्रूपुट, अनुमाननीय लेटेंसी, और ऑपरेशनल कंट्रोल के लिए डिजाइन किया गया था।
Bigtable एक wide-column स्टोर है: पारंपरिक स्थिर कॉलम सेट की जगह आप स्पार्स, विकसित होते डेटा स्टोर कर सकते हैं जहाँ अलग अलग पंक्तियों का "आकार" अलग हो सकता है। डेटा को tablets (पंक्तियों के रेंज) में विभाजित किया जाता है, जिन्हें लोड बैलेंस करने के लिए सर्वरों पर स्थानांतरित किया जा सकता है।
यह संरचना सामान्य बड़े-स्केल एक्सेस पैटर्न से मेल खाती है:
स्टोरेज डिज़ाइन चुपचाप यह प्रभावित करता है कि टीमें कौन से फीचर जनरेट करती हैं और कितनी भरोसेमंद तरीके से वे ट्रेन कर सकती हैं।
यदि आपका स्टोर कुशल रेंज स्कैन और वर्जन्ड डेटा का समर्थन करता है, तो आप किसी विशेष टाइम-विंडो के लिए ट्रेनिंग सेट पुनर्निर्माण कर सकते हैं, या पिछले महीने के प्रयोग को पुनरुत्पादित कर सकते हैं। यदि रीड्स धीमी या असंगत हों, तो फीचर जनरेशन नाज़ुक बन जाती है, और टीमें समस्याओं के चारों ओर "सैंपलिंग" करने लगती हैं—जिससे बायस्ड डेटासेट और कठिन-से-डिबग होने वाला मॉडल बिहेवियर पैदा होता है।
Bigtable-शैली का एक्सेस यह भी प्रोत्साहित करता है कि आप कच्चे सिग्नल एक बार लिखें, फिर बिना सब कुछ डुप्लिकेट किए कई फीचर व्यूज़ निकालें।
स्केल पर, स्टोरेज फेल्यर एक बड़े आउटेज की तरह नहीं दिखते—वे छोटे, लगातार घर्षण की तरह दिखते हैं। क्लासिक Bigtable सबक सीधे एमएल इन्फ्रास्ट्रक्चर पर लागू होते हैं:
जब डेटा एक्सेस अनुमाननीय होता है, ट्रेनिंग भी अनुमाननीय होती है—और यही बात एमएल को रिसर्च प्रयास से भरोसेमंद प्रोडक्ट कैपेबिलिटी बनाती है।
एक मॉडल को एक मशीन पर ट्रेन करना ज्यादातर "यह बॉक्स कितनी तेज़ी से गिणती कर सकता है?" का प्रश्न है। कई मशीनों में ट्रेनिंग जोड़ने से एक कठिन प्रश्न जुड़ जाता है: "हम दर्जनों या हजारों वर्कर्स को कैसे एक सुसंगत ट्रेनिंग रन जैसा व्यवहार कराएँ?" यही गैप है जिसकी वजह से वितरित ट्रेनिंग अक्सर वितरित डेटा प्रोसेसिंग से ज़्यादा जटिल होती है।
MapReduce जैसी प्रणालियों में, टास्क्स को रीट्राय और पुनर्निर्माण किया जा सकता है क्योंकि आउटपुट डिटरमिनिस्टिक होता है: समान इनपुट को फिर से चलाने पर वही परिणाम मिलता है। न्यूरल नेटवर्क ट्रेनिंग इतरेटिव और स्टेटफुल होती है। हर स्टेप साझा पैरामीटर्स को अपडेट करता है, और छोटे-छोटे समय-भेद सीखने के मार्ग को बदल सकते हैं। आप सिर्फ काम को नहीं बाँट रहे—आप एक गतिशील लक्ष्य का समन्वय कर रहे हैं।
जब आप ट्रेनिंग को स्केल आउट करते हैं, कुछ समस्याएँ तुरंत सामने आती हैं:
गूगल के भीतर, जेफ डीन से जुड़ा काम DistBelief जैसे सिस्टम्स को एक उत्साहजनक रिसर्च आइडिया से कुछ ऐसा बनने में मदद करता था जो बार-बार, असली फ़्लीट्स पर, अनुमाननीय परिणामों के साथ चल सके। महत्वपूर्ण बदलाव था ट्रेनिंग को एक प्रोडक्शन वर्कलोड के रूप में देखना: स्पष्ट फॉल्ट टॉलरेंस, परफ़ॉर्मेंस मैट्रिक्स, और जॉब शेड्यूलिंग व मॉनिटरिंग के आस-पास ऑटोमेशन।
अधिकांश संगठनों में हस्तांतरित होने वाली चीज़ें वास्तुशिल्प नहीं बल्कि अनुशासन हैं:
जब Google Brain ने मशीन लर्निंग को कुछ रिसर्च प्रोजेक्ट्स से इस तरह शिफ्ट किया कि कई प्रोडक्ट टीमें चाहने लगीं, तो बाधा केवल बेहतर मॉडलों की नहीं थी—यह समन्वय की थी। एक साझा एमएल प्लेटफ़ॉर्म घर्षण कम करके वन-ऑफ “हीरो वर्कफ़्लोज़” को उन सड़कों पर बदल देता है जिन्हें सैकड़ों इंजीनियर सुरक्षित रूप से उपयोग कर सकें।
बिना सामान्य टूलिंग के, हर टीम वही मूल बातें फिर से बनाती है: डेटा एक्सट्रैक्शन, ट्रेनिंग स्क्रिप्ट्स, इवैल्यूएशन कोड, और डिप्लॉयमेंट गोंद। वह नकल असंगत गुणवत्ता पैदा करती है और टीमों के बीच परिणामों की तुलना मुश्किल बनाती है। एक केंद्रीय प्लेटफ़ॉर्म उबाऊ हिस्सों को मानकीकृत करता है ताकि टीमें उस समस्या पर समय लगा सकें जिसका वे हल कर रही हैं, न कि वितरित ट्रेनिंग, डेटा वैलिडेशन, या प्रोडक्शन रोलआउट फिर से सीखने पर।
एक व्यावहारिक साझा एमएल प्लेटफ़ॉर्म सामान्यतः कवर करता है:
प्लेटफ़ॉर्म का काम प्रयोगों को दोहराने योग्य बनाना है: कॉन्फ़िगरेशन-चालित रन, वर्जन्ड डेटा और कोड, और एक्सपेरिमेंट ट्रैकिंग जो रिकॉर्ड करे कि क्या बदला और क्यों कोई मॉडल बेहतर हुआ (या नहीं)। यह नए आर्किटेक्चर खोजने जैसा ग्लैमर नहीं है, पर यह यह रोकता है कि "हम पिछले सप्ताह की जीत को पुनरुत्पादित नहीं कर सकते" सामान्य हो जाए।
बेहतर इन्फ्रास्ट्रक्चर आत्म-चतुर मॉडल नहीं बनाता—पर यह फर्श ऊपर उठा देता है। साफ़ डेटा, सुसंगत फीचर, भरोसेमंद इवैल्यूएशन, और सुरक्षित डिप्लॉयमेंट छिपी हुई त्रुटियों को घटाते हैं। समय के साथ, इसका मतलब है कम झूठी जीतें, तेज़ इटरेशन, और प्रोडक्शन में अधिक पूर्वानुमेय व्यवहार करने वाले मॉडल।
यदि आप छोटे संगठन में इस तरह की "पाइव्ड रोड" बना रहे हैं, तो मूल बात वही है: समन्वय लागत घटाइए। एक व्यावहारिक तरीका यह है कि ऐप्स, सेवाएँ, और डेटा-आधारित वर्कफ़्लोज़ कैसे बनाए जाते हैं, उसे मानकीकृत किया जाए। उदाहरण के तौर पर, Koder.ai एक वाइब-कोडिंग प्लेटफ़ॉर्म है जो टीमों को चैट के ज़रिए वेब, बैकएंड, और मोबाइल ऐप्स बनाने देता है (React वेब पर, Go + PostgreSQL बैकएंड पर, Flutter मोबाइल पर)। सोच-समझकर इस्तेमाल करने पर, ऐसे टूल्स प्लेटफ़ॉर्म के चारों ओर के स्कैफोल्डिंग और आंतरिक टूलिंग—एडमिन कंसोल, डेटा रिव्यू ऐप्स, एक्सपेरिमेंट डैशबोर्ड्स, या सेवा रैपर—को तेज़ी से शिप करने में मदद कर सकते हैं, जबकि सोर्स-कोड एक्सपोर्ट, डिप्लॉयमेंट और रोलबैक जैसी प्रोडक्शन नियंत्रण सुविधाएँ तब भी उपलब्ध रहती हैं जब आपको उन्हें चाहिए।
TensorFlow एक उपयोगी उदाहरण है कि क्या होता है जब एक कंपनी मशीन लर्निंग को एक-आफ रिसर्च प्रोजेक्ट्स की तरह नहीं बल्कि इन्फ्रास्ट्रक्चर की तरह पैकेज करना शुरू कर देती है। हर टीम फिर डेटा पाइपलाइंस, ट्रेनिंग लूप्स, और डिप्लॉयमेंट गोंद को फिर से नहीं बनाती; एक साझा फ्रेमवर्क "डिफ़ॉल्ट तरीका" को तेज़, सुरक्षित, और मेंटेन करना आसान बना देता है।
गूगल के अंदर चुनौती सिर्फ बड़े मॉडलों को ट्रेन करना नहीं थी—यह कई टीमों को एक समान तरीके से ट्रेन और शिप करने में मदद करना था। TensorFlow ने आंतरिक प्रैक्टिसेस को एक दोहराने योग्य वर्कफ़्लो में बदला: एक मॉडल परिभाषित करो, उसे अलग-अलग हार्डवेयर पर चलाओ, ज़रूरत पड़ने पर वितरित ट्रेनिंग करो, और इसे प्रोडक्शन सिस्टम्स में एक्सपोर्ट करो।
इस तरह का पैकेजिंग समन्वय लागत को घटाती है। जब टीमें समान प्रिमिटिव्स साझा करती हैं, तो कम बिस्पोक टूल्स, कम छिपी धारणाएँ, और अधिक पुन: उपयोगी कंपोनेंट्स (मैट्रिक्स, इनपुट प्रोसेसिंग, मॉडल सर्विंग फॉर्मैट) मिलते हैं।
प्रारंभिक TensorFlow ने कम्प्यूटेशन ग्राफ़्स पर निर्भर किया: आप क्या गणना होनी चाहिए बताएं, और सिस्टम यह तय करे कि इसे कुशलता से कैसे चलाना है। उस पृथक्करण ने CPUs, GPUs, और बाद में विशेष एक्सेलेरेटर्स को टार्गेट करना आसान बनाया बिना हर मॉडल को फिर से लिखे।
पोर्टेबिलिटी यहाँ खामोश सुपरपावर है। एक मॉडल जो अलग-अलग वातावरणों में—नोटबुक, बड़े ट्रेनिंग क्लस्टर, प्रोडक्शन सर्विसेज—चल सके, वह "यहाँ चलता है, वहाँ टूटता है" के टैक्स को घटा देता है जो टीमों को धीमा करता है।
भले ही आपकी कंपनी कभी कुछ ओपन-सोर्स न करे, "ओपन टूलिंग" माइंडसेट अपनाने से मदद मिलती है: स्पष्ट APIs, साझा परंपराएँ, संगतता गारंटी, और नई टीमों के लिए दस्तावेज़ जो उपयोगकर्ता मानकर लिखा गया हो। मानकीकरण वेलोसिटी बढ़ाता है क्योंकि ऑनबोर्डिंग बेहतर होती है और डिबगिंग अधिक अनुमाननीय होती है।
कहानी को किसने "आविष्कार" किया इसका ओवरक्लेम करना आसान है। हस्तांतरित करने योग्य पाठ नवीनता नहीं बल्कि प्रभाव है: कुछ कोर एब्स्ट्रैक्शंस चुनिए, उन्हें व्यापक रूप से उपयोगी बनाइए, और मानक पाथ को आसान बनाइए।
डीप लर्निंग ने सिर्फ़ "अधिक सर्वर" माँगे नहीं—उसने एक अलग प्रकार का कंप्यूटर माँगा। जैसे-जैसे मॉडल आकार और डेटासेट बढ़े, जनरल-पर्पज़ CPU बाधा बन गया—लचीलापन के लिए बढ़िया, पण न्यूनतम-लेवल के घनत्वीय लिनियर अल्जेब्रा के लिए अनुकूल नहीं।
GPUs ने दिखाया कि मासिवली पैरेलल चिप्स मॉडल को प्रति डॉलर कहीं अधिक तेज़ ट्रेन कर सकते हैं बनाम CPU फ़्लीट। बड़ा बदलावा सांस्कृतिक था: ट्रेनिंग अब कुछ ऐसा बन गया जिसे आप इंजीनियर करते हैं (मेमोरी बैंडविड्थ, बैच साइज़ेस, पैरेललिज़्म रणनीति), केवल चला कर इंतज़ार करने जैसा नहीं।
TPUs ने उस विचार को आगे बढ़ाया, हार्डवेयर को सामान्य एमएल ऑपरेशंस के आस-पास ऑप्टिमाइज़ करके। नतीजा केवल तेज़ी नहीं था—यह अनुमाननीयता भी थी। जब ट्रेनिंग का समय सप्ताहों से दिनों (या घंटों) तक घटता है, इटरेशन लूप तंग हो जाते हैं और रिसर्च प्रोडक्शन जैसा दिखने लगता है।
विशेष हार्डवेयर तभी फायदा देता है जब सॉफ़्टवेयर स्टैक उसे व्यस्त रख सके। इसलिए कंपाइलर्स, कर्नेल्स, और शेड्यूलिंग मायने रखते हैं:
दूसरे शब्दों में: मॉडल, रनटाइम, और चिप एक ही परफ़ॉर्मेंस कहानी हैं।
स्केल पर सवाल बन जाता है थ्रूपुट प्रति वॉट और उपयोगिता प्रति एक्सेलेरेटर-घंटा। टीमें जॉब्स का साइज सही-से-निर्धारित करने लगती हैं, वर्कलोड्स पैक करती हैं, और प्रिसिशन/पैरालेलिज़्म सेटिंग्स चुनती हैं जो आवश्यक गुणवत्ता पा कर क्षमता बर्बाद न करें।
एक एक्सेलेरेटर फ़्लीट चलाना भी क्षमता योजना और विश्वसनीयता इंजीनियरिंग माँगता है: दुर्लभ डिवाइस हैंडलिंग, प्रीएम्प्शन्स, फेल्यर्स मॉनिटरिंग, और डिजाइनिंग ट्रेनिंग ताकि वह स्क्रैच से फिर से शुरू करने के बजाय ग्रेसफुली रिकवर कर सके।
जेफ डीन का प्रभाव केवल तेज़ कोड लिखने तक सीमित नहीं था—यह इस बात को आकार देना भी था कि जब सिस्टम किसी एक व्यक्ति के समझ से बड़े हो जाएँ तो टीमें कैसे निर्णय लें।
स्केल पर, आर्किटेक्चर किसी एक डायग्राम द्वारा निर्देशित नहीं होता; इसे उन सिद्धांतों द्वारा मार्गदर्शित किया जाता है जो डिज़ाइन रिव्यू और रोज़मर्रा के चुनावों में दिखते हैं। नेताओं जो लगातार कुछ ट्रेडऑफ़्स को इनाम देते हैं—सादगी को चालाकी पर, स्पष्ट स्वामित्व को "सबका स्वामित्व" पर, विश्वसनीयता को वन-ऑफ स्पीडअप्स पर—वे धीरे-धीरे पूरे संगठन के लिए डिफ़ॉल्ट आर्किटेक्चर सेट कर देते हैं।
एक मजबूत रिव्यू संस्कृति इसका हिस्सा है। "गोटचा" रिव्यू नहीं, पर ऐसे रिव्यू जो अनुमानित प्रश्न पूछते हैं:
जब ये प्रश्न नियमित होते हैं, टीमें ऐसे सिस्टम बनाती हैं जिन्हें ऑपरेट करना और विकसित करना आसान होता है।
एक आवर्ती नेतृत्व चाल है दूसरों के समय को सबसे मूल्यवान संसाधन मानना। मंत्र "दूसरों के लिए आसान बनाइए" व्यक्ति की उत्पादकता को संगठनात्मक थ्रूपुट में बदल देता है: बेहतर डिफ़ॉल्ट्स, सुरक्षित APIs, स्पष्ट एरर मैसेज, और कम छिपी निर्भरताएँ।
यही तरीका है जिससे प्लेटफ़ॉर्म आंतरिक रूप से जीतते हैं। अगर पाइव्ड रोड सचमुच चिकनी है, तब अपनाना बिना आदेश के आता है।
डिज़ाइन डॉक्स और स्पष्ट इंटरफेस बाबत नौकरशाही नहीं हैं; वे टीमों और समय के पार इरादा संप्रेषित करने का तरीका हैं। एक अच्छा डॉक असहमति को उत्पादक बनाता है ("कौन सा अनुमान गलत है?") और फिर-से-काम को घटाता है। एक अच्छा इंटरफेस सीमाएँ खींचता है जो कई टीमों को समानांतर में शिप करने देती हैं बिना एक-दूसरे पर कदम रखे।
यदि आप एक सरल शुरुआत चाहते हैं, एक हल्का टेम्पलेट स्टैंडर्डाइज़ करें और उसे /blog/design-doc-template पर सुसंगत रखें।
लोगों को स्केल करना निर्णयशीलता के लिए हायर करना है, सिर्फ तकनीकी ट्रिविया के लिए नहीं, और मेंटर करना ऑपरेशनल परिपक्वता के लिए: दबाव में डिबग कैसे करें, सिस्टम को सुरक्षित रूप से कैसे सरल करें, और जोखिम कैसे संप्रेषित करें। लक्ष्य एक ऐसी टीम है जो महत्वपूर्ण इन्फ्रास्ट्रक्चर को शांति से चला सके—क्योंकि शांत टीमें कम अपरिवर्तनीय गलतियाँ करती हैं।
जेफ डीन की कहानी अक्सर एक "10x इंजीनियर" नरेटिव में सरल कर दी जाती है: एक व्यक्ति जो दूसरों से तेज़ टाइप करता है और एकल-हाथों से स्केल का आविष्कार कर देता है। वह उपयोगी हिस्सा नहीं है।
हस्तांतरित योग्य सबक कच्चे आउटपुट नहीं बल्कि लीवरेज है। सबसे मूल्यवान काम वह है जो अन्य इंजीनियरों को तेज़ बनाता और सिस्टम्स को सुरक्षित करता: स्पष्ट इंटरफेस, साझा टूलिंग, कम फूटगन्स, और ऐसे डिज़ाइन जो उम्र के साथ बेहतर हों।
जब लोग किंवदंती-समान उत्पादकता की ओर संकेत करते हैं, वे अक्सर छिपे गुणकों को अनदेखा करते हैं: सिस्टम की गहरी परिचितता, अनुशासित प्राथमिकताकरण, और उन परिवर्तनों के प्रति झुकाव जो भविष्य का काम घटाते हैं।
कुछ आदतें उन टीमों में बार-बार दिखाई देती हैं जो स्केल करती हैं:
इन आदतों के लिए गूगल-आकार के इंफ्रास्ट्रक्चर की ज़रूरत नहीं होती; निरंतरता की आवश्यकता होती है।
हीरो कहानियाँ असल कारण छिपा सकती हैं कि चीज़ें कैसे चलीं: सावधान प्रयोग, मजबूत रिव्यू संस्कृति, और विफलता के लिए डिज़ाइन किए सिस्टम। "किसने बनाया?" पूछने के बजाय पुछें:
आपको कस्टम हार्डवेयर या ग्रह-स्तरीय डेटा की ज़रूरत नहीं। एक उच्च-लीवरेज बाधा चुनें—धीमी ट्रेनिंग, नाजुक पाइपलाइंस, ताक़लीफदेह डिप्लॉय्स—और उसमें छोटे प्लेटफ़ॉर्म सुधार में निवेश करें: मानकीकृत जॉब टेम्पलेट्स, साझा मैट्रिक्स पैनल, या हल्का "गोल्डन पाथ"।
एक कम सराहना किया गया एक्सेलेरेटर "इन्फ्रास्ट्रक्चर UI" गैप को छोटा करना है। जब आंतरिक टूलिंग बनाने में समय लगता है, टीमें इसे नहीं बनातीं—और फिर मैन्युअल ऑपरेशन्स में हमेशा के लिए भुगतान करती हैं। Koder.ai जैसे टूल्स आपको प्लेटफ़ॉर्म और प्रोडक्ट सतहों को तेज़ी से शिप करने में मदद कर सकते हैं (ऑप्स कंसोल्स, डेटा लेबलिंग ऐप्स, रिव्यू वर्कफ़्लोज़), स्नैपशॉट/रोलबैक और डिप्लॉयमेंट/होस्टिंग जैसी सुविधाओं के साथ जो इटरेटिव प्लेटफ़ॉर्म इंजीनियरिंग का समर्थन करती हैं।
जेफ डीन का काम यह याद दिलाता है कि “एआई को स्केल करना” ज्यादातर दोहराने योग्य इंजीनियरिंग है: एक-ऑफ मॉडल जीतों को डेटा, ट्रेनिंग, इवैल्यूएशन, और डिप्लॉयमेंट की एक भरोसेमंद फैक्टरी में बदलना।
वो उबाऊ हिस्से से शुरू करें जो हर भविष्य के प्रोजेक्ट का गुणा करते हैं:
अधिकांश स्केलिंग विफलताएँ “हमें और GPUs चाहिए” नहीं होतीं। सामान्य अवरुद्धताएँ हैं:
डेटा क्वालिटी डेट: लेबल्स ड्रिफ्ट करते हैं, परिभाषाएँ बदलती हैं, और मिसिंग वैल्यूज़ दरारें डालते हैं। सुधारों को हीरोज़ नहीं बल्कि स्वामित्व और SLA की ज़रूरत होती है।
इवैल्यूएशन गैप्स: टीमें एकल ऑफ़लाइन मैट्रिक पर निर्भर रहती हैं और फिर प्रोडक्शन में आश्चर्यचकित होती हैं। रीजन, डिवाइस, कस्टमर सेगमेंट जैसे स्लाइस-आधारित रिपोर्टिंग जोड़ें और गो/नो-गो थ्रेशहोल्ड परिभाषित करें।
डिप्लॉयमेंट ड्रिफ्ट: ट्रेनिंग एक तरह की फीचर कैलकुलेशन उपयोग करती है, सर्विंग दूसरी। इसे साझा फीचर कोड, एंड-टू-एंड टेस्ट, और पुनरुत्पाद्य बिल्ड्स से ठीक करें।
इन्फ्रास्ट्रक्चर और वर्कफ़्लो मानक चुनें जो समन्वय लागत को घटाते हों: कम बिस्पोक पाइपलाइंस, कम छिपी डेटा धारणाएँ, और स्पष्ट प्रमोशन नियम। ये चुनाव गुणा करते हैं—हर नया मॉडल सस्ता, सुरक्षित, और तेज़ होने लगता है।
"स्केलिंग एआई" का मतलब वास्तविक सीमाओं में एमएल को दोहراتा और भरोसेमंद बनाना है:
यह एक सिंगल मॉडल ट्यून करने से अधिक, एक असेंबली लाइन बनाने जैसा है।
क्योंकि कई एमएल विचार तभी मूल्यवान बनते हैं जब वे बड़े डेटा और ट्रैफिक पर भरोसेमंद, बार-बार और सस्ते तौर पर चल सकें।
असर अक्सर “मिडल लेयर” में होता है:
रिसर्च प्रोटोटाइप को प्रोडक्शन वर्कलोड में बदलना
पाइपलाइंस और इंटरफेस को स्टैंडर्ड करना ताकि कई टीमें शिप कर सकें
सिस्टम डिजाइन करना जो फेलियर और ऑपरेशनल नॉइज़ सह सके
फ्लीट स्तर पर विफलता असामान्य नहीं, सामान्य है। आम शुरुआती बिंदु शामिल हैं:
रीकवरी के लिए डिजाइन (रीट्राय, चेकपॉइंट, बैकप्रेशर) अक्सर अकेले हाई-पिक मशीन स्पीड से ज्यादा मायने रखता है।
MapReduce ने बड़े बैच प्रोसेसिंग को मानक और जीवित रहने योग्य बनाया:
आधुनिक टूल (Spark/Flink/Beam और क्लाउड ETL) फीचर में अलग हैं, पर मूल सबक वही है: समानांतरता और रीट्राय को डिफ़ॉल्ट बनाइए।
Bigtable एक wide-column स्टोर है जिसे उच्च थ्रूपुट और अनुमाननीय लेटेंसी के लिए डिजाइन किया गया है। मुख्य बिंदु:
एमएल के लिए, अनुमानित डेटा एक्सेस प्रशिक्षण शेड्यूल और प्रयोगों को पुनरुत्पादित करना आसान बनाता है।
स्टोरेज विकल्प यह तय करते हैं कि आप किस डेटा पर भरोसे के साथ ट्रेन कर सकते हैं:
संक्षेप: स्थिर स्टोरेज अक्सर तय करता है कि एमएल एक प्रोडक्ट कैपेबिलिटी बनेगा या बार-बार आग बुझाने का काम।
ट्रेनिंग स्टेटफुल और Итरेटिव होती है, इसलिए समन्वय कठिन है:
व्यवहारिक दृष्टिकोण: एंड-टू-एंड समय को मापें, टोपोलॉजी को सरल रखें, और असली बोतलनेक मिलने के बाद ही जटिल ऑप्टिमाइज़ेशन जोड़ें।
एक साझा प्लेटफॉर्म “हीरो वर्कफ़्लोज़” को पाइव्ड रोड में बदल देता है:
यह नकल और अनुकूलन को कम करता है और टीमों के बीच परिणामों की तुलना-सक्षमता बढ़ाता है—जो अक्सर किसी सिंगल मॉडल ट्रिक से ज्यादा इटरेशन स्पीड बढ़ाता है।
स्टैंडर्डाइज़ेशन समन्वय लागत घटाता है:
TensorFlow के बाहर भी सबक लागू होता है: थोड़ी-सी धुरी चुनें, उसे अच्छी तरह डोक्यूमेंट करें, और मानक पाथ को आसान बनाइए।
आपको गूगल-स्केल संसाधनों की ज़रूरत नहीं है:
अगर टीमों को संरेखित करने के लिए हल्का उपकरण चाहिए, तो /blog/design-doc-template जैसे सुसंगत डिज़ाइन डॉक टेम्पलेट से शुरू करें।