Determined AI is an open source deep learning training platform that provides distributed training, automatic super-parameter search, GPU cluster management and experiment tracking capabilities, and supports PyTorch and TensorFlow.

DeterminedAI

Determined AI’s core parameters and statistics

Determined AI is positioned as an "operating system for deep learning training" and solves the most difficult distributed orchestration problem in ML engineering: when the training task expands from a single card to multiple nodes, code modification costs, resource competition, and experimental chaos have become an inevitable pain point for almost every team. Determined encapsulates these issues through a unified scheduling layer, allowing researchers to only focus on the model itself.

Projects	Public Information
Official positioning	Open source deep learning training platform
Core capabilities	Distributed training, hyperparameter search, experiment tracking GPU cluster management
Supported frameworks	PyTorch, TensorFlow, Keras (including KerasTuner)
Deployment method	Self-hosted: Kubernetes, local Agent cluster Slurm/PBS, AWS/GCP
Access portal	Web UI, CLI (det), Python SDK, REST API
Open Source License	Apache 2.0
Code repository	GitHub determined-ai/determined (3.2k Stars, 372 Forks, 96 contributors)
Latest version	v0.38.1 (2025-03-20)
Company Ownership	HPE (Hewlett Packard Enterprise) – 2021 Acquisitions
Technology stack	Go (44.6%) / Python (27.9%) / TypeScript (24.4%)

A brief comment in one sentence: It is not another MLOps dashboard, but a scheduling engine that changes "multi-machine and multi-card training" from manual configuration to declarative submission. The core value is to allow the team to complete distributed training with the mental burden of writing single-machine code.

HPE Acquisition Background: After the acquisition, Determined obtained enterprise-level support resources. The EE (Enterprise Edition) version began to require a license key. The OSS version and the EE version have functional differences in enterprise features such as SSO and RBAC auditing. The community needs to pay attention to whether the OSS version continues to receive core training feature updates of the same quality as the EE version.

Users and market recognition of Determined AI

GitHub community activity: The warehouse has 3.2k Stars, 372 Forks, a total of 121 Releases (as of 2026-07), and 96 contributors, indicating that the project has stable attention in the field of open source MLOps but has not yet entered the super popular ranks (similar projects such as MLflow have higher Stars).

Enterprise Adoption: HPE integrates Determined into its AI infrastructure solutions for HPC customers in finance, manufacturing, scientific research and other industries. Publicly available adoption cases are dominated by academic institutions and mid-sized ML teams, while the number of large-scale enterprise deployments is undisclosed.

Industry benchmarking: Compared with Kubeflow (complete K8s native MLOps) and MLflow (biased towards experimental tracking + model registration), the core difference of Determined lies in "scheduling and acceleration of the training task itself" rather than full-link orchestration. In the subfield of distributed training, it complements rather than directly competes with Horovod (distributed communication layer only) and Weights & Biases (experimental tracking only).

Comparative Dimensions	Determined AI	Kubeflow	MLflow	Horovod
Positioning	Training scheduling platform	Full-link MLOps	Experiment tracking + model registration	Distributed training communication library
Distributed training	Automatic orchestration	Manual configuration required	Not involved	Provide communication primitives
Hyperparameter search	Built-in (Grid/Bayesian/ASHA)	Need to integrate Katib	Not built-in	Not involved
Cluster scheduling	Built-in queue + quota	K8s native scheduling	Not involved	Not involved
Difficulty to get started	Medium (requires K8s basics)	High	Low	Medium

Cost Advantages of Determined AI

C-side/individual

The open source version is completely free (Apache 2.0). Individuals can install the CLI through pip install determined and deploy a local cluster on a single machine or their own GPU. There are zero licensing fees, but you have to bear the operational costs of maintaining your own PostgreSQL + storage backend.

Developer/Team

There is no software license fee for the open source version, and teams can choose to deploy it as needed:

• Local Agent Mode: Deploy Master + Agent on bare metal or VM, suitable for teams with existing GPU servers, with low operation and maintenance complexity.
• Kubernetes mode: Deployed through Helm Chart, suitable for teams that already have K8s infrastructure, but require K8s management capabilities.
• Cloud deployment: det deploy aws/gcp up One-click deployment, pay according to actual use of cloud resources, no additional license fees.

Hidden costs are mainly reflected in operation and maintenance manpower: PostgreSQL database management, storage (S3/GCS/shared file system) configuration, network and security group policies, version upgrades and migrations, etc.

Enterprise/Privatization

HPE offers Enterprise Edition, which includes:

• SSO/SAML integration
• RBAC fine-grained permission audit
• Commercial SLA and technical support
• Pre-integrated validation with HPE hardware such as ProLiant servers Nimble storage

Enterprise Edition pricing is not disclosed, please obtain a quote through HPE Sales. Key terms to verify before purchasing: whether the license is billed based on the number of nodes/GPUs or users, whether it includes production bounded SLA response time, upgrade path, and data migration support scope.

Cost Hierarchy	Cost Components	Typical Annual Costs (Derivation)
Individual/Small Team (OSS)	0 license fee + cloud host/GPU fee	$0 + on-demand cloud resources
Medium-sized team (OSS + self-operation and maintenance)	0 license fee + operation and maintenance manpower (about 0.5~1 person-month/year)	$5K~$15K (operation and maintenance conversion)
Enterprise (HPE EE)	License fee + support contract + hardware	Business confirmation required

Main functions of Determined AI

• Zero-modification distributed training: Users only need to use the determined.pytorch.PyTorchTrial or determined.keras.KerasTrial base class in the training script, and the platform automatically handles gradient synchronization (All-Reduce), data sharding and node fault tolerance. There is no need to manually write torch.distributed.launch or tf.distribute.Strategy, which reduces the entry barrier for distributed training.

  • Expert View: The hidden benefit of this abstraction layer is that the team can directly transition from single-card prototype to multi-card production without having to embed distributed logic in the code. To subsequently increase the number of GPUs, you only need to change slots_per_trial in the YAML configuration, without changing the training code.

• Adaptive Hyperparameter Search (ASHA): Based on the Asynchronous Successive Halving Algorithm, low-potential trials are eliminated first when resources are limited, and more computing power is allocated to high-potential parameter combinations. Supports Early Stopping, grid search and Bayesian search, and can dynamically adjust the search space during the search process.

  • Expert View: The collaboration between ASHA and the platform scheduler is the core difference of Determined - the search algorithm can not only determine "what is the next set of parameters", but can also control "which trials can be preempted" through the platform scheduler, automatically downgrading low-priority search trials when the cluster is full, to avoid hyperparameter searches blocking formal training tasks.

• GPU quota and queue scheduling: Supports dividing GPU quota by resource pool (Resource Pool). After the user submits the task through det experiment create, the platform automatically queues, schedules, and allocates slots. Supports Priority Scheduler and Fair Scheduler to prevent a single user from filling up the cluster.

  • Expert View: The combination of scheduler + quota solves the typical team dilemma of "GPU idling and contention coexist". Researchers no longer need to manually negotiate who will use the card when, and the platform guarantees that submitted tasks will eventually be scheduled—which can significantly reduce coordination costs in a team of 10+ people.

• Experiment tracking and automatic snapshots: Automatically record indicators (time series such as loss/accuracy), hyperparameter configuration, complete code snapshots (Git Commit + untracked files), and model weight checkpoints for each training. The Web UI supports comparison and visualization of multiple experimental indicators, and Checkpoint can resume or continue training with one click.

  • Expert View: Automatic interception of code snapshots is more reliable than manual recording - even if the researcher forgets to commit, the platform will automatically archive the source code when submitting. This is crucial for experimental reproducibility, especially when multiple researchers share a cluster. "Which version of the code this model was run with" is no longer a mystery.

• Notebook and interactive tasks: Start Jupyter Notebook, TensorBoard or Shell on the cluster GPU node, and the calculations are performed directly on the GPU node. The data in the notebook and the training tasks share the same storage layer (shared file system or object storage), which facilitates direct submission of training tasks after data preprocessing.

  • Expert View: Notebook and training tasks share the GPU pool, which means that the same card cannot run notebook and training at the same time. It is recommended to limit notebooks to low-priority resource pools or separate small GPU pools to prevent interactive tasks from occupying production training resources.

• DeepSpeed ​​integration: Built-in DeepSpeed ​​support since version 0.17.0, ZeRO optimization (Stage 1/2/3) can be enabled through YAML configuration to reduce graphics memory usage in very large model training scenarios. Together with Determined's automatic gradient synchronization, ZeRO's communication mode and platform scheduler work together.

• Core API (lower-level interface): For advanced users who do not need the Trial base class, Determined provides the Core API, allowing users to integrate platform functions in the least intrusive way - only use det.core.init() to obtain the Context to record indicators and save Checkpoints, without forcing modification of the training cycle structure. This is especially useful when integrating with third-party training libraries like Hugging Face Trainer.

Model and version evolution of Determined AI

Determined adopts the "OSS + EE" dual-track release strategy: the OSS version follows semantic versioning, and the EE version appends the -ee suffix after the OSS version number.

Mainline release

Version number	Release date	Core changes
v0.32.0	2026-05 (no official precise date yet)	Latest release version, including performance optimization and bug fixes
v0.38.1	2025-03-20	The latest stable version, including environment image updates and dependency repairs
v0.38.0	2024-11-23	Remove Searcher Context (architecture simplification), task configuration policy (Config Policies) GA, Global Config Policies UI
v0.37.0	2024-09-30	New Run Object (Run Centric API), Workload Alerting (Workload Alerting), Config Policies initial support
v0.36.0	2024-08-24	Flat Runs view GA, RBAC Webhook, Data Lineage initial support
v0.35.0	2024-08-09	Flat Runs comparison view, metadata filter search, K8s Pod to Job submission, Framework Splitting (Framework Splitting)
v0.34.0	2024-06-29	Notebook Token certification K8s Node Selector/Affinity supports Pause/Resume Run
v0.33.0	2024-05-30	WebUI template management Flat Runs sorting/filtering, heat map (Heatmap), Helm password complexity check
v0.32.0	2024-04 (no official precise date yet)	Template CRUD API, K8s multi-RM support, experimental batch operation

Version management observation

• Pace: Maintain an iteration frequency of about one minor version per month in 2024, and the pace will slow down after entering 2025 (v0.38.1 will be released in 2025-03), which may reflect the improvement of product maturity or the adjustment of team resources.
• Architecture Evolution: The core trend from v0.35 to v0.38 is the migration from "Experiment-Trial centralization" to "Run centralization" (Flat Runs), and the introduction of Config Policies to enhance multi-tenant governance capabilities.
• Enterprise Edition Differences: The EE version is ahead of OSS in enterprise features such as SSO improvements (v0.38.0+), license key verification, RBAC audit logs, etc. OSS users need to pay attention to whether these functions will be gradually transferred to the community version, or whether they will remain exclusive to EE for a long time.

Technical advantages of Determined AI

Declarative training configuration: Users define training hyperparameters, resource requirements (slots_per_trial), search algorithms and scheduling strategies through YAML, and the platform generates trials and schedules execution accordingly. The core advantage of this declarative abstraction is that researchers describe "what to do" rather than "how to do it", and the platform automatically decides "how many GPUs to run on which machine" based on the cluster load in the background.

Automatic Gradient Synchronization (All-Reduce Aggregation): Determined's Harness component automatically injects gradient synchronization logic (based on NCCL or Gloo) on top of user training code, eliminating the need for users to write distributed communication code. Multiple trials independently forward/reverse on their respective assigned slots. Harness automatically executes All-Reduce aggregation gradient after each backward()to ensure that the model parameters of each node are consistent. This mechanism allows expansion from a single card to multiple cards by simply modifyingslots_per_trial` in YAML, without touching the training script.

Scheduling collaboration for ASHA search: Traditional hyperparameter search tools run independently of the scheduler, and the searched trials still need to be queued for resources. Determined deeply integrates the searcher and the scheduler: after the searcher determines the next set of parameters, the scheduler decides whether to start the trial immediately and whether to preempt low-priority trials based on the current cluster load. This co-design allows hyperparameter search to not block production training tasks when the cluster is full - search trials are marked as preemptible, automatically releasing the GPU when a higher priority task is submitted.

Dual-track scheduling (Agent RM + K8s RM): Determined supports two resource management modes - Agent RM (self-managed Agent cluster) and K8s RM (Kubernetes native scheduling). Agent RM is suitable for bare metal/HPC environments, does not require K8s dependencies, and is more lightweight to deploy; K8s RM is suitable for teams that already have K8s infrastructure, and can take advantage of K8s' automatic expansion and contraction, Namespace isolation and other capabilities. Both can be enabled at the same time (Multi-RM), allowing the same Master to manage heterogeneous clusters.

Checkpoint's storage abstraction: Checkpoint supports storage to the shared file system S3/GCS object storage, or HDFS. The platform automatically maintains the checkpoint life cycle (GC policy) and can configure data migration across storage layers. This abstraction decouples the storage and computation of the training cluster - training nodes can be stateless instances, and checkpoints are persisted to external object storage to facilitate quick recovery after an experiment fails.

Performance Profiling built-in: The Web UI has a built-in training performance analysis tool that can view indicators such as GPU utilization, data loading throughput, and communication ratio to help locate training bottlenecks (such as whether data loading is a bottleneck or communication is a bottleneck). This function does not require additional integration of Prometheus/Grafana, reducing the complexity of the tool chain for performance tuning.

The choice of Go as the main language in the code warehouse (44.6%) shows that the Master component has high requirements for concurrency performance - the Master needs to manage the heartbeats, scheduling decisions and API requests of hundreds of Agents at the same time. Go's Goroutine model is more efficient than Python in this scenario. Python (27.9%) is used for Harness (training runtime) and SDK, and TypeScript (24.4%) is used for web UI.

How to use Determined AI

Install CLI and start the cluster

# Install CLI
pip install determined

# Local cluster (quick experience on a single machine)
det deploy local cluster-up

#AWSDeployment
det deploy aws up

# GCP deployment
det deploy gcp up

Submit training task

Training script adaptation (PyTorch example):

from determined.pytorch import PyTorchTrial, DataLoader, PyTorchTrialContext

class MyTrial(PyTorchTrial):
    def __init__(self, context: PyTorchTrialContext):
        self.context = context
        self.model = self.context.wrap_model(nn.Sequential(...))

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

YAML configuration file (experiment.yaml):

name: my_experiment
entrypoint:train.py
hyperparameters:
  learning_rate:
    type: double
    minval: 0.0001
    maxval: 1.0
searcher:
  name: adaptive_asha
  metric: loss
  smaller_is_better: true
  max_trials: 100
resources:
  slots_per_trial: 8

Submit command:

det experiment create experiment.yaml .

Deployment options comparison

Deployment method	Applicable scenarios	Prerequisites	Maintenance complexity
Local cluster (det deploy local)	Personal development/single machine with multiple cards	Docker	Low
AWS det deploy aws	Quick start on the cloud	AWS account + quota	Medium
GCP det deploy gcp	Quick start on the cloud	GCP account + quota	Medium
Kubernetes Helm Chart	Existing K8s cluster	K8s cluster + Helm 3	Medium to high
Agent Manual Deployment	Bare Metal/HPC	PostgreSQL + Shared Storage	High
Slurm/PBS Integration	HPC Cluster	Slurm/PBS Contextual	High

Quick verification path: Individual developers recommend pip install determined && det deploy local cluster-up, which can pull up a single-node cluster containing Master + Agent locally within 5 minutes and run the official MNIST sample verification core process.

Product Pricing for Determined AI

Determined AI adopts a dual-track pricing model of "open source core + enterprise version":

• Open Source Version (OSS): Apache 2.0 license, fully functional including distributed training, super parameter search, experiment tracking and scheduling. There are no usage restrictions or GPU caps. Suitable for individuals, academic teams, and medium-sized teams with self-operation and maintenance capabilities.
• Enterprise Edition (HPE Enterprise Edition): Based on OSS, it adds SSO/SAML integrated RBAC fine-grained permission auditing and commercial SLA support for HPE hardware pre-integrated verification. Prices are obtained through HPE Sales, on an annual subscription basis, and the specific billing unit (node/GPU/user) is not disclosed.
• Cloud Hosted Edition: HPE does not offer SaaS hosting, all deployments are self-hosted. If you want an operation-free experience, you can quickly launch it on the cloud through det deploy aws/gcp, but the management and monitoring are still the responsibility of the team.

Version	License	Price	Applicable Scale
OSS	Apache 2.0	Free	Individuals to mid-sized teams (<100 GPUs)
EE	Commercial license	Business confirmation required	Medium and large enterprises (100+ GPUs)

Before purchasing the Enterprise Edition, you need to confirm with HPE: whether it supports tiered pricing based on the number of GPUs, and whether it includes specific terms for production-enabled 24/7 support, upgrades, and data migration.

Determined AI application scenarios

• Multi-GPU cluster training management: When a team shares 10~100 GPUs, Determined's queue scheduling effectively reduces idle waste—researchers no longer need to manually coordinate who uses the card when. Superparameter search automatically scans the parameter space, eliminating the need to manually modify parameters and rerun. Key points of verification: When high-priority tasks are frequently submitted in queue scheduling, whether low-priority search trials can be correctly preempted and restored.

• Standardized Experiment Pipeline: Code snapshots, hyperparameters, indicators and checkpoints are automatically recorded for each training. When new researchers take over the project, they can directly view historical experiments on the Web UI, reproduce them with one click, or continue training from the specified checkpoint. Key points to verify: Whether the code snapshot completely contains untracked local modified files and whether the Checkpoint GC strategy may lead to premature deletion.

• Very Large Model Training (DeepSpeed ​​Integration): For model training with tens of billions of parameters, ZeRO Stage 2/3 optimizes the use of video memory and cooperates with Determined's automatic multi-node scheduling to lower the infrastructure threshold for large model training. Verification focus: Compatibility of DeepSpeed ​​version and Determined version Communication efficiency under ZeRO Stage 3.

• Hybrid cloud/heterogeneous cluster training: Unify the management of local bare metal clusters and K8s clusters on the cloud through Multi-RM, and training tasks are automatically scheduled to available nodes according to resource requirements. Verification focus: The impact of cross-cluster checkpoint synchronization mechanism and network delay on distributed training.

• HPC/Academic Research Computing: Deploy Determined on the Slurm/PBS cluster to provide scientific researchers with a Web UI to submit training tasks, replacing the traditional SSH method of manually submitting jobs. Built-in experiment tracking reduces non-reproducible problems caused by "forgetting to record parameters". Verification focus: The integrated version of Slurm supports Job Array and coexists with existing HPC scheduling strategies.

Applicable groups of Determined AI

• Deep Learning Researcher/Algorithm Engineer: Need to conduct frequent distributed training experiments, hoping to reduce the workload of distributed code adaptation, automatically record experimental parameters and results, and compare multiple sets of experimental indicators with one click. The value is most obvious among medium-sized teams with 5~50 GPUs.

• ML Infrastructure/Platform Engineer: Responsible for building training infrastructure for the team. We hope to provide a self-service platform of "submit and train" and reduce the daily support work of "helping researchers configure environments, adjust drivers, and package packages." It is necessary to evaluate the balance between K8s/PostgreSQL operation and maintenance costs and efficiency improvements.

• HPC Cluster Administrator: Manages Slurm/PBS clusters, hoping to lower the threshold for researchers to use the cluster through the Web UI, while retaining the ability to control job priorities and resource quotas. Determined compatibility with existing schedulers and replacement costs need to be confirmed.

• Technical Decision Maker (CTO/VP Eng): To evaluate MLOps platform selection, it is necessary to compare the functional coverage and operation and maintenance costs of Kubeflow/MLflow/Determined. Determined has outstanding competitiveness in the single dimension of "training efficiency improvement", but if the team needs a complete model deployment and monitoring link, it may need to be paired with other tools.

Not suitable for the crowd:

• For small teams or individuals whose needs can be met by a single card, the cluster deployment and maintenance costs of Determined may be greater than the benefits. It is more lightweight to directly use torchrun or python train.py.
• For teams that require complete inference deployment + A/B testing + model monitoring links, Determined does not include inference service components and needs to be paired with tools such as KServe/Seldon.
• Teams resistant to inevitable dependence on K8s - although Agent RM mode is available, most advanced features (Multi-RM, auto-scaling) still rely on K8s.

Summary and Outlook of Determined AI

Core Competencies: Determined AI provides the most complete out-of-the-box solution in the open source community in the vertical field of "distributed training scheduling". Its combination of declarative YAML configuration + automatic gradient synchronization + ASHA search + GPU quota management changes multi-machine and multi-card training from "each team makes its own wheel" to "configuration-as-training". For GPU resource-intensive (10+ GPU) ML teams, it can significantly improve GPU utilization and experiment efficiency without changing the training code.

Current Limitations:

• The learning curve focuses on K8s deployment and YAML configuration understanding. For non-containerized teams, the first deployment may take 1 to 2 weeks.
• There is uncertainty about the functional gap between the OSS version and the EE version - enterprise features such as SSO and RBAC auditing have been locked in the EE version for a long time. It remains to be seen whether the OSS version can maintain the complete iteration progress of core training functions.
• The community size (3.2k Stars) is smaller than Kubeflow (~14k Stars) and MLflow (~18k Stars), and third-party ecological contributions and response speed to community issues may be limited.

Procurement/Adoption Risk Assessment: It is recommended that the team first deploy the OSS version as a pilot on the existing cluster, and select 1~2 typical training tasks (non-core production tasks) to verify the ease of use and scheduling effect of distributed training. It is recommended to pay attention to the following three key indicators during the pilot period: (1) The average waiting time from the submission of training to the start of training (compared with the degree of improvement of manual coordination); (2) After the introduction of hyperparameter search, the number of trials and GPU hours required to find the optimal parameters; (3) The workload of code modification after researchers switch to the platform (the less, the more effective the abstraction layer is). If the pilot verification is passed, then evaluate whether the enterprise features of the EE version are needed, and in the process confirm the price terms and data migration path of the EE version with HPE.

Related tools: , replicate

Version Info

• Determined 0.32.0 ：There is no official precise date yet. （2026-05）
• Determined 0.28.0 ：There is no official precise date yet. （2025-12）