Rinventare un’architettura di federated learning nativa del cloud su AWS

Rinventare una nativa architettura di federated learning del cloud su AWS

Il machine learning (ML), in particolare il deep learning, richiede una grande quantità di dati per migliorare le prestazioni del modello. Spesso i clienti hanno bisogno di addestrare un modello con dati provenienti da diverse regioni, organizzazioni o account AWS. Centralizzare tali dati per il ML è una sfida a causa dei requisiti di privacy, dell’alto costo del trasferimento dati o della complessità operativa.

Il federated learning (FL) è un approccio di ML distribuito che addestra i modelli di ML su dataset distribuiti. L’obiettivo del FL è migliorare l’accuratezza dei modelli di ML utilizzando più dati, preservando al contempo la privacy e la località dei dataset distribuiti. Il FL aumenta la quantità di dati disponibili per addestrare i modelli di ML, in particolare i dati associati a eventi rari e nuovi, ottenendo così un modello di ML più generale. Le soluzioni open-source partner esistenti per il FL su AWS includono FedML e NVIDIA FLARE. Questi pacchetti open-source vengono implementati nel cloud eseguendo macchine virtuali, senza utilizzare i servizi nativi del cloud disponibili su AWS.

In questo blog, imparerai come costruire un’architettura FL nativa del cloud su AWS. Utilizzando gli strumenti Infrastructure as Code (IaC) su AWS, puoi implementare facilmente architetture di FL. Inoltre, un’architettura nativa del cloud sfrutta appieno una varietà di servizi AWS con sicurezza comprovata e eccellenza operativa, semplificando così lo sviluppo di FL.

<p+parliamo GitHub. Utilizziamo l’AWS Cloud Development Kit (AWS CDK) per implementare l’architettura con un singolo clic. Il codice di esempio mostra uno scenario in cui il server e tutti i client appartengono alla stessa organizzazione (allo stesso account AWS), ma i loro dataset non possono essere centralizzati a causa dei requisiti di localizzazione dei dati. Il codice di esempio supporta FL orizzontale e sincrono per addestrare modelli di rete neurale. Il framework di ML utilizzato nei client FL è TensorFlow.

• I modelli di Whisper per il riconoscimento automatico del parlato sono ora disponibili su Amazon SageMaker JumpStart
• Una nuova ricerca sull’apprendimento automatico del MIT mostra come i modelli di linguaggio di grandi dimensioni (LLM) comprendano e rappresentino i concetti di spazio e tempo
• Domanda di più dai social con annunci alimentati dall’IA

Panoramica del federated learning

Il FL coinvolge tipicamente un server FL centrale e un gruppo di client. I client sono nodi di elaborazione che eseguono l’addestramento locale. In un round di addestramento FL, il server centrale invia prima un modello globale comune a un gruppo di client. I client addestrano il modello globale con i dati locali, quindi restituiscono al server i modelli locali. Il server aggrega i modelli locali in un nuovo modello globale, quindi avvia un nuovo round di addestramento. Potrebbero esserci decine di round di addestramento fino a quando il modello globale converge o fino a quando il numero di round di addestramento raggiunge una soglia. Pertanto, il FL scambia modelli di ML tra il server FL centrale e i client, senza spostare i dati di addestramento in una posizione centrale.

Ci sono due categorie principali di FL a seconda del tipo di client: FL cross-device e FL cross-silo. Il FL cross-device addestra modelli globali comuni mantenendo tutti i dati di addestramento localmente su un gran numero di dispositivi, come telefoni cellulari o dispositivi IoT, con connessioni di rete limitate e instabili. Pertanto, il design del FL cross-device deve considerare l’adesione frequente e l’abbandono dei client FL.

Il FL cross-silo addestra un modello globale su dataset distribuiti in diverse organizzazioni e centri dati geo-distribuiti. Questi dataset sono proibiti di spostarsi al di fuori delle organizzazioni e delle regioni dei centri dati a causa di regolamenti sulla protezione dei dati, sfide operative (come duplicazione e sincronizzazione dei dati) o costi elevati. A differenza del FL cross-device, il FL cross-silo presume che le organizzazioni o i centri dati abbiano connessioni di rete affidabili, risorse di calcolo potenti e dataset indirizzabili.

Il FL è stato applicato a vari settori, come finanza, assistenza sanitaria, medicina e telecomunicazioni, dove la preservazione della privacy è fondamentale o è richiesta la localizzazione dei dati. Il FL è stato utilizzato per addestrare un modello globale per la rilevazione dei reati finanziari tra le varie istituzioni finanziarie. Il modello globale supera i modelli addestrati solo con i dataset locali del 20%. Nell’assistenza sanitaria, il FL è stato utilizzato per prevedere la mortalità dei pazienti ricoverati basandosi su cartelle cliniche elettroniche provenienti da diversi ospedali. Il modello globale che prevede la mortalità supera i modelli locali in tutti gli ospedali partecipanti. Il FL è stato anche utilizzato per la segmentazione dei tumori cerebrali. I modelli globali per la segmentazione dei tumori cerebrali si comportano in modo simile al modello addestrato raccogliendo dati distribuiti in una posizione centrale. Nelle telecomunicazioni, il FL può essere applicato all’edge computing, alla gestione dello spettro wireless e alle reti centrali 5G.

Ci sono molti altri modi per classificare FL:

• Orizzontale o verticale – A seconda della partizione delle caratteristiche nei dataset distribuiti, FL può essere classificato come orizzontale o verticale. Nel FL orizzontale, tutti i dataset distribuiti hanno lo stesso insieme di caratteristiche. Nel FL verticale, i dataset hanno gruppi diversi di caratteristiche che richiedono modelli di comunicazione aggiuntivi per allineare i campioni in base alle caratteristiche sovrapposte.
• Sincrono o asincrono – A seconda della strategia di aggregazione in un server FL, FL può essere classificato come sincrono o asincrono. Un server FL sincrono aggrega modelli locali da un insieme selezionato di client in un modello globale. Un server FL asincrono aggiorna immediatamente il modello globale dopo aver ricevuto un modello locale da un client, riducendo così il tempo di attesa e migliorando l’efficienza di formazione.
• Hub-and-spoke o peer-to-peer – La topologia FL tipica è hub-and-spoke, in cui un server FL centrale coordina un insieme di client. Un’altra topologia FL è peer-to-peer, senza un server FL centralizzato, in cui i client FL aggregano informazioni dai client vicini per apprendere un modello.

Sfide in FL

È possibile affrontare le seguenti sfide utilizzando algoritmi eseguiti su server e client FL all’interno di un’architettura FL comune:

• Eterogeneità dei dati – I dati locali dei client FL possono variare (cioè, eterogeneità dei dati) a causa di posizioni geografiche specifiche, organizzazioni o finestre temporali. L’eterogeneità dei dati influisce sull’accuratezza dei modelli globali, portando a più iterazioni di formazione e tempi di formazione più lunghi. Sono state proposte molte soluzioni per mitigare l’impatto dell’eterogeneità dei dati, come algoritmi di ottimizzazione, condivisione parziale dei dati tra i client e adattamento di dominio.
• Preservazione della privacy – I modelli locali e globali possono far trapelare informazioni private tramite un attacco avversario. Sono state proposte molte approcci di preservazione della privacy per FL. Un approccio di aggregazione sicura può essere utilizzato per preservare la privacy dei modelli locali scambiati tra server e client FL. Approcci di privacy differenziale locale e globale locale e globale limitano la perdita di privacy aggiungendo rumore ai modelli locali o globali, fornendo un compromesso controllato tra privacy e accuratezza del modello. A seconda delle esigenze di privacy, possono essere utilizzate combinazioni di diversi approcci di preservazione della privacy.
• Analisi federata – L’analisi federata fornisce misurazioni statistiche sui dataset distribuiti senza violare i requisiti di privacy. L’analisi federata è importante non solo per l’analisi dei dati tra dataset distribuiti prima della formazione, ma anche per il monitoraggio del modello durante l’inferenza.

Nonostante queste sfide degli algoritmi FL, è fondamentale costruire un’architettura sicura che fornisca operazioni FL end-to-end. Una sfida importante per la costruzione di tale architettura è consentire la facilità di distribuzione. L’architettura deve coordinare i server e i client FL per la costruzione, l’addestramento e la distribuzione del modello FL, inclusa l’integrazione continua e lo sviluppo continuo (CI/CD) tra i client, tracciabilità e autenticazione e controllo di accesso per i server e i client FL. Queste funzionalità sono simili alle operazioni di ML centralizzate (ML Ops), ma sono più difficili da implementare perché coinvolgono più parti. L’architettura deve anche essere flessibile per implementare diverse topologie FL e aggregazioni sincrone o asincrone.

Panoramica della soluzione

Proponiamo un’architettura FL nativa del cloud su AWS, come mostrato nel seguente diagramma. L’architettura include un server FL centrale e due client FL. In realtà, il numero di client FL può arrivare a centinaia per client tra diversi reparti aziendali. Il server FL deve trovarsi su AWS Cloud perché è composto da una serie di microservizi offerti dal cloud. I client FL possono trovarsi su AWS o nelle installazioni del cliente. I client FL ospitano i propri dataset locali e dispongono del proprio sistema IT e di ML per l’addestramento dei modelli di ML.

Durante l’addestramento del modello FL, il server FL e un gruppo di client scambiano modelli di ML. In altre parole, i client scaricano un modello ML globale dal server, eseguono l’addestramento locale e caricano i modelli locali sul server. Il server scarica i modelli locali, li aggrega in un nuovo modello globale. Questa procedura di scambio di modelli costituisce una singola iterazione di addestramento FL. L’iterazione di addestramento FL si ripete fino a quando il modello globale raggiunge una determinata accuratezza o il numero di iterazioni di addestramento raggiunge una soglia prestabilita.

Figura 1 – Un’architettura FL cloud-nativa per l’addestramento del modello tra un server FL e client FL.

Prerequisiti

Per implementare questa soluzione, è necessario avere un account AWS per avviare i servizi per un server FL centrale e i due client. I client FL in locale devono installare l’Interfaccia della linea di comando di AWS (AWS CLI), che consente di accedere ai servizi AWS sul server FL, inclusi Amazon Simple Queue Service (Amazon SQS), Amazon Simple Storage Service (Amazon S3) e Amazon DynamoDB.

Passaggi di apprendimento federato

In questa sezione, descriviamo l’architettura proposta nella figura 1. Sul server FL, la macchina a stati AWS Step Functions esegue un flusso di lavoro come mostrato nella figura 2, che esegue i passaggi 0, 1 e 5 della figura 1. La macchina a stati avvia i servizi AWS sul server (passo 0) e itera le round di addestramento FL. Per ogni round di addestramento, la macchina a stati invia una notifica Amazon Simple Notification Service (Amazon SNS) all’argomento global_model_ready, insieme a un token di attività (passo 1). La macchina a stati si mette quindi in pausa e attende una richiamata con il token di attività. Ci sono code SQS che sottoscrivono l’argomento global_model_ready. Ogni coda SQS corrisponde a un client FL e accoda le notifiche inviate dal server al client.

Figura 2 – Il flusso di lavoro nella macchina a stati Step Functions.

Ogni client estrae messaggi dalla propria coda SQS assegnata. Quando viene ricevuta una notifica global_model_ready, il client scarica un modello globale da Amazon S3 (passaggio 2) e avvia l’addestramento locale (passaggio 3). L’addestramento locale genera un modello locale. Il client quindi carica il modello locale su Amazon S3 e scrive le informazioni del modello locale, insieme al token di attività ricevuto, nella tabella di DynamoDB (passaggio 4).

Implementiamo il registro del modello FL utilizzando Amazon S3 e DynamoDB. Utilizziamo Amazon S3 per memorizzare i modelli globali e locali. Utilizziamo la tabella DynamoDB per memorizzare le informazioni del modello locale perché le informazioni del modello locale possono essere diverse tra gli algoritmi FL, il che richiede uno schema flessibile supportato da una tabella DynamoDB.

Abilitiamo anche uno stream di DynamoDB per innescare una funzione Lambda, in modo che ogni volta che viene scritto un record nella tabella DynamoDB (quando viene ricevuto un nuovo modello locale), una funzione Lambda viene innescata per verificare se sono stati raccolti i modelli locali richiesti (passaggio 5). In tal caso, la funzione Lambda esegue la funzione di aggregazione per aggregare i modelli locali nei modelli globali. Il modello globale risultante viene scritto su Amazon S3. La funzione invia anche una richiamata, insieme al token di attività recuperato dalla tabella DynamoDB, alla macchina a stati di Step Functions. La macchina a stati quindi determina se l’addestramento FL deve continuare con un nuovo round di addestramento o deve essere interrotto in base a una condizione, ad esempio il numero di round di addestramento che raggiunge una soglia.

Ogni client FL utilizza il seguente codice di esempio per interagire con il server FL. Se si desidera personalizzare l’addestramento locale dei client FL, è possibile modificare la funzione localTraining() a condizione che i valori restituiti siano local_model_name e local_model_info per l’upload al server FL. È possibile selezionare qualsiasi framework di ML per l’addestramento dei modelli locali nei client FL a condizione che tutti i client utilizzino lo stesso framework di ML.

# Passaggio 2: ricevere notifiche e nome del file del modello dalla sua coda SQS
client.receiveNotificationsFromServer(sqs_region, client_queue_name)
# Passaggio 3: scaricare un modello globale e addestrare localmente
local_model_name, local_model_info = client.localTraining(global_model_name, s3_fl_model_registry)
# Passaggio 4: caricare il modello locale e le informazioni sul modello locale sul server FL
client.uploadToFLServer(s3_fl_model_registry, local_model_name, dynamodb_table_model_info, local_model_info)

La funzione Lambda per l’esecuzione della funzione di aggregazione sul server ha il seguente codice di esempio. Se si desidera personalizzare l’algoritmo di aggregazione, è necessario modificare la funzione fedAvg() e l’output.

# Passaggio 5: aggregare i modelli locali nella funzione Lambda
def lambda_handler(event, context):
  # ottenere il nome del task dall'evento scatenato dallo stream DynamoDB
  task_name = event['Records'][0]['dynamodb']['Keys']['taskName']['S']
  
  # recuperare le transazioni dalla tabella DynamoDB
  transactions = readFromFLServerTaskTable(os.environ['TASKS_TABLE_NAME'], task_name)
  
  # leggere le informazioni sul modello locale dai client richiesti
  # il token è un token di richiamata dalla macchina a stati Step Functions
  local_model_info, round_id, token = receiveUpdatedModelsFromClients(transactions, task_name)
  
  # la funzione fedAvg aggrega i modelli locali in un modello globale e memorizza il modello globale in S3
  global_model_name, avg_train_acc, avg_test_acc, avg_train_loss, avg_test_loss = fedAvg(local_model_info, round_id)
  
  # output inviato alla macchina a stati Step Functions
  output = {
    'taskName': task_name,
    'roundId': str(round_id),
    'trainAcc': str(avg_train_acc),
    'testAcc': str(avg_test_acc),
    'trainLoss': str(avg_train_loss),
    'testLoss': str(avg_test_loss),
    'weightsFile': str(global_model_name)
  }
  
  # invia la chiamata di richiamo alla macchina a stati Step Functions per segnalare che il task identificato dal token è stato completato con successo
  step_client = boto3.client('stepfunctions')
  out_str = json.dumps(output)
  step_client.send_task_success(taskToken=token, output=out_str)

Questa architettura ha due design innovativi. In primo luogo, il server FL utilizza servizi serverless, come Step Functions e Lambda. Pertanto, non viene mantenuta alcuna istanza di calcolo per il server FL, il che riduce al minimo il costo di calcolo. In secondo luogo, i client FL estraggono messaggi dalle loro code SQS assegnate e caricano o scaricano modelli e informazioni dai servizi sul server FL. Questo design evita al server FL di accedere direttamente alle risorse dei client, il che è fondamentale per fornire ambienti IT e ML privati e flessibili (in locale o su AWS Cloud) ai client FL.

Vantaggi di essere cloud-native

Questa architettura è nativa del cloud e offre una trasparenza end-to-end utilizzando i servizi AWS con comprovata sicurezza ed eccellenza operativa. Ad esempio, è possibile avere client cross-account per assumere ruoli per accedere alle risorse sul server FL. Per i client in locale, AWS CLI e AWS SDK for Python (Boto3) sui client forniscono automaticamente connessioni di rete sicure tra il server FL e i client. Per i client su AWS Cloud, è possibile utilizzare AWS PrivateLink e servizi AWS con crittografia dei dati in transito e a riposo per la protezione dei dati. È possibile utilizzare Amazon Cognito e AWS Identity and Access Management (IAM) per l’autenticazione e il controllo di accesso dei server e dei client FL. Per il rilascio del modello globale addestrato, è possibile utilizzare le capacità di ML Ops in Amazon SageMaker.

L’architettura cloud-native consente anche l’integrazione con framework di ML personalizzati e algoritmi e protocolli di apprendimento federato. Ad esempio, è possibile selezionare un framework di ML per addestrare modelli locali nei client FL e personalizzare diversi algoritmi di aggregazione come script in esecuzione nelle funzioni Lambda sul server. Inoltre, è possibile modificare i flussi di lavoro nelle Step Functions per adattarsi a diversi protocolli di comunicazione tra il server e i client.

Un altro vantaggio dell’architettura nativa del cloud è la facilità di distribuzione utilizzando strumenti IaC offerti per il cloud. È possibile utilizzare il AWS Cloud Development Kit (AWS CDK) e AWS CloudFormation per la distribuzione con un solo clic.

Conclusione

Le nuove leggi sulla privacy continuano ad essere implementate in tutto il mondo e le infrastrutture tecnologiche si stanno espandendo rapidamente in varie regioni e si stanno estendendo ai bordi delle reti. L’apprendimento federato aiuta i clienti del cloud a utilizzare set di dati distribuiti per allenare modelli di ML accurati in modo rispettoso della privacy. L’apprendimento federato supporta anche la localizzazione dei dati e potenzialmente consente di risparmiare costi, poiché non richiede lo spostamento o la condivisione di grandi quantità di dati grezzi.

Puoi iniziare a sperimentare e costruire architetture di apprendimento federato native del cloud per i tuoi casi d’uso. Puoi personalizzare l’architettura per supportare vari framework di ML, come TensorFlow o PyTorch. Puoi anche personalizzarla per supportare diversi algoritmi FL, tra cui apprendimento federato asincrono, algoritmi di aggregazione e algoritmi di privacy differenziale. Puoi abilitare questa architettura con le funzionalità FL Ops utilizzando le capacità di ML Ops in Amazon SageMaker.