Serverless Computing

L’informatique sans serveur est un modèle d’exécution dans le cloud où le fournisseur exécute le code uniquement lorsqu’un événement le déclenche, démarre et met automatiquement à l’échelle les serveurs sous-jacents, les arrête complètement lorsque le trafic cesse, et facture les requêtes et le temps d’exécution plutôt que des machines réservées. Les serveurs existent toujours, mais les développeurs n’ont jamais à les provisionner, les corriger ni en dimensionner les ressources. Ce modèle s’est généralisé avec AWS Lambda, annoncé en novembre 2014, et couvre désormais les plateformes de fonctions telles que Lambda, Azure Functions et Cloud Run functions, ainsi que les conteneurs sans serveur tels que Google Cloud Run et Azure Container Apps. Des chercheurs de l’UC Berkeley ont décrit ses atouts et ses limites dans l’article de 2019 « Cloud Programming Simplified: A Berkeley View on Serverless Computing ». Pour le machine learning, l’informatique sans serveur convient au service de modèles lorsque le trafic est irrégulier ou imprévisible : payer un serveur GPU inactif entre les pics coûterait plus cher que le travail lui-même.

Fonctionnement de l’exécution sans serveur#

Le code est empaqueté sous forme de fonction ou d’image de conteneur, puis associé à des déclencheurs : une requête HTTP, le dépôt d’un fichier dans un stockage objet, un message dans une file d’attente ou une tâche planifiée. Lorsqu’un événement survient et qu’une instance déjà démarrée est disponible, la plateforme y exécute immédiatement le gestionnaire. Sinon, elle effectue un démarrage à froid : elle crée un bac à sable isolé, par exemple l’une des microVM Firecracker qu’AWS a conçues pour Lambda, charge le code, démarre l’environnement d’exécution du langage et exécute le code d’initialisation en dehors du gestionnaire avant de traiter l’événement. Les instances sont sans état et éphémères ; tout ce qui doit subsister après une requête est donc stocké dans un service de stockage externe ou une base de données.

Démarrages à froid et modèles de machine learning#

Le machine learning rend les démarrages à froid coûteux, car l’initialisation importe un framework tel que PyTorch et charge des poids de modèle qui peuvent atteindre plusieurs centaines de mégaoctets. Le modèle standard consiste à charger le modèle une fois par instance, en dehors du gestionnaire ou lors de la première utilisation, afin que chaque appel ultérieur sur une instance active le réutilise. Ce gestionnaire suit ce modèle avec un classificateur ResNet-50 de 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")

Sur le CPU d’un Apple M5 Pro, le premier appel construit le réseau et prend environ 0,2 seconde, tandis que les deux appels suivants, qui réutilisent le réseau, prennent environ 15 ms chacun. Les équipes réduisent le temps de démarrage à froid restant à l’aide d’images de conteneur plus petites, de modèles compacts ou quantifiés et d’environnements d’exécution plus légers tels que ONNX Runtime, ou le suppriment en maintenant un nombre minimal d’instances actives, par exemple avec la concurrence provisionnée de Lambda ou les instances minimales de Cloud Run, ce qui implique de nouveau de payer les périodes d’inactivité.

L’informatique sans serveur pour les charges de travail d’IA#

Le sans serveur convient aux pipelines de vision par ordinateur déclenchés par des événements. Le téléversement vers un stockage d’objets peut déclencher une fonction qui valide et redimensionne l’image pendant le prétraitement des données, avant son ajout à un jeu de données d’entraînement. Dans un système d’alarme de sécurité, un capteur de mouvement peut envoyer une seule image à une fonction de détection d’objets, qui n’émet une alerte que si elle trouve une personne. Le reste dépend des limites de la plateforme : AWS Lambda exécute chaque invocation pendant 15 minutes maximum, avec jusqu’à 10 240 Mo de mémoire et sans GPU ; cela convient à l’inférence CPU avec des modèles compacts, mais exclut les longs entraînements et le entraînement distribué sur plusieurs GPU. Le sans serveur avec GPU a comblé cette lacune : Cloud Run associe des GPU NVIDIA L4 à des conteneurs qui peuvent toujours revenir à zéro, et des plateformes comme Modal facturent l’utilisation du GPU à la seconde.

Ultralytics Platform propose le même compromis pour les déploiements YOLO : un point de terminaison de taille par défaut de 1 vCPU et 2 GiB est gratuit et revient à zéro lorsqu’il est inactif ; son démarrage depuis l’inactivité peut prendre environ une minute, tandis que les tailles personnalisées maintiennent une instance active et facturent sa durée de fonctionnement.

L’informatique sans serveur et les modèles apparentés#

• Infrastructure en tant que service : des machines virtuelles qui s’exécutent et sont facturées en continu, que des requêtes arrivent ou non, le client étant chargé de gérer le système d’exploitation et la mise à l’échelle. Les longues tâches d’entraînement s’exécutent généralement ici.
• Kubernetes : orchestre les conteneurs sur des clusters exploités par l’équipe. Knative y ajoute une mise à l’échelle pilotée par les requêtes, jusqu’à zéro, que KServe utilise pour servir les modèles.
• Informatique en périphérie : exécute le code sur les appareils qui produisent les données, ou à proximité de ceux-ci. L’informatique sans serveur l’exécute dans une région du cloud, et certaines plateformes en périphérie associent les deux en exécutant des fonctions dans de nombreux petits emplacements proches des utilisateurs.