HN लॉन्च: TCP के ज़रिए वर्चुअल GPU कनेक्शन

 (thundercompute.com)
2 पॉइंट द्वारा GN⁺ 2024-08-10 | 1 टिप्पणियां | WhatsApp पर शेयर करें
  • CPU·storage·networking·memory के विपरीत, GPU अभी तक प्रचुर संसाधन के रूप में virtualized नहीं हो पाया है, और Thunder Compute इसे system layer पर हल करना चाहता है
  • सप्लाई बढ़ाने का फोकस सिर्फ ज़्यादा chips बनाने पर नहीं, बल्कि पहले से deployed GPU का बेहतर उपयोग कराने वाले software utilization पर भी है
  • मौजूदा optimization जहाँ inference batching या training job queueing जैसे workload layer तक सीमित रहे हैं, वहीं GPU virtualization अपेक्षाकृत कम संबोधित किए गए system क्षेत्र को लक्ष्य बनाता है
  • NVIDIA H100 को प्रति घंटा $1.38 से VS Code, CLI और browser में इस्तेमाल किया जा सकता है, और यह AWS की तुलना में 80% बचत, कोई contract नहीं, कोई egress fee नहीं और scalable storage को आगे रखता है
  • 4 साल तक stealth mode में research prototype बनाया गया, और कंपनी अपने cloud व enterprise partners के ज़रिए datacenter की GPU capacity improvement deploy करना चाहती है

GPU virtualization से कम utilization rate में सुधार

  • Thunder Compute का मानना है कि computing के कई scarce resources आखिरकार abundant हो गए, लेकिन GPU ने अभी वैसा transition नहीं किया है
  • GPU को abundant बनाने का तरीका सिर्फ अधिक chips बनाना नहीं है; यह पहले से deployed chips का बेहतर उपयोग कराने वाले software पर भी निर्भर करता है
  • फिलहाल GPU अक्सर पूरी तरह उपयोग नहीं होते, और मौजूदा solutions मुख्यतः workload layer पर केंद्रित हैं
    • inference requests को batch process करना
    • कई server fleets में training jobs को queue करना
  • CPU, storage, networking और memory में virtualization आम हो चुका है, लेकिन GPU में अभी वही स्तर का virtualization स्थापित नहीं हुआ है
  • इसी खाली क्षेत्र को system layer पर संबोधित करना Thunder Compute का मुख्य approach है

Product approach और deployment plan

  • Thunder Compute एक system lab है जिसका commercial focus है, और यह नवीनतम GPU virtualization research को production environments में लागू करना चाहता है
  • टीम खुद को Citadel Securities, Aquatic और AWS से आए infrastructure experts व systems researchers से बनी बताती है
  • 4 साल तक stealth mode में research prototype बनाया गया, और अब नतीजों को अपने cloud और enterprise partners के ज़रिए deploy किया जा रहा है
  • Product description के अनुसार NVIDIA H100 प्रति घंटा $1.38 से इस्तेमाल के लिए उपलब्ध है
    • VS Code, CLI और browser से access किया जा सकता है
    • AWS की तुलना में 80% बचत को आगे रखता है
    • कोई contract नहीं, कोई egress fee नहीं, और scalable storage प्रदान करता है
  • लक्ष्य datacenter GPU capacity को चरणबद्ध तरीके से बेहतर बनाना है

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

1 टिप्पणियां

 
GN⁺ 2024-08-10
Hacker News पर राय

  • काफ़ी दिलचस्प। पहले मुझे सिर्फ़ वीडियो ट्रांसकोडिंग के लिए GPU-over-IP की ज़रूरत पड़ी थी
    मेरे homelab server में कमजोर परफॉर्मेंस वाला AMD GPU था, जो हर बार वीडियो encoding की कोशिश करने पर kernel crash कर देता था, और gaming PC में NVIDIA RTX 3080 था। इसलिए मैंने https://github.com/steelbrain/ffmpeg-over-ip बनाया और Windows machine पर server, media server (Plex, Emby, Jellyfin वगैरह) पर client चलाया, तो यह बिल्कुल सही चला

    • अगर आपने इसे अभी तक Show HN पर नहीं डाला है, तो एक बार विचार कर सकते हैं
      https://gist.github.com/tzmartin/88abb7ef63e41e27c2ec9a5ce5d...
      https://news.ycombinator.com/showhn.html
      https://news.ycombinator.com/item?id=22336638
    • शीर्षक देखकर मेरी उम्मीद कुछ ऐसी ही थी। असली submission कोई उपयोगी general-purpose tool नहीं बल्कि paid cloud service निकली, यह थोड़ा निराशाजनक था; और हमेशा की तरह असली बात comments में थी
      वीडियो encoding के अलावा GPU-over-network कहाँ काम आ सकता है, यह भी जानने की जिज्ञासा है। latency बढ़ने पर machine learning या graphics-heavy workloads मुश्किल नहीं हो जाएंगे क्या?
    • दिलचस्प। सोच रहा हूँ कि क्या यह HLS की तरह कई timeslice files बनने वाले multi-file conversion को भी support करता है

  • अगर यह CPU/GPU boundary पर काम करता है, तो जो datasets VRAM में फिट नहीं होते, उनमें बहुत बड़ा I/O bottleneck नहीं बनता क्या? इसे लेकर थोड़ा भ्रम है
    हो सकता है मैंने इसके काम करने का तरीका गलत समझा हो, लेकिन अगर GPU I/O को intercept किया जा रहा है, तो हर epoch में पूरा dataset remote machine पर stream करना पड़ेगा, जो wasteful लगता है

    • system को लेकर आपकी समझ सही है। इसे practical बनाने के लिए हमने I/O cost कम करने वाली कई optimizations implement की हैं
      BERT inference performance यहाँ देख सकते हैं: https://youtu.be/qsOBFQZtsFM?t=69
      training में inference से ज़्यादा overhead है, और native performance के करीब पहुँचने के लिए हम additional optimizations implement कर रहे हैं

  • जो लोग जानना चाहते हैं कि यह असल में कैसे काम करता है, उन्हें देखकर लगता है कि यह process में library inject करके इन functions[1] को hook करता है और फिर service को forward करता है
    [1] https://pastebin.com/raw/kCYmXr5A

    • जिज्ञासा है कि आपने कैसे पता किया कि ये functions hook हुए हैं। मेरा अनुमान है कि ld/ldd का कोई flag होगा जो बताता है कि कौन-से symbols re-bind हो रहे हैं
      साथ ही मुझे लगता था कि symbol re-bind होने के लिए weak symbol होना चाहिए, लेकिन NVIDIA weak symbols expose नहीं करेगा, तो क्या इसका मतलब है कि यह मूल रूप से LD_PRELOAD तरीका है?
    • उम्मीद थी कि पूरे PCIe device को pass-through करने जैसा कोई जादुई तरीका होगा

  • दिलचस्प है, लेकिन मेरी ज़्यादा दिलचस्पी self-hosting में है। मेरे पास पहले से बहुत सारे GPU हैं, कुछ चल रहे हैं और कुछ idle पड़े हैं
    जानना चाहता हूँ कि क्या मौजूदा GPU इस्तेमाल करने के लिए self-hosting option है

    • अभी self-hosting support नहीं है, लेकिन लगता है कि यही technology वहाँ अच्छी तरह fit होगी
      efficient job scheduling, GPU sharing और ease of use जैसे फायदे self-hosted environment में भी सीधे लागू होंगे। आगे इस संभावना के लिए हम पूरी तरह खुले हैं
    • अपने GPU, चाहे fixed hardware हों या cloud, के ऊपर PyTorch जैसा usage experience चाहते हैं, तो https://github.com/run-house/runhouse देखें
    • अगर अपने GPU या cloud account इस्तेमाल करते हुए भी अच्छा developer experience चाहते हैं, तो SkyPilot देखें
    • Akash Network जैसी services से आप अपना GPU cloud में rent पर दे सकते हैं, और thundercompute.com से GPU rent भी कर सकते हैं। यह लगभग self-hosting जैसा चलाने वाले admin path के करीब है

  • बात समझ नहीं आ रही। ECS में जिस GPU instance की ज़रूरत है, उसे सीधे launch किया जा सकता है, तो ECS में instance launch करके आपके GPU को ECS में इस्तेमाल करने की ज़रूरत क्यों होगी?
    अलग से, असली Nitro के बजाय आधा-अधूरा Nitro क्यों इस्तेमाल करना चाहूँगा, यह भी समझ नहीं आता

    • अच्छा point है। इसके कुछ फायदे हैं
      अगर आप लगातार GPU-requiring development कर रहे हैं, तो आमतौर पर instance जितनी देर on रहता है, पूरी अवधि का भुगतान करना पड़ता है। Thunder इस्तेमाल करने पर आप सिर्फ़ उतनी देर GPU के लिए pay करते हैं जब वह सच में इस्तेमाल हो रहा हो। जब सिर्फ़ CPU code चल रहा हो, तब GPU time का खर्च नहीं लगता। विकल्प है instance को manually on/off करना, लेकिन यह झंझट भरा हो सकता है
      साथ ही आप जिस प्रकार और जितनी संख्या के GPU इस्तेमाल कर रहे हैं, उसे आसानी से scale कर सकते हैं। उदाहरण के लिए अगर आप सस्ते T4 instance पर develop कर रहे हैं और 8 A100 पर पूरा deep learning training job चलाना चाहते हैं, तो instance बदलने और environment फिर से setup करने की ज़रूरत नहीं; एक command चलाकर सीधे ज़्यादा powerful GPU पर चला सकते हैं
    • system के नजरिए से यह ज़्यादा transparent दिखता है। उदाहरण के लिए अगर किसी thin client पर GPU acceleration माँगने वाला GUI application (Matlab, SolidWorks, Blender) इस्तेमाल करना हो, तो ECS setup किए बिना भी संभव है
      GPU के बिना develop करते हुए simulation चलाते समय अचानक GPU attach कर सकते हैं, और यह AWS से काफी सस्ता लगता है। मूल रूप से यह Ray(https://www.ray.io/) जिस problem को solve करता है, उसे ज्यादा general-purpose तरीके से solve करता दिखता है। आधे GPU जैसी ज्यादा granular GPU sharing भी संभव हो सकती है, इसलिए बहुत उत्साह है

  • यहाँ काफी interest है, इसलिए हमने T4 instances free में खोलने का फैसला किया है। खुद इस्तेमाल करके अपने विचार बताएं

    • A100 और H100 की pricing कैसी होगी, यह जानना चाहता हूँ

  • बढ़िया। जिज्ञासा है कि क्या इसे MIG या vGPU के साथ भी चलाया जा सकता था

    • MIG या vGPU पर test नहीं किया है, लेकिन चूँकि वे मूल रूप से GPU को physically partition करने के तरीके हैं, इसलिए लगता है कि यह काम करेगा
      निकट भविष्य के major goals में से एक GPU sharing allow करना है। हम users को memory के किसी हिस्से तक limit नहीं करेंगे, बल्कि पूरा GPU memory इस्तेमाल करने देंगे, इसलिए यह MIG या vGPU से बेहतर हो सकता है

  • meaningful throughput के साथ real-world use में यह कैसा लगता है, जानना चाहता हूँ। क्या इसे hash cracking के लिए भी इस्तेमाल कर सकते हैं?
    network के पार virtual GPU के बारे में सोचते ही botnet याद आता है। खासकर https://www.hpcwire.com/2012/12/06/gpu_monster_shreds_passwo... का वह हिस्सा याद आता है: “Gosney को पहले Mosix के co-founder Professor Amnon Barak को यह convince करना पड़ा कि वह ‘दुनिया को एक विशाल botnet में बदलने की कोशिश नहीं कर रहे’”

    • दिलचस्प thought experiment है, लेकिन असल में हमारा system botnet से ज़्यादा AWS जैसा है, क्योंकि GPUs distributed नहीं हैं
      यह technology data center के अंदर बहुत flexible clusters बनाने की दिशा में रोचक applications दे सकती है, और हम वही explore कर रहे हैं

  • glx विकसित करने वाले मूल SGI engineers ने GPU transfer के लिए X11 mechanisms इस्तेमाल करने को बहुत सावधानी से design किया था, इसलिए GL stream को network पर भेजकर मेरी graphics card पर render करना काफी आसान था
    मतलब “hallway के अंत में supercomputer पर run करो और workstation पर render करो” जैसा। हाल के driver development में ऐसी consideration नहीं दिखती, इसलिए आम तौर पर यह अब संभव नहीं है। यह वास्तव में कितना उपयोगी था, पता नहीं। आमतौर पर अगर आपके पास अच्छा graphics card था तो CPU भी अच्छा होता था। फिर भी इसके साथ खेलने में मज़ा आता था, और machine room में चल रहे program को accelerated graphics मिलना अजीब तरह से आकर्षक था। एक बार मैं इस तरह glquake चलाने में सफल हुआ था

  • यह संभव है, यही impressive है, लेकिन सोचता हूँ कि network connection टूट जाए या 100% stable न हो तो क्या होगा
    अनुभव से देखा है कि driver local GPU के थोड़ा भी अजीब behave करने पर खराब प्रतिक्रिया देते हैं