Riepilogo Tecnico: Inferenza Split Adattiva Ottimale per la Latenza per la Collaborazione Cloud-Edge-End Preservante la Privacy

1. Definizione del Problema

I dispositivi terminali dell'Internet of Things (IoT) affrontano un compromesso critico quando elaborano dati sensibili alla privacy (ad esempio, immagini mediche): essi mancano delle risorse computazionali per eseguire intere Reti Neurali Convoluzionali (CNN) localmente, ma l'offloading di dati grezzi o di feature intermedie verso server cloud o edge espone informazioni sensibili. Sebbene la Crittografia Completamente Omomorfica (FHE) permetta il calcolo su dati criptati senza decrittazione, l'implementazione della FHE interamente sul cloud è proibitivamente lenta a causa dell'espansione del ciphertext e dell'overhead dell'aritmetica omomorfica. Al contrario, fare affidamento esclusivamente sui server edge è insufficiente a causa della loro capacità limitata rispetto al cloud.

La sfida centrale affrontata da questo articolo è determinare dove dividere una CNN e come distribuire la parte finale criptata (suffix) tra i tier edge e cloud per minimizzare la latenza end-to-end garantendo rigorosamente la privacy. Nello specifico, l'articolo cerca di risolvere il problema della selezione di una coppia di split ottimale (un punto di split lato end e un punto di terminazione lato edge) che bilanci l'esecuzione in chiaro locale, i costi di cifratura, i ritardi di comunicazione e i costi di esecuzione FHE remota.

2. Metodologia

Architettura di Sistema e Modello di Minaccia

Il framework proposto opera su un'architettura a tre livelli:

• Dispositivo End: Agisce come ancora di fiducia (trust anchor). Esegue il prefisso iniziale in chiaro della CNN, cifra l'attivazione intermedia utilizzando la FHE (specificamente lo schema CKKS) e conserva localmente la chiave segreta. Non trasmette mai input grezzi o feature in chiaro.
• Server Edge: È il primo livello esterno. Riceve le attivazioni criptate ed esegue un segmento continuo del modello su ciphertext.
• Server Cloud: È il livello ad alta capacità. Completa la parte finale (suffix) criptata rimanente se l'edge non termina l'inferenza.

Modello di Minaccia: I server edge e cloud sono modellati come "onesti ma curiosi" (honest-but-curious). Seguono fedelmente il protocollo, ma potrebbero tentare di inferire informazioni private dai ciphertext che elaborano. Il framework assume l'assenza di collusione tra i tier; anche se edge e cloud combinano le osservazioni, non possono decriptare i dati senza la chiave segreta detenuta esclusivamente dal dispositivo end.

Design del Modello Compatibile con FHE

Per consentire un'efficace valutazione omomorfica, l'articolo sostituisce le funzioni di attivazione ReLU standard con una funzione di attivazione residua quadratica: $\sigma(z) = (\alpha \cdot z)^2 + z$. Questa preserva un percorso residuo lineare utilizzando al contempo un polinomio di grado 2, il che è compatibile con il supporto per addizione e moltiplicazione dello schema CKKS. Il modello è addestrato da zero con questa attivazione per garantire che l'accuratezza sia mantenuta nel dominio criptato.

Algoritmo di Pianificazione Ottimale per la Latenza

Gli autori formulano l'implementazione come un problema di ottimizzazione vincolata per minimizzare la latenza totale $T_{tot}(q, e)$, dove $q$ è il punto di split lato end ed $e$ è il punto di terminazione lato edge. La latenza totale è la somma di:

1. Esecuzione in Chiaro Locale ($T_{end}$): Calcolata in base ai GFLOPS del dispositivo end.
2. Cifratura ($T_{enc}$): Costo per cifrare l'attivazione di split.
3. Comunicazione ($T_{comm}$): Ritardi di trasmissione per i ciphertext tra i tier, calcolati in base alla dimensione del payload (determinata dai parametri CKKS e dal packing SIMD) e alle larghezze di banda dei link configurati.
4. Esecuzione FHE Remota ($T_{edge}, T_{cloud}$): Stimata utilizzando densità di costo empiricamente calibrate (secondi per GFLOP) per specifici gruppi di layer (ad esempio, convoluzione+pooling, layer fully connected) sull'hardware rispettivo.

Il pianificatore supporta due granularità:

• Livello di Convoluzione: Permette punti di split a livello di singoli layer convoluzionali.
• Livello di Blocco: Restringe i punti di split ai confini di blocchi completi della rete o ai layer fully connected.

Il sistema valuta tutte le coppie fattibili $(q, e)$ sotto vincoli quali una politica di esposizione massima del modello (che limita la frazione di parametri del modello sul dispositivo end) e la coerenza strutturale, selezionando la coppia che minimizza la latenza.

3. Contributi Chiave

1. Framework di Split Preservante la Privacy: Un'architettura innovativa in cui il dispositivo end rimane l'unico detentore della chiave segreta e dei dati in chiaro, mentre i tier edge e cloud eseguono il calcolo strettamente su ciphertext FHE.
2. Pianificatore Consapevole della Latenza: Un modello di costo unificato e un algoritmo di ottimizzazione che considera congiuntamente l'esecuzione in chiaro, la comunicazione e gli eterogenei costi di esecuzione FHE tra i tier edge e cloud.
3. Partizionamento Consapevole della Granularità: Il framework supporta la partizione sia a livello di convoluzione che a livello di blocco, dimostrando che gli split più fini possono ridurre significamente la latenza sfruttando meglio le risorse edge.
4. Implementazione di Prototipo: Un prototipo funzionante utilizzando CKKS/OpenFHE su un testbed ibrido (Raspberry Pi 4B per l'end, contenitori Docker su un server Xeon per edge/cloud) con modelli basati su VGG16.

4. Risultati Sperimentali

Gli esperimenti sono stati condotti sui dataset CIFAR-10 e PathMNIST utilizzando un'architettura VGG16 modificata (SquareVGG16).

• Prestazioni di Latenza:

  • Lo split a livello di convoluzione proposto ha raggiunto una latenza end-to-end ammortizzata di 1033,279 s/campione su CIFAR-10 e 1023,429 s/campione su PathMNIST.
  • Ciò rappresenta un'accelerazione di circa 12,9× rispetto a un baseline FHE full-cloud e di circa 3,9× rispetto a un baseline di split a livello di blocco.
  • Il baseline FHE full-cloud ha sofferto di un'alta latenza (circa 13.357 s/campione su CIFAR-10) a causa dell'esecuzione dell'intero modello remotamente.

• Accuratezza:

  • Lo schema collaborativo ha raggiunto un'accuratezza dell'88,53% su CIFAR-10 e del 91,43% su PathMNIST.
  • Questi risultati corrispondono esattamente al modello SquareVGG16 in chiaro (o entro 0,01 punti percentuali), confermando che l'attivazione compatibile con FHE e lo split inference non degradano le prestazioni del modello.

• Overhead di Comunicazione:

  • Lo split a livello di convoluzione ha comportato un volume di comunicazione più elevato (circa 276 MB/campione) rispetto allo split a livello di blocco (141 MB/campione) perché il passaggio al cloud è avvenuto prima (dopo Conv. III-1 invece che dopo il Blocco III). Tuttavia, la riduzione del tempo di esecuzione FHE lato edge ha superato il costo di comunicazione, risultando in una latenza totale inferiore.

• Analisi di Sensibilità:

  • Il piano di split ottimale (Blocco II sul device end, Conv. III-1 sull'edge) è rimasto stabile attraverso varie configurazioni di larghezza di banda. Il piano si è spostato solo più in profondamente nel tier edge quando il tasso di esecuzione FHE dell'edge si è avvicinato a quello del cloud.

5. Significato e Rivendicazioni

L'articolo sostiene che la sua importanza primaria risieda nel dimostrare che l'inferenza split preservante la privacy può essere resa ottimale per la latenza attraverso il partizionamento adattivo. Trattando la selezione del punto di split come un problema di ottimizzazione congiunta che coinvolge i costi di cifratura, comunicazione ed esecuzione FHE eterogenei, il framework colma il divario tra l'alta sicurezza della FHE e i requisiti pratici di latenza delle applicazioni IoT.

Gli autori sottolineano che il loro lavoro fornisce una soluzione a livello di sistema che:

• Preserva il confine di privacy crittografica della FHE full-cloud (nessun dato in chiaro lascia il dispositivo end) riducendo drasticamente la latenza.
• Valida il fatto che lo splitting a grana fine (livello di convoluzione) è superiore allo splitting a grana grossa (livello di blocco) in ambienti eterogenei cloud-edge, anche quando i costi di comunicazione aumentano.
• Offre un modello di costo riproducibile e calibrato su benchmark per la ricerca futura nell'inferenza distribuita criptata.

L'articolo conclude con modestia, notando che l'attuale implementazione è un prototipo di ricerca basato su CPU per l'inferenza batch non interattiva, non per il decision-making in tempo reale, e che il lavoro futuro si concentrerà sull'accelerazione hardware e su famiglie di modelli più ampie.