Présentation de la boîte à outils d'analyse comparative des inférences sans serveur Amazon SageMaker

Republié par Platon

Suiveurs: 0

Inférence sans serveur Amazon SageMaker est une option d'inférence spécialement conçue qui vous facilite le déploiement et la mise à l'échelle de modèles d'apprentissage automatique (ML). Il fournit un modèle de paiement à l'utilisation, idéal pour les services où les appels de point de terminaison sont peu fréquents et imprévisibles. Contrairement à un point de terminaison d'hébergement en temps réel, qui s'appuie sur une instance de longue durée, les ressources de calcul des points de terminaison sans serveur sont provisionnées à la demande, éliminant ainsi le besoin de choisir des types d'instance ou de gérer des politiques de mise à l'échelle.

L'architecture de haut niveau suivante illustre le fonctionnement d'un point de terminaison sans serveur. Un client appelle un point de terminaison soutenu par l'infrastructure gérée par AWS.

Cependant, les points de terminaison sans serveur sont sujets à des démarrages à froid de l'ordre de quelques secondes et sont donc plus adaptés aux charges de travail intermittentes ou imprévisibles.

Pour vous aider à déterminer si un point de terminaison sans serveur constitue la bonne option de déploiement du point de vue des coûts et des performances, nous avons développé le Kit d'outils d'analyse comparative d'inférence sans serveur SageMaker, qui teste différentes configurations de points de terminaison et compare la plus optimale à une instance d'hébergement en temps réel comparable.

Dans cet article, nous présentons la boîte à outils et fournissons un aperçu de sa configuration et de ses sorties.

Vue d'ensemble de la solution

Vous pouvez télécharger la boîte à outils et l'installer à partir du GitHub repo. La mise en route est simple : installez simplement la bibliothèque, créez un Modèle SageMaker, et fournissez le nom de votre modèle ainsi qu'un fichier au format de lignes JSON contenant un exemple d'ensemble de paramètres d'appel, y compris le corps de la charge utile et le type de contenu. Une fonction pratique est fournie pour convertir une liste d'exemples d'arguments d'invocation en un fichier de lignes JSON ou un fichier pickle pour les charges utiles binaires telles que des images, de la vidéo ou de l'audio.

Installer la boîte à outils

Installez d'abord la bibliothèque d'analyse comparative dans votre environnement Python à l'aide de pip :

pip install sm-serverless-benchmarking

Vous pouvez exécuter le code suivant à partir d'un Amazon SageMakerStudio exemple, Instance de notebook SageMaker, ou toute instance avec accès programmatique à AWS et le approprié Gestion des identités et des accès AWS (IAM). Les autorisations IAM requises sont documentées dans le GitHub repo. Pour obtenir des conseils supplémentaires et des exemples de politiques pour IAM, reportez-vous à Fonctionnement d'Amazon SageMaker avec IAM. Ce code exécute un benchmark avec un ensemble de paramètres par défaut sur un modèle qui attend une entrée CSV avec deux exemples d'enregistrements. C'est une bonne pratique de fournir un ensemble représentatif d'exemples pour analyser les performances du point de terminaison avec différentes charges utiles d'entrée.

from sm_serverless_benchmarking import benchmark
from sm_serverless_benchmarking.utils import convert_invoke_args_to_jsonl
model_name = ""
example_invoke_args = [
        {'Body': '1,2,3,4,5', "ContentType": "text/csv"},
        {'Body': '6,7,8,9,10', "ContentType": "text/csv"}
        ]
example_args_file = convert_invoke_args_to_jsonl(example_invoke_args,
output_path=".")
r = benchmark.run_serverless_benchmarks(model_name, example_args_file)

De plus, vous pouvez exécuter le test en tant que tâche de traitement SageMaker, ce qui peut constituer une option plus fiable pour les tests de performance à plus long terme avec un grand nombre d'appels. Voir le code suivant :

from sm_serverless_benchmarking.sagemaker_runner import run_as_sagemaker_job
run_as_sagemaker_job(
                    role="",
                    model_name="",
                    invoke_args_examples_file="",
                    )

Notez que cela entraînera des coûts supplémentaires liés à l’exécution d’une instance ml.m5.large SageMaker Processing pendant la durée du test.

Les deux méthodes acceptent un certain nombre de paramètres à configurer, tels qu'une liste de configurations de mémoire à évaluer et le nombre de fois où chaque configuration sera invoquée. Dans la plupart des cas, les options par défaut devraient suffire comme point de départ, mais reportez-vous au GitHub repo pour une liste complète et des descriptions de chaque paramètre.

Configuration d'analyse comparative

Avant d'examiner ce que fait le benchmark et les résultats qu'il produit, il est important de comprendre quelques concepts clés lorsqu'il s'agit de configurer des points de terminaison sans serveur.

Il y a deux options de configuration clés: MemorySizeInMB ainsi que MaxConcurrency. MemorySizeInMB configure la quantité de mémoire allouée à l'instance et peut être de 1024 2048 Mo, 3072 4096 Mo, 5120 6144 Mo, XNUMX XNUMX Mo, XNUMX XNUMX Mo ou XNUMX XNUMX Mo. Le nombre de processeurs virtuels évolue également proportionnellement à la quantité de mémoire allouée. Le MaxConcurrency Le paramètre ajuste le nombre de requêtes simultanées qu’un point de terminaison est capable de traiter. Avec un MaxConcurrency de 1, un point de terminaison sans serveur ne peut traiter qu'une seule requête à la fois.

Pour résumer, le MemorySizeInMB Le paramètre fournit un mécanisme d'évolutivité verticale, vous permettant d'ajuster les ressources de mémoire et de calcul pour servir des modèles plus grands, tandis que MaxConcurrency fournit un mécanisme d'évolutivité horizontale, permettant à votre point de terminaison de traiter davantage de requêtes simultanées.

Le coût d'exploitation d'un point de terminaison est largement déterminé par la taille de la mémoire, et il n'y a aucun coût associé à l'augmentation de la simultanéité maximale. Cependant, il existe une limite de compte par région pour une simultanéité maximale sur tous les points de terminaison. Faire référence à Points de terminaison et quotas SageMaker pour les dernières limites.

Résultats de l'analyse comparative

Compte tenu de cela, l’objectif de l’analyse comparative d’un point de terminaison sans serveur est de déterminer le paramètre de taille de mémoire le plus rentable et le plus fiable, ainsi que la simultanéité maximale minimale capable de gérer vos modèles de trafic attendus.

Par défaut, l'outil exécute deux benchmarks. Le premier est un test de stabilité, qui déploie un point de terminaison pour chacune des configurations de mémoire spécifiées et appelle chaque point de terminaison avec les exemples de charges utiles fournis. L’objectif de ce test est de déterminer le paramètre MemorySizeInMB le plus efficace et le plus stable. Le test de référence capture les latences d'appel et calcule le coût attendu par appel pour chaque point de terminaison. Il compare ensuite le coût à celui d’une instance d’hébergement en temps réel similaire.

Une fois l'analyse comparative terminée, l'outil génère plusieurs sorties dans les délais spécifiés. result_save_path répertoire avec la structure de répertoire suivante :

├── benchmarking_report
├── concurrency_benchmark_raw_results
├── concurrency_benchmark_summary_results
├── cost_analysis_summary_results
├── stability_benchmark_raw_results
├── stability_benchmark_summary_results

Les benchmarking_report Le répertoire contient un rapport consolidé avec tous les résultats récapitulatifs que nous décrivons dans cet article. Des répertoires supplémentaires contiennent des sorties brutes et intermédiaires que vous pouvez utiliser pour des analyses supplémentaires. Se référer au GitHub repo pour une description plus détaillée de chaque artefact de sortie.

Examinons quelques résultats d'analyse comparative réels pour un point de terminaison servant un modèle TensorFlow MobileNetV2 de vision par ordinateur. Si vous souhaitez reproduire cet exemple, reportez-vous au exemples de cahiers répertoire dans le dépôt GitHub.

Le premier résultat du rapport consolidé est un tableau récapitulatif qui fournit les mesures de latence minimale, moyenne, moyenne et maximale pour chaque MemorySizeInMB configuration réussie de la taille de la mémoire. Comme le montre le tableau suivant, la latence d'appel moyenne (invocation_latency_mean) a continué de s'améliorer à mesure que la configuration de la mémoire a augmenté à 3072 XNUMX Mo, mais a cessé de s'améliorer par la suite.