Compute-Aware Selection

Compute-aware selection relies on real-time resource profiling of edge devices. This involves continuously monitoring metrics like:

• CPU/GPU/NPU utilization
• Available RAM
• Thermal headroom
• Battery level An on-device resource monitor agent collects this data, allowing the orchestrator to predict if a device can complete a training task before a deadline or battery drain threshold. Profiling prevents selection of devices that will fail mid-round.

The core mechanism assigns training tasks only to devices predicted to finish within a target latency window. The system estimates Time-To-Train (TTT) for each candidate device using its profile and the current global model complexity. Devices with TTT exceeding the round deadline are excluded. This ensures predictable round completion times and prevents stragglers from bottlenecking the entire federation.

Selection decisions are informed by a federated device registry. This database stores both static capabilities (e.g., chipset, max RAM) and dynamic state from profiling. The orchestrator queries this registry to filter devices by compute tier. This enables stratified client sampling, ensuring a representative mix of device types is selected per round to prevent model bias towards only high-end hardware.

The strategy dynamically adapts to changing conditions. If many high-compute devices become unavailable (e.g., due to user activity), the system can:

• Adjust the target latency window for the round.
• Employ model compression techniques like capability-based pruning to reduce the computational load for selected devices.
• Trigger elastic federated learning protocols to scale down model complexity. This maintains system throughput despite resource fluctuations.

Compute-aware selection is a precursor to resource-aware scheduling. Once capable devices are selected, the scheduler can perform fine-grained optimization:

• Assigning variable-length training rounds or dynamic batching sizes based on each device's exact available margin.
• Implementing per-client learning rate tuning to optimize convergence for the device's compute profile.
• Coordinating with battery-aware and thermal-throttling management policies to preserve device health.

By filtering out incapable devices, compute-aware selection directly improves federated learning convergence and system efficiency.

• Reduces round failure rates and wasted communication.
• Leads to more reliable and higher-quality model updates.
• Lowers the statistical variance in client computation times, making aggregation via algorithms like Federated Averaging more stable.
• It is a foundational technique for heterogeneous federated averaging (HeteroFA) and asynchronous federated updates protocols.

A federated learning system trains a model to detect early signs of respiratory illness from microphone data. Compute-aware selection is critical because participating devices range from older smartphones to latest-generation models.

• The server profiles devices for available CPU cores, RAM, and thermal headroom.
• Only devices with sufficient resources to complete a 5-minute local training round without draining the battery below 20% are selected.
• This prevents low-end devices from timing out or causing user dissatisfaction, ensuring reliable round completion and consistent model updates from capable hardware.

A manufacturer uses federated learning to improve perception models across a global fleet. Vehicles have heterogeneous compute: some have full AI accelerator pods, while others use only embedded GPUs.

• The central server uses a device registry with detailed compute specs (TOPS, VRAM).
• For a complex LiDAR point cloud segmentation task, selection prioritizes vehicles with dedicated NPUs that can process the large model within the vehicle's idle charging window.
• Vehicles with lower-tier compute are selected for smaller, distillation-based tasks. This maximizes useful contributions and respects the real-time safety-critical primary function of each vehicle.

In a factory, sensors on motors and pumps collaborate to predict failures. Device heterogeneity is extreme: gateway-class edge servers coexist with microcontroller-based vibration sensors.

• Compute-aware selection creates two distinct pools. The powerful gateways train full LSTM models on high-frequency sensor streams.
• The microcontrollers, if selected, only perform inference with a tiny, pre-trained model to extract simple statistical features, which are sent as updates.
• This tiered approach ensures the system leverages all available compute appropriately without overloading constrained devices, maintaining overall system stability.

A company improves its next-word prediction model using typing data from phones, tablets, and laptops. The goal is a unified model update without degrading user experience on any device.

• The selection algorithm estimates training time based on device chipset (e.g., Apple M-series vs. mid-range Android SoC) and current foreground app usage.
• Training is scheduled and devices are selected during periods of idle compute, like when the device is plugged in and screen-off.
• Laptops may perform more local epochs than phones. This dynamic workload balancing ensures timely updates while preserving battery life and responsiveness on all platforms.

Satellites in low-earth orbit collaborate to update a model for cloud cover classification. Compute and connectivity are severely constrained; each satellite has a brief, scheduled window to communicate with ground stations.

• Compute-aware selection is fused with availability-aware scheduling. The ground station selects only satellites that will be in range and have finished their onboard training job before the pass.
• Satellites with older, slower processors are given simpler model variants or excluded if their processing time exceeds the pass duration.
• This guarantees that selected clients can deliver an update within the strict communication window, making the federated loop feasible in space.

Multiple hospitals collaborate to train a cancer detection model on private medical imaging data. Each hospital has an on-premise edge server, but their specs vary based on budget and IT refresh cycles.

• Before a training round, the coordinating server queries each hospital's edge server capability profile (GPU type, memory).
• For a memory-intensive 3D convolutional neural network, only servers meeting a minimum GPU memory threshold are selected to avoid out-of-memory errors.
• Hospitals with lesser hardware are assigned to train smaller patch-based classifiers. This stratified selection ensures all can contribute meaningfully without causing hardware failures.

The foundational process of systematically measuring and cataloging the computational resources, memory, network connectivity, and power availability of enrolled edge devices. This creates a dynamic registry used by the orchestrator to make informed selection and scheduling decisions.

• Key Metrics: CPU/GPU type, available RAM, battery level, network bandwidth/latency, storage I/O.
• Implementation: Often uses a lightweight on-device agent that periodically reports telemetry to a federated device registry.

A dynamic orchestration strategy that assigns training tasks based on real-time client resource states, going beyond initial capability profiles. It aims to maximize system throughput while preventing device failure.

• Considers: Current CPU load, memory pressure, thermal state, and active user sessions.
• Goal: Avoids selecting a device that becomes unavailable mid-round due to resource exhaustion, which wastes compute and slows convergence.

A client-side optimization technique where the local batch size for on-device training is automatically adjusted based on current memory and compute capacity. This prevents out-of-memory errors and optimizes hardware utilization.

• Mechanism: A resource monitor on the device may shrink the batch size if memory is constrained or increase it if surplus capacity is detected.
• Benefit: Enables participation from a wider range of devices by adapting the workload to fit within volatile resource envelopes.

A selection method that ensures a representative mix of devices from different capability tiers (e.g., high-end phones, mid-range sensors, low-power MCUs) in each training round. This mitigates bias that would occur if only the most capable devices were ever selected.

• Purpose: Improves model fairness and generalization by ensuring the aggregated update reflects the true, heterogeneous data distribution across all device classes.
• Contrast: Pure compute-aware selection without stratification could lead to a model that performs poorly on data from low-resource devices.

A communication protocol where the server aggregates client model updates as soon as they arrive, without waiting for a synchronized round deadline. This accommodates clients with highly variable training times due to compute heterogeneity.

• Solves the Straggler Problem: Slow devices no longer block the progress of faster ones.
• Trade-off: Introduces algorithmic complexity in aggregation (handling stale updates) but can significantly improve wall-clock training time in heterogeneous environments.

A system design principle that modifies client selection, training intensity, and communication frequency to minimize energy drain. It prioritizes user experience and device longevity, often working in concert with compute-aware logic.

• Policies: May exclude devices below a battery threshold, reduce local computation epochs, or schedule training during charging periods.
• Ethical Consideration: Critical for mobile devices to avoid negatively impacting the primary user, which is essential for long-term participation.