Trial API

Model Definition Interfaces

To create a Trial API model definition, we should implement the Trial interface provided by Determined. This interface returns information about the machine learning task the user wants to perform, like the model architecture to use or the validation metrics that should be computed.

Determined provides versions of the Trial interface for each of the application frameworks it supports:

Create an Experiment via det.experimental.create()

A user can submit an experiment from Python by executing the determined.experimental.create() function:

class MyTrial(...):

det.experimental.create(trial_def=MyTrial, context_dir=".")

In addition to a trial class definition, the create() API requires a context directory (context_dir). The context directory specifies the root directory of the code containing the trial implementation – for a majority of users this is the current working directory (.). The create() API also accepts two boolean keyword arguments:

local (bool):

local=False will submit the experiment to a Determined cluster. local=True will execute the the training loop in your local Python environment (although currently, local training is not implemented, so you must also set test=True). Defaults to False.

test (bool):

test=True will execute a minimal training loop rather than a full experiment. This can be useful for porting or debugging a model because many common errors will surface quickly. Defaults to False.

Create an Experiment via the CLI

A user can submit an experiment via the det experiment create CLI command:

$ det experiment create <YAML config file> <context directory>

The context directory of Python files that contain the Trial API implementation should include an accompanying entrypoint that specifies from where to load a trial class. The entrypoint specification is expected to take the form:

<module>:<object reference>

<module> specifies the module containing the trial class within the model definition, relative to the root. It may be an empty string if the model definition is a Python package and the trial class is exposed in the top-level file.

<object reference> specifies the naming of the trial class within the module. It may be a nested object delimited by dots.


  1. :MNistTrial expects an MNistTrial class that is exposed in a file at the top level of the model definition.

  2. model_def:CIFAR10Trial expects a CIFAR10Trial class that is defined in a file at the top level of the model definition.

  3. determined_lib.trial:trial_classes.NestedTrial expects a NestedTrial class that is an attribute of trial_classes, where trial_classes is defined in a file determined_lib/

Note that this follows the Entry points specification defined in the Python Packaging User Guide with a single difference: the directory name of the model definition is prefixed to <module>, or used as the module if <module> is empty.

Since project directories might include large artifacts that should not be packaged as part of the model definition (e.g., data sets or compiled binaries), users can optionally include a .detignore file at the top level that specifies file paths to be omitted from the model definition. The .detignore file uses the same syntax as .gitignore. Note that byte-compiled Python files (e.g., .pyc files or __pycache__ directories) are always ignored.