30PB हार्ड ड्राइव के साथ प्रीट्रेनिंग के लिए स्टोरेज क्लस्टर बनाना

• कंप्यूटर उपयोग समस्या-समाधान के लिए मॉडल प्रीट्रेनिंग हेतु 9 करोड़ घंटे के वीडियो डेटा स्टोरेज को लक्ष्य बनाकर सैन फ्रांसिस्को के डाउनटाउन में सीधे स्टोरेज क्लस्टर का निर्माण किया गया
• on-premise तरीके को चुनकर सालाना $354k (50 करोड़ वोन) में 30PB स्टोरेज इन्फ्रास्ट्रक्चर चलाना संभव हुआ। AWS पर यही लागत $12m (170 करोड़ वोन) होती, यानी लगभग 34 गुना लागत बचत
• अधिकांश public cloud के विपरीत high availability और integrity पर ज़ोर नहीं दिया गया, और training data की प्रकृति के अनुसार डेटा लॉस सहनशीलता की रणनीति अपनाई गई
• सरल Rust और Nginx आधारित सॉफ्टवेयर से संचालन किया जा रहा है, और Ceph या MinIO जैसे जटिल सिस्टम की जगह खुद का बनाया 200-लाइन का प्रोग्राम इस्तेमाल हो रहा है
• प्रोजेक्ट के दौरान फिजिकल लेआउट, नेटवर्क कॉन्फ़िगरेशन, केबल मैनेजमेंट जैसी कई वास्तविक चुनौतियों और व्यावहारिक सीखों का अनुभव हुआ

---

परिचय और पृष्ठभूमि

• कंप्यूटर उपयोग के लिए मॉडल प्रीट्रेनिंग में बहुत बड़े पैमाने के वीडियो डेटा की ज़रूरत होती है
• सामान्य text LLM (जैसे LLaMa-405B) के लिए लगभग 60TB डेटा पर्याप्त हो सकता है, लेकिन video-based training के लिए 500 गुना अधिक स्टोरेज चाहिए
• AWS जैसे public cloud का उपयोग करने पर सालाना $12 million खर्च होते, लेकिन colocation center किराए पर लेकर और खुद निर्माण करके इसे लगभग $354k तक घटाया गया
• बड़े पैमाने का डेटा स्वयं संग्रहीत करके उस समस्या को हल किया गया जिसमें डेटा लागत सबसे बड़ी बाधा थी

खुद निर्माण क्यों किया गया

• cloud का फोकस high reliability, redundancy, data integrity पर होता है, लेकिन प्रीट्रेनिंग डेटा इतना critical नहीं था कि 5% loss भी स्वीकार न हो
• इसी वजह से सामान्य enterprise की तुलना में कहीं अधिक ढीली reliability requirements चुनी जा सकीं (13 nines reliability की जगह 2 nines)
• स्टोरेज की कीमतें वास्तविक लागत की तुलना में बहुत अधिक तय की जाती हैं
• डेटा सबसे बड़ा लागत घटक था, और अनुमानित सीमा के भीतर local datacenter बनाना अधिक फायदेमंद माना गया

लागत तुलना: cloud बनाम self-build

• मासिक recurring cost: internet $7,500 + electricity $10,000 = कुल $17,500
• one-time cost: hard drive $300,000, chassis $35,000, CPU node $6,000, installation fee $38,500, labor $27,000, network और अन्य installation cost $20,000 → कुल $426,500
• 3 साल की depreciation सहित मासिक fixed cost $29,500 निकाली गई
• AWS $1,130,000/माह, Cloudflare R2 $270,000/माह, self-build $29,500/माह
  • AWS: लगभग $38 प्रति TB/माह
  • Cloudflare: लगभग $10 प्रति TB/माह
  • self-build: $1 प्रति TB/माह
• बड़े पैमाने के मॉडल प्रशिक्षण में Cloudflare पर भी internal system load के कारण rate-limit समस्या आई, जबकि अपने वातावरण में 100Gbps dedicated line से यह समस्या हल हो गई

निर्माण और प्रक्रिया

• तेज निर्माण के लिए Storage Stacking Saturday(S3) योजना बनाई गई, जिसमें परिचितों की मदद और पेशेवर contractors को लगाया गया
• 36 घंटे के भीतर 2,400 hard drive रैक में लगाकर 30PB हार्डवेयर तैयार किया गया
• सॉफ्टवेयर: Rust (write, 200 lines) + nginx (read) + SQLite (metadata tracking)
  • Ceph, MinIO, Weka, Vast आदि को complexity/cost के कारण उपयोग नहीं किया गया (जटिलता, आवश्यकता की कमी, maintenance burden आदि)
  • सभी drives को XFS में format किया गया

प्रोजेक्ट फीडबैक और सीख

क्या अच्छा रहा

• redundancy/performance trade-off को सही ढंग से लागू करके 100G network का लगभग पूरा उपयोग किया गया
• भौतिक रूप से नज़दीक निर्माण करने से debugging और maintenance में आसानी मिली
• vendors eBay पर मिले, लेकिन वास्तविक खरीद व्यक्तिगत suppliers से direct की गई; warranty की आवश्यकता पर ज़ोर दिया गया
• 100G internet line के कई फायदे रहे, और network issues का self-debugging भी आसान रहा
• उच्च-गुणवत्ता cable management ने बाद में समस्या-समाधान में बहुत मदद की
• जटिल open source storage systems की बजाय सरलता के सिद्धांत को अपनाकर maintenance burden कम रखा गया
• समय और labor cost का अनुमान भी सही निकला, और बचत का प्रभाव स्पष्ट रूप से साबित हुआ

मुश्किलें और ट्रायल-एंड-एरर

• front loader के उपयोग के कारण 2,400 HDD एक-एक करके हाथ से लगानी पड़ीं
• स्टोरेज density कम रही; यदि शुरुआती डिज़ाइन में अधिक density ली जाती तो labor और कम हो सकता था
• daisy-chain ने speed bottleneck पैदा किया; आदर्श रूप से हर chassis के लिए अलग HBA कनेक्शन होना चाहिए
• network components में brand compatibility महत्वपूर्ण है, खासकर optical transceiver
• network configuration के प्रयोग और setup में समय लगा; DHCP/NAT की जगह performance और सुविधा-केंद्रित configuration चुना गया (firewall/secure link की न्यूनतम शर्तें ही लागू की गईं)
• physical accessibility और setup के समय monitor/keyboard wiring की अहमियत का एहसास हुआ

आज़माने लायक विचार

• KVM और IPMI के उपयोग से remote management अधिक कुशल बनाया जा सकता है
• अलग admin Ethernet network बनाने की सिफारिश
• network overprovisioning (जैसे 400G internal network) पर भी विचार किया जा सकता है
• अधिक density वाले server (90-drive Supermicro/20TB HDD आदि) से
  rack count कम करना, बिजली बचत, CPU consolidation जैसे फायदे मिल सकते हैं

इसे खुद कैसे बनाया जा सकता है

स्टोरेज कॉन्फ़िगरेशन

• 10 CPU head node (Intel RR2000 आदि, प्रति server dual Intel Gold 6148/128GB ECC DDR4 RAM की सिफारिश)
  • CPU-intensive features (जैसे ZFS) के लिए अधिक performant hardware चुना जा सकता है
• 100 DS4246 chassis (प्रत्येक में 24 HDD)
• 2,400 3.5" HDD (संभव हो तो SAS drive की सिफारिश, speed advantage के कारण)
  • विभिन्न capacities (12TB, 14TB आदि) का मिश्रण; जितनी बड़ी capacity, deployment और resale value उतनी बेहतर
• physical mounting के लिए rails/brackets, equipment wiring और cables
• network issue debugging के लिए कई crash cart (monitor + keyboard)

नेटवर्क इन्फ्रास्ट्रक्चर

• 100GbE switch (used Arista आदि, QSFP28 ports)
• प्रति server HBA (सिफारिश: Broadcom 9305-16E आदि), HBA port/chassis connection method
• network card (Mellanox ConnectX-4 आदि, अनिवार्य रूप से Ethernet mode)
• DAC/AOC cable—रैक के बीच दूरी को देखते हुए DAC में compatibility advantage हो सकता है
• CPU head node खरीदते समय HBA/NIC pre-installed supplier का उपयोग करने की सिफारिश
• serial cable, अलग management Ethernet network (backup के लिए wireless adapter + mini switch विकल्प)

डेटा सेंटर आवश्यकताएँ

• प्रति cabinet 3.5kW बिजली उपयोग, 42U मानक पर 4U×10 + 2U×1 कॉन्फ़िगरेशन मानकर
• 3PB/cabinet, switch के लिए एक अतिरिक्त 42U cabinet या chassis 1U विकल्प
• dedicated 100G cross-connect (आमतौर पर QSFP28 LR4 optical pair), form factor और brand compatibility की पहले से जाँच आवश्यक
• ऑफिस के पास की location (colocation) की सिफारिश, ताकि समस्या आने पर तेज physical response संभव हो और debugging/operational productivity बेहतर हो

शुरुआती सेटअप टिप्स

• switch का पहला local console configuration करने के बाद, 100GbE uplink port setup और optical transceiver compatibility पहले सत्यापित करें
  • ज़रूरत पड़ने पर ISP optical line को सीधे NIC से जोड़कर पहले link-up की पुष्टि करें, फिर switch पर ले जाएँ
• Ubuntu installation के दौरान Netplan से node networking सेट कर लेना आसान रहता है
• nodes के internet से जुड़ने के बाद, हर DS4246 को 1-cable connection → format/mount → health check क्रम में सेट करें ताकि wiring और disk faults जल्दी पकड़ में आ जाएँ

प्रदर्शन, स्थिरता और सुरक्षा संबंधी सावधानियाँ

• केवल training data के लिए होने की security assumption के तहत public IP direct connection + port firewall + nginx secure_link से सरल संचालन किया गया
  • customer data संभालने की स्थिति में यही configuration उपयुक्त नहीं है; DHCP/NAT/granular firewall अनिवार्य हैं
• daisy-chain management और wiring को आसान बनाता है, लेकिन bandwidth bottleneck पैदा करता है; संभव हो तो प्रति chassis dedicated HBA की सिफारिश
• optical transceiver में brand lock-in बहुत होता है; FS.com और Amazon दोनों से sourcing करते समय spec और brand match की कड़ी जाँच ज़रूरी है

निष्कर्ष और महत्व

• $1/TB-month स्तर के अत्यंत कम-लागत self-storage से 30PB video pretraining को व्यावहारिक बनाया गया, और cloud की तुलना में 10–38 गुना लागत बचत हासिल की गई
• सरल architecture और on-site accessibility ने समय और जोखिम दोनों को घटाया, जबकि 100G dedicated line ने I/O bottleneck दूर किया
• बड़े पैमाने के multimodal और video model युग में कम-लागत, बड़े पैमाने का data infrastructure एक मुख्य प्रतिस्पर्धी क्षमता है, और यह तरीका कम लोगों की टीम द्वारा भी लागू किए जा सकने वाला व्यावहारिक reference देता है

समापन और सहयोग आमंत्रण

• यदि इस लेख को देखकर आपने ऐसा ही storage cluster बनाया है, तो सुधार बिंदु और अनुभव साझा करने का अनुरोध है
• बड़े पैमाने के computer-use model pretraining तथा generalization और human values से जुड़े AI research के लिए hiring जारी है (संपर्क: [e-mail])

[GN⁺]

Hacker News की राय

• जब मैंने अपने करियर की शुरुआत की थी, तब on-premises माहौल सामान्य बात था। जो हार्डवेयर लंबे समय तक चलता था, उससे लगाव हो जाता था और हर सर्वर की अपनी स्थिति समय के साथ जमा होती जाती थी। बाद में जब हार्डवेयर की क्षमता कम पड़ने लगती, तो अंदरूनी टीम के जरिए मौजूदा सूची में से नया हार्डवेयर चुनना पड़ता, अतिरिक्त खर्च की मंजूरी लेनी पड़ती, और यह सब काफ़ी झंझट भरा होता। हार्डवेयर बदलने की प्रक्रिया, या पालतू जानवर की तरह संभालकर रखे गए उपकरण को पूरी तरह अलग करके नए उपकरण पर जाना, कई बार प्रोजेक्ट में देरी भी करा देता था। फिर cloud आया और लगा कि “अब तो हर हाल में cloud पर जाना चाहिए।” लेकिन समय के साथ व्यक्ति और संगठन दोनों खुद हार्डवेयर संभालने का तरीका भूलने लगते हैं, और अगर उस कौशल को फिर से ज़िंदा न किया जाए तो जो cloud कभी अच्छा विकल्प लगता था, वही धीरे-धीरे कम आकर्षक लगने लगता है। इसलिए यह कौशल फिर से विकसित करने का मौका देने के लिए धन्यवाद

  • हमारी स्थिति थोड़ी अलग है। शुरुआत से ही hyperscale cloud का ऑपरेटिंग खर्च उठाना हमारे लिए संभव नहीं था, इसलिए मजबूरी में हमें अपनी तकनीकी क्षमता खुद विकसित करनी पड़ी। यह उम्मीद से इतना कठिन नहीं निकला, और फिलहाल हम इसी तरीके पर टिके रहने वाले हैं। हालांकि, आपने जिस state accumulation समस्या का ज़िक्र किया, वह थोड़ा दिखने लगी है

  • मेरी याद में on-premises हमेशा लागत के हिसाब से सस्ता था। कई लॉजिस्टिक बाधाएँ हट जाती थीं और एक ही बिल में सुविधा मिल जाती थी। जब cloud बहुत चर्चा में था, तब सलाह हमेशा यही होती थी कि मूल रूप से on-premises इस्तेमाल करो और सिर्फ़ अचानक ट्रैफ़िक बढ़ने-घटने पर cloud लो। लेकिन अस्थायी scaling धीरे-धीरे स्थायी इस्तेमाल बन गई, और developers नई machine तुरंत spin up करने की आदत पर निर्भर हो गए। अब सब लोग cloud को ही default state मानते हैं। इस प्रक्रिया में हमने वास्तविक लागत को ठीक से महसूस करने की बुनियाद खो दी, और cloud व on-premises के बीच लागत का अंतर और बढ़ता गया

  • Docker सर्वरों को पालतू चीज़ की तरह नहीं रहने देता, और यह बहुत शानदार टूल है। rack में रखा सर्वर बस एक और K3 या K8 node बन जाता है, इसलिए उसे pet की तरह treat नहीं किया जाता। यही बात मुझे बहुत पसंद है। VM के बारे में भी कुछ हद तक यही कहा जा सकता है, लेकिन आख़िर में VM खुद pet बन जाता है। बेशक image बनाना या snapshot लेना संभव है, पर Docker वाला बदलाव अलग महसूस होता है

  • क्या एक बार फिर ऐसा चैलेंज लिया जाए — यह एक मज़ाकिया सवाल था

• जिस startup के पास इतना पैसा हो कि वह बिना झिझक .inc का दो-अक्षरी domain खरीद ले, उसके पास शायद ज़रूरत से ज़्यादा फंडिंग है। यह कुछ वैसा ही है जैसे पुराने startups में दफ़्तर में कितनी Aeron chairs हैं, यह गिनकर अंदाज़ा लगाना। अच्छा संकेत नहीं है

  • unused दो-अक्षरी .inc domain सालाना $2300 में बिक रहे हैं, जो एक developer की कुल लागत का 5% भी नहीं है

  • मुझे शक है कि .inc domain name की कोई वास्तविक वैल्यू है भी या नहीं

• मज़ेदार लेख था, पढ़ते हुए परोक्ष संतोष मिला। अगर इसमें और तस्वीरें होतीं तो यह अनुभव और भी मज़ेदार होता

  • अगर लेखक लोग comments में आएँ, तो मैं सीधे पूछना चाहूँगा कि Standard Intelligence PBC असल में क्या करता है। क्या यह Public Benefit Corporation है, या वे कोई खास project कर रहे हैं?

• तकनीकी बातों को विस्तार से लिखा गया था, यह अच्छा लगा। मेरी जिज्ञासा यह है कि colocation space ढूँढने की प्रक्रिया कैसी रही। क्या broker का इस्तेमाल किया गया था, और शुरुआती quote की तुलना में असली भुगतान कितना अलग था?

  • हमने San Francisco और Fremont के ज़्यादातर colocation providers से quote माँगे थे। quote और वास्तविक भुगतान में कोई अंतर नहीं था, लेकिन terms और one-time costs पर बातचीत हुई थी

• लिंक किया गया Discord blog post भी दिलचस्प है। ज़्यादातर बातें गंभीर हैं, लेकिन उसमें यह मज़ेदार हिस्सा भी था: World Cup में गोल होते ही उसका असर monitoring graph पर तुरंत दिख जाता था, जिससे टीम के लोग meeting के दौरान football मैच देखने को काम के monitoring के बहाने छिपा सकते थे। इसे इस दावे के संदर्भ में भी उद्धृत किया गया था कि Discord “petabyte से कम” storage में messages रखता है। अनुमान के हिसाब से, इस पोस्ट में बताए गए node size और संख्या से पुराना cluster लगभग 708TB और नया setup लगभग 648TB निकलता है, (growth headroom सहित)

• storage अपने आप में बहुत सस्ता है। लेकिन training और networking setup वाला हिस्सा मेरी समझ में नहीं आ रहा। दूसरे comments में सुना कि GPUs एक ही जगह पर नहीं हैं, तो फिर अलग-अलग sites के बीच केवल 100Gbps पर training data इधर-उधर भेजना होगा। इससे pretraining के दौरान bottleneck बनने की चिंता होती है

  • अभी हमारे पास सिर्फ़ एक 100 gigabit link है, और फिलहाल GPU clusters भी लगभग उतना ही data भेज-ले पा रहे हैं। आगे scale करते समय bandwidth और storage दोनों बढ़ाने की योजना है। वैसे colo के भीतर कई 4090 भी हैं, जो data sharding या embedding कामों में बहुत उपयोगी रहे

• अगर workload का आकार ऐसा है, तो AWS या दूसरे clouds से private quote काफ़ी आसानी से मिल सकता है। S3 के मामले में 0.5PB पर भी अलग quote मिल सकता है। इससे यह साबित नहीं होता कि कुल लागत खुद मैनेज करने से कम होगी, लेकिन CSP की retail pricing और eBay से खरीदे गए hardware + free labor (pizza cost को छोड़कर) की तुलना पूरी तरह निष्पक्ष नहीं है

  • AWS या cloud में egress cost ही असली मुद्दा है। उस हिस्से में negotiation की कोशिश करो तो भी वे बिल्कुल नरमी नहीं दिखाते। AI training के लिए तो यह लगभग उपयोग लायक ही नहीं है। Cloudflare का quote managed object bucket storage में अपेक्षाकृत सस्ता है। खुद का cluster बनाने पर managed service से अंतर कुछ कम हो गया, और self-hosting कुछ negotiation leverage भी देता है। लेकिन managed buckets सिर्फ़ pretraining storage के लिए ज़रूरत से ज़्यादा overkill हैं। Glacier archive के लिए cost-effective है, लेकिन ML workload के लिए अभी बिल्कुल फिट product नहीं है

  • खास तौर पर किस स्तर की deal मिल सकती है, यह जानने की जिज्ञासा है। क्या 50% से ज़्यादा discount भी संभव है?

• drives लगाने का काम साथ में करना बहुत मज़ेदार था। इतने बड़े पैमाने पर data को वास्तव में संभालना सबसे रोमांचक अनुभवों में से एक है :P

• disk failure rate का कोई ज़िक्र नहीं था। कुछ महीनों बाद इसकी स्थिति कैसी है, यह जानना दिलचस्प होगा

  • मैंने पहले भी ऐसा अनुभव साझा किया है। कई disk arrays एक साथ लाते समय बड़े पैमाने पर drive failures हुए थे। शुक्रवार दोपहर rack setup किया, फिर पूरे weekend बिना छुए एक साधारण shell script से data read/write test चलने दिया। सोमवार को लौटकर देखा तो लगभग आधी disks खराब हो चुकी थीं और कोई logs भी नहीं थे। पता नहीं striping process में गड़बड़ी थी या stress test में वे फेल हुईं। वह factory defect वाली batch निकली, और उसी कंपनी के कई ग्राहकों ने शिकायत की थी। manufacturer ने सब कुछ बदलकर दिया, बस production deployment में देरी हुई। उसके बाद एक साल तक कोई failure नहीं हुआ

  • पिछले 10 साल पहले की तुलना में हाल के वर्षों में disk failure rate बहुत कम हुआ है। पहले हफ़्ते में 10 से ज़्यादा बदलने पड़ते थे, अब यह बहुत कम होता है। मुझे लगता है कि Backblaze की hard drive statistics देखना काफ़ी है

  • उस cluster में enterprise drives इस्तेमाल होने की बात कही गई थी, और अगर लागत बचाने के लिए गलत कटौती की जाए तो बाद में बड़ा नुकसान हो सकता है। मैंने निजी तौर पर home server के लिए used drives आज़माई थीं, लेकिन performance variance इतना ज़्यादा था कि अनुभव अच्छा नहीं रहा

  • अच्छा बिंदु है