Federated Learning für militärische KI, ohne Daten zu zentralisieren

Das zentrale Paradoxon des militärischen KI-Trainings ist, dass die Daten, die die Einsatzleistung eines Modells am stärksten verbessern würden, genau die Daten sind, die nicht bewegt werden können. Klassifizierte Sensorprotokolle, ISR-Bilder aus aktiven Einsatzgebieten, elektronische Order-of-Battle-Aufzeichnungen und Datensätze verbündeter Partner existieren hinter Compartment-Grenzen, die konventionelles zentralisiertes Training unmöglich machen. Federated Learning löst dieses Paradoxon durch Umkehrung des Trainingsparadigmas: Statt Daten zum Modell zu bewegen, geht das Modell zu den Daten. Jede teilnehmende Organisation trainiert lokal auf ihrem eigenen klassifizierten Korpus und teilt nur Gradienten-Updates — mathematische Ableitungen, die das globale Modell verbessern, ohne die zugrunde liegenden Trainingsbeispiele offenzulegen. Dieser Artikel untersucht den gesamten Engineering-Stack für die Bereitstellung von Federated Learning in Verteidigungsumgebungen, von der Auswahl der Föderationstopologie über die Kalibrierung der Differential Privacy, sichere Aggregation, asynchronen taktischen Betrieb bis zur byzantinisch-robusten Bedrohungsabmilderung.

Warum Federated Learning für die Verteidigung — Datensouveränität über Kommandos hinweg, die Klassifizierungsbarriere und Edge-Modellaktualität

Militärische KI-Trainingsdaten sind durch Design, nicht durch Zufall, über Organisationssilos verteilt. Klassifizierungspolitik, rechtliche Befugnisse und operationelle Sicherheitsanforderungen schaffen harte Grenzen zwischen datenbesitzenden Organisationen. Die ISR-Bilder eines Special Operations Command können nicht an die Trainingsinfrastruktur einer konventionellen Streitkraft übertragen werden, ohne Compartment-Zugriffskontrollen zu durchlaufen, deren Auflösung Monate dauern kann — wenn eine Auflösung überhaupt möglich ist. Ein verbündeter Partnerstaat, der Sensordaten zu einem Koalitionsmodell beiträgt, darf diese Daten nach nationalem Sicherheitsrecht nicht außerhalb seiner souveränen Infrastruktur übertragen, unabhängig davon, welche Vertragsrahmen zwischen den Staaten bestehen.

Die Klassifizierungsbarriere ist das akuteste Problem. Zentralisiertes Training auf Daten mehrerer Klassifizierungsstufen erfordert, die Trainingsinfrastruktur auf die höchste Sensitivitätsstufe eines beitragenden Datensatzes zu heben. Ein für Top Secret/SCI-Daten zugelassener Trainingscluster kostet Aufbau, Personal und Akkreditierung eine Größenordnung mehr als eine Secret-Einrichtung und schränkt den Pool der Ingenieure und Datenwissenschaftler, die damit arbeiten können, auf einen Bruchteil der Belegschaft ein. In der Praxis entscheiden sich die meisten Verteidigungs-KI-Programme, auf den verfügbaren am wenigsten sensiblen Daten zu trainieren, statt eine Einrichtung höherer Stufe zu akkreditieren — was bedeutet, dass dem Modell die operationell relevantesten Trainingsbeispiele vorenthalten werden. Federated Learning beseitigt diesen Kompromiss, indem jedes Silo zum globalen Modell auf seiner eigenen Klassifizierungsstufe beitragen kann. Die Gradienten-Updates, die jedes Silo verlassen, tragen keine Klassifizierungskennzeichnung, die ihren Quelldaten entspricht — sie sind mathematische Artefakte des Trainingsprozesses, keine Datensätze.

Die Edge-Modellaktualität ist die dritte Motivation. Eine Herausforderung bei edge AI inference military systems ist, dass das vor Monaten auf eine taktische Plattform bereitgestellte Modell auf einem Schnappschuss der Welt trainiert wurde, die nicht mehr zur aktuellen Einsatzumgebung passt. Ziel-Fahrzeugsets entwickeln sich weiter, neue Radarwellenformen werden eingeführt, und gegnerische Tarnungstechniken passen sich an, um bekannte Erkennungsmuster zu durchbrechen. Federated Learning ermöglicht kontinuierliche Modellverbesserung aus Daten, die auf bereitgestellten Plattformen und an vorgeschobenen Einsatzbasen gesammelt werden, und speist Verbesserungen zurück ins globale Modell, ohne dass Plattformen Roh-Einsatzdaten die Kette hinaufsenden müssen — eine Bandbreiten- und Sicherheitsbeschränkung, die Rohdaten-Exfiltration von taktischen Plattformen unpraktisch macht. Das Modell verbessert sich aus dem Feld, während die Daten im Feld bleiben.

FL-Architekturen für die Verteidigung: Cross-Silo vs. Cross-Device — Föderation auf Kommando- und Plattformebene

Federated Learning in Verteidigungsdeployments teilt sich in zwei grundverschiedene Architekturmuster, von denen jedes zu einer eigenen Schicht der militärischen Organisationshierarchie passt. Das Verständnis des Unterschieds ist Voraussetzung für die Wahl des richtigen Rahmenwerks, der Aggregationsstrategie und der Sicherheitsarchitektur.

Cross-Silo-Föderation verbindet eine kleine Anzahl großer, institutionell stabiler Teilnehmer — typischerweise 5–50 —, die jeweils erhebliche klassifizierte Datensätze halten. In einem Verteidigungskontext sind Cross-Silo-Teilnehmer militärische Kommandos, Nachrichtendienste, Partnerstaaten oder Plattformprogrammbüros. Jedes Silo hat eine dedizierte Recheninfrastruktur, die eine vollständige Modelltrainingsschleife ausführen kann, eine dauerhafte Netzwerkverbindung zum Aggregationsserver (mit geplanten Wartungsfenstern für Trennungen) und institutionelle Autorität über seine Daten. Cross-Silo-Föderation toleriert höhere Kommunikationskosten pro Runde, weil die Teilnehmer gut ausgestattet sind, und profitiert vom statistischen Reichtum jedes großen lokalen Datensatzes. Die primären Engineering-Herausforderungen sind heterogene Datenverteilungen über Organisationen hinweg, rechtliche und politische Rahmenwerke für die Teilnahme sowie die Authentifizierungs- und Autorisierungsinfrastruktur, die sicherstellt, dass nur autorisierte Silos zum globalen Modell beitragen können.

Cross-Device-Föderation verbindet eine große Anzahl ressourcenbeschränkter, episodisch verfügbarer Teilnehmer — potenziell Tausende einzelner Soldatenhandys, Sensorknoten, UAV-Bodenstationen oder Fahrzeug-Rechenmodule. Jedes Gerät hält nur eine kleine Menge lokal erzeugter Daten, hat unterbrochene Netzwerkkonnektivität und kann unvorhersehbar in die Föderation ein- und austreten. Cross-Device-FL erfordert asynchrone Aggregation, aggressive Gradientenkompression zur Minimierung der Kommunikationsbandbreite und statistische Methoden, die aus sehr kleinen, hochgradig non-IID (nicht unabhängig und identisch verteilten) lokalen Datensätzen ein nützliches Signal extrahieren können. Es ist die geeignete Architektur für taktische Mesh-Netzwerk-KI, bei der das Ziel ist, ein geteiltes Modell aus der kollektiven Erfahrung eines verteilten Sensornetzwerks zu aktualisieren, ohne dass ein einzelner Knoten je genug Daten anhäuft, um selbst aussagekräftig zu trainieren.

Die meisten institutionellen Verteidigungs-KI-Programme — solche auf Kommando-, Domänen- oder Program-of-Record-Ebene — nutzen Cross-Silo-Architektur mit 10–30 gut identifizierten Teilnehmern. Cross-Device-Architektur gilt vor allem für experimentelle taktische KI-Programme, bei denen einzelne Plattformen die Trainingsteilnehmer sind. Beide lassen sich hierarchisch kombinieren: Cross-Device-Föderation auf taktischer Netzwerkebene aggregiert zu einem Cross-Silo-Teilnehmer auf der Ebene des operativen Kommandos, das wiederum an einer strategischen Cross-Silo-Föderation teilnimmt. Diese hierarchische Struktur erlaubt es, dass Daten einzelner taktischer Sensoren das globale Modell letztlich beeinflussen, ohne dass Roh-Sensordaten mehr als einen Netzwerkhopp durchqueren.

Differential Privacy für militärische Trainingsdaten — DP-SGD-Rauschkalibrierung, Epsilon-Auswahl für Verteidigungsanwendungsfälle, Nutzen- vs. Privatsphäre-Abwägung

Gradienten-Updates sind, auch wenn sie keine Rohdaten sind, nicht perfekt undurchsichtig. Forschung hat gezeigt, dass Gradient-Inversion-Angriffe aus Gradienten-Updates einzelne Trainingsbeispiele mit überraschender Treue rekonstruieren können, insbesondere bei kleinen lokalen Batch-Größen und flachen Modellarchitekturen. In einem Verteidigungskontext könnte selbst eine teilweise Rekonstruktion von Trainingsdaten aus einem abgefangenen Gradienten Nachrichtenquellen kompromittieren, Sensorsammelmuster offenlegen oder Plattformfähigkeiten preisgeben. Differential Privacy (DP) liefert einen mathematisch rigorosen Mechanismus, um diese Preisgabe zu begrenzen.

DP-SGD (Differentially Private Stochastic Gradient Descent) wendet zwei Operationen auf jeden Gradienten an, bevor er das Trainingssilo verlässt. Erstens begrenzt Gradienten-Clipping pro Stichprobe die Sensitivität des Trainingssignals: Die L2-Norm des Gradienten jeder einzelnen Stichprobe wird auf einen Maximalwert C geclippt, sodass ein einzelnes Trainingsbeispiel das Gradienten-Update nicht dominieren kann. Zweitens wird der geclippten Gradientensumme kalibriertes Gaußsches Rauschen mit einer Standardabweichung proportional zu C / sigma hinzugefügt. Das Verhältnis C / sigma ist der Rauschmultiplikator; größere sigma-Werte fügen mehr Rauschen hinzu und liefern stärkere Privatsphäre auf Kosten stärker degradierter Gradientensignale.

Die formelle Privatsphäregarantie wird als Epsilon (das Privacy Budget) und Delta (eine vernachlässigbare Ausfallwahrscheinlichkeit) ausgedrückt. Nach R Trainingsrunden, jede mit einer lokalen Batch-Größe B aus insgesamt N Trainingsstichproben, wächst das kumulierte Epsilon ungefähr als Epsilon ≈ (q * sigma_inv * sqrt(2 * R * log(1/delta))), wobei q = B/N die Stichprobenrate ist. In der Praxis erfolgt das Tracking mit dem Moments Accountant oder Renyi Differential Privacy Accounting, das engere Grenzen liefert als das Basiskompositionstheorem.

# DP-SGD with Opacus (PyTorch) — defense FL configuration
import torch
from opacus import PrivacyEngine
from opacus.accountants import RDPAccountant

model = MyDetectionModel()
optimizer = torch.optim.SGD(model.parameters(), lr=0.01)

privacy_engine = PrivacyEngine(accountant="rdp")

model, optimizer, train_loader = privacy_engine.make_private_with_epsilon(
    module=model,
    optimizer=optimizer,
    data_loader=train_loader,
    epochs=local_epochs,
    target_epsilon=3.0,       # authorized privacy budget for SECRET data
    target_delta=1e-5,        # negligible failure probability
    max_grad_norm=1.0,        # clipping norm C (set to median gradient norm)
)

# Train local epochs
for epoch in range(local_epochs):
    for batch in train_loader:
        optimizer.zero_grad()
        loss = criterion(model(batch["inputs"]), batch["labels"])
        loss.backward()
        optimizer.step()  # gradient clipping + noise injection happens here

# Check remaining budget before transmission
epsilon_consumed = privacy_engine.get_epsilon(delta=1e-5)
assert epsilon_consumed <= AUTHORIZED_EPSILON_CEILING, "Privacy budget exceeded"

Die Epsilon-Auswahl für Verteidigungsanwendungsfälle hängt von der Klassifizierungsstufe der Trainingsdaten und dem Gegnermodell ab. Eine nützliche Heuristik für Verteidigungsprogramme ist, Epsilon nach Klassifizierung zu staffeln: Unklassifizierte Trainingsdaten vertragen Epsilon 8–12 bei minimalem Genauigkeitseinfluss; Secret-Daten rechtfertigen Epsilon 2–5 bei erheblichen Genauigkeitskosten, aber starker mathematischer Garantie; Top-Secret- oder Compartment-Daten können Epsilon nahe 1 erfordern, bei signifikanter Genauigkeitsdegradation, die gegen die Privatsphäreanforderung abgewogen werden muss. Die Genauigkeitskosten starker DP sind real — ein mit Epsilon = 1 trainiertes Detektionsmodell kann 3–6 mAP gegenüber einer nicht privaten Baseline verlieren — und Programmbüros müssen diese Abwägung formal akzeptieren, statt sie implizit durch Softwareentscheidungen eines Ingenieurs treffen zu lassen.

Modellaggregationsstrategien — FedAvg, FedProx für heterogene Datenverteilungen, gewichtete Aggregation nach Datenqualität und -menge

FedAvg (Federated Averaging), der kanonische FL-Aggregationsalgorithmus, berechnet das globale Modell-Update als einfaches Mittel der Teilnehmer-Gradienten-Updates über eine Runde. Er ist einfach, kommunikationseffizient und gut verstanden. Er ist auch brüchig, wenn die Datenverteilungen der Teilnehmer hochgradig heterogen sind — die Situation, die in militärischen Cross-Silo-Deployments die Regel und nicht die Ausnahme ist, wo die Trainingsdaten jedes Organisationssilos seinen spezifischen Einsatzkontext, seine Sensorplattform und sein geografisches Einsatzgebiet widerspiegeln.

Das Heterogenitätsproblem zeigt sich als Client-Drift: Das lokal optimierte Modell jedes Teilnehmers driftet in eine Richtung, die von seiner lokalen Datenverteilung bestimmt ist, und das Mittel mehrerer abgedrifteter Modelle kann schlechter sein als das lokale Modell jedes einzelnen Teilnehmers. Ein Kommando, das ausschließlich in einem arktischen Einsatzgebiet operiert, trainiert sein lokales Modell auf die Erkennung schneebedeckter Fahrzeuge; ein Kommando in einer Wüste spezialisiert sich auf sandfarbene Zielmarken. Das Mittel beider erzeugt ein Modell, das hinter beiden zurückbleibt. FedProx adressiert den Client-Drift, indem es jedem lokalen Zielsystem eines Teilnehmers einen proximalen Regularisierungsterm hinzufügt:

# FedProx local objective — adds proximal term to standard loss
# w_global = global model weights from last aggregation round
# w_local  = local model weights being updated
# mu       = proximal regularization strength (0.01 – 0.1)

def fedprox_loss(predictions, targets, w_local, w_global, mu=0.05):
    task_loss = criterion(predictions, targets)
    proximal_term = (mu / 2) * sum(
        torch.norm(w_l - w_g) ** 2
        for w_l, w_g in zip(w_local.parameters(), w_global.parameters())
    )
    return task_loss + proximal_term

Der proximale Term bestraft lokale Modellabweichung vom globalen Startpunkt und verhindert, dass ein einzelner Teilnehmer das Aggregat-Update zu weit in Richtung seiner lokalen Datenverteilung zieht. Der Hyperparameter mu steuert die Abwägung: mu = 0 stellt Standard-FedAvg wieder her (keine Regularisierung); mu = 1.0 verhindert, dass lokale Optimierung das globale Modell verbessert (zu viel Regularisierung). Werte im Bereich 0.01–0.1 sind typisch für Verteidigungs-Cross-Silo-Deployments. Das Tuning von mu erfordert die Überwachung der Genauigkeit des globalen Modells auf einem zurückgehaltenen zentralen Evaluierungsdatensatz über die Trainingsrunden hinweg — oszilliert die Genauigkeit oder konvergiert sie nicht, erhöhen Sie mu; ist die Konvergenz zu langsam, senken Sie es.

Gewichtete Aggregation nach Datenmenge ersetzt gleichgewichtetes Mittel durch stichprobenanzahlproportionale Aggregation. Ein Kommando mit 500.000 beschrifteten Beispielen sollte mehr zum globalen Update beitragen als ein vorgeschobener Einsatzstützpunkt mit 800 Beispielen. Stichprobenanzahl-Gewichtung ist unkompliziert: Jeder Teilnehmer meldet seine lokale Stichprobenzahl (diese Zahlen-Metadaten legen keine Dateninhalte offen), und der Server berechnet das Gewicht jedes Teilnehmers als seine Zahl geteilt durch die Gesamtzahl aller teilnehmenden Silos in der Runde.

Gewichtete Aggregation nach Datenqualität ist komplexer. Qualitätsproxys, die ohne Zugriff auf Rohdaten berechenbar sind, umfassen die lokale Modellvalidierungsgenauigkeit (falls ein zurückgehaltener lokaler Validierungsdatensatz verfügbar ist), die Gradientennorm (extrem große oder kleine Gradientennormen können Datenqualitätsprobleme anzeigen) und die Modellübereinstimmung (ob das lokale Update in eine ähnliche Richtung zeigt wie das Aggregat der anderen Teilnehmer). Verteidigungsprogramme mit heterogener Sensorqualität — die hochauflösende elektrooptische Bilder strategischer ISR-Mittel mit niedrig aufgelösten Bodenfahrzeugkameras mischen — sollten qualitätsgewichtete Aggregation implementieren, um zu verhindern, dass Datenquellen niedriger Qualität die Leistung des globalen Modells bei den folgenreichen Detektionsaufgaben verschlechtern, die von den höherwertigen Daten abhängen.

Sichere Aggregationsprotokolle — kryptografische Aggregation (SecAgg), Trusted Execution Environment für den Aggregationsserver, Gradientenverschlüsselung

Der Aggregationsserver ist der einzige Punkt in der FL-Architektur, der Gradienten-Updates aller Teilnehmer verarbeiten muss. Auch wenn einzelne Teilnehmer nicht auf die Gradienten anderer zugreifen können, können der Betreiber des Aggregationsservers — und jeder Gegner, der den Server kompromittiert — alle einzelnen Gradienten-Uploads beobachten. In einem Verteidigungs-FL-Deployment, in dem die Teilnehmer verschiedene Organisationen oder Nationen sind, schafft diese zentralisierte Sichtbarkeit ein Aufklärungssammelrisiko: Ein anspruchsvoller Gegner, der den Aggregationsserver kontrolliert oder durchdrungen hat, kann versuchen, Gradientenrekonstruktionsangriffe gegen die Trainingsdaten einzelner Teilnehmer durchzuführen.

Sichere Aggregation (SecAgg) beseitigt diese Preisgabe, indem sie dem Server erlaubt, das Aggregat der Teilnehmergradienten zu berechnen, ohne je den Gradienten eines einzelnen Teilnehmers im Klartext zu sehen. Das Protokoll verwendet paarweises Secret Sharing zwischen den Teilnehmern:

• In der Setup-Phase etabliert jedes Teilnehmerpaar über einen authentifizierten Kanal ein gemeinsames Geheimnis mittels Diffie-Hellman-Schlüsselaustausch. Der Aggregationsserver erleichtert die Schlüsselverteilung, erfährt aber die paarweisen Geheimnisse nicht.
• Vor dem Hochladen seines Gradienten erzeugt jeder Teilnehmer für jeden seiner Partner einen pseudorandom Maskierungsvektor (abgeleitet aus dem paarweisen Geheimnis) und addiert alle diese Masken zu seinem Gradienten. Die Maske für das Teilnehmerpaar (i, j) wird von Teilnehmer i mit positivem und von Teilnehmer j mit negativem Vorzeichen addiert.
• Werden alle maskierten Gradienten am Server summiert, fallen die Masken paarweise aus, sodass nur die wahre Summe der unmaskierten Gradienten bleibt. Der Server hat das Aggregat korrekt berechnet, ohne je den Klartext-Gradienten eines einzelnen Teilnehmers gesehen zu haben.
• Teilnehmerabbrüche werden über ein Secret-Sharing-Schema für die Maskierungsschlüssel behandelt: Fällt ein Teilnehmer vor dem Einreichen aus, kann eine Schwelle anderer Teilnehmer die Maske dieses Teilnehmers rekonstruieren und aus dem Aggregat entfernen.

Die Trusted Execution Environment (TEE) des Aggregationsservers liefert eine ergänzende Schutzebene. Eine TEE — implementiert über Intel TDX, AMD SEV-SNP oder ARM TrustZone — schafft einen hardwareisolierten Ausführungskontext, in dem Code und Daten selbst vor Betriebssystem und Hypervisor der Infrastruktur verschlüsselt und geschützt sind. Läuft der Aggregationsserver in einer TEE, kann der Serverbetreiber das aggregierte Gradient nicht im Klartext einsehen, ohne die Attestierungsgarantien der TEE zu brechen. Remote Attestierung erlaubt es Teilnehmern, kryptografisch zu verifizieren, dass der Aggregationsserver den autorisierten Aggregationscode in einer echten TEE ausführt, bevor sie Gradienten-Updates einreichen. Das adressiert die Insider-Bedrohung auf der Ebene des Infrastrukturbetreibers — ein Cloud-Administrator oder staatlicher IT-Auftragnehmer, der die Infrastruktur des Aggregationsservers betreibt, kann privilegierten Zugriff nicht nutzen, um Gradientenverkehr abzufangen.

Für computer vision defense systems, die an einem Cross-Silo-FL-Programm teilnehmen, muss der vollständige Datenpfad — vom lokalen Trainingsergebnis über Maskierung, über einen verschlüsselten Transport, durch TEE-basierte Aggregation und zurück zum Teilnehmer als aktualisiertes globales Modell — als Teil des Sicherheitsautorisierungspakets des Programms dokumentiert und akkreditiert werden. Jedes Glied der Kette erfordert seine eigene Sicherheitskontrollbewertung.

FL in nicht verbundenen und unterbrochenen taktischen Umgebungen — asynchrones FL mit verzögerten Gradienten, Satellitenverbindungsplanung, Modellversionierung für veraltete Gradienten

Das ideale FL-Protokoll nimmt an, dass alle Teilnehmer zu Beginn jeder Trainingsrunde gleichzeitig erreichbar sind und für die Dauer der Runde erreichbar bleiben. Taktische militärische Umgebungen verletzen diese Annahme systematisch. Satellitenverbundene Außenposten haben möglicherweise nur 20-Minuten-Konnektivitätsfenster alle 12 Stunden. Abgesessene Einheiten in Gelände mit verweigerter Kommunikation können tagelang offline sein. Fahrzeuggebundene Teilnehmer können je nach Geländemaskierung, Funkfrequenzstörung durch gegnerische Störmaßnahmen oder Emissionskontrollverfahren (EMCON), die Senden verbieten, unterbrochene Konnektivität haben.

Asynchrones Federated Learning entkoppelt die Teilnehmerverfügbarkeit vom Aggregationszeitpunkt. Statt alle Teilnehmergradienten vor der Berechnung einer Runde zu sammeln, führt der Aggregationsserver einen Gradientenpuffer und wendet Updates beim Eintreffen an. Das globale Modell schreitet fortlaufend voran und nimmt den Beitrag jedes Teilnehmers zu dessen Ankunftszeit auf. Die Engineering-Herausforderung ist Gradientenveraltung: Ein Teilnehmer, der sein lokales Modell auf globaler Modellversion T trainiert hat und seinen Gradienten zum Zeitpunkt T+5 einreicht, trägt einen Gradienten bei, der relativ zu einem Modell berechnet wurde, das nun fünf globale Schritte veraltet ist. Das naive Aggregieren veralteter Gradienten kann die Konvergenz verlangsamen oder im Extremfall destabilisieren.

# Staleness-weighted asynchronous aggregation (server side)
# Each gradient submission includes the round number it was computed from

def async_aggregate(gradient_buffer, current_round, max_staleness=10):
    """
    Aggregate gradient updates from the buffer, applying staleness weighting.
    Discard updates older than max_staleness rounds.
    """
    valid_updates = [
        (g, w, r) for g, w, r in gradient_buffer
        if (current_round - r) <= max_staleness
    ]

    total_weighted_grad = None
    total_weight = 0.0

    for grad, sample_weight, submission_round in valid_updates:
        staleness = current_round - submission_round
        # Exponential staleness decay: weight halves every 3 rounds
        staleness_factor = 0.5 ** (staleness / 3.0)
        effective_weight = sample_weight * staleness_factor

        scaled_grad = {k: v * effective_weight for k, v in grad.items()}
        if total_weighted_grad is None:
            total_weighted_grad = scaled_grad
        else:
            for k in total_weighted_grad:
                total_weighted_grad[k] += scaled_grad[k]
        total_weight += effective_weight

    # Normalize by total weight
    return {k: v / total_weight for k, v in total_weighted_grad.items()}

Die Satellitenverbindungs-FL-Planung stimmt den Abschluss der Trainingsrunde auf vorhergesagte Konnektivitätsfenster ab. Ist der Satellitenlink eines Teilnehmers täglich von 02:00–02:20 UTC verfügbar, sollte sein Trainingsclient so konfiguriert sein, dass er sein lokales Training abschließt und den Gradienten vor 02:00 zur Übertragung bereithält. Der Server plant Aggregationsrunden mit einer Frist, die zum Konnektivitätsfenster des letzten Teilnehmers passt. Bei Teilnehmern mit mehreren täglichen Passagen kann der Trainingsclient den jüngsten Gradienten verwenden, wenn seit der letzten Übertragung ein Trainingslauf abgeschlossen wurde, und so die Komplexität der Gradientenakkumulation über Passagen hinweg vermeiden.

Die Modellversionierung auf Teilnehmerebene ist für Resilienz wesentlich. Der lokale Modellspeicher sollte mindestens drei Prüfpunkte behalten: das aktuell bereitgestellte Inferenzmodell, das zuletzt empfangene globale Modell (als Ausgangspunkt für lokales Training) und das in Arbeit befindliche trainierte lokale Modell (vor der Gradientenextraktion). Geht nach einem lokalen Trainingslauf, aber vor der Gradientenübertragung die Konnektivität verloren, kann der Gradient gehalten und im nächsten Konnektivitätsfenster übertragen werden, ohne die Trainingsberechnung zu wiederholen. Empfängt der Teilnehmer während eines laufenden lokalen Trainings ein globales Modell-Update, muss er entscheiden, ob er den aktuellen Lauf abschließt (und einen möglicherweise veralteten Gradienten einreicht) oder vom neuen globalen Modell neu startet (was die Recheninvestition verschwendet). Für power-constrained edge inference-Plattformen, auf denen Rechenleistung teuer ist, ist es üblicherweise die bessere Richtlinie, den aktuellen Lauf abzuschließen und Veraltung zu akzeptieren.

Bedrohungsmodell für föderierte militärische KI — byzantinisch-robuste Aggregation (Krum, Trimmed Mean), Modellvergiftungserkennung, Abmilderung von Gradient-Inversion-Angriffen

Federated Learning in Verteidigungsprogrammen arbeitet gegen ein anspruchsvolleres Bedrohungsmodell als zivile FL-Anwendungen. Der Gegner hat sowohl die Motivation als auch potenziell die technische Fähigkeit, FL-Teilnehmer zu kompromittieren, Gradientenübertragungen abzufangen oder die Aggregationsinfrastruktur zu infiltrieren. Die für militärisches FL relevanten Bedrohungskategorien sind Gradientenvergiftung (ein kompromittierter Teilnehmer reicht bösartige Gradienten ein), Modellvergiftung (der Gegner bringt Trainingsdaten ein, die ein mit Hintertür versehenes Modell erzeugen), Gradient-Inversion (ein Lauscher rekonstruiert Trainingsdaten aus erfassten Gradienten-Updates) und Kompromittierung des Aggregationsservers (der Gegner erhält Zugriff auf den zentralen Aggregationspunkt).

Byzantinisch-robuste Aggregation verteidigt gegen Gradientenvergiftung, indem sie das globale Update unempfindlich gegen eine begrenzte Anzahl adversarialer Teilnehmerbeiträge macht. Standard-FedAvg ist nicht byzantinisch-robust — ein einzelner Teilnehmer, der einen Gradienten in entgegengesetzter Richtung zum wahren Gradienten einreicht, kann die Konvergenz spürbar verschlechtern. Byzantinisch-robuste Algorithmen wählen entweder eine Teilmenge von Gradienten oder berechnen eine robuste Statistik, die den adversarialen Einfluss begrenzt:

Multi-Krum wählt die m Gradienten, die ihren k nächsten Nachbarn unter allen eingereichten Gradienten am ähnlichsten sind. Byzantinische Gradienten, die darauf ausgelegt sind, das globale Update zu verzerren, sind in der Gradientenverteilung Ausreißer — weit entfernt vom Cluster ehrlicher Gradienten. Das Auswahlkriterium von Krum verwirft diese Ausreißer. Der Algorithmus erfordert eine obere Schranke f für die Anzahl byzantinischer Teilnehmer; zur Sicherheit setzen Sie den Krum-Parameter auf n - f - 2, wobei n die Gesamtzahl der Teilnehmer ist.

Coordinate-wise Trimmed Mean verwirft vor der Mittelwertberechnung in jeder Dimension unabhängig die oberen und unteren p-Anteile der Gradientenwerte. Das ist rechnerisch günstiger als Krum und wirksam, wenn byzantinische Gradienten in einzelnen Dimensionen extrem sind — eine häufige Struktur einfacher Gradientenangriffsstrategien. Der Trim-Anteil p sollte mindestens auf den angenommenen byzantinischen Anteil plus eine Sicherheitsmarge von 5–10 % gesetzt werden.

# Coordinate-wise Trimmed Mean aggregation
import numpy as np

def trimmed_mean_aggregate(gradients, trim_fraction=0.2):
    """
    Byzantine-robust aggregation: trim top and bottom trim_fraction
    of gradient values per dimension, then average.

    gradients: list of flat numpy arrays, one per participant
    trim_fraction: fraction to trim from each tail (e.g., 0.2 = 20%)
    """
    grad_matrix = np.stack(gradients, axis=0)  # shape: (n_participants, n_params)
    n = grad_matrix.shape[0]
    k = int(np.floor(trim_fraction * n))        # number to remove from each tail

    # Sort along participant axis, trim k from top and bottom
    sorted_grads = np.sort(grad_matrix, axis=0)
    trimmed = sorted_grads[k : n - k, :]       # remove k from each end

    return np.mean(trimmed, axis=0)

Modellvergiftungserkennung erfordert die Überwachung des Verhaltens des globalen Modells auf einem sauberen zentralen Evaluierungsdatensatz nach jeder Aggregationsrunde. Ein plötzlicher Genauigkeitsabfall, ein Anstieg der Falsch-Negativ-Rate bei einer bestimmten Zielklasse oder das Auftreten unerwarteter Klassifikationsverhalten (etwa Fehlklassifikation mit hoher Konfidenz eines bestimmten Fahrzeugtyps, der vor der Runde nicht im Evaluierungsdatensatz war) sind Indikatoren erfolgreicher Vergiftung. Verteidigungs-FL-Programme sollten einen Holdout-Evaluierungsdatensatz pflegen, der von einem Team gepflegt wird, das unabhängig von jedem FL-Teilnehmer ist, damit kein Teilnehmer darauf trainieren kann, auf dem Evaluierungsdatensatz gut abzuschneiden, während er das operative Verhalten des Modells vergiftet. Anomalieerkennung auf Teilnehmer-Gradientenstatistiken — Gradientennorm, Kosinusähnlichkeit zum Rundenaggregat und Varianz über die Trainingsrunden — liefert ein Frühwarnsignal, dass sich das Gradientenverhalten eines Teilnehmers geändert hat, was auf Kompromittierung hindeuten kann.

Abmilderung von Gradient-Inversion wirkt über drei ergänzende Mechanismen. Erstens verschleiert DP-SGD-Rauschen die Gradientenwerte unter die Rauschgrenze und verhindert hochauflösende Rekonstruktion. Zweitens stellt SecAgg sicher, dass am Aggregationsserver nur Aggregatgradienten sichtbar sind, und begrenzt die Angriffsfläche auf den Kommunikationskanal zwischen jedem Teilnehmer und dem Server. Drittens erhöht die Vergrößerung der lokalen Batch-Größe von einstelligen auf 64 oder mehr Stichproben pro Gradientenschritt die Schwierigkeit der Inversion drastisch, weil der Gradient ein Mittelwert über viele Stichproben statt ein Fingerabdruck eines einzelnen Datensatzes ist. Für die sensibelsten Trainingsdaten verhindern lokale Batch-Größen von 128 oder mehr wirksam, dass aktuelle Gradient-Inversion-Techniken einzelne Trainingsdatensätze wiedergewinnen.