San Francisco Compute : 512 H100 pour les startups à moins de 2 dollars de l’heure

 (sfcompute.org)
2 points par GN⁺ 2023-07-31 | 1 commentaires | Partager sur WhatsApp
  • Plusieurs startups et laboratoires de recherche achètent conjointement un cluster de GPU afin de mutualiser les ressources de calcul nécessaires à l’entraînement de grands modèles
  • Au lieu d’acheter chacun N GPU séparément, K startups se regroupent pour acheter ensemble un cluster de taille N×K
  • Un job scheduler répartit équitablement le calcul au prorata des parts détenues, et alloue en plus les capacités inutilisées lorsqu’il y en a
  • Plutôt que de remplir 128 A100 pendant tout un mois, il devient possible de burster sur 512 A100 pendant une semaine, afin d’entraîner les modèles plus vite
  • Une structure qui rend accessible aux startups le mode d’allocation en burst dont ne bénéficiaient jusque-là que de grands laboratoires comme OpenAI ou Deepmind

Idée principale

  • Au lieu que K startups achètent chacune un cluster de N GPU, elles achètent ensemble un cluster de GPU de taille N×K
  • Mise en place d’un job scheduler pour répartir équitablement le calcul au prorata des parts détenues par chaque startup
  • Si de la capacité de calcul reste inutilisée, le scheduler l’alloue telle quelle ; avec un peu de chance, il est donc possible d’utiliser plus de calcul que sa part
  • Plutôt que de maintenir 128 A100 occupés en continu pendant un mois, il est possible de burster jusqu’à 512 A100 pendant une semaine pour obtenir un modèle plus rapidement
  • Les grands laboratoires comme OpenAI ou Deepmind disposent de grands clusters permettant des allocations en burst pour leurs chercheurs
    • À l’inverse, les startups n’avaient jusqu’ici accès qu’à de tout petits clusters via des contrats de très longue durée, devaient attendre plusieurs mois et les maintenir constamment occupés
  • Objectif : appliquer l’allocation en burst et les contrats courts tout en visant environ 2,00 $ par H100
  • Les startups intéressées peuvent remplir le formulaire de candidature ; pour toute question, envoyer un e-mail à evan@roomservice.dev

Rejoindre, quitter et étendre

  • Comme dans une hacker house, pour quitter le cluster (par exemple afin de construire son propre cluster), il faut prévenir un ou deux mois à l’avance afin que la place puisse être remplacée par quelqu’un d’autre
  • Les nouvelles startups sont ajoutées au groupe par lots (batch), avec l’ajout de nouveaux H100 au cluster tous les quelques mois
  • Le même principe s’applique aux membres déjà présents dans le groupe qui souhaitent augmenter leur capacité de calcul
  • Une légère surallocation (overprovisioning) est envisagée — par exemple, si un ami veut quelques nœuds pour une petite expérimentation, ils peuvent être fournis immédiatement à un bon prix
    • Avec 10 % de surallocation, le prix horaire d’un H100 augmente de 10 %

Finances

  • Une voie solide a été trouvée pour mettre en service 512 H100 en 4 à 6 semaines
  • Si la demande dépasse ce volume, des H100 supplémentaires pourront être obtenus en environ 8 semaines
  • De bonnes conditions bancaires permettent d’étaler le coût d’achat du cluster, ce qui rend possible un niveau d’environ 2,00 $ par H100 tout en conservant des contrats courts et l’allocation en burst

Infrastructure

  • Partage d’une mailing list/Slack de débogage d’infrastructure ; en cas de problème avec InfiniBand ou autre, il est possible de poser des questions au groupe
  • Si quelqu’un a déjà rencontré le même problème, les membres peuvent s’entraider

À lire aussi

1 commentaires

 
GN⁺ 2023-07-31
Avis de Hacker News

  • J’espère que ça réussira. TPU Research Cloud (TRC) avait tenté quelque chose de ce genre en 2019, et c’est ce qui m’a permis de me lancer.
    En 2023, il est difficile d’obtenir ne serait-ce qu’un TPU pendant plus d’une heure, mais à l’époque on pouvait littéralement en recevoir des centaines. Je croyais au TRC, et je pensais qu’en passant à l’échelle pour créer un continent de TPU, le problème serait résolu ; au final, le temps TPU a été attribué en priorité aux chercheurs internes et a diminué. Le monde a tellement changé qu’aujourd’hui, si vous proposez d’apprendre les échecs à GPT sur des H100, on vous rirait au nez.
    Il y a dans ce projet un optimisme de jeunesse que j’espère ne pas voir disparaître, et à long terme c’est peut-être comme ça qu’on gagne. Si quelqu’un vient demander un tout petit fragment de H100 pour une idée farfelue, j’espère qu’on l’acceptera. C’est la seule raison pour laquelle j’ai pu devenir quelque chose.

    • « Le projet a un optimisme de jeunesse » est l’une des meilleures phrases que j’aie entendues jusqu’ici. Au point que j’aurais envie de l’encadrer et de l’accrocher au mur.
      Et bien sûr, nous comptons accepter les demandes farfelues pour un petit morceau de H100.
    • En fait, le programme TPU Research Cloud fonctionne toujours très bien. Le pool de calcul a été fortement étendu et inclut désormais aussi des slices de Cloud TPU v4 Pod ; les grands projets utilisent encore des centaines de puces à la fois. La capacité du TRC n’a pas été reprise pour des usages internes.
      La liste récente des articles soutenus par le TRC est disponible sur https://sites.research.google/trc/publications/
      La demande pour Cloud TPU est très forte, donc si vous utilisez de la capacité préemptible, vous pouvez constater des interruptions plus fréquentes, mais de la capacité réservée est également possible. Vous devriez contacter l’équipe de support du TRC.
    • Étonnamment, j’ai l’impression de ne voir cette lumière que maintenant. Dans les anciens billets, je ne voyais que des éloges du TRC, mais en ayant commencé plus tard, j’ai obtenu beaucoup plus de résultats avec ma propre GPU gaming.
      La comparaison n’est pas parfaitement identique, mais le TRC était très difficile à prendre en main, je n’ai eu accès qu’une seule fois à un TPUv3, et ce n’était même pas assez long pour apprendre les bases. J’ai compris que la situation variait beaucoup selon l’adresse e-mail utilisée et la notoriété du compte Twitter.
    • Mon expérience a été différente. Vu que la candidature est plutôt facile, je trouve que c’est encore assez généreux. Ces six derniers mois, pour plusieurs projets, on m’a proposé des v3-8, v3-32 pendant 30 jours, et des v3-64 préemptibles pendant 28 jours.
      Je me demande si vous êtes rattaché au monde académique. Si ce n’est pas le cas, je ne sais pas pourquoi ils ont été plus généreux avec moi, et mes projets étaient au mieux juste un peu intéressants. Cela dit, c’est vrai qu’ils sont beaucoup plus avares qu’avant avec les gros Pods.
    • Shawn a entièrement raison. La concurrence est tellement intense aujourd’hui qu’il n’y a plus ce genre de marge. Un seul client peut prendre 512 GPU pendant 3 ans.

  • « Au lieu que chacune des K startups achète séparément un cluster de N GPU, elles achètent ensemble un cluster de NK GPU et répartissent le calcul avec un ordonnanceur de tâches » ressemble, en théorie, presque au modèle des fournisseurs cloud comme AWS et Azure.
    C’est la structure suivante : « au lieu que tout le monde achète individuellement du matériel fixe, nous achetons un énorme pool de matériel et permettons de le partager dans le temps ». À part le fait que les fournisseurs cloud doivent augmenter les prix pour préserver leur marge nette, je me demande ce qui manque encore au point de rendre ce projet nécessaire.

    • Principalement le prix et la disponibilité.
      Premièrement, les investisseurs des clouds publics attendent une certaine structure de marges, ce qui rend difficile de rivaliser avec les marges de Lambda ou Fluidstack. Deuxièmement, les grands clouds sont aussi, dans une certaine mesure, désavantagés côté réseau pour l’entraînement de grands modèles de langage. À ma connaissance, seul Azure dispose d’InfiniBand ; Oracle est à 3200 Gbit/s mais ce n’est pas de l’InfiniBand, et je pense qu’AWS est similaire. Je ne suis pas sûr pour GCP, mais je me souviens que la vitesse réseau des A100 y était de 100 Gbit/s, pas 1600 Gbit/s. En revanche, Lambda, Fluidstack et CoreWeave ont tous de l’InfiniBand. Troisièmement, Nvidia n’alloue pas aux grands clouds autant de volume qu’ils le voudraient.
    • Les principaux clouds le font aussi. Tous les grands clouds préparent des fonctions de demandes/réservations à court terme. Avant l’IA générative, ce n’était pas une fonctionnalité très utile. À quelle fréquence aurait-on eu besoin de demander 1000 nœuds CPU pendant 48 heures dans une zone de disponibilité ?
      Deuxièmement, il y a ici un problème fondamental de partage des ressources. Même dans ce projet d’Evan et AI Grant, la question se pose : si une équipe a l’argent pour occuper tout le cluster en continu, pourquoi l’en empêcher ? Le problème est de définir précisément ce qu’est un usage équitable. Dans les réseaux, il existe des algorithmes de partage de bande passante comme l’équité TCP, mais ils s’adaptent mal à ce type de tâches par blocs.
      Dans les prochains mois, AWS et d’autres chercheront à lancer un service de file d’attente permettant d’obtenir temporairement des blocs de calcul, probablement avec paiement à l’avance et coûts élevés. Cela pourrait même coûter plus cher que les tarifs à la demande.
    • AWS et Azure préféreraient se trancher la gorge plutôt que de créer un moyen permettant aux clients de regrouper des instances pour économiser de l’argent.
      Ils font eux-mêmes cette mutualisation et ne veulent pas céder la relation client ni les profits à un intermédiaire ou aux clients.

  • Pour avoir exploité de l’infrastructure dans plusieurs colocations en Californie, il vaut mieux la mettre ailleurs si possible. Le coût de l’électricité en Californie et les autres coûts d’infrastructure sont bien plus élevés qu’en Arizona ou au Nevada.

    • Avec l’électricité bon marché et l’avantage du taux de change CAD-USD, Montréal semble bien adapté.
    • L’électricité semble représenter une toute petite part du coût du calcul GPU.

  • J’ai lu la phrase « aucun fournisseur cloud au monde ne vous donnera pour 100 000 dollars de calcul pendant seulement quelques semaines » ; je n’ai jamais acheté de très gros volumes de calcul, mais je pensais que c’était justement le cœur du cloud.

  • Je me demande en quoi c’est différent de https://lambdalabs.com/

    • Notre approche consiste à exploiter du calcul de taille intermédiaire avec une marge nulle. L’objectif n’est pas de vendre à des entreprises du Fortune 500, mais de permettre à un doctorant de dépenser une bourse de recherche de 50 000 dollars.
      Aujourd’hui, il est assez facile d’obtenir quelques A100/H100, et Lambda est excellent pour cet usage. Mais obtenir 24 GPU ou plus à un prix raisonnable, autour de 2 dollars de l’heure, est très difficile. Même si vous voulez seulement lancer un entraînement de 8 heures sur H100, on vous demande souvent un engagement de plus de 6 mois.
      Pour les intermédiaires en GPU, préférer les réservations longues est une décision logique du point de vue business, et nous ferions probablement pareil à leur place. Mais notre objectif est différent : armer les rebelles. Nous voulons que quelqu’un qui n’est pas BigCorp puisse aussi entraîner des modèles.
    • Les prix sont très similaires, mais le modèle semble assez différent. La différence importante peut être le cas où l’on lance souvent de courts entraînements sur plusieurs GPU. Lambdalabs ne peut peut-être pas vous fournir 256 instances immédiatement.
      L’approche décrite dans le billet ressemble davantage à l’achat du droit de placer des jobs dans la file d’attente d’un cluster de 512 GPU, donc un job nécessitant 256 GPU ne pose pas vraiment problème. Il faudra simplement éventuellement attendre derrière quelqu’un qui lance un job sur 512 GPU.
      Je ne sais pas quelle est la capacité réelle de Lambdalabs. Je me demande si quelqu’un sait à quel point il est facile d’y lancer plus de 2 ou 3 instances.
    • En général, sans engagement sur des instances réservées de longue durée, on ne peut obtenir que quelques H100 à la fois.
    • Il n’existe pas vraiment de moyen pratique d’obtenir un gros bloc sans engagement. De mémoire, l’engagement minimum pour des H100 était de 64 GPU pendant 3 ans, soit environ 3 millions de dollars.
    • À 2 dollars de l’heure pour un H100, cela semble plus flexible, mais je n’ai jamais essayé d’obtenir 10 000 GPU-heures sur ce genre de service. C’est peut-être là que se situe le goulot d’étranglement.

  • Personnellement, je m’intéresse beaucoup à l’IA et j’y participe depuis plusieurs années, mais je n’ai jamais vu une telle pénurie de GPU. Pour quelqu’un qui veut faire du machine learning en amateur, je recommande vivement vast.ai.

    • Comme clouds supplémentaires, pour les H100 et A100 il y a Lambda, Fluidstack, RunPod, CoreWeave, Crusoe, Oblivus et Latitude.
      Pour les GPU autres que A100/H100, il y a vast, TensorDock, ainsi que RunPod.
    • Cela dépend de ce qu’on entend par amateur, mais pour lancer quelques minutes de T4 afin d’apprendre les outils et les concepts, modal.com a été plutôt bien.
      Ils revendent actuellement AWS et GCP, et proposent aussi des A100, mais pour l’instant un T4 suffit.
    • vast.ai ressemble davantage à une place de marché façon gig economy pour GPU. Je viens d’utiliser ma première machine : elle fonctionnait bien, avec 512 Go de RAM, 256 CPU AMD et un GPU A100, et j’ai utilisé environ 4 minutes pour 0,05 dollar. Ce montant m’a même été offert gratuitement.

  • Je comprends qu’AWS/GCP/Azure aient de l’overhead, et aussi pourquoi beaucoup d’entreprises choisissent le bare metal en production. Personnellement, je pense que le temps et l’effort en valent rarement la peine, mais je conçois qu’à grande échelle les économies puissent être importantes.
    Cela dit, si même pour l’entraînement IA les clouds publics ne sont pas compétitifs sur les pics de demande, alors leurs marges sont bien plus élevées qu’on ne l’imaginait. Je me demande à quoi correspond la réduction de coût de 10 à 20 fois mentionnée dans le billet. Par rapport à AWS ?

    • Sur AWS, le p5.48xlarge coûte 98,32 dollars de l’heure pour 8 H100, soit 12,29 dollars de l’heure par H100. C’est environ 6 fois plus cher.

  • En tant que personne qui aime SF, je me demande s’il y a quelque chose d’intéressant derrière le nom. Le matériel sera-t-il réellement installé à SF ? Prévoyez-vous d’organiser des meetups ou de réunir les clients pour qu’ils échangent ?
    Nous n’avons pas encore disparu comme le Xerces blue, nous existons toujours.
    https://en.wikipedia.org/wiki/Xerces_blue

    • Le matériel ne sera pas hébergé à SF, car ce n’est pas l’espace de datacenter le moins cher.
      Mais je pense qu’une bonne partie des clients seront par ici. SF reste probablement le meilleur endroit pour créer une startup. Il y a vraiment beaucoup de gens qui résolvent des problèmes techniques difficiles. Dans tous les endroits où j’ai vécu à SF, il y avait une autre startup à l’étage au-dessus ou en dessous.
      Organiser des événements en présentiel est aussi une bonne idée.

  • J’aime l’idée d’un actif communautaire. Est-ce que cela pourrait être le début d’une coopérative de GPU ?

    • Pour les cartes grand public, cela existe déjà sous cette forme. Avec vast.AI, on peut gagner de l’argent avec son propre GPU.
      https://cloud.vast.ai/host/setup
    • Je ne connais absolument pas l’infrastructure interne de Twitter, mais vu la baisse des revenus publicitaires, la baisse de l’engagement des utilisateurs et l’arrivée de Threads, je me dis que Twitter pourrait utiliser une partie de son infrastructure pour soutenir ce genre de startups.
      Cela pourrait être de l’espace en rack, des VM, des conteneurs, de la connectivité, n’importe quoi. En gros, Twitter régresserait pour devenir un opérateur de colocation comme à la fin des années 90.
      Pour ceux qui ne l’auraient pas compris, c’est une blague.

  • Je me demande comment ils ont trouvé l’argent pour acheter 512 H100.

    • Comme c’est clairement indiqué dans la première phrase de l’article, ce sont des investisseurs VC qui font cela pour les startups dans lesquelles ils viennent d’investir, et ils cherchent aussi d’autres participants.