Pourquoi choisir Flower?
Dans notre cas, nous avons choisi d’utiliser le framework Flower sur PyTorch, et ce pour de nombreuses raisons :
Scalabilité : a été conçu pour être utilisé dans des cas d’utilisation réels, avec un très large nombre de clients (des dizaines de millions).
Interopérabilité : peut être implémenté sur tous types de serveurs et appareils, y compris les mobiles (AWS, GCP, Azure, Android, iOS, Raspberry Pi, Nvidia Jetson) pour bien fonctionner dans des environnements d’appareils hétérogènes.
Domaines de déploiement : peut être déployé dans des projets de recherche ou de production.
Compatibilité : avec la plupart des frameworks de machine learning et deep learning existants (TensorFlow, PyTorch, PyTorch Lightning, MXNet, JAX).
Facilité d’implémentation : plusieurs fonctionnalités et méthodes du federated learning sont déjà définies.
Architecture
Comme tout système d’apprentissage fédéré, composé d’un serveur et de plusieurs clients, Flower offre des classes préalablement définies qui permettent de garantir cette architecture. Deux fichiers sont nécessaires :
Client.py qui implémente le client Flower, permet de le connecter au serveur en précisant l’adresse IP et le port, définit le réseau de neurones à utiliser et le pré-traitement des données.
“Server.py” qui contient la configuration du serveur : nombre de rounds, la stratégie d’agrégation à adopter, la valeur du learning rate, etc. Ce fichier peut aussi contenir l’architecture du réseau de neurones du modèle dans le cas où l’initialisation des paramètres est réalisée par le serveur.
La classe Client ci-dessous, définie dans le fichier “Client.py”, représente un seul utilisateur, et permet de réaliser l’entraînement et l’évaluation sur les données locales, récupérer les paramètres actuels du modèle, les mettre à jour, et les envoyer ensuite au serveur. Ceci par le biais des fonctions suivantes :
“get_parameters” : retourne les paramètres du modèle à envoyer au serveur, sous la forme d’une liste de NumPy ndarrays.
“set_parameters” : met à jour les paramètres du modèle à partir de la liste de NumPy ndarrays.
“fit” : met à jour les paramètres, entraîne le modèle et envoie les nouveaux paramètres au serveur.
“evaluate” : met à jour les paramètres, évalue le modèle et envoie les métriques au serveur.
Le fichier Client.py
Le fichier “Server.py” suivant détermine la configuration initiale du serveur notamment le nombre total des rounds qui représente le nombre de fois où tous les participants envoient leurs paramètres au serveur, et la stratégie d’agrégation choisie.
Le fichier Server.py
A cette configuration nous pouvons ajouter les stratégies d’agrégation prédéfinies ou définir nos propres méthodes. Une liste des stratégies les plus utilisées dans l’apprentissage fédéré est citée dans l’article Introduction au Federated Learning. Le framework Flower permet au serveur de choisir l’une des méthodes suivantes : FedAvg, FedAdam, FedYogi, FedAdagrad, FedFS. Il offre aussi la possibilité de modifier leurs paramètres :
“fraction_eval” : représente le pourcentage des clients participants à l’entraînement par rapport au nombre de clients total.
“min_eval_clients” : définit le nombre minimal de clients nécessaires pour commencer l’entraînement.
“min_available_clients” : définit le nombre minimal de clients qui doivent être connectés au serveur avant chaque round. Cependant, ils peuvent ne pas participer tous à l’entraînement.
Chaque round peut avoir un ensemble différent de clients, en fonction des appareils connectés en premier.
La stratégie FedAvg est la plus utilisée pour agréger les poids du modèle reçus de la part des différents clients, elle consiste à combiner la descente de gradient stochastique (SGD) locale sur chaque client par le serveur qui effectue ensuite la moyenne.
Un autre paramètre modifiable est la configuration de l’évaluation de la stratégie, par la définition de la fonction suivante qui permet de modifier la valeur du learning rate :
Les constantes dans ce code sont fixées par le serveur de façon à avoir la valeur optimale qui permet au modèle de converger en minimisant le temps d’entraînement.
Lancement de l’entraînement
Afin de commencer l’entraînement, il suffit de lancer le fichier “server.py” qui sera en écoute, ainsi que des copies du fichier “client.py” selon le nombre de clients dans le réseau, pour permettre la connexion entre les deux composants.
Dans notre cas, nous avons testé avec 3 rounds et 2 clients. Nous obtenons cet exemple d’output à la fin des rounds pour chacun des clients.
Output de chaque client
L’output du serveur résume les étapes de l’apprentissage fédéré :
Initialisation des paramètres globaux (les poids du réseau de neurones) soit par le serveur suivant la stratégie choisie, soit par un client choisi aléatoirement.
2. Entraînement sur les données locales des clients, le nombre de fois fixé d’avance.
3. Agrégation des métriques (loss) reçues par le serveur, après chaque round.
4. Évaluation du modèle final par chaque client et retour des métriques (accuracy et validation loss)
L’impact des méthodes d’agrégation et la répartition des datasets chez les clients sur les performances du modèle
Plusieurs méthodes d’agrégation peuvent être utilisées dans le framework Flower, pour mettre à jour les poids du modèle général par le serveur. De même, la répartition des datasets chez les clients (données IID ou non-IID) joue un rôle important sur les performances du modèle. Pour cela, nous voulons étudier leurs impacts ainsi que les limites de chacune des méthodes afin de pouvoir choisir celle qui donne le meilleur modèle.
Nous utilisons dans notre cas la configuration suivante :
Le dataset Animals10 qui contient des images de 10 classes différentes d’animaux
Un serveur et 2 clients dans le même réseau (pour accélérer l’entraînement)
Entraînement sur un GPU
Nombre de rounds selon la convergence du modèle pour chaque cas
3 méthodes de répartition du dataset : aléatoire
- Méthode 1 : aléatoire
- Méthode 2 : biaisée pour certaines classes (pour 3 classes choisies aléatoirement dans les données de chaque client, nous divisons le dataset correspondant en 30% pour le train et 70% pour la validation)
- Méthode 3 : mixed (aléatoire pour certaines classes et biaisée pour d’autres)
6 stratégies d’agrégation :
- Stratégie 1 : FedAvg
- Stratégie 2 : FedAvg personnalisé (avec modification de configuration de l’évaluation)
- Stratégie 3 : FedAdam
- Stratégie 4 : FedAdagrad
- Stratégie 5 : FedYogi
- Stratégie 6 : FedFS
Nous testons pour chaque méthode de répartition, toutes les stratégies d’agrégation offertes par le framework Flower. Le graphe suivant montre la moyenne des accuracy des clients participants que donne chaque test :
Accuracy du modèle en fonction de la méthode de répartition du dataset et la stratégie d’agrégation
Nous pouvons constater d’après les valeurs obtenues que la stratégie choisie ainsi que la méthode de répartition des données, en considérant que le nombre des rounds est celui auquel le modèle atteint sa convergence, affectent directement les performances du modèle. Cependant, certaines méthodes d’agrégation comme FedAdagrad et FedAdam ne semblent pas être adaptées aux données utilisées dans notre cas, comme le modèle converge rapidement au bout de quelques rounds alors que l’accuracy reste faible. Elles ne permettent pas d’obtenir un bon modèle de prédiction indépendamment de la méthode de répartition du dataset.
Le tableau suivant détaille les résultats obtenus en fonction de toutes les méthodes proposées par Flower, et de la répartition du dataset :
Remerciement
Merci à notre collègue Beatrice CHETARD pour la revue de l’article.
A propos de l’auteur
Bochra BEN JABALLAH est étudiante en Master 2 en Intelligence Artificielle, Science des données et Systèmes Cyber-physiques à l’UPEC. Elle rejoint La Javaness en 2022 pour son stage de fin d’étude sur le sujet de Federated Learning.