TEPPIT Support for Federated ML on SPHERE Testbed

Flower AI - SPHERE Artifacts

Introduction

Flower AI is a popular federated learning frameworks used by researchers and industry alike. We have prototyped several approaches to installing Flower on the SPHERE testbed and packaged them as SPHERE “artifacts” i.e. prepackaged code and data needed to reproduce a successful Flower installations.

Our users are researchers and students who are interested in running federated learning experiments. The example below aimed at bridging the gap between technical knowledge needed to run flower experiments and the knowledge or being a SPHERE user. SPHERE testbed provides a way to allocate real or virtualized hardware (virtual machines and networks connecting them) and users can use these machines to emulate a distributed setup of federated learning where servers and clients are running on different nodes. In some cases SPHERE can provide one or several baremetal (actual, entire physical machine with a GPU) for running compute-heavy jobs. SPHERE also allows users to set up arbitrary network topologies between nodes. For example, nodes can be placed on the same local are network (LAN) or have intermediate nodes between them.

Our Flower examples shown here only demonstrate how a basic installation can proceed by using examples described in the Flower documentation. For actual experiments, users will need to modify these recepies to use their own learning models and training datasets. Many canonical flower datasets (such as CIFAR-10) can be automatically downloaded and partitioned using Flower Datasets (flwr-datasets) library. They are often also available via framework-specific utilities. For instance, PyTorch uses a torchvision.datasets module, and TensorFlow uses tf.keras.datasets utility. Private datasets can be uploaded using scp or flwr-datasets can download them from a private repository on the Hugging Face Hub.

Users will need to apply for a SPHERE accounts first (see Getting Started section) and get them activated before they can view the details of artifacts listed below.

Artifacts

1. Basic deployment of Flower framework in simulation on one node. This artifact is a basic installation that supports quickstart_pytorch simulation example from Flower documentation, described here. It runs a managed local SuperLink and 10 simulated clients, or SuperNodes using the Flower Simulation Runtime. This setup is optimal for students starting to learn Flower and suitable for small applications/datasets. Because everything is simulated and runs on the same node, it’s easy to debug and diagnose problems with the code. For larger datasets when learning needs more compute power, a distributed installation should be used.

2. Flower in deployment on two clients and a server. This artifact is a basic installation that supports quickstart_pytorch deployment on two SuperNodes (clients) and one SuperLink (server). It follows the example from Flower documentation, described here and sets up a distributed installation where multiple virtual machines are working together. The scripts used in this artifact can be modified to allow more clients, if needed, but in the following interactive Jupyter tutorial artifact, many adjustments can be made interactively, so it’s an easier way to tailor installation to your needs.

3. Flower Interactive Jupyter Tutorial. This tutorial uses Jupyter Notebooks to showcase a deployment of a Flower AI on SPHERE testbed. In this Jupyter tutorial, we show how to deploy a basic distributed flower application on the SPHERE testbed. We use quickstart_pytorch example, described in this tutorial deployed over a SPHERE topology consisting of one server running SuperLink and several clients running Supernodes. It follows the quickstart instructions for distributed insecure installation.

   This tutorial is a self-documented, self-contained Jupyter notebook that users are encouraged to run cell-by-cell or just consult for ideas on how SPHERE deployment tasks can be scripted and automated. Users can make inline changes e.g. to increase the number of clients or change the topology or modify the code to drop-in their own models and data.