Sharded SplitFed Learning (SSFL)

• Sharded SplitFed Learning (SSFL) is a distributed learning framework that partitions clients across multiple shard servers with a common split point, maintaining model accuracy.
• SSFL improves scalability by distributing server load and smoothing updates through a two-level federated averaging process between shard servers and a global FL server.
• Empirical results on Fashion-MNIST show SSFL achieved a 31.2% reduction in test loss and an 85.2% decrease in round time compared to standard SplitFed Learning.

Sharded SplitFed Learning (SSFL) is a sharded extension of SplitFed Learning (SFL) that introduces multiple parallel SFL shards together with an additional federated aggregation layer. In SSFL, each shard operates like a standard SFL instance consisting of one split-learning server and its assigned clients, while a global federated-learning server periodically aggregates the models of all shard servers and all clients using FedAvg. The stated purpose is twofold: to distribute the split-learning server load across multiple parallel shards, and to stabilize and improve training by smoothing server-side updates through another level of federated averaging (Sokhankhosh et al., 29 Sep 2025).

1. Conceptual position within FL, SL, and SplitFed

SSFL occupies a specific point in the distributed collaborative learning taxonomy. In federated learning, clients train full local models and a server aggregates model parameters, which implies heavy client-side computation and no model splitting. In split learning, a model is partitioned at a cut layer, clients train the early layers, and a central server trains the later layers using smashed data and returned activation gradients; this keeps clients light but creates a server bottleneck and sequential or high-frequency interaction. SplitFed combines these ideas: clients retain client-side submodels, a split server holds the server-side submodel, and federated aggregation is used to synchronize client-side models in parallel SFL training (Sokhankhosh et al., 29 Sep 2025).

SSFL modifies SFL by replacing the single split-learning server with multiple split-learning servers, or shards, while preserving a global federated aggregation stage. The distinction is structural rather than merely implementation-level: SFL has one SL server and one FL server, whereas SSFL has multiple SL servers and one FL server. This architecture is intended to address both infrastructure scalability and performance-level scalability, because the single-server bottleneck of SFL persists as the client population grows (Sokhankhosh et al., 29 Sep 2025).

A recurrent misconception is to treat a “shard” in SSFL as a partition of the model itself. In the framework as defined, a shard is not a model partition but a partition of the client set together with a separate replica of the server-side model. Model architecture and split point remain the same across shards; what differs across shards during local training are data and parameters (Sokhankhosh et al., 29 Sep 2025).

Historically, this formulation extends earlier SplitFed systems in which client-side synchronization was central to the method. Earlier surveys and architectural descriptions define SplitFed as a hybrid of split execution and federated aggregation, with a main server for server-side training and a fed server for aggregation of client-side model portions (Thapa et al., 2020). Subsequent work also emphasized that client-side synchronization itself is a source of overhead, and that removing it yields Multi-head Split Learning with performance comparable to SFL on MNIST, where SFL provides only $1\%-2\%$ better accuracy than Multi-head Split Learning on the MNIST test set (Joshi et al., 2021). That result does not redefine SSFL, but it clarifies that the synchronization design space around split-federated systems is broader than the original SFL protocol.

2. System architecture and training protocol

The SSFL system model contains three roles: clients, shard servers, and a global FL server. Clients hold private local datasets, train the client-side submodel up to the split layer, send activations and labels to their assigned shard server, receive gradients with respect to the cut-layer activations, and periodically send client-side model parameters $W^C_{j,t}$ to the FL server for aggregation. Each shard server manages a subset of clients, stores and trains the server-side submodel for its shard, maintains per-client server weights $W^S_{i,j,r}$, and aggregates those per-client server models into a shard-level model $W^S_{i,r+1}$. The FL server aggregates all shard server models and all client models, conceptually treating “client FL server” and “server FL server” as one process (Sokhankhosh et al., 29 Sep 2025).

Using the notation of the SSFL formulation, there are $I$ shard servers, each serving $J$ clients. Within shard $i$, server-side weights for client $j$ at round $r$ are $W^S_{i,j,r}$, and client-side weights for client $W^C_{j,t}$0 at round $W^C_{j,t}$1 are $W^C_{j,t}$2. After local shard training, shard $W^C_{j,t}$3 aggregates according to

$W^C_{j,t}$4

After all shards finish, the global FL server aggregates

$W^C_{j,t}$5

This yields a two-level averaging hierarchy: intra-shard averaging on server-side parameters and inter-shard/global averaging over shard models and client models (Sokhankhosh et al., 29 Sep 2025).

The communication topology is heterogeneous in frequency. Between clients and shard servers, communication is synchronous and batch-wise during local rounds: clients send smashed activations $W^C_{j,t}$6 and labels $W^C_{j,t}$7, and shard servers return gradients $W^C_{j,t}$8. Between shard servers and the FL server, communication occurs at the end of a shard training cycle, when the shard sends aggregated $W^C_{j,t}$9. Clients likewise send $W^S_{i,j,r}$0 to the FL server at the end of the cycle, after which the FL server broadcasts $W^S_{i,j,r}$1 and $W^S_{i,j,r}$2 for the next cycle (Sokhankhosh et al., 29 Sep 2025).

For experiments, the model split is a two-part CNN partition. The client-side model comprises a Conv2d layer with in channels $W^S_{i,j,r}$3, out channels $W^S_{i,j,r}$4, kernel $W^S_{i,j,r}$5, followed by ReLU and MaxPool2d with kernel $W^S_{i,j,r}$6 and stride $W^S_{i,j,r}$7. The server-side model comprises Conv2d with in $W^S_{i,j,r}$8, out $W^S_{i,j,r}$9, kernel $W^S_{i,r+1}$0, followed by ReLU, MaxPool2d with kernel $W^S_{i,r+1}$1 and stride $W^S_{i,r+1}$2, Flatten, Linear from $W^S_{i,r+1}$3 to $W^S_{i,r+1}$4, ReLU, and Linear from $W^S_{i,r+1}$5 to $W^S_{i,r+1}$6. The cut layer is after the first conv–ReLU–pool block (Sokhankhosh et al., 29 Sep 2025).

A second misconception concerns server placement. SSFL is not a decentralized protocol in its base form. It still uses a central FL server to aggregate models from shards and clients. The decentralized variant in the same line of work is Blockchain-enabled SplitFed Learning (BSFL), not SSFL (Sokhankhosh et al., 29 Sep 2025).

3. Sharding mechanics, aggregation dynamics, and scalability rationale

The operational meaning of sharding in SSFL is the distribution of split-learning server load across multiple parallel shard servers. Per-client communication pattern remains unchanged relative to SFL: each client still sends activations and receives activation gradients for each batch. What changes is the distribution of that traffic and the frequency of aggregation. Because client traffic is distributed over $W^S_{i,r+1}$7 shard servers, each shard server handles only $W^S_{i,r+1}$8 clients’ traffic, and the per-server communication load is reduced approximately by a factor of $W^S_{i,r+1}$9. The added communication between shard servers and the FL server is low-frequency and small, since it consists of model weights rather than per-batch activations and gradients (Sokhankhosh et al., 29 Sep 2025).

The same decomposition applies to computation. In single-server SL or SFL, all server-side forward and backward passes for all clients are executed on one server. In SSFL, the same total server-side computation is partitioned across $I$0 shard servers. Assuming balanced shards, per-server computation scales as approximately $I$1 of SFL’s server cost, while each client’s computation is unchanged relative to SFL (Sokhankhosh et al., 29 Sep 2025).

The framework also claims a statistical effect beyond infrastructure parallelism. In SL and SFL, server-side layers are updated much more frequently than client-side layers, effectively giving them a much higher learning rate. As the number of clients increases, this imbalance worsens and can degrade accuracy and convergence stability. SSFL mitigates this by averaging server models within shards and then across shards, which reduces the effective server learning rate by smoothing updates (Sokhankhosh et al., 29 Sep 2025).

This logic is closely related to broader analyses of scalable split learning. Earlier work on server-side local gradient averaging and learning-rate splitting argued that parallel split learning suffers from a server-side large effective batch problem and from backward client decoupling, and proposed server-side gradient averaging and separate server/client learning rates to emulate FL-like coupling without client-side weight exchange (Pal et al., 2021). Although that work does not define SSFL, it reinforces the view that split-federated systems become scalable only when server-side update imbalance is explicitly controlled.

A third misconception is that sharding automatically implies model parallelism. In the baseline SSFL formulation it does not. The server-side architecture is replicated across shards rather than partitioned across them. Possible model-sharded SSFL variants are plausible extensions, but they are not the architecture experimentally validated in the defining framework (Sokhankhosh et al., 29 Sep 2025).

4. Empirical behavior and measured performance

The reported SSFL experiments use Fashion-MNIST with non-IID local data. The paper considers two settings: $I$2 total nodes and $I$3 total nodes. In the $I$4-node case, SSFL uses $I$5 shards, each with $I$6 clients. In the $I$7-node case, SSFL uses $I$8 shards, each with $I$9 clients. Each node has an equal number of samples but non-IID distribution: $J$0 images per node in the $J$1-node setup, and $J$2 images per node in the $J$3-node setup (Sokhankhosh et al., 29 Sep 2025).

Measured outcomes in the $J$4-node setting show a substantial change in both normal test loss and round completion time. SSFL attains normal test loss $J$5, compared with $J$6 for SL and $J$7 for SFL, and average round time $J$8 minutes, compared with $J$9 for SL and $i$0 for SFL. The paper explicitly interprets the reduction from $i$1 to $i$2 as a $i$3 performance improvement relative to SFL, and the reduction from $i$4 to $i$5 minutes as an $i$6 scalability improvement (Sokhankhosh et al., 29 Sep 2025).

The validation-loss curves for both the $i$7-node and $i$8-node settings are described as dropping faster than SL and SFL and converging to a lower minimum. The same experiments report that SSFL exhibits a consistently much lower round time, around $i$9–$j$0 minutes, than SL and SFL, around $j$1–$j$2 minutes, in the $j$3-node setting (Sokhankhosh et al., 29 Sep 2025).

These empirical results support the claim that SSFL addresses both server bottlenecks and training degradation under scale. However, the gains are tied to a particular experimental regime: Fashion-MNIST, a simple CNN split, balanced static sharding, and non-IID but equal-sized local datasets. A plausible implication is that the reported gains establish a system-level proof of concept rather than a universal performance law.

The surrounding SplitFed literature adds context on where performance may change under other system pressures. MU-SplitFed addresses stragglers in Split Federated Learning by allowing the split server to perform $j$4 local updates per client round, yielding a convergence rate of $j$5 for the single-client case and $j$6 in the multi-client setting, with a linear speedup of $j$7 in communication rounds (Liang et al., 24 Oct 2025). HASFL, in turn, derives a convergence bound for SFL with heterogeneous batch sizes and split locations, and uses adaptive control of batch size and model splitting to mitigate stragglers and resource heterogeneity (Lin et al., 10 Jun 2025). These results do not measure SSFL directly, but they indicate that SSFL’s parallel shards are only one axis of scalability; straggler handling and heterogeneity-aware partitioning remain orthogonal concerns.

5. Security properties, attack surface, and relation to BSFL

SSFL is primarily a performance and scalability design rather than a security mechanism. Its threat model assumes honest shard servers and an honest FL server, as in classic SFL, and it does not incorporate Byzantine-robust aggregation. Malicious clients may perform data poisoning by sending harmful model updates to the FL server, and a malicious FL server could selectively aggregate or bias model updates. These issues are explicitly not mitigated by SSFL itself (Sokhankhosh et al., 29 Sep 2025).

This limitation is reflected in the attack experiments reported for the $j$8-node setting. Under attack, SSFL’s attacked test loss is $j$9, worse than its normal test loss of $r$0. The framework therefore improves normal-operation performance and scalability, but not robustness to poisoning (Sokhankhosh et al., 29 Sep 2025).

Security analyses of SplitFed more broadly provide a subtler picture. An empirical study of model poisoning in SplitFed reported that the accuracy reduction due to the model poisoning attack is $r$1 lower for SplitFed compared to FL, attributing this to the smaller dimensionality of client updates in SplitFed and the general observation that large models with higher dimensionality are more susceptible to privacy and security attacks (Khan et al., 2022). This suggests that SSFL may retain some robustness associated with the split-model setting of SFL, but that effect is not a substitute for explicit defenses. The defining SSFL framework itself states that it inherits FL/SL vulnerability to poisoned updates and central-server trust assumptions (Sokhankhosh et al., 29 Sep 2025).

BSFL is the security-oriented continuation of SSFL. It replaces the centralized FL server with a blockchain-based architecture employing a committee-driven consensus mechanism, and incorporates an evaluation mechanism to exclude poisoned or tampered model updates. The reported result is a $r$2 increase in resilience to data poisoning attacks while maintaining superior performance under normal operating conditions, and the work describes BSFL as the first blockchain-enabled framework to implement an end-to-end decentralized SplitFed Learning system (Sokhankhosh et al., 29 Sep 2025).

A persistent misconception is therefore that sharding alone decentralizes trust. In SSFL it does not. Sharding distributes the split-learning server workload, but the central FL server remains a single point of trust and failure until it is replaced by a mechanism such as that used in BSFL (Sokhankhosh et al., 29 Sep 2025).

6. Extensions, personalization, and open research directions

The base SSFL formulation is deliberately simple: one client-side partition, one replicated server-side partition per shard, static client-to-shard assignment in experiments, and synchronous global aggregation. Several strands of later or adjacent research indicate how SSFL might evolve.

One axis is personalization. PGFedSplit proposes a split personalized FL method in which representation layers are aggregated every round while personalization heads are synchronized periodically with an adaptive period, and clients mix local and global heads instead of replacing them. The work explicitly notes that, for SSFL, each shard or segment can have its own aggregation policy rather than a uniform schedule across all shards, and it suggests per-shard aggregation frequency, adaptive scheduling per shard, and shard-specific personalization parameters. This suggests an SSFL design in which feature-extracting shards are aggregated every round while task-specific shards are aggregated periodically with adaptive scheduling (Kang et al., 26 May 2026).

A second axis is heterogeneity awareness. HASFL derives a convergence bound for SFL under adaptive batch sizes and model splitting, showing that the number of client-side layers aggregated every $r$3 rounds enters the bound through $r$4, while batch sizes $r$5 control stochastic variance via $r$6. The same paper proposes a block-coordinate-descent procedure to jointly optimize training time, batch sizes, and split locations under latency, communication, and memory constraints (Lin et al., 10 Jun 2025). Although formulated for a single logical edge server, this analysis supplies a natural starting point for SSFL systems in which shard placement and client cut layers are co-optimized.

A third axis is straggler resilience. MU-SplitFed retains synchronous global aggregation but permits the split server to perform $r$7 local zeroth-order updates per client round, thereby decoupling training progress from straggler delays and achieving a convergence rate of $r$8 for non-convex objectives (Liang et al., 24 Oct 2025). A plausible implication is that SSFL could combine horizontal sharding with per-shard unbalanced updates, allowing each shard to amortize slow-client delays independently.

There are also open issues internal to SSFL itself. The defining framework includes no dynamic shard management, no explicit straggler mitigation, no formal convergence analysis for the sharded hierarchy, and no fault-tolerance mechanism for shard-server or FL-server failure (Sokhankhosh et al., 29 Sep 2025). Earlier SplitFed work without client-side synchronization further suggests that some aggregation layers may be removable with modest accuracy cost under IID settings, because Multi-head Split Learning is feasible and SFL provides only $r$9 better accuracy than Multi-head Split Learning on the MNIST test set (Joshi et al., 2021). Whether analogous partial or infrequent synchronization works in non-IID, multi-shard, large-model SSFL remains unresolved.

Taken together, the literature characterizes SSFL as a system-level refinement of SplitFed that redistributes server load and inserts a second aggregation level, rather than as a fundamentally new optimization principle. Its established contribution is the conversion of a single-server SplitFed pipeline into a multi-shard architecture with measured reductions in test loss and round time under non-IID Fashion-MNIST workloads (Sokhankhosh et al., 29 Sep 2025). Its unresolved research agenda concerns precisely the issues that dominate modern split-federated systems: heterogeneity, stragglers, personalization, robustness, and the coordination of multiple aggregation domains.