Fly.io, kini dilengkapi GPU

 (fly.io)
1 poin oleh GN⁺ 2024-02-14 | 1 komentar | Bagikan ke WhatsApp
  • Dukungan GPU kini ditambahkan ke Fly.io, yang menjalankan aplikasi dekat dengan pengguna, sehingga inferensi AI dapat ditempatkan dekat edge alih-alih di region pusat
  • Aplikasi dapat dipasangi Nvidia A100 untuk memanfaatkan CUDA dan VRAM berkapasitas besar, dan bisa digunakan untuk pengenalan suara, pemotongan teks, peringkasan artikel, pembuatan gambar, serta menjalankan model bantu kode
  • Aplikasi GPU berbasis Ollama dapat di-deploy dengan menetapkan vm.size = "a100-40gb" dan image ollama/ollama di fly.toml, lalu menjalankan fly apps create dan fly deploy
  • Di region yang mendukung GPU, program yang sama dapat dijalankan dengan IP publik dan sertifikat TLS yang sama, dan dapat diskalakan ke region Amsterdam seperti fly scale count 2 --region ams
  • A100 40GB berharga $2.50 per jam, A100 80GB $3.50, dan L40s $2.50; dengan mengatur start/stop otomatis, biaya waktu GPU saat tidak ada permintaan bisa dihindari

Menjalankan GPU dekat dengan pengguna

  • Fly.io adalah cloud yang dapat menjalankan aplikasi full-stack atau platform pengembangan berbasis Fly Machines API dekat dengan pengguna, dan kini menambahkan eksekusi GPU
  • Fly.io GPU menghubungkan Nvidia A100 ke aplikasi agar dapat memanfaatkan CUDA dan VRAM yang lebih besar daripada 4090 lokal
  • Pekerjaan AI/ML yang dapat diterapkan antara lain:

Deploy aplikasi GPU Ollama

  • Fly.io menargetkan pendekatan di mana pengguna men-deploy model pilihan mereka dan kode yang mereka tulis sendiri di atas backbone cloud Fly.io
  • Aplikasi GPU berbasis Ollama dapat dijalankan hanya dengan konfigurasi fly.toml dan perintah deploy
    • app = "sandwich_ai"
    • primary_region = "ord"
    • vm.size = "a100-40gb"
    • Image build adalah ollama/ollama
    • Me-mount volume 100gb ke /root/.ollama
  • Perintah menjalankannya adalah sebagai berikut
fly apps create sandwich_ai && fly deploy

Inferensi yang dijalankan dekat region

  • Poin yang ditekankan Fly.io bukan sekadar menyediakan GPU, melainkan inferensi edge
  • Aplikasi contoh memiliki struktur di mana pengguna memasukkan bahan yang ada di dapur lalu menerima resep sandwich
  • Jika di-deploy dengan primary_region = "ord", pengguna di dekat Chicago dapat menerima resep sandwich dengan cepat
  • Pengguna di luar Chicago, misalnya di Amsterdam, mungkin memerlukan waktu lebih lama karena permintaan harus menyeberangi Atlantik
  • Di region yang mendukung GPU, program yang sama dapat dijalankan dengan alamat IP publik dan sertifikat TLS yang sama
  • Ekspansi ke Amsterdam dilakukan dengan perintah berikut
fly scale count 2 --region ams

GPU yang hanya dipakai saat ada permintaan

  • GPU adalah perangkat pemrosesan paralel yang kuat, tetapi tidak murah, sehingga untuk aplikasi kecil lebih menguntungkan menggunakan konfigurasi yang hanya membayar saat ada permintaan dari pengguna
  • Start otomatis dan stop otomatis dapat diatur di bagian services pada fly.toml
[[services]]
  internal_port = 8080
  protocol = "tcp"
  auto_stop_machines = true
  auto_start_machines = true
  min_machines_running = 0
  • auto_stop_machines = true dan auto_start_machines = true adalah pengaturan untuk menghentikan machine saat tidak ada permintaan dan menjalankannya kembali saat dibutuhkan
  • Jika min_machines_running = 0, maka tidak ada biaya waktu GPU saat tidak ada permintaan resep sandwich

GPU yang tersedia dan resource dasar

  • GPU dapat digunakan di beberapa region AS dan UE serta Sydney
  • Target deploy dan harganya adalah sebagai berikut
  • Aplikasi yang di-deploy ke GPU secara default menggunakan 8 core CPU AMD EPYC
  • Volume dapat dipasang hingga maksimum 500GB
  • Diskon untuk reserved instance dan dedicated host juga dapat disediakan

Bacaan terkait

1 komentar

 
GN⁺ 2024-02-14
Opini Hacker News

  • Saya ragu apakah Fly benar-benar sudah punya fungsi dasar yang matang. Saat dipakai di produksi sungguhan, saya kecewa karena tim support-nya sampai pada level tidak bisa melihat isu platform internal, dan pesan error-nya ambigu atau malah tidak ada sama sekali.
    Bagi orang yang takut atau kurang paham Kubernetes, ini mungkin terlihat menarik, tetapi setelah memakai Fly, saya justru jadi merindukan Kubernetes.

    • Saya mengujinya karena ingin migrasi ke Fly.io, tetapi bahkan deployment sederhana pun mengalami putus koneksi selama beberapa detik saat pergantian. Kalau menjalankan watch -n 2 curl saat deployment, Anda bisa melihatnya sendiri, dan ini terjadi apa pun strategi terdokumentasi yang dipakai, termasuk blue-green.
      Saya berharap skenario terburuknya hanya koneksi lama yang diakhiri lebih awal dan koneksi baru tidak terputus; skenario terbaiknya menunggu dengan mulus sampai koneksi lama selesai. Namun kenyataannya, setiap kali itu adalah pergantian dengan downtime penuh. Melihat topologi jaringan yang dijelaskan di blog mereka, saya merasa ini memang sejak awal tidak mungkin diimplementasikan dengan benar.
      Saya jarang memberi komentar negatif tentang sebuah layanan, tetapi bagi perusahaan infrastruktur, cukup mengganggu ketika support bertindak seolah-olah kamilah yang aneh, padahal kami bahkan mengirim bukti video. Sekarang saya tidak merekomendasikannya selain untuk aplikasi mainan.
      Saya juga pernah membuat sistem deployment yang cukup besar untuk Kubernetes, jadi ini bukan karena saya tidak paham Kubernetes. Jelas ada ruang untuk deployment ala Heroku yang benar, tetapi tampaknya belum ada yang melakukannya dengan baik, atau resource komputasinya sangat tipis atau mahal.
    • Tolong kirim detail lebih lanjut lewat email ke dua huruf pertama nama pengguna @fly.io. Saya ingin mencari tahu apa yang membuat Anda kesulitan dan memperbaiki situasinya sebisa mungkin.
    • Betul, reliabilitas dan support-nya buruk sekali. Pernah sekali selama 2 hari saya tidak bisa melakukan deployment, dan mereka benar-benar menjawab agar saya memakai perusahaan lain.
      Saya bisa cerita lebih banyak, seperti DB tidak terkelola yang dikemas seolah-olah managed, downtime acak, dan sebagainya, tetapi karena ini bukan layanan yang siap produksi, saya sudah pindah beberapa bulan lalu.
    • Sayangnya ini pola yang cukup umum. Separuh kenalan saya yang mengadopsi Fly sudah pindah ke tempat lain.
      Awalnya saya sangat antusias dengan Fly dan bahkan membuat seluruh orchestrator di atas Fly Machines, tetapi terjadi gangguan selama beberapa hari, dan untuk mendapat jawaban pun butuh beberapa hari.
      Kubernetes bisa kompleks, tetapi kompleksitas itu setidaknya bisa dikendalikan dan sudah menjadi jalur yang banyak teruji.
    • Saya menjalankan beberapa layanan di Fly selama hampir 1 tahun, dan sejauh ini belum mengalami masalah.

  • Saya penulis artikel sekaligus developer relations di Fly.io. Kalau ada pertanyaan, saya bisa menjawab. GPU sudah diluncurkan resmi kemarin, dan jika dewa algoritma anti-penipuan mengizinkan, Anda bisa bereksperimen sepuasnya.
    Justru saya terkejut tulisan penjelasan tentang apa sebenarnya “GPU” tidak terlalu berhasil di sini: https://fly.io/blog/what-are-these-gpus-really/

    • Saya khususnya penasaran dengan pandangan Anda tentang inference di hardware Apple. Saya menghabiskan banyak waktu untuk men-tuning inference lokal di lingkungan Apple Silicon on-premise atau di atas meja, dan meskipun mempertimbangkan banyaknya pekerjaan yang masuk ke hal-hal seperti GGUF, menurut saya masih ada banyak ruang tersisa.
      Apakah keunggulan process node dan akses prioritas ke SoC/HBM akan bertahan cukup lama hingga software bisa mengejar? Perangkat Metal kelas atas terlihat mahal, tetapi terlihat berbeda jika dibandingkan dengan NVIDIA yang punya bandwidth memori cukup tinggi di kelas 64GB+ dan unit vektor FP khusus.
      Jika platform seperti fly.io bisa memindahkan workload inference keluar-masuk perangkat, sepertinya itu bisa memberi banyak kebebasan untuk aplikasi yang sangat berorientasi edge.
    • Waktunya pas sekali. Saya sedang mengevaluasi layanan GPU serverless untuk proyek mendatang. Dari pengumumannya terlihat penagihannya per jam, tetapi saya penasaran apakah saat scale down ke 0, tagihannya dihitung per menit/detik.
      Dalam workflow segmentasi citra medis, satu file memakan waktu sekitar 5 menit.
    • Selamat atas peluncurannya. Namun saya penasaran siapa pengguna target layanan ini. Apakah terutama untuk pelanggan fly.io yang sudah ada dan ingin tetap berada di dalam sandbox fly.io?
    • Saya penasaran seberapa cepat cold start-nya, dan bagaimana perbandingannya dengan penyedia GPU lain seperti runpod atau modal.
    • Ini bukan pertanyaan, tetapi tautan “Lovelace L40s are coming soon (pricing TBD)” mengarah ke 404.

  • Setahu saya Fly menggunakan Firecracker untuk VM. Saya sudah cukup lama mengikuti Firecracker dan pernah memakainya di proyek, tetapi pada dasarnya ia tidak mendukung GPU dan tidak ada rencana untuk mendukungnya [1].
    Saya penasaran bagaimana Fly menyelesaikan dukungan GPU mereka sendiri dengan Firecracker. Dulu mereka sering menulis artikel teknis yang sangat detail tentang bagaimana mereka mengimplementasikan fitur tertentu, jadi saya berharap nanti ada tulisan tentang dukungan GPU juga.
    [1]: https://github.com/firecracker-microvm/firecracker/issues/11...

    • Singkatnya, mesin GPU menggunakan Cloud Hypervisor, bukan Firecracker.

  • Keren bahwa mereka bisa menangani scale down hingga 0. Ini sangat berguna untuk mengerjakan situs eksperimental dengan jumlah pengguna kecil, ketika biaya server kecil pun sulit dibenarkan.
    Akan bagus kalau ada contoh satu request ditagih sebagai berapa lama. Tentu saja akan bervariasi, tetapi saya penasaran apakah 2 detik, atau “minimal 60 detik per spin-up”.

    • Penagihan dimulai sejak mesin di-boot sampai berhenti. Tidak ada waktu minimum yang dipaksakan, tetapi secara umum sulit melakukan pekerjaan bermakna di mesin dalam waktu kurang dari 5 detik.
      Mesin GPU mungkin membutuhkan waktu jalan sekitar 30 detik agar berguna, tergantung ukuran data yang masuk ke memori GPU.

  • Mengadopsi Fly.io sejak awal, tetapi belum siap untuk produksi. Sebelum menambahkan fitur baru, mereka harus memperbaiki fungsi dasar terlebih dahulu

    • Sayangnya itu benar. Awalnya saya sangat berharap pada produknya, tetapi akhirnya meninggalkan fly.io dan kembali ke platform aplikasi DigitalOcean
      Perlu sedikit lebih banyak konfigurasi dan harganya juga jauh lebih mahal, tetapi di produksi kita butuh stabilitas. Kita tidak bisa membiarkan pelanggan menelepon karena layanan terhenti
    • Di antara layanan dengan “kemasan yang terlihat meyakinkan”, ini adalah hosting paling tidak stabil yang pernah saya pakai seumur hidup. Banyak hal sering rusak secara bersamaan, dan rapat serta akhir pekan berantakan sementara halaman status selalu hijau
      Perangkat lunak bisa saja rusak, tetapi sikap Fly dalam menangani insiden terasa tidak profesional dan tidak matang. Pada dasarnya, kita membayar 10 kali lebih mahal untuk layanan tidak stabil yang hanya “terlihat” bagus
      Sekarang saya memakai Hetzner + Kamal dengan perangkat keras yang jauh lebih baik dengan seperempat biaya, berjalan stabil, harganya dapat diprediksi, dan tidak ada kejadian bulan depan harus membayar 25% lebih mahal untuk penggunaan yang sama
      https://news.ycombinator.com/item?id=36808296
    • Komentar seperti ini sayang sekali terlihat di HN. Tidak konstruktif. Anda perlu menuliskan dengan tepat fungsi dasar apa yang dimaksud dan perbaikan seperti apa yang diperlukan

  • Terlepas dari pengumuman GPU, saya berharap Fly punya layanan pengganti S3. Saat ini mereka menyarankan proyek GNU Affero, yang menjadi hambatan bagi perusahaan
    Jika harus keluar dari Fly untuk menyimpan aset pengguna, sulit untuk memakai Fly pada proyek berikutnya. Sayang, karena saya suka kesederhanaannya, value for money-nya, dan VPN bawaan

  • Saya penasaran siapa pasar sasaran layanan ini. Apakah ini untuk aplikasi kecil yang belum tervalidasi yang perlu menjalankan model AI tertentu, tetapi tidak memakai atau tidak bisa memakai banyak startup bersaing harga yang menyediakan hosting model open source?
    Setelah cukup banyak mengoperasikan model dan hardware sendiri, saya paham keinginan untuk mengontrol sampai ke bare metal. Namun saya ingin tahu ini ditujukan untuk siapa

    • Saya punya beberapa pemikiran, tetapi belum ada jawaban yang jelas. Mungkin untuk orang-orang yang membuat platform hosting. Hal-hal yang dari luar tidak tampak seperti platform hosting, tetapi sebenarnya adalah platform hosting
    • Fly adalah jaringan edge. Secara teori, jika GPU berada di sebelah server dan server berada di sebelah pengguna, seperti yang ditekankan dalam tulisan itu, aplikasi bisa menjadi sangat cepat
      Dalam praktiknya, inferensi itu sendiri memakan waktu lama, jadi perbedaannya mungkin tidak terlalu penting
    • Ringkasnya, ada banyak alasan kecil untuk tertarik pada Fly GPU, terutama jika Anda sudah memakai Fly, tetapi jika Anda sudah melakukan deployment di cloud lain, belum ada satu alasan penentu yang kuat
      Jika komputasi GPU berada di data center yang sama atau setidaknya dalam penyedia cloud yang sama, itu bisa menjadi keuntungan besar. Tidak jarang A100 habis di beberapa penyedia, dan saya juga beberapa kali mengalaminya bahkan di penyedia besar. Jika tidak terikat pada region tertentu, itu tidak terlalu menjadi masalah
      Tidak semua penyedia menawarkan model on-demand scale-down ke 0 yang layak dipakai. Saya tidak tahu seberapa baik ini akan berjalan di Fly dalam jangka panjang, tetapi itu bisa menjadi keunggulan lain
      Startup yang bersaing harga cenderung tidak bertahan lama, dan strukturnya lebih mirip hanya segelintir dari 100 yang akan bertahan
      Jika Anda sudah memakai Fly dan hanya perlu menjalankan beberapa demo teknologi privat untuk dievaluasi, Fly GPU bisa menjadi pilihan default yang tidak perlu banyak dipikirkan. Tentu saja memakai layanan Hugging Face mungkin lebih umum
      Banyak perusahaan juga tidak bisa mengoperasikan hardware sendiri karena berbagai alasan, dan paling banter hanya menyewa rack di data center lain, tetapi untuk use case kecil itu tidak selalu bernilai. Ada juga kasus yang membutuhkan A100 tetapi hanya dijalankan sesekali, seperti analisis mingguan; jika kurang dari 1 jam per minggu, layanan bersaing harga mungkin tidak terlalu menarik
    • Di sisi layanan hosting, saya tidak terlalu melihat fenomena perlombaan harga sampai ke dasar. Sebagian besar beberapa kali lebih mahal daripada GCP, dan harga publik GCP sendiri juga beberapa kali lebih tinggi daripada harga yang sebenarnya dibayar pelanggan korporat

  • Contoh resep atau use case LLM apa pun tampaknya contoh yang sangat buruk untuk menekankan inferensi di edge. Karena tambahan latensi bolak-balik beberapa ratus ms pun tidak terlalu berpengaruh

    • Use case yang lebih baik tentu saja adalah asisten suara di edge. Dalam alur seperti suara→teks→pencarian/GPT→pembuatan respons suara, ms itu penting
      Namun tampaknya ini area dengan potensi penyalahgunaan tinggi, jadi belum ada yang ingin terlibat. Mungkin akan dibahas di tulisan berikutnya, dan jika demikian mereka perlu membuat GPT online bergaya Perplexity sendiri. Saat ini sepertinya sengaja dibuat sebagai pengantar biasa untuk melihat apakah ide lain muncul
    • Setuju. Saya tidak bisa memikirkan kasus bisnis untuk menjalankan LLM di edge. Apakah ini momen Pets.com bagi industri AI?

  • Penasaran apakah sudah ada yang mencoba performanya. Kesan pertama, harganya terlihat cukup mahal. Misalnya jika dibandingkan dengan mesin CPU Hetzner

    • Tidak tahu untuk tempat lain, tetapi di DigitalOcean, A100 dengan RAM 90GB bisa dipakai seharga 1,15 dolar per jam. Harganya sekitar sepertiga
      Bahkan H100 juga bisa didapat lebih murah dari harga ini, yaitu 2,24 dolar per jam
      Jadi memang terlihat agak mahal, tetapi mungkin karena permintaan pelanggan tinggi dan pasokannya terbatas

  • Saya menjalankan Uptime Kuma di tier gratis Fly.io untuk memantau uptime. Berjalan sangat baik, jadi sangat puas

    • Dengan apa Anda mendapat notifikasi kalau Uptime Kuma sedang down?