Les traductions sont fournies par des outils de traduction automatique. En cas de conflit entre le contenu d'une traduction et celui de la version originale en anglais, la version anglaise prévaudra.
Mise en cache des poids des modèles et mise en cache des images
Lorsque vous agrandissez un déploiement d'inférence, chaque nouveau pod doit extraire l'image du conteneur du serveur d'inférence à partir d'un registre. Il doit également télécharger les poids des modèles depuis le stockage distant (Amazon S3 ou Amazon FSx) avant de pouvoir gérer le trafic. Pour les modèles linguistiques de grande taille, le téléchargement des poids des modèles et l'extraction des images des conteneurs contribuent le plus à la latence de démarrage à froid.
Pour éliminer ces goulots d'étranglement lors de la mise à l'échelle, configurez l'un des mécanismes de mise en cache locaux de l'hôte suivants ou les deux dans Amazon Inference : SageMaker HyperPod
- Mise en cache des poids des modèles ()
weightsCache -
Pre-populates modélisez les fichiers de poids sur le stockage NVMe local de l'hôte sur chaque nœud éligible. Déduisez les poids de charge des modules sur les mêmes nœuds à partir du stockage local au lieu de les télécharger depuis la source du modèle distant, ce qui élimine les téléchargements redondants entre les modules.
- Mise en cache d'images ()
imageCache -
Pre-pulls l'image du conteneur du serveur d'inférence sur les nœuds cibles afin que les nouveaux pods démarrent sans attendre l'extraction d'une image à froid.
Vous configurez les deux mécanismes de mise en cache via le modelCacheConfig champ de votre JumpStartModel déploiement InferenceEndpointConfig ou de votre déploiement.
Vous pouvez activer la mise en cache des pondérations et la mise en cache des images indépendamment ou conjointement. Les deux fonctionnalités fonctionnent avec toutes les sources de modèles Amazon SageMaker HyperPod Inference, y compris les SageMaker JumpStart déploiements Amazon (modèles à poids ouverts et modèles fermés) et les modèles personnalisés d'Amazon S3 ou Amazon FSx.
Conditions préalables
Avant d'activer la mise en cache, vérifiez les points suivants :
- Type d'instance avec stockage NVMe local
-
La mise en cache des pondérations des modèles stocke les pondérations sur le stockage NVMe local de l'hôte (
/opt/dlami/nvmepar défaut). Votre type d'instance doit fournir un stockage NVMe local au niveau configuréhostPath. - Capacité NVMe suffisante
-
Assurez-vous que le nœud dispose d'un espace de stockage local suffisant pour votre modèle. Chaque déploiement utilise son propre répertoire de cache isolé, de sorte que plusieurs déploiements mis en cache sur le même nœud consomment chacun leur propre espace de stockage.
- Opérateur d'inférence
-
Votre cluster doit disposer d'une version de l'opérateur d' HyperPod inférence qui prend en charge la mise en cache des modèles. Si le
modelCacheConfigchamp n'est pas reconnu, mettez à jour le module complémentaire de l'opérateur d'inférence vers la dernière version.
Important
Si votre type d'instance ne dispose pas de stockage NVMe local au niveau configuréhostPath, la mise en cache des pondérations des modèles ne réchauffe pas le cache et les modules d'inférence reviennent au téléchargement des pondérations depuis la source distante du modèle. Vérifiez que votre type d'instance fournit un stockage NVMe local avant d'activer cette fonctionnalité.
Configurer la mise en cache des pondérations des modèles et la mise en cache des images
Ajoutez un modelCacheConfig bloc à votre JumpStartModel ressource InferenceEndpointConfig ou à votre ressource. spec L'exemple suivant active à la fois la mise en cache des pondérations des modèles et la mise en cache des images.
spec: # ... model source, worker, and TLS configuration ... modelCacheConfig: weightsCache: enabled: true hostPath: /opt/dlami/nvme imageCache: enabled: true
Le modelCacheConfig champ prend en charge les sous-champs suivants.
| Champ | Par défaut | Description |
|---|---|---|
weightsCache.enabled |
false |
Indique si la mise en cache des pondérations des modèles locaux à l'hôte est activée. Lorsquetrue, l'opérateur préremplit les poids du modèle sur le stockage local de l'hôte et les monte dans des modules d'inférence. |
weightsCache.hostPath |
/opt/dlami/nvme |
Le chemin hôte où les poids des modèles mis en cache sont stockés. Il doit s'agir d'un chemin absolu non vide d'au plus 255 caractères. |
imageCache.enabled |
false |
Si la mise en cache des images de conteneur est activée. Lorsquetrue, l'opérateur extrait au préalable l'image du conteneur du serveur d'inférence sur les nœuds cibles. |
Comment fonctionne la mise en cache des poids des modèles
Lorsque weightsCache.enabled c'est le castrue, l'opérateur télécharge les pondérations de modèle depuis la source de modèle distante (Amazon S3 ou Amazon FSx) vers le stockage NVMe local de l'hôte sur chaque nœud éligible avant que les pods d'inférence ne commencent à gérer le trafic. Les modules d'inférence montent les poids mis en cache en lecture seule et chargent le modèle depuis le stockage local au lieu de le télécharger à plusieurs reprises depuis la source distante.
L'opérateur remplit le cache sur les nœuds qui correspondent aux contraintes de planification du déploiement par inférence, et étiquette chaque nœud lorsque son cache est chaud. Le déploiement par inférence utilise l'affinité de nœud préférée sur cette étiquette, de sorte que les pods sont planifiés sur des nœuds chauds lorsqu'ils sont disponibles, mais peuvent toujours être planifiés ailleurs.
- Isolation
-
Chaque déploiement utilise un répertoire de cache isolé par déploiement dans le répertoire configuré
hostPath, de sorte que les déploiements de plusieurs modèles sur le même nœud n'interfèrent pas les uns avec les autres. - Cache Miss Fallback
-
Si un pod est planifié sur un nœud dont le cache n'est pas encore disponible, le déploiement revient au chargement des poids du modèle directement depuis la source du modèle distant, de sorte que les déploiements restent fonctionnels même sans cache chaud.
- Remplacement du nœud
-
Si un nœud est remplacé (par exemple, après une panne), l'opérateur doit réchauffer à nouveau le cache du nouveau nœud avant que les pods ne soient planifiés de préférence pour celui-ci. Entre-temps, les nœuds chauds existants continuent de gérer le trafic.
- Nettoyage lors de la suppression
-
Lorsque vous supprimez le déploiement, l'opérateur supprime les fichiers de poids mis en cache des nœuds qu'il a renseignés.
Comment fonctionne la mise en cache des images
Lorsque imageCache.enabled c'est le castrue, l'opérateur extrait au préalable l'image du conteneur du serveur d'inférence sur les nœuds cibles. Comme l'image est déjà présente sur le nœud, les nouveaux modules d'inférence évitent l'extraction d'images à froid qui retarderait autrement le démarrage du module. Cela est particulièrement utile pour les images de serveurs d'inférence volumineuses et pour les déploiements qui évoluent fréquemment.
La mise en cache des images est indépendante de la mise en cache des pondérations des modèles. Vous pouvez l'activer seul ou le combiner avec la mise en cache des pondérations pour réduire à la fois le temps d'extraction des images et de téléchargement des poids lors de la mise à l'échelle.
Vérifiez que la mise en cache fonctionne
Effectuez les vérifications suivantes pour vérifier que la mise en cache est active pour votre déploiement.
Vérifiez les étiquettes des nœuds pour un cache chaud
Lorsque le cache d'un nœud est chaud, l'opérateur lui applique une étiquette prête à être mise en cache. La mise en cache des pondérations des modèles utilise une étiquette avec le préfixeinference.sagemaker.aws.amazon.com/weights-cache-ready., et la mise en cache des images utilise le préfixeinference.sagemaker.aws.amazon.com/image-cache-ready., chacun étant suffixé par l'UID de la configuration de cache.
kubectl get nodes --show-labels | grep "cache-ready"
L'absence de sortie signifie qu'aucun nœud n'a encore réchauffé le cache.
Vérifiez les événements du pod pour le montage du cache
Inspectez un module d'inférence et vérifiez qu'il monte le chemin de cache local de l'hôte en lecture seule. Si le volume HostPath est absent, cela signifie que le pod charge des poids depuis le stockage distant.
kubectl describe podinference-pod-name-nnamespace
Vérifiez les journaux des opérateurs
Consultez les journaux des opérateurs d'inférence pour détecter toute activité de préchauffage du cache ou détecter des erreurs.
kubectl logs -n hyperpod-inference-system deployment/hyperpod-inference-controller-manager | grep -i "cache"
Résolution des problèmes
| Symptôme | Cause possible | Résolution |
|---|---|---|
| Les pods démarrent lentement même si la mise en cache est activée. | Le chemin NVMe n'existe pas sur le type d'instance. | Vérifiez que votre type d'instance dispose d'un stockage NVMe local et qu'il hostPath correspond au point de montage réel. |
| Le cache ne se réchauffe jamais. | Espace disque insuffisant sur le chemin d'accès de l'hôte. | Vérifiez la capacité disponible àhostPath. Les grands modèles peuvent nécessiter un stockage local important. |
| Aucun nœud n'est étiqueté comme prêt pour le cache. | Le téléchargement du cache a échoué ou la source distante est inaccessible. | Consultez les journaux de l'opérateur pour détecter les erreurs de téléchargement et vérifiez l'accès réseau à Amazon S3 ou Amazon FSx. |
| Les déploiements multiples entraînent une pression du disque sur un nœud. | Les déploiements mis en cache partagent le même nœud de stockage NVMe. | Utilisez des groupes d'instances distincts ou réduisez le nombre de déploiements simultanés mis en cache par nœud. |
Considérations
-
La mise en cache des poids des modèles nécessite des types d'instance dotés d'un stockage NVMe local. EBS-only les instances ne sont pas prises en charge.
-
La taille maximale du modèle pouvant être mise en cache est limitée par la capacité NVMe disponible sur le type d'instance.
-
Le temps de préchauffage du cache dépend de la taille du modèle et du débit réseau vers la source du modèle distant.
