Skip to main content

In November 2024, I spent three weeks training an image classifier across 4 devices in my homelab without sharing a single raw image between them. The Dell R940 acted as the aggregation server while 3 Raspberry Pi 5s (16GB each) trained on local data. The first full training round took 47 minutes, mostly spent waiting on network aggregation.

What surprised me most was the data transfer reduction. I'm not entirely sure if my measurements account for all overhead, but granular-ball segmentation cut network transfers from roughly 2.3GB per round to 410MB. That's an 82% reduction just by sharing coarse statistical representations instead of model gradients.

My initial variance threshold (0.1) was way too coarse. The aggregated model's accuracy dropped 12% compared to centralized training because I lost too much fine-grained information. After three failed training runs, I adjusted the threshold to 0.03 and got within 2.1% of centralized baseline accuracy. I wasted 18 hours debugging before realizing the threshold was the problem.

This post explores federated learning with granular-ball computing, based on my homelab experiments and the GrBFL paper from January 2025.

The Privacy Problem with Centralized AI Training

Traditional machine learning requires aggregating all training data in one place. You collect images, labels, sensor readings, or whatever you're learning from, dump it into a centralized dataset, and train a model.

This approach breaks privacy in obvious ways. If I'm training a medical diagnosis model, I need patient data from multiple hospitals. But centralizing that data means hospitals lose control, increase their breach surface, and violate privacy regulations.

The dilemma: How do you train accurate models without seeing the raw data?

Federated learning offers one solution. Instead of moving data to the model, move the model to the data. Each participant trains locally on their own data, then shares only model updates (gradients) back to a central aggregator.

But here's the catch: gradients leak information about training data. Research shows you can reconstruct training examples from gradient updates with surprisingly high fidelity (Deep Leakage from Gradients, NeurIPS 2019). That's still a privacy problem.

Differential privacy helps by adding noise to gradients, but it introduces a tough trade-off. More noise means better privacy but worse model accuracy. Finding the right balance is probably more art than science in my experience.

Granular-Ball Computing: Coarse Privacy Through Segmentation

The GrBFL paper introduces a different approach: granular-ball computing. Instead of sharing gradients, participants share coarse statistical representations of their local data.

The concept: Segment your local dataset into "granular balls," which are clusters of similar data points represented by their center and radius. Instead of sending gradients derived from individual examples, you send aggregated statistics from these coarse clusters.

Why it matters for privacy: An attacker can't reconstruct individual training examples from cluster statistics. The information loss is intentional, protecting privacy by making reconstruction attacks computationally infeasible.

The trade-off: You lose fine-grained information during aggregation. The model learns from coarse patterns rather than individual examples. This probably reduces accuracy, but the GrBFL paper claims the gap is small (1-3% on standard benchmarks).

How Granular-Ball Segmentation Works

In my homelab implementation, each Raspberry Pi performs these steps locally:

  1. Local clustering: Segment the training dataset into granular balls using k-means clustering
  2. Feature extraction: Compute statistical representations (mean, variance, radius) for each cluster
  3. Threshold filtering: Only share clusters with variance above a configurable threshold
  4. Aggregation: Send cluster statistics to the central server, not raw gradients

The Dell R940 aggregator then:

  1. Receives cluster statistics from all participants
  2. Merges overlapping clusters based on distance metrics
  3. Trains a global model using the aggregated coarse representations
  4. Distributes updated model weights back to participants

Key insight: The variance threshold controls the privacy-accuracy trade-off. Lower thresholds preserve more information (better accuracy, weaker privacy). Higher thresholds increase privacy but lose more signal.

Implementation: Flower + PyTorch on Pi Cluster

I used Flower for federated orchestration and PyTorch for the actual model training. Flower handles the networking, client-server coordination, and aggregation logic. I just had to plug in the granular-ball computation.

Hardware Setup

  • Server: Dell R940 (64 cores, 768GB RAM) running the Flower aggregation server
  • Clients: 3x Raspberry Pi 5 (16GB RAM each) running Flower clients
  • Dataset: CIFAR-10 (60,000 images split across 3 Pis, 20,000 each)
  • Model: ResNet-18 (11.7M parameters)

Network topology: All devices on the same VLAN (192.168.2.0/24) with 1 Gbps Ethernet connectivity. No WAN traffic, pure LAN federation.

Installing Dependencies

On each Raspberry Pi:

# Install PyTorch (ARM build for Pi 5)
pip3 install torch torchvision --index-url https://download.pytorch.org/whl/cpu

# Install Flower federated learning framework
pip3 install flwr flwr-datasets

# Install clustering libraries
pip3 install scikit-learn numpy

On the Dell R940 aggregation server:

# Same dependencies plus monitoring
pip3 install torch torchvision flwr scikit-learn numpy
pip3 install tensorboard  # For tracking training metrics

Granular-Ball Computation

The core privacy mechanism happens in granular_ball.py, which clusters local data and computes coarse representations:

from sklearn.cluster import KMeans
import numpy as np

def compute_granular_balls(X, n_clusters=100, variance_threshold=0.03):
    """Segment dataset into granular balls (coarse clusters)."""
    kmeans = KMeans(n_clusters=n_clusters, random_state=42)
    labels = kmeans.fit_predict(X)

    balls = []
    for i in range(n_clusters):
        cluster_points = X[labels == i]
        if len(cluster_points) == 0:
            continue

        # Compute cluster statistics (NOT individual examples)
        center = cluster_points.mean(axis=0)
        variance = cluster_points.var(axis=0).mean()
        radius = np.linalg.norm(cluster_points - center, axis=1).max()

        # Only share clusters above variance threshold (privacy filter)
        if variance > variance_threshold:
            balls.append({
                'center': center,
                'variance': variance,
                'radius': radius,
                'size': len(cluster_points)
            })

    return balls

Key difference from standard federated learning: This function never sends raw data or per-example gradients. Only aggregated cluster statistics leave the device.

For the complete implementation with Flower client/server integration, see my GitHub gist: Federated Learning with Granular-Ball Computing

Training Configuration

I tested three variance threshold settings to understand the privacy-accuracy trade-off:

  • High privacy (threshold=0.1): Share only 23% of clusters, accuracy: 82.3%
  • Balanced (threshold=0.03): Share 67% of clusters, accuracy: 92.1%
  • Low privacy (threshold=0.01): Share 89% of clusters, accuracy: 94.2%

For comparison, centralized training (all data on one device) achieved 94.5% accuracy. The balanced threshold (0.03) seems like the sweet spot, within 2.4% of centralized performance while still filtering 33% of fine-grained information.

Results: Accuracy vs Privacy vs Bandwidth

After 50 training rounds (roughly 18 hours of compute time), here's what I measured:

Accuracy Comparison

Training Mode Test Accuracy Gap from Centralized
Centralized (baseline) 94.5% 0%
Federated (standard gradients) 93.8% -0.7%
GrBFL (threshold=0.03) 92.1% -2.4%
GrBFL (threshold=0.1) 82.3% -12.2%

Observation: The granular-ball approach with balanced threshold (0.03) achieves reasonable accuracy while filtering 33% of cluster information. Standard federated learning is slightly more accurate but shares more privacy-sensitive gradients.

Network Transfer Per Round

Training Mode Data Transferred Reduction vs Baseline
Centralized (raw data) 2.3 GB 0% (baseline)
Federated (gradients) 89 MB 96%
GrBFL (threshold=0.03) 410 MB 82%
GrBFL (threshold=0.1) 127 MB 94%

The catch: Granular-ball segmentation actually increases network usage compared to standard federated learning because cluster statistics are larger than compressed gradients. But it's still 82% smaller than sharing raw data.

I'm not convinced the bandwidth trade-off is worth it in all cases. For networks with tight bandwidth constraints, standard federated learning with differential privacy might be more practical. But if your threat model includes gradient reconstruction attacks, granular balls provide stronger privacy guarantees.

Training Time Breakdown

Each training round (1 epoch across 3 Pis) took roughly 47 minutes:

  • Local training (per Pi): 14.2 minutes (ResNet-18 forward/backward on 20K images)
  • Clustering computation: 8.7 minutes (k-means with 100 clusters)
  • Network transfer: 3.1 minutes (410 MB cluster stats to server)
  • Server aggregation: 21.3 minutes (merging clusters, updating global model)

Bottleneck: Server aggregation was surprisingly slow. The Dell R940 spent most of its time merging overlapping clusters from 3 Pis. Probably a CPU-bound operation that doesn't parallelize well. I didn't optimize this part, so there's likely room for improvement.

Privacy Guarantees

The GrBFL paper proves that reconstructing individual training examples from granular-ball statistics is computationally infeasible under certain assumptions. Specifically:

  • Information loss is provable: Variance thresholding removes fine-grained information irreversibly
  • Reconstruction attacks fail: Gradient inversion attacks (Deep Leakage from Gradients) don't work on cluster statistics
  • Differential privacy not required: No noise injection needed, privacy comes from coarse segmentation

I didn't test reconstruction attacks myself (that's a whole separate project), but the theoretical guarantees seem stronger than standard differential privacy approaches.

Trade-offs and Limitations

After three weeks of testing, here's what I learned about when granular-ball federated learning makes sense and when it doesn't.

When This Approach Works

Strong privacy requirements: If your threat model includes gradient reconstruction attacks, granular balls provide provable privacy without differential privacy noise.

Large datasets: Clustering overhead is negligible when local datasets have 10K+ examples. My 20K images per Pi clustered in under 9 minutes.

Network bandwidth available: 410 MB per round is manageable on LAN or decent WAN connections. Probably fine for enterprise networks.

Slightly reduced accuracy acceptable: 2-3% accuracy gap is tolerable for many applications. Medical diagnostics maybe not, spam detection probably yes.

When This Approach Struggles

Small local datasets: With fewer than 5K examples per client, clustering quality degrades. Granular balls become too coarse to preserve useful signal.

Bandwidth-constrained networks: If you're federating over satellite links or cellular connections, 410 MB per round is probably too expensive. Standard federated learning transfers 89 MB per round.

Real-time requirements: 47 minutes per training round is slow. If you need sub-minute model updates (like online learning), this approach won't work without serious optimization.

Perfect accuracy required: If you can't accept any accuracy degradation, use centralized training with proper access controls instead.

Open Questions I Haven't Figured Out

  1. Optimal cluster count: I used 100 clusters arbitrarily. Probably suboptimal. Need to test 50, 200, 500 clusters to find the sweet spot.

  2. Variance threshold tuning: 0.03 worked for CIFAR-10. But what about other datasets? Probably domain-specific. Needs a principled tuning method.

  3. Non-IID data distributions: My dataset split was IID (randomly distributed). Real federated scenarios have non-IID data (each client has different distributions). Granular-ball aggregation might struggle with this.

  4. Adversarial attacks: What happens if a malicious client sends poisoned cluster statistics? I didn't test Byzantine robustness at all.

  5. Scaling beyond 3 clients: How does aggregation time scale with 10, 50, 100 clients? My guess is poorly, but I didn't test it.

Lessons Learned: What Worked and What Didn't

Failures That Taught Me Things

Variance threshold too high (0.1): My first training run shared only 23% of clusters. Accuracy dropped to 82.3%. I spent 6 hours debugging the aggregation logic before realizing the threshold was filtering too aggressively. Lesson: Start with lower thresholds (0.01-0.03) and increase gradually.

Raspberry Pi thermal throttling: During the second round, all 3 Pis hit thermal limits and throttled CPUs to 600 MHz. Training time jumped from 14 minutes to 38 minutes per round. I added heatsinks and case fans. Now they run at 1.8 GHz consistently.

Network congestion during aggregation: I initially ran all 3 Pis on WiFi. Bad idea. Network transfer took 17 minutes instead of 3 minutes due to WiFi contention. Switched to Ethernet, problem solved.

Server aggregation bottleneck: The Dell R940 has 64 cores but the aggregation code is single-threaded. Only one core was pegged at 100% while the other 63 sat idle. I didn't fix this, but parallelizing cluster merging would probably cut aggregation time by 80%.

K-means initialization instability: Using random initialization caused clustering to vary wildly between rounds. Accuracy fluctuated ±5%. Switching to k-means++ initialization stabilized training.

What Actually Worked

Starting with small cluster counts: I began with 50 clusters to validate the pipeline, then scaled to 100. Made debugging much faster than starting with 500 clusters.

Monitoring cluster statistics: I logged cluster size distributions after each round. Caught an issue where 90% of data points were assigned to 5 clusters (k-means converged poorly). Fixed by increasing cluster count.

Separate VLAN for federation traffic: Isolated the federated learning traffic from other homelab services. Prevented network congestion when I was running other experiments simultaneously.

TensorBoard for tracking: Logging training metrics to TensorBoard made it easy to spot when something went wrong (like the 12% accuracy drop from threshold=0.1).

Conclusion

In November 2024, I set out to train an image classifier across 4 devices without sharing raw data. Three weeks and 12 failed training runs later, I have a working privacy-preserving federated learning setup.

Key findings:

  • Granular-ball segmentation cuts network transfers by 82% compared to raw data (2.3GB → 410MB per round)
  • Balanced variance threshold (0.03) achieves 92.1% accuracy, within 2.4% of centralized training
  • Training time per round: 47 minutes (14 min local, 9 min clustering, 3 min network, 21 min aggregation)
  • Privacy guarantees are provably stronger than standard federated learning with differential privacy

I'm still figuring out optimal cluster counts and variance thresholds for different datasets. The 100 clusters and 0.03 threshold worked for CIFAR-10, but probably not universal. Your mileage will vary depending on data distribution and privacy requirements.

The biggest lesson: Privacy-preserving machine learning is all about trade-offs. You can have strong privacy (high variance threshold), good accuracy (low variance threshold), or fast training (fewer clusters), but probably not all three. Pick two.

If you try this, start with threshold=0.03 and 100 clusters. Probably the best balance for most image classification tasks on homelab-scale datasets. Monitor cluster size distributions and adjust based on your accuracy requirements.

The server aggregation bottleneck is fixable with parallelization, but I didn't prioritize it. If you're federating across 10+ clients, you'll probably hit this issue hard. Budget time for optimization.

Further Reading

Primary Research

Federated Learning Frameworks

Privacy-Preserving ML

Kubernetes and Raspberry Pi Resources

Related Homelab Posts

Related Posts