Zustandsbehaftete Sitzungen mit Modellen von Amazon SageMaker AI - Amazon SageMaker KI
So funktionieren zustandsbehaftete SitzungenBeispielimplementierung

Die vorliegende Übersetzung wurde maschinell erstellt. Im Falle eines Konflikts oder eines Widerspruchs zwischen dieser übersetzten Fassung und der englischen Fassung (einschließlich infolge von Verzögerungen bei der Übersetzung) ist die englische Fassung maßgeblich.

Zustandsbehaftete Sitzungen mit Modellen von Amazon SageMaker AI

Wenn Sie Anforderungen an einen Inferenzendpunkt von Amazon SageMaker AI senden, können Sie wählen, ob die Anforderungen an eine zustandsbehaftete Sitzung weitergeleitet werden sollen. Während einer zustandsbehafteten Sitzung senden Sie mehrere Inferenzanforderungen an dieselbe ML-Instance und die Instance ermöglicht die Sitzung.

Wenn Sie einen Inferenzendpunkt aufrufen, leitet Amazon SageMaker AI Ihre Anforderung normalerweise an eine beliebige ML-Instance unter den vom Endpunkt gehosteten Instances weiter. Dieses Routing-Verhalten trägt dazu bei, die Latenz zu minimieren, indem Ihr Inferenzdatenverkehr gleichmäßig verteilt wird. Eine Folge des Routing-Verhaltens ist jedoch, dass Sie nicht vorhersagen können, welche Instance Ihre Anforderung bearbeiten wird.

Diese Unvorhersehbarkeit stellt eine Einschränkung dar, wenn Sie beabsichtigen, Ihre Anforderung an ein zustandsbehaftetes Modell zu senden. Ein zustandsbehaftetes Modell hat einen Container, der die Kontextdaten zwischenspeichert, die er aus Inferenzanforderungen erhält. Da die Daten zwischengespeichert werden, können Sie mit dem Container interagieren, indem Sie mehrere Anforderungen senden, und Sie müssen nicht bei jeder Anforderungen den vollständigen Kontext der Interaktion angeben. Stattdessen stützt sich das Modell auf die zwischengespeicherten Kontextdaten, um seine Prognose zu untermauern.

Zustandsbehaftete Modelle sind ideal, wenn die Kontextdaten für die Interaktion sehr umfangreich sind, z. B. wenn sie Folgendes beinhalten:

  • große Textdateien

  • lange Chatverläufe

  • Multimediadaten (Bilder, Video und Audio) für multimodale Modelle

In diesen Fällen wird die Netzwerklatenz Ihrer Anforderungen verlangsamt und die Reaktionsfähigkeit Ihrer Anwendung verringert, wenn Sie bei jedem Prompt den vollständigen Kontext übergeben.

Bevor Ihr Inferenzendpunkt eine zustandsbehaftete Sitzung unterstützen kann, muss er ein zustandsbehaftetes Modell hosten. Die Implementierung des zustandsbehafteten Modells müssen Sie selbst durchführen. Amazon SageMaker AI ermöglicht es Ihnen zwar, Ihre Anforderungen an eine zustandsbehaftete Sitzung weiterzuleiten, bietet jedoch keine zustandsbehafteten Modelle, die Sie bereitstellen und verwenden können.

Ein Beispiel für ein Notebook und einen Modellcontainer, das demonstriert, wie zustandsbehaftete Interaktionen implementiert werden, finden Sie unter Beispielimplementierung.

Informationen zur Implementierung von zustandsbehafteten Modellen mit TorchServe finden Sie unter Stateful Inference im TorchServe-GitHub-Repository.

So funktionieren zustandsbehaftete Sitzungen

Während einer zustandsbehafteten Sitzung interagiert Ihre Anwendung auf folgende Weise mit Ihrem Modellcontainer.

So starten Sie eine zustandsbehaftete Sitzung

  1. Um eine Sitzung mit einem zustandsbehafteten Modell zu starten, das von Amazon SageMaker AI gehostet wird, sendet Ihr Kunde eine InvokeEndpoint-Anforderung mit der SageMaker-API. Für den SessionID-Anforderungsparameter weist der Client SageMaker AI an, eine neue Sitzung zu starten, indem er den Wert NEW_SESSION angibt. In den Nutzdaten der Anfrage weist der Client den Container außerdem an, eine neue Sitzung zu starten. Die Syntax dieser Anweisung hängt von Ihrer Container-Implementierung ab. Sie hängt davon ab, wie Ihr Container-Code die Nutzdaten der Anforderung verarbeitet.

    Das folgende Beispiel startet eine neue Sitzung mit Hilfe des SDK für Python (Boto3):

    import boto3
import sagemaker
import json

payload = {
"requestType":"NEW_SESSION"
}
payload = json.dumps(payload)

smr = boto3.client(
    'sagemaker-runtime',
    region_name="region_name",
    endpoint_url="endoint_url")

create_session_response = smr.invoke_endpoint(
    EndpointName="endpoint_name",
    Body=payload,
    ContentType="application/json",
    SessionId="NEW_SESSION")

  2. Ihr Modellcontainer bearbeitet die Anforderung Ihres Kunden, indem er eine neue Sitzung startet. Für die Sitzung werden die Daten, die der Client sendet, in den Nutzdaten der Anforderung zwischengespeichert. Außerdem wird eine Sitzungs-ID erstellt und ein Time-to-Live (TTL)-Zeitstempel festgelegt. Dieser Zeitstempel gibt an, wann die Sitzung abläuft. Der Container muss Amazon SageMaker AI die Sitzungs-ID und den Zeitstempel zur Verfügung stellen, indem er den folgenden HTTP-Header in der Antwort festlegt:

    X-Amzn-SageMaker-Session-Id: session_id; Expires=yyyy-mm-ddThh:mm:ssZ

  3. In der Antwort auf die InvokeEndpoint-Anforderung stellt Amazon SageMaker AI die Sitzungs-ID und den TTL-Zeitstempel für den Antwortparameter NewSessionID bereit.

    Im folgenden Beispiel wird die Sitzungs-ID aus der invoke_endpoint-Antwort extrahiert:

    session_id = create_session_response['ResponseMetadata']['HTTPHeaders']['x-amzn-sagemaker-new-session-id'].split(';')[0]
So setzen Sie eine zustandsbehafteten Sitzung fort

  • Um dieselbe Sitzung für eine nachfolgende Inferenzanforderung zu verwenden, sendet Ihr Client eine weitere InvokeEndpoint-Anforderung. Für den SessionID-Anforderungsparameter gibt er die ID der Sitzung an. Mit dieser ID leitet SageMaker AI die Anforderung an dieselbe ML-Instance weiter, in der die Sitzung gestartet wurde. Da Ihr Container die ursprünglichen Nutzdaten der Anforderung bereits zwischengespeichert hat, muss Ihr Client nicht dieselben Kontextdaten wie in der ursprünglichen Anforderung übergeben.

    Im folgenden Beispiel wird eine Sitzung fortgesetzt, indem die Sitzungs-ID mit dem SessionId-Anforderungsparameter übergeben wird:

    smr.invoke_endpoint(
    EndpointName="endpoint_name",
    Body=payload,
    ContentType="application/json",
    SessionId=session_id)
Beenden einer zustandsbehafteten Sitzung

  1. Um eine Sitzung zu schließen, sendet Ihr Client eine letzte InvokeEndpoint-Anforderung. Für den SessionID-Anforderungsparameter gibt der Client die ID der Sitzung an. In den Nutzdaten im Anforderungstext gibt Ihr Client an, dass der Container die Sitzung schließen soll. Die Syntax dieser Anweisung hängt von Ihrer Container-Implementierung ab.

    Das folgende Beispiel schließt eine Sitzung:

    payload = {
    "requestType":"CLOSE"
}
payload = json.dumps(payload)

closeSessionResponse = smr.invoke_endpoint(
    EndpointName="endpoint_name",
    Body=payload,
    ContentType="application/json",
    SessionId=session_id)

  2. Wenn der Container die Sitzung schließt, gibt er die Sitzungs-ID an SageMaker AI zurück, indem er den folgenden HTTP-Header in der Antwort festlegt:

    X-Amzn-SageMaker-Closed-Session-Id: session_id

  3. In der Antwort auf die InvokeEndpoint-Anforderung des Clients stellt SageMaker AI die Sitzungs-ID für den ClosedSessionId-Antwortparameter bereit.

    Im folgenden Beispiel wird die ID der geschlossenen Sitzung aus der invoke_endpoint-Antwort extrahiert:

    closed_session_id = closeSessionResponse['ResponseMetadata']['HTTPHeaders']['x-amzn-sagemaker-closed-session-id'].split(';')[0]

Beispielimplementierung

Das folgende Beispiel-Notebook zeigt, wie der Container für ein zustandsbehaftetes Modell implementiert wird. Es zeigt auch, wie eine Client-Anwendung eine zustandsbehaftete Sitzung startet, fortsetzt und beendet.

Zustandsbehaftete LLaVA-Inferenz mit SageMaker AI

Das Notebook verwendet das Modell LLava: Large Language and Vision Assistant, das Bilder und Text-Prompts akzeptiert. Das Notebook lädt ein Bild in das Modell hoch und stellt dann Fragen zu dem Bild, ohne dass das Bild für jede Anforderung erneut gesendet werden muss. Der Modellcontainer verwendet das TorchServe-Framework. Die Bilddaten werden im GPU-Speicher zwischengespeichert.