FedEYE: A scalable and flexible end-to-end federated learning platform for ophthalmology

Summary

Data-driven machine learning, as a promising approach, possesses the capability to build high-quality, exact, and robust models from ophthalmic medical data. Ophthalmic medical data, however, presently exist across disparate data silos with privacy limitations, making centralized training challenging. While ophthalmologists may not specialize in machine learning and artificial intelligence (AI), considerable impediments arise in the associated realm of research. To address these issues, we design and develop FedEYE, a scalable and flexible end-to-end ophthalmic federated learning platform. During FedEYE design, we adhere to four fundamental design principles, ensuring that ophthalmologists can effortlessly create independent and federated AI research tasks. Benefiting from the design principles and architecture of FedEYE, it encloses numerous key features, including rich and customizable capabilities, separation of concerns, scalability, and flexible deployment. We also validated the applicability of FedEYE by employing several prevalent neural networks on ophthalmic disease image classification tasks.

Graphical abstract

Highlights

• •FedEYE is a scalable and flexible federated learning platform for ophthalmology
• •FedEYE empowers ophthalmologists to apply AI techniques to private data
• •Guided by design principles, FedEYE offers a full solution for federated learning

The bigger picture

Federated learning (FL) enables training machine learning models on decentralized medical data while preserving privacy. Despite growing research on FL algorithms and systems, building real-world FL applications requires extensive expertise, posing barriers for medical researchers. FedEYE, an end-to-end FL platform tailored for ophthalmologists without programming skills, is developed here to easily create federated projects on tasks like image classification. The platform provides rich capabilities, scalability, flexible deployment, and separation of concerns. With user-friendly interfaces and comprehension of underlying mechanisms, FedEYE strives to democratize FL for ophthalmology.

FedEYE is an end-to-end federated learning platform tailored for ophthalmologists with limited programming expertise. Its user-friendly interface, modular architecture, and flexible deployment empower ophthalmologists to easily create collaborative projects for tasks like fundus image classification across data silos. FedEYE strives to make federated learning more accessible for ophthalmic research.

Introduction

Recent advancements in artificial intelligence (AI) and machine learning (ML) have revolutionized various industries, including medical and ophthalmology. The ability to process vast amounts of data has led to the development of powerful algorithms and large deep learning (DL) models that can assist in diagnosing diseases accurately and efficiently, identify potential drug candidates, and personalize patient treatment plans. However, the success of ML models primarily depends on the quality and quantity of the training data. In ophthalmology, data are generally stored in data silos with privacy and policy limitations, such as the General Data Protection Regulation,¹ which was published by the European Parliament and Council of the European Union in 2016 on data protection and privacy, making it hard to train models via centralized training across multiple institutions.

Federated learning (FL) or federated ML (FML) is a promising solution to this issue. It allows multiple institutions to train an ML model collaboratively without sharing data. Instead of relying on a centralized model, institutions can train the models using their data and local machines. The parameters of all locally trained models can be aggregated to create a federated global model. This approach ensures greater data privacy and security, benefiting institutions from more accurate and robust global ML models. One of the earliest works in FL is the federated averaging algorithm proposed by Mcmahan et al.² in 2017. In addition to these algorithmic advances, there has been much work on the theoretical analysis of FL, including convergence analysis^3,4 and communication complexity analysis.^5,6 Many researchers have also studied the practical challenges of deploying FL systems in real-world settings, such as the heterogeneity of devices,^7,8 the reliability of wireless networks,^9,10 and the variability of user behavior.^11,12,13

As research on FL progresses, more researchers focus on studying FL system architecture. Due to the heterogeneity of FL, unique features of different platforms require the resolution of heterogeneity issues. Therefore, several FL frameworks are designed to address these issues, such as PySyft,¹⁴ OpenFL,¹⁵ FLOWER,¹⁶ Fedlearn-Algo,¹⁷ FedJAX,¹⁸ FedScale,¹⁹ and FederatedScope,²⁰ among others. Although most FL frameworks mentioned above are still in the simulation stage, the first enterprise-level framework, FATE,²¹ and the developing FedML²² are presently designed for practical applications. FATE²¹ is an FL framework based on multi-party collaborative and secure computing that addresses privacy issues and data sensitivity in data sharing. The framework protects data privacy, accelerates training speed, reduces dataset maintenance costs, and enhances model prediction capabilities. FedML²² is an open FL research library and benchmark that aims to promote the development and fair comparison of FL algorithms.

FL’s unique ability to train ML models on decentralized data sources while preserving user privacy makes it a promising approach for a wide range of healthcare, finance, smart cities, and Internet of Things applications. In the medical field, by allowing multiple medical institutions to collaborate and train ML models on their respective datasets without sharing sensitive patient information, FL can help overcome the limitations of data silos and promote knowledge sharing across regions. Many studies have investigated the use of FL in medical subfields,^23,24,25 including lung cancer,^26,27,28 pneumonia,^29,30,31 kidney diseases,^32,33 and even intensive care unit mortality rate prediction.³⁴ Also, there are many researches in ophthalmology.^35,36,37,38

The utilization of FL has been acknowledged as a promising approach in medical research. However, building an FL application requires significant expertise in computer science and ML, and most of the existing FL systems, which are designed for FL researchers, are not friendly to medical researchers or ophthalmologists and are challenging to use, which can be a barrier for ophthalmologists who may not have extensive training in this research.

Hence, we developed FedEYE, a scalable and flexible end-to-end FL system tailored specifically for medical researchers, particularly ophthalmologists. This platform tackles these challenges by providing a user-friendly and parameterized interface. While ophthalmologists and ophthalmic researchers may not be versed in ML and AI, these technologies enable them to effortlessly launch independent or federated projects with their research collaborators, encompassing tasks such as fundus image classification, segmentation, and more. FedEYE strives to democratize the FL process for ophthalmologists by minimizing the requirement for intricate programming, facilitating comprehension of the underlying mechanism, and providing convenient access to diverse medical systems. The platform adheres to the MLDevOps paradigm,³⁹ effectively segregating the algorithmic layer from the application layer, simplifying management and maintenance tasks. Additionally, FedEYE supports software and hardware components, enabling its deployment on various devices with flexible configurations.

Results

FedEYE represents a federated edge computing platform meticulously designed for FL, adhering to a set of guiding principles. It harnesses the power of edge computing capabilities, including privacy preservation, prompt processing, and offline computing, to facilitate distributed computing of multi-modal data while upholding robust data security measures. Moreover, FedEYE provides a user-friendly and easily comprehensible web interface, empowering medical professors and researchers to embark on their own federated training research collaborations. Furthermore, in order to cater to the specific research requirements of ophthalmologists, the current platform has already incorporated support for a diverse array of ophthalmic research tasks, encompassing but not limited to tabular data categorization, image classification, text classification, image segmentation, and object detection. This comprehensive coverage ensures that a wide range of ophthalmic research pursuits can be accommodated.

In Table 1, we have conducted a comparative analysis of our FL platform against existing platforms, evaluating them across 13 dimensions and 46 indicators. This evaluation encompasses aspects such as deployment support, privacy protection, data security, availability of built-in ML models, scalability, and more. The privacy protection section encompasses support for methods such as differential privacy (DP), multi-party computing (MPC), and homomorphic encryption (HE). In ML models and benchmarks sections, it includes the support for tree-based models, neural network-based models including regression, convolutional neural network (CNN), recurrent neural network (RNN), and the quantity of common neural network (NN) for computer vision (CV).

Table 1.

Comparison with existing platforms/frameworks/libraries

Metrics		Platform/framework/library
Information	name	FedEYE (ours)	FATE	FedML	FederatedScope	PySyft	TensorFlow Federated	PaddleFL
	version	1.0	1.10.0	0.7.502	0.2.0	0.7.0	0.50.0	1.2.0
FL algorithm	horizontal FL	✓	✓	✓	✓	✓	✓	✓
	vertical FL	✓	✓	✓	✓	✓	✗	✓
	split learning	✓	✓	✓	✗	✓	✓	✓
Benchmarks	regression	✓	✓	✓	✓	✓	✓	✓
	NN	✓	✓	✓	✓	✓	✓	✓
	tree-based model	✓	✓	✗	✓	✗	✗	✗
Documentation	tutorial	✓	✓	✓	✓	✓	✓	✓
	code example	✓	✓	✓	✓	✓	✓	✓
	API detailed document	✓	✓	✗	✓	✓	✓	✓
Deployment support	standalone	✓	✓	✓	✓	✓	✓	✓
	GPU support	✓	✓	✓	✓	✓	✓	✓
	cluster support	✓	✓	✗	✗	✗	✗	✗
	container deployment	✓	✓	✓	✓	✓	✓	✓
	heterogeneous hardware	✓	◗a	◗	◗	◗	◗	◗
Privacy and data security	DP	✓	✓	✓	✓	✓	✓	✓
	MPC	✓	✓	✓	✓	✓	✓	✓
	HE	✓	✓	✗	✓	✓	✓	✓
	distributed storage	✓	✗	✗	✗	✗	✗	✗
Built-in DL models	CNN	✓	✓	✓	✓	✓	✓	✓
	RNN	✓	✓	✓	✓	✓	✓	✓
	custom optimizer	✓	✓	✓	✓	✓	✓	✓
	# NN (CV)	24	<10	<15	<10	<10	<10	<10
DL backend	PyTorch	✓	✓	✓	✓	✓	✗	✗
	TensorFlow	✓	✓	✓	✓	✗	✓	✗
	PaddlePaddle	✗	✗	✗	✗	✗	✗	✓
	JAX	✗	✗	✓	✗	✗	✗	✗
	Caffe	✗	✗	✗	✗	✗	✗	✗
Scheduling	task scheduling	✓	✓	✗	✗	✗	✗	✗
	resource scheduling	✓	✓	✗	✗	✗	✗	✗
	task parallelism	✓	✓	✗	✗	✗	✗	✗
Scalability	model/data/algorithm	✓	✓	✓	✓	✓	✓	✓
	service	✓	✗	✗	✗	✗	✗	✗
Logging	task logging	✓	✓	✓	✓	✓	✓	✓
	cluster status	✓	✓	✗	✗	✗	✗	✗
	device status	✓	✓	✓	✓	✓	✓	✓
Maintain	user management	✓	✗	✓	✗	✗	✗	✗
	role management	✓	✗	✗	✗	✗	✗	✗
Completeness	full-stack implement	✓	✗	✓	✗	✗	✗	✗
	low code	✓	✗	✗	✗	✗	✗	✗
	parameters	✓	✗	✓	✗	✗	✗	✗
	algorithms pool	✓	✗	✗	✗	✗	✗	✗
	model pool	✓	✗	✗	✗	✗	✗	✗
	mission pool	✓	✗	✓	✗	✗	✗	✗
	data pool	✓	✗	✗	✗	✗	✗	✗

^a◗ means not specifically processed or not mentioned.

In this section, we will introduce FedEYE, including its guiding design principles, detailed platform architecture, key features, and benchmarks.

Design principles of FedEYE

Designing an FL platform for ophthalmology that can accommodate the heterogeneity of ophthalmology data and enable effective collaboration between medical professionals and data scientists presents a significant challenge.

To address this challenge, we propose an FL system FedEYE that is designed with the following principles.

• (1)Low-code programming: the aim is to minimize the need for complex programming, making it easier for medical professionals to participate in the FL process and to understand it better.
• (2)Accessibility: the platform needs to have OpenAPI, which makes it easy to integrate with traditional medical systems.
• (3)MLDevOps³⁹: the aim is to separate the work of the algorithm layer from the application layer, which can improve the system’s manageability and maintainability.
• (4)Heterogeneous hardware support: the architecture should support both software and hardware components, making it possible to run on various devices with heterogeneous hardware configurations.

Detailed architecture design of FedEYE

As shown in Figure 1, FedEYE can be divided into four layers from bottom to top: a platform infrastructure layer; a data, mission, and algorithm (DMA) layer; a federated mechanism layer; and a model as a service (MaaS) layer. The DMA layer, federated mechanism layer, and MaaS layer shall collectively be referred to as the DMA-MaaS framework.

Figure 1.

Architecture design overview of FedEYE

Platform infrastructure

The platform infrastructure layer provides fundamental computing and storage capabilities to the upper layers. This layer is comprised of hardware facilities, containers, networks, and federated components.

FedEYE’s cluster management capabilities rely on Kubernetes⁴⁰ to provide real-time reporting of the running status of federated devices and services, making it easier for the cloud control console to monitor them. This platform containerizes model services, allowing for hosted models to be pushed to the edge and for integrated, visualized management and flexible scheduling of edge devices and services.

The key design abstracts platform differences through a unified edge runtime. The edges use CPUs, GPUs, and FPGAs for training and inference via scheduling and containers. It allows FL model computation on devices, continuous inference during training, and seamless model upgrades. Models and applications are containerized plug-and-play modules. Integrating extended FATE frameworks’ containers enables cloud-edge collaboration for FL.

In order to address the challenges posed by heterogeneous networks in real-world deployment scenarios, FedEYE incorporates a cloud service layer and an edge device layer, as depicted in Figure 2. The edge device layer is connected to the cloud server through an application programming interface (API) gateway after passing through a firewall. The cloud service layer includes micro-services such as the cloud control console, the server side of the edge computing platform, and a cloud-based model management platform. The edge device layer comprises client devices participating in FL modeling. Each client device contains an agent side of the edge computing platform and federated components and is deployed in a containerized virtual environment. The network environment of all devices is composed of virtual private networks (VPNs), which can ensure the privacy and security of data transmission and prevent hijacking and attacks. For example, Wire-Guard, which implements encrypted VPNs and is open source, can be used.

Figure 2.

FedEYE deployment with heterogeneous networks

DMA-MaaS framework

The DMA layer includes a data pool, mission pool, and algorithm pool, while the MaaS layer mainly provides model services for the model market. To ensure data security and privacy, we store the necessary data, algorithm, and model in a distributed manner across the edge nodes while providing external interfaces for data input and management. The algorithms used include feature engineering and federated algorithms such as aggregation optimization and federated transfer. Upon initiating a task, a parameterized configuration and a graphical interface are provided for display and participation. Once the task is completed, the resulting model can be set to private or added to the model pool for others to use for research and inference. Our platform offers essential model management services, which include model inference for vertical and horizontal FL, model upload and download, and model version management.

We use the federated mechanism layer as the middle layer to connect the DMA layer and the MaaS layer, mainly by combining and orchestrating algorithms, data, and models to build two different types of federated tasks.

Key features of FedEYE

Leveraging the design principles and architecture of FedEYE, the platform boasts a multitude of key features. These encompass a diverse range of rich and customizable capabilities, clear separation of concerns, scalability, and flexible deployment.

Rich and customizable capabilities

FedEYE is a ML platform that enables both federated and standalone ML tasks across structured data like tabular data as well as unstructured data such as images and text. The platform facilitates secure and privacy-preserving FL by allowing federated training of ML models on sensitive data that remains on users’ local devices. Beyond FL, FedEYE also supports independent research tasks on private datasets. The platform can handle a wide variety of tasks, including binary and multi-class classification for tabular data, image and text data, and object detection for image data. FedEYE seamlessly integrates popular model libraries such as timm,⁴¹ torchvision,⁴² transformers,⁴³ and more. Ophthalmic researchers can leverage the capabilities of the platform to engage in numerous federated tasks, such as the classification and diagnosis of fundus images, lesion identification, and analysis of patient morbidity rates, among other scientific collaborators.

We develop a web-based interactive interface that schedules tasks through the edge-cloud subsystem. When creating tasks, we offer a parameterized task configuration method and a graphical interface to construct tasks modularly. This makes it easy for medical staff without solid programming skills.

Clear separation of concerns

Aligned with the design principle of MLDevOps,³⁹ FedEYE empowers individuals with distinct responsibilities to independently manage various aspects of the platform. For instance, doctors and patients can create inference tasks and complete model applications through the MaaS in FedEYE’s web-based interactive interface. Additionally, doctors can utilize the DMA-MaaS framework of the platform to initiate tasks and involve other medical institutions. The maintenance staff of the hospital system can integrate the system and fulfill specific personalized requirements using the FedEYE API open platform. ML algorithm engineers can focus on the algorithm pool and related inference task development, while hardware engineers can concentrate on the infrastructure layer. The platform’s operations personnel focus on user, role, metadata management, and platform development.

Scalability

The scalability of the FedEYE platform has two key aspects: the scalability of the cluster nodes and the scalability of the functionalities.

The cluster nodes’ scalability of FedEYE is due to using K3s⁴⁰ as the underlying tool for managing computing nodes. K3s is a lightweight Kubernetes distribution designed for the Internet of Things and edge computing. K3s minimizes external dependencies, requiring only kernel and cgroup mounting, making it easy to scale computing nodes up or down. When a computing node needs to join the cluster, simply install the K3s agent with one command. When a node becomes unavailable due to a crash or another reason, the platform automatically migrates the applications on the node to other healthy nodes. At the same time, the platform dynamically binds namespaces with computing nodes to ensure that application components of each federated party can be migrated to suitable computing nodes during node scaling.

The functional scalability of FedEYE is due to the micro-service architecture. Micro-service architecture involves breaking down different functional modules of the system into multiple separate services, each independently developed and deployed. Each service runs in its own process, so updates to one service do not affect the running of other services. Because each service deploys independently, it is possible to monitor the resource consumption of each service more accurately and to quickly identify performance bottlenecks between services. Each service is independently developed and can use different programming languages, reducing code conflicts and duplication. This makes the logical processing flow clearer and makes maintenance and expansion easier in the future.

Flexible deployment

FedEYE offers readily available edge computing machines seamlessly connected to the federated platform once the network configuration is complete. Moreover, FedEYE provides a containerized deployment approach facilitated through Docker.⁴⁴ Users have the convenience of installing and upgrading the platform components by simply downloading the Docker image.

FedEYE benchmarks

FedEYE provides FL benchmarks on the public and private datasets, and the detailed benchmarks are shown in Table 2. We conducted image classification experiments based on FedAvg using ResNet,⁴⁵ Swin-Transformer,⁴⁶ and ViT⁴⁷ models on each dataset. The experimental results display only the top three highest accuracy rates for each model.

Table 2.

FedEYE federated learning benchmarks

Dataset	Partition	Model	Accuracy	Recall	Data size
DR	iid	Swin-T46	0.9711	0.9653	7901
DR	iid	ViT47	0.9714a	0.9690a	7901
DR	iid	ResNet45	0.9099	0.9144	7901
RVO	iid	Swin-T46	0.9859	0.9466	5547
RVO	iid	ViT47	0.9496	0.9870a	5547
RVO	iid	ResNet45	0.9910a	0.9686	5547
AMD	iid	Swin-T46	0.9422a	0.9344	8261
AMD	iid	ViT47	0.9268	0.9232	8261
AMD	iid	ResNet45	0.9072	0.9103	8261
HMCN	iid	Swin-T46	0.9989a	0.9977a	5369
HMCN	iid	ViT47	0.9978	0.9971	5369
HMCN	iid	ResNet45	0.9985	0.9975	5369
PM	iid	Swin-T46	0.9511	0.8721	5852
PM	iid	ViT47	0.9552a	0.8767a	5852
PM	iid	ResNet45	0.9532	0.8794	5852
EDDL	iid	Swin-T46	0.9607a	0.9293a	712
EDDL	iid	ViT47	0.9438	0.8905	712
EDDL	iid	ResNet45	0.9002	0.8783	712
EDDL	non-iid	Swin-T46	0.9542	0.7784	712
EDDL	non-iid	ViT47	0.9663a	0.9459a	712
EDDL	non-iid	ResNet45	0.9052	0.6327	712
OCT17	iid	Swin-T46	0.9897a	0.9850a	83484
OCT17	iid	ViT47	0.9852	0.9791	83484
OCT17	iid	ResNet45	0.9706	0.9734	83484
OCT17	non-iid	Swin-T46	0.9949a	0.9850a	83484
OCT17	non-iid	ViT47	0.9775	0.9316	83484
OCT17	non-iid	ResNet45	0.9865	0.9759	83484

DR, diabetic retinopathy classification dataset; AMD, age-related macular degeneration dataset; RVO, retinal vein occlusion dataset; HMCN, highly myopic choroidal neovascularization dataset; PM, pathological myopia dataset.

^aBest results

To further illustrate the significance of the platform, we also conduct experiments on the Eye Disease Deep Learning Dataset (EDDL) and the Retinal OCT Images Dataset (OCT17), conducting independent ML experiments on different clients. It can be seen from the results shown in Table 3 that performing federated tasks through the FedEYE platform can achieve better model performance while protecting data privacy.

Table 3.

FedEYE independent research benchmarks

Dataset	Client 0	Client 1	Client 2	Client 3	FedEYE FL task
EDDL	0.7569	0.7222	0.7361	0.7222	0.9607a
OCT17	0.9566	0.9566	0.9591	0.9542	0.9897a

^aBest results

The detailed description is in the experimental procedures section.

Discussion

The FedEYE platform is designed to address the unique challenges of training ML models in ophthalmology. By providing a user-friendly and scalable system that separates the concerns of data, algorithm, model, and hardware management, we believe that our platform can enable more effective and efficient ophthalmology research while protecting patient privacy. However, FedEYE still has some limitations. We have solely contemplated the training and inference process of the model, whereas the configuration of model parameters necessitates further guidance and expertise. Moreover, data collection and annotation automation remain focal points for future advancements and for refinement of the platform. With the development of platforms such as FedEYE, FL collaborations for ophthalmology research and data can become more accessible to medical professionals and institutions, further advancing the field of medical research.

Experimental procedures

Resource availability

Lead contact

Further information and requests for resources and reagents should be directed to and will be fulfilled by the lead contact, Yiqiang Chen (yqchen@ict.ac.cn).

Materials availability

This study did not generate new materials.

Data and code availability

The EDDL⁴⁸ dataset is available at the repositories,⁴⁸ and the OCT17 can be found at Mendeley Data.⁴⁹ All other data reported in this descriptor will be provided by the lead contact upon request. However, we highly recommend contacting the lead contact to access the FedEYE platform and participate in the federated training to use the complete data.

The FedEYE platform can be accessed at https://fedeye.aierchina.com/. All original code for platform and data pre-processing is available at GitHub (https://github.com/beiyuouo/FedEYE) and has been deposited at Zenodo.⁵⁰

Any additional information required to reanalyze the data reported in this paper is available from the lead contact upon request.

Experiment setup

To demonstrate the capabilities of the platform, we conducted an FL experiment on ophthalmic medical images using FedEYE deployed in the real world. We first introduced the definition of the FL problem, experimental settings, platform deployment, and benchmark experimental results.

Problem definition

FL is a distributed ML approach that enables training ML models on decentralized data located on devices like mobile phones or hospital servers without exchanging local private data samples. This allows collaborative model training while keeping data localized and private.

The key steps in FL are

• (1)Model initialization: a global model is created on a central server with randomly initialized weights.
• (2)Model distribution: the central server distributes the global model back to all clients.
• (3)Local training: each client trains the model on local private data and updates the model locally.
• (4)Server aggregation: the locally updated models are sent back to the central server. In FedAvg, the server aggregates these models by averaging their weights and creates an improved global model.
• (5)Iteration: steps 2–4 are repeated until the global model converges.

The schematic diagram of the FL process is illustrated in Figure 3. The goal is to collaboratively train an accurate model while keeping data decentralized on devices. FL preserves privacy and reduces communication costs. It is well-suited for medical applications where sensitive patient data need to remain localized. The iterative process allows building a shared global model from local insights without sharing the data.

Figure 3.

Federated learning process on FedEYE

Datasets

We used seven datasets, including two public datasets: the EDDL⁴⁸ and the OCT17.⁴⁹ We performed both independently and identically distributed (iid) data partition and non-independently and identically (non-iid) data partition based on the Dirichlet distribution (alpha = 0.5) for each dataset. The relationship between the number of data instances and label quantities for each client is depicted in Figure 4. In addition, there are five private datasets belonging to Aier Eye Hospital: the diabetic retinopathy classification dataset, the age-related macular degeneration dataset, the retinal vein occlusion dataset, the highly myopic choroidal neovascularization dataset, and the pathological myopia dataset (note: all of Aier Eye’s data were collected from several natural data centers).

Figure 4.

The data partition of EDDL and OCT17

The size of the circles represents the volume of data.

Experiments detailed

For the CNN-based model, ResNet⁴⁵ employs a learning rate of 1e−4 and conducts training with the Adam optimizer. For the transformer-based model, Swin-Transformer⁴⁶ and ViT⁴⁷ apply a learning rate of 3e−5 and training using the AdamW optimizer. All models are pre-trained on ImageNet. We utilize a batch size of 8 for the OCT17 dataset, iterating for 20 rounds, while employing a batch size of 2 for other datasets, iterating for ten rounds. Before the training procedure, the platform shall autonomously partition the dataset in an 8:2 ratio, distinguishing between the training and validation datasets. This division serves the purpose of evaluating the model’s generalization capability and safeguarding against overfitting.

Deployment detailed

The FedEYE platform is deployed in clusters across five data centers of Aier Eye Hospital, which include Aier Eye Hospital headquarters, Changsha, Wuhan, Chongqing, and Shenzhen.

Published: February 2, 2024