Einsatz von Modellen für Echtzeit-Inferenz (REST API)¶

Wie es funktioniert¶

Snowflake vereinfacht die Bereitstellungspipeline, indem Ihr Modell als HTTP-Server innerhalb von Snowpark Container Services (SPCS) gehostet wird. Diese Architektur ermöglicht Folgendes:

• Komplexität abstrahieren: Bereitstellen von anspruchsvollen Modellen, ohne Docker-Images oder Kubernetes-Cluster verwalten zu müssen.

• Leistung skalieren: Ausführen umfangreicher Modelle auf verteilten GPU-Clustern für hohe Leistungsanforderungen.

• Zuverlässigkeit sicherstellen: Verwenden von integrierter Beobachtbarkeit, Aufteilung des Datenverkehrs und Shadow-/Canary-Bereitstellungen für nahtlose Modellaktualisierungen.

# reg is a snowflake.ml.registry.Registry object
example_mv_object = reg.get_model("mymodel_name").version("version_name") # a snowflake.ml.model.ModelVersion object

example_mv_object.create_service(service_name="myservice",
                  service_compute_pool="my_compute_pool",
                  ingress_enabled=True,
                  gpu_requests=None)

Standard Konfiguration des Dienstes¶

Der Server, der das von Ihnen bereitgestellte Modell ausführt, verwendet Standardwerte, die für die meisten Anwendungsfälle geeignet sind:

• Anzahl der Worker-Threads: Bei einem CPU-gestützten Modell ist die Anzahl der Prozesse, die der Server verwendet, doppelt so groß wie die Anzahl der CPUs plus einem Prozess. GPU-gestützte Modelle verwenden einen Worker-Prozess. Sie können dies mit dem Argument num_workers im create_service-Aufruf überschreiben. Es wird empfohlen, den kleinsten GPU-Knoten anzugeben, bei dem das Modell in den Speicher passt. Skalieren Sie, indem Sie die Anzahl der Instanzen erhöhen. Wenn das Modell beispielsweise in GPU_NV_S (GPU_NV_SM in Azure) passt, verwenden Sie gpu_requests=1 und skalieren nach oben, indem Sie den Wert für max_instances erhöhen. Wenn der kleinste verfügbare Knoten jedoch 4 GPUs hat und Sie nur 2 benötigen, verwenden Sie num_workers=2 (d. h. GPU verfügbar / GPUs, die vom Modell benötigt werden).

• Threadsicherheit: Einige Modelle sind nicht Thread-sicher. Daher lädt der Dienst für jeden Worker-Prozess eine eigene Kopie des Modells. Dies kann bei großen Modellen zu einer Erschöpfung der Ressourcen führen.

• Knotennutzung: Standardmäßig fordert eine Inferenzserverinstanz den gesamten Knoten an, indem sie die gesamte CPU und den gesamten Speicher des Knotens anfordert, auf dem sie läuft. Um die Ressourcenzuweisung pro Instanz anzupassen, verwenden Sie Argumente wie cpu_requests, memory_requests und gpu_requests.

• Endpunkt: Der Endpunkt hat den Namen „inference“ und verwendet Port 5000. Diese können nicht angepasst werden. Für eine optimale Ressourcennutzung geben Sie den kleinsten GPU-Knoten an, bei dem das Modell in den Speicher passen kann. Erhöhen Sie die Anzahl der Instanzen, die an Ihre Workload angepasst werden. Wenn das Modell beispielsweise in GPU_NV_S (GPU_NV_SM in Azure) passt, verwenden Sie gpu_requests=1 und skalieren nach oben, indem Sie den Wert für max_instances erhöhen.

Verhaltensweise bei der Erstellung von Container-Images¶

Der Snowflake conda-Kanal ist nur in Warehouses verfügbar und ist die einzige Quelle für Abhängigkeiten von Warehouses. Standardmäßig beziehen die conda-Abhängigkeiten für SPCS-Modelle ihre Abhängigkeiten aus conda-forge.

Standardmäßig erstellt Snowflake Model Serving das Container-Image unter Verwendung desselben Computepools, der für die Ausführung des Modells verwendet wird. Der Computepool ist für den Prozess der Image-Erstellung vermutlich überdimensioniert (zum Beispiel werden GPUs nicht für die Erstellung von Container-Images verwendet). In den meisten Fällen wird dies keine wesentlichen Auswirkungen auf die Computekosten haben. Wenn Sie jedoch Bedenken haben, können Sie mit dem Argument image_build_compute_pool einen weniger leistungsfähigen Pool für die Erstellung von Images angeben.

Auch wenn create_service() mehrfach aufgerufen wird, wird nicht jedes Mal ein neuer Image-Erstellungsprozess ausgelöst.

Container-Images können jedoch neu erstellt werden, wenn Snowflake Aktualisierungen am Inference-Service vorgenommen hat, einschließlich Korrekturen für Sicherheitslücken in abhängigen Paketen. Wenn dies geschieht, löst create_service automatisch eine Neuerstellung des Images aus.

Benutzeroberfläche¶

Sie können eingesetzte Modelle in der Modellregistrierung Snowsight UI verwalten. Weitere Informationen dazu finden Sie unter Dienste zur Modellinferenz.

HTTP-Endpunkte¶

Jeder Service verfügt über einen internen DNS-Namen. Das Bereitstellen eines Service mit ingress_enabled erstellt auch einen öffentlichen HTTP-Endpunkt, der außerhalb von Snowflake verfügbar ist. Jeder Endpunkt kann verwendet werden, um einen Service aufzurufen.

Sie finden den öffentlichen HTTP-Endpunkt eines Service mit aktiviertem Eingang über den Befehl SHOW ENDPOINTS. Die Ausgabe enthält eine Spalte „ingress_url“, die einen Eintrag im Format eindeutige-service-id-konto-id.snowflakecomputing.app enthält. Dies ist der öffentlich zugängliche HTTP-Endpunkt für Ihren Service. Für Benutzende von Private Link verwenden Sie „privatelink_ingress_url“ anstelle von „ingress_url“.

Um den internen DNS-Namen in Snowflake abzurufen, verwenden Sie den Befehl DESCRIBE SERVICE. Die Spalte „dns_name“ der Ausgabe dieses Befehls enthält den internen DNS-Namen des Service. Um den Port Ihres Service zu finden, verwenden Sie die den Befehl SHOW ENDPOINTS IN SERVICE. Die Spalte „port“ oder „port_range“ enthält den von einem Dienst verwendeten Port. Sie können Ihren Service über die URL http://dns_name:port aufrufen.

Um eine bestimmte Methode des Modells aufzurufen, verwenden Sie den Methodennamen als Pfad zur URL (z. B. https://unique-service-id-account-id.snowflakecomputing.app/method-name oder http://dns_name:port/<method-name>). In einer URL werden Unterstriche (_) im Methodennamen durch Bindestriche (-) in der URL ersetzt. So wird beispielsweise der Name des Dienstes „predict_prob“ in „prediction-proba“ in der URL geändert.

Zur Vereinfachung kann in Python die list_services()-API für das ModelVersion-Objekt aufgerufen werden:

# mv: snowflake.ml.model.ModelVersion
mv.list_services()

Sie liefert Ausgaben sowohl für den öffentlichen Endpunkt (inference_endpoint) als auch für den internen Endpunkt (internal_endpoint).

Authentifizierung¶

Snowflake unterstützt mehrere Authentifizierungsprotokolle. Am einfachsten ist die Verwendung von programmgesteuerten Zugriffstoken (PAT), wobei ein Token hierbei einfach als Authorization: Snowflake Token="your_pat_token" an den Anforderungs-Header übergeben werden kann.

Autorisierung¶

Standardmäßig können nur Personen mit den entsprechenden Eigentumsrechten am Dienst den Endpunkt verwenden. Um einer anderen Rolle den Zugriff auf den Endpunkt zu ermöglichen, können diese Personen die Dienstrolle ALL_ENDPOINTS_USAGE gewähren.

Anforderungstext (oder Protokoll oder Datenformat)¶

Snowflake unterstützt zwei Arten von Datenformaten für REST-Anforderungen. Sie orientieren sich an pandas-Datenframes, da sie in der Branche sehr bekannt sind und von Kunden mithilfe einfacher Python-Skripte mit einem pandas-Datenframe überprüft werden können.

Hier finden Sie die Details zu den Formaten

1. dataframe_split ist eine kompakte, Index/Spalten/Daten-Darstellung.

• Eine Darstellung, die pandas_df.to_json(orient="split") spiegelt.

1. dataframe_records ist eine Schlüssel/Wert-Darstellung (datensatzorientiert).

• Eine Darstellung, die df.to_json(orient="records") spiegelt.

Es wird empfohlen, das dataframe_split-Format zu verwenden. Da dataframe_records die Spaltennamen für jede Zeile wiederholt, erzeugt diese Darstellung normalerweise einen größeren Anforderungstext als dataframe_split. Dies kann sich bei großen Batches oder häufigen Aufrufen auf die Leistung auswirken.

Modell-Endpunkte geben weiterhin ein einziges Ausgabeformat zurück, unabhängig davon, welches Eingabeformat Sie verwenden.

1. dataframe_split-Format (empfohlen)

Dies entspricht der Struktur, die durch die „split“-Ausrichtung von pandas erzeugt wird. Der Anforderungstext ist unter einem:code:dataframe_split-Schlüssel in der folgenden Struktur organisiert:

• index: Eine Liste von Zeilenindizes.

• columns: Eine Liste der Spaltennamen.

• data: Eine Liste von Zeilen, wobei jede Zeile eine Liste von Werten ist, die auf die Spalten abgestimmt sind.

Beispiel für eine cURL-Anforderung:

curl -X POST "<endpoint_url>" \
  -H 'Authorization: Snowflake Token="<pat_token>"' \
  -H 'Content-Type: application/json' \
  -w "\n\n=== RESULT ===\nHTTP Status: %{http_code}\nTotal Time: %{time_total}s\nConnect Time: %{time_connect}s\nServer Processing: %{time_starttransfer}s\nResponse Size: %{size_download} bytes\nRequest Size: %{size_upload} bytes\n" \
 -d '{
       "dataframe_split": {
         "index": [0, 1],
         "columns": ["customer_id", "age", "monthly_spend"],
         "data": [
            [101, 32, 85.5],
            [102, 45, 120.0],
         ]
       }
     }'

1. dataframe_records-Format

dataframe_records entspricht der Struktur, die durch die „records“-Ausrichtung von pandas erzeugt wird.

• Eine Liste von Datensätzen, wobei jeder Datensatz ein Wörterbuch ist, das Spaltennamen zu Werten zuordnet.

Der Anforderungstext ist unter dem dataframe_records-Schlüssel in der folgenden Liste organisiert:

Beispiel für eine cURL-Anforderung:

curl -X POST "<endpoint_url>" \
  -H 'Authorization: Snowflake Token="<pat_token>"' \
  -H 'Content-Type: application/json' \
  -w "\n\n=== RESULT ===\nHTTP Status: %{http_code}\nTotal Time: %{time_total}s\nConnect Time: %{time_connect}s\nServer Processing: %{time_starttransfer}s\nResponse Size: %{size_download} bytes\nRequest Size: %{size_upload} bytes\n" \
 -d '{
       "dataframe_records": [
          {
            "customer_id": 101,
            "age": 32,
            "monthly_spend": 85.5,
          },
          {
            "customer_id": 102,
            "age": 45,
            "monthly_spend": 120.0,
          },
        ]
     }'

Python-Beispiele¶

1. dataframe_split-Format

Snowflake empfiehlt, die Payload mithilfe der JSON-Serialisierung von pandas zu erzeugen und vor dem Senden der Anforderung mit json.loads zu deserialisieren. Dadurch wird sichergestellt, dass die Datentypen konsistent gehandhabt werden.

import json
import pandas as pd
import requests

# Example DataFrame
df = pd.DataFrame(
    {
        "customer_id": [101, 102],
        "age": [32, 45],
        "monthly_spend": [85.5, 120.0],
    }
)

ENDPOINT_URL = "<your endpoint URL>"
HEADERS = {
    "Authorization": f'Snowflake Token="{PAT}"',
    "Content-Type": "application/json"
}

# Use Pandas to generate the JSON, then load it back to a Python dict
split_obj = json.loads(df.to_json(orient="split"))

payload = {
    "dataframe_split": split_obj
}

response = requests.post(
    ENDPOINT_URL,
    headers=HEADERS,
    json=payload,
    timeout=30,
)

result = response.json()

Wichtigste Punkte:

• Verwenden Sie pd.Dataframe.to_json (z. B. df.to_json(orient="split") ), um Typen wie Zeitstempel, Floats, Nullen, Kategoriale usw. korrekt zu verarbeiten, mit denen das native JSON-Serialisierungsprogramm nicht vertraut ist.

• json.loads(...) konvertiert die JSON-Zeichenfolge in ein Python-Wörterbuch, damit die Nutzlast korrekt erstellt werden kann.

• requests.post(..., json=payload) serialisiert das Wörterbuch für die HTTP-Anforderung zurück nach JSON.

1. dataframe_records-Format

Verwenden Sie wie auch bei dataframe_split die JSON-Serialisierung von pandas und json.loads:

import json
import pandas as pd
import requests

df = pd.DataFrame(
    {
        "customer_id": [101, 102],
        "age": [32, 45],
        "monthly_spend": [85.5, 120.0],
    }
)

ENDPOINT_URL = "<your endpoint invoke URL>"
HEADERS = {
    "Authorization": "Bearer <your token>",
    "Content-Type": "application/json",
}

records_obj = json.loads(df.to_json(orient="records"))

payload = {
    "dataframe_records": records_obj
}

response = requests.post(
    ENDPOINT_URL,
    headers=HEADERS,
    json=payload,
    timeout=30,
)

response.raise_for_status()
result = response.json()

Nächste Schritte¶

Erkunden Sie diese detaillierten Anleitungen zur Optimierung und Verwaltung Ihrer Inferenzdienste:

• Beispiel-Workflows: Siehe End-to-End-Code für XGBoost (CPU), Hugging Face (GPU) und PyTorch-Modelle.

• Service Management und Skalierung: Erfahren Sie mehr über die automatische Skalierung, manuelles Anhalten und die Hardware-Konfiguration.

• Stabile Endpunkte und API-Referenz: Erhalten Sie detaillierte Einblicke in das Snowflake Gateway, die Authentifizierung und Datenprotokolle (dataframe_split).

• Automatische Erfassung von Inferenzprotokollen: Richten Sie die automatische Protokollierung für die Modellüberwachung ein.

• Problembehandlung: Gängige Korrekturen für Paketkonflikte, OOM- und Build-Fehler.