Neural Network Intelligence

Overview

NNI (Neural Network Intelligence) is a toolkit to help users design and tune machine learning models (e.g., hyperparameters), neural network architectures, or complex system’s parameters, in an efficient and automatic way. NNI has several appealing properties: ease-of-use, scalability, flexibility, and efficiency.

  • Ease-of-use: NNI can be easily installed through python pip. Only several lines need to be added to your code in order to use NNI’s power. You can use both the commandline tool and WebUI to work with your experiments.

  • Scalability: Tuning hyperparameters or the neural architecture often demands a large number of computational resources, while NNI is designed to fully leverage different computation resources, such as remote machines, training platforms (e.g., OpenPAI, Kubernetes). Hundreds of trials could run in parallel by depending on the capacity of your configured training platforms.

  • Flexibility: Besides rich built-in algorithms, NNI allows users to customize various hyperparameter tuning algorithms, neural architecture search algorithms, early stopping algorithms, etc. Users can also extend NNI with more training platforms, such as virtual machines, kubernetes service on the cloud. Moreover, NNI can connect to external environments to tune special applications/models on them.

  • Efficiency: We are intensively working on more efficient model tuning on both the system and algorithm level. For example, we leverage early feedback to speedup the tuning procedure.

The figure below shows high-level architecture of NNI.

drawing

Key Concepts

  • Experiment: One task of, for example, finding out the best hyperparameters of a model, finding out the best neural network architecture, etc. It consists of trials and AutoML algorithms.

  • Search Space: The feasible region for tuning the model. For example, the value range of each hyperparameter.

  • Configuration: An instance from the search space, that is, each hyperparameter has a specific value.

  • Trial: An individual attempt at applying a new configuration (e.g., a set of hyperparameter values, a specific neural architecture, etc.). Trial code should be able to run with the provided configuration.

  • Tuner: An AutoML algorithm, which generates a new configuration for the next try. A new trial will run with this configuration.

  • Assessor: Analyze a trial’s intermediate results (e.g., periodically evaluated accuracy on test dataset) to tell whether this trial can be early stopped or not.

  • Training Platform: Where trials are executed. Depending on your experiment’s configuration, it could be your local machine, or remote servers, or large-scale training platform (e.g., OpenPAI, Kubernetes).

Basically, an experiment runs as follows: Tuner receives search space and generates configurations. These configurations will be submitted to training platforms, such as the local machine, remote machines, or training clusters. Their performances are reported back to Tuner. Then, new configurations are generated and submitted.

For each experiment, the user only needs to define a search space and update a few lines of code, and then leverage NNI built-in Tuner/Assessor and training platforms to search the best hyperparameters and/or neural architecture. There are basically 3 steps:

drawing

For more details about how to run an experiment, please refer to Get Started.

Core Features

NNI provides a key capacity to run multiple instances in parallel to find the best combinations of parameters. This feature can be used in various domains, like finding the best hyperparameters for a deep learning model or finding the best configuration for database and other complex systems with real data.

NNI also provides algorithm toolkits for machine learning and deep learning, especially neural architecture search (NAS) algorithms, model compression algorithms, and feature engineering algorithms.

Hyperparameter Tuning

This is a core and basic feature of NNI, we provide many popular automatic tuning algorithms (i.e., tuner) and early stop algorithms (i.e., assessor). You can follow Quick Start to tune your model (or system). Basically, there are the above three steps and then starting an NNI experiment.

General NAS Framework

This NAS framework is for users to easily specify candidate neural architectures, for example, one can specify multiple candidate operations (e.g., separable conv, dilated conv) for a single layer, and specify possible skip connections. NNI will find the best candidate automatically. On the other hand, the NAS framework provides a simple interface for another type of user (e.g., NAS algorithm researchers) to implement new NAS algorithms. A detailed description of NAS and its usage can be found here.

NNI has support for many one-shot NAS algorithms such as ENAS and DARTS through NNI trial SDK. To use these algorithms you do not have to start an NNI experiment. Instead, import an algorithm in your trial code and simply run your trial code. If you want to tune the hyperparameters in the algorithms or want to run multiple instances, you can choose a tuner and start an NNI experiment.

Other than one-shot NAS, NAS can also run in a classic mode where each candidate architecture runs as an independent trial job. In this mode, similar to hyperparameter tuning, users have to start an NNI experiment and choose a tuner for NAS.

Model Compression

NNI provides an easy-to-use model compression framework to compress deep neural networks, the compressed networks typically have much smaller model size and much faster inference speed without losing performance significantlly. Model compression on NNI includes pruning algorithms and quantization algorithms. NNI provides many pruning and quantization algorithms through NNI trial SDK. Users can directly use them in their trial code and run the trial code without starting an NNI experiment. Users can also use NNI model compression framework to customize their own pruning and quantization algorithms.

A detailed description of model compression and its usage can be found here.

Automatic Feature Engineering

Automatic feature engineering is for users to find the best features for their tasks. A detailed description of automatic feature engineering and its usage can be found here. It is supported through NNI trial SDK, which means you do not have to create an NNI experiment. Instead, simply import a built-in auto-feature-engineering algorithm in your trial code and directly run your trial code.

The auto-feature-engineering algorithms usually have a bunch of hyperparameters themselves. If you want to automatically tune those hyperparameters, you can leverage hyperparameter tuning of NNI, that is, choose a tuning algorithm (i.e., tuner) and start an NNI experiment for it.

Installation

Currently we support installation on Linux, Mac and Windows. We also allow you to use docker.

Install on Linux & Mac

Installation

Installation on Linux and macOS follow the same instructions, given below.

Install NNI through pip

Prerequisite: python 64-bit >= 3.6

python3 -m pip install --upgrade nni
Install NNI through source code

If you are interested in special or the latest code versions, you can install NNI through source code.

Prerequisites: python 64-bit >=3.6, git

git clone -b v2.2 https://github.com/Microsoft/nni.git
cd nni
python3 -m pip install --upgrade pip setuptools
python3 setup.py develop
Build wheel package from NNI source code

The previous section shows how to install NNI in development mode. If you want to perform a persist install instead, we recommend to build your own wheel package and install from wheel.

git clone -b v2.2 https://github.com/Microsoft/nni.git
cd nni
export NNI_RELEASE=2.0
python3 -m pip install --upgrade pip setuptools wheel
python3 setup.py clean --all
python3 setup.py build_ts
python3 setup.py bdist_wheel -p manylinux1_x86_64
python3 -m pip install dist/nni-2.0-py3-none-manylinux1_x86_64.whl
Use NNI in a docker image

You can also install NNI in a docker image. Please follow the instructions here to build an NNI docker image. The NNI docker image can also be retrieved from Docker Hub through the command docker pull msranni/nni:latest.

Verify installation

  • Download the examples via cloning the source code.

    git clone -b v2.2 https://github.com/Microsoft/nni.git
    
  • Run the MNIST example.

    nnictl create --config nni/examples/trials/mnist-pytorch/config.yml
    
  • Wait for the message INFO: Successfully started experiment! in the command line. This message indicates that your experiment has been successfully started. You can explore the experiment using the Web UI url.

INFO: Starting restful server...
INFO: Successfully started Restful server!
INFO: Setting local config...
INFO: Successfully set local config!
INFO: Starting experiment...
INFO: Successfully started experiment!
-----------------------------------------------------------------------
The experiment id is egchD4qy
The Web UI urls are: http://223.255.255.1:8080   http://127.0.0.1:8080
-----------------------------------------------------------------------

You can use these commands to get more information about the experiment
-----------------------------------------------------------------------
         commands                       description
1. nnictl experiment show        show the information of experiments
2. nnictl trial ls               list all of trial jobs
3. nnictl top                    monitor the status of running experiments
4. nnictl log stderr             show stderr log content
5. nnictl log stdout             show stdout log content
6. nnictl stop                   stop an experiment
7. nnictl trial kill             kill a trial job by id
8. nnictl --help                 get help information about nnictl
-----------------------------------------------------------------------
  • Open the Web UI url in your browser, you can view detailed information about the experiment and all the submitted trial jobs as shown below. Here are more Web UI pages.

overview detail

System requirements

Due to potential programming changes, the minimum system requirements of NNI may change over time.

Linux

Recommended

Minimum

Operating System

Ubuntu 16.04 or above

CPU

Intel® Core™ i5 or AMD Phenom™ II X3 or better

Intel® Core™ i3 or AMD Phenom™ X3 8650

GPU

NVIDIA® GeForce® GTX 660 or better

NVIDIA® GeForce® GTX 460

Memory

6 GB RAM

4 GB RAM

Storage

30 GB available hare drive space

Internet

Boardband internet connection

Resolution

1024 x 768 minimum display resolution

macOS

Recommended

Minimum

Operating System

macOS 10.14.1 or above

CPU

Intel® Core™ i7-4770 or better

Intel® Core™ i5-760 or better

GPU

AMD Radeon™ R9 M395X or better

NVIDIA® GeForce® GT 750M or AMD Radeon™ R9 M290 or better

Memory

8 GB RAM

4 GB RAM

Storage

70GB available space SSD

70GB available space 7200 RPM HDD

Internet

Boardband internet connection

Resolution

1024 x 768 minimum display resolution

Install on Windows

Prerequires

  • Python 3.6 (or above) 64-bit. Anaconda or Miniconda is highly recommended to manage multiple Python environments on Windows.

  • If it’s a newly installed Python environment, it needs to install Microsoft C++ Build Tools to support build NNI dependencies like scikit-learn.

    pip install cython wheel
    
  • git for verifying installation.

Install NNI

In most cases, you can install and upgrade NNI from pip package. It’s easy and fast.

If you are interested in special or the latest code versions, you can install NNI through source code.

If you want to contribute to NNI, refer to setup development environment.

  • From pip package

    python -m pip install --upgrade nni
    
  • From source code

    git clone -b v2.2 https://github.com/Microsoft/nni.git
    cd nni
    python setup.py develop
    

Verify installation

  • Clone examples within source code.

    git clone -b v2.2 https://github.com/Microsoft/nni.git
    
  • Run the MNIST example.

       nnictl create --config nni\examples\trials\mnist-pytorch\config_windows.yml
    
    Note:  If you are familiar with other frameworks, you can choose corresponding example under ``examples\trials``. It needs to change trial command ``python3`` to ``python`` in each example YAML, since default installation has ``python.exe``\ , not ``python3.exe`` executable.
    
  • Wait for the message INFO: Successfully started experiment! in the command line. This message indicates that your experiment has been successfully started. You can explore the experiment using the Web UI url.

INFO: Starting restful server...
INFO: Successfully started Restful server!
INFO: Setting local config...
INFO: Successfully set local config!
INFO: Starting experiment...
INFO: Successfully started experiment!
-----------------------------------------------------------------------
The experiment id is egchD4qy
The Web UI urls are: http://223.255.255.1:8080   http://127.0.0.1:8080
-----------------------------------------------------------------------

You can use these commands to get more information about the experiment
-----------------------------------------------------------------------
         commands                       description
1. nnictl experiment show        show the information of experiments
2. nnictl trial ls               list all of trial jobs
3. nnictl top                    monitor the status of running experiments
4. nnictl log stderr             show stderr log content
5. nnictl log stdout             show stdout log content
6. nnictl stop                   stop an experiment
7. nnictl trial kill             kill a trial job by id
8. nnictl --help                 get help information about nnictl
-----------------------------------------------------------------------
  • Open the Web UI url in your browser, you can view detailed information about the experiment and all the submitted trial jobs as shown below. Here are more Web UI pages.

overview detail

System requirements

Below are the minimum system requirements for NNI on Windows, Windows 10.1809 is well tested and recommend. Due to potential programming changes, the minimum system requirements for NNI may change over time.

Recommended

Minimum

Operating System

Windows 10 1809 or above

CPU

Intel® Core™ i5 or AMD Phenom™ II X3 or better

Intel® Core™ i3 or AMD Phenom™ X3 8650

GPU

NVIDIA® GeForce® GTX 660 or better

NVIDIA® GeForce® GTX 460

Memory

6 GB RAM

4 GB RAM

Storage

30 GB available hare drive space

Internet

Boardband internet connection

Resolution

1024 x 768 minimum display resolution

FAQ

simplejson failed when installing NNI

Make sure a C++ 14.0 compiler is installed.

building ‘simplejson._speedups’ extension error: [WinError 3] The system cannot find the path specified

Trial failed with missing DLL in command line or PowerShell

This error is caused by missing LIBIFCOREMD.DLL and LIBMMD.DLL and failure to install SciPy. Using Anaconda or Miniconda with Python(64-bit) can solve it.

ImportError: DLL load failed

Trial failed on webUI

Please check the trial log file stderr for more details.

If there is a stderr file, please check it. Two possible cases are:

  • forgetting to change the trial command python3 to python in each experiment YAML.

  • forgetting to install experiment dependencies such as TensorFlow, Keras and so on.

Fail to use BOHB on Windows

Make sure a C++ 14.0 compiler is installed when trying to run pip install nni[BOHB] to install the dependencies.

Not supported tuner on Windows

SMAC is not supported currently; for the specific reason refer to this GitHub issue.

Use Windows as a remote worker

Refer to Remote Machine mode.

Segmentation fault (core dumped) when installing

Refer to FAQ.

How to Use Docker in NNI

Overview

Docker is a tool to make it easier for users to deploy and run applications based on their own operating system by starting containers. Docker is not a virtual machine, it does not create a virtual operating system, but it allows different applications to use the same OS kernel and isolate different applications by container.

Users can start NNI experiments using Docker. NNI also provides an official Docker image msranni/nni on Docker Hub.

Using Docker in local machine

Step 1: Installation of Docker

Before you start using Docker for NNI experiments, you should install Docker on your local machine. See here.

Step 2: Start a Docker container

If you have installed the Docker package in your local machine, you can start a Docker container instance to run NNI examples. You should notice that because NNI will start a web UI process in a container and continue to listen to a port, you need to specify the port mapping between your host machine and Docker container to give access to web UI outside the container. By visiting the host IP address and port, you can redirect to the web UI process started in Docker container and visit web UI content.

For example, you could start a new Docker container from the following command:

docker run -i -t -p [hostPort]:[containerPort] [image]

-i: Start a Docker in an interactive mode.

-t: Docker assign the container an input terminal.

-p: Port mapping, map host port to a container port.

For more information about Docker commands, please refer to this.

Note:

NNI only supports Ubuntu and MacOS systems in local mode for the moment, please use correct Docker image type. If you want to use gpu in a Docker container, please use nvidia-docker.
Step 3: Run NNI in a Docker container

If you start a Docker image using NNI’s official image msranni/nni, you can directly start NNI experiments by using the nnictl command. Our official image has NNI’s running environment and basic python and deep learning frameworks preinstalled.

If you start your own Docker image, you may need to install the NNI package first; please refer to NNI installation.

If you want to run NNI’s official examples, you may need to clone the NNI repo in GitHub using

git clone https://github.com/Microsoft/nni.git

then you can enter nni/examples/trials to start an experiment.

After you prepare NNI’s environment, you can start a new experiment using the nnictl command. See here.

Using Docker on a remote platform

NNI supports starting experiments in remoteTrainingService, and running trial jobs on remote machines. As Docker can start an independent Ubuntu system as an SSH server, a Docker container can be used as the remote machine in NNI’s remote mode.

Step 1: Setting a Docker environment

You should install the Docker software on your remote machine first, please refer to this.

To make sure your Docker container can be connected by NNI experiments, you should build your own Docker image to set an SSH server or use images with an SSH configuration. If you want to use a Docker container as an SSH server, you should configure the SSH password login or private key login; please refer to this.

Note:

NNI's official image msranni/nni does not support SSH servers for the time being; you should build your own Docker image with an SSH configuration or use other images as a remote server.
Step 2: Start a Docker container on a remote machine

An SSH server needs a port; you need to expose Docker’s SSH port to NNI as the connection port. For example, if you set your container’s SSH port as A, you should map the container’s port A to your remote host machine’s other port B, NNI will connect port B as an SSH port, and your host machine will map the connection from port B to port A then NNI could connect to your Docker container.

For example, you could start your Docker container using the following commands:

docker run -dit -p [hostPort]:[containerPort] [image]

The containerPort is the SSH port used in your Docker container and the hostPort is your host machine’s port exposed to NNI. You can set your NNI’s config file to connect to hostPort and the connection will be transmitted to your Docker container. For more information about Docker commands, please refer to this.

Note:

If you use your own Docker image as a remote server, please make sure that this image has a basic python environment and an NNI SDK runtime environment. If you want to use a GPU in a Docker container, please use nvidia-docker.
Step 3: Run NNI experiments

You can set your config file as a remote platform and set the machineList configuration to connect to your Docker SSH server; refer to this. Note that you should set the correct port, username, and passWd or sshKeyPath of your host machine.

port: The host machine’s port, mapping to Docker’s SSH port.

username: The username of the Docker container.

passWd: The password of the Docker container.

sshKeyPath: The path of the private key of the Docker container.

After the configuration of the config file, you could start an experiment, refer to this.

QuickStart

Installation

We currently support Linux, macOS, and Windows. Ubuntu 16.04 or higher, macOS 10.14.1, and Windows 10.1809 are tested and supported. Simply run the following pip install in an environment that has python >= 3.6.

Linux and macOS

python3 -m pip install --upgrade nni

Windows

python -m pip install --upgrade nni

Note

For Linux and macOS, --user can be added if you want to install NNI in your home directory; this does not require any special privileges.

Note

If there is an error like Segmentation fault, please refer to the FAQ.

Note

For the system requirements of NNI, please refer to Install NNI on Linux & Mac or Windows.

Enable NNI Command-line Auto-Completion (Optional)

After the installation, you may want to enable the auto-completion feature for nnictl commands. Please refer to this tutorial.

“Hello World” example on MNIST

NNI is a toolkit to help users run automated machine learning experiments. It can automatically do the cyclic process of getting hyperparameters, running trials, testing results, and tuning hyperparameters. Here, we’ll show how to use NNI to help you find the optimal hyperparameters for a MNIST model.

Here is an example script to train a CNN on the MNIST dataset without NNI:

def main(args):
    # load data
    train_loader = torch.utils.data.DataLoader(datasets.MNIST(...), batch_size=args['batch_size'], shuffle=True)
    test_loader = torch.tuils.data.DataLoader(datasets.MNIST(...), batch_size=1000, shuffle=True)
    # build model
    model = Net(hidden_size=args['hidden_size'])
    optimizer = optim.SGD(model.parameters(), lr=args['lr'], momentum=args['momentum'])
    # train
    for epoch in range(10):
        train(args, model, device, train_loader, optimizer, epoch)
        test_acc = test(args, model, device, test_loader)
        print(test_acc)
    print('final accuracy:', test_acc)

if __name__ == '__main__':
    params = {
        'batch_size': 32,
        'hidden_size': 128,
        'lr': 0.001,
        'momentum': 0.5
    }
    main(params)

The above code can only try one set of parameters at a time; if we want to tune learning rate, we need to manually modify the hyperparameter and start the trial again and again.

NNI is born to help the user do tuning jobs; the NNI working process is presented below:

input: search space, trial code, config file
output: one optimal hyperparameter configuration

1: For t = 0, 1, 2, ..., maxTrialNum,
2:      hyperparameter = chose a set of parameter from search space
3:      final result = run_trial_and_evaluate(hyperparameter)
4:      report final result to NNI
5:      If reach the upper limit time,
6:          Stop the experiment
7: return hyperparameter value with best final result

If you want to use NNI to automatically train your model and find the optimal hyper-parameters, you need to do three changes based on your code:

Three steps to start an experiment

Step 1: Write a Search Space file in JSON, including the name and the distribution (discrete-valued or continuous-valued) of all the hyperparameters you need to search.

-   params = {'batch_size': 32, 'hidden_size': 128, 'lr': 0.001, 'momentum': 0.5}
+   {
+       "batch_size": {"_type":"choice", "_value": [16, 32, 64, 128]},
+       "hidden_size":{"_type":"choice","_value":[128, 256, 512, 1024]},
+       "lr":{"_type":"choice","_value":[0.0001, 0.001, 0.01, 0.1]},
+       "momentum":{"_type":"uniform","_value":[0, 1]}
+   }

Example: search_space.json

Step 2: Modify your Trial file to get the hyperparameter set from NNI and report the final result to NNI.

+ import nni

  def main(args):
      # load data
      train_loader = torch.utils.data.DataLoader(datasets.MNIST(...), batch_size=args['batch_size'], shuffle=True)
      test_loader = torch.tuils.data.DataLoader(datasets.MNIST(...), batch_size=1000, shuffle=True)
      # build model
      model = Net(hidden_size=args['hidden_size'])
      optimizer = optim.SGD(model.parameters(), lr=args['lr'], momentum=args['momentum'])
      # train
      for epoch in range(10):
          train(args, model, device, train_loader, optimizer, epoch)
          test_acc = test(args, model, device, test_loader)
-         print(test_acc)
+         nni.report_intermeidate_result(test_acc)
-     print('final accuracy:', test_acc)
+     nni.report_final_result(test_acc)

  if __name__ == '__main__':
-     params = {'batch_size': 32, 'hidden_size': 128, 'lr': 0.001, 'momentum': 0.5}
+     params = nni.get_next_parameter()
      main(params)

Example: mnist.py

Step 3: Define a config file in YAML which declares the path to the search space and trial files. It also gives other information such as the tuning algorithm, max trial number, and max duration arguments.

authorName: default
experimentName: example_mnist
trialConcurrency: 1
maxExecDuration: 1h
maxTrialNum: 10
trainingServicePlatform: local
# The path to Search Space
searchSpacePath: search_space.json
useAnnotation: false
tuner:
  builtinTunerName: TPE
# The path and the running command of trial
trial:
  command: python3 mnist.py
  codeDir: .
  gpuNum: 0

Note

If you are planning to use remote machines or clusters as your training service, to avoid too much pressure on network, we limit the number of files to 2000 and total size to 300MB. If your codeDir contains too many files, you can choose which files and subfolders should be excluded by adding a .nniignore file that works like a .gitignore file. For more details on how to write this file, see the git documentation.

Example: config.yml and .nniignore

All the code above is already prepared and stored in examples/trials/mnist-pytorch/.

Linux and macOS

Run the config.yml file from your command line to start an MNIST experiment.

nnictl create --config nni/examples/trials/mnist-pytorch/config.yml

Windows

Run the config_windows.yml file from your command line to start an MNIST experiment.

nnictl create --config nni\examples\trials\mnist-pytorch\config_windows.yml

Note

If you’re using NNI on Windows, you probably need to change python3 to python in the config.yml file or use the config_windows.yml file to start the experiment.

Note

nnictl is a command line tool that can be used to control experiments, such as start/stop/resume an experiment, start/stop NNIBoard, etc. Click here for more usage of nnictl.

Wait for the message INFO: Successfully started experiment! in the command line. This message indicates that your experiment has been successfully started. And this is what we expect to get:

INFO: Starting restful server...
INFO: Successfully started Restful server!
INFO: Setting local config...
INFO: Successfully set local config!
INFO: Starting experiment...
INFO: Successfully started experiment!
-----------------------------------------------------------------------
The experiment id is egchD4qy
The Web UI urls are: [Your IP]:8080
-----------------------------------------------------------------------

You can use these commands to get more information about the experiment
-----------------------------------------------------------------------
         commands                       description
1. nnictl experiment show        show the information of experiments
2. nnictl trial ls               list all of trial jobs
3. nnictl top                    monitor the status of running experiments
4. nnictl log stderr             show stderr log content
5. nnictl log stdout             show stdout log content
6. nnictl stop                   stop an experiment
7. nnictl trial kill             kill a trial job by id
8. nnictl --help                 get help information about nnictl
-----------------------------------------------------------------------

If you prepared trial, search space, and config according to the above steps and successfully created an NNI job, NNI will automatically tune the optimal hyper-parameters and run different hyper-parameter sets for each trial according to the requirements you set. You can clearly see its progress through the NNI WebUI.

WebUI

After you start your experiment in NNI successfully, you can find a message in the command-line interface that tells you the Web UI url like this:

The Web UI urls are: [Your IP]:8080

Open the Web UI url (Here it’s: [Your IP]:8080) in your browser; you can view detailed information about the experiment and all the submitted trial jobs as shown below. If you cannot open the WebUI link in your terminal, please refer to the FAQ.

View overview page

Information about this experiment will be shown in the WebUI, including the experiment trial profile and search space message. NNI also supports downloading this information and the parameters through the Experiment summary button.

overview

View trials detail page

We could see best trial metrics and hyper-parameter graph in this page. And the table content includes more columns when you click the button Add/Remove columns.

detail

View experiments management page

On the All experiments page, you can see all the experiments on your machine.

Experiments list

More detail please refer the doc.

Auto (Hyper-parameter) Tuning

Auto tuning is one of the key features provided by NNI; a main application scenario being hyper-parameter tuning. Tuning specifically applies to trial code. We provide a lot of popular auto tuning algorithms (called Tuner), and some early stop algorithms (called Assessor). NNI supports running trials on various training platforms, for example, on a local machine, on several servers in a distributed manner, or on platforms such as OpenPAI, Kubernetes, etc.

Other key features of NNI, such as model compression, feature engineering, can also be further enhanced by auto tuning, which we’ll described when introducing those features.

NNI has high extensibility, advanced users can customize their own Tuner, Assessor, and Training Service according to their needs.

Write a Trial Run on NNI

A Trial in NNI is an individual attempt at applying a configuration (e.g., a set of hyper-parameters) to a model.

To define an NNI trial, you need to first define the set of parameters (i.e., search space) and then update the model. NNI provides two approaches for you to define a trial: NNI API and NNI Python annotation. You could also refer to here for more trial examples.

NNI API

Step 1 - Prepare a SearchSpace parameters file.

An example is shown below:

{
    "dropout_rate":{"_type":"uniform","_value":[0.1,0.5]},
    "conv_size":{"_type":"choice","_value":[2,3,5,7]},
    "hidden_size":{"_type":"choice","_value":[124, 512, 1024]},
    "learning_rate":{"_type":"uniform","_value":[0.0001, 0.1]}
}

Refer to SearchSpaceSpec to learn more about search spaces. Tuner will generate configurations from this search space, that is, choosing a value for each hyperparameter from the range.

Step 2 - Update model code
  • Import NNI

    Include import nni in your trial code to use NNI APIs.

  • Get configuration from Tuner

RECEIVED_PARAMS = nni.get_next_parameter()

RECEIVED_PARAMS is an object, for example:

{"conv_size": 2, "hidden_size": 124, "learning_rate": 0.0307, "dropout_rate": 0.2029}.

  • Report metric data periodically (optional)

nni.report_intermediate_result(metrics)

metrics can be any python object. If users use the NNI built-in tuner/assessor, metrics can only have two formats: 1) a number e.g., float, int, or 2) a dict object that has a key named default whose value is a number. These metrics are reported to assessor. Often, metrics includes the periodically evaluated loss or accuracy.

  • Report performance of the configuration

nni.report_final_result(metrics)

metrics can also be any python object. If users use the NNI built-in tuner/assessor, metrics follows the same format rule as that in report_intermediate_result, the number indicates the model’s performance, for example, the model’s accuracy, loss etc. These metrics are reported to tuner.

Step 3 - Enable NNI API

To enable NNI API mode, you need to set useAnnotation to false and provide the path of the SearchSpace file was defined in step 1:

useAnnotation: false
searchSpacePath: /path/to/your/search_space.json

You can refer to here for more information about how to set up experiment configurations.

Please refer to here for more APIs (e.g., nni.get_sequence_id()) provided by NNI.

NNI Python Annotation

An alternative to writing a trial is to use NNI’s syntax for python. NNI annotations are simple, similar to comments. You don’t have to make structural changes to your existing code. With a few lines of NNI annotation, you will be able to:

  • annotate the variables you want to tune

  • specify the range in which you want to tune the variables

  • annotate which variable you want to report as an intermediate result to assessor

  • annotate which variable you want to report as the final result (e.g. model accuracy) to tuner.

Again, take MNIST as an example, it only requires 2 steps to write a trial with NNI Annotation.

Step 1 - Update codes with annotations

The following is a TensorFlow code snippet for NNI Annotation where the highlighted four lines are annotations that:

  1. tune batch_size and dropout_rate

  2. report test_acc every 100 steps

  3. lastly report test_acc as the final result.

It’s worth noting that, as these newly added codes are merely annotations, you can still run your code as usual in environments without NNI installed.

with tf.Session() as sess:
    sess.run(tf.global_variables_initializer())
+   """@nni.variable(nni.choice(50, 250, 500), name=batch_size)"""
    batch_size = 128
    for i in range(10000):
        batch = mnist.train.next_batch(batch_size)
+       """@nni.variable(nni.choice(0.1, 0.5), name=dropout_rate)"""
        dropout_rate = 0.5
        mnist_network.train_step.run(feed_dict={mnist_network.images: batch[0],
                                                mnist_network.labels: batch[1],
                                                mnist_network.keep_prob: dropout_rate})
        if i % 100 == 0:
            test_acc = mnist_network.accuracy.eval(
                feed_dict={mnist_network.images: mnist.test.images,
                            mnist_network.labels: mnist.test.labels,
                            mnist_network.keep_prob: 1.0})
+           """@nni.report_intermediate_result(test_acc)"""

    test_acc = mnist_network.accuracy.eval(
        feed_dict={mnist_network.images: mnist.test.images,
                    mnist_network.labels: mnist.test.labels,
                    mnist_network.keep_prob: 1.0})
+   """@nni.report_final_result(test_acc)"""

NOTE:

  • @nni.variable will affect its following line which should be an assignment statement whose left-hand side must be the same as the keyword name in the @nni.variable statement.

  • @nni.report_intermediate_result/@nni.report_final_result will send the data to assessor/tuner at that line.

For more information about annotation syntax and its usage, please refer to Annotation.

Step 2 - Enable NNI Annotation

In the YAML configure file, you need to set useAnnotation to true to enable NNI annotation:

useAnnotation: true

Standalone mode for debugging

NNI supports a standalone mode for trial code to run without starting an NNI experiment. This is for finding out bugs in trial code more conveniently. NNI annotation natively supports standalone mode, as the added NNI related lines are comments. For NNI trial APIs, the APIs have changed behaviors in standalone mode, some APIs return dummy values, and some APIs do not really report values. Please refer to the following table for the full list of these APIs.

# NOTE: please assign default values to the hyperparameters in your trial code
nni.get_next_parameter # return {}
nni.report_final_result # have log printed on stdout, but does not report
nni.report_intermediate_result # have log printed on stdout, but does not report
nni.get_experiment_id # return "STANDALONE"
nni.get_trial_id # return "STANDALONE"
nni.get_sequence_id # return 0

You can try standalone mode with the mnist example. Simply run python3 mnist.py under the code directory. The trial code should successfully run with the default hyperparameter values.

For more information on debugging, please refer to How to Debug

Where are my trials?

Local Mode

In NNI, every trial has a dedicated directory for them to output their own data. In each trial, an environment variable called NNI_OUTPUT_DIR is exported. Under this directory, you can find each trial’s code, data, and other logs. In addition, each trial’s log (including stdout) will be re-directed to a file named trial.log under that directory.

If NNI Annotation is used, the trial’s converted code is in another temporary directory. You can check that in a file named run.sh under the directory indicated by NNI_OUTPUT_DIR. The second line (i.e., the cd command) of this file will change directory to the actual directory where code is located. Below is an example of run.sh:

#!/bin/bash
cd /tmp/user_name/nni/annotation/tmpzj0h72x6 #This is the actual directory
export NNI_PLATFORM=local
export NNI_SYS_DIR=/home/user_name/nni-experiments/$experiment_id$/trials/$trial_id$
export NNI_TRIAL_JOB_ID=nrbb2
export NNI_OUTPUT_DIR=/home/user_name/nni-experiments/$eperiment_id$/trials/$trial_id$
export NNI_TRIAL_SEQ_ID=1
export MULTI_PHASE=false
export CUDA_VISIBLE_DEVICES=
eval python3 mnist.py 2>/home/user_name/nni-experiments/$experiment_id$/trials/$trial_id$/stderr
echo $? `date +%s%3N` >/home/user_name/nni-experiments/$experiment_id$/trials/$trial_id$/.nni/state
Other Modes

When running trials on other platforms like remote machine or PAI, the environment variable NNI_OUTPUT_DIR only refers to the output directory of the trial, while the trial code and run.sh might not be there. However, the trial.log will be transmitted back to the local machine in the trial’s directory, which defaults to ~/nni-experiments/$experiment_id$/trials/$trial_id$/

For more information, please refer to HowToDebug.

Builtin-Tuners

NNI provides an easy way to adopt an approach to set up parameter tuning algorithms, we call them Tuner.

Tuner receives metrics from Trial to evaluate the performance of a specific parameters/architecture configuration. Tuner sends the next hyper-parameter or architecture configuration to Trial.

HyperParameter Tuning with NNI Built-in Tuners

To fit a machine/deep learning model into different tasks/problems, hyperparameters always need to be tuned. Automating the process of hyperparaeter tuning always requires a good tuning algorithm. NNI has provided state-of-the-art tuning algorithms as part of our built-in tuners and makes them easy to use. Below is the brief summary of NNI’s current built-in tuners:

Note: Click the Tuner’s name to get the Tuner’s installation requirements, suggested scenario, and an example configuration. A link for a detailed description of each algorithm is located at the end of the suggested scenario for each tuner. Here is an article comparing different Tuners on several problems.

Currently, we support the following algorithms:

Tuner

Brief Introduction of Algorithm

TPE

The Tree-structured Parzen Estimator (TPE) is a sequential model-based optimization (SMBO) approach. SMBO methods sequentially construct models to approximate the performance of hyperparameters based on historical measurements, and then subsequently choose new hyperparameters to test based on this model. Reference Paper

Random Search

In Random Search for Hyper-Parameter Optimization show that Random Search might be surprisingly simple and effective. We suggest that we could use Random Search as the baseline when we have no knowledge about the prior distribution of hyper-parameters. Reference Paper

Anneal

This simple annealing algorithm begins by sampling from the prior, but tends over time to sample from points closer and closer to the best ones observed. This algorithm is a simple variation on the random search that leverages smoothness in the response surface. The annealing rate is not adaptive.

Naïve Evolution

Naïve Evolution comes from Large-Scale Evolution of Image Classifiers. It randomly initializes a population-based on search space. For each generation, it chooses better ones and does some mutation (e.g., change a hyperparameter, add/remove one layer) on them to get the next generation. Naïve Evolution requires many trials to work, but it’s very simple and easy to expand new features. Reference paper

SMAC

SMAC is based on Sequential Model-Based Optimization (SMBO). It adapts the most prominent previously used model class (Gaussian stochastic process models) and introduces the model class of random forests to SMBO, in order to handle categorical parameters. The SMAC supported by NNI is a wrapper on the SMAC3 GitHub repo. Notice, SMAC needs to be installed by pip install nni[SMAC] command. Reference Paper, GitHub Repo

Batch tuner

Batch tuner allows users to simply provide several configurations (i.e., choices of hyper-parameters) for their trial code. After finishing all the configurations, the experiment is done. Batch tuner only supports the type choice in search space spec.

Grid Search

Grid Search performs an exhaustive searching through a manually specified subset of the hyperparameter space defined in the searchspace file. Note that the only acceptable types of search space are choice, quniform, randint.

Hyperband

Hyperband tries to use limited resources to explore as many configurations as possible and returns the most promising ones as a final result. The basic idea is to generate many configurations and run them for a small number of trials. The half least-promising configurations are thrown out, the remaining are further trained along with a selection of new configurations. The size of these populations is sensitive to resource constraints (e.g. allotted search time). Reference Paper

Network Morphism

Network Morphism provides functions to automatically search for deep learning architectures. It generates child networks that inherit the knowledge from their parent network which it is a morph from. This includes changes in depth, width, and skip-connections. Next, it estimates the value of a child network using historic architecture and metric pairs. Then it selects the most promising one to train. Reference Paper

Metis Tuner

Metis offers the following benefits when it comes to tuning parameters: While most tools only predict the optimal configuration, Metis gives you two outputs: (a) current prediction of optimal configuration, and (b) suggestion for the next trial. No more guesswork. While most tools assume training datasets do not have noisy data, Metis actually tells you if you need to re-sample a particular hyper-parameter. Reference Paper

BOHB

BOHB is a follow-up work to Hyperband. It targets the weakness of Hyperband that new configurations are generated randomly without leveraging finished trials. For the name BOHB, HB means Hyperband, BO means Bayesian Optimization. BOHB leverages finished trials by building multiple TPE models, a proportion of new configurations are generated through these models. Reference Paper

GP Tuner

Gaussian Process Tuner is a sequential model-based optimization (SMBO) approach with Gaussian Process as the surrogate. Reference Paper, Github Repo

PPO Tuner

PPO Tuner is a Reinforcement Learning tuner based on PPO algorithm. Reference Paper

PBT Tuner

PBT Tuner is a simple asynchronous optimization algorithm which effectively utilizes a fixed computational budget to jointly optimize a population of models and their hyperparameters to maximize performance. Reference Paper

Usage of Built-in Tuners

Using a built-in tuner provided by the NNI SDK requires one to declare the builtinTunerName and classArgs in the config.yml file. In this part, we will introduce each tuner along with information about usage and suggested scenarios, classArg requirements, and an example configuration.

Note: Please follow the format when you write your config.yml file. Some built-in tuners have dependencies that need to be installed using pip install nni[<tuner>], like SMAC’s dependencies can be installed using pip install nni[SMAC].

TPE

Built-in Tuner Name: TPE

Suggested scenario

TPE, as a black-box optimization, can be used in various scenarios and shows good performance in general. Especially when you have limited computation resources and can only try a small number of trials. From a large amount of experiments, we found that TPE is far better than Random Search. Detailed Description

classArgs Requirements:

  • optimize_mode (maximize or minimize, optional, default = maximize) - If ‘maximize’, the tuner will try to maximize metrics. If ‘minimize’, the tuner will try to minimize metrics.

Note: We have optimized the parallelism of TPE for large-scale trial concurrency. For the principle of optimization or turn-on optimization, please refer to TPE document.

Example Configuration:

# config.yml
tuner:
  builtinTunerName: TPE
  classArgs:
    optimize_mode: maximize


Anneal

Built-in Tuner Name: Anneal

Suggested scenario

Anneal is suggested when each trial does not take very long and you have enough computation resources (very similar to Random Search). It’s also useful when the variables in the search space can be sample from some prior distribution. Detailed Description

classArgs Requirements:

  • optimize_mode (maximize or minimize, optional, default = maximize) - If ‘maximize’, the tuner will try to maximize metrics. If ‘minimize’, the tuner will try to minimize metrics.

Example Configuration:

# config.yml
tuner:
  builtinTunerName: Anneal
  classArgs:
    optimize_mode: maximize


Naïve Evolution

Built-in Tuner Name: Evolution

Suggested scenario

Its computational resource requirements are relatively high. Specifically, it requires a large initial population to avoid falling into a local optimum. If your trial is short or leverages assessor, this tuner is a good choice. It is also suggested when your trial code supports weight transfer; that is, the trial could inherit the converged weights from its parent(s). This can greatly speed up the training process. Detailed Description

classArgs Requirements:

  • optimize_mode (maximize or minimize, optional, default = maximize) - If ‘maximize’, the tuner will try to maximize metrics. If ‘minimize’, the tuner will try to minimize metrics.

  • population_size (int value (should > 0), optional, default = 20) - the initial size of the population (trial num) in the evolution tuner. It’s suggested that population_size be much larger than concurrency so users can get the most out of the algorithm (and at least concurrency, or the tuner will fail on its first generation of parameters).

Example Configuration:

# config.yml
tuner:
  builtinTunerName: Evolution
  classArgs:
    optimize_mode: maximize
    population_size: 100


SMAC

Built-in Tuner Name: SMAC

Please note that SMAC doesn’t support running on Windows currently. For the specific reason, please refer to this GitHub issue.

Installation

SMAC has dependencies that need to be installed by following command before the first usage. As a reminder, swig is required for SMAC: for Ubuntu swig can be installed with apt.

pip install nni[SMAC]

Suggested scenario

Similar to TPE, SMAC is also a black-box tuner that can be tried in various scenarios and is suggested when computational resources are limited. It is optimized for discrete hyperparameters, thus, it’s suggested when most of your hyperparameters are discrete. Detailed Description

classArgs Requirements:

  • optimize_mode (maximize or minimize, optional, default = maximize) - If ‘maximize’, the tuner will try to maximize metrics. If ‘minimize’, the tuner will try to minimize metrics.

  • config_dedup (True or False, optional, default = False) - If True, the tuner will not generate a configuration that has been already generated. If False, a configuration may be generated twice, but it is rare for a relatively large search space.

Example Configuration:

# config.yml
tuner:
  builtinTunerName: SMAC
  classArgs:
    optimize_mode: maximize


Batch Tuner

Built-in Tuner Name: BatchTuner

Suggested scenario

If the configurations you want to try have been decided beforehand, you can list them in search space file (using choice) and run them using batch tuner. Detailed Description

Example Configuration:

# config.yml
tuner:
  builtinTunerName: BatchTuner


Note that the search space for BatchTuner should look like:

{
    "combine_params":
    {
        "_type" : "choice",
        "_value" : [{"optimizer": "Adam", "learning_rate": 0.00001},
                    {"optimizer": "Adam", "learning_rate": 0.0001},
                    {"optimizer": "Adam", "learning_rate": 0.001},
                    {"optimizer": "SGD", "learning_rate": 0.01},
                    {"optimizer": "SGD", "learning_rate": 0.005},
                    {"optimizer": "SGD", "learning_rate": 0.0002}]
    }
}

The search space file should include the high-level key combine_params. The type of params in the search space must be choice and the values must include all the combined params values.

Hyperband

Built-in Advisor Name: Hyperband

Suggested scenario

This is suggested when you have limited computational resources but have a relatively large search space. It performs well in scenarios where intermediate results can indicate good or bad final results to some extent. For example, when models that are more accurate early on in training are also more accurate later on. Detailed Description

classArgs Requirements:

  • optimize_mode (maximize or minimize, optional, default = maximize) - If ‘maximize’, the tuner will try to maximize metrics. If ‘minimize’, the tuner will try to minimize metrics.

  • R (int, optional, default = 60) - the maximum budget given to a trial (could be the number of mini-batches or epochs). Each trial should use TRIAL_BUDGET to control how long they run.

  • eta (int, optional, default = 3) - (eta-1)/eta is the proportion of discarded trials.

  • exec_mode (serial or parallelism, optional, default = parallelism) - If ‘parallelism’, the tuner will try to use available resources to start new bucket immediately. If ‘serial’, the tuner will only start new bucket after the current bucket is done.

Example Configuration:

# config.yml
advisor:
  builtinAdvisorName: Hyperband
  classArgs:
    optimize_mode: maximize
    R: 60
    eta: 3


Network Morphism

Built-in Tuner Name: NetworkMorphism

Installation

NetworkMorphism requires PyTorch.

Suggested scenario

This is suggested when you want to apply deep learning methods to your task but you have no idea how to choose or design a network. You may modify this example to fit your own dataset and your own data augmentation method. Also you can change the batch size, learning rate, or optimizer. Currently, this tuner only supports the computer vision domain. Detailed Description

classArgs Requirements:

  • optimize_mode (maximize or minimize, optional, default = maximize) - If ‘maximize’, the tuner will try to maximize metrics. If ‘minimize’, the tuner will try to minimize metrics.

  • task ((‘cv’), optional, default = ‘cv’) - The domain of the experiment. For now, this tuner only supports the computer vision (CV) domain.

  • input_width (int, optional, default = 32) - input image width

  • input_channel (int, optional, default = 3) - input image channel

  • n_output_node (int, optional, default = 10) - number of classes

Example Configuration:

# config.yml
tuner:
  builtinTunerName: NetworkMorphism
    classArgs:
      optimize_mode: maximize
      task: cv
      input_width: 32
      input_channel: 3
      n_output_node: 10


Metis Tuner

Built-in Tuner Name: MetisTuner

Note that the only acceptable types of search space types are quniform, uniform, randint, and numerical choice. Only numerical values are supported since the values will be used to evaluate the ‘distance’ between different points.

Suggested scenario

Similar to TPE and SMAC, Metis is a black-box tuner. If your system takes a long time to finish each trial, Metis is more favorable than other approaches such as random search. Furthermore, Metis provides guidance on subsequent trials. Here is an example on the use of Metis. Users only need to send the final result, such as accuracy, to the tuner by calling the NNI SDK. Detailed Description

classArgs Requirements:

  • optimize_mode (‘maximize’ or ‘minimize’, optional, default = ‘maximize’) - If ‘maximize’, the tuner will try to maximize metrics. If ‘minimize’, the tuner will try to minimize metrics.

Example Configuration:

# config.yml
tuner:
  builtinTunerName: MetisTuner
  classArgs:
    optimize_mode: maximize


BOHB Advisor

Built-in Tuner Name: BOHB

Installation

BOHB advisor requires ConfigSpace package. ConfigSpace can be installed using the following command.

pip install nni[BOHB]

Suggested scenario

Similar to Hyperband, BOHB is suggested when you have limited computational resources but have a relatively large search space. It performs well in scenarios where intermediate results can indicate good or bad final results to some extent. In this case, it may converge to a better configuration than Hyperband due to its usage of Bayesian optimization. Detailed Description

classArgs Requirements:

  • optimize_mode (maximize or minimize, optional, default = maximize) - If ‘maximize’, tuners will try to maximize metrics. If ‘minimize’, tuner will try to minimize metrics.

  • min_budget (int, optional, default = 1) - The smallest budget to assign to a trial job, (budget can be the number of mini-batches or epochs). Needs to be positive.

  • max_budget (int, optional, default = 3) - The largest budget to assign to a trial job, (budget can be the number of mini-batches or epochs). Needs to be larger than min_budget.

  • eta (int, optional, default = 3) - In each iteration, a complete run of sequential halving is executed. In it, after evaluating each configuration on the same subset size, only a fraction of 1/eta of them ‘advances’ to the next round. Must be greater or equal to 2.

  • min_points_in_model(int, optional, default = None): number of observations to start building a KDE. Default ‘None’ means dim+1; when the number of completed trials in this budget is equal to or larger than max{dim+1, min_points_in_model}, BOHB will start to build a KDE model of this budget then use said KDE model to guide configuration selection. Needs to be positive. (dim means the number of hyperparameters in search space)

  • top_n_percent(int, optional, default = 15): percentage (between 1 and 99) of the observations which are considered good. Good points and bad points are used for building KDE models. For example, if you have 100 observed trials and top_n_percent is 15, then the top 15% of points will be used for building the good points models “l(x)”. The remaining 85% of points will be used for building the bad point models “g(x)”.

  • num_samples(int, optional, default = 64): number of samples to optimize EI (default 64). In this case, we will sample “num_samples” points and compare the result of l(x)/g(x). Then we will return the one with the maximum l(x)/g(x) value as the next configuration if the optimize_mode is maximize. Otherwise, we return the smallest one.

  • random_fraction(float, optional, default = 0.33): fraction of purely random configurations that are sampled from the prior without the model.

  • bandwidth_factor(float, optional, default = 3.0): to encourage diversity, the points proposed to optimize EI are sampled from a ‘widened’ KDE where the bandwidth is multiplied by this factor. We suggest using the default value if you are not familiar with KDE.

  • min_bandwidth(float, optional, default = 0.001): to keep diversity, even when all (good) samples have the same value for one of the parameters, a minimum bandwidth (default: 1e-3) is used instead of zero. We suggest using the default value if you are not familiar with KDE.

Please note that the float type currently only supports decimal representations. You have to use 0.333 instead of 1/3 and 0.001 instead of 1e-3.

Example Configuration:

advisor:
  builtinAdvisorName: BOHB
  classArgs:
    optimize_mode: maximize
    min_budget: 1
    max_budget: 27
    eta: 3

GP Tuner

Built-in Tuner Name: GPTuner

Note that the only acceptable types within the search space are randint, uniform, quniform, loguniform, qloguniform, and numerical choice. Only numerical values are supported since the values will be used to evaluate the ‘distance’ between different points.

Suggested scenario

As a strategy in a Sequential Model-based Global Optimization (SMBO) algorithm, GP Tuner uses a proxy optimization problem (finding the maximum of the acquisition function) that, albeit still a hard problem, is cheaper (in the computational sense) to solve and common tools can be employed to solve it. Therefore, GP Tuner is most adequate for situations where the function to be optimized is very expensive to evaluate. GP can be used when computational resources are limited. However, GP Tuner has a computational cost that grows at O(N^3) due to the requirement of inverting the Gram matrix, so it’s not suitable when lots of trials are needed. Detailed Description

classArgs Requirements:

  • optimize_mode (‘maximize’ or ‘minimize’, optional, default = ‘maximize’) - If ‘maximize’, the tuner will try to maximize metrics. If ‘minimize’, the tuner will try to minimize metrics.

  • utility (‘ei’, ‘ucb’ or ‘poi’, optional, default = ‘ei’) - The utility function (acquisition function). ‘ei’, ‘ucb’, and ‘poi’ correspond to ‘Expected Improvement’, ‘Upper Confidence Bound’, and ‘Probability of Improvement’, respectively.

  • kappa (float, optional, default = 5) - Used by the ‘ucb’ utility function. The bigger kappa is, the more exploratory the tuner will be.

  • xi (float, optional, default = 0) - Used by the ‘ei’ and ‘poi’ utility functions. The bigger xi is, the more exploratory the tuner will be.

  • nu (float, optional, default = 2.5) - Used to specify the Matern kernel. The smaller nu, the less smooth the approximated function is.

  • alpha (float, optional, default = 1e-6) - Used to specify the Gaussian Process Regressor. Larger values correspond to an increased noise level in the observations.

  • cold_start_num (int, optional, default = 10) - Number of random explorations to perform before the Gaussian Process. Random exploration can help by diversifying the exploration space.

  • selection_num_warm_up (int, optional, default = 1e5) - Number of random points to evaluate when getting the point which maximizes the acquisition function.

  • selection_num_starting_points (int, optional, default = 250) - Number of times to run L-BFGS-B from a random starting point after the warmup.

Example Configuration:

# config.yml
tuner:
  builtinTunerName: GPTuner
  classArgs:
    optimize_mode: maximize
    utility: 'ei'
    kappa: 5.0
    xi: 0.0
    nu: 2.5
    alpha: 1e-6
    cold_start_num: 10
    selection_num_warm_up: 100000
    selection_num_starting_points: 250

PPO Tuner

Built-in Tuner Name: PPOTuner

Note that the only acceptable types within the search space are layer_choice and input_choice. For input_choice, n_chosen can only be 0, 1, or [0, 1]. Note, the search space file for NAS is usually automatically generated through the command nnictl ss_gen.

Suggested scenario

PPOTuner is a Reinforcement Learning tuner based on the PPO algorithm. PPOTuner can be used when using the NNI NAS interface to do neural architecture search. In general, the Reinforcement Learning algorithm needs more computing resources, though the PPO algorithm is relatively more efficient than others. It’s recommended to use this tuner when you have a large amount of computional resources available. You could try it on a very simple task, such as the mnist-nas example. See details

classArgs Requirements:

  • optimize_mode (‘maximize’ or ‘minimize’) - If ‘maximize’, the tuner will try to maximize metrics. If ‘minimize’, the tuner will try to minimize metrics.

  • trials_per_update (int, optional, default = 20) - The number of trials to be used for one update. It must be divisible by minibatch_size. trials_per_update is recommended to be an exact multiple of trialConcurrency for better concurrency of trials.

  • epochs_per_update (int, optional, default = 4) - The number of epochs for one update.

  • minibatch_size (int, optional, default = 4) - Mini-batch size (i.e., number of trials for a mini-batch) for the update. Note that trials_per_update must be divisible by minibatch_size.

  • ent_coef (float, optional, default = 0.0) - Policy entropy coefficient in the optimization objective.

  • lr (float, optional, default = 3e-4) - Learning rate of the model (lstm network); constant.

  • vf_coef (float, optional, default = 0.5) - Value function loss coefficient in the optimization objective.

  • max_grad_norm (float, optional, default = 0.5) - Gradient norm clipping coefficient.

  • gamma (float, optional, default = 0.99) - Discounting factor.

  • lam (float, optional, default = 0.95) - Advantage estimation discounting factor (lambda in the paper).

  • cliprange (float, optional, default = 0.2) - Cliprange in the PPO algorithm, constant.

Example Configuration:

# config.yml
tuner:
  builtinTunerName: PPOTuner
  classArgs:
    optimize_mode: maximize

PBT Tuner

Built-in Tuner Name: PBTTuner

Suggested scenario

Population Based Training (PBT) bridges and extends parallel search methods and sequential optimization methods. It requires relatively small computation resource, by inheriting weights from currently good-performing ones to explore better ones periodically. With PBTTuner, users finally get a trained model, rather than a configuration that could reproduce the trained model by training the model from scratch. This is because model weights are inherited periodically through the whole search process. PBT can also be seen as a training approach. If you don’t need to get a specific configuration, but just expect a good model, PBTTuner is a good choice. See details

classArgs requirements:

  • optimize_mode (‘maximize’ or ‘minimize’) - If ‘maximize’, the tuner will target to maximize metrics. If ‘minimize’, the tuner will target to minimize metrics.

  • all_checkpoint_dir (str, optional, default = None) - Directory for trials to load and save checkpoint, if not specified, the directory would be “~/nni/checkpoint/“. Note that if the experiment is not local mode, users should provide a path in a shared storage which can be accessed by all the trials.

  • population_size (int, optional, default = 10) - Number of trials in a population. Each step has this number of trials. In our implementation, one step is running each trial by specific training epochs set by users.

  • factors (tuple, optional, default = (1.2, 0.8)) - Factors for perturbation of hyperparameters.

  • fraction (float, optional, default = 0.2) - Fraction for selecting bottom and top trials.

Usage example

# config.yml
tuner:
  builtinTunerName: PBTTuner
  classArgs:
    optimize_mode: maximize

Note that, to use this tuner, your trial code should be modified accordingly, please refer to the document of PBTTuner for details.

Reference and Feedback

TPE, Random Search, Anneal Tuners on NNI

TPE

The Tree-structured Parzen Estimator (TPE) is a sequential model-based optimization (SMBO) approach. SMBO methods sequentially construct models to approximate the performance of hyperparameters based on historical measurements, and then subsequently choose new hyperparameters to test based on this model. The TPE approach models P(x|y) and P(y) where x represents hyperparameters and y the associated evaluation matric. P(x|y) is modeled by transforming the generative process of hyperparameters, replacing the distributions of the configuration prior with non-parametric densities. This optimization approach is described in detail in Algorithms for Hyper-Parameter Optimization. ​

Parallel TPE optimization

TPE approaches were actually run asynchronously in order to make use of multiple compute nodes and to avoid wasting time waiting for trial evaluations to complete. The original algorithm design was optimized for sequential computation. If we were to use TPE with much concurrency, its performance will be bad. We have optimized this case using the Constant Liar algorithm. For these principles of optimization, please refer to our research blog.

Usage

To use TPE, you should add the following spec in your experiment’s YAML config file:

tuner:
  builtinTunerName: TPE
  classArgs:
    optimize_mode: maximize
    parallel_optimize: True
    constant_liar_type: min

classArgs requirements:

  • optimize_mode (maximize or minimize, optional, default = maximize) - If ‘maximize’, tuners will try to maximize metrics. If ‘minimize’, tuner will try to minimize metrics.

  • parallel_optimize (bool, optional, default = False) - If True, TPE will use the Constant Liar algorithm to optimize parallel hyperparameter tuning. Otherwise, TPE will not discriminate between sequential or parallel situations.

  • constant_liar_type (min or max or mean, optional, default = min) - The type of constant liar to use, will logically be determined on the basis of the values taken by y at X. There are three possible values, min{Y}, max{Y}, and mean{Y}.

Anneal

This simple annealing algorithm begins by sampling from the prior but tends over time to sample from points closer and closer to the best ones observed. This algorithm is a simple variation on random search that leverages smoothness in the response surface. The annealing rate is not adaptive.

Naive Evolution Tuners on NNI

Naive Evolution

Naive Evolution comes from Large-Scale Evolution of Image Classifiers. It randomly initializes a population based on the search space. For each generation, it chooses better ones and does some mutation (e.g., changes a hyperparameter, adds/removes one layer, etc.) on them to get the next generation. Naive Evolution requires many trials to works but it’s very simple and it’s easily expanded with new features.

SMAC Tuner on NNI

SMAC

SMAC is based on Sequential Model-Based Optimization (SMBO). It adapts the most prominent previously used model class (Gaussian stochastic process models) and introduces the model class of random forests to SMBO in order to handle categorical parameters. The SMAC supported by nni is a wrapper on the SMAC3 github repo.

Note that SMAC on nni only supports a subset of the types in the search space spec: choice, randint, uniform, loguniform, and quniform.

Metis Tuner on NNI

Metis Tuner

Metis offers several benefits over other tuning algorithms. While most tools only predict the optimal configuration, Metis gives you two outputs, a prediction for the optimal configuration and a suggestion for the next trial. No more guess work!

While most tools assume training datasets do not have noisy data, Metis actually tells you if you need to resample a particular hyper-parameter.

While most tools have problems of being exploitation-heavy, Metis’ search strategy balances exploration, exploitation, and (optional) resampling.

Metis belongs to the class of sequential model-based optimization (SMBO) algorithms and it is based on the Bayesian Optimization framework. To model the parameter-vs-performance space, Metis uses both a Gaussian Process and GMM. Since each trial can impose a high time cost, Metis heavily trades inference computations with naive trials. At each iteration, Metis does two tasks:

  • It finds the global optimal point in the Gaussian Process space. This point represents the optimal configuration.

  • It identifies the next hyper-parameter candidate. This is achieved by inferring the potential information gain of exploration, exploitation, and resampling.

Note that the only acceptable types within the search space are quniform, uniform, randint, and numerical choice.

More details can be found in our paper.

Batch Tuner on NNI

Batch Tuner

Batch tuner allows users to simply provide several configurations (i.e., choices of hyper-parameters) for their trial code. After finishing all the configurations, the experiment is done. Batch tuner only supports the type choice in the search space spec.

Suggested scenario: If the configurations you want to try have been decided, you can list them in the SearchSpace file (using choice) and run them using the batch tuner.

Grid Search on NNI

GP Tuner on NNI

GP Tuner

Bayesian optimization works by constructing a posterior distribution of functions (a Gaussian Process) that best describes the function you want to optimize. As the number of observations grows, the posterior distribution improves, and the algorithm becomes more certain of which regions in parameter space are worth exploring and which are not.

GP Tuner is designed to minimize/maximize the number of steps required to find a combination of parameters that are close to the optimal combination. To do so, this method uses a proxy optimization problem (finding the maximum of the acquisition function) that, albeit still a hard problem, is cheaper (in the computational sense) to solve, and it’s amenable to common tools. Therefore, Bayesian Optimization is suggested for situations where sampling the function to be optimized is very expensive.

Note that the only acceptable types within the search space are randint, uniform, quniform, loguniform, qloguniform, and numerical choice.

This optimization approach is described in Section 3 of Algorithms for Hyper-Parameter Optimization.

Network Morphism Tuner on NNI

1. Introduction

Autokeras is a popular autoML tool using Network Morphism. The basic idea of Autokeras is to use Bayesian Regression to estimate the metric of the Neural Network Architecture. Each time, it generates several child networks from father networks. Then it uses a naïve Bayesian regression to estimate its metric value from the history of trained results of network and metric value pairs. Next, it chooses the child which has the best, estimated performance and adds it to the training queue. Inspired by the work of Autokeras and referring to its code, we implemented our Network Morphism method on the NNI platform.

If you want to know more about network morphism trial usage, please see the Readme.md.

2. Usage

To use Network Morphism, you should modify the following spec in your config.yml file:

tuner:
  #choice: NetworkMorphism
  builtinTunerName: NetworkMorphism
  classArgs:
    #choice: maximize, minimize
    optimize_mode: maximize
    #for now, this tuner only supports cv domain
    task: cv
    #modify to fit your input image width
    input_width: 32
    #modify to fit your input image channel
    input_channel: 3
    #modify to fit your number of classes
    n_output_node: 10

In the training procedure, it generates a JSON file which represents a Network Graph. Users can call the “json_to_graph()” function to build a PyTorch or Keras model from this JSON file.

import nni
from nni.networkmorphism_tuner.graph import json_to_graph

def build_graph_from_json(ir_model_json):
    """build a pytorch model from json representation
    """
    graph = json_to_graph(ir_model_json)
    model = graph.produce_torch_model()
    return model

# trial get next parameter from network morphism tuner
RCV_CONFIG = nni.get_next_parameter()
# call the function to build pytorch model or keras model
net = build_graph_from_json(RCV_CONFIG)

# training procedure
# ....

# report the final accuracy to NNI
nni.report_final_result(best_acc)

If you want to save and load the best model, the following methods are recommended.

# 1. Use NNI API
## You can get the best model ID from WebUI
## or `nni-experiments/experiment_id/log/model_path/best_model.txt'

## read the json string from model file and load it with NNI API
with open("best-model.json") as json_file:
    json_of_model = json_file.read()
model = build_graph_from_json(json_of_model)

# 2. Use Framework API (Related to Framework)
## 2.1 Keras API

## Save the model with Keras API in the trial code
## it's better to save model with id in nni local mode
model_id = nni.get_sequence_id()
## serialize model to JSON
model_json = model.to_json()
with open("model-{}.json".format(model_id), "w") as json_file:
    json_file.write(model_json)
## serialize weights to HDF5
model.save_weights("model-{}.h5".format(model_id))

## Load the model with Keras API if you want to reuse the model
## load json and create model
model_id = "" # id of the model you want to reuse
with open('model-{}.json'.format(model_id), 'r') as json_file:
    loaded_model_json = json_file.read()
loaded_model = model_from_json(loaded_model_json)
## load weights into new model
loaded_model.load_weights("model-{}.h5".format(model_id))

## 2.2 PyTorch API

## Save the model with PyTorch API in the trial code
model_id = nni.get_sequence_id()
torch.save(model, "model-{}.pt".format(model_id))

## Load the model with PyTorch API if you want to reuse the model
model_id = "" # id of the model you want to reuse
loaded_model = torch.load("model-{}.pt".format(model_id))
3. File Structure

The tuner has a lot of different files, functions, and classes. Here, we will give most of those files only a brief introduction:

  • networkmorphism_tuner.py is a tuner which uses network morphism techniques.

  • bayesian.py is a Bayesian method to estimate the metric of unseen model based on the models we have already searched.

  • graph.py is the meta graph data structure. The class Graph represents the neural architecture graph of a model.

    • Graph extracts the neural architecture graph from a model.

    • Each node in the graph is an intermediate tensor between layers.

    • Each layer is an edge in the graph.

    • Notably, multiple edges may refer to the same layer.

  • graph_transformer.py includes some graph transformers which widen, deepen, or add skip-connections to the graph.

  • layers.py includes all the layers we use in our model.

  • layer_transformer.py includes some layer transformers which widen, deepen, or add skip-connections to the layer.

  • nn.py includes the class which generates the initial network.

  • metric.py some metric classes including Accuracy and MSE.

  • utils.py is the example search network architectures for the cifar10 dataset, using Keras.

4. The Network Representation Json Example

Here is an example of the intermediate representation JSON file we defined, which is passed from the tuner to the trial in the architecture search procedure. Users can call the “json_to_graph()” function in the trial code to build a PyTorch or Keras model from this JSON file.

{
     "input_shape": [32, 32, 3],
     "weighted": false,
     "operation_history": [],
     "layer_id_to_input_node_ids": {"0": [0],"1": [1],"2": [2],"3": [3],"4": [4],"5": [5],"6": [6],"7": [7],"8": [8],"9": [9],"10": [10],"11": [11],"12": [12],"13": [13],"14": [14],"15": [15],"16": [16]
     },
     "layer_id_to_output_node_ids": {"0": [1],"1": [2],"2": [3],"3": [4],"4": [5],"5": [6],"6": [7],"7": [8],"8": [9],"9": [10],"10": [11],"11": [12],"12": [13],"13": [14],"14": [15],"15": [16],"16": [17]
     },
     "adj_list": {
         "0": [[1, 0]],
         "1": [[2, 1]],
         "2": [[3, 2]],
         "3": [[4, 3]],
         "4": [[5, 4]],
         "5": [[6, 5]],
         "6": [[7, 6]],
         "7": [[8, 7]],
         "8": [[9, 8]],
         "9": [[10, 9]],
         "10": [[11, 10]],
         "11": [[12, 11]],
         "12": [[13, 12]],
         "13": [[14, 13]],
         "14": [[15, 14]],
         "15": [[16, 15]],
         "16": [[17, 16]],
         "17": []
     },
     "reverse_adj_list": {
         "0": [],
         "1": [[0, 0]],
         "2": [[1, 1]],
         "3": [[2, 2]],
         "4": [[3, 3]],
         "5": [[4, 4]],
         "6": [[5, 5]],
         "7": [[6, 6]],
         "8": [[7, 7]],
         "9": [[8, 8]],
         "10": [[9, 9]],
         "11": [[10, 10]],
         "12": [[11, 11]],
         "13": [[12, 12]],
         "14": [[13, 13]],
         "15": [[14, 14]],
         "16": [[15, 15]],
         "17": [[16, 16]]
     },
     "node_list": [
         [0, [32, 32, 3]],
         [1, [32, 32, 3]],
         [2, [32, 32, 64]],
         [3, [32, 32, 64]],
         [4, [16, 16, 64]],
         [5, [16, 16, 64]],
         [6, [16, 16, 64]],
         [7, [16, 16, 64]],
         [8, [8, 8, 64]],
         [9, [8, 8, 64]],
         [10, [8, 8, 64]],
         [11, [8, 8, 64]],
         [12, [4, 4, 64]],
         [13, [64]],
         [14, [64]],
         [15, [64]],
         [16, [64]],
         [17, [10]]
     ],
     "layer_list": [
         [0, ["StubReLU", 0, 1]],
         [1, ["StubConv2d", 1, 2, 3, 64, 3]],
         [2, ["StubBatchNormalization2d", 2, 3, 64]],
         [3, ["StubPooling2d", 3, 4, 2, 2, 0]],
         [4, ["StubReLU", 4, 5]],
         [5, ["StubConv2d", 5, 6, 64, 64, 3]],
         [6, ["StubBatchNormalization2d", 6, 7, 64]],
         [7, ["StubPooling2d", 7, 8, 2, 2, 0]],
         [8, ["StubReLU", 8, 9]],
         [9, ["StubConv2d", 9, 10, 64, 64, 3]],
         [10, ["StubBatchNormalization2d", 10, 11, 64]],
         [11, ["StubPooling2d", 11, 12, 2, 2, 0]],
         [12, ["StubGlobalPooling2d", 12, 13]],
         [13, ["StubDropout2d", 13, 14, 0.25]],
         [14, ["StubDense", 14, 15, 64, 64]],
         [15, ["StubReLU", 15, 16]],
         [16, ["StubDense", 16, 17, 64, 10]]
     ]
 }

You can consider the model to be a directed acyclic graph. The definition of each model is a JSON object where:

  • input_shape is a list of integers which do not include the batch axis.

  • weighted means whether the weights and biases in the neural network should be included in the graph.

  • operation_history is a list saving all the network morphism operations.

  • layer_id_to_input_node_ids is a dictionary mapping from layer identifiers to their input nodes identifiers.

  • layer_id_to_output_node_ids is a dictionary mapping from layer identifiers to their output nodes identifiers

  • adj_list is a two-dimensional list; the adjacency list of the graph. The first dimension is identified by tensor identifiers. In each edge list, the elements are two-element tuples of (tensor identifier, layer identifier).

  • reverse_adj_list is a reverse adjacent list in the same format as adj_list.

  • node_list is a list of integers. The indices of the list are the identifiers.

  • layer_list is a list of stub layers. The indices of the list are the identifiers.

    • For StubConv (StubConv1d, StubConv2d, StubConv3d), the numbering follows the format: its node input id (or id list), node output id, input_channel, filters, kernel_size, stride, and padding.

    • For StubDense, the numbering follows the format: its node input id (or id list), node output id, input_units, and units.

    • For StubBatchNormalization (StubBatchNormalization1d, StubBatchNormalization2d, StubBatchNormalization3d), the numbering follows the format: its node input id (or id list), node output id, and features numbers.

    • For StubDropout(StubDropout1d, StubDropout2d, StubDropout3d), the numbering follows the format: its node input id (or id list), node output id, and dropout rate.

    • For StubPooling (StubPooling1d, StubPooling2d, StubPooling3d), the numbering follows the format: its node input id (or id list), node output id, kernel_size, stride, and padding.

    • For else layers, the numbering follows the format: its node input id (or id list) and node output id.

5. TODO

Next step, we will change the API from s fixed network generator to a network generator with more available operators. We will use ONNX instead of JSON later as the intermediate representation spec in the future.

Hyperband on NNI

1. Introduction

Hyperband is a popular autoML algorithm. The basic idea of Hyperband is to create several buckets, each having n randomly generated hyperparameter configurations, each configuration using r resources (e.g., epoch number, batch number). After the n configurations are finished, it chooses the top n/eta configurations and runs them using increased r*eta resources. At last, it chooses the best configuration it has found so far.

2. Implementation with full parallelism

First, this is an example of how to write an autoML algorithm based on MsgDispatcherBase, rather than Tuner and Assessor. Hyperband is implemented in this way because it integrates the functions of both Tuner and Assessor, thus, we call it Advisor.

Second, this implementation fully leverages Hyperband’s internal parallelism. Specifically, the next bucket is not started strictly after the current bucket. Instead, it starts when there are available resources. If you want to use full parallelism mode, set exec_mode with parallelism.

Or if you want to set exec_mode with serial according to the original algorithm. In this mode, the next bucket will start strictly after the current bucket.

parallelism mode may lead to multiple unfinished buckets, and there is at most one unfinished bucket under serial mode. The advantage of parallelism mode is to make full use of resources, which may reduce the experiment duration multiple times. The following two pictures are the results of quick verification using nas-bench-201, picture above is in parallelism mode, picture below is in serial mode.

parallelism mode serial mode

If you want to reproduce these results, refer to the example under examples/trials/benchmarking/ for details.

3. Usage

To use Hyperband, you should add the following spec in your experiment’s YAML config file:

advisor:
  #choice: Hyperband
  builtinAdvisorName: Hyperband
  classArgs:
    #R: the maximum trial budget
    R: 100
    #eta: proportion of discarded trials
    eta: 3
    #choice: maximize, minimize
    optimize_mode: maximize
    #choice: serial, parallelism
    exec_mode: parallelism

Note that once you use Advisor, you are not allowed to add a Tuner and Assessor spec in the config file. If you use Hyperband, among the hyperparameters (i.e., key-value pairs) received by a trial, there will be one more key called TRIAL_BUDGET defined by user. By using this ``TRIAL_BUDGET``, the trial can control how long it runs.

For report_intermediate_result(metric) and report_final_result(metric) in your trial code, ``metric`` should be either a number or a dict which has a key ``default`` with a number as its value. This number is the one you want to maximize or minimize, for example, accuracy or loss.

R and eta are the parameters of Hyperband that you can change. R means the maximum trial budget that can be allocated to a configuration. Here, trial budget could mean the number of epochs or mini-batches. This TRIAL_BUDGET should be used by the trial to control how long it runs. Refer to the example under examples/trials/mnist-advisor/ for details.

eta means n/eta configurations from n configurations will survive and rerun using more budgets.

Here is a concrete example of R=81 and eta=3:

s=4

s=3

s=2

s=1

s=0

i

n r

n r

n r

n r

n r

0

81 1

27 3

9 9

6 27

5 81

1

27 3

9 9

3 27

2 81

2

9 9

3 27

1 81

3

3 27

1 81

4

1 81

s means bucket, n means the number of configurations that are generated, the corresponding r means how many budgets these configurations run. i means round, for example, bucket 4 has 5 rounds, bucket 3 has 4 rounds.

For information about writing trial code, please refer to the instructions under examples/trials/mnist-hyperband/.

4. Future improvements

The current implementation of Hyperband can be further improved by supporting a simple early stop algorithm since it’s possible that not all the configurations in the top n/eta perform well. Any unpromising configurations should be stopped early.

In the current implementation, configurations are generated randomly which follows the design in the paper. As an improvement, configurations could be generated more wisely by leveraging advanced algorithms.

BOHB Advisor on NNI

1. Introduction

BOHB is a robust and efficient hyperparameter tuning algorithm mentioned in this reference paper. BO is an abbreviation for “Bayesian Optimization” and HB is an abbreviation for “Hyperband”.

BOHB relies on HB (Hyperband) to determine how many configurations to evaluate with which budget, but it replaces the random selection of configurations at the beginning of each HB iteration by a model-based search (Bayesian Optimization). Once the desired number of configurations for the iteration is reached, the standard successive halving procedure is carried out using these configurations. We keep track of the performance of all function evaluations g(x, b) of configurations x on all budgets b to use as a basis for our models in later iterations.

Below we divide the introduction of the BOHB process into two parts:

HB (Hyperband)

We follow Hyperband’s way of choosing the budgets and continue to use SuccessiveHalving. For more details, you can refer to the Hyperband in NNI and the reference paper for Hyperband. This procedure is summarized by the pseudocode below.

BO (Bayesian Optimization)

The BO part of BOHB closely resembles TPE with one major difference: we opted for a single multidimensional KDE compared to the hierarchy of one-dimensional KDEs used in TPE in order to better handle interaction effects in the input space.

Tree Parzen Estimator(TPE): uses a KDE (kernel density estimator) to model the densities.

To fit useful KDEs, we require a minimum number of data points Nmin; this is set to d + 1 for our experiments, where d is the number of hyperparameters. To build a model as early as possible, we do not wait until Nb = |Db|, where the number of observations for budget b is large enough to satisfy q · Nb ≥ Nmin. Instead, after initializing with Nmin + 2 random configurations, we choose the

best and worst configurations, respectively, to model the two densities.

Note that we also sample a constant fraction named random fraction of the configurations uniformly at random.

2. Workflow
This image shows the workflow of BOHB. Here we set max_budget = 9, min_budget = 1, eta = 3, others as default. In this case, s_max = 2, so we will continuously run the {s=2, s=1, s=0, s=2, s=1, s=0, …} cycle. In each stage of SuccessiveHalving (the orange box), we will pick the top 1/eta configurations and run them again with more budget, repeating the SuccessiveHalving stage until the end of this iteration. At the same time, we collect the configurations, budgets and final metrics of each trial and use these to build a multidimensional KDEmodel with the key “budget”.

Multidimensional KDE is used to guide the selection of configurations for the next iteration.

The sampling procedure (using Multidimensional KDE to guide selection) is summarized by the pseudocode below.

3. Usage

BOHB advisor requires the ConfigSpace package. ConfigSpace can be installed using the following command.

pip install nni[BOHB]

To use BOHB, you should add the following spec in your experiment’s YAML config file:

advisor:
  builtinAdvisorName: BOHB
  classArgs:
    optimize_mode: maximize
    min_budget: 1
    max_budget: 27
    eta: 3
    min_points_in_model: 7
    top_n_percent: 15
    num_samples: 64
    random_fraction: 0.33
    bandwidth_factor: 3.0
    min_bandwidth: 0.001

classArgs Requirements:

  • optimize_mode (maximize or minimize, optional, default = maximize) - If ‘maximize’, tuners will try to maximize metrics. If ‘minimize’, tuner will try to minimize metrics.

  • min_budget (int, optional, default = 1) - The smallest budget to assign to a trial job, (budget can be the number of mini-batches or epochs). Needs to be positive.

  • max_budget (int, optional, default = 3) - The largest budget to assign to a trial job, (budget can be the number of mini-batches or epochs). Needs to be larger than min_budget.

  • eta (int, optional, default = 3) - In each iteration, a complete run of sequential halving is executed. In it, after evaluating each configuration on the same subset size, only a fraction of 1/eta of them ‘advances’ to the next round. Must be greater or equal to 2.

  • min_points_in_model(int, optional, default = None): number of observations to start building a KDE. Default ‘None’ means dim+1; when the number of completed trials in this budget is equal to or larger than max{dim+1, min_points_in_model}, BOHB will start to build a KDE model of this budget then use said KDE model to guide configuration selection. Needs to be positive. (dim means the number of hyperparameters in search space)

  • top_n_percent(int, optional, default = 15): percentage (between 1 and 99) of the observations which are considered good. Good points and bad points are used for building KDE models. For example, if you have 100 observed trials and top_n_percent is 15, then the top 15% of points will be used for building the good points models “l(x)”. The remaining 85% of points will be used for building the bad point models “g(x)”.

  • num_samples(int, optional, default = 64): number of samples to optimize EI (default 64). In this case, we will sample “num_samples” points and compare the result of l(x)/g(x). Then we will return the one with the maximum l(x)/g(x) value as the next configuration if the optimize_mode is maximize. Otherwise, we return the smallest one.

  • random_fraction(float, optional, default = 0.33): fraction of purely random configurations that are sampled from the prior without the model.

  • bandwidth_factor(float, optional, default = 3.0): to encourage diversity, the points proposed to optimize EI are sampled from a ‘widened’ KDE where the bandwidth is multiplied by this factor. We suggest using the default value if you are not familiar with KDE.

  • min_bandwidth(float, optional, default = 0.001): to keep diversity, even when all (good) samples have the same value for one of the parameters, a minimum bandwidth (default: 1e-3) is used instead of zero. We suggest using the default value if you are not familiar with KDE.

Please note that the float type currently only supports decimal representations. You have to use 0.333 instead of 1/3 and 0.001 instead of 1e-3.

4. File Structure

The advisor has a lot of different files, functions, and classes. Here, we will only give most of those files a brief introduction:

  • bohb_advisor.py Definition of BOHB, handles interaction with the dispatcher, including generating new trials and processing results. Also includes the implementation of the HB (Hyperband) part.

  • config_generator.py Includes the implementation of the BO (Bayesian Optimization) part. The function get_config can generate new configurations based on BO; the function new_result will update the model with the new result.

5. Experiment
MNIST with BOHB

code implementation: examples/trials/mnist-advisor

We chose BOHB to build a CNN on the MNIST dataset. The following is our experimental final results:

More experimental results can be found in the reference paper. We can see that BOHB makes good use of previous results and has a balanced trade-off in exploration and exploitation.

PPO Tuner on NNI

PPOTuner

This is a tuner geared for NNI’s Neural Architecture Search (NAS) interface. It uses the ppo algorithm. The implementation inherits the main logic of the ppo2 OpenAI implementation here and is adapted for the NAS scenario.

We had successfully tuned the mnist-nas example and has the following result:

Note

we are refactoring this example to the latest NAS interface, will publish the example codes after the refactor.

We also tune the macro search space for image classification in the enas paper (with a limited epoch number for each trial, i.e., 8 epochs), which is implemented using the NAS interface and tuned with PPOTuner. Here is Figure 7 from the enas paper to show what the search space looks like

The figure above was the chosen architecture. Each square is a layer whose operation was chosen from 6 options. Each dashed line is a skip connection, each square layer can choose 0 or 1 skip connections, getting the output from a previous layer. Note that, in original macro search space, each square layer could choose any number of skip connections, while in our implementation, it is only allowed to choose 0 or 1.

The results are shown in figure below (see the experimenal config here:

PBT Tuner on NNI

PBTTuner

Population Based Training (PBT) comes from Population Based Training of Neural Networks. It’s a simple asynchronous optimization algorithm which effectively utilizes a fixed computational budget to jointly optimize a population of models and their hyperparameters to maximize performance. Importantly, PBT discovers a schedule of hyperparameter settings rather than following the generally sub-optimal strategy of trying to find a single fixed set to use for the whole course of training.

PBTTuner initializes a population with several trials (i.e., population_size). There are four steps in the above figure, each trial only runs by one step. How long is one step is controlled by trial code, e.g., one epoch. When a trial starts, it loads a checkpoint specified by PBTTuner and continues to run one step, then saves checkpoint to a directory specified by PBTTuner and exits. The trials in a population run steps synchronously, that is, after all the trials finish the i-th step, the (i+1)-th step can be started. Exploitation and exploration of PBT are executed between two consecutive steps.

Provide checkpoint directory

Since some trials need to load other trial’s checkpoint, users should provide a directory (i.e., all_checkpoint_dir) which is accessible by every trial. It is easy for local mode, users could directly use the default directory or specify any directory on the local machine. For other training services, users should follow the document of those training services to provide a directory in a shared storage, such as NFS, Azure storage.

Modify your trial code

Before running a step, a trial needs to load a checkpoint, the checkpoint directory is specified in hyper-parameter configuration generated by PBTTuner, i.e., params['load_checkpoint_dir']. Similarly, the directory for saving checkpoint is also included in the configuration, i.e., params['save_checkpoint_dir']. Here, all_checkpoint_dir is base folder of load_checkpoint_dir and save_checkpoint_dir whose format is all_checkpoint_dir/<population-id>/<step>.

params = nni.get_next_parameter()
# the path of the checkpoint to load
load_path = os.path.join(params['load_checkpoint_dir'], 'model.pth')
# load checkpoint from `load_path`
...
# run one step
...
# the path for saving a checkpoint
save_path = os.path.join(params['save_checkpoint_dir'], 'model.pth')
# save checkpoint to `save_path`
...

The complete example code can be found here.

Experiment config

Below is an exmaple of PBTTuner configuration in experiment config file. Note that Assessor is not allowed if PBTTuner is used.

# config.yml
tuner:
  builtinTunerName: PBTTuner
  classArgs:
    optimize_mode: maximize
    all_checkpoint_dir: /the/path/to/store/checkpoints
    population_size: 10

Builtin-Assessors

In order to save on computing resources, NNI supports an early stopping policy and has an interface called Assessor to do this job.

Assessor receives the intermediate result from a trial and decides whether the trial should be killed using a specific algorithm. Once the trial experiment meets the early stopping conditions (which means Assessor is pessimistic about the final results), the assessor will kill the trial and the status of the trial will be EARLY_STOPPED.

Here is an experimental result of MNIST after using the ‘Curvefitting’ Assessor in ‘maximize’ mode. You can see that Assessor successfully early stopped many trials with bad hyperparameters in advance. If you use Assessor, you may get better hyperparameters using the same computing resources.

Implemented code directory: config_assessor.yml

_images/Assessor.png

Built-in Assessors

NNI provides state-of-the-art tuning algorithms within our builtin-assessors and makes them easy to use. Below is a brief overview of NNI’s current builtin Assessors.

Note: Click the Assessor’s name to get each Assessor’s installation requirements, suggested usage scenario, and a config example. A link to a detailed description of each algorithm is provided at the end of the suggested scenario for each Assessor.

Currently, we support the following Assessors:

Assessor

Brief Introduction of Algorithm

Medianstop

Medianstop is a simple early stopping rule. It stops a pending trial X at step S if the trial’s best objective value by step S is strictly worse than the median value of the running averages of all completed trials’ objectives reported up to step S. Reference Paper

Curvefitting

Curve Fitting Assessor is an LPA (learning, predicting, assessing) algorithm. It stops a pending trial X at step S if the prediction of the final epoch’s performance worse than the best final performance in the trial history. In this algorithm, we use 12 curves to fit the accuracy curve. Reference Paper

Usage of Builtin Assessors

Usage of builtin assessors provided by the NNI SDK requires one to declare the builtinAssessorName and classArgs in the config.yml file. In this part, we will introduce the details of usage and the suggested scenarios, classArg requirements, and an example for each assessor.

Note: Please follow the provided format when writing your config.yml file.

Median Stop Assessor

Builtin Assessor Name: Medianstop

Suggested scenario

It’s applicable in a wide range of performance curves, thus, it can be used in various scenarios to speed up the tuning progress. Detailed Description

classArgs requirements:

  • optimize_mode (maximize or minimize, optional, default = maximize) - If ‘maximize’, assessor will stop the trial with smaller expectation. If ‘minimize’, assessor will stop the trial with larger expectation.

  • start_step (int, optional, default = 0) - A trial is determined to be stopped or not only after receiving start_step number of reported intermediate results.

Usage example:

# config.yml
assessor:
    builtinAssessorName: Medianstop
    classArgs:
      optimize_mode: maximize
      start_step: 5


Curve Fitting Assessor

Builtin Assessor Name: Curvefitting

Suggested scenario

It’s applicable in a wide range of performance curves, thus, it can be used in various scenarios to speed up the tuning progress. Even better, it’s able to handle and assess curves with similar performance. Detailed Description

Note, according to the original paper, only incremental functions are supported. Therefore this assessor can only be used to maximize optimization metrics. For example, it can be used for accuracy, but not for loss.

classArgs requirements:

  • epoch_num (int,* required***) - The total number of epochs. We need to know the number of epochs to determine which points we need to predict.

  • start_step (int, optional, default = 6) - A trial is determined to be stopped or not only after receiving start_step number of reported intermediate results.

  • threshold (float, optional, default = 0.95) - The threshold that we use to decide to early stop the worst performance curve. For example: if threshold = 0.95, and the best performance in the history is 0.9, then we will stop the trial who’s predicted value is lower than 0.95 * 0.9 = 0.855.

  • gap (int, optional, default = 1) - The gap interval between Assessor judgements. For example: if gap = 2, start_step = 6, then we will assess the result when we get 6, 8, 10, 12…intermediate results.

Usage example:

# config.yml
assessor:
    builtinAssessorName: Curvefitting
    classArgs:
      epoch_num: 20
      start_step: 6
      threshold: 0.95
      gap: 1

Medianstop Assessor on NNI

Median Stop

Medianstop is a simple early stopping rule mentioned in this paper. It stops a pending trial X after step S if the trial’s best objective value by step S is strictly worse than the median value of the running averages of all completed trials’ objectives reported up to step S.

Curve Fitting Assessor on NNI

Introduction

The Curve Fitting Assessor is an LPA (learning, predicting, assessing) algorithm. It stops a pending trial X at step S if the prediction of the final epoch’s performance is worse than the best final performance in the trial history.

In this algorithm, we use 12 curves to fit the learning curve. The set of parametric curve models are chosen from this reference paper. The learning curves’ shape coincides with our prior knowledge about the form of learning curves: They are typically increasing, saturating functions.

learning_curve

We combine all learning curve models into a single, more powerful model. This combined model is given by a weighted linear combination:

f_comb

with the new combined parameter vector

expression_xi

Assuming additive Gaussian noise and the noise parameter being initialized to its maximum likelihood estimate.

We determine the maximum probability value of the new combined parameter vector by learning the historical data. We use such a value to predict future trial performance and stop the inadequate experiments to save computing resources.

Concretely, this algorithm goes through three stages of learning, predicting, and assessing.

  • Step1: Learning. We will learn about the trial history of the current trial and determine the xi at the Bayesian angle. First of all, We fit each curve using the least-squares method, implemented by fit_theta. After we obtained the parameters, we filter the curve and remove the outliers, implemented by filter_curve. Finally, we use the MCMC sampling method. implemented by mcmc_sampling, to adjust the weight of each curve. Up to now, we have determined all the parameters in xi.

  • Step2: Predicting. It calculates the expected final result accuracy, implemented by f_comb, at the target position (i.e., the total number of epochs) by xi and the formula of the combined model.

  • Step3: If the fitting result doesn’t converge, the predicted value will be None. In this case, we return AssessResult.Good to ask for future accuracy information and predict again. Furthermore, we will get a positive value from the predict() function. If this value is strictly greater than the best final performance in history * THRESHOLD(default value = 0.95), return AssessResult.Good, otherwise, return AssessResult.Bad

The figure below is the result of our algorithm on MNIST trial history data, where the green point represents the data obtained by Assessor, the blue point represents the future but unknown data, and the red line is the Curve predicted by the Curve fitting assessor.

examples
Usage

To use Curve Fitting Assessor, you should add the following spec in your experiment’s YAML config file:

assessor:
  builtinAssessorName: Curvefitting
  classArgs:
    # (required)The total number of epoch.
    #  We need to know the number of epoch to determine which point we need to predict.
    epoch_num: 20
    # (optional) In order to save our computing resource, we start to predict when we have more than only after receiving start_step number of reported intermediate results.
    # The default value of start_step is 6.
    start_step: 6
    # (optional) The threshold that we decide to early stop the worse performance curve.
    # For example: if threshold = 0.95, best performance in the history is 0.9, then we will stop the trial which predict value is lower than 0.95 * 0.9 = 0.855.
    # The default value of threshold is 0.95.
    threshold: 0.95
    # (optional) The gap interval between Assesor judgements.
    # For example: if gap = 2, start_step = 6, then we will assess the result when we get 6, 8, 10, 12...intermedian result.
    # The default value of gap is 1.
    gap: 1
Limitation

According to the original paper, only incremental functions are supported. Therefore this assessor can only be used to maximize optimization metrics. For example, it can be used for accuracy, but not for loss.

File Structure

The assessor has a lot of different files, functions, and classes. Here we briefly describe a few of them.

  • curvefunctions.py includes all the function expressions and default parameters.

  • modelfactory.py includes learning and predicting; the corresponding calculation part is also implemented here.

  • curvefitting_assessor.py is the assessor which receives the trial history and assess whether to early stop the trial.

TODO
  • Further improve the accuracy of the prediction and test it on more models.

Introduction to NNI Training Services

Training Service

What is Training Service?

NNI training service is designed to allow users to focus on AutoML itself, agnostic to the underlying computing infrastructure where the trials are actually run. When migrating from one cluster to another (e.g., local machine to Kubeflow), users only need to tweak several configurations, and the experiment can be easily scaled.

Users can use training service provided by NNI, to run trial jobs on local machine, remote machines, and on clusters like PAI, Kubeflow, AdaptDL, FrameworkController, DLTS and AML. These are called built-in training services.

If the computing resource customers try to use is not listed above, NNI provides interface that allows users to build their own training service easily. Please refer to how to implement training service for details.

How to use Training Service?

Training service needs to be chosen and configured properly in experiment configuration YAML file. Users could refer to the document of each training service for how to write the configuration. Also, reference provides more details on the specification of the experiment configuration file.

Next, users should prepare code directory, which is specified as codeDir in config file. Please note that in non-local mode, the code directory will be uploaded to remote or cluster before the experiment. Therefore, we limit the number of files to 2000 and total size to 300MB. If the code directory contains too many files, users can choose which files and subfolders should be excluded by adding a .nniignore file that works like a .gitignore file. For more details on how to write this file, see this example and the git documentation.

In case users intend to use large files in their experiment (like large-scaled datasets) and they are not using local mode, they can either: 1) download the data before each trial launches by putting it into trial command; or 2) use a shared storage that is accessible to worker nodes. Usually, training platforms are equipped with shared storage, and NNI allows users to easily use them. Refer to docs of each built-in training service for details.

Built-in Training Services

TrainingService

Brief Introduction

Local

NNI supports running an experiment on local machine, called local mode. Local mode means that NNI will run the trial jobs and nniManager process in same machine, and support gpu schedule function for trial jobs.

Remote

NNI supports running an experiment on multiple machines through SSH channel, called remote mode. NNI assumes that you have access to those machines, and already setup the environment for running deep learning training code. NNI will submit the trial jobs in remote machine, and schedule suitable machine with enough gpu resource if specified.

PAI

NNI supports running an experiment on OpenPAI (aka PAI), called PAI mode. Before starting to use NNI PAI mode, you should have an account to access an OpenPAI cluster. See here if you don’t have any OpenPAI account and want to deploy an OpenPAI cluster. In PAI mode, your trial program will run in PAI’s container created by Docker.

Kubeflow

NNI supports running experiment on Kubeflow, called kubeflow mode. Before starting to use NNI kubeflow mode, you should have a Kubernetes cluster, either on-premises or Azure Kubernetes Service(AKS), a Ubuntu machine on which kubeconfig is setup to connect to your Kubernetes cluster. If you are not familiar with Kubernetes, here is a good start. In kubeflow mode, your trial program will run as Kubeflow job in Kubernetes cluster.

AdaptDL

NNI supports running experiment on AdaptDL, called AdaptDL mode. Before starting to use AdaptDL mode, you should have a Kubernetes cluster.

FrameworkController

NNI supports running experiment using FrameworkController, called frameworkcontroller mode. FrameworkController is built to orchestrate all kinds of applications on Kubernetes, you don’t need to install Kubeflow for specific deep learning framework like tf-operator or pytorch-operator. Now you can use FrameworkController as the training service to run NNI experiment.

DLTS

NNI supports running experiment using DLTS, which is an open source toolkit, developed by Microsoft, that allows AI scientists to spin up an AI cluster in turn-key fashion.

AML

NNI supports running an experiment on AML , called aml mode.

What does Training Service do?

drawing

According to the architecture shown in Overview, training service (platform) is actually responsible for two events: 1) initiating a new trial; 2) collecting metrics and communicating with NNI core (NNI manager); 3) monitoring trial job status. To demonstrated in detail how training service works, we show the workflow of training service from the very beginning to the moment when first trial succeeds.

Step 1. Validate config and prepare the training platform. Training service will first check whether the training platform user specifies is valid (e.g., is there anything wrong with authentication). After that, training service will start to prepare for the experiment by making the code directory (codeDir) accessible to training platform.

Note

Different training services have different ways to handle codeDir. For example, local training service directly runs trials in codeDir. Remote training service packs codeDir into a zip and uploads it to each machine. K8S-based training services copy codeDir onto a shared storage, which is either provided by training platform itself, or configured by users in config file.

Step 2. Submit the first trial. To initiate a trial, usually (in non-reuse mode), NNI copies another few files (including parameters, launch script and etc.) onto training platform. After that, NNI launches the trial through subprocess, SSH, RESTful API, and etc.

Warning

The working directory of trial command has exactly the same content as codeDir, but can have different paths (even on different machines) Local mode is the only training service that shares one codeDir across all trials. Other training services copies a codeDir from the shared copy prepared in step 1 and each trial has an independent working directory. We strongly advise users not to rely on the shared behavior in local mode, as it will make your experiments difficult to scale to other training services.

Step 3. Collect metrics. NNI then monitors the status of trial, updates the status (e.g., from WAITING to RUNNING, RUNNING to SUCCEEDED) recorded, and also collects the metrics. Currently, most training services are implemented in an “active” way, i.e., training service will call the RESTful API on NNI manager to update the metrics. Note that this usually requires the machine that runs NNI manager to be at least accessible to the worker node.

Tutorial: Create and Run an Experiment on local with NNI API

In this tutorial, we will use the example in [nni/examples/trials/mnist-pytorch] to explain how to create and run an experiment on local with NNI API.

Before starts

You have an implementation for MNIST classifer using convolutional layers, the Python code is in mnist_before.py.

Step 1 - Update model codes

To enable NNI API, make the following changes:

1.1 Declare NNI API: include import nni in your trial code to use NNI APIs.

1.2 Get predefined parameters

Use the following code snippet:

tuner_params = nni.get_next_parameter()

to get hyper-parameters’ values assigned by tuner. tuner_params is an object, for example:

{"batch_size": 32, "hidden_size": 128, "lr": 0.01, "momentum": 0.2029}

1.3 Report NNI results: Use the API: nni.report_intermediate_result(accuracy) to send accuracy to assessor. Use the API: nni.report_final_result(accuracy) to send accuracy to tuner.

We had made the changes and saved it to mnist.py.

NOTE:

accuracy - The `accuracy` could be any python object, but  if you use NNI built-in tuner/assessor, `accuracy` should be a numerical variable (e.g. float, int).
assessor - The assessor will decide which trial should early stop based on the history performance of trial (intermediate result of one trial).
tuner    - The tuner will generate next parameters/architecture based on the explore history (final result of all trials).

Step 2 - Define SearchSpace

The hyper-parameters used in Step 1.2 - Get predefined parameters is defined in a search_space.json file like below:

{
    "batch_size": {"_type":"choice", "_value": [16, 32, 64, 128]},
    "hidden_size":{"_type":"choice","_value":[128, 256, 512, 1024]},
    "lr":{"_type":"choice","_value":[0.0001, 0.001, 0.01, 0.1]},
    "momentum":{"_type":"uniform","_value":[0, 1]}
}

Refer to define search space to learn more about search space.

Step 3 - Define Experiment

3.1 enable NNI API mode

To enable NNI API mode, you need to set useAnnotation to false and provide the path of SearchSpace file (you just defined in step 1):

useAnnotation: false
searchSpacePath: /path/to/your/search_space.json

To run an experiment in NNI, you only needed:

  • Provide a runnable trial

  • Provide or choose a tuner

  • Provide a YAML experiment configure file

  • (optional) Provide or choose an assessor

Prepare trial:

You can download nni source code and a set of examples can be found in nni/examples, run ls nni/examples/trials to see all the trial examples.

Let’s use a simple trial example, e.g. mnist, provided by NNI. After you installed NNI, NNI examples have been put in ~/nni/examples, run ls ~/nni/examples/trials to see all the trial examples. You can simply execute the following command to run the NNI mnist example:

python ~/nni/examples/trials/mnist-annotation/mnist.py

This command will be filled in the YAML configure file below. Please refer to here for how to write your own trial.

Prepare tuner: NNI supports several popular automl algorithms, including Random Search, Tree of Parzen Estimators (TPE), Evolution algorithm etc. Users can write their own tuner (refer to here), but for simplicity, here we choose a tuner provided by NNI as below:

tuner:
  builtinTunerName: TPE
  classArgs:
    optimize_mode: maximize

builtinTunerName is used to specify a tuner in NNI, classArgs are the arguments pass to the tuner (the spec of builtin tuners can be found here), optimization_mode is to indicate whether you want to maximize or minimize your trial’s result.

Prepare configure file: Since you have already known which trial code you are going to run and which tuner you are going to use, it is time to prepare the YAML configure file. NNI provides a demo configure file for each trial example, cat ~/nni/examples/trials/mnist-annotation/config.yml to see it. Its content is basically shown below:

authorName: your_name
experimentName: auto_mnist

# how many trials could be concurrently running
trialConcurrency: 1

# maximum experiment running duration
maxExecDuration: 3h

# empty means never stop
maxTrialNum: 100

# choice: local, remote
trainingServicePlatform: local

# search space file
searchSpacePath: search_space.json

# choice: true, false
useAnnotation: true
tuner:
  builtinTunerName: TPE
  classArgs:
    optimize_mode: maximize
trial:
  command: python mnist.py
  codeDir: ~/nni/examples/trials/mnist-annotation
  gpuNum: 0

Here useAnnotation is true because this trial example uses our python annotation (refer to here for details). For trial, we should provide trialCommand which is the command to run the trial, provide trialCodeDir where the trial code is. The command will be executed in this directory. We should also provide how many GPUs a trial requires.

With all these steps done, we can run the experiment with the following command:

nnictl create --config ~/nni/examples/trials/mnist-annotation/config.yml

You can refer to here for more usage guide of nnictl command line tool.

View experiment results

The experiment has been running now. Other than nnictl, NNI also provides WebUI for you to view experiment progress, to control your experiment, and some other appealing features.

Run an Experiment on Remote Machines

NNI can run one experiment on multiple remote machines through SSH, called remote mode. It’s like a lightweight training platform. In this mode, NNI can be started from your computer, and dispatch trials to remote machines in parallel.

The OS of remote machines supports Linux, Windows 10, and Windows Server 2019.

Requirements
  • Make sure the default environment of remote machines meets requirements of your trial code. If the default environment does not meet the requirements, the setup script can be added into command field of NNI config.

  • Make sure remote machines can be accessed through SSH from the machine which runs nnictl command. It supports both password and key authentication of SSH. For advanced usages, please refer to machineList part of configuration.

  • Make sure the NNI version on each machine is consistent.

  • Make sure the command of Trial is compatible with remote OSes, if you want to use remote Linux and Windows together. For example, the default python 3.x executable called python3 on Linux, and python on Windows.

Linux
Windows
  • Follow installation to install NNI on the remote machine.

  • Install and start OpenSSH Server.

    1. Open Settings app on Windows.

    2. Click Apps, then click Optional features.

    3. Click Add a feature, search and select OpenSSH Server, and then click Install.

    4. Once it’s installed, run below command to start and set to automatic start.

    sc config sshd start=auto
    net start sshd
    
  • Make sure remote account is administrator, so that it can stop running trials.

  • Make sure there is no welcome message more than default, since it causes ssh2 failed in NodeJs. For example, if you’re using Data Science VM on Azure, it needs to remove extra echo commands in C:\dsvm\tools\setup\welcome.bat.

    The output like below is ok, when opening a new command window.

    Microsoft Windows [Version 10.0.17763.1192]
    (c) 2018 Microsoft Corporation. All rights reserved.
    
    (py37_default) C:\Users\AzureUser>
    
Run an experiment

e.g. there are three machines, which can be logged in with username and password.

IP

Username

Password

10.1.1.1

bob

bob123

10.1.1.2

bob

bob123

10.1.1.3

bob

bob123

Install and run NNI on one of those three machines or another machine, which has network access to them.

Use examples/trials/mnist-annotation as the example. Below is content of examples/trials/mnist-annotation/config_remote.yml:

authorName: default
experimentName: example_mnist
trialConcurrency: 1
maxExecDuration: 1h
maxTrialNum: 10
#choice: local, remote, pai
trainingServicePlatform: remote
# search space file
searchSpacePath: search_space.json
#choice: true, false
useAnnotation: true
tuner:
  #choice: TPE, Random, Anneal, Evolution, BatchTuner
  #SMAC (SMAC should be installed through nnictl)
  builtinTunerName: TPE
  classArgs:
    #choice: maximize, minimize
    optimize_mode: maximize
trial:
  command: python3 mnist.py
  codeDir: .
  gpuNum: 0
#machineList can be empty if the platform is local
machineList:
  - ip: 10.1.1.1
    username: bob
    passwd: bob123
    #port can be skip if using default ssh port 22
    #port: 22
  - ip: 10.1.1.2
    username: bob
    passwd: bob123
  - ip: 10.1.1.3
    username: bob
    passwd: bob123

Files in codeDir will be uploaded to remote machines automatically. You can run below command on Windows, Linux, or macOS to spawn trials on remote Linux machines:

nnictl create --config examples/trials/mnist-annotation/config_remote.yml
Configure python environment

By default, commands and scripts will be executed in the default environment in remote machine. If there are multiple python virtual environments in your remote machine, and you want to run experiments in a specific environment, then use pythonPath to specify a python environment on your remote machine.

Use examples/trials/mnist-tfv2 as the example. Below is content of examples/trials/mnist-tfv2/config_remote.yml:

authorName: default
experimentName: example_mnist
trialConcurrency: 1
maxExecDuration: 1h
maxTrialNum: 10
#choice: local, remote, pai
trainingServicePlatform: remote
searchSpacePath: search_space.json
#choice: true, false
useAnnotation: false
tuner:
  #choice: TPE, Random, Anneal, Evolution, BatchTuner, MetisTuner
  #SMAC (SMAC should be installed through nnictl)
  builtinTunerName: TPE
  classArgs:
    #choice: maximize, minimize
    optimize_mode: maximize
trial:
  command: python3 mnist.py
  codeDir: .
  gpuNum: 0
#machineList can be empty if the platform is local
machineList:
  - ip: ${replace_to_your_remote_machine_ip}
    username: ${replace_to_your_remote_machine_username}
    sshKeyPath: ${replace_to_your_remote_machine_sshKeyPath}
    # Below is an example of specifying python environment.
    pythonPath: ${replace_to_python_environment_path_in_your_remote_machine}

Remote machine supports running experiment in reuse mode. In this mode, NNI will reuse remote machine jobs to run as many as possible trials. It can save time of creating new jobs. User needs to make sure each trial can run independent in the same job, for example, avoid loading checkpoint from previous trials. Follow the setting to enable reuse mode:

remoteConfig:
  reuse: true

Run an Experiment on OpenPAI

NNI supports running an experiment on OpenPAI, called pai mode. Before starting to use NNI pai mode, you should have an account to access an OpenPAI cluster. See here if you don’t have any OpenPAI account and want to deploy an OpenPAI cluster. In pai mode, your trial program will run in pai’s container created by Docker.

Setup environment

Step 1. Install NNI, follow the install guide here.

Step 2. Get token.

Open web portal of OpenPAI, and click My profile button in the top-right side.

_images/pai_profile.jpg

Click copy button in the page to copy a jwt token.

_images/pai_token.jpg

Step 3. Mount NFS storage to local machine.

Click Submit job button in web portal.

_images/pai_job_submission_page.jpg

Find the data management region in job submission page.

_images/pai_data_management_page.jpg

The Preview container paths is the NFS host and path that OpenPAI provided, you need to mount the corresponding host and path to your local machine first, then NNI could use the OpenPAI’s NFS storage.
For example, use the following command:

sudo mount -t nfs4 gcr-openpai-infra02:/pai/data /local/mnt

Then the /data folder in container will be mounted to /local/mnt folder in your local machine.
You could use the following configuration in your NNI’s config file:

nniManagerNFSMountPath: /local/mnt

Step 4. Get OpenPAI’s storage config name and nniManagerMountPath

The Team share storage field is storage configuration used to specify storage value in OpenPAI. You can get paiStorageConfigName and containerNFSMountPath field in Team share storage, for example:

paiStorageConfigName: confignfs-data
containerNFSMountPath: /mnt/confignfs-data
Run an experiment

Use examples/trials/mnist-annotation as an example. The NNI config YAML file’s content is like:

authorName: your_name
experimentName: auto_mnist
# how many trials could be concurrently running
trialConcurrency: 2
# maximum experiment running duration
maxExecDuration: 3h
# empty means never stop
maxTrialNum: 100
# choice: local, remote, pai
trainingServicePlatform: pai
# search space file
searchSpacePath: search_space.json
# choice: true, false
useAnnotation: true
tuner:
  builtinTunerName: TPE
  classArgs:
    optimize_mode: maximize
trial:
  command: python3 mnist.py
  codeDir: ~/nni/examples/trials/mnist-annotation
  gpuNum: 0
  cpuNum: 1
  memoryMB: 8196
  image: msranni/nni:latest
  virtualCluster: default
  nniManagerNFSMountPath: /local/mnt
  containerNFSMountPath: /mnt/confignfs-data
  paiStorageConfigName: confignfs-data
# Configuration to access OpenPAI Cluster
paiConfig:
  userName: your_pai_nni_user
  token: your_pai_token
  host: 10.1.1.1
  # optional, experimental feature.
  reuse: true

Note: You should set trainingServicePlatform: pai in NNI config YAML file if you want to start experiment in pai mode. The host field in configuration file is PAI’s job submission page uri, like 10.10.5.1, the default http protocol in NNI is http, if your PAI’s cluster enabled https, please use the uri in https://10.10.5.1 format.

Trial configurations

Compared with LocalMode and RemoteMachineMode, trial configuration in pai mode has the following additional keys:

  • cpuNum

    Optional key. Should be positive number based on your trial program’s CPU requirement. If it is not set in trial configuration, it should be set in the config file specified in paiConfigPath field.

  • memoryMB

    Optional key. Should be positive number based on your trial program’s memory requirement. If it is not set in trial configuration, it should be set in the config file specified in paiConfigPath field.

  • image

    Optional key. In pai mode, your trial program will be scheduled by OpenPAI to run in Docker container. This key is used to specify the Docker image used to create the container in which your trial will run.

    We already build a docker image nnimsra/nni. You can either use this image directly in your config file, or build your own image based on it. If it is not set in trial configuration, it should be set in the config file specified in paiConfigPath field.

  • virtualCluster

    Optional key. Set the virtualCluster of OpenPAI. If omitted, the job will run on default virtual cluster.

  • nniManagerNFSMountPath

    Required key. Set the mount path in your nniManager machine.

  • containerNFSMountPath

    Required key. Set the mount path in your container used in OpenPAI.

  • paiStorageConfigName:

    Optional key. Set the storage name used in OpenPAI. If it is not set in trial configuration, it should be set in the config file specified in paiConfigPath field.

  • command

    Optional key. Set the commands used in OpenPAI container.

  • paiConfigPath Optional key. Set the file path of OpenPAI job configuration, the file is in yaml format.

    If users set paiConfigPath in NNI’s configuration file, no need to specify the fields command, paiStorageConfigName, virtualCluster, image, memoryMB, cpuNum, gpuNum in trial configuration. These fields will use the values from the config file specified by paiConfigPath.

    Note:

    1. The job name in OpenPAI’s configuration file will be replaced by a new job name, the new job name is created by NNI, the name format is nni_exp_{this.experimentId}_trial_{trialJobId} .

    2. If users set multiple taskRoles in OpenPAI’s configuration file, NNI will wrap all of these taksRoles and start multiple tasks in one trial job, users should ensure that only one taskRole report metric to NNI, otherwise there might be some conflict error.

OpenPAI configurations

paiConfig includes OpenPAI specific configurations,

  • userName

    Required key. User name of OpenPAI platform.

  • token

    Required key. Authentication key of OpenPAI platform.

  • host

    Required key. The host of OpenPAI platform. It’s OpenPAI’s job submission page uri, like 10.10.5.1, the default http protocol in NNI is http, if your OpenPAI cluster enabled https, please use the uri in https://10.10.5.1 format.

  • reuse (experimental feature)

    Optional key, default is false. If it’s true, NNI will reuse OpenPAI jobs to run as many as possible trials. It can save time of creating new jobs. User needs to make sure each trial can run independent in same job, for example, avoid loading checkpoint from previous trials.

Once complete to fill NNI experiment config file and save (for example, save as exp_pai.yml), then run the following command

nnictl create --config exp_pai.yml

to start the experiment in pai mode. NNI will create OpenPAI job for each trial, and the job name format is something like nni_exp_{experiment_id}_trial_{trial_id}. You can see jobs created by NNI in the OpenPAI cluster’s web portal, like:

Notice: In pai mode, NNIManager will start a rest server and listen on a port which is your NNI WebUI’s port plus 1. For example, if your WebUI port is 8080, the rest server will listen on 8081, to receive metrics from trial job running in Kubernetes. So you should enable 8081 TCP port in your firewall rule to allow incoming traffic.

Once a trial job is completed, you can goto NNI WebUI’s overview page (like http://localhost:8080/oview) to check trial’s information.

Expand a trial information in trial list view, click the logPath link like:

_images/nni_webui_joblist.png

And you will be redirected to HDFS web portal to browse the output files of that trial in HDFS:

_images/nni_trial_hdfs_output.jpg

You can see there’re three fils in output folder: stderr, stdout, and trial.log

data management

Before using NNI to start your experiment, users should set the corresponding mount data path in your nniManager machine. OpenPAI has their own storage(NFS, AzureBlob …), and the storage will used in OpenPAI will be mounted to the container when it start a job. Users should set the OpenPAI storage type by paiStorageConfigName field to choose a storage in OpenPAI. Then users should mount the storage to their nniManager machine, and set the nniManagerNFSMountPath field in configuration file, NNI will generate bash files and copy data in codeDir to the nniManagerNFSMountPath folder, then NNI will start a trial job. The data in nniManagerNFSMountPath will be sync to OpenPAI storage, and will be mounted to OpenPAI’s container. The data path in container is set in containerNFSMountPath, NNI will enter this folder first, and then run scripts to start a trial job.

version check

NNI support version check feature in since version 0.6. It is a policy to insure the version of NNIManager is consistent with trialKeeper, and avoid errors caused by version incompatibility. Check policy:

  1. NNIManager before v0.6 could run any version of trialKeeper, trialKeeper support backward compatibility.

  2. Since version 0.6, NNIManager version should keep same with triakKeeper version. For example, if NNIManager version is 0.6, trialKeeper version should be 0.6 too.

  3. Note that the version check feature only check first two digits of version.For example, NNIManager v0.6.1 could use trialKeeper v0.6 or trialKeeper v0.6.2, but could not use trialKeeper v0.5.1 or trialKeeper v0.7.

If you could not run your experiment and want to know if it is caused by version check, you could check your webUI, and there will be an error message about version check.

_images/experimentError.png

Run an Experiment on Kubeflow

Now NNI supports running experiment on Kubeflow, called kubeflow mode. Before starting to use NNI kubeflow mode, you should have a Kubernetes cluster, either on-premises or Azure Kubernetes Service(AKS), a Ubuntu machine on which kubeconfig is setup to connect to your Kubernetes cluster. If you are not familiar with Kubernetes, here is a good start. In kubeflow mode, your trial program will run as Kubeflow job in Kubernetes cluster.

Prerequisite for on-premises Kubernetes Service
  1. A Kubernetes cluster using Kubernetes 1.8 or later. Follow this guideline to set up Kubernetes

  2. Download, set up, and deploy Kubeflow to your Kubernetes cluster. Follow this guideline to setup Kubeflow.

  3. Prepare a kubeconfig file, which will be used by NNI to interact with your Kubernetes API server. By default, NNI manager will use $(HOME)/.kube/config as kubeconfig file’s path. You can also specify other kubeconfig files by setting the KUBECONFIG environment variable. Refer this guideline to learn more about kubeconfig.

  4. If your NNI trial job needs GPU resource, you should follow this guideline to configure Nvidia device plugin for Kubernetes.

  5. Prepare a NFS server and export a general purpose mount (we recommend to map your NFS server path in root_squash option, otherwise permission issue may raise when NNI copy files to NFS. Refer this page to learn what root_squash option is), or Azure File Storage.

  6. Install NFS client on the machine where you install NNI and run nnictl to create experiment. Run this command to install NFSv4 client:

apt-get install nfs-common
  1. Install NNI, follow the install guide here.

Prerequisite for Azure Kubernetes Service
  1. NNI support Kubeflow based on Azure Kubernetes Service, follow the guideline to set up Azure Kubernetes Service.

  2. Install Azure CLI and kubectl. Use az login to set azure account, and connect kubectl client to AKS, refer this guideline.

  3. Deploy Kubeflow on Azure Kubernetes Service, follow the guideline.

  4. Follow the guideline to create azure file storage account. If you use Azure Kubernetes Service, NNI need Azure Storage Service to store code files and the output files.

  5. To access Azure storage service, NNI need the access key of the storage account, and NNI use Azure Key Vault Service to protect your private key. Set up Azure Key Vault Service, add a secret to Key Vault to store the access key of Azure storage account. Follow this guideline to store the access key.

Design

Kubeflow training service instantiates a Kubernetes rest client to interact with your K8s cluster’s API server.

For each trial, we will upload all the files in your local codeDir path (configured in nni_config.yml) together with NNI generated files like parameter.cfg into a storage volumn. Right now we support two kinds of storage volumes: nfs and azure file storage, you should configure the storage volumn in NNI config YAML file. After files are prepared, Kubeflow training service will call K8S rest API to create Kubeflow jobs (tf-operator job or pytorch-operator job) in K8S, and mount your storage volume into the job’s pod. Output files of Kubeflow job, like stdout, stderr, trial.log or model files, will also be copied back to the storage volumn. NNI will show the storage volumn’s URL for each trial in WebUI, to allow user browse the log files and job’s output files.

Supported operator

NNI only support tf-operator and pytorch-operator of Kubeflow, other operators is not tested. Users could set operator type in config file. The setting of tf-operator:

kubeflowConfig:
  operator: tf-operator

The setting of pytorch-operator:

kubeflowConfig:
  operator: pytorch-operator

If users want to use tf-operator, he could set ps and worker in trial config. If users want to use pytorch-operator, he could set master and worker in trial config.

Supported storage type

NNI support NFS and Azure Storage to store the code and output files, users could set storage type in config file and set the corresponding config.

The setting for NFS storage are as follows:

kubeflowConfig:
  storage: nfs
  nfs:
    # Your NFS server IP, like 10.10.10.10
    server: {your_nfs_server_ip}
    # Your NFS server export path, like /var/nfs/nni
    path: {your_nfs_server_export_path}

If you use Azure storage, you should set kubeflowConfig in your config YAML file as follows:

kubeflowConfig:
  storage: azureStorage
  keyVault:
    vaultName: {your_vault_name}
    name: {your_secert_name}
  azureStorage:
    accountName: {your_storage_account_name}
    azureShare: {your_azure_share_name}
Run an experiment

Use examples/trials/mnist-tfv1 as an example. This is a tensorflow job, and use tf-operator of Kubeflow. The NNI config YAML file’s content is like:

authorName: default
experimentName: example_mnist
trialConcurrency: 2
maxExecDuration: 1h
maxTrialNum: 20
#choice: local, remote, pai, kubeflow
trainingServicePlatform: kubeflow
searchSpacePath: search_space.json
#choice: true, false
useAnnotation: false
tuner:
  #choice: TPE, Random, Anneal, Evolution
  builtinTunerName: TPE
  classArgs:
    #choice: maximize, minimize
    optimize_mode: maximize
assessor:
  builtinAssessorName: Medianstop
  classArgs:
    optimize_mode: maximize
trial:
  codeDir: .
  worker:
    replicas: 2
    command: python3 dist_mnist.py
    gpuNum: 1
    cpuNum: 1
    memoryMB: 8196
    image: msranni/nni:latest
  ps:
    replicas: 1
    command: python3 dist_mnist.py
    gpuNum: 0
    cpuNum: 1
    memoryMB: 8196
    image: msranni/nni:latest
kubeflowConfig:
  operator: tf-operator
  apiVersion: v1alpha2
  storage: nfs
  nfs:
    # Your NFS server IP, like 10.10.10.10
    server: {your_nfs_server_ip}
    # Your NFS server export path, like /var/nfs/nni
    path: {your_nfs_server_export_path}

Note: You should explicitly set trainingServicePlatform: kubeflow in NNI config YAML file if you want to start experiment in kubeflow mode.

If you want to run PyTorch jobs, you could set your config files as follow:

authorName: default
experimentName: example_mnist_distributed_pytorch
trialConcurrency: 1
maxExecDuration: 1h
maxTrialNum: 10
#choice: local, remote, pai, kubeflow
trainingServicePlatform: kubeflow
searchSpacePath: search_space.json
#choice: true, false
useAnnotation: false
tuner:
  #choice: TPE, Random, Anneal, Evolution
  builtinTunerName: TPE
  classArgs:
    #choice: maximize, minimize
    optimize_mode: minimize
trial:
  codeDir: .
  master:
    replicas: 1
    command: python3 dist_mnist.py
    gpuNum: 1
    cpuNum: 1
    memoryMB: 2048
    image: msranni/nni:latest
  worker:
    replicas: 1
    command: python3 dist_mnist.py
    gpuNum: 0
    cpuNum: 1
    memoryMB: 2048
    image: msranni/nni:latest
kubeflowConfig:
  operator: pytorch-operator
  apiVersion: v1alpha2
  nfs:
    # Your NFS server IP, like 10.10.10.10
    server: {your_nfs_server_ip}
    # Your NFS server export path, like /var/nfs/nni
    path: {your_nfs_server_export_path}

Trial configuration in kubeflow mode have the following configuration keys:

  • codeDir

    • code directory, where you put training code and config files

  • worker (required). This config section is used to configure tensorflow worker role

    • replicas

      • Required key. Should be positive number depends on how many replication your want to run for tensorflow worker role.

    • command

      • Required key. Command to launch your trial job, like python mnist.py

    • memoryMB

      • Required key. Should be positive number based on your trial program’s memory requirement

    • cpuNum

    • gpuNum

    • image

      • Required key. In kubeflow mode, your trial program will be scheduled by Kubernetes to run in Pod. This key is used to specify the Docker image used to create the pod where your trail program will run.

      • We already build a docker image msranni/nni. You can either use this image directly in your config file, or build your own image based on it.

    • privateRegistryAuthPath

      • Optional field, specify config.json file path that holds an authorization token of docker registry, used to pull image from private registry. Refer.

    • apiVersion

      • Required key. The API version of your Kubeflow.

  • ps (optional). This config section is used to configure Tensorflow parameter server role.

  • master(optional). This config section is used to configure PyTorch parameter server role.

Once complete to fill NNI experiment config file and save (for example, save as exp_kubeflow.yml), then run the following command

nnictl create --config exp_kubeflow.yml

to start the experiment in kubeflow mode. NNI will create Kubeflow tfjob or pytorchjob for each trial, and the job name format is something like nni_exp_{experiment_id}_trial_{trial_id}. You can see the Kubeflow tfjob created by NNI in your Kubernetes dashboard.

Notice: In kubeflow mode, NNIManager will start a rest server and listen on a port which is your NNI WebUI’s port plus 1. For example, if your WebUI port is 8080, the rest server will listen on 8081, to receive metrics from trial job running in Kubernetes. So you should enable 8081 TCP port in your firewall rule to allow incoming traffic.

Once a trial job is completed, you can go to NNI WebUI’s overview page (like http://localhost:8080/oview) to check trial’s information.

version check

NNI support version check feature in since version 0.6, refer

Any problems when using NNI in Kubeflow mode, please create issues on NNI Github repo.

Run an Experiment on AdaptDL

Now NNI supports running experiment on AdaptDL. Before starting to use NNI AdaptDL mode, you should have a Kubernetes cluster, either on-premises or Azure Kubernetes Service(AKS), a Ubuntu machine on which kubeconfig is setup to connect to your Kubernetes cluster. In AdaptDL mode, your trial program will run as AdaptDL job in Kubernetes cluster.

AdaptDL aims to make distributed deep learning easy and efficient in dynamic-resource environments such as shared clusters and the cloud.

Prerequisite for Kubernetes Service
  1. A Kubernetes cluster using Kubernetes 1.14 or later with storage. Follow this guideline to set up Kubernetes on Azure, or on-premise with cephfs, or microk8s with storage add-on enabled.

  2. Helm install AdaptDL Scheduler to your Kubernetes cluster. Follow this guideline to setup AdaptDL scheduler.

  3. Prepare a kubeconfig file, which will be used by NNI to interact with your Kubernetes API server. By default, NNI manager will use $(HOME)/.kube/config as kubeconfig file’s path. You can also specify other kubeconfig files by setting the ** KUBECONFIG** environment variable. Refer this guideline to learn more about kubeconfig.

  4. If your NNI trial job needs GPU resource, you should follow this guideline to configure Nvidia device plugin for Kubernetes.

  5. (Optional) Prepare a NFS server and export a general purpose mount as external storage.

  6. Install NNI, follow the install guide here.

Verify Prerequisites
nnictl --version
# Expected: <version_number>
kubectl version
# Expected that the kubectl client version matches the server version.
kubectl api-versions | grep adaptdl
# Expected: adaptdl.petuum.com/v1
Run an experiment

We have a CIFAR10 example that fully leverages the AdaptDL scheduler under examples/trials/cifar10_pytorch folder. (main_adl.py and config_adl.yaml)

Here is a template configuration specification to use AdaptDL as a training service.

authorName: default
experimentName: minimal_adl

trainingServicePlatform: adl
nniManagerIp: 10.1.10.11
logCollection: http

tuner:
  builtinTunerName: GridSearch
searchSpacePath: search_space.json

trialConcurrency: 2
maxTrialNum: 2

trial:
  adaptive: false # optional.
  image: <image_tag>
  imagePullSecrets:  # optional
    - name: stagingsecret
  codeDir: .
  command: python main.py
  gpuNum: 1
  cpuNum: 1  # optional
  memorySize: 8Gi  # optional
  nfs: # optional
    server: 10.20.41.55
    path: /
    containerMountPath: /nfs
  checkpoint: # optional
    storageClass: dfs
    storageSize: 1Gi

Those configs not mentioned below, are following the default specs defined in the NNI doc.

  • trainingServicePlatform: Choose adl to use the Kubernetes cluster with AdaptDL scheduler.

  • nniManagerIp: Required to get the correct info and metrics back from the cluster, for adl training service. IP address of the machine with NNI manager (NNICTL) that launches NNI experiment.

  • logCollection: Recommended to set as http. It will collect the trial logs on cluster back to your machine via http.

  • tuner: It supports the Tuun tuner and all NNI built-in tuners (only except for the checkpoint feature of the NNI PBT tuners).

  • trial: It defines the specs of an adl trial.

    • namespace: (Optional) Kubernetes namespace to launch the trials. Default to default namespace.

    • adaptive: (Optional) Boolean for AdaptDL trainer. While true, it the job is preemptible and adaptive.

    • image: Docker image for the trial

    • imagePullSecret: (Optional) If you are using a private registry, you need to provide the secret to successfully pull the image.

    • codeDir: the working directory of the container. . means the default working directory defined by the image.

    • command: the bash command to start the trial

    • gpuNum: the number of GPUs requested for this trial. It must be non-negative integer.

    • cpuNum: (Optional) the number of CPUs requested for this trial. It must be non-negative integer.

    • memorySize: (Optional) the size of memory requested for this trial. It must follow the Kubernetes default format.

    • nfs: (Optional) mounting external storage. For more information about using NFS please check the below paragraph.

    • checkpoint (Optional) storage settings for model checkpoints.

      • storageClass: check Kubernetes storage documentation for how to use the appropriate storageClass.

      • storageSize: this value should be large enough to fit your model’s checkpoints, or it could cause “disk quota exceeded” error.

NFS Storage

As you may have noticed in the above configuration spec, an optional section is available to configure NFS external storage. It is optional when no external storage is required, when for example an docker image is sufficient with codes and data inside.

Note that adl training service does NOT help mount an NFS to the local dev machine, so that one can manually mount it to local, manage the filesystem, copy the data or code etc. The adl training service can then mount it to the kubernetes for every trials, with the proper configurations:

  • server: NFS server address, e.g. IP address or domain

  • path: NFS server export path, i.e. the absolute path in NFS that can be mounted to trials

  • containerMountPath: In container absolute path to mount the NFS path above, so that every trial will have the access to the NFS. In the trial containers, you can access the NFS with this path.

Use cases:

  • If your training trials depend on a dataset of large size, you may want to download it first onto the NFS first, and mount it so that it can be shared across multiple trials.

  • The storage for containers are ephemeral and the trial containers will be deleted after a trial’s lifecycle is over. So if you want to export your trained models, you may mount the NFS to the trial to persist and export your trained models.

In short, it is not limited how a trial wants to read from or write on the NFS storage, so you may use it flexibly as per your needs.

Monitor via Log Stream

Follow the log streaming of a certain trial:

nnictl log trial --trial_id=<trial_id>
nnictl log trial <experiment_id> --trial_id=<trial_id>

Note that after a trial has done and its pod has been deleted, no logs can be retrieved then via this command. However you may still be able to access the past trial logs according to the following approach.

Monitor via TensorBoard

In the context of NNI, an experiment has multiple trials. For easy comparison across trials for a model tuning process, we support TensorBoard integration. Here one experiment has an independent TensorBoard logging directory thus dashboard.

You can only use the TensorBoard while the monitored experiment is running. In other words, it is not supported to monitor stopped experiments.

In the trial container you may have access to two environment variables:

  • ADAPTDL_TENSORBOARD_LOGDIR: the TensorBoard logging directory for the current experiment,

  • NNI_TRIAL_JOB_ID: the trial job id for the current trial.

It is recommended for to have them joined as the directory for trial, for example in Python:

import os
tensorboard_logdir = os.path.join(
    os.getenv("ADAPTDL_TENSORBOARD_LOGDIR"),
    os.getenv("NNI_TRIAL_JOB_ID")
)

If an experiment is stopped, the data logged here (defined by the above envs for monitoring with the following commands) will be lost. To persist the logged data, you can use the external storage (e.g. to mount an NFS) to export it and view the TensorBoard locally.

With the above setting, you can monitor the experiment easily via TensorBoard by

nnictl tensorboard start

If having multiple experiment running at the same time, you may use

nnictl tensorboard start <experiment_id>

It will provide you the web url to access the tensorboard.

Note that you have the flexibility to set up the local --port for the TensorBoard.

Run an Experiment on FrameworkController

NNI supports running experiment using FrameworkController, called frameworkcontroller mode. FrameworkController is built to orchestrate all kinds of applications on Kubernetes, you don’t need to install Kubeflow for specific deep learning framework like tf-operator or pytorch-operator. Now you can use FrameworkController as the training service to run NNI experiment.

Prerequisite for on-premises Kubernetes Service
  1. A Kubernetes cluster using Kubernetes 1.8 or later. Follow this guideline to set up Kubernetes

  2. Prepare a kubeconfig file, which will be used by NNI to interact with your Kubernetes API server. By default, NNI manager will use $(HOME)/.kube/config as kubeconfig file’s path. You can also specify other kubeconfig files by setting the**KUBECONFIG** environment variable. Refer this guideline to learn more about kubeconfig.

  3. If your NNI trial job needs GPU resource, you should follow this guideline to configure Nvidia device plugin for Kubernetes.

  4. Prepare a NFS server and export a general purpose mount (we recommend to map your NFS server path in root_squash option, otherwise permission issue may raise when NNI copies files to NFS. Refer this page to learn what root_squash option is), or Azure File Storage.

  5. Install NFS client on the machine where you install NNI and run nnictl to create experiment. Run this command to install NFSv4 client:

apt-get install nfs-common
  1. Install NNI, follow the install guide here.

Prerequisite for Azure Kubernetes Service
  1. NNI support Kubeflow based on Azure Kubernetes Service, follow the guideline to set up Azure Kubernetes Service.

  2. Install Azure CLI and kubectl. Use az login to set azure account, and connect kubectl client to AKS, refer this guideline.

  3. Follow the guideline to create azure file storage account. If you use Azure Kubernetes Service, NNI need Azure Storage Service to store code files and the output files.

  4. To access Azure storage service, NNI need the access key of the storage account, and NNI uses Azure Key Vault Service to protect your private key. Set up Azure Key Vault Service, add a secret to Key Vault to store the access key of Azure storage account. Follow this guideline to store the access key.

Prerequisite for PVC storage mode

In order to use persistent volume claims instead of NFS or Azure storage, related storage must be created manually, in the namespace your trials will run later. This restriction is due to the fact, that persistent volume claims are hard to recycle and thus can quickly mess with a cluster’s storage management. Persistent volume claims can be created by e.g. using kubectl. Please refer to the official Kubernetes documentation for further information.

Setup FrameworkController

Follow the guideline to set up FrameworkController in the Kubernetes cluster, NNI supports FrameworkController by the stateful set mode. If your cluster enforces authorization, you need to create a service account with granted permission for FrameworkController, and then pass the name of the FrameworkController service account to the NNI Experiment Config. refer

Design

Please refer the design of Kubeflow training service, FrameworkController training service pipeline is similar.

Example

The FrameworkController config file format is:

authorName: default
experimentName: example_mnist
trialConcurrency: 1
maxExecDuration: 10h
maxTrialNum: 100
#choice: local, remote, pai, kubeflow, frameworkcontroller
trainingServicePlatform: frameworkcontroller
searchSpacePath: ~/nni/examples/trials/mnist-tfv1/search_space.json
#choice: true, false
useAnnotation: false
tuner:
  #choice: TPE, Random, Anneal, Evolution
  builtinTunerName: TPE
  classArgs:
    #choice: maximize, minimize
    optimize_mode: maximize
assessor:
  builtinAssessorName: Medianstop
  classArgs:
    optimize_mode: maximize
trial:
  codeDir: ~/nni/examples/trials/mnist-tfv1
  taskRoles:
    - name: worker
      taskNum: 1
      command: python3 mnist.py
      gpuNum: 1
      cpuNum: 1
      memoryMB: 8192
      image: msranni/nni:latest
      frameworkAttemptCompletionPolicy:
        minFailedTaskCount: 1
        minSucceededTaskCount: 1
frameworkcontrollerConfig:
  storage: nfs
  nfs:
    server: {your_nfs_server}
    path: {your_nfs_server_exported_path}

If you use Azure Kubernetes Service, you should set frameworkcontrollerConfig in your config YAML file as follows:

frameworkcontrollerConfig:
  storage: azureStorage
  serviceAccountName: {your_frameworkcontroller_service_account_name}
  keyVault:
    vaultName: {your_vault_name}
    name: {your_secert_name}
  azureStorage:
    accountName: {your_storage_account_name}
    azureShare: {your_azure_share_name}

Note: You should explicitly set trainingServicePlatform: frameworkcontroller in NNI config YAML file if you want to start experiment in frameworkcontrollerConfig mode.

The trial’s config format for NNI frameworkcontroller mode is a simple version of FrameworkController’s official config, you could refer the Tensorflow example of FrameworkController for deep understanding.

Trial configuration in frameworkcontroller mode have the following configuration keys:

  • taskRoles: you could set multiple task roles in config file, and each task role is a basic unit to process in Kubernetes cluster.

    • name: the name of task role specified, like “worker”, “ps”, “master”.

    • taskNum: the replica number of the task role.

    • command: the users’ command to be used in the container.

    • gpuNum: the number of gpu device used in container.

    • cpuNum: the number of cpu device used in container.

    • memoryMB: the memory limitaion to be specified in container.

    • image: the docker image used to create pod and run the program.

    • frameworkAttemptCompletionPolicy: the policy to run framework, please refer the user-manual to get the specific information. Users could use the policy to control the pod, for example, if ps does not stop, only worker stops, The completion policy could helps stop ps.

NNI also offers the possibility to include a customized frameworkcontroller template similar to the aforementioned tensorflow example. A valid configuration the may look like:

experimentName: example_mnist_pytorch
trialConcurrency: 1
maxExecDuration: 1h
maxTrialNum: 2
logLevel: trace
trainingServicePlatform: frameworkcontroller
searchSpacePath: search_space.json
tuner:
  builtinTunerName: TPE
  classArgs:
    optimize_mode: maximize
assessor:
  builtinAssessorName: Medianstop
  classArgs:
    optimize_mode: maximize
trial:
  codeDir: .
frameworkcontrollerConfig:
  configPath: fc_template.yml
  storage: pvc
  namespace: twin-pipelines
  pvc:
    path: /mnt/data

Note that in this example a persistent volume claim has been used, that must be created manually in the specified namespace beforehand. Stick to the mnist-pytorch example (:githublink: examples/trials/mnist-pytorch) for a more detailed config (:githublink: examples/trials/mnist-pytorch/config_frameworkcontroller_custom.yml) and frameworkcontroller template (:githublink: examples/trials/fc_template.yml).

How to run example

After you prepare a config file, you could run your experiment by nnictl. The way to start an experiment on FrameworkController is similar to Kubeflow, please refer the document for more information.

version check

NNI support version check feature in since version 0.6, refer

Run an Experiment on DLTS

NNI supports running an experiment on DLTS, called dlts mode. Before starting to use NNI dlts mode, you should have an account to access DLTS dashboard.

Setup Environment

Step 1. Choose a cluster from DLTS dashboard, ask administrator for the cluster dashboard URL.

Choose Cluster

Step 2. Prepare a NNI config YAML like the following:

# Set this field to "dlts"
trainingServicePlatform: dlts
authorName: your_name
experimentName: auto_mnist
trialConcurrency: 2
maxExecDuration: 3h
maxTrialNum: 100
searchSpacePath: search_space.json
useAnnotation: false
tuner:
  builtinTunerName: TPE
  classArgs:
    optimize_mode: maximize
trial:
  command: python3 mnist.py
  codeDir: .
  gpuNum: 1
  image: msranni/nni
# Configuration to access DLTS
dltsConfig:
  dashboard: # Ask administrator for the cluster dashboard URL

Remember to fill the cluster dashboard URL to the last line.

Step 3. Open your working directory of the cluster, paste the NNI config as well as related code to a directory.

Copy Config

Step 4. Submit a NNI manager job to the specified cluster.

Submit Job

Step 5. Go to Endpoints tab of the newly created job, click the Port 40000 link to check trial’s information.

View NNI WebUI

Run an Experiment on Azure Machine Learning

NNI supports running an experiment on AML , called aml mode.

Setup environment

Step 1. Install NNI, follow the install guide here.

Step 2. Create an Azure account/subscription using this link. If you already have an Azure account/subscription, skip this step.

Step 3. Install the Azure CLI on your machine, follow the install guide here.

Step 4. Authenticate to your Azure subscription from the CLI. To authenticate interactively, open a command line or terminal and use the following command:

az login

Step 5. Log into your Azure account with a web browser and create a Machine Learning resource. You will need to choose a resource group and specific a workspace name. Then download config.json which will be used later.

Step 6. Create an AML cluster as the computeTarget.

Step 7. Open a command line and install AML package environment.

python3 -m pip install azureml
python3 -m pip install azureml-sdk
Run an experiment

Use examples/trials/mnist-pytorch as an example. The NNI config YAML file’s content is like:

authorName: default
experimentName: example_mnist
trialConcurrency: 1
maxExecDuration: 1h
maxTrialNum: 10
trainingServicePlatform: aml
searchSpacePath: search_space.json
#choice: true, false
useAnnotation: false
tuner:
  #choice: TPE, Random, Anneal, Evolution, BatchTuner, MetisTuner, GPTuner
  #SMAC (SMAC should be installed through nnictl)
  builtinTunerName: TPE
  classArgs:
    #choice: maximize, minimize
    optimize_mode: maximize
trial:
  command: python3 mnist.py
  codeDir: .
  image: msranni/nni
  gpuNum: 1
amlConfig:
  subscriptionId: ${replace_to_your_subscriptionId}
  resourceGroup: ${replace_to_your_resourceGroup}
  workspaceName: ${replace_to_your_workspaceName}
  computeTarget: ${replace_to_your_computeTarget}

Note: You should set trainingServicePlatform: aml in NNI config YAML file if you want to start experiment in aml mode.

Compared with LocalMode trial configuration in aml mode have these additional keys:

  • image

    • required key. The docker image name used in job. NNI support image msranni/nni for running aml jobs.

Note

This image is build based on cuda environment, may not be suitable for CPU clusters in AML.

amlConfig:

  • subscriptionId

    • required key, the subscriptionId of your account

  • resourceGroup

    • required key, the resourceGroup of your account

  • workspaceName

    • required key, the workspaceName of your account

  • computeTarget

    • required key, the compute cluster name you want to use in your AML workspace. refer See Step 6.

  • maxTrialNumPerGpu

    • optional key, default 1. Used to specify the max concurrency trial number on a GPU device.

  • useActiveGpu

    • optional key, default false. Used to specify whether to use a GPU if there is another process. By default, NNI will use the GPU only if there is no other active process in the GPU.

The required information of amlConfig could be found in the downloaded config.json in Step 5.

Run the following commands to start the example experiment:

git clone -b ${NNI_VERSION} https://github.com/microsoft/nni
cd nni/examples/trials/mnist-pytorch

# modify config_aml.yml ...

nnictl create --config config_aml.yml

Replace ${NNI_VERSION} with a released version name or branch name, e.g., v2.2.

Monitor your code in the cloud by using the studio

To monitor your job’s code, you need to visit your studio which you create at step 5. Once the job completes, go to the Outputs + logs tab. There you can see a 70_driver_log.txt file, This file contains the standard output from a run and can be useful when you’re debugging remote runs in the cloud. Learn more about aml from here.

Run an Experiment on Hybrid Mode

Run NNI on hybrid mode means that NNI will run trials jobs in multiple kinds of training platforms. For example, NNI could submit trial jobs to remote machine and AML simultaneously.

Setup environment

NNI has supported local, remote, PAI, and AML for hybrid training service. Before starting an experiment using these mode, users should setup the corresponding environment for the platforms. More details about the environment setup could be found in the corresponding docs.

Run an experiment

Use examples/trials/mnist-tfv1 as an example. The NNI config YAML file’s content is like:

authorName: default
experimentName: example_mnist
trialConcurrency: 2
maxExecDuration: 1h
maxTrialNum: 10
trainingServicePlatform: hybrid
searchSpacePath: search_space.json
#choice: true, false
useAnnotation: false
tuner:
  builtinTunerName: TPE
  classArgs:
    #choice: maximize, minimize
    optimize_mode: maximize
trial:
  command: python3 mnist.py
  codeDir: .
  gpuNum: 1
hybridConfig:
  trainingServicePlatforms:
    - local
    - remote
remoteConfig:
  reuse: true
machineList:
  - ip: 10.1.1.1
    username: bob
    passwd: bob123

Configurations for hybrid mode:

hybridConfig:

  • trainingServicePlatforms. required key. This field specify the platforms used in hybrid mode, the values using yaml list format. NNI support setting local, remote, aml, pai in this field.

Note

If setting a platform in trainingServicePlatforms mode, users should also set the corresponding configuration for the platform. For example, if set remote as one of the platform, should also set machineList and remoteConfig configuration.

Examples

MNIST examples

CNN MNIST classifier for deep learning is similar to hello world for programming languages. Thus, we use MNIST as example to introduce different features of NNI. The examples are listed below:

MNIST with NNI API (PyTorch)

This is a simple network which has two convolutional layers, two pooling layers and a fully connected layer. We tune hyperparameters, such as dropout rate, convolution size, hidden size, etc. It can be tuned with most NNI built-in tuners, such as TPE, SMAC, Random. We also provide an exmaple YAML file which enables assessor.

code directory: mnist-pytorch/

MNIST with NNI API (TensorFlow v2.x)

Same network to the example above, but written in TensorFlow.

code directory: mnist-tfv2/

MNIST with NNI API (TensorFlow v1.x)

Same network to the example above, but written in TensorFlow v1.x API.

code directory: mnist-tfv1/

MNIST with NNI annotation

This example is similar to the example above, the only difference is that this example uses NNI annotation to specify search space and report results, while the example above uses NNI apis to receive configuration and report results.

code directory: mnist-annotation/

MNIST – tuning with batch tuner

This example is to show how to use batch tuner. Users simply list all the configurations they want to try in the search space file. NNI will try all of them.

code directory: mnist-batch-tune-keras/

MNIST – tuning with hyperband

This example is to show how to use hyperband to tune the model. There is one more key STEPS in the received configuration for trials to control how long it can run (e.g., number of iterations).

code directory: mnist-hyperband/

MNIST – tuning within a nested search space

This example is to show that NNI also support nested search space. The search space file is an example of how to define nested search space.

code directory: mnist-nested-search-space/

distributed MNIST (tensorflow) using kubeflow

This example is to show how to run distributed training on kubeflow through NNI. Users can simply provide distributed training code and a configure file which specifies the kubeflow mode. For example, what is the command to run ps and what is the command to run worker, and how many resources they consume. This example is implemented in tensorflow, thus, uses kubeflow tensorflow operator.

code directory: mnist-distributed/

distributed MNIST (pytorch) using kubeflow

Similar to the previous example, the difference is that this example is implemented in pytorch, thus, it uses kubeflow pytorch operator.

code directory: mnist-distributed-pytorch/

CIFAR-10 examples

Overview

CIFAR-10 classification is a common benchmark problem in machine learning. The CIFAR-10 dataset is the collection of images. It is one of the most widely used datasets for machine learning research which contains 60,000 32x32 color images in 10 different classes. Thus, we use CIFAR-10 classification as an example to introduce NNI usage.

Goals

As we all know, the choice of model optimizer is directly affects the performance of the final metrics. The goal of this tutorial is to tune a better performace optimizer to train a relatively small convolutional neural network (CNN) for recognizing images.

In this example, we have selected the following common deep learning optimizer:

"SGD", "Adadelta", "Adagrad", "Adam", "Adamax"
Experimental
Preparations

This example requires PyTorch. PyTorch install package should be chosen based on python version and cuda version.

Here is an example of the environment python==3.5 and cuda == 8.0, then using the following commands to install PyTorch:

python3 -m pip install http://download.pytorch.org/whl/cu80/torch-0.4.1-cp35-cp35m-linux_x86_64.whl
python3 -m pip install torchvision
CIFAR-10 with NNI

Search Space

As we stated in the target, we target to find out the best optimizer for training CIFAR-10 classification. When using different optimizers, we also need to adjust learning rates and network structure accordingly. so we chose these three parameters as hyperparameters and write the following search space.

{
    "lr":{"_type":"choice", "_value":[0.1, 0.01, 0.001, 0.0001]},
    "optimizer":{"_type":"choice", "_value":["SGD", "Adadelta", "Adagrad", "Adam", "Adamax"]},
    "model":{"_type":"choice", "_value":["vgg", "resnet18", "googlenet", "densenet121", "mobilenet", "dpn92", "senet18"]}
}

Implemented code directory: search_space.json

Trial

The code for CNN training of each hyperparameters set, paying particular attention to the following points are specific for NNI:

  • Use nni.get_next_parameter() to get next training hyperparameter set.

  • Use nni.report_intermediate_result(acc) to report the intermedian result after finish each epoch.

  • Use nni.report_final_result(acc) to report the final result before the trial end.

Implemented code directory: main.py

You can also use your previous code directly, refer to How to define a trial for modify.

Config

Here is the example of running this experiment on local(with multiple GPUs):

code directory: examples/trials/cifar10_pytorch/config.yml

Here is the example of running this experiment on OpenPAI:

code directory: examples/trials/cifar10_pytorch/config_pai.yml

The complete examples we have implemented: examples/trials/cifar10_pytorch/

Launch the experiment

We are ready for the experiment, let’s now run the config.yml file from your command line to start the experiment.

nnictl create --config nni/examples/trials/cifar10_pytorch/config.yml

Scikit-learn in NNI

Scikit-learn is a popular machine learning tool for data mining and data analysis. It supports many kinds of machine learning models like LinearRegression, LogisticRegression, DecisionTree, SVM etc. How to make the use of scikit-learn more efficiency is a valuable topic.

NNI supports many kinds of tuning algorithms to search the best models and/or hyper-parameters for scikit-learn, and support many kinds of environments like local machine, remote servers and cloud.

1. How to run the example

To start using NNI, you should install the NNI package, and use the command line tool nnictl to start an experiment. For more information about installation and preparing for the environment, please refer here.

After you installed NNI, you could enter the corresponding folder and start the experiment using following commands:

nnictl create --config ./config.yml
2. Description of the example
2.1 classification

This example uses the dataset of digits, which is made up of 1797 8x8 images, and each image is a hand-written digit, the goal is to classify these images into 10 classes.

In this example, we use SVC as the model, and choose some parameters of this model, including "C", "kernel", "degree", "gamma" and "coef0". For more information of these parameters, please refer.

2.2 regression

This example uses the Boston Housing Dataset, this dataset consists of price of houses in various places in Boston and the information such as Crime (CRIM), areas of non-retail business in the town (INDUS), the age of people who own the house (AGE) etc., to predict the house price of Boston.

In this example, we tune different kinds of regression models including "LinearRegression", "SVR", "KNeighborsRegressor", "DecisionTreeRegressor" and some parameters like "svr_kernel", "knr_weights". You could get more details about these models from here.

3. How to write scikit-learn code using NNI

It is easy to use NNI in your scikit-learn code, there are only a few steps.

  • step 1

    Prepare a search_space.json to storage your choose spaces. For example, if you want to choose different models, you may try:

    {
      "model_name":{"_type":"choice","_value":["LinearRegression", "SVR", "KNeighborsRegressor", "DecisionTreeRegressor"]}
    }
    

    If you want to choose different models and parameters, you could put them together in a search_space.json file.

    {
      "model_name":{"_type":"choice","_value":["LinearRegression", "SVR", "KNeighborsRegressor", "DecisionTreeRegressor"]},
      "svr_kernel": {"_type":"choice","_value":["linear", "poly", "rbf"]},
      "knr_weights": {"_type":"choice","_value":["uniform", "distance"]}
    }
    

    Then you could read these values as a dict from your python code, please get into the step 2.

  • step 2

    At the beginning of your python code, you should import nni to insure the packages works normally.

    First, you should use nni.get_next_parameter() function to get your parameters given by NNI. Then you could use these parameters to update your code. For example, if you define your search_space.json like following format:

    {
      "C": {"_type":"uniform","_value":[0.1, 1]},
      "kernel": {"_type":"choice","_value":["linear", "rbf", "poly", "sigmoid"]},
      "degree": {"_type":"choice","_value":[1, 2, 3, 4]},
      "gamma": {"_type":"uniform","_value":[0.01, 0.1]},
      "coef0": {"_type":"uniform","_value":[0.01, 0.1]}
    }
    

    You may get a parameter dict like this:

    params = {
          'C': 1.0,
          'kernel': 'linear',
          'degree': 3,
          'gamma': 0.01,
          'coef0': 0.01
    }
    

    Then you could use these variables to write your scikit-learn code.

  • step 3

    After you finished your training, you could get your own score of the model, like your precision, recall or MSE etc. NNI needs your score to tuner algorithms and generate next group of parameters, please report the score back to NNI and start next trial job.

    You just need to use nni.report_final_result(score) to communicate with NNI after you process your scikit-learn code. Or if you have multiple scores in the steps of training, you could also report them back to NNI using nni.report_intemediate_result(score). Note, you may not report intermediate result of your job, but you must report back your final result.

GBDT in nni

Gradient boosting is a machine learning technique for regression and classification problems, which produces a prediction model in the form of an ensemble of weak prediction models, typically decision trees. It builds the model in a stage-wise fashion as other boosting methods do, and it generalizes them by allowing optimization of an arbitrary differentiable loss function.

Gradient boosting decision tree has many popular implementations, such as lightgbm, xgboost, and catboost, etc. GBDT is a great tool for solving the problem of traditional machine learning problem. Since GBDT is a robust algorithm, it could use in many domains. The better hyper-parameters for GBDT, the better performance you could achieve.

NNI is a great platform for tuning hyper-parameters, you could try various builtin search algorithm in nni and run multiple trials concurrently.

1. Search Space in GBDT

There are many hyper-parameters in GBDT, but what kind of parameters will affect the performance or speed? Based on some practical experience, some suggestion here(Take lightgbm as example):

  • For better accuracy

  • learning_rate. The range of learning rate could be [0.001, 0.9].

  • num_leaves. num_leaves is related to max_depth, you don’t have to tune both of them.

  • bagging_freq. bagging_freq could be [1, 2, 4, 8, 10]

  • num_iterations. May larger if underfitting.

  • For speed up

  • bagging_fraction. The range of bagging_fraction could be [0.7, 1.0].

  • feature_fraction. The range of feature_fraction could be [0.6, 1.0].

  • max_bin.

  • To avoid overfitting

  • min_data_in_leaf. This depends on your dataset.

  • min_sum_hessian_in_leaf. This depend on your dataset.

  • lambda_l1 and lambda_l2.

  • min_gain_to_split.

  • num_leaves.

Reference link: lightgbm and autoxgoboost

2. Task description

Now we come back to our example “auto-gbdt” which run in lightgbm and nni. The data including train data and test data. Given the features and label in train data, we train a GBDT regression model and use it to predict.

3. How to run in nni
3.1 Install all the requirments
pip install lightgbm
pip install pandas
3.2 Prepare your trial code

You need to prepare a basic code as following:

...

def get_default_parameters():
    ...
    return params


def load_data(train_path='./data/regression.train', test_path='./data/regression.test'):
    '''
    Load or create dataset
    '''
    ...

    return lgb_train, lgb_eval, X_test, y_test

def run(lgb_train, lgb_eval, params, X_test, y_test):
    # train
    gbm = lgb.train(params,
                    lgb_train,
                    num_boost_round=20,
                    valid_sets=lgb_eval,
                    early_stopping_rounds=5)
    # predict
    y_pred = gbm.predict(X_test, num_iteration=gbm.best_iteration)

    # eval
    rmse = mean_squared_error(y_test, y_pred) ** 0.5
    print('The rmse of prediction is:', rmse)

if __name__ == '__main__':
    lgb_train, lgb_eval, X_test, y_test = load_data()

    PARAMS = get_default_parameters()
    # train
    run(lgb_train, lgb_eval, PARAMS, X_test, y_test)
3.3 Prepare your search space.

If you like to tune num_leaves, learning_rate, bagging_fraction and bagging_freq, you could write a search_space.json as follow:

{
    "num_leaves":{"_type":"choice","_value":[31, 28, 24, 20]},
    "learning_rate":{"_type":"choice","_value":[0.01, 0.05, 0.1, 0.2]},
    "bagging_fraction":{"_type":"uniform","_value":[0.7, 1.0]},
    "bagging_freq":{"_type":"choice","_value":[1, 2, 4, 8, 10]}
}

More support variable type you could reference here.

3.4 Add SDK of nni into your code.
+import nni
...

def get_default_parameters():
    ...
    return params


def load_data(train_path='./data/regression.train', test_path='./data/regression.test'):
    '''
    Load or create dataset
    '''
    ...

    return lgb_train, lgb_eval, X_test, y_test

def run(lgb_train, lgb_eval, params, X_test, y_test):
    # train
    gbm = lgb.train(params,
                    lgb_train,
                    num_boost_round=20,
                    valid_sets=lgb_eval,
                    early_stopping_rounds=5)
    # predict
    y_pred = gbm.predict(X_test, num_iteration=gbm.best_iteration)

    # eval
    rmse = mean_squared_error(y_test, y_pred) ** 0.5
    print('The rmse of prediction is:', rmse)
+   nni.report_final_result(rmse)

if __name__ == '__main__':
    lgb_train, lgb_eval, X_test, y_test = load_data()
+   RECEIVED_PARAMS = nni.get_next_parameter()
    PARAMS = get_default_parameters()
+   PARAMS.update(RECEIVED_PARAMS)

    # train
    run(lgb_train, lgb_eval, PARAMS, X_test, y_test)
3.5 Write a config file and run it.

In the config file, you could set some settings including:

  • Experiment setting: trialConcurrency, maxExecDuration, maxTrialNum, trial gpuNum, etc.

  • Platform setting: trainingServicePlatform, etc.

  • Path seeting: searchSpacePath, trial codeDir, etc.

  • Algorithm setting: select tuner algorithm, tuner optimize_mode, etc.

An config.yml as follow:

authorName: default
experimentName: example_auto-gbdt
trialConcurrency: 1
maxExecDuration: 10h
maxTrialNum: 10
#choice: local, remote, pai
trainingServicePlatform: local
searchSpacePath: search_space.json
#choice: true, false
useAnnotation: false
tuner:
  #choice: TPE, Random, Anneal, Evolution, BatchTuner
  #SMAC (SMAC should be installed through nnictl)
  builtinTunerName: TPE
  classArgs:
    #choice: maximize, minimize
    optimize_mode: minimize
trial:
  command: python3 main.py
  codeDir: .
  gpuNum: 0

Run this experiment with command as follow:

nnictl create --config ./config.yml

WebUI

Experiments managerment

Click the tab All experiments on the nav bar.

ExperimentList nav
  • On the All experiments page, you can see all the experiments on your machine.

Experiments list
  • When you want to see more details about an experiment you could click the trial id, look that:

See this experiment detail
  • If has many experiments on the table, you can use the filter button.

filter button

View summary page

Click the tab Overview.

  • On the overview tab, you can see the experiment information and status and the performance of top trials.

overview
  • If you want to see experiment search space and config, please click the right button Search space and Config (when you hover on this button).

    1. Search space file:

      searchSpace
    2. Config file:

      config
  • You can view and download nni-manager/dispatcher log files on here.

logfile
  • If your experiment has many trials, you can change the refresh interval here.

refresh
  • You can review and download the experiment results(experiment config, trial message and intermeidate metrics) when you click the button Experiment summary.

summary
  • You can change some experiment configurations such as maxExecDuration, maxTrialNum and trial concurrency on here.

editExperimentParams
  • You can click the icon to see specific error message and nni-manager/dispatcher log files by clicking Learn about link.

experimentError
  • You can click About to see the version and report any questions.

View job default metric

  • Click the tab Default Metric to see the point graph of all trials. Hover to see its specific default metric and search space message.

defaultMetricGraph
  • Click the switch named optimization curve to see the experiment’s optimization curve.

bestCurveGraph

View hyper parameter

Click the tab Hyper Parameter to see the parallel graph.

  • You can add/remove axes and drag to swap axes on the chart.

  • You can select the percentage to see top trials.

hyperParameterGraph

View Trial Duration

Click the tab Trial Duration to see the bar graph.

trialDurationGraph

View Trial Intermediate Result Graph

Click the tab Intermediate Result to see the line graph.

trialIntermediateGraph

The trial may have many intermediate results in the training process. In order to see the trend of some trials more clearly, we set a filtering function for the intermediate result graph.

You may find that these trials will get better or worse at an intermediate result. This indicates that it is an important and relevant intermediate result. To take a closer look at the point here, you need to enter its corresponding X-value at #Intermediate. Then input the range of metrics on this intermedia result. In the picture below, we choose the No. 4 intermediate result and set the range of metrics to 0.8-1.

filterIntermediateGraph

View trials status

Click the tab Trials Detail to see the status of all trials. Specifically:

  • Trial detail: trial’s id, trial’s duration, start time, end time, status, accuracy, and search space file.

detailLocalImage
  • The button named Add column can select which column to show on the table. If you run an experiment whose final result is a dict, you can see other keys in the table. You can choose the column Intermediate count to watch the trial’s progress.

addColumnGraph
  • If you want to compare some trials, you can select them and then click Compare to see the results.

selectTrialGraph compareTrialsGraph
  • Support to search for a specific trial by it’s id, status, Trial No. and parameters.

searchTrial
  • You can use the button named Copy as python to copy the trial’s parameters.

copyTrialParameters
  • If you run on the OpenPAI or Kubeflow platform, you can also see the nfs log.

detailPai
  • Intermediate Result Graph: you can see the default metric in this graph by clicking the intermediate button.

intermeidateGraph
  • Kill: you can kill a job that status is running.

killTrial

How to Debug in NNI

Overview

There are three parts that might have logs in NNI. They are nnimanager, dispatcher and trial. Here we will introduce them succinctly. More information please refer to Overview.

  • NNI controller: NNI controller (nnictl) is the nni command-line tool that is used to manage experiments (e.g., start an experiment).

  • nnimanager: nnimanager is the core of NNI, whose log is important when the whole experiment fails (e.g., no webUI or training service fails)

  • Dispatcher: Dispatcher calls the methods of Tuner and Assessor. Logs of dispatcher are related to the tuner or assessor code.

    • Tuner: Tuner is an AutoML algorithm, which generates a new configuration for the next try. A new trial will run with this configuration.

    • Assessor: Assessor analyzes trial’s intermediate results (e.g., periodically evaluated accuracy on test dataset) to tell whether this trial can be early stopped or not.

  • Trial: Trial code is the code you write to run your experiment, which is an individual attempt at applying a new configuration (e.g., a set of hyperparameter values, a specific nerual architecture).

Where is the log

There are three kinds of log in NNI. When creating a new experiment, you can specify log level as debug by adding --debug. Besides, you can set more detailed log level in your configuration file by using logLevel keyword. Available logLevels are: trace, debug, info, warning, error, fatal.

NNI controller

All possible errors that happen when launching an NNI experiment can be found here.

You can use nnictl log stderr to find error information. For more options please refer to NNICTL

Experiment Root Directory

Every experiment has a root folder, which is shown on the right-top corner of webUI. Or you could assemble it by replacing the experiment_id with your actual experiment_id in path ~/nni-experiments/experiment_id/ in case of webUI failure. experiment_id could be seen when you run nnictl create ... to create a new experiment.

For flexibility, we also offer a logDir option in your configuration, which specifies the directory to store all experiments (defaults to ~/nni-experiments). Please refer to Configuration for more details.

Under that directory, there is another directory named log, where nnimanager.log and dispatcher.log are placed.

Trial Root Directory

Usually in webUI, you can click + in the left of every trial to expand it to see each trial’s log path.

Besides, there is another directory under experiment root directory, named trials, which stores all the trials. Every trial has a unique id as its directory name. In this directory, a file named stderr records trial error and another named trial.log records this trial’s log.

Different kinds of errors

There are different kinds of errors. However, they can be divided into three categories based on their severity. So when nni fails, check each part sequentially.

Generally, if webUI is started successfully, there is a Status in the Overview tab, serving as a possible indicator of what kind of error happens. Otherwise you should check manually.

NNI Fails

This is the most serious error. When this happens, the whole experiment fails and no trial will be run. Usually this might be related to some installation problem.

When this happens, you should check nnictl‘s error output file stderr (i.e., nnictl log stderr) and then the nnimanager‘s log to find if there is any error.

Dispatcher Fails

Dispatcher fails. Usually, for some new users of NNI, it means that tuner fails. You could check dispatcher’s log to see what happens to your dispatcher. For built-in tuner, some common errors might be invalid search space (unsupported type of search space or inconsistence between initializing args in configuration file and actual tuner’s __init__ function args).

Take the later situation as an example. If you write a customized tuner who’s __init__ function has an argument called optimize_mode, which you do not provide in your configuration file, NNI will fail to run your tuner so the experiment fails. You can see errors in the webUI like:

Here we can see it is a dispatcher error. So we can check dispatcher’s log, which might look like:

[2019-02-19 19:36:45] DEBUG (nni.main/MainThread) START
[2019-02-19 19:36:47] ERROR (nni.main/MainThread) __init__() missing 1 required positional arguments: 'optimize_mode'
Traceback (most recent call last):
  File "/usr/lib/python3.7/site-packages/nni/__main__.py", line 202, in <module>
    main()
  File "/usr/lib/python3.7/site-packages/nni/__main__.py", line 164, in main
    args.tuner_args)
  File "/usr/lib/python3.7/site-packages/nni/__main__.py", line 81, in create_customized_class_instance
    instance = class_constructor(**class_args)
TypeError: __init__() missing 1 required positional arguments: 'optimize_mode'.
Trial Fails

In this situation, NNI can still run and create new trials.

It means your trial code (which is run by NNI) fails. This kind of error is strongly related to your trial code. Please check trial’s log to fix any possible errors shown there.

A common example of this would be run the mnist example without installing tensorflow. Surely there is an Import Error (that is, not installing tensorflow but trying to import it in your trial code) and thus every trial fails.

As it shows, every trial has a log path, where you can find trial’s log and stderr.

In addition to experiment level debug, NNI also provides the capability for debugging a single trial without the need to start the entire experiment. Refer to standalone mode for more information about debug single trial code.

Advanced Features

Customize-Tuner

Customize Tuner

NNI provides state-of-the-art tuning algorithm in builtin-tuners. NNI supports to build a tuner by yourself for tuning demand.

If you want to implement your own tuning algorithm, you can implement a customized Tuner, there are three things to do:

  1. Inherit the base Tuner class

  2. Implement receive_trial_result, generate_parameter and update_search_space function

  3. Configure your customized tuner in experiment YAML config file

Here is an example:

1. Inherit the base Tuner class

from nni.tuner import Tuner

class CustomizedTuner(Tuner):
    def __init__(self, ...):
        ...

2. Implement receive_trial_result, generate_parameter and update_search_space function

from nni.tuner import Tuner

class CustomizedTuner(Tuner):
    def __init__(self, ...):
        ...

    def receive_trial_result(self, parameter_id, parameters, value, **kwargs):
        '''
        Receive trial's final result.
        parameter_id: int
        parameters: object created by 'generate_parameters()'
        value: final metrics of the trial, including default metric
        '''
        # your code implements here.
    ...

    def generate_parameters(self, parameter_id, **kwargs):
        '''
        Returns a set of trial (hyper-)parameters, as a serializable object
        parameter_id: int
        '''
        # your code implements here.
        return your_parameters
    ...

    def update_search_space(self, search_space):
        '''
        Tuners are advised to support updating search space at run-time.
        If a tuner can only set search space once before generating first hyper-parameters,
        it should explicitly document this behaviour.
        search_space: JSON object created by experiment owner
        '''
        # your code implements here.
    ...

receive_trial_result will receive the parameter_id, parameters, value as parameters input. Also, Tuner will receive the value object are exactly same value that Trial send.

The your_parameters return from generate_parameters function, will be package as json object by NNI SDK. NNI SDK will unpack json object so the Trial will receive the exact same your_parameters from Tuner.

For example: If the you implement the generate_parameters like this:

def generate_parameters(self, parameter_id, **kwargs):
    '''
    Returns a set of trial (hyper-)parameters, as a serializable object
    parameter_id: int
    '''
    # your code implements here.
    return {"dropout": 0.3, "learning_rate": 0.4}

It means your Tuner will always generate parameters {"dropout": 0.3, "learning_rate": 0.4}. Then Trial will receive {"dropout": 0.3, "learning_rate": 0.4} by calling API nni.get_next_parameter(). Once the trial ends with a result (normally some kind of metrics), it can send the result to Tuner by calling API nni.report_final_result(), for example nni.report_final_result(0.93). Then your Tuner’s receive_trial_result function will receied the result like:

parameter_id = 82347
parameters = {"dropout": 0.3, "learning_rate": 0.4}
value = 0.93

Note that The working directory of your tuner is <home>/nni-experiments/<experiment_id>/log, which can be retrieved with environment variable NNI_LOG_DIRECTORY, therefore, if you want to access a file (e.g., data.txt) in the directory of your own tuner, you cannot use open('data.txt', 'r'). Instead, you should use the following:

_pwd = os.path.dirname(__file__)
_fd = open(os.path.join(_pwd, 'data.txt'), 'r')

This is because your tuner is not executed in the directory of your tuner (i.e., pwd is not the directory of your own tuner).

3. Configure your customized tuner in experiment YAML config file

NNI needs to locate your customized tuner class and instantiate the class, so you need to specify the location of the customized tuner class and pass literal values as parameters to the __init__ constructor.

tuner:
  codeDir: /home/abc/mytuner
  classFileName: my_customized_tuner.py
  className: CustomizedTuner
  # Any parameter need to pass to your tuner class __init__ constructor
  # can be specified in this optional classArgs field, for example
  classArgs:
    arg1: value1

More detail example you could see:

Write a more advanced automl algorithm

The methods above are usually enough to write a general tuner. However, users may also want more methods, for example, intermediate results, trials’ state (e.g., the methods in assessor), in order to have a more powerful automl algorithm. Therefore, we have another concept called advisor which directly inherits from MsgDispatcherBase in msg_dispatcher_base.py. Please refer to here for how to write a customized advisor.

Customize Assessor

NNI supports to build an assessor by yourself for tuning demand.

If you want to implement a customized Assessor, there are three things to do:

  1. Inherit the base Assessor class

  2. Implement assess_trial function

  3. Configure your customized Assessor in experiment YAML config file

1. Inherit the base Assessor class

from nni.assessor import Assessor

class CustomizedAssessor(Assessor):
    def __init__(self, ...):
        ...

2. Implement assess trial function

from nni.assessor import Assessor, AssessResult

class CustomizedAssessor(Assessor):
    def __init__(self, ...):
        ...

    def assess_trial(self, trial_history):
        """
        Determines whether a trial should be killed. Must override.
        trial_history: a list of intermediate result objects.
        Returns AssessResult.Good or AssessResult.Bad.
        """
        # you code implement here.
        ...

3. Configure your customized Assessor in experiment YAML config file

NNI needs to locate your customized Assessor class and instantiate the class, so you need to specify the location of the customized Assessor class and pass literal values as parameters to the __init__ constructor.

assessor:
  codeDir: /home/abc/myassessor
  classFileName: my_customized_assessor.py
  className: CustomizedAssessor
  # Any parameter need to pass to your Assessor class __init__ constructor
  # can be specified in this optional classArgs field, for example
  classArgs:
    arg1: value1

Please noted in 2. The object trial_history are exact the object that Trial send to Assessor by using SDK report_intermediate_result function.

The working directory of your assessor is <home>/nni-experiments/<experiment_id>/log, which can be retrieved with environment variable NNI_LOG_DIRECTORY,

More detail example you could see:

How To - Customize Your Own Advisor

Warning: API is subject to change in future releases.

Advisor targets the scenario that the automl algorithm wants the methods of both tuner and assessor. Advisor is similar to tuner on that it receives trial parameters request, final results, and generate trial parameters. Also, it is similar to assessor on that it receives intermediate results, trial’s end state, and could send trial kill command. Note that, if you use Advisor, tuner and assessor are not allowed to be used at the same time.

If a user want to implement a customized Advisor, she/he only needs to:

1. Define an Advisor inheriting from the MsgDispatcherBase class. For example:

from nni.runtime.msg_dispatcher_base import MsgDispatcherBase

class CustomizedAdvisor(MsgDispatcherBase):
    def __init__(self, ...):
        ...

2. Implement the methods with prefix “handle_” except “handle_request””

You might find docs for MsgDispatcherBase helpful.

3. Configure your customized Advisor in experiment YAML config file.

Similar to tuner and assessor. NNI needs to locate your customized Advisor class and instantiate the class, so you need to specify the location of the customized Advisor class and pass literal values as parameters to the __init__ constructor.

advisor:
  codeDir: /home/abc/myadvisor
  classFileName: my_customized_advisor.py
  className: CustomizedAdvisor
  # Any parameter need to pass to your advisor class __init__ constructor
  # can be specified in this optional classArgs field, for example
  classArgs:
    arg1: value1

Note that The working directory of your advisor is <home>/nni-experiments/<experiment_id>/log, which can be retrieved with environment variable NNI_LOG_DIRECTORY.

Example

Here we provide an example.

How to Implement Training Service in NNI

Overview

TrainingService is a module related to platform management and job schedule in NNI. TrainingService is designed to be easily implemented, we define an abstract class TrainingService as the parent class of all kinds of TrainingService, users just need to inherit the parent class and complete their own child class if they want to implement customized TrainingService.

System architecture

The brief system architecture of NNI is shown in the picture. NNIManager is the core management module of system, in charge of calling TrainingService to manage trial jobs and the communication between different modules. Dispatcher is a message processing center responsible for message dispatch. TrainingService is a module to manage trial jobs, it communicates with nniManager module, and has different instance according to different training platform. For the time being, NNI supports local platfrom, remote platfrom, PAI platfrom, kubeflow platform and FrameworkController platfrom.

In this document, we introduce the brief design of TrainingService. If users want to add a new TrainingService instance, they just need to complete a child class to implement TrainingService, don’t need to understand the code detail of NNIManager, Dispatcher or other modules.

Folder structure of code

NNI’s folder structure is shown below:

nni
  |- deployment
  |- docs
  |- examaples
  |- src
  | |- nni_manager
  | | |- common
  | | |- config
  | | |- core
  | | |- coverage
  | | |- dist
  | | |- rest_server
  | | |- training_service
  | | | |- common
  | | | |- kubernetes
  | | | |- local
  | | | |- pai
  | | | |- remote_machine
  | | | |- test
  | |- sdk
  | |- webui
  |- test
  |- tools
  | |-nni_annotation
  | |-nni_cmd
  | |-nni_gpu_tool
  | |-nni_trial_tool

nni/src/ folder stores the most source code of NNI. The code in this folder is related to NNIManager, TrainingService, SDK, WebUI and other modules. Users could find the abstract class of TrainingService in nni/src/nni_manager/common/trainingService.ts file, and they should put their own implemented TrainingService in nni/src/nni_manager/training_service folder. If users have implemented their own TrainingService code, they should also supplement the unit test of the code, and place them in nni/src/nni_manager/training_service/test folder.

Function annotation of TrainingService
abstract class TrainingService {
    public abstract listTrialJobs(): Promise<TrialJobDetail[]>;
    public abstract getTrialJob(trialJobId: string): Promise<TrialJobDetail>;
    public abstract addTrialJobMetricListener(listener: (metric: TrialJobMetric) => void): void;
    public abstract removeTrialJobMetricListener(listener: (metric: TrialJobMetric) => void): void;
    public abstract submitTrialJob(form: JobApplicationForm): Promise<TrialJobDetail>;
    public abstract updateTrialJob(trialJobId: string, form: JobApplicationForm): Promise<TrialJobDetail>;
    public abstract get isMultiPhaseJobSupported(): boolean;
    public abstract cancelTrialJob(trialJobId: string, isEarlyStopped?: boolean): Promise<void>;
    public abstract setClusterMetadata(key: string, value: string): Promise<void>;
    public abstract getClusterMetadata(key: string): Promise<string>;
    public abstract cleanUp(): Promise<void>;
    public abstract run(): Promise<void>;
}

The parent class of TrainingService has a few abstract functions, users need to inherit the parent class and implement all of these abstract functions.

setClusterMetadata(key: string, value: string)

ClusterMetadata is the data related to platform details, for examples, the ClusterMetadata defined in remote machine server is:

export class RemoteMachineMeta {
    public readonly ip : string;
    public readonly port : number;
    public readonly username : string;
    public readonly passwd?: string;
    public readonly sshKeyPath?: string;
    public readonly passphrase?: string;
    public gpuSummary : GPUSummary | undefined;
    /* GPU Reservation info, the key is GPU index, the value is the job id which reserves this GPU*/
    public gpuReservation : Map<number, string>;

    constructor(ip : string, port : number, username : string, passwd : string,
        sshKeyPath : string, passphrase : string) {
        this.ip = ip;
        this.port = port;
        this.username = username;
        this.passwd = passwd;
        this.sshKeyPath = sshKeyPath;
        this.passphrase = passphrase;
        this.gpuReservation = new Map<number, string>();
    }
}

The metadata includes the host address, the username or other configuration related to the platform. Users need to define their own metadata format, and set the metadata instance in this function. This function is called before the experiment is started to set the configuration of remote machines.

getClusterMetadata(key: string)

This function will return the metadata value according to the values, it could be left empty if users don’t need to use it.

submitTrialJob(form: JobApplicationForm)

SubmitTrialJob is a function to submit new trial jobs, users should generate a job instance in TrialJobDetail type. TrialJobDetail is defined as follow:

interface TrialJobDetail {
    readonly id: string;
    readonly status: TrialJobStatus;
    readonly submitTime: number;
    readonly startTime?: number;
    readonly endTime?: number;
    readonly tags?: string[];
    readonly url?: string;
    readonly workingDirectory: string;
    readonly form: JobApplicationForm;
    readonly sequenceId: number;
    isEarlyStopped?: boolean;
}

According to different kinds of implementation, users could put the job detail into a job queue, and keep fetching the job from the queue and start preparing and running them. Or they could finish preparing and running process in this function, and return job detail after the submit work.

cancelTrialJob(trialJobId: string, isEarlyStopped?: boolean)

If this function is called, the trial started by the platform should be canceled. Different kind of platform has diffenent methods to calcel a running job, this function should be implemented according to specific platform.

updateTrialJob(trialJobId: string, form: JobApplicationForm)

This function is called to update the trial job’s status, trial job’s status should be detected according to different platform, and be updated to RUNNING, SUCCEED, FAILED etc.

getTrialJob(trialJobId: string)

This function returns a trialJob detail instance according to trialJobId.

listTrialJobs()

Users should put all of trial job detail information into a list, and return the list.

addTrialJobMetricListener(listener: (metric: TrialJobMetric) => void)

NNI will hold an EventEmitter to get job metrics, if there is new job metrics detected, the EventEmitter will be triggered. Users should start the EventEmitter in this function.

removeTrialJobMetricListener(listener: (metric: TrialJobMetric) => void)

Close the EventEmitter.

run()

The run() function is a main loop function in TrainingService, users could set a while loop to execute their logic code, and finish executing them when the experiment is stopped.

cleanUp()

This function is called to clean up the environment when a experiment is stopped. Users should do the platform-related cleaning operation in this function.

TrialKeeper tool

NNI offers a TrialKeeper tool to help maintaining trial jobs. Users can find the source code in nni/tools/nni_trial_tool. If users want to run trial jobs in cloud platform, this tool will be a fine choice to help keeping trial running in the platform.

The running architecture of TrialKeeper is show as follow:

When users submit a trial job to cloud platform, they should wrap their trial command into TrialKeeper, and start a TrialKeeper process in cloud platform. Notice that TrialKeeper use restful server to communicate with TrainingService, users should start a restful server in local machine to receive metrics sent from TrialKeeper. The source code about restful server could be found in nni/src/nni_manager/training_service/common/clusterJobRestServer.ts.

Reference

For more information about how to debug, please refer.

The guideline of how to contribute, please refer.

How to register customized algorithms as builtin tuners, assessors and advisors

Overview

NNI provides a lot of builtin tuners, advisors and assessors can be used directly for Hyper Parameter Optimization, and some extra algorithms can be registered via nnictl algo register --meta <path_to_meta_file> after NNI is installed. You can check builtin algorithms via nnictl algo list command.

NNI also provides the ability to build your own customized tuners, advisors and assessors. To use the customized algorithm, users can simply follow the spec in experiment config file to properly reference the algorithm, which has been illustrated in the tutorials of customized tuners / advisors / assessors.

NNI also allows users to install the customized algorithm as a builtin algorithm, in order for users to use the algorithm in the same way as NNI builtin tuners/advisors/assessors. More importantly, it becomes much easier for users to share or distribute their implemented algorithm to others. Customized tuners/advisors/assessors can be installed into NNI as builtin algorithms, once they are installed into NNI, you can use your customized algorithms the same way as builtin tuners/advisors/assessors in your experiment configuration file. For example, you built a customized tuner and installed it into NNI using a builtin name mytuner, then you can use this tuner in your configuration file like below:

tuner:
  builtinTunerName: mytuner
Register customized algorithms as builtin tuners, assessors and advisors

You can follow below steps to build a customized tuner/assessor/advisor, and register it into NNI as builtin algorithm.

2. (Optional) Create a validator to validate classArgs

NNI provides a ClassArgsValidator interface for customized algorithms author to validate the classArgs parameters in experiment configuration file which are passed to customized algorithms constructors. The ClassArgsValidator interface is defined as:

class ClassArgsValidator(object):
    def validate_class_args(self, **kwargs):
        """
        The classArgs fields in experiment configuration are packed as a dict and
        passed to validator as kwargs.
        """
        pass

For example, you can implement your validator such as:

from schema import Schema, Optional
from nni import ClassArgsValidator

class MedianstopClassArgsValidator(ClassArgsValidator):
    def validate_class_args(self, **kwargs):
        Schema({
            Optional('optimize_mode'): self.choices('optimize_mode', 'maximize', 'minimize'),
            Optional('start_step'): self.range('start_step', int, 0, 9999),
        }).validate(kwargs)

The validator will be invoked before experiment is started to check whether the classArgs fields are valid for your customized algorithms.

3. Install your customized algorithms into python environment

Firstly, the customized algorithms need to be prepared as a python package. Then you can install the package into python environment via:

  • Run command python setup.py develop from the package directory, this command will install the package in development mode, this is recommended if your algorithm is under development.

  • Run command python setup.py bdist_wheel from the package directory, this command build a whl file which is a pip installation source. Then run pip install <wheel file> to install it.

4. Prepare meta file

Create a yaml file with following keys as meta file:

  • algoType: type of algorithms, could be one of tuner, assessor, advisor

  • builtinName: builtin name used in experiment configuration file

  • className: tuner class name, including its module name, for example: demo_tuner.DemoTuner

  • classArgsValidator: class args validator class name, including its module name, for example: demo_tuner.MyClassArgsValidator

Following is an example of the yaml file:

algoType: tuner
builtinName: demotuner
className: demo_tuner.DemoTuner
classArgsValidator: demo_tuner.MyClassArgsValidator
5. Register customized algorithms into NNI

Run following command to register the customized algorithms as builtin algorithms in NNI:

nnictl algo register --meta <path_to_meta_file>

The <path_to_meta_file> is the path to the yaml file your created in above section.

Reference customized tuner example for a full example.

Use the installed builtin algorithms in experiment

Once your customized algorithms is installed, you can use it in experiment configuration file the same way as other builtin tuners/assessors/advisors, for example:

tuner:
  builtinTunerName: demotuner
  classArgs:
    #choice: maximize, minimize
    optimize_mode: maximize
Manage builtin algorithms using nnictl algo
List builtin algorithms

Run following command to list the registered builtin algorithms:

nnictl algo list
+-----------------+------------+-----------+--------=-------------+------------------------------------------+
|      Name       |    Type    | Source    |      Class Name      |               Module Name                |
+-----------------+------------+-----------+----------------------+------------------------------------------+
| TPE             | tuners     | nni       | HyperoptTuner        | nni.hyperopt_tuner.hyperopt_tuner        |
| Random          | tuners     | nni       | HyperoptTuner        | nni.hyperopt_tuner.hyperopt_tuner        |
| Anneal          | tuners     | nni       | HyperoptTuner        | nni.hyperopt_tuner.hyperopt_tuner        |
| Evolution       | tuners     | nni       | EvolutionTuner       | nni.evolution_tuner.evolution_tuner      |
| BatchTuner      | tuners     | nni       | BatchTuner           | nni.batch_tuner.batch_tuner              |
| GridSearch      | tuners     | nni       | GridSearchTuner      | nni.gridsearch_tuner.gridsearch_tuner    |
| NetworkMorphism | tuners     | nni       | NetworkMorphismTuner | nni.networkmorphism_tuner.networkmo...   |
| MetisTuner      | tuners     | nni       | MetisTuner           | nni.metis_tuner.metis_tuner              |
| GPTuner         | tuners     | nni       | GPTuner              | nni.gp_tuner.gp_tuner                    |
| PBTTuner        | tuners     | nni       | PBTTuner             | nni.pbt_tuner.pbt_tuner                  |
| SMAC            | tuners     | nni       | SMACTuner            | nni.smac_tuner.smac_tuner                |
| PPOTuner        | tuners     | nni       | PPOTuner             | nni.ppo_tuner.ppo_tuner                  |
| Medianstop      | assessors  | nni       | MedianstopAssessor   | nni.medianstop_assessor.medianstop_...   |
| Curvefitting    | assessors  | nni       | CurvefittingAssessor | nni.curvefitting_assessor.curvefitt...   |
| Hyperband       | advisors   | nni       | Hyperband            | nni.hyperband_advisor.hyperband_adv...   |
| BOHB            | advisors   | nni       | BOHB                 | nni.bohb_advisor.bohb_advisor            |
+-----------------+------------+-----------+----------------------+------------------------------------------+
Unregister builtin algorithms

Run following command to uninstall an installed package:

nnictl algo unregister <builtin name>

For example:

nnictl algo unregister demotuner

Porting customized algorithms from v1.x to v2.x

All that needs to be modified is to delete NNI Package :: tuner metadata in setup.py and add a meta file mentioned in 4. Prepare meta file. Then you can follow Register customized algorithms as builtin tuners, assessors and advisors to register your customized algorithms.

Example: Register a customized tuner as a builtin tuner

You can following below steps to register a customized tuner in nni/examples/tuners/customized_tuner as a builtin tuner.

Install the customized tuner package into python environment

There are 2 options to install the package into python environment:

Option 1: install from directory

From nni/examples/tuners/customized_tuner directory, run:

python setup.py develop

This command will build the nni/examples/tuners/customized_tuner directory as a pip installation source.

Option 2: install from whl file

Step 1: From nni/examples/tuners/customized_tuner directory, run:

python setup.py bdist_wheel

This command build a whl file which is a pip installation source.

Step 2: Run command:

pip install dist/demo_tuner-0.1-py3-none-any.whl

Register the customized tuner as builtin tuner:

Run following command:

nnictl algo register --meta meta_file.yml

Check the registered builtin algorithms

Then run command nnictl algo list, you should be able to see that demotuner is installed:

+-----------------+------------+-----------+--------=-------------+------------------------------------------+
|      Name       |    Type    |   source  |      Class Name      |               Module Name                |
+-----------------+------------+-----------+----------------------+------------------------------------------+
| demotuner       | tuners     |    User   | DemoTuner            | demo_tuner                               |
+-----------------+------------+-----------+----------------------+------------------------------------------+

Model Compression

Deep neural networks (DNNs) have achieved great success in many tasks. However, typical neural networks are both computationally expensive and energy intensive, can be difficult to be deployed on devices with low computation resources or with strict latency requirements. Therefore, a natural thought is to perform model compression to reduce model size and accelerate model training/inference without losing performance significantly. Model compression techniques can be divided into two categories: pruning and quantization. The pruning methods explore the redundancy in the model weights and try to remove/prune the redundant and uncritical weights. Quantization refers to compressing models by reducing the number of bits required to represent weights or activations.

NNI provides an easy-to-use toolkit to help user design and use model pruning and quantization algorithms. It supports Tensorflow and PyTorch with unified interface. For users to compress their models, they only need to add several lines in their code. There are some popular model compression algorithms built-in in NNI. Users could further use NNI’s auto tuning power to find the best compressed model, which is detailed in Auto Model Compression. On the other hand, users could easily customize their new compression algorithms using NNI’s interface.

For details, please refer to the following tutorials:

Model Compression with NNI

As larger neural networks with more layers and nodes are considered, reducing their storage and computational cost becomes critical, especially for some real-time applications. Model compression can be used to address this problem.

NNI provides a model compression toolkit to help user compress and speed up their model with state-of-the-art compression algorithms and strategies. There are several core features supported by NNI model compression:

  • Support many popular pruning and quantization algorithms.

  • Automate model pruning and quantization process with state-of-the-art strategies and NNI’s auto tuning power.

  • Speed up a compressed model to make it have lower inference latency and also make it become smaller.

  • Provide friendly and easy-to-use compression utilities for users to dive into the compression process and results.

  • Concise interface for users to customize their own compression algorithms.

Note

Since NNI compression algorithms are not meant to compress model while NNI speedup tool can truly compress model and reduce latency. To obtain a truly compact model, users should conduct model speedup. The interface and APIs are unified for both PyTorch and TensorFlow, currently only PyTorch version has been supported, TensorFlow version will be supported in future.

Supported Algorithms

The algorithms include pruning algorithms and quantization algorithms.

Pruning Algorithms

Pruning algorithms compress the original network by removing redundant weights or channels of layers, which can reduce model complexity and address the over-fitting issue.

Name

Brief Introduction of Algorithm

Level Pruner

Pruning the specified ratio on each weight based on absolute values of weights

AGP Pruner

Automated gradual pruning (To prune, or not to prune: exploring the efficacy of pruning for model compression) Reference Paper

Lottery Ticket Pruner

The pruning process used by “The Lottery Ticket Hypothesis: Finding Sparse, Trainable Neural Networks”. It prunes a model iteratively. Reference Paper

FPGM Pruner

Filter Pruning via Geometric Median for Deep Convolutional Neural Networks Acceleration Reference Paper

L1Filter Pruner

Pruning filters with the smallest L1 norm of weights in convolution layers (Pruning Filters for Efficient Convnets) Reference Paper

L2Filter Pruner

Pruning filters with the smallest L2 norm of weights in convolution layers

ActivationAPoZRankFilterPruner

Pruning filters based on the metric APoZ (average percentage of zeros) which measures the percentage of zeros in activations of (convolutional) layers. Reference Paper

ActivationMeanRankFilterPruner

Pruning filters based on the metric that calculates the smallest mean value of output activations

Slim Pruner

Pruning channels in convolution layers by pruning scaling factors in BN layers(Learning Efficient Convolutional Networks through Network Slimming) Reference Paper

TaylorFO Pruner

Pruning filters based on the first order taylor expansion on weights(Importance Estimation for Neural Network Pruning) Reference Paper

ADMM Pruner

Pruning based on ADMM optimization technique Reference Paper

NetAdapt Pruner

Automatically simplify a pretrained network to meet the resource budget by iterative pruning Reference Paper

SimulatedAnnealing Pruner

Automatic pruning with a guided heuristic search method, Simulated Annealing algorithm Reference Paper

AutoCompress Pruner

Automatic pruning by iteratively call SimulatedAnnealing Pruner and ADMM Pruner Reference Paper

AMC Pruner

AMC: AutoML for Model Compression and Acceleration on Mobile Devices Reference Paper

You can refer to this benchmark for the performance of these pruners on some benchmark problems.

Quantization Algorithms

Quantization algorithms compress the original network by reducing the number of bits required to represent weights or activations, which can reduce the computations and the inference time.

Name

Brief Introduction of Algorithm

Naive Quantizer

Quantize weights to default 8 bits

QAT Quantizer

Quantization and Training of Neural Networks for Efficient Integer-Arithmetic-Only Inference. Reference Paper

DoReFa Quantizer

DoReFa-Net: Training Low Bitwidth Convolutional Neural Networks with Low Bitwidth Gradients. Reference Paper

BNN Quantizer

Binarized Neural Networks: Training Deep Neural Networks with Weights and Activations Constrained to +1 or -1. Reference Paper

Model Speedup

The final goal of model compression is to reduce inference latency and model size. However, existing model compression algorithms mainly use simulation to check the performance (e.g., accuracy) of compressed model, for example, using masks for pruning algorithms, and storing quantized values still in float32 for quantization algorithms. Given the output masks and quantization bits produced by those algorithms, NNI can really speed up the model. The detailed tutorial of Masked Model Speedup can be found here, The detailed tutorial of Mixed Precision Quantization Model Speedup can be found here.

Compression Utilities

Compression utilities include some useful tools for users to understand and analyze the model they want to compress. For example, users could check sensitivity of each layer to pruning. Users could easily calculate the FLOPs and parameter size of a model. Please refer to here for a complete list of compression utilities.

Advanced Usage

NNI model compression leaves simple interface for users to customize a new compression algorithm. The design philosophy of the interface is making users focus on the compression logic while hiding framework specific implementation details from users. Users can learn more about our compression framework and customize a new compression algorithm (pruning algorithm or quantization algorithm) based on our framework. Moreover, users could leverage NNI’s auto tuning power to automatically compress a model. Please refer to here for more details.

Reference and Feedback

Quick Start

Tutorial

In this tutorial, we will explain more detailed usage about the model compression in NNI.

Setup compression goal
Specify the configuration

Users can specify the configuration (i.e., config_list) for a compression algorithm. For example, when compressing a model, users may want to specify the sparsity ratio, to specify different ratios for different types of operations, to exclude certain types of operations, or to compress only a certain types of operations. For users to express these kinds of requirements, we define a configuration specification. It can be seen as a python list object, where each element is a dict object.

The dicts in the list are applied one by one, that is, the configurations in latter dict will overwrite the configurations in former ones on the operations that are within the scope of both of them.

There are different keys in a dict. Some of them are common keys supported by all the compression algorithms:

  • op_types: This is to specify what types of operations to be compressed. ‘default’ means following the algorithm’s default setting. All suported module types are defined in default_layers.py for pytorch.

  • op_names: This is to specify by name what operations to be compressed. If this field is omitted, operations will not be filtered by it.

  • exclude: Default is False. If this field is True, it means the operations with specified types and names will be excluded from the compression.

Some other keys are often specific to a certain algorithm, users can refer to pruning algorithms and quantization algorithms for the keys allowed by each algorithm.

To prune all Conv2d layers with the sparsity of 0.6, the configuration can be written as:

[{
 'sparsity': 0.6,
 'op_types': ['Conv2d']
}]

To control the sparsity of specific layers, the configuration can be written as:

[{
   'sparsity': 0.8,
   'op_types': ['default']
},
{
   'sparsity': 0.6,
   'op_names': ['op_name1', 'op_name2']
},
{
   'exclude': True,
   'op_names': ['op_name3']
}]

It means following the algorithm’s default setting for compressed operations with sparsity 0.8, but for op_name1 and op_name2 use sparsity 0.6, and do not compress op_name3.

Quantization specific keys

Besides the keys explained above, if you use quantization algorithms you need to specify more keys in config_list, which are explained below.

  • quant_types : list of string.

Type of quantization you want to apply, currently support ‘weight’, ‘input’, ‘output’. ‘weight’ means applying quantization operation to the weight parameter of modules. ‘input’ means applying quantization operation to the input of module forward method. ‘output’ means applying quantization operation to the output of module forward method, which is often called as ‘activation’ in some papers.

  • quant_bits : int or dict of {str : int}

bits length of quantization, key is the quantization type, value is the quantization bits length, eg.

{
   quant_bits: {
      'weight': 8,
      'output': 4,
      },
}

when the value is int type, all quantization types share same bits length. eg.

{
   quant_bits: 8, # weight or output quantization are all 8 bits
}

The following example shows a more complete config_list, it uses op_names (or op_types) to specify the target layers along with the quantization bits for those layers.

config_list = [{
   'quant_types': ['weight'],
   'quant_bits': 8,
   'op_names': ['conv1']
},
{
   'quant_types': ['weight'],
   'quant_bits': 4,
   'quant_start_step': 0,
   'op_names': ['conv2']
},
{
   'quant_types': ['weight'],
   'quant_bits': 3,
   'op_names': ['fc1']
},
{
   'quant_types': ['weight'],
   'quant_bits': 2,
   'op_names': ['fc2']
}]

In this example, ‘op_names’ is the name of layer and four layers will be quantized to different quant_bits.

Export compression result
Export the pruned model

You can easily export the pruned model using the following API if you are pruning your model, state_dict of the sparse model weights will be stored in model.pth, which can be loaded by torch.load('model.pth'). Note that, the exported model.pthhas the same parameters as the original model except the masked weights are zero. mask_dict stores the binary value that produced by the pruning algorithm, which can be further used to speed up the model.

# export model weights and mask
pruner.export_model(model_path='model.pth', mask_path='mask.pth')

# apply mask to model
from nni.compression.pytorch import apply_compression_results

apply_compression_results(model, mask_file, device)

export model in onnx format(input_shape need to be specified):

pruner.export_model(model_path='model.pth', mask_path='mask.pth', onnx_path='model.onnx', input_shape=[1, 1, 28, 28])
Export the quantized model

You can export the quantized model directly by using torch.save api and the quantized model can be loaded by torch.load without any extra modification. The following example shows the normal procedure of saving, loading quantized model and get related parameters in QAT.

# Save quantized model which is generated by using NNI QAT algorithm
torch.save(model.state_dict(), "quantized_model.pth")

# Simulate model loading procedure
# Have to init new model and compress it before loading
qmodel_load = Mnist()
optimizer = torch.optim.SGD(qmodel_load.parameters(), lr=0.01, momentum=0.5)
quantizer = QAT_Quantizer(qmodel_load, config_list, optimizer)
quantizer.compress()

# Load quantized model
qmodel_load.load_state_dict(torch.load("quantized_model.pth"))

# Get scale, zero_point and weight of conv1 in loaded model
conv1 = qmodel_load.conv1
scale = conv1.module.scale
zero_point = conv1.module.zero_point
weight = conv1.module.weight
Speed up the model

Masks do not provide real speedup of your model. The model should be speeded up based on the exported masks, thus, we provide an API to speed up your model as shown below. After invoking apply_compression_results on your model, your model becomes a smaller one with shorter inference latency.

from nni.compression.pytorch import apply_compression_results, ModelSpeedup

dummy_input = torch.randn(config['input_shape']).to(device)
m_speedup = ModelSpeedup(model, dummy_input, masks_file, device)
m_speedup.speedup_model()

Please refer to here for detailed description. The example code for model speedup can be found here

Control the Fine-tuning process
APIs to control the fine-tuning

Some compression algorithms control the progress of compression during fine-tuning (e.g. AGP), and some algorithms need to do something after every minibatch. Therefore, we provide another two APIs for users to invoke: pruner.update_epoch(epoch) and pruner.step().

update_epoch should be invoked in every epoch, while step should be invoked after each minibatch. Note that most algorithms do not require calling the two APIs. Please refer to each algorithm’s document for details. For the algorithms that do not need them, calling them is allowed but has no effect.

Enhance the fine-tuning process

Knowledge distillation effectively learns a small student model from a large teacher model. Users can enhance the fine-tuning process that utilize knowledge distillation to improve the performance of the compressed model. Example code can be found here

Model compression usually consists of three stages: 1) pre-training a model, 2) compress the model, 3) fine-tuning the model. NNI mainly focuses on the second stage and provides very simple APIs for compressing a model. Follow this guide for a quick look at how easy it is to use NNI to compress a model.

Model Pruning

Here we use level pruner as an example to show the usage of pruning in NNI.

Step1. Write configuration

Write a configuration to specify the layers that you want to prune. The following configuration means pruning all the defaultops to sparsity 0.5 while keeping other layers unpruned.

config_list = [{
    'sparsity': 0.5,
    'op_types': ['default'],
}]

The specification of configuration can be found here. Note that different pruners may have their own defined fields in configuration, for exmaple start_epoch in AGP pruner. Please refer to each pruner’s usage for details, and adjust the configuration accordingly.

Step2. Choose a pruner and compress the model

First instantiate the chosen pruner with your model and configuration as arguments, then invoke compress() to compress your model. Note that, some algorithms may check gradients for compressing, so we also define an optimizer and pass it to the pruner.

from nni.algorithms.compression.pytorch.pruning import LevelPruner

optimizer_finetune = torch.optim.SGD(model.parameters(), lr=0.01)
pruner = LevelPruner(model, config_list, optimizer_finetune)
model = pruner.compress()

Then, you can train your model using traditional training approach (e.g., SGD), pruning is applied transparently during the training. Some pruners (e.g., L1FilterPruner, FPGMPruner) prune once at the beginning, the following training can be seen as fine-tune. Some pruners (e.g., AGPPruner) prune your model iteratively, the masks are adjusted epoch by epoch during training.

Note that, pruner.compress simply adds masks on model weights, it does not include fine-tuning logic. If users want to fine tune the compressed model, they need to write the fine tune logic by themselves after pruner.compress.

For example:

for epoch in range(1, args.epochs + 1):
     pruner.update_epoch(epoch)
     train(args, model, device, train_loader, optimizer_finetune, epoch)
     test(model, device, test_loader)

More APIs to control the fine-tuning can be found here.

Step3. Export compression result

After training, you can export model weights to a file, and the generated masks to a file as well. Exporting onnx model is also supported.

pruner.export_model(model_path='pruned_vgg19_cifar10.pth', mask_path='mask_vgg19_cifar10.pth')

Plese refer to mnist example for example code.

More examples of pruning algorithms can be found in basic_pruners_torch and auto_pruners_torch.

Model Quantization

Here we use QAT Quantizer as an example to show the usage of pruning in NNI.

Step1. Write configuration
config_list = [{
    'quant_types': ['weight'],
    'quant_bits': {
        'weight': 8,
    }, # you can just use `int` here because all `quan_types` share same bits length, see config for `ReLu6` below.
    'op_types':['Conv2d', 'Linear']
}, {
    'quant_types': ['output'],
    'quant_bits': 8,
    'quant_start_step': 7000,
    'op_types':['ReLU6']
}]

The specification of configuration can be found here.

Step2. Choose a quantizer and compress the model
from nni.algorithms.compression.pytorch.quantization import QAT_Quantizer

quantizer = QAT_Quantizer(model, config_list)
quantizer.compress()
Step3. Export compression result

After training and calibration, you can export model weight to a file, and the generated calibration parameters to a file as well. Exporting onnx model is also supported.

calibration_config = quantizer.export_model(model_path, calibration_path, onnx_path, input_shape, device)

Plese refer to mnist example for example code.

Congratulations! You’ve compressed your first model via NNI. To go a bit more in depth about model compression in NNI, check out the Tutorial.

Pruning

Pruning is a common technique to compress neural network models. The pruning methods explore the redundancy in the model weights(parameters) and try to remove/prune the redundant and uncritical weights. The redundant elements are pruned from the model, their values are zeroed and we make sure they don’t take part in the back-propagation process.

From pruning granularity perspective, fine-grained pruning or unstructured pruning refers to pruning each individual weights separately. Coarse-grained pruning or structured pruning is pruning entire group of weights, such as a convolutional filter.

NNI provides multiple unstructured pruning and structured pruning algorithms. It supports Tensorflow and PyTorch with unified interface. For users to prune their models, they only need to add several lines in their code. For the structured filter pruning, NNI also provides a dependency-aware mode. In the dependency-aware mode, the filter pruner will get better speed gain after the speedup.

For details, please refer to the following tutorials:

Supported Pruning Algorithms on NNI

We provide several pruning algorithms that support fine-grained weight pruning and structural filter pruning. Fine-grained Pruning generally results in unstructured models, which need specialized hardware or software to speed up the sparse network. Filter Pruning achieves acceleration by removing the entire filter. Some pruning algorithms use one-shot method that prune weights at once based on an importance metric. Other pruning algorithms control the pruning schedule that prune weights during optimization, including some automatic pruning algorithms.

Fine-grained Pruning

Filter Pruning

Pruning Schedule

Others

Level Pruner

This is one basic one-shot pruner: you can set a target sparsity level (expressed as a fraction, 0.6 means we will prune 60% of the weight parameters).

We first sort the weights in the specified layer by their absolute values. And then mask to zero the smallest magnitude weights until the desired sparsity level is reached.

Usage

PyTorch code

from nni.algorithms.compression.pytorch.pruning import LevelPruner
config_list = [{ 'sparsity': 0.8, 'op_types': ['default'] }]
pruner = LevelPruner(model, config_list)
pruner.compress()
User configuration for Level Pruner

PyTorch

class nni.algorithms.compression.pytorch.pruning.LevelPruner(model, config_list, optimizer=None)[source]
Parameters
  • model (torch.nn.Module) – Model to be pruned

  • config_list (list) –

    Supported keys:
    • sparsity : This is to specify the sparsity operations to be compressed to.

    • op_types : Operation types to prune.

  • optimizer (torch.optim.Optimizer) – Optimizer used to train model

TensorFlow

Slim Pruner

This is an one-shot pruner, which adds sparsity regularization on the scaling factors of batch normalization (BN) layers during training to identify unimportant channels. The channels with small scaling factor values will be pruned. For more details, please refer to ‘Learning Efficient Convolutional Networks through Network Slimming’.

Usage

PyTorch code

from nni.algorithms.compression.pytorch.pruning import SlimPruner
config_list = [{ 'sparsity': 0.8, 'op_types': ['BatchNorm2d'] }]
pruner = SlimPruner(model, config_list)
pruner.compress()
User configuration for Slim Pruner

PyTorch

class nni.algorithms.compression.pytorch.pruning.SlimPruner(model, config_list, optimizer=None)[source]
Parameters
  • model (torch.nn.Module) – Model to be pruned

  • config_list (list) –

    Supported keys:
    • sparsity : This is to specify the sparsity operations to be compressed to.

    • op_types : Only BatchNorm2d is supported in Slim Pruner.

  • optimizer (torch.optim.Optimizer) – Optimizer used to train model

Reproduced Experiment

We implemented one of the experiments in Learning Efficient Convolutional Networks through Network Slimming, we pruned 70% channels in the VGGNet for CIFAR-10 in the paper, in which 88.5% parameters are pruned. Our experiments results are as follows:

Model

Error(paper/ours)

Parameters

Pruned

VGGNet

6.34/6.69

20.04M

Pruned-VGGNet

6.20/6.34

2.03M

88.5%

The experiments code can be found at examples/model_compress/pruning/basic_pruners_torch.py

python basic_pruners_torch.py --pruner slim --model vgg19 --sparsity 0.7 --speed-up

FPGM Pruner

This is an one-shot pruner, which prunes filters with the smallest geometric median. FPGM chooses the filters with the most replaceable contribution. For more details, please refer to Filter Pruning via Geometric Median for Deep Convolutional Neural Networks Acceleration.

We also provide a dependency-aware mode for this pruner to get better speedup from the pruning. Please reference dependency-aware for more details.

Usage

PyTorch code

from nni.algorithms.compression.pytorch.pruning import FPGMPruner
config_list = [{
    'sparsity': 0.5,
    'op_types': ['Conv2d']
}]
pruner = FPGMPruner(model, config_list)
pruner.compress()
User configuration for FPGM Pruner

PyTorch

class nni.algorithms.compression.pytorch.pruning.FPGMPruner(model, config_list, optimizer=None, dependency_aware=False, dummy_input=None)[source]
Parameters
  • model (torch.nn.Module) – Model to be pruned

  • config_list (list) –

    Supported keys:
    • sparsity : This is to specify the sparsity operations to be compressed to.

    • op_types : Only Conv2d is supported in FPGM Pruner.

  • optimizer (torch.optim.Optimizer) – Optimizer used to train model

  • dependency_aware (bool) – If prune the model in a dependency-aware way. If it is True, this pruner will prune the model according to the l2-norm of weights and the channel-dependency or group-dependency of the model. In this way, the pruner will force the conv layers that have dependencies to prune the same channels, so the speedup module can better harvest the speed benefit from the pruned model. Note that, if this flag is set True , the dummy_input cannot be None, because the pruner needs a dummy input to trace the dependency between the conv layers.

  • dummy_input (torch.Tensor) – The dummy input to analyze the topology constraints. Note that, the dummy_input should on the same device with the model.

L1Filter Pruner

This is an one-shot pruner, which prunes the filters in the convolution layers.

For more details, please refer to PRUNING FILTERS FOR EFFICIENT CONVNETS.

In addition, we also provide a dependency-aware mode for the L1FilterPruner. For more details about the dependency-aware mode, please reference dependency-aware mode.

Usage

PyTorch code

from nni.algorithms.compression.pytorch.pruning import L1FilterPruner
config_list = [{ 'sparsity': 0.8, 'op_types': ['Conv2d'] }]
pruner = L1FilterPruner(model, config_list)
pruner.compress()
User configuration for L1Filter Pruner

PyTorch

class nni.algorithms.compression.pytorch.pruning.L1FilterPruner(model, config_list, optimizer=None, dependency_aware=False, dummy_input=None)[source]
Parameters
  • model (torch.nn.Module) – Model to be pruned

  • config_list (list) –

    Supported keys:
    • sparsity : This is to specify the sparsity operations to be compressed to.

    • op_types : Only Conv2d is supported in L1FilterPruner.

  • optimizer (torch.optim.Optimizer) – Optimizer used to train model

  • dependency_aware (bool) – If prune the model in a dependency-aware way. If it is True, this pruner will prune the model according to the l2-norm of weights and the channel-dependency or group-dependency of the model. In this way, the pruner will force the conv layers that have dependencies to prune the same channels, so the speedup module can better harvest the speed benefit from the pruned model. Note that, if this flag is set True , the dummy_input cannot be None, because the pruner needs a dummy input to trace the dependency between the conv layers.

  • dummy_input (torch.Tensor) – The dummy input to analyze the topology constraints. Note that, the dummy_input should on the same device with the model.

Reproduced Experiment

We implemented one of the experiments in PRUNING FILTERS FOR EFFICIENT CONVNETS with L1FilterPruner, we pruned VGG-16 for CIFAR-10 to VGG-16-pruned-A in the paper, in which 64% parameters are pruned. Our experiments results are as follows:

Model

Error(paper/ours)

Parameters

Pruned

VGG-16

6.75/6.49

1.5x10^7

VGG-16-pruned-A

6.60/6.47

5.4x10^6

64.0%

The experiments code can be found at examples/model_compress/pruning/basic_pruners_torch.py

python basic_pruners_torch.py --pruner l1filter --model vgg16 --speed-up

L2Filter Pruner

This is a structured pruning algorithm that prunes the filters with the smallest L2 norm of the weights. It is implemented as a one-shot pruner.

We also provide a dependency-aware mode for this pruner to get better speedup from the pruning. Please reference dependency-aware for more details.

Usage

PyTorch code

from nni.algorithms.compression.pytorch.pruning import L2FilterPruner
config_list = [{ 'sparsity': 0.8, 'op_types': ['Conv2d'] }]
pruner = L2FilterPruner(model, config_list)
pruner.compress()
User configuration for L2Filter Pruner

PyTorch

class nni.algorithms.compression.pytorch.pruning.L2FilterPruner(model, config_list, optimizer=None, dependency_aware=False, dummy_input=None)[source]
Parameters
  • model (torch.nn.Module) – Model to be pruned

  • config_list (list) –

    Supported keys:
    • sparsity : This is to specify the sparsity operations to be compressed to.

    • op_types : Only Conv2d is supported in L2FilterPruner.

  • optimizer (torch.optim.Optimizer) – Optimizer used to train model

  • dependency_aware (bool) – If prune the model in a dependency-aware way. If it is True, this pruner will prune the model according to the l2-norm of weights and the channel-dependency or group-dependency of the model. In this way, the pruner will force the conv layers that have dependencies to prune the same channels, so the speedup module can better harvest the speed benefit from the pruned model. Note that, if this flag is set True , the dummy_input cannot be None, because the pruner needs a dummy input to trace the dependency between the conv layers.

  • dummy_input (torch.Tensor) – The dummy input to analyze the topology constraints. Note that, the dummy_input should on the same device with the model.


ActivationAPoZRankFilter Pruner

ActivationAPoZRankFilter Pruner is a pruner which prunes the filters with the smallest importance criterion APoZ calculated from the output activations of convolution layers to achieve a preset level of network sparsity. The pruning criterion APoZ is explained in the paper Network Trimming: A Data-Driven Neuron Pruning Approach towards Efficient Deep Architectures.

The APoZ is defined as:

\(APoZ_{c}^{(i)} = APoZ\left(O_{c}^{(i)}\right)=\frac{\sum_{k}^{N} \sum_{j}^{M} f\left(O_{c, j}^{(i)}(k)=0\right)}{N \times M}\)

We also provide a dependency-aware mode for this pruner to get better speedup from the pruning. Please reference dependency-aware for more details.

Usage

PyTorch code

from nni.algorithms.compression.pytorch.pruning import ActivationAPoZRankFilterPruner
config_list = [{
    'sparsity': 0.5,
    'op_types': ['Conv2d']
}]
pruner = ActivationAPoZRankFilterPruner(model, config_list, statistics_batch_num=1)
pruner.compress()

Note: ActivationAPoZRankFilterPruner is used to prune convolutional layers within deep neural networks, therefore the op_types field supports only convolutional layers.

You can view example for more information.

User configuration for ActivationAPoZRankFilter Pruner

PyTorch

class nni.algorithms.compression.pytorch.pruning.ActivationAPoZRankFilterPruner(model, config_list, optimizer=None, activation='relu', statistics_batch_num=1, dependency_aware=False, dummy_input=None)[source]
Parameters
  • model (torch.nn.Module) – Model to be pruned

  • config_list (list) –

    Supported keys:
    • sparsity : How much percentage of convolutional filters are to be pruned.

    • op_types : Only Conv2d is supported in ActivationAPoZRankFilterPruner.

  • optimizer (torch.optim.Optimizer) – Optimizer used to train model

  • activation (str) – The activation type.

  • statistics_batch_num (int) – The number of batches to statistic the activation.

  • dependency_aware (bool) – If prune the model in a dependency-aware way. If it is True, this pruner will prune the model according to the l2-norm of weights and the channel-dependency or group-dependency of the model. In this way, the pruner will force the conv layers that have dependencies to prune the same channels, so the speedup module can better harvest the speed benefit from the pruned model. Note that, if this flag is set True , the dummy_input cannot be None, because the pruner needs a dummy input to trace the dependency between the conv layers.

  • dummy_input (torch.Tensor) – The dummy input to analyze the topology constraints. Note that, the dummy_input should on the same device with the model.


ActivationMeanRankFilter Pruner

ActivationMeanRankFilterPruner is a pruner which prunes the filters with the smallest importance criterion mean activation calculated from the output activations of convolution layers to achieve a preset level of network sparsity. The pruning criterion mean activation is explained in section 2.2 of the paper Pruning Convolutional Neural Networks for Resource Efficient Inference. Other pruning criteria mentioned in this paper will be supported in future release.

We also provide a dependency-aware mode for this pruner to get better speedup from the pruning. Please reference dependency-aware for more details.

Usage

PyTorch code

from nni.algorithms.compression.pytorch.pruning import ActivationMeanRankFilterPruner
config_list = [{
    'sparsity': 0.5,
    'op_types': ['Conv2d']
}]
pruner = ActivationMeanRankFilterPruner(model, config_list, statistics_batch_num=1)
pruner.compress()

Note: ActivationMeanRankFilterPruner is used to prune convolutional layers within deep neural networks, therefore the op_types field supports only convolutional layers.

You can view example for more information.

User configuration for ActivationMeanRankFilterPruner

PyTorch

class nni.algorithms.compression.pytorch.pruning.ActivationMeanRankFilterPruner(model, config_list, optimizer=None, activation='relu', statistics_batch_num=1, dependency_aware=False, dummy_input=None)[source]
Parameters
  • model (torch.nn.Module) – Model to be pruned

  • config_list (list) –

    Supported keys:
    • sparsity : How much percentage of convolutional filters are to be pruned.

    • op_types : Only Conv2d is supported in ActivationMeanRankFilterPruner.

  • optimizer (torch.optim.Optimizer) – Optimizer used to train model.

  • activation (str) – The activation type.

  • statistics_batch_num (int) – The number of batches to statistic the activation.

  • dependency_aware (bool) – If prune the model in a dependency-aware way. If it is True, this pruner will prune the model according to the l2-norm of weights and the channel-dependency or group-dependency of the model. In this way, the pruner will force the conv layers that have dependencies to prune the same channels, so the speedup module can better harvest the speed benefit from the pruned model. Note that, if this flag is set True , the dummy_input cannot be None, because the pruner needs a dummy input to trace the dependency between the conv layers.

  • dummy_input (torch.Tensor) – The dummy input to analyze the topology constraints. Note that, the dummy_input should on the same device with the model.


TaylorFOWeightFilter Pruner

TaylorFOWeightFilter Pruner is a pruner which prunes convolutional layers based on estimated importance calculated from the first order taylor expansion on weights to achieve a preset level of network sparsity. The estimated importance of filters is defined as the paper Importance Estimation for Neural Network Pruning. Other pruning criteria mentioned in this paper will be supported in future release.

\(\widehat{\mathcal{I}}_{\mathcal{S}}^{(1)}(\mathbf{W}) \triangleq \sum_{s \in \mathcal{S}} \mathcal{I}_{s}^{(1)}(\mathbf{W})=\sum_{s \in \mathcal{S}}\left(g_{s} w_{s}\right)^{2}\)

We also provide a dependency-aware mode for this pruner to get better speedup from the pruning. Please reference dependency-aware for more details.

Usage

PyTorch code

from nni.algorithms.compression.pytorch.pruning import TaylorFOWeightFilterPruner
config_list = [{
    'sparsity': 0.5,
    'op_types': ['Conv2d']
}]
pruner = TaylorFOWeightFilterPruner(model, config_list, statistics_batch_num=1)
pruner.compress()
User configuration for TaylorFOWeightFilter Pruner

PyTorch

class nni.algorithms.compression.pytorch.pruning.TaylorFOWeightFilterPruner(model, config_list, optimizer=None, statistics_batch_num=1, dependency_aware=False, dummy_input=None)[source]
Parameters
  • model (torch.nn.Module) – Model to be pruned

  • config_list (list) –

    Supported keys:
    • sparsity : How much percentage of convolutional filters are to be pruned.

    • op_types : Currently only Conv2d is supported in TaylorFOWeightFilterPruner.

  • optimizer (torch.optim.Optimizer) – Optimizer used to train model

  • statistics_batch_num (int) – The number of batches to statistic the activation.

  • dependency_aware (bool) – If prune the model in a dependency-aware way. If it is True, this pruner will prune the model according to the l2-norm of weights and the channel-dependency or group-dependency of the model. In this way, the pruner will force the conv layers that have dependencies to prune the same channels, so the speedup module can better harvest the speed benefit from the pruned model. Note that, if this flag is set True , the dummy_input cannot be None, because the pruner needs a dummy input to trace the dependency between the conv layers.

  • dummy_input (torch.Tensor) – The dummy input to analyze the topology constraints. Note that, the dummy_input should on the same device with the model.


AGP Pruner

This is an iterative pruner, which the sparsity is increased from an initial sparsity value si (usually 0) to a final sparsity value sf over a span of n pruning steps, starting at training step \(t_{0}\) and with pruning frequency \(\Delta t\):

\(s_{t}=s_{f}+\left(s_{i}-s_{f}\right)\left(1-\frac{t-t_{0}}{n \Delta t}\right)^{3} \text { for } t \in\left\{t_{0}, t_{0}+\Delta t, \ldots, t_{0} + n \Delta t\right\}\)

For more details please refer to To prune, or not to prune: exploring the efficacy of pruning for model compression.

Usage

You can prune all weights from 0% to 80% sparsity in 10 epoch with the code below.

PyTorch code

from nni.algorithms.compression.pytorch.pruning import AGPPruner
config_list = [{
    'initial_sparsity': 0,
    'final_sparsity': 0.8,
    'start_epoch': 0,
    'end_epoch': 10,
    'frequency': 1,
    'op_types': ['default']
}]

# load a pretrained model or train a model before using a pruner
# model = MyModel()
# model.load_state_dict(torch.load('mycheckpoint.pth'))

# AGP pruner prunes model while fine tuning the model by adding a hook on
# optimizer.step(), so an optimizer is required to prune the model.
optimizer = torch.optim.SGD(model.parameters(), lr=0.001, momentum=0.9, weight_decay=1e-4)

pruner = AGPPruner(model, config_list, optimizer, pruning_algorithm='level')
pruner.compress()

AGP pruner uses LevelPruner algorithms to prune the weight by default, however you can set pruning_algorithm parameter to other values to use other pruning algorithms:

  • level: LevelPruner

  • slim: SlimPruner

  • l1: L1FilterPruner

  • l2: L2FilterPruner

  • fpgm: FPGMPruner

  • taylorfo: TaylorFOWeightFilterPruner

  • apoz: ActivationAPoZRankFilterPruner

  • mean_activation: ActivationMeanRankFilterPruner

You should add code below to update epoch number when you finish one epoch in your training code.

PyTorch code

pruner.update_epoch(epoch)
User configuration for AGP Pruner

PyTorch

class nni.algorithms.compression.pytorch.pruning.AGPPruner(model, config_list, optimizer, pruning_algorithm='level')[source]
Parameters
  • model (torch.nn.Module) – Model to be pruned.

  • config_list (listlist) –

    Supported keys:
    • initial_sparsity: This is to specify the sparsity when compressor starts to compress.

    • final_sparsity: This is to specify the sparsity when compressor finishes to compress.

    • start_epoch: This is to specify the epoch number when compressor starts to compress, default start from epoch 0.

    • end_epoch: This is to specify the epoch number when compressor finishes to compress.

    • frequency: This is to specify every frequency number epochs compressor compress once, default frequency=1.

  • optimizer (torch.optim.Optimizer) – Optimizer used to train model.

  • pruning_algorithm (str) – Algorithms being used to prune model, choose from [‘level’, ‘slim’, ‘l1’, ‘l2’, ‘fpgm’, ‘taylorfo’, ‘apoz’, ‘mean_activation’], by default level


NetAdapt Pruner

NetAdapt allows a user to automatically simplify a pretrained network to meet the resource budget. Given the overall sparsity, NetAdapt will automatically generate the sparsities distribution among different layers by iterative pruning.

For more details, please refer to NetAdapt: Platform-Aware Neural Network Adaptation for Mobile Applications.

Usage

PyTorch code

from nni.algorithms.compression.pytorch.pruning import NetAdaptPruner
config_list = [{
    'sparsity': 0.5,
    'op_types': ['Conv2d']
}]
pruner = NetAdaptPruner(model, config_list, short_term_fine_tuner=short_term_fine_tuner, evaluator=evaluator,base_algo='l1', experiment_data_dir='./')
pruner.compress()

You can view example for more information.

User configuration for NetAdapt Pruner

PyTorch

class nni.algorithms.compression.pytorch.pruning.NetAdaptPruner(model, config_list, short_term_fine_tuner, evaluator, optimize_mode='maximize', base_algo='l1', sparsity_per_iteration=0.05, experiment_data_dir='./')[source]

A Pytorch implementation of NetAdapt compression algorithm.

Parameters
  • model (pytorch model) – The model to be pruned.

  • config_list (list) –

    Supported keys:
    • sparsity : The target overall sparsity.

    • op_types : The operation type to prune.

  • short_term_fine_tuner (function) –

    function to short-term fine tune the masked model. This function should include model as the only parameter, and fine tune the model for a short term after each pruning iteration. Example:

    def short_term_fine_tuner(model, epoch=3):
        device = torch.device("cuda" if torch.cuda.is_available() else "cpu")
        train_loader = ...
        criterion = torch.nn.CrossEntropyLoss()
        optimizer = torch.optim.SGD(model.parameters(), lr=0.01)
        model.train()
        for _ in range(epoch):
            for batch_idx, (data, target) in enumerate(train_loader):
                data, target = data.to(device), target.to(device)
                optimizer.zero_grad()
                output = model(data)
                loss = criterion(output, target)
                loss.backward()
                optimizer.step()
    

  • evaluator (function) –

    function to evaluate the masked model. This function should include model as the only parameter, and returns a scalar value. Example:

    def evaluator(model):
        device = torch.device("cuda" if torch.cuda.is_available() else "cpu")
        val_loader = ...
        model.eval()
        correct = 0
        with torch.no_grad():
            for data, target in val_loader:
                data, target = data.to(device), target.to(device)
                output = model(data)
                # get the index of the max log-probability
                pred = output.argmax(dim=1, keepdim=True)
                correct += pred.eq(target.view_as(pred)).sum().item()
        accuracy = correct / len(val_loader.dataset)
        return accuracy
    

  • optimize_mode (str) – optimize mode, maximize or minimize, by default maximize.

  • base_algo (str) – Base pruning algorithm. level, l1, l2 or fpgm, by default l1. Given the sparsity distribution among the ops, the assigned base_algo is used to decide which filters/channels/weights to prune.

  • sparsity_per_iteration (float) – sparsity to prune in each iteration.

  • experiment_data_dir (str) – PATH to save experiment data, including the config_list generated for the base pruning algorithm and the performance of the pruned model.

SimulatedAnnealing Pruner

We implement a guided heuristic search method, Simulated Annealing (SA) algorithm, with enhancement on guided search based on prior experience. The enhanced SA technique is based on the observation that a DNN layer with more number of weights often has a higher degree of model compression with less impact on overall accuracy.

  • Randomly initialize a pruning rate distribution (sparsities).

  • While current_temperature < stop_temperature:

    1. generate a perturbation to current distribution

    2. Perform fast evaluation on the perturbated distribution

    3. accept the perturbation according to the performance and probability, if not accepted, return to step 1

    4. cool down, current_temperature <- current_temperature * cool_down_rate

For more details, please refer to AutoCompress: An Automatic DNN Structured Pruning Framework for Ultra-High Compression Rates.

Usage

PyTorch code

from nni.algorithms.compression.pytorch.pruning import SimulatedAnnealingPruner
config_list = [{
    'sparsity': 0.5,
    'op_types': ['Conv2d']
}]
pruner = SimulatedAnnealingPruner(model, config_list, evaluator=evaluator, base_algo='l1', cool_down_rate=0.9, experiment_data_dir='./')
pruner.compress()

You can view example for more information.

User configuration for SimulatedAnnealing Pruner

PyTorch

class nni.algorithms.compression.pytorch.pruning.SimulatedAnnealingPruner(model, config_list, evaluator, optimize_mode='maximize', base_algo='l1', start_temperature=100, stop_temperature=20, cool_down_rate=0.9, perturbation_magnitude=0.35, experiment_data_dir='./')[source]

A Pytorch implementation of Simulated Annealing compression algorithm.

Parameters
  • model (pytorch model) – The model to be pruned.

  • config_list (list) –

    Supported keys:
    • sparsity : The target overall sparsity.

    • op_types : The operation type to prune.

  • evaluator (function) –

    Function to evaluate the pruned model. This function should include model as the only parameter, and returns a scalar value. Example:

    def evaluator(model):
        device = torch.device("cuda" if torch.cuda.is_available() else "cpu")
        val_loader = ...
        model.eval()
        correct = 0
        with torch.no_grad():
            for data, target in val_loader:
                data, target = data.to(device), target.to(device)
                output = model(data)
                # get the index of the max log-probability
                pred = output.argmax(dim=1, keepdim=True)
                correct += pred.eq(target.view_as(pred)).sum().item()
        accuracy = correct / len(val_loader.dataset)
        return accuracy
    

  • optimize_mode (str) – Optimize mode, maximize or minimize, by default maximize.

  • base_algo (str) – Base pruning algorithm. level, l1, l2 or fpgm, by default l1. Given the sparsity distribution among the ops, the assigned base_algo is used to decide which filters/channels/weights to prune.

  • start_temperature (float) – Start temperature of the simulated annealing process.

  • stop_temperature (float) – Stop temperature of the simulated annealing process.

  • cool_down_rate (float) – Cool down rate of the temperature.

  • perturbation_magnitude (float) – Initial perturbation magnitude to the sparsities. The magnitude decreases with current temperature.

  • experiment_data_dir (string) – PATH to save experiment data, including the config_list generated for the base pruning algorithm, the performance of the pruned model and the pruning history.

AutoCompress Pruner

For each round, AutoCompressPruner prune the model for the same sparsity to achive the overall sparsity:

1. Generate sparsities distribution using SimulatedAnnealingPruner
2. Perform ADMM-based structured pruning to generate pruning result for the next round.
   Here we use `speedup` to perform real pruning.

For more details, please refer to AutoCompress: An Automatic DNN Structured Pruning Framework for Ultra-High Compression Rates.

Usage

PyTorch code

from nni.algorithms.compression.pytorch.pruning import AutoCompressPruner
config_list = [{
        'sparsity': 0.5,
        'op_types': ['Conv2d']
    }]
pruner = AutoCompressPruner(
            model, config_list, trainer=trainer, evaluator=evaluator,
            dummy_input=dummy_input, num_iterations=3, optimize_mode='maximize', base_algo='l1',
            cool_down_rate=0.9, admm_num_iterations=30, admm_training_epochs=5, experiment_data_dir='./')
pruner.compress()

You can view example for more information.

User configuration for AutoCompress Pruner

PyTorch

class nni.algorithms.compression.pytorch.pruning.AutoCompressPruner(model, config_list, trainer, evaluator, dummy_input, num_iterations=3, optimize_mode='maximize', base_algo='l1', start_temperature=100, stop_temperature=20, cool_down_rate=0.9, perturbation_magnitude=0.35, admm_num_iterations=30, admm_training_epochs=5, row=0.0001, experiment_data_dir='./')[source]

A Pytorch implementation of AutoCompress pruning algorithm.

Parameters
  • model (pytorch model) – The model to be pruned.

  • config_list (list) –

    Supported keys:
    • sparsity : The target overall sparsity.

    • op_types : The operation type to prune.

  • trainer (function) –

    Function used for the first subproblem of ADMM Pruner. Users should write this function as a normal function to train the Pytorch model and include model, optimizer, criterion, epoch, callback as function arguments. Here callback acts as an L2 regulizer as presented in the formula (7) of the original paper. The logic of callback is implemented inside the Pruner, users are just required to insert callback() between loss.backward() and optimizer.step(). Example:

    def trainer(model, criterion, optimizer, epoch, callback):
        device = torch.device("cuda" if torch.cuda.is_available() else "cpu")
        train_loader = ...
        model.train()
        for batch_idx, (data, target) in enumerate(train_loader):
            data, target = data.to(device), target.to(device)
            optimizer.zero_grad()
            output = model(data)
            loss = criterion(output, target)
            loss.backward()
            # callback should be inserted between loss.backward() and optimizer.step()
            if callback:
                callback()
            optimizer.step()
    

  • evaluator (function) –

    function to evaluate the pruned model. This function should include model as the only parameter, and returns a scalar value. Example:

    def evaluator(model):
        device = torch.device("cuda" if torch.cuda.is_available() else "cpu")
        val_loader = ...
        model.eval()
        correct = 0
        with torch.no_grad():
            for data, target in val_loader:
                data, target = data.to(device), target.to(device)
                output = model(data)
                # get the index of the max log-probability
                pred = output.argmax(dim=1, keepdim=True)
                correct += pred.eq(target.view_as(pred)).sum().item()
        accuracy = correct / len(val_loader.dataset)
        return accuracy
    

  • dummy_input (pytorch tensor) – The dummy input for `jit.trace`, users should put it on right device before pass in.

  • num_iterations (int) – Number of overall iterations.

  • optimize_mode (str) – optimize mode, maximize or minimize, by default maximize.

  • base_algo (str) – Base pruning algorithm. level, l1, l2 or fpgm, by default l1. Given the sparsity distribution among the ops, the assigned base_algo is used to decide which filters/channels/weights to prune.

  • start_temperature (float) – Start temperature of the simulated annealing process.

  • stop_temperature (float) – Stop temperature of the simulated annealing process.

  • cool_down_rate (float) – Cool down rate of the temperature.

  • perturbation_magnitude (float) – Initial perturbation magnitude to the sparsities. The magnitude decreases with current temperature.

  • admm_num_iterations (int) – Number of iterations of ADMM Pruner.

  • admm_training_epochs (int) – Training epochs of the first optimization subproblem of ADMMPruner.

  • row (float) – Penalty parameters for ADMM training.

  • experiment_data_dir (string) – PATH to store temporary experiment data.

AMC Pruner

AMC pruner leverages reinforcement learning to provide the model compression policy. This learning-based compression policy outperforms conventional rule-based compression policy by having higher compression ratio, better preserving the accuracy and freeing human labor.

For more details, please refer to AMC: AutoML for Model Compression and Acceleration on Mobile Devices.

Usage

PyTorch code

from nni.algorithms.compression.pytorch.pruning import AMCPruner
config_list = [{
        'op_types': ['Conv2d', 'Linear']
    }]
pruner = AMCPruner(model, config_list, evaluator, val_loader, flops_ratio=0.5)
pruner.compress()

You can view example for more information.

User configuration for AMC Pruner

PyTorch

class nni.algorithms.compression.pytorch.pruning.AMCPruner(model, config_list, evaluator, val_loader, suffix=None, model_type='mobilenet', dataset='cifar10', flops_ratio=0.5, lbound=0.2, rbound=1.0, reward='acc_reward', n_calibration_batches=60, n_points_per_layer=10, channel_round=8, hidden1=300, hidden2=300, lr_c=0.001, lr_a=0.0001, warmup=100, discount=1.0, bsize=64, rmsize=100, window_length=1, tau=0.01, init_delta=0.5, delta_decay=0.99, max_episode_length=1000000000.0, output_dir='./logs', debug=False, train_episode=800, epsilon=50000, seed=None)[source]

A pytorch implementation of AMC: AutoML for Model Compression and Acceleration on Mobile Devices. (https://arxiv.org/pdf/1802.03494.pdf)

Parameters
  • model – nn.Module The model to be pruned.

  • config_list – list Configuration list to configure layer pruning. Supported keys: - op_types: operation type to be pruned - op_names: operation name to be pruned

  • evaluator – function function to evaluate the pruned model. The prototype of the function: >>> def evaluator(val_loader, model): >>> … >>> return acc

  • val_loader – torch.utils.data.DataLoader Data loader of validation dataset.

  • suffix – str suffix to help you remember what experiment you ran. Default: None.

  • parameters for pruning environment (#) –

  • model_type – str model type to prune, currently ‘mobilenet’ and ‘mobilenetv2’ are supported. Default: mobilenet

  • flops_ratio – float preserve flops ratio. Default: 0.5

  • lbound – float minimum weight preserve ratio for each layer. Default: 0.2

  • rbound – float maximum weight preserve ratio for each layer. Default: 1.0

  • reward – function reward function type: - acc_reward: accuracy * 0.01 - acc_flops_reward: - (100 - accuracy) * 0.01 * np.log(flops) Default: acc_reward

  • parameters for channel pruning (#) –

  • n_calibration_batches – int number of batches to extract layer information. Default: 60

  • n_points_per_layer – int number of feature points per layer. Default: 10

  • channel_round – int round channel to multiple of channel_round. Default: 8

  • parameters for ddpg agent (#) –

  • hidden1 – int hidden num of first fully connect layer. Default: 300

  • hidden2 – int hidden num of second fully connect layer. Default: 300

  • lr_c – float learning rate for critic. Default: 1e-3

  • lr_a – float learning rate for actor. Default: 1e-4

  • warmup – int number of episodes without training but only filling the replay memory. During warmup episodes, random actions ares used for pruning. Default: 100

  • discount – float next Q value discount for deep Q value target. Default: 0.99

  • bsize – int minibatch size for training DDPG agent. Default: 64

  • rmsize – int memory size for each layer. Default: 100

  • window_length – int replay buffer window length. Default: 1

  • tau – float moving average for target network being used by soft_update. Default: 0.99

  • noise (#) –

  • init_delta – float initial variance of truncated normal distribution

  • delta_decay – float delta decay during exploration

  • parameters for training ddpg agent (#) –

  • max_episode_length – int maximum episode length

  • output_dir – str output directory to save log files and model files. Default: ./logs

  • debug – boolean debug mode

  • train_episode – int train iters each timestep. Default: 800

  • epsilon – int linear decay of exploration policy. Default: 50000

  • seed – int random seed to set for reproduce experiment. Default: None

Reproduced Experiment

We implemented one of the experiments in AMC: AutoML for Model Compression and Acceleration on Mobile Devices, we pruned MobileNet to 50% FLOPS for ImageNet in the paper. Our experiments results are as follows:

Model

Top 1 acc.(paper/ours)

Top 5 acc. (paper/ours)

FLOPS

MobileNet

70.5% / 69.9%

89.3% / 89.1%

50%

The experiments code can be found at examples/model_compress/pruning/

ADMM Pruner

Alternating Direction Method of Multipliers (ADMM) is a mathematical optimization technique, by decomposing the original nonconvex problem into two subproblems that can be solved iteratively. In weight pruning problem, these two subproblems are solved via 1) gradient descent algorithm and 2) Euclidean projection respectively.

During the process of solving these two subproblems, the weights of the original model will be changed. An one-shot pruner will then be applied to prune the model according to the config list given.

This solution framework applies both to non-structured and different variations of structured pruning schemes.

For more details, please refer to A Systematic DNN Weight Pruning Framework using Alternating Direction Method of Multipliers.

Usage

PyTorch code

from nni.algorithms.compression.pytorch.pruning import ADMMPruner
config_list = [{
            'sparsity': 0.8,
            'op_types': ['Conv2d'],
            'op_names': ['conv1']
        }, {
            'sparsity': 0.92,
            'op_types': ['Conv2d'],
            'op_names': ['conv2']
        }]
pruner = ADMMPruner(model, config_list, trainer=trainer, num_iterations=30, epochs=5)
pruner.compress()

You can view example for more information.

User configuration for ADMM Pruner

PyTorch

class nni.algorithms.compression.pytorch.pruning.ADMMPruner(model, config_list, trainer, num_iterations=30, training_epochs=5, row=0.0001, base_algo='l1')[source]

A Pytorch implementation of ADMM Pruner algorithm.

Parameters
  • model (torch.nn.Module) – Model to be pruned.

  • config_list (list) – List on pruning configs.

  • trainer (function) –

    Function used for the first subproblem. Users should write this function as a normal function to train the Pytorch model and include model, optimizer, criterion, epoch, callback as function arguments. Here callback acts as an L2 regulizer as presented in the formula (7) of the original paper. The logic of callback is implemented inside the Pruner, users are just required to insert callback() between loss.backward() and optimizer.step(). Example:

    def trainer(model, criterion, optimizer, epoch, callback):
        device = torch.device("cuda" if torch.cuda.is_available() else "cpu")
        train_loader = ...
        model.train()
        for batch_idx, (data, target) in enumerate(train_loader):
            data, target = data.to(device), target.to(device)
            optimizer.zero_grad()
            output = model(data)
            loss = criterion(output, target)
            loss.backward()
            # callback should be inserted between loss.backward() and optimizer.step()
            if callback:
                callback()
            optimizer.step()
    

  • num_iterations (int) – Total number of iterations.

  • training_epochs (int) – Training epochs of the first subproblem.

  • row (float) – Penalty parameters for ADMM training.

  • base_algo (str) – Base pruning algorithm. level, l1, l2 or fpgm, by default l1. Given the sparsity distribution among the ops, the assigned base_algo is used to decide which filters/channels/weights to prune.

Lottery Ticket Hypothesis

The Lottery Ticket Hypothesis: Finding Sparse, Trainable Neural Networks, authors Jonathan Frankle and Michael Carbin,provides comprehensive measurement and analysis, and articulate the lottery ticket hypothesis: dense, randomly-initialized, feed-forward networks contain subnetworks (winning tickets) that – when trained in isolation – reach test accuracy comparable to the original network in a similar number of iterations.

In this paper, the authors use the following process to prune a model, called iterative prunning:

  1. Randomly initialize a neural network f(x;theta_0) (where theta0 follows D{theta}).

  2. Train the network for j iterations, arriving at parameters theta_j.

  3. Prune p% of the parameters in theta_j, creating a mask m.

  4. Reset the remaining parameters to their values in theta_0, creating the winning ticket f(x;m*theta_0).

  5. Repeat step 2, 3, and 4.

If the configured final sparsity is P (e.g., 0.8) and there are n times iterative pruning, each iterative pruning prunes 1-(1-P)^(1/n) of the weights that survive the previous round.

Usage

PyTorch code

from nni.algorithms.compression.pytorch.pruning import LotteryTicketPruner
config_list = [{
    'prune_iterations': 5,
    'sparsity': 0.8,
    'op_types': ['default']
}]
pruner = LotteryTicketPruner(model, config_list, optimizer)
pruner.compress()
for _ in pruner.get_prune_iterations():
    pruner.prune_iteration_start()
    for epoch in range(epoch_num):
        ...

The above configuration means that there are 5 times of iterative pruning. As the 5 times iterative pruning are executed in the same run, LotteryTicketPruner needs model and optimizer (Note that should add ``lr_scheduler`` if used) to reset their states every time a new prune iteration starts. Please use get_prune_iterations to get the pruning iterations, and invoke prune_iteration_start at the beginning of each iteration. epoch_num is better to be large enough for model convergence, because the hypothesis is that the performance (accuracy) got in latter rounds with high sparsity could be comparable with that got in the first round.

User configuration for LotteryTicket Pruner

PyTorch

class nni.algorithms.compression.pytorch.pruning.LotteryTicketPruner(model, config_list, optimizer=None, lr_scheduler=None, reset_weights=True)[source]
Parameters
  • model (pytorch model) – The model to be pruned

  • config_list (list) –

    Supported keys:
    • prune_iterations : The number of rounds for the iterative pruning.

    • sparsity : The final sparsity when the compression is done.

  • optimizer (pytorch optimizer) – The optimizer for the model

  • lr_scheduler (pytorch lr scheduler) – The lr scheduler for the model if used

  • reset_weights (bool) – Whether reset weights and optimizer at the beginning of each round.

Reproduced Experiment

We try to reproduce the experiment result of the fully connected network on MNIST using the same configuration as in the paper. The code can be referred here. In this experiment, we prune 10 times, for each pruning we train the pruned model for 50 epochs.

The above figure shows the result of the fully connected network. round0-sparsity-0.0 is the performance without pruning. Consistent with the paper, pruning around 80% also obtain similar performance compared to non-pruning, and converges a little faster. If pruning too much, e.g., larger than 94%, the accuracy becomes lower and convergence becomes a little slower. A little different from the paper, the trend of the data in the paper is relatively more clear.

Sensitivity Pruner

For each round, SensitivityPruner prunes the model based on the sensitivity to the accuracy of each layer until meeting the final configured sparsity of the whole model:

1. Analyze the sensitivity of each layer in the current state of the model.
2. Prune each layer according to the sensitivity.

For more details, please refer to Learning both Weights and Connections for Efficient Neural Networks.

Usage

PyTorch code

from nni.algorithms.compression.pytorch.pruning import SensitivityPruner
config_list = [{
        'sparsity': 0.5,
        'op_types': ['Conv2d']
    }]
pruner = SensitivityPruner(model, config_list, finetuner=fine_tuner, evaluator=evaluator)
# eval_args and finetune_args are the parameters passed to the evaluator and finetuner respectively
pruner.compress(eval_args=[model], finetune_args=[model])
User configuration for Sensitivity Pruner

PyTorch

class nni.algorithms.compression.pytorch.pruning.SensitivityPruner(model, config_list, evaluator, finetuner=None, base_algo='l1', sparsity_proportion_calc=None, sparsity_per_iter=0.1, acc_drop_threshold=0.05, checkpoint_dir=None)[source]

This function prune the model based on the sensitivity for each layer.

Parameters
  • model (torch.nn.Module) – model to be compressed

  • evaluator (function) – validation function for the model. This function should return the accuracy of the validation dataset. The input parameters of evaluator can be specified in the parameter eval_args and ‘eval_kwargs’ of the compress function if needed. Example: >>> def evaluator(model): >>> device = torch.device(“cuda” if torch.cuda.is_available() else “cpu”) >>> val_loader = … >>> model.eval() >>> correct = 0 >>> with torch.no_grad(): >>> for data, target in val_loader: >>> data, target = data.to(device), target.to(device) >>> output = model(data) >>> # get the index of the max log-probability >>> pred = output.argmax(dim=1, keepdim=True) >>> correct += pred.eq(target.view_as(pred)).sum().item() >>> accuracy = correct / len(val_loader.dataset) >>> return accuracy

  • finetuner (function) – finetune function for the model. This parameter is not essential, if is not None, the sensitivity pruner will finetune the model after pruning in each iteration. The input parameters of finetuner can be specified in the parameter of compress called finetune_args and finetune_kwargs if needed. Example: >>> def finetuner(model, epoch=3): >>> device = torch.device(“cuda” if torch.cuda.is_available() else “cpu”) >>> train_loader = … >>> criterion = torch.nn.CrossEntropyLoss() >>> optimizer = torch.optim.SGD(model.parameters(), lr=0.01) >>> model.train() >>> for _ in range(epoch): >>> for _, (data, target) in enumerate(train_loader): >>> data, target = data.to(device), target.to(device) >>> optimizer.zero_grad() >>> output = model(data) >>> loss = criterion(output, target) >>> loss.backward() >>> optimizer.step()

  • base_algo (str) – base pruning algorithm. level, l1, l2 or fpgm, by default l1.

  • sparsity_proportion_calc (function) – This function generate the sparsity proportion between the conv layers according to the sensitivity analysis results. We provide a default function to quantify the sparsity proportion according to the sensitivity analysis results. Users can also customize this function according to their needs. The input of this function is a dict, for example : {‘conv1’ : {0.1: 0.9, 0.2 : 0.8}, ‘conv2’ : {0.1: 0.9, 0.2 : 0.8}}, in which, ‘conv1’ and is the name of the conv layer, and 0.1:0.9 means when the sparsity of conv1 is 0.1 (10%), the model’s val accuracy equals to 0.9.

  • sparsity_per_iter (float) – The sparsity of the model that the pruner try to prune in each iteration.

  • acc_drop_threshold (float) – The hyperparameter used to quantifiy the sensitivity for each layer.

  • checkpoint_dir (str) – The dir path to save the checkpoints during the pruning.

Dependency-aware Mode for Filter Pruning

Currently, we have several filter pruning algorithm for the convolutional layers: FPGM Pruner, L1Filter Pruner, L2Filter Pruner, Activation APoZ Rank Filter Pruner, Activation Mean Rank Filter Pruner, Taylor FO On Weight Pruner. In these filter pruning algorithms, the pruner will prune each convolutional layer separately. While pruning a convolution layer, the algorithm will quantify the importance of each filter based on some specific rules(such as l1-norm), and prune the less important filters.

As dependency analysis utils shows, if the output channels of two convolutional layers(conv1, conv2) are added together, then these two conv layers have channel dependency with each other(more details please see Compression Utils). Take the following figure as an example.

If we prune the first 50% of output channels(filters) for conv1, and prune the last 50% of output channels for conv2. Although both layers have pruned 50% of the filters, the speedup module still needs to add zeros to align the output channels. In this case, we cannot harvest the speed benefit from the model pruning.

To better gain the speed benefit of the model pruning, we add a dependency-aware mode for the Filter Pruner. In the dependency-aware mode, the pruner prunes the model not only based on the l1 norm of each filter, but also the topology of the whole network architecture.

In the dependency-aware mode(dependency_aware is set True), the pruner will try to prune the same output channels for the layers that have the channel dependencies with each other, as shown in the following figure.

Take the dependency-aware mode of L1Filter Pruner as an example. Specifically, the pruner will calculate the L1 norm (for example) sum of all the layers in the dependency set for each channel. Obviously, the number of channels that can actually be pruned of this dependency set in the end is determined by the minimum sparsity of layers in this dependency set(denoted by min_sparsity). According to the L1 norm sum of each channel, the pruner will prune the same min_sparsity channels for all the layers. Next, the pruner will additionally prune sparsity - min_sparsity channels for each convolutional layer based on its own L1 norm of each channel. For example, suppose the output channels of conv1 , conv2 are added together and the configured sparsities of conv1 and conv2 are 0.3, 0.2 respectively. In this case, the dependency-aware pruner will

- First, prune the same 20% of channels for `conv1` and `conv2` according to L1 norm sum of `conv1` and `conv2`.
- Second, the pruner will additionally prune 10% channels for `conv1` according to the L1 norm of each channel of `conv1`.

In addition, for the convolutional layers that have more than one filter group, dependency-aware pruner will also try to prune the same number of the channels for each filter group. Overall, this pruner will prune the model according to the L1 norm of each filter and try to meet the topological constrains(channel dependency, etc) to improve the final speed gain after the speedup process.

In the dependency-aware mode, the pruner will provide a better speed gain from the model pruning.

Usage

In this section, we will show how to enable the dependency-aware mode for the filter pruner. Currently, only the one-shot pruners such as FPGM Pruner, L1Filter Pruner, L2Filter Pruner, Activation APoZ Rank Filter Pruner, Activation Mean Rank Filter Pruner, Taylor FO On Weight Pruner, support the dependency-aware mode.

To enable the dependency-aware mode for L1FilterPruner:

from nni.algorithms.compression.pytorch.pruning import L1FilterPruner
config_list = [{ 'sparsity': 0.8, 'op_types': ['Conv2d'] }]
# dummy_input is necessary for the dependency_aware mode
dummy_input = torch.ones(1, 3, 224, 224).cuda()
pruner = L1FilterPruner(model, config_list, dependency_aware=True, dummy_input=dummy_input)
# for L2FilterPruner
# pruner = L2FilterPruner(model, config_list, dependency_aware=True, dummy_input=dummy_input)
# for FPGMPruner
# pruner = FPGMPruner(model, config_list, dependency_aware=True, dummy_input=dummy_input)
# for ActivationAPoZRankFilterPruner
# pruner = ActivationAPoZRankFilterPruner(model, config_list, statistics_batch_num=1, , dependency_aware=True, dummy_input=dummy_input)
# for ActivationMeanRankFilterPruner
# pruner = ActivationMeanRankFilterPruner(model, config_list, statistics_batch_num=1, dependency_aware=True, dummy_input=dummy_input)
# for TaylorFOWeightFilterPruner
# pruner = TaylorFOWeightFilterPruner(model, config_list, statistics_batch_num=1, dependency_aware=True, dummy_input=dummy_input)

pruner.compress()
Evaluation

In order to compare the performance of the pruner with or without the dependency-aware mode, we use L1FilterPruner to prune the Mobilenet_v2 separately when the dependency-aware mode is turned on and off. To simplify the experiment, we use the uniform pruning which means we allocate the same sparsity for all convolutional layers in the model. We trained a Mobilenet_v2 model on the cifar10 dataset and prune the model based on this pretrained checkpoint. The following figure shows the accuracy and FLOPs of the model pruned by different pruners.

In the figure, the Dependency-aware represents the L1FilterPruner with dependency-aware mode enabled. L1 Filter is the normal L1FilterPruner without the dependency-aware mode, and the No-Dependency means pruner only prunes the layers that has no channel dependency with other layers. As we can see in the figure, when the dependency-aware mode enabled, the pruner can bring higher accuracy under the same Flops.

Speed up Masked Model

This feature is in Beta version.

Introduction

Pruning algorithms usually use weight masks to simulate the real pruning. Masks can be used to check model performance of a specific pruning (or sparsity), but there is no real speedup. Since model speedup is the ultimate goal of model pruning, we try to provide a tool to users to convert a model to a smaller one based on user provided masks (the masks come from the pruning algorithms).

There are two types of pruning. One is fine-grained pruning, it does not change the shape of weights, and input/output tensors. Sparse kernel is required to speed up a fine-grained pruned layer. The other is coarse-grained pruning (e.g., channels), shape of weights and input/output tensors usually change due to such pruning. To speed up this kind of pruning, there is no need to use sparse kernel, just replace the pruned layer with smaller one. Since the support of sparse kernels in community is limited, we only support the speedup of coarse-grained pruning and leave the support of fine-grained pruning in future.

Design and Implementation

To speed up a model, the pruned layers should be replaced, either replaced with smaller layer for coarse-grained mask, or replaced with sparse kernel for fine-grained mask. Coarse-grained mask usually changes the shape of weights or input/output tensors, thus, we should do shape inference to check are there other unpruned layers should be replaced as well due to shape change. Therefore, in our design, there are two main steps: first, do shape inference to find out all the modules that should be replaced; second, replace the modules. The first step requires topology (i.e., connections) of the model, we use jit.trace to obtain the model graph for PyTorch.

For each module, we should prepare four functions, three for shape inference and one for module replacement. The three shape inference functions are: given weight shape infer input/output shape, given input shape infer weight/output shape, given output shape infer weight/input shape. The module replacement function returns a newly created module which is smaller.

Usage
from nni.compression.pytorch import ModelSpeedup
# model: the model you want to speed up
# dummy_input: dummy input of the model, given to `jit.trace`
# masks_file: the mask file created by pruning algorithms
m_speedup = ModelSpeedup(model, dummy_input.to(device), masks_file)
m_speedup.speedup_model()
dummy_input = dummy_input.to(device)
start = time.time()
out = model(dummy_input)
print('elapsed time: ', time.time() - start)

For complete examples please refer to the code

NOTE: The current implementation supports PyTorch 1.3.1 or newer.

Limitations

Since every module requires four functions for shape inference and module replacement, this is a large amount of work, we only implemented the ones that are required by the examples. If you want to speed up your own model which cannot supported by the current implementation, you are welcome to contribute.

For PyTorch we can only replace modules, if functions in forward should be replaced, our current implementation does not work. One workaround is make the function a PyTorch module.

Speedup Results of Examples

The code of these experiments can be found here.

slim pruner example

on one V100 GPU, input tensor: torch.randn(64, 3, 32, 32)

Times

Mask Latency

Speedup Latency

1

0.01197

0.005107

2

0.02019

0.008769

4

0.02733

0.014809

8

0.04310

0.027441

16

0.07731

0.05008

32

0.14464

0.10027

fpgm pruner example

on cpu, input tensor: torch.randn(64, 1, 28, 28), too large variance

Times

Mask Latency

Speedup Latency

1

0.01383

0.01839

2

0.01167

0.003558

4

0.01636

0.01088

40

0.14412

0.08268

40

1.29385

0.14408

40

0.41035

0.46162

400

6.29020

5.82143

l1filter pruner example

on one V100 GPU, input tensor: torch.randn(64, 3, 32, 32)

Times

Mask Latency

Speedup Latency

1

0.01026

0.003677

2

0.01657

0.008161

4

0.02458

0.020018

8

0.03498

0.025504

16

0.06757

0.047523

32

0.10487

0.086442

APoZ pruner example

on one V100 GPU, input tensor: torch.randn(64, 3, 32, 32)

Times

Mask Latency

Speedup Latency

1

0.01389

0.004208

2

0.01628

0.008310

4

0.02521

0.014008

8

0.03386

0.023923

16

0.06042

0.046183

32

0.12421

0.087113

SimulatedAnnealing pruner example

In this experiment, we use SimulatedAnnealing pruner to prune the resnet18 on the cifar10 dataset. We measure the latencies and accuracies of the pruned model under different sparsity ratios, as shown in the following figure. The latency is measured on one V100 GPU and the input tensor is torch.randn(128, 3, 32, 32).

_images/SA_latency_accuracy.png

Automatic Model Pruning using NNI Tuners

It’s convenient to implement auto model pruning with NNI compression and NNI tuners

First, model compression with NNI

You can easily compress a model with NNI compression. Take pruning for example, you can prune a pretrained model with L2FilterPruner like this

from nni.algorithms.compression.pytorch.pruning import L2FilterPruner
config_list = [{ 'sparsity': 0.5, 'op_types': ['Conv2d'] }]
pruner = L2FilterPruner(model, config_list)
pruner.compress()

The ‘Conv2d’ op_type stands for the module types defined in default_layers.py for pytorch.

Therefore { 'sparsity': 0.5, 'op_types': ['Conv2d'] }means that all layers with specified op_types will be compressed with the same 0.5 sparsity. When pruner.compress() called, the model is compressed with masks and after that you can normally fine tune this model and pruned weights won’t be updated which have been masked.

Then, make this automatic

The previous example manually chose L2FilterPruner and pruned with a specified sparsity. Different sparsity and different pruners may have different effects on different models. This process can be done with NNI tuners.

Firstly, modify our codes for few lines

import nni
from nni.algorithms.compression.pytorch.pruning import *

params = nni.get_parameters()
sparsity = params['sparsity']
pruner_name = params['pruner']
model_name = params['model']

model, pruner = get_model_pruner(model_name, pruner_name, sparsity)
pruner.compress()

train(model)  # your code for fine-tuning the model
acc = test(model)  # test the fine-tuned model
nni.report_final_results(acc)

Then, define a config file in YAML to automatically tuning model, pruning algorithm and sparsity.

searchSpace:
sparsity:
  _type: choice
  _value: [0.25, 0.5, 0.75]
pruner:
  _type: choice
  _value: ['slim', 'l2filter', 'fpgm', 'apoz']
model:
  _type: choice
  _value: ['vgg16', 'vgg19']
trainingService:
platform: local
trialCodeDirectory: .
trialCommand: python3 basic_pruners_torch.py --nni
trialConcurrency: 1
trialGpuNumber: 0
tuner:
  name: grid

The full example can be found here

Finally, start the searching via

nnictl create -c config.yml

Quantization

Quantization refers to compressing models by reducing the number of bits required to represent weights or activations, which can reduce the computations and the inference time. In the context of deep neural networks, the major numerical format for model weights is 32-bit float, or FP32. Many research works have demonstrated that weights and activations can be represented using 8-bit integers without significant loss in accuracy. Even lower bit-widths, such as 4/2/1 bits, is an active field of research.

A quantizer is a quantization algorithm implementation in NNI, NNI provides multiple quantizers as below. You can also create your own quantizer using NNI model compression interface.

Supported Quantization Algorithms on NNI

Index of supported quantization algorithms

Naive Quantizer

We provide Naive Quantizer to quantizer weight to default 8 bits, you can use it to test quantize algorithm without any configure.

Usage

pytorch

model = nni.algorithms.compression.pytorch.quantization.NaiveQuantizer(model).compress()

QAT Quantizer

In Quantization and Training of Neural Networks for Efficient Integer-Arithmetic-Only Inference, authors Benoit Jacob and Skirmantas Kligys provide an algorithm to quantize the model with training.

We propose an approach that simulates quantization effects in the forward pass of training. Backpropagation still happens as usual, and all weights and biases are stored in floating point so that they can be easily nudged by small amounts. The forward propagation pass however simulates quantized inference as it will happen in the inference engine, by implementing in floating-point arithmetic the rounding behavior of the quantization scheme

  • Weights are quantized before they are convolved with the input. If batch normalization (see [17]) is used for the layer, the batch normalization parameters are “folded into” the weights before quantization.

  • Activations are quantized at points where they would be during inference, e.g. after the activation function is applied to a convolutional or fully connected layer’s output, or after a bypass connection adds or concatenates the outputs of several layers together such as in ResNets.

Usage

You can quantize your model to 8 bits with the code below before your training code.

PyTorch code

from nni.algorithms.compression.pytorch.quantization import QAT_Quantizer
model = Mnist()

config_list = [{
    'quant_types': ['weight'],
    'quant_bits': {
        'weight': 8,
    }, # you can just use `int` here because all `quan_types` share same bits length, see config for `ReLu6` below.
    'op_types':['Conv2d', 'Linear']
}, {
    'quant_types': ['output'],
    'quant_bits': 8,
    'quant_start_step': 7000,
    'op_types':['ReLU6']
}]
quantizer = QAT_Quantizer(model, config_list)
quantizer.compress()

You can view example for more information

User configuration for QAT Quantizer

common configuration needed by compression algorithms can be found at Specification of `config_list.

configuration needed by this algorithm :

  • quant_start_step: int

disable quantization until model are run by certain number of steps, this allows the network to enter a more stable state where activation quantization ranges do not exclude a significant fraction of values, default value is 0

note

batch normalization folding is currently not supported.


DoReFa Quantizer

In DoReFa-Net: Training Low Bitwidth Convolutional Neural Networks with Low Bitwidth Gradients, authors Shuchang Zhou and Yuxin Wu provide an algorithm named DoReFa to quantize the weight, activation and gradients with training.

Usage

To implement DoReFa Quantizer, you can add code below before your training code

PyTorch code

from nni.algorithms.compression.pytorch.quantization import DoReFaQuantizer
config_list = [{
    'quant_types': ['weight'],
    'quant_bits': 8,
    'op_types': 'default'
}]
quantizer = DoReFaQuantizer(model, config_list)
quantizer.compress()

You can view example for more information

User configuration for DoReFa Quantizer

common configuration needed by compression algorithms can be found at Specification of ``config_list` <./QuickStart.rst>`__.

configuration needed by this algorithm :


BNN Quantizer

In Binarized Neural Networks: Training Deep Neural Networks with Weights and Activations Constrained to +1 or -1,

We introduce a method to train Binarized Neural Networks (BNNs) - neural networks with binary weights and activations at run-time. At training-time the binary weights and activations are used for computing the parameters gradients. During the forward pass, BNNs drastically reduce memory size and accesses, and replace most arithmetic operations with bit-wise operations, which is expected to substantially improve power-efficiency.

Usage

PyTorch code

from nni.algorithms.compression.pytorch.quantization import BNNQuantizer
model = VGG_Cifar10(num_classes=10)

configure_list = [{
    'quant_bits': 1,
    'quant_types': ['weight'],
    'op_types': ['Conv2d', 'Linear'],
    'op_names': ['features.0', 'features.3', 'features.7', 'features.10', 'features.14', 'features.17', 'classifier.0', 'classifier.3']
}, {
    'quant_bits': 1,
    'quant_types': ['output'],
    'op_types': ['Hardtanh'],
    'op_names': ['features.6', 'features.9', 'features.13', 'features.16', 'features.20', 'classifier.2', 'classifier.5']
}]

quantizer = BNNQuantizer(model, configure_list)
model = quantizer.compress()

You can view example examples/model_compress/quantization/BNN_quantizer_cifar10.py for more information.

User configuration for BNN Quantizer

common configuration needed by compression algorithms can be found at Specification of ``config_list` <./QuickStart.rst>`__.

configuration needed by this algorithm :

Experiment

We implemented one of the experiments in Binarized Neural Networks: Training Deep Neural Networks with Weights and Activations Constrained to +1 or -1, we quantized the VGGNet for CIFAR-10 in the paper. Our experiments results are as follows:

Model

Accuracy

VGGNet

86.93%

The experiments code can be found at examples/model_compress/quantization/BNN_quantizer_cifar10.py

Speed up Mixed Precision Quantization Model (experimental)

Introduction

Deep learning network has been computational intensive and memory intensive which increases the difficulty of deploying deep neural network model. Quantization is a fundamental technology which is widely used to reduce memory footprint and speed up inference process. Many frameworks begin to support quantization, but few of them support mixed precision quantization and get real speedup. Frameworks like HAQ: Hardware-Aware Automated Quantization with Mixed Precision, only support simulated mixed precision quantization which will not speed up the inference process. To get real speedup of mixed precision quantization and help people get the real feedback from hardware, we design a general framework with simple interface to allow NNI quantization algorithms to connect different DL model optimization backends (e.g., TensorRT, NNFusion), which gives users an end-to-end experience that after quantizing their model with quantization algorithms, the quantized model can be directly speeded up with the connected optimization backend. NNI connects TensorRT at this stage, and will support more backends in the future.

Design and Implementation

To support speeding up mixed precision quantization, we divide framework into two part, frontend and backend. Frontend could be popular training frameworks such as PyTorch, TensorFlow etc. Backend could be inference framework for different hardwares, such as TensorRT. At present, we support PyTorch as frontend and TensorRT as backend. To convert PyTorch model to TensorRT engine, we leverage onnx as intermediate graph representation. In this way, we convert PyTorch model to onnx model, then TensorRT parse onnx model to generate inference engine.

Quantization aware training combines NNI quantization algorithm ‘QAT’ and NNI quantization speedup tool. Users should set config to train quantized model using QAT algorithm(please refer to NNI Quantization Algorithms ). After quantization aware training, users can get new config with calibration parameters and model with quantized weight. By passing new config and model to quantization speedup tool, users can get real mixed precision speedup engine to do inference.

After getting mixed precision engine, users can do inference with input data.

Note

  • User can also do post-training quantization leveraging TensorRT directly(need to provide calibration dataset).

  • Not all op types are supported right now. At present, NNI supports Conv, Linear, Relu and MaxPool. More op types will be supported in the following release.

Prerequisite

CUDA version >= 11.0

TensorRT version >= 7.2

Usage

quantization aware training:

# arrange bit config for QAT algorithm
configure_list = [{
        'quant_types': ['weight', 'output'],
        'quant_bits': {'weight':8, 'output':8},
        'op_names': ['conv1']
    }, {
        'quant_types': ['output'],
        'quant_bits': {'output':8},
        'op_names': ['relu1']
    }
]

quantizer = QAT_Quantizer(model, configure_list, optimizer)
quantizer.compress()
calibration_config = quantizer.export_model(model_path, calibration_path)

engine = ModelSpeedupTensorRT(model, input_shape, config=calibration_config, batchsize=batch_size)
# build tensorrt inference engine
engine.compress()
# data should be pytorch tensor
output, time = engine.inference(data)

Note that NNI also supports post-training quantization directly, please refer to complete examples for detail.

For complete examples please refer to the code.

For more parameters about the class ‘TensorRTModelSpeedUp’, you can refer to Model Compression API Reference.

Mnist test

on one GTX2080 GPU, input tensor: torch.randn(128, 1, 28, 28)

quantization strategy

Latency

accuracy

all in 32bit

0.001199961

96%

mixed precision(average bit 20.4)

0.000753688

96%

all in 8bit

0.000229869

93.7%

Cifar10 resnet18 test(train one epoch)

on one GTX2080 GPU, input tensor: torch.randn(128, 3, 32, 32)

quantization strategy

Latency

accuracy

all in 32bit

0.003286268

54.21%

mixed precision(average bit 11.55)

0.001358022

54.78%

all in 8bit

0.000859139

52.81%

Analysis Utils for Model Compression

We provide several easy-to-use tools for users to analyze their model during model compression.

Sensitivity Analysis

First, we provide a sensitivity analysis tool (SensitivityAnalysis) for users to analyze the sensitivity of each convolutional layer in their model. Specifically, the SensitiviyAnalysis gradually prune each layer of the model, and test the accuracy of the model at the same time. Note that, SensitivityAnalysis only prunes a layer once a time, and the other layers are set to their original weights. According to the accuracies of different convolutional layers under different sparsities, we can easily find out which layers the model accuracy is more sensitive to.

Usage

The following codes show the basic usage of the SensitivityAnalysis.

from nni.compression.pytorch.utils.sensitivity_analysis import SensitivityAnalysis

def val(model):
    model.eval()
    total = 0
    correct = 0
    with torch.no_grad():
        for batchid, (data, label) in enumerate(val_loader):
            data, label = data.cuda(), label.cuda()
            out = model(data)
            _, predicted = out.max(1)
            total += data.size(0)
            correct += predicted.eq(label).sum().item()
    return correct / total

s_analyzer = SensitivityAnalysis(model=net, val_func=val)
sensitivity = s_analyzer.analysis(val_args=[net])
os.makedir(outdir)
s_analyzer.export(os.path.join(outdir, filename))

Two key parameters of SensitivityAnalysis are model, and val_func. model is the neural network that to be analyzed and the val_func is the validation function that returns the model accuracy/loss/ or other metrics on the validation dataset. Due to different scenarios may have different ways to calculate the loss/accuracy, so users should prepare a function that returns the model accuracy/loss on the dataset and pass it to SensitivityAnalysis. SensitivityAnalysis can export the sensitivity results as a csv file usage is shown in the example above.

Futhermore, users can specify the sparsities values used to prune for each layer by optional parameter sparsities.

s_analyzer = SensitivityAnalysis(model=net, val_func=val, sparsities=[0.25, 0.5, 0.75])

the SensitivityAnalysis will prune 25% 50% 75% weights gradually for each layer, and record the model’s accuracy at the same time (SensitivityAnalysis only prune a layer once a time, the other layers are set to their original weights). If the sparsities is not set, SensitivityAnalysis will use the numpy.arange(0.1, 1.0, 0.1) as the default sparsity values.

Users can also speed up the progress of sensitivity analysis by the early_stop_mode and early_stop_value option. By default, the SensitivityAnalysis will test the accuracy under all sparsities for each layer. In contrast, when the early_stop_mode and early_stop_value are set, the sensitivity analysis for a layer will stop, when the accuracy/loss has already met the threshold set by early_stop_value. We support four early stop modes: minimize, maximize, dropped, raised.

minimize: The analysis stops when the validation metric return by the val_func lower than early_stop_value.

maximize: The analysis stops when the validation metric return by the val_func larger than early_stop_value.

dropped: The analysis stops when the validation metric has dropped by early_stop_value.

raised: The analysis stops when the validation metric has raised by early_stop_value.

s_analyzer = SensitivityAnalysis(model=net, val_func=val, sparsities=[0.25, 0.5, 0.75], early_stop_mode='dropped', early_stop_value=0.1)

If users only want to analyze several specified convolutional layers, users can specify the target conv layers by the specified_layers in analysis function. specified_layers is a list that consists of the Pytorch module names of the conv layers. For example

sensitivity = s_analyzer.analysis(val_args=[net], specified_layers=['Conv1'])

In this example, only the Conv1 layer is analyzed. In addtion, users can quickly and easily achieve the analysis parallelization by launching multiple processes and assigning different conv layers of the same model to each process.

Output example

The following lines are the example csv file exported from SensitivityAnalysis. The first line is constructed by ‘layername’ and sparsity list. Here the sparsity value means how much weight SensitivityAnalysis prune for each layer. Each line below records the model accuracy when this layer is under different sparsities. Note that, due to the early_stop option, some layers may not have model accuracies/losses under all sparsities, for example, its accuracy drop has already exceeded the threshold set by the user.

layername,0.05,0.1,0.2,0.3,0.4,0.5,0.7,0.85,0.95
features.0,0.54566,0.46308,0.06978,0.0374,0.03024,0.01512,0.00866,0.00492,0.00184
features.3,0.54878,0.51184,0.37978,0.19814,0.07178,0.02114,0.00438,0.00442,0.00142
features.6,0.55128,0.53566,0.4887,0.4167,0.31178,0.19152,0.08612,0.01258,0.00236
features.8,0.55696,0.54194,0.48892,0.42986,0.33048,0.2266,0.09566,0.02348,0.0056
features.10,0.55468,0.5394,0.49576,0.4291,0.3591,0.28138,0.14256,0.05446,0.01578

Topology Analysis

We also provide several tools for the topology analysis during the model compression. These tools are to help users compress their model better. Because of the complex topology of the network, when compressing the model, users often need to spend a lot of effort to check whether the compression configuration is reasonable. So we provide these tools for topology analysis to reduce the burden on users.

ChannelDependency

Complicated models may have residual connection/concat operations in their models. When the user prunes these models, they need to be careful about the channel-count dependencies between the convolution layers in the model. Taking the following residual block in the resnet18 as an example. The output features of the layer2.0.conv2 and layer2.0.downsample.0 are added together, so the number of the output channels of layer2.0.conv2 and layer2.0.downsample.0 should be the same, or there may be a tensor shape conflict.

If the layers have channel dependency are assigned with different sparsities (here we only discuss the structured pruning by L1FilterPruner/L2FilterPruner), then there will be a shape conflict during these layers. Even the pruned model with mask works fine, the pruned model cannot be speedup to the final model directly that runs on the devices, because there will be a shape conflict when the model tries to add/concat the outputs of these layers. This tool is to find the layers that have channel count dependencies to help users better prune their model.

Usage
from nni.compression.pytorch.utils.shape_dependency import ChannelDependency
data = torch.ones(1, 3, 224, 224).cuda()
channel_depen = ChannelDependency(net, data)
channel_depen.export('dependency.csv')
Output Example

The following lines are the output example of torchvision.models.resnet18 exported by ChannelDependency. The layers at the same line have output channel dependencies with each other. For example, layer1.1.conv2, conv1, and layer1.0.conv2 have output channel dependencies with each other, which means the output channel(filters) numbers of these three layers should be same with each other, otherwise, the model may have shape conflict.

Dependency Set,Convolutional Layers
Set 1,layer1.1.conv2,layer1.0.conv2,conv1
Set 2,layer1.0.conv1
Set 3,layer1.1.conv1
Set 4,layer2.0.conv1
Set 5,layer2.1.conv2,layer2.0.conv2,layer2.0.downsample.0
Set 6,layer2.1.conv1
Set 7,layer3.0.conv1
Set 8,layer3.0.downsample.0,layer3.1.conv2,layer3.0.conv2
Set 9,layer3.1.conv1
Set 10,layer4.0.conv1
Set 11,layer4.0.downsample.0,layer4.1.conv2,layer4.0.conv2
Set 12,layer4.1.conv1
MaskConflict

When the masks of different layers in a model have conflict (for example, assigning different sparsities for the layers that have channel dependency), we can fix the mask conflict by MaskConflict. Specifically, the MaskConflict loads the masks exported by the pruners(L1FilterPruner, etc), and check if there is mask conflict, if so, MaskConflict sets the conflicting masks to the same value.

from nni.compression.pytorch.utils.mask_conflict import fix_mask_conflict
fixed_mask = fix_mask_conflict('./resnet18_mask', net, data)

Model FLOPs/Parameters Counter

We provide a model counter for calculating the model FLOPs and parameters. This counter supports calculating FLOPs/parameters of a normal model without masks, it can also calculates FLOPs/parameters of a model with mask wrappers, which helps users easily check model complexity during model compression on NNI. Note that, for sturctured pruning, we only identify the remained filters according to its mask, which not taking the pruned input channels into consideration, so the calculated FLOPs will be larger than real number (i.e., the number calculated after Model Speedup).

We support two modes to collect information of modules. The first mode is default, which only collect the information of convolution and linear. The second mode is full, which also collect the information of other operations. Users can easily use our collected results for futher analysis.

Usage
from nni.compression.pytorch.utils.counter import count_flops_params

# Given input size (1, 1, 28, 28)
flops, params, results = count_flops_params(model, (1, 1, 28, 28))

# Given input tensor with size (1, 1, 28, 28) and switch to full mode
x = torch.randn(1, 1, 28, 28)

flops, params, results = count_flops_params(model, (x,) mode='full') # tuple of tensor as input

# Format output size to M (i.e., 10^6)
print(f'FLOPs: {flops/1e6:.3f}M,  Params: {params/1e6:.3f}M)
print(results)
{
'conv': {'flops': [60], 'params': [20], 'weight_size': [(5, 3, 1, 1)], 'input_size': [(1, 3, 2, 2)], 'output_size': [(1, 5, 2, 2)], 'module_type': ['Conv2d']},
'conv2': {'flops': [100], 'params': [30], 'weight_size': [(5, 5, 1, 1)], 'input_size': [(1, 5, 2, 2)], 'output_size': [(1, 5, 2, 2)], 'module_type': ['Conv2d']}
}

Advanced Usage

Framework overview of model compression

Below picture shows the components overview of model compression framework.

There are 3 major components/classes in NNI model compression framework: Compressor, Pruner and Quantizer. Let’s look at them in detail one by one:

Compressor

Compressor is the base class for pruner and quntizer, it provides a unified interface for pruner and quantizer for end users, so that pruner and quantizer can be used in the same way. For example, to use a pruner:

from nni.algorithms.compression.pytorch.pruning import LevelPruner

# load a pretrained model or train a model before using a pruner

configure_list = [{
    'sparsity': 0.7,
    'op_types': ['Conv2d', 'Linear'],
}]

optimizer = torch.optim.SGD(model.parameters(), lr=0.001, momentum=0.9, weight_decay=1e-4)
pruner = LevelPruner(model, configure_list, optimizer)
model = pruner.compress()

# model is ready for pruning, now start finetune the model,
# the model will be pruned during training automatically

To use a quantizer:

from nni.algorithms.compression.pytorch.pruning import DoReFaQuantizer

configure_list = [{
    'quant_types': ['weight'],
    'quant_bits': {
        'weight': 8,
    },
    'op_types':['Conv2d', 'Linear']
}]
optimizer = torch.optim.SGD(model.parameters(), lr=0.001, momentum=0.9, weight_decay=1e-4)
quantizer = DoReFaQuantizer(model, configure_list, optimizer)
quantizer.compress()

View example code for more information.

Compressor class provides some utility methods for subclass and users:

Set wrapper attribute

Sometimes calc_mask must save some state data, therefore users can use set_wrappers_attribute API to register attribute just like how buffers are registered in PyTorch modules. These buffers will be registered to module wrapper. Users can access these buffers through module wrapper. In above example, we use set_wrappers_attribute to set a buffer if_calculated which is used as flag indicating if the mask of a layer is already calculated.

Collect data during forward

Sometimes users want to collect some data during the modules’ forward method, for example, the mean value of the activation. This can be done by adding a customized collector to module.

class MyMasker(WeightMasker):
    def __init__(self, model, pruner):
        super().__init__(model, pruner)
        # Set attribute `collected_activation` for all wrappers to store
        # activations for each layer
        self.pruner.set_wrappers_attribute("collected_activation", [])
        self.activation = torch.nn.functional.relu

        def collector(wrapper, input_, output):
            # The collected activation can be accessed via each wrapper's collected_activation
            # attribute
            wrapper.collected_activation.append(self.activation(output.detach().cpu()))

        self.pruner.hook_id = self.pruner.add_activation_collector(collector)

The collector function will be called each time the forward method runs.

Users can also remove this collector like this:

# Save the collector identifier
collector_id = self.pruner.add_activation_collector(collector)

# When the collector is not used any more, it can be remove using
# the saved collector identifier
self.pruner.remove_activation_collector(collector_id)

Pruner

A pruner receives model, config_list and optimizer as arguments. It prunes the model per the config_list during training loop by adding a hook on optimizer.step().

Pruner class is a subclass of Compressor, so it contains everything in the Compressor class and some additional components only for pruning, it contains:

Weight masker

A weight masker is the implementation of pruning algorithms, it can prune a specified layer wrapped by module wrapper with specified sparsity.

Pruning module wrapper

A pruning module wrapper is a module containing:

  1. the origin module

  2. some buffers used by calc_mask

  3. a new forward method that applies masks before running the original forward method.

the reasons to use module wrapper:

  1. some buffers are needed by calc_mask to calculate masks and these buffers should be registered in module wrapper so that the original modules are not contaminated.

  2. a new forward method is needed to apply masks to weight before calling the real forward method.

Pruning hook

A pruning hook is installed on a pruner when the pruner is constructed, it is used to call pruner’s calc_mask method at optimizer.step() is invoked.


Quantizer

Quantizer class is also a subclass of Compressor, it is used to compress models by reducing the number of bits required to represent weights or activations, which can reduce the computations and the inference time. It contains:

Quantization module wrapper

Each module/layer of the model to be quantized is wrapped by a quantization module wrapper, it provides a new forward method to quantize the original module’s weight, input and output.

Quantization hook

A quantization hook is installed on a quntizer when it is constructed, it is call at optimizer.step().

Quantization methods

Quantizer class provides following methods for subclass to implement quantization algorithms:

class Quantizer(Compressor):
    """
    Base quantizer for pytorch quantizer
    """
    def quantize_weight(self, weight, wrapper, **kwargs):
        """
        quantize should overload this method to quantize weight.
        This method is effectively hooked to :meth:`forward` of the model.
        Parameters
        ----------
        weight : Tensor
            weight that needs to be quantized
        wrapper : QuantizerModuleWrapper
            the wrapper for origin module
        """
        raise NotImplementedError('Quantizer must overload quantize_weight()')

    def quantize_output(self, output, wrapper, **kwargs):
        """
        quantize should overload this method to quantize output.
        This method is effectively hooked to :meth:`forward` of the model.
        Parameters
        ----------
        output : Tensor
            output that needs to be quantized
        wrapper : QuantizerModuleWrapper
            the wrapper for origin module
        """
        raise NotImplementedError('Quantizer must overload quantize_output()')

    def quantize_input(self, *inputs, wrapper, **kwargs):
        """
        quantize should overload this method to quantize input.
        This method is effectively hooked to :meth:`forward` of the model.
        Parameters
        ----------
        inputs : Tensor
            inputs that needs to be quantized
        wrapper : QuantizerModuleWrapper
            the wrapper for origin module
        """
        raise NotImplementedError('Quantizer must overload quantize_input()')

Multi-GPU support

On multi-GPU training, buffers and parameters are copied to multiple GPU every time the forward method runs on multiple GPU. If buffers and parameters are updated in the forward method, an in-place update is needed to ensure the update is effective. Since calc_mask is called in the optimizer.step method, which happens after the forward method and happens only on one GPU, it supports multi-GPU naturally.

Customize New Compression Algorithm

In order to simplify the process of writing new compression algorithms, we have designed simple and flexible programming interface, which covers pruning and quantization. Below, we first demonstrate how to customize a new pruning algorithm and then demonstrate how to customize a new quantization algorithm.

Important Note To better understand how to customize new pruning/quantization algorithms, users should first understand the framework that supports various pruning algorithms in NNI. Reference Framework overview of model compression

Customize a new pruning algorithm

Implementing a new pruning algorithm requires implementing a weight masker class which shoud be a subclass of WeightMasker, and a pruner class, which should be a subclass Pruner.

An implementation of weight masker may look like this:

class MyMasker(WeightMasker):
    def __init__(self, model, pruner):
        super().__init__(model, pruner)
        # You can do some initialization here, such as collecting some statistics data
        # if it is necessary for your algorithms to calculate the masks.

    def calc_mask(self, sparsity, wrapper, wrapper_idx=None):
        # calculate the masks based on the wrapper.weight, and sparsity,
        # and anything else
        # mask = ...
        return {'weight_mask': mask}

You can reference nni provided weight masker implementations to implement your own weight masker.

A basic pruner looks likes this:

class MyPruner(Pruner):
    def __init__(self, model, config_list, optimizer):
        super().__init__(model, config_list, optimizer)
        self.set_wrappers_attribute("if_calculated", False)
        # construct a weight masker instance
        self.masker = MyMasker(model, self)

    def calc_mask(self, wrapper, wrapper_idx=None):
        sparsity = wrapper.config['sparsity']
        if wrapper.if_calculated:
            # Already pruned, do not prune again as a one-shot pruner
            return None
        else:
            # call your masker to actually calcuate the mask for this layer
            masks = self.masker.calc_mask(sparsity=sparsity, wrapper=wrapper, wrapper_idx=wrapper_idx)
            wrapper.if_calculated = True
            return masks

Reference nni provided pruner implementations to implement your own pruner class.


Customize a new quantization algorithm

To write a new quantization algorithm, you can write a class that inherits nni.compression.pytorch.Quantizer. Then, override the member functions with the logic of your algorithm. The member function to override is quantize_weight. quantize_weight directly returns the quantized weights rather than mask, because for quantization the quantized weights cannot be obtained by applying mask.

from nni.compression.pytorch import Quantizer

class YourQuantizer(Quantizer):
    def __init__(self, model, config_list):
        """
        Suggest you to use the NNI defined spec for config
        """
        super().__init__(model, config_list)

    def quantize_weight(self, weight, config, **kwargs):
        """
        quantize should overload this method to quantize weight tensors.
        This method is effectively hooked to :meth:`forward` of the model.

        Parameters
        ----------
        weight : Tensor
            weight that needs to be quantized
        config : dict
            the configuration for weight quantization
        """

        # Put your code to generate `new_weight` here

        return new_weight

    def quantize_output(self, output, config, **kwargs):
        """
        quantize should overload this method to quantize output.
        This method is effectively hooked to `:meth:`forward` of the model.

        Parameters
        ----------
        output : Tensor
            output that needs to be quantized
        config : dict
            the configuration for output quantization
        """

        # Put your code to generate `new_output` here

        return new_output

    def quantize_input(self, *inputs, config, **kwargs):
        """
        quantize should overload this method to quantize input.
        This method is effectively hooked to :meth:`forward` of the model.

        Parameters
        ----------
        inputs : Tensor
            inputs that needs to be quantized
        config : dict
            the configuration for inputs quantization
        """

        # Put your code to generate `new_input` here

        return new_input

    def update_epoch(self, epoch_num):
        pass

    def step(self):
        """
        Can do some processing based on the model or weights binded
        in the func bind_model
        """
        pass
Customize backward function

Sometimes it’s necessary for a quantization operation to have a customized backward function, such as Straight-Through Estimator, user can customize a backward function as follow:

from nni.compression.pytorch.compressor import Quantizer, QuantGrad, QuantType

class ClipGrad(QuantGrad):
    @staticmethod
    def quant_backward(tensor, grad_output, quant_type):
        """
        This method should be overrided by subclass to provide customized backward function,
        default implementation is Straight-Through Estimator
        Parameters
        ----------
        tensor : Tensor
            input of quantization operation
        grad_output : Tensor
            gradient of the output of quantization operation
        quant_type : QuantType
            the type of quantization, it can be `QuantType.QUANT_INPUT`, `QuantType.QUANT_WEIGHT`, `QuantType.QUANT_OUTPUT`,
            you can define different behavior for different types.
        Returns
        -------
        tensor
            gradient of the input of quantization operation
        """

        # for quant_output function, set grad to zero if the absolute value of tensor is larger than 1
        if quant_type == QuantType.QUANT_OUTPUT:
            grad_output[torch.abs(tensor) > 1] = 0
        return grad_output


class YourQuantizer(Quantizer):
    def __init__(self, model, config_list):
        super().__init__(model, config_list)
        # set your customized backward function to overwrite default backward function
        self.quant_grad = ClipGrad

If you do not customize QuantGrad, the default backward is Straight-Through Estimator. Coming Soon

Model Compression API Reference

Compressors

Compressor
class nni.compression.pytorch.compressor.Compressor(model, config_list, optimizer=None)[source]

Abstract base PyTorch compressor

compress()[source]

Compress the model with algorithm implemented by subclass.

The model will be instrumented and user should never edit it after calling this method. self.modules_to_compress records all the to-be-compressed layers

Returns

model with specified modules compressed.

Return type

torch.nn.Module

get_modules_to_compress()[source]

To obtain all the to-be-compressed modules.

Returns

a list of the layers, each of which is a tuple (layer, config), layer is LayerInfo, config is a dict

Return type

list

get_modules_wrapper()[source]

To obtain all the wrapped modules.

Returns

a list of the wrapped modules

Return type

list

reset(checkpoint=None)[source]

reset model state dict and model wrapper

select_config(layer)[source]

Find the configuration for layer by parsing self.config_list

Parameters

layer (LayerInfo) – one layer

Returns

the retrieved configuration for this layer, if None, this layer should not be compressed

Return type

config or None

set_wrappers_attribute(name, value)[source]

To register attributes used in wrapped module’s forward method. If the type of the value is Torch.tensor, then this value is registered as a buffer in wrapper, which will be saved by model.state_dict. Otherwise, this value is just a regular variable in wrapper.

Parameters
  • name (str) – name of the variable

  • value (any) – value of the variable

update_epoch(epoch)[source]

If user want to update model every epoch, user can override this method. This method should be called at the beginning of each epoch

Parameters

epoch (num) – the current epoch number

validate_config(model, config_list)[source]

subclass can optionally implement this method to check if config_list if valid

class nni.compression.pytorch.compressor.Pruner(model, config_list, optimizer=None)[source]

Prune to an exact pruning level specification

mask_dict

Dictionary for saving masks, key should be layer name and value should be a tensor which has the same shape with layer’s weight

Type

dict

calc_mask(wrapper, **kwargs)[source]

Pruners should overload this method to provide mask for weight tensors. The mask must have the same shape and type comparing to the weight. It will be applied with mul() operation on the weight. This method is effectively hooked to forward() method of the model.

Parameters

wrapper (Module) – calculate mask for wrapper.module’s weight

compress()[source]

Compress the model with algorithm implemented by subclass.

The model will be instrumented and user should never edit it after calling this method. self.modules_to_compress records all the to-be-compressed layers

Returns

model with specified modules compressed.

Return type

torch.nn.Module

export_model(model_path, mask_path=None, onnx_path=None, input_shape=None, device=None)[source]

Export pruned model weights, masks and onnx model(optional)

Parameters
  • model_path (str) – path to save pruned model state_dict

  • mask_path (str) – (optional) path to save mask dict

  • onnx_path (str) – (optional) path to save onnx model

  • input_shape (list or tuple) – input shape to onnx model

  • device (torch.device) – device of the model, used to place the dummy input tensor for exporting onnx file. the tensor is placed on cpu if `device` is None

load_model_state_dict(model_state)[source]

Load the state dict saved from unwrapped model.

Parameters

model_state (dict) – state dict saved from unwrapped model

class nni.compression.pytorch.compressor.Quantizer(model, config_list, optimizer=None)[source]

Base quantizer for pytorch quantizer

export_model(model_path, calibration_path=None, onnx_path=None, input_shape=None, device=None)[source]

Export quantized model weights and calibration parameters

Parameters
  • model_path (str) – path to save quantized model weight

  • calibration_path (str) – (optional) path to save quantize parameters after calibration

  • onnx_path (str) – (optional) path to save onnx model

  • input_shape (list or tuple) – input shape to onnx model

  • device (torch.device) – device of the model, used to place the dummy input tensor for exporting onnx file. the tensor is placed on cpu if `device` is None

Returns

Return type

Dict

export_model_save(model, model_path, calibration_config=None, calibration_path=None, onnx_path=None, input_shape=None, device=None)[source]

This method helps save pytorch model, calibration config, onnx model in quantizer.

Parameters
  • model (pytorch model) – pytorch model to be saved

  • model_path (str) – path to save pytorch

  • calibration_config (dict) – (optional) config of calibration parameters

  • calibration_path (str) – (optional) path to save quantize parameters after calibration

  • onnx_path (str) – (optional) path to save onnx model

  • input_shape (list or tuple) – input shape to onnx model

  • device (torch.device) – device of the model, used to place the dummy input tensor for exporting onnx file. the tensor is placed on cpu if `device` is None

quantize_input(*inputs, wrapper, **kwargs)[source]

quantize should overload this method to quantize input. This method is effectively hooked to forward() of the model. :param inputs: inputs that needs to be quantized :type inputs: Tensor :param wrapper: the wrapper for origin module :type wrapper: QuantizerModuleWrapper

quantize_output(output, wrapper, **kwargs)[source]

quantize should overload this method to quantize output. This method is effectively hooked to forward() of the model. :param output: output that needs to be quantized :type output: Tensor :param wrapper: the wrapper for origin module :type wrapper: QuantizerModuleWrapper

quantize_weight(wrapper, **kwargs)[source]

quantize should overload this method to quantize weight. This method is effectively hooked to forward() of the model. :param wrapper: the wrapper for origin module :type wrapper: QuantizerModuleWrapper

Module Wrapper
class nni.compression.pytorch.compressor.PrunerModuleWrapper(module, module_name, module_type, config, pruner)[source]
forward(*inputs)[source]

Defines the computation performed at every call.

Should be overridden by all subclasses.

Note

Although the recipe for forward pass needs to be defined within this function, one should call the Module instance afterwards instead of this since the former takes care of running the registered hooks while the latter silently ignores them.

class nni.compression.pytorch.compressor.QuantizerModuleWrapper(module, module_name, module_type, config, quantizer)[source]
forward(*inputs)[source]

Defines the computation performed at every call.

Should be overridden by all subclasses.

Note

Although the recipe for forward pass needs to be defined within this function, one should call the Module instance afterwards instead of this since the former takes care of running the registered hooks while the latter silently ignores them.

Weight Masker
class nni.algorithms.compression.pytorch.pruning.weight_masker.WeightMasker(model, pruner, **kwargs)[source]
calc_mask(sparsity, wrapper, wrapper_idx=None)[source]

Calculate the mask of given layer. :param sparsity: pruning ratio, preserved weight ratio is 1 - sparsity :type sparsity: float :param wrapper: layer wrapper of this layer :type wrapper: PrunerModuleWrapper :param wrapper_idx: index of this wrapper in pruner’s all wrappers :type wrapper_idx: int

Returns

dictionary for storing masks, keys of the dict: ‘weight_mask’: weight mask tensor ‘bias_mask’: bias mask tensor (optional)

Return type

dict

class nni.algorithms.compression.pytorch.pruning.structured_pruning.StructuredWeightMasker(model, pruner, preserve_round=1, dependency_aware=False)[source]

A structured pruning masker base class that prunes convolutional layer filters.

Parameters
  • model (nn.Module) – model to be pruned

  • pruner (Pruner) – A Pruner instance used to prune the model

  • preserve_round (int) – after pruning, preserve filters/channels round to preserve_round, for example: for a Conv2d layer, output channel is 32, sparsity is 0.2, if preserve_round is 1 (no preserve round), then there will be int(32 * 0.2) = 6 filters pruned, and 32 - 6 = 26 filters are preserved. If preserve_round is 4, preserved filters will be round up to 28 (which can be divided by 4) and only 4 filters are pruned.

calc_mask(sparsity, wrapper, wrapper_idx=None, **depen_kwargs)[source]

calculate the mask for wrapper.

Parameters
  • sparsity (float/list of float) – The target sparsity of the wrapper. If we calculate the mask in the normal way, then sparsity is a float number. In contrast, if we calculate the mask in the dependency-aware way, sparsity is a list of float numbers, each float number corressponds to a sparsity of a layer.

  • wrapper (PrunerModuleWrapper/list of PrunerModuleWrappers) – The wrapper of the target layer. If we calculate the mask in the normal way, then wrapper is an instance of PrunerModuleWrapper, else wrapper is a list of PrunerModuleWrapper.

  • wrapper_idx (int/list of int) – The index of the wrapper.

  • depen_kwargs (dict) – The kw_args for the dependency-aware mode.

get_channel_sum(wrapper, wrapper_idx)[source]

Calculate the importance weight for each channel. If want to support the dependency-aware mode for this one-shot pruner, this function must be implemented. :param wrapper: layer wrapper of this layer :type wrapper: PrunerModuleWrapper :param wrapper_idx: index of this wrapper in pruner’s all wrappers :type wrapper_idx: int

Returns

Tensor that indicates the importance of each channel

Return type

tensor

get_mask(base_mask, weight, num_prune, wrapper, wrapper_idx, channel_masks=None)[source]

Calculate the mask of given layer.

Parameters
  • base_mask (dict) – The basic mask with the same shape of weight, all item in the basic mask is 1.

  • weight (tensor) – the module weight to be pruned

  • num_prune (int) – Num of filters to prune

  • wrapper (PrunerModuleWrapper) – layer wrapper of this layer

  • wrapper_idx (int) – index of this wrapper in pruner’s all wrappers

  • channel_masks (Tensor) – If mask some channels for this layer in advance. In the dependency-aware mode, before calculating the masks for each layer, we will calculate a common mask for all the layers in the dependency set. For the pruners that doesnot support dependency-aware mode, they can just ignore this parameter.

Returns

dictionary for storing masks

Return type

dict

Pruners
class nni.algorithms.compression.pytorch.pruning.sensitivity_pruner.SensitivityPruner(model, config_list, evaluator, finetuner=None, base_algo='l1', sparsity_proportion_calc=None, sparsity_per_iter=0.1, acc_drop_threshold=0.05, checkpoint_dir=None)[source]

This function prune the model based on the sensitivity for each layer.

Parameters
  • model (torch.nn.Module) – model to be compressed

  • evaluator (function) – validation function for the model. This function should return the accuracy of the validation dataset. The input parameters of evaluator can be specified in the parameter eval_args and ‘eval_kwargs’ of the compress function if needed. Example: >>> def evaluator(model): >>> device = torch.device(“cuda” if torch.cuda.is_available() else “cpu”) >>> val_loader = … >>> model.eval() >>> correct = 0 >>> with torch.no_grad(): >>> for data, target in val_loader: >>> data, target = data.to(device), target.to(device) >>> output = model(data) >>> # get the index of the max log-probability >>> pred = output.argmax(dim=1, keepdim=True) >>> correct += pred.eq(target.view_as(pred)).sum().item() >>> accuracy = correct / len(val_loader.dataset) >>> return accuracy

  • finetuner (function) – finetune function for the model. This parameter is not essential, if is not None, the sensitivity pruner will finetune the model after pruning in each iteration. The input parameters of finetuner can be specified in the parameter of compress called finetune_args and finetune_kwargs if needed. Example: >>> def finetuner(model, epoch=3): >>> device = torch.device(“cuda” if torch.cuda.is_available() else “cpu”) >>> train_loader = … >>> criterion = torch.nn.CrossEntropyLoss() >>> optimizer = torch.optim.SGD(model.parameters(), lr=0.01) >>> model.train() >>> for _ in range(epoch): >>> for _, (data, target) in enumerate(train_loader): >>> data, target = data.to(device), target.to(device) >>> optimizer.zero_grad() >>> output = model(data) >>> loss = criterion(output, target) >>> loss.backward() >>> optimizer.step()

  • base_algo (str) – base pruning algorithm. level, l1, l2 or fpgm, by default l1.

  • sparsity_proportion_calc (function) – This function generate the sparsity proportion between the conv layers according to the sensitivity analysis results. We provide a default function to quantify the sparsity proportion according to the sensitivity analysis results. Users can also customize this function according to their needs. The input of this function is a dict, for example : {‘conv1’ : {0.1: 0.9, 0.2 : 0.8}, ‘conv2’ : {0.1: 0.9, 0.2 : 0.8}}, in which, ‘conv1’ and is the name of the conv layer, and 0.1:0.9 means when the sparsity of conv1 is 0.1 (10%), the model’s val accuracy equals to 0.9.

  • sparsity_per_iter (float) – The sparsity of the model that the pruner try to prune in each iteration.

  • acc_drop_threshold (float) – The hyperparameter used to quantifiy the sensitivity for each layer.

  • checkpoint_dir (str) – The dir path to save the checkpoints during the pruning.

calc_mask(wrapper, **kwargs)[source]

Pruners should overload this method to provide mask for weight tensors. The mask must have the same shape and type comparing to the weight. It will be applied with mul() operation on the weight. This method is effectively hooked to forward() method of the model.

Parameters

wrapper (Module) – calculate mask for wrapper.module’s weight

compress(eval_args=None, eval_kwargs=None, finetune_args=None, finetune_kwargs=None, resume_sensitivity=None)[source]

This function iteratively prune the model according to the results of the sensitivity analysis.

Parameters
  • eval_args (list) –

  • eval_kwargs (list& dict) – Parameters for the val_funtion, the val_function will be called like evaluator(*eval_args, **eval_kwargs)

  • finetune_args (list) –

  • finetune_kwargs (dict) – Parameters for the finetuner function if needed.

  • resume_sensitivity – resume the sensitivity results from this file.

create_cfg(ratios)[source]

Generate the cfg_list for the pruner according to the prune ratios.

Parameters

ratios – For example: {‘conv1’ : 0.2}

Returns

For example: [{‘sparsity’:0.2, ‘op_names’:[‘conv1’], ‘op_types’:[‘Conv2d’]}]

Return type

cfg_list

current_sparsity()[source]

The sparsity of the weight.

load_sensitivity(filepath)[source]

load the sensitivity results exported by the sensitivity analyzer

normalize(ratios, target_pruned)[source]

Normalize the prune ratio of each layer according to the total already pruned ratio and the final target total pruning ratio

Parameters
  • ratios – Dict object that save the prune ratio for each layer

  • target_pruned – The amount of the weights expected to be pruned in this iteration

Returns

return the normalized prune ratios for each layer.

Return type

new_ratios

validate_config(model, config_list)[source]
Parameters
  • model (torch.nn.module) – Model to be pruned

  • config_list (list) – List on pruning configs

class nni.algorithms.compression.pytorch.pruning.one_shot.OneshotPruner(model, config_list, pruning_algorithm='level', optimizer=None, **algo_kwargs)[source]

Prune model to an exact pruning level for one time.

calc_mask(wrapper, wrapper_idx=None)[source]

Calculate the mask of given layer :param wrapper: the module to instrument the compression operation :type wrapper: Module :param wrapper_idx: index of this wrapper in pruner’s all wrappers :type wrapper_idx: int

Returns

dictionary for storing masks, keys of the dict: ‘weight_mask’: weight mask tensor ‘bias_mask’: bias mask tensor (optional)

Return type

dict

validate_config(model, config_list)[source]
Parameters
  • model (torch.nn.Module) – Model to be pruned

  • config_list (list) – List on pruning configs

class nni.algorithms.compression.pytorch.pruning.one_shot.LevelPruner(model, config_list, optimizer=None)[source]
Parameters
  • model (torch.nn.Module) – Model to be pruned

  • config_list (list) –

    Supported keys:
    • sparsity : This is to specify the sparsity operations to be compressed to.

    • op_types : Operation types to prune.

  • optimizer (torch.optim.Optimizer) – Optimizer used to train model

class nni.algorithms.compression.pytorch.pruning.one_shot.SlimPruner(model, config_list, optimizer=None)[source]
Parameters
  • model (torch.nn.Module) – Model to be pruned

  • config_list (list) –

    Supported keys:
    • sparsity : This is to specify the sparsity operations to be compressed to.

    • op_types : Only BatchNorm2d is supported in Slim Pruner.

  • optimizer (torch.optim.Optimizer) – Optimizer used to train model

validate_config(model, config_list)[source]
Parameters
  • model (torch.nn.Module) – Model to be pruned

  • config_list (list) – List on pruning configs

class nni.algorithms.compression.pytorch.pruning.one_shot.L1FilterPruner(model, config_list, optimizer=None, dependency_aware=False, dummy_input=None)[source]
Parameters
  • model (torch.nn.Module) – Model to be pruned

  • config_list (list) –

    Supported keys:
    • sparsity : This is to specify the sparsity operations to be compressed to.

    • op_types : Only Conv2d is supported in L1FilterPruner.

  • optimizer (torch.optim.Optimizer) – Optimizer used to train model

  • dependency_aware (bool) – If prune the model in a dependency-aware way. If it is True, this pruner will prune the model according to the l2-norm of weights and the channel-dependency or group-dependency of the model. In this way, the pruner will force the conv layers that have dependencies to prune the same channels, so the speedup module can better harvest the speed benefit from the pruned model. Note that, if this flag is set True , the dummy_input cannot be None, because the pruner needs a dummy input to trace the dependency between the conv layers.

  • dummy_input (torch.Tensor) – The dummy input to analyze the topology constraints. Note that, the dummy_input should on the same device with the model.

class nni.algorithms.compression.pytorch.pruning.one_shot.L2FilterPruner(model, config_list, optimizer=None, dependency_aware=False, dummy_input=None)[source]
Parameters
  • model (torch.nn.Module) – Model to be pruned

  • config_list (list) –

    Supported keys:
    • sparsity : This is to specify the sparsity operations to be compressed to.

    • op_types : Only Conv2d is supported in L2FilterPruner.

  • optimizer (torch.optim.Optimizer) – Optimizer used to train model

  • dependency_aware (bool) – If prune the model in a dependency-aware way. If it is True, this pruner will prune the model according to the l2-norm of weights and the channel-dependency or group-dependency of the model. In this way, the pruner will force the conv layers that have dependencies to prune the same channels, so the speedup module can better harvest the speed benefit from the pruned model. Note that, if this flag is set True , the dummy_input cannot be None, because the pruner needs a dummy input to trace the dependency between the conv layers.

  • dummy_input (torch.Tensor) – The dummy input to analyze the topology constraints. Note that, the dummy_input should on the same device with the model.

class nni.algorithms.compression.pytorch.pruning.one_shot.FPGMPruner(model, config_list, optimizer=None, dependency_aware=False, dummy_input=None)[source]
Parameters
  • model (torch.nn.Module) – Model to be pruned

  • config_list (list) –

    Supported keys:
    • sparsity : This is to specify the sparsity operations to be compressed to.

    • op_types : Only Conv2d is supported in FPGM Pruner.

  • optimizer (torch.optim.Optimizer) – Optimizer used to train model

  • dependency_aware (bool) – If prune the model in a dependency-aware way. If it is True, this pruner will prune the model according to the l2-norm of weights and the channel-dependency or group-dependency of the model. In this way, the pruner will force the conv layers that have dependencies to prune the same channels, so the speedup module can better harvest the speed benefit from the pruned model. Note that, if this flag is set True , the dummy_input cannot be None, because the pruner needs a dummy input to trace the dependency between the conv layers.

  • dummy_input (torch.Tensor) – The dummy input to analyze the topology constraints. Note that, the dummy_input should on the same device with the model.

class nni.algorithms.compression.pytorch.pruning.one_shot.TaylorFOWeightFilterPruner(model, config_list, optimizer=None, statistics_batch_num=1, dependency_aware=False, dummy_input=None)[source]
Parameters
  • model (torch.nn.Module) – Model to be pruned

  • config_list (list) –

    Supported keys:
    • sparsity : How much percentage of convolutional filters are to be pruned.

    • op_types : Currently only Conv2d is supported in TaylorFOWeightFilterPruner.

  • optimizer (torch.optim.Optimizer) – Optimizer used to train model

  • statistics_batch_num (int) – The number of batches to statistic the activation.

  • dependency_aware (bool) – If prune the model in a dependency-aware way. If it is True, this pruner will prune the model according to the l2-norm of weights and the channel-dependency or group-dependency of the model. In this way, the pruner will force the conv layers that have dependencies to prune the same channels, so the speedup module can better harvest the speed benefit from the pruned model. Note that, if this flag is set True , the dummy_input cannot be None, because the pruner needs a dummy input to trace the dependency between the conv layers.

  • dummy_input (torch.Tensor) – The dummy input to analyze the topology constraints. Note that, the dummy_input should on the same device with the model.

class nni.algorithms.compression.pytorch.pruning.one_shot.ActivationAPoZRankFilterPruner(model, config_list, optimizer=None, activation='relu', statistics_batch_num=1, dependency_aware=False, dummy_input=None)[source]
Parameters
  • model (torch.nn.Module) – Model to be pruned

  • config_list (list) –

    Supported keys:
    • sparsity : How much percentage of convolutional filters are to be pruned.

    • op_types : Only Conv2d is supported in ActivationAPoZRankFilterPruner.

  • optimizer (torch.optim.Optimizer) – Optimizer used to train model

  • activation (str) – The activation type.

  • statistics_batch_num (int) – The number of batches to statistic the activation.

  • dependency_aware (bool) – If prune the model in a dependency-aware way. If it is True, this pruner will prune the model according to the l2-norm of weights and the channel-dependency or group-dependency of the model. In this way, the pruner will force the conv layers that have dependencies to prune the same channels, so the speedup module can better harvest the speed benefit from the pruned model. Note that, if this flag is set True , the dummy_input cannot be None, because the pruner needs a dummy input to trace the dependency between the conv layers.

  • dummy_input (torch.Tensor) – The dummy input to analyze the topology constraints. Note that, the dummy_input should on the same device with the model.

class nni.algorithms.compression.pytorch.pruning.one_shot.ActivationMeanRankFilterPruner(model, config_list, optimizer=None, activation='relu', statistics_batch_num=1, dependency_aware=False, dummy_input=None)[source]
Parameters
  • model (torch.nn.Module) – Model to be pruned

  • config_list (list) –

    Supported keys:
    • sparsity : How much percentage of convolutional filters are to be pruned.

    • op_types : Only Conv2d is supported in ActivationMeanRankFilterPruner.

  • optimizer (torch.optim.Optimizer) – Optimizer used to train model.

  • activation (str) – The activation type.

  • statistics_batch_num (int) – The number of batches to statistic the activation.

  • dependency_aware (bool) – If prune the model in a dependency-aware way. If it is True, this pruner will prune the model according to the l2-norm of weights and the channel-dependency or group-dependency of the model. In this way, the pruner will force the conv layers that have dependencies to prune the same channels, so the speedup module can better harvest the speed benefit from the pruned model. Note that, if this flag is set True , the dummy_input cannot be None, because the pruner needs a dummy input to trace the dependency between the conv layers.

  • dummy_input (torch.Tensor) – The dummy input to analyze the topology constraints. Note that, the dummy_input should on the same device with the model.

class nni.algorithms.compression.pytorch.pruning.lottery_ticket.LotteryTicketPruner(model, config_list, optimizer=None, lr_scheduler=None, reset_weights=True)[source]
Parameters
  • model (pytorch model) – The model to be pruned

  • config_list (list) –

    Supported keys:
    • prune_iterations : The number of rounds for the iterative pruning.

    • sparsity : The final sparsity when the compression is done.

  • optimizer (pytorch optimizer) – The optimizer for the model

  • lr_scheduler (pytorch lr scheduler) – The lr scheduler for the model if used

  • reset_weights (bool) – Whether reset weights and optimizer at the beginning of each round.

calc_mask(wrapper, **kwargs)[source]

Generate mask for the given weight.

Parameters

wrapper (Module) – The layer to be pruned

Returns

The mask for this weight, it is `None` because this pruner calculates and assigns masks in `prune_iteration_start`, no need to do anything in this function.

Return type

tensor

get_prune_iterations()[source]

Return the range for iterations. In the first prune iteration, masks are all one, thus, add one more iteration

Returns

A list for pruning iterations

Return type

list

prune_iteration_start()[source]

Control the pruning procedure on updated epoch number. Should be called at the beginning of the epoch.

validate_config(model, config_list)[source]
Parameters
  • model (torch.nn.Module) – Model to be pruned

  • config_list (list) –

    Supported keys:
    • prune_iterations : The number of rounds for the iterative pruning.

    • sparsity : The final sparsity when the compression is done.

class nni.algorithms.compression.pytorch.pruning.agp.AGPPruner(model, config_list, optimizer, pruning_algorithm='level')[source]
Parameters
  • model (torch.nn.Module) – Model to be pruned.

  • config_list (listlist) –

    Supported keys:
    • initial_sparsity: This is to specify the sparsity when compressor starts to compress.

    • final_sparsity: This is to specify the sparsity when compressor finishes to compress.

    • start_epoch: This is to specify the epoch number when compressor starts to compress, default start from epoch 0.

    • end_epoch: This is to specify the epoch number when compressor finishes to compress.

    • frequency: This is to specify every frequency number epochs compressor compress once, default frequency=1.

  • optimizer (torch.optim.Optimizer) – Optimizer used to train model.

  • pruning_algorithm (str) – Algorithms being used to prune model, choose from [‘level’, ‘slim’, ‘l1’, ‘l2’, ‘fpgm’, ‘taylorfo’, ‘apoz’, ‘mean_activation’], by default level

calc_mask(wrapper, wrapper_idx=None)[source]

Calculate the mask of given layer. Scale factors with the smallest absolute value in the BN layer are masked. :param wrapper: the layer to instrument the compression operation :type wrapper: Module :param wrapper_idx: index of this wrapper in pruner’s all wrappers :type wrapper_idx: int

Returns

Dictionary for storing masks, keys of the dict: ‘weight_mask’: weight mask tensor ‘bias_mask’: bias mask tensor (optional)

Return type

dict | None

compute_target_sparsity(config)[source]

Calculate the sparsity for pruning :param config: Layer’s pruning config :type config: dict

Returns

Target sparsity to be pruned

Return type

float

update_epoch(epoch)[source]

Update epoch :param epoch: current training epoch :type epoch: int

validate_config(model, config_list)[source]
Parameters
  • model (torch.nn.Module) – Model to be pruned

  • config_list (list) – List on pruning configs

class nni.algorithms.compression.pytorch.pruning.admm_pruner.ADMMPruner(model, config_list, trainer, num_iterations=30, training_epochs=5, row=0.0001, base_algo='l1')[source]

A Pytorch implementation of ADMM Pruner algorithm.

Parameters
  • model (torch.nn.Module) – Model to be pruned.

  • config_list (list) – List on pruning configs.

  • trainer (function) –

    Function used for the first subproblem. Users should write this function as a normal function to train the Pytorch model and include model, optimizer, criterion, epoch, callback as function arguments. Here callback acts as an L2 regulizer as presented in the formula (7) of the original paper. The logic of callback is implemented inside the Pruner, users are just required to insert callback() between loss.backward() and optimizer.step(). Example:

    def trainer(model, criterion, optimizer, epoch, callback):
        device = torch.device("cuda" if torch.cuda.is_available() else "cpu")
        train_loader = ...
        model.train()
        for batch_idx, (data, target) in enumerate(train_loader):
            data, target = data.to(device), target.to(device)
            optimizer.zero_grad()
            output = model(data)
            loss = criterion(output, target)
            loss.backward()
            # callback should be inserted between loss.backward() and optimizer.step()
            if callback:
                callback()
            optimizer.step()
    

  • num_iterations (int) – Total number of iterations.

  • training_epochs (int) – Training epochs of the first subproblem.

  • row (float) – Penalty parameters for ADMM training.

  • base_algo (str) – Base pruning algorithm. level, l1, l2 or fpgm, by default l1. Given the sparsity distribution among the ops, the assigned base_algo is used to decide which filters/channels/weights to prune.

compress()[source]

Compress the model with ADMM.

Returns

model with specified modules compressed.

Return type

torch.nn.Module

validate_config(model, config_list)[source]
Parameters
  • model (torch.nn.Module) – Model to be pruned

  • config_list (list) – List on pruning configs

class nni.algorithms.compression.pytorch.pruning.auto_compress_pruner.AutoCompressPruner(model, config_list, trainer, evaluator, dummy_input, num_iterations=3, optimize_mode='maximize', base_algo='l1', start_temperature=100, stop_temperature=20, cool_down_rate=0.9, perturbation_magnitude=0.35, admm_num_iterations=30, admm_training_epochs=5, row=0.0001, experiment_data_dir='./')[source]

A Pytorch implementation of AutoCompress pruning algorithm.

Parameters
  • model (pytorch model) – The model to be pruned.

  • config_list (list) –

    Supported keys:
    • sparsity : The target overall sparsity.

    • op_types : The operation type to prune.

  • trainer (function) –

    Function used for the first subproblem of ADMM Pruner. Users should write this function as a normal function to train the Pytorch model and include model, optimizer, criterion, epoch, callback as function arguments. Here callback acts as an L2 regulizer as presented in the formula (7) of the original paper. The logic of callback is implemented inside the Pruner, users are just required to insert callback() between loss.backward() and optimizer.step(). Example:

    def trainer(model, criterion, optimizer, epoch, callback):
        device = torch.device("cuda" if torch.cuda.is_available() else "cpu")
        train_loader = ...
        model.train()
        for batch_idx, (data, target) in enumerate(train_loader):
            data, target = data.to(device), target.to(device)
            optimizer.zero_grad()
            output = model(data)
            loss = criterion(output, target)
            loss.backward()
            # callback should be inserted between loss.backward() and optimizer.step()
            if callback:
                callback()
            optimizer.step()
    

  • evaluator (function) –

    function to evaluate the pruned model. This function should include model as the only parameter, and returns a scalar value. Example:

    def evaluator(model):
        device = torch.device("cuda" if torch.cuda.is_available() else "cpu")
        val_loader = ...
        model.eval()
        correct = 0
        with torch.no_grad():
            for data, target in val_loader:
                data, target = data.to(device), target.to(device)
                output = model(data)
                # get the index of the max log-probability
                pred = output.argmax(dim=1, keepdim=True)
                correct += pred.eq(target.view_as(pred)).sum().item()
        accuracy = correct / len(val_loader.dataset)
        return accuracy
    

  • dummy_input (pytorch tensor) – The dummy input for `jit.trace`, users should put it on right device before pass in.

  • num_iterations (int) – Number of overall iterations.

  • optimize_mode (str) – optimize mode, maximize or minimize, by default maximize.

  • base_algo (str) – Base pruning algorithm. level, l1, l2 or fpgm, by default l1. Given the sparsity distribution among the ops, the assigned base_algo is used to decide which filters/channels/weights to prune.

  • start_temperature (float) – Start temperature of the simulated annealing process.

  • stop_temperature (float) – Stop temperature of the simulated annealing process.

  • cool_down_rate (float) – Cool down rate of the temperature.

  • perturbation_magnitude (float) – Initial perturbation magnitude to the sparsities. The magnitude decreases with current temperature.

  • admm_num_iterations (int) – Number of iterations of ADMM Pruner.

  • admm_training_epochs (int) – Training epochs of the first optimization subproblem of ADMMPruner.

  • row (float) – Penalty parameters for ADMM training.

  • experiment_data_dir (string) – PATH to store temporary experiment data.

calc_mask(wrapper, **kwargs)[source]

Pruners should overload this method to provide mask for weight tensors. The mask must have the same shape and type comparing to the weight. It will be applied with mul() operation on the weight. This method is effectively hooked to forward() method of the model.

Parameters

wrapper (Module) – calculate mask for wrapper.module’s weight

compress()[source]

Compress the model with AutoCompress.

Returns

model with specified modules compressed.

Return type

torch.nn.Module

export_model(model_path, mask_path=None, onnx_path=None, input_shape=None, device=None)[source]

Export pruned model weights, masks and onnx model(optional)

Parameters
  • model_path (str) – path to save pruned model state_dict

  • mask_path (str) – (optional) path to save mask dict

  • onnx_path (str) – (optional) path to save onnx model

  • input_shape (list or tuple) – input shape to onnx model

  • device (torch.device) – device of the model, used to place the dummy input tensor for exporting onnx file. the tensor is placed on cpu if `device` is None

validate_config(model, config_list)[source]
Parameters
  • model (torch.nn.Module) – Model to be pruned

  • config_list (list) – List on pruning configs

class nni.algorithms.compression.pytorch.pruning.net_adapt_pruner.NetAdaptPruner(model, config_list, short_term_fine_tuner, evaluator, optimize_mode='maximize', base_algo='l1', sparsity_per_iteration=0.05, experiment_data_dir='./')[source]

A Pytorch implementation of NetAdapt compression algorithm.

Parameters
  • model (pytorch model) – The model to be pruned.

  • config_list (list) –

    Supported keys:
    • sparsity : The target overall sparsity.

    • op_types : The operation type to prune.

  • short_term_fine_tuner (function) –

    function to short-term fine tune the masked model. This function should include model as the only parameter, and fine tune the model for a short term after each pruning iteration. Example:

    def short_term_fine_tuner(model, epoch=3):
        device = torch.device("cuda" if torch.cuda.is_available() else "cpu")
        train_loader = ...
        criterion = torch.nn.CrossEntropyLoss()
        optimizer = torch.optim.SGD(model.parameters(), lr=0.01)
        model.train()
        for _ in range(epoch):
            for batch_idx, (data, target) in enumerate(train_loader):
                data, target = data.to(device), target.to(device)
                optimizer.zero_grad()
                output = model(data)
                loss = criterion(output, target)
                loss.backward()
                optimizer.step()
    

  • evaluator (function) –

    function to evaluate the masked model. This function should include model as the only parameter, and returns a scalar value. Example:

    def evaluator(model):
        device = torch.device("cuda" if torch.cuda.is_available() else "cpu")
        val_loader = ...
        model.eval()
        correct = 0
        with torch.no_grad():
            for data, target in val_loader:
                data, target = data.to(device), target.to(device)
                output = model(data)
                # get the index of the max log-probability
                pred = output.argmax(dim=1, keepdim=True)
                correct += pred.eq(target.view_as(pred)).sum().item()
        accuracy = correct / len(val_loader.dataset)
        return accuracy
    

  • optimize_mode (str) – optimize mode, maximize or minimize, by default maximize.

  • base_algo (str) – Base pruning algorithm. level, l1, l2 or fpgm, by default l1. Given the sparsity distribution among the ops, the assigned base_algo is used to decide which filters/channels/weights to prune.

  • sparsity_per_iteration (float) – sparsity to prune in each iteration.

  • experiment_data_dir (str) – PATH to save experiment data, including the config_list generated for the base pruning algorithm and the performance of the pruned model.

calc_mask(wrapper, **kwargs)[source]

Pruners should overload this method to provide mask for weight tensors. The mask must have the same shape and type comparing to the weight. It will be applied with mul() operation on the weight. This method is effectively hooked to forward() method of the model.

Parameters

wrapper (Module) – calculate mask for wrapper.module’s weight

compress()[source]

Compress the model.

Returns

model with specified modules compressed.

Return type

torch.nn.Module

validate_config(model, config_list)[source]
Parameters
  • model (torch.nn.Module) – Model to be pruned

  • config_list (list) – List on pruning configs

class nni.algorithms.compression.pytorch.pruning.simulated_annealing_pruner.SimulatedAnnealingPruner(model, config_list, evaluator, optimize_mode='maximize', base_algo='l1', start_temperature=100, stop_temperature=20, cool_down_rate=0.9, perturbation_magnitude=0.35, experiment_data_dir='./')[source]

A Pytorch implementation of Simulated Annealing compression algorithm.

Parameters
  • model (pytorch model) – The model to be pruned.

  • config_list (list) –

    Supported keys:
    • sparsity : The target overall sparsity.

    • op_types : The operation type to prune.

  • evaluator (function) –

    Function to evaluate the pruned model. This function should include model as the only parameter, and returns a scalar value. Example:

    def evaluator(model):
        device = torch.device("cuda" if torch.cuda.is_available() else "cpu")
        val_loader = ...
        model.eval()
        correct = 0
        with torch.no_grad():
            for data, target in val_loader:
                data, target = data.to(device), target.to(device)
                output = model(data)
                # get the index of the max log-probability
                pred = output.argmax(dim=1, keepdim=True)
                correct += pred.eq(target.view_as(pred)).sum().item()
        accuracy = correct / len(val_loader.dataset)
        return accuracy
    

  • optimize_mode (str) – Optimize mode, maximize or minimize, by default maximize.

  • base_algo (str) – Base pruning algorithm. level, l1, l2 or fpgm, by default l1. Given the sparsity distribution among the ops, the assigned base_algo is used to decide which filters/channels/weights to prune.

  • start_temperature (float) – Start temperature of the simulated annealing process.

  • stop_temperature (float) – Stop temperature of the simulated annealing process.

  • cool_down_rate (float) – Cool down rate of the temperature.

  • perturbation_magnitude (float) – Initial perturbation magnitude to the sparsities. The magnitude decreases with current temperature.

  • experiment_data_dir (string) – PATH to save experiment data, including the config_list generated for the base pruning algorithm, the performance of the pruned model and the pruning history.

calc_mask(wrapper, **kwargs)[source]

Pruners should overload this method to provide mask for weight tensors. The mask must have the same shape and type comparing to the weight. It will be applied with mul() operation on the weight. This method is effectively hooked to forward() method of the model.

Parameters

wrapper (Module) – calculate mask for wrapper.module’s weight

compress(return_config_list=False)[source]

Compress the model with Simulated Annealing.

Returns

model with specified modules compressed.

Return type

torch.nn.Module

validate_config(model, config_list)[source]
Parameters
  • model (torch.nn.Module) – Model to be pruned

  • config_list (list) – List on pruning configs

Quantizers
class nni.algorithms.compression.pytorch.quantization.quantizers.NaiveQuantizer(model, config_list, optimizer=None)[source]

quantize weight to 8 bits

quantize_weight(wrapper, **kwargs)[source]

quantize should overload this method to quantize weight. This method is effectively hooked to forward() of the model. :param wrapper: the wrapper for origin module :type wrapper: QuantizerModuleWrapper

validate_config(model, config_list)[source]

subclass can optionally implement this method to check if config_list if valid

class nni.algorithms.compression.pytorch.quantization.quantizers.QAT_Quantizer(model, config_list, optimizer=None)[source]

Quantizer defined in: Quantization and Training of Neural Networks for Efficient Integer-Arithmetic-Only Inference http://openaccess.thecvf.com/content_cvpr_2018/papers/Jacob_Quantization_and_Training_CVPR_2018_paper.pdf

export_model(model_path, calibration_path=None, onnx_path=None, input_shape=None, device=None)[source]

Export quantized model weights and calibration parameters(optional)

Parameters
  • model_path (str) – path to save quantized model weight

  • calibration_path (str) – (optional) path to save quantize parameters after calibration

  • onnx_path (str) – (optional) path to save onnx model

  • input_shape (list or tuple) – input shape to onnx model

  • device (torch.device) – device of the model, used to place the dummy input tensor for exporting onnx file. the tensor is placed on cpu if `device` is None

Returns

Return type

Dict

quantize_output(output, wrapper, **kwargs)[source]

quantize should overload this method to quantize output. This method is effectively hooked to forward() of the model. :param output: output that needs to be quantized :type output: Tensor :param wrapper: the wrapper for origin module :type wrapper: QuantizerModuleWrapper

quantize_weight(wrapper, **kwargs)[source]

quantize should overload this method to quantize weight. This method is effectively hooked to forward() of the model. :param wrapper: the wrapper for origin module :type wrapper: QuantizerModuleWrapper

step_with_optimizer()[source]

override compressor step method, quantization only happens after certain number of steps

validate_config(model, config_list)[source]
Parameters
  • model (torch.nn.Module) – Model to be pruned

  • config_list (list of dict) – List of configurations

class nni.algorithms.compression.pytorch.quantization.quantizers.DoReFaQuantizer(model, config_list, optimizer=None)[source]

Quantizer using the DoReFa scheme, as defined in: Zhou et al., DoReFa-Net: Training Low Bitwidth Convolutional Neural Networks with Low Bitwidth Gradients (https://arxiv.org/abs/1606.06160)

export_model(model_path, calibration_path=None, onnx_path=None, input_shape=None, device=None)[source]

Export quantized model weights and calibration parameters(optional)

Parameters
  • model_path (str) – path to save quantized model weight

  • calibration_path (str) – (optional) path to save quantize parameters after calibration

  • onnx_path (str) – (optional) path to save onnx model

  • input_shape (list or tuple) – input shape to onnx model

  • device (torch.device) – device of the model, used to place the dummy input tensor for exporting onnx file. the tensor is placed on cpu if `device` is None

Returns

Return type

Dict

quantize_weight(wrapper, **kwargs)[source]

quantize should overload this method to quantize weight. This method is effectively hooked to forward() of the model. :param wrapper: the wrapper for origin module :type wrapper: QuantizerModuleWrapper

validate_config(model, config_list)[source]
Parameters
  • model (torch.nn.Module) – Model to be pruned

  • config_list (list of dict) – List of configurations

class nni.algorithms.compression.pytorch.quantization.quantizers.BNNQuantizer(model, config_list, optimizer=None)[source]

Binarized Neural Networks, as defined in: Binarized Neural Networks: Training Deep Neural Networks with Weights and Activations Constrained to +1 or -1 (https://arxiv.org/abs/1602.02830)

export_model(model_path, calibration_path=None, onnx_path=None, input_shape=None, device=None)[source]

Export quantized model weights and calibration parameters(optional)

Parameters
  • model_path (str) – path to save quantized model weight

  • calibration_path (str) – (optional) path to save quantize parameters after calibration

  • onnx_path (str) – (optional) path to save onnx model

  • input_shape (list or tuple) – input shape to onnx model

  • device (torch.device) – device of the model, used to place the dummy input tensor for exporting onnx file. the tensor is placed on cpu if `device` is None

Returns

Return type

Dict

quantize_output(output, wrapper, **kwargs)[source]

quantize should overload this method to quantize output. This method is effectively hooked to forward() of the model. :param output: output that needs to be quantized :type output: Tensor :param wrapper: the wrapper for origin module :type wrapper: QuantizerModuleWrapper

quantize_weight(wrapper, **kwargs)[source]

quantize should overload this method to quantize weight. This method is effectively hooked to forward() of the model. :param wrapper: the wrapper for origin module :type wrapper: QuantizerModuleWrapper

validate_config(model, config_list)[source]
Parameters
  • model (torch.nn.Module) – Model to be pruned

  • config_list (list of dict) – List of configurations

Compression Utilities

Sensitivity Utilities
class nni.compression.pytorch.utils.sensitivity_analysis.SensitivityAnalysis(model, val_func, sparsities=None, prune_type='l1', early_stop_mode=None, early_stop_value=None)[source]
analysis(val_args=None, val_kwargs=None, specified_layers=None)[source]

This function analyze the sensitivity to pruning for each conv layer in the target model. If start and end are not set, we analyze all the conv layers by default. Users can specify several layers to analyze or parallelize the analysis process easily through the start and end parameter.

Parameters
  • val_args (list) – args for the val_function

  • val_kwargs (dict) – kwargs for the val_funtion

  • specified_layers (list) – list of layer names to analyze sensitivity. If this variable is set, then only analyze the conv layers that specified in the list. User can also use this option to parallelize the sensitivity analysis easily.

Returns

sensitivities – dict object that stores the trajectory of the accuracy/loss when the prune ratio changes

Return type

dict

export(filepath)[source]

Export the results of the sensitivity analysis to a csv file. The firstline of the csv file describe the content structure. The first line is constructed by ‘layername’ and sparsity list. Each line below records the validation metric returned by val_func when this layer is under different sparsities. Note that, due to the early_stop option, some layers may not have the metrics under all sparsities.

layername, 0.25, 0.5, 0.75 conv1, 0.6, 0.55 conv2, 0.61, 0.57, 0.56

Parameters

filepath (str) – Path of the output file

load_state_dict(state_dict)[source]

Update the weight of the model

update_already_pruned(layername, ratio)[source]

Set the already pruned ratio for the target layer.

Topology Utilities
class nni.compression.pytorch.utils.shape_dependency.ChannelDependency(model=None, dummy_input=None, traced_model=None)[source]
build_dependency()[source]

Build the channel dependency for the conv layers in the model.

property dependency_sets

Get the list of the dependency set.

Returns

dependency_sets – list of the dependency sets. For example, [set([‘conv1’, ‘conv2’]), set([‘conv3’, ‘conv4’])]

Return type

list

export(filepath)[source]

export the channel dependencies as a csv file. The layers at the same line have output channel dependencies with each other. For example, layer1.1.conv2, conv1, and layer1.0.conv2 have output channel dependencies with each other, which means the output channel(filters) numbers of these three layers should be same with each other, otherwise the model may has shape conflict.

Output example: Dependency Set,Convolutional Layers Set 1,layer1.1.conv2,layer1.0.conv2,conv1 Set 2,layer1.0.conv1 Set 3,layer1.1.conv1

class nni.compression.pytorch.utils.shape_dependency.GroupDependency(model=None, dummy_input=None, traced_model=None)[source]
build_dependency()[source]

Build the channel dependency for the conv layers in the model. This function return the group number of each conv layers. Note that, here, the group count of conv layers may be larger than their originl groups. This is because that the input channel will also be grouped for the group conv layers. To make this clear, assume we have two group conv layers: conv1(group=2), conv2(group=4). conv2 takes the output features of conv1 as input. Then we have to the filters of conv1 can still be divided into 4 groups after filter pruning, because the input channels of conv2 shoule be divided into 4 groups.

Returns

self.dependency – key: the name of conv layers, value: the minimum value that the number of filters should be divisible to.

Return type

dict

export(filepath)[source]

export the group dependency to a csv file. Each line describes a convolution layer, the first part of each line is the Pytorch module name of the conv layer. The second part of each line is the group count of the filters in this layer. Note that, the group count may be larger than this layers original group number.

output example: Conv layer, Groups Conv1, 1 Conv2, 2 Conv3, 4

class nni.compression.pytorch.utils.mask_conflict.CatMaskPadding(masks, model, dummy_input=None, traced=None)[source]
class nni.compression.pytorch.utils.mask_conflict.GroupMaskConflict(masks, model=None, dummy_input=None, traced=None)[source]
fix_mask()[source]

Fix the mask conflict before the mask inference for the layers that has group dependencies. This function should be called before the mask inference of the ‘speedup’ module.

class nni.compression.pytorch.utils.mask_conflict.ChannelMaskConflict(masks, model=None, dummy_input=None, traced=None)[source]
fix_mask()[source]

Fix the mask conflict before the mask inference for the layers that has shape dependencies. This function should be called before the mask inference of the ‘speedup’ module. Only structured pruning masks are supported.

Model FLOPs/Parameters Counter
nni.compression.pytorch.utils.counter.count_flops_params(model, x, custom_ops=None, verbose=True, mode='default')[source]

Count FLOPs and Params of the given model. This function would identify the mask on the module and take the pruned shape into consideration. Note that, for sturctured pruning, we only identify the remained filters according to its mask, and do not take the pruned input channels into consideration, so the calculated FLOPs will be larger than real number.

Parameters
  • model (nn.Module) – Target model.

  • x (tuple or tensor) – The input shape of data (a tuple), a tensor or a tuple of tensor as input data.

  • custom_ops (dict) – A mapping of (module -> torch.nn.Module : custom operation) the custom operation is a callback funtion to calculate the module flops and parameters, it will overwrite the default operation. for reference, please see ops in ModelProfiler.

  • verbose (bool) – If False, mute detail information about modules. Default is True.

  • mode (str) – the mode of how to collect information. If the mode is set to default, only the information of convolution and linear will be collected. If the mode is set to full, other operations will also be collected.

Returns

Representing total FLOPs, total parameters, and a detailed list of results respectively. The list of results are a list of dict, each of which contains (name, module_type, weight_shape, flops, params, input_size, output_size) as its keys.

Return type

tuple of int, int and dict

Feature Engineering

We are glad to introduce Feature Engineering toolkit on top of NNI, it’s still in the experiment phase which might evolve based on usage feedback. We’d like to invite you to use, feedback and even contribute.

For details, please refer to the following tutorials:

Feature Engineering with NNI

We are glad to announce the alpha release for Feature Engineering toolkit on top of NNI, it’s still in the experiment phase which might evolve based on user feedback. We’d like to invite you to use, feedback and even contribute.

For now, we support the following feature selector:

These selectors are suitable for tabular data(which means it doesn’t include image, speech and text data).

In addition, those selector only for feature selection. If you want to: 1) generate high-order combined features on nni while doing feature selection; 2) leverage your distributed resources; you could try this example.

How to use?

from nni.algorithms.feature_engineering.gradient_selector import FeatureGradientSelector
# from nni.algorithms.feature_engineering.gbdt_selector import GBDTSelector

# load data
...
X_train, X_test, y_train, y_test = train_test_split(X, y, test_size=0.33, random_state=42)

# initlize a selector
fgs = FeatureGradientSelector(...)
# fit data
fgs.fit(X_train, y_train)
# get improtant features
# will return the index with important feature here.
print(fgs.get_selected_features(...))

...

When using the built-in Selector, you first need to import a feature selector, and initialize it. You could call the function fit in the selector to pass the data to the selector. After that, you could use get_seleteced_features to get important features. The function parameters in different selectors might be different, so you need to check the docs before using it.

How to customize?

NNI provides state-of-the-art feature selector algorithm in the builtin-selector. NNI also supports to build a feature selector by yourself.

If you want to implement a customized feature selector, you need to:

  1. Inherit the base FeatureSelector class

  2. Implement fit and _get_selected features function

  3. Integrate with sklearn (Optional)

Here is an example:

1. Inherit the base Featureselector Class

from nni.feature_engineering.feature_selector import FeatureSelector

class CustomizedSelector(FeatureSelector):
    def __init__(self, ...):
    ...

2. Implement fit and _get_selected features Function

from nni.tuner import Tuner

from nni.feature_engineering.feature_selector import FeatureSelector

class CustomizedSelector(FeatureSelector):
    def __init__(self, ...):
    ...

    def fit(self, X, y, **kwargs):
        """
        Fit the training data to FeatureSelector

        Parameters
        ------------
        X : array-like numpy matrix
        The training input samples, which shape is [n_samples, n_features].
        y: array-like numpy matrix
        The target values (class labels in classification, real numbers in regression). Which shape is [n_samples].
        """
        self.X = X
        self.y = y
        ...

    def get_selected_features(self):
        """
        Get important feature

        Returns
        -------
        list :
        Return the index of the important feature.
        """
        ...
        return self.selected_features_

    ...

3. Integrate with Sklearn

sklearn.pipeline.Pipeline can connect models in series, such as feature selector, normalization, and classification/regression to form a typical machine learning problem workflow. The following step could help us to better integrate with sklearn, which means we could treat the customized feature selector as a module of the pipeline.

  1. Inherit the calss sklearn.base.BaseEstimator

  2. Implement _getparams and _set*params* function in BaseEstimator

  3. Inherit the class _sklearn.featureselection.base.SelectorMixin

  4. Implement _getsupport, transform and _inverse*transform* Function in SelectorMixin

Here is an example:

1. Inherit the BaseEstimator Class and its Function

from sklearn.base import BaseEstimator
from nni.feature_engineering.feature_selector import FeatureSelector

class CustomizedSelector(FeatureSelector, BaseEstimator):
    def __init__(self, ...):
    ...

    def get_params(self, ...):
        """
        Get parameters for this estimator.
        """
        params = self.__dict__
        params = {key: val for (key, val) in params.items()
        if not key.endswith('_')}
        return params

    def set_params(self, **params):
        """
        Set the parameters of this estimator.
        """
        for param in params:
        if hasattr(self, param):
        setattr(self, param, params[param])
        return self

2. Inherit the SelectorMixin Class and its Function

from sklearn.base import BaseEstimator
from sklearn.feature_selection.base import SelectorMixin

from nni.feature_engineering.feature_selector import FeatureSelector

class CustomizedSelector(FeatureSelector, BaseEstimator, SelectorMixin):
    def __init__(self, ...):
        ...

    def get_params(self, ...):
        """
        Get parameters for this estimator.
        """
        params = self.__dict__
        params = {key: val for (key, val) in params.items()
        if not key.endswith('_')}
        return params

    def set_params(self, **params):
        """
        Set the parameters of this estimator.
        """
        for param in params:
        if hasattr(self, param):
        setattr(self, param, params[param])
        return self

    def get_support(self, indices=False):
        """
        Get a mask, or integer index, of the features selected.

        Parameters
        ----------
        indices : bool
        Default False. If True, the return value will be an array of integers, rather than a boolean mask.

        Returns
        -------
        list :
        returns support: An index that selects the retained features from a feature vector.
        If indices are False, this is a boolean array of shape [# input features], in which an element is True iff its corresponding feature is selected for retention.
        If indices are True, this is an integer array of shape [# output features] whose values
        are indices into the input feature vector.
        """
        ...
        return mask


    def transform(self, X):
        """Reduce X to the selected features.

        Parameters
        ----------
        X : array
        which shape is [n_samples, n_features]

        Returns
        -------
        X_r : array
        which shape is [n_samples, n_selected_features]
        The input samples with only the selected features.
        """
        ...
        return X_r


    def inverse_transform(self, X):
        """
        Reverse the transformation operation

        Parameters
        ----------
        X : array
        shape is [n_samples, n_selected_features]

        Returns
        -------
        X_r : array
        shape is [n_samples, n_original_features]
        """
        ...
        return X_r

After integrating with Sklearn, we could use the feature selector as follows:

from sklearn.linear_model import LogisticRegression

# load data
...
X_train, y_train = ...

# build a ppipeline
pipeline = make_pipeline(XXXSelector(...), LogisticRegression())
pipeline = make_pipeline(SelectFromModel(ExtraTreesClassifier(n_estimators=50)), LogisticRegression())
pipeline.fit(X_train, y_train)

# score
print("Pipeline Score: ", pipeline.score(X_train, y_train))

Benchmark

Baseline means without any feature selection, we directly pass the data to LogisticRegression. For this benchmark, we only use 10% data from the train as test data. For the GradientFeatureSelector, we only take the top20 features. The metric is the mean accuracy on the given test data and labels.

Dataset

All Features + LR (acc, time, memory)

GradientFeatureSelector + LR (acc, time, memory)

TreeBasedClassifier + LR (acc, time, memory)

#Train

#Feature

colon-cancer

0.7547, 890ms, 348MiB

0.7368, 363ms, 286MiB

0.7223, 171ms, 1171 MiB

62

2,000

gisette

0.9725, 215ms, 584MiB

0.89416, 446ms, 397MiB

0.9792, 911ms, 234MiB

6,000

5,000

avazu

0.8834, N/A, N/A

N/A, N/A, N/A

N/A, N/A, N/A

40,428,967

1,000,000

rcv1

0.9644, 557ms, 241MiB

0.7333, 401ms, 281MiB

0.9615, 752ms, 284MiB

20,242

47,236

news20.binary

0.9208, 707ms, 361MiB

0.6870, 565ms, 371MiB

0.9070, 904ms, 364MiB

19,996

1,355,191

real-sim

0.9681, 433ms, 274MiB

0.7969, 251ms, 274MiB

0.9591, 643ms, 367MiB

72,309

20,958

The dataset of benchmark could be download in here

The code could be refenrence /examples/feature_engineering/gradient_feature_selector/benchmark_test.py.

Reference and Feedback

GradientFeatureSelector

The algorithm in GradientFeatureSelector comes from Feature Gradients: Scalable Feature Selection via Discrete Relaxation.

GradientFeatureSelector, a gradient-based search algorithm for feature selection.

1) This approach extends a recent result on the estimation of learnability in the sublinear data regime by showing that the calculation can be performed iteratively (i.e., in mini-batches) and in linear time and space with respect to both the number of features D and the sample size N.

  1. This, along with a discrete-to-continuous relaxation of the search domain, allows for an efficient, gradient-based search algorithm among feature subsets for very large datasets.

  2. Crucially, this algorithm is capable of finding higher-order correlations between features and targets for both the N > D and N < D regimes, as opposed to approaches that do not consider such interactions and/or only consider one regime.

Usage

from nni.algorithms.feature_engineering.gradient_selector import FeatureGradientSelector

# load data
...
X_train, X_test, y_train, y_test = train_test_split(X, y, test_size=0.33, random_state=42)

# initlize a selector
fgs = FeatureGradientSelector(n_features=10)
# fit data
fgs.fit(X_train, y_train)
# get improtant features
# will return the index with important feature here.
print(fgs.get_selected_features())

...

And you could reference the examples in /examples/feature_engineering/gradient_feature_selector/, too.

Parameters of class FeatureGradientSelector constructor

  • order (int, optional, default = 4) - What order of interactions to include. Higher orders may be more accurate but increase the run time. 12 is the maximum allowed order.

  • penatly (int, optional, default = 1) - Constant that multiplies the regularization term.

  • n_features (int, optional, default = None) - If None, will automatically choose number of features based on search. Otherwise, the number of top features to select.

  • max_features (int, optional, default = None) - If not None, will use the ‘elbow method’ to determine the number of features with max_features as the upper limit.

  • learning_rate (float, optional, default = 1e-1) - learning rate

  • init (zero, on, off, onhigh, offhigh, or sklearn, optional, default = zero) - How to initialize the vector of scores. ‘zero’ is the default.

  • n_epochs (int, optional, default = 1) - number of epochs to run

  • shuffle (bool, optional, default = True) - Shuffle “rows” prior to an epoch.

  • batch_size (int, optional, default = 1000) - Nnumber of “rows” to process at a time.

  • target_batch_size (int, optional, default = 1000) - Number of “rows” to accumulate gradients over. Useful when many rows will not fit into memory but are needed for accurate estimation.

  • classification (bool, optional, default = True) - If True, problem is classification, else regression.

  • ordinal (bool, optional, default = True) - If True, problem is ordinal classification. Requires classification to be True.

  • balanced (bool, optional, default = True) - If true, each class is weighted equally in optimization, otherwise weighted is done via support of each class. Requires classification to be True.

  • prerocess (str, optional, default = ‘zscore’) - ‘zscore’ which refers to centering and normalizing data to unit variance or ‘center’ which only centers the data to 0 mean.

  • soft_grouping (bool, optional, default = True) - If True, groups represent features that come from the same source. Used to encourage sparsity of groups and features within groups.

  • verbose (int, optional, default = 0) - Controls the verbosity when fitting. Set to 0 for no printing 1 or higher for printing every verbose number of gradient steps.

  • device (str, optional, default = ‘cpu’) - ‘cpu’ to run on CPU and ‘cuda’ to run on GPU. Runs much faster on GPU

Requirement of fit FuncArgs

  • X (array-like, require) - The training input samples which shape = [n_samples, n_features]

  • y (array-like, require) - The target values (class labels in classification, real numbers in regression) which shape = [n_samples].

  • groups (array-like, optional, default = None) - Groups of columns that must be selected as a unit. e.g. [0, 0, 1, 2] specifies the first two columns are part of a group. Which shape is [n_features].

Requirement of get_selected_features FuncArgs

For now, the get_selected_features function has no parameters.

GBDTSelector

GBDTSelector is based on LightGBM, which is a gradient boosting framework that uses tree-based learning algorithms.

When passing the data into the GBDT model, the model will construct the boosting tree. And the feature importance comes from the score in construction, which indicates how useful or valuable each feature was in the construction of the boosted decision trees within the model.

We could use this method as a strong baseline in Feature Selector, especially when using the GBDT model as a classifier or regressor.

For now, we support the importance_type is split and gain. But we will support customized importance_type in the future, which means the user could define how to calculate the feature score by themselves.

Usage

First you need to install dependency:

pip install lightgbm

Then

from nni.algorithms.feature_engineering.gbdt_selector import GBDTSelector

# load data
...
X_train, X_test, y_train, y_test = train_test_split(X, y, test_size=0.33, random_state=42)

# initlize a selector
fgs = GBDTSelector()
# fit data
fgs.fit(X_train, y_train, ...)
# get improtant features
# will return the index with important feature here.
print(fgs.get_selected_features(10))

...

And you could reference the examples in /examples/feature_engineering/gbdt_selector/, too.

Requirement of fit FuncArgs

  • X (array-like, require) - The training input samples which shape = [n_samples, n_features]

  • y (array-like, require) - The target values (class labels in classification, real numbers in regression) which shape = [n_samples].

  • lgb_params (dict, require) - The parameters for lightgbm model. The detail you could reference here

  • eval_ratio (float, require) - The ratio of data size. It’s used for split the eval data and train data from self.X.

  • early_stopping_rounds (int, require) - The early stopping setting in lightgbm. The detail you could reference here.

  • importance_type (str, require) - could be ‘split’ or ‘gain’. The ‘split’ means ‘ result contains numbers of times the feature is used in a model’ and the ‘gain’ means ‘result contains total gains of splits which use the feature’. The detail you could reference in here.

  • num_boost_round (int, require) - number of boost round. The detail you could reference here.

Requirement of get_selected_features FuncArgs

  • topk (int, require) - the topK impotance features you want to selected.

References

nnictl

Introduction

nnictl is a command line tool, which can be used to control experiments, such as start/stop/resume an experiment, start/stop NNIBoard, etc.

Commands

nnictl support commands:

Manage an experiment

nnictl create
  • Description

    You can use this command to create a new experiment, using the configuration specified in config file.

    After this command is successfully done, the context will be set as this experiment, which means the following command you issued is associated with this experiment, unless you explicitly changes the context(not supported yet).

  • Usage

    nnictl create [OPTIONS]
    
  • Options

Name, shorthand

Required

Default

Description

–config, -c

True

YAML configure file of the experiment

–port, -p

False

the port of restful server

–debug, -d

False

set debug mode

–foreground, -f

False

set foreground mode, print log content to terminal

  • Examples

    create a new experiment with the default port: 8080

    nnictl create --config nni/examples/trials/mnist-pytorch/config.yml
    

    create a new experiment with specified port 8088

    nnictl create --config nni/examples/trials/mnist-pytorch/config.yml --port 8088
    

    create a new experiment with specified port 8088 and debug mode

    nnictl create --config nni/examples/trials/mnist-pytorch/config.yml --port 8088 --debug
    

Note:

Debug mode will disable version check function in Trialkeeper.

nnictl resume
  • Description

    You can use this command to resume a stopped experiment.

  • Usage

    nnictl resume [OPTIONS]
    
  • Options

Name, shorthand

Required

Default

Description

id

True

The id of the experiment you want to resume

–port, -p

False

Rest port of the experiment you want to resume

–debug, -d

False

set debug mode

–foreground, -f

False

set foreground mode, print log content to terminal

  • Example

    resume an experiment with specified port 8088

    nnictl resume [experiment_id] --port 8088
    

nnictl view
  • Description

    You can use this command to view a stopped experiment.

  • Usage

    nnictl view [OPTIONS]
    
  • Options

Name, shorthand

Required

Default

Description

id

True

The id of the experiment you want to view

–port, -p

False

Rest port of the experiment you want to view

  • Example

    view an experiment with specified port 8088

    nnictl view [experiment_id] --port 8088
    

nnictl stop
  • Description

    You can use this command to stop a running experiment or multiple experiments.

  • Usage

    nnictl stop [Options]
    
  • Options

Name, shorthand

Required

Default

Description

id

False

The id of the experiment you want to stop

–port, -p

False

Rest port of the experiment you want to stop

–all, -a

False

Stop all of experiments

  • Details & Examples

    1. If there is no id specified, and there is an experiment running, stop the running experiment, or print error message.

      nnictl stop
      
    2. If there is an id specified, and the id matches the running experiment, nnictl will stop the corresponding experiment, or will print error message.

      nnictl stop [experiment_id]
      
    3. If there is a port specified, and an experiment is running on that port, the experiment will be stopped.

      nnictl stop --port 8080
      
    4. Users could use ‘nnictl stop –all’ to stop all experiments.

      nnictl stop --all
      
    5. If the id ends with *, nnictl will stop all experiments whose ids matchs the regular.

    6. If the id does not exist but match the prefix of an experiment id, nnictl will stop the matched experiment.

    7. If the id does not exist but match multiple prefix of the experiment ids, nnictl will give id information.

nnictl update
  • nnictl update searchspace

    • Description

      You can use this command to update an experiment’s search space.

    • Usage

      nnictl update searchspace [OPTIONS]
      
    • Options

Name, shorthand

Required

Default

Description

id

False

ID of the experiment you want to set

–filename, -f

True

the file storing your new search space

  • Example

    update experiment's new search space with file dir 'examples/trials/mnist-pytorch/search_space.json'

    nnictl update searchspace [experiment_id] --filename examples/trials/mnist-pytorch/search_space.json
    
  • nnictl update concurrency

    • Description

      You can use this command to update an experiment’s concurrency.

    • Usage

      nnictl update concurrency [OPTIONS]
      
    • Options

Name, shorthand

Required

Default

Description

id

False

ID of the experiment you want to set

–value, -v

True

the number of allowed concurrent trials

  • Example

    update experiment’s concurrency

    nnictl update concurrency [experiment_id] --value [concurrency_number]
    
  • nnictl update duration

    • Description

      You can use this command to update an experiment’s duration.

    • Usage

      nnictl update duration [OPTIONS]
      
    • Options

Name, shorthand

Required

Default

Description

id

False

ID of the experiment you want to set

–value, -v

True

Strings like ‘1m’ for one minute or ‘2h’ for two hours. SUFFIX may be ‘s’ for seconds, ‘m’ for minutes, ‘h’ for hours or ‘d’ for days.

  • Example

    update experiment’s duration

    nnictl update duration [experiment_id] --value [duration]
    
  • nnictl update trialnum

    • Description

      You can use this command to update an experiment’s maxtrialnum.

    • Usage

      nnictl update trialnum [OPTIONS]
      
    • Options

Name, shorthand

Required

Default

Description

id

False

ID of the experiment you want to set

–value, -v

True

the new number of maxtrialnum you want to set

  • Example

    update experiment’s trial num

    nnictl update trialnum [experiment_id] --value [trial_num]
    

nnictl trial
  • nnictl trial ls

    • Description

      You can use this command to show trial’s information. Note that if head or tail is set, only complete trials will be listed.

    • Usage

      nnictl trial ls
      nnictl trial ls --head 10
      nnictl trial ls --tail 10
      
    • Options

Name, shorthand

Required

Default

Description

id

False

ID of the experiment you want to set

–head

False

the number of items to be listed with the highest default metric

–tail

False

the number of items to be listed with the lowest default metric

  • nnictl trial kill

    • Description

      You can use this command to kill a trial job.

    • Usage

      nnictl trial kill [OPTIONS]
      
    • Options

Name, shorthand

Required

Default

Description

id

False

Experiment ID of the trial

–trial_id, -T

True

ID of the trial you want to kill.

  • Example

    kill trail job

    nnictl trial kill [experiment_id] --trial_id [trial_id]
    

nnictl top
  • Description

    Monitor all of running experiments.

  • Usage

    nnictl top
    
  • Options

Name, shorthand

Required

Default

Description

id

False

ID of the experiment you want to set

–time, -t

False

The interval to update the experiment status, the unit of time is second, and the default value is 3 second.

Manage experiment information
  • nnictl experiment show

    • Description

      Show the information of experiment.

    • Usage

      nnictl experiment show
      
    • Options

Name, shorthand

Required

Default

Description

id

False

ID of the experiment you want to set

  • nnictl experiment status

    • Description

      Show the status of experiment.

    • Usage

      nnictl experiment status
      
    • Options

Name, shorthand

Required

Default

Description

id

False

ID of the experiment you want to set

  • nnictl experiment list

    • Description

      Show the information of all the (running) experiments.

    • Usage

      nnictl experiment list [OPTIONS]
      
    • Options

Name, shorthand

Required

Default

Description

–all

False

list all of experiments

  • nnictl experiment delete

    • Description

      Delete one or all experiments, it includes log, result, environment information and cache. It uses to delete useless experiment result, or save disk space.

    • Usage

      nnictl experiment delete [OPTIONS]
      
    • Options

Name, shorthand

Required

Default

Description

id

False

ID of the experiment

–all

False

delete all of experiments

  • nnictl experiment export

    • Description

      You can use this command to export reward & hyper-parameter of trial jobs to a csv file.

    • Usage

      nnictl experiment export [OPTIONS]
      
    • Options

Name, shorthand

Required

Default

Description

id

False

ID of the experiment

–filename, -f

True

File path of the output file

–type

True

Type of output file, only support “csv” and “json”

–intermediate, -i

False

Are intermediate results included

  • Examples

    export all trial data in an experiment as json format

    nnictl experiment export [experiment_id] --filename [file_path] --type json --intermediate
    
  • nnictl experiment import

    • Description

      You can use this command to import several prior or supplementary trial hyperparameters & results for NNI hyperparameter tuning. The data are fed to the tuning algorithm (e.g., tuner or advisor).

    • Usage

      nnictl experiment import [OPTIONS]
      
    • Options

Name, shorthand

Required

Default

Description

id

False

The id of the experiment you want to import data into

–filename, -f

True

a file with data you want to import in json format

  • Details

    NNI supports users to import their own data, please express the data in the correct format. An example is shown below:

    [
      {"parameter": {"x": 0.5, "y": 0.9}, "value": 0.03},
      {"parameter": {"x": 0.4, "y": 0.8}, "value": 0.05},
      {"parameter": {"x": 0.3, "y": 0.7}, "value": 0.04}
    ]
    

    Every element in the top level list is a sample. For our built-in tuners/advisors, each sample should have at least two keys: parameter and value. The parameter must match this experiment’s search space, that is, all the keys (or hyperparameters) in parameter must match the keys in the search space. Otherwise, tuner/advisor may have unpredictable behavior. Value should follow the same rule of the input in nni.report_final_result, that is, either a number or a dict with a key named default. For your customized tuner/advisor, the file could have any json content depending on how you implement the corresponding methods (e.g., import_data).

    You also can use nnictl experiment export to export a valid json file including previous experiment trial hyperparameters and results.

    Currently, following tuner and advisor support import data:

    builtinTunerName: TPE, Anneal, GridSearch, MetisTuner
    builtinAdvisorName: BOHB
    

    If you want to import data to BOHB advisor, user are suggested to add “TRIAL_BUDGET” in parameter as NNI do, otherwise, BOHB will use max_budget as “TRIAL_BUDGET”. Here is an example:

    [
      {"parameter": {"x": 0.5, "y": 0.9, "TRIAL_BUDGET": 27}, "value": 0.03}
    ]
    
  • Examples

    import data to a running experiment

    nnictl experiment import [experiment_id] -f experiment_data.json
    
  • nnictl experiment save

    • Description

      Save nni experiment metadata and code data.

    • Usage

      nnictl experiment save [OPTIONS]
      
    • Options

Name, shorthand

Required

Default

Description

id

True

The id of the experiment you want to save

–path, -p

False

the folder path to store nni experiment data, default current working directory

–saveCodeDir, -s

False

save codeDir data of the experiment, default False

  • Examples

    save an expeirment

    nnictl experiment save [experiment_id] --saveCodeDir
    
  • nnictl experiment load

    • Description

      Load an nni experiment.

    • Usage

      nnictl experiment load [OPTIONS]
      
    • Options

Name, shorthand

Required

Default

Description

–path, -p

True

the file path of nni package

–codeDir, -c

True

the path of codeDir for loaded experiment, this path will also put the code in the loaded experiment package

–logDir, -l

False

the path of logDir for loaded experiment

–searchSpacePath, -s

True

the path of search space file for loaded experiment, this path contains file name. Default in $codeDir/search_space.json

  • Examples

    load an expeirment

    nnictl experiment load --path [path] --codeDir [codeDir]
    

Manage platform information
  • nnictl platform clean

    • Description

      It uses to clean up disk on a target platform. The provided YAML file includes the information of target platform, and it follows the same schema as the NNI configuration file.

    • Note

      if the target platform is being used by other users, it may cause unexpected errors to others.

    • Usage

      nnictl platform clean [OPTIONS]
      
    • Options

Name, shorthand

Required

Default

Description

–config

True

the path of yaml config file used when create an experiment

nnictl config show
  • Description

    Display the current context information.

  • Usage

    nnictl config show
    

Manage log
  • nnictl log stdout

    • Description

      Show the stdout log content.

    • Usage

      nnictl log stdout [options]
      
    • Options

Name, shorthand

Required

Default

Description

id

False

ID of the experiment you want to set

–head, -h

False

show head lines of stdout

–tail, -t

False

show tail lines of stdout

–path, -p

False

show the path of stdout file

  • Example

    Show the tail of stdout log content

    nnictl log stdout [experiment_id] --tail [lines_number]
    
  • nnictl log stderr

    • Description

      Show the stderr log content.

    • Usage

      nnictl log stderr [options]
      
    • Options

Name, shorthand

Required

Default

Description

id

False

ID of the experiment you want to set

–head, -h

False

show head lines of stderr

–tail, -t

False

show tail lines of stderr

–path, -p

False

show the path of stderr file

  • nnictl log trial

    • Description

      Show trial log path.

    • Usage

      nnictl log trial [options]
      
    • Options

Name, shorthand

Required

Default

Description

id

False

Experiment ID of the trial

–trial_id, -T

False

ID of the trial to be found the log path, required when id is not empty.

Manage webui
  • nnictl webui url

    • Description

      Show an experiment’s webui url

    • Usage

      nnictl webui url [options]
      
    • Options

Name, shorthand

Required

Default

Description

id

False

Experiment ID

Manage tensorboard
  • nnictl tensorboard start

    • Description

      Start the tensorboard process.

    • Usage

      nnictl tensorboard start
      
    • Options

Name, shorthand

Required

Default

Description

id

False

ID of the experiment you want to set

–trial_id, -T

False

ID of the trial

–port

False

6006

The port of the tensorboard process

  • Detail

    1. NNICTL support tensorboard function in local and remote platform for the moment, other platforms will be supported later.

    2. If you want to use tensorboard, you need to write your tensorboard log data to environment variable [NNI_OUTPUT_DIR] path.

    3. In local mode, nnictl will set –logdir=[NNI_OUTPUT_DIR] directly and start a tensorboard process.

    4. In remote mode, nnictl will create a ssh client to copy log data from remote machine to local temp directory firstly, and then start a tensorboard process in your local machine. You need to notice that nnictl only copy the log data one time when you use the command, if you want to see the later result of tensorboard, you should execute nnictl tensorboard command again.

    5. If there is only one trial job, you don’t need to set trial id. If there are multiple trial jobs running, you should set the trial id, or you could use [nnictl tensorboard start –trial_id all] to map –logdir to all trial log paths.

  • nnictl tensorboard stop

    • Description

      Stop all of the tensorboard process.

    • Usage

      nnictl tensorboard stop
      
    • Options

Name, shorthand

Required

Default

Description

id

False

ID of the experiment you want to set

Manage builtin algorithms
  • nnictl algo register

    • Description

      Register customized algorithms as builtin tuner/assessor/advisor.

    • Usage

      nnictl algo register --meta <path_to_meta_file>
      

      <path_to_meta_file> is the path to the meta data file in yml format, which has following keys:

      • algoType: type of algorithms, could be one of tuner, assessor, advisor

      • builtinName: builtin name used in experiment configuration file

      • className: tuner class name, including its module name, for example: demo_tuner.DemoTuner

      • classArgsValidator: class args validator class name, including its module name, for example: demo_tuner.MyClassArgsValidator

    • Example

      Install a customized tuner in nni examples

      cd nni/examples/tuners/customized_tuner
      python3 setup.py develop
      nnictl algo register --meta meta_file.yml
      
  • nnictl algo show

    • Description

      Show the detailed information of specified registered algorithms.

    • Usage

      nnictl algo show <builtinName>
      
    • Example

      nnictl algo show SMAC
      
  • nnictl package list

    • Description

      List the registered builtin algorithms.

    • Usage

      nnictl algo list
      
  • Example

    nnictl algo list
    
  • nnictl algo unregister

    • Description

      Unregister a registered customized builtin algorithms. The NNI provided builtin algorithms can not be unregistered.

    • Usage

      nnictl algo unregister <builtinName>
      
    • Example

      nnictl algo unregister demotuner
      

Generate search space
  • nnictl ss_gen

    • Description

      Generate search space from user trial code which uses NNI NAS APIs.

    • Usage

      nnictl ss_gen [OPTIONS]
      
    • Options

Name, shorthand

Required

Default

Description

–trial_command

True

The command of the trial code

–trial_dir

False

./

The directory of the trial code

–file

False

nni_auto_gen_search_space.json

The file for storing generated search space

  • Example

    Generate a search space

    nnictl ss_gen --trial_command="python3 mnist.py" --trial_dir=./ --file=ss.json
    

Check NNI version
  • nnictl –version

    • Description

      Describe the current version of NNI installed.

    • Usage

      nnictl --version
      

Experiment Config Reference

A config file is needed when creating an experiment. The path of the config file is provided to nnictl. The config file is in YAML format. This document describes the rules to write the config file, and provides some examples and templates.

Template

  • Light weight (without Annotation and Assessor)

authorName:
experimentName:
trialConcurrency:
maxExecDuration:
maxTrialNum:
#choice: local, remote, pai, kubeflow
trainingServicePlatform:
searchSpacePath:
#choice: true, false, default: false
useAnnotation:
#choice: true, false, default: false
multiThread:
tuner:
  #choice: TPE, Random, Anneal, Evolution
  builtinTunerName:
  classArgs:
    #choice: maximize, minimize
    optimize_mode:
  gpuIndices:
trial:
  command:
  codeDir:
  gpuNum:
#machineList can be empty if the platform is local
machineList:
  - ip:
    port:
    username:
    passwd:
  • Use Assessor

authorName:
experimentName:
trialConcurrency:
maxExecDuration:
maxTrialNum:
#choice: local, remote, pai, kubeflow
trainingServicePlatform:
searchSpacePath:
#choice: true, false, default: false
useAnnotation:
#choice: true, false, default: false
multiThread:
tuner:
  #choice: TPE, Random, Anneal, Evolution
  builtinTunerName:
  classArgs:
    #choice: maximize, minimize
    optimize_mode:
  gpuIndices:
assessor:
  #choice: Medianstop
  builtinAssessorName:
  classArgs:
    #choice: maximize, minimize
    optimize_mode:
trial:
  command:
  codeDir:
  gpuNum:
#machineList can be empty if the platform is local
machineList:
  - ip:
    port:
    username:
    passwd:
  • Use Annotation

authorName:
experimentName:
trialConcurrency:
maxExecDuration:
maxTrialNum:
#choice: local, remote, pai, kubeflow
trainingServicePlatform:
#choice: true, false, default: false
useAnnotation:
#choice: true, false, default: false
multiThread:
tuner:
  #choice: TPE, Random, Anneal, Evolution
  builtinTunerName:
  classArgs:
    #choice: maximize, minimize
    optimize_mode:
  gpuIndices:
assessor:
  #choice: Medianstop
  builtinAssessorName:
  classArgs:
    #choice: maximize, minimize
    optimize_mode:
trial:
  command:
  codeDir:
  gpuNum:
#machineList can be empty if the platform is local
machineList:
  - ip:
    port:
    username:
    passwd:

Configuration Spec

authorName

Required. String.

The name of the author who create the experiment.

TBD: add default value.

experimentName

Required. String.

The name of the experiment created.

TBD: add default value.

trialConcurrency

Required. Integer between 1 and 99999.

Specifies the max num of trial jobs run simultaneously.

If trialGpuNum is bigger than the free gpu numbers, and the trial jobs running simultaneously can not reach trialConcurrency number, some trial jobs will be put into a queue to wait for gpu allocation.

maxExecDuration

Optional. String. Default: 999d.

maxExecDuration specifies the max duration time of an experiment. The unit of the time is {sm, h, d}, which means {seconds, minutes, hours, days}.

Note: The maxExecDuration spec set the time of an experiment, not a trial job. If the experiment reach the max duration time, the experiment will not stop, but could not submit new trial jobs any more.

versionCheck

Optional. Bool. Default: true.

NNI will check the version of nniManager process and the version of trialKeeper in remote, pai and kubernetes platform. If you want to disable version check, you could set versionCheck be false.

debug

Optional. Bool. Default: false.

Debug mode will set versionCheck to false and set logLevel to be ‘debug’.

maxTrialNum

Optional. Integer between 1 and 99999. Default: 99999.

Specifies the max number of trial jobs created by NNI, including succeeded and failed jobs.

trainingServicePlatform

Required. String.

Specifies the platform to run the experiment, including local, remote, pai, kubeflow, frameworkcontroller.

  • local run an experiment on local ubuntu machine.

  • remote submit trial jobs to remote ubuntu machines, and machineList field should be filed in order to set up SSH connection to remote machine.

  • pai submit trial jobs to OpenPAI of Microsoft. For more details of pai configuration, please refer to Guide to PAI Mode

  • kubeflow submit trial jobs to kubeflow, NNI support kubeflow based on normal kubernetes and azure kubernetes. For detail please refer to Kubeflow Docs

  • adl submit trial jobs to AdaptDL, NNI support AdaptDL on Kubernetes cluster. For detail please refer to AdaptDL Docs

  • TODO: explain frameworkcontroller.

searchSpacePath

Optional. Path to existing file.

Specifies the path of search space file, which should be a valid path in the local linux machine.

The only exception that searchSpacePath can be not fulfilled is when useAnnotation=True.

useAnnotation

Optional. Bool. Default: false.

Use annotation to analysis trial code and generate search space.

Note: if useAnnotation is true, the searchSpacePath field should be removed.

multiThread

Optional. Bool. Default: false.

Enable multi-thread mode for dispatcher. If multiThread is enabled, dispatcher will start a thread to process each command from NNI Manager.

nniManagerIp

Optional. String. Default: eth0 device IP.

Set the IP address of the machine on which NNI manager process runs. This field is optional, and if it’s not set, eth0 device IP will be used instead.

Note: run ifconfig on NNI manager’s machine to check if eth0 device exists. If not, nniManagerIp is recommended to set explicitly.

logDir

Optional. Path to a directory. Default: <user home directory>/nni-experiments.

Configures the directory to store logs and data of the experiment.

logLevel

Optional. String. Default: info.

Sets log level for the experiment. Available log levels are: trace, debug, info, warning, error, fatal.

logCollection

Optional. http or none. Default: none.

Set the way to collect log in remote, pai, kubeflow, frameworkcontroller platform. There are two ways to collect log, one way is from http, trial keeper will post log content back from http request in this way, but this way may slow down the speed to process logs in trialKeeper. The other way is none, trial keeper will not post log content back, and only post job metrics. If your log content is too big, you could consider setting this param be none.

tuner

Required.

Specifies the tuner algorithm in the experiment, there are two kinds of ways to set tuner. One way is to use tuner provided by NNI sdk (built-in tuners), in which case you need to set builtinTunerName and classArgs. Another way is to use users’ own tuner file, in which case codeDirectory, classFileName, className and classArgs are needed. Users must choose exactly one way.

builtinTunerName

Required if using built-in tuners. String.

Specifies the name of system tuner, NNI sdk provides different tuners introduced here.

codeDir

Required if using customized tuners. Path relative to the location of config file.

Specifies the directory of tuner code.

classFileName

Required if using customized tuners. File path relative to codeDir.

Specifies the name of tuner file.

className

Required if using customized tuners. String.

Specifies the name of tuner class.

classArgs

Optional. Key-value pairs. Default: empty.

Specifies the arguments of tuner algorithm. Please refer to this file for the configurable arguments of each built-in tuner.

gpuIndices

Optional. String. Default: empty.

Specifies the GPUs that can be used by the tuner process. Single or multiple GPU indices can be specified. Multiple GPU indices are separated by comma ,. For example, 1, or 0,1,3. If the field is not set, no GPU will be visible to tuner (by setting CUDA_VISIBLE_DEVICES to be an empty string).

includeIntermediateResults

Optional. Bool. Default: false.

If includeIntermediateResults is true, the last intermediate result of the trial that is early stopped by assessor is sent to tuner as final result.

assessor

Specifies the assessor algorithm to run an experiment. Similar to tuners, there are two kinds of ways to set assessor. One way is to use assessor provided by NNI sdk. Users need to set builtinAssessorName and classArgs. Another way is to use users’ own assessor file, and users need to set codeDirectory, classFileName, className and classArgs. Users must choose exactly one way.

By default, there is no assessor enabled.

builtinAssessorName

Required if using built-in assessors. String.

Specifies the name of built-in assessor, NNI sdk provides different assessors introduced here.

codeDir

Required if using customized assessors. Path relative to the location of config file.

Specifies the directory of assessor code.

classFileName

Required if using customized assessors. File path relative to codeDir.

Specifies the name of assessor file.

className

Required if using customized assessors. String.

Specifies the name of assessor class.

classArgs

Optional. Key-value pairs. Default: empty.

Specifies the arguments of assessor algorithm.

advisor

Optional.

Specifies the advisor algorithm in the experiment. Similar to tuners and assessors, there are two kinds of ways to specify advisor. One way is to use advisor provided by NNI sdk, need to set builtinAdvisorName and classArgs. Another way is to use users’ own advisor file, and need to set codeDirectory, classFileName, className and classArgs.

When advisor is enabled, settings of tuners and advisors will be bypassed.

builtinAdvisorName

Specifies the name of a built-in advisor. NNI sdk provides BOHB and Hyperband.

codeDir

Required if using customized advisors. Path relative to the location of config file.

Specifies the directory of advisor code.

classFileName

Required if using customized advisors. File path relative to codeDir.

Specifies the name of advisor file.

className

Required if using customized advisors. String.

Specifies the name of advisor class.

classArgs

Optional. Key-value pairs. Default: empty.

Specifies the arguments of advisor.

gpuIndices

Optional. String. Default: empty.

Specifies the GPUs that can be used. Single or multiple GPU indices can be specified. Multiple GPU indices are separated by comma ,. For example, 1, or 0,1,3. If the field is not set, no GPU will be visible to tuner (by setting CUDA_VISIBLE_DEVICES to be an empty string).

trial

Required. Key-value pairs.

In local and remote mode, the following keys are required.

  • command: Required string. Specifies the command to run trial process.

  • codeDir: Required string. Specifies the directory of your own trial file. This directory will be automatically uploaded in remote mode.

  • gpuNum: Optional integer. Specifies the num of gpu to run the trial process. Default value is 0.

In PAI mode, the following keys are required.

  • command: Required string. Specifies the command to run trial process.

  • codeDir: Required string. Specifies the directory of the own trial file. Files in the directory will be uploaded in PAI mode.

  • gpuNum: Required integer. Specifies the num of gpu to run the trial process. Default value is 0.

  • cpuNum: Required integer. Specifies the cpu number of cpu to be used in pai container.

  • memoryMB: Required integer. Set the memory size to be used in pai container, in megabytes.

  • image: Required string. Set the image to be used in pai.

  • authFile: Optional string. Used to provide Docker registry which needs authentication for image pull in PAI. Reference.

  • shmMB: Optional integer. Shared memory size of container.

  • portList: List of key-values pairs with label, beginAt, portNumber. See job tutorial of PAI for details.

In Kubeflow mode, the following keys are required.

  • codeDir: The local directory where the code files are in.

  • ps: An optional configuration for kubeflow’s tensorflow-operator, which includes

    • replicas: The replica number of ps role.

    • command: The run script in ps‘s container.

    • gpuNum: The gpu number to be used in ps container.

    • cpuNum: The cpu number to be used in ps container.

    • memoryMB: The memory size of the container.

    • image: The image to be used in ps.

  • worker: An optional configuration for kubeflow’s tensorflow-operator.

    • replicas: The replica number of worker role.

    • command: The run script in worker‘s container.

    • gpuNum: The gpu number to be used in worker container.

    • cpuNum: The cpu number to be used in worker container.

    • memoryMB: The memory size of the container.

    • image: The image to be used in worker.

localConfig

Optional in local mode. Key-value pairs.

Only applicable if trainingServicePlatform is set to local, otherwise there should not be localConfig section in configuration file.

gpuIndices

Optional. String. Default: none.

Used to specify designated GPU devices for NNI, if it is set, only the specified GPU devices are used for NNI trial jobs. Single or multiple GPU indices can be specified. Multiple GPU indices should be separated with comma (,), such as 1 or 0,1,3. By default, all GPUs available will be used.

maxTrialNumPerGpu

Optional. Integer. Default: 1.

Used to specify the max concurrency trial number on a GPU device.

useActiveGpu

Optional. Bool. Default: false.

Used to specify whether to use a GPU if there is another process. By default, NNI will use the GPU only if there is no other active process in the GPU. If useActiveGpu is set to true, NNI will use the GPU regardless of another processes. This field is not applicable for NNI on Windows.

machineList

Required in remote mode. A list of key-value pairs with the following keys.

ip

Required. IP address or host name that is accessible from the current machine.

The IP address or host name of remote machine.

port

Optional. Integer. Valid port. Default: 22.

The ssh port to be used to connect machine.

username

Required if authentication with username/password. String.

The account of remote machine.

passwd

Required if authentication with username/password. String.

Specifies the password of the account.

sshKeyPath

Required if authentication with ssh key. Path to private key file.

If users use ssh key to login remote machine, sshKeyPath should be a valid path to a ssh key file.

Note: if users set passwd and sshKeyPath simultaneously, NNI will try passwd first.

passphrase

Optional. String.

Used to protect ssh key, which could be empty if users don’t have passphrase.

gpuIndices

Optional. String. Default: none.

Used to specify designated GPU devices for NNI, if it is set, only the specified GPU devices are used for NNI trial jobs. Single or multiple GPU indices can be specified. Multiple GPU indices should be separated with comma (,), such as 1 or 0,1,3. By default, all GPUs available will be used.

maxTrialNumPerGpu

Optional. Integer. Default: 1.

Used to specify the max concurrency trial number on a GPU device.

useActiveGpu

Optional. Bool. Default: false.

Used to specify whether to use a GPU if there is another process. By default, NNI will use the GPU only if there is no other active process in the GPU. If useActiveGpu is set to true, NNI will use the GPU regardless of another processes. This field is not applicable for NNI on Windows.

pythonPath

Optional. String.

Users can configure the python path environment on remote machine by setting pythonPath.

remoteConfig

Optional field in remote mode. Users could set per machine information in machineList field, and set global configuration for remote mode in this field.

reuse

Optional. Bool. default: false. It’s an experimental feature.

If it’s true, NNI will reuse remote jobs to run as many as possible trials. It can save time of creating new jobs. User needs to make sure each trial can run independent in same job, for example, avoid loading checkpoint from previous trials.

kubeflowConfig
operator

Required. String. Has to be tf-operator or pytorch-operator.

Specifies the kubeflow’s operator to be used, NNI support tf-operator in current version.

storage

Optional. String. Default. nfs.

Specifies the storage type of kubeflow, including nfs and azureStorage.

nfs

Required if using nfs. Key-value pairs.

  • server is the host of nfs server.

  • path is the mounted path of nfs.

keyVault

Required if using azure storage. Key-value pairs.

Set keyVault to storage the private key of your azure storage account. Refer to the doc .

  • vaultName is the value of --vault-name used in az command.

  • name is the value of --name used in az command.

azureStorage

Required if using azure storage. Key-value pairs.

Set azure storage account to store code files.

  • accountName is the name of azure storage account.

  • azureShare is the share of the azure file storage.

uploadRetryCount

Required if using azure storage. Integer between 1 and 99999.

If upload files to azure storage failed, NNI will retry the process of uploading, this field will specify the number of attempts to re-upload files.

paiConfig
userName

Required. String.

The user name of your pai account.

password

Required if using password authentication. String.

The password of the pai account.

token

Required if using token authentication. String.

Personal access token that can be retrieved from PAI portal.

host

Required. String.

The hostname of IP address of PAI.

reuse

Optional. Bool. default: false. It’s an experimental feature.

If it’s true, NNI will reuse OpenPAI jobs to run as many as possible trials. It can save time of creating new jobs. User needs to make sure each trial can run independent in same job, for example, avoid loading checkpoint from previous trials.

sharedStorage
storageType

Required. String.

The type of the storage, support NFS and AzureBlob.

localMountPoint

Required. String.

The absolute or relative path that the storage has been or will be mounted in local. If the path does not exist, it will be created automatically. Recommended to use an absolute path. i.e. /tmp/nni-shared-storage.

remoteMountPoint

Required. String.

The absolute or relative path that the storage will be mounted in remote. If the path does not exist, it will be created automatically. Note that the directory must be empty if using AzureBlob. Recommended to use a relative path. i.e. ./nni-shared-storage.

localMounted

Required. String.

One of usermount, nnimount or nomount. usermount means you have already mount this storage on localMountPoint. nnimount means nni will try to mount this storage on localMountPoint. nomount means storage will not mount in local machine, will support partial storages in the future.

nfsServer

Optional. String.

Required if using NFS storage. The NFS server host.

exportedDirectory

Optional. String.

Required if using NFS storage. The exported directory of NFS server.

storageAccountName

Optional. String.

Required if using AzureBlob storage. The azure storage account name.

storageAccountKey

Optional. String.

Required if using AzureBlob storage and resourceGroupName not set. The azure storage account key.

resourceGroupName

Optional. String.

Required if using AzureBlob storage and storageAccountKey not set. The resource group that AzureBlob container belongs to.

containerName

Optional. String.

Required if using AzureBlob storage. The AzureBlob container name.

Examples

Local mode

If users want to run trial jobs in local machine, and use annotation to generate search space, could use the following config:

authorName: test
experimentName: test_experiment
trialConcurrency: 3
maxExecDuration: 1h
maxTrialNum: 10
#choice: local, remote, pai, kubeflow
trainingServicePlatform: local
#choice: true, false
useAnnotation: true
tuner:
  #choice: TPE, Random, Anneal, Evolution
  builtinTunerName: TPE
  classArgs:
    #choice: maximize, minimize
    optimize_mode: maximize
trial:
  command: python3 mnist.py
  codeDir: /nni/mnist
  gpuNum: 0

You can add assessor configuration.

authorName: test
experimentName: test_experiment
trialConcurrency: 3
maxExecDuration: 1h
maxTrialNum: 10
#choice: local, remote, pai, kubeflow
trainingServicePlatform: local
searchSpacePath: /nni/search_space.json
#choice: true, false
useAnnotation: false
tuner:
  #choice: TPE, Random, Anneal, Evolution
  builtinTunerName: TPE
  classArgs:
    #choice: maximize, minimize
    optimize_mode: maximize
assessor:
  #choice: Medianstop
  builtinAssessorName: Medianstop
  classArgs:
    #choice: maximize, minimize
    optimize_mode: maximize
trial:
  command: python3 mnist.py
  codeDir: /nni/mnist
  gpuNum: 0

Or you could specify your own tuner and assessor file as following,

authorName: test
experimentName: test_experiment
trialConcurrency: 3
maxExecDuration: 1h
maxTrialNum: 10
#choice: local, remote, pai, kubeflow
trainingServicePlatform: local
searchSpacePath: /nni/search_space.json
#choice: true, false
useAnnotation: false
tuner:
  codeDir: /nni/tuner
  classFileName: mytuner.py
  className: MyTuner
  classArgs:
    #choice: maximize, minimize
    optimize_mode: maximize
assessor:
  codeDir: /nni/assessor
  classFileName: myassessor.py
  className: MyAssessor
  classArgs:
    #choice: maximize, minimize
    optimize_mode: maximize
trial:
  command: python3 mnist.py
  codeDir: /nni/mnist
  gpuNum: 0
Remote mode

If run trial jobs in remote machine, users could specify the remote machine information as following format:

authorName: test
experimentName: test_experiment
trialConcurrency: 3
maxExecDuration: 1h
maxTrialNum: 10
#choice: local, remote, pai, kubeflow
trainingServicePlatform: remote
searchSpacePath: /nni/search_space.json
#choice: true, false
useAnnotation: false
tuner:
  #choice: TPE, Random, Anneal, Evolution
  builtinTunerName: TPE
  classArgs:
    #choice: maximize, minimize
    optimize_mode: maximize
trial:
  command: python3 mnist.py
  codeDir: /nni/mnist
  gpuNum: 0
#machineList can be empty if the platform is local
machineList:
  - ip: 10.10.10.10
    port: 22
    username: test
    passwd: test
  - ip: 10.10.10.11
    port: 22
    username: test
    passwd: test
  - ip: 10.10.10.12
    port: 22
    username: test
    sshKeyPath: /nni/sshkey
    passphrase: qwert
    # Below is an example of specifying python environment.
    pythonPath: ${replace_to_python_environment_path_in_your_remote_machine}
PAI mode
authorName: test
experimentName: nni_test1
trialConcurrency: 1
maxExecDuration:500h
maxTrialNum: 1
#choice: local, remote, pai, kubeflow
trainingServicePlatform: pai
searchSpacePath: search_space.json
#choice: true, false
useAnnotation: false
tuner:
  #choice: TPE, Random, Anneal, Evolution, BatchTuner
  #SMAC (SMAC should be installed through nnictl)
  builtinTunerName: TPE
  classArgs:
    #choice: maximize, minimize
    optimize_mode: maximize
trial:
  command: python3 main.py
  codeDir: .
  gpuNum: 4
  cpuNum: 2
  memoryMB: 10000
  #The docker image to run NNI job on pai
  image: msranni/nni:latest
paiConfig:
  #The username to login pai
  userName: test
  #The password to login pai
  passWord: test
  #The host of restful server of pai
  host: 10.10.10.10
Kubeflow mode

kubeflow with nfs storage.

authorName: default
experimentName: example_mni
trialConcurrency: 1
maxExecDuration: 1h
maxTrialNum: 1
#choice: local, remote, pai, kubeflow
trainingServicePlatform: kubeflow
searchSpacePath: search_space.json
#choice: true, false
useAnnotation: false
tuner:
  #choice: TPE, Random, Anneal, Evolution
  builtinTunerName: TPE
  classArgs:
    #choice: maximize, minimize
    optimize_mode: maximize
trial:
  codeDir: .
  worker:
    replicas: 1
    command: python3 mnist.py
    gpuNum: 0
    cpuNum: 1
    memoryMB: 8192
    image: msranni/nni:latest
kubeflowConfig:
  operator: tf-operator
  nfs:
    server: 10.10.10.10
    path: /var/nfs/general
Kubeflow with azure storage
authorName: default
experimentName: example_mni
trialConcurrency: 1
maxExecDuration: 1h
maxTrialNum: 1
#choice: local, remote, pai, kubeflow
trainingServicePlatform: kubeflow
searchSpacePath: search_space.json
#choice: true, false
useAnnotation: false
#nniManagerIp: 10.10.10.10
tuner:
  #choice: TPE, Random, Anneal, Evolution
  builtinTunerName: TPE
  classArgs:
    #choice: maximize, minimize
    optimize_mode: maximize
assessor:
  builtinAssessorName: Medianstop
  classArgs:
    optimize_mode: maximize
trial:
  codeDir: .
  worker:
    replicas: 1
    command: python3 mnist.py
    gpuNum: 0
    cpuNum: 1
    memoryMB: 4096
    image: msranni/nni:latest
kubeflowConfig:
  operator: tf-operator
  keyVault:
    vaultName: Contoso-Vault
    name: AzureStorageAccountKey
  azureStorage:
    accountName: storage
    azureShare: share01

Experiment Config Reference

Notes

  1. This document list field names is camelCase. They need to be converted to snake_case for Python library nni.experiment.

  2. In this document type of fields are formatted as Python type hint. Therefore JSON objects are called dict and arrays are called list.

  1. Some fields take a path to file or directory. Unless otherwise noted, both absolute path and relative path are supported, and ~ will be expanded to home directory.

    • When written in YAML file, relative paths are relative to the directory containing that file.

    • When assigned in Python code, relative paths are relative to current working directory.

    • All relative paths are converted to absolute when loading YAML file into Python class, and when saving Python class to YAML file.

  2. Setting a field to None or null is equivalent to not setting the field.

Examples

Local Mode
experimentName: MNIST
searchSpaceFile: search_space.json
trialCommand: python mnist.py
trialCodeDirectory: .
trialGpuNumber: 1
trialConcurrency: 2
maxExperimentDuration: 24h
maxTrialNumber: 100
tuner:
  name: TPE
  classArgs:
    optimize_mode: maximize
trainingService:
  platform: local
  useActiveGpu: True
Local Mode (Inline Search Space)
searchSpace:
  batch_size:
    _type: choice
    _value: [16, 32, 64]
  learning_rate:
    _type: loguniform
    _value: [0.0001, 0.1]
trialCommand: python mnist.py
trialGpuNumber: 1
trialConcurrency: 2
tuner:
  name: TPE
  classArgs:
    optimize_mode: maximize
trainingService:
  platform: local
  useActiveGpu: True
Remote Mode
experimentName: MNIST
searchSpaceFile: search_space.json
trialCommand: python mnist.py
trialCodeDirectory: .
trialGpuNumber: 1
trialConcurrency: 2
maxExperimentDuration: 24h
maxTrialNumber: 100
tuner:
  name: TPE
  classArgs:
    optimize_mode: maximize
trainingService:
  platform: remote
  machineList:
    - host: 11.22.33.44
      user: alice
      password: xxxxx
    - host: my.domain.com
      user: bob
      sshKeyFile: ~/.ssh/id_rsa

Reference

ExperimentConfig
experimentName

Mnemonic name of the experiment. This will be shown in web UI and nnictl.

type: Optional[str]

searchSpaceFile

Path to a JSON file containing the search space.

type: Optional[str]

Search space format is determined by tuner. Common format for built-in tuners is documeted here.

Mutually exclusive to searchSpace.

searchSpace

Search space object.

type: Optional[JSON]

The format is determined by tuner. Common format for built-in tuners is documented here.

Note that None means “no such field” so empty search space should be written as {}.

Mutually exclusive to searchSpaceFile.

trialCommand

Command to launch trial.

type: str

The command will be executed in bash on Linux and macOS, and in PowerShell on Windows.

trialCodeDirectory

Path to the directory containing trial source files.

type: str

default: "."

All files in this directory will be sent to training machine, unless there is a .nniignore file. (See nniignore section of quick start guide for details.)

trialConcurrency

Specify how many trials should be run concurrently.

type: int

The real concurrency also depends on hardware resources and may be less than this value.

trialGpuNumber

Number of GPUs used by each trial.

type: Optional[int]

This field might have slightly different meaning for various training services, especially when set to 0 or None. See training service’s document for details.

In local mode, setting the field to zero will prevent trials from accessing GPU (by empty CUDA_VISIBLE_DEVICES). And when set to None, trials will be created and scheduled as if they did not use GPU, but they can still use all GPU resources if they want.

maxExperimentDuration

Limit the duration of this experiment if specified.

type: Optional[str]

format: number + s|m|h|d

examples: "10m", "0.5h"

When time runs out, the experiment will stop creating trials but continue to serve web UI.

maxTrialNumber

Limit the number of trials to create if specified.

type: Optional[int]

When the budget runs out, the experiment will stop creating trials but continue to serve web UI.

nniManagerIp

IP of current machine, used by training machines to access NNI manager. Not used in local mode.

type: Optional[str]

If not specified, IPv4 address of eth0 will be used.

Must be set on Windows and systems using predictable network interface name, except for local mode.

useAnnotation

Enable annotation.

type: bool

default: False

When using annotation, searchSpace and searchSpaceFile should not be specified manually.

debug

Enable debug mode.

type: bool

default: False

When enabled, logging will be more verbose and some internal validation will be loosen.

logLevel

Set log level of whole system.

type: Optional[str]

values: "trace", "debug", "info", "warning", "error", "fatal"

Defaults to “info” or “debug”, depending on debug option.

Most modules of NNI will be affected by this value, including NNI manager, tuner, training service, etc.

The exception is trial, whose logging level is directly managed by trial code.

For Python modules, “trace” acts as logging level 0 and “fatal” acts as logging.CRITICAL.

experimentWorkingDirectory

Specify the directory to place log, checkpoint, metadata, and other run-time stuff.

type: Optional[str]

By default uses ~/nni-experiments.

NNI will create a subdirectory named by experiment ID, so it is safe to use same directory for multiple experiments.

tunerGpuIndices

Limit the GPUs visible to tuner, assessor, and advisor.

type: Optional[list[int] | str]

This will be the CUDA_VISIBLE_DEVICES environment variable of tuner process.

Because tuner, assessor, and advisor run in same process, this option will affect them all.

tuner

Specify the tuner.

type: Optional AlgorithmConfig

assessor

Specify the assessor.

type: Optional AlgorithmConfig

advisor

Specify the advisor.

type: Optional AlgorithmConfig

trainingService

Specify training service.

type: TrainingServiceConfig

AlgorithmConfig

AlgorithmConfig describes a tuner / assessor / advisor algorithm.

For custom algorithms, there are two ways to describe them:

  1. Register the algorithm to use it like built-in. (preferred)

  2. Specify code directory and class name directly.

name

Name of built-in or registered algorithm.

type: str for built-in and registered algorithm, None for other custom algorithm

className

Qualified class name of not registered custom algorithm.

type: None for built-in and registered algorithm, str for other custom algorithm

example: "my_tuner.MyTuner"

codeDirectory

Path to directory containing the custom algorithm class.

type: None for built-in and registered algorithm, str for other custom algorithm

classArgs

Keyword arguments passed to algorithm class’ constructor.

type: Optional[dict[str, Any]]

See algorithm’s document for supported value.

TrainingServiceConfig

One of following:

For other training services, we suggest to use v1 config schema for now.

LocalConfig

Detailed here.

platform

Constant string "local".

useActiveGpu

Specify whether NNI should submit trials to GPUs occupied by other tasks.

type: Optional[bool]

Must be set when trialGpuNumber greater than zero.

If your are using desktop system with GUI, set this to True.

maxTrialNumberPerGpu

Specify how many trials can share one GPU.

type: int

default: 1

gpuIndices

Limit the GPUs visible to trial processes.

type: Optional[list[int] | str]

If trialGpuNumber is less than the length of this value, only a subset will be visible to each trial.

This will be used as CUDA_VISIBLE_DEVICES environment variable.

RemoteConfig

Detailed here.

platform

Constant string "remote".

machineList

List of training machines.

type: list of RemoteMachineConfig

reuseMode

Enable reuse mode.

type: bool

RemoteMachineConfig
host

IP or hostname (domain name) of the machine.

type: str

port

SSH service port.

type: int

default: 22

user

Login user name.

type: str

password

Login password.

type: Optional[str]

If not specified, sshKeyFile will be used instead.

sshKeyFile

Path to sshKeyFile (identity file).

type: Optional[str]

Only used when password is not specified.

sshPassphrase

Passphrase of SSH identity file.

type: Optional[str]

useActiveGpu

Specify whether NNI should submit trials to GPUs occupied by other tasks.

type: bool

default: False

maxTrialNumberPerGpu

Specify how many trials can share one GPU.

type: int

default: 1

gpuIndices

Limit the GPUs visible to trial processes.

type: Optional[list[int] | str]

If trialGpuNumber is less than the length of this value, only a subset will be visible to each trial.

This will be used as CUDA_VISIBLE_DEVICES environment variable.

pythonPath
Specify a python environment, this path will insert at the front of PATH. Here are some examples:
  • (linux) pythonPath: /opt/python3.7/bin

  • (windows) pythonPath: C:/Python37

Notice: If you are working on anaconda,there are some difference. You have to add “../script” and “../Library/bin” to this and separated by “;” on windows, example as below:
  • (linux anaconda) pythonPath: /home/yourname/anaconda3/envs/myenv/bin/

  • (windows anaconda) pythonPath: C:/Users/yourname/.conda/envs/myenv;C:/Users/yourname/.conda/envs/myenv/Scripts;C:/Users/yourname/.conda/envs/myenv/Library/bin

type: Optional[str]

This is useful if preparing steps vary for different machines.

OpenpaiConfig

Detailed here.

platform

Constant string "openpai".

host

Hostname of OpenPAI service.

type: str

This may includes https:// or http:// prefix.

HTTPS will be used by default.

username

OpenPAI user name.

type: str

token

OpenPAI user token.

type: str

This can be found in your OpenPAI user settings page.

dockerImage

Name and tag of docker image to run the trials.

type: str

default: "msranni/nni:latest"

nniManagerStorageMountPoint

Mount point of storage service (typically NFS) on current machine.

type: str

containerStorageMountPoint

Mount point of storage service (typically NFS) in docker container.

type: str

This must be an absolute path.

reuseMode

Enable reuse mode.

type: bool

default: False

openpaiConfig

Embedded OpenPAI config file.

type: Optional[JSON]

openpaiConfigFile

Path to OpenPAI config file.

type: Optional[str]

An example can be found here

AmlConfig

Detailed here.

platform

Constant string "aml".

dockerImage

Name and tag of docker image to run the trials.

type: str

default: "msranni/nni:latest"

subscriptionId

Azure subscription ID.

type: str

resourceGroup

Azure resource group name.

type: str

workspaceName

Azure workspace name.

type: str

computeTarget

AML compute cluster name.

type: str

Search Space

Overview

In NNI, tuner will sample parameters/architecture according to the search space, which is defined as a json file.

To define a search space, users should define the name of the variable, the type of sampling strategy and its parameters.

  • An example of a search space definition is as follow:

{
    "dropout_rate": {"_type": "uniform", "_value": [0.1, 0.5]},
    "conv_size": {"_type": "choice", "_value": [2, 3, 5, 7]},
    "hidden_size": {"_type": "choice", "_value": [124, 512, 1024]},
    "batch_size": {"_type": "choice", "_value": [50, 250, 500]},
    "learning_rate": {"_type": "uniform", "_value": [0.0001, 0.1]}
}

Take the first line as an example. dropout_rate is defined as a variable whose priori distribution is a uniform distribution with a range from 0.1 to 0.5.

Note that the available sampling strategies within a search space depend on the tuner you want to use. We list the supported types for each builtin tuner below. For a customized tuner, you don’t have to follow our convention and you will have the flexibility to define any type you want.

Types

All types of sampling strategies and their parameter are listed here:

  • {"_type": "choice", "_value": options}

    • The variable’s value is one of the options. Here options should be a list of numbers or a list of strings. Using arbitrary objects as members of this list (like sublists, a mixture of numbers and strings, or null values) should work in most cases, but may trigger undefined behaviors.

    • options can also be a nested sub-search-space, this sub-search-space takes effect only when the corresponding element is chosen. The variables in this sub-search-space can be seen as conditional variables. Here is an simple example of nested search space definition. If an element in the options list is a dict, it is a sub-search-space, and for our built-in tuners you have to add a _name key in this dict, which helps you to identify which element is chosen. Accordingly, here is a sample which users can get from nni with nested search space definition. See the table below for the tuners which support nested search spaces.

  • {"_type": "randint", "_value": [lower, upper]}

    • Choosing a random integer between lower (inclusive) and upper (exclusive).

    • Note: Different tuners may interpret randint differently. Some (e.g., TPE, GridSearch) treat integers from lower to upper as unordered ones, while others respect the ordering (e.g., SMAC). If you want all the tuners to respect the ordering, please use quniform with q=1.

  • {"_type": "uniform", "_value": [low, high]}

    • The variable value is uniformly sampled between low and high.

    • When optimizing, this variable is constrained to a two-sided interval.

  • {"_type": "quniform", "_value": [low, high, q]}

    • The variable value is determined using clip(round(uniform(low, high) / q) * q, low, high), where the clip operation is used to constrain the generated value within the bounds. For example, for _value specified as [0, 10, 2.5], possible values are [0, 2.5, 5.0, 7.5, 10.0]; For _value specified as [2, 10, 5], possible values are [2, 5, 10].

    • Suitable for a discrete value with respect to which the objective is still somewhat “smooth”, but which should be bounded both above and below. If you want to uniformly choose an integer from a range [low, high], you can write _value like this: [low, high, 1].

  • {"_type": "loguniform", "_value": [low, high]}

    • The variable value is drawn from a range [low, high] according to a loguniform distribution like exp(uniform(log(low), log(high))), so that the logarithm of the return value is uniformly distributed.

    • When optimizing, this variable is constrained to be positive.

  • {"_type": "qloguniform", "_value": [low, high, q]}

    • The variable value is determined using clip(round(loguniform(low, high) / q) * q, low, high), where the clip operation is used to constrain the generated value within the bounds.

    • Suitable for a discrete variable with respect to which the objective is “smooth” and gets smoother with the size of the value, but which should be bounded both above and below.

  • {"_type": "normal", "_value": [mu, sigma]}

    • The variable value is a real value that’s normally-distributed with mean mu and standard deviation sigma. When optimizing, this is an unconstrained variable.

  • {"_type": "qnormal", "_value": [mu, sigma, q]}

    • The variable value is determined using round(normal(mu, sigma) / q) * q

    • Suitable for a discrete variable that probably takes a value around mu, but is fundamentally unbounded.

  • {"_type": "lognormal", "_value": [mu, sigma]}

    • The variable value is drawn according to exp(normal(mu, sigma)) so that the logarithm of the return value is normally distributed. When optimizing, this variable is constrained to be positive.

  • {"_type": "qlognormal", "_value": [mu, sigma, q]}

    • The variable value is determined using round(exp(normal(mu, sigma)) / q) * q

    • Suitable for a discrete variable with respect to which the objective is smooth and gets smoother with the size of the variable, which is bounded from one side.

Search Space Types Supported by Each Tuner

choice

choice(nested)

randint

uniform

quniform

loguniform

qloguniform

normal

qnormal

lognormal

qlognormal

TPE Tuner

Random Search Tuner

Anneal Tuner

Evolution Tuner

SMAC Tuner

Batch Tuner

Grid Search Tuner

Hyperband Advisor

Metis Tuner

GP Tuner

Known Limitations:

  • GP Tuner and Metis Tuner support only numerical values in search space (choice type values can be no-numerical with other tuners, e.g. string values). Both GP Tuner and Metis Tuner use Gaussian Process Regressor(GPR). GPR make predictions based on a kernel function and the ‘distance’ between different points, it’s hard to get the true distance between no-numerical values.

  • Note that for nested search space:

    • Only Random Search/TPE/Anneal/Evolution/Grid Search tuner supports nested search space

NNI Annotation

Overview

To improve user experience and reduce user effort, we design an annotation grammar. Using NNI annotation, users can adapt their code to NNI just by adding some standalone annotating strings, which does not affect the execution of the original code.

Below is an example:

'''@nni.variable(nni.choice(0.1, 0.01, 0.001), name=learning_rate)'''
learning_rate = 0.1

The meaning of this example is that NNI will choose one of several values (0.1, 0.01, 0.001) to assign to the learning_rate variable. Specifically, this first line is an NNI annotation, which is a single string. Following is an assignment statement. What nni does here is to replace the right value of this assignment statement according to the information provided by the annotation line.

In this way, users could either run the python code directly or launch NNI to tune hyper-parameter in this code, without changing any codes.

Types of Annotation:

In NNI, there are mainly four types of annotation:

1. Annotate variables

'''@nni.variable(sampling_algo, name)'''

@nni.variable is used in NNI to annotate a variable.

Arguments

  • sampling_algo: Sampling algorithm that specifies a search space. User should replace it with a built-in NNI sampling function whose name consists of an nni. identification and a search space type specified in SearchSpaceSpec such as choice or uniform.

  • name: The name of the variable that the selected value will be assigned to. Note that this argument should be the same as the left value of the following assignment statement.

There are 10 types to express your search space as follows:

  • @nni.variable(nni.choice(option1,option2,...,optionN),name=variable) Which means the variable value is one of the options, which should be a list The elements of options can themselves be stochastic expressions

  • @nni.variable(nni.randint(lower, upper),name=variable) Which means the variable value is a value like round(uniform(low, high)). For now, the type of chosen value is float. If you want to use integer value, please convert it explicitly.

  • @nni.variable(nni.uniform(low, high),name=variable) Which means the variable value is a value uniformly between low and high.

  • @nni.variable(nni.quniform(low, high, q),name=variable) Which means the variable value is a value like clip(round(uniform(low, high) / q) * q, low, high), where the clip operation is used to constraint the generated value in the bound.

  • @nni.variable(nni.loguniform(low, high),name=variable) Which means the variable value is a value drawn according to exp(uniform(low, high)) so that the logarithm of the return value is uniformly distributed.

  • @nni.variable(nni.qloguniform(low, high, q),name=variable) Which means the variable value is a value like clip(round(loguniform(low, high) / q) * q, low, high), where the clip operation is used to constraint the generated value in the bound.

  • @nni.variable(nni.normal(mu, sigma),name=variable) Which means the variable value is a real value that’s normally-distributed with mean mu and standard deviation sigma.

  • @nni.variable(nni.qnormal(mu, sigma, q),name=variable) Which means the variable value is a value like round(normal(mu, sigma) / q) * q

  • @nni.variable(nni.lognormal(mu, sigma),name=variable) Which means the variable value is a value drawn according to exp(normal(mu, sigma))

  • @nni.variable(nni.qlognormal(mu, sigma, q),name=variable) Which means the variable value is a value like round(exp(normal(mu, sigma)) / q) * q

Below is an example:

'''@nni.variable(nni.choice(0.1, 0.01, 0.001), name=learning_rate)'''
learning_rate = 0.1
2. Annotate functions

'''@nni.function_choice(*functions, name)'''

@nni.function_choice is used to choose one from several functions.

Arguments

  • functions: Several functions that are waiting to be selected from. Note that it should be a complete function call with arguments. Such as max_pool(hidden_layer, pool_size).

  • name: The name of the function that will be replaced in the following assignment statement.

An example here is:

"""@nni.function_choice(max_pool(hidden_layer, pool_size), avg_pool(hidden_layer, pool_size), name=max_pool)"""
h_pooling = max_pool(hidden_layer, pool_size)
3. Annotate intermediate result

'''@nni.report_intermediate_result(metrics)'''

@nni.report_intermediate_result is used to report intermediate result, whose usage is the same as nni.report_intermediate_result in the doc of Write a trial run on NNI

4. Annotate final result

'''@nni.report_final_result(metrics)'''

@nni.report_final_result is used to report the final result of the current trial, whose usage is the same as nni.report_final_result in the doc of Write a trial run on NNI

Python API Reference

Python API Reference of Auto Tune

Trial
nni.get_next_parameter()[source]

Get the hyper paremeters generated by tuner. For a multiphase experiment, it returns a new group of hyper parameters at each call of get_next_parameter. For a non-multiphase (multiPhase is not configured or set to False) experiment, it returns hyper parameters only on the first call for each trial job, it returns None since second call. This API should be called only once in each trial job of an experiment which is not specified as multiphase.

Returns

A dict object contains the hyper parameters generated by tuner, the keys of the dict are defined in search space. Returns None if no more hyper parameters can be generated by tuner.

Return type

dict

nni.get_current_parameter(tag=None)[source]

Get current hyper parameters generated by tuner. It returns the same group of hyper parameters as the last call of get_next_parameter returns.

Parameters

tag (str) – hyper parameter key

nni.report_intermediate_result(metric)[source]

Reports intermediate result to NNI.

Parameters

metric – serializable object.

nni.report_final_result(metric)[source]

Reports final result to NNI.

Parameters

metric (serializable object) – Usually (for built-in tuners to work), it should be a number, or a dict with key “default” (a number), and any other extra keys.

nni.get_experiment_id()[source]

Get experiment ID.

Returns

Identifier of current experiment

Return type

str

nni.get_trial_id()[source]

Get trial job ID which is string identifier of a trial job, for example ‘MoXrp’. In one experiment, each trial job has an unique string ID.

Returns

Identifier of current trial job which is calling this API.

Return type

str

nni.get_sequence_id()[source]

Get trial job sequence nubmer. A sequence number is an integer value assigned to each trial job base on the order they are submitted, incremental starting from 0. In one experiment, both trial job ID and sequence number are unique for each trial job, they are of different data types.

Returns

Sequence number of current trial job which is calling this API.

Return type

int

Tuner
class nni.tuner.Tuner[source]

Tuner is an AutoML algorithm, which generates a new configuration for the next try. A new trial will run with this configuration.

This is the abstract base class for all tuners. Tuning algorithms should inherit this class and override update_search_space(), receive_trial_result(), as well as generate_parameters() or generate_multiple_parameters().

After initializing, NNI will first call update_search_space() to tell tuner the feasible region, and then call generate_parameters() one or more times to request for hyper-parameter configurations.

The framework will train several models with given configuration. When one of them is finished, the final accuracy will be reported to receive_trial_result(). And then another configuration will be reqeusted and trained, util the whole experiment finish.

If a tuner want’s to know when a trial ends, it can also override trial_end().

Tuners use parameter ID to track trials. In tuner context, there is a one-to-one mapping between parameter ID and trial. When the framework ask tuner to generate hyper-parameters for a new trial, an ID has already been assigned and can be recorded in generate_parameters(). Later when the trial ends, the ID will be reported to trial_end(), and receive_trial_result() if it has a final result. Parameter IDs are unique integers.

The type/format of search space and hyper-parameters are not limited, as long as they are JSON-serializable and in sync with trial code. For HPO tuners, however, there is a widely shared common interface, which supports choice, randint, uniform, and so on. See docs/en_US/Tutorial/SearchSpaceSpec.md for details of this interface.

[WIP] For advanced tuners which take advantage of trials’ intermediate results, an Advisor interface is under development.

See also

Builtin, HyperoptTuner, EvolutionTuner, SMACTuner, GridSearchTuner, NetworkMorphismTuner, MetisTuner, PPOTuner, GPTuner

generate_multiple_parameters(parameter_id_list, **kwargs)[source]

Callback method which provides multiple sets of hyper-parameters.

This method will get called when the framework is about to launch one or more new trials.

If user does not override this method, it will invoke generate_parameters() on each parameter ID.

See generate_parameters() for details.

User code must override either this method or generate_parameters().

Parameters
  • parameter_id_list (list of int) – Unique identifiers for each set of requested hyper-parameters. These will later be used in receive_trial_result().

  • **kwargs – Unstable parameters which should be ignored by normal users.

Returns

List of hyper-parameters. An empty list indicates there are no more trials.

Return type

list

generate_parameters(parameter_id, **kwargs)[source]

Abstract method which provides a set of hyper-parameters.

This method will get called when the framework is about to launch a new trial, if user does not override generate_multiple_parameters().

The return value of this method will be received by trials via nni.get_next_parameter(). It should fit in the search space, though the framework will not verify this.

User code must override either this method or generate_multiple_parameters().

Parameters
  • parameter_id (int) – Unique identifier for requested hyper-parameters. This will later be used in receive_trial_result().

  • **kwargs – Unstable parameters which should be ignored by normal users.

Returns

The hyper-parameters, a dict in most cases, but could be any JSON-serializable type when needed.

Return type

any

Raises

nni.NoMoreTrialError – If the search space is fully explored, tuner can raise this exception.

import_data(data)[source]

Internal API under revising, not recommended for end users.

load_checkpoint()[source]

Internal API under revising, not recommended for end users.

receive_trial_result(parameter_id, parameters, value, **kwargs)[source]

Abstract method invoked when a trial reports its final result. Must override.

This method only listens to results of algorithm-generated hyper-parameters. Currently customized trials added from web UI will not report result to this method.

Parameters
save_checkpoint()[source]

Internal API under revising, not recommended for end users.

trial_end(parameter_id, success, **kwargs)[source]

Abstract method invoked when a trial is completed or terminated. Do nothing by default.

Parameters
  • parameter_id (int) – Unique identifier for hyper-parameters used by this trial.

  • success (bool) – True if the trial successfully completed; False if failed or terminated.

  • **kwargs – Unstable parameters which should be ignored by normal users.

update_search_space(search_space)[source]

Abstract method for updating the search space. Must override.

Tuners are advised to support updating search space at run-time. If a tuner can only set search space once before generating first hyper-parameters, it should explicitly document this behaviour.

Parameters

search_space – JSON object defined by experiment owner.

class nni.algorithms.hpo.hyperopt_tuner.HyperoptTuner(algorithm_name, optimize_mode='minimize', parallel_optimize=False, constant_liar_type='min')[source]

HyperoptTuner is a tuner which using hyperopt algorithm.

generate_parameters(parameter_id, **kwargs)[source]

Returns a set of trial (hyper-)parameters, as a serializable object.

Parameters

parameter_id (int) –

Returns

params

Return type

dict

get_suggestion(random_search=False)[source]

get suggestion from hyperopt

Parameters

random_search (bool) – flag to indicate random search or not (default: {False})

Returns

total_params – parameter suggestion

Return type

dict

import_data(data)[source]

Import additional data for tuning

Parameters

data – a list of dictionarys, each of which has at least two keys, ‘parameter’ and ‘value’

miscs_update_idxs_vals(miscs, idxs, vals, assert_all_vals_used=True, idxs_map=None)[source]

Unpack the idxs-vals format into the list of dictionaries that is misc.

Parameters
  • idxs_map (dict) – idxs_map is a dictionary of id->id mappings so that the misc[‘idxs’] can

  • different numbers than the idxs argument. (contain) –

receive_trial_result(parameter_id, parameters, value, **kwargs)[source]

Record an observation of the objective function

Parameters
  • parameter_id (int) –

  • parameters (dict) –

  • value (dict/float) – if value is dict, it should have “default” key. value is final metrics of the trial.

update_search_space(search_space)[source]

Update search space definition in tuner by search_space in parameters.

Will called when first setup experiemnt or update search space in WebUI.

Parameters

search_space (dict) –

class nni.algorithms.hpo.evolution_tuner.EvolutionTuner(optimize_mode='maximize', population_size=32)[source]

EvolutionTuner is tuner using navie evolution algorithm.

generate_multiple_parameters(parameter_id_list, **kwargs)[source]

Returns multiple sets of trial (hyper-)parameters, as iterable of serializable objects. :param parameter_id_list: Unique identifiers for each set of requested hyper-parameters. :type parameter_id_list: list of int :param **kwargs: Not used

Returns

A list of newly generated configurations

Return type

list

generate_parameters(parameter_id, **kwargs)[source]

This function will returns a dict of trial (hyper-)parameters. If no trial configration for now, self.credit plus 1 to send the config later

Parameters

parameter_id (int) –

Returns

One newly generated configuration.

Return type

dict

import_data(data)[source]

Internal API under revising, not recommended for end users.

receive_trial_result(parameter_id, parameters, value, **kwargs)[source]

Record the result from a trial

Parameters
  • parameter_id (int) –

  • parameters (dict) –

  • value (dict/float) – if value is dict, it should have “default” key. value is final metrics of the trial.

trial_end(parameter_id, success, **kwargs)[source]

To deal with trial failure. If a trial fails, random generate the parameters and add into the population. :param parameter_id: Unique identifier for hyper-parameters used by this trial. :type parameter_id: int :param success: True if the trial successfully completed; False if failed or terminated. :type success: bool :param **kwargs: Not used

update_search_space(search_space)[source]

Update search space.

Search_space contains the information that user pre-defined.

Parameters

search_space (dict) –

class nni.algorithms.hpo.gridsearch_tuner.GridSearchTuner[source]

GridSearchTuner will search all the possible configures that the user define in the searchSpace. The only acceptable types of search space are choice, quniform, randint

Type choice will select one of the options. Note that it can also be nested.

Type quniform will receive three values [low, high, q], where [low, high] specifies a range and q specifies the interval. It will be sampled in a way that the first sampled value is low, and each of the following values is ‘interval’ larger than the value in front of it.

Type randint gives all possible intergers in range[low, high). Note that high is not included.

generate_parameters(parameter_id, **kwargs)[source]

Generate parameters for one trial.

Parameters
  • parameter_id (int) – The id for the generated hyperparameter

  • **kwargs – Not used

Returns

One configuration from the expanded search space.

Return type

dict

Raises

NoMoreTrialError – If all the configurations has been sent, raise NoMoreTrialError.

import_data(data)[source]

Import additional data for tuning

Parameters

list – A list of dictionarys, each of which has at least two keys, parameter and value

receive_trial_result(parameter_id, parameters, value, **kwargs)[source]

Receive a trial’s final performance result reported through report_final_result() by the trial. GridSearchTuner does not need trial’s results.

update_search_space(search_space)[source]

Check if the search space is valid and expand it: support only choice, quniform, randint.

Parameters

search_space (dict) – The format could be referred to search space spec (https://nni.readthedocs.io/en/latest/Tutorial/SearchSpaceSpec.html).

class nni.algorithms.hpo.networkmorphism_tuner.NetworkMorphismTuner(task='cv', input_width=32, input_channel=3, n_output_node=10, algorithm_name='Bayesian', optimize_mode='maximize', path='model_path', verbose=True, beta=2.576, t_min=0.0001, max_model_size=16777216, default_model_len=3, default_model_width=64)[source]

NetworkMorphismTuner is a tuner which using network morphism techniques.

n_classes

The class number or output node number (default: 10)

Type

int

input_shape

A tuple including: (input_width, input_width, input_channel)

Type

tuple

t_min

The minimum temperature for simulated annealing. (default: Constant.T_MIN)

Type

float

beta

The beta in acquisition function. (default: Constant.BETA)

Type

float

algorithm_name

algorithm name used in the network morphism (default: "Bayesian")

Type

str

optimize_mode

optimize mode “minimize” or “maximize” (default: "minimize")

Type

str

verbose

verbose to print the log (default: True)

Type

bool

bo

The optimizer used in networkmorphsim tuner.

Type

BayesianOptimizer

max_model_size

max model size to the graph (default: Constant.MAX_MODEL_SIZE)

Type

int

default_model_len

default model length (default: Constant.MODEL_LEN)

Type

int

default_model_width

default model width (default: Constant.MODEL_WIDTH)

Type

int

search_space
Type

dict

add_model(metric_value, model_id)[source]

Add model to the history, x_queue and y_queue

Parameters
  • metric_value (float) –

  • graph (dict) –

  • model_id (int) –

Returns

model

Return type

dict

generate()[source]

Generate the next neural architecture.

Returns

  • other_info (any object) – Anything to be saved in the training queue together with the architecture.

  • generated_graph (Graph) – An instance of Graph.

generate_parameters(parameter_id, **kwargs)[source]

Returns a set of trial neural architecture, as a serializable object.

Parameters

parameter_id (int) –

get_best_model_id()[source]

Get the best model_id from history using the metric value

get_metric_value_by_id(model_id)[source]

Get the model metric valud by its model_id

Parameters

model_id (int) – model index

Returns

the model metric

Return type

float

import_data(data)[source]

Internal API under revising, not recommended for end users.

Call the generators to generate the initial architectures for the search.

load_best_model()[source]

Get the best model by model id

Returns

load_model – the model graph representation

Return type

Graph

load_model_by_id(model_id)[source]

Get the model by model_id

Parameters

model_id (int) – model index

Returns

load_model – the model graph representation

Return type

Graph

receive_trial_result(parameter_id, parameters, value, **kwargs)[source]

Record an observation of the objective function.

Parameters
  • parameter_id (int) – the id of a group of paramters that generated by nni manager.

  • parameters (dict) – A group of parameters.

  • value (dict/float) – if value is dict, it should have “default” key.

update(other_info, graph, metric_value, model_id)[source]

Update the controller with evaluation result of a neural architecture.

Parameters
  • other_info (any object) – In our case it is the father ID in the search tree.

  • graph (Graph) – An instance of Graph. The trained neural architecture.

  • metric_value (float) – The final evaluated metric value.

  • model_id (int) –

update_search_space(search_space)[source]

Update search space definition in tuner by search_space in neural architecture.

class nni.algorithms.hpo.metis_tuner.MetisTuner(optimize_mode='maximize', no_resampling=True, no_candidates=False, selection_num_starting_points=600, cold_start_num=10, exploration_probability=0.9)[source]

Metis Tuner

More algorithm information you could reference here: https://www.microsoft.com/en-us/research/publication/metis-robustly-tuning-tail-latencies-cloud-systems/

optimize_mode

optimize_mode is a string that including two mode “maximize” and “minimize”

Type

str

no_resampling

True or False. Should Metis consider re-sampling as part of the search strategy? If you are confident that the training dataset is noise-free, then you do not need re-sampling.

Type

bool

no_candidates

True or False. Should Metis suggest parameters for the next benchmark? If you do not plan to do more benchmarks, Metis can skip this step.

Type

bool

selection_num_starting_points

How many times Metis should try to find the global optimal in the search space? The higher the number, the longer it takes to output the solution.

Type

int

cold_start_num

Metis need some trial result to get cold start. when the number of trial result is less than cold_start_num, Metis will randomly sample hyper-parameter for trial.

Type

int

exploration_probability

The probability of Metis to select parameter from exploration instead of exploitation.

Type

float

generate_parameters(parameter_id, **kwargs)[source]

Generate next parameter for trial

If the number of trial result is lower than cold start number, metis will first random generate some parameters. Otherwise, metis will choose the parameters by the Gussian Process Model and the Gussian Mixture Model.

Parameters

parameter_id (int) –

Returns

result

Return type

dict

import_data(data)[source]

Import additional data for tuning

Parameters

data (a list of dict) – each of which has at least two keys: ‘parameter’ and ‘value’.

receive_trial_result(parameter_id, parameters, value, **kwargs)[source]

Tuner receive result from trial.

Parameters
  • parameter_id (int) – The id of parameters, generated by nni manager.

  • parameters (dict) – A group of parameters that trial has tried.

  • value (dict/float) – if value is dict, it should have “default” key.

update_search_space(search_space)[source]

Update the self.x_bounds and self.x_types by the search_space.json

Parameters

search_space (dict) –

class nni.algorithms.hpo.batch_tuner.BatchTuner[source]

BatchTuner is tuner will running all the configure that user want to run batchly.

Examples

The search space only be accepted like:

{'combine_params':
    { '_type': 'choice',
                '_value': '[{...}, {...}, {...}]',
    }
}
generate_parameters(parameter_id, **kwargs)[source]

Returns a dict of trial (hyper-)parameters, as a serializable object.

Parameters

parameter_id (int) –

Returns

A candidate parameter group.

Return type

dict

import_data(data)[source]

Import additional data for tuning

Parameters

data – a list of dictionarys, each of which has at least two keys, ‘parameter’ and ‘value’

is_valid(search_space)[source]

Check the search space is valid: only contains ‘choice’ type

Parameters

search_space (dict) –

Returns

If valid, return candidate values; else return None.

Return type

None or list

receive_trial_result(parameter_id, parameters, value, **kwargs)[source]

Abstract method invoked when a trial reports its final result. Must override.

This method only listens to results of algorithm-generated hyper-parameters. Currently customized trials added from web UI will not report result to this method.

Parameters
update_search_space(search_space)[source]

Update the search space

Parameters

search_space (dict) –

class nni.algorithms.hpo.gp_tuner.GPTuner(optimize_mode='maximize', utility='ei', kappa=5, xi=0, nu=2.5, alpha=1e-06, cold_start_num=10, selection_num_warm_up=100000, selection_num_starting_points=250)[source]

GPTuner is a Bayesian Optimization method where Gaussian Process is used for modeling loss functions.

Parameters
  • optimize_mode (str) – optimize mode, ‘maximize’ or ‘minimize’, by default ‘maximize’

  • utility (str) – utility function (also called ‘acquisition funcition’) to use, which can be ‘ei’, ‘ucb’ or ‘poi’. By default ‘ei’.

  • kappa (float) – value used by utility function ‘ucb’. The bigger kappa is, the more the tuner will be exploratory. By default 5.

  • xi (float) – used by utility function ‘ei’ and ‘poi’. The bigger xi is, the more the tuner will be exploratory. By default 0.

  • nu (float) – used to specify Matern kernel. The smaller nu, the less smooth the approximated function is. By default 2.5.

  • alpha (float) – Used to specify Gaussian Process Regressor. Larger values correspond to increased noise level in the observations. By default 1e-6.

  • cold_start_num (int) – Number of random exploration to perform before Gaussian Process. By default 10.

  • selection_num_warm_up (int) – Number of random points to evaluate for getting the point which maximizes the acquisition function. By default 100000

  • selection_num_starting_points (int) – Number of times to run L-BFGS-B from a random starting point after the warmup. By default 250.

generate_parameters(parameter_id, **kwargs)[source]

Method which provides one set of hyper-parameters. If the number of trial result is lower than cold_start_number, GPTuner will first randomly generate some parameters. Otherwise, choose the parameters by the Gussian Process Model.

Override of the abstract method in Tuner.

import_data(data)[source]

Import additional data for tuning.

Override of the abstract method in Tuner.

receive_trial_result(parameter_id, parameters, value, **kwargs)[source]

Method invoked when a trial reports its final result.

Override of the abstract method in Tuner.

update_search_space(search_space)[source]

Update the self.bounds and self.types by the search_space.json file.

Override of the abstract method in Tuner.

Assessor
class nni.assessor.Assessor[source]

Assessor analyzes trial’s intermediate results (e.g., periodically evaluated accuracy on test dataset) to tell whether this trial can be early stopped or not.

This is the abstract base class for all assessors. Early stopping algorithms should inherit this class and override assess_trial() method, which receives intermediate results from trials and give an assessing result.

If assess_trial() returns AssessResult.Bad for a trial, it hints NNI framework that the trial is likely to result in a poor final accuracy, and therefore should be killed to save resource.

If an assessor want’s to be notified when a trial ends, it can also override trial_end().

To write a new assessor, you can reference MedianstopAssessor’s code as an example.

assess_trial(trial_job_id, trial_history)[source]

Abstract method for determining whether a trial should be killed. Must override.

The NNI framework has little guarantee on trial_history. This method is not guaranteed to be invoked for each time trial_history get updated. It is also possible that a trial’s history keeps updating after receiving a bad result. And if the trial failed and retried, trial_history may be inconsistent with its previous value.

The only guarantee is that trial_history is always growing. It will not be empty and will always be longer than previous value.

This is an example of how assess_trial() get invoked sequentially:

trial_job_id | trial_history   | return value
------------ | --------------- | ------------
Trial_A      | [1.0, 2.0]      | Good
Trial_B      | [1.5, 1.3]      | Bad
Trial_B      | [1.5, 1.3, 1.9] | Good
Trial_A      | [0.9, 1.8, 2.3] | Good
Parameters
  • trial_job_id (str) – Unique identifier of the trial.

  • trial_history (list) – Intermediate results of this trial. The element type is decided by trial code.

Returns

AssessResult.Good or AssessResult.Bad.

Return type

AssessResult

load_checkpoint()[source]

Internal API under revising, not recommended for end users.

save_checkpoint()[source]

Internal API under revising, not recommended for end users.

trial_end(trial_job_id, success)[source]

Abstract method invoked when a trial is completed or terminated. Do nothing by default.

Parameters
  • trial_job_id (str) – Unique identifier of the trial.

  • success (bool) – True if the trial successfully completed; False if failed or terminated.

class nni.assessor.AssessResult(value)[source]

Enum class for Assessor.assess_trial() return value.

Bad = False

The trial works poorly and should be early stopped.

Good = True

The trial works well.

class nni.algorithms.hpo.curvefitting_assessor.CurvefittingAssessor(epoch_num=20, start_step=6, threshold=0.95, gap=1)[source]

CurvefittingAssessor uses learning curve fitting algorithm to predict the learning curve performance in the future. It stops a pending trial X at step S if the trial’s forecast result at target step is convergence and lower than the best performance in the history.

Parameters
  • epoch_num (int) – The total number of epoch

  • start_step (int) – only after receiving start_step number of reported intermediate results

  • threshold (float) – The threshold that we decide to early stop the worse performance curve.

assess_trial(trial_job_id, trial_history)[source]

assess whether a trial should be early stop by curve fitting algorithm

Parameters
  • trial_job_id (int) – trial job id

  • trial_history (list) – The history performance matrix of each trial

Returns

AssessResult.Good or AssessResult.Bad

Return type

bool

Raises

Exception – unrecognize exception in curvefitting_assessor

trial_end(trial_job_id, success)[source]

update the best performance of completed trial job

Parameters
  • trial_job_id (int) – trial job id

  • success (bool) – True if succssfully finish the experiment, False otherwise

class nni.algorithms.hpo.medianstop_assessor.MedianstopAssessor(optimize_mode='maximize', start_step=0)[source]

MedianstopAssessor is The median stopping rule stops a pending trial X at step S if the trial’s best objective value by step S is strictly worse than the median value of the running averages of all completed trials’ objectives reported up to step S

Parameters
  • optimize_mode (str) – optimize mode, ‘maximize’ or ‘minimize’

  • start_step (int) – only after receiving start_step number of reported intermediate results

assess_trial(trial_job_id, trial_history)[source]
Parameters
  • trial_job_id (int) – trial job id

  • trial_history (list) – The history performance matrix of each trial

Returns

AssessResult.Good or AssessResult.Bad

Return type

bool

Raises

Exception – unrecognize exception in medianstop_assessor

trial_end(trial_job_id, success)[source]
Parameters
  • trial_job_id (int) – trial job id

  • success (bool) – True if succssfully finish the experiment, False otherwise

Advisor
class nni.runtime.msg_dispatcher_base.MsgDispatcherBase[source]

This is where tuners and assessors are not defined yet. Inherits this class to make your own advisor.

command_queue_worker(command_queue)[source]

Process commands in command queues.

enqueue_command(command, data)[source]

Enqueue command into command queues

handle_add_customized_trial(data)[source]

Experimental API. Not recommended for usage.

handle_import_data(data)[source]

Import previous data when experiment is resumed. :param data: a list of dictionaries, each of which has at least two keys, ‘parameter’ and ‘value’ :type data: list

handle_initialize(data)[source]

Initialize search space and tuner, if any This method is meant to be called only once for each experiment, after calling this method, dispatcher should send(CommandType.Initialized, ‘’), to set the status of the experiment to be “INITIALIZED”. :param data: search space :type data: dict

handle_report_metric_data(data)[source]

Called when metric data is reported or new parameters are requested (for multiphase). When new parameters are requested, this method should send a new parameter.

Parameters

data (dict) – a dict which contains ‘parameter_id’, ‘value’, ‘trial_job_id’, ‘type’, ‘sequence’. type: can be MetricType.REQUEST_PARAMETER, MetricType.FINAL or MetricType.PERIODICAL. REQUEST_PARAMETER is used to request new parameters for multiphase trial job. In this case, the dict will contain additional keys: trial_job_id, parameter_index. Refer to msg_dispatcher.py as an example.

Raises

ValueError – Data type is not supported

handle_request_trial_jobs(data)[source]

The message dispatcher is demanded to generate data trial jobs. These trial jobs should be sent via send(CommandType.NewTrialJob, json_tricks.dumps(parameter)), where parameter will be received by NNI Manager and eventually accessible to trial jobs as “next parameter”. Semantically, message dispatcher should do this send exactly data times.

The JSON sent by this method should follow the format of

{
    "parameter_id": 42
    "parameters": {
        // this will be received by trial
    },
    "parameter_source": "algorithm" // optional
}
Parameters

data (int) – number of trial jobs

handle_trial_end(data)[source]

Called when the state of one of the trials is changed

Parameters

data (dict) – a dict with keys: trial_job_id, event, hyper_params. trial_job_id: the id generated by training service. event: the job’s state. hyper_params: the string that is sent by message dispatcher during the creation of trials.

handle_update_search_space(data)[source]

This method will be called when search space is updated. It’s recommended to call this method in handle_initialize to initialize search space. No need to notify NNI Manager when this update is done. :param data: search space :type data: dict

process_command_thread(request)[source]

Worker thread to process a command.

run()[source]

Run the tuner. This function will never return unless raise.

class nni.algorithms.hpo.hyperband_advisor.Hyperband(R=60, eta=3, optimize_mode='maximize', exec_mode='parallelism')[source]

Hyperband inherit from MsgDispatcherBase rather than Tuner, because it integrates both tuner’s functions and assessor’s functions. This is an implementation that could fully leverage available resources or follow the algorithm process, i.e., high parallelism or serial. A single execution of Hyperband takes a finite budget of (s_max + 1)B.

Parameters
  • R (int) – the maximum amount of resource that can be allocated to a single configuration

  • eta (int) – the variable that controls the proportion of configurations discarded in each round of SuccessiveHalving

  • optimize_mode (str) – optimize mode, ‘maximize’ or ‘minimize’

  • exec_mode (str) – execution mode, ‘serial’ or ‘parallelism’

handle_add_customized_trial(data)[source]

Experimental API. Not recommended for usage.

handle_import_data(data)[source]

Import previous data when experiment is resumed. :param data: a list of dictionaries, each of which has at least two keys, ‘parameter’ and ‘value’ :type data: list

handle_initialize(data)[source]

callback for initializing the advisor :param data: search space :type data: dict

handle_report_metric_data(data)[source]
Parameters

data – it is an object which has keys ‘parameter_id’, ‘value’, ‘trial_job_id’, ‘type’, ‘sequence’.

Raises

ValueError – Data type not supported

handle_request_trial_jobs(data)[source]
Parameters

data (int) – number of trial jobs

handle_trial_end(data)[source]
Parameters

data (dict()) – it has three keys: trial_job_id, event, hyper_params trial_job_id: the id generated by training service event: the job’s state hyper_params: the hyperparameters (a string) generated and returned by tuner

handle_update_search_space(data)[source]

data: JSON object, which is search space

Utilities
nni.utils.merge_parameter(base_params, override_params)[source]

Update the parameters in base_params with override_params. Can be useful to override parsed command line arguments.

Parameters
  • base_params (namespace or dict) – Base parameters. A key-value mapping.

  • override_params (dict or None) – Parameters to override. Usually the parameters got from get_next_parameters(). When it is none, nothing will happen.

Returns

The updated base_params. Note that base_params will be updated inplace. The return value is only for convenience.

Return type

namespace or dict

Framework and Library Supports

With the built-in Python API, NNI naturally supports the hyper parameter tuning and neural network search for all the AI frameworks and libraries who support Python models(version >= 3.6). NNI had also provided a set of examples and tutorials for some of the popular scenarios to make jump start easier.

Supported Library

NNI also supports all libraries written in python.Here are some common libraries, including some algorithms based on GBDT: XGBoost, CatBoost and lightGBM.

Here is just a small list of libraries that supported by NNI. If you are interested in NNI, you can refer to the tutorial to complete your own hacks.

In addition to the above examples, we also welcome more and more users to apply NNI to your own work, if you have any doubts, please refer Write a Trial Run on NNI. In particular, if you want to be a contributor of NNI, whether it is the sharing of examples , writing of Tuner or otherwise, we are all looking forward to your participation.More information please refer to here.

How to Launch an Experiment from Python

Start and Manage a New Experiment

1. Configure Search Space
[1]:
search_space = {
    "C": {"_type":"quniform","_value":[0.1, 1, 0.1]},
    "kernel": {"_type":"choice","_value":["linear", "rbf", "poly", "sigmoid"]},
    "degree": {"_type":"choice","_value":[1, 2, 3, 4]},
    "gamma": {"_type":"quniform","_value":[0.01, 0.1, 0.01]},
    "coef0": {"_type":"quniform","_value":[0.01, 0.1, 0.01]}
}
2. Configure Experiment
[2]:
from nni.experiment import Experiment
experiment = Experiment('local')
experiment.config.experiment_name = 'Example'
experiment.config.trial_concurrency = 2
experiment.config.max_trial_number = 10
experiment.config.search_space = search_space
experiment.config.trial_command = 'python3 main.py'
experiment.config.trial_code_directory = './'
experiment.config.tuner.name = 'TPE'
experiment.config.tuner.class_args['optimize_mode'] = 'maximize'
experiment.config.training_service.use_active_gpu = True
3. Start Experiment
[3]:
experiment.start(8080)
[2021-03-05 12:12:19] Creating experiment, Experiment ID: wdt0le3v
[2021-03-05 12:12:19] Statring web server...
[2021-03-05 12:12:20] Setting up...
[2021-03-05 12:12:20] Web UI URLs: http://127.0.0.1:8080 http://10.0.1.5:8080 http://172.17.0.1:8080
4. Experiment View & Control
[4]:
experiment.get_status()
[4]:
'RUNNING'
[5]:
experiment.export_data()
[5]:
[TrialResult(parameter={'C': 0.30000000000000004, 'kernel': 'linear', 'degree': 3, 'gamma': 0.03, 'coef0': 0.07}, value=0.9888888888888889, trialJobId='VLqU9'),
 TrialResult(parameter={'C': 0.5, 'kernel': 'sigmoid', 'degree': 1, 'gamma': 0.03, 'coef0': 0.07}, value=0.8888888888888888, trialJobId='DLo6r')]
[6]:
experiment.get_job_metrics()
[6]:
{'DLo6r': [TrialMetricData(timestamp=1614946351592, trialJobId='DLo6r', parameterId='1', type='FINAL', sequence=0, data=0.8888888888888888)],
 'VLqU9': [TrialMetricData(timestamp=1614946351607, trialJobId='VLqU9', parameterId='0', type='FINAL', sequence=0, data=0.9888888888888889)]}
5. Stop Experiment
[7]:
experiment.stop()
[2021-03-05 12:12:40] Stopping experiment, please wait...
[2021-03-05 12:12:42] Experiment stopped

Connect and Manage an Exist Experiment

1. Connect Experiment
[1]:
from nni.experiment import Experiment
experiment = Experiment.connect(8080)
[2021-03-05 12:18:28] Connect to port 8080 success, experiment id is DH8pVfXc, status is RUNNING.
2. Experiment View & Control
[2]:
experiment.get_experiment_profile()
[2]:
{'id': 'DH8pVfXc',
 'revision': 4,
 'execDuration': 10,
 'logDir': '/home/ningshang/nni-experiments/DH8pVfXc',
 'nextSequenceId': 1,
 'params': {'authorName': 'default',
  'experimentName': 'example_sklearn-classification',
  'trialConcurrency': 1,
  'maxExecDuration': 3600,
  'maxTrialNum': 100,
  'searchSpace': '{"C": {"_type": "uniform", "_value": [0.1, 1]}, "kernel": {"_type": "choice", "_value": ["linear", "rbf", "poly", "sigmoid"]}, "degree": {"_type": "choice", "_value": [1, 2, 3, 4]}, "gamma": {"_type": "uniform", "_value": [0.01, 0.1]}, "coef0": {"_type": "uniform", "_value": [0.01, 0.1]}}',
  'trainingServicePlatform': 'local',
  'tuner': {'builtinTunerName': 'TPE',
   'classArgs': {'optimize_mode': 'maximize'},
   'checkpointDir': '/home/ningshang/nni-experiments/DH8pVfXc/checkpoint'},
  'versionCheck': True,
  'clusterMetaData': [{'key': 'trial_config',
    'value': {'command': 'python3 main.py',
     'codeDir': '/home/ningshang/nni/examples/trials/sklearn/classification/.',
     'gpuNum': 0}}]},
 'startTime': 1614946699989}
[3]:
experiment.update_max_trial_number(200)
[2021-03-05 12:18:32] (root) Successfully update maxTrialNum.
[4]:
experiment.get_experiment_profile()
[4]:
{'id': 'DH8pVfXc',
 'revision': 5,
 'execDuration': 14,
 'logDir': '/home/ningshang/nni-experiments/DH8pVfXc',
 'nextSequenceId': 1,
 'params': {'authorName': 'default',
  'experimentName': 'example_sklearn-classification',
  'trialConcurrency': 1,
  'maxExecDuration': 3600,
  'maxTrialNum': 200,
  'searchSpace': '{"C": {"_type": "uniform", "_value": [0.1, 1]}, "kernel": {"_type": "choice", "_value": ["linear", "rbf", "poly", "sigmoid"]}, "degree": {"_type": "choice", "_value": [1, 2, 3, 4]}, "gamma": {"_type": "uniform", "_value": [0.01, 0.1]}, "coef0": {"_type": "uniform", "_value": [0.01, 0.1]}}',
  'trainingServicePlatform': 'local',
  'tuner': {'builtinTunerName': 'TPE',
   'classArgs': {'optimize_mode': 'maximize'},
   'checkpointDir': '/home/ningshang/nni-experiments/DH8pVfXc/checkpoint'},
  'versionCheck': True,
  'clusterMetaData': [{'key': 'trial_config',
    'value': {'command': 'python3 main.py',
     'codeDir': '/home/ningshang/nni/examples/trials/sklearn/classification/.',
     'gpuNum': 0}}]},
 'startTime': 1614946699989}
3. Stop Experiment
[5]:
experiment.stop()
[2021-03-05 12:18:36] Stopping experiment, please wait...
[2021-03-05 12:18:38] Experiment stopped

Overview

Since nni v2.0, we provide a new way to launch experiments. Before that, you need to configure the experiment in the yaml configuration file and then use the experiment nnictl command to launch the experiment. Now, you can also configure and run experiments directly in python file. If you are familiar with python programming, this will undoubtedly bring you more convenience.

Run a New Experiment

After successfully installing nni, you can start the experiment with a python script in the following 2 steps.

Step 1 - Initialize an experiment instance and configure it

from nni.experiment import Experiment
experiment = Experiment('local')

Now, you have a Experiment instance, and this experiment will launch trials on your local machine due to training_service='local'.

See all training services supported in NNI.

experiment.config.experiment_name = 'MNIST example'
experiment.config.trial_concurrency = 2
experiment.config.max_trial_number = 10
experiment.config.search_space = search_space
experiment.config.trial_command = 'python3 mnist.py'
experiment.config.trial_code_directory = Path(__file__).parent
experiment.config.tuner.name = 'TPE'
experiment.config.tuner.class_args['optimize_mode'] = 'maximize'
experiment.config.training_service.use_active_gpu = True

Use the form like experiment.config.foo = 'bar' to configure your experiment.

See all real builtin tuners supported in NNI.

See parameter configuration required by different training services.

Step 2 - Just run

experiment.run(port=8080)

Now, you have successfully launched an NNI experiment. And you can type localhost:8080 in your browser to observe your experiment in real time.

Note

In this way, experiment will run in the foreground and will automatically exit when the experiment finished. If you want to run an experiment in an interactive way, use start() in Step 2.

Example

Below is an example for this new launching approach. You can also find this code in mnist-tfv2/launch.py.

from pathlib import Path

from nni.experiment import Experiment

search_space = {
    "dropout_rate": { "_type": "uniform", "_value": [0.5, 0.9] },
    "conv_size": { "_type": "choice", "_value": [2, 3, 5, 7] },
    "hidden_size": { "_type": "choice", "_value": [124, 512, 1024] },
    "batch_size": { "_type": "choice", "_value": [16, 32] },
    "learning_rate": { "_type": "choice", "_value": [0.0001, 0.001, 0.01, 0.1] }
}

experiment = Experiment('local')
experiment.config.experiment_name = 'MNIST example'
experiment.config.trial_concurrency = 2
experiment.config.max_trial_number = 10
experiment.config.search_space = search_space
experiment.config.trial_command = 'python3 mnist.py'
experiment.config.trial_code_directory = Path(__file__).parent
experiment.config.tuner.name = 'TPE'
experiment.config.tuner.class_args['optimize_mode'] = 'maximize'
experiment.config.training_service.use_active_gpu = True

experiment.run(8080)

Start and Manage a New Experiment

We migrate the API in NNI Client to this new launching approach. Launch the experiment by start() instead of run(), then you can use these APIs in interactive mode.

Please refer to example usage and code file python_api_start.ipynb.

Note

run() polls the experiment status and will automatically call stop() when the experiment finished. start() just launched a new experiment, so you need to manually stop the experiment by calling stop().

Connect and Manage an Exist Experiment

If you launch the experiment by nnictl and also want to use these APIs, you can use Experiment.connect() to connect to an existing experiment.

Please refer to example usage and code file python_api_connect.ipynb.

Note

You can use stop() to stop the experiment when connecting to an existing experiment.

Resume/View and Manage a Stopped Experiment

You can use Experiment.resume() and Experiment.view() to resume and view a stopped experiment, these functions behave like nnictl resume and nnictl view. If you want to manage the experiment, set wait_completion as False and the functions will return an Experiment instance. For more parameters, please refer to API.

API

How to Use Shared Storage

If you want to use your own storage during using NNI, shared storage can satisfy you. Instead of using training service native storage, shared storage can bring you more convenience. All the information generated by the experiment will be stored under /nni folder in your shared storage. All the output produced by the trial will be located under /nni/{EXPERIMENT_ID}/trials/{TRIAL_ID}/nnioutput folder in your shared storage. This saves you from finding for experiment-related information in various places. Remember that your trial working directory is /nni/{EXPERIMENT_ID}/trials/{TRIAL_ID}, so if you upload your data in this shared storage, you can open it like a local file in your trial code without downloading it. And we will develop more practical features in the future based on shared storage.

Note

Shared storage is currently in the experimental stage. We suggest use AzureBlob under Ubuntu/CentOS/RHEL, and NFS under Ubuntu/CentOS/RHEL/Fedora/Debian for remote. And make sure your local machine can mount NFS or fuse AzureBlob and has sudo permission on your remote runtime. We only support shared storage under training service with reuse mode for now.

Example

If you want to use AzureBlob, add below to your config. Full config file see mnist-sharedstorage/config_azureblob.yml.

sharedStorage:
    storageType: AzureBlob
    localMountPoint: ${your/local/mount/point}
    remoteMountPoint: ${your/remote/mount/point}
    storageAccountName: ${replace_to_your_storageAccountName}
    storageAccountKey: ${replace_to_your_storageAccountKey}
    # If you did not set storageAccountKey, you need use `az login` with Azure CLI at first and set resourceGroupName.
    # resourceGroupName: ${replace_to_your_resourceGroupName}
    containerName: ${replace_to_your_containerName}
    # usermount means you have already mount this storage on localMountPoint
    # nnimount means nni will try to mount this storage on localMountPoint
    # nomount means storage will not mount in local machine, will support partial storages in the future
    localMounted: nnimount

If you want to use NFS, add below to your config. Full config file see mnist-sharedstorage/config_nfs.yml.

sharedStorage:
    storageType: NFS
    localMountPoint: ${your/local/mount/point}
    remoteMountPoint: ${your/remote/mount/point}
    nfsServer: ${nfs-server-ip}
    exportedDirectory: ${nfs/exported/directory}
    # usermount means you have already mount this storage on localMountPoint
    # nnimount means nni will try to mount this storage on localMountPoint
    # nomount means storage will not mount in local machine, will support partial storages in the future
    localMounted: nnimount

How to Use Tensorboard within WebUI

You can launch a tensorboard process cross one or multi trials within webui since NNI v2.2. This feature supports local training service and reuse mode training service with shared storage for now, and will support more scenarios in later nni version.

Preparation

Make sure tensorboard installed in your environment. If you never used tensorboard, here are getting start tutorials for your reference, tensorboard with tensorflow, tensorboard with pytorch.

Use WebUI Launch Tensorboard

1. Save Logs

NNI will automatically fetch the tensorboard subfolder under trial’s output folder as tensorboard logdir. So in trial’s source code, you need to save the tensorboard logs under NNI_OUTPUT_DIR/tensorboard. This log path can be joined as:

log_dir = os.path.join(os.environ["NNI_OUTPUT_DIR"], 'tensorboard')
2. Launch Tensorboard

Like compare, select the trials you want to combine to launch the tensorboard at first, then click the Tensorboard button.

After click the OK button in the pop-up box, you will jump to the tensorboard portal.

You can see the SequenceID-TrialID on the tensorboard portal.

3. Stop All

If you want to open the portal you have already launched, click the tensorboard id. If you don’t need the tensorboard anymore, click Stop all tensorboard button.

Use Cases and Solutions

Different from the tutorials and examples in the rest of the document which show the usage of a feature, this part mainly introduces end-to-end scenarios and use cases to help users further understand how NNI can help them. NNI can be widely adopted in various scenarios. We also encourage community contributors to share their AutoML practices especially the NNI usage practices from their experience.

Use Cases and Solutions

Automatic Model Tuning

NNI can be applied on various model tuning tasks. Some state-of-the-art model search algorithms, such as EfficientNet, can be easily built on NNI. Popular models, e.g., recommendation models, can be tuned with NNI. The following are some use cases to illustrate how to leverage NNI in your model tuning tasks and how to build your own pipeline with NNI.

Automatically tuning SVD (NNI in Recommenders)

In this tutorial, we first introduce a github repo Recommenders. It is a repository that provides examples and best practices for building recommendation systems, provided as Jupyter notebooks. It has various models that are popular and widely deployed in recommendation systems. To provide a complete end-to-end experience, they present each example in five key tasks, as shown below:

The fourth task is tuning and optimizing the model’s hyperparameters, this is where NNI could help. To give a concrete example that NNI tunes the models in Recommenders, let’s demonstrate with the model SVD, and data Movielens100k. There are more than 10 hyperparameters to be tuned in this model.

This Jupyter notebook provided by Recommenders is a very detailed step-by-step tutorial for this example. It uses different built-in tuning algorithms in NNI, including Annealing, SMAC, Random Search, TPE, Hyperband, Metis and Evolution. Finally, the results of different tuning algorithms are compared. Please go through this notebook to learn how to use NNI to tune SVD model, then you could further use NNI to tune other models in Recommenders.

EfficientNet

EfficientNet: Rethinking Model Scaling for Convolutional Neural Networks

Use Grid search to find the best combination of alpha, beta and gamma for EfficientNet-B1, as discussed in Section 3.3 in paper. Search space, tuner, configuration examples are provided here.

Instructions

Example code

  1. Set your working directory here in the example code directory.

  2. Run git clone https://github.com/ultmaster/EfficientNet-PyTorch to clone the ultmaster modified version of the original EfficientNet-PyTorch. The modifications were done to adhere to the original Tensorflow version as close as possible (including EMA, label smoothing and etc.); also added are the part which gets parameters from tuner and reports intermediate/final results. Clone it into EfficientNet-PyTorch; the files like main.py, train_imagenet.sh will appear inside, as specified in the configuration files.

  3. Run nnictl create --config config_local.yml (use config_pai.yml for OpenPAI) to find the best EfficientNet-B1. Adjust the training service (PAI/local/remote), batch size in the config files according to the environment.

For training on ImageNet, read EfficientNet-PyTorch/train_imagenet.sh. Download ImageNet beforehand and extract it adhering to PyTorch format and then replace /mnt/data/imagenet in with the location of the ImageNet storage. This file should also be a good example to follow for mounting ImageNet into the container on OpenPAI.

Results

The follow image is a screenshot, demonstrating the relationship between acc@1 and alpha, beta, gamma.

Automatic Model Architecture Search for Reading Comprehension

This example shows us how to use Genetic Algorithm to find good model architectures for Reading Comprehension.

1. Search Space

Since attention and RNN have been proven effective in Reading Comprehension, we conclude the search space as follow:

  1. IDENTITY (Effectively means keep training).

  2. INSERT-RNN-LAYER (Inserts a LSTM. Comparing the performance of GRU and LSTM in our experiment, we decided to use LSTM here.)

  3. REMOVE-RNN-LAYER

  4. INSERT-ATTENTION-LAYER(Inserts an attention layer.)

  5. REMOVE-ATTENTION-LAYER

  6. ADD-SKIP (Identity between random layers).

  7. REMOVE-SKIP (Removes random skip).

New version

Also we have another version which time cost is less and performance is better. We will release soon.

2. How to run this example in local?
2.1 Use downloading script to download data

Execute the following command to download needed files using the downloading script:

chmod +x ./download.sh
./download.sh

Or Download manually

  1. download dev-v1.1.json and train-v1.1.json here

wget https://rajpurkar.github.io/SQuAD-explorer/dataset/train-v1.1.json
wget https://rajpurkar.github.io/SQuAD-explorer/dataset/dev-v1.1.json
  1. download glove.840B.300d.txt here

wget http://nlp.stanford.edu/data/glove.840B.300d.zip
unzip glove.840B.300d.zip
2.2 Update configuration

Modify nni/examples/trials/ga_squad/config.yml, here is the default configuration:

authorName: default
experimentName: example_ga_squad
trialConcurrency: 1
maxExecDuration: 1h
maxTrialNum: 1
#choice: local, remote
trainingServicePlatform: local
#choice: true, false
useAnnotation: false
tuner:
  codeDir: ~/nni/examples/tuners/ga_customer_tuner
  classFileName: customer_tuner.py
  className: CustomerTuner
  classArgs:
    optimize_mode: maximize
trial:
  command: python3 trial.py
  codeDir: ~/nni/examples/trials/ga_squad
  gpuNum: 0

In the trial part, if you want to use GPU to perform the architecture search, change gpuNum from 0 to 1. You need to increase the maxTrialNum and maxExecDuration, according to how long you want to wait for the search result.

2.3 submit this job
nnictl create --config ~/nni/examples/trials/ga_squad/config.yml
3 Run this example on OpenPAI

Due to the memory limitation of upload, we only upload the source code and complete the data download and training on OpenPAI. This experiment requires sufficient memory that memoryMB >= 32G, and the training may last for several hours.

3.1 Update configuration

Modify nni/examples/trials/ga_squad/config_pai.yml, here is the default configuration:

authorName: default
experimentName: example_ga_squad
trialConcurrency: 1
maxExecDuration: 1h
maxTrialNum: 10
#choice: local, remote, pai
trainingServicePlatform: pai
#choice: true, false
useAnnotation: false
#Your nni_manager ip
nniManagerIp: 10.10.10.10
tuner:
  codeDir: https://github.com/Microsoft/nni/tree/v2.2/examples/tuners/ga_customer_tuner
  classFileName: customer_tuner.py
  className: CustomerTuner
  classArgs:
    optimize_mode: maximize
trial:
  command: chmod +x ./download.sh && ./download.sh && python3 trial.py
  codeDir: .
  gpuNum: 0
  cpuNum: 1
  memoryMB: 32869
  #The docker image to run nni job on OpenPAI
  image: msranni/nni:latest
paiConfig:
  #The username to login OpenPAI
  userName: username
  #The password to login OpenPAI
  passWord: password
  #The host of restful server of OpenPAI
  host: 10.10.10.10

Please change the default value to your personal account and machine information. Including nniManagerIp, userName, passWord and host.

In the “trial” part, if you want to use GPU to perform the architecture search, change gpuNum from 0 to 1. You need to increase the maxTrialNum and maxExecDuration, according to how long you want to wait for the search result.

trialConcurrency is the number of trials running concurrently, which is the number of GPUs you want to use, if you are setting gpuNum to 1.

3.2 submit this job
nnictl create --config ~/nni/examples/trials/ga_squad/config_pai.yml
4. Technical details about the trial
4.1 How does it works

The evolution-algorithm based architecture for question answering has two different parts just like any other examples: the trial and the tuner.

4.2 The trial

The trial has a lot of different files, functions and classes. Here we will only give most of those files a brief introduction:

  • attention.py contains an implementation for attention mechanism in Tensorflow.

  • data.py contains functions for data preprocessing.

  • evaluate.py contains the evaluation script.

  • graph.py contains the definition of the computation graph.

  • rnn.py contains an implementation for GRU in Tensorflow.

  • train_model.py is a wrapper for the whole question answering model.

Among those files, trial.py and graph_to_tf.py are special.

graph_to_tf.py has a function named as graph_to_network, here is its skeleton code:

def graph_to_network(input1,
                     input2,
                     input1_lengths,
                     input2_lengths,
                     graph,
                     dropout_rate,
                     is_training,
                     num_heads=1,
                     rnn_units=256):
    topology = graph.is_topology()
    layers = dict()
    layers_sequence_lengths = dict()
    num_units = input1.get_shape().as_list()[-1]
    layers[0] = input1*tf.sqrt(tf.cast(num_units, tf.float32)) + \
        positional_encoding(input1, scale=False, zero_pad=False)
    layers[1] = input2*tf.sqrt(tf.cast(num_units, tf.float32))
    layers[0] = dropout(layers[0], dropout_rate, is_training)
    layers[1] = dropout(layers[1], dropout_rate, is_training)
    layers_sequence_lengths[0] = input1_lengths
    layers_sequence_lengths[1] = input2_lengths
    for _, topo_i in enumerate(topology):
        if topo_i == '|':
            continue
        if graph.layers[topo_i].graph_type == LayerType.input.value:
            # ......
        elif graph.layers[topo_i].graph_type == LayerType.attention.value:
            # ......
        # More layers to handle

As we can see, this function is actually a compiler, that converts the internal model DAG configuration (which will be introduced in the Model configuration format section) graph, to a Tensorflow computation graph.

topology = graph.is_topology()

performs topological sorting on the internal graph representation, and the code inside the loop:

for _, topo_i in enumerate(topology):

performs actually conversion that maps each layer to a part in Tensorflow computation graph.

4.3 The tuner

The tuner is much more simple than the trial. They actually share the same graph.py. Besides, the tuner has a customer_tuner.py, the most important class in which is CustomerTuner:

class CustomerTuner(Tuner):
    # ......

    def generate_parameters(self, parameter_id):
        """Returns a set of trial graph config, as a serializable object.
        parameter_id : int
        """
        if len(self.population) <= 0:
            logger.debug("the len of poplution lower than zero.")
            raise Exception('The population is empty')
        pos = -1
        for i in range(len(self.population)):
            if self.population[i].result == None:
                pos = i
                break
        if pos != -1:
            indiv = copy.deepcopy(self.population[pos])
            self.population.pop(pos)
            temp = json.loads(graph_dumps(indiv.config))
        else:
            random.shuffle(self.population)
            if self.population[0].result > self.population[1].result:
                self.population[0] = self.population[1]
            indiv = copy.deepcopy(self.population[0])
            self.population.pop(1)
            indiv.mutation()
            graph = indiv.config
            temp =  json.loads(graph_dumps(graph))

    # ......

As we can see, the overloaded method generate_parameters implements a pretty naive mutation algorithm. The code lines:

if self.population[0].result > self.population[1].result:
    self.population[0] = self.population[1]
indiv = copy.deepcopy(self.population[0])

controls the mutation process. It will always take two random individuals in the population, only keeping and mutating the one with better result.

4.4 Model configuration format

Here is an example of the model configuration, which is passed from the tuner to the trial in the architecture search procedure.

{
    "max_layer_num": 50,
    "layers": [
        {
            "input_size": 0,
            "type": 3,
            "output_size": 1,
            "input": [],
            "size": "x",
            "output": [4, 5],
            "is_delete": false
        },
        {
            "input_size": 0,
            "type": 3,
            "output_size": 1,
            "input": [],
            "size": "y",
            "output": [4, 5],
            "is_delete": false
        },
        {
            "input_size": 1,
            "type": 4,
            "output_size": 0,
            "input": [6],
            "size": "x",
            "output": [],
            "is_delete": false
        },
        {
            "input_size": 1,
            "type": 4,
            "output_size": 0,
            "input": [5],
            "size": "y",
            "output": [],
            "is_delete": false
        },
        {"Comment": "More layers will be here for actual graphs."}
    ]
}

Every model configuration will have a “layers” section, which is a JSON list of layer definitions. The definition of each layer is also a JSON object, where:

  • type is the type of the layer. 0, 1, 2, 3, 4 corresponds to attention, self-attention, RNN, input and output layer respectively.

  • size is the length of the output. “x”, “y” correspond to document length / question length, respectively.

  • input_size is the number of inputs the layer has.

  • input is the indices of layers taken as input of this layer.

  • output is the indices of layers use this layer’s output as their input.

  • is_delete means whether the layer is still available.

Parallelizing a Sequential Algorithm TPE

TPE approaches were actually run asynchronously in order to make use of multiple compute nodes and to avoid wasting time waiting for trial evaluations to complete. For the TPE approach, the so-called constant liar approach was used: each time a candidate point x∗ was proposed, a fake fitness evaluation of the y was assigned temporarily, until the evaluation completed and reported the actual loss f(x∗).

Introduction and Problems
Sequential Model-based Global Optimization

Sequential Model-Based Global Optimization (SMBO) algorithms have been used in many applications where evaluation of the fitness function is expensive. In an application where the true fitness function f: X → R is costly to evaluate, model-based algorithms approximate f with a surrogate that is cheaper to evaluate. Typically the inner loop in an SMBO algorithm is the numerical optimization of this surrogate, or some transformation of the surrogate. The point x∗ that maximizes the surrogate (or its transformation) becomes the proposal for where the true function f should be evaluated. This active-learning-like algorithm template is summarized in the figure below. SMBO algorithms differ in what criterion they optimize to obtain x∗ given a model (or surrogate) of f, and in they model f via observation history H.

The algorithms in this work optimize the criterion of Expected Improvement (EI). Other criteria have been suggested, such as Probability of Improvement and Expected Improvement, minimizing the Conditional Entropy of the Minimizer, and the bandit-based criterion. We chose to use the EI criterion in TPE because it is intuitive, and has been shown to work well in a variety of settings. Expected improvement is the expectation under some model M of f : X → RN that f(x) will exceed (negatively) some threshold y∗:

Since calculation of p(y|x) is expensive, TPE approach modeled p(y|x) by p(x|y) and p(y).The TPE defines p(x|y) using two such densities:

where l(x) is the density formed by using the observations {x(i)} such that corresponding loss f(x(i)) was less than y∗ and g(x) is the density formed by using the remaining observations. TPE algorithm depends on a y∗ that is larger than the best observed f(x) so that some points can be used to form l(x). The TPE algorithm chooses y∗ to be some quantile γ of the observed y values, so that p(y<y∗) = γ, but no specific model for p(y) is necessary. The tree-structured form of l and g makes it easy to draw many candidates according to l and evaluate them according to g(x)/l(x). On each iteration, the algorithm returns the candidate x∗ with the greatest EI.

Here is a simulation of the TPE algorithm in a two-dimensional search space. The difference of background color represents different values. It can be seen that TPE combines exploration and exploitation very well. (Black indicates the points of this round samples, and yellow indicates the points has been taken in the history.)

Since EI is a continuous function, the highest x of EI is determined at a certain status. As shown in the figure below, the blue triangle is the point that is most likely to be sampled in this state.

TPE performs well when we use it in sequential, but if we provide a larger concurrency, then there will be a large number of points produced in the same EI state, too concentrated points will reduce the exploration ability of the tuner, resulting in resources waste.

Here is the simulation figure when we set concurrency=60, It can be seen that this phenomenon is obvious.

Research solution
Approximated q-EI Maximization

The multi-points criterion that we have presented below can potentially be used to deliver an additional design of experiments in one step through the resolution of the optimization problem.

However, the computation of q-EI becomes intensive as q increases. After our research, there are four popular greedy strategies that approach the result of problem while avoiding its numerical cost.

Solution 1: Believing the OK Predictor: The KB(Kriging Believer) Heuristic Strategy

The Kriging Believer strategy replaces the conditional knowledge about the responses at the sites chosen within the last iterations by deterministic values equal to the expectation of the Kriging predictor. Keeping the same notations as previously, the strategy can be summed up as follows:

This sequential strategy delivers a q-points design and is computationally affordable since it relies on the analytically known EI, optimized in d dimensions. However, there is a risk of failure, since believing an OK predictor that overshoots the observed data may lead to a sequence that gets trapped in a non-optimal region for many iterations. We now propose a second strategy that reduces this risk.

Solution 2: The CL(Constant Liar) Heuristic Strategy

Let us now consider a sequential strategy in which the metamodel is updated (still without hyperparameter re-estimation) at each iteration with a value L exogenously fixed by the user, here called a ”lie”. The strategy referred to as the Constant Liar consists in lying with the same value L at every iteration: maximize EI (i.e. find xn+1), actualize the model as if y(xn+1) = L, and so on always with the same L ∈ R:

L should logically be determined on the basis of the values taken by y at X. Three values, min{Y}, mean{Y}, and max{Y} are considered here. The larger L is, the more explorative the algorithm will be, and vice versa.

We have simulated the method above. The following figure shows the result of using mean value liars to maximize q-EI. We find that the points we have taken have begun to be scattered.

Experiment
Branin-Hoo

The four optimization strategies presented in the last section are now compared on the Branin-Hoo function which is a classical test-case in global optimization.

The recommended values of a, b, c, r, s and t are: a = 1, b = 5.1 ⁄ (4π2), c = 5 ⁄ π, r = 6, s = 10 and t = 1 ⁄ (8π). This function has three global minimizers(-3.14, 12.27), (3.14, 2.27), (9.42, 2.47).

Next is the comparison of the q-EI associated with the q first points (q ∈ [1,10]) given by the constant liar strategies (min and max), 2000 q-points designs uniformly drawn for every q, and 2000 q-points LHS designs taken at random for every q.

As we can seen on figure, CL[max] and CL[min] offer very good q-EI results compared to random designs, especially for small values of q.

Gaussian Mixed Model function

We also compared the case of using parallel optimization and not using parallel optimization. A two-dimensional multimodal Gaussian Mixed distribution is used to simulate, the following is our result:

concurrency=80

concurrency=60

concurrency=40

concurrency=20

concurrency=10

Without parallel optimization

avg = 0.4841
var = 0.1953

avg = 0.5155
var = 0.2219

avg = 0.5773
var = 0.2570

avg = 0.4680
var = 0.1994

avg = 0.2774
var = 0.1217

With parallel optimization

avg = 0.2132
var = 0.0700

avg = 0.2177
var = 0.0796

avg = 0.1835
var = 0.0533

avg = 0.1671
var = 0.0413

avg = 0.1918
var = 0.0697

Note: The total number of samples per test is 240 (ensure that the budget is equal). The trials in each form were repeated 1000 times, the value is the average and variance of the best results in 1000 trials.

References

[1] James Bergstra, Remi Bardenet, Yoshua Bengio, Balazs Kegl. Algorithms for Hyper-Parameter Optimization.

[2] Meng-Hiot Lim, Yew-Soon Ong. Computational Intelligence in Expensive Optimization Problems.

[3] M. Jordan, J. Kleinberg, B. Scho¨lkopf. Pattern Recognition and Machine Learning.

Automatic System Tuning

The performance of systems, such as database, tensor operator implementaion, often need to be tuned to adapt to specific hardware configuration, targeted workload, etc. Manually tuning a system is complicated and often requires detailed understanding of hardware and workload. NNI can make such tasks much easier and help system owners find the best configuration to the system automatically. The detailed design philosophy of automatic system tuning can be found in this paper. The following are some typical cases that NNI can help.

Automatically tuning SPTAG with NNI

SPTAG (Space Partition Tree And Graph) is a library for large scale vector approximate nearest neighbor search scenario released by Microsoft Research (MSR) and Microsoft Bing.

This library assumes that the samples are represented as vectors and that the vectors can be compared by L2 distances or cosine distances. Vectors returned for a query vector are the vectors that have smallest L2 distance or cosine distances with the query vector. SPTAG provides two methods: kd-tree and relative neighborhood graph (SPTAG-KDT) and balanced k-means tree and relative neighborhood graph (SPTAG-BKT). SPTAG-KDT is advantageous in index building cost, and SPTAG-BKT is advantageous in search accuracy in very high-dimensional data.

In SPTAG, there are tens of parameters that can be tuned for specified scenarios or datasets. NNI is a great tool for automatically tuning those parameters. The authors of SPTAG tried NNI for the auto tuning and found good-performing parameters easily, thus, they shared the practice of tuning SPTAG on NNI in their document here. Please refer to it for detailed tutorial.

Tuning RocksDB on NNI
Overview

RocksDB is a popular high performance embedded key-value database used in production systems at various web-scale enterprises including Facebook, Yahoo!, and LinkedIn.. It is a fork of LevelDB by Facebook optimized to exploit many central processing unit (CPU) cores, and make efficient use of fast storage, such as solid-state drives (SSD), for input/output (I/O) bound workloads.

The performance of RocksDB is highly contingent on its tuning. However, because of the complexity of its underlying technology and a large number of configurable parameters, a good configuration is sometimes hard to obtain. NNI can help to address this issue. NNI supports many kinds of tuning algorithms to search the best configuration of RocksDB, and support many kinds of environments like local machine, remote servers and cloud.

This example illustrates how to use NNI to search the best configuration of RocksDB for a fillrandom benchmark supported by a benchmark tool db_bench, which is an official benchmark tool provided by RocksDB itself. Therefore, before running this example, please make sure NNI is installed and db_bench is in your PATH. Please refer to here for detailed information about installation and preparing of NNI environment, and here for compiling RocksDB as well as db_bench.

We also provide a simple script db_bench_installation.sh helping to compile and install db_bench as well as its dependencies on Ubuntu. Installing RocksDB on other systems can follow the same procedure.

code directory

Experiment setup

There are mainly three steps to setup an experiment of tuning systems on NNI. Define search space with a json file, write a benchmark code, and start NNI experiment by passing a config file to NNI manager.

Search Space

For simplicity, this example tunes three parameters, write_buffer_size, min_write_buffer_num and level0_file_num_compaction_trigger, for writing 16M keys with 20 Bytes of key size and 100 Bytes of value size randomly, based on writing operations per second (OPS). write_buffer_size sets the size of a single memtable. Once memtable exceeds this size, it is marked immutable and a new one is created. min_write_buffer_num is the minimum number of memtables to be merged before flushing to storage. Once the number of files in level 0 reaches level0_file_num_compaction_trigger, level 0 to level 1 compaction is triggered.

In this example, the search space is specified by a search_space.json file as shown below. Detailed explanation of search space could be found here.

{
    "write_buffer_size": {
        "_type": "quniform",
        "_value": [2097152, 16777216, 1048576]
    },
    "min_write_buffer_number_to_merge": {
        "_type": "quniform",
        "_value": [2, 16, 1]
    },
    "level0_file_num_compaction_trigger": {
        "_type": "quniform",
        "_value": [2, 16, 1]
    }
}

code directory

Benchmark code

Benchmark code should receive a configuration from NNI manager, and report the corresponding benchmark result back. Following NNI APIs are designed for this purpose. In this example, writing operations per second (OPS) is used as a performance metric. Please refer to here for detailed information.

  • Use nni.get_next_parameter() to get next system configuration.

  • Use nni.report_final_result(metric) to report the benchmark result.

code directory

Config file

One could start a NNI experiment with a config file. A config file for NNI is a yaml file usually including experiment settings (trialConcurrency, maxExecDuration, maxTrialNum, trial gpuNum, etc.), platform settings (trainingServicePlatform, etc.), path settings (searchSpacePath, trial codeDir, etc.) and tuner settings (tuner, tuner optimize_mode, etc.). Please refer to here for more information.

Here is an example of tuning RocksDB with SMAC algorithm:

code directory

Here is an example of tuning RocksDB with TPE algorithm:

code directory

Other tuners can be easily adopted in the same way. Please refer to here for more information.

Finally, we could enter the example folder and start the experiment using following commands:

# tuning RocksDB with SMAC tuner
nnictl create --config ./config_smac.yml
# tuning RocksDB with TPE tuner
nnictl create --config ./config_tpe.yml
Experiment results

We ran these two examples on the same machine with following details:

  • 16 * Intel(R) Xeon(R) CPU E5-2650 v2 @ 2.60GHz

  • 465 GB of rotational hard drive with ext4 file system

  • 128 GB of RAM

  • Kernel version: 4.15.0-58-generic

  • NNI version: v1.0-37-g1bd24577

  • RocksDB version: 6.4

  • RocksDB DEBUG_LEVEL: 0

The detailed experiment results are shown in the below figure. Horizontal axis is sequential order of trials. Vertical axis is the metric, write OPS in this example. Blue dots represent trials for tuning RocksDB with SMAC tuner, and orange dots stand for trials for tuning RocksDB with TPE tuner.

image

Following table lists the best trials and corresponding parameters and metric obtained by the two tuners. Unsurprisingly, both of them found the same optimal configuration for fillrandom benchmark.

Tuner

Best trial

Best OPS

write_buffer_size

min_write_buffer_number_to_merge

level0_file_num_compaction_trigger

SMAC

255

779289

2097152

7.0

7.0

TPE

169

761456

2097152

7.0

7.0

Tuning Tensor Operators on NNI
Overview

Abundant applications raise the demands of training and inference deep neural networks (DNNs) efficiently on diverse hardware platforms ranging from cloud servers to embedded devices. Moreover, computational graph-level optimization of deep neural network, like tensor operator fusion, may introduce new tensor operators. Thus, manually optimized tensor operators provided by hardware-specific libraries have limitations in terms of supporting new hardware platforms or supporting new operators, so automatically optimizing tensor operators on diverse hardware platforms is essential for large-scale deployment and application of deep learning technologies in the real-world problems.

Tensor operator optimization is substantially a combinatorial optimization problem. The objective function is the performance of a tensor operator on specific hardware platform, which should be maximized with respect to the hyper-parameters of corresponding device code, such as how to tile a matrix or whether to unroll a loop. Unlike many typical problems of this type, such as travelling salesman problem, the objective function of tensor operator optimization is a black box and expensive to sample. One has to compile a device code with a specific configuration and run it on real hardware to get the corresponding performance metric. Therefore, a desired method for optimizing tensor operators should find the best configuration with as few samples as possible.

The expensive objective function makes solving tensor operator optimization problem with traditional combinatorial optimization methods, for example, simulated annealing and evolutionary algorithms, almost impossible. Although these algorithms inherently support combinatorial search spaces, they do not take sample-efficiency into account, thus thousands of or even more samples are usually needed, which is unacceptable when tuning tensor operators in product environments. On the other hand, sequential model based optimization (SMBO) methods are proved sample-efficient for optimizing black-box functions with continuous search spaces. However, when optimizing ones with combinatorial search spaces, SMBO methods are not as sample-efficient as their continuous counterparts, because there is lack of prior assumptions about the objective functions, such as continuity and differentiability in the case of continuous search spaces. For example, if one could assume an objective function with a continuous search space is infinitely differentiable, a Gaussian process with a radial basis function (RBF) kernel could be used to model the objective function. In this way, a sample provides not only a single value at a point but also the local properties of the objective function in its neighborhood or even global properties, which results in a high sample-efficiency. In contrast, SMBO methods for combinatorial optimization suffer poor sample-efficiency due to the lack of proper prior assumptions and surrogate models which can leverage them.

OpEvo is recently proposed for solving this challenging problem. It efficiently explores the search spaces of tensor operators by introducing a topology-aware mutation operation based on q-random walk distribution to leverage the topological structures over the search spaces. Following this example, you can use OpEvo to tune three representative types of tensor operators selected from two popular neural networks, BERT and AlexNet. Three comparison baselines, AutoTVM, G-BFS and N-A2C, are also provided. Please refer to OpEvo: An Evolutionary Method for Tensor Operator Optimization for detailed explanation about these algorithms.

Environment Setup

We prepared a dockerfile for setting up experiment environments. Before starting, please make sure the Docker daemon is running and the driver of your GPU accelerator is properly installed. Enter into the example folder examples/trials/systems/opevo and run below command to build and instantiate a Docker image from the dockerfile.

# if you are using Nvidia GPU
make cuda-env
# if you are using AMD GPU
make rocm-env
Run Experiments:

Three representative kinds of tensor operators, matrix multiplication, batched matrix multiplication and 2D convolution, are chosen from BERT and AlexNet, and tuned with NNI. The Trial code for all tensor operators is /root/compiler_auto_tune_stable.py, and Search Space files and config files for each tuning algorithm locate in /root/experiments/, which are categorized by tensor operators. Here /root refers to the root of the container.

For tuning the operators of matrix multiplication, please run below commands from /root:

# (N, K) x (K, M) represents a matrix of shape (N, K) multiplies a matrix of shape (K, M)

# (512, 1024) x (1024, 1024)
# tuning with OpEvo
nnictl create --config experiments/mm/N512K1024M1024/config_opevo.yml
# tuning with G-BFS
nnictl create --config experiments/mm/N512K1024M1024/config_gbfs.yml
# tuning with N-A2C
nnictl create --config experiments/mm/N512K1024M1024/config_na2c.yml
# tuning with AutoTVM
OP=matmul STEP=512 N=512 M=1024 K=1024 P=NN ./run.s

# (512, 1024) x (1024, 4096)
# tuning with OpEvo
nnictl create --config experiments/mm/N512K1024M4096/config_opevo.yml
# tuning with G-BFS
nnictl create --config experiments/mm/N512K1024M4096/config_gbfs.yml
# tuning with N-A2C
nnictl create --config experiments/mm/N512K1024M4096/config_na2c.yml
# tuning with AutoTVM
OP=matmul STEP=512 N=512 M=1024 K=4096 P=NN ./run.sh

# (512, 4096) x (4096, 1024)
# tuning with OpEvo
nnictl create --config experiments/mm/N512K4096M1024/config_opevo.yml
# tuning with G-BFS
nnictl create --config experiments/mm/N512K4096M1024/config_gbfs.yml
# tuning with N-A2C
nnictl create --config experiments/mm/N512K4096M1024/config_na2c.yml
# tuning with AutoTVM
OP=matmul STEP=512 N=512 M=4096 K=1024 P=NN ./run.sh

For tuning the operators of batched matrix multiplication, please run below commands from /root:

# batched matrix with batch size 960 and shape of matrix (128, 128) multiplies batched matrix with batch size 960 and shape of matrix (128, 64)
# tuning with OpEvo
nnictl create --config experiments/bmm/B960N128K128M64PNN/config_opevo.yml
# tuning with AutoTVM
OP=batch_matmul STEP=512 B=960 N=128 K=128 M=64 P=NN ./run.sh

# batched matrix with batch size 960 and shape of matrix (128, 128) is transposed first and then multiplies batched matrix with batch size 960 and shape of matrix (128, 64)
# tuning with OpEvo
nnictl create --config experiments/bmm/B960N128K128M64PTN/config_opevo.yml
# tuning with AutoTVM
OP=batch_matmul STEP=512 B=960 N=128 K=128 M=64 P=TN ./run.sh

# batched matrix with batch size 960 and shape of matrix (128, 64) is transposed first and then right multiplies batched matrix with batch size 960 and shape of matrix (128, 64).
# tuning with OpEvo
nnictl create --config experiments/bmm/B960N128K64M128PNT/config_opevo.yml
# tuning with AutoTVM
OP=batch_matmul STEP=512 B=960 N=128 K=64 M=128 P=NT ./run.sh

For tuning the operators of 2D convolution, please run below commands from /root:

# image tensor of shape (512, 3, 227, 227) convolves with kernel tensor of shape (64, 3, 11, 11) with stride 4 and padding 0
# tuning with OpEvo
nnictl create --config experiments/conv/N512C3HW227F64K11ST4PD0/config_opevo.yml
# tuning with AutoTVM
OP=convfwd_direct STEP=512 N=512 C=3 H=227 W=227 F=64 K=11 ST=4 PD=0 ./run.sh

# image tensor of shape (512, 64, 27, 27) convolves with kernel tensor of shape (192, 64, 5, 5) with stride 1 and padding 2
# tuning with OpEvo
nnictl create --config experiments/conv/N512C64HW27F192K5ST1PD2/config_opevo.yml
# tuning with AutoTVM
OP=convfwd_direct STEP=512 N=512 C=64 H=27 W=27 F=192 K=5 ST=1 PD=2 ./run.sh

Please note that G-BFS and N-A2C are only designed for tuning tiling schemes of multiplication of matrices with only power of 2 rows and columns, so they are not compatible with other types of configuration spaces, thus not eligible to tune the operators of batched matrix multiplication and 2D convolution. Here, AutoTVM is implemented by its authors in the TVM project, so the tuning results are printed on the screen rather than reported to NNI manager. The port 8080 of the container is bind to the host on the same port, so one can access the NNI Web UI through host_ip_addr:8080 and monitor tuning process as below screenshot.

_images/opevo.png
Citing OpEvo

If you feel OpEvo is helpful, please consider citing the paper as follows:

@misc{gao2020opevo,
    title={OpEvo: An Evolutionary Method for Tensor Operator Optimization},
    author={Xiaotian Gao and Cui Wei and Lintao Zhang and Mao Yang},
    year={2020},
    eprint={2006.05664},
    archivePrefix={arXiv},
    primaryClass={cs.LG}
}

Model Compression

The following one shows how to apply knowledge distillation on NNI model compression. More use cases and solutions will be added in the future.

Knowledge Distillation on NNI
KnowledgeDistill

Knowledge Distillation (KD) is proposed in Distilling the Knowledge in a Neural Network, the compressed model is trained to mimic a pre-trained, larger model. This training setting is also referred to as “teacher-student”, where the large model is the teacher and the small model is the student. KD is often used to fine-tune the pruned model.

Usage

PyTorch code

for batch_idx, (data, target) in enumerate(train_loader):
   data, target = data.to(device), target.to(device)
   optimizer.zero_grad()
   y_s = model_s(data)
   y_t = model_t(data)
   loss_cri = F.cross_entropy(y_s, target)

   # kd loss
   p_s = F.log_softmax(y_s/kd_T, dim=1)
   p_t = F.softmax(y_t/kd_T, dim=1)
   loss_kd = F.kl_div(p_s, p_t, size_average=False) * (self.T**2) / y_s.shape[0]

   # total loss
   loss = loss_cir + loss_kd
   loss.backward()

The complete code for fine-tuning the pruned model can be found here

python finetune_kd_torch.py --model [model name] --teacher-model-dir [pretrained checkpoint path]  --student-model-dir [pruned checkpoint path] --mask-path [mask file path]

Note that: for fine-tuning a pruned model, run basic_pruners_torch.py first to get the mask file, then pass the mask path as argument to the script.

Feature Engineering

The following is an article about how NNI helps in auto feature engineering shared by a community contributor. More use cases and solutions will be added in the future.

NNI review article from Zhihu: - By Garvin Li

The article is by a NNI user on Zhihu forum. In the article, Garvin had shared his experience on using NNI for Automatic Feature Engineering. We think this article is very useful for users who are interested in using NNI for feature engineering. With author’s permission, we translated the original article into English.

source: 如何看待微软最新发布的AutoML平台NNI?By Garvin Li

01 Overview of AutoML

In author’s opinion, AutoML is not only about hyperparameter optimization, but also a process that can target various stages of the machine learning process, including feature engineering, NAS, HPO, etc.

02 Overview of NNI

NNI (Neural Network Intelligence) is an open source AutoML toolkit from Microsoft, to help users design and tune machine learning models, neural network architectures, or a complex system’s parameters in an efficient and automatic way.

Link: https://github.com/Microsoft/nni

In general, most of Microsoft tools have one prominent characteristic: the design is highly reasonable (regardless of the technology innovation degree). NNI’s AutoFeatureENG basically meets all user requirements of AutoFeatureENG with a very reasonable underlying framework design.

03 Details of NNI-AutoFeatureENG

The article is following the github project: https://github.com/SpongebBob/tabular_automl_NNI.

Each new user could do AutoFeatureENG with NNI easily and efficiently. To exploring the AutoFeatureENG capability, downloads following required files, and then run NNI install through pip.

NNI treats AutoFeatureENG as a two-steps-task, feature generation exploration and feature selection. Feature generation exploration is mainly about feature derivation and high-order feature combination.

04 Feature Exploration

For feature derivation, NNI offers many operations which could automatically generate new features, which list as following :

count: Count encoding is based on replacing categories with their counts computed on the train set, also named frequency encoding.

target: Target encoding is based on encoding categorical variable values with the mean of target variable per value.

embedding: Regard features as sentences, generate vectors using Word2Vec.

crosscout: Count encoding on more than one-dimension, alike CTR (Click Through Rate).

aggregete: Decide the aggregation functions of the features, including min/max/mean/var.

nunique: Statistics of the number of unique features.

histsta: Statistics of feature buckets, like histogram statistics.

Search space could be defined in a JSON file: to define how specific features intersect, which two columns intersect and how features generate from corresponding columns.

The picture shows us the procedure of defining search space. NNI provides count encoding for 1-order-op, as well as cross count encoding, aggerate statistics (min max var mean median nunique) for 2-order-op.

For example, we want to search the features which are a frequency encoding (valuecount) features on columns name {“C1”, …,” C26”}, in the following way:

we can define a cross frequency encoding (value count on cross dims) method on columns {“C1”,…,”C26”} x {“C1”,…,”C26”} in the following way:

The purpose of Exploration is to generate new features. You can use get_next_parameter function to get received feature candidates of one trial.

RECEIVED_PARAMS = nni.get_next_parameter()

05 Feature selection

To avoid feature explosion and overfitting, feature selection is necessary. In the feature selection of NNI-AutoFeatureENG, LightGBM (Light Gradient Boosting Machine), a gradient boosting framework developed by Microsoft, is mainly promoted.

If you have used XGBoost or GBDT, you would know the algorithm based on tree structure can easily calculate the importance of each feature on results. LightGBM is able to make feature selection naturally.

The issue is that selected features might be applicable to GBDT (Gradient Boosting Decision Tree), but not to the linear algorithm like LR (Logistic Regression).

06 Summary

NNI’s AutoFeatureEng sets a well-established standard, showing us the operation procedure, available modules, which is highly convenient to use. However, a simple model is probably not enough for good results.

Suggestions to NNI

About Exploration: If consider using DNN (like xDeepFM) to extract high-order feature would be better.

About Selection: There could be more intelligent options, such as automatic selection system based on downstream models.

Conclusion: NNI could offer users some inspirations of design and it is a good open source project. I suggest researchers leverage it to accelerate the AI research.

Tips: Because the scripts of open source projects are compiled based on gcc7, Mac system may encounter problems of gcc (GNU Compiler Collection). The solution is as follows:

brew install libomp

Performance Measurement, Comparison and Analysis

Performance comparison and analysis can help users decide a proper algorithm (e.g., tuner, NAS algorithm) for their scenario. The following are some measurement and comparison data for users’ reference.

Neural Architecture Search Comparison

Posted by Anonymous Author

Train and Compare NAS (Neural Architecture Search) models including Autokeras, DARTS, ENAS and NAO.

Their source code link is as below:

Experiment Description

To avoid over-fitting in CIFAR-10, we also compare the models in the other five datasets including Fashion-MNIST, CIFAR-100, OUI-Adience-Age, ImageNet-10-1 (subset of ImageNet), ImageNet-10-2 (another subset of ImageNet). We just sample a subset with 10 different labels from ImageNet to make ImageNet-10-1 or ImageNet-10-2.

Dataset

Training Size

Numer of Classes

Descriptions

Fashion-MNIST

60,000

10

T-shirt/top, trouser, pullover, dress, coat, sandal, shirt, sneaker, bag and ankle boot.

CIFAR-10

50,000

10

Airplanes, cars, birds, cats, deer, dogs, frogs, horses, ships and trucks.

CIFAR-100

50,000

100

Similar to CIFAR-10 but with 100 classes and 600 images each.

OUI-Adience-Age

26,580

8

8 age groups/labels (0-2, 4-6, 8-13, 15-20, 25-32, 38-43, 48-53, 60-).

ImageNet-10-1

9,750

10

Coffee mug, computer keyboard, dining table, wardrobe, lawn mower, microphone, swing, sewing machine, odometer and gas pump.

ImageNet-10-2

9,750

10

Drum, banj, whistle, grand piano, violin, organ, acoustic guitar, trombone, flute and sax.

We do not change the default fine-tuning technique in their source code. In order to match each task, the codes of input image shape and output numbers are changed.

Search phase time for all NAS methods is two days as well as the retrain time. Average results are reported based on three repeat times. Our evaluation machines have one Nvidia Tesla P100 GPU, 112GB of RAM and one 2.60GHz CPU (Intel E5-2690).

For NAO, it requires too much computing resources, so we only use NAO-WS which provides the pipeline script.

For AutoKeras, we used 0.2.18 version because it was the latest version when we started the experiment.

NAS Performance

NAS

AutoKeras (%)

ENAS (macro) (%)

ENAS (micro) (%)

DARTS (%)

NAO-WS (%)

Fashion-MNIST

91.84

95.44

95.53

95.74

95.20

CIFAR-10

75.78

95.68

96.16

94.23

95.64

CIFAR-100

43.61

78.13

78.84

79.74

75.75

OUI-Adience-Age

63.20

80.34

78.55

76.83

72.96

ImageNet-10-1

61.80

77.07

79.80

80.48

77.20

ImageNet-10-2

37.20

58.13

56.47

60.53

61.20

Unfortunately, we cannot reproduce all the results in the paper.

The best or average results reported in the paper:

NAS

AutoKeras(%)

ENAS (macro) (%)

ENAS (micro) (%)

DARTS (%)

NAO-WS (%)

CIFAR- 10

88.56(best)

96.13(best)

97.11(best)

97.17(average)

96.47(best)

For AutoKeras, it has relatively worse performance across all datasets due to its random factor on network morphism.

For ENAS, ENAS (macro) shows good results in OUI-Adience-Age and ENAS (micro) shows good results in CIFAR-10.

For DARTS, it has a good performance on some datasets but we found its high variance in other datasets. The difference among three runs of benchmarks can be up to 5.37% in OUI-Adience-Age and 4.36% in ImageNet-10-1.

For NAO-WS, it shows good results in ImageNet-10-2 but it can perform very poorly in OUI-Adience-Age.

Reference
  1. Jin, Haifeng, Qingquan Song, and Xia Hu. “Efficient neural architecture search with network morphism.” arXiv preprint arXiv:1806.10282 (2018).

  2. Liu, Hanxiao, Karen Simonyan, and Yiming Yang. “Darts: Differentiable architecture search.” arXiv preprint arXiv:1806.09055 (2018).

  3. Pham, Hieu, et al. “Efficient Neural Architecture Search via Parameters Sharing.” international conference on machine learning (2018): 4092-4101.

  4. Luo, Renqian, et al. “Neural Architecture Optimization.” neural information processing systems (2018): 7827-7838.

Hyper Parameter Optimization Comparison

Posted by Anonymous Author

Comparison of Hyperparameter Optimization (HPO) algorithms on several problems.

Hyperparameter Optimization algorithms are list below:

All algorithms run in NNI local environment.

Machine Environment:

OS: Linux Ubuntu 16.04 LTS
CPU: Intel(R) Xeon(R) CPU E5-2690 v3 @ 2.60GHz 2600 MHz
Memory: 112 GB
NNI Version: v0.7
NNI Mode(local|pai|remote): local
Python version: 3.6
Is conda or virtualenv used?: Conda
is running in docker?: no
AutoGBDT Example
Problem Description

Nonconvex problem on the hyper-parameter search of AutoGBDT example.

Search Space
{
  "num_leaves": {
    "_type": "choice",
    "_value": [10, 12, 14, 16, 18, 20, 22, 24, 28, 32, 48, 64, 96, 128]
  },
  "learning_rate": {
    "_type": "choice",
    "_value": [0.00001, 0.0001, 0.001, 0.01, 0.05, 0.1, 0.2, 0.5]
  },
  "max_depth": {
    "_type": "choice",
    "_value": [-1, 2, 3, 4, 5, 6, 8, 10, 12, 14, 16, 18, 20, 22, 24, 28, 32, 48, 64, 96, 128]
  },
  "feature_fraction": {
    "_type": "choice",
    "_value": [0.9, 0.8, 0.7, 0.6, 0.5, 0.4, 0.3, 0.2]
  },
  "bagging_fraction": {
    "_type": "choice",
    "_value": [0.9, 0.8, 0.7, 0.6, 0.5, 0.4, 0.3, 0.2]
  },
  "bagging_freq": {
    "_type": "choice",
    "_value": [1, 2, 4, 8, 10, 12, 14, 16]
  }
}

The total search space is 1,204,224, we set the number of maximum trial to 1000. The time limitation is 48 hours.

Results

Algorithm

Best loss

Average of Best 5 Losses

Average of Best 10 Losses

Random Search

0.418854

0.420352

0.421553

Random Search

0.417364

0.420024

0.420997

Random Search

0.417861

0.419744

0.420642

Grid Search

0.498166

0.498166

0.498166

Evolution

0.409887

0.409887

0.409887

Evolution

0.413620

0.413875

0.414067

Evolution

0.409887

0.409887

0.409887

Anneal

0.414877

0.417289

0.418281

Anneal

0.409887

0.409887

0.410118

Anneal

0.413683

0.416949

0.417537

Metis

0.416273

0.420411

0.422380

Metis

0.420262

0.423175

0.424816

Metis

0.421027

0.424172

0.425714

TPE

0.414478

0.414478

0.414478

TPE

0.415077

0.417986

0.418797

TPE

0.415077

0.417009

0.418053

SMAC

0.408386

0.408386

0.408386

SMAC

0.414012

0.414012

0.414012

SMAC

0.408386

0.408386

0.408386

BOHB

0.410464

0.415319

0.417755

BOHB

0.418995

0.420268

0.422604

BOHB

0.415149

0.418072

0.418932

HyperBand

0.414065

0.415222

0.417628

HyperBand

0.416807

0.417549

0.418828

HyperBand

0.415550

0.415977

0.417186

GP

0.414353

0.418563

0.420263

GP

0.414395

0.418006

0.420431

GP

0.412943

0.416566

0.418443

In this example, all the algorithms are used with default parameters. For Metis, there are about 300 trials because it runs slowly due to its high time complexity O(n^3) in Gaussian Process.

RocksDB Benchmark ‘fillrandom’ and ‘readrandom’
Problem Description

DB_Bench is the main tool that is used to benchmark RocksDB‘s performance. It has so many hapermeter to tune.

The performance of DB_Bench is associated with the machine configuration and installation method. We run the DB_Benchin the Linux machine and install the Rock in shared library.

Machine configuration
RocksDB:    version 6.1
CPU:        6 * Intel(R) Xeon(R) CPU E5-2690 v4 @ 2.60GHz
CPUCache:   35840 KB
Keys:       16 bytes each
Values:     100 bytes each (50 bytes after compression)
Entries:    1000000
Storage performance

Latency: each IO request will take some time to complete, this is called the average latency. There are several factors that would affect this time including network connection quality and hard disk IO performance.

IOPS: IO operations per second, which means the amount of read or write operations that could be done in one seconds time.

IO size: the size of each IO request. Depending on the operating system and the application/service that needs disk access it will issue a request to read or write a certain amount of data at the same time.

Throughput (in MB/s) = Average IO size x IOPS

IOPS is related to online processing ability and we use the IOPS as the metric in my experiment.

Search Space
{
  "max_background_compactions": {
    "_type": "quniform",
    "_value": [1, 256, 1]
  },
  "block_size": {
    "_type": "quniform",
    "_value": [1, 500000, 1]
  },
  "write_buffer_size": {
    "_type": "quniform",
    "_value": [1, 130000000, 1]
  },
  "max_write_buffer_number": {
    "_type": "quniform",
    "_value": [1, 128, 1]
  },
  "min_write_buffer_number_to_merge": {
    "_type": "quniform",
    "_value": [1, 32, 1]
  },
  "level0_file_num_compaction_trigger": {
    "_type": "quniform",
    "_value": [1, 256, 1]
  },
  "level0_slowdown_writes_trigger": {
    "_type": "quniform",
    "_value": [1, 1024, 1]
  },
  "level0_stop_writes_trigger": {
    "_type": "quniform",
    "_value": [1, 1024, 1]
  },
  "cache_size": {
    "_type": "quniform",
    "_value": [1, 30000000, 1]
  },
  "compaction_readahead_size": {
    "_type": "quniform",
    "_value": [1, 30000000, 1]
  },
  "new_table_reader_for_compaction_inputs": {
    "_type": "randint",
    "_value": [1]
  }
}

The search space is enormous (about 10^40) and we set the maximum number of trial to 100 to limit the computation resource.

Results
fillrandom’ Benchmark

Model

Best IOPS (Repeat 1)

Best IOPS (Repeat 2)

Best IOPS (Repeat 3)

Random

449901

427620

477174

Anneal

461896

467150

437528

Evolution

436755

389956

389790

TPE

378346

482316

468989

SMAC

491067

490472

491136

Metis

444920

457060

454438

Figure:

‘readrandom’ Benchmark

Model

Best IOPS (Repeat 1)

Best IOPS (Repeat 2)

Best IOPS (Repeat 3)

Random

2276157

2285301

2275142

Anneal

2286330

2282229

2284012

Evolution

2286524

2283673

2283558

TPE

2287366

2282865

2281891

SMAC

2270874

2284904

2282266

Metis

2287696

2283496

2277701

Figure:

Comparison of Filter Pruning Algorithms

To provide an initial insight into the performance of various filter pruning algorithms, we conduct extensive experiments with various pruning algorithms on some benchmark models and datasets. We present the experiment result in this document. In addition, we provide friendly instructions on the re-implementation of these experiments to facilitate further contributions to this effort.

Experiment Setting

The experiments are performed with the following pruners/datasets/models:

  • Models: VGG16, ResNet18, ResNet50

  • Datasets: CIFAR-10

  • Pruners:

    • These pruners are included:

      • Pruners with scheduling : SimulatedAnnealing Pruner, NetAdapt Pruner, AutoCompress Pruner. Given the overal sparsity requirement, these pruners can automatically generate a sparsity distribution among different layers.

      • One-shot pruners: L1Filter Pruner, L2Filter Pruner, FPGM Pruner. The sparsity of each layer is set the same as the overall sparsity in this experiment.

    • Only filter pruning performances are compared here.

      For the pruners with scheduling, L1Filter Pruner is used as the base algorithm. That is to say, after the sparsities distribution is decided by the scheduling algorithm, L1Filter Pruner is used to performn real pruning.

    • All the pruners listed above are implemented in nni.

Experiment Result

For each dataset/model/pruner combination, we prune the model to different levels by setting a series of target sparsities for the pruner.

Here we plot both Number of Weights - Performances curve and FLOPs - Performance curve. As a reference, we also plot the result declared in the paper AutoCompress: An Automatic DNN Structured Pruning Framework for Ultra-High Compression Rates for models VGG16 and ResNet18 on CIFAR-10.

The experiment result are shown in the following figures:

CIFAR-10, VGG16:

CIFAR-10, ResNet18:

CIFAR-10, ResNet50:

Analysis

From the experiment result, we get the following conclusions:

  • Given the constraint on the number of parameters, the pruners with scheduling ( AutoCompress Pruner , SimualatedAnnealing Pruner ) performs better than the others when the constraint is strict. However, they have no such advantage in FLOPs/Performances comparison since only number of parameters constraint is considered in the optimization process;

  • The basic algorithms L1Filter Pruner , L2Filter Pruner , FPGM Pruner performs very similarly in these experiments;

  • NetAdapt Pruner can not achieve very high compression rate. This is caused by its mechanism that it prunes only one layer each pruning iteration. This leads to un-acceptable complexity if the sparsity per iteration is much lower than the overall sparisity constraint.

Experiments Reproduction
Implementation Details
  • The experiment results are all collected with the default configuration of the pruners in nni, which means that when we call a pruner class in nni, we don’t change any default class arguments.

  • Both FLOPs and the number of parameters are counted with Model FLOPs/Parameters Counter after model speed up. This avoids potential issues of counting them of masked models.

  • The experiment code can be found here.

Experiment Result Rendering
  • If you follow the practice in the example, for every single pruning experiment, the experiment result will be saved in JSON format as follows:

    {
        "performance": {"original": 0.9298, "pruned": 0.1, "speedup": 0.1, "finetuned": 0.7746},
        "params": {"original": 14987722.0, "speedup": 167089.0},
        "flops": {"original": 314018314.0, "speedup": 38589922.0}
    }
    
  • The experiment results are saved here. You can refer to analyze to plot new performance comparison figures.

Contribution
TODO Items
  • Pruners constrained by FLOPS/latency

  • More pruning algorithms/datasets/models

Issues

For algorithm implementation & experiment issues, please create an issue.

Use NNI on Google Colab

NNI can easily run on Google Colab platform. However, Colab doesn’t expose its public IP and ports, so by default you can not access NNI’s Web UI on Colab. To solve this, you need a reverse proxy software like ngrok or frp. This tutorial will show you how to use ngrok to access NNI’s Web UI on Colab.

How to Open NNI’s Web UI on Google Colab
  1. Install required packages and softwares.

! pip install nni # install nni
! wget https://bin.equinox.io/c/4VmDzA7iaHb/ngrok-stable-linux-amd64.zip # download ngrok and unzip it
! unzip ngrok-stable-linux-amd64.zip
! mkdir -p nni_repo
! git clone https://github.com/microsoft/nni.git nni_repo/nni # clone NNI's offical repo to get examples
  1. Register a ngrok account here, then connect to your account using your authtoken.

! ./ngrok authtoken <your-authtoken>
  1. Start an NNI example on a port bigger than 1024, then start ngrok with the same port. If you want to use gpu, make sure gpuNum >= 1 in config.yml. Use get_ipython() to start ngrok since it will be stuck if you use ! ngrok http 5000 &.

! nnictl create --config nni_repo/nni/examples/trials/mnist-pytorch/config.yml --port 5000 &
get_ipython().system_raw('./ngrok http 5000 &')
  1. Check the public url.

! curl -s http://localhost:4040/api/tunnels # don't change the port number 4040

You will see an url like http://xxxx.ngrok.io after step 4, open this url and you will find NNI’s Web UI. Have fun :)

Access Web UI with frp

frp is another reverse proxy software with similar functions. However, frp doesn’t provide free public urls, so you may need an server with public IP as a frp server. See here to know more about how to deploy frp.

Auto Completion for nnictl Commands

NNI’s command line tool nnictl support auto-completion, i.e., you can complete a nnictl command by pressing the tab key.

For example, if the current command is

nnictl cre

By pressing the tab key, it will be completed to

nnictl create

For now, auto-completion will not be enabled by default if you install NNI through pip, and it only works on Linux with bash shell. If you want to enable this feature on your computer, please refer to the following steps:

Step 1. Download bash-completion
cd ~
wget https://raw.githubusercontent.com/microsoft/nni/{nni-version}/tools/bash-completion

Here, {nni-version} should by replaced by the version of NNI, e.g., master, v2.2. You can also check the latest bash-completion script here.

Step 2. Install the script

If you are running a root account and want to install this script for all the users

install -m644 ~/bash-completion /usr/share/bash-completion/completions/nnictl

If you just want to install this script for your self

mkdir -p ~/.bash_completion.d
install -m644 ~/bash-completion ~/.bash_completion.d/nnictl
echo '[[ -f ~/.bash_completion.d/nnictl ]] && source ~/.bash_completion.d/nnictl' >> ~/.bash_completion
Step 3. Reopen your terminal

Reopen your terminal and you should be able to use the auto-completion feature. Enjoy!

Step 4. Uninstall

If you want to uninstall this feature, just revert the changes in the steps above.

External Repositories and References

With authors’ permission, we listed a set of NNI usage examples and relevant articles.

External Repositories

Research and Publications

We are intensively working on both tool chain and research to make automatic model design and tuning really practical and powerful. On the one hand, our main work is tool chain oriented development. On the other hand, our research works aim to improve this tool chain, rethink challenging problems in AutoML (on both system and algorithm) and propose elegant solutions. Below we list some of our research works, we encourage more research works on this topic and encourage collaboration with us.

System Research

@inproceedings{zhang2020retiarii,
  title={Retiarii: A Deep Learning Exploratory-Training Framework},
  author={Zhang, Quanlu and Han, Zhenhua and Yang, Fan and Zhang, Yuge and Liu, Zhe and Yang, Mao and Zhou, Lidong},
  booktitle={14th $\{$USENIX$\}$ Symposium on Operating Systems Design and Implementation ($\{$OSDI$\}$ 20)},
  pages={919--936},
  year={2020}
}
@inproceedings{liang2020autosys,
  title={AutoSys: The Design and Operation of Learning-Augmented Systems},
  author={Liang, Chieh-Jan Mike and Xue, Hui and Yang, Mao and Zhou, Lidong and Zhu, Lifei and Li, Zhao Lucis and Wang, Zibo and Chen, Qi and Zhang, Quanlu and Liu, Chuanjie and others},
  booktitle={2020 $\{$USENIX$\}$ Annual Technical Conference ($\{$USENIX$\}$$\{$ATC$\}$ 20)},
  pages={323--336},
  year={2020}
}
@inproceedings{xiao2018gandiva,
  title={Gandiva: Introspective cluster scheduling for deep learning},
  author={Xiao, Wencong and Bhardwaj, Romil and Ramjee, Ramachandran and Sivathanu, Muthian and Kwatra, Nipun and Han, Zhenhua and Patel, Pratyush and Peng, Xuan and Zhao, Hanyu and Zhang, Quanlu and others},
  booktitle={13th $\{$USENIX$\}$ Symposium on Operating Systems Design and Implementation ($\{$OSDI$\}$ 18)},
  pages={595--610},
  year={2018}
}

Algorithm Research

New Algorithms

@inproceedings{wang2020textnas,
  title={TextNAS: A Neural Architecture Search Space Tailored for Text Representation.},
  author={Wang, Yujing and Yang, Yaming and Chen, Yiren and Bai, Jing and Zhang, Ce and Su, Guinan and Kou, Xiaoyu and Tong, Yunhai and Yang, Mao and Zhou, Lidong},
  booktitle={AAAI},
  pages={9242--9249},
  year={2020}
}
@article{peng2020cream,
  title={Cream of the Crop: Distilling Prioritized Paths For One-Shot Neural Architecture Search},
  author={Peng, Houwen and Du, Hao and Yu, Hongyuan and Li, Qi and Liao, Jing and Fu, Jianlong},
  journal={Advances in Neural Information Processing Systems},
  volume={33},
  year={2020}
}
@inproceedings{li2018metis,
  title={Metis: Robustly tuning tail latencies of cloud systems},
  author={Li, Zhao Lucis and Liang, Chieh-Jan Mike and He, Wenjia and Zhu, Lianjie and Dai, Wenjun and Jiang, Jin and Sun, Guangzhong},
  booktitle={2018 $\{$USENIX$\}$ Annual Technical Conference ($\{$USENIX$\}$$\{$ATC$\}$ 18)},
  pages={981--992},
  year={2018}
}
@article{gao2020opevo,
  title={OpEvo: An Evolutionary Method for Tensor Operator Optimization},
  author={Gao, Xiaotian and Wei, Cui and Zhang, Lintao and Yang, Mao},
  journal={arXiv preprint arXiv:2006.05664},
  year={2020}
}

Measurement and Understanding

@article{zhang2020deeper,
  title={Deeper insights into weight sharing in neural architecture search},
  author={Zhang, Yuge and Lin, Zejun and Jiang, Junyang and Zhang, Quanlu and Wang, Yujing and Xue, Hui and Zhang, Chen and Yang, Yaming},
  journal={arXiv preprint arXiv:2001.01431},
  year={2020}
}
@article{zhang2020does,
  title={How Does Supernet Help in Neural Architecture Search?},
  author={Zhang, Yuge and Zhang, Quanlu and Yang, Yaming},
  journal={arXiv preprint arXiv:2010.08219},
  year={2020}
}

Applications

@inproceedings{chen2020autoadr,
  title={AutoADR: Automatic Model Design for Ad Relevance},
  author={Chen, Yiren and Yang, Yaming and Sun, Hong and Wang, Yujing and Xu, Yu and Shen, Wei and Zhou, Rong and Tong, Yunhai and Bai, Jing and Zhang, Ruofei},
  booktitle={Proceedings of the 29th ACM International Conference on Information \& Knowledge Management},
  pages={2365--2372},
  year={2020}
}

FAQ

This page is for frequent asked questions and answers.

tmp folder fulled

nnictl will use tmp folder as a temporary folder to copy files under codeDir when executing experimentation creation. When met errors like below, try to clean up tmp folder first.

OSError: [Errno 28] No space left on device

Cannot get trials’ metrics in OpenPAI mode

In OpenPAI training mode, we start a rest server which listens on 51189 port in NNI Manager to receive metrcis reported from trials running in OpenPAI cluster. If you didn’t see any metrics from WebUI in OpenPAI mode, check your machine where NNI manager runs on to make sure 51189 port is turned on in the firewall rule.

Segmentation Fault (core dumped) when installing

make: *** [install-XXX] Segmentation fault (core dumped)

Please try the following solutions in turn:

  • Update or reinstall you current python’s pip like python3 -m pip install -U pip

  • Install NNI with --no-cache-dir flag like python3 -m pip install nni --no-cache-dir

Job management error: getIPV4Address() failed because os.networkInterfaces().eth0 is undefined.

Your machine don’t have eth0 device, please set nniManagerIp in your config file manually.

Exceed the MaxDuration but didn’t stop

When the duration of experiment reaches the maximum duration, nniManager will not create new trials, but the existing trials will continue unless user manually stop the experiment.

Could not stop an experiment using nnictl stop

If you upgrade your NNI or you delete some config files of NNI when there is an experiment running, this kind of issue may happen because the loss of config file. You could use ps -ef | grep node to find the PID of your experiment, and use kill -9 {pid} to kill it manually.

Could not get default metric in webUI of virtual machines

Config the network mode to bridge mode or other mode that could make virtual machine’s host accessible from external machine, and make sure the port of virtual machine is not forbidden by firewall.

Restful server start failed

Probably it’s a problem with your network config. Here is a checklist.

  • You might need to link 127.0.0.1 with localhost. Add a line 127.0.0.1 localhost to /etc/hosts.

  • It’s also possible that you have set some proxy config. Check your environment for variables like HTTP_PROXY or HTTPS_PROXY and unset if they are set.

NNI on Windows problems

Please refer to NNI on Windows

Help us improve

Please inquiry the problem in https://github.com/Microsoft/nni/issues to see whether there are other people already reported the problem, create a new one if there are no existing issues been created.

Contribute to NNI

Setup NNI development environment

NNI development environment supports Ubuntu 1604 (or above), and Windows 10 with Python3 64bit.

Installation

1. Clone source code
git clone https://github.com/Microsoft/nni.git

Note, if you want to contribute code back, it needs to fork your own NNI repo, and clone from there.

2. Install from source code
python3 -m pip install --upgrade pip setuptools
python3 setup.py develop

This installs NNI in development mode, so you don’t need to reinstall it after edit.

3. Check if the environment is ready

Now, you can try to start an experiment to check if your environment is ready. For example, run the command

nnictl create --config examples/trials/mnist-pytorch/config.yml

And open WebUI to check if everything is OK

4. Reload changes
Python

Nothing to do, the code is already linked to package folders.

TypeScript (Linux and macOS)
  • If ts/nni_manager is changed, run yarn watch under this folder. It will watch and build code continually. The nnictl need to be restarted to reload NNI manager.

  • If ts/webui is changed, run yarn dev, which will run a mock API server and a webpack dev server simultaneously. Use EXPERIMENT environment variable (e.g., mnist-tfv1-running) to specify the mock data being used. Built-in mock experiments are listed in src/webui/mock. An example of the full command is EXPERIMENT=mnist-tfv1-running yarn dev.

  • If ts/nasui is changed, run yarn start under the corresponding folder. The web UI will refresh automatically if code is changed. There is also a mock API server that is useful when developing. It can be launched via node server.js.

TypeScript (Windows)

Currently you must rebuild TypeScript modules with python3 setup.py build_ts after edit.

5. Submit Pull Request

All changes are merged to master branch from your forked repo. The description of Pull Request must be meaningful, and useful.

We will review the changes as soon as possible. Once it passes review, we will merge it to master branch.

For more contribution guidelines and coding styles, you can refer to the contributing document.

Contributing to Neural Network Intelligence (NNI)

Great!! We are always on the lookout for more contributors to our code base.

Firstly, if you are unsure or afraid of anything, just ask or submit the issue or pull request anyways. You won’t be yelled at for giving your best effort. The worst that can happen is that you’ll be politely asked to change something. We appreciate any sort of contributions and don’t want a wall of rules to get in the way of that.

However, for those individuals who want a bit more guidance on the best way to contribute to the project, read on. This document will cover all the points we’re looking for in your contributions, raising your chances of quickly merging or addressing your contributions.

Looking for a quickstart, get acquainted with our Get Started guide.

There are a few simple guidelines that you need to follow before providing your hacks.

Raising Issues

When raising issues, please specify the following:

  • Setup details needs to be filled as specified in the issue template clearly for the reviewer to check.

  • A scenario where the issue occurred (with details on how to reproduce it).

  • Errors and log messages that are displayed by the software.

  • Any other details that might be useful.

Submit Proposals for New Features

  • There is always something more that is required, to make it easier to suit your use-cases. Feel free to join the discussion on new features or raise a PR with your proposed change.

  • Fork the repository under your own github handle. After cloning the repository. Add, commit, push and sqaush (if necessary) the changes with detailed commit messages to your fork. From where you can proceed to making a pull request.

Contributing to Source Code and Bug Fixes

Provide PRs with appropriate tags for bug fixes or enhancements to the source code. Do follow the correct naming conventions and code styles when you work on and do try to implement all code reviews along the way.

If you are looking for How to develop and debug the NNI source code, you can refer to How to set up NNI developer environment doc file in the docs folder.

Similarly for Quick Start. For everything else, refer to NNI Home page.

Solve Existing Issues

Head over to issues to find issues where help is needed from contributors. You can find issues tagged with ‘good-first-issue’ or ‘help-wanted’ to contribute in.

A person looking to contribute can take up an issue by claiming it as a comment/assign their Github ID to it. In case there is no PR or update in progress for a week on the said issue, then the issue reopens for anyone to take up again. We need to consider high priority issues/regressions where response time must be a day or so.

Code Styles & Naming Conventions

  • We follow PEP8 for Python code and naming conventions, do try to adhere to the same when making a pull request or making a change. One can also take the help of linters such as flake8 or pylint

  • We also follow NumPy Docstring Style for Python Docstring Conventions. During the documentation building, we use sphinx.ext.napoleon to generate Python API documentation from Docstring.

  • For docstrings, please refer to numpydoc docstring guide and pandas docstring guide

    • For function docstring, description, Parameters, and Returns Yields are mandatory.

    • For class docstring, description, Attributes are mandatory.

    • For docstring to describe dict, which is commonly used in our hyper-param format description, please refer to Internal Guideline on Writing Standards

Documentation

Our documentation is built with sphinx.

  • Before submitting the documentation change, please build homepage locally: cd docs/en_US && make html, then you can see all the built documentation webpage under the folder docs/en_US/_build/html. It’s also highly recommended taking care of every WARNING during the build, which is very likely the signal of a deadlink and other annoying issues.

  • For links, please consider using relative paths first. However, if the documentation is written in Markdown format, and:

    • It’s an image link which needs to be formatted with embedded html grammar, please use global URL like https://user-images.githubusercontent.com/44491713/51381727-e3d0f780-1b4f-11e9-96ab-d26b9198ba65.png, which can be automatically generated by dragging picture onto Github Issue Box.

    • It cannot be re-formatted by sphinx, such as source code, please use its global URL. For source code that links to our github repo, please use URLs rooted at https://github.com/Microsoft/nni/tree/v2.2/ (mnist.py for example).

Change Log

Release 2.2 - 4/26/2021

Major updates

Model Compression
  • Support speedup for mixed precision quantization model (Experimental) (#3488 #3512)

  • Support model export for quantization algorithm (#3458 #3473)

  • Support model export in model compression for TensorFlow (#3487)

  • Improve documentation (#3482)

nnictl & nni.experiment
  • Add native support for experiment config V2 (#3466 #3540 #3552)

  • Add resume and view mode in Python API nni.experiment (#3490 #3524 #3545)

Training Service
  • Support umount for shared storage in remote training service (#3456)

  • Support Windows as the remote training service in reuse mode (#3500)

  • Remove duplicated env folder in remote training service (#3472)

  • Add log information for GPU metric collector (#3506)

  • Enable optional Pod Spec for FrameworkController platform (#3379, thanks the external contributor @mbu93)

WebUI
  • Support launching TensorBoard on WebUI (#3454 #3361 #3531)

  • Upgrade echarts-for-react to v5 (#3457)

  • Add wrap for dispatcher/nnimanager log monaco editor (#3461)

Bug Fixes

  • Fix bug of FLOPs counter (#3497)

  • Fix bug of hyper-parameter Add/Remove axes and table Add/Remove columns button conflict (#3491)

  • Fix bug that monaco editor search text is not displayed completely (#3492)

  • Fix bug of Cream NAS (#3498, thanks the external contributor @AliCloud-PAI)

  • Fix typos in docs (#3448, thanks the external contributor @OliverShang)

  • Fix typo in NAS 1.0 (#3538, thanks the external contributor @ankitaggarwal23)

Release 2.1 - 3/10/2021

Major updates

Neural architecture search
  • Improve NAS 2.0 (Retiarii) Framework (Improved Experimental)

    • Improve the robustness of graph generation and code generation for PyTorch models (#3365)

    • Support the inline mutation API ValueChoice (#3349 #3382)

    • Improve the design and implementation of Model Evaluator (#3359 #3404)

    • Support Random/Grid/Evolution exploration strategies (i.e., search algorithms) (#3377)

    • Refer to here for Retiarii Roadmap

Training service
  • Support shared storage for reuse mode (#3354)

  • Support Windows as the local training service in hybrid mode (#3353)

  • Remove PAIYarn training service (#3327)

  • Add “recently-idle” scheduling algorithm (#3375)

  • Deprecate preCommand and enable pythonPath for remote training service (#3284 #3410)

  • Refactor reuse mode temp folder (#3374)

nnictl & nni.experiment
  • Migrate nnicli to new Python API nni.experiment (#3334)

  • Refactor the way of specifying tuner in experiment Python API (nni.experiment), more aligned with nnictl (#3419)

WebUI
  • Support showing the assigned training service of each trial in hybrid mode on WebUI (#3261 #3391)

  • Support multiple selection for filter status in experiments management page (#3351)

  • Improve overview page (#3316 #3317 #3352)

  • Support copy trial id in the table (#3378)

Documentation

  • Improve model compression examples and documentation (#3326 #3371)

  • Add Python API examples and documentation (#3396)

  • Add SECURITY doc (#3358)

  • Add ‘What’s NEW!’ section in README (#3395)

  • Update English contributing doc (#3398, thanks external contributor @Yongxuanzhang)

Bug fixes

  • Fix AML outputs path and python process not killed (#3321)

  • Fix bug that an experiment launched from Python cannot be resumed by nnictl (#3309)

  • Fix import path of network morphism example (#3333)

  • Fix bug in the tuple unpack (#3340)

  • Fix bug of security for arbitrary code execution (#3311, thanks external contributor @huntr-helper)

  • Fix NoneType error on jupyter notebook (#3337, thanks external contributor @tczhangzhi)

  • Fix bugs in Retiarii (#3339 #3341 #3357, thanks external contributor @tczhangzhi)

  • Fix bug in AdaptDL mode example (#3381, thanks external contributor @ZeyaWang)

  • Fix the spelling mistake of assessor (#3416, thanks external contributor @ByronCHAO)

  • Fix bug in ruamel import (#3430, thanks external contributor @rushtehrani)

Release 2.0 - 1/14/2021

Major updates

Neural architecture search
  • Support an improved NAS framework: Retiarii (experimental)

  • Support a new NAS algorithm: Cream (#2705)

  • Add a new NAS benchmark for NLP model search (#3140)

Training service
  • Support hybrid training service (#3097 #3251 #3252)

  • Support AdlTrainingService, a new training service based on Kubernetes (#3022, thanks external contributors Petuum @pw2393)

Model compression
  • Support pruning schedule for fpgm pruning algorithm (#3110)

  • ModelSpeedup improvement: support torch v1.7 (updated graph_utils.py) (#3076)

  • Improve model compression utility: model flops counter (#3048 #3265)

WebUI & nnictl
  • Support experiments management on WebUI, add a web page for it (#3081 #3127)

  • Improve the layout of overview page (#3046 #3123)

  • Add navigation bar on the right for logs and configs; add expanded icons for table (#3069 #3103)

Others
  • Support launching an experiment from Python code (#3111 #3210 #3263)

  • Refactor builtin/customized tuner installation (#3134)

  • Support new experiment configuration V2 (#3138 #3248 #3251)

  • Reorganize source code directory hierarchy (#2962 #2987 #3037)

  • Change SIGKILL to SIGTERM in local mode when cancelling trial jobs (#3173)

  • Refector hyperband (#3040)

Documentation

  • Port markdown docs to reStructuredText docs and introduce githublink (#3107)

  • List related research and publications in doc (#3150)

  • Add tutorial of saving and loading quantized model (#3192)

  • Remove paiYarn doc and add description of reuse config in remote mode (#3253)

  • Update EfficientNet doc to clarify repo versions (#3158, thanks external contributor @ahundt)

Bug fixes

  • Fix exp-duration pause timing under NO_MORE_TRIAL status (#3043)

  • Fix bug in NAS SPOS trainer, apply_fixed_architecture (#3051, thanks external contributor @HeekangPark)

  • Fix _compute_hessian bug in NAS DARTS (PyTorch version) (#3058, thanks external contributor @hroken)

  • Fix bug of conv1d in the cdarts utils (#3073, thanks external contributor @athaker)

  • Fix the handling of unknown trials when resuming an experiment (#3096)

  • Fix bug of kill command under Windows (#3106)

  • Fix lazy logging (#3108, thanks external contributor @HarshCasper)

  • Fix checkpoint load and save issue in QAT quantizer (#3124, thanks external contributor @eedalong)

  • Fix quant grad function calculation error (#3160, thanks external contributor @eedalong)

  • Fix device assignment bug in quantization algorithm (#3212, thanks external contributor @eedalong)

  • Fix bug in ModelSpeedup and enhance UT for it (#3279)

  • and others (#3063 #3065 #3098 #3109 #3125 #3143 #3156 #3168 #3175 #3180 #3181 #3183 #3203 #3205 #3207 #3214 #3216 #3219 #3223 #3224 #3230 #3237 #3239 #3240 #3245 #3247 #3255 #3257 #3258 #3262 #3263 #3267 #3269 #3271 #3279 #3283 #3289 #3290 #3295)

Release 1.9 - 10/22/2020

Major updates

Neural architecture search
  • Support regularized evolution algorithm for NAS scenario (#2802)

  • Add NASBench201 in search space zoo (#2766)

Model compression
  • AMC pruner improvement: support resnet, support reproduction of the experiments (default parameters in our example code) in AMC paper (#2876 #2906)

  • Support constraint-aware on some of our pruners to improve model compression efficiency (#2657)

  • Support “tf.keras.Sequential” in model compression for TensorFlow (#2887)

  • Support customized op in the model flops counter (#2795)

  • Support quantizing bias in QAT quantizer (#2914)

Training service
  • Support configuring python environment using “preCommand” in remote mode (#2875)

  • Support AML training service in Windows (#2882)

  • Support reuse mode for remote training service (#2923)

WebUI & nnictl
  • The “Overview” page on WebUI is redesigned with new layout (#2914)

  • Upgraded node, yarn and FabricUI, and enabled Eslint (#2894 #2873 #2744)

  • Add/Remove columns in hyper-parameter chart and trials table in “Trials detail” page (#2900)

  • JSON format utility beautify on WebUI (#2863)

  • Support nnictl command auto-completion (#2857)

UT & IT

  • Add integration test for experiment import and export (#2878)

  • Add integration test for user installed builtin tuner (#2859)

  • Add unit test for nnictl (#2912)

Documentation

  • Refactor of the document for model compression (#2919)

Bug fixes

  • Bug fix of naïve evolution tuner, correctly deal with trial fails (#2695)

  • Resolve the warning “WARNING (nni.protocol) IPC pipeline not exists, maybe you are importing tuner/assessor from trial code?” (#2864)

  • Fix search space issue in experiment save/load (#2886)

  • Fix bug in experiment import data (#2878)

  • Fix annotation in remote mode (python 3.8 ast update issue) (#2881)

  • Support boolean type for “choice” hyper-parameter when customizing trial configuration on WebUI (#3003)

Release 1.8 - 8/27/2020

Major updates

Training service
  • Access trial log directly on WebUI (local mode only) (#2718)

  • Add OpenPAI trial job detail link (#2703)

  • Support GPU scheduler in reusable environment (#2627) (#2769)

  • Add timeout for web_channel in trial_runner (#2710)

  • Show environment error message in AzureML mode (#2724)

  • Add more log information when copying data in OpenPAI mode (#2702)

WebUI, nnictl and nnicli
  • Improve hyper-parameter parallel coordinates plot (#2691) (#2759)

  • Add pagination for trial job list (#2738) (#2773)

  • Enable panel close when clicking overlay region (#2734)

  • Remove support for Multiphase on WebUI (#2760)

  • Support save and restore experiments (#2750)

  • Add intermediate results in export result (#2706)

  • Add command to list trial results with highest/lowest metrics (#2747)

  • Improve the user experience of nnicli with examples (#2713)

Neural architecture search
Model compression
Backward incompatible changes
  • Update the default experiment folder from $HOME/nni/experiments to $HOME/nni-experiments. If you want to view the experiments created by previous NNI releases, you can move the experiments folders from $HOME/nni/experiments to $HOME/nni-experiments manually. (#2686) (#2753)

  • Dropped support for Python 3.5 and scikit-learn 0.20 (#2778) (#2777) (2783) (#2787) (#2788) (#2790)

Others
  • Upgrade TensorFlow version in Docker image (#2732) (#2735) (#2720)

Examples

  • Remove gpuNum in assessor examples (#2641)

Documentation

  • Improve customized tuner documentation (#2628)

  • Fix several typos and grammar mistakes in documentation (#2637 #2638, thanks @tomzx)

  • Improve AzureML training service documentation (#2631)

  • Improve CI of Chinese translation (#2654)

  • Improve OpenPAI training service documentation (#2685)

  • Improve documentation of community sharing (#2640)

  • Add tutorial of Colab support (#2700)

  • Improve documentation structure for model compression (#2676)

Bug fixes

  • Fix mkdir error in training service (#2673)

  • Fix bug when using chmod in remote training service (#2689)

  • Fix dependency issue by making _graph_utils imported inline (#2675)

  • Fix mask issue in SimulatedAnnealingPruner (#2736)

  • Fix intermediate graph zooming issue (#2738)

  • Fix issue when dict is unordered when querying NAS benchmark (#2728)

  • Fix import issue for gradient selector dataloader iterator (#2690)

  • Fix support of adding tens of machines in remote training service (#2725)

  • Fix several styling issues in WebUI (#2762 #2737)

  • Fix support of unusual types in metrics including NaN and Infinity (#2782)

  • Fix nnictl experiment delete (#2791)

Release 1.7 - 7/8/2020

Major Features

Training Service
Model Compression
Examples
WebUI
  • Support visualizing nested search space more friendly.

  • Show trial’s dict keys in hyper-parameter graph.

  • Enhancements to trial duration display.

Others
  • Provide utility function to merge parameters received from NNI

  • Support setting paiStorageConfigName in pai mode

Documentation

Bug Fixes

  • Fix bug for model graph with shared nn.Module

  • Fix nodejs OOM when make build

  • Fix NASUI bugs

  • Fix duration and intermediate results pictures update issue.

  • Fix minor WebUI table style issues.

Release 1.6 - 5/26/2020

Major Features

New Features and improvement

  • Improve IPC limitation to 100W

  • improve code storage upload logic among trials in non-local platform

  • support __version__ for SDK version

  • support windows dev intall

Web UI

  • Show trial error message

  • finalize homepage layout

  • Refactor overview’s best trials module

  • Remove multiphase from webui

  • add tooltip for trial concurrency in the overview page

  • Show top trials for hyper-parameter graph

HPO Updates

  • Improve PBT on failure handling and support experiment resume for PBT

NAS Updates

  • NAS support for TensorFlow 2.0 (preview) TF2.0 NAS examples

  • Use OrderedDict for LayerChoice

  • Prettify the format of export

  • Replace layer choice with selected module after applied fixed architecture

Model Compression Updates

  • Model compression PyTorch 1.4 support

Training Service Updates

  • update pai yaml merge logic

  • support windows as remote machine in remote mode Remote Mode

Bug Fix

  • fix dev install

  • SPOS example crash when the checkpoints do not have state_dict

  • Fix table sort issue when experiment had failed trial

  • Support multi python env (conda, pyenv etc)

Release 1.5 - 4/13/2020

New Features and Documentation

Hyper-Parameter Optimizing

Neural Architecture Search

Model Compression

  • New Pruner: GradientRankFilterPruner

  • Compressors will validate configuration by default

  • Refactor: Adding optimizer as an input argument of pruner, for easy support of DataParallel and more efficient iterative pruning. This is a broken change for the usage of iterative pruning algorithms.

  • Model compression examples are refactored and improved

  • Added documentation for implementing compressing algorithm

Training Service

  • Kubeflow now supports pytorchjob crd v1 (thanks external contributor @jiapinai)

  • Experimental DLTS support

Overall Documentation Improvement

  • Documentation is significantly improved on grammar, spelling, and wording (thanks external contributor @AHartNtkn)

Fixed Bugs

  • ENAS cannot have more than one LSTM layers (thanks external contributor @marsggbo)

  • NNI manager’s timers will never unsubscribe (thanks external contributor @guilhermehn)

  • NNI manager may exhaust head memory (thanks external contributor @Sundrops)

  • Batch tuner does not support customized trials (#2075)

  • Experiment cannot be killed if it failed on start (#2080)

  • Non-number type metrics break web UI (#2278)

  • A bug in lottery ticket pruner

  • Other minor glitches

Release 1.4 - 2/19/2020

Major Features

Neural Architecture Search

Model Compression

  • Support DataParallel for compressing models, and provide an example of using DataParallel

  • Support model speedup for compressed models, in Alpha version

Training Service

  • Support complete PAI configurations by allowing users to specify PAI config file path

  • Add example config yaml files for the new PAI mode (i.e., paiK8S)

  • Support deleting experiments using sshkey in remote mode (thanks external contributor @tyusr)

WebUI

  • WebUI refactor: adopt fabric framework

Others

  • Support running NNI experiment at foreground, i.e., --foreground argument in nnictl create/resume/view

  • Support canceling the trials in UNKNOWN state

  • Support large search space whose size could be up to 50mb (thanks external contributor @Sundrops)

Documentation

Bug Fixes

  • Correctly support NaN in metric data, JSON compliant

  • Fix the out-of-range bug of randint type in search space

  • Fix the bug of wrong tensor device when exporting onnx model in model compression

  • Fix incorrect handling of nnimanagerIP in the new PAI mode (i.e., paiK8S)

Release 1.3 - 12/30/2019

Major Features

Neural Architecture Search Algorithms Support

Model Compression Algorithms Support

Training Service

  • NFS Support for PAI

    Instead of using HDFS as default storage, since OpenPAI v0.11, OpenPAI can have NFS or AzureBlob or other storage as default storage. In this release, NNI extended the support for this recent change made by OpenPAI, and could integrate with OpenPAI v0.11 or later version with various default storage.

  • Kubeflow update adoption

    Adopted the Kubeflow 0.7’s new supports for tf-operator.

Engineering (code and build automation)

  • Enforced ESLint on static code analysis.

Small changes & Bug Fixes

  • correctly recognize builtin tuner and customized tuner

  • logging in dispatcher base

  • fix the bug where tuner/assessor’s failure sometimes kills the experiment.

  • Fix local system as remote machine issue

  • de-duplicate trial configuration in smac tuner ticket

Release 1.2 - 12/02/2019

Major Features

Bug fix

  • Fix the table sort issue when failed trials haven’t metrics. -Issue #1773

  • Maintain selected status(Maximal/Minimal) when the page switched. -PR#1710

  • Make hyper-parameters graph’s default metric yAxis more accurate. -PR#1736

  • Fix GPU script permission issue. -Issue #1665

Release 1.1 - 10/23/2019

Major Features

  • New tuner: PPO Tuner

  • View stopped experiments

  • Tuners can now use dedicated GPU resource (see gpuIndices in tutorial for details)

  • Web UI improvements

    • Trials detail page can now list hyperparameters of each trial, as well as their start and end time (via “add column”)

    • Viewing huge experiment is now less laggy

  • More examples

  • Model compression toolkit - Alpha release: We are glad to announce the alpha release for model compression toolkit on top of NNI, it’s still in the experiment phase which might evolve based on usage feedback. We’d like to invite you to use, feedback and even contribute

Fixed Bugs

  • Multiphase job hangs when search space exhuasted (issue #1204)

  • nnictl fails when log not available (issue #1548)

Release 1.0 - 9/2/2019

Major Features

  • Tuners and Assessors

    • Support Auto-Feature generator & selection -Issue#877 -PR #1387

    • Add a parallel algorithm to improve the performance of TPE with large concurrency. -PR #1052

    • Support multiphase for hyperband -PR #1257

  • Training Service

    • Support private docker registry -PR #755

    • Engineering Improvements

      • Python wrapper for rest api, support retrieve the values of the metrics in a programmatic way PR #1318

      • New python API : get_experiment_id(), get_trial_id() -PR #1353 -Issue #1331 & -Issue#1368

      • Optimized NAS Searchspace -PR #1393

        • Unify NAS search space with _type – “mutable_type”e

        • Update random search tuner

      • Set gpuNum as optional -Issue #1365

      • Remove outputDir and dataDir configuration in PAI mode -Issue #1342

      • When creating a trial in Kubeflow mode, codeDir will no longer be copied to logDir -Issue #1224

  • Web Portal & User Experience

    • Show the best metric curve during search progress in WebUI -Issue #1218

    • Show the current number of parameters list in multiphase experiment -Issue1210 -PR #1348

    • Add “Intermediate count” option in AddColumn. -Issue #1210

    • Support search parameters value in WebUI -Issue #1208

    • Enable automatic scaling of axes for metric value in default metric graph -Issue #1360

    • Add a detailed documentation link to the nnictl command in the command prompt -Issue #1260

    • UX improvement for showing Error log -Issue #1173

  • Documentation

    • Update the docs structure -Issue #1231

    • (deprecated) Multi phase document improvement -Issue #1233 -PR #1242

      • Add configuration example

    • WebUI description improvement -PR #1419

Bug fix

  • (Bug fix)Fix the broken links in 0.9 release -Issue #1236

  • (Bug fix)Script for auto-complete

  • (Bug fix)Fix pipeline issue that it only check exit code of last command in a script. -PR #1417

  • (Bug fix)quniform fors tuners -Issue #1377

  • (Bug fix)’quniform’ has different meaning beween GridSearch and other tuner. -Issue #1335

  • (Bug fix)”nnictl experiment list” give the status of a “RUNNING” experiment as “INITIALIZED” -PR #1388

  • (Bug fix)SMAC cannot be installed if nni is installed in dev mode -Issue #1376

  • (Bug fix)The filter button of the intermediate result cannot be clicked -Issue #1263

  • (Bug fix)API “/api/v1/nni/trial-jobs/xxx” doesn’t show a trial’s all parameters in multiphase experiment -Issue #1258

  • (Bug fix)Succeeded trial doesn’t have final result but webui show ×××(FINAL) -Issue #1207

  • (Bug fix)IT for nnictl stop -Issue #1298

  • (Bug fix)fix security warning

  • (Bug fix)Hyper-parameter page broken -Issue #1332

  • (Bug fix)Run flake8 tests to find Python syntax errors and undefined names -PR #1217

Release 0.9 - 7/1/2019

Major Features

  • General NAS programming interface

    • Add enas-mode and oneshot-mode for NAS interface: PR #1201

  • Gaussian Process Tuner with Matern kernel

  • (deprecated) Multiphase experiment supports

    • Added new training service support for multiphase experiment: PAI mode supports multiphase experiment since v0.9.

    • Added multiphase capability for the following builtin tuners:

      • TPE, Random Search, Anneal, Naïve Evolution, SMAC, Network Morphism, Metis Tuner.

  • Web Portal

  • Commandline Interface

    • nnictl experiment delete: delete one or all experiments, it includes log, result, environment information and cache. It uses to delete useless experiment result, or save disk space.

    • nnictl platform clean: It uses to clean up disk on a target platform. The provided YAML file includes the information of target platform, and it follows the same schema as the NNI configuration file.

Bug fix and other changes

  • Tuner Installation Improvements: add sklearn to nni dependencies.

  • (Bug Fix) Failed to connect to PAI http code - Issue #1076

  • (Bug Fix) Validate file name for PAI platform - Issue #1164

  • (Bug Fix) Update GMM evaluation in Metis Tuner

  • (Bug Fix) Negative time number rendering in Web Portal - Issue #1182, Issue #1185

  • (Bug Fix) Hyper-parameter not shown correctly in WebUI when there is only one hyper parameter - Issue #1192

Release 0.8 - 6/4/2019

Major Features

  • Support NNI on Windows for OpenPAI/Remote mode

    • NNI running on windows for remote mode

    • NNI running on windows for OpenPAI mode

  • Advanced features for using GPU

    • Run multiple trial jobs on the same GPU for local and remote mode

    • Run trial jobs on the GPU running non-NNI jobs

  • Kubeflow v1beta2 operator

    • Support Kubeflow TFJob/PyTorchJob v1beta2

  • General NAS programming interface

    • Provide NAS programming interface for users to easily express their neural architecture search space through NNI annotation

    • Provide a new command nnictl trial codegen for debugging the NAS code

    • Tutorial of NAS programming interface, example of NAS on MNIST, customized random tuner for NAS

  • Support resume tuner/advisor’s state for experiment resume

  • For experiment resume, tuner/advisor will be resumed by replaying finished trial data

  • Web Portal

    • Improve the design of copying trial’s parameters

    • Support ‘randint’ type in hyper-parameter graph

    • Use should ComponentUpdate to avoid unnecessary render

Bug fix and other changes

Release 0.7 - 4/29/2018

Major Features

  • Support NNI on Windows

    • NNI running on windows for local mode

  • New advisor: BOHB

    • Support a new advisor BOHB, which is a robust and efficient hyperparameter tuning algorithm, combines the advantages of Bayesian optimization and Hyperband

  • Support import and export experiment data through nnictl

    • Generate analysis results report after the experiment execution

    • Support import data to tuner and advisor for tuning

  • Designated gpu devices for NNI trial jobs

    • Specify GPU devices for NNI trial jobs by gpuIndices configuration, if gpuIndices is set in experiment configuration file, only the specified GPU devices are used for NNI trial jobs.

  • Web Portal enhancement

    • Decimal format of metrics other than default on the Web UI

    • Hints in WebUI about Multi-phase

    • Enable copy/paste for hyperparameters as python dict

    • Enable early stopped trials data for tuners.

  • NNICTL provide better error message

    • nnictl provide more meaningful error message for YAML file format error

Bug fix

  • Unable to kill all python threads after nnictl stop in async dispatcher mode

  • nnictl –version does not work with make dev-install

  • All trail jobs status stays on ‘waiting’ for long time on OpenPAI platform

Release 0.6 - 4/2/2019

Major Features

  • Version checking

    • check whether the version is consistent between nniManager and trialKeeper

  • Report final metrics for early stop job

    • If includeIntermediateResults is true, the last intermediate result of the trial that is early stopped by assessor is sent to tuner as final result. The default value of includeIntermediateResults is false.

  • Separate Tuner/Assessor

    • Adds two pipes to separate message receiving channels for tuner and assessor.

  • Make log collection feature configurable

  • Add intermediate result graph for all trials

Bug fix

  • Add shmMB config key for OpenPAI

  • Fix the bug that doesn’t show any result if metrics is dict

  • Fix the number calculation issue for float types in hyperband

  • Fix a bug in the search space conversion in SMAC tuner

  • Fix the WebUI issue when parsing experiment.json with illegal format

  • Fix cold start issue in Metis Tuner

Release 0.5.2 - 3/4/2019

Improvements

  • Curve fitting assessor performance improvement.

Documentation

Bug Fixes and Other Changes

  • Fix a race condition bug that does not store trial job cancel status correctly.

  • Fix search space parsing error when using SMAC tuner.

  • Fix cifar10 example broken pipe issue.

  • Add unit test cases for nnimanager and local training service.

  • Add integration test azure pipelines for remote machine, OpenPAI and kubeflow training services.

  • Support Pylon in OpenPAI webhdfs client.

Release 0.5.1 - 1/31/2018

Improvements

Documentation

Bug Fixes and Other Changes

  • Fix the bug of installation in python virtualenv, and refactor the installation logic

  • Fix the bug of HDFS access failure on OpenPAI mode after OpenPAI is upgraded.

  • Fix the bug that sometimes in-place flushed stdout makes experiment crash

Release 0.5.0 - 01/14/2019

Major Features

New tuner and assessor supports

  • Support Metis tuner as a new NNI tuner. Metis algorithm has been proofed to be well performed for online hyper-parameter tuning.

  • Support ENAS customized tuner, a tuner contributed by github community user, is an algorithm for neural network search, it could learn neural network architecture via reinforcement learning and serve a better performance than NAS.

  • Support Curve fitting assessor for early stop policy using learning curve extrapolation.

  • Advanced Support of Weight Sharing: Enable weight sharing for NAS tuners, currently through NFS.

Training Service Enhancement

  • FrameworkController Training service: Support run experiments using frameworkcontroller on kubernetes

    • FrameworkController is a Controller on kubernetes that is general enough to run (distributed) jobs with various machine learning frameworks, such as tensorflow, pytorch, MXNet.

    • NNI provides unified and simple specification for job definition.

    • MNIST example for how to use FrameworkController.

User Experience improvements

  • A better trial logging support for NNI experiments in OpenPAI, Kubeflow and FrameworkController mode:

    • An improved logging architecture to send stdout/stderr of trials to NNI manager via Http post. NNI manager will store trial’s stdout/stderr messages in local log file.

    • Show the link for trial log file on WebUI.

  • Support to show final result’s all key-value pairs.

Release 0.4.1 - 12/14/2018

Major Features

New tuner supports

Training Service improvements

  • Migrate Kubeflow training service‘s dependency from kubectl CLI to Kubernetes API client

  • Pytorch-operator support for Kubeflow training service

  • Improvement on local code files uploading to OpenPAI HDFS

  • Fixed OpenPAI integration WebUI bug: WebUI doesn’t show latest trial job status, which is caused by OpenPAI token expiration

NNICTL improvements

  • Show version information both in nnictl and WebUI. You can run nnictl -v to show your current installed NNI version

WebUI improvements

  • Enable modify concurrency number during experiment

  • Add feedback link to NNI github ‘create issue’ page

  • Enable customize top 10 trials regarding to metric numbers (largest or smallest)

  • Enable download logs for dispatcher & nnimanager

  • Enable automatic scaling of axes for metric number

  • Update annotation to support displaying real choice in searchspace

New examples

Release 0.4 - 12/6/2018

Major Features

Others

  • Asynchronous dispatcher

  • Docker file update, add pytorch library

  • Refactor ‘nnictl stop’ process, send SIGTERM to nni manager process, rather than calling stop Rest API.

  • OpenPAI training service bug fix

    • Support NNI Manager IP configuration(nniManagerIp) in OpenPAI cluster config file, to fix the issue that user’s machine has no eth0 device

    • File number in codeDir is capped to 1000 now, to avoid user mistakenly fill root dir for codeDir

    • Don’t print useless ‘metrics is empty’ log in OpenPAI job’s stdout. Only print useful message once new metrics are recorded, to reduce confusion when user checks OpenPAI trial’s output for debugging purpose

    • Add timestamp at the beginning of each log entry in trial keeper.

Release 0.3.0 - 11/2/2018

NNICTL new features and updates

  • Support running multiple experiments simultaneously.

    Before v0.3, NNI only supports running single experiment once a time. After this release, users are able to run multiple experiments simultaneously. Each experiment will require a unique port, the 1st experiment will be set to the default port as previous versions. You can specify a unique port for the rest experiments as below:

    nnictl create --port 8081 --config <config file path>
    
  • Support updating max trial number. use nnictl update --help to learn more. Or refer to NNICTL Spec for the fully usage of NNICTL.

API new features and updates

  • **breaking change**: nn.get_parameters() is refactored to nni.get_next_parameter. All examples of prior releases can not run on v0.3, please clone nni repo to get new examples. If you had applied NNI to your own codes, please update the API accordingly.

  • New API nni.get_sequence_id(). Each trial job is allocated a unique sequence number, which can be retrieved by nni.get_sequence_id() API.

    git clone -b v0.3 https://github.com/microsoft/nni.git
    
  • nni.report_final_result(result) API supports more data types for result parameter.

    It can be of following types:

    • int

    • float

    • A python dict containing ‘default’ key, the value of ‘default’ key should be of type int or float. The dict can contain any other key value pairs.

New tuner support

  • Batch Tuner which iterates all parameter combination, can be used to submit batch trial jobs.

New examples

Others

  • UI refactoring, refer to WebUI doc for how to work with the new UI.

  • Continuous Integration: NNI had switched to Azure pipelines

Release 0.2.0 - 9/29/2018

Major Features

  • Support OpenPAI Training Platform (See here for instructions about how to submit NNI job in pai mode)

    • Support training services on pai mode. NNI trials will be scheduled to run on OpenPAI cluster

    • NNI trial’s output (including logs and model file) will be copied to OpenPAI HDFS for further debugging and checking

  • Support SMAC tuner (See here for instructions about how to use SMAC tuner)

    • SMAC is based on Sequential Model-Based Optimization (SMBO). It adapts the most prominent previously used model class (Gaussian stochastic process models) and introduces the model class of random forests to SMBO to handle categorical parameters. The SMAC supported by NNI is a wrapper on SMAC3

  • Support NNI installation on conda and python virtual environment

  • Others

    • Update ga squad example and related documentation

    • WebUI UX small enhancement and bug fix

Release 0.1.0 - 9/10/2018 (initial release)

Initial release of Neural Network Intelligence (NNI).

Major Features

  • Installation and Deployment

    • Support pip install and source codes install

    • Support training services on local mode(including Multi-GPU mode) as well as multi-machines mode

  • Tuners, Assessors and Trial

    • Support AutoML algorithms including: hyperopt_tpe, hyperopt_annealing, hyperopt_random, and evolution_tuner

    • Support assessor(early stop) algorithms including: medianstop algorithm

    • Provide Python API for user defined tuners and assessors

    • Provide Python API for user to wrap trial code as NNI deployable codes

  • Experiments

    • Provide a command line toolkit ‘nnictl’ for experiments management

    • Provide a WebUI for viewing experiments details and managing experiments

  • Continuous Integration

    • Support CI by providing out-of-box integration with travis-ci on ubuntu

  • Others

    • Support simple GPU job scheduling