FedXgbBagging: Federated XGBoost Bagging

• FedXgbBagging is a federated ensemble method that aggregates local XGBoost decision trees using a bagging strategy rather than parameter averaging.
• It preserves data privacy by keeping raw operational data local while combining serialized client-side trees to improve energy prediction in Kubernetes systems.
• Empirical results demonstrate an 11.7% improvement in MAE with enhanced generalization across heterogeneous client settings.

FedXgbBagging is a federated aggregation strategy for XGBoost in which a central Flower server constructs a global ensemble by collecting decision trees learned at distributed clients and combining them with a bagging procedure rather than by averaging model parameters. In the carbon-aware Kubernetes energy-modeling framework proposed in “Towards Carbon-Aware Container Orchestration: Predicting Workload Energy Consumption with Federated Learning” (Saad et al., 4 Oct 2025), it is the core mechanism for privacy-preserving energy or power prediction across enterprises: raw operational data remain local, while serialized client-side trees are aggregated into a shared model for workload energy estimation.

1. Definition, scope, and motivation

Within the cited Kubernetes energy-prediction system, FedXgbBagging is used to address a specific tension between privacy and generalization. Centralized learning is described as problematic because enterprises do not want to send sensitive workload traces, utilization data, or power-related telemetry to a central server, while isolated local models may fail to generalize across heterogeneous hardware types, workload patterns, and deployment environments. The federated design is therefore intended to preserve data locality while still exploiting cross-client diversity for a more generalizable predictor (Saad et al., 4 Oct 2025).

Its use is also tied to the model class. The local predictor is an XGBoost regression model rather than a neural network, so conventional federated averaging is not structurally appropriate. The paper states that, unlike FedAvg, which averages model weights, FedXgbBagging aggregates decision trees from distributed clients using a bagging approach, because XGBoost models cannot be averaged directly. FedXgbBagging is thus motivated both by the privacy and generalization requirements of workload energy prediction and by the incompatibility of boosted-tree models with parameter averaging.

The application context is carbon-aware container orchestration. The broader goal is to support scheduling decisions that reduce energy use and carbon emissions in Kubernetes-based environments. The work explicitly positions itself relative to Kepler and CASPER, arguing that prior systems either rely on centralized training or remain confined to isolated settings that generalize poorly across diverse environments. FedXgbBagging appears in this setting not as a generic federated-learning abstraction, but as the server-side ensembling mechanism that makes federated XGBoost feasible for Kepler-style energy modeling.

2. Aggregation semantics and model representation

In this framework, FedXgbBagging is the server-side aggregation strategy executed by Flower. The architecture consists of multiple clients or data centers, each training a local XGBoost regression model on private data, and a central server that initializes a global model, coordinates rounds, receives model artifacts, and redistributes the aggregated result (Saad et al., 4 Oct 2025).

The aggregation unit is the decision tree. The paper is explicit that clients share decision trees without sharing raw data, and that the server collects trees from all clients to construct a global ensemble using a bagging strategy. The mechanism does not aggregate raw examples, neural-network weights, scalar gradient updates, or only final predictions. A common misconception is to treat federated tree aggregation as prediction-level voting; that is not the description given here. The bagging effect arises through ensemble composition.

The practical procedure is also specified. Each client trains a local XGBoost model, serializes it to JSON, and uploads the serialized artifact. The server parses the serialized model, extracts the learned trees, renumbers trees with unique IDs to avoid collisions, appends them into a shared global model structure, and updates both the total number of trees and the starting index of each training iteration’s trees. The result is best understood as a global ensemble composed of client-contributed trees.

A further implementation property is that clients are not required to produce the same number of trees. The aggregator treats each tree independently and can accept variable tree counts across clients. Flower’s FedXgbBagging is described as using uniform bagging: no weighting is applied during aggregation, and each decision tree contributes equally to the final prediction. There is therefore no weighting by client dataset size, model quality, or observed performance.

3. Mathematical formulation and protocol flow

The paper formalizes the client-side and global models at tree level. If there are $K$ clients and client $k$ trains an XGBoost model with $T_k$ trees, then

$$M_k = \{f_{k}^{(1)}, f_{k}^{(2)}, \dots, f_{k}^{(T_k)}\}, \quad \text{for } k = 1, 2, \dots, K.$$

The aggregated model is

$$M_G = \bigcup_{k=1}^{K} \{f_{k}^{(1)}, f_{k}^{(2)}, \dots, f_{k}^{(T_k)}\},$$

and the total number of trees is

$T = \sum_{k=1}^{K} T_k.$

Here the union symbol denotes collection of all client trees into one ensemble, not a parameter-level merge (Saad et al., 4 Oct 2025).

The end-to-end protocol is described procedurally rather than as pseudocode. The dataset is loaded and preprocessed, then synthetically partitioned into clients by node_type to simulate heterogeneous organizations or data centers. The server initializes a global model or ensemble structure and coordinates training rounds. Each client receives the current global model, trains an XGBoost regressor on its local node-type-specific data, serializes the result to JSON, and uploads it. The server extracts trees, renumbers and appends them, updates the global structure, and sends the aggregated model back to clients. This process repeats for 10 rounds.

Evaluation is performed offline using MAE, MSE, RMSE, MAPE, and $R^2$. The text explicitly emphasizes that the aggregated model outperforms individual clients after the initial rounds. At the same time, the mathematical specification is incomplete in several respects. The paper does not provide an explicit XGBoost objective function, an explicit federated optimization objective, a formula for the final prediction rule $\hat{y}(x)$, or explicit formulas for the evaluation metrics. This suggests that the server-side ensemble semantics are operationally clear but not fully formalized at scoring level.

4. Software stack and systems embedding

The implementation is built around Flower, XGBoost, Kepler, and Kubernetes. Flower provides the federated orchestration layer and the FedXgbBagging aggregation strategy. Each client trains an XGBoost regression model. The explicit local hyperparameters given are n_estimators = 100 and learning rate 0.01; the paper states that each model consists of 100 boosting rounds and that the low learning rate is used to ensure smooth convergence and prevent overfitting (Saad et al., 4 Oct 2025).

The federated XGBoost model is implemented as an extension of Kepler’s power-modelling pipeline. Kepler is used for power-related telemetry and performance-counter collection, and the work extends that pipeline so that training becomes federated rather than centralized. Kubernetes remains the intended orchestration environment in which the model would support carbon-aware scheduling, but the reported experiments are not from a live operational cluster.

The evaluation uses the SPECpower_ssj2008 benchmark dataset. The current implementation relies on the BPFOnly feature group, MinIdleIsolator for isolating idle power states, and ACPI as the energy source supported by the dataset. The dataset is synthetically partitioned into 3 clients, with the paper explaining that a larger number of clients would leave each client with too little data for adequate model learning. The main reported setting uses a 20% test split, learning rate 0.01, and 10 training rounds.

A further systems caveat is explicit: the setup is offline. The paper states that the SPECPower benchmark dataset is not collected in real time from an operational Kubernetes cluster. The Kubernetes integration is therefore architectural and intended, whereas real-time deployment remains future work.

5. Empirical behavior, advantages, and limitations

The main quantitative result is a reduction in Mean Absolute Error from a centralized baseline MAE of 14.51 to a final aggregated federated MAE of 12.81, described as an 11.7% improvement. The learning dynamics are also reported: client MAE values begin around 20–24, decrease steadily over rounds, and the aggregated model improves to about 12.8 by round 10. The paper further states that the aggregated model consistently outperformed individual clients after the initial rounds, and reports improving qualitative trends for $R^2$, MSE, RMSE, and MAPE (Saad et al., 4 Oct 2025).

These results support several concrete advantages. First, privacy is preserved by data locality: only model artifacts, specifically decision trees, are transmitted. Second, the method is compatible with XGBoost, avoiding an inapplicable parameter-averaging design. Third, the aggregated ensemble appears to exploit node-type diversity across clients. This suggests that tree-level aggregation across heterogeneous client distributions can improve robustness and generalization for workload energy prediction in this particular benchmark setup.

The limitations are equally explicit. The method does not provide a formal privacy guarantee: no differential privacy mechanism is applied, and model inference attacks on shared trees remain a theoretical concern. The evaluation is offline and uses only 3 clients. The paper does not quantify final global tree count, memory overhead, inference latency, or any pruning or compression strategy, even though the ensemble can grow across clients and rounds. It also does not provide a formal ablation isolating the contribution of bagging, a comparison with alternative federated tree strategies, a statistical significance analysis, or a communication-cost study.

Reproducibility is partially constrained by missing training details. The paper does not specify max depth, subsampling, column sampling, min child weight, regularization settings beyond the learning rate, the exact XGBoost objective string, early stopping, the exact Flower strategy configuration, or the exact centralized-baseline setup. It also does not fully specify whether clients continue training from the received global ensemble state or reconstruct local models afresh in each round. These omissions do not alter the published workflow, but they limit exact reimplementation.

6. Relation to adjacent federated tree-ensemble methods

FedXgbBagging occupies a specific position within federated tree learning. It differs from horizontal federated XGBoost methods that build a single global boosted model by exchanging gradient, Hessian, histogram, or sketch statistics. “Federated XGBoost on Sample-Wise Non-IID Data” studies a boosting-based procedure with DDSketch-style histogram aggregation and server-side global tree growth; it is explicitly not a bagging method (Jones et al., 2022). “Histogram-Based Federated XGBoost using Minimal Variance Sampling for Federated Tabular Data” likewise remains sequential boosting with client-side row sampling, not bagging or client-model ensembling (Lindskog et al., 2024).

It is closer in spirit to methods that aggregate already trained client ensembles. “Gradient-less Federated Gradient Boosting Trees with Learnable Learning Rates” trains complete local XGBoost ensembles once, uploads them, concatenates the resulting trees, and learns aggregation weights with a lightweight federated neural combiner; the paper explicitly characterizes this as bagging-like or stacking-like aggregation rather than classical federated boosting (Ma et al., 2023). FedXgbBagging in the Kepler setting is simpler: it uses uniform bagging, without learned per-tree or per-client coefficients.

The method is also distinct from vertical federated boosting or security-focused vertical XGBoost protocols. “FedGBF: An efficient vertical federated learning framework via gradient boosting and bagging” is conceptually close in its hybridization of boosting and bagging, but it operates in vertical federated learning and boosts over forests rather than concatenating client-trained XGBoost trees in a horizontal setting (Han et al., 2022). A plausible implication is that FedXgbBagging is best viewed as a horizontal, model-artifact-level ensemble strategy, not as a general federated tree-learning recipe across federation types.

This placement helps clarify what FedXgbBagging is and is not. It is not federated averaging for trees, not split-statistics aggregation for one globally grown boosted model, and not a cryptographically private protocol. It is a tree-concatenation ensemble mechanism for federated XGBoost, used here to support privacy-preserving energy modeling in a Kepler and Kubernetes context.