Changelog

Unreleased

Quoi de neuf ?

Changements incompatibles

Aucun

v1.8.0 (2024-04-03)

Merci à nos contributeurs

Nous tenons à remercier tout particulièrement tous les contributeurs qui ont rendu possible la nouvelle version de Flower (dans l’ordre git shortlog) :

Adam Narozniak, Charles Beauville, Daniel J. Beutel, Daniel Nata Nugraha, Danny, Gustavo Bertoli, Heng Pan, Ikko Eltociear Ashimine, Jack Cook, Javier, Raj Parekh, Robert Steiner, Sebastian van der Voort, Taner Topal, Yan Gao, mohammadnaseri, tabdar-khan

Quoi de neuf ?

• Introduce Flower Next high-level API (stable) (#3002, #2934, #2958, #3173, #3174, #2923, #2691, #3079, #2961, #2924, #3166, #3031, #3057, #3000, #3113, #2957, #3183, #3180, #3035, #3189, #3185, #3190, #3191, #3195, #3197)

  The Flower Next high-level API is stable! Flower Next is the future of Flower - all new features (like Flower Mods) will be built on top of it. You can start to migrate your existing projects to Flower Next by using ServerApp and ClientApp (check out quickstart-pytorch or quickstart-tensorflow, a detailed migration guide will follow shortly). Flower Next allows you to run multiple projects concurrently (we call this multi-run) and execute the same project in either simulation environments or deployment environments without having to change a single line of code. The best part? It’s fully compatible with existing Flower projects that use Strategy, NumPyClient & co.

• Introduce Flower Next low-level API (preview) (#3062, #3034, #3069)

  In addition to the Flower Next high-level API that uses Strategy, NumPyClient & co, Flower 1.8 also comes with a preview version of the new Flower Next low-level API. The low-level API allows for granular control of every aspect of the learning process by sending/receiving individual messages to/from client nodes. The new ServerApp supports registering a custom main function that allows writing custom training loops for methods like async FL, cyclic training, or federated analytics. The new ClientApp supports registering train, evaluate and query functions that can access the raw message received from the ServerApp. New abstractions like RecordSet, Message and Context further enable sending multiple models, multiple sets of config values and metrics, stateful computations on the client node and implementations of custom SMPC protocols, to name just a few.

• Introduce Flower Mods (preview) (#3054, #2911, #3083)

  Flower Modifiers (we call them Mods) can intercept messages and analyze, edit or handle them directly. Mods can be used to develop pluggable modules that work across different projects. Flower 1.8 already includes mods to log the size of a message, the number of parameters sent over the network, differential privacy with fixed clipping and adaptive clipping, local differential privacy and secure aggregation protocols SecAgg and SecAgg+. The Flower Mods API is released as a preview, but researchers can already use it to experiment with arbirtrary SMPC protocols.

• Fine-tune LLMs with LLM FlowerTune (#3029, #3089, #3092, #3100, #3114, #3162, #3172)

  We are introducing LLM FlowerTune, an introductory example that demonstrates federated LLM fine-tuning of pre-trained Llama2 models on the Alpaca-GPT4 dataset. The example is built to be easily adapted to use different models and/or datasets. Read our blog post LLM FlowerTune: Federated LLM Fine-tuning with Flower for more details.

• Introduce built-in Differential Privacy (preview) (#2798, #2959, #3038, #3147, #2909, #2893, #2892, #3039, #3074)

  Built-in Differential Privacy is here! Flower supports both central and local differential privacy (DP). Central DP can be configured with either fixed or adaptive clipping. The clipping can happen either on the server-side or the client-side. Local DP does both clipping and noising on the client-side. A new documentation page explains Differential Privacy approaches and a new how-to guide describes how to use the new Differential Privacy components in Flower.

• Introduce built-in Secure Aggregation (preview) (#3120, #3110, #3108)

  Built-in Secure Aggregation is here! Flower now supports different secure aggregation protocols out-of-the-box. The best part? You can add secure aggregation to your Flower projects with only a few lines of code. In this initial release, we inlcude support for SecAgg and SecAgg+, but more protocols will be implemented shortly. We’ll also add detailed docs that explain secure aggregation and how to use it in Flower. You can already check out the new code example that shows how to use Flower to easily combine Federated Learning, Differential Privacy and Secure Aggregation in the same project.

• Introduce flwr CLI (preview) (#2942, #3055, #3111, #3130, #3136, #3094, #3059, #3049, #3142)

  A new flwr CLI command allows creating new Flower projects (flwr new) and then running them using the Simulation Engine (flwr run).

• Introduce Flower Next Simulation Engine (#3024, #3061, #2997, #2783, #3184, #3075, #3047, #2998, #3009, #3008)

  The Flower Simulation Engine can now run Flower Next projects. For notebook environments, there’s also a new run_simulation function that can run ServerApp and ClientApp.

• Handle SuperNode connection errors (#2969)

  A SuperNode will now try to reconnect indefinitely to the SuperLink in case of connection errors. The arguments --max-retries and --max-wait-time can now be passed to the flower-client-app command. --max-retries will define the number of tentatives the client should make before it gives up trying to reconnect to the SuperLink, and, --max-wait-time defines the time before the SuperNode gives up trying to reconnect to the SuperLink.

• General updates to Flower Baselines (#2904, #2482, #2985, #2968)

  There’s a new FedStar baseline. Several other baselined have been updated as well.

• Improve documentation and translations (#3050, #3044, #3043, #2986, #3041, #3046, #3042, #2978, #2952, #3167, #2953, #3045, #2654, #3082, #2990, #2989)

  As usual, we merged many smaller and larger improvements to the documentation. A special thank you goes to Sebastian van der Voort for landing a big documentation PR!

• General updates to Flower Examples (3134, 2996, 2930, 2967, 2467, 2910, #2918, #2773, #3063, #3116, #3117)

  Two new examples show federated training of a Vision Transformer (ViT) and federated learning in a medical context using the popular MONAI library. quickstart-pytorch and quickstart-tensorflow demonstrate the new Flower Next ServerApp and ClientApp. Many other examples received considerable updates as well.

• General improvements (#3171, 3099, 3003, 3145, 3017, 3085, 3012, 3119, 2991, 2970, 2980, 3086, 2932, 2928, 2941, 2933, 3181, 2973, 2992, 2915, 3040, 3022, 3032, 2902, 2931, 3005, 3132, 3115, 2944, 3064, 3106, 2974, 3178, 2993, 3186, 3091, 3125, 3093, 3013, 3033, 3133, 3068, 2916, 2975, 2984, 2846, 3077, 3143, 2921, 3101, 2927, 2995, 2972, 2912, 3065, 3028, 2922, 2982, 2914, 3179, 3080, 2994, 3187, 2926, 3018, 3144, 3011, #3152, #2836, #2929, #2943, #2955, #2954)

Changements incompatibles

Aucun

v1.7.0 (2024-02-05)

Merci à nos contributeurs

Nous tenons à remercier tout particulièrement tous les contributeurs qui ont rendu possible la nouvelle version de Flower (dans l’ordre git shortlog) :

Aasheesh Singh, Adam Narozniak, Aml Hassan Esmil, Charles Beauville, Daniel J. Beutel, Daniel Nata Nugraha, Edoardo Gabrielli, Gustavo Bertoli, HelinLin, Heng Pan, Javier, M S Chaitanya Kumar, Mohammad Naseri, Nikos Vlachakis, Pritam Neog, Robert Kuska, Robert Steiner, Taner Topal, Yahia Salaheldin Shaaban, Yan Gao, Yasar Abbas

Quoi de neuf ?

• Introduce stateful clients (experimental) (#2770, #2686, #2696, #2643, #2769)

  Subclasses of Client and NumPyClient can now store local state that remains on the client. Let’s start with the highlight first: this new feature is compatible with both simulated clients (via start_simulation) and networked clients (via start_client). It’s also the first preview of new abstractions like Context and RecordSet. Clients can access state of type RecordSet via state: RecordSet = self.context.state. Changes to this RecordSet are preserved across different rounds of execution to enable stateful computations in a unified way across simulation and deployment.

• Improve performance (#2293)

  Flower is faster than ever. All FedAvg-derived strategies now use in-place aggregation to reduce memory consumption. The Flower client serialization/deserialization has been rewritten from the ground up, which results in significant speedups, especially when the client-side training time is short.

• Support Federated Learning with Apple MLX and Flower (#2693)

  Flower has official support for federated learning using Apple MLX via the new quickstart-mlx code example.

• Introduce new XGBoost cyclic strategy (#2666, #2668)

  A new strategy called FedXgbCyclic supports a client-by-client style of training (often called cyclic). The xgboost-comprehensive code example shows how to use it in a full project. In addition to that, xgboost-comprehensive now also supports simulation mode. With this, Flower offers best-in-class XGBoost support.

• Support Python 3.11 (#2394)

  Framework tests now run on Python 3.8, 3.9, 3.10, and 3.11. This will ensure better support for users using more recent Python versions.

• Update gRPC and ProtoBuf dependencies (#2814)

  The grpcio and protobuf dependencies were updated to their latest versions for improved security and performance.

• Introduce Docker image for Flower server (#2700, #2688, #2705, #2695, #2747, #2746, #2680, #2682, #2701)

  The Flower server can now be run using an official Docker image. A new how-to guide explains how to run Flower using Docker. An official Flower client Docker image will follow.

• Introduce flower-via-docker-compose example (#2626)

• Introduce quickstart-sklearn-tabular example (#2719)

• Introduce custom-metrics example (#1958)

• Update code examples to use Flower Datasets (#2450, #2456, #2318, #2712)

  Several code examples were updated to use Flower Datasets.

• General updates to Flower Examples (#2381, #2805, #2782, #2806, #2829, #2825, #2816, #2726, #2659, #2655)

  Many Flower code examples received substantial updates.

• Update Flower Baselines

  • HFedXGBoost (#2226, #2771)

  • FedVSSL (#2412)

  • FedNova (#2179)

  • HeteroFL (#2439)

  • FedAvgM (#2246)

  • FedPara (#2722)

• Improve documentation (#2674, #2480, #2826, #2727, #2761, #2900)

• Improved testing and development infrastructure (#2797, #2676, #2644, #2656, #2848, #2675, #2735, #2767, #2732, #2744, #2681, #2699, #2745, #2734, #2731, #2652, #2720, #2721, #2717, #2864, #2694, #2709, #2658, #2796, #2692, #2657, #2813, #2661, #2398)

  The Flower testing and development infrastructure has received substantial updates. This makes Flower 1.7 the most tested release ever.

• Update dependencies (#2753, #2651, #2739, #2837, #2788, #2811, #2774, #2790, #2751, #2850, #2812, #2872, #2736, #2756, #2857, #2757, #2810, #2740, #2789)

• General improvements (#2803, #2847, #2877, #2690, #2889, #2874, #2819, #2689, #2457, #2870, #2669, #2876, #2885, #2858, #2867, #2351, #2886, #2860, #2828, #2869, #2875, #2733, #2488, #2646, #2879, #2821, #2855, #2800, #2807, #2801, #2804, #2851, #2787, #2852, #2672, #2759)

Changements incompatibles

• Deprecate start_numpy_client (#2563, #2718)

  Until now, clients of type NumPyClient needed to be started via start_numpy_client. In our efforts to consolidate framework APIs, we have introduced changes, and now all client types should start via start_client. To continue using NumPyClient clients, you simply need to first call the .to_client() method and then pass returned Client object to start_client. The examples and the documentation have been updated accordingly.

• Deprecate legacy DP wrappers (#2749)

  Legacy DP wrapper classes are deprecated, but still functional. This is in preparation for an all-new pluggable version of differential privacy support in Flower.

• Make optional arg --callable in flower-client a required positional arg (#2673)

• Rename certificates to root_certificates in Driver (#2890)

• Drop experimental Task fields (#2866, #2865)

  Experimental fields sa, legacy_server_message and legacy_client_message were removed from Task message. The removed fields are superseded by the new RecordSet abstraction.

• Retire MXNet examples (#2724)

  The development of the MXNet fremework has ended and the project is now archived on GitHub. Existing MXNet examples won’t receive updates.

v1.6.0 (2023-11-28)

Merci à nos contributeurs

Nous tenons à remercier tout particulièrement tous les contributeurs qui ont rendu possible la nouvelle version de Flower (dans l’ordre git shortlog) :

Aashish Kolluri, Adam Narozniak, Alessio Mora, Barathwaja S, Charles Beauville, Daniel J. Beutel, Daniel Nata Nugraha, Gabriel Mota, Heng Pan, Ivan Agarský, JS.KIM, Javier, Marius Schlegel, Navin Chandra, Nic Lane, Peterpan828, Qinbin Li, Shaz-hash, Steve Laskaridis, Taner Topal, William Lindskog, Yan Gao, cnxdeveloper, k3nfalt

Quoi de neuf ?

• Add experimental support for Python 3.12 (#2565)

• Add new XGBoost examples (#2612, #2554, #2617, #2618, #2619, #2567)

  We have added a new xgboost-quickstart example alongside a new xgboost-comprehensive example that goes more in-depth.

• Add Vertical FL example (#2598)

  We had many questions about Vertical Federated Learning using Flower, so we decided to add an simple example for it on the Titanic dataset alongside a tutorial (in the README).

• Support custom ClientManager in start_driver() (#2292)

• Update REST API to support create and delete nodes (#2283)

• Update the Android SDK (#2187)

  Add gRPC request-response capability to the Android SDK.

• Update the C++ SDK (#2537, #2528, #2523, #2522)

  Add gRPC request-response capability to the C++ SDK.

• Make HTTPS the new default (#2591, #2636)

  Flower is moving to HTTPS by default. The new flower-server requires passing --certificates, but users can enable --insecure to use HTTP for prototyping. The same applies to flower-client, which can either use user-provided credentials or gRPC-bundled certificates to connect to an HTTPS-enabled server or requires opt-out via passing --insecure to enable insecure HTTP connections.

  For backward compatibility, start_client() and start_numpy_client() will still start in insecure mode by default. In a future release, insecure connections will require user opt-in by passing insecure=True.

• Unify client API (#2303, #2390, #2493)

  Using the client_fn, Flower clients can interchangeably run as standalone processes (i.e. via start_client) or in simulation (i.e. via start_simulation) without requiring changes to how the client class is defined and instantiated. The to_client() function is introduced to convert a NumPyClient to a Client.

• Add new Bulyan strategy (#1817, #1891)

  The new Bulyan strategy implements Bulyan by El Mhamdi et al., 2018

• Add new XGB Bagging strategy (#2611)

• Introduce WorkloadState (#2564, #2632)

• Introduce WorkloadState (#2564, #2632)

• Update Flower Baselines

  • FedProx (#2210, #2286, #2509)

  • Baselines Docs (#2290, #2400)

  • FedMLB (#2340, #2507)

  • TAMUNA (#2254, #2508)

  • FedMeta #2438

  • FjORD #2431

  • MOON #2421

  • DepthFL #2295

  • FedPer #2266

  • FedWav2vec #2551

  • niid-Bench #2428

  • FedBN (#2608, #2615)

• General updates to Flower Examples (#2384, #2425, #2526, #2302, #2545)

• General updates to Flower Baselines (#2301, #2305, #2307, #2327, #2435, #2462, #2463, #2461, #2469, #2466, #2471, #2472, #2470)

• General updates to the simulation engine (#2331, #2447, #2448, #2294)

• General updates to Flower SDKs (#2288, #2429, #2555, #2543, #2544, #2597, #2623)

• General improvements (#2309, #2310, #2313, #2316, #2317, #2349, #2360, #2402, #2446, #2561, #2273, #2267, #2274, #2275, #2432, #2251, #2321, #1936, #2408, #2413, #2401, #2531, #2534, #2535, #2521, #2553, #2596)

  Flower a reçu de nombreuses améliorations sous le capot, trop nombreuses pour être énumérées ici.

Changements incompatibles

• Remove support for Python 3.7 (#2280, #2299, #2304, #2306, #2355, #2356)

  Python 3.7 support was deprecated in Flower 1.5, and this release removes support. Flower now requires Python 3.8.

• Remove experimental argument rest from start_client (#2324)

  The (still experimental) argument rest was removed from start_client and start_numpy_client. Use transport="rest" to opt into the experimental REST API instead.

v1.5.0 (2023-08-31)

Merci à nos contributeurs

Nous tenons à remercier tout particulièrement tous les contributeurs qui ont rendu possible la nouvelle version de Flower (dans l’ordre git shortlog) :

Adam Narozniak, Anass Anhari, Charles Beauville, Dana-Farber, Daniel J. Beutel, Daniel Nata Nugraha, Edoardo Gabrielli, Gustavo Bertoli, Heng Pan, Javier, Mahdi, Steven Hé (Sīchàng), Taner Topal, achiverram28, danielnugraha, eunchung, ruthgal

Quoi de neuf ?

• Introduce new simulation engine (#1969, #2221, #2248)

  The new simulation engine has been rewritten from the ground up, yet it remains fully backwards compatible. It offers much improved stability and memory handling, especially when working with GPUs. Simulations transparently adapt to different settings to scale simulation in CPU-only, CPU+GPU, multi-GPU, or multi-node multi-GPU environments.

  Comprehensive documentation includes a new how-to run simulations guide, new simulation-pytorch and simulation-tensorflow notebooks, and a new YouTube tutorial series.

• Restructure Flower Docs (#1824, #1865, #1884, #1887, #1919, #1922, #1920, #1923, #1924, #1962, #2006, #2133, #2203, #2215, #2122, #2223, #2219, #2232, #2233, #2234, #2235, #2237, #2238, #2242, #2231, #2243, #2227)

  Much effort went into a completely restructured Flower docs experience. The documentation on flower.ai/docs is now divided into Flower Framework, Flower Baselines, Flower Android SDK, Flower iOS SDK, and code example projects.

• Introduce Flower Swift SDK (#1858, #1897)

  This is the first preview release of the Flower Swift SDK. Flower support on iOS is improving, and alongside the Swift SDK and code example, there is now also an iOS quickstart tutorial.

• Introduce Flower Android SDK (#2131)

  This is the first preview release of the Flower Kotlin SDK. Flower support on Android is improving, and alongside the Kotlin SDK and code example, there is now also an Android quickstart tutorial.

• Introduce new end-to-end testing infrastructure (#1842, #2071, #2072, #2068, #2067, #2069, #2073, #2070, #2074, #2082, #2084, #2093, #2109, #2095, #2140, #2137, #2165)

  A new testing infrastructure ensures that new changes stay compatible with existing framework integrations or strategies.

• Deprecate Python 3.7

  Since Python 3.7 reached its end of life (EOL) on 2023-06-27, support for Python 3.7 is now deprecated and will be removed in an upcoming release.

• Add new FedTrimmedAvg strategy (#1769, #1853)

  The new FedTrimmedAvg strategy implements Trimmed Mean by Dong Yin, 2018.

• Introduce start_driver (#1697)

  In addition to start_server and using the raw Driver API, there is a new start_driver function that allows for running start_server scripts as a Flower driver with only a single-line code change. Check out the mt-pytorch code example to see a working example using start_driver.

• Add parameter aggregation to mt-pytorch code example (#1785)

  The mt-pytorch example shows how to aggregate parameters when writing a driver script. The included driver.py and server.py have been aligned to demonstrate both the low-level way and the high-level way of building server-side logic.

• Migrate experimental REST API to Starlette (2171)

  The (experimental) REST API used to be implemented in FastAPI, but it has now been migrated to use Starlette directly.

  Please note: The REST request-response API is still experimental and will likely change significantly over time.

• Introduce experimental gRPC request-response API (#1867, #1901)

  In addition to the existing gRPC API (based on bidirectional streaming) and the experimental REST API, there is now a new gRPC API that uses a request-response model to communicate with client nodes.

  Please note: The gRPC request-response API is still experimental and will likely change significantly over time.

• Replace the experimental start_client(rest=True) with the new start_client(transport="rest") (#1880)

  The (experimental) start_client argument rest was deprecated in favour of a new argument transport. start_client(transport="rest") will yield the same behaviour as start_client(rest=True) did before. All code should migrate to the new argument transport. The deprecated argument rest will be removed in a future release.

• Add a new gRPC option (#2197)

  We now start a gRPC server with the grpc.keepalive_permit_without_calls option set to 0 by default. This prevents the clients from sending keepalive pings when there is no outstanding stream.

• Improve example notebooks (#2005)

  There’s a new 30min Federated Learning PyTorch tutorial!

• Example updates (#1772, #1873, #1981, #1988, #1984, #1982, #2112, #2144, #2174, #2225, #2183)

  Many examples have received significant updates, including simplified advanced-tensorflow and advanced-pytorch examples, improved macOS compatibility of TensorFlow examples, and code examples for simulation. A major upgrade is that all code examples now have a requirements.txt (in addition to pyproject.toml).

• General improvements (#1872, #1866, #1884, #1837, #1477, #2171)

  Flower a reçu de nombreuses améliorations sous le capot, trop nombreuses pour être énumérées ici.

Changements incompatibles

Aucun

v1.4.0 (2023-04-21)

Merci à nos contributeurs

Nous tenons à remercier tout particulièrement tous les contributeurs qui ont rendu possible la nouvelle version de Flower (dans l’ordre git shortlog) :

Adam Narozniak, Alexander Viala Bellander, Charles Beauville, Chenyang Ma (Danny), Daniel J. Beutel, Edoardo, Gautam Jajoo, Iacob-Alexandru-Andrei, JDRanpariya, Jean Charle Yaacoub, Kunal Sarkhel, L. Jiang, Lennart Behme, Max Kapsecker, Michał, Nic Lane, Nikolaos Episkopos, Ragy, Saurav Maheshkar, Semo Yang, Steve Laskaridis, Steven Hé (Sīchàng), Taner Topal

Quoi de neuf ?

• Introduire la prise en charge de XGBoost (FedXgbNnAvg stratégie et exemple) (#1694, #1709, #1715, #1717, #1763, #1795)

  Nous avons ajouté une nouvelle [stratégie] FedXgbNnAvg (https://github.com/adap/flower/tree/main/src/py/flwr/server/strategy/fedxgb_nn_avg.py), et un [exemple de code] (https://github.com/adap/flower/tree/main/examples/xgboost-quickstart) qui démontre l’utilisation de cette nouvelle stratégie dans un projet XGBoost.

• Introduction du SDK iOS (aperçu) (#1621, #1764)

  Il s’agit d’une mise à jour majeure pour tous ceux qui souhaitent mettre en œuvre l’apprentissage fédéré sur les appareils mobiles iOS. Nous disposons désormais d’un SDK swift iOS présent sous src/swift/flwr qui facilitera grandement le processus de création d’applications. Pour présenter son utilisation, l”exemple iOS a également été mis à jour !

• Introduire un nouveau tutoriel « Qu’est-ce que l’apprentissage fédéré ? «  (#1657, #1721)

  A new entry-level tutorial in our documentation explains the basics of Fedetated Learning. It enables anyone who’s unfamiliar with Federated Learning to start their journey with Flower. Forward it to anyone who’s interested in Federated Learning!

• Introduire une nouvelle fleur Référence : FedProx MNIST (#1513, #1680, #1681, #1679)

  Cette nouvelle ligne de base reproduit la tâche MNIST+CNN de l’article [Federated Optimization in Heterogeneous Networks (Li et al., 2018)] (https://arxiv.org/abs/1812.06127). Elle utilise la stratégie FedProx, qui vise à rendre la convergence plus robuste dans des contextes hétérogènes.

• Introduire une nouvelle ligne de base pour les fleurs : FedAvg FEMNIST (#1655)

  Cette nouvelle ligne de base reproduit une expérience évaluant les performances de l’algorithme FedAvg sur le jeu de données FEMNIST tiré de l’article [LEAF : A Benchmark for Federated Settings (Caldas et al., 2018)] (https://arxiv.org/abs/1812.01097).

• Introduire l’API REST (expérimentale) (#1594, #1690, #1695, #1712, #1802, #1770, #1733)

  Une nouvelle API REST a été introduite comme alternative à la pile de communication basée sur gRPC. Dans cette version initiale, l’API REST ne prend en charge que les clients anonymes.

  Remarque : l’API REST est encore expérimentale et est susceptible de changer de manière significative au fil du temps.

• Améliorer l’API (expérimentale) du pilote (#1663, #1666, #1667, #1664, #1675, #1676, #1693, #1662, #1794)

  L’API du pilote est encore une fonction expérimentale, mais cette version introduit quelques améliorations majeures. L’une des principales améliorations est l’introduction d’une base de données SQLite pour stocker l’état du serveur sur le disque (au lieu de la mémoire). Une autre amélioration est que les tâches (instructions ou résultats) qui ont été livrées seront désormais supprimées, ce qui améliore considérablement l’efficacité de la mémoire d’un serveur Flower fonctionnant depuis longtemps.

• Répare les problèmes de déversement liés à Ray pendant les simulations (#1698)

  While running long simulations, ray was sometimes spilling huge amounts of data that would make the training unable to continue. This is now fixed! 🎉

• Ajouter un nouvel exemple utilisant TabNet et Flower (#1725)

  TabNet est un cadre puissant et flexible pour former des modèles d’apprentissage automatique sur des données tabulaires. Nous avons maintenant un exemple fédéré utilisant Flower : quickstart-tabnet.

• Ajouter un nouveau guide pratique pour le suivi des simulations (#1649)

  Nous avons maintenant un guide de documentation pour aider les utilisateurs à surveiller leurs performances pendant les simulations.

• Ajouter des mesures de formation à History objet pendant les simulations (#1696)

  La fonction fit_metrics_aggregation_fn peut être utilisée pour agréger les mesures d’entraînement, mais les versions précédentes n’enregistraient pas les résultats dans l’objet History. c’est désormais le cas !

• General improvements (#1659, #1646, #1647, #1471, #1648, #1651, #1652, #1653, #1659, #1665, #1670, #1672, #1677, #1684, #1683, #1686, #1682, #1685, #1692, [#1705](https://github.com/ada

  Flower a reçu de nombreuses améliorations sous le capot, trop nombreuses pour être énumérées ici.

Changements incompatibles

Aucun

v1.3.0 (2023-02-06)

Merci à nos contributeurs

Nous tenons à remercier tout particulièrement tous les contributeurs qui ont rendu possible la nouvelle version de Flower (dans l’ordre git shortlog) :

Adam Narozniak, Alexander Viala Bellander, Charles Beauville, Daniel J. Beutel, JDRanpariya, Lennart Behme, Taner Topal

Quoi de neuf ?

• Ajouter la prise en charge de workload_id et group_id dans l’API du pilote (#1595)

  L’API (expérimentale) Driver prend désormais en charge un workload_id qui peut être utilisé pour identifier la charge de travail à laquelle une tâche appartient. Elle prend également en charge un nouveau group_id qui peut être utilisé, par exemple, pour indiquer le cycle de formation en cours. Le workload_id et le group_id permettent tous deux aux nœuds clients de décider s’ils veulent traiter une tâche ou non.

• Faire en sorte que l’adresse de l’API du conducteur et de l’API de la flotte soit configurable (#1637)

  Le serveur Flower (expérimental) de longue durée (Driver API et Fleet API) peut maintenant configurer l’adresse du serveur de Driver API (via --driver-api-address) et de Fleet API (via --fleet-api-address) lors de son démarrage :

  flower-server --driver-api-address "0.0.0.0:8081" --fleet-api-address "0.0.0.0:8086"

  Les adresses IPv4 et IPv6 sont toutes deux prises en charge.

• Ajouter un nouvel exemple d’apprentissage fédéré utilisant fastai et Flower (#1598)

  Un nouvel exemple de code (quickstart-fastai) démontre l’apprentissage fédéré avec fastai et Flower. Tu peux le trouver ici : quickstart-fastai.

• Rendre l’exemple Android compatible avec flwr >= 1.0.0 et les dernières versions d’Android (#1603)

  The Android code example has received a substantial update: the project is compatible with Flower 1.0 (and later), the UI received a full refresh, and the project is updated to be compatible with newer Android tooling.

• Ajouter une nouvelle stratégie FedProx (#1619)

  Cette stratégie est presque identique à FedAvg, mais aide les utilisateurs à reproduire ce qui est décrit dans cet article. Elle ajoute essentiellement un paramètre appelé proximal_mu pour régulariser les modèles locaux par rapport aux modèles globaux.

• Ajouter de nouvelles métriques aux événements de télémétrie (#1640)

  Une structure d’événements mise à jour permet, par exemple, de regrouper des événements au sein d’une même charge de travail.

• Ajouter une nouvelle section de tutoriel sur les stratégies personnalisées #1623

  The Flower tutorial now has a new section that covers implementing a custom strategy from scratch: Open in Colab

• Ajouter une nouvelle section de tutoriel sur la sérialisation personnalisée (#1622)

  The Flower tutorial now has a new section that covers custom serialization: Open in Colab

• General improvements (#1638, #1634, #1636, #1635, #1633, #1632, #1631, #1630, #1627, #1593, #1616, #1615, #1607, #1609, #1608, #1603, #1590, #1580, #1599, [#1600](https://github.com/ada

  Flower a reçu de nombreuses améliorations sous le capot, trop nombreuses pour être énumérées ici.

• Mise à jour de la documentation (#1629, #1628, #1620, #1618, #1617, #1613, #1614)

  Comme d’habitude, la documentation s’est beaucoup améliorée. C’est une autre étape dans notre effort pour faire de la documentation de Flower la meilleure documentation de tout projet. Reste à l’écoute et comme toujours, n’hésite pas à nous faire part de tes commentaires !

Changements incompatibles

Aucun

v1.2.0 (2023-01-13)

Merci à nos contributeurs

Nous tenons à remercier tout particulièrement tous les contributeurs qui ont rendu possible la nouvelle version de Flower (dans l’ordre git shortlog) :

adam Narozniak, Charles Beauville, Daniel J. Beutel, Edoardo, L. Jiang, Ragy, Taner Topal, dannymcy`

Quoi de neuf ?

• Introduire une nouvelle fleur Référence : FedAvg MNIST (#1497, #1552)

  Au cours des prochaines semaines, nous publierons un certain nombre de nouvelles implémentations de référence utiles en particulier pour les nouveaux venus en FL. Elles revisiteront généralement des articles bien connus de la littérature, et seront adaptées à l’intégration dans votre propre application ou à l’expérimentation, afin d’approfondir votre connaissance de FL en général. La publication d’aujourd’hui est la première de cette série. Lire la suite.

• Améliorer la prise en charge des GPU dans les simulations (#1555)

  Le moteur client virtuel basé sur Ray (start_simulation) a été mis à jour pour améliorer la prise en charge des GPU. La mise à jour inclut certaines des leçons durement apprises lors de la mise à l’échelle des simulations dans des environnements de grappes de GPU. De nouveaux paramètres par défaut rendent l’exécution des simulations basées sur les GPU beaucoup plus robuste.

• Améliorer la prise en charge du GPU dans les tutoriels Jupyter Notebook (#1527, #1558)

  Certains utilisateurs ont signalé que les carnets Jupyter n’ont pas toujours été faciles à utiliser sur les instances GPU. Nous les avons écoutés et avons apporté des améliorations à tous nos carnets Jupyter ! Découvre les carnets mis à jour ici :

  • An Introduction to Federated Learning

  • Strategies in Federated Learning

  • Building a Strategy

  • Client and NumPyClient

• Introduire la télémétrie optionnelle (#1533, #1544, #1584)

  À la suite d’une [demande de commentaires] (https://github.com/adap/flower/issues/1534) de la part de la communauté, le projet open-source Flower introduit la collecte optionnelle de mesures d’utilisation anonymes afin de prendre des décisions éclairées pour améliorer Flower. Cela permet à l’équipe de Flower de comprendre comment Flower est utilisé et quels sont les défis auxquels les utilisateurs peuvent être confrontés.

  Flower is a friendly framework for collaborative AI and data science. Staying true to this statement, Flower makes it easy to disable telemetry for users who do not want to share anonymous usage metrics. Read more..

• **(#1520, #1525, #1545, #1546, #1550, #1551, #1567)

  Flower dispose désormais d’une nouvelle API de pilote (expérimentale) qui permettra de créer des applications Federated Learning et Federated Analytics entièrement programmables, asynchrones et multi-tenant. Ouf, c’est beaucoup ! À l’avenir, l’API de pilote sera l’abstraction sur laquelle de nombreuses fonctionnalités à venir seront construites - et tu peux commencer à construire ces choses dès maintenant, aussi.

  L’API du pilote permet également un nouveau mode d’exécution dans lequel le serveur s’exécute indéfiniment. Plusieurs charges de travail individuelles peuvent s’exécuter simultanément et démarrer et arrêter leur exécution indépendamment du serveur. Ceci est particulièrement utile pour les utilisateurs qui souhaitent déployer Flower en production.

  Pour en savoir plus, consulte l’exemple de code mt-pytorch. Nous attendons tes commentaires avec impatience !

  Remarque : L’API du pilote est encore expérimentale et est susceptible de changer de manière significative au fil du temps.

• Ajouter un nouvel exemple de Federated Analytics avec Pandas (#1469, #1535)

  Un nouvel exemple de code (quickstart-pandas) démontre l’analyse fédérée avec Pandas et Flower. Tu peux le trouver ici : quickstart-pandas.

• Ajouter de nouvelles stratégies : Krum et MultiKrum (#1481)

  Edoardo, étudiant en informatique à l’Université Sapienza de Rome, a contribué à une nouvelle stratégie Krum qui permet aux utilisateurs d’utiliser facilement Krum et MultiKrum dans leurs charges de travail.

• Mettre à jour l’exemple C++ pour qu’il soit compatible avec Flower v1.2.0 (#1495)

  L’exemple de code C++ a reçu une mise à jour substantielle pour le rendre compatible avec la dernière version de Flower.

• Améliorations générales (#1491, #1504, #1506, #1514, #1522, #1523, #1526, #1528, #1547, #1549, #1560, #1564, #1566)

  Flower a reçu de nombreuses améliorations sous le capot, trop nombreuses pour être énumérées ici.

• Documentation mise à jour (#1494, #1496, #1500, #1503, #1505, #1524, #1518, #1519, #1515)

  Comme d’habitude, la documentation s’est beaucoup améliorée. C’est une autre étape dans notre effort pour faire de la documentation de Flower la meilleure documentation de tout projet. Reste à l’écoute et comme toujours, n’hésite pas à nous faire part de tes commentaires !

  L’un des points forts est le nouveau [guide du premier contributeur] (https://flower.ai/docs/first-time-contributors.html) : si tu n’as jamais contribué sur GitHub auparavant, c’est l’endroit idéal pour commencer !

Changements incompatibles

Aucun

v1.1.0 (2022-10-31)

Merci à nos contributeurs

Nous aimerions remercier tout particulièrement tous les contributeurs qui ont rendu possible la nouvelle version de Flower (dans l’ordre git shortlog) :

Akis Linardos, Christopher S, Daniel J. Beutel, George, Jan Schlicht, Mohammad Fares, Pedro Porto Buarque de Gusmão, Philipp Wiesner, Rob Luke, Taner Topal, VasundharaAgarwal, danielnugraha, edogab33

Quoi de neuf ?

• Introduire les enveloppes de confidentialité différentielle (aperçu) (#1357, #1460)

  Le premier aperçu (expérimental) des wrappers enfichables de confidentialité différentielle permet de configurer et d’utiliser facilement la confidentialité différentielle (DP). Les wrappers DP enfichables permettent une utilisation agnostique du cadre et de la stratégie à la fois de la DP côté client et de la DP côté serveur. Va voir les documents de Flower, un nouvel explicatif va plus loin dans les détails.

• Nouvel exemple de code CoreML pour iOS (#1289)

  Flower passe à iOS ! Un nouvel exemple de code massif montre comment les clients Flower peuvent être construits pour iOS. L’exemple de code contient à la fois des composants Flower iOS SDK qui peuvent être utilisés pour de nombreuses tâches, et un exemple de tâche fonctionnant sur CoreML.

• Nouvelle stratégie de FedMedian (#1461)

  La nouvelle stratégie FedMedian met en œuvre Federated Median (FedMedian) par [Yin et al., 2018] (https://arxiv.org/pdf/1803.01498v1.pdf).

• Log Client exceptions dans le moteur de client virtuel (#1493)

  Toutes les exceptions Client qui se produisent dans le VCE sont maintenant enregistrées par défaut et ne sont pas seulement exposées à la Stratégie configurée (via l’argument failures).

• Améliorer le moteur du client virtuel (#1401, #1453)

  Le VCE utilise maintenant Ray 2.0 sous le capot, le type de valeur du dictionnaire client_resources a été remplacé par float pour permettre l’allocation de fractions de ressources.

• Support optional Client/NumPyClient methods in Virtual Client Engine

  Le moteur de client virtuel prend désormais en charge les méthodes optionnelles Client (et NumPyClient).

• Fournir des informations de type aux paquets en utilisant flwr (#1377)

  Le paquet flwr est maintenant accompagné d’un fichier py.typed indiquant que le paquet est typé. Cela permet de prendre en charge le typage pour les projets ou les paquets qui utilisent flwr en leur permettant d’améliorer leur code à l’aide de vérificateurs de types statiques comme mypy.

• Exemple de code mis à jour (#1344, #1347)

  Les exemples de code couvrant scikit-learn et PyTorch Lightning ont été mis à jour pour fonctionner avec la dernière version de Flower.

• Documentation mise à jour (#1355, #1558, #1379, #1380, #1381, #1332, #1391, #1403, #1364, #1409, #1419, #1444, #1448, #1417, #1449, #1465, #1467)

  Il y a eu tellement de mises à jour de la documentation que cela n’a même pas de sens de les énumérer individuellement.

• Documentation restructurée (#1387)

  La documentation a été restructurée pour faciliter la navigation. Ce n’est que la première étape d’un effort plus important visant à faire de la documentation de Flower la meilleure documentation de tous les projets

• Ouvrir dans le bouton Colab (#1389)

  Les quatre parties du didacticiel d’apprentissage fédéré Flower sont maintenant accompagnées d’un nouveau bouton « Ouvrir dans Colab ». Pas besoin d’installer quoi que ce soit sur ta machine locale, tu peux maintenant utiliser et apprendre à connaître Flower dans ton navigateur, il te suffit d’un simple clic.

• Tutoriel amélioré (#1468, #1470, #1472, #1473, #1474, #1475)

  Le tutoriel sur l’apprentissage fédéré des fleurs a deux toutes nouvelles parties couvrant les stratégies personnalisées (encore WIP) et la distinction entre Client et NumPyClient. Les parties un et deux existantes ont également été améliorées (beaucoup de petits changements et de corrections).

Changements incompatibles

Aucun

v1.0.0 (2022-07-28)

Points forts

• Moteur de client virtuel stable** (accessible via start_simulation)

• Toutes les méthodes Client/NumPyClient sont maintenant optionnelles

• get_parameters configurable

• Des tonnes de petits nettoyages d’API résultant en une expérience plus cohérente pour les développeurs

Merci à nos contributeurs

Nous tenons à remercier particulièrement tous les contributeurs qui ont rendu Flower 1.0 possible (dans l’ordre inverse de GitHub Contributors) :

@rtaiello, @g-pichler, @rob-luke, @andreea-zaharia, @kinshukdua, @nfnt, @tatiana-s, @TParcollet, @vballoli, @negedng, @RISHIKESHAVAN, @hei411, @SebastianSpeitel, @AmitChaulwar, @Rubiel1, @FANTOME-PAN, @Rono-BC, @lbhm, @sishtiaq, @remde, @Jueun-Park, @architjen, @PratikGarai, [@mrinaald](

Changements incompatibles

• Tous les arguments doivent être passés comme des arguments de mot-clé (#1338)

  Pass all arguments as keyword arguments, positional arguments are not longer supported. Code that uses positional arguments (e.g., start_client("127.0.0.1:8080", FlowerClient())) must add the keyword for each positional argument (e.g., start_client(server_address="127.0.0.1:8080", client=FlowerClient())).

• Introduire l’objet de configuration ServerConfig dans start_server et start_simulation (#1317)

  Au lieu d’un dictionnaire de configuration {"num_rounds" : 3, "round_timeout" : 600.0}, start_server et start_simulation attendent maintenant un objet de configuration de type flwr.server.ServerConfig. ServerConfig prend les mêmes arguments que le dict de configuration précédent, mais il rend l’écriture de code sécurisé plus facile et les valeurs des paramètres par défaut plus transparentes.

• Renommer les paramètres de la stratégie intégrée pour plus de clarté (#1334)

  Les paramètres de stratégie intégrés suivants ont été renommés pour améliorer la lisibilité et la cohérence avec d’autres API :

  • fraction_eval –> fraction_evaluate

  • min_eval_clients –> min_evaluate_clients

  • eval_fn –> evaluate_fn

• Mettre à jour les arguments par défaut des stratégies intégrées (#1278)

  Toutes les stratégies intégrées utilisent désormais fraction_fit=1.0 et fraction_evaluate=1.0, ce qui signifie qu’elles sélectionnent tous les clients actuellement disponibles pour l’entraînement et l’évaluation. Les projets qui s’appuyaient sur les valeurs par défaut précédentes peuvent retrouver le comportement antérieur en initialisant la stratégie de la manière suivante :

  stratégie = FedAvg(fraction_fit=0.1, fraction_evaluate=0.1)

• Ajouter server_round à Strategy.evaluate (#1334)

  La méthode Stratégie évaluer reçoit maintenant le cycle actuel d’apprentissage/évaluation fédéré comme premier paramètre.

• Ajouter server_round et config paramètres à evaluate_fn (#1334)

  Le evaluate_fn passé aux stratégies intégrées comme FedAvg prend maintenant trois paramètres : (1) le cycle actuel d’apprentissage/évaluation fédéré (server_round), (2) les paramètres du modèle à évaluer (parameters), et (3) un dictionnaire de configuration (config).

• Rename rnd to server_round (#1321)

  Plusieurs méthodes et fonctions de Flower (evaluate_fn, configure_fit, aggregate_fit, configure_evaluate, aggregate_evaluate) reçoivent le cycle actuel d’apprentissage/évaluation fédéré comme premier paramètre. Pour améliorer la fiabilité et éviter la confusion avec random, ce paramètre a été renommé de rnd à server_round.

• Déplacer flwr.dataset vers flwr_baselines (#1273)

  Le paquet expérimental flwr.dataset a été migré vers Flower Baselines.

• Supprimer les stratégies expérimentales (#1280)

  Supprimer les stratégies expérimentales non maintenues (FastAndSlow, FedFSv0, FedFSv1).

• Rename Weights to NDArrays (#1258, #1259)

  flwr.common.Weights a été renommé en flwr.common.NDArys pour mieux rendre compte de la nature de ce type.

• Supprimez l’ancien force_final_distributed_eval de start_server (#1258, #1259)

  Le paramètre start_server force_final_distributed_eval a longtemps été un artefact historique, dans cette version il a finalement disparu pour de bon.

• Make get_parameters configurable (#1242)

  La méthode get_parameters accepte maintenant un dictionnaire de configuration, tout comme get_properties, fit, et evaluate.

• Remplace num_rounds dans start_simulation avec le nouveau config paramètre (#1281)

  La fonction start_simulation accepte maintenant un dictionnaire de configuration config au lieu de l’entier num_rounds. Cela améliore la cohérence entre start_simulation et start_server et facilite la transition entre les deux.

Quoi de neuf ?

• Support Python 3.10 (#1320)

  La version précédente de Flower a introduit la prise en charge expérimentale de Python 3.10, cette version déclare la prise en charge de Python 3.10 comme stable.

• **Rendre toutes les **méthodes Client et NumPyClient facultatives (#1260, #1277)

  Les méthodes Client/NumPyClient get_properties, get_parameters, fit, et evaluate sont toutes optionnelles. Cela permet d’écrire des clients qui n’implémentent, par exemple, que fit, mais aucune autre méthode. Pas besoin d’implémenter evaluate quand on utilise l’évaluation centralisée !

• **Autoriser le passage d’une instance Server à start_simulation (#1281)

  Comme pour start_server, start_simulation accepte maintenant une instance complète de Server. Cela permet aux utilisateurs de personnaliser fortement l’exécution des expériences et ouvre la porte à l’exécution, par exemple, de FL asynchrones à l’aide du moteur de client virtuel.

• Mettre à jour les exemples de code (#1291, #1286, #1282)

  De nombreux exemples de code ont reçu de petites ou même de grandes mises à jour de maintenance

  • scikit-learn

  • simulation_pytorch

  • quickstart_pytorch (démarrage rapide)

  • quickstart_simulation

  • quickstart_tensorflow

  • advanced_tensorflow (en anglais)

• Supprime l’exemple de simulation obsolète (#1328)

  Supprime l’exemple obsolète simulation et renomme quickstart_simulation en simulation_tensorflow pour qu’il corresponde au nom de simulation_pytorch

• Mise à jour de la documentation (#1223, #1209, #1251, #1257, #1267, #1268, #1300, #1304, #1305, #1307)

  Une mise à jour substantielle de la documentation corrige plusieurs petits problèmes de rendu, rend les titres plus succincts pour améliorer la navigation, supprime une bibliothèque obsolète, met à jour les dépendances de la documentation, inclut le module flwr.common dans la référence de l’API, inclut le support de la documentation basée sur le markdown, migre le changelog de .rst vers .md, et corrige un certain nombre de détails plus petits !

• Mises à jour mineures

  • Ajoute un chiffre rond pour ajuster et évaluer les messages du journal (#1266)

  • Ajouter une connexion gRPC sécurisée à l’exemple de code advanced_tensorflow (#847)

  • Mettre à jour les outils de développement (#1231, #1276, #1301, #1310)

  • Renomme les messages ProtoBuf pour améliorer la cohérence (#1214, #1258, #1259)

v0.19.0 (2022-05-18)

Quoi de neuf ?

• Flower Baselines (preview) : FedOpt, FedBN, FedAvgM (#919, #1127, #914)

  The first preview release of Flower Baselines has arrived! We’re kickstarting Flower Baselines with implementations of FedOpt (FedYogi, FedAdam, FedAdagrad), FedBN, and FedAvgM. Check the documentation on how to use Flower Baselines. With this first preview release we’re also inviting the community to contribute their own baselines.

• SDK client C++ (aperçu) et exemple de code (#1111)

  L’aperçu C++ comprend un SDK pour les clients Flower et un exemple de code de démarrage rapide qui démontre un client C++ simple utilisant le SDK.

• Ajouter la prise en charge expérimentale de Python 3.10 et Python 3.11 (#1135)

  Python 3.10 est la dernière version stable de Python et Python 3.11 devrait sortir en octobre. Cette version de Flower ajoute une prise en charge expérimentale pour les deux versions de Python.

• Agréger des mesures personnalisées grâce à des fonctions fournies par l’utilisateur (#1144)

  Les stratégies intégrées prennent en charge deux nouveaux arguments, fit_metrics_aggregation_fn et evaluate_metrics_aggregation_fn, qui permettent de passer des fonctions d’agrégation de métriques personnalisées.

• Temps d’attente configurable par l’utilisateur (#1162)

  Si le dictionnaire config contient une clé round_timeout (avec une valeur float en secondes), le serveur attendra au moins round_timeout secondes avant de fermer la connexion.

• Permettre l’utilisation simultanée de l’évaluation fédérée et de l’évaluation centralisée dans toutes les stratégies intégrées (#1091)

  Les stratégies intégrées peuvent maintenant effectuer une évaluation fédérée (c’est-à-dire côté client) et une évaluation centralisée (c’est-à-dire côté serveur) dans le même tour. L’évaluation fédérée peut être désactivée en réglant fraction_eval sur 0.0.

• Deux nouveaux tutoriels Jupyter Notebook (#1141)

  Deux tutoriels Jupyter Notebook (compatibles avec Google Colab) expliquent les fonctionnalités de base et intermédiaires de Flower :

  Introduction à l’apprentissage fédéré : Open in Colab

  Utiliser des stratégies dans l’apprentissage fédéré : Open in Colab

• Nouvelle stratégie FedAvgM (Federated Averaging with Server Momentum) (#1076)

  The new FedAvgM strategy implements Federated Averaging with Server Momentum [Hsu et al., 2019].

• Nouvel exemple de code PyTorch avancé (#1007)

  Un nouvel exemple de code (advanced_pytorch) démontre des concepts de fleur avancés avec PyTorch.

• Nouvel exemple de code JAX (#906, #1143)

  Un nouvel exemple de code (jax_from_centralized_to_federated) montre l’apprentissage fédéré avec JAX et Flower.

• Mises à jour mineures

  • Nouvelle option pour continuer à faire fonctionner Ray si Ray a déjà été initialisé dans start_simulation (#1177)

  • Ajout de la prise en charge d’un ClientManager personnalisé comme paramètre de start_simulation (#1171)

  • New documentation for implementing strategies (#1097, #1175)

  • Nouveau thème de documentation adapté aux mobiles (#1174)

  • Limite la plage de versions pour la dépendance (optionnelle) ray pour n’inclure que les versions compatibles (>=1.9.2,<1.12.0) (#1205)

Changements incompatibles

• Supprime la prise en charge obsolète de Python 3.6 (#871)

• Supprimez KerasClient (#857)

• Supprimer les installations supplémentaires no-op dépréciées (#973)

• Supprimez les champs proto obsolètes de FitRes et EvaluateRes (#869)

• Supprime la stratégie QffedAvg (remplacée par QFedAvg) (#1107)

• Supprime la stratégie DefaultStrategy qui est obsolète (#1142)

• Supprimer la prise en charge obsolète de la valeur de retour de la précision eval_fn (#1142)

• Supprime la prise en charge obsolète du passage des paramètres initiaux en tant que ndarrays NumPy (#1142)

v0.18.0 (2022-02-28)

Quoi de neuf ?

• Amélioration de la compatibilité du moteur de client virtuel avec Jupyter Notebook / Google Colab (#866, #872, #833, #1036)

  Les simulations (utilisant le moteur de client virtuel via start_simulation) fonctionnent maintenant plus facilement sur les Notebooks Jupyter (y compris Google Colab) après avoir installé Flower avec l’option simulation (pip install flwr[simulation]).

• Nouvel exemple de code Jupyter Notebook (#833)

  Un nouvel exemple de code (quickstart_simulation) démontre des simulations de Flower en utilisant le moteur de client virtuel via Jupyter Notebook (y compris Google Colab).

• Propriétés du client (aperçu des fonctionnalités) (#795)

  Les clients peuvent implémenter une nouvelle méthode get_properties pour permettre aux stratégies côté serveur d’interroger les propriétés du client.

• Support expérimental d’Android avec TFLite (#865)

  La prise en charge d’Android est enfin arrivée dans main ! Flower est à la fois agnostique au niveau du client et du cadre de travail. On peut intégrer des plates-formes client arbitraires et avec cette version, l’utilisation de Flower sur Android est devenue beaucoup plus facile.

  L’exemple utilise TFLite du côté client, ainsi qu’une nouvelle stratégie FedAvgAndroid. Le client Android et FedAvgAndroid sont encore expérimentaux, mais ils constituent un premier pas vers un SDK Android à part entière et une implémentation unifiée de FedAvg intégrant la nouvelle fonctionnalité de FedAvgAndroid.

• Rendre le temps de garde gRPC configurable par l’utilisateur et diminuer le temps de garde par défaut (#1069)

  Le temps de keepalive gRPC par défaut a été réduit pour augmenter la compatibilité de Flower avec davantage d’environnements cloud (par exemple, Microsoft Azure). Les utilisateurs peuvent configurer le temps de keepalive pour personnaliser la pile gRPC en fonction d’exigences spécifiques.

• Nouvel exemple de confidentialité différentielle utilisant Opacus et PyTorch (#805)

  Un nouvel exemple de code (opacus) démontre l’apprentissage fédéré différentiellement privé avec Opacus, PyTorch et Flower.

• Nouvel exemple de code pour les Transformers à visage embrassant (#863)

  Un nouvel exemple de code (quickstart_huggingface) démontre l’utilisation des transformateurs Hugging Face avec Flower.

• Nouvel exemple de code MLCube (#779, #1034, #1065, #1090)

  Un nouvel exemple de code (quickstart_mlcube) démontre l’utilisation de MLCube avec Flower.

• **(#842, #844, #845, #847, #993, #994)

  SSL permet d’établir des connexions cryptées et sécurisées entre les clients et les serveurs. Cette version met en open-source l’implémentation gRPC sécurisée de Flower afin de rendre les canaux de communication cryptés accessibles à tous les utilisateurs de Flower.

• Mise à jour FedAdam et FedYogi stratégies (#885, #895)

  FedAdam et FedAdam correspondent à la dernière version de l’article sur l’optimisation fédérée adaptative.

• Initialise start_simulation avec une liste d’ID de clients (#860)

  start_simulation peut maintenant être appelé avec une liste d’identifiants de clients (clients_ids, type : List[str]). Ces identifiants seront passés à client_fn chaque fois qu’un client doit être initialisé, ce qui peut faciliter le chargement de partitions de données qui ne sont pas accessibles par des identifiants int.

• Mises à jour mineures

  • Mettre à jour le calcul de num_examples dans les exemples de code PyTorch dans (#909)

  • Exposer la version de Flower à travers flwr.__version__ (#952)

  • start_server dans app.py renvoie maintenant un objet History contenant les métriques de l’entraînement (#974)

  • Rendre max_workers (utilisé par ThreadPoolExecutor) configurable (#978)

  • Augmente le temps de sommeil après le démarrage du serveur à trois secondes dans tous les exemples de code (#1086)

  • Ajout d’une nouvelle section FAQ à la documentation (#948)

  • Et bien d’autres changements sous le capot, des mises à jour de la bibliothèque, des modifications de la documentation et des améliorations de l’outillage !

Changements incompatibles

• Supprimé flwr_example et flwr_experimental de la version release build (#869)

  Les paquets flwr_example et flwr_experimental ont été dépréciés depuis Flower 0.12.0 et ils ne sont plus inclus dans les builds de Flower. Les extras associés (baseline, examples-pytorch, examples-tensorflow, http-logger, ops) sont maintenant no-op et seront supprimés dans une prochaine version.

v0.17.0 (2021-09-24)

Quoi de neuf ?

• Moteur expérimental de client virtuel (#781 #790 #791)

  L’un des objectifs de Flower est de permettre la recherche à grande échelle. Cette version donne un premier aperçu (expérimental) d’une nouvelle fonctionnalité majeure, connue sous le nom de code de moteur de client virtuel. Les clients virtuels permettent des simulations qui s’étendent à un (très) grand nombre de clients sur une seule machine ou une grappe de calcul. La façon la plus simple de tester la nouvelle fonctionnalité est de regarder les deux nouveaux exemples de code appelés quickstart_simulation et simulation_pytorch.

  La fonction est encore expérimentale, il n’y a donc aucune garantie de stabilité pour l’API. Elle n’est pas non plus tout à fait prête pour le prime time et s’accompagne de quelques mises en garde connues. Cependant, les personnes curieuses sont encouragées à l’essayer et à faire part de leurs réflexions.

• Nouvelles stratégies intégrées (#828 #822)

  • FedYogi - Stratégie d’apprentissage fédéré utilisant Yogi côté serveur. Mise en oeuvre basée sur https://arxiv.org/abs/2003.00295

  • FedAdam - Stratégie d’apprentissage fédéré utilisant Adam côté serveur. Mise en œuvre basée sur https://arxiv.org/abs/2003.00295

• Nouvel exemple de code PyTorch Lightning (#617)

• Nouvel exemple de code d’autocodage variationnel (#752)

• Nouvel exemple de code scikit-learn (#748)

• Nouvelle stratégie expérimentale TensorBoard (#789)

• Mises à jour mineures

  • Amélioration de l’exemple de code TensorFlow avancé (#769)

  • Avertissement lorsque min_available_clients est mal configuré (#830)

  • Amélioration de la documentation sur le serveur gRPC (#841)

  • Amélioration du message d’erreur dans NumPyClient (#851)

  • Exemple de code de démarrage rapide PyTorch amélioré (#852)

Changements incompatibles

• Désactivé l’évaluation finale distribuée (#800)

  Le comportement précédent consistait à effectuer un dernier tour d’évaluation distribuée sur tous les clients connectés, ce qui n’est souvent pas nécessaire (par exemple, lors de l’utilisation de l’évaluation côté serveur). Le comportement précédent peut être activé en passant force_final_distributed_eval=True à start_server.

• Renommé stratégie q-FedAvg (#802)

  La stratégie nommée QffedAvg a été renommée en QFedAvg pour mieux refléter la notation donnée dans l’article original (q-FFL est l’objectif d’optimisation, q-FedAvg est le solveur proposé). Notez que la classe QffedAvg originale (maintenant obsolète) est toujours disponible pour des raisons de compatibilité (elle sera supprimée dans une prochaine version).

• Exemple de code déprécié et renommé simulation_pytorch en simulation_pytorch_legacy (#791)

  Cet exemple a été remplacé par un nouvel exemple. Le nouvel exemple est basé sur le moteur expérimental du client virtuel, qui deviendra la nouvelle méthode par défaut pour effectuer la plupart des types de simulations à grande échelle dans Flower. L’exemple existant a été conservé à des fins de référence, mais il pourrait être supprimé à l’avenir.

v0.16.0 (2021-05-11)

Quoi de neuf ?

• Nouvelles stratégies intégrées (#549)

  • (résumé) FedOpt

  • FedAdagrad

• Métriques personnalisées pour le serveur et les stratégies (#717)

  Le serveur Flower est maintenant totalement agnostique, toutes les instances restantes de métriques spécifiques à une tâche (telles que accuracy) ont été remplacées par des dictionnaires de métriques personnalisées. Flower 0.15 a introduit la possibilité de passer un dictionnaire contenant des métriques personnalisées du client au serveur. À partir de cette version, les métriques personnalisées remplacent les métriques spécifiques à une tâche sur le serveur.

  Custom metric dictionaries are now used in two user-facing APIs: they are returned from Strategy methods aggregate_fit/aggregate_evaluate and they enable evaluation functions passed to built-in strategies (via eval_fn) to return more than two evaluation metrics. Strategies can even return aggregated metrics dictionaries for the server to keep track of.

  Strategy implementations should migrate their aggregate_fit and aggregate_evaluate methods to the new return type (e.g., by simply returning an empty {}), server-side evaluation functions should migrate from return loss, accuracy to return loss, {"accuracy": accuracy}.

  Les types de retour du style Flower 0.15 sont dépréciés (mais toujours pris en charge), la compatibilité sera supprimée dans une prochaine version.

• Avertissements de migration pour les fonctionnalités obsolètes (#690)

  Les versions antérieures de Flower ont souvent été migrées vers de nouvelles API, tout en maintenant la compatibilité avec les anciennes API. Cette version introduit des messages d’avertissement détaillés si l’utilisation d’API obsolètes est détectée. Les nouveaux messages d’avertissement fournissent souvent des détails sur la façon de migrer vers des API plus récentes, facilitant ainsi la transition d’une version à l’autre.

• Amélioration des docs et des docstrings (#691 #692 #713)

• Exemple et documentation MXNet

• Mise en œuvre de FedBN dans l’exemple PyTorch : De la centralisation à la fédération (#696 #702 #705)

Changements incompatibles

• Serveur agnostique de sérialisation (#721)

  Le serveur Flower est désormais totalement agnostique en matière de sérialisation. L’utilisation antérieure de la classe Weights (qui représente les paramètres sous forme de tableaux NumPy désérialisés) a été remplacée par la classe Parameters (par exemple, dans Strategy). Les objets Parameters sont totalement agnostiques en matière de sérialisation et représentent les paramètres sous forme de tableaux d’octets, les attributs tensor_type indiquent comment ces tableaux d’octets doivent être interprétés (par exemple, pour la sérialisation/désérialisation).

  Les stratégies intégrées mettent en œuvre cette approche en gérant en interne la sérialisation et la désérialisation de Weights. Les implémentations de stratégies personnalisées ou tierces doivent être mises à jour avec les définitions de méthodes de stratégie légèrement modifiées. Les auteurs de stratégies peuvent consulter le PR #721 pour voir comment les stratégies peuvent facilement migrer vers le nouveau format.

• Déclassé flwr.server.Server.evaluate, utiliser flwr.server.Server.evaluate_round à la place (#717)

v0.15.0 (2021-03-12)

Quoi de neuf ?

• Initialisation des paramètres côté serveur (#658)

  Les paramètres du modèle peuvent maintenant être initialisés côté serveur. L’initialisation des paramètres côté serveur fonctionne via une nouvelle méthode Strategy appelée initialize_parameters.

  Les stratégies intégrées prennent en charge un nouvel argument du constructeur appelé initial_parameters pour définir les paramètres initiaux. Les stratégies intégrées fourniront ces paramètres initiaux au serveur au démarrage et les supprimeront ensuite pour libérer la mémoire.

  # Create model
  model = tf.keras.applications.EfficientNetB0(
      input_shape=(32, 32, 3), weights=None, classes=10
  )
  model.compile("adam", "sparse_categorical_crossentropy", metrics=["accuracy"])
  
  # Create strategy and initialize parameters on the server-side
  strategy = fl.server.strategy.FedAvg(
      # ... (other constructor arguments)
      initial_parameters=model.get_weights(),
  )
  
  # Start Flower server with the strategy
  fl.server.start_server("[::]:8080", config={"num_rounds": 3}, strategy=strategy)
  

  Si aucun paramètre initial n’est fourni à la stratégie, le serveur continuera à utiliser le comportement actuel (à savoir qu’il demandera à l’un des clients connectés ses paramètres et les utilisera comme paramètres globaux initiaux).

Dépréciations

• Déclasser flwr.server.strategy.DefaultStrategy (migrer vers flwr.server.strategy.FedAvg, qui est équivalent)

v0.14.0 (2021-02-18)

Quoi de neuf ?

• Généralisé Client.fit et Client.evaluate valeurs de retour (#610 #572 #633)

  Les clients peuvent maintenant renvoyer un dictionnaire supplémentaire associant les clés str aux valeurs des types suivants : bool, bytes, float, int, str. Cela signifie que l’on peut renvoyer des valeurs presque arbitraires de fit/evaluate et les utiliser du côté du serveur !

  Cette amélioration a également permis de rendre plus cohérents les types de retour entre fit et evaluate : evaluate devrait maintenant retourner un tuple (float, int, dict) représentant la perte, le nombre d’exemples, et un dictionnaire contenant des valeurs arbitraires spécifiques au problème comme la précision.

  Au cas où tu te poserais la question : cette fonctionnalité est compatible avec les projets existants, la valeur de retour supplémentaire du dictionnaire est facultative. Le nouveau code doit cependant migrer vers les nouveaux types de retour pour être compatible avec les prochaines versions de Flower (fit : List[np.ndarray], int, Dict[str, Scalar], evaluate : float, int, Dict[str, Scalar]). Voir l’exemple ci-dessous pour plus de détails.

  Exemple de code: note les valeurs de retour du dictionnaire supplémentaires dans FlwrClient.fit et FlwrClient.evaluate :

  class FlwrClient(fl.client.NumPyClient):
      def fit(self, parameters, config):
          net.set_parameters(parameters)
          train_loss = train(net, trainloader)
          return net.get_weights(), len(trainloader), {"train_loss": train_loss}
  
      def evaluate(self, parameters, config):
          net.set_parameters(parameters)
          loss, accuracy, custom_metric = test(net, testloader)
          return loss, len(testloader), {"accuracy": accuracy, "custom_metric": custom_metric}
  

• Généralisé config argument dans Client.fit et Client.evaluate (#595)

  L’argument config était auparavant de type Dict[str, str], ce qui signifie que les valeurs du dictionnaire devaient être des chaînes. La nouvelle version généralise cela pour permettre les valeurs des types suivants : bool, bytes, float, int, str.

  Cela signifie que l’on peut maintenant passer des valeurs presque arbitraires à fit/evaluate en utilisant le dictionnaire config. Yay, plus de str(epochs) du côté serveur et int(config["epochs"]) du côté client !

  Exemple de code: Notez que le dictionnaire config contient maintenant des valeurs autres que str dans Client.fit et Client.evaluate :

  class FlwrClient(fl.client.NumPyClient):
      def fit(self, parameters, config):
          net.set_parameters(parameters)
          epochs: int = config["epochs"]
          train_loss = train(net, trainloader, epochs)
          return net.get_weights(), len(trainloader), {"train_loss": train_loss}
  
      def evaluate(self, parameters, config):
          net.set_parameters(parameters)
          batch_size: int = config["batch_size"]
          loss, accuracy = test(net, testloader, batch_size)
          return loss, len(testloader), {"accuracy": accuracy}
  

v0.13.0 (2021-01-08)

Quoi de neuf ?

• Nouvel exemple : PyTorch de centralisé à fédéré (#549)

• Amélioration de la documentation

  • Nouveau thème de documentation (#551)

  • Nouvelle référence API (#554)

  • Mise à jour de la documentation des exemples (#549)

  • Suppression de la documentation obsolète (#548)

Correction de bogues :

• Server.fit ne déconnecte pas les clients lorsqu’il est terminé, la déconnexion des clients est maintenant gérée dans flwr.server.start_server (#553 #540).

v0.12.0 (2020-12-07)

Changements importants :

• Ajout d’un exemple pour les périphériques embarqués (#507)

• Ajout d’un nouveau NumPyClient (en plus du KerasClient existant) (#504 #508)

• Déclassement du paquet flwr_example et migration des exemples dans le répertoire de premier niveau examples (#494 #512)

v0.11.0 (2020-11-30)

Changements incompatibles :

• Renommé les méthodes de stratégie (#486) pour unifier le nommage des API publiques de Flower. D’autres méthodes/fonctions publiques (par exemple, toutes les méthodes de Client, mais aussi Strategy.evaluate) n’utilisent pas le préfixe on_, c’est pourquoi nous le supprimons des quatre méthodes de Stratégie. Pour migrer, renommez les méthodes de Strategy suivantes en conséquence :

  • on_configure_evaluate => configure_evaluate

  • on_aggregate_evaluate => aggregate_evaluate

  • on_configure_fit => configure_fit

  • on_aggregate_fit => aggregate_fit

Changements importants :

• Déclassé DefaultStrategy (#479). Pour migrer, utilisez FedAvg à la place.

• Exemples simplifiés et lignes de base (#484).

• Suppression de on_conclude_round actuellement inutilisé de l’interface de stratégie (#483).

• Fixe la version minimale de Python à 3.6.1 au lieu de 3.6.9 (#471).

• Amélioration des docstrings Stratégie (#470).