Model training

Model Training

In this task, a model for recognition is trained in a federated manner. In this example, a model for recognizing the digit from the MNIST dataset (https://www.tensorflow.org/datasets/catalog/mnist).

Assets

For this procedure, two sets of assets are required. One for the model_creator and one for model_contributor. Possible examples for these assets can be found in substrate-client-decentralml/assets.

Here's an example of the code and assets for the model_creator:

model_creator
├── __init__.py
├── model_creator.py
├── setup.sh
├── requirements.txt
└── settings.py
  • model_creator.py contains the python code for generating the first model, saving it and federated the results once the contributors have completed their training.

  • setup.sh is a script to setup the development environment for the model_creator

  • requirements.txt lists the python requirements for the model developement

  • settings.py is just a support file for specifiying the model parameters for the model_contributor and the creator.

The model_creator must also create the python code for the contributor to perform his task:

model_contributor
├── __init__.py
├── model_contributor.py
├── requirements.txt
├── settings.py
└── start_task.sh
  • model_contributor.py contains the python code for the training of the model

  • requirements.txt lists the python requirements for the model developement

  • settings.py is just a support file for specifiying the model parameters for the model_contributor and the creator.

  • start_task.sh is a script for the model_contributor to actually execute the task

Procedure

  1. The model_creator starts by creating a model structure and compiles it:

    Once the first model is generated, it can be trained:

    Evaluated:

    And more importantly, saved for the model contributors to use:

    In a federated system, the training step is generally delegated to the model contributors, but the model creator could perform some training just to initiate the system. The contributors can then subsequently training on new data.

    Note all these steps are part of the model_creator.py in the assets folder.

  2. In order to start the federated training, the model_creator can then create a task for model contributors using the function:

    In which:

    • model_contributor_script_path is the path to the assets for the model_contributor

    For additional info on the substrate parameters (i.e. expiration block, substrate, etc.) consult the documentation of the python client or view the example (https://github.com/livetreetech/DecentralML/blob/main/substrate-client-decentralml/src/decentralml/create_task.py).

  3. The model_contributor then can list_task and accept a task with:

    by specifying the task_id. Assigning a task will download the corresponding assets for model contributor task.

  4. The model_contributor can then start the task by executing the script provided by the model_creator:

    which setups the environment and starts the python code for the federated learning in the model_contributor.py file.

    A model contributor receive a model and trains it on a subset of data that can be either provided by the model creator, or provided locally by the contributor. In this example, the data are provided by the model creator as a method to load them:

    The contributor can then load the model provided by the creator for the training:

    The contributor then starts the training of the model according with the indication of the creator (i.e. epochs, batch_size, etc.):

    The generated model can finally be saved for the model creator to federate the model training results:

    Saving the model creates an output folder which includes the structure and the weights. The name of the folder includes the model name and an id for the contributor:

    The contributor ID in this example is a randomly generated string used to uniquely identify the different models generated by the contributors as part of the training.

  5. Once the model_contributor has completed his task, the model_contributor can send the results using:

    This function accepts a parameter result_path which will have to be set to the output folder containing the saved model. Sending the results uploads the model training results to a remote and/or shared storage.

  6. The model_creator can list the available results for each task using the list_task_results (see Listing objects).

  7. Once, a result is available, the model_creator can start validating the results using the validate_task_results. The validation of the results can be performed according to three policies:

    • AutoAccept: the results are automatically accepted

    • ManualAccept: the model_creator manually accepts each task results

    • CustomAccept: the model_creator can implement custom methods for automatically validating the results.

    Starting the validation process downloads the results and the corresponding saved models. In this example, we explain a manual validation process. The model_creator can validate process by loading the federated models. For this example, the functions to federate the models are included in the assets/model_creator/model_creator.py.

    Then, the results of each trained model are federated averaging the model weights:

    Finally, the new weights can be applied to the same model structure that was originally created:

    This model can then be evaluated:

  8. Once the validation process is complete, the model_creator or the automatic validation procedure can either accept or reject the results, using respectively accept_task_results() or reject_task_results().

    Accepting the results issues the payment to the contributor.

Last updated