क्लाउड किराए पर मत लें, उसे खुद अपना बनाइए

 (blog.comma.ai)
11 पॉइंट द्वारा GN⁺ 2026-02-06 | 3 टिप्पणियां | WhatsApp पर शेयर करें
  • CommaAI अपने सभी मॉडल ट्रेनिंग और डेटा प्रोसेसिंग अपने ही डेटासेंटर में करता है, और लगभग $5 million के इन्फ्रास्ट्रक्चर को सीधे संचालित कर रहा है
  • क्लाउड पर निर्भरता बढ़ती लागत और नियंत्रण के नुकसान तक ले जा सकती है, जबकि अपना compute चलाने से इंजीनियरिंग क्वालिटी में सुधार और लागत में कमी संभव होती है
  • डेटासेंटर में लगभग 450kW बिजली, 600 GPU, 4PB SSD स्टोरेज, और सरल cooling व network संरचना शामिल है
  • सॉफ़्टवेयर स्टैक Ubuntu + Salt, minikeyvalue(mkv) स्टोरेज, Slurm scheduler, PyTorch distributed training, और miniray distributed compute पर डिज़ाइन किया गया है
  • comma.ai इस संरचना के जरिए स्वायत्त ड्राइविंग मॉडल ट्रेनिंग को पूरी तरह ऑटोमेट करता है, और क्लाउड की तुलना में लगभग 5 गुना लागत बचत हासिल करता है

अपना डेटासेंटर चलाने के कारण

  • क्लाउड पर निर्भरता से लागत बढ़ना और vendor lock-in पैदा होता है
    • क्लाउड कंपनियां onboarding आसान, लेकिन offboarding मुश्किल होने के लिए डिज़ाइन की जाती हैं
    • लगातार उपयोग करने पर ऊंची लागत वाली संरचना में फंसना आसान होता है
  • अपना compute चलाना तकनीकी आत्मनिर्भरता और अधिक कुशल इंजीनियरिंग संस्कृति को बढ़ावा देता है
    • क्लाउड में API और billing सिस्टम-केंद्रित मैनेजमेंट चाहिए, जबकि डेटासेंटर में बिजली·कंप्यूट·bandwidth जैसे वास्तविक तकनीकी समस्याओं को हल करना पड़ता है
  • ML engineering के नज़रिए से भी संसाधनों की सीमाएं कोड optimization और बुनियादी सुधारों को प्रेरित करती हैं
    • क्लाउड में आमतौर पर बजट बढ़ाकर समस्या हल की जाती है, लेकिन अपनी infrastructure में performance improvement अनिवार्य होता है
  • लागत के लिहाज से comma.ai ने लगभग $5 million निवेश किया, जबकि वही काम क्लाउड में करने पर $25 million से अधिक की जरूरत पड़ती, ऐसा उसका अनुमान है

डेटासेंटर के घटक

  • बिजली

    • अधिकतम 450kW उपयोग, 2025 की बिजली लागत $540,112
    • San Diego की बिजली दर 40 cents/kWh है, जो वैश्विक औसत से लगभग 3 गुना है
    • आगे अपना बिजली उत्पादन करने की योजना का उल्लेख

  • cooling

    • बाहरी हवा से cooling का उपयोग, जो CRAC सिस्टम की तुलना में अधिक power-efficient है
      • हवा के संचार के लिए 48-inch intake/exhaust fan 2-2 लगाए गए हैं
      • PID control loop से तापमान और आर्द्रता का स्वचालित नियंत्रण (<45% बनाए रखना)
      • बिजली खपत दर्जनों kW के स्तर पर

  • सर्वर और स्टोरेज

    • TinyBox Pro की 75 मशीनें (कुल 600 GPU), जिन्हें खुद बनाया गया है
      • हर मशीन में 2 CPU + 8 GPU, और इन्हें training व सामान्य compute के लिए उपयोग किया जाता है
      • खुद निर्माण करने से maintenance आसान होता है
    • स्टोरेज Dell R630/R730 आधारित, कुल 4PB SSD
      • non-redundant संरचना, प्रति node 20Gbps read speed
    • नेटवर्क में 100Gbps Z9264F switch 3 और Infiniband switch 2 शामिल हैं

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

  • बेसिक सेटअप

    • सभी सर्वर Ubuntu + PXE boot पर चलते हैं, और Salt से मैनेज होते हैं
    • single master संरचना के साथ 99% uptime बनाए रखा जाता है

  • distributed storage — minikeyvalue (mkv)

    • 3PB non-redundant storage में training के लिए driving data रखा जाता है
      • 1TB/s read speed, caching के बिना सीधे training संभव
    • 300TB cache array, और redundant storage array में model व metrics रखे जाते हैं
    • हर array को single master server से मैनेज किया जाता है

  • job management — Slurm

    • PyTorch training jobs और miniray distributed jobs को schedule करता है

  • distributed training — PyTorch + FSDP

    • Infiniband network से जुड़े दो training partition चलाए जाते हैं
    • अपने training framework से training loop automation किया गया है
    • model experiment tracking service भी उपलब्ध है

  • distributed compute — miniray

    • हल्का open source task scheduler, जो idle मशीनों पर Python code चलाता है
      • Dask से सरल, और Redis central server के जरिए tasks मैनेज करता है
      • GPU worker Triton Inference Server से model inference करते हैं
    • सैकड़ों मशीनों तक parallel scale-out संभव
      • उदाहरण: Controls Challenge record डेटासेंटर के 1 घंटे के उपयोग से हासिल किया गया

  • code management — NFS-आधारित monorepo

    • पूरा codebase 3GB से कम, और हर workstation पर replicated है
    • काम शुरू होने पर local code और packages sync होते हैं, और यह 2 सेकंड के भीतर पूरा हो जाता है
    • इससे सुनिश्चित होता है कि सभी distributed jobs एक ही code और environment में चलें

एकीकृत training pipeline

  • comma में सबसे जटिल काम on-policy तरीके से driving model को train करना है
  • इसके लिए नवीनतम model weights लागू करके simulated driving चलानी पड़ती है, ताकि training data generate किया जा सके
  • नीचे दिए गए एकल command से पूरी pipeline चलाई जा सकती है
    • ./training/train.sh N=4 partition=tbox2 trainer=mlsimdriving dataset=/home/batman/xx/datasets/lists/train_500k_20250717.txt vision_model=8d4e28c7-7078-4caf-ac7d-d0e41255c3d4/500 data.shuffle_size=125k optim.scheduler=COSINE bs=4
  • इस training को चलाने में ऊपर बताए गए सभी इन्फ्रास्ट्रक्चर का उपयोग होता है
  • यह सिर्फ एक साधारण command दिखती है, लेकिन कई घटकों को orchestrate करने का काम करती है

निष्कर्ष

  • comma.ai ने अपना डेटासेंटर चलाकर लागत बचत और तकनीकी आत्मनिर्भरता हासिल की है
  • इसी तरह के दृष्टिकोण से कंपनियां या व्यक्ति भी अपना infrastructure बना सकते हैं

संबंधित पढ़ाई

3 टिप्पणियां

 
kaydash 2026-02-06

मेमोरी महंगी है!
 
harryhan2435 2026-02-12

हाहाहाहाहाहाहाहाहा
 
GN⁺ 2026-02-06
Hacker News की राय

  • जिस इंडस्ट्री का हम हिस्सा हैं, उसमें ownership vs cloud स्पेक्ट्रम के दो छोर हैं
    ① cloud में शुरुआती निवेश (capex) और staffing का बोझ कम होता है, लेकिन operating cost (opex) ज़्यादा और अस्थिर होता है
    ② Managed Private Cloud हमारा काम है, जिसे हम open source के आधार पर manage करते हैं, और यह AWS की तुलना में लगभग 50% सस्ता है
    ③ Rented Bare Metal ऐसा मॉडल है जो hardware financing की जगह लेता है, और AWS से 90% सस्ता है
    ④ खुद खरीदकर colocation करने का तरीका, अगर आपके पास तकनीकी क्षमता और scale है, तो सबसे सस्ता पड़ता है
    Hetzner जैसी कंपनियाँ 3-year ROI के आधार पर चलती हैं, और विकल्प 3~4 बड़े scale वाली या infra-केंद्रित कंपनियों के लिए उपयुक्त हैं
    startup के लिए 1, और SMB के लिए 2 ज़्यादा व्यावहारिक है (lithus.eu)

    • समस्या यह है कि cloud की cost structure सिर्फ hardware price की वजह से नहीं है, बल्कि यह complex architecture की ओर धकेलती है, जिससे inefficiency बढ़ती है
      AWS की ‘managed services’ का ढांचा ऐसा है कि user server efficiency जितनी बढ़ाए, AWS की कमाई उतनी घटे
      अगर बस EC2 पर 4 Java server और replicated DB रखे जाएँ, तो वह कहीं ज़्यादा efficient होता है
      आख़िरकार बेतुके AWS bills तब बनते हैं जब ढेर सारी services का overuse होता है

    • (Carolina Cloud के derek@) हम भी मॉडल (4) को पसंद करते हैं, लेकिन जिन users के पास तकनीकी क्षमता कम है, वे 1~3 में ही अटके रहते हैं और public cloud की high-cost structure में फँसे रह जाते हैं
      इसे ‘usage-based’ कहा जाता है, लेकिन असल में इसमें base fee और minimum usage charge जुड़ते हैं, जिससे यह काफ़ी महँगा पड़ता है (carolinacloud.io)

    • Hetzner एक आकर्षक विकल्प है
      Postgres या VPN जैसी services खुद manage करनी पड़ती हैं, यह बोझ लग सकता है, लेकिन अगर monthly spend $10k~15k से ऊपर है, तो यह AWS से बेहतर पड़ता है
      risk है, लेकिन लेने लायक है

    • मैं $500/month का bare metal server किराए पर लेकर इस्तेमाल करता हूँ, और इसे manage करने में साल भर में बस कुछ घंटे लगते हैं
      शायद इसलिए कि मेरी requirements simple हैं, लेकिन मुझे यह overcomplicated cloud से काफ़ी बेहतर लगता है

    • मैं 2 साल पहले colocation में गया था, और अब 30% लागत में ज़्यादा capacity मिली है
      RAM/storage की बाद में आने वाली price cuts का फ़ायदा भी मिलता है
      हाँ, compliance management पर थोड़ा ज़्यादा ध्यान देना पड़ता है

  • पहले इसे बस datacenter कहा जाता था
    यह cloud से पहले भी मौजूद अवधारणा थी, और आख़िरकार यह ownership vs rental, centralization vs decentralization के दोहराव की कहानी है
    जब कंपनियाँ किसी एक छोर को बहुत ज़्यादा चुन लेती हैं, तो वही समस्याएँ फिर सामने आ जाती हैं

    • दिलचस्प बात यह है कि cloud finance teams को इसलिए आकर्षक लगा क्योंकि इसमें tax saving का असर था
      लेकिन हाल की क़ानूनी पहल (OBB) के बाद CapEx को expense की तरह treat किया जा सकता है, इसलिए on-prem की वापसी को हवा मिल रही है

    • तो फिर price-competitive cloud alternatives क्यों नहीं उभरते?
      AWS और Azure ने बाज़ार पर कब्ज़ा कर रखा है, इसलिए price cut का incentive नहीं है, और Google में service shutdown का risk बड़ा है

    • cloud से पहले internal infra teams ही bottleneck हुआ करती थीं
      cloud ने इसे standardize किया और single billing system से सरल बनाया
      और US के बाहर कई क्षेत्रों में server procurement धीमा था, इसलिए cloud का speed advantage काफ़ी बड़ा था

    • on-prem datacenter का operational burden बहुत ज़्यादा होता है, और engineering resources काफ़ी खा जाता है
      इसलिए यह बहस बार-बार लौटती रहती है

    • cloud की असली innovation यह थी कि “service level पर cost को साफ़-साफ़ दिखाया”
      पहले जैसा “यह काम करवाने के लिए किससे कहना होगा?” की जगह अब API के ज़रिए access मिल गया
      इससे जुड़ा context इस लेख में अच्छी तरह समझाया गया है

  • San Diego जैसे ऐसे इलाक़ों में भी जहाँ temperature control आसान लगता है, outside air cooling जोखिम भरा है
    नमी और pollutants server को तेज़ी से ख़राब कर देते हैं
    इसकी जगह enthalpy wheel cooler (kyotocooling) जैसे तरीके efficient होते हैं, और cooling efficiency की तुलना में power consumption कम होता है
    outside air cooling में equipment lifespan घटने का जोखिम बड़ा है, इसलिए सावधानी ज़रूरी है

    • filtering और humidity को 45% से नीचे रखने से काफ़ी अच्छे नतीजे मिलने के उदाहरण भी हैं

    • मुझे पता ही नहीं था कि ऐसी चीज़ों का ध्यान रखना पड़ता है
      इसलिए मैं बस cloud इस्तेमाल करता हूँ — इससे ऐसे ‘unknown risks’ से बचा जा सकता है

  • on-prem और cloud को साथ-साथ चलाना ही व्यावहारिक है
    core infra को किसी भरोसेमंद cloud पर रखा जाए, और Slurm jobs जैसी चीज़ें अपने server पर चलाई जाएँ
    colocation अब भी एक valid option है, और research HPC पर भी विचार किया जा सकता है
    Norway में private companies भी paid basis पर research HPC इस्तेमाल कर सकती हैं

    • मैंने Italy में दो locations पर server farms चलाए थे, जिन्हें 5 लोगों की टीम manage करती थी, और लगभग 100% uptime बनाए रखा
      सालाना €800k में €7~8M के cloud cost की बचत हुई

    • कई developers ग़लती से मानते हैं कि वे hosting नहीं कर सकते
      असल में यह सोच से ज़्यादा आसान है, और technical problems सुलझाने में मज़ा भी आता है

    • Equinix या Global Switch जैसी जगहों से space किराए पर लें, तो power, cooling, cable वगैरह सब manage करके दिया जाता है
      अपने तौर पर दो locations में server room रखना भी पूरी तरह संभव है

    • हम अभी भी user-facing services के लिए Azure इस्तेमाल करते हैं
      जिन web services को GPU नहीं चाहिए, उनके लिए cloud ज़्यादा efficient है
      GitHub भी अब तक एक भरोसेमंद service बना हुआ है

    • (मज़ाक में) Slurm pool में Postgres daemon उलझ गया था और Rust बेकाबू हो गया था
      आख़िरकार उसे stabilize कर लिया, लेकिन hardware engineer के नज़रिए से software की दुनिया काफ़ी अराजक लगती है

  • project के शुरुआती चरण में AWS पर $250/month से शुरू करें, और जब monthly spend $30k तक पहुँच जाए तो colocation में जाएँ
    असली बात है cost calculation की क्षमता — अच्छे engineer को इसी आधार पर management को proposal देना आना चाहिए

    • सिर्फ़ साधारण हिसाब से आगे बढ़कर यह भी सोचना चाहिए कि आप किस तरह के talent को attract करना चाहते हैं और किस तरह का business बनाना चाहते हैं
      अगर कंपनी ML models train करती है, तो उसका अपना infra ज़्यादा उपयुक्त हो सकता है

    • लेकिन ज़्यादातर कंपनियों में engineers platform choice में शामिल ही नहीं होते
      99.999999% मामलों में management पहले ही फ़ैसला कर चुका होता है और बस बता देता है

  • career की शुरुआत में cloud obvious choice था, लेकिन अब on-prem फिर से trend में है
    हो सकता है 10 साल बाद फिर उलटी दिशा का दौर आए

    • मेरे अनुभव में on-prem को आगे बढ़ाने वाली teams हमेशा maintenance fatigue को कम करके आँकती थीं
      startup जैसी जगहों पर, जहाँ fast development चाहिए, यह उल्टा रुकावट बनता है
      वहीं maintenance mode में जा चुकी कंपनियों में on-prem ज़्यादा efficient था
      उम्र बढ़ने के साथ “जल्दी, budget के भीतर काम ख़त्म करना” ज़्यादा अहम लगने लगता है, और infra खुद चलाने का आकर्षण कम हो जाता है

    • इस बार का रुझान सिर्फ़ एक तकनीकी cycle नहीं, बल्कि ‘ऐसे समाज के ख़िलाफ़ प्रतिक्रिया है जहाँ ownership नहीं बची’
      music, घर, car तक सब subscription model में बदलते जा रहे हैं, इसलिए कंपनियाँ भी computing sovereignty वापस लेने की कोशिश कर रही हैं

    • ऐसा चक्र हमेशा से रहा है
      mainframe → PC → server room → cloud → edge computing तक की यात्रा centralization ↔ decentralization के दोहराव की कहानी है
      आख़िरकार जब technology और priorities बदलती हैं, तो चीज़ें फिर वापस घूमकर आती हैं
      जब “the network is the computer” जैसी बात फिर सुनाई देने लगे, तो समझिए चक्र एक और बार पूरा हो गया

    • (मज़ाक) अगला चरण शायद space (Skynet) ही हो

  • ज़्यादातर कंपनियाँ on-prem से इसलिए बचती हैं क्योंकि यह risk management का मामला है
    अच्छी कंपनियाँ risk को अपनी core competency पर केंद्रित करती हैं
    इसलिए फ़ैसला सिर्फ़ cost नहीं, बल्कि risk-adjusted cost के आधार पर होना चाहिए

    • लेकिन आजकल यह भी सवाल है कि क्या कंपनियों के पास उस risk को सही तरह assess करने की क्षमता है
      क्योंकि price competitiveness भी आख़िरकार differentiation का एक हिस्सा है

    • असली बात है अपने core business पर ध्यान देना
      अगर यह आपको ऐसा product बेहतर बेचने में मदद नहीं करता जो अभी नहीं बिक रहा, तो datacenter पर समय बर्बाद नहीं करना चाहिए
      Google जैसी कंपनियाँ अपवाद हैं, जहाँ infra खुद product competitiveness का हिस्सा है

    • आख़िरकार ज़्यादातर मामलों में Opex, Capex पर भारी पड़ता है

  • on-prem का असली फ़ायदा freedom, control, privacy है
    यह सिर्फ़ पैसे का मामला नहीं, बल्कि वैसा ही सवाल है जैसे घर own करना या rent पर लेना

    • लेकिन मूल लेख में भी लागत को आख़िरी बिंदु के रूप में रखा गया था, और असली ज़ोर बाकी फ़ायदों पर था

  • 2010s की MBA-शैली की सोच यह थी कि “सब कुछ cloud में ले जाओ”
    risk और cost को किसी third party पर डाल देना ही सही जवाब माना जाता था
    लेकिन व्यवहार में हमारा datacenter कहीं ज़्यादा सस्ता था, और software subscription fee की बढ़ोतरी hardware की तुलना में कहीं ज़्यादा तेज़ थी

    • बेशक AWS के पास दुनिया भर में redundant datacenters हैं, इसलिए उसकी reliability अलग स्तर की है
      लेकिन उसी अनुपात में labor और management cost को देखें, तो सीधी cost comparison का कोई मतलब नहीं रह जाता
      एक tornado से पूरी कंपनी उड़ सकती है, इसलिए आख़िरकार फ़ैसला risk के मुकाबले value के आधार पर करना चाहिए