- Reka ने साफ-सlate से बड़े language और multimodal models के training infrastructure को बनाया, और compute हासिल करने से ज्यादा cluster quality variance और operational instability बड़ी bottleneck बन गई
- वही H100 GPU होने पर भी provider और cluster के हिसाब से node failures, cabling issues, GPU errors, I/O और filesystem bottlenecks, checkpoint deletion, delivery delays मिलकर hardware lottery जैसी स्थिति पैदा करते हैं
- Google के TPU और internal infrastructure experience के उलट, external GPU environments में multi-node training, wiring और support quality में बड़ा फर्क होता है, इसलिए MFU और downtime cluster-दर-cluster काफी बदलते हैं
- कई clusters, बड़े data movement और external codebase constraints को झेलना पड़ा; Reka ने PyTorch-based setup पर जाते हुए monitoring, efficient checkpoints और custom filesystem खुद बनाए
- सीमित compute के कारण Big Tech जैसी systematic scaling के बजाय कम संख्या में छोटे ablation experiments और Yolo run पर निर्भर रहना पड़ा, और इसी से 21B Reka Flash और 7B edge model बन सके
साफ-सlate से training infrastructure बनाना
- Reka ने मजबूत multimodal language model को train करते हुए बड़े language और multimodal models को बिल्कुल शुरुआत से train करने के लिए जरूरी infrastructure नया बनाया
- मुख्य कठिनाई TPU और GPU में से क्या चुनना है यह नहीं थी, बल्कि external infrastructure और code environment में actual training को reliably चलाने लायक operational quality सुनिश्चित करना था
LLM युग की hardware lottery
- model training की पहली शर्त compute हासिल करना है, लेकिन असल में provider, cluster और accelerator connectivity की quality में variation सबसे बड़ा variable बन जाता है
- वही H100 GPU होने पर भी पूरे cluster की quality बहुत अलग थी, और यहां hardware से मतलब chip खुद से ज्यादा पूरे cluster की quality से है
- Reka ने कई compute providers से सैकड़ों से हजारों chips के scale वाले clusters rent किए, और उनकी स्थिति relatively solvable level से लेकर हर कुछ घंटों में fail होने तक अलग-अलग थी
- कुछ clusters में cabling issues या GPU hardware errors के कारण nodes छोटे intervals में fail होते थे
- एक ही provider के clusters के बीच भी robustness में बड़ा फर्क था
- Stable nodes होने पर भी अगर I/O और filesystem खराब हों, तो checkpoint saving timeout हो सकती है या cluster utilization बहुत घट सकता है
- कुछ compute sources execution के लिए पूरी तरह अलग software layer मांगते थे, जिससे अपनी codebase लेकर आए team के लिए migration cost जुड़ गई
- पहले से यह जानना मुश्किल था कि कौन-सा hardware मिलेगा, और experience कितना robust और fault-tolerant होगा
- अगर provider समय पर delivery न कर पाए, तो कई महीनों की delay हो सकती है, और दूसरे suppliers से भी कई weeks या months तक procurement न हो पाने की स्थिति बन सकती है
- कुछ providers ने गलती से checkpoints delete भी कर दिए
MFU और failure response के लिए internal tools
- हर cluster में Model Flop Utilisation(MFU) अलग था, और गलत तरीके से cabled nodes या provider issues मिलने पर non-trivial compute waste हो जाता था
- बहुत inefficient filesystem वाले environment में, किसी के clusterों के बीच bulk data transfer शुरू करने भर से training run का MFU तेजी से गिर सकता था
- Provider support level भी बहुत अलग-अलग था
- polite support से लेकर indifferent responses तक सब मिला
- “ChatGPT style” के templated replies या हर problem का दोष user पर डालने वाले responses भी थे
- हर cluster की अपनी अलग pains और failure modes थीं, और ऐसा लगता था जैसे हर cluster के लिए अलग hotfix चाहिए
- usable environment बनाने के लिए Reka ने कई internal tools बनाए
- monitoring tools
- efficient checkpoints
- कई optimizations
- scalable data storage के लिए custom filesystem installation
- इन tools के combination ने खराब hardware पर भी downtime घटाया और MFU को meaningful तरीके से improve किया
GPU और TPU experience का फर्क
- Reka ने ज्यादातर models GPU पर train किए
- Google में बड़े language models training के लिए TPUs का मुख्य रूप से इस्तेमाल करने के experience की तुलना में, CUDA और nccl unfamiliar environment थे
- GPU failure rate Google में TPUs इस्तेमाल करने के experience से काफी अलग था
- Google का UL2 20B job गलती से एक महीने तक चलता रहा, लेकिन fail नहीं हुआ
- माना गया कि GPU environment होता तो पहले कुछ दिनों में ही fail हो जाता
- हालांकि यह फर्क chip खुद से ज्यादा accelerators manage करने वाली hardware team की capability और provider support quality से जुड़ा हो सकता है
- GPU environment में multi-node training, TPU pod की तरह distributed training को first-class concept मानने जैसा नहीं लगा, बल्कि बाद में जोड़े गए element जैसा लगा
- हर provider में multi-node training संभव बनाने की wiring approach अलग दिखती थी, और इसी फर्क ने location-wise variance बढ़ाया
Multi-cluster operations का बोझ
- Google का internal infrastructure Borg, Xmanager, Colossus पर बना ऐसा environment था जिसे कहीं से भी access किया जा सकता था
- External environment में कई clusters पर नया environment खुद configure करना पड़ता था, और यह पिछले experience से काफी अलग था
- जब तक एक जगह बड़े accelerator pool को खुद न बनाया जाए, कई clusters के accelerator pools इस्तेमाल करने की स्थिति inevitable लगती है
- GPU supply shortage procurement को naturally distributed clusters के रूप में बना देती है
- बड़े model training के लिए tens of TB data चाहिए, इसलिए data move करना अपने आप में बड़ा बोझ बन जाता है
- बहुत बड़े scale पर data replication भी आसान नहीं है और costly है
- Ideal form कई servers पर jobs भेजने वाली orchestration layer है, लेकिन एक हल्के और नए startup के लिए शुरुआती दौर में इतना sophisticated ML training infrastructure रखना मुश्किल है
- Reka ने कई internal workflows से समस्या को कम किया और world-class experimentation infrastructure की ओर लगातार बढ़ रहा है
- कहा गया कि ऐसी scrappy setup, top-tier या बड़ी companies के अलावा, आम तौर पर common है
External codebase और PyTorch का चुनाव
- preferred codebases T5X और Mesh Tensorflow थे, लेकिन Reka में वे practical choices नहीं थे
- Google के बाहर support ज्यादा नहीं है
- कुछ हद तक deprecated हैं
- team में Google background न रखने वाले लोगों के लिए friendly नहीं हैं
- Reka ने ज्यादा vanilla, stable दिखने वाला और widely used PyTorch चुना
- शुरुआती दौर में pip, git, docker जैसे external development environments के साथ adapt करना पड़ा
- संभव है कि बाहर Google codebase को stable और user-friendly तरीके से इस्तेमाल करना मुश्किल रहा हो
- External codebase quality Google में familiar codebases से काफी पीछे महसूस हुई
- माना गया कि Google internal codebases अक्सर Noam Shazeer, Barret Zoph, Adam Roberts, Hyung Won Chung जैसे ML researchers ने खुद लिखी थीं
- दूसरी companies द्वारा बनाए code में कुछ cases में code quality खास तौर पर disappointing थी
- कुछ codebases में model parallelization configuration बदलने के लिए अलग converter लिखना पड़ता था, और parallelization changes automatically उपलब्ध नहीं थे
- बड़े encoder-decoder training या prefixLM training का support भी कम था
- कहा गया कि GitHub issues में reasonable demand होने के बावजूद flash attention ने prefixLM training, यानी custom mask support, लगातार provide नहीं किया
- Jax इस्तेमाल करना चाहिए ऐसी समझ थी, लेकिन startup में तेजी से move करने के लिए PyTorch चुना गया
सीमित compute और Yolo run
- systematic model scaling आम तौर पर 1B → 8B → 64B → 300B जैसे छोटे models से बड़े models तक कई-stage experiments चलाकर, winners चुनकर उन्हें आगे scale करने का तरीका है
- Startup में hyperparameters verify करने के लिए large-scale sweeps करने जितना compute बहुत कम था
- Reka ने कई Yolo run पर भरोसा किया, और माना कि नतीजा आखिरकार अच्छा रहा
- कम संख्या के छोटे-scale और short ablation experiments से ही मजबूत 21B Reka Flash, 7B edge model और planned सबसे बड़े core model तक पहुंचा गया
- सीमित run count में अच्छी recipe ढूंढना मुश्किल है, और search space बहुत बड़ा होने से एक बार में कई variables बदलने पड़े
- Big Tech जैसी systematic approach के बजाय Yolo, gut feel और intuition पर ज्यादा निर्भर रहना पड़ा
- Team members की पिछली ML careers से बनी intuition ने कम attempts में सही चीज पकड़ने में मदद की
- पिछली jobs में अच्छे models train करने का experience होने पर भी, training infrastructure, data, नए ideas का integration और environment issues में फर्क result में non-trivial difference ला सकता है
- strong prior experience ने search space काफी घटाया, और कम trials, resources और experiments से मजबूत models train कर पाने की एक आसान explanation के रूप में देखा जा सकता है
एक साल से कम समय के results और बाकी challenges
- compute shortage और unstable compute providers ने उम्मीद से कहीं ज्यादा बड़ी मुश्किलें पैदा कीं
- Reka ने company शुरू कर funding जुटाई और chips खरीदने के बाद सब कुछ बिल्कुल शुरुआत से बनाया
- कहा गया कि एक साल से कम समय में यह Gemini Pro/GPT-3.5 के बराबर पहुंचा और कई models से आगे निकला
- data pipeline और human evaluation आदि अभी आगे discuss किए जाने वाले topics हैं
1 टिप्पणियां
Hacker News की राय
इस संदर्भ में startup आखिरकार कम लोगों और training cluster पर खर्च करने के लिए बड़ी पूंजी वाली organization जैसा दिखता है
लेख यह मानकर चलता है कि कई server rental providers हैं, और वे servers कई startups या मौजूदा कंपनियों के पास जाते हैं
आखिर में कई LLM निर्माता मिलते-जुलते hardware और मिलते-जुलते data के साथ text·image training कर रहे हैं, मोटे तौर पर वही काम कर रहे हैं, और अपने-अपने “secret sauce” से अलग दिखने की कोशिश कर रहे हैं
ऐसा secret sauce LLM output quality में फर्क ला सकता है, लेकिन कुल मिलाकर यह बहुत energy खर्च करने वाला विशाल duplicate काम लगता है
अंत में बहुत छोटा प्रतिशत ही कुछ ठीक-ठाक सफलता पाएगा, लेकिन progress की frontier पर यह चुकाई जाने वाली लागत है
planned monopoly ज़्यादा efficient हो सकती है, लेकिन innovation में ऐसी संरचना का market को हराना दुर्लभ है
founders शायद इस उम्मीद में acquire होना चाहते हैं कि वे “लगभग state-of-the-art” LLM train कर सकते हैं, और उस स्तर की capability और infra उसके ऊपर कुछ बनाने लायक मूल्य रख सकती है
बस, यह बात investors को समझाना कहीं ज़्यादा कठिन है
असल में, लगता है कई startups writers और photographers को hire करके unpolluted और बहुत अच्छी तरह labeled training data बना रहे होंगे
civitai की तरफ देखें तो पता चलता है कि छोटे compute budget के साथ भी dense labeling से कितना आगे जाया जा सकता है
LLM के ज़्यादातर use cases मौजूदा foundation model को fine-tune करके support किए जा सकते हैं
अगर foundation model को scratch से train करते हैं, तो आप ऐसे market में उतरते हैं जहाँ monetization कठिन है, और कोई बड़ी company सिर्फ एक नया foundation model जारी करके आपके model के 95% से ज़्यादा काम कर सकती है
संदर्भ के हिसाब से Yi Tay Google PaLM, UL2, Flan, Bard आदि के tech lead थे, और अब Reka के cofounder हैं
Reka ने कुछ दिलचस्प छोटे multimodal models जारी किए हैं जो यहाँ भी आए थे
Google से निकले होकर independent startup में LLM train करने की स्थिति से उन्होंने यह लेख लिखने का अनुरोध किया था: https://twitter.com/YiTayML/status/1765105066263052718
बातचीत की recording यहाँ है: https://sub.thursdai.news/p/thursdai-feb-15-2024-openai-chan...
इस लेख से मुझे reka.ai के बारे में पता चला, और लगता है कि HN पर अभी Reka के LLM पर ज़्यादा चर्चा नहीं हुई है [1]
जिज्ञासा में मैंने पिछले एक घंटे में chat interface [2] पर prompts को ChatGPT 4, Gemini Advanced, Claude 3, Mistral Large से तुलना करके test किया, और नतीजे [3] पर डाले
कुल मिलाकर Reka Flash दूसरे models की तुलना में बहुत खराब या बहुत अच्छा नहीं लगा
हालांकि पक्का देखने के लिए कहीं ज़्यादा tests चाहिए
[1] https://hn.algolia.com/?dateRange=all&page=0&prefix=false&qu...
[2] https://chat.reka.ai/chat
[3] https://gally.net/temp/20240307llmcomparison.html
यह बात ध्यान देने लायक है कि लेखक मानकर चलता है कि पाठक “wilderness” को Google के बाहर के रूप में समझेंगे
यह लेख Google की infra और hardware teams को बहुत credit देता है, लेकिन मैं उस व्यक्ति का दृष्टिकोण भी पढ़ना चाहूँगा जो वहाँ था और बाद में कहीं और ऐसा काम करके आया हो
ज़्यादा सटीक रूप में यह कुछ ऐसा है: “पूरे career में Google के अंदर Google TPU इस्तेमाल किए और उनके failure modes की आदत थी, लेकिन GPU के failure modes के बारे में बिल्कुल नहीं जानता था”
GPU मुख्य रूप से इस्तेमाल करने के बाद जब TPU आज़माया, तो debugging में मुश्किल कारणों से काम बार-बार fail हुआ
x86 chip और TPU device के बीच की indirect layers की वजह से कई घंटे सिर पकड़ना पड़ता था, और यह x86+NVIDIA+PyTorch में मिलने वाली समस्या जैसा नहीं था
10~15 साल पहले Google ने 10 million dollar से ज़्यादा मूल्य वाले data scientists, यानी Sawzall engineers, बड़ी संख्या में निकाले थे, और वे भी “wilderness” में जाकर ऐसी ही प्रतिक्रिया देते थे
यह लेख community के लिए उपयोगी record छोड़ने से ज़्यादा, लेखक द्वारा अपनी company और personal brand को उठाने जैसा लगता है
मेरी राय में large-scale training में भी मैंने GPU failure नहीं देखा
मौजूदा training batch job 20GB JSON file है जिसे सिर्फ load होने में 6 घंटे लगते हैं, और वह 15 दिन से ज़्यादा समय से बिना समस्या चल रही है, वह भी पुराने Tesla T4 पर
GPU में memory constraint की समस्या है, लेकिन अगर plan करके workaround कर लें, तो मैंने वास्तव में crash नहीं देखा
यह काफ़ी स्पष्ट रूपक लगता है, और अगर startup बड़े infra projects कर रहा है, तो उसे सचमुच wilderness में camp लगाने की तरह logistics system खुद बनाना पड़ता है
यह ऐसे पढ़ा जाता है जैसे Seven of Nine Collective से अलग होकर तुच्छ मानवीय क्षमताओं पर निर्भर होना समझ रही हो
vendors के बारे में insight उपयोगी थी
उम्मीद है training progress पूरी की पूरी नहीं खो जाती होगी, तो क्या असली दर्द मुख्यतः समस्या का diagnosis करने और cluster को फिर से उठाने में होता है, और data loss की खास चिंता नहीं करनी पड़ती?
लेकिन ये लोग बेच क्या रहे हैं, यानी उनका product क्या है?
Reka.AI का main page एक आम ChatGPT clone जैसा दिखता है, जहाँ token के हिसाब से पैसे देने होते हैं।
समझ नहीं आता कि यह दूसरी कंपनियों से कैसे अलग है, और pricing भी ChatGPT 3.5-Turbo जैसी लगती है।
LLM को शुरुआत से train करने की समस्या बहुत महत्वपूर्ण विषय है, जो AI की iteration की गति और दायरे पर उतना ही बड़ा असर डालती है जितना raw hardware improvements डालते हैं।
लेख दिलचस्प है, लेकिन थोड़ा सतही है; और अगर आपने कई सालों तक किसी न किसी रूप में GPU cluster संभाले हैं, तो इसमें तकनीकी रूप से कुछ बहुत गहरा या चौंकाने वाला नहीं है।
एक पूर्व Googler का नज़रिया अच्छा था, लेकिन Google के बाहर LLM बनाते समय उनके पुराने सहकर्मी PyTorch से ज़्यादा JAX क्यों recommend करते थे, यह साफ़ नहीं है।
अच्छा होगा अगर यह नई कंपनी बाद में अपनी training journey पर कोई और technical report निकाले। उदाहरण के लिए यहाँ दिए गए इस PDF की तरह: https://github.com/facebookresearch/metaseq/tree/main/projec...
शायद इसमें Google bias भी मिला हुआ होगा।
बड़ा सवाल यह है कि सही background और pedigree के बिना कोई छोटा startup LLM product के साथ funding कैसे जुटाता है।
LLM startup की दुनिया अब hedge fund और private equity की दुनिया जैसी लगने लगी है।
seed investment और fundraising के लिए शुरुआती शर्तें शायद ये लगती हैं: A) प्रतिष्ठित करियर और सही pedigree, B) ऐसा मज़बूत investor network जो product शुरू होने से पहले ही कूद पड़ने को तैयार हो।
शायद यही वजह है कि VC ऐसी कंपनियों में निवेश करते हैं।
दुनिया भर में सही अनुभव रखने वाले, जो funding जुटा सकें, ऐसे लोग बहुत कम हैं; और funding जुटा सकने वाले लोग ही वैसा अनुभव हासिल कर पाते हैं, इसलिए स्वाभाविक entry barrier बन जाता है।
कम-से-कम तब तक तो यही सच लगता है जब तक compute cost पर्याप्त सस्ती नहीं हो जाती।
जब वे कहते हैं, “हमने कंपनी बनाई, पैसा जुटाया, chips खरीदे, और एक साल से भी कम समय में सब कुछ scratch से बनाकर Gemini Pro/GPT 3.5 के बराबर पहुँच गए और कई models को पीछे छोड़ दिया,” तो यह जानने की जिज्ञासा होती है कि GPT 3.5 स्तर के LLM तक पहुँचने के लिए chips या cloud GPU पर कुल कितना budget खर्च हुआ होगा।
क्या मोटे तौर पर यह 2 million से 5 million dollars के आसपास रहा होगा?
लगता है title में “ground zero” की जगह “from the ground up” होना चाहिए था: https://en.wikipedia.org/wiki/Hypocenter
मुहावरे के रूप में यह पूरी तरह स्वीकार्य usage है।
शायद मतलब यह हो कि LLM tech industry के लिए रूपकात्मक nuclear bomb है, लेकिन सच कहूँ तो मैं भी उलझ गया था।
मैं ऐसे लेखक से सीखना नहीं चाहूँगा।
Google के systems स्थिर इसलिए हैं क्योंकि Google ने 25 साल तक data center hardware, software, और process development में दसियों अरब dollars निवेश किए हैं।
किसी छोटे और कम परिपक्व संगठन की बहुत सक्षम team भी हमेशा तुलना में कहीं कम quality वाला नतीजा देगी।
एक और बात है priority।
Google reliability को प्राथमिकता देता है, और जो parts अपेक्षाकृत कम fail होते हुए भी बार-बार समस्या देते हैं, उन्हें retire कर देता है।
छोटे और कम sophisticated data centers अक्सर बार-बार खराब होने वाले parts भी इस्तेमाल करते रहते हैं, या किसी खास part के failure rate को monitor तक नहीं करते।
छोटे data centers कभी-कभी Google के पुराने parts और कम reliable parts खरीदकर भी इस्तेमाल करते हैं।
इसलिए machines unstable हों, तो इससे hardware team की क्षमता के बारे में ज़रूरी नहीं कि कुछ साबित हो।
अगर hardware की कम reliability काम को धीमा कर रही है, तो software को इस तरह बेहतर बनाना चाहिए कि वह unstable hardware को सह सके, या फिर ज़्यादा reliable लेकिन महंगे hardware provider के पास जाना चाहिए।