बेयर मेटल पर 70B मॉडल ट्रेन करने के लिए इंफ्रास्ट्रक्चर सेटअप और ओपन सोर्स स्क्रिप्ट्स

 (imbue.com)
1 पॉइंट द्वारा GN⁺ 2024-06-29 | 1 टिप्पणियां | WhatsApp पर शेयर करें
  • Imbue ने एक छोटी टीम के साथ अपने खुद के बेयर मेटल इंफ्रास्ट्रक्चर पर 70B पैरामीटर मॉडल को स्क्रैच से ट्रेन किया, और क्लस्टर बनाने से लेकर failure recovery तक की operational procedures और scripts सार्वजनिक कीं
  • क्लस्टर में 4,088 H100 GPU और 511 GPU servers थे; हर server में 8 GPU थे, जो InfiniBand के जरिए बड़े पैमाने की synchronous training में शामिल हुए
  • वास्तविक setup अलग-अलग machines की provisioning, InfiniBand fabric की मरम्मत/सफाई, host health checks, training error diagnostics, और automation सुधारों को दोहराते हुए हुआ; इसमें करीब 10% machines के boot failure और बड़ी संख्या में port warnings को संभालना पड़ा
  • सार्वजनिक tools में host health checks, NCCL logging patch, GPU stress test, NVLink·InfiniBand network tests, UFM event log parser, और InfiniBand burn-in workload generation script शामिल हैं
  • बड़े पैमाने की LLM training में एक भी unstable host या link पूरा run धीमा कर सकता है, इसलिए automatic health checks·failure isolation·restart·port disabling लगातार संचालन की कुंजी बन जाते हैं

अपने 70B मॉडल की training के लिए cluster बनाना

  • Imbue ने कई महीनों तक अपने infrastructure पर 70B पैरामीटर मॉडल को स्क्रैच से train किया, और यह मॉडल reasoning-related tasks में zero-shot GPT-4o से आगे निकला
  • सार्वजनिक किए गए scope में शुरुआती cluster booting, OS installation, और training के दौरान errors की automatic recovery तक फैली end-to-end infrastructure procedure शामिल है
  • साथ में जारी किए गए infrastructure tools ये हैं
    • Host-level health checks: यह जांचने वाली script कि host बिना known errors के training में लगाया जा सकता है या नहीं
    • NCCL patch: errors और hang स्थितियों में ज्यादा logs छोड़ने के लिए सुधार
    • GPU stress test: यह verify करता है कि GPU बड़े tensors allocate कर सकता है और standard operations चला सकता है
    • Networking tests: एक ही machine के GPU के बीच NVLink communication और अलग machines के GPU के बीच InfiniBand communication की जांच करता है
    • UFM event log parser: Unified Fabric Manager event logs को parse करके तय करता है कि कौन-से network ports disable करने हैं
    • InfiniBand burn-in workload generator: उपलब्ध सभी links को stress करने वाला InfiniBand burn-in workload बनाता है

Cluster और network configuration

  • core cluster में 4,088 H100 GPU को 511 GPU servers में बांटा गया था, और हर server में 8 GPU लगे थे
  • GPU servers 511 होने की वजह यह थी कि कुछ connections को InfiniBand network management के लिए Unified Fabric Manager(UFM) nodes के लिए reserve करना पड़ा
  • हर GPU सीधे ConnectX-7 card से जुड़ा था, और InfiniBand network में दूसरे GPU के साथ अपने ConnectX-7 card के जरिए एक साथ 400Gbps send/receive कर सकता था
  • InfiniBand topology एक fully non-blocking structure थी, जिसमें सभी GPU सिद्धांततः maximum speed पर एक साथ दूसरे GPU से communicate कर सकते थे
    • 3-stage InfiniBand switch architecture पूरे network throughput को उपलब्ध कराता है
    • training communication Ethernet पर नहीं, InfiniBand पर होता है
  • Ethernet का इस्तेमाल datasets, checkpoints, और अन्य data transfer के लिए होता है
    • अगर training communication Ethernet पर भेजा जाए, तो उसे GPU से CPU तक जाना पड़ता है और फिर 100Gbps Ethernet card से बाहर निकलना पड़ता है, इसलिए यह बहुत धीमा होता है
    • RoCE के जरिए Ethernet training भी संभव है, लेकिन hardware और software दोनों तरफ काफी extra work चाहिए, और आम तौर पर यह InfiniBand से कम reliable होता है
  • अलग management Ethernet network का इस्तेमाल BIOS, power supply, और low-level machine interface controller access के लिए होता है
    • इस management network के बिना सैकड़ों machines को USB drive, keyboard, और monitor से manually setup करना पड़ता
  • बड़े पैमाने की high-performance training में InfiniBand, Ethernet, GPU, और nodes का लगभग perfect तरीके से काम करना जरूरी है
    • 12,000 से ज्यादा connections में से सिर्फ एक unstable हो तो भी पूरा training run धीमा हो सकता है

अलग-अलग machines की provisioning

  • शुरुआती management network के जरिए cluster में Ethernet connection बनाने के बाद, BMC(Baseboard Management Controller) access credentials हासिल किए गए
    • BMC एक service processor है जो remote से host को monitor करता है
    • यह hardware status, BIOS settings, और power management API प्रदान करता है
  • पहला server Dell के BMC, यानी iDRAC, से Ubuntu 22.04 manually install करके तैयार किया गया
    • local computer की ISO image mount करके boot किया जा सकता था, और browser-based virtual console उपलब्ध था
    • लक्ष्य यह था कि यह manual install पूरी process में इकलौता manual install रहे

  • MAAS और PXE booting

    • पहली machine तैयार करने के बाद Ubuntu MAAS(Metal-as-a-Service) install किया गया, ताकि बाकी servers provision किए जा सकें
    • PXE booting और automated iDRAC tools के जरिए हर machine को network से boot करने का निर्देश दिया गया
    • servers DHCP से MAAS से IP लेते, initial kernel download करते, और local drive खाली होने पर भी permanent OS installation अपने-आप करते
    • व्यवहार में MAAS और BMC integration stable नहीं था, इसलिए iDRAC API से सभी machines के MAC addresses पहले ही collect किए गए
    • MAAS पूरे training process में कुल मिलाकर reliable रहा, लेकिन शुरुआत में setup-specific समस्याएं थीं
      • clock skew ज्यादा होने से HTTPS certificate verification fail हुआ और apt installation रुक गया
      • MAAS server एक साथ DHCP, DNS, HTTP proxy, NTP, cloud-init configuration management, और MAC·IP·hostname·metadata की source-of-truth database की भूमिका निभा रहा था, जिससे root cause trace करना मुश्किल था

  • Boot failures और basic observability

    • बड़े GPU cluster setup में जैसा आम है, करीब 10% machines boot करने में fail हुईं, और मुख्य वजह servers की physical issues थीं
      • Ethernet cable connect न होना या गलत wiring
      • iDRAC hardware issue
      • power supply failure
      • खराब NVMe drive
      • internal wiring गायब होना
      • network card या GPU detect न होना
    • Imbue ने इन issues की checks automate कीं, कुछ machines को Dell re-inspection के लिए भेजा, और datacenter staff के लिए जरूरी tickets बनाए
    • infrastructure setup खुद करने की वजह से repair का इंतजार करते समय भी working machines को तुरंत इस्तेमाल किया जा सका
    • सभी servers पर Docker, datacenter GPU driver, Prometheus node exporter, NVIDIA DCGM exporter, और OS के अलावा सभी drives पर RAIDZ ZFS pool install किया गया
    • ZFS ने एक drive down होने पर भी machine को चलते रहने दिया, और transparent compression से plain-text datasets और repetitive logs की storage space काफी घट गई
    • 400 nodes पर parallel में software packages install करते समय bandwidth bottleneck पैदा हुआ
    • datacenter deployment के कई components में पहली बार high-temperature alerts आए, और शुरुआती thermal issues ज्यादातर firmware update से कम हुए

  • Single-node GPU training verification

    • यह verify किया गया कि हर machine independently real GPU workload संभाल सकती है या नहीं
    • कई machines में single-node GPU training इन समस्याओं की वजह से fail हुई
      • GPU-related errors ज्यादातर cards को slot में फिर से बैठाने से हल हुए
      • Ubuntu server logs में PCIe connection limited width: x4 < x16 के रूप में दिखाई दिया
      • PCIe switch bus firmware update के बाद भी cluster के करीब एक-चौथाई hosts में internal PCIe cables को फिर से लगाना पड़ा
      • कुछ NVMe drives faulty mark नहीं होती थीं, लेकिन access करने पर पूरी machine को lock कर देती थीं
      • Linux में hard disk order random दिखाई देता था, जिससे MAAS ने OS को गलत drive पर install कर दिया
      • गलत temperature reading के कारण fans हमेशा 100% पर घूमते रहे
      • CPU dynamic frequency scaling ने active cores को 2GHz तक limit कर दिया
      • GDR, यानी GPUDirect RDMA Peer Memory Client, apply करने में failure हुआ

InfiniBand प्रोविज़निंग

  • अपने केंद्रीकृत डिज़ाइन की वजह से InfiniBand में पूरे नेटवर्क के लिए एक ही control entity था, और 320 network switches को एक ही fabric की तरह संभाला जा सकता था
  • पहला काम यह पता लगाना था कि कौन-सा switch किस machine से जुड़ा है, और wiring diagram से मिलान करके switches के नाम उनकी physical location के आधार पर बदलना था

  • गलत fabric डिज़ाइन और rewiring

    • शुरुआत में UFM 320 network switches को detect नहीं कर पा रहा था, और fabric में होने चाहिए थे ऐसे hosts भी नहीं मिल रहे थे
    • datacenter partner से जांच करने पर पता चला कि switches चालू थे और wiring भी की गई थी, लेकिन वे detect नहीं हो रहे थे
    • network wiring list की जांच करने पर पता चला कि upper fabric एक unified fabric नहीं था, बल्कि common routing path के बिना 8 अलग-अलग networks से बना था
    • rewiring के बाद सभी physical connections नए design से मेल खाते हैं या नहीं, यह verify करने के लिए checks जोड़े गए

  • तापमान warning और port errors

    • physical wiring की समस्या हल करने के बाद UFM सभी InfiniBand switches से जुड़ गया, लेकिन लगभग सभी switch ports अत्यधिक high temperature report कर रहे थे
    • वास्तविक data transfer से पहले भी कुछ ports 70°C से ऊपर थे, और कारण था networking racks में switches के बीच खाली जगहों से गर्म हवा का सामने की ओर recirculate होना
    • कई ports में high error rate दिखा या वे normal और failed state के बीच आते-जाते रहे, यानी link flapping दिखा; यह समस्या केवल तब दिखती थी जब port वास्तव में इस्तेमाल होता था, इसलिए पहले से detect करना मुश्किल था
    • पूरे fabric में 10,000 links और high redundancy थी, लेकिन fabric के लगभग 10% में समस्या दिखने पर adaptive routing जैसे features भी अनियमित रूप से टूटने वाले links को पर्याप्त रूप से bypass नहीं कर पाए
    • datacenter partner ने warning ports को साफ किया और फिर से लगाया, और replacement का इंतज़ार कर रहे बाकी warning transceivers को disable कर दिया
    • इस अवधि में 100~200 machines के साथ multinode training चलाकर stable InfiniBand subsets खोजे गए

  • InfiniBand burn-in और GPUDirect RDMA

    • InfiniBand समस्याओं को ज्यादा efficiently diagnose करने के लिए एक special workload बनाया गया, जो पूरे fabric के सभी ports पर एक साथ जितना संभव हो उतना data push करता था
    • यह पूरे cluster पर एक बड़ा all-reduce चलाने के तरीके से अलग था
      • क्योंकि NCCL single node के अंदर communication को NVLink और SXM socket paths के लिए optimize करता है
    • UFM ने अधिकांश ports पर theoretical capacity के 97% से अधिक data transfer की alerts भेजीं, और कुछ switches अस्थायी रूप से crash हो गए
    • दिन के अंत तक जो ports बचे रहे उन्हें पर्याप्त मजबूत माना गया, और बाकी को disable कर दिया गया या future repair के लिए भेजा गया
    • GPU को CPU overhead के बिना communicate करने देने के लिए GPUDirect RDMA enable किया गया

  • stable machine set और maintenance

    • latest hardware GPU clusters के लिए rule of thumb के तौर पर, हर हफ्ते machines के लगभग 3% के fail होने की उम्मीद रखनी चाहिए
    • ऐसा नहीं है कि सभी machines समान रूप से 3% probability से fail होती हैं; बल्कि कुछ problematic machines कई तरीकों से बार-बार fail होती हैं
    • एक ही fabric में कई machines रखने से random machine issues का लगातार पीछा करने के बजाय, भरोसेमंद माने जाने वाले golden machines का set बढ़ाया जा सकता है
    • InfiniBand maintenance मुख्य रूप से UFM warnings पर response, cable और transceiver replacement, और faulty switches की diagnosis से बना था
    • बड़े regressions आम तौर पर दो कारणों से होते थे
      • cluster के सिर्फ आधे हिस्से पर लागू firmware upgrade ने UFM state को corrupt कर दिया, जिससे सभी InfiniBand switches पर UFM restart करना पड़ा
      • GPU boxes को एक साथ बड़ी संख्या में restart करने पर UFM state updates की बाढ़ आ गई, जिससे UFM service restart करना पड़ा

host health check system

  • Imbue ने ऐसी कई single-machine failures खोजीं जो training runs को fail या slow कर देती थीं, और training के लिए पर्याप्त healthy hosts की पहचान करने के लिए health checks लिखे
  • code cluster-health पर public है
  • कई checks Imbue runtime environment के लिए खास हैं, लेकिन goal training readiness के लिए एक entry point से yes/no return करना था

  • quick health checks

    • GPU Health Check: GPU count, ECC enablement, ECC errors, NVLink topology और errors check करता है
    • Disk Space Health Check: verify करता है कि host disk usage 95% से ज्यादा न हो
    • Docker Health Check: GPU-connected container चल रहा है या नहीं और monitoring/profiling containers की permissions check करता है
    • Dmesg Health Check: NVIDIA GPU या NVIDIA switch के Xid/SXid errors ढूंढता है, और verify करता है कि dmesg log lines expected logs की list में classify होती हैं या नहीं
    • iDRAC Health Check: Dell machines के iDRAC errors check करता है और non-critical error messages को ignore करता है
      • यह check open source release में शामिल नहीं है
    • Disk Health Check: zpool mount, Docker connectivity, और disk access के दौरान CPU hang होता है या नहीं, यह check करता है
    • InfiniBand Health Check: InfiniBand error rate increases और पुराने driver firmware check करता है
    • Nvlink Health Check: machine के NVLink errors check करता है
      • अनुभव के आधार पर, इससे training failure नहीं होता था लेकिन slowdown हो सकता था
    • GDR Health Check: machine पर GDR enable है या नहीं, यह check करता है
    • VBIOS Health Check: GPU VBIOS version और H100 baseboard firmware latest हैं या नहीं, यह check करता है
    • Flint Health Check: flint और hca_self_test से Mellanox OFED driver, card firmware, transceiver firmware versions और NVIDIA driver compilation status check करता है
    • PSB Health Check: PCIe devices query करके verify करता है कि GPU, PSB और network card के बीच connection speed और width expected values से match करते हैं या नहीं
      • यह Dell द्वारा developed script है, इसलिए फिलहाल share नहीं किया जा सकता

  • longer health checks

    • PyTorch से matrix computations initialize करके NVLink bandwidth, GPU compute speed और memory measure करता है
    • GDR flag set करके InfiniBand और NVLink दोनों test करता है
    • ib_write_bw और --use_cuda से IB card को data भेजकर PCIe और InfiniBand card bandwidth measure करता है
    • flapping InfiniBand links पकड़ने के लिए लगभग 15 मिनट तक चलता है
    • multinode diagnostic run से NCCL initialization संभव है या नहीं और कहीं arbitrary hang तो नहीं हो रहा, यह check करता है
      • hang होने पर fork किया गया NCCL code extra logs छोड़ता है
    • समस्या detect करने में 12~24 घंटे लग सकते हैं, इसलिए इसे मुख्य रूप से नए nodes या suspicious situations में चलाया जाता है
    • DCGM exports में GPU clock throttle events check करता है, लेकिन expected gpu_idle और power_cap को exclude करता है
    • सभी GPU, InfiniBand cards, CPU और disks को एक साथ use करने वाली multinode training power events को सबसे अच्छी तरह expose करती है

ट्रेनिंग के दौरान आम errors की diagnosis

  • शुरू होते ही crash

    • शुरू होते ही crash को reproduce और repeat करना अपेक्षाकृत आसान था, इसलिए यह संभालने के लिए सबसे बेहतर errors में से था
    • पहले यह जांचा कि code version, settings और environment variables सही हैं या नहीं
    • Docker image caching या opaque secrets settings जैसी बीच की abstractions root cause समझने को धुंधला कर सकती थीं
    • यह भी जांचा कि सभी machines online हैं या नहीं, और stack traces व logs को आसानी से aggregate और inspect किया जा सकता है या नहीं
      • Imbue ने Loki, Prometheus, Grafana stack का उपयोग किया
    • synchronous distributed execution में पहला error अक्सर असंबंधित cascading errors पैदा कर देता था
    • automatic re-run system बनाते समय अलग-अलग re-runs के logs और errors आपस में न मिलें, इसलिए log/error aggregation और भी महत्वपूर्ण हो गया
    • अक्सर दिखे errors ये थे
      • Forward order differs across ranks...: PyTorch FSDP implementation की विशेषता के कारण re-run से हल हो सकता था
      • CUDA out of memory...: settings और code जांचकर, और हाल के code changes rollback करके हल किया
      • CPU/RAM OOM: container के बाहर host dmesg logs में OOM Killer call से detect करना बेहतर था

  • ट्रेनिंग के बीच में crash

    • hardware के काम करना शुरू करने के बाद, सभी diagnostic health checks फिर से चलाना और unhealthy hosts को छोड़कर automatic restart करने वाला system पहले जरूरी था
    • Xid·SXid जैसे random hardware errors meaningful Python stack trace के बिना execution को crash करा सकते थे
    • row remapping जैसे कुछ instances restart से recover हो सकते थे, लेकिन uncorrectable ECC errors में आमतौर पर hardware maintenance या part replacement की जरूरत होती थी
    • बहुत खराब format वाला training data भी crash करा देता है
      • corpus का बहुत बड़ा single document GPU या CPU OOM ला सकता था
      • पूरी तरह deterministic data loader का उपयोग किया, ताकि epoch या step number और crash को आसानी से जोड़ा जा सके
      • data वजह है या नहीं, यह जांचने के लिए data loading बंद की या केवल 0 वाली fake data से replace किया
    • Ethernet की temporary disconnection या disk space की कमी useful error messages के रूप में दिखाई नहीं दे सकती, इसलिए network और node status metrics record करके correlation जांचा

  • stack trace के बिना hang

    • stack trace के बिना hang या timeout होने वाले errors में जानकारी कम होती है और इन्हें भरोसेमंद तरीके से reproduce करना मुश्किल होता है, इसलिए debugging खास तौर पर पेचीदा होती है
    • typical message Watchdog caught collective operation timeout... जैसा था
    • अगर एक या अधिक hosts NCCL operation पूरा नहीं कर पाते या NCCL·InfiniBand connection से बाहर हो जाते हैं, तो बाकी सभी hosts उस tensor operation पर NCCL_TIMEOUT तक synchronously block हो जाते हैं
    • NCCL library की प्रकृति के कारण यह पता लगाना मुश्किल था कि कौन सा host कारण है
    • Imbue ने NCCL fork में logging changes जोड़े, ताकि crash के समय in-flight messages या operations बेहतर दिखें और problematic host या GPU की पहचान हो सके
    • गलत व्यवहार कर रहे host को खोजने के लिए अक्सर उन hosts को देखना पड़ता था जिन्होंने कोई खास log message generate नहीं किया
    • Py-Spy और GDB से रुके हुए processes को real-time में debug करके NCCL hang, driver hang, और Python code race condition/deadlock में फर्क किया

MFU से दिखी training speed degradation

  • सामान्य speed degradation या पहले observed level से कम MFU(Model FLOPs Utilization) कई कारणों से होता है
  • पहले settings, code और environment variables फिर से जांचना मददगार होता है
    • गलत model
    • गलत batch size
    • गलत UFM या NCCL settings
    • गलत CUDA_DEVICE_MAX_CONNECTIONS
  • smoothed average की तुलना में batch-level immediate MFU मापना issue type diagnose करने में ज्यादा useful था

  • MFU patterns के हिसाब से causes

    • training शुरू होते ही expected value के 1/10 से कम MFU पर स्थिर बना रहे, तो आमतौर पर यह T2 या T3 layer में dead switch जैसी InfiniBand hardware problem होती थी
      • GPU और NIC के बीच hardware problem भी कारण हो सकती है, और dmesg में PCIe x16 lanes limited by ... के रूप में दिखती है
    • शुरू होते ही expected value के 30% MFU पर स्थिर बना रहे, तो किसी host की GDR setting या GDR environment variable गलत हो सकता था
    • शुरू होते ही expected value के 60~80% MFU पर स्थिर बना रहे, तो आमतौर पर degraded या faulty InfiniBand link वजह होती थी
      • अगर किसी specific GPU से जुड़ा InfiniBand NIC खराब हो, तो NCCL local NVLink के जरिए उसी host के दूसरे GPU NIC का उपयोग करने की कोशिश करता है
      • CPU throttling भी कारण हो सकती है, इसलिए specific host की BIOS settings adjust करनी पड़ती थीं
    • single batch में 10x drop नियमित रूप से हो, तो यह लगभग checkpointing या evaluation से जुड़ा होता था, और epoch/step count से compare करके verify किया जा सकता था
      • सिर्फ MFU anomaly पर automatic alerts लगाने से false positives बढ़ जाते हैं
    • single batch में 10x drop दुर्लभ और random रूप से हो और तुरंत recover हो जाए, तो अक्सर running hosts में से किसी एक पर CPU-intensive workload schedule हुआ होता था
      • intermittent network issues या data loader bottleneck भी कारण हो सकते हैं
    • execution आगे बढ़ने के साथ MFU graph धीरे-धीरे नीचे जाता हो और restart करने पर 100% पर लौटता हो, तो Python और NVIDIA profilers से verify किया कि कारण automatic garbage collection था
      • automatic garbage collection बंद करके सभी hosts पर fixed interval में garbage collection करने से throughput degradation खत्म हो गया
    • शुरुआती performance अच्छी हो, लेकिन बाद में अक्सर expected value के 70% तक गिर जाए, तो इसका correlation NVIDIA GPU clock throttle reasons से था
      • वजह GPU temperature, host cooling fan failure/degradation, या power supply failure थी
    • performance अच्छी हो, लेकिन expected MFU के 90~100% के बीच high-frequency noise ज्यादा हो, तो आमतौर पर network upper layers में moderate degradation या flapping link जैसी InfiniBand hardware problem होती थी

  • throughput regression जांचने के सवाल

    • क्या पहले कभी normal तरीके से चला था, यह जांचें
    • हाल में code merge या driver update जैसी कोई change हुई है या नहीं, यह जांचें
    • healthy hosts पर चल रहा है या नहीं, और Docker Hub·GitHub जैसी dependent services काम कर रही हैं या नहीं, यह जांचें
    • पिछले normal run जैसे ही code, environment, settings, versions, host list, rank order, random seed के साथ run किया गया था या नहीं, यह जांचें
    • reproduce हो सकता है या नहीं, यह जांचें
    • दूसरे processes, daily crontab, host·DCGM·UFM metrics से correlation है या नहीं, यह जांचें
    • metrics measurement tool सही है या नहीं, यह जांचें
    • छोटे model, fake data, checkpoint save/load हटाने जैसे reduced code में भी issue आता है या नहीं, यह जांचें

ऑटोमेशन टूल्स और ऑपरेशनल सुधार

  • ट्रेनिंग अच्छे प्रदर्शन के साथ शुरू हो सकती है, फिर भी आखिरकार कुछ न कुछ खराब होता है, इसलिए ऐसे टूल्स और सिस्टम की जरूरत थी जो मानवीय हस्तक्षेप को कम से कम रखें
  • Imbue एक छोटी टीम है, इसलिए मैनुअल रिपेयर करते रहने के लिए पर्याप्त लोग नहीं थे, और उन्होंने जितनी प्रक्रियाएं संभव थीं उन्हें automate किया
  • ट्रेनिंग रन की ज्यादातर समस्याएं खराब मशीनों या network components तक सीमित हो गई थीं

  • खराब मशीनों को अपने-आप अलग करना

    • crashed रन को latest checkpoint से अपने-आप restart करने वाला सिस्टम विकसित किया
    • restart प्रक्रिया सभी उपलब्ध मशीनों पर health check चलाती है, और पास हुए checks के आधार पर मशीनों की health स्थिति classify करती है
    • इसके बाद सबसे healthy मशीनों पर ट्रेनिंग job फिर से चलाती है

  • network components पर automatic response

    • देखी गई network component failures को UFM ने सभी detect किया और UFM event log में register किया
    • वास्तव में समस्या पैदा करने वाले events दर्जनों में से कुछ ही थे, और ज्यादातर link down या high symbol error count से जुड़े थे
    • script UFM event log को parse करके हालिया events से जुड़े links और ports को disable करती है, maintenance ticket बनाती है, और repair पूरा होने के बाद उन्हें फिर से enable करती है

  • लोकल file system mirror

    • cluster के अंदर और बाहर Ethernet speed बड़े पैमाने की distributed training में bottleneck बन सकती थी
    • करीब 10Gbit/s shared Ethernet connection तब जल्दी saturate हो जाता है जब सैकड़ों workers dataset और model checkpoints को एक साथ download करते हैं
    • Imbue ने cluster के अंदर cloud storage को mirror करने वाला local file system बनाया, जिससे S3 से लानी पड़ने वाली files की संख्या कम हुई
    • मशीनों के अक्सर disable या replace होने से होने वाले churn से निपटने के लिए हर file को 3 copies में replicate किया
    • consistent hashing से load को समान रूप से distribute किया और churn के दौरान file movement को न्यूनतम रखा
    • सीमित disk space के कारण file lifecycle tracking और अनावश्यक files हटाने के tools भी विकसित किए

  • लोकल distributed Docker registry

    • Docker images transfer करने के लिए Kraken का उपयोग किया
    • Kraken open source software है जो Docker images को peer-to-peer तरीके से transfer करने देता है, और Imbue ने बताया कि उन्हें इससे लगभग कोई समस्या नहीं हुई

  • प्रदर्शन monitoring और खराब hosts की पहचान

    • Torch profiler और NVIDIA Nsight Systems को set up किया
    • Nsight Systems forward/backward pass और NCCL communication में कितना समय लग रहा है, यह समझने में उपयोगी था
    • model size और workers की संख्या के आधार पर यह तय करने में मदद मिली कि bottleneck communication में है या computation में
    • Docker privileged mode, performance monitoring events से जुड़े security checks disable करने, और profiles save करने के लिए training रोकने की जरूरत के कारण इसका उपयोग कुछ मुश्किल था
    • धीमे training batches को detect करने और उनका कारण समझने के लिए tools भी लिखे
      • सबसे उपयोगी tool हर batch time को monitor करता था और असामान्य रूप से धीमे batch पर सभी workers के stack traces dump कर देता था
      • इससे सूक्ष्म hardware/software समस्या वाले खास hosts की पहचान करना आसान हुआ
    • health checks पर्याप्त mature होने से पहले, किसी specific machine set पर training fail होने पर यह स्पष्ट नहीं होता था कि कौन-सी machine वजह है
      • उदाहरण के लिए, अगर 48 machines का group fail होता, तो 8 machines के 6 groups और 6 machines के 8 groups में छोटे runs launch किए जाते
      • दोनों stages में failed group में शामिल machines को उच्च confidence के साथ problematic machines माना जाता

निर्माण प्रक्रिया से मिले operational principles

  • किसी specific training run के लिए जरूरी संख्या से 10–20% ज्यादा machines सुरक्षित रख लें, तो machine failure होने पर आसानी से rerun किया जा सकता है
  • cluster network को इस तरह configure करें कि सभी machines आपस में नजदीकी से connected हों, ताकि कोई भी काम करने वाला arbitrary subset इस्तेमाल किया जा सके
  • training के दौरान मिले hardware/software failures फिर से आएंगे, इसलिए हर failure type के लिए tests और automation solution लिखना worthwhile है
  • हर opaque error message के लिए ज्यादा interpretable tool बनाना उपयोगी है
  • reproducibility के लिए सबसे simple change भी एक बार में केवल एक ही बदलने का नियम अपनाया
  • external tools introduce करते समय या किसी नए व्यक्ति के process में शामिल होने पर, खासकर जब आगे के steps उसके result पर depend करते हों, claims को फिर से verify करें
  • पूरी प्रक्रिया में काफी supervision और iteration की जरूरत पड़ी, लेकिन infrastructure पर पूरा control होना और सभी abstraction layers पर समस्याओं को debug कर पाना निर्णायक साबित हुआ

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

1 टिप्पणियां

 
GN⁺ 2024-06-29
Hacker News टिप्पणियाँ
  • कुछ महीनों तक एक छोटी research/engineering टीम ने अपने ही infrastructure पर 70 अरब parameters वाले model को scratch से train किया, और inference-संबंधित tasks में zero-shot GPT-4o से आगे निकला
    high-performance training के लिए अपना cluster इस्तेमाल करना हो तो InfiniBand, Ethernet, GPU और nodes तक हर component का पूरी तरह काम करना ज़रूरी था, और 12,000 से ज़्यादा connections में से सिर्फ़ एक भी unstable हो तो पूरी training धीमी पड़ सकती थी
    infrastructure setup के लिए open source scripts और end-to-end guide जारी की गई है, और यह 70 अरब model training toolkit की 3-part series में से एक है। evaluation और hyperparameter optimization tool CARBS यहाँ देखे जा सकते हैं: https://imbue.com/research/70b-intro/
    • details वाकई बहुत अच्छी थीं, और ऐसे model के पीछे की engineering work को इतनी अंदरूनी detail में दिखाने वाला लेख मैंने पहली बार देखा
      मेरे दो सवाल हैं। पहला, अगर 400 अरब parameters वाला model train किया जाए तो क्या बदलेगा, यह जानना चाहूँगा। पूरे cluster के हिसाब से video memory पर्याप्त लगती है, लेकिन असली आकलन जानना चाहता हूँ
      दूसरा, क्या वे इस architecture को model training का अंतिम रूप मानते हैं, यह जानना चाहूँगा। यह बहुत fragile लगता है; क्या बेहतर shared training mechanism या architecture, या बेहतर cluster structure मौजूद है?
    • टीम जो Minecraft जैसा 3D world बना रही थी, उसका क्या हुआ? क्या उन्होंने दिशा बदल ली?
    • “zero-shot GPT-4o से आगे निकला” वाला हिस्सा दिलचस्प है। क्या इस model में RLHF तक किया गया था, या सिर्फ़ pretraining हुई थी?
      अगर दूसरा है, तो यह GPT-4 को कैसे हराया, जानना चाहूँगा
    • 12,000 से ज़्यादा connections में से सिर्फ़ एक unstable होने पर भी पूरी training धीमी हो सकती है—यह वाक्य काफ़ी अलग लगा, इसलिए लगा “यह वाक्य पहले कहीं देखा है”
      सच में, यह वाक्य और लेख का ज़्यादातर हिस्सा Twitter, LinkedIn, Reddit पर लगभग शब्दशः पोस्ट हुआ दिखता है; क्या यह बस spam है?
      https://x.com/imbue_ai/status/1805629547473518695
      https://reddit.com/r/learnmachinelearning/comments/1dobgbs/t...
      https://www.linkedin.com/posts/mattboulos_training-a-70b-mod...
  • “511 computers में 4,092 H100 GPUs, हर computer में 8” का मतलब क्या सिर्फ़ GPUs ही 100 million dollars से ज़्यादा के हैं?
    जानना चाहता हूँ कि इनमें से कितना हिस्सा, और कब तक, gaming PC budget वाले hobbyist developers की पहुँच में आ पाएगा
    • GPUs पर 100 million dollars खर्च करते हुए खराब Ethernet port वाले Dell box से जूझना दिलचस्प है
      जिन समस्याओं से वे गुज़रे, उनके बारे में सुनना मज़ेदार है
    • सही लगता है। उन्होंने NVIDIA से 200 million dollars जुटाए थे, शायद लगभग पूरी तरह GPU के रूप में: https://news.crunchbase.com/ai-robotics/new-ai-unicorn-imbue...
    • अगर सिर्फ़ GPUs ही 100 million dollars से ज़्यादा के हैं, तो ऐसे पैमाने की funding न रखने वाले ज़्यादातर readers को शायद अगले HN post पर बढ़ जाना चाहिए
  • वाकई शानदार। Cisco ने NVIDIA के साथ नए collaboration में port प्रति 800G देने वाला equipment निकाला है, लेकिन याद नहीं कि वह RoCE था या नहीं
    यहाँ लगता है कि GPU को InfiniBand तक पहुँच वाली structure मिली है, और यह खूबसूरत है। सीधे तौर पर उपयोगी लेखों में से एक है
  • कुछ दिन पहले Latent Space podcast में भी यह विषय आया था: https://www.latent.space/p/llm-training-2024
    अच्छा episode था, और ये decisions क्यों लिए गए, इसकी वजहें सुनने लायक थीं
    • मैं ऐसे interviews का अभ्यस्त नहीं हूँ, इसलिए लगा कि यह मेरी capability से बाहर था। अगर कोई सवाल छूट गया जो पूछा जाना चाहिए था, तो सुझाव दें
  • model बनाने में होने वाली कुल power usage को लेकर जिज्ञासा है। power और cooling तक मिलाकर कोई आंकड़ा है क्या, जानना चाहता हूँ
    Zuckerberg ने एक podcast में कहा था कि वे अगला 1GW model plan कर रहे हैं; इसका मतलब लगभग medium-sized power plant से जुड़े datacenter जैसा है, इसलिए और curiosity है
  • यह वाकई मूल्यवान लेख है और पढ़कर बहुत कुछ सीखा। जारी किया गया open source code भी बेहतरीन है
    कुछ सवाल हैं। उन्होंने अपना cluster क्यों बनाया, cloud partner के साथ defective equipment या switches से निपटने का अनुभव कैसा रहा, यह जानना चाहूँगा
    साथ ही all-to-all communication के अलावा cluster architecture चुनते समय उन्होंने किस चीज़ को सबसे ज़्यादा महत्व दिया और असल में सबसे मूल्यवान क्या रहा; Loki-based होने के अलावा logging infrastructure कैसा था; local Docker registry की ज़रूरत क्यों पड़ी; और nvidia-container-runtime के अलावा क्या दूसरी images भी इस्तेमाल कीं, यह जानना चाहता हूँ
  • ईमानदार सवाल है: इसमें इतना ज़्यादा PC hardware क्यों मिला हुआ है?
    क्या PCI और InfiniBand backend से GPUs जोड़कर, सिर्फ़ बहुत छोटे ARM coordination controllers रखकर, उन्हें आपस में coordinate करने नहीं दिया जा सकता? समझ नहीं आ रहा कि यह पुराने design की inertia है या specialized GPU controller market की कमी
    • अगर आपका सवाल CPU और RAM पर extra cost देने की वजह को लेकर है, तो हर काम GPU पर नहीं किया जा सकता। उदाहरण के लिए .png decompression है
      अगर training code को सच में analyze करके data की बहुत preprocessing की जाए, तो बहुत हल्के CPU/RAM resources से भी काम चल सकता है, लेकिन GPUs महंगे हैं, इसलिए पूरे system cost में CPU/RAM का हिस्सा छोटा है; ऐसे optimization पर development time लगाना ज़रूरी ही हो, ऐसा नहीं है

अगर कोई hyperscale cloud provider हो, तो संभावना है कि वह ऐसी 0.x% cost efficiency भी हासिल करने की कोशिश करेगा। उदाहरण के लिए, वे .png को .webp (multi-threaded lossless) या .jpeg (lossy) में preprocess करना चाह सकते हैं, लेकिन उसे ऐसे format में बदलना जिसे GPU decompress कर सके, training के दौरान CPU cost तो घटा सकता है, पर storage और transfer cost बढ़ा सकता है, इसलिए शायद यह सही न बैठे
ज़्यादा सटीक कहें तो, अगर CPU work training bottleneck है, तो data preprocessing और training script adjustment के ज़रिए जितना हो सके optimize करना चाहिए। यहाँ बात “काफी तेज़” और “और तेज़” के बीच के gap की है: CPU training के लिए पर्याप्त तेज़ नहीं है < CPU training के लिए बस पर्याप्त तेज़ है < CPU training की ज़रूरत से ज़्यादा तेज़ है

  • अगर हर machine में 250,000 डॉलर के GPU लगे हों, तो control hardware के कुछ हजार डॉलर बचाने पर माथापच्ची करना मूर्खता है। नए hardware configuration का जोखिम बहुत बड़ा है
    एक और समस्या यह है कि GPU-related hardware, drivers और operational experience सब PC side पर है। ARM पर चलाने के लिए लगभग शुरू से शुरू करना पड़ेगा, और stabilize करने में भी काफी अतिरिक्त काम लगेगा। आखिर में processor cost थोड़ी बचाने के चक्कर में बड़ी cost चुकानी पड़ती है
  • GPU को लगातार data feed करते रहना deep learning training में काफी पेचीदा काम है
    LLM/NLP का अनुभव नहीं है, लेकिन image और audio workloads में आम 4–8 core CPU से RTX 2/3/4xxx GPU तक को पूरी तरह utilize करना कभी-कभी मुश्किल होता है। CPU या I/O का bottleneck बनना बहुत कठिन नहीं है
  • 4,092 H100 GPU—यह तो बड़ा scale है
    वे “self-coding” कर रहे हैं, ऐसा कहा गया है; जिज्ञासा है कि यह no-code या न्यूनतम-code solutions के करीब है क्या
    वेबसाइट पर भी रुचि जगाने वाले कई लेख हैं: https://imbue.com/our-work/
  • उत्सुकता है कि लागत कितनी आई होगी। बिल्कुल शून्य से usable model files तक पहुँचने में hardware cost, development time, बिजली और cooling cost—सब मिलाकर कितना हुआ होगा?
  • सोच रहा हूँ कि क्या बहुत सारे hobbyist developers seti@home या folding@home की तरह मिलकर distributed तरीके से कोई model train कर सकते हैं
    उन projects की खासियत थी कि काम को काफी independent work packages में बाँटा जा सकता था, लेकिन model training को भी ऐसे बाँटा जा सकता है या नहीं, यह ठीक से नहीं पता
    • शायद ठीक से काम न करे। hobbyist developers में ऐसे लोग बहुत कम होंगे, या शायद कोई नहीं, जो एक-दूसरे के GPU के बीच 400Gbps network throughput सुनिश्चित कर सकें