Changelog

v1.12.0 (2024-10-14)

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, Audris, Charles Beauville, Chong Shen Ng, Daniel J. Beutel, Daniel Nata Nugraha, Heng Pan, Javier, Jiahao Tan, Julian Rußmeyer, Mohammad Naseri, Ray Sun, Robert Steiner, Yan Gao, xiliguguagua

Quoi de neuf ?

  • Introduce SuperExec log streaming (#3577, #3584, #4242, #3611, #3613)

    Flower now supports log streaming from a remote SuperExec using the flwr log command. This new feature allows you to monitor logs from SuperExec in real time via flwr log <run-id> (or flwr log <run-id> <app-dir> <federation>).

  • Improve flwr new templates (#4291, #4292, #4293, #4294, #4295)

    The flwr new command templates for MLX, NumPy, sklearn, JAX, and PyTorch have been updated to improve usability and consistency across frameworks.

  • Migrate ID handling to use unsigned 64-bit integers (#4170, #4237, #4243)

    Node IDs, run IDs, and related fields have been migrated from signed 64-bit integers (sint64) to unsigned 64-bit integers (uint64). To support this change, the uint64 type is fully supported in all communications. You may now use uint64 values in config and metric dictionaries. For Python users, that means using int values larger than the maximum value of sint64 but less than the maximum value of uint64.

  • Add Flower architecture explanation (#3270)

    A new Flower architecture explainer page introduces Flower components step-by-step. Check out the EXPLANATIONS section of the Flower documentation if you’re interested.

  • Introduce FedRep baseline (#3790)

    FedRep is a federated learning algorithm that learns shared data representations across clients while allowing each to maintain personalized local models, balancing collaboration and individual adaptation. Read all the details in the paper: « Exploiting Shared Representations for Personalized Federated Learning » (arxiv)

  • Improve FlowerTune template and LLM evaluation pipelines (#4286, #3769, #4272, #4257, #4220, #4282, #4171, #4228, #4258, #4296, #4287, #4217, #4249, #4324, #4219, #4327)

    Refined evaluation pipelines, metrics, and documentation for the upcoming FlowerTune LLM Leaderboard across multiple domains including Finance, Medical, and general NLP. Stay tuned for the official launch—we welcome all federated learning and LLM enthusiasts to participate in this exciting challenge!

  • Enhance Docker Support and Documentation (#4191, #4251, #4190, #3928, #4298, #4192, #4136, #4187, #4261, #4177, #4176, #4189, #4297, #4226)

    Upgraded Ubuntu base image to 24.04, added SBOM and gcc to Docker images, and comprehensively updated Docker documentation including quickstart guides and distributed Docker Compose instructions.

  • Introduce Flower glossary (#4165, #4235)

    Added the Federated Learning glossary to the Flower repository, located under the flower/glossary/ directory. This resource aims to provide clear definitions and explanations of key FL concepts. Community contributions are highly welcomed to help expand and refine this knowledge base — this is probably the easiest way to become a Flower contributor!

  • Implement Message Time-to-Live (TTL) (#3620, #3596, #3615, #3609, #3635)

    Added comprehensive TTL support for messages in Flower’s SuperLink. Messages are now automatically expired and cleaned up based on configurable TTL values, available through the low-level API (and used by default in the high-level API).

  • Improve FAB handling (#4303, #4264, #4305, #4304)

    An 8-character hash is now appended to the FAB file name. The flwr install command installs FABs with a more flattened folder structure, reducing it from 3 levels to 1.

  • Update documentation (#3341, #3338, #3927, #4152, #4151, #3993)

    Updated quickstart tutorials (PyTorch Lightning, TensorFlow, Hugging Face, Fastai) to use the new flwr run command and removed default title from documentation base template. A new blockchain example has been added to FAQ.

  • Update example projects (#3716, #4007, #4130, #4234, #4206, #4188, #4247, #4331)

    Refreshed multiple example projects including vertical FL, PyTorch (advanced), Pandas, Secure Aggregation, and XGBoost examples. Optimized Hugging Face quickstart with a smaller language model and removed legacy simulation examples.

  • Update translations (#4070, #4316, #4252, #4256, #4210, #4263, #4259)

  • General improvements (#4239, 4276, 4204, 4184, 4227, 4183, 4202, 4250, 4267, 4246, 4240, 4265, 4238, 4275, 4318, #4178, #4315, #4241, #4289, #4290, #4181, #4208, #4225, #4314, #4174, #4203, #4274, #3154, #4201, #4268, #4254, #3990, #4212, #2938, #4205, #4222, #4313, #3936, #4278, #4319, #4332, #4333)

    As always, many parts of the Flower framework and quality infrastructure were improved and updated.

Changements incompatibles

  • Drop Python 3.8 support and update minimum version to 3.9 (#4180, #4213, #4193, #4199, #4196, #4195, #4198, #4194)

    Python 3.8 support was deprecated in Flower 1.9, and this release removes support. Flower now requires Python 3.9 or later (Python 3.11 is recommended). CI and documentation were updated to use Python 3.9 as the minimum supported version. Flower now supports Python 3.9 to 3.12.

v1.11.1 (2024-09-11)

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) :

Charles Beauville, Chong Shen Ng, Daniel J. Beutel, Heng Pan, Javier, Robert Steiner, Yan Gao

Improvements

  • Implement keys/values/items methods for TypedDict (#4146)

  • Fix parsing of --executor-config if present (#4125)

  • Adjust framework name in templates docstrings (#4127)

  • Update flwr new Hugging Face template (#4169)

  • Fix flwr new FlowerTune template (#4123)

  • Add buffer time after ServerApp thread initialization (#4119)

  • Handle unsuitable resources for simulation (#4143)

  • Update example READMEs (#4117)

  • Update SuperNode authentication docs (#4160)

Changements incompatibles

Aucun

v1.11.0 (2024-08-30)

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, Chong Shen Ng, Daniel J. Beutel, Daniel Nata Nugraha, Danny, Edoardo Gabrielli, Heng Pan, Javier, Meng Yan, Michal Danilowski, Mohammad Naseri, Robert Steiner, Steve Laskaridis, Taner Topal, Yan Gao

Quoi de neuf ?

  • Deliver Flower App Bundle (FAB) to SuperLink and SuperNodes (#4006, #3945, #3999, #4027, #3851, #3946, #4003, #4029, #3942, #3957, #4020, #4044, #3852, #4019, #4031, #4036, #4049, #4017, #3943, #3944, #4011, #3619)

    Dynamic code updates are here! flwr run can now ship and install the latest version of your ServerApp and ClientApp to an already-running federation (SuperLink and SuperNodes).

    How does it work? flwr run bundles your Flower app into a single FAB (Flower App Bundle) file. It then ships this FAB file, via the SuperExec, to both the SuperLink and those SuperNodes that need it. This allows you to keep SuperExec, SuperLink and SuperNodes running as permanent infrastructure, and then ship code updates (including completely new projects!) dynamically.

    flwr run is all you need.

  • Introduce isolated ClientApp execution (#3970, #3976, #4002, #4001, #4034, #4037, #3977, #4042, #3978, #4039, #4033, #3971, #4035, #3973, #4032)

    The SuperNode can now run your ClientApp in a fully isolated way. In an enterprise deployment, this allows you to set strict limits on what the ClientApp can and cannot do.

    flower-supernode supports three --isolation modes:

    • Unset: The SuperNode runs the ClientApp in the same process (as in previous versions of Flower). This is the default mode.

    • --isolation=subprocess: The SuperNode starts a subprocess to run the ClientApp.

    • --isolation=process: The SuperNode expects an externally-managed process to run the ClientApp. This external process is not managed by the SuperNode, so it has to be started beforehand and terminated manually. The common way to use this isolation mode is via the new flwr/clientapp Docker image.

  • Improve Docker support for enterprise deployments (#4050, #4090, #3784, #3998, #4094, #3722)

    Flower 1.11 ships many Docker improvements that are especially useful for enterprise deployments:

    • flwr/supernode comes with a new Alpine Docker image.

    • flwr/clientapp is a new image to be used with the --isolation=process option. In this mode, SuperNode and ClientApp run in two different Docker containers. flwr/supernode (preferably the Alpine version) runs the long-running SuperNode with --isolation=process. flwr/clientapp runs the ClientApp. This is the recommended way to deploy Flower in enterprise settings.

    • New all-in-one Docker Compose enables you to easily start a full Flower Deployment Engine on a single machine.

    • Completely new Docker documentation: https://flower.ai/docs/framework/docker/index.html

  • Improve SuperNode authentication (#4043, #4047, #4074)

    SuperNode auth has been improved in several ways, including improved logging, improved testing, and improved error handling.

  • Update flwr new templates (#3933, #3894, #3930, #3931, #3997, #3979, #3965, #4013, #4064)

    All flwr new templates have been updated to show the latest recommended use of Flower APIs.

  • Improve Simulation Engine (#4095, #3913, #4059, #3954, #4071, #3985, #3988)

    The Flower Simulation Engine comes with several updates, including improved run config support, verbose logging, simulation backend configuration via flwr run, and more.

  • Improve RecordSet (#4052, #3218, #4016)

    RecordSet is the core object to exchange model parameters, configuration values and metrics between ClientApp and ServerApp. This release ships several smaller improvements to RecordSet and related *Record types.

  • Update documentation (#3972, #3925, #4061, #3984, #3917, #3900, #4066, #3765, #4021, #3906, #4063, #4076, #3920, #3916)

    Many parts of the documentation, including the main tutorial, have been migrated to show new Flower APIs and other new Flower features like the improved Docker support.

  • Migrate code example to use new Flower APIs (#3758, #3701, #3919, #3918, #3934, #3893, #3833, #3922, #3846, #3777, #3874, #3873, #3935, #3754, #3980, #4089, #4046, #3314, #3316, #3295, #3313)

    Many code examples have been migrated to use new Flower APIs.

  • Update Flower framework, framework internals and quality infrastructure (#4018, #4053, #4098, #4067, #4105, #4048, #4107, #4069, #3915, #4101, #4108, #3914, #4068, #4041, #4040, #3986, #4026, #3961, #3975, #3983, #4091, #3982, #4079, #4073, #4060, #4106, #4080, #3974, #3996, #3991, #3981, #4093, #4100, #3939, #3955, #3940, #4038)

    As always, many parts of the Flower framework and quality infrastructure were improved and updated.

Dépréciations

  • Deprecate accessing Context via Client.context (#3797)

    Now that both client_fn and server_fn receive a Context object, accessing Context via Client.context is deprecated. Client.context will be removed in a future release. If you need to access Context in your Client implementation, pass it manually when creating the Client instance in client_fn:

    def client_fn(context: Context) -> Client:
    return FlowerClient(context).to_client()

Changements incompatibles

  • Update CLIs to accept an app directory instead of ClientApp and ServerApp (#3952, #4077, #3850)

    The CLI commands flower-supernode and flower-server-app now accept an app directory as argument (instead of references to a ClientApp or ServerApp). An app directory is any directory containing a pyproject.toml file (with the appropriate Flower config fields set). The easiest way to generate a compatible project structure is to use flwr new.

  • Disable flower-client-app CLI command (#4022)

    flower-client-app has been disabled. Use flower-supernode instead.

  • Use spaces instead of commas for separating config args (#4000)

    When passing configs (run config, node config) to Flower, you now need to separate key-value pairs using spaces instead of commas. For example:

    flwr run . --run-config "learning-rate=0.01 num_rounds=10"  # Works

    Previously, you could pass configs using commas, like this:

    flwr run . --run-config "learning-rate=0.01,num_rounds=10"  # Doesn't work

  • Remove flwr example CLI command (#4084)

    The experimental flwr example CLI command has been removed. Use flwr new to generate a project and then run it using flwr run.

v1.10.0 (2024-07-24)

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, Chong Shen Ng, Daniel J. Beutel, Daniel Nata Nugraha, Danny, Gustavo Bertoli, Heng Pan, Ikko Eltociear Ashimine, Javier, Jiahao Tan, Mohammad Naseri, Robert Steiner, Sebastian van der Voort, Taner Topal, Yan Gao

Quoi de neuf ?

  • Introduce flwr run (beta) (#3810, #3826, #3880, #3807, #3800, #3814, #3811, #3809, #3819)

    Flower 1.10 ships the first beta release of the new flwr run command. flwr run can run different projects using flwr run path/to/project, it enables you to easily switch between different federations using flwr run . federation and it runs your Flower project using either local simulation or the new (experimental) SuperExec service. This allows Flower to scale federatated learning from fast local simulation to large-scale production deployment, seamlessly. All projects generated with flwr new are immediately runnable using flwr run. Give it a try: use flwr new to generate a project and then run it using flwr run.

  • Introduce run config (#3751, #3750, #3845, #3824, #3746, #3728, #3730, #3725, #3729, #3580, #3578, #3576, #3798, #3732, #3815)

    The new run config feature allows you to run your Flower project in different configurations without having to change a single line of code. You can now build a configurable ServerApp and ClientApp that read configuration values at runtime. This enables you to specify config values like learning-rate=0.01 in pyproject.toml (under the [tool.flwr.app.config] key). These config values can then be easily overridden via flwr run --run-config learning-rate=0.02, and read from Context using lr = context.run_config["learning-rate"]. Create a new project using flwr new to see run config in action.

  • Generalize client_fn signature to client_fn(context: Context) -> Client (#3779, #3697, #3694, #3696)

    The client_fn signature has been generalized to client_fn(context: Context) -> Client. It now receives a Context object instead of the (now depreacated) cid: str. Context allows accessing node_id, node_config and run_config, among other things. This enables you to build a configurable ClientApp that leverages the new run config system.

    The previous signature client_fn(cid: str) is now deprecated and support for it will be removed in a future release. Use client_fn(context: Context) -> Client everywhere.

  • Introduce new server_fn(context) (#3773, #3796, #3771)

    In addition to the new client_fn(context:Context), a new server_fn(context: Context) -> ServerAppComponents can now be passed to ServerApp (instead of passing, for example, Strategy, directly). This enables you to leverage the full Context on the server-side to build a configurable ServerApp.

  • Relaunch all flwr new templates (#3877, #3821, #3587, #3795, #3875, #3859, #3760)

    All flwr new templates have been significantly updated to showcase new Flower features and best practices. This includes using flwr run and the new run config feature. You can now easily create a new project using flwr new and, after following the instructions to install it, flwr run it.

  • Introduce flower-supernode (preview) (#3353)

    The new flower-supernode CLI is here to replace flower-client-app. flower-supernode brings full multi-app support to the Flower client-side. It also allows to pass --node-config to the SuperNode, which is accessible in your ClientApp via Context (using the new client_fn(context: Context) signature).

  • Introduce node config (#3782, #3780, #3695, #3886)

    A new node config feature allows you to pass a static configuration to the SuperNode. This configuration is read-only and available to every ClientApp running on that SuperNode. A ClientApp can access the node config via Context (context.node_config).

  • Introduce SuperExec (experimental) (#3605, #3723, #3731, #3589, #3604, #3622, #3838, #3720, #3606, #3602, #3603, #3555, #3808, #3724, #3658, #3629)

    This is the first experimental release of Flower SuperExec, a new service that executes your runs. It’s not ready for production deployment just yet, but don’t hesitate to give it a try if you’re interested.

  • Add new federated learning with tabular data example (#3568)

    A new code example exemplifies a federated learning setup using the Flower framework on the Adult Census Income tabular dataset.

  • Create generic adapter layer (preview) (#3538, #3536, #3540)

    A new generic gRPC adapter layer allows 3rd-party frameworks to integrate with Flower in a transparent way. This makes Flower more modular and allows for integration into other federated learning solutions and platforms.

  • Refactor Flower Simulation Engine (#3581, #3471, #3804, #3468, #3839, #3806, #3861, #3543, #3472, #3829, #3469)

    The Simulation Engine was significantly refactored. This results in faster and more stable simulations. It is also the foundation for upcoming changes that aim to provide the next level of performance and configurability in federated learning simulations.

  • Optimize Docker containers (#3591)

    Flower Docker containers were optimized and updated to use that latest Flower framework features.

  • Improve logging (#3776, #3789)

    Improved logging aims to be more concise and helpful to show you the details you actually care about.

  • Refactor framework internals (#3621, #3792, #3772, #3805, #3583, #3825, #3597, #3802, #3569)

    As always, many parts of the Flower framework and quality infrastructure were improved and updated.

Documentation improvements

Dépréciations

  • Deprecate client_fn(cid: str)

    client_fn used to have a signature client_fn(cid: str) -> Client. This signature is now deprecated. Use the new signature client_fn(context: Context) -> Client instead. The new argument context allows accessing node_id, node_config, run_config and other Context features. When running using the simulation engine (or using flower-supernode with a custom --node-config partition-id=...), context.node_config["partition-id"] will return an int partition ID that can be used with Flower Datasets to load a different partition of the dataset on each simulated or deployed SuperNode.

  • Deprecate passing Server/ServerConfig/Strategy/ClientManager to ServerApp directly

    Creating ServerApp using ServerApp(config=config, strategy=strategy) is now deprecated. Instead of passing Server/ServerConfig/Strategy/ClientManager to ServerApp directly, pass them wrapped in a server_fn(context: Context) -> ServerAppComponents function, like this: ServerApp(server_fn=server_fn). ServerAppComponents can hold references to Server/ServerConfig/Strategy/ClientManager. In addition to that, server_fn allows you to access Context (for example, to read the run_config).

Changements incompatibles

  • Remove support for client_ids in start_simulation (#3699)

    The (rarely used) feature that allowed passing custom client_ids to the start_simulation function was removed. This removal is part of a bigger effort to refactor the simulation engine and unify how the Flower internals work in simulation and deployment.

  • Remove flower-driver-api and flower-fleet-api (#3418)

    The two deprecated CLI commands flower-driver-api and flower-fleet-api were removed in an effort to streamline the SuperLink developer experience. Use flower-superlink instead.

v1.9.0 (2024-06-10)

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, Chong Shen Ng, Daniel J. Beutel, Daniel Nata Nugraha, Heng Pan, Javier, Mahdi Beitollahi, Robert Steiner, Taner Topal, Yan Gao, bapic, mohammadnaseri

Quoi de neuf ?

Dépréciations

  • Deprecate Python 3.8 support

    Python 3.8 will stop receiving security fixes in October 2024. Support for Python 3.8 is now deprecated and will be removed in an upcoming release.

  • Deprecate (experimental) flower-driver-api and flower-fleet-api (#3416, #3420)

    Flower 1.9 deprecates the two (experimental) commands flower-driver-api and flower-fleet-api. Both commands will be removed in an upcoming release. Use flower-superlink instead.

  • Deprecate --server in favor of --superlink (#3518)

    The commands flower-server-app and flower-client-app should use --superlink instead of the now deprecated --server. Support for --server will be removed in a future release.

Changements incompatibles

  • Replace flower-superlink CLI option --certificates with --ssl-ca-certfile , --ssl-certfile and --ssl-keyfile (#3512, #3408)

    SSL-related flower-superlink CLI arguments were restructured in an incompatible way. Instead of passing a single --certificates flag with three values, you now need to pass three flags (--ssl-ca-certfile, --ssl-certfile and --ssl-keyfile) with one value each. Check out the SSL connections documentation page for details.

  • Remove SuperLink --vce option (#3513)

    Instead of separately starting a SuperLink and a ServerApp for simulation, simulations must now be started using the single flower-simulation command.

  • Merge --grpc-rere and --rest SuperLink options (#3527)

    To simplify the usage of flower-superlink, previously separate sets of CLI options for gRPC and REST were merged into one unified set of options. Consult the Flower CLI reference documentation for details.

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 ?

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

  • 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 :

  • 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).