Distributed Learning as a Service: The Developer's Perspective
Authors: Tianyue Chu, Filippo Vannella, Dimitra Tsigkari, Paula Delgado-Santos, Fernando López, Pablo Gomez Guerrero, Sotirios Spantideas, David Solans Noguero
Organizations: Telef´onica Scientific Research, Telef´onica, Madrid, Spain · National and Kapodistrian University of Athens, Psachna, Evia, Greece
Application developers of distributed learning services face challenges that a typical federated learning loop does not address. Specifically, the model updates can still leak private data, devices might not be able to participate in the training due to limited resources, a single aggregator might not be able to scale, and the transmissions of model weights induce a considerable bandwidth cost. This paper demonstrates DLaaS (Distributed Learning as a Service) from the developer's vantage point. Using a single admin dashboard, the developer initiates a distributed/federated learning job and is able to activate Differential Privacy (DP), Split Learning (SL), Hierarchical Aggregation (HA), and Knowledge Distillation (KD) as declarative options, with no change to the clients' code. We demonstrate the complete service lifecycle on an industrial smart-home Wake-up Word (WuW) task, using the "Ok Aura" dataset. Once the developer initiates a distributed learning job by toggling DP, SL, HA, and KD in the admin dashboard, the system dispatches the job to a set of Android clients and Dockerized helper aggregators. In the demonstration, these mechanisms run live across configurations. Then, the clients train the model locally and return their updates. The trained model is served to a consumer-side Android application that performs on-device WuW detection on a live microphone stream. In particular, the conference attendees will be invited to speak the trigger phrase and monitor in real time the per-class confidence and inference latency. Finally, we release the source code and short video walkthroughs of these configurations.
Figures & tables
Fig. 1: DLaaS architecture annotated for the demonstration as a job flows through the system: (1) the developer composes the job at the admin front-end (DP mechanism and its (ε,δ) values, the SL, HA, and KD toggles) and submits the specifications; (2) the server cluster compiles the given specs into a per-round plan and runs the server-side core logic (central DP, SL, KD, model aggregation, and device scheduling), driving the distributed learning round loop; (3) the helper tier performs partial aggregation over client clusters and can host the SL server-side part; and (4) each client device runs local training, local DP, and sends the trained model back to the server.
Fig. 2: (1) Compose — the server-side admin interface (Django admin). (a) the admin home, where projects are created, scheduled, and managed; (b) a project’s training configuration, selecting the model, dataset, and number of FL rounds; and (c) the DP mechanism with its (ε,δ) configuration and the SL, HA, and KD module toggles. The whole job is composed from this one interface.
Fig. 4: (3) Local training — the Android client. Left: the authenticated app on the emulator. Right: the Logcat lines reporting per-epoch training loss and accuracy (timestamp, PID, and tag columns omitted for readability).
Fig. 5: (4) Detect — the consumer app. It downloads the trained global model and reports live on the “Ok Aura” detection task with per-class confidence and inference latency.