L’outil de calcul distribué Ray Core a étendu son support natif pour inclure une douzaine de types d’accélérateurs matériels. Cette intégration permet désormais aux tâches et aux acteurs de spécifier leurs besoins en ressources matérielles, qu’il s’agisse de GPU NVIDIA, de TPU Google, ou de puces plus spécialisées comme les Gaudi d’Intel ou les Ascend de Huawei, selon docs.ray.io.

Le support natif distingue les niveaux de validation. Les GPU NVIDIA et les TPU Google sont entièrement testés et soutenus par l’équipe de Ray. En revanche, les accélérateurs comme les GPU AMD et Intel, les puces Neuron Core d’AWS, ou les unités FuriosaAI sont intégrés, mais leur support est marqué comme expérimental et dépend de la communauté.

Le fonctionnement repose sur la spécification des ressources. Si une tâche ou un acteur requiert un accélérateur, l’utilisateur le précise, par exemple via @ray.remote(num_gpus=1). Ray planifie alors cette charge de travail sur un nœud disposant de la capacité adéquate. Pour affiner ce contrôle, des variables d’environnement permettent de limiter la visibilité du matériel. Par exemple, CUDA_VISIBLE_DEVICES=1,3 permet de restreindre les GPU NVIDIA visibles à Ray aux dispositifs 1 et 3.

Ce niveau de granularité répond à la complexification du marché des accélérateurs. PyTorch souligne que l’écosystème actuel est très spécialisé : on trouve des GPU Blackwell de NVIDIA pour l’entraînement à grande échelle, des TPU Ironwood de Google, ou des unités Groq dédiées à l’inférence à faible latence.

L’ambition derrière cette évolution dépasse la simple liste de composants. Le groupe d’intérêt (SIG) Ray sur les accélérateurs vise à définir une feuille de route neutre vis-à-vis des fournisseurs. L’objectif n’est plus seulement de compter les puces, mais de comprendre la topologie du système : comment les dispositifs sont interconnectés, leur relation avec les CPU et les autres composants.

Les priorités initiales de ce groupe se concentrent sur l’infrastructure de développement et de test. Il est nécessaire d’établir des processus pour que les contributeurs puissent valider les changements sur des équipements réels, assurant ainsi la stabilité de chaque nouvelle intégration avant sa diffusion. Par ailleurs, la gestion de la découverte matérielle doit évoluer d’une simple identification de type à une cartographie précise de l’architecture du cluster.

Pour les utilisateurs avancés, des mécanismes de contrôle fins sont déjà disponibles. Si un utilisateur souhaite limiter la visibilité des dispositifs, il peut définir des variables spécifiques. Par exemple, pour les puces Huawei Ascend, on utilise ASCEND_RT_VISIBLE_DEVICES. Il est même possible de spécifier un nombre de ressources supérieur au nombre réel de dispositifs sur la machine ; dans ce cas, Ray simule la présence de ce matériel pour le dimensionnement des tâches, tant que celles-ci n’essaient pas réellement de l’utiliser.

Ce travail sur la sémantique du matériel est fondamental. Si Ray se contente de compter les GPU, il est limité. En comprenant la connectivité et la structure, il peut placer les tâches sur le matériel le plus adapté, une exigence essentielle pour les déploiements d’IA à l’échelle.

Sources

• Accelerator Support, docs.ray.io
• Announcing the Special Interest Group (SIG) for Ray on Accelerators, PyTorch, 2 novembre 2026