Fly.io के पास अब GPUs हैं
Fly.io ने GPU-backed virtual machines पेश किए हैं, जिनमें scale-to-zero billing है, ताकि मौजूदा Fly-hosted apps के साथ on-demand AI workloads चलाना आसान हो सके। Commenters इस बात की पड़ताल करते हैं कि pricing और cold-start costs (model loading, large images, volumes) क्या DigitalOcean, Runpod, और Vast.ai जैसे विकल्पों के मुकाबले प्रतिस्पर्धी हैं, और यह भी बहस करते हैं कि सामान्य LLM और image workloads के लिए “edge” GPU inference कितना उपयोगी है। एक बार-बार उठने वाली चिंता production उपयोग के लिए Fly.io की reliability और support maturity है, हालांकि कुछ उपयोगकर्ता सहज अनुभव बताते हैं और emerging S3-compatible storage तथा flexible VM lifecycle control जैसी पूरक सुविधाओं पर ध्यान दिलाते हैं।
मूल्य निर्धारण और प्रतिस्पर्धा
- कई लोगों को लगता है कि Fly के GPU दाम कुछ प्रतिस्पर्धियों (DigitalOcean, AWS, विभिन्न “race-to-zero” GPU startups) की तुलना में ऊँचे हैं, खासकर लंबे समय की प्रतिबद्धताओं के बिना।
- अन्य लोग ध्यान दिलाते हैं कि ऑन-डिमांड GPU सप्लाई हर जगह तंग है; “सस्ते” दिखने वाले दाम अक्सर बहु-वर्षीय प्रतिबद्धताओं के साथ आते हैं या व्यवहार में उपलब्ध नहीं होते।
- कुछ लोग लागत की तुलना Modal और Replicate जैसे प्लेटफ़ॉर्म से अनुकूल रूप में करते हैं, और hosted inference में अधिक प्रतिस्पर्धा का स्वागत करते हैं।
प्रदर्शन, Cold Starts, और मॉडल लोडिंग
- Spin-up time VM boot से कम और GPU images तथा model weights से अधिक प्रभावित होता है।
- बड़े base images (1–3+ GB) और model files डाउनलोड करने में 30–120 सेकंड जुड़ सकते हैं; multi‑GB models को VRAM में लोड करना एक बड़ा कारक है।
- Local NVMe volumes पर संग्रहीत weights को दोबारा उपयोग किया जा सकता है, जिससे repeated downloads कम होते हैं; कई commenters remote/network-style storage for models को खराब विचार मानते हैं।
शून्य तक स्केलिंग और “Keep Warm” व्यवहार
- Billing तब शुरू होती है जब machine boot होती है और तब समाप्त होती है जब वह रुकती है, बिना किसी enforced minimum के।
- सही restart policy के तहत code 0 के साथ exit करके machines scale down होती हैं; “keep warm” को user code में delayed exit या custom logic के जरिए लागू किया जाता है।
- kill signals और timeouts जैसे runtime options shutdown व्यवहार पर कुछ नियंत्रण देते हैं।
लक्षित उपयोग-केस और बाज़ार
- Intended users में मौजूदा Fly apps शामिल हैं जिन्हें GPUs चाहिए, hosting/AI platforms बनाने वाले लोग, और ऐसे workloads जो कभी-कभार GPU bursts तथा scale-to-zero economics से लाभ लेते हैं।
- कुछ लोग “GPU चाहिए लेकिन scale-to-zero भी चाहिए” वाले बाज़ार के आकार पर सवाल उठाते हैं, और यह भी कि edge GPU inference, standard datacenter inference से वास्तव में कितना अलग है।
इन्फ्रास्ट्रक्चर और वर्चुअलाइज़ेशन
- GPU VMs में Cloud Hypervisor (Firecracker नहीं) का उपयोग होता है, PCI passthrough के साथ, vGPU के साथ नहीं।
- Operationally, Fly के दृष्टिकोण से Cloud Hypervisor और Firecracker को समान बताया गया है।
विश्वसनीयता और सपोर्ट संबंधी चिंताएँ
- Thread में तीखा असहमति-भरा रुख है: कुछ लोग कई महीनों या एक साल तक सहज उपयोग की रिपोर्ट करते हैं; अन्य Fly को “not production ready” कहते हैं, outages, flaky deploys, non-spinning machines, और कमजोर या सिर्फ forum-only support का वर्णन करते हैं।
- Fly का अपना messaging ज़ोर देता है कि उनका Postgres offering पूरी तरह managed नहीं है; कुछ उपयोगकर्ता इससे हैरान थे और इसे एक कमी मानते हैं।
Storage / S3 Replacement
- First-class S3-compatible service की कमी कुछ लोगों के लिए blocker थी।
- कई comments एक beta में मौजूद, Fly-integrated S3 replacement (Tigris / regional object store) की ओर इशारा करते हैं।
- सुझाए गए AGPL-based S3 alternatives की licensing कॉरपोरेट policies के कारण विवादास्पद है जो AGPL के खिलाफ हैं।