Actualités

Quoi qu’il en soit, Google Cloud ajoute un support natif Ray pour PyTorch sur les TPU

Anyscale et Google Cloud ont indiqué que Ray prend désormais en charge PyTorch sur les TPU Google nativement sur GKE, avec une personne par puce TPU et une planification compatible TPU.

Quoi qu’il en soit, Google Cloud ajoute un support natif Ray pour PyTorch sur les TPU

Article traduit. Lire l'article original.

Anyscale et Google Cloud ont déclaré le 20 octobre 2026 que Ray prend désormais en charge nativement les charges de travail PyTorch sur les TPU Google, étendant la pile PARK à la formation et à l’inférence basées sur TPU sur Google Kubernetes Engine. Les entreprises ont indiqué que l’intégration est basée sur le projet TorchTPU de Google et KubeRay sur GKE, et est conçue pour offrir aux utilisateurs de PyTorch un modèle appareil par travailleur sur les TPU Cloud.

Preuves et contexte

Dans l’annonce, Anyscale a indiqué que les équipes de plateformes et de machine learning fonctionnant sur GKE peuvent planifier, mettre en échelle, faire fonctionner des charges d’entraînement distribué PyTorch, d’inférence vLLM et d’apprentissage par renforcement entre GPU et TPU sur un seul plan de contrôle Kubernetes. La société a indiqué que les travailleurs Ray sur les TPU mappent désormais un worker vers un puce TPU, en utilisant resources={"TPU": 1} une isolation de dispositif via TPU_VISIBLE_CHIPS, tout en basculant le code PyTorch de cuda vers tpu et le backend distribué de nccl vers tpu_dist.

Le post précisait également que l’API SlicePlacementGroup de Ray est utilisée pour organiser en groupe les acteurs sur la même tranche TPU, et que TorchTrainer de Ray Train peut orchestrer des charges de travail parallèles de données distribuées, Fully Sharded v2 Data Parallel et DTensor sur des tranches Cloud TPU à hôte unique et multi-hôte. Les exemples du post spécifient une configuration 16-worker sur une tranche V6E TPU- 4x4, avec use_tpu=True, resources_per_worker={"TPU": 1} et une configuration automatique des variables d’environnement distribuées PyTorch.

Pour inférence, Anyscale a indiqué que vLLM-TorchTPU enregistre TorchTPU comme un plugin de plateforme vLLM, permettant aux terminaux compatibles OpenAI de s’exécuter sur des tranches TPU via Ray Serve LLM. La configuration d’exemple dans le post utilise une topologie TPU-V6E 4x4 et spécifie tensor_parallel_size=16, enable_expert_parallel=True et max_model_len=8192.

Ce qui est vérifié et ce qui reste limité

L’annonce est conforme aux récentes recommandations TPU de Google Cloud et fait suite aux publications Google Developers datées du 20 juillet et 2026-07-24 sur l’exécution de Ray sur les TPU. Le matériel de fond vérifié fourni avec cette demande précise également que Ray Train orchestre la formation distribuée entre machines, mais se distingue du runtime du framework qui exécute les opérations tensorielles.

En même temps, le background fourni indique que le backend Ray 2.59.0 PyTorch inspecté recommande exactement un appareil TPU par travailleur et génère explicitement une erreur pour l’entraînement sur plusieurs tranches TPU. Cela signifie que l’article doit distinguer entre l’entraînement multi-hôtes dans une seule tranche TPU, ce qui est décrit dans le matériel source, et l’entraînement multi-tranches, qui n’est pas vérifié ici pour Ray 2.59.0. Le matériel fourni indique également qu’un article Google de juillet 24 décrit la mise à l’échelle multi-tranches pour JaxTrainer, mais cela ne doit pas être généralisé à PyTorch.

Le matériel source ne fournit ni prix, ni données de marché, ni dates de résultats ni positionnement des investisseurs. Il ne fournit pas non plus de date catalyseur vérifiée au-delà de l’annonce 20 octobre 2026 elle-même.

Autres articles en français · Comparaisons financières et sources SEC (anglais)