- Uygulamaları kullanıcılara yakın konumlarda çalıştıran Fly.io’ya GPU desteği eklendi; böylece yapay zeka çıkarımı merkezi bir bölge yerine edge’e yakın konumlandırılabiliyor
- Uygulamalara Nvidia A100 bağlanarak CUDA ve büyük kapasiteli VRAM kullanılabiliyor; konuşma tanıma, metin parçalama, makale özetleme, görüntü üretimi ve kod yardımcı modellerini çalıştırma gibi işlerde kullanılabiliyor
- Ollama tabanlı bir GPU uygulaması,
fly.toml içinde vm.size = "a100-40gb" ve ollama/ollama imajı belirtilip fly apps create ve fly deploy ile dağıtılabiliyor
- GPU destekli bölgelerde aynı program aynı açık IP ve TLS sertifikasıyla çalıştırılabiliyor;
fly scale count 2 --region ams gibi bir komutla Amsterdam bölgesine ölçeklenebiliyor
- A100 40GB saatlik $2.50, A100 80GB $3.50, L40s ise $2.50; otomatik başlatma ve durdurma ayarlanırsa istek yokken GPU süresi ücretinden kaçınılabiliyor
Kullanıcıya yakın konumlandırılan GPU çalıştırma
- Fly.io, full-stack uygulamaları veya Fly Machines API tabanlı geliştirme platformlarını kullanıcılara yakın konumlarda çalıştırmaya yarayan bir bulut; buna GPU çalıştırma desteği ekledi
- Fly.io GPU, Nvidia A100’ü uygulamaya bağlayarak CUDA ve yerel 4090’dan daha fazla VRAM kullanılmasını sağlıyor
- Uygulanabilir AI/ML işleri şunlar
Ollama GPU uygulaması dağıtımı
- Fly.io, kullanıcıların tercih ettikleri modelleri ve doğrudan yazdıkları kodu Fly.io bulut omurgası üzerinde dağıtmasını hedefliyor
- Ollama tabanlı bir GPU uygulaması yalnızca
fly.toml yapılandırması ve dağıtım komutlarıyla çalıştırılabiliyor
app = "sandwich_ai"primary_region = "ord"vm.size = "a100-40gb"- Build imajı
ollama/ollama
/root/.ollama konumuna 100gb hacim bağlanıyor
- Çalıştırma komutu şöyle
fly apps create sandwich_ai && fly deploy
Bölgeye yakın yerde yapılan çıkarım
- Fly.io’nun vurguladığı nokta yalnızca GPU sağlamak değil, edge çıkarımı
- Örnek uygulama, kullanıcının mutfağındaki malzemeleri girdiğinde sandviç tarifi aldığı bir yapıda
primary_region = "ord" ile dağıtıldığında Chicago yakınındaki kullanıcılar sandviç tarifini hızlıca alabiliyor- Chicago dışındaki kullanıcılar, örneğin Amsterdam’dakiler, istek Atlantik’i aşmak zorunda kaldığı için daha uzun bekleyebiliyor
- GPU destekli bölgelerde aynı program aynı açık IP adresi ve aynı TLS sertifikasıyla çalıştırılabiliyor
- Amsterdam’a genişletme şu komutla yapılıyor
fly scale count 2 --region ams
GPU’yu yalnızca istek olduğunda kullanma
- GPU güçlü bir paralel işleme birimi olsa da ucuz değil; küçük uygulamalar için yalnızca kullanıcı istek yaptığında ödeme yapılan bir yapı avantajlı
fly.toml içindeki services bölümünde otomatik başlatma ve otomatik durdurma ayarlanabiliyor
[[services]]
internal_port = 8080
protocol = "tcp"
auto_stop_machines = true
auto_start_machines = true
min_machines_running = 0
auto_stop_machines = true ve auto_start_machines = true, istek yokken makineleri durdurup gerektiğinde yeniden başlatan ayarlarmin_machines_running = 0 ise sandviç tarifi isteği olmadığında GPU süresi maliyeti ödenmemesini sağlıyor
Sunulan GPU’lar ve temel kaynaklar
- GPU’lar çeşitli ABD ve AB bölgeleri ile Sydney’de kullanılabiliyor
- Dağıtım hedefleri ve fiyatlar şöyle
- GPU’ya dağıtılan uygulamalar varsayılan olarak 8 adet AMD EPYC CPU çekirdeği kullanıyor
- Hacimler en fazla 500GB’a kadar bağlanabiliyor
- Rezerve instance’lar ve dedicated host’lar için indirim de sunulabiliyor
1 yorum
Hacker News yorumları
Fly'ın temel işlevleri gerçekten doğru düzgün yerine getirip getirmediğinden şüpheliyim. Gerçek prodüksiyonda kullanınca destek ekibinin dahili platform sorunlarını göremeyecek düzeyde olduğunu, hata mesajlarının da muğlak ya da hiç olmadığını görmek hayal kırıklığı yarattı.
Kubernetes'ten korkan ya da onu pek bilmeyen kişilere cazip görünebilir ama Fly kullandıkça aksine Kubernetes'i özler oldum.
watch -n 2 curlçalıştırırsanız bunu kendiniz de görebilirsiniz; belgelenmiş stratejilerden, blue-green dâhil, hangisini kullansam böyle oldu.En kötü ihtimalle yalnızca mevcut bağlantıların erken sonlandırılmasını, yeni bağlantıların kopmamasını bekliyordum; en iyi senaryo ise mevcut bağlantılar bitene kadar zarifçe beklemesiydi. Ama gerçekte her seferinde tam kesintili bir geçiş yaşandı. Blogda anlatılan ağ topolojisini düşününce, bunun en baştan düzgün uygulanamayacağı hissine kapılıyorum.
Bir servis hakkında olumsuz yorum yapmak pek yaptığım bir şey değil; fakat video kanıtı bile göndermemize rağmen destek ekibinin sanki tuhaf olan bizmişiz gibi yanıt vermesi, bir altyapı şirketi için epey rahatsız ediciydi. Artık oyuncak uygulamalar dışında önermiyorum.
Kubernetes için oldukça büyük bir dağıtım sistemi de yaptım; yani bu sorun Kubernetes'i bilmediğim için söylediğim bir şey değil. Düzgün bir Heroku tarzı dağıtım için kesinlikle bir alan var, ama ya kimse bunu iyi yapmıyor ya da sunulan compute kaynakları saçma derecede zayıf veya pahalı.
Yönetilen gibi paketlenmiş yönetilmeyen DB, rastgele kesintiler vb. daha da sayabilirim; ama prodüksiyona hazır bir servis olmadığı için birkaç ay önce ayrıldık.
Başta Fly için çok heyecanlıydım ve Fly Machines üzerine komple bir orkestratör bile kurdum; ama günler süren bir arıza yaşandı ve yanıt almak da günler sürdü.
Kubernetes karmaşık olabilir, fakat o karmaşıklık en azından kontrol edilebilir ve zaten fazlasıyla doğrulanmış bir yol.
Yazının yazarı ve Fly.io geliştirici ilişkileri sorumlusuyum. Sorularınız varsa yanıtlayabilirim. GPU'lar dün genel kullanıma açıldı; dolandırıcılık önleme algoritması tanrıları izin verirse dilediğiniz gibi deney yapabilirsiniz.
Asıl şaşırtıcı olan, “GPU”nun gerçekte ne olduğuna dair yazdığım açıklama yazısının burada pek ilgi görmemesi: https://fly.io/blog/what-are-these-gpus-really/
Üretim süreci node avantajı ve SoC/HBM'e öncelikli erişim, yazılımın yetişmesine yetecek kadar uzun süre korunabilir mi? Üst seviye Metal ekipmanı pahalı görünüyor; ama 64GB+ sınıfında oldukça yüksek bellek bant genişliği ve özel FP vektör birimleri olan NVIDIA ile kıyaslayınca tablo farklı görünüyor.
fly.iogibi bir platformla inference iş yükleri cihazın içine ve dışına taşınabilirse, edge ağırlıklı uygulamalara ciddi bir esneklik kazandırabilir gibi.Tıbbi görüntü segmentasyonu iş akışında bir dosya yaklaşık 5 dakika sürüyor.
Bildiğim kadarıyla Fly, VM'ler için Firecracker kullanıyor. Firecracker'ı bir süredir takip ediyorum ve projede de kullandım; temel olarak GPU desteklemiyor ve destekleme planı da yok [1].
Fly'ın Firecracker ile kendi GPU desteğini nasıl çözdüğünü merak ediyorum. Eskiden belirli bir özelliği nasıl uyguladıklarına dair çok ayrıntılı teknik yazılar yayımlıyorlardı; GPU desteği hakkında da ileride bir yazı çıkarsa güzel olur.
[1]: https://github.com/firecracker-microvm/firecracker/issues/11...
0'a kadar scale down yapabilmesi harika. Kullanıcı sayısı az olduğu için küçük bir sunucu maliyetini bile gerekçelendirmesi zor olan deneysel site işleri için özellikle faydalı.
Tek bir isteğin yaklaşık ne kadar süre üzerinden ücretlendirildiğine dair bir örnek olsa güzel olurdu. Elbette değişir ama 2 saniye mi, yoksa “spin-up başına minimum 60 saniye” mi merak ediyorum.
GPU makinelerinin kullanışlı hâle gelmesi, GPU belleğine giren veri boyutuna bağlı olarak yaklaşık 30 saniye çalışma süresi gerektirebilir.
Fly.io’yu erken dönemde benimsemişti ama prodüksiyona hazır değildi. Yeni özellikler eklemeden önce temel işlevleri düzeltmeleri gerekiyor
Biraz daha fazla yapılandırma gerekiyor ve fiyatı da epey daha pahalı, ama prodüksiyonda istikrar gerekir. Kesintiler yüzünden müşterilerin aramasına yol açamam
Yazılım bozulabilir, ama Fly’ın olaylara müdahale yaklaşımı profesyonellikten uzak ve olgunlaşmamış. Temelde sadece “iyi görünen” istikrarsız bir hizmete 10 kat fazla ödüyorsunuz
Şimdi Hetzner + Kamal ile çok daha iyi donanımı maliyetin dörtte birine kullanıyorum; kararlı çalışıyor, fiyatı öngörülebilir ve gelecek ay aynı kullanıma %25 daha fazla ödeme durumu yok
https://news.ycombinator.com/item?id=36808296
GPU duyurusundan bağımsız olarak Fly’da bir S3 alternatifi olmasını isterdim. Şu anda GNU Affero lisanslı bir proje öneriyorlar; bu da şirketler açısından bir engel
Kullanıcı varlıklarını saklamak için Fly’ın dışına çıkmak zorunda kalacaksam, bir sonraki projede Fly kullanmak zorlaşır. Basitliğini, fiyat/performansını ve yerleşik VPN’ini sevdiğim için yazık
https://benhoyt.com/writings/flyio-and-tigris/ Burada da tartışılmış: https://news.ycombinator.com/item?id=39360870
https://fly.io/docs/reference/tigris/
S3 benzeri bir hizmete yalnızca HTTPS API üzerinden erişiyorsanız, bu yüzden kodunuz AGPL kapsamına girmez
Bu hizmetin hedef pazarının kim olduğunu merak ediyorum. Bir yapay zeka modeli çalıştırması gereken, ama açık kaynak model barındırma sunan sayısız fiyat rekabetçisi startup’ı kullanmayan ya da kullanamayan küçük ve doğrulanmamış uygulamalar mı?
Modelleri ve donanımı doğrudan epey işletmiş biri olarak, fiziksel donanıma kadar kontrol etme isteğini anlıyorum. Yine de kimin hedeflendiğini bilmek isterim
Pratikte çıkarımın kendisi uzun sürdüğü için bu fark çok önemli olmayabilir
GPU işleminin aynı veri merkezinde ya da en azından aynı bulut sağlayıcısında olması büyük avantaj olabilir. Birden fazla sağlayıcıda A100’lerin tükenmesi de nadir değildi; büyük sağlayıcılarda bile bunu birkaç kez yaşadım. Belirli bir bölgeye bağlı değilseniz daha az sorun
Her sağlayıcı işe yarar bir isteğe bağlı 0’a ölçeklendirme modeli sunmuyor. Fly’da uzun vadede ne kadar iyi işleyeceğini bilmiyorum ama bu da başka bir avantaj olabilir
Fiyat rekabetçisi startup’lar uzun süre dayanamama eğiliminde; 100 tanesinden yalnızca çok azının hayatta kaldığı bir yapıya daha yakın
Zaten Fly kullanıyorsanız ve yalnızca birkaç kez gizli teknoloji demosu değerlendirtecekseniz, Fly GPU fazla düşünmeden seçilecek varsayılan seçenek olabilir. Elbette Hugging Face hizmetlerini kullanmak daha yaygın da olabilir
Çeşitli nedenlerle kendi donanımını işletemeyen çok şirket var; en iyi ihtimalle başka bir veri merkezinde rack kiralarlar, ama küçük kullanım senaryoları için bunun her zaman değeri yoktur. A100’e ihtiyaç duyup yalnızca haftalık analiz gibi seyrek çalıştıranlar da var; haftada 1 saatin altındaysa fiyat rekabetçisi hizmetler o kadar cazip olmayabilir
Tarif örneği ya da herhangi bir LLM kullanım senaryosu, edge çıkarımı vurgulamak için çok kötü bir örnek gibi görünüyor. Çünkü gidiş-dönüş gecikmesine birkaç yüz ms eklenmesi pek önemli değil
Ancak kötüye kullanım potansiyeli yüksek bir alan olduğu için şimdilik kimse buna bulaşmak istemiyor gibi. Muhtemelen sonraki yazıda bunu ele alırlar; öyleyse kendi Perplexity tarzı çevrim içi GPT’lerini yapmaları gerekir. Şimdilik bilerek sıradan bir tanıtım yapıp başka fikirler çıkıyor mu diye bakıyorlar gibi
Performansını deneyen biri var mı merak ediyorum. İlk izlenim olarak oldukça pahalı görünüyor. Örneğin Hetzner CPU makineleriyle karşılaştırınca öyle
Hatta H100’ü bile saatlik 2,24 dolara, bu fiyattan daha ucuza bulmak mümkün
Bu yüzden biraz pahalı görünüyor; ancak müşteri talebi yüksek ve arz yetersiz olduğu için de olabilir
Fly.io’nun ücretsiz katmanında Uptime Kuma çalıştırıp çalışma süresi izleme yapıyorum. İnanılmaz iyi çalışıyor, çok memnunum