Name | Modified | Size | Downloads / Week |
---|---|---|---|
Parent folder | |||
flwr-1.17.0-py3-none-any.whl | 2025-03-24 | 542.5 kB | |
flwr-1.17.0.tar.gz | 2025-03-24 | 321.6 kB | |
Flower 1.17.0 source code.tar.gz | 2025-03-24 | 68.0 MB | |
Flower 1.17.0 source code.zip | 2025-03-24 | 69.4 MB | |
README.md | 2025-03-24 | 7.7 kB | |
Totals: 5 Items | 138.3 MB | 0 |
Thanks to our contributors
We would like to give our special thanks to all the contributors who made the new version of Flower possible (in git shortlog
order):
Aline Almeida
, Charles Beauville
, Chong Shen Ng
, Daniel Hinjos García
, Daniel J. Beutel
, Daniel Nata Nugraha
, Dimitris Stripelis
, Heng Pan
, Javier
, Robert Steiner
, Yan Gao
What's new?
- Allow registration of functions for custom message types (#5093)
Enables support for custom message types in ServerApp
by allowing the message_type
field to be set as "<action_type>.<action_name>"
, where <action_type>
is one of train
, evaluate
, or query
, and <action_name>
is a valid Python identifier. Developers can now register handler functions for these custom message types using the decorator @app.<action_type>("<action_name>")
. For example, the my_echo_fn
function is called when the ServerApp
sends a message with message_type
set to "query.echo"
, and the get_mean_value
function is called when it's "query.mean"
:
```python app = ClientApp()
@app.query("echo") def my_echo_fn(message: Message, context: Context): # Echo the incoming message return Message(message.content, reply_to=message)
@app.query("mean") def get_mean_value(message: Message, context: Context): # Calculate the mean value mean = ... # Replace with actual computation
# Wrap the result in a MetricRecord, then in a RecordDict
metrics = MetricRecord({"mean": mean})
content = RecordDict({"metrics": metrics})
return Message(content, reply_to=message)
```
- Rename core Message API components for clarity and consistency (#5140, #5133, #5139, #5129, #5150, #5151, #5146, #5152)
To improve clarity and ensure consistency across the Message API, the following renamings have been made:
Driver
→Grid
RecordSet
→RecordDict
ParametersRecord
→ArrayRecord
MetricsRecord
→MetricRecord
ConfigsRecord
→ConfigRecord
Backward compatibility is maintained for all the above changes, and deprecation notices have been introduced to support a smooth transition.
One-liner conversions are now supported between Array
and numpy.ndarray
or torch.Tensor
, and between ArrayRecord
(formerly ParametersRecord
) and PyTorch state_dict
or a list of numpy.ndarray
. This simplifies workflows involving model parameters and tensor data structures. Example usage includes ArrayRecord(model.state_dict())
and array_record.to_torch_state_dict()
. Refer to the ArrayRecord and Array documentation for details.
Revamps the Message
creation workflow by enabling direct instantiation via the Message(...)
constructor. This deprecates the previous APIs and simplifies message creation:
Driver.create_message(...)
→Message(...)
-
<some_message>.create_reply(...)
→Message(..., reply_to=<some_message>)
-
Stabilize low-level Message API (#5120)
With all the changes above, the stability of the low-level Message API has been significantly improved. All preview feature warnings have been removed, marking the completion of its transition out of experimental status.
- Add node availability check to reduce wait time (#4968)
Adds a node availability check to SuperLink. If the target SuperNode is offline, SuperLink automatically generates an error reply message when the ServerApp attempts to pull the reply. This mechanism helps avoid unnecessary delays in each round caused by waiting for responses from unavailable nodes.
- Enable extensible event logging for FleetServicer and ExecServicer (#4998, #4997, #4951, #4950, #5108)
Introduces the necessary hooks and infrastructure to support RPC event logging for FleetServicer
and ExecServicer
. This enables advanced auditing and observability of RPC calls made by flwr CLI
users and SuperNodes, when appropriate event log plugins are available.
- Add CareQA benchmark for medical LLM evaluation (#4966)
Adds the CareQA dataset as a new benchmark for evaluating medical knowledge in LLMs. CareQA consists of 5,621 QA pairs from official Spanish healthcare exams (2020–2024), translated to English and covering multiple disciplines. This enhances the diversity of datasets used in the Flower Medical LLM Leaderboard.
Fixes inaccurate or outdated docstrings in RecordDict
and the FlowerClient
used in FlowerTune templates, improving documentation clarity. Also adds handling for Ray nodes that report zero CPU resources, preventing potential runtime issues.
-
Improve documentation and examples (#5162, #5079, #5123, #5066, #5143, #5118, #5148, #5134, #5080, #5160, #5069, #5032)
-
Update CI/CD (#5125, #5062, #5056, #5048, #5065, #5061, #5057, #5064, #5144)
As always, many parts of the Flower framework and quality infrastructure were improved and updated.