Föderiertes Lernen in Kliniken: der GPU-Server für jeden Standort und der Aggregator

Was föderiertes Lernen für eine Klinik ändert

Föderiertes Lernen lässt mehrere Kliniken ein Modell trainieren, ohne Patientendaten zu bewegen: Jeder Standort trainiert das aktuelle Modell auf seinen eigenen Daten, schickt das Ergebnis als Update an einen Aggregationsserver und erhält das zusammengeführte Modell für die nächste Runde zurück. Jede teilnehmende Klinik braucht daher einen eigenen GPU-Server, bemessen am lokalen Trainingsjob, während der Aggregator, der die Updates zusammenführt, eine kleine Maschine ist. Für 3D-Bildgebung oder Sprachmodelle würden wir mit einem Standortknoten mit zwei Karten der NVIDIA RTX PRO 6000 Blackwell Server Edition beginnen; für 2D-Bilder, tabellarische Daten und kleinere Netze passen vier Karten der RTX PRO 4500 Server Edition in 2U.

Wir schreiben für die IT-Leitung einer Klinik, die einem Forschungsverbund beitritt, und für das Forschungsteam, das ihn plant. Was eine einzelne Klinik für ihre eigene KI braucht, behandeln unsere Leitfäden zum KI-Server für die medizinische Bildgebung und zum privaten LLM-Server für Krankenhäuser. Diese Seite behandelt das Muster über mehrere Standorte: den Knoten je Standort, das Netz zwischen den Standorten und was die Verordnungen zu Daten sagen, die an ihrem Ort bleiben.

Wie eine föderierte Runde abläuft

NVIDIA FLARE beschreibt sich als „a domain-agnostic, open-source, extensible Python SDK“, das bestehende Abläufe des maschinellen Lernens in einen föderierten Aufbau überführt. Es steht unter Apache 2.0 und unterstützt PyTorch, TensorFlow, scikit-learn und XGBoost. Version 2.9.0 erschien am 4. September 2026 und braucht Python 3.10 oder neuer. Flower, ebenfalls unter Apache 2.0, ist eine frameworkunabhängige Alternative, deren README MONAI unter den unterstützten Bibliotheken nennt.

NVIDIA-FLARE-Dokumentation, Überblick zum realen Einsatz (Main-Branch), sowie README und Release Notes zu 2.9.0 von NVFlare auf GitHub, gelesen am 24. Oktober 2026.

Ein Projekt beginnt mit dem Provisioning. nvflare provision oder das FLARE-Dashboard erzeugt ein Startup-Kit für den Server, für jeden Client und für jede Administratorin und jeden Administrator, und die Kits gelangen über einen sicheren Kanal zu den Teilnehmern. Jedes Kit enthält das Root-Zertifikat sowie das eigene Zertifikat und den Schlüssel des Teilnehmers; die Identität steht im Common Name des Zertifikats, und die FLARE-Dokumentation fordert jeden Standort auf, seinen Client-Schlüssel zu schützen. Der Inhalt der Kits ist signiert, eine geänderte Datei fällt also auf. Die Clients verbinden sich mit dem Server, der sich an den beim Provisioning festgelegten Hostnamen bindet; der Port des Servers muss deshalb jede Firewall auf dem Weg passieren, und der Hostname muss an jedem Standort auflösbar sein. Mit Version 2.9.0 wurde gegenseitiges TLS zum Standard für die internen Verbindungen von FLARE in Docker-, Slurm- und Kubernetes-Umgebungen.

Der Trainingscode bleibt in der Hand der Klinik. FLARE überführt eine Trainingsschleife in PyTorch in einen föderierten Job, Version 2.9.0 kann einen vorhandenen Trainer von Hugging Face oder einen SFTTrainer von TRL über flare.patch(trainer) föderiert ausführen und bringt einen Slurm-Launcher mit; eine Klinik mit eigenem Forschungscluster kann den FL-Client also wie jeden anderen Job einplanen; unser Leitfaden zum GPU-Server für Universität und Labor behandelt die GPU-Planung in Slurm.

Was jeder Standort trainiert und wie viel GPU-Speicher er braucht

Der GPU-Knoten an jedem Standort muss einen lokalen Trainingsjob des gemeinsamen Modells ausführen, und das Modell bestimmt den Speicher. Die Werte unten stammen aus der Modelldokumentation, die unser Leitfaden zur Bildgebung zusammenfasst, und aus unserer Bemessung für das Fine-Tuning.

READMEs des MONAI Model Zoo, wie in unserem Leitfaden zum KI-Server für die medizinische Bildgebung zitiert (gelesen am 10. Oktober 2026); 70B mit QLoRA aus unserer Bemessung für das Fine-Tuning, berechnet aus der angegebenen Kartenkapazität. Die Kartenspalte ist unsere Lesart.

Auch Sprachmodelle lassen sich föderiert trainieren. Die Release Notes von FLARE 2.9.0 nennen Federated Averaging als validiert „up to a 72-billion-parameter model“. Ein Standort, der ein 70B-Modell per QLoRA-Fine-Tuning anpasst, braucht auf der Karte etwa 42,8 GB, was auf einer RTX PRO 6000 mit 96 GB 53 GB für Batch und Sequenzlänge lässt; unser Leitfaden zum GPU-Speicher für LoRA- und QLoRA-Fine-Tuning behandelt die Rechnung. Auch der Arbeitsspeicher zählt: MONAIs Ganzkörper-Bundle meldet 83 GB Arbeitsspeicher auf einer GPU für ein CacheDataset mit 1.000 Volumen bei einer Cache-Rate von 0,4; ein Standortknoten braucht also RAM für den Daten-Cache zusätzlich zu NVIDIAs Regel des doppelten GPU-Speichers.

Standortkonfigurationen nach Kartenzahl

Die Standorte können unterschiedliche Knoten betreiben, aber jeder muss denselben Trainingsjob ausführen. Beim Federated Averaging führt eine Runde die Updates aller Standorte zusammen, der langsamste Knoten bestimmt also das Tempo der Runde, und ein Verbund tut gut daran, einen Mindestknoten zu vereinbaren.

Referenz­konfigurationen auf unserer Seite zu KI-Servern und NVIDIAs Leitfaden für zertifizierte Systeme (Arbeitsspeicher doppelt so groß wie der GPU-Speicher); vier RTX PRO 4500 Server Edition aus unserem Kaufleitfaden für diesen Server; Leistung nach unserer Schätzung (Karten, Prozessoren und 15 Prozent für den Rest des Servers). Die FLARE-Seiten, die wir gelesen haben (README, Release Notes, Überblick zum realen Einsatz), nennen keine Hardware-Anforderung für den Server.

Vier RTX PRO 4500 Server Edition. Vier passive Single-Slot-Karten mit je 32 GB passen in einen 2U-Server und an einen Anschluss mit 230 V und 16 A, der bei 80 Prozent 2,94 kW trägt. Jede Karte lässt sich außerdem in zwei MIG-Instanzen mit 16 GB teilen, sodass sich FL-Job und ein lokaler Inferenzdienst den Server mit isoliertem Speicher teilen können. Das passt zu einem Standort, der in einem Verbund 2D-Modelle oder Klassifikatoren trainiert.

Zwei RTX PRO 6000 Server Edition. Der Einstiegsserver von unserer Seite zu KI-Servern mit zwei AMD-EPYC-Prozessoren, 384 GB DDR5-ECC und zwei NVMe-Laufwerken hält das Training einer 3D-Segmentierung auf einer Karte und lässt die zweite Karte für die eigene Arbeit der Klinik frei, oder er trainiert auf beiden. Diesen Knoten würden wir als Mindestknoten des Verbunds für Bildgebung und Sprachmodelle vorschlagen.

Vier RTX PRO 6000 Server Edition. Der Inferenzknoten mit 768 GB passt zum koordinierenden Standort, der den Trainingsjob auch entwickelt, ihn vor jeder Kampagne auf eigenen Daten testet und den FL-Server in einer getrennten VM betreiben kann.

Die RTX PRO 6000 Max-Q ist die Workstation-Karte, eine Radiallüfter-Karte mit 300 W; ins Rack gehört sie nur in ein Gehäuse, für das der Hersteller sie listet, und für den Dauerbetrieb empfehlen wir die Server Edition.

Wir bauen für jeden Standort eines Verbunds denselben Knoten und liefern ihn an jede Klinik in der EU mit einem Vertrag; schicken Sie uns die Zahl der Standorte, das Modell und die Daten je Standort, und unser Team antwortet mit einer Konfiguration.

Das Netz zwischen den Standorten

Nur Modell-Updates verlassen die Klinik, aber sie sind nicht klein. Ein vollständiges Update hat einen Wert je Parameter: Das Pathologie-Modell H-optimus-0 mit 1,1 Mrd. Parametern kommt als Datei von 4,54 GB, die über 1 Gbit/s etwa 36 Sekunden je Richtung braucht und über 10 Gbit/s etwa 3,6 Sekunden, nach unserer Rechnung. Eine Kampagne mit 100 Runden bewegt für ein solches Modell etwa 0,9 TB je Standort. Ein Segmentierungsnetz mit 100 Millionen Parametern schickt in FP32 etwa 400 MB je Update, etwa 3 Sekunden bei 1 Gbit/s. Ein Job, der nur LoRA-Adapter trainiert, muss nur die Adaptergewichte austauschen, einen kleinen Bruchteil des Modells.

In der FLARE-Dokumentation verbinden sich die Clients mit dem Server, und es ist der Port des Servers, den keine Firewall blockieren darf; planen Sie die Regeln auf dieser Grundlage und bestätigen Sie sie in einem Testlauf vor der ersten Kampagne. Vereinbaren Sie Hostnamen, Zertifizierungsstelle und Firewall-Regeln vor dem Provisioning, denn die Startup-Kits tragen sie. Der FL-Client sitzt in einer Netzzone für die Forschung, mit Lesezugriff auf die vorbereiteten Trainingsdaten und darüber hinaus ohne Zugriff auf klinische Systeme; unser Leitfaden zur Netzwerk­segmentierung beschreibt die Zonen.

Was die Modell-Updates verraten können

Ein Update wird aus Patientendaten berechnet und trägt daher Information über diese Daten. FLARE nennt „differential privacy, homomorphic encryption, private set intersection (PSI)“ unter dem Schutz der Privatsphäre und ergänzt eine föderierte Autorisierung und eine Datenschutzrichtlinie, die jeder Standort für seinen eigenen Client durchsetzt. Welche davon ein Verbund nutzt, gehört in sein Protokoll und in seine Datenschutz-Folgenabschätzung. Für Sprachmodelle warnt das Reflexionspapier der EMA zu KI, dass „Large language models, often containing billions of parameters, are at particular risk of memorisation due to their size“; das ist wichtig, wenn ein Verbund ein solches Modell per Fine-Tuning an klinische Texte anpasst. Das fertige Modell ist ein Ergebnis, das geprüft wird, bevor es den Verbund verlässt.

EHDS, DSGVO und die Rolle der Klinik

Die Verordnung über den Europäischen Gesundheitsdatenraum, Verordnung (EU) 2025/327 vom 11. Februar 2025, ist am 26. März 2025 in Kraft getreten. Die EHDS-Seite der Kommission nennt den Zeitplan: Die Regeln zur Sekundärnutzung gelten für die meisten Datenkategorien, etwa Daten aus elektronischen Patientenakten, ab März 2029 und für die übrigen Kategorien, etwa genomische Daten, ab März 2031. Die Sekundärnutzung beruht auf einer Genehmigung einer Zugangsstelle für Gesundheitsdaten („based on a permit issued by a health data access body“), die Verarbeitung findet nur in sicheren Verarbeitungsumgebungen statt, und „No personal data can be downloaded from these environments“. Erwägungs­grund 77 hält fest, dass jeder Zugang zur Sekundärnutzung über eine sichere Verarbeitungsumgebung erfolgen soll, und Erwägungs­grund 80, dass der Grundsatz, Fragen zu den Daten zu bringen, statt die Daten zu bewegen, „should be respected whenever possible“.

Föderiertes Lernen hält die Daten am Standort; das ist der Ansatz, den Erwägungs­grund 80 beschreibt. Ob ein bestimmter föderierter Aufbau oder die Teilnahme einer Klinik daran die Regeln der Verordnung zu Genehmigungen und sicheren Verarbeitungsumgebungen erfüllt, beantworten die Passagen, die wir gelesen haben, nicht; es hängt von den Daten, dem Zweck und der nationalen Durchführung ab. Gesundheitsdaten bleiben eine besondere Kategorie nach Artikel 9 Absatz 1 der DSGVO, und die umfangreiche Verarbeitung solcher Daten gehört nach Artikel 35 Absatz 3 Buchstabe b zu den Fällen, die eine Datenschutz-Folgenabschätzung verlangen; unser Leitfaden zur Datenschutz-Folgenabschätzung für ein internes LLM listet die technischen Angaben. Rechtsgrundlage und Verbundvertrag sind Sache der Datenschutz­beauftragten und der Rechtsberatung jeder Klinik. Allgemeine Informationen zum EU-Recht mit Stand Oktober 2026; nationale Regeln und Umsetzung können abweichen.

Hinweise für das IT-Team

1. Software. FLARE 2.9.0 braucht Python 3.10 oder neuer und läuft in Docker, als Slurm-Job oder auf Kubernetes. Legen Sie die FLARE-Version für eine Kampagne an allen Standorten gleich fest, denn jeder Client führt denselben Job aus.
2. Schlüssel. Das Startup-Kit enthält den privaten Schlüssel des Standorts. Bewahren Sie ihn wie andere Zugangsdaten von Diensten auf und beschränken Sie, wer den Client starten darf.
3. GPU-Teilung. Betreibt der Knoten auch lokale Inferenz, legen Sie den FL-Job auf eine eigene Karte oder MIG-Instanz, wie unser Leitfaden zur GPU-Teilung auf Kubernetes mit MIG erklärt, damit eine Trainingsrunde die klinische Arbeit nicht bremst.
4. Datenpfad. Der Client liest einen vorbereiteten, pseudonymisierten Trainingsdatensatz von lokalem NVMe oder vom Forschungsspeicher, nie direkt aus den Produktivsystemen.
5. Software bei Lieferung. Auf Wunsch kommt der Server mit Betriebssystem, NVIDIA-Treiber, CUDA und Container-Runtime. Der BMC gehört ins Management-Netz, wie unser Leitfaden zur Absicherung eines GPU-Servers beschreibt.

Unser Private-AI/ML-Service richtet mit unserem Engineering-Partner Vixen.UNO FL-Client, Container und Protokollierung auf diesen Knoten ein; nennen Sie uns das Framework, das der Verbund nutzt, und wir bereiten den Knoten passend vor.

Was wir liefern

Sie können dieses System bei uns kaufen: Unser Team dimensioniert die Konfiguration nach Ihrer Last und Ihrem Budget und antwortet innerhalb eines Werktages. Wir bauen GPU-Server auf Bestellung mit Karten der RTX PRO 4500 Server Edition oder der RTX PRO 6000 Server Edition, vor der Lieferung montiert und getestet, geliefert an jeden Standort in der gesamten EU mit einem EU-Vertrag und einer Rechnung, mit Herstellergarantie auf jede Komponente, abgewickelt über uns; Stückzahlen und Lieferzeit werden mit dem Angebot schriftlich bestätigt. Unser Service Private AI/ML richtet die Software darauf ein. Verbundvertrag, Datenschutz-Folgenabschätzung und regulatorische Bewertung bleiben bei den teilnehmenden Kliniken.

FAQ