Performances - Amazon EKS
Mise à l'échelle et performances des applications

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.

Performances

Mise à l'échelle et performances des applications

Gestion des artefacts ML, des frameworks de service et optimisation du démarrage

Le déploiement de modèles d'apprentissage automatique (ML) sur Amazon EKS nécessite une réflexion approfondie sur la manière dont les modèles sont intégrés aux images de conteneur et aux environnements d'exécution. Cela garantit l'évolutivité, la reproductibilité et l'utilisation efficace des ressources. Cette rubrique décrit les différentes approches de gestion des artefacts du modèle ML, de sélection de frameworks de service et d'optimisation des temps de démarrage des conteneurs grâce à des techniques telles que la pré-mise en cache, toutes conçues pour réduire les temps de démarrage des conteneurs.

Réduction de la taille des images des conteneurs

  • La réduction de la taille des images du conteneur au démarrage est un autre moyen de réduire la taille des images. Vous pouvez effectuer des réductions à chaque étape du processus de création de l'image du conteneur. Pour commencer, choisissez les images de base contenant le moins de dépendances requises. Lors de la création d'images, incluez uniquement les bibliothèques et artefacts essentiels requis. Lorsque vous créez des images, essayez de combiner plusieurs commandes RUN ou COPY pour créer un plus petit nombre de couches plus grandes. La création d'images plus petites présente les avantages et les inconvénients suivants :

  • Avantages :

    • Les extractions d'images sont plus rapides et nécessitent moins de stockage dans l'ensemble.

    • Les images de petite taille ont moins de vecteur d'attaque.

  • Inconvénients :

    • Les images de conteneur étant de plus en plus rationalisées, vous devrez créer plusieurs images pour répondre aux besoins d'exécution dans différents environnements.

    • Les économies de taille résultant de la combinaison de commandes peuvent parfois être négligeables. Vous devez donc tester différentes approches de construction pour déterminer celle qui donne les meilleurs résultats. Pour les AI/ML frameworks, sélectionnez des variantes telles que les images destinées pytorch/pytorch:2.7.1-cuda11.8-cudnn9-runtime à l'exécution uniquement (par exemple, 3,03 Go contre 6,66 Go pour le développement), mais comparez les charges de travail car les images plus petites peuvent ignorer la compilation JIT, ce qui ralentit les chemins de code. Utilisez des versions en plusieurs étapes pour séparer la construction et l'exécution, en copiant uniquement les artefacts requis (par exemple, via COPY —from= pour les registres ou les contextes locaux). Utilisez l'optimisation des couches en combinant COPY dans une étape d'assemblage pour réduire le nombre de couches, tout en réduisant l'efficacité du cache et en allongeant les temps de création.

Gestion des artefacts du modèle ML dans les déploiements

L'une des décisions clés est de savoir comment gérer les artefacts du modèle ML (par exemple, les poids, les configurations) eux-mêmes. Le choix a un impact sur la taille de l'image, la vitesse de déploiement, la fréquence de mise à jour du modèle et la surcharge opérationnelle. Ce n'est pas que lorsque nous parlons de stockage du « modèle », nous faisons référence aux artefacts du modèle (par exemple, les paramètres entraînés, les poids du modèle). Il existe trois approches pour gérer les artefacts du modèle ML sur Amazon EKS. Chacun a ses inconvénients, et le meilleur dépend de la taille de votre modèle, de la cadence de mise à jour et des besoins en infrastructure, classés du moins recommandé au plus recommandé :

Intégration du modèle dans l'image du conteneur Copiez les fichiers du modèle (par exemple, .safetensors, .pth, .h5) dans l'image du conteneur (par exemple, Dockerfile) lors de la création de l'image. Le modèle fait partie de l'image immuable. Nous recommandons d'utiliser cette approche pour les petits modèles avec des mises à jour peu fréquentes.

  • Avantages : Garantit la cohérence et la reproductibilité, aucun retard de chargement, simplifie la gestion des dépendances.

  • Inconvénients : augmente la taille des images, ralentit les compilations et les transmissions, nécessite une reconstruction et un redéploiement pour les mises à jour des modèles, ce qui n'est pas idéal pour les modèles de grande taille en raison du débit d'extraction du registre. En outre, cela peut entraîner des boucles de rétroaction plus longues pour l'expérimentation, le débogage et les tests en raison de la complexité de la configuration, et cela peut augmenter les coûts de stockage en cas de colocation entre différentes images.

Téléchargement du modèle lors de l'exécution Au démarrage du conteneur, l'application télécharge le modèle depuis un stockage externe (par exemple, Amazon S3, soutenu par S3 CRT pour des transferts haut débit optimisés à l'aide de méthodes telles que le pilote CSI Mountpoint pour S3, la CLI AWS S3 ou la CLI OSS s5cmd) via des scripts dans un conteneur d'initialisation ou un point d'entrée. Nous recommandons de commencer par cette approche pour les grands modèles soumis à des mises à jour fréquentes.

  • Avantages : permet aux images de conteneur de se concentrer sur les code/runtime, enables easy model updates without rebuilds, supports versioning via storage metadata. It also allows for A/B tests, le remplacement à chaud ou la restauration de modèles sans augmenter la taille de l'image du conteneur, et permet de partager des modèles entre différentes applications sans les intégrer dans toutes les images de conteneur. En outre, il introduit des modifications minimes dans les flux de travail du ML ou des équipes d'application et permet de créer des conteneurs plus rapidement pour faciliter l'expérimentation et les tests. L'utilisation d'outils S3 CRT tels que l'AWS CLI, s5cmd ou le pilote CSI Mountpoint S3 permet de réduire considérablement la latence de téléchargement et d'améliorer les performances des fichiers volumineux, ce qui se traduit souvent par des temps de démarrage globaux plus rapides du pod par rapport à l'extraction d'images de conteneurs volumineux depuis des registres tels que ECR, en fonction des performances du réseau et du registre.

  • Inconvénients : introduit des défaillances réseau potentielles (nécessite une logique de nouvelle tentative), nécessite une authentification et une mise en cache. La gestion du processus de téléchargement, notamment les nouvelles tentatives, la gestion des erreurs et les interruptions, ainsi que la gestion du stockage et du nettoyage supplémentaires qui reproduisent les fonctionnalités ECR constituent une complexité opérationnelle supplémentaire.

Montage du modèle via des volumes persistants Stockez le modèle dans un espace de stockage externe (par exemple, Amazon EFS, EBS, FSx pour NetApp ONTAP, FSx pour Lustre, FSx pour OpenZFS ou S3 via le pilote CSI Mountpoint S3) et montez-le en tant que Kubernetes (PV). PersistentVolume Il s'agit des fichiers et des données générés pendant le processus d'entraînement du modèle qui lui permettent de faire des prédictions ou des inférences. Nous recommandons d'utiliser cette approche pour les modèles partagés entre des pods ou des clusters.

  • Avantages : dissocie le modèle de l'image pour un accès partagé, facilite les mises à jour sans redémarrage (si votre infrastructure le permet) et gère efficacement les grands ensembles de données. Il permet également le provisionnement et le contrôle d'accès pilotés par Kubernetes via des fonctionnalités telles que le clonage, le partage et les instantanés, réduisant ainsi le besoin de copier des modèles et de créer de nouvelles opérations. Le contrôle d'accès aux modèles basé sur POSIX est possible, ainsi que la possibilité de mettre à jour les versions des modèles séparément de l'application sans reconstruire l'image du conteneur, et des constructions de conteneurs plus rapides à des fins d'expérimentation et de test. Pour les applications d' AI/ML inférence qui lisent des artefacts en mémoire, cela permet de charger les données directement depuis le système de fichiers externe sans avoir à les stocker de manière intermédiaire sur le disque local du nœud, ce qui améliore les performances de chargement. En outre, pour le stockage de grands modèles à grande échelle, des services tels que FSx NetApp ONTAP ou Lustre fournissent des techniques d'optimisation du stockage (par exemple, déduplication, compression, provisionnement léger), le contrôle des versions via des instantanés et la prise en charge de la réutilisation du même fichier sans gaspiller d'espace de stockage. FSx D'autres services, tels que S3, proposent un versionnement natif. Cette approche peut également s'étendre à des clusters et potentiellement à des régions, en fonction de la configuration de réplication (par exemple, réplication asynchrone FSx ou inter-région dans S3 et EFS).

  • Inconvénients : peut augmenter la I/O latence en cas de connexion au réseau, nécessite un provisionnement du stockage et des contrôles d'accès, peut être moins portable (par exemple, EBS) si le stockage est spécifique au cluster. Les compromis incluent une complexité opérationnelle accrue pour les CI/CD modifications et la maintenance des processus de chargement, le besoin de TTL/retention mécanismes personnalisés pour réduire les coûts de stockage et une réplication interrégionale plus complexe. Les performances de lecture des artefacts du modèle doivent être mesurées par rapport au temps de téléchargement de l'image du conteneur.

Au service des modèles ML

Le déploiement et le service de modèles d'apprentissage automatique (ML) sur Amazon EKS nécessitent de sélectionner une approche de diffusion de modèles appropriée afin d'optimiser la latence, le débit, l'évolutivité et la simplicité opérationnelle. Le choix dépend de votre type de modèle (par exemple, langage, modèle de vision), des exigences en matière de charge de travail (par exemple, inférence en temps réel) et de l'expertise de votre équipe. Les approches courantes incluent des configurations basées sur Python pour le prototypage, des serveurs de modèles dédiés pour les fonctionnalités de production et des moteurs d'inférence spécialisés pour des performances et une efficacité élevées. Chaque méthode implique des compromis en termes de complexité de configuration, de performances et d'utilisation des ressources. Notez que les frameworks de distribution peuvent augmenter la taille (multiple GBs) des images de conteneur en raison de dépendances, ce qui peut avoir un impact sur les temps de démarrage. Envisagez le découplage à l'aide de techniques de gestion des artefacts pour atténuer ce problème. Les options sont répertoriées de la moins recommandée à la plus recommandée :

À l'aide de frameworks Python (par exemple, FastAPI, HuggingFace Transformers with PyTorch) Développez une application personnalisée à l'aide de frameworks Python, en intégrant des fichiers de modèle (poids, configuration, tokenizer) dans une configuration de nœud conteneurisé.

  • Avantages : prototypage facile, Python uniquement sans infrastructure supplémentaire, compatible avec tous les HuggingFace modèles, déploiement simple de Kubernetes.

  • Inconvénients : se limite au traitement par request/simple lots uniques, génération lente de jetons (pas de noyaux optimisés), mémoire inefficace, manque de scalabilité et de surveillance et implique de longs temps de démarrage.

  • Recommandation : à utiliser pour le prototypage initial ou pour les tâches à nœud unique nécessitant une intégration logique personnalisée.

Utilisation de frameworks de service de modèles dédiés (par exemple, TensorRT-LLM, TGI) Adoptez des serveurs spécialisés tels que TensorRT-LLM ou TGI pour l'inférence ML, la gestion du chargement, du routage et de l'optimisation des modèles. Ils prennent en charge des formats tels que les capteurs de sécurité, avec une compilation optionnelle ou des plugins.

  • Avantages : Propose le traitement par lots (static/in-flight or continuous), quantization (INT8, FP8, GPTQ), hardware optimizations (NVIDIA, AMD, Intel, Inferentia), and multi-GPU support (Tensor/Pipelineparallélisme). TensorRT-LLM prend en charge divers modèles (encodeur-décodeur)LLMs, tandis que TGI tire parti de l'intégration. HuggingFace

  • Inconvénients : TensorRT-LLM doit être compilé et n'est disponible que sur NVIDIA ; TGI peut être moins efficace pour le traitement par lots ; les deux ajoutent une charge de configuration et peuvent ne pas convenir à tous les types de modèles (par exemple, les modèles autres que les transformateurs).

  • Recommandation : convient aux PyTorch/TensorFlow modèles nécessitant des capacités de production telles que A/B des tests ou un débit élevé avec du matériel compatible.

Utilisation de moteurs d'inférence spécialisés à haut débit (par exemple, vLLM) Utilisez des moteurs d'inférence avancés tels que vLLM, qui optimisent le service LLM, le traitement par lots en vol et la quantification (, -KV PagedAttention, AWQ), intégrés à la mise à l'échelle automatique d'EKS. INT8 FP8

  • Avantages : haut débit et efficacité de la mémoire (40 à 60 % d'économies de VRAM), gestion dynamique des demandes, diffusion de jetons, prise en charge de plusieurs processeurs graphiques Tensor Parallel à nœud unique et large compatibilité matérielle.

  • Inconvénients : optimisé pour les transformateurs à décodeur uniquement (par exemple, LLa MA), moins efficace pour les modèles sans transformateur, nécessite du matériel compatible (par exemple, NVIDIA GPUs) et des efforts de configuration.

  • Recommandation : le meilleur choix pour l'inférence LLM à volume élevé et à faible latence sur EKS, afin d'optimiser l'évolutivité et les performances.

Pré-mise en cache des images de conteneurs

Les images de conteneurs de grande taille (modèles similaires, par exemple PyTorch) peuvent entraîner des retards de démarrage à froid qui ont un impact sur la latence. Pour les charges de travail sensibles à la latence, telles que les charges de travail d'inférence en temps réel redimensionnées horizontalement et le démarrage rapide du pod, nous recommandons de précharger les images des conteneurs afin de minimiser les délais d'initialisation. Envisagez les approches suivantes, de la moins recommandée à la plus recommandée :

Utilisation du cache d'exécution du conteneur pour pré-extraire des images

  • Vous pouvez pré-extraire des images de conteneur sur des nœuds à l'aide des ressources Kubernetes (par exemple, DaemonSet ou Deployment) pour remplir le cache d'exécution du conteneur du nœud. Le cache d'exécution du conteneur est le stockage local géré par le moteur d'exécution du conteneur (par exemple, [containerd] (https://containerd.io/)) où les images sont stockées après avoir été extraites d'un registre. Le pré-extraction garantit la disponibilité des images localement, évitant ainsi les retards de téléchargement lors du démarrage du pod. Cette approche est utile lorsque les instantanés EBS ne sont pas préconfigurés ou lorsqu'il est préférable de pré-extraire des images. Consultez le [ GitHub référentiel d'échantillons AWS] (https://github.com/aws-samples/aws-do-eks/tree/main/Container-Root/eks/deployment/prepull) pour des exemples de pré-extraction d'images. Notez que des alternatives telles que le chargement différé avec le [SOCI Snapshotter] (un plugin containerd pour les https://github.com/awslabs/extractions partielles d'images) peuvent compléter ces méthodes, bien qu'elles nécessitent une configuration personnalisée et ne conviennent pas à tous les scénarios. L'utilisation du cache d'exécution du conteneur présente les avantages et les inconvénients suivants :

  • Avantages :

    • Il n'est pas nécessaire de gérer les instantanés EBS.

    • Avec DaemonSets vous, vous obtenez toujours la dernière version de l'image du conteneur.

    • Plus flexible, car les images peuvent être mises à jour sans avoir à recréer des instantanés.

    • Réduit tout de même le temps de démarrage du pod en garantissant que les images se trouvent déjà sur le nœud.

  • Inconvénients :

    • L'extraction initiale d'images de grande taille peut encore prendre du temps, même si cela se fait à l'avance.

    • Ce n'est peut-être pas aussi efficace que les instantanés EBS pour les images de très grande taille (plus de 10 Go), car il est toujours nécessaire de les extraire, mais pas au démarrage du pod.

    • Avec DaemonSets, une image est pré-extraite vers tous les nœuds sur lesquels le pod est susceptible de fonctionner. Par exemple, si 1 000 nœuds n'exécutaient qu'une seule instance d'un pod, de l'espace est consommé sur les 1 000 nœuds uniquement pour exécuter l'instance sur un nœud.

    • Pour les charges de travail d'inférence en temps réel dans lesquelles les nœuds évoluent ou diminuent, les nouveaux nœuds ajoutés par des outils tels que Cluster Autoscaler peuvent planifier des modules de charge de travail avant que le pré-pull ne termine l'extraction de l'image. DaemonSet Cela peut amener le pod initial du nouveau nœud à déclencher le pull de toute façon, ce qui peut retarder le démarrage et avoir un impact sur les exigences de faible latence.

    • La collecte de déchets d'images par Kubelet peut affecter les images pré-extraites en supprimant celles qui ne sont pas utilisées lorsque l'utilisation du disque dépasse certains seuils ou si elles dépassent un âge maximum d'inutilisation configuré. Dans les modèles de scale-in/out, cela peut entraîner l'expulsion des images sur les nœuds inactifs, ce qui nécessite des extractions supplémentaires lors des mises à l'échelle ultérieures et réduit la fiabilité du cache pour les charges de travail en rafale.

Utilisation des instantanés EBS

  • Vous pouvez prendre un instantané Amazon Elastic Block Store (EBS) des images de conteneurs mises en cache et le réutiliser pour les nœuds de travail EKS. Cela garantit que les images sont préextraites localement au démarrage du nœud, ce qui réduit le temps d'initialisation du module. Consultez ce document Réduisez le temps de démarrage des conteneurs sur Amazon EKS avec le volume de données Bottlerocket pour plus d'informations sur Karpenter et ces plans EKS Terraform pour les groupes de nœuds gérés. Nous vous recommandons d'automatiser la création d'instantanés EBS dans le cadre de votre CI/CD pipeline afin de les conserver up-to-date avec les dernières versions des images de conteneur. L'utilisation des instantanés EBS présente les avantages et les inconvénients suivants :

  • Avantages :

    • Élimine le besoin d'extraire de grandes images de conteneur au démarrage du pod, ce qui réduit considérablement le temps de démarrage (par exemple, de 10 à 15 minutes à quelques secondes pour les images de plus de 10 Go).

    • Garantit que les images sont disponibles localement au démarrage du nœud.

    • Particulièrement utile pour les charges de travail d'inférence comportant de grandes images de conteneur.

  • Inconvénients :

    • Nécessite la maintenance et la mise à jour des instantanés EBS à chaque mise à niveau d'image ou de version.

    • Nécessite des étapes supplémentaires pour garantir que toutes vos charges de travail utilisent la dernière version de l'image du conteneur.

    • Implique des activités opérationnelles supplémentaires pour créer et gérer des instantanés.

    • Peut inclure des images inutiles si elle n'est pas correctement gérée, mais cela peut être atténué par une configuration appropriée du pool de nœuds.

Optimisez les performances d'extraction d'images

Nous recommandons vivement d'optimiser les performances d'extraction d'images de conteneurs pour les clusters Amazon EKS exécutant des AI/ML charges de travail. L'utilisation d'images de base volumineuses non optimisées ou d'un ordre des couches inefficace peut ralentir le démarrage des pods, augmenter la consommation de ressources et réduire la latence d'inférence. Pour y remédier, adoptez des images de base petites et légères avec un minimum de dépendances, adaptées à vos charges de travail. Vous pouvez également envisager les AWS Deep Learning Containers (DLCs), qui sont des images de conteneur prédéfinies qui facilitent l'exécution de frameworks d'apprentissage profond populaires (par exemple, PyTorchet TensorFlow). Pour en savoir plus sur la création d'une image personnalisée, consultez la section Personnaliser les Deep Learning Containers. Lorsque vous créez des images personnalisées, pensez à des images de base légères et ajoutez uniquement les bibliothèques nécessaires pour préserver la netteté des images. Utilisez des versions en plusieurs étapes pour réduire la taille des couches et optimiser l'ordre des couches pour une mise en cache efficace. Pour plus de détails, consultez les meilleures pratiques Docker pour créer des images.

Réduisez les temps de démarrage des conteneurs en préchargeant les images des conteneurs dans des volumes de données

Pour les charges de travail d'apprentissage automatique nécessitant une faible latence de démarrage des pods, telles que l'inférence en temps réel, nous recommandons de précharger les images des conteneurs afin de minimiser les délais d'initialisation. Les images de conteneur de grande taille peuvent ralentir le démarrage du pod, en particulier sur les nœuds dont la bande passante est limitée. Outre l'utilisation d'images de base minimales, de builds en plusieurs étapes et de techniques de chargement différé, envisagez les approches suivantes pour précharger des images dans Amazon EKS. Outre l'utilisation d'images de base minimales, de builds en plusieurs étapes et de techniques de chargement différé, considérez les options suivantes :

  • Préchargez des images à l'aide d'instantanés EBS : prenez un instantané Amazon Elastic Block Store (EBS) des images de conteneurs mises en cache et réutilisez cet instantané pour les nœuds de travail EKS. Bien que cela ajoute des activités opérationnelles supplémentaires, cela garantit que les images sont préextraites localement au démarrage du nœud, réduisant ainsi le temps d'initialisation du pod. Consultez ce document Réduisez le temps de démarrage des conteneurs sur Amazon EKS avec le volume de données Bottlerocket pour plus d'informations sur Karpenter et ces plans EKS Terraform pour les groupes de nœuds gérés.

  • Pré-extraction des images dans le cache d'exécution du conteneur : préextrayez les images du conteneur sur les nœuds à l'aide des ressources Kubernetes (par exemple, DaemonSet ou Deployment) pour remplir le cache d'exécution du conteneur du nœud. Le cache d'exécution du conteneur est le stockage local géré par le moteur d'exécution du conteneur (par exemple, containerd) où les images sont stockées après avoir été extraites d'un registre. Le pré-extraction garantit la disponibilité des images localement, évitant ainsi les retards de téléchargement lors du démarrage du pod. Cette approche est utile lorsque les instantanés EBS ne sont pas préconfigurés ou lorsqu'il est préférable de pré-extraire des images. Testez cette approche dans un environnement intermédiaire pour valider les améliorations de latence. Consultez le GitHub référentiel AWS Samples pour des exemples de pré-extraction d'images.