Serverless Computing

Serverloses Computing ist ein Cloud-Ausführungsmodell, bei dem der Anbieter Code nur dann ausführt, wenn ein Ereignis dies erfordert, die zugrunde liegenden Server automatisch startet und skaliert, sie bei ausbleibendem Datenverkehr vollständig herunterfährt und statt reservierter Maschinen die Anfragen und Ausführungszeit abrechnet. Server gibt es weiterhin, aber Entwickler müssen sie weder bereitstellen noch aktualisieren oder dimensionieren. Das Modell wurde mit AWS Lambda, das im November 2014 angekündigt wurde, allgemein bekannt und umfasst heute Funktionsplattformen wie Lambda, Azure Functions und Cloud Run functions sowie serverlose Container wie Google Cloud Run und Azure Container Apps. Forschende der UC Berkeley beschrieben die Stärken und Grenzen des Modells 2019 in der Arbeit „Cloud Programming Simplified: A Berkeley View on Serverless Computing“. Für maschinelles Lernen eignet sich Serverless für die Modellbereitstellung bei sprunghaftem oder unvorhersehbarem Datenverkehr, bei dem ein ungenutzter GPU-Server zwischen Spitzen mehr kosten würde als die eigentliche Arbeit.

So funktioniert die serverlose Ausführung#

Code wird als Funktion oder Container-Image verpackt und mit Auslösern verknüpft: einer HTTP-Anfrage, einer Datei, die im Objektspeicher abgelegt wird, einer Nachricht in einer Warteschlange oder einem Zeitplan. Trifft ein Ereignis ein und ist eine warme Instanz verfügbar, führt die Plattform den Handler sofort darauf aus. Andernfalls erfolgt ein Kaltstart: Die Plattform erstellt eine isolierte Sandbox, etwa eine der Firecracker-MicroVMs, die AWS für Lambda entwickelt hat, lädt den Code, startet die Sprachlaufzeit und führt den Initialisierungscode außerhalb des Handlers aus, bevor sie das Ereignis verarbeitet. Instanzen sind zustandslos und kurzlebig. Alles, was eine Anfrage überdauern muss, wird daher in einem externen Speicher oder einer Datenbank abgelegt.

Kaltstarts und Modelle des maschinellen Lernens#

Bei maschinellem Lernen sind Kaltstarts kostspielig, da die Initialisierung ein Framework wie PyTorch importiert und Modellgewichte lädt, die Hunderte Megabyte groß sein können. Üblicherweise wird das Modell einmal pro Instanz außerhalb des Handlers oder bei der ersten Verwendung geladen, sodass es bei jedem warmen Aufruf wiederverwendet wird. Dieser Handler setzt das Muster mit einem ResNet-50-Klassifikator aus torchvision um:

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")

Auf einer Apple M5 Pro CPU erstellt der erste Aufruf das Netzwerk und dauert ungefähr 0,2 Sekunden, während die beiden warmen Aufrufe, die es wiederverwenden, jeweils etwa 15 ms benötigen. Teams verkürzen die verbleibende Kaltstartzeit mit kleineren Container-Images, kompakten oder quantisierten Modellen und schlankeren Laufzeitumgebungen wie der ONNX-Laufzeit. Alternativ lässt sie sich vermeiden, indem eine Mindestanzahl warmer Instanzen vorgehalten wird, etwa durch die bereitgestellte Parallelität von Lambda oder Mindestinstanzen bei Cloud Run. Dann fallen allerdings wieder Kosten für Leerlaufzeiten an.

Serverless für KI-Arbeitslasten#

Serverless eignet sich für ereignisgesteuerte Computer-Vision-Pipelines. Ein Upload in einen Objektspeicher kann eine Funktion auslösen, die ein Bild während der Datenvorverarbeitung prüft und skaliert, bevor es einem Trainingsdatensatz hinzugefügt wird. In einem Sicherheitsalarmsystem kann ein Bewegungssensor ein einzelnes Bild an eine Funktion zur Objekterkennung senden, die nur dann einen Alarm auslöst, wenn sie eine Person findet. Der Rest hängt von den Plattformgrenzen ab: AWS Lambda führt jeden Aufruf höchstens 15 Minuten lang mit bis zu 10.240 MB Speicher und ohne GPU aus. Das eignet sich für CPU-Inferenz mit kompakten Modellen, nicht aber für lange Trainingsläufe oder verteiltes Training über viele GPUs. Serverless-Angebote mit GPU haben diese Lücke geschlossen: Cloud Run bindet NVIDIA-L4-GPUs an Container an, die weiterhin auf null skalieren können. Plattformen wie Modal rechnen GPU-Zeit sekundengenau ab.

Die Ultralytics Platform bietet denselben Kompromiss für YOLO-Bereitstellungen: Ein Endpunkt in der Standardgröße mit 1 vCPU und 2 GiB ist kostenlos und wird bei Inaktivität auf null skaliert. Der Kaltstart kann etwa eine Minute dauern. Bei benutzerdefinierten Größen bleibt eine Instanz warm, und ihre Laufzeit wird abgerechnet.

Serverless im Vergleich zu verwandten Modellen#

• Infrastructure as a Service: Virtuelle Maschinen, die rund um die Uhr laufen und abgerechnet werden, unabhängig davon, ob Anfragen eingehen. Das Betriebssystem und die Skalierung verwaltet der Kunde. Lange Trainingsläufe finden meist hier statt.
• Kubernetes: Orchestriert Container in Clustern, die das Team betreibt. Knative ergänzt dies um eine anfragenbasierte Skalierung auf null, die KServe zum Bereitstellen von Modellen nutzt.
• Edge Computing: Führt Code auf oder nahe den Geräten aus, die Daten erzeugen. Serverless führt Code in einer Cloud-Region aus. Manche Edge-Plattformen kombinieren beides, indem sie Funktionen an vielen kleinen Standorten in Nutzernähe ausführen.