Fly.io में अब GPU भी

 (fly.io)
1 पॉइंट द्वारा GN⁺ 2024-02-14 | 1 टिप्पणियां | WhatsApp पर शेयर करें
  • उपयोगकर्ताओं के करीब ऐप चलाने वाले Fly.io में GPU support जुड़ गया है, जिससे AI inference को किसी केंद्रीय region के बजाय edge के करीब रखा जा सकता है
  • ऐप में Nvidia A100 जोड़ा जा सकता है, ताकि CUDA और बड़े VRAM का उपयोग हो सके; इसका इस्तेमाल speech recognition, text segmentation, article summarization, image generation और code assistant models चलाने में किया जा सकता है
  • Ollama-आधारित GPU app को fly.toml में vm.size = "a100-40gb" और ollama/ollama image निर्दिष्ट करने के बाद fly apps create और fly deploy से deploy किया जा सकता है
  • GPU support वाले regions में वही program उसी public IP और TLS certificate के साथ चलाया जा सकता है, और fly scale count 2 --region ams की तरह Amsterdam region में scale किया जा सकता है
  • A100 40GB की कीमत $2.50 प्रति घंटा, A100 80GB की $3.50, और L40s की $2.50 है; auto start/stop सेट करने पर requests न होने पर GPU time billing से बचा जा सकता है

उपयोगकर्ताओं के करीब GPU execution

  • Fly.io एक cloud है जो full-stack apps या Fly Machines API आधारित development platforms को उपयोगकर्ताओं के करीब चला सकता है, और अब इसमें GPU execution जोड़ा गया है
  • Fly.io GPU, Nvidia A100 को app से जोड़कर CUDA और local 4090 से ज्यादा VRAM का उपयोग करने देता है
  • लागू होने वाले AI/ML workloads इस प्रकार हैं
    • speech recognition
    • text segmentation
    • article summarization
    • image synthesis
    • DeepSeek-Coder जैसे चुने गए models का उपयोग करके programming assistance

Ollama GPU app deploy करना

  • Fly.io का लक्ष्य यह है कि users अपने पसंदीदा models और खुद लिखे code को Fly.io cloud backbone पर deploy कर सकें
  • Ollama आधारित GPU app को सिर्फ fly.toml configuration और deploy commands से चलाया जा सकता है
    • app = "sandwich_ai"
    • primary_region = "ord"
    • vm.size = "a100-40gb"
    • build image ollama/ollama है
    • /root/.ollama पर 100gb volume mount किया जाता है
  • चलाने की command यह है
fly apps create sandwich_ai && fly deploy
  • Scaling Large Language Models to zero with Ollama में यह बताया गया है कि Ollama इस्तेमाल में न होने पर उसे automatically scale down करने के लिए कैसे configure किया जाए

region के करीब inference चलाना

  • Fly.io जिस बात पर जोर देता है, वह सिर्फ GPU उपलब्ध कराना नहीं बल्कि edge inference है
  • example app की संरचना ऐसी है कि user kitchen में मौजूद ingredients दर्ज करता है और sandwich recipe प्राप्त करता है
  • primary_region = "ord" के साथ deploy करने पर Chicago के पास के users को sandwich recipe जल्दी मिल सकती है
  • Chicago के बाहर के users, उदाहरण के लिए Amsterdam users, के requests को Atlantic पार करना पड़ सकता है, इसलिए ज्यादा समय लग सकता है
  • GPU support वाले regions में वही program उसी public IP address और उसी TLS certificate के साथ चलाया जा सकता है
  • Amsterdam में विस्तार निम्न command से किया जाता है
fly scale count 2 --region ams

सिर्फ request आने पर GPU इस्तेमाल करना

  • GPU शक्तिशाली parallel processing devices हैं, लेकिन सस्ते नहीं होते; इसलिए छोटे apps के लिए ऐसा configuration फायदेमंद है जिसमें users की request आने पर ही लागत लगे
  • fly.toml के services section में auto start और auto stop configure किए जा सकते हैं
[[services]]
  internal_port = 8080
  protocol = "tcp"
  auto_stop_machines = true
  auto_start_machines = true
  min_machines_running = 0
  • auto_stop_machines = true और auto_start_machines = true ऐसी settings हैं जो requests न होने पर machines को रोक देती हैं और जरूरत पड़ने पर फिर शुरू करती हैं
  • min_machines_running = 0 होने पर, sandwich recipe requests न होने पर GPU time cost नहीं देनी पड़ती

उपलब्ध GPU और default resources

  • GPU कई US और EU regions तथा Sydney में उपलब्ध हैं
  • deployment targets और pricing इस प्रकार हैं
  • GPU पर deploy होने वाले apps default रूप से AMD EPYC CPU के 8 cores का उपयोग करते हैं
  • volumes को अधिकतम 500GB तक जोड़ा जा सकता है
  • reserved instances और dedicated hosts के लिए discounts भी दिए जा सकते हैं

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

1 टिप्पणियां

 
GN⁺ 2024-02-14
Hacker News की राय

  • मुझे शक है कि Fly ने अपनी बुनियादी सुविधाएँ भी ठीक से तैयार की हैं या नहीं। असली production में इस्तेमाल करके देखा तो support team अपने internal platform issues तक देख नहीं पा रही थी, और error messages धुंधले थे या बिल्कुल नहीं थे, इसलिए काफी निराशा हुई
    Kubernetes से डरने वाले या उसे ठीक से न जानने वाले लोगों को यह आकर्षक लग सकता है, लेकिन Fly इस्तेमाल करते-करते उल्टा Kubernetes की याद आने लगी

    • Fly.io पर migrate करने के लिए test किया था, लेकिन साधारण deployment में भी switch के दौरान कुछ सेकंड के लिए connection टूट गया। deployment के दौरान watch -n 2 curl चलाकर इसे खुद देख सकते हैं, और documented strategies—blue-green सहित—कोई भी इस्तेमाल करें, यही हुआ
      मेरी उम्मीद थी कि सबसे खराब हालत में भी सिर्फ मौजूदा connections जल्दी खत्म होंगे और नए connections नहीं टूटेंगे; सबसे अच्छी हालत में existing connections खत्म होने तक graceful wait होगा। लेकिन असल में हर बार पूरी तरह downtime वाला switch हुआ। blog में दिखाई गई network topology को देखते हुए लगता है कि शायद इसे शुरू से ही सही ढंग से implement किया ही नहीं जा सकता था
      मैं किसी service पर negative comment कम ही करता हूँ, लेकिन video evidence भेजने के बाद भी support team ने ऐसे react किया जैसे अजीब हम ही हों—यह एक infrastructure company के हिसाब से काफी खटका। अब toy apps के अलावा इसे recommend नहीं करता
      Kubernetes के लिए मैंने काफी बड़ा deployment system भी बनाया है, इसलिए यह बात Kubernetes न जानने की वजह से नहीं कह रहा। अच्छे Heroku-style deployment के लिए जगह साफ तौर पर है, लेकिन या तो कोई इसे ठीक से नहीं कर रहा, या compute resources बेवजह बहुत पतले या महंगे हैं
    • कृपया और detail username के पहले दो अक्षर @fly.io पर email करें। किस वजह से दिक्कत हुई, यह समझकर जितना संभव हो स्थिति सुधारना चाहते हैं
    • सही कहा, reliability और support बहुत खराब हैं। एक बार 2 दिन तक deploy नहीं कर पाया, और सचमुच जवाब मिला कि किसी दूसरी company का इस्तेमाल करें
      Managed जैसा दिखाया गया unmanaged DB, random downtime वगैरह पर और भी कह सकता हूँ, लेकिन यह production-ready service नहीं थी, इसलिए कुछ महीने पहले छोड़ दिया
    • अफसोस, लेकिन यह काफी common pattern है। मेरे जिन जान-पहचान वालों ने Fly अपनाया, उनमें से आधे कहीं और चले गए
      शुरुआत में Fly को लेकर बहुत उत्साहित था और Fly Machines के ऊपर पूरा orchestrator तक बना लिया था, लेकिन कई दिनों की outage हुई और जवाब मिलने में भी कई दिन लग गए
      Kubernetes जटिल हो सकता है, लेकिन वह complexity कम से कम controllable है और पहले से काफी proven path है
    • करीब 1 साल से Fly पर कई services चला रहा हूँ, अब तक कोई समस्या नहीं आई

  • मैं इस post का लेखक और Fly.io का developer relations प्रभारी हूँ। सवाल हों तो जवाब दे सकता हूँ। GPU कल officially launch हुए हैं, और अगर anti-fraud algorithm देवता अनुमति दें तो आप जी भरकर experiment कर सकते हैं
    बल्कि हैरानी है कि “GPU” असल में क्या है, इस पर लिखा guide यहाँ ज्यादा नहीं चला: https://fly.io/blog/what-are-these-gpus-really/

    • खास तौर पर Apple hardware पर inference को लेकर आपकी राय जानना चाहूँगा। Apple Silicon on-premises या desk-top environment में local inference tune करने में काफी समय लगा रहा हूँ, और GGUF जैसी चीजों में हुए काम को देखते हुए भी मुझे लगता है कि अभी बहुत गुंजाइश बाकी है
      क्या process node advantage और SoC/HBM की priority access software के catch up करने तक लंबे समय तक बनी रहेगी? high-end Metal machines महंगी लगती हैं, लेकिन 64GB+ class की काफी high memory bandwidth और dedicated FP vector units वाले NVIDIA से तुलना करें तो तस्वीर अलग दिखती है
      अगर fly.io जैसे platform से inference workloads को device के अंदर-बाहर move किया जा सके, तो edge-heavy applications को काफी freedom मिल सकती है
    • timing बिल्कुल सही है। आने वाले project के लिए serverless GPU service evaluate कर रहा हूँ। announcement देखकर लगा कि billing hourly है; scale down to 0 करते समय billing minute/second basis पर होती है या नहीं, यह जानना चाहूँगा
      medical image segmentation workflow में एक file में करीब 5 मिनट लगते हैं
    • launch की बधाई। हालांकि जानना चाहूँगा कि इस service के target users कौन हैं। क्या यह मुख्य रूप से मौजूदा fly.io customers के लिए है, जो fly.io sandbox के अंदर ही रहना चाहते हैं?
    • cold start कितना तेज है, और runpod या modal जैसे दूसरे GPU providers की तुलना में कैसा है, यह जानना चाहूँगा
    • सवाल नहीं है, लेकिन “Lovelace L40s are coming soon (pricing TBD)” link 404 दे रहा है

  • जहाँ तक मुझे पता है, Fly VMs के लिए Firecracker इस्तेमाल करता है। मैं Firecracker को कुछ समय से follow कर रहा हूँ और project में भी इस्तेमाल किया है, लेकिन यह मूल रूप से GPU support नहीं करता और support की कोई योजना भी नहीं है [1]
    उत्सुकता है कि Fly ने Firecracker के साथ अपना GPU support कैसे solve किया। पहले वे किसी specific feature को कैसे implement किया, इस पर बहुत detailed technical posts डालते थे, इसलिए GPU support पर भी बाद में कोई post आए तो अच्छा होगा
    [1]: https://github.com/firecracker-microvm/firecracker/issues/11...

    • संक्षेप में कहें तो GPU machines Firecracker नहीं, बल्कि Cloud Hypervisor इस्तेमाल करती हैं

  • 0 तक scale down handle कर पाना शानदार है। खासकर उन experimental sites पर काम करते समय उपयोगी है जहाँ users कम हैं और छोटे server का खर्च भी justify करना मुश्किल होता है
    अच्छा होगा अगर एक request पर roughly कितने समय की billing होती है, इसका example हो। जाहिर है बदलता रहेगा, लेकिन जानना चाहता हूँ कि यह 2 सेकंड है या “हर spin-up पर minimum 60 seconds” जैसा कुछ है

    • machine boot होने के समय से रुकने तक billing होती है। कोई enforced minimum time नहीं है, लेकिन आम तौर पर 5 seconds से कम में machine पर meaningful काम करना मुश्किल होता है
      GPU machine को उपयोगी होने के लिए, GPU memory में जाने वाले data size के आधार पर, करीब 30 seconds runtime चाहिए हो सकता है

  • Fly.io को शुरुआत में अपनाया था, लेकिन यह प्रोडक्शन के लिए तैयार नहीं है। नई सुविधाएँ जोड़ने से पहले बुनियादी चीज़ें ठीक करनी चाहिए

    • दुख की बात है, लेकिन सच है। शुरुआत में मुझे प्रोडक्ट से काफी उम्मीद थी, लेकिन मैंने fly.io छोड़ दिया और DigitalOcean के ऐप प्लेटफ़ॉर्म पर लौट गया
      सेटअप थोड़ा ज़्यादा चाहिए और कीमत भी काफ़ी ज़्यादा है, लेकिन प्रोडक्शन में स्थिरता चाहिए। सर्विस डाउन होने की वजह से ग्राहकों को फोन करने की नौबत नहीं आनी चाहिए
    • “चमकदार पैकेजिंग” वाली सेवाओं में, यह मेरे जीवन में इस्तेमाल की गई सबसे अस्थिर होस्टिंग थी। अक्सर एक साथ कई चीज़ें टूट जाती थीं, और status page हमेशा हरा दिखता रहता था जबकि मीटिंग्स और वीकेंड खराब हो जाते थे
      सॉफ़्टवेयर टूट सकता है, लेकिन Fly का incident response रवैया गैर-पेशेवर और अपरिपक्व है। असल में आप केवल देखने में “अच्छी” अस्थिर सेवा के लिए 10 गुना ज़्यादा दे रहे होते हैं
      अब मैं Hetzner + Kamal पर कहीं बेहतर हार्डवेयर एक-चौथाई लागत में इस्तेमाल कर रहा हूँ, यह स्थिरता से चलता है, कीमत अनुमानित रहती है, और अगले महीने उसी usage पर 25% ज़्यादा देने की नौबत नहीं आती
      https://news.ycombinator.com/item?id=36808296
    • HN पर ऐसे कमेंट देखकर अफ़सोस होता है। यह constructive नहीं है। आप जिन बुनियादी चीज़ों की बात कर रहे हैं वे ठीक-ठीक क्या हैं, और कौन-से सुधार चाहिए, यह लिखना चाहिए

  • GPU घोषणा से अलग, काश Fly के पास S3 का विकल्प होता। अभी वे GNU Affero प्रोजेक्ट सुझाते हैं, जो कंपनियों के लिए अड़चन है
    अगर user assets स्टोर करने के लिए Fly से बाहर जाना पड़े, तो अगले प्रोजेक्ट में Fly इस्तेमाल करना मुश्किल है। इसकी simplicity, value for money और built-in VPN अच्छे लगते हैं, इसलिए अफ़सोस है

  • मैं जानना चाहता हूँ कि इस सेवा का target market कौन है। क्या यह उन छोटे और अभी validated नहीं हुए apps के लिए है जिन्हें कोई AI model चलाना है, लेकिन जो open-source model hosting देने वाले ढेरों price-competitive startups का इस्तेमाल नहीं करते या नहीं कर सकते?
    खुद काफी model और hardware operate करके देखा है, इसलिए metal तक control करने की इच्छा समझता हूँ। बस यह जानना चाहता हूँ कि इसे किसके लिए बनाया जा रहा है

    • मेरे पास कुछ विचार हैं, लेकिन अभी साफ़ जवाब नहीं है। शायद यह hosting platforms बनाने वालों के लिए हो। ऐसी चीज़ें जो दिखने में hosting platform जैसी नहीं लगतीं, लेकिन असल में hosting platform ही होती हैं
    • Fly एक edge network है। सिद्धांत रूप में, अगर GPU server के पास हो और server user के पास हो, तो लेख में जिस तरह कहा गया है, app बहुत तेज़ हो सकता है
      व्यवहार में inference खुद ही लंबा समय लेता है, इसलिए यह फर्क शायद बहुत मायने न रखे
    • संक्षेप में, Fly GPU में दिलचस्पी लेने के कई छोटे कारण हैं, खासकर अगर आप पहले से Fly इस्तेमाल कर रहे हैं; लेकिन अगर आप पहले से किसी और cloud पर deploy कर रहे हैं, तो कोई एक निर्णायक वजह कम पड़ती है
      GPU compute अगर उसी datacenter में या कम से कम उसी cloud provider के भीतर हो, तो बड़ा फायदा हो सकता है। कई providers पर A100 stock खत्म होना भी दुर्लभ नहीं था, और बड़े providers में भी कई बार ऐसा हुआ। अगर आप किसी खास region से बंधे नहीं हैं तो यह समस्या कम है
      सभी providers उपयोगी on-demand 0 scale-down model नहीं देते। Fly पर long term में यह कितना अच्छा चलेगा पता नहीं, लेकिन यह एक और फायदा हो सकता है
      price-competitive startups लंबे समय तक टिक नहीं पाते, और यह लगभग ऐसा ढांचा है जिसमें 100 में से बहुत ही कम बचते हैं
      अगर आप पहले से Fly इस्तेमाल कर रहे हैं और कुछ private tech demos का evaluation करवाना है, तो Fly GPU ज्यादा सोचे बिना default option बन सकता है। बेशक Hugging Face services इस्तेमाल करना शायद ज्यादा आम हो
      कई कंपनियाँ अलग-अलग कारणों से अपना hardware operate नहीं कर सकतीं, और ज्यादा से ज्यादा किसी और datacenter में rack किराए पर लेती हैं, लेकिन छोटे use cases में यह हमेशा worthwhile नहीं होता। कुछ मामलों में A100 चाहिए होता है लेकिन केवल साप्ताहिक analytics जैसी दुर्लभ runs के लिए, और अगर प्रति सप्ताह 1 घंटे से कम usage है तो price-competitive service बहुत आकर्षक नहीं रह सकती
    • hosting services की तरफ price competition में bottom तक गिरने वाली बात ज्यादा नहीं दिखती। ज्यादातर GCP से कई गुना महंगी हैं, और GCP की public pricing खुद enterprise customers द्वारा असल में दी जाने वाली कीमत से कई गुना ऊँची होती है

  • recipe example या कोई भी LLM use case, edge inference को highlight करने के लिए बहुत खराब उदाहरण लगता है। round-trip latency कुछ सौ ms और बढ़ भी जाए तो ज्यादा फर्क नहीं पड़ता

    • बेहतर use case तो निश्चित रूप से edge पर voice assistant है। voice→text→search/GPT→voice response generation जैसे flow में ms मायने रखते हैं
      लेकिन यह क्षेत्र abuse की संभावना वाला है, इसलिए लगता है अभी कोई भी इसमें उलझना नहीं चाहता। शायद अगले लेख में इसे cover करेंगे, और अगर ऐसा है तो उन्हें अपना Perplexity-style online GPT बनाना होगा। अभी शायद जानबूझकर साधारण परिचय दिया गया है ताकि देखा जा सके कि और ideas आते हैं या नहीं
    • सहमत हूँ। edge पर LLM चलाने का कोई business case मेरे दिमाग में नहीं आता। क्या यह AI industry का Pets.com moment है?

  • जानना चाहूंगा कि क्या किसी ने इसकी performance इस्तेमाल करके देखी है। पहली नजर में यह काफी महंगा लगता है। उदाहरण के लिए, Hetzner CPU machines की तुलना में

    • बाकी जगहों का पता नहीं, लेकिन DigitalOcean पर 90GB RAM वाली A100 को 1.15 डॉलर प्रति घंटे में इस्तेमाल किया जा सकता है। यह लगभग एक-तिहाई कीमत है
      यहां तक कि H100 भी 2.24 डॉलर प्रति घंटे में मिल सकता है, जो इस कीमत से सस्ता है
      इसलिए यह थोड़ा महंगा लगता है, लेकिन शायद customer demand ज्यादा और supply कम होने की वजह से ऐसा हो

  • Fly.io के free tier पर Uptime Kuma चलाकर uptime monitoring कर रहा हूं। यह बेहद अच्छी तरह काम करता है, इसलिए बहुत संतुष्ट हूं

    • Uptime Kuma down हो गया है, यह notification आपको किससे मिलता है?