Apprendimento federato tra silos e dispositivi su Google Cloud

Last reviewed 2024-06-03 UTC

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

  • Apprendimento federato cross-silo
  • Apprendimento federato cross-device, basato sull'architettura cross-silo

I destinatari di questo documento sono architetti cloud e ingegneri AI e ML che vogliono implementare casi d'uso di apprendimento federato suGoogle Cloud. È inoltre destinato ai responsabili delle decisioni che stanno valutando se implementare l'apprendimento federato su Google Cloud.

Architettura

I diagrammi in questa sezione mostrano un'architettura cross-silo e un'architettura cross-device per l'apprendimento federato. Per scoprire le diverse applicazioni di queste architetture, consulta la sezione Casi d'uso.

Architettura cross-silo

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

Architettura cross-silo, componenti descritti nel testo seguente.

Il diagramma precedente mostra un esempio semplificato di un'architettura cross-silo. Nel diagramma, tutte le risorse si trovano nello stesso progetto di un'organizzazione Google Cloud. Queste risorse includono il modello client locale, il modello client globale e i relativi carichi di lavoro di apprendimento federato.

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

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

Per collaborare, i membri partecipanti devono stabilire canali di comunicazione sicuri tra i loro ambienti. Per saperne di più sul ruolo dei membri partecipanti nell'impegno di apprendimento federato, su come collaborano e su cosa condividono tra loro, consulta Casi d'uso.

L'architettura include i seguenti componenti:

  • Una rete Virtual Private Cloud (VPC) e una subnet.
  • Un cluster GKE privato che ti aiuta a svolgere le seguenti operazioni:
    • Isola i nodi del cluster da internet.
    • Limita l'esposizione a internet dei nodi e del control plane del cluster creando un cluster GKE privato con reti autorizzate.
    • Utilizza nodi del cluster protetti che utilizzano un'immagine del sistema operativo protetta.
    • Abilita Dataplane V2 per un networking Kubernetes ottimizzato.
  • Node pool GKE dedicati: crea un pool di nodi dedicato per ospitare esclusivamente app e risorse tenant. I nodi hanno taint per garantire che solo i carichi di lavoro tenant vengano pianificati sui nodi tenant. Le altre risorse del cluster sono ospitate nel pool di nodil principale.

  • Crittografia dei dati (abilitata per impostazione predefinita):

  • Crittografia dei dati in uso, attivando facoltativamente i nodi Confidential GKE.

  • Regole firewall VPC che applicano quanto segue:

    • Regole di base che si applicano a tutti i nodi nel cluster.
    • Regole aggiuntive che si applicano solo ai nodi nel pool di nodi tenant. Queste regole firewall limitano l'accesso in entrata e in uscita dai nodi tenant.

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

  • Record Cloud DNS per abilitare l'accesso privato Google in modo che le app all'interno del cluster possano accedere alle API di Google senza passare da internet.

  • Service account che sono i 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 workload.

  • Supporto per l'utilizzo di Google Gruppi per il controllo dell'accesso basato sui ruoli (RBAC) di Kubernetes.

  • Un repository Git per archiviare i descrittori di configurazione.

  • Un repository Artifact Registry per archiviare le immagini container.

  • Config Sync e Policy Controller per implementare la configurazione e i criteri.

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

  • Bucket Cloud Storage per archiviare i pesi dei modelli globali e locali.

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

Architettura cross-device

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

Architettura cross-device, componenti spiegati nel testo seguente.

L'architettura cross-device precedente si basa sull'architettura cross-silo con l'aggiunta dei seguenti componenti:

  • Un servizio Cloud Run che simula la connessione dei dispositivi al server
  • Un Certificate Authority Service che crea certificati privati per il server e i client da eseguire
  • Un 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 confidenziali come pool principale per proteggere i dati in uso

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

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

I componenti FCP mostrati nel diagramma precedente possono essere implementati come un insieme di microservizi. Questi componenti svolgono le seguenti funzioni:

  • Aggregatore: questo job legge i gradienti del dispositivo e calcola il risultato aggregato con la privacy differenziale.
  • Collector: questo job viene eseguito periodicamente per eseguire query sulle attività attive e sui gradienti criptati. Queste informazioni determinano l'inizio dell'aggregazione.
  • Caricatore di modelli: questo job ascolta gli eventi e pubblica i risultati in modo che i dispositivi possano scaricare i modelli aggiornati.
  • Assegnazione attività: questo servizio frontend distribuisce le attività di addestramento ai dispositivi.
  • Gestione delle attività: questo job gestisce le attività.
  • Task-scheduler: questo job viene eseguito periodicamente o viene attivato da eventi specifici.

Prodotti utilizzati

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

GKE fornisce anche le seguenti funzionalità alla tua piattaforma di apprendimento federato:

  • Hosting del coordinatore dell'apprendimento federato: il coordinatore dell'apprendimento federato è responsabile della gestione del processo di apprendimento federato. Questa gestione include attività come la distribuzione del modello globale ai partecipanti, l'aggregazione degli aggiornamenti dei partecipanti e l'aggiornamento del modello globale. GKE può essere utilizzato per ospitare il coordinatore dell'apprendimento federato in modo altamente disponibile e scalabile.
  • Hosting dei partecipanti all'apprendimento federato: i partecipanti all'apprendimento federato sono responsabili dell'addestramento del modello globale sui propri dati locali. GKE può essere utilizzato per ospitare i partecipanti all'apprendimento federato in modo sicuro e isolato. Questo approccio può contribuire a garantire che i dati dei partecipanti rimangano locali.
  • Fornire un canale di comunicazione sicuro e scalabile: i partecipanti all'apprendimento federato devono essere in grado di comunicare con il coordinatore dell'apprendimento federato in modo sicuro e scalabile. GKE può essere utilizzato per fornire un canale di comunicazione sicuro e scalabile tra i partecipanti e il coordinatore.
  • Gestione del ciclo di vita dei deployment di apprendimento federato: GKE può essere utilizzato per gestire il ciclo di vita dei deployment di apprendimento federato. Questa gestione include attività come il provisioning delle risorse, il deployment della piattaforma di apprendimento federato e il monitoraggio delle prestazioni della piattaforma di apprendimento federato.

Oltre a questi vantaggi, GKE offre anche una serie di funzionalità che possono essere utili per le implementazioni di apprendimento federato, ad esempio le seguenti:

  • Cluster regionali: GKE consente di creare cluster regionali, contribuendo a migliorare le prestazioni delle implementazioni di apprendimento federato riducendo la latenza tra i partecipanti e il coordinatore.
  • Norme di rete: GKE consente di creare norme di rete, contribuendo a migliorare la sicurezza delle implementazioni di apprendimento federato controllando il flusso di traffico tra i partecipanti e il coordinatore.
  • Bilanciamento del carico: GKE offre una serie di opzioni di bilanciamento del carico, contribuendo a migliorare la scalabilità dei deployment di apprendimento federato distribuendo il traffico tra i partecipanti e il coordinatore.

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

  • La possibilità di esprimere in modo dichiarativo i calcoli federati, ovvero un insieme di passaggi di elaborazione eseguiti su un server e un insieme di client. Questi calcoli possono essere implementati 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 dei client partecipanti. È particolarmente adatta ai casi d'uso in cui i dati sono relativamente omogenei e il modello non è troppo complesso. I casi d'uso tipici sono i seguenti:
      • Consigli personalizzati: un'azienda può utilizzare la media federata per addestrare un modello che consiglia prodotti agli utenti in base alla loro cronologia degli acquisti.
      • Rilevamento di frodi: un consorzio di banche può utilizzare la media federata per addestrare un modello che rileva le transazioni fraudolente.
      • Diagnosi medica: un gruppo di ospedali può utilizzare la media federata per addestrare un modello che diagnostica il cancro.
    • Discesa stocastica del gradiente federato (FedSGD): un algoritmo che utilizza la discesa stocastica del gradiente per aggiornare i parametri del modello. È ideale per i casi d'uso in cui i dati sono eterogenei e il modello è complesso. I casi d'uso tipici sono i seguenti:
      • Elaborazione del linguaggio naturale: un'azienda può utilizzare FedSGD per addestrare un modello che migliora l'accuratezza del riconoscimento vocale.
      • Riconoscimento delle immagini: un'azienda può utilizzare FedSGD per addestrare un modello in grado di identificare gli oggetti nelle immagini.
      • Manutenzione predittiva: un'azienda può utilizzare FedSGD per addestrare un modello che preveda quando è probabile che una macchina si guasti.
    • Federated Adam: Un algoritmo che utilizza l'ottimizzatore Adam per aggiornare i parametri del modello. I casi d'uso tipici sono i seguenti:
      • Sistemi di raccomandazione: un'azienda può utilizzare l'algoritmo federato Adam per addestrare un modello che consiglia prodotti agli utenti in base alla loro cronologia degli acquisti.
      • Ranking: un'azienda può utilizzare Adam federato per addestrare un modello che classifica i 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 per i quali le architetture cross-silo e cross-device sono scelte appropriate per la tua piattaforma di apprendimento federato.

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

Nel paradigma dell'apprendimento federato, i client scaricano un modello globale e lo migliorano addestrandolo localmente sui propri dati. Poi, ogni client invia gli aggiornamenti del modello calcolati al server centrale, dove vengono aggregati e viene generata una nuova iterazione del modello globale. In queste architetture di riferimento, i carichi di lavoro di addestramento del modello vengono eseguiti su GKE.

L'apprendimento federato incarna il principio di minimizzazione dei dati per la privacy, limitando i dati raccolti in ogni fase del calcolo, limitando l'accesso ai dati ed elaborandoli e scartandoli il prima possibile. Inoltre, l'impostazione del problema dell'apprendimento federato è compatibile con tecniche aggiuntive per la tutela della privacy, come l'utilizzo della privacy differenziale (DP) per migliorare l'anonimizzazione del modello per garantire che il modello finale non memorizzi i dati dei singoli utenti.

A seconda del caso d'uso, l'addestramento dei modelli con l'apprendimento federato può avere vantaggi aggiuntivi:

  • Conformità: in alcuni casi, le normative potrebbero limitare le modalità di utilizzo o condivisione dei dati. L'apprendimento federato potrebbe essere utilizzato per rispettare questi regolamenti.
  • Efficienza della comunicazione: in alcuni casi, è più efficiente addestrare un modello su dati distribuiti che centralizzare i dati. Ad esempio, i set di dati su cui deve essere addestrato il modello sono troppo grandi per essere spostati centralmente.
  • 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: l'addestramento sui dati reali degli utenti (garantendo al contempo la privacy) anziché sui dati sintetici (a volte chiamati dati proxy) spesso comporta una maggiore accuratezza del modello.

Esistono diversi tipi di apprendimento federato, caratterizzati da dove hanno origine i dati e dove vengono eseguiti i calcoli locali. Le architetture descritte in questo documento si concentrano su due tipi di apprendimento federato: cross-silo e cross-device. Altri tipi di apprendimento federato non rientrano nell'ambito di questo documento.

L'apprendimento federato è ulteriormente classificato in base al modo in cui vengono partizionati i set di dati, che può essere il seguente:

  • Apprendimento federato orizzontale (HFL): set di dati con le stesse funzionalità (colonne) ma campioni diversi (righe). Ad esempio, più ospedali potrebbero avere cartelle cliniche con gli stessi parametri medici, ma popolazioni di pazienti diverse.
  • Apprendimento federato verticale (VFL): set di dati con gli stessi campioni (righe) ma caratteristiche (colonne) diverse. Ad esempio, una banca e un'azienda di e-commerce potrebbero avere dati dei clienti con persone che si sovrappongono, ma informazioni finanziarie e di acquisto diverse.
  • Federated Transfer Learning (FTL): sovrapposizione parziale sia nei campioni che nelle funzionalità tra i set di dati. Ad esempio, due ospedali potrebbero avere cartelle cliniche di pazienti con alcune persone in comune e alcuni parametri medici condivisi, ma anche caratteristiche uniche in ogni set di dati.

Il calcolo federato cross-silo si verifica quando i membri partecipanti sono organizzazioni o aziende. In pratica, il numero di membri è solitamente ridotto (ad esempio, entro cento membri). Il calcolo cross-silo viene in genere utilizzato in scenari in cui le organizzazioni partecipanti hanno set di dati diversi, ma vogliono addestrare un modello condiviso o analizzare i risultati aggregati senza condividere i dati non elaborati tra loro. Ad esempio, i membri partecipanti possono avere i loro ambienti in organizzazioni Google Cloud diverse, ad esempio quando rappresentano persone giuridiche diverse, o nella stessa organizzazioneGoogle Cloud , ad esempio quando rappresentano reparti diversi della stessa persona giuridica.

I membri partecipanti potrebbero non essere in grado di considerare i carichi di lavoro degli altri come entità attendibili. Ad esempio, un membro partecipante potrebbe non avere accesso al codice sorgente di un carico di lavoro di addestramento che riceve da una terza parte, come il coordinatore. Poiché non può accedere a questo codice sorgente, il membro partecipante non può garantire che il carico di lavoro sia completamente attendibile.

Per impedire a un workload non attendibile di accedere ai tuoi dati o alle tue risorse senza autorizzazione, ti consigliamo di procedere nel seguente modo:

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

Per aiutarti a isolare i carichi di lavoro potenzialmente non attendibili, queste architetture di riferimento implementano controlli di sicurezza, ad esempio la configurazione di spazi dei nomi Kubernetes isolati, in cui ogni spazio dei nomi ha un pool di nodi GKE dedicato. La comunicazione tra spazi dei nomi e il traffico in entrata e in uscita del cluster sono vietati per impostazione predefinita, a meno che tu non esegua l'override esplicito di questa impostazione.

Di seguito sono riportati alcuni esempi di casi d'uso per l'apprendimento federato cross-silo:

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

L'apprendimento federato cross-device è un tipo di calcolo federato in cui i membri partecipanti sono dispositivi degli utenti finali, come cellulari, veicoli o dispositivi IoT. Il numero di abbonati può raggiungere una scala di milioni o addirittura decine di milioni.

Il processo di apprendimento federato cross-device è simile a quello dell'apprendimento federato cross-silo. Tuttavia, richiede anche di adattare l'architettura di riferimento per tenere conto di alcuni fattori aggiuntivi da considerare quando si ha a che fare con migliaia o milioni di dispositivi. Devi implementare carichi di lavoro amministrativi per gestire gli scenari che si verificano nei casi d'uso dell'apprendimento federato cross-device. Ad esempio, la necessità di coordinare un sottoinsieme di clienti che parteciperanno al ciclo di addestramento. L'architettura cross-device fornisce questa funzionalità consentendoti di eseguire il deployment dei servizi FCP. Questi servizi hanno carichi di lavoro con punti di connessione con TFF. TFF viene utilizzato per scrivere il codice che gestisce questa coordinazione.

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

  • Suggerimenti personalizzati: puoi utilizzare l'apprendimento federato cross-device per addestrare un modello di suggerimenti personalizzati 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 alla loro cronologia acquisti.
  • Elaborazione del linguaggio naturale: l'apprendimento federato può essere utilizzato per addestrare un modello di elaborazione del linguaggio naturale su dati distribuiti su più dispositivi. Ad esempio, un'azienda potrebbe utilizzare l'apprendimento federato per addestrare un modello che migliora l'accuratezza del riconoscimento vocale.
  • Previsione delle esigenze di manutenzione del veicolo: il Federated Learning può essere utilizzato per addestrare un modello che prevede quando è probabile che un veicolo necessiti di manutenzione. Questo modello potrebbe essere addestrato su dati raccolti da più veicoli. Questo approccio consente al modello di apprendere dalle esperienze di tutti i veicoli, senza compromettere la privacy di nessun veicolo in particolare.

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

Funzionalità Calcoli federati cross-silo Calcoli federati cross-device
Dimensioni della popolazione Di solito di piccole dimensioni (ad esempio, entro cento dispositivi) Scalabile a migliaia, milioni o centinaia di milioni di dispositivi
Membri partecipanti Organizzazioni o società 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 parte dei partecipanti è disponibile in un determinato momento
Esempi di casi d'uso Rilevamento di frodi, diagnosi mediche, previsioni finanziarie Monitoraggio del fitness, riconoscimento vocale, classificazione delle immagini

Considerazioni sulla progettazione

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

Considerazioni sulla progettazione dell'architettura cross-silo

Per implementare un'architettura di apprendimento federato cross-silo in Google Cloud, devi implementare i seguenti prerequisiti minimi, che sono spiegati in modo più dettagliato nelle sezioni seguenti:

  1. Crea un consorzio di 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, il proprietario della federazione deve intraprendere altre azioni che non rientrano nell'ambito di questo documento, ad esempio:

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

Creare un consorzio di apprendimento federato

Un consorzio di apprendimento federato è il gruppo di organizzazioni che partecipano a un'iniziativa di apprendimento federato cross-silo. Le organizzazioni del consorzio condividono solo i parametri dei modelli di ML e puoi criptarli per aumentare la privacy. Se il consorzio di apprendimento federato lo consente, le organizzazioni possono anche aggregare dati che non contengono informazioni che consentono l'identificazione personale (PII).

Determinare un modello di collaborazione per il consorzio di apprendimento federato

Il consorzio di apprendimento federato può implementare diversi modelli di collaborazione, ad esempio:

  • Un modello centralizzato composto da una singola organizzazione di coordinamento, chiamata proprietario della federazione o orchestratore, e da un insieme di organizzazioni partecipanti o proprietari dei dati.
  • Un modello decentralizzato composto da organizzazioni che si coordinano come gruppo.
  • Un modello eterogeneo costituito da un consorzio di diverse organizzazioni partecipanti, ognuna delle quali apporta risorse diverse al consorzio.

Questo documento presuppone che il modello di collaborazione sia un modello centralizzato.

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à delle organizzazioni partecipanti.

Il proprietario della federazione deve anche eseguire le seguenti operazioni quando inizia a creare un consorzio di apprendimento federato:

  • Coordinare l'impegno di apprendimento federato.
  • Progetta e implementa il modello ML globale e i modelli ML da condividere con le organizzazioni partecipanti.
  • Definisci i round di apprendimento federato, ovvero l'approccio per l'iterazione del processo di addestramento ML.
  • Seleziona le organizzazioni partecipanti che contribuiscono a un determinato round di apprendimento federato. Questa selezione è chiamata coorte.
  • Progettare e implementare una procedura di verifica dell'appartenenza al consorzio per le organizzazioni partecipanti.
  • Aggiorna il modello ML globale e i modelli ML da condividere con le organizzazioni partecipanti.
  • Fornisci alle organizzazioni partecipanti gli strumenti per verificare che il consorzio di apprendimento federato soddisfi i requisiti di privacy, sicurezza e normativi.
  • Fornisci alle organizzazioni partecipanti canali di comunicazione sicuri e criptati.
  • Fornisci alle organizzazioni partecipanti tutti i dati aggregati non confidenziali necessari per completare ogni round di apprendimento federato.

Le organizzazioni partecipanti hanno le seguenti responsabilità:

  • Fornire e gestire un ambiente sicuro e isolato (un silo). Il silo è il luogo in cui le organizzazioni partecipanti archiviano i propri dati e in cui viene implementato l'addestramento del modello ML. Le organizzazioni partecipanti non condividono i propri dati con altre organizzazioni.
  • Addestra i modelli forniti dal proprietario della federazione utilizzando la propria infrastruttura di calcolo e i propri dati locali.
  • Condividi i risultati dell'addestramento del modello con il proprietario della federazione sotto forma di dati aggregati, dopo aver rimosso eventuali PII.

Il proprietario della federazione e le organizzazioni partecipanti possono utilizzare Cloud Storage per condividere modelli aggiornati e risultati dell'addestramento.

Il proprietario della federazione e le organizzazioni partecipanti perfezionano l'addestramento del modello ML finché il modello non soddisfa i loro requisiti.

Implementare l'apprendimento federato su Google Cloud

Dopo aver creato il consorzio di apprendimento federato e aver stabilito le modalità di collaborazione, consigliamo alle organizzazioni partecipanti di:

  1. Esegui il provisioning e configura l'infrastruttura necessaria per il consorzio di apprendimento federato.
  2. Implementa il modello di collaborazione.
  3. Avviare l'apprendimento federato.

Esegui il provisioning e la configurazione dell'infrastruttura per il consorzio di apprendimento federato

Durante il provisioning e la configurazione dell'infrastruttura per il consorzio di apprendimento federato, è responsabilità del proprietario della federazione creare e distribuire i workload che addestrano i modelli ML federati alle organizzazioni partecipanti. Poiché i workload sono stati creati e forniti da una terza parte (il proprietario della federazione), le organizzazioni partecipanti devono prendere precauzioni quando li implementano nei propri ambienti di runtime.

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

Implementare il modello di collaborazione

Una volta preparata l'infrastruttura del consorzio di apprendimento federato, il proprietario della federazione progetta e implementa i meccanismi che consentono alle organizzazioni partecipanti di interagire tra loro. L'approccio segue il modello di collaborazione che il proprietario della federazione ha scelto per il consorzio di apprendimento federato.

Inizia l'impegno di apprendimento federato

Dopo aver implementato il modello di collaborazione, il proprietario della federazione implementa il modello di ML globale per l'addestramento e i modelli di ML da condividere con l'organizzazione partecipante. Una volta pronti i modelli ML, il proprietario della federazione inizia il primo round dell'attività di apprendimento federato.

Durante ogni ciclo di apprendimento federato, il proprietario della federazione esegue le seguenti operazioni:

  1. Distribuisce i modelli ML da condividere con le organizzazioni partecipanti.
  2. Attende che le organizzazioni partecipanti forniscano i risultati dell'addestramento dei modelli ML condivisi dal proprietario della federazione.
  3. Raccoglie ed elabora i risultati dell'addestramento prodotti dalle organizzazioni partecipanti.
  4. Aggiorna il modello ML globale quando riceve risultati di addestramento appropriati dalle organizzazioni partecipanti.
  5. Aggiorna i modelli ML da condividere con gli altri membri del consorzio se applicabile.
  6. Prepara i dati di addestramento per il successivo round di apprendimento federato.
  7. Avvia il round successivo di apprendimento federato.

Sicurezza, privacy e conformità

Questa sezione descrive i fattori da considerare quando utilizzi questa architettura di riferimento per progettare e creare una piattaforma di apprendimento federato su Google Cloud. Queste indicazioni si applicano a entrambe le architetture descritte in questo documento.

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

Per aiutarti ad aumentare la sicurezza dei tuoi ambienti di apprendimento federato, queste architetture di riferimento configurano controlli di sicurezza GKE che si concentrano sull'infrastruttura dei tuoi ambienti. Questi controlli potrebbero non essere sufficienti a proteggerti dalle minacce specifiche per i tuoi carichi di lavoro e casi d'uso di apprendimento federato. Data la specificità di ogni carico di lavoro e caso d'uso di apprendimento federato, i controlli di sicurezza volti a proteggere l'implementazione dell'apprendimento federato non rientrano nell'ambito di questo documento. Per ulteriori informazioni ed esempi su queste minacce, consulta Considerazioni sulla sicurezza del Federated Learning.

Controlli di sicurezza di GKE

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

Sicurezza avanzata dei cluster GKE

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

Per ulteriori informazioni sulle impostazioni di sicurezza di GKE, vedi Rafforzare la sicurezza del cluster e Informazioni sulla dashboard della postura di sicurezza.

Regole firewall VPC

Le regole firewall VPC (Virtual Private Cloud) controllano il traffico consentito da o verso le VM di Compute Engine. Le regole ti consentono di filtrare il traffico con granularità VM, a seconda degli attributi del livello 4.

Crea un cluster GKE con le regole firewall del cluster GKE predefinite. Queste regole firewall consentono la comunicazione tra i nodi del cluster e il piano di controllo GKE, nonché tra i nodi e i pod del cluster.

Applichi regole firewall aggiuntive ai nodi nel pool di nodi tenant. Queste 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 dai nodi tenant viene negato. Tutto l'accesso in uscita richiesto deve essere configurato in modo esplicito. Ad esempio, crei regole firewall per consentire il traffico in uscita dai nodi tenant al piano di controllo GKE e alle API di Google utilizzando Private Google Access. Le regole firewall sono destinate ai nodi tenant utilizzando l'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, puoi delegare la responsabilità amministrativa per le 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 control plane. Tuttavia, non forniscono isolamento dei nodi, del piano dati o della rete.

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

Queste architetture di riferimento ti aiutano a creare uno spazio dei nomi dedicato per ospitare le app di terze parti. Lo spazio dei nomi e le relative risorse vengono trattati come un tenant all'interno del cluster. Applichi criteri e controlli allo spazio dei nomi per limitare l'ambito delle risorse nello spazio dei nomi.

Criteri di rete

I criteri di rete applicano i flussi di traffico di rete di livello 4 utilizzando regole firewall a livello di pod. Le policy di rete sono ambito di uno spazio dei nomi.

Nelle architetture di riferimento descritte in questo documento, applichi i criteri di rete 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. Il traffico richiesto deve essere aggiunto esplicitamente a una lista consentita. Ad esempio, le norme di rete in queste architetture di riferimento consentono esplicitamente il traffico verso i servizi del cluster richiesti, come il DNS interno del cluster e il piano di controllo di Cloud Service Mesh.

Config Sync

Config Sync mantiene i cluster GKE sincronizzati con le configurazioni archiviate in un repository Git. Il repository Git funge da unica fonte attendibile per la configurazione e le policy del cluster. Config Sync è dichiarativo. Controlla continuamente lo stato del cluster e applica lo stato dichiarato nel file di configurazione per implementare i criteri, il che contribuisce a prevenire la deriva della configurazione.

Installa Config Sync nel cluster GKE. Configura Config Sync per sincronizzare le configurazioni e i criteri dei cluster da un repository Cloud Source. Le risorse sincronizzate includono quanto segue:

  • Configurazione di Cloud Service Mesh a livello di cluster
  • Policy di sicurezza a livello di cluster
  • Configurazione e policy a livello di spazio dei nomi del tenant, incluse policy di rete, service account, regole RBAC e configurazione di Cloud Service Mesh

Policy Controller

Policy Controller di Google Kubernetes Engine (GKE) Enterprise è un controller di ammissione dinamico per Kubernetes che applica criteri basati su CustomResourceDefinition (CRD) eseguiti da Open Policy Agent (OPA).

I controller di ammissione sono plug-in Kubernetes che intercettano le richieste al server API Kubernetes prima che un oggetto venga reso persistente, ma dopo che la richiesta è stata autenticata e autorizzata. Puoi utilizzare i controller di ammissione per limitare l'utilizzo di un cluster.

Installa Policy Controller nel tuo cluster GKE. Queste architetture di riferimento includono policy di esempio per proteggere il cluster. Applichi automaticamente i criteri al cluster utilizzando Config Sync. Applichi i seguenti criteri:

Cloud Service Mesh

Cloud Service Mesh è un mesh di servizi che ti aiuta a semplificare la gestione delle comunicazioni sicure tra i servizi. Queste architetture di riferimento configurano Cloud Service Mesh in modo che esegua le seguenti operazioni:

  • Inserisce automaticamente i proxy sidecar.
  • Applica la 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 basati sull'identità del servizio anziché sull'indirizzo IP dei peer sulla rete.
  • Limita la comunicazione autorizzata tra i servizi nel mesh. Ad esempio, le app nello spazio dei nomi del tenant possono comunicare solo con le app nello stesso spazio dei nomi o con un insieme di host esterni noti.
  • Instrada tutto il traffico in entrata e in uscita attraverso i gateway mesh dove puoi applicare ulteriori controlli del traffico.
  • Supporta la comunicazione sicura tra i cluster.

Incompatibilità e affinità dei nodi

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

I nodi con taint respingono i pod. Kubernetes non pianificherà un pod su un nodo con incompatibilità a meno che il pod non abbia una tolleranza per l'incompatibilità. Puoi utilizzare le incompatibilità dei nodi per riservare i nodi per l'utilizzo solo da parte di determinati workload o tenant. Taint e tolleranze vengono spesso utilizzati nei cluster multi-tenant. Per saperne di più, consulta la documentazione relativa ai nodi dedicati con taint e tolleranze.

L'affinità dei nodi consente di limitare i pod ai nodi con etichette particolari. Se un pod ha un requisito di affinità nodo, Kubernetes non pianifica il pod su un nodo a meno che il nodo non abbia un'etichetta che corrisponda al requisito di affinità. Puoi utilizzare l'affinità nodo per assicurarti che i pod vengano pianificati sui nodi appropriati.

Puoi utilizzare le incompatibilità dei nodi e l'affinità dei nodi insieme per garantire che i pod dei carichi di lavoro tenant vengano pianificati esclusivamente sui nodi riservati al tenant.

Queste architetture di riferimento ti aiutano a 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 taint correlato al nome del tenant.
  • Applicando automaticamente la tolleranza e l'affinità del nodo appropriate a qualsiasi pod che abbia come target lo spazio dei nomi del tenant. Applichi la tolleranza e l'affinità utilizzando le mutazioni di Policy Controller.

Privilegio minimo

È una best practice di sicurezza adottare un principio del privilegio minimo per i tuoi Google Cloud progetti e risorse come i cluster GKE. Utilizzando questo approccio, le app eseguite all'interno del cluster e gli sviluppatori e gli operatori che utilizzano il cluster dispongono solo del set minimo di autorizzazioni richieste.

Queste architetture di riferimento ti aiutano a utilizzare i service account con privilegio minimo nei seguenti modi:

  • Ogni pool di nodi GKE riceve il proprio service account. Ad esempio, i nodi nel pool di nodi tenant utilizzano un service account dedicato. I service account dei nodi sono configurati con le autorizzazioni minime richieste.
  • Il cluster utilizza Workload Identity Federation for GKE per associare i service account Kubernetes ai service account Google. In questo modo, alle app tenant può essere concesso l'accesso limitato a qualsiasi API Google richiesta senza scaricare e archiviare una chiave del account di servizio. Ad esempio, puoi concedere all'account di servizio le autorizzazioni per leggere i dati da un bucket Cloud Storage.

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

  • Crea un ruolo Kubernetes RBAC di esempio con autorizzazioni limitate per gestire le app. Puoi concedere questo ruolo agli utenti e ai gruppi che gestiscono le app nello spazio dei nomi del tenant. Applicando questo ruolo limitato di utenti e gruppi, questi utenti hanno solo le autorizzazioni per modificare le risorse dell'app nello spazio dei nomi del tenant. Non dispongono delle autorizzazioni per modificare le risorse a livello di cluster o le impostazioni di sicurezza sensibili, come le policy Cloud Service Mesh.

Autorizzazione binaria

Autorizzazione binaria ti consente di applicare le policy che definisci in merito alle immagini container di cui viene eseguito il deployment nel tuo ambiente GKE. Autorizzazione binaria consente il deployment solo delle immagini container conformi ai criteri definiti. Non consente il deployment di altre immagini container.

In questa architettura di riferimento, l'autorizzazione binaria è abilitata con la sua configurazione predefinita. Per esaminare la configurazione predefinita di Autorizzazione binaria, consulta Esportare il file YAML dei criteri.

Per ulteriori informazioni su come configurare i criteri, consulta le seguenti indicazioni specifiche:

Verifica dell'attestazione tra organizzazioni

Puoi utilizzare Autorizzazione binaria per verificare le attestazioni generate da un firmatario di terze parti. Ad esempio, in un caso d'uso di apprendimento federato cross-silo, puoi verificare le attestazioni create da un'altra organizzazione partecipante.

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 le chiavi pubbliche che hai ricevuto dalla terza parte agli attestatori che hai creato.

Per saperne di più sulla creazione di attestatori, consulta le seguenti indicazioni specifiche:

Considerazioni sulla sicurezza dell'apprendimento federato

Nonostante il suo modello di condivisione dei dati rigoroso, l'apprendimento federato non è intrinsecamente sicuro contro tutti gli attacchi mirati e devi tenere conto di questi rischi quando implementi una delle architetture descritte in questo documento. Esiste anche il rischio di divulgazione involontaria di informazioni su modelli di ML o dati di addestramento dei modelli. Ad esempio, un malintenzionato potrebbe compromettere intenzionalmente il modello di ML globale o i round dell'impegno di apprendimento federato oppure potrebbe eseguire un attacco di temporizzazione (un tipo di attacco side-channel) per raccogliere informazioni sulle dimensioni dei set di dati di addestramento.

Le minacce più comuni contro un'implementazione dell'apprendimento federato sono le seguenti:

  • Memorizzazione intenzionale o involontaria dei dati di addestramento. L'implementazione dell'apprendimento federato o un utente malintenzionato potrebbe archiviare intenzionalmente o involontariamente i dati in modi difficili da gestire. Un malintenzionato potrebbe essere in grado di raccogliere informazioni sul modello ML globale o sulle sessioni precedenti dell'attività di apprendimento federato tramite il reverse engineering dei dati archiviati.
  • Estrai informazioni dagli aggiornamenti del modello ML globale. Durante l'impegno di apprendimento federato, un malintenzionato potrebbe eseguire il reverse engineering degli aggiornamenti al modello ML globale che il proprietario della federazione raccoglie dalle organizzazioni e dai dispositivi partecipanti.
  • Il proprietario della federazione potrebbe compromettere i round. Un proprietario della federazione compromesso potrebbe controllare un silo o un dispositivo non autorizzato e avviare un round di apprendimento federato. Al termine del round, il proprietario della federazione compromessa potrebbe essere in grado di raccogliere informazioni sugli aggiornamenti che raccoglie da organizzazioni e dispositivi partecipanti legittimi confrontando questi aggiornamenti con quello prodotto dal silo non autorizzato.
  • Le organizzazioni e i dispositivi partecipanti potrebbero compromettere il modello ML globale. Durante l'attività di apprendimento federato, un malintenzionato potrebbe tentare di influire in modo dannoso sul rendimento, sulla qualità o sull'integrità del modello di ML globale producendo aggiornamenti non autorizzati o irrilevanti.

Per contribuire a mitigare l'impatto delle minacce descritte in questa sezione, ti consigliamo le seguenti best practice:

  • Ottimizza il modello per ridurre al minimo la memorizzazione dei dati di addestramento.
  • Implementa meccanismi che tutelano la privacy.
  • Controlla regolarmente il modello ML globale, i modelli ML che intendi condividere, i dati di addestramento e l'infrastruttura che hai implementato per raggiungere i tuoi obiettivi di apprendimento federato.
  • Implementa un algoritmo di aggregazione sicura per elaborare i risultati dell'addestramento prodotti dalle organizzazioni partecipanti.
  • Genera e distribuisci in modo sicuro le chiavi di crittografia dei dati utilizzando un'infrastruttura a chiave pubblica.
  • Esegui il deployment dell'infrastruttura su una piattaforma Confidential Computing.

I proprietari della federazione devono inoltre svolgere i seguenti passaggi aggiuntivi:

  • Verifica l'identità di ogni organizzazione partecipante e l'integrità di ogni silo in caso di architetture cross-silo, nonché l'identità e l'integrità di ogni dispositivo in caso di architetture cross-device.
  • Limita l'ambito degli aggiornamenti al modello ML globale che le organizzazioni e i dispositivi partecipanti possono produrre.

Affidabilità

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

Quando progetti l'architettura di apprendimento federato su Google Cloud, ti consigliamo di seguire le indicazioni riportate in questa sezione per migliorare la disponibilità e la scalabilità del workload e rendere la tua architettura resiliente a interruzioni e disastri.

GKE: GKE supporta diversi tipi di cluster che puoi personalizzare in base ai requisiti di disponibilità dei tuoi carichi di lavoro e al tuo budget. Ad esempio, puoi creare cluster regionali che distribuiscono il control plane e i nodi in più zone all'interno di una regione oppure cluster di zona che hanno il control plane e i nodi in una singola zona. Le architetture di riferimento cross-silo e cross-device si basano su cluster GKE regionali. Per saperne di più sugli aspetti da considerare durante la creazione dei cluster GKE, consulta Scelte di configurazione del cluster.

A seconda del tipo di cluster e di come vengono distribuiti il control plane e i nodi del cluster tra regioni e zone, GKE offre diverse funzionalità di ripristino di emergenza per proteggere i tuoi carichi di lavoro da interruzioni a livello di zona e regionale. Per ulteriori informazioni sulle funzionalità di disaster recovery di GKE, consulta Progettazione ripristino di emergenza per interruzioni dell'infrastruttura cloud: Google Kubernetes Engine.

Google Cloud Load Balancing: GKE supporta diversi modi per bilanciare il carico del traffico verso i tuoi carichi di lavoro. Le implementazioni GKE delle API Kubernetes Gateway e Kubernetes Service ti consentono di eseguire il provisioning e la configurazione automatici di Cloud Load Balancing per esporre in modo sicuro e affidabile i carichi di lavoro in esecuzione nei cluster GKE.

In queste architetture di riferimento, tutto il traffico in entrata e in uscita passa attraverso i gateway Cloud Service Mesh. Questi gateway ti consentono di controllare con precisione il flusso di traffico all'interno e all'esterno dei cluster GKE.

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

L'apprendimento federato cross-device presenta una serie di problemi di affidabilità che non si verificano negli scenari cross-silo. Di seguito sono elencati alcuni esempi:

  • Connettività del dispositivo non affidabile o intermittente
  • Spazio di archiviazione del dispositivo limitato
  • Calcolo e memoria limitati

Una connettività inaffidabile può causare problemi come i seguenti:

  • Aggiornamenti obsoleti e divergenza del modello: quando i dispositivi riscontrano una connettività intermittente, gli aggiornamenti del modello locale potrebbero diventare obsoleti, rappresentando informazioni obsolete rispetto allo stato attuale del modello globale. L'aggregazione di aggiornamenti obsoleti può portare alla divergenza del modello, in cui il modello globale si discosta dalla soluzione ottimale a causa di incoerenze nel processo di addestramento.
  • Contributi sbilanciati e modelli distorti: la comunicazione intermittente può comportare una distribuzione non uniforme dei contributi dei dispositivi partecipanti. I dispositivi con connettività scarsa potrebbero contribuire con meno aggiornamenti, portando a una rappresentazione sbilanciata della distribuzione dei dati sottostanti. Questo squilibrio può distorcere il modello globale verso i dati dei dispositivi con connessioni più affidabili.
  • Maggiore overhead di comunicazione e consumo energetico: la comunicazione intermittente può comportare un maggiore overhead di comunicazione, in quanto i dispositivi potrebbero dover inviare nuovamente gli aggiornamenti persi o danneggiati. Questo problema può anche aumentare il consumo di energia sui dispositivi, soprattutto per quelli con autonomia limitata, in quanto potrebbero dover mantenere attive le connessioni per periodi più lunghi per garantire la trasmissione corretta degli aggiornamenti.

Per contribuire a mitigare alcuni degli effetti causati dalla comunicazione intermittente, le architetture di riferimento in questo documento possono essere utilizzate con FCP.

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

  • Gestisci i round di lunga durata.
  • Abilita l'esecuzione speculativa (i round possono iniziare prima che venga assemblato il numero richiesto di client in previsione di un numero maggiore di client a breve).
  • Consenti ai dispositivi di scegliere a quali attività partecipare. Questo approccio può attivare funzionalità come il campionamento senza reintegro, una strategia di campionamento in cui ogni unità campione di una popolazione ha una sola possibilità di essere selezionata. Questo approccio aiuta a mitigare i contributi non bilanciati e i modelli distorti.
  • Estensibile per tecniche di anonimizzazione come la privacy differenziale (DP) e l'aggregazione attendibile (TAG).

Per contribuire a mitigare le limitate capacità di archiviazione e di calcolo del dispositivo, possono essere utili le seguenti tecniche:

  • Comprendere qual è la capacità massima disponibile per eseguire il calcolo di apprendimento federato
  • Comprendere la quantità di dati che possono essere conservati in un determinato momento
  • Progetta il codice di apprendimento federato lato client in modo che funzioni entro i limiti di calcolo e RAM disponibili sui client.
  • Comprendere le implicazioni dell'esaurimento dello spazio di archiviazione e implementare la procedura per gestire questo problema

Ottimizzazione dei costi

Questa sezione fornisce indicazioni per ottimizzare il costo di creazione ed esecuzione della piattaforma di apprendimento federato su Google Cloud che stabilisci utilizzando questa architettura di riferimento. Queste indicazioni si applicano a entrambe le architetture descritte in questo documento.

L'esecuzione di carichi di lavoro su GKE può aiutarti a ottimizzare i costi del tuo ambiente eseguendo il provisioning e la configurazione dei cluster in base ai requisiti di risorse dei tuoi carichi di lavoro. Consente inoltre funzionalità che riconfigurano dinamicamente i cluster e i nodi del cluster, ad esempio il ridimensionamento automatico dei nodi del cluster e dei pod e il dimensionamento corretto dei cluster.

Per saperne di più sull'ottimizzazione dei costi degli ambienti GKE, consulta Best practice per l'esecuzione di applicazioni Kubernetes con ottimizzazione dei costi su GKE.

Efficienza operativa

Questa sezione descrive i fattori da considerare per ottimizzare l'efficienza quando utilizzi questa architettura di riferimento per creare ed eseguire una piattaforma di apprendimento federato su Google Cloud. Queste indicazioni si applicano a entrambe le architetture descritte in questo documento.

Per aumentare l'automazione e il monitoraggio dell'architettura di apprendimento federato, ti consigliamo di adottare i principi MLOps, ovvero i principi DevOps nel contesto dei sistemi di machine learning. Mettere in pratica le MLOps significa promuovere l'automazione e il monitoraggio in tutte le fasi di creazione del sistema ML, tra cui integrazione, test, rilascio, deployment e gestione dell'infrastruttura. Per saperne di più sulle MLOps, consulta MLOps: pipeline di distribuzione continua e automazione nel machine learning.

Ottimizzazione delle prestazioni

Questa sezione descrive i fattori da considerare per ottimizzare le prestazioni dei tuoi carichi di lavoro quando utilizzi questa architettura di riferimento per creare ed eseguire una piattaforma di apprendimento federato su Google Cloud. Queste indicazioni si applicano a entrambe le architetture descritte in questo documento.

GKE supporta diverse funzionalità per dimensionare e scalare automaticamente e manualmente l'ambiente GKE in modo da soddisfare le richieste dei tuoi carichi di lavoro e aiutarti a evitare il provisioning eccessivo delle risorse. Ad esempio, puoi utilizzare Recommender per generare approfondimenti e suggerimenti per ottimizzare l'utilizzo delle risorse GKE.

Quando pensi a come scalare l'ambiente GKE, ti consigliamo di progettare piani a breve, medio e lungo termine per il modo in cui intendi scalare gli ambienti e i carichi di lavoro. Ad esempio, come intendi aumentare la tua impronta GKE tra qualche settimana, mese e anno? Avere un piano pronto ti aiuta a sfruttare al meglio le funzionalità di scalabilità fornite da GKE, ottimizzare gli ambienti GKE e ridurre i costi. Per saperne di più sulla pianificazione della scalabilità di cluster e workload, consulta Informazioni sulla scalabilità di GKE.

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

Deployment

Per eseguire il deployment delle architetture di riferimento cross-silo e cross-device descritte in questo documento, consulta il repository GitHub di Federated Learning su Google Cloud.

Passaggi successivi

Collaboratori

Autori:

Altri collaboratori: