Cold Start

Die Verzögerung beim ersten Aufruf einer Serverless-Funktion oder eines skalierten Services – wenn Container oder VMs erst gestartet werden müssen.

Fortgeschritten2 Min Lesezeit

Erklärung starten

Auf einen Blick

3 Punkte

  1. Erste Anfrage nach Inaktivität ist langsamer
  2. Ursache: Container/VM muss gestartet, Code geladen werden
  3. Besonders relevant bei Serverless, Scale-to-Zero und ML-Inference

Sofortantwort

Cold Start einfach erklärt

Verzögerung beim ersten Request, wenn Ressourcen erst hochgefahren werden müssen.

Kurz gesagt
Erste Anfrage nach Inaktivität ist langsamer
Typischer Einsatz
Serverless Functions, Scale-to-Zero, ML-Inference
Wichtig zu wissen
Besonders relevant bei Serverless, Scale-to-Zero und ML-Inference

Cold Start im Überblick

Cold Start ist die Verzögerung beim ersten Request, wenn ein Service erst hochgefahren oder initialisiert werden muss. Bei Serverless und Scale-to-Zero kann das nach Inaktivität auftreten.

Der Ablauf:

Warm Start (Instanz läuft bereits):
Request ──► Handler ──► Response
           kurze Latenz

Cold Start (Instanz muss starten):
Request ──► Container Start ──► Runtime Init ──► Code Load ──► Handler ──► Response
           zusätzliche Initialisierungsschritte vor der eigentlichen Verarbeitung

Cold Start Unterschiede nach Runtime:

Runtime-TypTypische EinordnungAnmerkung
Kompilierte, kleine Binariesoft schnellergeringe Initialisierung, kleine Artefakte
Interpreter-Runtimesabhängig von DependenciesImports und Paketgröße wichtig
VM-basierte Runtimesoft stärker initialisierungsabhängigVM/JIT und Framework-Start können dominieren
Containerisierte Workloadsstark image- und plattformabhängigImage-Größe, Cache und Netzwerk relevant
ML-Inferenceoft durch Modell-Ladezeit geprägtModellgröße und Speicherpfad entscheidend

Technisch betrachtet

Was passiert beim Cold Start?

1. Container/MicroVM starten
   └── Image pullen (wenn nicht gecached)
   └── Netzwerk konfigurieren
   └── Filesystem mounten

2. Runtime initialisieren
   └── Interpreter/VM starten
   └── Dependencies laden

3. Anwendungscode laden
   └── Handler-Funktion importieren
   └── Globale Initialisierung

4. Request verarbeiten
   └── Eigentliche Logik

Optimierungsstrategien

1. Provisioned Concurrency (AWS Lambda):

# serverless.yml
functions:
  api:
    handler: handler.main
    provisionedConcurrency: desired_warm_instances

2. Warmup-Requests:

# Regelmäßiger Warmup-Trigger, falls zur Plattform passend
import json

def handler(event, context):
    # Warmup-Request erkennen
    if event.get("source") == "warmup":
        return {"statusCode": 200, "body": "warm"}
    
    # Normale Logik
    return process_request(event)

3. Kleinere Deployments:

# ❌ Schlecht: Alles importieren
import pandas as pd
import numpy as np
import tensorflow as tf
import boto3
# ... große Dependencies erhöhen Start- und Ladezeit

# ✅ Besser: Lazy Loading
def handler(event, context):
    if event["type"] == "ml":
        import tensorflow as tf  # Nur wenn nötig
        return ml_inference(event)
    else:
        return simple_response(event)

4. Schnellere Runtimes:

VM-basierte Runtime → Native Image prüfen
Interpreter-Runtime → kritische Pfade ggf. kompiliert umsetzen
Große Frameworks → schlankere Runtime oder Lazy Loading prüfen

ML-Modell Cold Start

# Problem: Modell bei jedem Cold Start laden
def handler(event, context):
    model = load_model("model-uri")  # kann Cold Start dominieren
    return model.predict(event["data"])

# Lösung: Globale Initialisierung
model = None

def handler(event, context):
    global model
    if model is None:
        model = load_model("s3://bucket/model.pkl")
    return model.predict(event["data"])

# Noch besser: Model in Container-Image einbetten

Messung

import time

def handler(event, context):
    # Cold Start erkennen
    is_cold = not hasattr(handler, "_initialized")
    
    if is_cold:
        handler._initialized = True
        handler._start_time = time.time()
    
    # Metriken loggen
    print(json.dumps({
        "cold_start": is_cold,
        "init_duration_ms": context.get("initDuration", 0)
    }))
    
    return process(event)

01Einsatzbereiche

Wann ist Cold Start sinnvoll?

Geeignet für

  • Serverless FunctionsServerless Functions können nach Inaktivität Cold Starts haben
  • Scale-to-ZeroKubernetes Pods die auf 0 skaliert wurden
  • ML-InferenceModell muss erst in GPU-Speicher geladen werden
  • JVM-AnwendungenJIT-Kompilierung beim Start

↑ Inhalt

02Werkzeuge

Womit Cold Start umgesetzt wird

↑ Inhalt

Merksatz

Cold Start ist wie ein Auto im Winter

Der erste Start dauert länger, weil der Motor kalt ist. Danach läuft alles flüssig – bis du den Motor wieder abstellst und er auskühlt.

  1. Erste Anfrage nach Inaktivität ist langsamer
  2. Ursache: Container/VM muss gestartet, Code geladen werden
  3. Besonders relevant bei Serverless, Scale-to-Zero und ML-Inference

04Redaktion

Herkunft und Stand

Redaktion und Aktualität

Ebenex RedaktionRedaktion

Veröffentlicht
Aktualisiert

Dieses Feld entwickelt sich schnell. Oben stehen Veröffentlichung und letzte Änderung; ein Prüfdatum kommt dazu, sobald die Erklärung nach ihrer letzten Änderung geprüft wurde.

↑ Inhalt

05FAQ

Häufige Fragen zu Cold Start

Wie lange dauert ein Cold Start?

Das hängt von Runtime, Paketgröße, Netzwerk, Plattform, Region, Initialisierung und Workload ab. Kleine Funktionen starten oft deutlich schneller als große Container oder ML-Modelle, die erst geladen werden müssen.

Wie vermeide ich Cold Starts?

Mögliche Ansätze sind vorgewärmte Kapazität, kleinere Deployments, Lazy Loading, optimierte Initialisierung, geeignete Runtimes oder bewusstes Vermeiden von Scale-to-Zero für latenzkritische Pfade.

Ist Cold Start bei allen Serverless-Anbietern gleich?

Nein. Anbieter und Plattformen unterscheiden sich stark bei Isolation, Runtime, Container-Handling, Warmhalte-Strategien und Netzwerkpfaden. Architektur und Workload machen den Unterschied.

↑ Inhalt

06Weiterlernen

Was möchtest du als Nächstes verstehen?

  • Grundlage nachholen

    Serverless

    Der Cloud-Anbieter verwaltet die Infrastruktur, Entwickler laden nur Code hoch.

  • Technisch vertiefen

    Autoscaling

    Automatische Anpassung von Ressourcen basierend auf Auslastung.

↑ Inhalt