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

Last reviewed 2024-04-12 UTC

Questo documento descrive due architetture di riferimento che ti aiutano a creare una piattaforma di apprendimento federata su Google Cloud. Le architetture di riferimento e le risorse associate descritte in questo documento supportano quanto segue:

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

I destinatari di questo documento sono i Cloud Architect e gli ingegneri AI e ML che vogliono implementare casi d'uso di apprendimento federato su Google Cloud. È inoltre destinata ai responsabili delle decisioni che valutano 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 di più sulle diverse applicazioni per queste architetture, consulta Casi d'uso.

Architettura a più silos

Il seguente diagramma mostra un'architettura che supporta l'apprendimento federato tra più silos:

Architettura a più silo, componenti descritti nel testo che segue.

Il diagramma precedente mostra come un membro partecipante a un impegno di apprendimento federato può progettare un silo in un'organizzazione Google Cloud. Quando un membro partecipante esegue il deployment di questa architettura su Google Cloud, può collaborare con i membri partecipanti i cui silos possono essere organizzati come segue:

  • In Google Cloud, nella stessa organizzazione Google Cloud e nello stesso progetto Google Cloud.
  • In 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 stabilire canali di comunicazione sicuri tra i loro ambienti. Per saperne di più sul ruolo dei membri partecipanti allo sforzo di apprendimento federato, sulle modalità di collaborazione e su cosa condividono tra loro, consulta i 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 fare quanto segue:
    • Isolare i nodi del cluster da internet.
    • Limita l'esposizione a internet dei nodi del cluster e del piano di controllo creando un cluster GKE privato con reti autorizzate.
    • Utilizza nodi cluster schermati che utilizzano un'immagine del sistema operativo protetta.
    • Abilita Dataplane V2 per il networking Kubernetes ottimizzato.
    • Cripta i secret del cluster a livello di applicazione.
  • Pool di nodi GKE dedicati: crei un pool di nodi dedicato per ospitare esclusivamente app e risorse tenant. I nodi presentano incompatibilità per garantire che solo i carichi di lavoro tenant siano pianificati sui nodi tenant. Altre risorse del cluster sono ospitate nel pool di nodi principale.
  • Regole firewall VPC che applicano quanto segue:
    • Regole di riferimento 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 il traffico in entrata e in uscita dai nodi tenant.
  • Cloud NAT per consentire il traffico in uscita verso internet.
  • Cloud DNS registra l'accesso privato Google in modo che le app all'interno del cluster possano accedere alle API di Google senza passare su internet.
  • Account di servizio, 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 di Workload Identity.
  • Supporto per l'utilizzo del controllo degli controllo dell'accesso basato su ruoli (RBAC) di Google Gruppi per Kubernetes.
  • Un repository di codice sorgente Cloud per archiviare i descrittori di configurazione.
  • Un repository Artifact Registry per archiviare le immagini container.

Architettura cross-device

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

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

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

  • Un servizio Cloud Run che simula i dispositivi che si connettono al server
  • Un Certificate Authority Service che crea certificati privati per l'esecuzione del server e dei client
  • 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 proteggere i dati in uso

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

  • Codice client per la comunicazione con un server e l'esecuzione di attività sui dispositivi
  • Un protocollo per la comunicazione client-server
  • i punti di connessione con TensorFlow Federated per semplificare la definizione dei calcoli federati,

I componenti FCP mostrati nel diagramma precedente possono essere distribuiti come un insieme di microservizi. Questi componenti:

  • Aggregatore: questo job legge i gradienti del dispositivo e calcola i risultati aggregati con privacy differenziale.
  • Raccoglitore: questo job viene eseguito periodicamente per eseguire query sulle attività attive e su gradienti criptati. Queste informazioni determinano quando inizia l'aggregazione.
  • Caricatore modello: questo job ascolta gli eventi e pubblica i risultati in modo che i dispositivi possano scaricare i modelli aggiornati.
  • Assegnazione di attività: questo servizio frontend distribuisce le attività di addestramento ai dispositivi.
  • Gestione delle attività: questo job gestisce le attività.
  • Pianificazione delle attività: questo job viene eseguito periodicamente o viene attivato da eventi specifici.

Prodotti utilizzati

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

GKE fornisce inoltre le seguenti funzionalità alla tua piattaforma di apprendimento federata:

  • Ospitare il 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 usato per ospitare il coordinatore di apprendimento federato in modo altamente disponibile
  • Organizzazione di partecipanti all'apprendimento federato: i partecipanti all'apprendimento federato sono responsabili dell'addestramento del modello globale sui propri dati locali. GKE può essere usato per ospitare partecipanti all'apprendimento federato, in modo sicuro e isolato. Questo approccio contribuisce 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 federata e il monitoraggio delle prestazioni della piattaforma di apprendimento federata.

Oltre a questi vantaggi, GKE fornisce anche una serie di funzionalità che possono essere utili per i deployment di apprendimento federato, tra cui:

  • Cluster a livello di regione: GKE consente di creare cluster a livello di regione, contribuendo a migliorare le prestazioni dei deployment di apprendimento federato riducendo la latenza tra i partecipanti e il coordinatore.
  • Criteri di rete: GKE consente di creare criteri di rete, 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 offre una serie di opzioni di bilanciamento del carico, contribuendo a migliorare la scalabilità dei deployment dell'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 capacità di esprimere in modo dichiarativo calcoli federati, ovvero un insieme di fasi di elaborazione che vengono eseguite su un server e un insieme di client. Il deployment di questi calcoli può essere eseguito in ambienti di runtime diversi.
  • Gli aggregatori personalizzati possono essere creati utilizzando l'open source TFF.
  • Supporto per una serie di algoritmi di apprendimento federato, inclusi i seguenti algoritmi:
    • Media federata: un algoritmo che calcola la media dei parametri del modello dei client partecipanti. È particolarmente adatto per i casi d'uso in cui i dati sono relativamente omogenei e il modello non è troppo complesso. I casi d'uso tipici sono i seguenti:
      • Suggerimenti personalizzati: un'azienda può utilizzare la media federata per addestrare un modello che consiglia prodotti agli utenti in base alla loro cronologia 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ò usare la media federata per addestrare un modello che diagnostica il cancro.
    • Federated Stocasttic gradient Descent (FedSGD): un algoritmo che utilizza la discesa del gradiente stocastico per aggiornare i parametri del modello. È adatto a 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ò usare FedSGD per addestrare un modello che migliora l'accuratezza del riconoscimento vocale.
      • Riconoscimento delle immagini: un'azienda può usare FedSGD per addestrare un modello in grado di identificare gli oggetti nelle immagini.
      • Manutenzione predittiva: un'azienda può usare FedSGD per addestrare un modello che prevede i guasti di una macchina.
    • Federated Adam: un algoritmo che utilizza l'ottimizzatore di 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 prodotti agli utenti in base alla loro cronologia acquisti.
      • Ranking: un'azienda può utilizzare il ruolo federato Adam 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 un annuncio.

Casi d'uso

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

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

Nel paradigma dell'apprendimento federato, i clienti scaricano un modello globale e lo migliorano mediante l'addestramento locale sui loro dati. Quindi, ogni client invia gli aggiornamenti del modello calcolati di nuovo al server centrale, dove vengono aggregati gli aggiornamenti del modello e viene generata una nuova iterazione del modello globale. In queste architetture di riferimento, i carichi di lavoro di addestramento dei modelli vengono eseguiti su GKE.

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

A seconda del caso d'uso, l'addestramento di modelli con apprendimento federato può offrire ulteriori vantaggi:

  • Conformità: in alcuni casi, le normative potrebbero limitare il modo in cui i dati possono essere utilizzati o condivisi. L'apprendimento federato può essere utilizzato per rispettare queste normative.
  • 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 precisione del modello: l'addestramento si basa su dati utente reali (garantendo la privacy) anziché su dati sintetici (talvolta definiti dati proxy), comporta una maggiore precisione del modello.

Esistono diversi tipi di apprendimento federato, caratterizzato dall'origine dei dati e da dove avvengono i calcoli locali. Le architetture 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 i set di dati sono partizionati, che può essere come segue:

  • Apprendimento federato orizzontale (HFL): set di dati con le stesse caratteristiche (colonne) ma campioni diversi (righe). Ad esempio, più ospedali potrebbero avere cartelle di pazienti con gli stessi parametri medici ma popolazioni di pazienti diverse.
  • Apprendimento federato verticale (VFL): set di dati con gli stessi campioni (righe) ma funzionalità diverse (colonne). 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 di campioni e funzionalità tra i set di dati. Ad esempio, due ospedali potrebbero avere cartelle di pazienti con alcuni individui sovrapposti e alcuni parametri medici condivisi, ma anche caratteristiche uniche in ogni set di dati.

Il calcolo federato tra silos è il luogo in cui i membri partecipanti sono organizzazioni o aziende. In pratica, il numero di membri è solitamente piccolo (ad es. non più di cento). 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 risultati aggregati senza condividere tra loro i dati non elaborati. Per aiutarti a isolare i carichi di lavoro che appartengono a diverse organizzazioni partecipanti, l'architettura di riferimento tra silos implementa controlli di sicurezza, come spazi dei nomi dedicati e pool di nodi GKE. Le comunicazioni tra spazi dei nomi e il traffico in entrata e in uscita dei cluster sono vietati per impostazione predefinita, a meno che tu non esegua esplicitamente l'override di questa impostazione.

Di seguito sono riportati alcuni casi d'uso di esempio per l'apprendimento federato tra silos:

  • Rilevamento di frodi: l'apprendimento federato può essere utilizzato per addestrare un modello di rilevamento di attività fraudolente su dati distribuiti tra 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 sui dati distribuiti tra 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 membri può arrivare a milioni o persino decine di milioni.

Il processo per l'apprendimento federato cross-device è simile a quello dell'apprendimento federato cross-silo. Tuttavia, richiede anche di adattare l'architettura di riferimento per soddisfare alcuni dei fattori aggiuntivi da considerare quando si hanno a che fare con migliaia o milioni di dispositivi. Devi eseguire il deployment dei carichi di lavoro amministrativi per gestire gli scenari che si verificano nei casi d'uso di apprendimento federato cross-device. Ad esempio, la necessità di coordinare un sottoinsieme di client che avverrà durante la fase di addestramento. L'architettura cross-device offre questa capacità consentendoti di eseguire il deployment dei servizi FCP. Questi servizi includono carichi di lavoro che hanno punti di connessione con TFF. Il TFF viene usato per scrivere il codice che gestisce questo coordinamento.

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

  • Consigli 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 usare 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. Un'azienda potrebbe usare l'apprendimento federato per addestrare un modello che migliora l'accuratezza del riconoscimento vocale.
  • Previsione delle esigenze di manutenzione dei veicoli: l'apprendimento federato può essere usato per addestrare un modello che prevede quando è probabile che un veicolo abbia bisogno di manutenzione. Questo modello può 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 ogni singolo veicolo.

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

Selezione delle Calcoli federati tra silos Calcoli federati cross-device
Dimensione della popolazione Solitamente di piccole dimensioni (ad esempio, entro cento 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 medica, 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 di sicurezza, affidabilità, efficienza operativa, costi e prestazioni.

Considerazioni sulla progettazione dell'architettura cross-silo

Per implementare un'architettura di apprendimento federato tra silo in Google Cloud, devi implementare i seguenti prerequisiti minimi, descritti in maggiore dettaglio nelle sezioni seguenti:

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

Oltre a questi prerequisiti, il proprietario della federazione deve eseguire altre azioni che non rientrano nell'ambito di questo documento, tra cui:

  • Gestisci il Consorzio per l'apprendimento federato.
  • Progettare e implementare un modello di collaborazione.
  • Preparare, gestire e utilizzare i dati di addestramento del modello e il modello 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 per trasferire i dati in modo sicuro.

Istituire un consorzio di apprendimento federato

Un consorzio di apprendimento federato è un gruppo di organizzazioni che partecipa a un'iniziativa di apprendimento federata. Le organizzazioni del consorzio condividono solo i parametri dei modelli ML e tu puoi criptarli per aumentare la privacy. Se il Consorzio per l'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 per l'apprendimento federato

Il consorzio per l'apprendimento federato può implementare diversi modelli di collaborazione, come i seguenti:

  • Un modello centralizzato costituito da un'unica organizzazione di coordinamento, denominata proprietario della federazione o orchestratore, e 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, che portano tutte 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 inoltre procedere nel seguente modo quando inizia a creare un consorzio di apprendimento federato:

  • Coordina l'impegno di apprendimento federato.
  • Progettare e implementare il modello ML globale e i modelli ML da condividere con le organizzazioni partecipanti.
  • Definire i cicli di apprendimento federati, 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 è denominata coorte.
  • Progettare e implementare una procedura di verifica dell'appartenenza al consorzio per le organizzazioni partecipanti.
  • Aggiornare il modello ML globale e i modelli ML per condividerli con le organizzazioni partecipanti.
  • Fornire alle organizzazioni partecipanti gli strumenti per verificare che il consorzio per l'apprendimento federato soddisfi i loro requisiti di privacy, sicurezza e normative.
  • Fornire alle organizzazioni dei partecipanti canali di comunicazione sicuri e criptati.
  • Fornire alle organizzazioni partecipanti tutti i dati aggregati e non riservati necessari per completare ogni round di apprendimento federato.

Le organizzazioni partecipanti hanno le seguenti responsabilità:

  • Fornire e mantenere un ambiente sicuro e isolato (un silo). Questo silo è il luogo in cui le organizzazioni partecipanti archiviano i propri dati e in cui viene implementato l'addestramento del modello ML.
  • Addestra i modelli forniti dal proprietario della federazione utilizzando la propria infrastruttura di computing 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 perfezionano l'addestramento del modello ML fino a quando il modello non soddisfa i requisiti.

Implementare l'apprendimento federato su Google Cloud

Dopo aver istituito il consorzio per l'apprendimento federato e aver determinato le modalità di collaborazione, consigliamo alle organizzazioni partecipanti di procedere come segue:

  1. Provisioning e configurazione dell'infrastruttura necessaria per il consorzio di apprendimento federato.
  2. Implementa il modello di collaborazione.
  3. Avvia l'impegno di apprendimento federato.

Esegui il provisioning e la configurazione dell'infrastruttura per il consorzio per l'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 carichi di lavoro che addestrano i modelli ML federati alle organizzazioni partecipanti. Poiché una terza parte (il proprietario della federazione) ha creato e fornito i carichi di lavoro, le organizzazioni partecipanti devono adottare precauzioni quando eseguono il deployment di questi carichi di lavoro nei propri ambienti di runtime.

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

Implementare il modello di collaborazione

Dopo aver preparato 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.

Avvia l'impegno di apprendimento federato

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

Durante ogni fase dell'apprendimento federato, il proprietario della federazione procede nel seguente modo:

  1. Distribuisce i modelli ML da condividere con le organizzazioni dei 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 ricevono 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 la prossima fase di apprendimento federato.
  7. Avvia il prossimo round 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 federata su Google Cloud. Queste linee guida si applicano a entrambe le architetture descritte in questo documento.

I carichi di lavoro di apprendimento federato di cui 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 avere un impatto sulla tua attività.

Per aumentare la sicurezza dei tuoi ambienti di apprendimento federato, queste architetture di riferimento configurano i controlli di sicurezza di GKE incentrati sull'infrastruttura dei tuoi ambienti. Questi controlli potrebbero non essere sufficienti per proteggerti da minacce specifiche per i tuoi casi d'uso e i carichi di lavoro di apprendimento federato. Data la specificità di ogni caso d'uso e di ogni carico di lavoro 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 le considerazioni sulla sicurezza di Federated Learning.

Controlli di sicurezza di GKE

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

Sicurezza avanzata dei cluster GKE

Queste architetture di riferimento consentono di creare un cluster GKE che implementa le seguenti impostazioni di sicurezza:

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

Regole firewall VPC

Le regole firewall VPC (Virtual Private Cloud) regolano il traffico consentito dalle VM di Compute Engine. Le regole consentono di filtrare il traffico con granularità delle VM, a seconda degli attributi del livello 4.

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

Applicherai 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 è negato. Qualsiasi traffico in uscita richiesto deve essere configurato esplicitamente. 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 l'accesso privato Google. Le regole firewall vengono indirizzate 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. Se utilizzi gli spazi dei nomi, puoi delegare la responsabilità di amministrazione 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 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 le singole applicazioni. Ad esempio, puoi 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 per ospitare le app di terze parti. Lo spazio dei nomi e le relative risorse vengono trattati come tenant all'interno del cluster. Puoi applicare 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. I criteri di rete hanno come ambito uno spazio dei nomi.

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

Config Sync

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

Devi installare Config Sync nel tuo cluster GKE. Config Sync per sincronizzare configurazioni di cluster e criteri da un repository Cloud Source. Le risorse sincronizzate includono quanto segue:

  • Configurazione di Anthos Service Mesh a livello di cluster
  • Criteri di sicurezza a livello di cluster
  • Configurazione e criteri a livello di spazio dei nomi tenant, inclusi criteri di rete, account di servizio, regole RBAC

Policy Controller

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

I controller di ammissione sono plug-in Kubernetes che intercettano le richieste al server API di Kubernetes prima che un oggetto sia permanente, ma dopo che la richiesta viene autenticata e autorizzata. Puoi usare i controller di ammissione per limitare l'utilizzo di un cluster.

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

Anthos Service Mesh

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

  • Inserisci automaticamente i proxy collaterali.
  • Applica la comunicazione mTLS tra i servizi nel mesh.
  • Limita il traffico mesh in uscita solo agli host noti.
  • Limita solo il traffico in entrata da determinati client.
  • Consente di configurare criteri di sicurezza di rete in base all'identità del servizio anziché all'indirizzo IP dei peer sulla rete.
  • Limita le comunicazioni autorizzate tra i servizi nel mesh. Ad esempio, le app nello spazio dei nomi tenant possono comunicare soltanto 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 tramite gateway mesh, dove puoi applicare ulteriori controlli del traffico.

Incompatibilità e affinità dei nodi

Le incompatibilità dei nodi e l'affinità dei nodi sono meccanismi Kubernetes che consentono di influenzare il modo in cui i pod vengono pianificati sui nodi cluster.

I nodi danneggiati respingono i pod. Kubernetes non pianifica un pod su un nodo incompatibile, a meno che il pod non abbia una tolleranza per l'incompatibilità. Puoi utilizzare le incompatibilità dei nodi per prenotare i nodi in modo che vengano utilizzati solo da determinati carichi di lavoro o tenant. Incompatibilità e tolleranze sono spesso utilizzate nei cluster multi-tenant. Per ulteriori informazioni, consulta la documentazione relativa ai nodi dedicati con incompatibilità e tolleranze.

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

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

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

  • Creazione di un pool di nodi GKE dedicato al tenant. Ogni nodo del pool ha un'incompatibilità relativa al nome del tenant.
  • Applicazione automatica della tolleranza e dell'affinità dei nodi appropriate a qualsiasi pod che abbia come target lo spazio dei nomi tenant. Puoi applicare la tolleranza e l'affinità utilizzando le mutazioni di PolicyController.

Privilegio minimo

Una best practice per la sicurezza prevede l'adozione del principio del privilegio minimo per i progetti e le risorse Google Cloud come i cluster GKE. Utilizzando questo approccio, le app in esecuzione all'interno del cluster e gli sviluppatori e gli operatori che utilizzano il cluster 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 account di servizio. Ad esempio, i nodi nel pool di nodi tenant utilizzano un account di servizio dedicato a questi nodi. Gli account di servizio dei nodi sono configurati con le autorizzazioni minime richieste.
  • Il cluster utilizza Workload Identity per associare gli account di servizio Kubernetes agli account di servizio Google. In questo modo, è possibile concedere alle app tenant l'accesso limitato a qualsiasi API Google richiesta senza scaricare e archiviare una chiave dell'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 consentono di limitare l'accesso alle risorse del cluster nei modi seguenti:

  • Creerai 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 tenant. Se applichi questo ruolo limitato per utenti e gruppi, questi utenti dispongono solo delle autorizzazioni per modificare le risorse delle app nello spazio dei nomi del tenant. Non hanno le autorizzazioni per modificare risorse a livello di cluster o impostazioni di sicurezza sensibili come i criteri di Anthos Service Mesh.

Autorizzazione binaria

Autorizzazione binaria consente di applicare i criteri da te definiti per le immagini container di cui viene eseguito il deployment nel tuo ambiente GKE. Autorizzazione binaria consente il deployment solo delle immagini container conformi al criterio, altrimenti non ne è consentito.

In questa architettura di riferimento, 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 linee guida 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 dell'apprendimento federato tra più silos, puoi verificare le attestazioni create da un'altra organizzazione partecipante.

Per verificare le attestazioni create da una terza parte:

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

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

Dashboard per la conformità di GKE

La dashboard Conformità di GKE fornisce insight strategici per rafforzare la postura di sicurezza e consente di automatizzare i report sulla conformità per standard e benchmark di settore. Puoi registrare i tuoi cluster GKE per abilitare report di conformità automatici.

Per maggiori informazioni, consulta Informazioni sulla dashboard di conformità di GKE.

Considerazioni sulla sicurezza dell'apprendimento federato

Nonostante il rigoroso modello di condivisione dei dati, l'apprendimento federato non è intrinsecamente sicuro contro tutti gli attacchi mirati e dovresti prendere in considerazione 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 ML o sui dati di addestramento dei modelli. Ad esempio, un utente malintenzionato potrebbe compromettere intenzionalmente il modello ML globale o le serie di iniziative di 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 contro un'implementazione di apprendimento federato sono le seguenti:

  • Memorizzazione intenzionale o non intenzionale dei dati di addestramento. La tua implementazione di apprendimento federato o un utente malintenzionato potrebbero archiviare intenzionalmente o meno i dati in modi con cui potrebbe essere difficile lavorare. Un utente malintenzionato potrebbe riuscire a raccogliere informazioni sul modello ML globale o sui passaggi precedenti dell'apprendimento federato mediante il reverse engineering dei dati archiviati.
  • Estrarre informazioni dagli aggiornamenti al modello ML globale. Durante l'apprendimento federato, un utente malintenzionato potrebbe eseguire il reverse engineering degli aggiornamenti del modello ML globale che il proprietario della federazione raccoglie dalle organizzazioni e dai dispositivi dei partecipanti.
  • Il proprietario della federazione potrebbe compromettere i round. Il proprietario di una federazione compromesso potrebbe controllare un silo o un dispositivo non autorizzato e avviare una fase di apprendimento federato. Alla fine del round, il proprietario della federazione compromessa potrebbe essere in grado di raccogliere informazioni sugli aggiornamenti che raccoglie da dispositivi e organizzazioni legittime partecipanti confrontando questi aggiornamenti con quello prodotto dal silo non autorizzato.
  • Le organizzazioni e i dispositivi dei partecipanti potrebbero compromettere il modello ML globale. Durante l'impegno di apprendimento federato, un utente malintenzionato potrebbe tentare di influire in modo dannoso su prestazioni, qualità o integrità del modello ML globale producendo aggiornamenti irregolari o irrilevanti.

Per 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.
  • Implementare 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 di elaborazione riservata.

I proprietari di federazioni devono inoltre eseguire 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 di 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, ti consigliamo di seguire le indicazioni riportate in questa sezione per migliorare la disponibilità e la scalabilità del carico di lavoro e per 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 a livello di regione che distribuiscono il piano di controllo e i nodi in diverse zone all'interno di un'area geografica oppure cluster di zona che hanno il piano di controllo e i nodi in un'unica zona. Le architetture di riferimento cross-silo e cross-device si basano su cluster GKE a livello di regione. Per ulteriori informazioni 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 il piano di controllo e i nodi del cluster sono distribuiti 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 regione. Per ulteriori informazioni sulle funzionalità di ripristino di emergenza di GKE, consulta Architettura del ripristino di emergenza in caso di interruzioni dell'infrastruttura cloud: Google Kubernetes Engine.

Google Cloud Load Balancing: GKE supporta diversi modi per bilanciare il traffico verso i carichi di lavoro. Le implementazioni GKE delle API del gateway Kubernetes e del servizio Kubernetes consentono di eseguire automaticamente il provisioning e la configurazione 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 Anthos Service Mesh. Grazie a questi gateway, puoi controllare rigorosamente il flusso del 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 si incontrano in scenari cross-silo. Sono incluse le seguenti app:

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

Una connettività inaffidabile può causare problemi quali:

  • Aggiornamenti inattivi e divergenza dei modelli: quando i dispositivi riscontrano una connettività intermittente, gli aggiornamenti dei modelli locali potrebbero diventare obsoleti, rappresentando informazioni obsolete rispetto allo stato attuale del modello globale. L'aggregazione di aggiornamenti inattivi può portare a una 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 di parte: la comunicazione intermittente può comportare una distribuzione non uniforme dei contributi dei dispositivi partecipanti. I dispositivi con scarsa connettività potrebbero contribuire meno aggiornamenti, portando a una rappresentazione sbilanciata della distribuzione dei dati sottostante. Questo squilibrio può influenzare il modello globale in base ai dati provenienti da 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 di nuovo aggiornamenti persi o danneggiati. Questo problema può anche aumentare il consumo energetico dei dispositivi, in particolare quelli con una durata della batteria limitata, in quanto potrebbero dover mantenere connessioni attive per periodi più lunghi per garantire la trasmissione corretta degli aggiornamenti.

Per mitigare alcuni degli effetti causati da comunicazioni intermittenti, è possibile utilizzare le architetture di riferimento in questo documento con l'FCP.

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

  • Affronta i round più lunghi.
  • Abilita l'esecuzione speculativa (gli arrotondamenti possono iniziare prima che venga assemblato il numero di client richiesto in previsione di ulteriori verifiche abbastanza presto).
  • Consenti ai dispositivi di scegliere a quali attività vogliono partecipare. Questo approccio può attivare funzionalità come il campionamento senza sostituzione, ovvero 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 sbilanciati e i modelli
  • estendibile per tecniche di anonimizzazione come la privacy differenziale (DP) e l'aggregazione attendibile (TAG).

Per ridurre le capacità di calcolo e di archiviazione del dispositivo, puoi utilizzare le seguenti tecniche:

  • Scopri qual è la capacità massima disponibile per eseguire il calcolo dell'apprendimento federato
  • Comprendere la quantità di dati che possono essere conservati in un determinato momento
  • Progettare il codice di apprendimento federato lato client in modo che funzioni all'interno delle risorse di calcolo e RAM disponibili sui client
  • Comprendi le implicazioni dell'esaurimento dello spazio di archiviazione e implementa la procedura per

Ottimizzazione dei costi

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

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

Per ulteriori informazioni sull'ottimizzazione del costo 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 federata su Google Cloud. Queste indicazioni si applicano a entrambe le architetture descritte in questo documento.

Per aumentare l'automazione e il monitoraggio della tua architettura di apprendimento federato, ti consigliamo di adottare i principi MLOps, ovvero quelli DevOps nel contesto dei sistemi di machine learning. Praticare MLOps significa sostenere l'automazione e il monitoraggio in tutte le fasi di creazione di sistemi ML, tra cui integrazione, test, rilascio, deployment e 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 considerare per ottimizzare le prestazioni dei carichi di lavoro quando utilizzi questa architettura di riferimento per creare ed eseguire una piattaforma di apprendimento federata su Google Cloud. Queste indicazioni si applicano a entrambe le architetture descritte in questo documento.

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

Per la scalabilità del tuo ambiente GKE, ti consigliamo di progettare piani a breve, medio e lungo termine per la scalabilità dei tuoi ambienti e carichi di lavoro. Ad esempio, come intendi aumentare la tua presenza su GKE in settimane, mesi e anni? Avere un piano pronto ti consente di sfruttare al meglio le funzionalità di scalabilità offerte da GKE, di ottimizzare gli ambienti GKE e ridurre i costi. Per saperne di più sulla pianificazione della scalabilità dei cluster e dei carichi di lavoro, 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 di AI progettati da Google 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 Federated Learning on Google Cloud.

Passaggi successivi

Collaboratori

Autori:

Altri collaboratori: