Comment fonctionnent les sessions dynamiques Exemple de mise en œuvre

Sessions dynamiques avec des modèles Amazon SageMaker

Lorsque vous envoyez des demandes à un point de terminaison d' SageMaker inférence Amazon, vous pouvez choisir de les acheminer vers une session dynamique. Au cours d'une session dynamique, vous envoyez plusieurs demandes d'inférence à la même instance ML, et l'instance facilite la session.

Normalement, lorsque vous invoquez un point de terminaison d'inférence, Amazon SageMaker achemine votre demande vers n'importe quelle instance ML parmi les multiples instances hébergées par le point de terminaison. Ce comportement de routage permet de minimiser la latence en répartissant uniformément votre trafic d'inférence. Cependant, l'une des conséquences du comportement de routage est que vous ne pouvez pas prévoir quelle instance répondra à votre demande.

Cette imprévisibilité constitue une limite si vous avez l'intention d'envoyer votre demande à un modèle dynamique. Un modèle dynamique possède un conteneur qui met en cache les données contextuelles qu'il reçoit des demandes d'inférence. Les données étant mises en cache, vous pouvez interagir avec le conteneur en envoyant plusieurs demandes, et pour chaque demande, vous n'avez pas besoin d'inclure le contexte complet de l'interaction. Le modèle puise plutôt dans les données contextuelles mises en cache pour éclairer ses prévisions.

Les modèles dynamiques sont idéaux lorsque les données contextuelles de l'interaction sont très volumineuses, par exemple lorsqu'elles incluent les éléments suivants :

Fichiers texte volumineux
Longue histoire des discussions
Données multimédia (images, vidéo et audio) pour les modèles multimodaux

Dans ces cas, si vous transmettez le contexte complet à chaque invite, la latence réseau de vos demandes est ralentie et la réactivité de votre application est diminuée.

Avant que votre point de terminaison d'inférence puisse prendre en charge une session dynamique, il doit héberger un modèle dynamique. La mise en œuvre du modèle stateful vous appartient. Amazon vous SageMaker permet d'acheminer vos demandes vers une session dynamique, mais ne fournit pas de modèles dynamiques que vous pouvez déployer et utiliser.

Pour un exemple de bloc-notes et de conteneur de modèles illustrant la manière dont les interactions dynamiques sont mises en œuvre, voirExemple de mise en œuvre.

Pour plus d'informations sur l'implémentation de modèles dynamiques avec TorchServe, consultez Stateful Inference dans le référentiel. TorchServe GitHub

Comment fonctionnent les sessions dynamiques

Au cours d'une session dynamique, votre application interagit avec votre conteneur de modèles de la manière suivante.

Pour démarrer une session dynamique

Pour démarrer une session avec un modèle dynamique hébergé par Amazon SageMaker, votre client envoie une InvokeEndpointdemande avec le SageMaker API. Pour le paramètre de SessionID requête, le client demande SageMaker de démarrer une nouvelle session en spécifiant la valeurNEW_SESSION. Dans la charge utile de la demande, le client demande également au conteneur de démarrer une nouvelle session. La syntaxe de cette instruction varie en fonction de l'implémentation de votre conteneur. Cela dépend de la façon dont votre code de conteneur gère la charge utile de la demande.

L'exemple suivant démarre une nouvelle session en utilisant le SDK for 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")
```
Votre conteneur modèle gère la demande de votre client en démarrant une nouvelle session. Pendant la session, il met en cache les données que le client envoie dans la charge utile de la demande. Il crée également un identifiant de session et définit un horodatage time to live (TTL). Cet horodatage indique la date d'expiration de la session. Le conteneur doit fournir l'ID de session et l'horodatage à Amazon SageMaker en définissant l'HTTPen-tête suivant dans la réponse :
```
X-Amzn-SageMaker-Session-Id: session_id; Expires=yyyy-mm-ddThh:mm:ssZ
```
Dans la réponse à la InvokeEndpoint demande, Amazon SageMaker fournit l'ID de session et l'TTLhorodatage du paramètre de NewSessionID réponse.

L'exemple suivant extrait l'ID de session de la invoke_endpoint réponse :
```
session_id = create_session_response['ResponseMetadata']['HTTPHeaders']['x-amzn-sagemaker-new-session-id'].split(';')[0]
```

Pour poursuivre une session dynamique

Pour utiliser la même session pour une demande d'inférence ultérieure, votre client envoie une autre InvokeEndpoint demande. Pour le paramètre de SessionID requête, il indique l'ID de la session. Avec cet ID, SageMaker achemine la demande vers la même instance ML où la session a été démarrée. Comme votre conteneur a déjà mis en cache la charge utile de la demande d'origine, votre client n'a pas besoin de transmettre les mêmes données contextuelles que celles contenues dans la demande d'origine.

L'exemple suivant poursuit une session en transmettant l'ID de session avec le paramètre de SessionId requête :
```
smr.invoke_endpoint(
    EndpointName="endpoint_name",
    Body=payload,
    ContentType="application/json",
    SessionId=session_id)
```

Pour fermer une session dynamique

Pour fermer une session, votre client envoie une dernière InvokeEndpoint demande. Pour le paramètre de SessionID demande, le client fournit l'ID de la session. Dans la charge utile du corps de la demande, votre client indique que le conteneur doit fermer la session. La syntaxe de cette instruction varie en fonction de l'implémentation de votre conteneur.

L'exemple suivant ferme une session :
```
payload = {
    "requestType":"CLOSE"
}
payload = json.dumps(payload)

closeSessionResponse = smr.invoke_endpoint(
    EndpointName="endpoint_name",
    Body=payload,
    ContentType="application/json",
    SessionId=session_id)
```
Lorsqu'il ferme la session, le conteneur renvoie l'ID de session à SageMaker en définissant l'HTTPen-tête suivant dans la réponse :
```
X-Amzn-SageMaker-Closed-Session-Id: session_id
```
Dans la réponse à la InvokeEndpoint demande du client, SageMaker fournit l'ID de session pour le paramètre de ClosedSessionId réponse.

L'exemple suivant extrait l'ID de session fermée de la invoke_endpoint réponse :
```
closed_session_id = closeSessionResponse['ResponseMetadata']['HTTPHeaders']['x-amzn-sagemaker-closed-session-id'].split(';')[0]
```

Exemple de mise en œuvre

L'exemple de bloc-notes suivant montre comment implémenter le conteneur pour un modèle dynamique. Il montre également comment une application cliente démarre, poursuit et ferme une session dynamique.

LLaVAinférence dynamique avec SageMaker

Le bloc-notes utilise le modèle LLaVA: Large Language and Vision Assistant, qui accepte les images et les instructions textuelles. Le bloc-notes télécharge une image sur le modèle, puis pose des questions à son sujet sans avoir à renvoyer l'image pour chaque demande. Le conteneur modèle utilise le TorchServe framework. Il met en cache les données d'image en GPU mémoire.

Avertissement JavaScript est désactivé ou n'est pas disponible dans votre navigateur.

Pour que vous puissiez utiliser la documentation AWS, Javascript doit être activé. Vous trouverez des instructions sur les pages d'aide de votre navigateur.

Conventions de rédaction

Résolution des erreurs Ambarella

Bonnes pratiques