- Fly.io, nền tảng chạy ứng dụng gần người dùng, đã bổ sung hỗ trợ GPU, cho phép triển khai suy luận AI gần edge thay vì chỉ ở region trung tâm
- Có thể gắn Nvidia A100 vào ứng dụng để tận dụng CUDA và VRAM dung lượng lớn, dùng cho nhận dạng giọng nói, phân đoạn văn bản, tóm tắt bài viết, tạo ảnh và chạy các mô hình hỗ trợ lập trình
- Ứng dụng GPU dựa trên Ollama có thể được triển khai bằng cách chỉ định
vm.size = "a100-40gb" và image ollama/ollama trong fly.toml, sau đó dùng fly apps create và fly deploy
- Ở các region hỗ trợ GPU, có thể chạy cùng một chương trình với cùng địa chỉ IP công khai và chứng chỉ TLS, đồng thời mở rộng sang region Amsterdam bằng lệnh như
fly scale count 2 --region ams
- A100 40GB có giá $2.50/giờ, A100 80GB là $3.50, L40s là $2.50; nếu cấu hình tự động khởi động và dừng, có thể tránh tính phí thời gian GPU khi không có yêu cầu
Chạy GPU được triển khai gần người dùng
- Fly.io là một đám mây cho phép chạy ứng dụng full-stack hoặc nền tảng phát triển dựa trên Fly Machines API gần người dùng, và nay đã bổ sung khả năng chạy GPU
- GPU của Fly.io cho phép gắn Nvidia A100 vào ứng dụng để tận dụng CUDA và lượng VRAM còn lớn hơn cả 4090 cục bộ
- Các tác vụ AI/ML có thể áp dụng gồm
Triển khai ứng dụng GPU với Ollama
- Fly.io hướng tới cách làm cho phép người dùng triển khai các mô hình họ ưa dùng và mã do chính họ viết lên backbone cloud của Fly.io
- Ứng dụng GPU dựa trên Ollama có thể chạy chỉ với cấu hình
fly.toml và lệnh triển khai
app = "sandwich_ai"primary_region = "ord"vm.size = "a100-40gb"- Image build là
ollama/ollama
- Mount volume
100gb vào /root/.ollama
- Lệnh chạy như sau
fly apps create sandwich_ai && fly deploy
Suy luận được thực hiện gần region
- Điểm Fly.io nhấn mạnh không chỉ là cung cấp GPU đơn thuần mà là suy luận ở edge
- Ứng dụng ví dụ có cấu trúc cho phép người dùng nhập các nguyên liệu có trong bếp để nhận công thức sandwich
- Nếu triển khai với
primary_region = "ord", người dùng gần Chicago có thể nhận công thức sandwich nhanh chóng
- Người dùng ngoài Chicago, chẳng hạn ở Amsterdam, có thể mất nhiều thời gian hơn vì yêu cầu phải đi qua Đại Tây Dương
- Ở các region hỗ trợ GPU, có thể chạy cùng một chương trình với cùng địa chỉ IP công khai và cùng chứng chỉ TLS
- Việc mở rộng sang Amsterdam được thực hiện bằng lệnh sau
fly scale count 2 --region ams
GPU chỉ dùng khi có yêu cầu
- GPU là thiết bị xử lý song song mạnh mẽ nhưng không rẻ, nên với các ứng dụng nhỏ, cấu hình chỉ trả phí khi người dùng có yêu cầu sẽ có lợi hơn
- Trong phần
services của fly.toml, có thể thiết lập tự động khởi động và tự động dừng
[[services]]
internal_port = 8080
protocol = "tcp"
auto_stop_machines = true
auto_start_machines = true
min_machines_running = 0
auto_stop_machines = true và auto_start_machines = true là cấu hình dừng máy khi không có yêu cầu và khởi động lại khi cần- Nếu
min_machines_running = 0, sẽ không phải trả chi phí thời gian GPU khi không có yêu cầu công thức sandwich
Các GPU được cung cấp và tài nguyên mặc định
- GPU có thể dùng tại nhiều region ở Mỹ, EU và Sydney
- Mục tiêu triển khai và giá như sau
- Các ứng dụng triển khai lên GPU mặc định sử dụng 8 lõi CPU AMD EPYC
- Có thể gắn volume tối đa 500GB
- Cũng có thể cung cấp chiết khấu cho reserved instances và dedicated hosts
1 bình luận
Các ý kiến trên Hacker News
Tôi nghi ngờ liệu Fly đã có đầy đủ những tính năng cơ bản đúng nghĩa chưa. Khi dùng trong production thực tế, tôi khá thất vọng vì đội hỗ trợ đến mức không thể tra cứu các vấn đề của nền tảng nội bộ, còn thông báo lỗi thì mơ hồ hoặc hoàn toàn không có
Với những người sợ Kubernetes hoặc không rành về nó, Fly có thể trông hấp dẫn, nhưng dùng Fly rồi tôi lại thấy nhớ Kubernetes hơn
watch -n 2 curltrong khi triển khai; các chiến lược được tài liệu hóa, kể cả blue-green, dùng cách nào cũng vậyTôi kỳ vọng trong trường hợp tệ nhất thì chỉ các kết nối hiện có bị kết thúc sớm, còn kết nối mới không bị ngắt; tốt nhất là hệ thống sẽ đợi một cách êm ái cho đến khi các kết nối hiện có kết thúc. Nhưng thực tế lần nào cũng là chuyển đổi với downtime hoàn toàn. Nghĩ đến topology mạng trong bài blog thì tôi có cảm giác ngay từ đầu việc này đã không thể được triển khai đúng
Tôi hiếm khi bình luận tiêu cực về một dịch vụ, nhưng việc đã gửi cả bằng chứng video mà đội hỗ trợ vẫn phản hồi như thể phía chúng tôi mới là bên kỳ lạ thì với tiêu chuẩn của một công ty hạ tầng là khá khó chịu. Giờ tôi không khuyến nghị dịch vụ này cho bất cứ thứ gì ngoài app đồ chơi
Tôi cũng từng xây một hệ thống triển khai khá lớn cho Kubernetes, nhưng vấn đề này không phải là do không biết Kubernetes. Rõ ràng vẫn có chỗ cho kiểu triển khai theo phong cách Heroku đúng nghĩa, chỉ là hoặc chưa ai làm tốt, hoặc tài nguyên tính toán quá mỏng hay quá đắt
Còn nhiều chuyện khác như DB không được quản lý nhưng được đóng gói như dịch vụ managed, downtime ngẫu nhiên, v.v.; nhưng đây không phải là dịch vụ sẵn sàng cho production nên tôi đã rời đi vài tháng trước
Ban đầu tôi rất kỳ vọng vào Fly và còn xây cả một orchestrator hoàn chỉnh trên Fly Machines, nhưng đã xảy ra sự cố kéo dài nhiều ngày, và để nhận được phản hồi cũng mất nhiều ngày
Kubernetes có thể phức tạp, nhưng sự phức tạp đó ít nhất là có thể kiểm soát và là con đường đã được kiểm chứng rất nhiều
Tôi là tác giả bài viết và là người phụ trách quan hệ nhà phát triển của Fly.io. Nếu có câu hỏi, tôi có thể trả lời. GPU đã được phát hành chính thức hôm qua, và nếu vị thần thuật toán chống gian lận cho phép thì bạn có thể thoải mái thử nghiệm
Ngược lại, tôi ngạc nhiên là bài hướng dẫn viết về “GPU” thực sự là gì lại không được đón nhận ở đây: https://fly.io/blog/what-are-these-gpus-really/
Liệu lợi thế về node tiến trình và quyền tiếp cận ưu tiên với SoC/HBM có duy trì đủ lâu để phần mềm bắt kịp không? Thiết bị Metal cao cấp trông có vẻ đắt, nhưng nếu so với NVIDIA có băng thông bộ nhớ khá cao ở mức 64GB+ và các đơn vị vector FP chuyên dụng thì lại nhìn khác
Nếu có thể chuyển workload inference vào/ra khỏi thiết bị bằng một nền tảng như
fly.io, điều đó có vẻ sẽ đem lại rất nhiều độ linh hoạt cho các ứng dụng thiên về edgeTrong workflow phân đoạn ảnh y tế, mỗi file mất khoảng 5 phút
Theo tôi biết, Fly dùng Firecracker cho VM. Tôi đã theo dõi Firecracker một thời gian và cũng từng dùng trong dự án, nhưng về cơ bản nó không hỗ trợ GPU và cũng không có kế hoạch hỗ trợ [1]
Tôi tò mò Fly đã giải quyết hỗ trợ GPU riêng với Firecracker như thế nào. Trước đây họ từng đăng các bài kỹ thuật rất chi tiết về cách triển khai một số tính năng cụ thể, nên hy vọng sau này cũng sẽ có bài về hỗ trợ GPU
[1]: https://github.com/firecracker-microvm/firecracker/issues/11...
Việc có thể xử lý scale down về 0 thật hay. Nó đặc biệt hữu ích khi làm các site thử nghiệm có ít người dùng, đến mức khó biện minh cả chi phí cho một máy chủ nhỏ
Sẽ tốt nếu có ví dụ về việc một request được tính phí theo khoảng thời gian như thế nào. Tất nhiên là sẽ thay đổi, nhưng tôi muốn biết đó là 2 giây, hay “tối thiểu 60 giây cho mỗi lần spin up”
Máy GPU có thể cần khoảng 30 giây thời gian chạy mới trở nên hữu ích, tùy vào kích thước dữ liệu được nạp vào bộ nhớ GPU
Đã sớm áp dụng Fly.io nhưng chưa sẵn sàng cho production. Trước khi thêm tính năng mới, họ cần sửa các chức năng cơ bản trước
Cần cấu hình nhiều hơn một chút và giá cũng đắt hơn khá nhiều, nhưng trong production thì cần độ ổn định. Không thể để khách hàng phải gọi điện vì dịch vụ bị gián đoạn
Phần mềm có thể hỏng, nhưng thái độ ứng phó sự cố của Fly thiếu chuyên nghiệp và non nớt. Về cơ bản là trả gấp 10 lần cho một dịch vụ bất ổn chỉ “trông” đẹp
Hiện tôi dùng Hetzner + Kamal, có phần cứng tốt hơn nhiều với chi phí chỉ bằng một phần tư, chạy ổn định, giá dễ dự đoán và tháng sau cũng không phải trả thêm 25% cho cùng mức sử dụng
https://news.ycombinator.com/item?id=36808296
Tách khỏi thông báo về GPU, tôi mong Fly có một dịch vụ thay thế S3. Hiện họ đề xuất một dự án GNU Affero, nhưng với doanh nghiệp thì đó là một trở ngại
Nếu vì lưu trữ tài sản người dùng mà phải ra ngoài Fly, thì sẽ khó dùng Fly cho dự án tiếp theo. Tôi tiếc vì thích sự đơn giản, hiệu quả chi phí và VPN tích hợp của họ
Cũng được thảo luận ở đây https://benhoyt.com/writings/flyio-and-tigris/: https://news.ycombinator.com/item?id=39360870
https://fly.io/docs/reference/tigris/
Nếu bạn chỉ truy cập một dịch vụ kiểu S3 qua HTTPS API, thì vì thế mà mã của bạn không trở thành đối tượng áp dụng AGPL
Tôi tò mò thị trường mục tiêu của dịch vụ này là ai. Có phải là các ứng dụng nhỏ và chưa được kiểm chứng cần chạy một mô hình AI nào đó, nhưng không dùng hoặc không thể dùng vô số startup cạnh tranh về giá đang cung cấp hosting mô hình mã nguồn mở?
Từng tự vận hành khá nhiều mô hình và phần cứng, tôi hiểu mong muốn kiểm soát tới tận phần cứng vật lý. Nhưng tôi muốn biết họ đang nhắm tới ai
Trên thực tế, bản thân quá trình inference mất nhiều thời gian, nên khác biệt đó có thể không quá quan trọng
Việc tính toán GPU nằm trong cùng data center, hoặc ít nhất cùng nhà cung cấp cloud, có thể là lợi thế lớn. Chuyện A100 cạn hàng ở nhiều nhà cung cấp cũng không hiếm, và tôi đã gặp nhiều lần ngay cả ở các nhà cung cấp lớn. Nếu không bị ràng buộc vào một region cụ thể thì đỡ vấn đề hơn
Không phải nhà cung cấp nào cũng đưa ra mô hình on-demand scale down về 0 thực sự dùng được. Tôi không biết về dài hạn Fly sẽ làm tốt đến đâu, nhưng đó có thể là một lợi thế nữa
Các startup cạnh tranh về giá thường không trụ được lâu, gần giống một cấu trúc mà trong 100 công ty chỉ có rất ít sống sót
Nếu bạn đã dùng Fly và chỉ cần vài lần đánh giá demo kỹ thuật không công khai, Fly GPU có thể trở thành lựa chọn mặc định không cần suy nghĩ nhiều. Tất nhiên dùng dịch vụ của Hugging Face có thể phổ biến hơn
Cũng có nhiều công ty vì nhiều lý do không thể tự vận hành phần cứng; tốt lắm thì chỉ thuê rack ở một data center khác, nhưng với các use case nhỏ thì không phải lúc nào cũng đáng. Có trường hợp cần A100 nhưng chỉ chạy hiếm hoi như phân tích hằng tuần, và nếu dưới 1 giờ mỗi tuần thì các dịch vụ cạnh tranh về giá có thể không hấp dẫn lắm
Ví dụ công thức nấu ăn hay bất kỳ use case LLM nào đó có vẻ là ví dụ rất tệ để nhấn mạnh inference ở edge. Vì độ trễ khứ hồi tăng thêm vài trăm ms cũng không quan trọng lắm
Tuy nhiên đây là lĩnh vực có khả năng bị lạm dụng cao, nên có vẻ hiện chưa ai muốn dính vào. Có lẽ bài tiếp theo sẽ nói về chuyện đó, và nếu vậy thì họ phải tự xây một GPT trực tuyến kiểu Perplexity. Hiện có vẻ họ cố tình giới thiệu theo cách bình thường để xem có ý tưởng khác xuất hiện không
Tò mò không biết đã có ai dùng thử hiệu năng chưa. Ấn tượng ban đầu là có vẻ khá đắt. Ví dụ là so với máy CPU của Hetzner
Thậm chí H100 cũng có thể kiếm được với giá 2,24 USD mỗi giờ, rẻ hơn mức giá này
Vì vậy trông có vẻ hơi đắt, nhưng cũng có thể là do nhu cầu khách hàng cao và nguồn cung thiếu
Đang chạy Uptime Kuma trên gói miễn phí của Fly.io để giám sát uptime. Nó hoạt động cực kỳ tốt nên rất hài lòng