Apprendimento federato cross-silo e cross-device su Google Cloud

Last reviewed 2024-06-03 UTC

Questo documento descrive due architetture di riferimento che consentono di creare apprendimento federato su Google Cloud utilizzando Google Kubernetes Engine (GKE). Il riferimento le architetture e le risorse associate descritte in questo documento supportano quanto segue:

  • Apprendimento federato tra silos
  • Apprendimento federato cross-device, basato su un'architettura multi-silo

I destinatari di questo documento sono Cloud Architect, AI e ML che desiderano implementare casi d'uso dell'apprendimento federato su in Google Cloud. È destinata anche ai responsabili delle decisioni che stanno valutando se implementare l'apprendimento federato su Google Cloud.

Architettura

I diagrammi in questa sezione mostrano un'architettura multi-silo e un'architettura per l'apprendimento federato. Per conoscere le diverse applicazioni per queste architetture, consulta i Casi d'uso.

Architettura multi-silo

Il seguente diagramma mostra un'architettura che supporta l'architettura federata tra silos apprendimento:

Architettura multi-silo, componenti descritti nel testo che segue.

Il diagramma precedente mostra un esempio semplicistico di architettura a più silos. Nel diagramma, tutte le risorse si trovano nello stesso progetto in un Google Cloud dell'organizzazione. Queste risorse includono il modello di client locale, l'API globale del modello client e dei relativi carichi di lavoro di apprendimento federato associati.

Questa architettura di riferimento può essere modificata per supportare diverse configurazioni per i silos di dati. I membri del consorzio possono ospitare i propri silos di dati nei seguenti modi:

  • Su Google Cloud, nella stessa organizzazione Google Cloud e nella stessa organizzazione progetto.
  • Su Google Cloud, nella stessa organizzazione Google Cloud, in diversi progetti Google Cloud.
  • Su Google Cloud, in diverse organizzazioni Google Cloud.
  • In ambienti privati on-premise o in altri cloud pubblici.

Affinché i membri partecipanti possano collaborare, devono creare norme di sicurezza canali di comunicazione tra i loro ambienti. Per ulteriori informazioni il ruolo dei membri partecipanti all'impegno di apprendimento federato, il modo in cui collaborano e i contenuti che condividono tra loro, vedi Casi d'uso.

L'architettura include i seguenti componenti:

  • R Rete Virtual Private Cloud (VPC) e una subnet.
  • R cluster GKE privato che ti consente di:
    • Isola i nodi del cluster da internet.
    • Limita l'esposizione dei nodi e del piano di controllo del cluster creando un cluster GKE privato reti autorizzate.
    • Utilizza nodi dei cluster schermati che utilizzano un'immagine del sistema operativo con protezione avanzata.
    • Attiva Dataplane V2 per ottimizzare il networking di Kubernetes.
  • GKE dedicato pool di nodi: Creerai un pool di nodi dedicato per ospitare esclusivamente app tenant e Google Cloud. I nodi presentano incompatibilità per garantire che vengano eseguiti solo i carichi di lavoro tenant e pianificato nei nodi tenant. Altre risorse del cluster sono ospitate pool di nodi principale.

  • Crittografia dei dati (attivata per impostazione predefinita):

  • Crittografia dei dati in uso, abilitando facoltativamente i Confidential Google Kubernetes Engine Node.

  • Regole firewall VPC che si applicano quanto segue:

    • Regole di base di riferimento che si applicano a tutti i nodi nel cluster.
    • Regole aggiuntive che si applicano solo ai nodi nel nodo tenant piscina. Queste regole firewall limitano il traffico in entrata e in uscita dai nodi tenant.

  • Cloud NAT per consentire il traffico in uscita verso internet.

  • Cloud DNS record per abilitare Accesso privato Google in modo che le app nel cluster possano accedere alle API di Google senza dover su internet.

  • Account di servizio che sono le seguenti:

    • Un account di servizio dedicato per i nodi nel pool di nodi tenant.
    • Un account di servizio dedicato per le app tenant da utilizzare con la federazione delle identità per i carichi di lavoro.

  • Supporto per l'utilizzo Google Gruppi per il controllo degli accessi basato su ruoli (RBAC, Role-Based Access Control) di Google Gruppi

  • Un repository Git in cui archiviare i descrittori di configurazione.

  • Un Artifact Registry in un repository per archiviare le immagini container.

  • Configurazione Sync e Policy Controller per il deployment della configurazione e dei criteri.

  • Gateway Cloud Service Mesh per consentire selettivamente il traffico in entrata e in uscita del cluster.

  • Bucket Cloud Storage per archiviare i pesi del modello globali e locali.

  • Accesso ad altre API Google e Google Cloud. Ad esempio, un corso di formazione carico di lavoro potrebbe dover accedere ai dati Cloud Storage, BigQuery o Cloud SQL.

Architettura cross-device

Il seguente diagramma mostra un'architettura che supporta cross-device apprendimento federato:

Architettura cross-device, componenti spiegati nel testo che segue.

La precedente architettura cross-device si basa su un'architettura multi-silo con l'aggiunta dei seguenti componenti:

  • Un servizio Cloud Run che simula dispositivi che si connettono all'istanza server
  • Un Certificate Authority Service che crea certificati privati per il server e client per eseguire
  • Una Vertex AI TensorBoard per visualizzare il risultato dell'addestramento
  • Un bucket Cloud Storage per archiviare il modello consolidato
  • Il cluster GKE privato che utilizza nodi riservati come pool principale per contribuire a proteggere i dati in uso

L'architettura cross-device utilizza componenti open source Progetto Federated Compute Platform (FCP). Questo progetto include:

  • Codice client per comunicare con un server ed eseguire attività sul dispositivi
  • Un protocollo per la comunicazione client-server
  • Punti di connessione con TensorFlow Federated per semplificare per definire i calcoli federati

Il deployment dei componenti FCP mostrati nel diagramma precedente può essere eseguito come un insieme di microservizi. Questi componenti:

  • Aggregatore: questo job legge i gradienti dei dispositivi e calcola i dati aggregati con la privacy differenziale.
  • Raccoglitore: questo job viene eseguito periodicamente per eseguire query sulle attività attive e gradienti criptati. Queste informazioni determinano quando inizia l'aggregazione.
  • Strumento di caricamento del modello: questo job ascolta gli eventi e pubblica i risultati per i dispositivi possono scaricare i modelli aggiornati.
  • Assegnazione dell'attività: questo servizio di frontend distribuisce le attività di addestramento ai dispositivi mobili.
  • Gestione delle attività: questo job gestisce le attività.
  • Task-scheduler: questo job viene eseguito periodicamente o viene attivato dal per eventi specifici.

Prodotti utilizzati

Le architetture di riferimento per entrambi i casi d'uso dell'apprendimento federato utilizzano i seguenti componenti di Google Cloud:

GKE offre inoltre le seguenti funzionalità piattaforma di apprendimento federata:

  • Ospita il coordinatore dell'apprendimento federato: l'apprendimento federato responsabile della gestione del processo di apprendimento federato. Questa gestione include attività come la distribuzione del modello globale partecipanti, aggregando gli aggiornamenti dei partecipanti e aggiornando i globale. GKE può essere utilizzato per ospitare di machine learning in modo ad alta disponibilità e scalabilità.
  • Hosting dei partecipanti all'apprendimento federato: partecipanti dell'apprendimento federato sono responsabili dell'addestramento del modello globale sulla base dei dati locali. GKE può essere utilizzato per ospitare l'apprendimento federato partecipanti in modo sicuro e isolato. Questo approccio può aiutare a garantire che i partecipanti vengono mantenuti locali.
  • Fornire un canale di comunicazione sicuro e scalabile: Federated i partecipanti devono essere in grado di comunicare con di machine learning in modo sicuro e scalabile. GKE possono essere utilizzati per fornire un canale di comunicazione sicuro e scalabile partecipanti e il coordinatore.
  • Gestione del ciclo di vita dei deployment dell'apprendimento federato: GKE può essere utilizzato per gestire il ciclo di vita deployment di machine learning. Questa gestione include attività come il provisioning risorse, il deployment della piattaforma di apprendimento federata e il monitoraggio le prestazioni della piattaforma di apprendimento federata.

Oltre a questi vantaggi, GKE offre anche una serie di funzionalità utili per i deployment dell'apprendimento federato, come seguenti:

  • Cluster regionali: GKE ti consente di creare regionali, aiutandoti a migliorare le prestazioni dei cluster di machine learning riducendo la latenza tra i partecipanti e coordinatore.
  • Criteri di rete: GKE ti consente di creare criteri, contribuendo a migliorare la sicurezza dei deployment dell'apprendimento federato controllando il flusso di traffico tra i partecipanti e il coordinatore.
  • Bilanciamento del carico: GKE fornisce una serie di carichi di bilanciamento del carico, contribuendo a migliorare la scalabilità dell'apprendimento federato distribuendo il traffico tra i partecipanti e il coordinatore.

Il TFF fornisce le seguenti funzionalità per facilitare l'implementazione casi d'uso dell'apprendimento federato:

  • La possibilità di esprimere in modo dichiarativo i calcoli federati, ovvero un insieme di passaggi di elaborazione eseguiti su un server e su un insieme di client. Questi di computing può essere implementato in diversi ambienti di runtime.
  • Gli aggregatori personalizzati possono essere creati utilizzando TFF open source.
  • Supporto di una serie di algoritmi di apprendimento federato, tra cui i seguenti algoritmi:
    • Media federata: Un algoritmo che calcola la media dei parametri del modello clienti. È particolarmente adatta per i casi d'uso in cui i dati vengono relativamente omogeneo e il modello non è troppo complesso. I casi d'uso tipici sono come segue:
      • Consigli personalizzati: un'azienda può utilizzare la media federata per addestrare un modello che consiglia prodotti utenti in base alla loro cronologia acquisti.
      • Rilevamento di frodi: un consorzio di banche può utilizzare per addestrare un modello che rileva transazioni fraudolente.
      • Diagnosi medica: un gruppo di ospedali può utilizzare media federata per addestrare un modello che diagnostica il cancro.
    • Discesa stocastica del gradiente federata (FedSGD): un algoritmo che utilizza la discesa stocastica del gradiente per aggiornare il modello. parametri. È adatta per casi d'uso in cui i dati sono eterogenei e il modello è complesso. Di seguito sono riportati i casi d'uso tipici:
      • Elaborazione del linguaggio naturale: un'azienda può utilizzare FedSGD per addestrare un modello che migliora la precisione del riconoscimento vocale.
      • Riconoscimento di immagini: un'azienda può utilizzare FedSGD per addestrare un di analisi in grado di identificare gli oggetti nelle immagini.
      • Manutenzione predittiva: un'azienda può utilizzare FedSGD per addestrare un modello che prevede il probabile guasto di una macchina.
    • Adamo federato: Un algoritmo che utilizza l'ottimizzatore Adam per aggiornare i parametri del modello. Di seguito sono riportati i casi d'uso tipici:
      • Sistemi del motore per suggerimenti: un'azienda può utilizzare Adam federato per addestrare un modello che consiglia i prodotti agli utenti in base alla loro cronologia acquisti.
      • Ranking: un'azienda può utilizzare Adam federato per addestrare un modello che classifica risultati di ricerca.
      • Previsione della percentuale di clic: un'azienda può utilizzare Adam federato per addestrare un modello che prevede la probabilità che un utente faccia clic su una pubblicità.

Casi d'uso

Questa sezione descrive i casi d'uso in cui le funzionalità cross-silo e cross-device sono le scelte giuste per la tua piattaforma di apprendimento federata.

L'apprendimento federato è un ambiente di machine learning in cui molti client per addestrare un modello in modo collaborativo. Questo processo è guidato da un coordinatore centrale e i dati di addestramento rimangono decentralizzati.

Nel paradigma di apprendimento federato, i clienti scaricano un modello globale e migliorano addestrando il modello localmente in base ai suoi dati. Quindi, ciascun client invia i propri gli aggiornamenti del modello calcolati di nuovo al server centrale, dove vengono e viene generata una nuova iterazione del modello globale. In queste di riferimento, i carichi di lavoro di addestramento con GKE.

Apprendimento federato incarna il principio della privacy relativo alla minimizzazione dei dati, limitando i dati raccolti in ogni fase del calcolo, limitando l'accesso ai dati ed elaborarli per poi scartarli il prima possibile. Inoltre, l'impostazione dei problemi dell'apprendimento federato è compatibile Ulteriori tecniche di tutela della privacy, come l'uso della privacy differenziale (DP) per migliorare l'anonimizzazione del modello per garantire che il modello finale non memorizzi i dati del singolo utente.

A seconda del caso d'uso, i modelli con l'apprendimento federato possono avere vantaggi aggiuntivi:

  • Conformità: in alcuni casi, le normative potrebbero limitare il modo in cui i dati possono o condivise. È possibile utilizzare l'apprendimento federato per rispettare queste normative.
  • Efficienza della comunicazione: in alcuni casi, è più efficiente addestrare un un modello basato su dati distribuiti, anziché centralizzare i dati. Ad esempio, I set di dati su cui deve essere addestrato il modello sono troppo grandi per essere spostati a livello centrale.
  • Rendere accessibili i dati: l'apprendimento federato consente alle organizzazioni di mantenere i dati di addestramento decentralizzati in silos di dati per utente o per organizzazione.
  • Maggiore accuratezza del modello: mediante l'addestramento su dati di utenti reali (assicurando al contempo che privacy) anziché dati sintetici (a volte indicati come dati proxy), spesso si traduce in una maggiore accuratezza del modello.

Esistono diversi tipi di apprendimento federato, caratterizzati da l'origine dei dati e il luogo in cui vengono eseguiti i calcoli locali. La di questo documento si concentrano su due tipi di apprendimento federato: cross-silo e cross-device. Altri tipi di apprendimento federato non rientrano nell'ambito per questo documento.

L'apprendimento federato è ulteriormente classificato in base al modo in cui i set di dati sono partizionati, che possono essere:

  • Apprendimento federato orizzontale (HFL): set di dati con le stesse caratteristiche (colonne), ma diversi campioni (righe). Ad esempio, più ospedali potrebbero avere cartelle cliniche con gli stessi parametri medici ma diversi popolazioni di pazienti.
  • Apprendimento federato verticale (VFL): set di dati con gli stessi campioni (righe) ma caratteristiche diverse (colonne). Ad esempio, una banca e un negozio l'azienda potrebbe avere dati dei clienti con persone che si sovrappongono ma informazioni finanziarie e sugli acquisti.
  • Federated Transfer Learning (FTL): sovrapposizione parziale in entrambi i campioni e le caratteristiche tra i set di dati. Ad esempio, due ospedali potrebbero avere documenti con alcuni individui sovrapposti e alcuni medici condivisi ma anche caratteristiche uniche in ogni set di dati.

Il calcolo federato tra silo è dedicato ai membri partecipanti. organizzazioni o aziende. In pratica, il numero di abbonati è solitamente ridotto (ad esempio, entro un centinaio di membri). Il calcolo cross-silo è in genere utilizzati in scenari in cui le organizzazioni partecipanti dispongono di diversi set di dati, ma vuole addestrare un modello condiviso o analizzare risultati aggregati senza condividere tra loro i dati non elaborati. Ad esempio, la partecipazione possono avere i propri ambienti in diverse organizzazioni Google Cloud, ad esempio quando rappresentano persone giuridiche diverse o nello stesso dell'organizzazione Google Cloud, ad esempio quando rappresentano reparti diversi di la stessa persona giuridica.

I membri partecipanti potrebbero non essere in grado di considerare i reciproci carichi di lavoro le entità attendibili. Ad esempio, un membro partecipante potrebbe non avere accesso a il codice sorgente di un carico di lavoro di addestramento come il coordinatore. Poiché non possono accedere a questo codice sorgente, i membri partecipanti non possono garantire l'affidabilità completa del carico di lavoro.

Per aiutarti a impedire a un carico di lavoro non attendibile di accedere ai tuoi dati o alle tue risorse senza autorizzazione, ti consigliamo di procedere come segue:

  • Esegui il deployment di carichi di lavoro non attendibili in un ambiente isolato.
  • Concedi ai carichi di lavoro non attendibili solo i diritti di accesso strettamente necessari e le autorizzazioni necessarie per completare i cicli di addestramento assegnati al carico di lavoro.

Per aiutarti a isolare i carichi di lavoro potenzialmente non attendibili, consulta questi riferimenti le architetture implementano i controlli di sicurezza, come la configurazione spazi dei nomi Kubernetes, dove ogni spazio è associato del pool di nodi GKE. Comunicazione e cluster tra spazio dei nomi il traffico in entrata e in uscita è vietato per impostazione predefinita, a meno che non questa impostazione.

Ecco alcuni casi d'uso di esempio per l'apprendimento federato tra silos:

  • Rilevamento di frodi: l'apprendimento federato può essere utilizzato per addestrare una frode di rilevamento dei dati su dati distribuiti in più organizzazioni. Ad esempio, un consorzio di banche potrebbe utilizzare l’apprendimento federato per addestrare modello che rileva le transazioni fraudolente.
  • Diagnosi medica: l'apprendimento federato può essere utilizzato per formare un di diagnosi su dati distribuiti in più ospedali. Per Ad esempio, un gruppo di ospedali potrebbe utilizzare l'apprendimento federato per addestrare un modello che diagnostica il cancro.

Apprendimento federato cross-device è un tipo di calcolo federato in cui i membri partecipanti sono utenti finali come telefoni cellulari, veicoli o dispositivi IoT. Il numero di membri può raggiungere una scala di milioni o persino decine di milioni.

Il processo per l'apprendimento federato cross-device è simile a quello dell'apprendimento l'apprendimento federato tra silos. Tuttavia, richiede anche l'adattamento del riferimento per tenere conto di alcuni dei fattori aggiuntivi da prendere in considerazione con migliaia o milioni di dispositivi. Devi eseguire il deployment per gestire gli scenari che si verificano di apprendimento federato cross-device. Ad esempio, la necessità coordinare un sottoinsieme di clienti che si svolgeranno nel corso dell'addestramento. L'architettura cross-device consente di eseguire il deployment dei servizi FCP. Questi servizi avere carichi di lavoro che hanno punti di connessione con TFF. TFF viene utilizzato per scrivere codice che gestisce questo coordinamento.

Ecco alcuni casi d'uso di esempio per l'apprendimento federato cross-device:

  • Consigli personalizzati: puoi usare federata tra dispositivi ad addestrare un modello di suggerimenti personalizzato sui dati distribuiti su più dispositivi. Ad esempio, un'azienda potrebbe utilizzare l'apprendimento federato per addestrare un modello che consiglia prodotti agli utenti in base nella loro cronologia acquisti.
  • Elaborazione del linguaggio naturale: l'apprendimento federato può essere utilizzato per addestrare un di elaborazione del linguaggio naturale su dati distribuiti più dispositivi. Ad esempio, un'azienda potrebbe utilizzare l'apprendimento federato per addestrare un modello che migliora la precisione del riconoscimento vocale.
  • Prevedere le esigenze di manutenzione dei veicoli: l'apprendimento federato può essere utilizzato addestrare un modello che prevede quando è probabile che un veicolo richieda manutenzione. Questo modello può essere addestrato su dati raccolti da più veicoli. Questo approccio consente al modello di imparare dalle esperienze i veicoli, senza compromettere la privacy dei singoli veicoli.

La seguente tabella riassume le funzionalità dei servizi cross-silo e cross-device di Kubernetes e ti mostra come classificare il tipo di apprendimento federato applicabile al tuo caso d'uso.

Funzionalità Calcoli federati tra silo Calcoli federati cross-device
Dimensione della popolazione Di solito è ridotto (ad esempio, entro un centinaio di dispositivi) Scalabile fino a migliaia, milioni o centinaia di milioni di dispositivi
Membri partecipanti Organizzazioni o aziende Dispositivi mobili, dispositivi periferici, veicoli
Partizionamento dei dati più comune HFL, VFL, FTL HFL
Sensibilità dei dati Dati sensibili che i partecipanti non vogliono condividere tra loro in formato non elaborato Dati troppo sensibili per essere condivisi con un server centrale
Disponibilità dei dati I partecipanti sono quasi sempre disponibili Solo una frazione dei partecipanti è disponibile in qualsiasi momento
Esempi di casi d'uso Rilevamento di frodi, diagnosi mediche, previsioni finanziarie Monitoraggio dell'attività fisica, riconoscimento vocale, classificazione delle immagini

Note sul layout

Questa sezione fornisce indicazioni per aiutarti a utilizzare questa architettura di riferimento per: sviluppare una o più architetture che soddisfino i tuoi requisiti specifici sicurezza, affidabilità, efficienza operativa, costi e prestazioni.

Considerazioni sulla progettazione dell'architettura multi-silo

Per implementare un'architettura di apprendimento federato tra più silos Google Cloud, devi implementare i seguenti prerequisiti minimi: descritti più dettagliatamente nelle sezioni seguenti:

  1. Istituisci un consorzio per l'apprendimento federato.
  2. Determina il modello di collaborazione per il Consorzio di apprendimento federato da implementare.
  3. Determina le responsabilità delle organizzazioni partecipanti.

Oltre a questi prerequisiti, esistono altre azioni che la federazione che non rientrano nell'ambito di questo documento, ad esempio le seguenti:

  • Gestisci il Consorzio per l'apprendimento federato.
  • Progettare e implementare un modello di collaborazione.
  • Prepara, gestisci e utilizza i dati di addestramento del modello e il modello che che il proprietario della federazione intende addestrare.
  • Crea, containerizza e orchestra flussi di lavoro di apprendimento federato.
  • Esegui il deployment e gestisci carichi di lavoro di apprendimento federato.
  • Configura i canali di comunicazione per le organizzazioni partecipanti trasferire i dati in modo sicuro.

Istituisci un consorzio per l'apprendimento federato

Un consorzio per l'apprendimento federato è il gruppo di organizzazioni che partecipano in un'attività di apprendimento federato in più silos. Solo le organizzazioni che fanno parte del consorzio condividono i parametri dei modelli ML, che puoi criptare per aumentare la privacy. Se il consorzio per l'apprendimento federato consente questa pratica, le organizzazioni possono anche aggregare dati che non contengono informazioni di informazioni (PII).

Determinare un modello di collaborazione per il Consorzio di Apprendimento federato

Il Consorzio per l'apprendimento federato può implementare diversi modelli di collaborazione, ad esempio:

  • Un modello centralizzato composto da un unico coordinamento dell'organizzazione, denominato proprietario della federazione o agente di orchestrazione, e un insieme di organizzazioni partecipanti o proprietari di dati.
  • Un modello decentralizzato composto da organizzazioni che coordinano come gruppo.
  • Un modello eterogeneo composto da un consorzio di diversi organizzazioni partecipanti, che mettono a disposizione risorse diverse consorzio.

Questo documento presuppone che il modello di collaborazione sia un ambiente un modello di machine learning.

Determinare le responsabilità delle organizzazioni partecipanti

Dopo aver scelto un modello di collaborazione per il Consorzio di Apprendimento federato, il proprietario della federazione deve determinare le responsabilità le tue organizzazioni.

Il proprietario della federazione deve inoltre effettuare le seguenti operazioni quando inizia a creare un consorzio per l'apprendimento federato:

  • Coordina l'impegno di apprendimento federato.
  • Progettare e implementare il modello ML globale e i modelli ML da condividere le organizzazioni partecipanti.
  • Definire i cicli di apprendimento federati, ovvero l'approccio per l'iterazione delle il processo di addestramento ML.
  • Seleziona le organizzazioni partecipanti che contribuiscono a un determinato di apprendimento federato. Questa selezione viene chiamata coorte.
  • Progettare e implementare una procedura di verifica dell'iscrizione a consorzio per le organizzazioni partecipanti.
  • Aggiornare il modello ML globale e i modelli ML da condividere con organizzazioni partecipanti.
  • Fornisci alle organizzazioni partecipanti gli strumenti per verificare che ciò avvenga il consorzio per l'apprendimento federato soddisfa le loro esigenze in termini di requisiti normativi.
  • Offri alle organizzazioni partecipanti informazioni canali di comunicazione.
  • Fornisci alle organizzazioni partecipanti tutto il necessario dati aggregati non riservati necessari per la compilazione di ogni di Google Cloud.

Le organizzazioni partecipanti hanno le seguenti responsabilità:

  • Fornire e gestire un ambiente sicuro e isolato (un silo). La silo è il luogo in cui le organizzazioni partecipanti archiviano i propri dati e dove il ML sia implementato l'addestramento del modello.
  • Addestra i modelli forniti dal proprietario della federazione utilizzando i modelli dell'infrastruttura informatica e dei propri dati locali.
  • Condividi i risultati dell'addestramento del modello con il proprietario della federazione sotto forma di e aggregati dopo aver rimosso eventuali PII.

Il proprietario della federazione e le organizzazioni partecipanti perfezionano il modello ML fino a quando il modello non soddisfa i requisiti.

Implementazione dell'apprendimento federato su Google Cloud

Dopo la creazione del consorzio per l'apprendimento federato e una volta stabilito in che modo consorzio per l'apprendimento federato, consigliamo a quel partecipante le organizzazioni:

  1. Esegui il provisioning e la configurazione dell'infrastruttura necessaria per l'infrastruttura learning consortium.
  2. Implementa il modello di collaborazione.
  3. Inizia l'impegno di apprendimento federato.

Esegui il provisioning e la configurazione dell'infrastruttura per il Consorzio di Apprendimento federato

Quando si esegue il provisioning e la configurazione dell'infrastruttura per l'apprendimento federato consorzio, è responsabilità del proprietario della federazione creare e distribuire i carichi di lavoro che addestrano i modelli di ML federato ai partecipanti le tue organizzazioni. Poiché una terza parte (il proprietario della federazione) ha creato e fornito carichi di lavoro, le organizzazioni partecipanti devono prendere precauzioni quando il deployment di questi carichi di lavoro nei rispettivi ambienti di runtime.

Le organizzazioni partecipanti devono configurare i propri ambienti in base alle proprie best practice per la sicurezza individuali e applicare controlli che limitano l'ambito le autorizzazioni concesse a ogni carico di lavoro. Oltre a seguire i loro best practice per la sicurezza individuali, consigliamo al proprietario della federazione le organizzazioni partecipanti prendono in considerazione vettori di minacce specifici dell'apprendimento federato.

Implementare il modello di collaborazione

Una volta preparata l'infrastruttura del Consorzio per l'apprendimento federato, il proprietario della federazione progetta e implementa i meccanismi che consentono al partecipante che interagiscono tra loro. L'approccio segue la collaborazione scelto dal proprietario della federazione per il Consorzio per l'apprendimento federato.

Inizia l'impegno di apprendimento federato

Dopo aver implementato il modello di collaborazione, il proprietario della federazione implementa un modello ML globale da addestrare e i modelli ML da condividere con il partecipante. dell'organizzazione. Quando i modelli ML sono pronti, il proprietario della federazione avvia la configurazione primo round dell'apprendimento federato.

Durante ogni fase dell'apprendimento federato, il proprietario della federazione le seguenti:

  1. Distribuisce i modelli di ML da condividere con le organizzazioni partecipanti.
  2. Attende che le organizzazioni partecipanti consegnino i risultati del dei modelli ML condivisi dal proprietario della federazione.
  3. Raccoglie ed elabora i risultati della formazione che il partecipante le organizzazioni produttive.
  4. Aggiorna il modello ML globale quando ricevono l'addestramento appropriato. risultati dalle organizzazioni partecipanti.
  5. Aggiorna i modelli di ML da condividere con gli altri membri del consorzio laddove applicabile.
  6. Prepara i dati di addestramento per il prossimo ciclo di apprendimento federato.
  7. Avvia il prossimo ciclo di apprendimento federato.

Sicurezza, privacy e conformità

Questa sezione descrive i fattori da prendere in considerazione quando utilizzi questo di riferimento per progettare e creare una piattaforma di apprendimento federata in Google Cloud. Queste linee guida si applicano a entrambe le architetture descritti in questo documento.

I carichi di lavoro di apprendimento federato di cui esegui il deployment nei tuoi ambienti esporre te, i tuoi dati, i tuoi modelli di apprendimento federato e la tua infrastruttura alle minacce che potrebbero avere un impatto sulla tua attività.

Per aiutarti ad aumentare la sicurezza dei tuoi ambienti di apprendimento federato, queste architetture di riferimento configurano Controlli di sicurezza di GKE incentrati sull'infrastruttura dei tuoi ambienti. Questi controlli potrebbero non essere sufficienti per proteggerti da minacce specifiche per il tuo carichi di lavoro di apprendimento federato e casi d'uso. Data la specificità di ogni del carico di lavoro e del caso d'uso dell'apprendimento federato, controlli di sicurezza volti l'implementazione dell'apprendimento federato non rientra nell'ambito di questo documento. Per ulteriori informazioni ed esempi su queste minacce, consulta Considerazioni sulla sicurezza per l'apprendimento federato.

Controlli di sicurezza di GKE

Questa sezione illustra i controlli che applichi con queste architetture per per proteggere il tuo cluster GKE.

Sicurezza avanzata dei cluster GKE

Queste architetture di riferimento aiutano a creare un cluster GKE implementa le seguenti impostazioni di sicurezza:

Per ulteriori informazioni sulle impostazioni di sicurezza di GKE, consulta Rafforza la sicurezza del tuo cluster e Dashboard della postura di sicurezza.

Regole firewall VPC

Regole firewall Virtual Private Cloud (VPC) e disciplinare quale traffico è consentito da o verso le VM di Compute Engine. Le regole consentono il traffico viene filtrato con granularità delle VM, a seconda Attributi di livello 4.

Crei un cluster GKE con regole firewall predefinite per il cluster GKE. Queste regole firewall consentono la comunicazione tra i nodi del cluster dal piano di controllo GKE, e tra nodi e pod in un cluster Kubernetes.

Applichi regole firewall aggiuntive ai nodi nel pool di nodi tenant. Questi le regole firewall limitano il traffico in uscita dai nodi tenant. Questo approccio può Aumentare l'isolamento dei nodi tenant. Per impostazione predefinita, tutto il traffico in uscita di nodi tenant. Qualsiasi traffico in uscita richiesto deve essere configurato in modo esplicito. Per Ad esempio, crei regole firewall per consentire il traffico in uscita dai nodi tenant dal piano di controllo GKE e alle API di Google utilizzando Accesso privato Google. Le regole firewall vengono indirizzate ai nodi tenant utilizzando account di servizio per il pool di nodi tenant.

Spazi dei nomi

Gli spazi dei nomi consentono di fornire un ambito per le risorse correlate all'interno di un cluster, ad esempio pod, servizi e controller di replica. Utilizzando gli spazi dei nomi, può delegare la responsabilità dell'amministrazione delle risorse correlate come unità. Pertanto, gli spazi dei nomi sono parte integrante della maggior parte dei pattern di sicurezza.

Gli spazi dei nomi sono una funzionalità importante per l'isolamento del piano di controllo. Tuttavia, non forniscono l'isolamento dei nodi, del piano dati o della rete.

Un approccio comune consiste nel creare spazi dei nomi per singole applicazioni. Per Ad esempio, potresti creare lo spazio dei nomi myapp-frontend per il componente UI di un'applicazione.

Queste architetture di riferimento consentono di creare uno spazio dei nomi dedicato app di terze parti. Lo spazio dei nomi e le relative risorse vengono trattati come un tenant all'interno nel tuo cluster. Applichi criteri e controlli allo spazio dei nomi per limitare delle risorse nello spazio dei nomi.

Criteri di rete

Criteri di rete applicare i flussi di traffico di rete di livello 4 utilizzando regole firewall a livello di pod. Rete criteri sono con ambito a uno spazio dei nomi.

Nelle architetture di riferimento descritte in questo documento, vengono applicati i criteri allo spazio dei nomi tenant che ospita le app di terze parti. Per impostazione predefinita, Il criterio di rete nega tutto il traffico da e verso i pod nello spazio dei nomi. Qualsiasi il traffico richiesto deve essere aggiunto esplicitamente a una lista consentita. Ad esempio, i criteri di rete in queste architetture di riferimento consentono esplicitamente al traffico servizi cluster richiesti, come il DNS interno del cluster e Cloud Service Mesh dal piano di controllo.

Config Sync

Configurazione Sync mantiene sincronizzati i cluster GKE con le configurazioni archiviate in un repository. Il repository Git funge da unica fonte attendibile per il tuo cluster configurazione e criteri. Config Sync è dichiarativo. È continuamente controlla lo stato del cluster e applica lo stato dichiarato nel file di configurazione a applicare criteri, il che aiuta a prevenire deviazione della configurazione.

Installerai Config Sync nel tuo cluster GKE. Configura Config Sync per sincronizzare le configurazioni e i criteri dei cluster da un Repository di codice sorgente Cloud. Le risorse sincronizzate includono:

  • Configurazione di Cloud Service Mesh a livello di cluster
  • Criteri di sicurezza a livello di cluster
  • Configurazione e criterio a livello di spazio dei nomi tenant, inclusa la rete criteri, account di servizio, regole RBAC e configurazione di Cloud Service Mesh

Policy Controller

Policy Controller della versione Google Kubernetes Engine (GKE) Enterprise è un controller di ammissione dinamico per Kubernetes che applica In base a CustomResourceDefinition (basato su CRD) i criteri che vengono eseguiti Apri Policy Agent (OPA).

Controller di ammissione sono plug-in Kubernetes che intercettano le richieste al server API Kubernetes. prima che un oggetto sia persistente, ma dopo che la richiesta è stata autenticata autorizzati. Puoi usare i controller di ammissione per limitare l'utilizzo di un cluster.

Installerai Policy Controller nel tuo cluster GKE. Questi architetture di riferimento includono criteri di esempio per contribuire a proteggere il cluster. Applicherai automaticamente i criteri al cluster utilizzando Config Sync. Tu e applicare le seguenti norme:

Cloud Service Mesh

Cloud Service Mesh è un mesh di servizi che aiuta a semplificare la gestione delle le comunicazioni tra i servizi. Queste architetture di riferimento configurano Cloud Service Mesh per eseguire le seguenti operazioni:

  • Inserisce automaticamente i proxy sidecar.
  • Applica comunicazione mTLS tra i servizi nel mesh.
  • Limita il traffico mesh in uscita solo agli host noti.
  • Limita il traffico in entrata solo da determinati client.
  • Consente di configurare criteri di sicurezza di rete in base all'identità del servizio anziché in base all'indirizzo IP dei peer sulla rete.
  • Limiti comunicazione autorizzata tra i servizi nel mesh. Ad esempio, le app nello spazio dei nomi tenant Possono comunicare solo con app nello stesso spazio dei nomi o con un insieme degli host esterni noti.
  • Indirizza tutto il traffico in entrata e in uscita attraverso gateway mesh in cui puoi applicare ulteriori controlli del traffico.
  • Supporta la comunicazione sicura tra i cluster.

Incompatibilità e affinità dei nodi

Incompatibilità dei nodi e affinità nodo sono meccanismi Kubernetes che ti consentono di influire sulla pianificazione dei pod. nodi del cluster.

I nodi infetti respingono i pod. Kubernetes non pianificherà un pod su un nodo incompatibile a meno che il pod non abbia una tolleranza per l'incompatibilità. Puoi usare le incompatibilità dei nodi dei nodi in modo che siano utilizzati solo da determinati carichi di lavoro o tenant. Incompatibilità e le tolleranze sono spesso usate nei cluster multi-tenant. Per ulteriori informazioni, consulta nodi dedicati con incompatibilità e tolleranze documentazione.

L'affinità dei nodi ti consente di vincolare i pod a nodi con determinate etichette. Se un pod ha un requisito di affinità nodo, Kubernetes non pianifica il pod su a meno che il nodo non abbia un'etichetta che corrisponde al requisito di affinità. Puoi usano l'affinità dei nodi per garantire che i pod siano pianificati sui nodi appropriati.

Puoi utilizzare insieme le incompatibilità dei nodi e l'affinità dei nodi per garantire il carico di lavoro del tenant i pod sono pianificati esclusivamente su nodi riservati al tenant.

Queste architetture di riferimento consentono di controllare la pianificazione delle app tenant nei seguenti modi:

  • Creazione di un pool di nodi GKE dedicato al tenant. Ogni nodo nel pool ha un'incompatibilità correlata al nome del tenant.
  • Applicazione automatica della tolleranza e dell'affinità nodo appropriate a qualsiasi pod che abbia come target lo spazio dei nomi tenant. Applichi la tolleranza e affinità con Cambiamenti di PolicyController.

Privilegio minimo

Una best practice per la sicurezza consiste nell'adottare un principio del privilegio minimo a progetti e risorse Google Cloud come i cluster GKE. Utilizzando questo approccio, le app eseguite all'interno del cluster e gli sviluppatori e gli operatori che utilizzano dispongono solo dell'insieme minimo di autorizzazioni richiesto.

Queste architetture di riferimento consentono di utilizzare gli account di servizio con privilegio minimo nei seguenti modi:

  • Ogni pool di nodi GKE riceve il proprio servizio . Ad esempio, i nodi nel pool di nodi tenant utilizzano un servizio dedicato a questi nodi. Gli account di servizio dei nodi sono configurati con autorizzazioni minime richieste.
  • Il cluster utilizza Identità carico di lavoro per associare gli account di servizio Kubernetes agli account di servizio Google. Questo alle app tenant può essere concesso un accesso limitato a qualsiasi API senza scaricare e archiviare una chiave dell'account di servizio. Ad esempio: puoi concedere all'account di servizio le autorizzazioni per leggere i dati nel bucket Cloud Storage.

Queste architetture di riferimento ti aiutano limitare l'accesso alle risorse del cluster nei seguenti modi:

  • Puoi creare un ruolo RBAC in Kubernetes di esempio con autorizzazioni limitate per gestire le app. Puoi concedere questo ruolo agli utenti e ai gruppi che operano le app nello spazio dei nomi tenant. Applicando questo ruolo limitato di utenti e gruppi, questi utenti dispongono solo delle autorizzazioni per modificare le risorse dell'app nel tenant nello spazio dei nomi. Non dispongono delle autorizzazioni per modificare risorse a livello di cluster o e sensibili, come i criteri di Cloud Service Mesh.

Autorizzazione binaria

Autorizzazione binaria consente di applicare in modo forzato i criteri che definisci per le immagini container il deployment nel tuo ambiente GKE. Autorizzazione binaria consente di cui eseguire il deployment solo per le immagini container conformi ai criteri che hai definito. it non consente il deployment di altre immagini container.

In questa architettura di riferimento, Autorizzazione binaria è abilitata con il suo configurazione. Per ispezionare l'impostazione predefinita di Autorizzazione binaria configurazione, consulta Esportare il file YAML dei criteri.

Per ulteriori informazioni su come configurare i criteri, consulta le guida:

Verifica attestazione tra organizzazioni

Puoi utilizzare Autorizzazione binaria per verificare le attestazioni generate da una terza parte firmatario. Ad esempio, in un apprendimento federato tra più silos caso d'uso, puoi verificare le attestazioni che un'altra organizzazione partecipante è stato creato.

Per verificare le attestazioni create da una terza parte:

  1. Ricevi le chiavi pubbliche utilizzate dalla terza parte per creare le attestazioni che devi verificare.
  2. Crea gli attestatori per verificare le attestazioni.
  3. Aggiungi agli attestatori le chiavi pubbliche ricevute dalla terza parte che hai creato.

Per ulteriori informazioni sulla creazione di attestatori, consulta le seguenti guida:

Dashboard della conformità GKE

La dashboard Conformità di GKE fornisce insight strategici per a rafforzare il livello di sicurezza e ad automatizzare i report di conformità per benchmark e standard di settore. Puoi registrare il tuo cluster GKE per abilitare report automatici sulla conformità.

Per ulteriori informazioni, vedi Informazioni sulla dashboard di conformità GKE.

Considerazioni sulla sicurezza dell'apprendimento federato

Nonostante il suo rigoroso modello di condivisione dei dati, l'apprendimento federato non è intrinsecamente essere protetti da tutti gli attacchi mirati, ed è quindi opportuno accettare questi rischi quando esegui il deployment di una delle architetture descritte in questo documento. Esiste anche il rischio di fughe di informazioni indesiderate sui modelli di ML o dati di addestramento. Ad esempio, un utente malintenzionato potrebbe compromettere intenzionalmente o più cicli dell'apprendimento federato, oppure eseguire un attacco a tempo (un tipo di attacco side-channel) per raccogliere informazioni sulle dimensioni dei set di dati di addestramento.

Le minacce più comuni nei confronti di un'implementazione dell'apprendimento federato sono i seguenti: che segue:

  • Memorizzazione intenzionale o non intenzionale dei dati di addestramento. Il tuo account federato dell’apprendimento dell’implementazione o che un aggressore potrebbe archiviare involontariamente dati in modi con cui potrebbe essere difficile lavorare. Un potrebbe essere in grado di raccogliere informazioni sul modello ML globale gli ultimi cicli dell'impegno di apprendimento federato mediante il reverse engineering e archiviare i dati archiviati.
  • Estrai informazioni dagli aggiornamenti del modello ML globale. Durante la sessione di apprendimento, un aggressore potrebbe effettuare il reverse engineering degli aggiornamenti Modello ML che il proprietario della federazione raccoglie dalle organizzazioni partecipanti e dispositivi.
  • Il proprietario della federazione potrebbe compromettere i round. Una federazione compromessa il proprietario potrebbe controllare un silo o un dispositivo disonesti e avviare un round impegno di apprendimento federato. Alla fine del round, il compromesso proprietario della federazione potrebbe essere in grado di raccogliere informazioni sugli aggiornamenti raccoglie da organizzazioni e dispositivi partecipanti legittimi confrontando questi aggiornamenti con quello prodotto dal silo rogue.
  • Le organizzazioni e i dispositivi partecipanti potrebbero compromettere il machine learning globale un modello di machine learning. Durante l’apprendimento federato, un utente malintenzionato potrebbe tentare di compromettere in modo dannoso le prestazioni, la qualità o l'integrità del un modello ML globale mediante aggiornamenti non autorizzati o irrilevanti.

Per contribuire a mitigare l’impatto delle minacce descritte in questa sezione, consigliamo di adottare le seguenti best practice:

  • Ottimizza il modello per ridurre al minimo la memorizzazione dei dati di addestramento.
  • Implementare meccanismi che tutelano la privacy.
  • Controlla regolarmente il modello ML globale, i modelli ML che intendi condividere i dati e l'infrastruttura di addestramento a raggiungere gli obiettivi di apprendimento federato.
  • Implementare un modello aggregazione sicura per elaborare i risultati dell'addestramento che le organizzazioni partecipanti produrre.
  • Genera e distribuisci in modo sicuro chiavi di crittografia dei dati utilizzando un infrastruttura a chiave pubblica.
  • Esegui il deployment dell'infrastruttura piattaforma di computing riservata.

I proprietari della federazione devono eseguire anche i seguenti passaggi aggiuntivi:

  • Verificare l'identità di ogni organizzazione partecipante e l'integrità di ogni silo nel caso di architetture multi-silo, e l'identità e all'integrità di ogni dispositivo nel caso di architetture cross-device.
  • Limita l'ambito degli aggiornamenti al modello ML globale a cui il partecipante che organizzazioni e dispositivi possono produrre.

Affidabilità

Questa sezione descrive i fattori di progettazione da prendere in considerazione quando utilizzi una delle architetture di riferimento presenti in questo documento per progettare e creare una piattaforma di apprendimento federata su Google Cloud.

Durante la progettazione della tua architettura di apprendimento federato su Google Cloud, consigliamo di seguire le indicazioni di questa sezione per migliorare la disponibilità e la scalabilità del carico di lavoro, oltre a rendere la tua architettura resiliente a interruzioni e disastri.

GKE: GKE supporta diverse diversi tipi di cluster che puoi personalizzare in base ai requisiti di disponibilità ai tuoi carichi di lavoro e al tuo budget. Ad esempio, puoi creare cluster a livello di regione che distribuiscono il piano di controllo e i nodi tra diverse zone all'interno di un di regione o di zona che hanno il piano di controllo e i nodi in un zona di destinazione. Sia le architetture di riferimento cross-silo che cross-device si basano cluster GKE. Per ulteriori informazioni sugli aspetti da considerare durante la creazione per i cluster GKE, consulta scelte di configurazione del cluster.

A seconda del tipo di cluster e di come sono i nodi del piano di controllo e del cluster distribuiti tra regioni e zone, GKE offre diverse di ripristino di emergenza per proteggere i carichi di lavoro a livello di regione. Per ulteriori informazioni sull'emergenza di GKE per il ripristino di emergenza, Architecting ripristino di emergenza in caso di interruzioni dell'infrastruttura cloud: Google Kubernetes Engine.

Google Cloud Load Balancing: GKE supporta diverse per bilanciare il carico del traffico verso i carichi di lavoro. Lo strumento GKE delle implementazioni Gateway Kubernetes e Servizio Kubernetes Le API consentono di eseguire automaticamente il provisioning Cloud Load Balancing per esporre in modo sicuro e affidabile i carichi di lavoro in esecuzione cluster GKE.

In queste architetture di riferimento, tutto il traffico in entrata e in uscita passa attraverso o i gateway di Cloud Service Mesh. Questi gateway consentono di controllare rigorosamente come fluisce il traffico all'interno e all'esterno dei tuoi cluster GKE.

Sfide di affidabilità per l'apprendimento federato cross-device

L'apprendimento federato cross-device presenta una serie di sfide di affidabilità che non riscontrati in scenari multi-silo. Di seguito sono elencati alcuni esempi:

  • Connettività del dispositivo inaffidabile o intermittente
  • Spazio di archiviazione limitato sul dispositivo
  • Computing e memoria limitati

Una connettività inaffidabile può causare problemi quali:

  • Aggiornamenti obsoleti e divergenza dei modelli: in caso di problemi con i dispositivi la connettività è intermittente, gli aggiornamenti del modello locale potrebbero diventare inattivi, che rappresentano informazioni obsolete rispetto allo stato attuale dei globale. L'aggregazione degli aggiornamenti inattivi può portare a differenze nel modello, dove il modello globale si discosta dalla soluzione ottimale a causa di incoerenze durante il processo di addestramento.
  • Contributi sbilanciati e modelli distorti: comunicazione intermittente può comportare una distribuzione non uniforme dei contributi della partecipazione dispositivi mobili. I dispositivi con connettività scadente potrebbero contribuire a un numero inferiore di aggiornamenti. generando una rappresentazione sbilanciata dei dati sottostanti distribuzione dei contenuti. Questo squilibrio può influenzare il modello globale da dispositivi con connessioni più affidabili.
  • Aumento dell'overhead di comunicazione e consumo energetico: intermittente la comunicazione può comportare un aumento dell'overhead di comunicazione, dato che i dispositivi inviare di nuovo gli aggiornamenti persi o danneggiati. Questo problema può anche aumentare il consumo energetico dei dispositivi, in particolare per quelli con una durata limitata della batteria, potrebbero dover mantenere le connessioni attive per periodi più lunghi la corretta trasmissione degli aggiornamenti.

Per ridurre alcuni degli effetti causati da una comunicazione intermittente, architetture di riferimento di questo documento possono essere utilizzate con il FCP.

Un'architettura di sistema che esegue il protocollo FCP può essere progettata per soddisfare i seguenti requisiti:

  • Affronta colpi di corsa lunghi.
  • Abilita l'esecuzione speculativa (i turni possono iniziare prima della richiesta numero di clienti è riunito in previsione di altri controlli a breve).
  • Consenti ai dispositivi di scegliere le attività a cui vogliono partecipare. Questo approccio abilitare funzionalità come il campionamento senza sostituzione, una strategia di campionamento in cui ogni unità campione di una popolazione ha una sola possibilità da selezionare. Questo approccio aiuta a mitigare lo squilibrio contributi e modelli parziali
  • Estensibile per tecniche di anonimizzazione come la privacy differenziale (DP) e l'aggregazione attendibile (TAG).

Per contribuire a mitigare le capacità limitate di calcolo e spazio di archiviazione del dispositivo, quanto segue tecniche possono aiutare:

  • Qual è la capacità massima disponibile per eseguire l'istanza federata computing per l'apprendimento
  • Comprendere quanti dati possono essere conservati in un determinato momento
  • Progettare il codice di apprendimento federato lato client per funzionare all'interno e RAM disponibili sui client
  • Comprendere le implicazioni dell'esaurimento dello spazio di archiviazione e dell'implementazione per la gestione

Ottimizzazione dei costi

Questa sezione fornisce indicazioni per ottimizzare i costi di creazione ed esecuzione piattaforma di apprendimento federata su Google Cloud che stabilisci utilizzando per questa architettura di riferimento. Queste linee guida valgono per entrambe le architetture descritti in questo documento.

L'esecuzione di carichi di lavoro su GKE può aiutarti a rendere con un'ottimizzazione dei costi più ampia mediante il provisioning e la configurazione dei cluster in base ai carichi di lavoro requisiti delle risorse. Inoltre, abilita le funzionalità che riconfigurano dinamicamente i cluster e i nodi cluster, ad esempio la scalabilità automatica di nodi e pod del cluster e il dimensionamento corretto cluster.

Per ulteriori informazioni sull'ottimizzazione dei costi di GKE ambienti, consulta Best practice per l'esecuzione di applicazioni Kubernetes con ottimizzazione dei costi su GKE.

Efficienza operativa

Questa sezione descrive i fattori da prendere in considerazione per ottimizzare efficienza quando utilizzi questa architettura di riferimento per creare ed eseguire la piattaforma di apprendimento federata su Google Cloud. Queste linee guida si applicano entrambe le architetture descritte in questo documento.

Per aumentare l'automazione e il monitoraggio dell'apprendimento federato ti consigliamo di adottare i principi MLOps, ossia DevOps nel contesto dei sistemi di machine learning. Mettere in pratica i mezzi MLOps sostieni per l'automazione e il monitoraggio in tutte le fasi del sistema ML creazione, tra cui integrazione, test, rilascio, deployment per la gestione dell'infrastruttura. Per ulteriori informazioni su MLOps, consulta MLOps: pipeline di distribuzione continua e automazione nel machine learning.

Ottimizzazione delle prestazioni

Questa sezione descrive i fattori da prendere in considerazione per ottimizzare il rendimento dei tuoi carichi di lavoro quando utilizzi questa architettura di riferimento per creare ed eseguire la piattaforma di apprendimento federata su Google Cloud. Queste linee guida si applicano entrambe le architetture descritte in questo documento.

GKE supporta diverse funzionalità per dimensionare e scalare manualmente l'ambiente GKE per soddisfare per soddisfare le esigenze dei tuoi carichi di lavoro ed evitare il provisioning eccessivo delle risorse. Ad esempio, puoi utilizza il motore per suggerimenti per generare insight e suggerimenti al fine di ottimizzare l'utilizzo delle risorse GKE.

Per quanto riguarda la scalabilità del tuo ambiente GKE, ti consigliamo di elaborare piani a breve, medio e lungo termine in base alle tue intenzioni per scalare ambienti e carichi di lavoro. Ad esempio, in che modo intendi far crescere la tua presenza GKE in settimane, mesi e anni? Avere un piano pronto ti aiuta a sfruttare al meglio la scalabilità fornite da GKE, ottimizza le tue ambienti GKE e ridurre i costi. Per ulteriori informazioni sulla pianificazione della scalabilità del cluster e del carico di lavoro, vedi Informazioni sulla scalabilità di GKE.

Per aumentare le prestazioni dei tuoi carichi di lavoro ML, puoi adottare Unità di elaborazione Cloud Tensor (Cloud TPU), acceleratori AI progettati da Google e ottimizzati per l'addestramento e l'inferenza dei modelli AI di grandi dimensioni.

Deployment

Per eseguire il deployment delle architetture di riferimento cross-silo e cross-device che descrive il documento, consulta Apprendimento federato su Google Cloud GitHub di ASL.

Passaggi successivi

Collaboratori

Autori:

Altri collaboratori: