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. # Stateful-Sitzungen mit SageMaker Amazon-KI-Modellen Wenn Sie Anfragen an einen Amazon SageMaker AI-Inferenzendpunkt senden, können Sie wählen, ob die Anfragen an eine *statusbehaftete* Sitzung weitergeleitet werden sollen. Während einer Stateful-Sitzung senden Sie mehrere Inferenzanfragen an dieselbe ML-Instance, und die Instance erleichtert die Sitzung. Wenn Sie einen Inferenzendpunkt aufrufen, leitet Amazon SageMaker AI Ihre Anfrage normalerweise an eine beliebige ML-Instance unter den mehreren Instances weiter, die der Endpunkt hostet. 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, Ihre Anfragen an eine statusbehaftete Sitzung weiterzuleiten, bietet jedoch keine statusbehafteten 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](#stateful-sessions-example-notebook). Informationen zur Implementierung von Stateful-Modellen mit TorchServe finden Sie unter [Stateful Inference](https://github.com/pytorch/serve/tree/master/examples/stateful/sequence_continuous_batching) im Repository. TorchServe GitHub ## 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 Stateful-Modell zu starten, das von Amazon SageMaker AI gehostet wird, sendet Ihr Kunde eine [https://docs.aws.amazon.com/sagemaker/latest/APIReference/API_runtime_InvokeEndpoint.html](https://docs.aws.amazon.com/sagemaker/latest/APIReference/API_runtime_InvokeEndpoint.html)Anfrage 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") ``` 1. 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}} ``` 1. In der Antwort auf die `InvokeEndpoint` Anfrage stellt Amazon SageMaker AI die Sitzungs-ID und den TTL-Zeitstempel für den `NewSessionID` Antwortparameter 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 Anfrage 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) ``` 1. Wenn die Sitzung geschlossen wird, gibt der Container die Sitzungs-ID an SageMaker AI zurück, indem er in der Antwort den folgenden HTTP-Header festlegt: ``` X-Amzn-SageMaker-Closed-Session-Id: {{session_id}} ``` 1. In der Antwort auf die `InvokeEndpoint` Anfrage 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. [Lava Stateful-Inferenz mit KI SageMaker ](https://github.com/aws-samples/sagemaker-genai-hosting-examples/blob/main/LLava/torchserve/workspace/llava_stateful_deploy_infer.ipynb) Das Notebook verwendet das Modell [LLava: Large Language and Vision Assistant](https://github.com/haotian-liu/LLaVA/tree/main), 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 Framework. TorchServe Die Bilddaten werden im GPU-Speicher zwischengespeichert.