Fly.io prend désormais en charge les GPU

 (fly.io)
1 points par GN⁺ 2024-02-14 | 1 commentaires | Partager sur WhatsApp
  • Fly.io, qui exécute les apps au plus près des utilisateurs, ajoute la prise en charge des GPU, ce qui permet de placer l’inférence IA près de l’edge plutôt que dans une région centrale
  • Les apps peuvent être associées à un Nvidia A100 afin d’exploiter CUDA et une grande quantité de VRAM, pour la reconnaissance vocale, le découpage de texte, le résumé d’articles, la génération d’images et l’exécution de modèles d’assistance au code
  • Une app GPU basée sur Ollama peut être déployée en indiquant l’image ollama/ollama et vm.size = "a100-40gb" dans fly.toml, puis avec fly apps create et fly deploy
  • Dans les régions prenant en charge les GPU, le même programme peut être exécuté avec la même IP publique et le même certificat TLS, et il est possible de l’étendre à la région d’Amsterdam avec une commande comme fly scale count 2 --region ams
  • L’A100 40GB coûte $2.50 par heure, l’A100 80GB $3.50, et le L40s $2.50 ; en configurant le démarrage et l’arrêt automatiques, on peut éviter la facturation du temps GPU en l’absence de requêtes

Exécuter des GPU au plus près des utilisateurs

  • Fly.io est un cloud qui permet d’exécuter des apps full-stack ou des plateformes de développement basées sur la Fly Machines API au plus près des utilisateurs, et y ajoute désormais l’exécution sur GPU
  • Les GPU Fly.io connectent un Nvidia A100 à une app, permettant d’exploiter CUDA et davantage de VRAM qu’une 4090 locale
  • Les tâches IA/ML applicables sont notamment :

Déployer une app GPU Ollama

  • Fly.io vise une approche où les utilisateurs déploient leurs modèles préférés et leur propre code sur le backbone cloud de Fly.io
  • Une app GPU basée sur Ollama peut être lancée avec une simple configuration fly.toml et des commandes de déploiement
    • app = "sandwich_ai"
    • primary_region = "ord"
    • vm.size = "a100-40gb"
    • l’image de build est ollama/ollama
    • un volume de 100gb est monté sur /root/.ollama
  • La commande d’exécution est la suivante :
fly apps create sandwich_ai && fly deploy

Faire de l’inférence au plus près des régions

  • Le point mis en avant par Fly.io n’est pas simplement la fourniture de GPU, mais l’inférence à l’edge
  • L’app d’exemple permet à l’utilisateur de saisir les ingrédients présents dans sa cuisine pour recevoir une recette de sandwich
  • Avec un déploiement primary_region = "ord", les utilisateurs proches de Chicago peuvent recevoir rapidement une recette de sandwich
  • Pour les utilisateurs situés hors de Chicago, par exemple à Amsterdam, les requêtes doivent traverser l’Atlantique, ce qui peut prendre plus de temps
  • Dans les régions prenant en charge les GPU, le même programme peut être exécuté avec la même adresse IP publique et le même certificat TLS
  • L’extension à Amsterdam se fait avec la commande suivante :
fly scale count 2 --region ams

Utiliser les GPU uniquement lorsqu’il y a des requêtes

  • Les GPU sont des unités de traitement parallèle puissantes, mais elles ne sont pas bon marché ; pour les petites apps, il est donc préférable de ne payer que lorsque des utilisateurs envoient des requêtes
  • Il est possible de configurer le démarrage et l’arrêt automatiques dans la section services de fly.toml
[[services]]
  internal_port = 8080
  protocol = "tcp"
  auto_stop_machines = true
  auto_start_machines = true
  min_machines_running = 0
  • auto_stop_machines = true et auto_start_machines = true configurent l’arrêt des machines lorsqu’il n’y a pas de requête et leur redémarrage lorsque c’est nécessaire
  • Avec min_machines_running = 0, aucun coût de temps GPU n’est facturé lorsqu’il n’y a pas de demande de recette de sandwich

GPU proposés et ressources par défaut

  • Les GPU sont disponibles dans plusieurs régions aux États-Unis et dans l’UE, ainsi qu’à Sydney
  • Les cibles de déploiement et les tarifs sont les suivants :
  • Les apps déployées sur GPU utilisent par défaut 8 cœurs CPU AMD EPYC
  • Des volumes allant jusqu’à 500GB peuvent être attachés
  • Des remises peuvent aussi être proposées pour les instances réservées et les hôtes dédiés

À lire aussi

1 commentaires

 
GN⁺ 2024-02-14
Avis sur Hacker News

  • Je me demande si Fly a vraiment les fonctionnalités de base au point. Après l’avoir utilisé en production réelle, c’est décevant : le support n’est même pas en mesure de consulter les problèmes de plateforme internes, et les messages d’erreur sont vagues, voire inexistants.
    Cela peut sembler attractif pour les personnes qui ont peur de Kubernetes ou ne le connaissent pas bien, mais à force d’utiliser Fly, j’en suis venu à regretter Kubernetes.

    • J’ai testé une migration vers Fly.io, et même un déploiement simple coupait la connexion pendant quelques secondes lors du basculement. On peut le constater soi-même en lançant watch -n 2 curl pendant un déploiement, et c’était le cas quelle que soit la stratégie documentée utilisée, y compris le blue-green.
      Dans le pire des cas, je m’attendais à ce que seules les connexions existantes soient terminées prématurément et que les nouvelles ne soient pas coupées ; dans le meilleur des cas, à une attente propre jusqu’à la fin des connexions existantes. En réalité, c’était à chaque fois un basculement avec downtime complet. Quand on pense à la topologie réseau décrite dans leur blog, on a l’impression que cela ne pouvait de toute façon pas être implémenté correctement.
      Je laisse rarement des commentaires négatifs sur un service, mais le fait que le support ait réagi comme si nous étions les bizarres, alors même que nous avions envoyé une preuve vidéo, était assez irritant pour une entreprise d’infrastructure. Je ne le recommande plus, sauf pour des applis jouets.
      J’ai aussi construit un système de déploiement assez conséquent pour Kubernetes, donc ce n’est pas une remarque due à une méconnaissance de Kubernetes. Il y a clairement de la place pour un vrai déploiement à la Heroku, mais soit personne ne le fait bien, soit les ressources de calcul sont ridiculement maigres ou chères.
    • Envoyez-moi plus de détails par e-mail aux deux premières lettres du nom d’utilisateur @fly.io. J’aimerais comprendre ce qui vous a posé problème et améliorer la situation dans la mesure du possible.
    • Exact, la fiabilité et le support sont épouvantables. Une fois, nous n’avons pas pu déployer pendant 2 jours, et on nous a carrément répondu d’utiliser une autre entreprise.
      Je pourrais aussi parler de la base de données non managée emballée comme du managé, des downtimes aléatoires, etc., mais ce n’est pas un service prêt pour la production, et nous sommes partis il y a quelques mois.
    • Malheureusement, c’est un schéma assez courant. Parmi mes connaissances qui ont adopté Fly, la moitié est partie ailleurs.
      Au début, j’étais très enthousiaste à propos de Fly et j’ai même construit tout un orchestrateur au-dessus de Fly Machines, mais nous avons eu une panne de plusieurs jours, et il a aussi fallu plusieurs jours pour obtenir une réponse.
      Kubernetes peut être complexe, mais cette complexité est au moins contrôlable, et c’est une voie déjà largement éprouvée.
    • J’exploite plusieurs services sur Fly depuis presque un an, et je n’ai encore rencontré aucun problème.

  • Je suis l’auteur du billet et responsable des relations développeurs chez Fly.io. Si vous avez des questions, je peux y répondre. Les GPU ont été lancés officiellement hier, et si le dieu des algorithmes anti-fraude vous l’autorise, vous pouvez expérimenter autant que vous voulez.
    Je suis plutôt surpris que l’article explicatif sur ce que sont réellement les « GPU » n’ait pas si bien pris ici : https://fly.io/blog/what-are-these-gpus-really/

    • Je suis particulièrement curieux de votre avis sur l’inférence sur matériel Apple. Je passe beaucoup de temps à optimiser l’inférence locale sur Apple Silicon, en environnement on-premise ou sur un bureau, et même compte tenu de la quantité de travail investie dans des formats comme GGUF, je pense qu’il reste encore beaucoup de marge.
      L’avantage du nœud de gravure et l’accès prioritaire au SoC/HBM vont-ils durer assez longtemps pour que le logiciel rattrape son retard ? Le matériel Metal haut de gamme paraît cher, mais vu autrement, quand on le compare à NVIDIA avec 64 Go+ de bande passante mémoire assez élevée et des unités vectorielles FP dédiées, la perspective change.
      Si une plateforme comme fly.io permettait de déplacer des charges d’inférence vers et depuis les appareils, cela pourrait offrir beaucoup de liberté aux applications fortement orientées edge.
    • Le timing est parfait. J’évalue des services GPU serverless pour un projet à venir. D’après l’annonce, la facturation se fait à l’heure, mais je me demande si, lorsqu’on scale down à 0, la facturation se fait à la minute ou à la seconde.
      Dans un workflow de segmentation d’imagerie médicale, un fichier prend environ 5 minutes.
    • Félicitations pour le lancement. Je me demande toutefois quels sont les utilisateurs cibles de ce service. Est-ce principalement destiné aux clients fly.io existants qui veulent rester dans le bac à sable fly.io ?
    • Je me demande à quelle vitesse est le cold start, et comment cela se compare à d’autres fournisseurs GPU comme runpod ou modal.
    • Ce n’est pas une question, mais le lien « Lovelace L40s are coming soon (pricing TBD) » renvoie une 404.

  • À ma connaissance, Fly utilise Firecracker pour ses VM. J’ai suivi Firecracker pendant un certain temps et je l’ai aussi utilisé dans un projet, mais il ne prend pas en charge les GPU par défaut et il n’est pas prévu de le faire [1].
    Je me demande comment Fly a résolu sa propre prise en charge GPU avec Firecracker. Par le passé, ils publiaient des articles techniques très détaillés sur la façon dont ils avaient implémenté certaines fonctionnalités ; j’aimerais donc voir un article sur le support GPU plus tard.
    [1]: https://github.com/firecracker-microvm/firecracker/issues/11...

    • Pour faire simple, les machines GPU n’utilisent pas Firecracker, mais Cloud Hypervisor.

  • Le fait de pouvoir gérer le scale down jusqu’à 0 est super. C’est particulièrement utile pour travailler sur des sites expérimentaux avec peu d’utilisateurs, où même le coût d’un petit serveur est difficile à justifier.
    Ce serait bien d’avoir un exemple du temps facturé pour une requête. Bien sûr, cela dépendra, mais je me demande si c’est 2 secondes ou plutôt « minimum 60 secondes par démarrage ».

    • Vous êtes facturé à partir du moment où la machine démarre jusqu’à son arrêt. Il n’y a pas de durée minimale imposée, mais en général il est difficile de faire quelque chose de significatif sur une machine en moins de 5 secondes.
      Pour les machines GPU, selon la taille des données qui doivent entrer dans la mémoire GPU, il peut falloir environ 30 secondes d’exécution pour que ce soit utile.

  • Fly.io a été adopté très tôt, mais il n’est pas prêt pour la production. Avant d’ajouter de nouvelles fonctionnalités, il faudrait corriger les fonctions de base.

    • C’est regrettable, mais c’est vrai. Au début, j’avais de grandes attentes pour le produit, mais j’ai quitté fly.io et je suis revenu à la plateforme d’apps de DigitalOcean.
      Il faut un peu plus de configuration et c’est nettement plus cher, mais en production, on a besoin de fiabilité. On ne peut pas se permettre que des clients appellent à cause d’une interruption de service.
    • Parmi tous les services à l’« emballage séduisant » que j’ai utilisés dans ma vie, c’était l’hébergement le plus instable. Plusieurs choses tombaient souvent en panne en même temps, et pendant que la page de statut restait toujours verte, des réunions et des week-ends étaient gâchés.
      Un logiciel peut tomber en panne, mais l’attitude de Fly dans la gestion des incidents est peu professionnelle et immature. En gros, on paie 10 fois plus pour un service instable qui ne fait que “bien” présenter.
      Aujourd’hui, avec Hetzner + Kamal, j’utilise un matériel bien meilleur pour un quart du coût, ça fonctionne de manière fiable, le prix est prévisible, et je ne me retrouve pas à payer 25 % de plus le mois suivant pour la même utilisation.
      https://news.ycombinator.com/item?id=36808296
    • C’est dommage de voir ce genre de commentaire sur HN. Ce n’est pas constructif. Il faudrait préciser exactement quelles sont les fonctions de base dont vous parlez, et quels correctifs sont nécessaires.

  • Indépendamment de l’annonce des GPU, j’aimerais que Fly propose une alternative à S3. Pour l’instant, ils suggèrent un projet GNU Affero, ce qui est un obstacle pour les entreprises.
    Si je dois sortir de Fly pour stocker les ressources des utilisateurs, il devient difficile d’utiliser Fly pour le prochain projet. C’est dommage, car j’aime sa simplicité, son rapport qualité-prix et son VPN intégré.

  • Je me demande quel est le marché cible de ce service. De petites apps non validées qui doivent faire tourner un modèle d’IA, mais qui n’utilisent pas, ou ne peuvent pas utiliser, les innombrables startups se livrant une guerre des prix pour proposer l’hébergement de modèles open source ?
    Pour avoir beaucoup exploité moi-même des modèles et du matériel, je comprends l’envie de contrôler jusqu’au bare metal. Mais j’aimerais savoir à qui cela s’adresse.

    • J’ai quelques idées, mais pas encore de réponse claire. Probablement les gens qui construisent des plateformes d’hébergement. Des choses qui, en apparence, ne ressemblent pas à des plateformes d’hébergement, mais qui le sont en réalité.
    • Fly est un réseau edge. En théorie, si le GPU est à côté du serveur, et que le serveur est à côté de l’utilisateur, l’app peut devenir très rapide, comme l’article le souligne.
      En pratique, l’inférence elle-même prend du temps, donc cette différence pourrait ne pas être si importante.
    • En résumé, il y a beaucoup de petites raisons de s’intéresser aux GPU de Fly, surtout si l’on utilise déjà Fly, mais si l’on déploie déjà sur un autre cloud, il manque une raison décisive unique.
      Avoir le calcul GPU dans le même datacenter, ou au moins chez le même fournisseur cloud, peut être un gros avantage. Il n’a pas été rare non plus de voir des A100 en rupture chez plusieurs fournisseurs, et je l’ai vécu plusieurs fois même chez de gros fournisseurs. C’est moins problématique si vous n’êtes pas attaché à une région précise.
      Tous les fournisseurs ne proposent pas un modèle exploitable de scale down à 0 à la demande. Je ne sais pas à quel point cela fonctionnera bien chez Fly à long terme, mais cela pourrait être un avantage supplémentaire.
      Les startups qui se livrent une guerre des prix ont tendance à ne pas durer longtemps ; on est plutôt dans une dynamique où seule une infime minorité sur 100 survit.
      Si vous utilisez déjà Fly et que vous faites simplement évaluer quelques démos techniques privées, les GPU de Fly peuvent devenir un choix par défaut qui ne demande pas beaucoup de réflexion. Bien sûr, utiliser les services de Hugging Face est probablement plus courant.
      Beaucoup d’entreprises ne peuvent pas exploiter leur propre matériel pour diverses raisons, et au mieux elles louent des racks dans un autre datacenter, ce qui n’a pas toujours de valeur pour de petits cas d’usage. On peut aussi avoir besoin d’un A100, mais seulement rarement, comme pour des analyses hebdomadaires ; si cela représente moins d’une heure par semaine, les services à prix agressifs ne sont peut-être pas si attractifs.
    • Du côté des services d’hébergement, je ne vois pas vraiment de course vers le bas sur les prix. La plupart sont plusieurs fois plus chers que GCP, et les prix publics de GCP eux-mêmes sont déjà plusieurs fois supérieurs à ce que paient réellement les clients entreprises.

  • Les exemples de recettes, ou n’importe quel cas d’usage LLM, semblent être de très mauvais exemples pour mettre en avant l’inférence en edge. Quelques centaines de ms de latence aller-retour en plus n’ont pas vraiment d’importance.

    • Un meilleur cas d’usage serait évidemment un assistant vocal en edge. Dans un flux du type voix→texte→recherche/GPT→génération de réponse vocale, les ms comptent.
      Mais c’est un domaine à fort potentiel d’abus, donc personne ne semble encore vouloir s’y associer. Ce sera sans doute le sujet du prochain article, et dans ce cas il faudra créer son propre GPT en ligne façon Perplexity. Pour l’instant, ils semblent volontairement faire une introduction banale afin de voir si d’autres idées émergent.
    • D’accord. Je ne vois pas de cas business pour faire tourner un LLM en edge. Est-ce le moment Pets.com du secteur de l’IA ?

  • Je me demande si quelqu’un a testé les performances. À première vue, ça paraît assez cher, par exemple par rapport aux machines CPU de Hetzner.

    • Je ne sais pas pour les autres, mais chez DigitalOcean on peut utiliser une A100 avec 90 Go de RAM pour 1,15 $ de l’heure. C’est environ trois fois moins cher.
      Même une H100 est disponible à 2,24 $ de l’heure, donc moins cher que ce tarif.
      Ça semble donc un peu cher, mais c’est peut-être dû à une forte demande client et à une offre limitée.

  • J’utilise le niveau gratuit de Fly.io pour faire tourner Uptime Kuma et surveiller la disponibilité. Ça marche super bien, j’en suis très satisfait.

    • Et comment es-tu alerté quand Uptime Kuma tombe ?