/csteps/inner color=white /csteps/fill color=black XX XX 8

# LLMs as On-demand Customizable Service

Souvika Sarkar  Auburn University, Auburn, AL, USA  Mohammad Fakhruddin Babar
Washington State University, Pullman, WA, USA  Monowar Hasan  Washington State
University, Pullman, WA, USA  Shubhra Kanti Karmaker (Santu)  Auburn
University, Auburn, AL, USA

###### Abstract

Large Language Models (LLMs) have demonstrated remarkable language
understanding and generation capabilities. However, training, deploying, and
accessing these models pose notable challenges, including resource-intensive
demands, extended training durations, and scalability issues. To address these
issues, we introduce a concept of hierarchical, distributed LLM architecture
that aims at enhancing the accessibility and deployability of LLMs across
heterogeneous computing platforms, including general-purpose computers (e.g.,
laptops) and IoT-style devices (e.g., embedded systems). By introducing a
“layered” approach, the proposed architecture enables on-demand accessibility
to LLMs as a customizable service. This approach also ensures optimal trade-
offs between the available computational resources and the user’s application
needs. We envision that the concept of hierarchical LLM will empower
extensive, crowd-sourced user bases to harness the capabilities of LLMs,
thereby fostering advancements in AI technology in general.

Large Language Models (LLMs), such as GPT-3.5 [1], LLaMA [2], BLOOM [3], have
unleashed unparalleled language processing capabilities, serving as catalysts
for developing various AI tools and enabling seamless knowledge transfer
across diverse NLP tasks, including automatic news summarization [4],
efficient healthcare research [5], software bug solving [6], zero-shot
classification [7, 8] and machine translation [9]. While LLMs offer remarkable
advantages, their widespread adoption encounters substantial challenges,
primarily stemming from their enormous size. These models boast an
astronomical number of parameters, necessitating considerable computational
resources. Unfortunately, such resources are often lacking on local devices,
rendering LLMs less accessible and casting doubts on their customizability for
specific applications, particularly on devices with limited computational
capabilities. The intricacies of training, deploying, and consistently
updating LLMs further compound these challenges. In response to the challenges
presented by LLMs, we present an innovative idea: a hierarchical, distributed
architecture (Sec. A Multi-Layer LLM Architecture). Our proposed solution
aimed to improve the accessibility and utility of LLMs in various settings
through the following aspects.

Hierarchical Organization of Knowledge.  By hierarchically structuring an LLM,
vast knowledge learned from big data corpora is distributed across multiple
layers based on target language (e.g., English, Spanish), target application
domains (e.g., Medical, Sports), and application-oriented sub-domains (e.g.,
Soccer, Baseball). The basic idea is that each node in this hierarchy
represents a language model, where nodes in the upper layer of the hierarchy
represent models that are general-purpose (and larger), while nodes at the
lower layers of the hierarchy represent models that are small and domain-
specific. This organization allows for a more efficient organization of
information, reducing redundancy and eliminating the need for every
application to store the entire model. As a result, the size of each
application-specific language model is more manageable.

Enhanced Customization.  The hierarchical architecture permits users to
custom-select LLMs according to their specific requirements. Rather than
deploying a monolithic, one-size-fits-all model with an enormous parameter
count, users can select an LLM from the “right/optimal” layer and further
configure it to suit their application.

Efficient Resource Management.  The architecture optimizes resource (computing
power, memory, battery capacity) allocation by allowing users to choose a
language model that matches their hardware capabilities. Local devices with
limited computational resources can opt for a smaller, more resource-friendly
language model from lower layers of the hierarchy. This prevents over-
commitment of resources and ensures that LLMs can run effectively on various
devices, from personal computers to low-power embedded devices.

Scalability.  The hierarchical structure also supports scalability. As the
demands of an application grow in terms of its knowledge base, users can
upgrade their application-specific-language model by selecting a model from a
higher layer that offers enhanced capabilities and covers a larger knowledge
base. This scalability ensures that applications can handle more complex tasks
without transitioning to an entirely new model architecture.

Figure 1: A Use Case - Leveraging Hierarchical Language Model Architecture as
On-Demand Service.

A layered architecture such as those proposed here can offer seamless on-
demand adoption of LLMs customized to a user’s specific needs and available
computing resources. Such a multi-layer architecture allows users more control
when customizing LLMs according to their preferred platforms, languages,
domains, and service preferences while ensuring the trade-off between the
computational resources available and the business application needs.
Furthermore, the open-source implementation of this architecture plays a
pivotal role in democratizing AI. Making it open and crowd-sourced promotes
collaboration, accessibility, and a sense of shared ownership within the
community.

## Leveraging Adaptive Language Models for On-demand Service: A Healthcare Use
Case

Figure 1 depicts a practical healthcare use case that exemplifies our
conceptual architecture in resource-constrained environments.111Although we
present a healthcare case study, our concept is general and applicable to
various application domains.

Scenario. Dr. Smith, a medical researcher at a rural healthcare facility
equipped with devices of limited computational capabilities, is researching
rare diseases. She needs advanced language models to analyze and categorize
vast volumes of medical texts, research papers, and patient records. However,
her local infrastructure lacks the computational power required to deploy and
fine-tune LLMs, and she does not have sufficient funding to use a paid LLM
service available online.

Solution. Our hierarchical LLM architecture can aid Dr. Smith’s study as
follows.

  1. a

User Interaction: Dr. Smith initiates a conversation with a Virtual Assistant,
specifying her LLM service requirements and resource constraints.

  2. b

Query Model Recommender: The Virtual Assistant — an “online service agent” —
notifies the Language Model Recommender about Smith’s specific requirements.

  3. c

Recommendation: The Language Model Recommender then finds the most suitable
language model for Dr. Smith’s research. The Recommender considers factors
such as domain (healthcare), sub-domain (rare diseases), resource limitations,
computational cost (processing time, memory), and monetary costs (to receive
the service) associated with the language models.

  4. d

On-Demand Access: Dr. Smith, following the recommendation, acquires a
suggested language model designed to match her hardware capacity and research
requirements. This language model serves as an on-demand, customizable
research tool. We note that the chosen model is not rigid but highly
adaptable. For instance, Dr. Smith might initially acquire a general-purpose
language model suitable for various medical topics. However, as her focus is
on rare diseases requiring specific knowledge, she adapts the language model
using her personal data corpus. This adaptability guarantees that the language
model aligns with her research objectives, allowing her to delve into the
intricacies of rare disease studies efficiently.

  5. e

Local Language Model Setup: Dr. Smith then deploys the language model on her
local device (e.g., a personal computer).

  6. f

Learning and Staying Updated: Dr. Smith can update her language model
continually. For instance, let us assume Dr. Smith starts with a language
model that knows up to a certain date, which is common in many commercial
LLMs. Over time, she collects new research findings and data related to rare
diseases. The language model can incorporate this new information into its
knowledge base. For example, if a breakthrough discovery about a particular
rare disease occurs, Dr. Smith can feed this information into the language
model. The language model then learns from it, making it aware of the latest
developments in the field. This ensures that Dr. Smith’s research tool is
always up-to-date and equipped with the most recent information, allowing her
to stay at the forefront of her research field.

  7. g

Sharing Knowledge: Whenever Dr. Smith updates her language model, the peer
language models (part of the layered architecture) are notified. The peer
language models ensure that the updates are efficiently shared with “upstream”
and “downstream” language models.

  8. h

Gaining Knowledge: When other peer language models update themselves, they
share their knowledge with their counterparts. If the new information aligns
with Dr. Smith’s language model requirements, her model can efficiently gain
this newfound knowledge from others.

Impact. By utilizing the hierarchical language model architecture, Dr. Smith
can conduct advanced healthcare research even with limited computational
resources. The adaptability of language models to user-specific needs and the
continual update process enhances user tasks (for instance, research
capabilities of Dr. Smith), allowing the user to contribute towards a desired
goal (viz., contribute to understanding and treating rare diseases in this
case). The use case illustrates how our architecture democratizes access to
advanced AI technology, reducing technological disparities.

Figure 2: High-level schematic diagram of a multi-tier distributed LLM
architecture.

## A Multi-Layer LLM Architecture

Figure 2 presents an overview of the layered architecture. We propose to
organize multiple language models in a hierarchical order, considering
languages, domains, sub-domains, variations in size, resource requirements,
and computational cost. We arrange the language models in a “top-down” manner,
with larger models at the top and smaller models at the bottom, following a
decreasing order of size, resource availability, and computation cost. Such a
hierarchical arrangement allows users to choose a language model that suits
their needs and available resources.

### Workflow

The high-level workflow of our architecture is as follows.

i.  The User interacts with a Virtual Assistant, providing specific
requirements for their desired application.

ii.  Based on the user’s specifications, the virtual assistant consults a
Language model Recommender System [10] and recommends the most suitable
language model for the scenario. Users with sufficient resources can opt for a
larger language model, while those with limited computing power may choose
smaller language models to achieve their goals.

iii.  The user then clones the recommended language model and proceeds to
fine-tune it on their goal task using their local devices. Fine-tuning means
making small adjustments to an existing model to make it work better for a
specific task or situation. For instance, consider a camera that can capture
photos, but they do not always turn out perfect. Fine-tuning involves making
small changes to the camera’s settings, such as adjusting the focus or
brightness, so that the photos appear just as the user wants.

iv.  The user can update the cloned language model with new data through
continual learning [11]. Continual learning (a.k.a. lifelong learning) enables
AI systems to keep learning new things while retaining previous knowledge.
This is akin to adding new information to an existing database without erasing
existing information. For instance, when introducing a new animal, like a
parrot, to an AI system trained to recognize cats and dogs, the system learns
about parrots while still recognizing cats and dogs. This concept allows AI to
build on its existing knowledge, making it smarter over time without
forgetting what it has learned in the past. v.  When a language model is
updated or fine-tuned with new data, the peer language models are notified to
update themselves with this new knowledge.

vi.  The language model then shares this new knowledge with both the preceding
and succeeding layer language models through Upstream and Downstream knowledge
transfer mechanisms. Upstream knowledge transfer works as follows: imagine a
group of researchers specializing in various subdomains of Biology, such as
Microbiology and Zoology. They share their latest discoveries and findings
with a senior researcher who acts as a mentor. This senior researcher works in
a broader field, encompassing the specialized topics within Biology. In this
context, knowledge flows from the junior researchers in subdomains like
Microbiology and Zoology to the senior researcher, representing Upstream
knowledge transfer. Now, let us delve into Downstream knowledge transfer.
Expanding on the scenario we discussed above, consider the role of a senior
researcher in Biology. When the senior researcher comes across new and
relevant information within specific subdomains of Biology, they take on the
role of a knowledge distributor. In this context, knowledge flows from the
senior to junior researchers specializing in particular areas of Biology, such
as Microbiology and Zoology.

### Components and Functions

We now present the components and describe the functionalities of each layer.

User.  The user represents the end user who desires to obtain language model
services based on their specific requirements and preferences.

Virtual Assistant (VA).  The VA interfaces the user and the backend layered
architecture. The user interacts with the VA and provides specifications, such
as the desired platform and services they are looking for. The VA then
recommends the most suitable language model instance.

Master LLM Layer (Root).  At the root of our hierarchical architecture resides
the Master LLM, the largest general-purpose language model available, and
serves as the base (viz., “Teacher”) model for transferring knowledge to
successor language models.

Language Specific Language Model (LSLM) Layer.  The following layer in the
hierarchy is language models specific to a particular language (called LSLM,
depicted by the Orange box in Fig. 2). LSLMs are smaller than the Master LLM.
We can use distillation techniques [12] across the hierarchy to transfer
knowledge from a larger model to a smaller model. As an example, the Master
LLM acts as the “Teacher” and the language-specific (e.g., English, Spanish)
models as the “Student” during the distillation process.

Domain Language Model (DLM) Layer.  The subsequent layer contains domain-
specific language models for each Language Specific Language Model (LSLM),
such as Medical, Sports, Law, and Education, as shown by the Green box in Fig.
2). These domain-specific language models are (i) compact in size, (ii)
possess fewer parameters, and (iii) exhibit lower complexity. However, they
possess the essential knowledge/information to excel in their respective
domains in a specific language.

Sub-Domain Language Model (SDLM) Layer.  The next layer of the architecture
consists of SDLMs, essentially specialized language models tailored to
specific sub-areas of a domain. For example, in the medical field, sub-domains
include Virology or Heart Health. Likewise, in the sports industry, sub-
domains may contain language models related to Gymnastics or Soccer. SDLMs can
be customized to cater to the specific requirements of each domain precisely
while ensuring optimal performance and usability. As we descend the hierarchy,
these specialized models (illustrated by the Blue rectangle in Fig. 2) become
increasingly focused, compact, and application-friendly.

End Devices Layer.  End devices include heterogeneous computing systems such
as laptops, tablets, smartwatches, and embedded devices (as shown inside the
Gray rectangle in Fig. 2). Depending on the specific application scenarios and
requirements/constraints, a user can (a) acquire a preferred language model
compatible with computing resources and (b) fine-tune it on their system
depending on the goal task.

Continual Learning.  Continual learning is a machine learning paradigm where a
model learns from a continuous stream of data over time. Unlike traditional
machine learning, where models are typically trained on a static dataset and
then tested on new data, continual learning models are designed to adapt and
improve their performance as they encounter new data. In our setup, continual
learning plays a pivotal role in updating the knowledge of the entire
architecture. This allows the model to (a) adapt to new data and language
patterns, (b) learn from recent examples, and (c) improve its performance over
time, as discussed in our case study (Step f: Learning and Staying Updated).
The open-source nature of the architecture plays a vital part in this process,
as it encourages a collaborative effort among a diverse community. With a
crowd-sourced community-driven approach, the model can adapt to the latest
developments and benefit from a wealth of recent examples derived from various
sources, including niche domains (based on user consent). This collective
intelligence promotes constant improvements, leading to an architecture that
continually refines its performance and consistently delivers more accurate
and relevant results over time. As Fig. 2 depicts, we leverage continual
learning techniques [11] throughout the layer hierarchy (indicated by the
circular arrow at the right corner of each layer).

Upstream & Downstream Knowledge Transfer.  The bidirectional arrow in Fig. 2
signifies the architecture’s dynamic flow of updates and information exchange.
When a language model engages in continual learning and updates itself, it
triggers a two-way knowledge transfer process. This transfer occurs both
Upstream (from bottom to top) and Downstream (from top to bottom) across all
layers of language models. This collaborative exchange ensures that all models
remain synchronized and can capitalize on the latest advancements and data
insights. Although it is conceivable to perform knowledge transfer among
language models within the same layer, this falls outside the current scope of
our architecture.

## Challenges and Deployment Issues

While our proposed framework provides one way to make LLMs customizable for
heterogeneous devices, there exist several open deployment challenges, as we
present below.

Challenge 1: How to identify the most suitable language model?  A
comprehensive study of LLMs across diverse resource constraints and accuracy
prerequisites is crucial. This endeavor enables users to make informed choices
when opting for LLMs for applications, thus streamlining development efforts.
Dr. Smith’s scenario vividly underscores this challenge as she strives to
employ advanced language models in medical research, even within her
facility’s resource limitations. This instance emphasizes the critical
necessity for methodical language model assessments under varying resource
constraints and accuracy criteria. Through this investigation, we aim to offer
practical insights to assist users like Dr. Smith in optimizing their language
model choices for local deployment. A comprehensive investigation, as
conducted by [13], can elucidate the pipeline of machine learning tasks and
pinpoint the stages most vulnerable to resource constraints.

Challenge 2: How to coordinate continuous updates?  Effective collaboration
among layers is vital to ensure a seamless process of continual learning. As
depicted in Fig. 2, knowledge transfer is a dynamic process occurring in both
Upstream and Downstream. To illustrate, when Dr. Smith updates her language
model with new information, the language models in the hierarchy might receive
notifications through upstream knowledge transfer based on some criteria.
While downstream knowledge transfer can be achieved through distillation,
achieving upstream knowledge transfer can be realized through three distinct
methods: (a) sharing raw data, (b) employing a generator with synthetic
training samples, or (c) sharing model parameters.

(a) Collaboration via Direct Dataset Sharing: When an end device
retrains/updates its language model, the device can send the training dataset
to the corresponding parent language model to update itself. However, this
method raises concerns about data privacy since the original dataset is shared
among language models.

(b) Privacy-Preserving Collaboration via Synthetic Data Sharing: To address
the privacy concerns, a continual learning process with two components can be
leveraged: the generator and the learner [11]. As bulk, new data arrives at
the end devices, the learner component incorporates these generated examples
into the training process, fine-tuning the model’s parameters based on the new
data. Next, The generator component generates synthetic training examples that
mimic real-world language patterns and structures. These examples serve as
additional training data for the peer language model, allowing it to learn
from more diverse language variations and scenarios while preserving privacy.
In cases where an intermediate language model (LSLM, DLM, SDLM) updates
itself, its generator generates synthetic training examples and sends the
dataset to the predecessor or successor layer for further updating. This
approach ensures privacy and facilitates consistent, collaborative learning.
In the healthcare research scenario, as new patient data arrives at healthcare
facilities, the “learner” component incorporates it into the research process
for fine-tuning/continual learning methods. Simultaneously, the “generator”
component generates synthetic patient data, mimicking real-world patterns, and
shares this with the research network. This approach ensures privacy and
enables collaborative learning among healthcare researchers while maintaining
data privacy.

(c) Privacy-Preserving Collaboration via Model Parameter Sharing: Another
alternative approach is that the parent language model maintains a copy of the
immediate child (distilled) language models. Instead of sharing datasets, the
updated model parameters are communicated back to the Upstream language model.
This parameter-passing approach promotes collaborative learning while
preserving data privacy, following the principles of federated learning [14,
15]. For Downstream knowledge transfer, a distilled Topic-Driven Generator to
generate topic-specific synthetic training data can be employed, which will be
used to update the successor layer language models. However, there is a need
to investigate specific techniques for Upstream and Downstream knowledge
transfer to optimize the overall architecture.

Challenge 3: How to prevent the loss of previously learned knowledge?  One of
the challenges we might face in this context is the loss of previously learned
knowledge. This issue is commonly referred to as “catastrophic forgetting”
[16], where knowledge that was previously acquired is at risk of being
forgotten when new information is introduced. Catastrophic forgetting is a
common side-effect of continual learning, where previously acquired knowledge
is at risk of being lost during the assimilation of new information. In the
healthcare use case, catastrophic forgetting is pertinent if she continuously
updates her language model with new medical data to stay current with rare
disease research. The risk of forgetting critical insights while adapting to
the latest information is a significant concern and needs further research in
the context of hierarchical LLM architecture such as those we proposed here.

Challenge 4: When should we update the parent language model?  One of the
challenges is to define the criteria for updating an Upstream (parent)
language model. Considering the multitude of end devices actively utilizing
and modifying these models, managing this constant stream of updates is of
utmost importance. End users may use specific language models, tailoring them
to their immediate needs. However, not all updates are pertinent to the Master
language model. Therefore, it becomes crucial to determine the optimal timing
for these updates to maintain efficiency and effectiveness in the distributed
architecture. One strategy could be evaluating the significance of new data in
contributing to the broader knowledge base [17].

Challenge 5: What if a node is malicious?  Thus far, we assume all nodes
cooperate and obey the protocol. However, an end device could misbehave and
try to destabilize the system by (i) data poisoning attacks (participants
intentionally submit data with incorrect labels) [18], (ii) model poisoning
attacks (malicious participants modify the updated model directly before
sending it for aggregation) [19], and (iii) free-riding attacks (malicious
participants contribute passively) [20]. These concerns are not just
theoretical. A medical researcher, for instance, faces similar risks due to
the dependency on labeled data for fine-tuning/continually updating models. If
participants intentionally provide incorrect medical data or tamper with the
model during updates, it could negatively affect research findings.
Additionally, passive disruptions by malicious individuals could hinder the
research process without their active participation. Hence, it is imperative
to develop suitable techniques that can (a) isolate malicious nodes, (b) limit
their information propagation to prevent poisoning Upstream models, and (c)
identify if any misinformation colludes with parent models.

## Conclusion

This work presents a “layered” LLM architecture to tackle the challenges of
deploying LLMs in practical, real-world applications. We believe this concept
can serve as a stepping stone for implementing an open-source, customizable
LLM architecture, which will foster a wider adoption of LLMs across various
platforms and applications, unlocking their potential for agile performance.

## REFERENCES

  * [1] T. Brown, B. Mann, N. Ryder, M. Subbiah, J. D. Kaplan, P. Dhariwal, A. Neelakantan, P. Shyam, G. Sastry, A. Askell _et al._ , “Language models are few-shot learners,” _Advances in neural information processing systems_ , vol. 33, pp. 1877–1901, 2020.
  * [2] H. Touvron, T. Lavril, G. Izacard, X. Martinet, M.-A. Lachaux, T. Lacroix, B. Rozière, N. Goyal, E. Hambro, F. Azhar, A. Rodriguez, A. Joulin, E. Grave, and G. Lample, “Llama: Open and efficient foundation language models,” 2023.
  * [3] T. L. Scao, A. Fan, C. Akiki, E. Pavlick, S. Ilić, D. Hesslow, R. Castagné, A. S. Luccioni, F. Yvon, M. Gallé _et al._ , “Bloom: A 176b-parameter open-access multilingual language model,” _arXiv preprint arXiv:2211.05100_ , 2022.
  * [4] T. Zhang, F. Ladhak, E. Durmus, P. Liang, K. McKeown, and T. B. Hashimoto, “Benchmarking large language models for news summarization,” 2023.
  * [5] M. Sallam, “Chatgpt utility in healthcare education, research, and practice: systematic review on the promising perspectives and valid concerns,” in _Healthcare_ , vol. 11. MDPI, 2023, p. 887.
  * [6] N. M. S. Surameery and M. Y. Shakor, “Use chat gpt to solve programming bugs,” _International Journal of Information Technology & Computer Engineering (IJITC) ISSN: 2455-5290_, vol. 3, no. 01, pp. 17–22, 2023.
  * [7] S. Sarkar, D. Feng, and S. K. K. Santu, “Exploring universal sentence encoders for zero-shot text classification,” in _Proceedings of the 2nd Conference of the Asia-Pacific Chapter of the Association for Computational Linguistics and the 12th International Joint Conference on Natural Language Processing_ , 2022, pp. 135–147.
  * [8] ——, “Zero-shot multi-label topic inference with sentence encoders and llms,” in _Proceedings of the 2023 Conference on Empirical Methods in Natural Language Processing_ , 2023, pp. 16 218–16 233.
  * [9] W. Jiao, W. Wang, J.-t. Huang, X. Wang, and Z. Tu, “Is chatgpt a good translator? a preliminary study,” _arXiv preprint arXiv:2301.08745_ , 2023.
  * [10] S. Sarkar, M. F. Babar, M. M. Hassan, M. Hasan, and S. K. K. Santu, “Exploring challenges of deploying bert-based nlp models in resource-constrained embedded devices,” _arXiv preprint arXiv:2304.11520_ , 2023.
  * [11] F.-K. Sun, C.-H. Ho, and H.-Y. Lee, “Lamol: Language modeling for lifelong language learning,” _arXiv preprint arXiv:1909.03329_ , 2019.
  * [12] J. Gou, B. Yu, S. J. Maybank, and D. Tao, “Knowledge distillation: A survey,” _International Journal of Computer Vision_ , vol. 129, pp. 1789–1819, 2021.
  * [13] S. K. Karmaker, M. M. Hassan, M. J. Smith, L. Xu, C. Zhai, and K. Veeramachaneni, “Automl to date and beyond: Challenges and opportunities,” _ACM Computing Surveys (CSUR)_ , vol. 54, no. 8, pp. 1–36, 2021.
  * [14] X. Zhu, J. Wang, Z. Hong, and J. Xiao, “Empirical studies of institutional federated learning for natural language processing,” in _Findings of the Association for Computational Linguistics: EMNLP 2020_ , 2020, pp. 625–634.
  * [15] M. Chen, A. T. Suresh, R. Mathews, A. Wong, C. Allauzen, F. Beaufays, and M. Riley, “Federated learning of n-gram language models,” _arXiv preprint arXiv:1910.03432_ , 2019.
  * [16] X. Li, Y. Zhou, T. Wu, R. Socher, and C. Xiong, “Learn to grow: A continual structure learning framework for overcoming catastrophic forgetting,” in _International Conference on Machine Learning_. PMLR, 2019, pp. 3925–3934.
  * [17] Z. Ke, Y. Shao, H. Lin, T. Konishi, G. Kim, and B. Liu, “Continual pre-training of language models,” in _The Eleventh International Conference on Learning Representations_ , 2023.
  * [18] V. Tolpegin, S. Truex, M. E. Gursoy, and L. Liu, “Data poisoning attacks against federated learning systems,” in _Computer Security–ESORICS 2020: 25th European Symposium on Research in Computer Security, ESORICS 2020, Guildford, UK, September 14–18, 2020, Proceedings, Part I 25_. Springer, 2020, pp. 480–501.
  * [19] X. Zhou, M. Xu, Y. Wu, and N. Zheng, “Deep model poisoning attack on federated learning,” _Future Internet_ , vol. 13, no. 3, p. 73, 2021.
  * [20] J. Lin, M. Du, and J. Liu, “Free-riders in federated learning: Attacks and defenses,” _arXiv preprint arXiv:1911.12560_ , 2019.