Announcing Flower 1.17

Just 2 days before the Flower AI Summit 2025, the Flower team is excited to announce the release of Flower 1.17 stable, packed with new updates! Flower is a friendly framework for collaborative AI and data science. It makes novel approaches such as federated learning, federated evaluation, federated analytics, and fleet learning accessible to a wide audience of researchers and engineers.

Join us at the summit to dive deeper into these innovations and explore the future of AI!

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

  Copy

  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.

• Enable seamless conversions between ArrayRecord/Array and NumPy/PyTorch types (#4922, #4920)

  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.

• Revamp message creation using Message constructor (#5137, #5153)

  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.

• Fix docstrings and improve handling of Ray nodes without CPU resources (#5155, #5076, #5132)

  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)

• General Improvements (#5074, #5126, #5122, #5149, #5157)

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