Serverless Computing

Il serverless computing è un modello di esecuzione cloud in cui il provider esegue il codice solo quando un evento lo richiede, avvia e scala automaticamente i server sottostanti, li arresta fino a zero quando il traffico si interrompe e addebita le richieste e il tempo di esecuzione invece di macchine riservate. I server esistono comunque, ma gli sviluppatori non devono mai predisporli, applicare patch o dimensionarli. Il modello è diventato mainstream con AWS Lambda, annunciato nel novembre 2014, e oggi comprende piattaforme basate su funzioni come Lambda, Azure Functions e Cloud Run functions, oltre a container serverless come Google Cloud Run e Azure Container Apps. I ricercatori dell'UC Berkeley ne hanno descritto punti di forza e limiti nell'articolo del 2019 "Cloud Programming Simplified: A Berkeley View on Serverless Computing". Per il machine learning, il serverless è adatto alla distribuzione di modelli con traffico a picchi o imprevedibile, quando pagare un server GPU inattivo tra un picco e l'altro costerebbe più del lavoro stesso.

Come funziona l'esecuzione serverless#

Il codice viene impacchettato come funzione o immagine di container e associato a trigger: una richiesta HTTP, un file caricato nell'archiviazione di oggetti, un messaggio in una coda o una pianificazione. Quando arriva un evento e c'è un'istanza pronta disponibile, la piattaforma vi esegue immediatamente il gestore. Altrimenti esegue un avvio a freddo: crea una sandbox isolata, come una delle microVM Firecracker sviluppate da AWS per Lambda, carica il codice, avvia il runtime del linguaggio ed esegue il codice di inizializzazione al di fuori del gestore prima di elaborare l'evento. Le istanze sono senza stato e usa e getta, quindi tutto ciò che deve sopravvivere a una richiesta viene salvato in uno spazio di archiviazione esterno o in un database.

Avvii a freddo e modelli di machine learning#

Il machine learning rende costosi gli avvii a freddo, perché l'inizializzazione importa un framework come PyTorch e carica pesi del modello che possono raggiungere centinaia di megabyte. La pratica standard consiste nel caricare il modello una volta per istanza, al di fuori del gestore o al primo utilizzo, così ogni invocazione a caldo lo riutilizza. Questo gestore segue tale pratica con un classificatore ResNet-50 di torchvision:

import time

import torch
import torchvision

model = None  # module state survives between invocations while the instance stays warm


def handler(event, context):
    """Classify one image tensor, building the model only on a cold start."""
    global model
    cold_start = model is None
    if cold_start:
        model = torchvision.models.resnet50().eval()  # built once per instance
    with torch.inference_mode():
        logits = model(event["image"])
    return {"cold_start": cold_start, "class_id": int(logits.argmax())}


for _ in range(3):
    start = time.perf_counter()
    response = handler({"image": torch.rand(1, 3, 224, 224)}, context=None)
    print(response["cold_start"], f"{(time.perf_counter() - start) * 1000:.0f} ms")

Su una CPU Apple M5 Pro, la prima chiamata crea la rete e richiede circa 0,2 secondi, mentre le due chiamate a caldo che la riutilizzano impiegano circa 15 ms ciascuna. I team riducono ulteriormente l'avvio a freddo con immagini di container più piccole, modelli compatti o quantizzati e runtime più leggeri come ONNX Runtime, oppure lo eliminano mantenendo un numero minimo di istanze a caldo, come la concorrenza con provisioning di Lambda o le istanze minime di Cloud Run, che comportano nuovamente costi per il tempo di inattività.

Serverless per i carichi di lavoro IA#

L'architettura serverless è adatta alle pipeline di visione artificiale basate su eventi. Un caricamento nello spazio di archiviazione a oggetti può attivare una funzione che convalida e ridimensiona l'immagine durante la preelaborazione dei dati, prima che venga aggiunta a un dataset di addestramento. In un sistema di allarme di sicurezza, invece, un sensore di movimento può inviare un singolo fotogramma a una funzione di rilevamento degli oggetti, che invia un avviso solo se trova una persona. Per il resto, tutto dipende dai limiti della piattaforma: AWS Lambda consente a ogni invocazione di durare al massimo 15 minuti, con fino a 10.240 MB di memoria e senza GPU; è adatta all'inferenza su CPU con modelli compatti, ma non a lunghe esecuzioni di addestramento, tantomeno all'addestramento distribuito su molte GPU. Il serverless con GPU ha colmato questa lacuna: Cloud Run collega GPU NVIDIA L4 a container che possono comunque scalare a zero e piattaforme come Modal fatturano l'uso della GPU al secondo.

Ultralytics Platform offre lo stesso compromesso per le distribuzioni YOLO: un endpoint con dimensione predefinita di 1 vCPU e 2 GiB è gratuito e scala a zero quando è inattivo; l'avvio da inattività può richiedere fino a circa un minuto, mentre le dimensioni personalizzate mantengono un'istanza sempre attiva e ne addebitano il tempo di attività.

Serverless e modelli correlati#

• Infrastruttura come servizio: macchine virtuali che vengono eseguite e fatturate ininterrottamente, indipendentemente dal fatto che arrivino richieste, e il cui sistema operativo e ridimensionamento sono gestiti dal cliente. Di solito qui vengono eseguiti i lunghi processi di training.
• Kubernetes: orchestra i container su cluster gestiti dal team. Knative aggiunge la scalabilità a zero in base alle richieste e KServe lo usa per distribuire i modelli.
• Edge computing: esegue il codice sui dispositivi che producono i dati o nelle loro vicinanze. Il serverless lo esegue in una regione cloud, mentre alcune piattaforme edge combinano i due approcci eseguendo funzioni in molte piccole sedi vicine agli utenti.