Die aktuelle Version von NVIDIA FLARE richtet sich an Szenarien, in denen Daten nicht zentral zusammengeführt werden können oder sollen. Statt Rohdaten zu verschieben, bringt die föderierte Laufzeit die Trainingslogik an die Daten; zwischen den Standorten werden nur Modell-Updates oder vergleichbare Signale ausgetauscht.
Als Gründe nennt NVIDIA regulatorische Vorgaben, Anforderungen an Datensouveränität, organisatorische Risikogrenzen und die praktische Schwierigkeit großer Datentransfers. In solchen Umgebungen müsse eine föderierte Plattform Datenisolation, Compliance und Privacy-Enhancing Technologies als grundlegende Anforderungen behandeln. Genannt werden dabei unter anderem homomorphic encryption, differential privacy und confidential computing.
Nach Darstellung des Beitrags lag die Hürde für viele Teams bisher weniger im Konzept des Federated Learning selbst als in der Entwicklererfahrung. Projekte scheiterten oft nach ersten Pilotphasen entweder am hohen Umbauaufwand für vorhandenen PyTorch-, TensorFlow- oder Lightning-Code oder beim Übergang von der Simulation in Proof-of-Concept und Produktion, wenn Jobs, Konfigurationen und Umgebungen neu definiert werden mussten.
Die Weiterentwicklung der FLARE-API soll diesen Aufwand in zwei Schritten reduzieren. Im ersten Schritt wird ein bestehendes lokales Trainingsskript mit wenigen zusätzlichen Codezeilen zu einem föderierten Client gemacht, ohne die Struktur der Trainingsschleife grundsätzlich zu verändern. Das zugrunde liegende Modell bleibt einfach: Client-Laufzeit initialisieren, während der Job läuft das aktuelle globale Modell empfangen, lokal trainieren und anschließend aktualisierte Gewichte sowie Metriken zurücksenden.
Dafür hebt NVIDIA die zentralen Berührungspunkte flare.init(), flare.receive() und flare.send() hervor. Die Client-API ist auf minimale Änderungen ausgelegt und soll keine schweren Vererbungsstrukturen wie Executor- oder Learner-Hierarchien erzwingen. Die Kommunikation mit der Laufzeit erfolgt über die Struktur FLModel oder einen einfachen Datenaustausch.
Für PyTorch Lightning beschreibt NVIDIA eine angepasste Integration, bei der die gleiche Grundlogik erhalten bleibt: globales Modell empfangen, trainieren, Updates senden. Statt eigener föderierter Messaging-Logik wird dazu der Trainer mit dem Lightning-Client-Adapter gepatcht. Der typische Ablauf besteht aus Import, Patchen des Trainers, optionaler Validierung und anschließendem Training wie gewohnt.
Im zweiten Schritt wird das föderierte Client-Skript als portabler Job ausgeführt. Dafür führt FLARE sogenannte Job Recipes ein, die JSON-basierte Job-Konfigurationen durch Python-basierte Definitionen ersetzen sollen. Diese Recipes referenzieren das im ersten Schritt erzeugte Trainingsskript und koppeln es an einen FL-Workflow wie etwa FedAvgRecipe.
Der Beitrag beschreibt dies als Code-first-Ansatz: Ein Job wird einmal in Python definiert und anschließend in verschiedenen Ausführungsumgebungen genutzt. Als Umgebungen nennt NVIDIA SimEnv für Entwicklung und Debugging, PocEnv für realistischere lokale Multi-Prozess-Tests und ProdEnv für verteilte Produktionsdeployments. Die grundlegende Idee ist, dass beim Übergang durch den Lebenszyklus nur die Ausführungsumgebung ausgetauscht wird, nicht die Code-Struktur des Jobs.
Als Zielgruppe nennt NVIDIA Praktiker, ML-Ingenieure, Data Scientists und angewandte Teams mit vorhandenem Trainingscode, die den Unterschied zwischen lokalem Training und föderierter Ausführung möglichst klein halten wollen. Der empfohlene Ablauf ist entsprechend schrittweise: mit einem bereits erprobten Skript beginnen, die minimale FLARE-Handshake-Logik ergänzen oder den Lightning-Trainer patchen und den Job dann von der Simulation über PoC bis in die Produktion über verschiedene Umgebungen ausführen.
Der Beitrag verweist außerdem auf bestehende Einsätze, darunter Eli Lilly TuneLab, eine nationale Healthcare-Initiative des taiwanischen MOHW sowie einen föderierten KI-Pilotbetrieb der Tri-labs Sandia, LANL und LLNL über sensible Datensätze.
