HN en public : connexion à un GPU virtuel via TCP

• Contrairement au CPU, au stockage, au réseau et à la mémoire, le GPU n’a pas encore été virtualisé comme une ressource abondante, et Thunder Compute cherche à résoudre cela au niveau système
• L’objectif de l’augmentation de l’offre ne consiste pas seulement à fabriquer plus de puces, mais aussi à mieux utiliser les GPU déjà déployés grâce au logiciel
• Alors que les optimisations existantes sont restées au niveau des workloads, comme le batching pour l’inférence ou la mise en file d’attente des tâches d’entraînement, la virtualisation des GPU vise un domaine système relativement moins exploré
• Il est possible d’utiliser des NVIDIA H100 à partir de 1,38 $/heure depuis VS Code, le CLI ou le navigateur, avec une réduction de 80 % par rapport à AWS, sans contrat, sans frais d’egress et avec un stockage extensible
• Après quatre ans en mode furtif, l’entreprise a créé un prototype de recherche et veut déployer une amélioration de la capacité GPU des datacenters via son propre cloud et des partenaires enterprise

---

Améliorer la faible utilisation grâce à la virtualisation des GPU

• Thunder Compute estime que plusieurs ressources rares du calcul sont finalement devenues abondantes, mais que les GPU n’ont pas encore connu la même transition
• Rendre les GPU abondants ne dépend pas uniquement de la production de davantage de puces, mais aussi du logiciel permettant de mieux exploiter les puces déjà installées
• À l’heure actuelle, les GPU sont souvent sous-utilisés, et les solutions existantes se concentrent principalement sur la couche workload
  • Traitement par lots des requêtes d’inférence
  • Mise en file d’attente des tâches d’entraînement sur plusieurs flottes de serveurs
• La virtualisation est devenue courante pour les CPU, le stockage, le réseau et la mémoire, mais le GPU n’a pas encore atteint le même niveau de virtualisation
• Traiter cet espace laissé vacant au niveau système constitue l’approche centrale de Thunder Compute

Approche produit et plan de déploiement

• Thunder Compute se présente comme un systems lab à vocation commerciale, qui cherche à appliquer en production les recherches les plus récentes sur la virtualisation des GPU
• L’équipe se compose, selon sa présentation, d’experts en infrastructure et de chercheurs en systèmes venant de Citadel Securities, Aquatic et AWS
• Pendant quatre ans en mode furtif, elle a développé un prototype de recherche, et déploie désormais ses résultats via son propre cloud et des partenaires enterprise
• D’après la présentation du produit, les NVIDIA H100 sont disponibles à partir de 1,38 $/heure
  • Accès via VS Code, CLI et navigateur
  • Réduction annoncée de 80 % par rapport à AWS
  • Sans contrat, sans frais d’egress, avec stockage extensible
• L’objectif est d’améliorer progressivement la capacité GPU des datacenters

[GN⁺]

Avis sur Hacker News

• Plutôt intéressant. Il m’est déjà arrivé d’avoir besoin de GPU-over-IP uniquement pour du transcodage vidéo.
  Mon serveur de homelab avait un GPU AMD peu performant qui faisait planter le noyau à chaque tentative d’encodage vidéo, tandis que mon PC de jeu avait une NVIDIA RTX 3080. J’ai donc créé https://github.com/steelbrain/ffmpeg-over-ip, lancé le serveur sur la machine Windows et le client sur le serveur multimédia (Plex, Emby, Jellyfin, etc.), et ça a parfaitement fonctionné.

  • Si tu ne l’as pas encore soumis à Show HN, ça vaudrait le coup d’y penser.
    https://gist.github.com/tzmartin/88abb7ef63e41e27c2ec9a5ce5d...
    https://news.ycombinator.com/showhn.html
    https://news.ycombinator.com/item?id=22336638
  • C’est à peu près ce à quoi je m’attendais en voyant le titre. J’ai été déçu que la soumission elle-même soit un service cloud payant plutôt qu’un outil généraliste utile ; comme souvent, le vrai contenu était dans les commentaires.
    Je me demande aussi dans quels cas on utiliserait du GPU-over-network en dehors de l’encodage vidéo. Avec la latence supplémentaire, le machine learning ou les tâches graphiques intensives ne deviennent-ils pas difficiles ?
  • Intéressant. Je me demande si ça prend aussi en charge les conversions multi-fichiers, comme avec HLS où plusieurs fichiers découpés en tranches temporelles sont générés.

• Si cela fonctionne à la frontière CPU/GPU, je me demande si, pour les datasets qui ne tiennent pas en VRAM, cela ne crée pas un énorme goulot d’étranglement d’E/S.
  J’ai peut-être mal compris le fonctionnement, mais si les E/S GPU sont interceptées, cela voudrait dire streamer tout le dataset vers la machine distante à chaque époque, ce qui semble être du gâchis.

  • Ta compréhension du système est correcte. Pour le rendre pratique, nous avons implémenté plusieurs optimisations afin de réduire le coût des E/S.
    Les performances d’inférence BERT sont visibles ici : https://youtu.be/qsOBFQZtsFM?t=69
    L’entraînement a plus d’overhead que l’inférence, et nous sommes en train d’implémenter d’autres optimisations pour nous rapprocher des performances natives.

• Pour ceux qui se demandent comment cela fonctionne concrètement, on dirait qu’ils injectent une bibliothèque dans le processus, hookent ces fonctions[1], puis les transmettent au service.
  [1] https://pastebin.com/raw/kCYmXr5A

  • Je me demande comment ils ont déterminé que ces fonctions étaient hookées. Je suppose qu’il existe un flag ld/ldd qui indique quels symboles sont rebondés.
    Je pensais aussi qu’un symbole devait être faible pour pouvoir être rebondé, mais NVIDIA n’exposerait sûrement pas de symboles faibles ; donc cela veut-il dire qu’en pratique c’est une approche LD_PRELOAD ?
  • J’espérais une sorte de méthode magique qui transmettrait tout le périphérique PCIe.

• Intéressant, mais ce qui m’intéresse davantage, c’est le self-hosting. J’ai déjà beaucoup de GPU, certains utilisés et d’autres inactifs.
  Je me demande s’il existe une option self-hosted pour utiliser les GPU que l’on possède déjà.

  • Le self-hosting n’est pas encore pris en charge, mais la même technologie semble bien s’y prêter.
    Les avantages comme l’ordonnancement efficace des tâches, le partage de GPU et la facilité d’utilisation s’appliquent tout autant à un environnement self-hosted. Nous sommes tout à fait ouverts à cette possibilité à l’avenir.
  • Si tu veux une expérience proche de PyTorch au-dessus de tes propres GPU, qu’il s’agisse de matériel fixe ou de cloud, regarde https://github.com/run-house/runhouse.
  • Si tu veux une bonne expérience de développement tout en utilisant tes propres GPU ou ton compte cloud, regarde SkyPilot.
  • Avec des services comme Akash Network, tu peux louer tes propres GPU dans le cloud, et tu peux aussi louer des GPU sur thundercompute.com. Cela ressemble presque à un parcours administrateur de type self-hosting.

• Je ne comprends pas bien. On peut lancer directement l’instance GPU voulue dans ECS ; je ne vois donc pas pourquoi il faudrait lancer une instance dans ECS pour utiliser vos GPU depuis ECS.
  À part ça, je ne vois pas non plus pourquoi on voudrait utiliser un Nitro au rabais plutôt que le vrai Nitro.

  • C’est un bon point. Il y a quelques avantages.
    Si tu fais du développement nécessitant un GPU en continu, tu dois généralement payer pendant toute la durée où l’instance est allumée. Avec Thunder, tu ne paies que pendant que tu utilises réellement le GPU. Quand tu exécutes seulement du code CPU, tu ne paies pas de temps GPU. L’alternative consiste à démarrer et arrêter manuellement l’instance, ce qui peut être pénible.
    Il est aussi facile d’augmenter le type et le nombre de GPU utilisés. Par exemple, si tu développes sur une instance T4 peu chère puis veux lancer un entraînement deep learning complet sur 8 A100, tu peux exécuter une seule commande et passer immédiatement à des GPU plus puissants, sans changer d’instance ni reconfigurer ton environnement.
  • Du point de vue du système, cela paraît plus transparent. Par exemple, si tu utilises sur un client léger une application GUI nécessitant l’accélération GPU (Matlab, SolidWorks, Blender), tu peux le faire sans configurer ECS.
    Tu peux développer sans GPU puis en attacher soudainement un au moment de lancer une simulation, et cela semble beaucoup moins cher qu’AWS. Au fond, cela ressemble à une manière plus généraliste de résoudre le problème que Ray (https://www.ray.io/) cherche à résoudre. La possibilité d’un partage de GPU plus fin, par exemple un demi-GPU, serait aussi envisageable, ce qui est très prometteur.

• Comme il y a beaucoup d’intérêt ici, nous avons décidé d’ouvrir gratuitement des instances T4. Essayez-les et dites-nous ce que vous en pensez.

  • Je me demande quels sont les prix pour les A100 et H100.

• Génial. Je me demande si vous auriez pu faire fonctionner ça aussi avec MIG ou vGPU.

  • Nous n’avons pas testé avec MIG ou vGPU, mais comme ce sont essentiellement des méthodes de partitionnement physique du GPU, cela devrait fonctionner.
    L’un de nos principaux objectifs à court terme est de permettre le partage de GPU. Comme nous permettrons aux utilisateurs d’utiliser toute la mémoire du GPU au lieu de les limiter à une partie de celle-ci, cela pourrait être mieux que MIG ou vGPU.

• Je me demande à quoi ressemble l’usage réel avec un débit significatif. Peut-on aussi l’utiliser pour du craquage de hash ?
  Chaque fois que je pense à un GPU virtuel par-dessus le réseau, je pense à un botnet. En particulier à ce passage de https://www.hpcwire.com/2012/12/06/gpu_monster_shreds_passwo... : « Gosney a d’abord dû convaincre le professeur Amnon Barak, cofondateur de Mosix, qu’il ne cherchait pas à “transformer le monde en un botnet géant”. »

  • C’est une expérience de pensée intéressante, mais en pratique notre système ressemble davantage à AWS qu’à un botnet, puisque les GPU ne sont pas distribués.
    Cette technologie ouvre des applications intéressantes pour créer des clusters très flexibles au sein d’un datacenter, et c’est ce que nous explorons.

• Les ingénieurs SGI d’origine qui ont développé glx avaient très soigneusement conçu le système pour utiliser les mécanismes X11 pour le transport GPU ; il était donc assez simple d’envoyer un flux GL sur le réseau et de le rendre sur ma carte graphique.
  C’était du genre : « exécuter sur le supercalculateur au bout du couloir, rendre sur la station de travail ». Le développement récent des pilotes ne semble pas avoir gardé cette attention, donc ce n’est généralement plus possible. Je ne sais pas à quel point c’était réellement utile. En général, si on avait une bonne carte graphique, on avait aussi un bon CPU. Mais c’était amusant à expérimenter, et il y avait quelque chose d’étrangement séduisant à voir un programme tournant dans la salle des machines bénéficier de graphismes accélérés. Une fois, j’ai réussi à lancer glquake de cette façon.

• Le simple fait que ce soit possible est impressionnant, mais je me demande ce qui se passe quand la connexion réseau se coupe ou n’est pas fiable à 100 %.
  D’après mon expérience, les pilotes réagissent mal dès qu’un GPU local se comporte ne serait-ce qu’un peu bizarrement.