Supercharging the Federated Learning Ecosystem by Integrating Flower and NVIDIA FLARE

In recent years, open-source systems like Flower and NVIDIA FLARE have emerged as pivotal tools in the federated learning (FL) landscape, each with its unique focus. Flower champions a unified approach to FL, enabling researchers and developers to design, analyze, and evaluate FL applications with ease. Over time, it has amassed a rich suite of strategies and algorithms, fostering a thriving community across academia and industry.

On the other hand, NVIDIA FLARE targets production-grade applications, delivering an enterprise-ready runtime environment built for reliability and scalability. By focusing on robust infrastructure, FLARE empowers FL deployments to meet the demands of real-world environments seamlessly.

This post describes our efforts in bridging these two frameworks, showing how their combined strengths can elevate the FL ecosystem as a whole. This integration enables applications developed with Flower to run natively on the FLARE runtime without requiring any code modifications. By unifying Flower’s widely adopted, easy-to-use design tools and APIs with FLARE’s industrial-grade runtime, this integration simplifies the end-to-end deployment pipeline.

The result? A seamless, efficient, and highly accessible FL workflow that bridges research innovation with production readiness, supercharging federated learning for both researchers and practitioners alike.

Integration goals: Deploying Flower apps through FLARE

The vision is simple: Enable users to deploy Flower ServerApps and ClientApps directly within the FLARE runtime without the need for code modifications.

Here’s how it works. Both Flower and FLARE share a similar architectural foundation based on client/server communication. Both Flower and FLARE rely on gRPC for communication between clients and the server, and they both offer multi-job support—enabling multiple jobs to share clients and servers without requiring extra open ports on the server host.

This shared architecture makes integrating the two frameworks straightforward. By using FLARE as the communicator for Flower applications, you can transform any Flower app into a FLARE job. This process shifts Flower’s SuperNodes away from direct communication through SuperLink, instead routing them through FLARE’s runtime environment (Figure 1).

This integration isn’t just seamless—it’s powerful. Here’s what it unlocks:

• Effortless provisioning: FLARE provides startup kits, including certificates, to simplify initialization.
• Custom code deployment: You can deploy tailored code for unique application needs without friction using Flower’s user-friendly APIs and dev environment.
• Tested implementations: You can build on top of an extensive library of federated algorithms provided by the Flower community.
• Enhanced security: Built-in authentication and authorization mechanisms ensure secure access and control.
• Reliable communication: With FLARE’s ReliableMessage feature, connection stability issues are resolved.
• Protocol flexibility: Support for multiple communication protocols, including gRPC, HTTP, TCP, and Redis, ensures adaptable implementation.
• Peer-to-peer communication: P2P capabilities enable direct interaction between parties, opening up diverse deployment topologies.
• Multi-job efficiency: FLARE’s runtime can handle multiple Flower apps simultaneously—no extra ports required.

By combining Flower’s easy-to-use development tools and APIs with FLARE’s robust runtime, this integration bridges the gap between FL research and production, creating a cohesive ecosystem that scales effortlessly from experimentation to deployment.

Integration design: Routing Flower through FLARE

FL thrives on efficient communication between clients and servers. Flower, a leading FL framework, uses gRPC as its communication protocol. When integrating with FLARE, you route Flower’s gRPC messages through FLARE’s runtime environment to maintain compatibility and reliability.

Here’s the key adjustment. Instead of Flower clients sending messages directly to the server, their endpoint is redirected to a local gRPC server (LGS) within each FLARE client. This simple rerouting enables Flower apps to operate seamlessly within FLARE without altering the original application code (Figure 2).

Here’s the communication pathway between a Flower SuperNode and the Flower SuperLink:

1. A Flower SuperNode generates a gRPC message and sends it to the LGS hosted in the FLARE client.
2. The FLARE client forwards this message as a reliable FLARE message to the FLARE server.
3. Within the FLARE server, a local gRPC client (LGC) interacts with the Flower SuperLink, forwarding the message to its intended destination.
4. The SuperLink processes the message and sends a response back to the LGC in the FLARE server.
5. The FLARE server routes the response back to the FLARE client.
6. The FLARE client sends the response to the Flower SuperNode through the LGS.

This design ensures smooth communication between Flower’s SuperNode and SuperLink through FLARE. The SuperNode can run as an independent process or within the same process as the FLARE client, offering flexibility for deployment.

With this setup, you can tap into FLARE’s powerful runtime capabilities while maintaining your applications’ simplicity and modularity, enhancing usability and scalability in real-world FL deployments.

Integration without code changes

To showcase this integration, run Flower’s PyTorch-Quickstart example directly within FLARE.

First, create a Flower ServerApp:

# Define strategystrategy =FedAvg(...)# Flower ServerAppdefserver_fn(context: Context):    # Read from config    num_rounds =context.run_config["num-server-rounds"]    # Define config    config =ServerConfig(num_rounds=num_rounds)    returnServerAppComponents(strategy=strategy, config=config)# Create ServerAppapp =ServerApp(server_fn=server_fn)

Next, define the Flower ClientApp:

# Define FlowerClient and client_fnclassFlowerClient(NumPyClient):    deffit(self, parameters, config):        set_weights(net, parameters)        results =train(net, trainloader, testloader, epochs=1, device=DEVICE)        returnget_weights(net), len(trainloader.dataset), results    defevaluate(self, parameters, config):        set_weights(net, parameters)        loss, accuracy =test(net, testloader)        returnloss, len(testloader.dataset), {"accuracy": accuracy}defclient_fn(context: Context):    """Create and return an instance of Flower `Client`."""    returnFlowerClient().to_client()# Flower ClientAppapp =ClientApp(    client_fn=client_fn,)

With the integration of Flower and FLARE, applications developed with the Flower framework run seamlessly in FLARE runtime and you don’t have to make any changes. 

For an end-to-end example, see Flower App (PyTorch) in NVIDIA FLARE.

Ensuring reproducibility: Running Flower Applications with FLARE

One of the most critical aspects of integrating frameworks is ensuring that the functionality and outcomes remain unchanged. When integrating Flower applications into the FLARE environment, we aimed to preserve identical results as when running the applications in a standalone Flower setup.

To demonstrate this, we conducted an experiment:

1. We initialized the Flower application using the same random seeds for the clients in both environments, standalone Flower and Flower within FLARE.
2. We tracked and plotted the training curves for both scenarios (Figure 3).

When overlaying the training curves from both setups, they align exactly, confirming that the routing of messages through FLARE does not affect the results.

This consistency is a significant milestone, as it proves that integrating Flower with FLARE preserves the integrity of the training process. It enables you to seamlessly transition their Flower applications to FLARE’s runtime environment without worrying about deviations in performance or outcomes.

Unlocking new possibilities: Hybrid integration with FLARE’s experiment tracking

Imagine combining the best of two powerful frameworks: Flower’s intuitive FL development tools with FLARE’s robust runtime features. With this hybrid integration, the vision becomes a reality.

By deploying a Flower app within the FLARE runtime, you can unlock exciting new capabilities, such as FLARE’s experiment tracking using SummaryWriter. Now, you can seamlessly integrate FLARE’s metric streaming directly into your Flower client code when deployed in FLARE’s runtime environment. For this, add FLARE’s SummaryWriter to Flower’s client app:

# initializes NVFlare interfacefromnvflare.client.tracking importSummaryWriter# Define FlowerClient and client_fnclassFlowerClient(NumPyClient):    def__init__(self, context: Context):        super().__init__()        self.writer =SummaryWriter()        self.flwr_context =context        if"step"notincontext.state.metrics_records:            self.set_step(0)    defset_step(self, step: int):        self.flwr_context.state =RecordSet(metrics_records={"step": MetricsRecord({"step": step})})    defget_step(self):        returnint(self.flwr_context.state.metrics_records["step"]["step"])    deffit(self, parameters, config):        step =self.get_step()        set_weights(net, parameters)        results =train(net, trainloader, testloader, epochs=1, device=DEVICE)        self.writer.add_scalar("train_loss", results["train_loss"], step)        self.writer.add_scalar("train_accuracy", results["train_accuracy"], step)        self.writer.add_scalar("val_loss", results["val_loss"], step)        self.writer.add_scalar("val_accuracy", results["val_accuracy"], step)        self.set_step(step +1)        returnget_weights(net), len(trainloader.dataset), results…

In the code example, you keep track of the current training step using Flower’s metrics_records.

With this integration, researchers and developers can:

• Effortlessly monitor progress: Track experiments with precision, right within the familiar Flower workflow.
• Use unified power: Take advantage of FLARE’s industrial-grade features without giving up Flower’s simplicity.

For more information, see Run a simulation with TensorBoard streaming in the /NVIDIA/NVFlare GitHub repo.

Summary

This is just the beginning of what’s possible when two cutting-edge FL frameworks come together. The Flower and NVIDIA Flare integration opens the door to more efficient, scalable, and feature-rich federated learning applications!

For researchers and developers, maintaining reproducibility across FL environments is paramount. With this integration, reproducibility is guaranteed, ensuring trust in experiments and outcomes. Seamless integration also becomes possible, removing barriers to using FLARE for enterprise-grade deployment.

By preserving identical results in both deployments, we’ve ensured that you can confidently use FLARE’s robust runtime without compromising the reliability or performance of their Flower applications. 

For more information, see the following resources:

• Supercharging Federated Learning with Flower and NVIDIA FLARE paper
• Latest Flower version at flower.ai 
• NVIDIA FLARE 2.6 release on GitHub 
• NVIDIA FLARE 2.6 documentation

Any questions or comments? Reach out to us at federatedlearning@nvidia.com.