Déterminé AI est une plate-forme de formation open source d'apprentissage en profondeur qui fournit une formation distribuée, une recherche automatique de super-paramètres, des capacités de gestion de cluster GPU et de suivi des expériences, et prend en charge PyTorch et TensorFlow.

IADéterminée

Détermination des paramètres et statistiques de base de l'IA

L'IA déterminée se positionne comme un « système d'exploitation pour la formation en apprentissage profond » et résout le problème d'orchestration distribuée le plus difficile en ingénierie ML : lorsque la tâche de formation s'étend d'une seule carte à plusieurs nœuds, les coûts de modification du code, la concurrence entre les ressources et le chaos expérimental sont devenus un problème inévitable pour presque toutes les équipes. Déterminé encapsule ces problèmes via une couche de planification unifiée, permettant aux chercheurs de se concentrer uniquement sur le modèle lui-même.

Projets	Informations publiques
Positionnement officiel	Plateforme de formation open source en deep learning
Capacités de base	Formation distribuée, recherche d'hyperparamètres, suivi des expériences, gestion des clusters GPU
Frameworks pris en charge	PyTorch, TensorFlow, Keras (y compris KerasTuner)
Méthode de déploiement	Auto-hébergé : Kubernetes, cluster d'agents local Slurm/PBS, AWS/GCP
Portail d'accès	Interface utilisateur Web, CLI (det), SDK Python, API REST
Licence Open Source	Apache2.0
Dépôt de codes	GitHub determined-ai/determined (3,2 000 étoiles, 372 Forks, 96 contributeurs)
Dernière version	v0.38.1 (20/03/2025)
Propriété de l'entreprise	HPE (Hewlett Packard Enterprise) – Acquisitions 2021
Pile technologique	Go (44,6%) / Python (27,9%) / TypeScript (24,4%)

Un bref commentaire en une phrase : Il ne s'agit pas d'un autre tableau de bord MLOps, mais d'un moteur de planification qui fait passer la "formation multi-machines et multi-cartes" de la configuration manuelle à la soumission déclarative. La valeur fondamentale est de permettre à l'équipe de suivre une formation distribuée avec la charge mentale d'écrire du code sur une seule machine.

Contexte de l'acquisition HPE : Après l'acquisition, déterminé a obtenu des ressources de support au niveau de l'entreprise. La version EE (Enterprise Edition) a commencé à nécessiter une clé de licence. La version OSS et la version EE présentent des différences fonctionnelles dans les fonctionnalités d'entreprise telles que l'audit SSO et RBAC. La communauté doit veiller à ce que la version OSS continue de recevoir des mises à jour des fonctionnalités de formation de base de la même qualité que la version EE.

Utilisateurs et reconnaissance du marché de l'IA déterminée

Activité de la communauté GitHub : L'entrepôt compte 3,2 000 étoiles, 372 Forks, un total de 121 versions (en 2026-07) et 96 contributeurs, ce qui indique que le projet bénéficie d'une attention stable dans le domaine des MLOps open source mais n'est pas encore entré dans les rangs des plus populaires (des projets similaires tels que MLflow ont des étoiles plus élevées).

Adoption par les entreprises : HPE intègre Déterminé dans ses solutions d'infrastructure d'IA pour les clients HPC des secteurs de la finance, de la fabrication, de la recherche scientifique et d'autres secteurs. Les cas d'adoption accessibles au public sont dominés par les établissements universitaires et les équipes de ML de taille moyenne, tandis que le nombre de déploiements d'entreprises à grande échelle n'est pas divulgué.

Analyse comparative de l'industrie : par rapport à Kubeflow (MLOps natif complet du K8) et MLflow (orienté vers le suivi expérimental + l'enregistrement du modèle), la principale différence de Déterminé réside dans « la planification et l'accélération de la tâche de formation elle-même » plutôt que dans l'orchestration des liens complets. Dans le sous-domaine de la formation distribuée, il complète plutôt qu'il ne concurrence directement Horovod (couche de communication distribuée uniquement) et Weights & Biases (suivi expérimental uniquement).

Dimensions comparatives	IA déterminée	Kubeflow	MLflow	Horovod
Positionnement	Plateforme de planification de formations	MLOps à lien complet	Suivi des expériences + enregistrement du modèle	Bibliothèque de communication de formation distribuée
Formation distribuée	Orchestration automatique	Configuration manuelle requise	Non impliqué	Fournir des primitives de communication
Recherche d'hyperparamètres	Intégré (Grille/Bayésien/ASHA)	Nécessité d'intégrer Katib	Non intégré	Non impliqué
Planification des clusters	File d'attente intégrée + quota	Planification native K8	Non impliqué	Non impliqué
Difficulté à démarrer	Moyen (nécessite les bases de K8)	Élevé	Faible	Moyen

Avantages financiers de l'IA déterminée

Côté C/individuel

La version open source est entièrement gratuite (Apache 2.0). Les particuliers peuvent installer la CLI via « pip install approved » et déployer un cluster local sur une seule machine ou sur leur propre GPU. Il n'y a aucun frais de licence, mais vous devez supporter les coûts opérationnels liés à la maintenance de votre propre backend de stockage PostgreSQL +.

Développeur/Équipe

Il n'y a pas de frais de licence logicielle pour la version open source, et les équipes peuvent choisir de la déployer selon leurs besoins :

• Mode agent local : déployez Master + Agent sur bare metal ou VM, adapté aux équipes disposant de serveurs GPU existants, avec une faible complexité d'exploitation et de maintenance.
• Mode Kubernetes : déployé via Helm Chart, adapté aux équipes qui disposent déjà de l'infrastructure K8, mais nécessitent des capacités de gestion K8.
• Déploiement cloud : det déployer aws/gcp up Déploiement en un clic, payez en fonction de l'utilisation réelle des ressources cloud, pas de frais de licence supplémentaires.

Les coûts cachés se reflètent principalement dans la main d'œuvre d'exploitation et de maintenance : gestion de la base de données PostgreSQL, configuration du stockage (S3/GCS/système de fichiers partagé), politiques de groupe réseau et de sécurité, mises à niveau et migrations de versions, etc.

Entreprise/Privatisation

HPE propose Enterprise Edition, qui comprend :

• Intégration SSO/SAML
• Audit d'autorisation précis RBAC
• SLA commercial et support technique
• Validation pré-intégrée avec le matériel HPE tel que les serveurs ProLiant Stockage Nimble

Le prix de l'édition Enterprise n'est pas divulgué, veuillez obtenir un devis via les ventes HPE. Termes clés à vérifier avant l'achat : si la licence est facturée en fonction du nombre de nœuds/GPU ou d'utilisateurs, si elle inclut le temps de réponse SLA limité à la production, le chemin de mise à niveau et l'étendue de la prise en charge de la migration des données.

Hiérarchie des coûts	Éléments de coût	Coûts annuels typiques (dérivation)
Individuel/Petite équipe (OSS)	0 frais de licence + frais d'hôte cloud/GPU	0 $ + ressources cloud à la demande
Equipe de taille moyenne (OSS + autoexploitation et maintenance)	0 droit de licence + main d'œuvre d'exploitation et de maintenance (environ 0,5~1 personne-mois/an)	5 000 $ ~ 15 000 $ (conversion d'exploitation et de maintenance)
Entreprise (HPE EE)	Frais de licence + contrat de support + matériel	Confirmation commerciale requise

Principales fonctions de l'IA déterminée

• Formation distribuée sans modification : les utilisateurs doivent uniquement utiliser la classe de base determined.pytorch.PyTorchTrial ou determined.keras.KerasTrial dans le script de formation, et la plateforme gère automatiquement la synchronisation du gradient (All-Reduce), le partage des données et la tolérance aux pannes des nœuds. Il n'est pas nécessaire d'écrire manuellement « torch.distributed.launch » ou « tf.distribute.Strategy », ce qui réduit la barrière d'entrée pour la formation distribuée.

  • Vue d'expert : l'avantage caché de cette couche d'abstraction est que l'équipe peut passer directement d'un prototype à carte unique à une production multi-cartes sans avoir à intégrer une logique distribuée dans le code. Pour augmenter ultérieurement le nombre de GPU, il vous suffit de modifier slots_per_trial dans la configuration YAML, sans changer le code d'entraînement.

• Recherche adaptative d'hyperparamètres (ASHA) : basée sur l'algorithme de réduction de moitié successive asynchrone, les essais à faible potentiel sont éliminés en premier lorsque les ressources sont limitées, et davantage de puissance de calcul est allouée aux combinaisons de paramètres à haut potentiel. Prend en charge l'arrêt anticipé, la recherche par grille et la recherche bayésienne, et peut ajuster dynamiquement l'espace de recherche pendant le processus de recherche.

  • Vue d'expert : La collaboration entre ASHA et le planificateur de plate-forme est la principale différence de Déterminé : l'algorithme de recherche peut non seulement déterminer « quel est le prochain ensemble de paramètres », mais peut également contrôler « quels essais peuvent être préemptés » via le planificateur de plate-forme, rétrogradant automatiquement les essais de recherche de faible priorité lorsque le cluster est plein, pour éviter que les recherches d'hyperparamètres ne bloquent les tâches de formation formelles.

• Quota GPU et planification de files d'attente : prend en charge la division du quota GPU par pool de ressources (Resource Pool). Une fois que l'utilisateur a soumis la tâche via « det experience create », la plate-forme met automatiquement en file d'attente, planifie et alloue des emplacements. Prend en charge Priority Scheduler et Fair Scheduler pour empêcher un seul utilisateur de remplir le cluster.

  • Vue d'expert : la combinaison du planificateur + du quota résout le dilemme typique de l'équipe de « la inactivité du GPU et les conflits coexistent ». Les chercheurs n'ont plus besoin de négocier manuellement qui utilisera la carte et à quel moment, et la plateforme garantit que les tâches soumises seront finalement planifiées, ce qui peut réduire considérablement les coûts de coordination dans une équipe de plus de 10 personnes.

• Suivi des expériences et instantanés automatiques : enregistrez automatiquement les indicateurs (séries chronologiques telles que la perte/précision), la configuration des hyperparamètres, les instantanés de code complets (Git Commit + fichiers non suivis) et les points de contrôle de poids du modèle pour chaque formation. L'interface utilisateur Web prend en charge la comparaison et la visualisation de plusieurs indicateurs expérimentaux, et Checkpoint peut reprendre ou poursuivre la formation en un seul clic.

  • Expert View : l'interception automatique des instantanés de code est plus fiable que l'enregistrement manuel - même si le chercheur oublie de s'engager, la plateforme archivera automatiquement le code source lors de sa soumission. Ceci est crucial pour la reproductibilité expérimentale, en particulier lorsque plusieurs chercheurs partagent un cluster. "Avec quelle version du code ce modèle a été exécuté" n'est plus un mystère.

• Tâches Notebook et interactives : démarrez Jupyter Notebook, TensorBoard ou Shell sur le nœud GPU du cluster, et les calculs sont effectués directement sur le nœud GPU. Les données du notebook et les tâches de formation partagent la même couche de stockage (système de fichiers partagé ou stockage d'objets), ce qui facilite la soumission directe des tâches de formation après le prétraitement des données.

  • Vue Expert : les tâches de bloc-notes et de formation partagent le pool GPU, ce qui signifie que la même carte ne peut pas exécuter le bloc-notes et la formation en même temps. Il est recommandé de limiter les blocs-notes à des pools de ressources de faible priorité ou à des petits pools GPU séparés pour éviter que les tâches interactives n'occupent les ressources de formation en production.

• Intégration DeepSpeed ​​​​ : prise en charge intégrée de DeepSpeed ​​​​depuis la version 0.17.0, l'optimisation ZeRO (étape 1/2/3) peut être activée via la configuration YAML pour réduire l'utilisation de la mémoire graphique dans des scénarios de formation de très grands modèles. Associés à la synchronisation automatique des gradients de Ensured, le mode de communication et le planificateur de plate-forme de ZeRO fonctionnent ensemble.

• Core API (interface de niveau inférieur) : Pour les utilisateurs avancés qui n'ont pas besoin de la classe de base Trial, Ensured fournit l'API Core, permettant aux utilisateurs d'intégrer les fonctions de la plateforme de la manière la moins intrusive - utilisez uniquement det.core.init() pour obtenir le contexte pour enregistrer les indicateurs et sauvegarder les points de contrôle, sans forcer la modification de la structure du cycle de formation. Ceci est particulièrement utile lors de l'intégration de bibliothèques de formation tierces telles que Hugging Face Trainer.

Evolution du modèle et de la version de Déterminé AI

Déterminé adopte la stratégie de publication à double voie « OSS + EE » : la version OSS suit le versionnement sémantique et la version EE ajoute le suffixe « -ee » après le numéro de version OSS.

Version principale

Numéro de version	Date de sortie	Changements fondamentaux
v0.32.0	2026-05 (pas encore de date officielle précise)	Dernière version, incluant l'optimisation des performances et les corrections de bugs
v0.38.1	2025-03-20	La dernière version stable, y compris les mises à jour des images d'environnement et les réparations des dépendances
v0.38.0	2024-11-23	Supprimer le contexte du chercheur (simplification de l'architecture), la politique de configuration des tâches (politiques de configuration) GA, l'interface utilisateur des politiques de configuration globales
v0.37.0	2024-09-30	Nouvel objet d'exécution (API Run Centric), alerte de charge de travail (alerte de charge de travail), prise en charge initiale des politiques de configuration
v0.36.0	2024-08-24	Vue Flat Runs GA, RBAC Webhook, prise en charge initiale de Data Lineage
v0.35.0	2024-08-09	Vue de comparaison des exécutions plates, recherche de filtre de métadonnées, soumission du pod K8s au travail, fractionnement du framework (Framework Splitting)
v0.34.0	2024-06-29	Certification Notebook Token Le sélecteur de nœud/affinité K8s prend en charge la pause/reprise de l'exécution
v0.33.0	2024-05-30	Gestion des modèles WebUI Tri/filtrage Flat Runs, carte thermique (Heatmap), vérification de la complexité du mot de passe Helm
v0.32.0	2024-04 (pas encore de date officielle précise)	API CRUD de modèle, prise en charge multi-RM K8s, fonctionnement par lots expérimental

Observation de la gestion des versions

• Rythme : maintenir une fréquence d'itération d'environ une version mineure par mois en 2024, et le rythme ralentira après l'entrée en 2025 (la v0.38.1 sera publiée en 2025-03), ce qui peut refléter l'amélioration de la maturité du produit ou l'ajustement des ressources de l'équipe.
• Évolution de l'architecture : la tendance principale de la v0.35 à la v0.38 est la migration de la « centralisation d'expérimentation-essai » vers la « centralisation d'exécution » (exécutions à plat) et l'introduction de politiques de configuration pour améliorer les capacités de gouvernance multi-locataires.
• Différences de l'édition Enterprise : La version EE est en avance sur OSS en termes de fonctionnalités d'entreprise telles que les améliorations SSO (v0.38.0+), la vérification des clés de licence, les journaux d'audit RBAC, etc. Les utilisateurs d'OSS doivent faire attention à savoir si ces fonctions seront progressivement transférées vers la version communautaire ou si elles resteront exclusives à EE pendant une longue période.

Avantages techniques de l'IA déterminée

Configuration déclarative de la formation : les utilisateurs définissent les hyperparamètres de formation, les besoins en ressources (slots_per_trial), les algorithmes de recherche et les stratégies de planification via YAML, et la plateforme génère des essais et planifie l'exécution en conséquence. Le principal avantage de cette abstraction déclarative est que les chercheurs décrivent « quoi faire » plutôt que « comment le faire », et la plate-forme décide automatiquement « combien de GPU exécuter sur quelle machine » en fonction de la charge du cluster en arrière-plan.

Synchronisation automatique du gradient (agrégation All-Reduce) : le composant Harness de Ensured injecte automatiquement une logique de synchronisation du gradient (basée sur NCCL ou Gloo) au-dessus du code de formation des utilisateurs, éliminant ainsi le besoin pour les utilisateurs d'écrire du code de communication distribué. Plusieurs essais indépendamment avant/arrière sur leurs emplacements attribués respectifs. Harness exécute automatiquement le gradient d'agrégation All-Reduce après chaque reverse()` pour garantir que les paramètres du modèle de chaque nœud sont cohérents. Ce mécanisme permet l'expansion d'une seule carte à plusieurs cartes en modifiant simplement « slots_per_trial » dans YAML, sans toucher au script de formation.

Planification de la collaboration pour la recherche ASHA : les outils de recherche d'hyperparamètres traditionnels s'exécutent indépendamment du planificateur, et les essais recherchés doivent toujours être mis en file d'attente pour les ressources. Déterminé intègre profondément le chercheur et le planificateur : une fois que le chercheur a déterminé l'ensemble de paramètres suivant, le planificateur décide s'il doit démarrer l'essai immédiatement et s'il doit anticiper les essais de faible priorité en fonction de la charge actuelle du cluster. Cette co-conception permet à la recherche d'hyperparamètres de ne pas bloquer les tâches de formation en production lorsque le cluster est plein : les essais de recherche sont marqués comme préemptifs, libérant automatiquement le GPU lorsqu'une tâche de priorité plus élevée est soumise.

Planification à double voie (Agent RM + K8s RM) : Déterminé prend en charge deux modes de gestion des ressources : Agent RM (cluster d'agents autogéré) et K8s RM (planification native Kubernetes). L'agent RM est adapté aux environnements Bare Metal/HPC, ne nécessite pas de dépendances K8 et est plus léger à déployer ; K8s RM convient aux équipes qui disposent déjà de l'infrastructure K8 et peuvent profiter de l'expansion et de la contraction automatiques de K8, de l'isolation de l'espace de noms et d'autres fonctionnalités. Les deux peuvent être activés en même temps (Multi-RM), permettant au même maître de gérer des clusters hétérogènes.

Abstraction du stockage de Checkpoint : Checkpoint prend en charge le stockage sur le stockage d'objets du système de fichiers partagé S3/GCS, ou HDFS. La plateforme maintient automatiquement le cycle de vie des points de contrôle (politique GC) et peut configurer la migration des données entre les couches de stockage. Cette abstraction dissocie le stockage et le calcul du cluster de formation : les nœuds de formation peuvent être des instances sans état et les points de contrôle sont conservés dans le stockage d'objets externe pour faciliter une récupération rapide après l'échec d'une expérience.

Profilage des performances intégré : l'interface utilisateur Web dispose d'un outil d'analyse des performances de formation intégré qui peut afficher des indicateurs tels que l'utilisation du GPU, le débit de chargement des données et le taux de communication pour aider à localiser les goulots d'étranglement de la formation (par exemple, si le chargement des données est un goulot d'étranglement ou si la communication est un goulot d'étranglement). Cette fonction ne nécessite pas d'intégration supplémentaire de Prometheus/Grafana, ce qui réduit la complexité de la chaîne d'outils pour le réglage des performances.

Le choix de Go comme langage principal dans l'entrepôt de code (44,6 %) montre que le composant Master a des exigences élevées en matière de performances de concurrence : le Master doit gérer les battements de cœur, les décisions de planification et les requêtes API de centaines d'agents en même temps. Le modèle Goroutine de Go est plus efficace que Python dans ce scénario. Python (27,9 %) est utilisé pour Harness (runtime de formation) et le SDK, et TypeScript (24,4 %) est utilisé pour l'interface utilisateur Web.

Comment utiliser l'IA déterminée

Installez la CLI et démarrez le cluster

# Installer la CLI
installation pip déterminée

# Cluster local (expérience rapide sur une seule machine)
det déployer un cluster local

#AWSDéploiement
det déployer aws up

# Déploiement GCP
det déployer gcp up

Soumettre la tâche de formation

Adaptation du script de formation (exemple PyTorch) :

à partir de déterminé.pytorch importer PyTorchTrial, DataLoader, PyTorchTrialContext

classe MonTrial(PyTorchTrial) :
    def __init__(soi, contexte : PyTorchTrialContext) :
        self.context = contexte
        self.model = self.context.wrap_model(nn.Sequential(...))

    def train_batch(self, batch, epoch_idx) :
        perte = self.model (lot)
        self.context.backward (perte)
        self.context.step_optimizer(self.optimizer)
        return {"perte": perte}

Fichier de configuration YAML (experiment.yaml) :

nom : mon_expérience
point d'entrée : train.py
hyperparamètres :
  taux_d'apprentissage :
    type: double
    minval : 0,0001
    valeur maximale : 1,0
chercheur :
  nom : adaptatif_asha
  métrique : perte
  small_is_better : vrai
  max_essais : 100
ressources :
  slots_per_trial : 8

Soumettre la commande :

det expérience créer experience.yaml .

Comparaison des options de déploiement

Méthode de déploiement	Scénarios applicables	Conditions préalables	Complexité de la maintenance
Cluster local (det déployer local)	Développement personnel/machine unique avec plusieurs cartes	Docker	Faible
AWS déploie aws	Démarrage rapide sur le cloud	Compte AWS + quota	Moyen
GCP det déployer gcp	Démarrage rapide sur le cloud	Compte GCP + quota	Moyen
Graphique de barre Kubernetes	Cluster K8 existant	Cluster K8s + Helm 3	Moyen à élevé
Déploiement manuel de l'agent	Métal nu/HPC	PostgreSQL + Stockage partagé	Élevé
Intégration Slurm/PBS	Grappe HPC	Slurm/PBS Contextuel	Élevé

Chemin de vérification rapide : les développeurs individuels recommandent « pip install approved && det déployer local cluster-up », qui peut extraire localement un cluster à nœud unique contenant Master + Agent en 5 minutes et exécuter l'exemple de processus principal de vérification officiel du MNIST.

Prix des produits pour une IA déterminée

Determined AI adopte un modèle de tarification à double voie : « version open source core + entreprise » :

• Version Open Source (OSS) : licence Apache 2.0, entièrement fonctionnelle, y compris la formation distribuée, la recherche de super paramètres, le suivi et la planification des expériences. Il n’y a aucune restriction d’utilisation ni plafond GPU. Convient aux particuliers, aux équipes académiques et aux équipes de taille moyenne disposant de capacités d'auto-exploitation et de maintenance.
• Enterprise Edition (HPE Enterprise Edition) : basé sur OSS, il ajoute un audit d'autorisation à granularité fine RBAC intégré SSO/SAML et une prise en charge SLA commerciale pour la vérification pré-intégrée du matériel HPE. Les prix sont obtenus via HPE Sales, sur la base d'un abonnement annuel, et l'unité de facturation spécifique (nœud/GPU/utilisateur) n'est pas divulguée.
• Cloud Hosted Edition : HPE ne propose pas d'hébergement SaaS, tous les déploiements sont auto-hébergés. Si vous souhaitez une expérience sans opération, vous pouvez la lancer rapidement sur le cloud via « det déployer aws/gcp », mais la gestion et la surveillance restent sous la responsabilité de l'équipe.

Version	Licence	Prix ​​	Échelle applicable
OSS	Apache2.0	Gratuit	Particuliers à équipes de taille moyenne (<100 GPU)
EE	Licence commerciale	Confirmation commerciale requise	Moyennes et grandes entreprises (plus de 100 GPU)

Avant d'acheter l'édition Enterprise, vous devez confirmer auprès de HPE : si elle prend en charge une tarification échelonnée en fonction du nombre de GPU et si elle inclut des conditions spécifiques pour l'assistance 24h/24 et 7j/7 en production, les mises à niveau et la migration des données.

Scénarios d'application d'IA déterminés

• Gestion de la formation de clusters multi-GPU : lorsqu'une équipe partage 10 à 100 GPU, la planification de file d'attente de déterminée réduit efficacement le gaspillage inactif : les chercheurs n'ont plus besoin de coordonner manuellement qui utilise la carte et à quel moment. La recherche de superparamètres analyse automatiquement l'espace des paramètres, éliminant ainsi le besoin de modifier manuellement les paramètres et de les réexécuter. Points clés de vérification : lorsque des tâches hautement prioritaires sont fréquemment soumises dans la planification de file d'attente, si les essais de recherche de faible priorité peuvent être correctement préemptés et restaurés.

• Pipeline d'expérimentation standardisé : des instantanés de code, des hyperparamètres, des indicateurs et des points de contrôle sont automatiquement enregistrés pour chaque formation. Lorsque de nouveaux chercheurs reprennent le projet, ils peuvent visualiser directement les expériences historiques sur l'interface utilisateur Web, les reproduire en un clic ou poursuivre leur formation à partir du point de contrôle spécifié. Points clés à vérifier : si l'instantané de code contient entièrement des fichiers modifiés locaux non suivis et si la stratégie Checkpoint GC peut conduire à une suppression prématurée.

• Very Large Model Training (DeepSpeed ​​​​Integration) : Pour la formation de modèles avec des dizaines de milliards de paramètres, ZeRO Stage 2/3 optimise l'utilisation de la mémoire vidéo et coopère avec la planification automatique multi-nœuds de Ensured pour abaisser le seuil d'infrastructure pour la formation de grands modèles. Focus de vérification : Compatibilité de la version DeepSpeed ​​et de la version déterminée Efficacité de la communication sous ZeRO Stage 3.

• Formation cloud hybride/cluster hétérogène : unifiez la gestion des clusters bare metal locaux et des clusters K8s sur le cloud via Multi-RM, et les tâches de formation sont automatiquement planifiées sur les nœuds disponibles en fonction des besoins en ressources. Objectif de vérification : impact du mécanisme de synchronisation des points de contrôle entre clusters et du retard du réseau sur la formation distribuée.

• HPC/Academic Research Computing : Déployez-vous sur le cluster Slurm/PBS pour fournir aux chercheurs scientifiques une interface utilisateur Web pour soumettre des tâches de formation, remplaçant ainsi la méthode SSH traditionnelle de soumission manuelle des tâches. Le suivi d'expérience intégré réduit les problèmes non reproductibles causés par « l'oubli d'enregistrer les paramètres ». Objectif de vérification : la version intégrée de Slurm prend en charge Job Array et coexiste avec les stratégies de planification HPC existantes.

Groupes applicables d'IA déterminée

• Chercheur en apprentissage profond/ingénieur en algorithmes : nécessité de mener des expériences de formation distribuées fréquentes, dans l'espoir de réduire la charge de travail d'adaptation du code distribué, d'enregistrer automatiquement les paramètres et les résultats expérimentaux et de comparer plusieurs ensembles d'indicateurs expérimentaux en un seul clic. La valeur est plus évidente parmi les équipes de taille moyenne dotées de 5 à 50 GPU.

• Ingénieur infrastructure/plateforme ML : responsable de la création d'une infrastructure de formation pour l'équipe. Nous espérons fournir une plate-forme en libre-service de « soumission et formation » et réduire le travail de support quotidien consistant à « aider les chercheurs à configurer les environnements, à ajuster les pilotes et à emballer les packages ». Il est nécessaire d'évaluer l'équilibre entre les coûts d'exploitation et de maintenance de K8/PostgreSQL et les améliorations d'efficacité.

• Administrateur de cluster HPC : gère les clusters Slurm/PBS, dans l'espoir d'abaisser le seuil permettant aux chercheurs d'utiliser le cluster via l'interface utilisateur Web, tout en conservant la possibilité de contrôler les priorités des tâches et les quotas de ressources. La compatibilité déterminée avec les planificateurs existants et les coûts de remplacement doivent être confirmés.

• Décideur technique (CTO/VP Eng) : Pour évaluer la sélection de la plateforme MLOps, il est nécessaire de comparer la couverture fonctionnelle et les coûts d'exploitation et de maintenance de Kubeflow/MLflow/Determined. Déterminé a une compétitivité exceptionnelle dans la seule dimension de « l'amélioration de l'efficacité de la formation », mais si l'équipe a besoin d'un lien complet de déploiement et de surveillance du modèle, il faudra peut-être l'associer à d'autres outils.

Ne convient pas à la foule :

• Pour les petites équipes ou les individus dont les besoins peuvent être satisfaits par une seule carte, les coûts de déploiement et de maintenance du cluster de Déterminé peuvent être supérieurs aux avantages. Il est plus léger d'utiliser directement torchrun ou python train.py.
• Pour les équipes qui nécessitent un déploiement complet d'inférence + des tests A/B + des liens de surveillance de modèle, Déterminé n'inclut pas de composants de service d'inférence et doit être associé à des outils tels que KServe/Seldon.
• Des équipes résistantes à une dépendance inévitable aux K8 - bien que le mode Agent RM soit disponible, la plupart des fonctionnalités avancées (Multi-RM, mise à l'échelle automatique) reposent toujours sur les K8.

Résumé et perspectives de l'IA déterminée

Compétences de base : Déterminé AI fournit la solution prête à l'emploi la plus complète de la communauté open source dans le domaine vertical de la « planification distribuée des formations ». Sa combinaison de configuration déclarative YAML + synchronisation automatique des gradients + recherche ASHA + gestion des quotas GPU fait passer la formation multi-machines et multi-cartes de « chaque équipe crée sa propre roue » à « configuration en tant que formation ». Pour les équipes ML gourmandes en ressources GPU (10+ GPU), il peut améliorer considérablement l’utilisation du GPU et l’efficacité des expériences sans modifier le code de formation.

Limites actuelles :

• La courbe d'apprentissage se concentre sur le déploiement de K8 et la compréhension de la configuration YAML. Pour les équipes non conteneurisées, le premier déploiement peut prendre 1 à 2 semaines.
• Il existe une incertitude quant à l'écart fonctionnel entre la version OSS et la version EE - les fonctionnalités d'entreprise telles que l'audit SSO et RBAC sont verrouillées dans la version EE depuis longtemps. Il reste à voir si la version OSS peut maintenir la progression complète des itérations des fonctions de formation de base.
• La taille de la communauté (3,2 000 étoiles) est plus petite que Kubeflow (~ 14 000 étoiles) et MLflow (~ 18 000 étoiles), et les contributions écologiques de tiers et la vitesse de réponse aux problèmes de la communauté peuvent être limitées.

Évaluation des risques d'approvisionnement/d'adoption : il est recommandé à l'équipe de déployer d'abord la version OSS en tant que pilote sur le cluster existant et de sélectionner 1 à 2 tâches de formation typiques (tâches de production non essentielles) pour vérifier la facilité d'utilisation et l'effet de planification de la formation distribuée. Il est recommandé de prêter attention aux trois indicateurs clés suivants pendant la période pilote : (1) Le temps d'attente moyen entre la soumission de la formation et le début de la formation (par rapport au degré d'amélioration de la coordination manuelle) ; (2) Après l'introduction de la recherche d'hyperparamètres, le nombre d'essais et d'heures GPU nécessaires pour trouver les paramètres optimaux ; (3) La charge de travail de modification du code après le passage des chercheurs à la plateforme (moins la couche d'abstraction est efficace). Si la vérification pilote est réussie, évaluez si les fonctionnalités d'entreprise de la version EE sont nécessaires et, ce faisant, confirmez les conditions tarifaires et le chemin de migration des données de la version EE avec HPE.

Outils associés : , replicate

Informations de version

• Déterminé 0,32,0 ：Il n’y a pas encore de date officielle précise. （2026-05）
• Déterminé 0,28,0 ：Il n’y a pas encore de date officielle précise. （2025-12）