Planificateur de déploiement SageMaker

Vous aidez un utilisateur à déployer un modèle sur Amazon SageMaker. La plupart des utilisateurs qui invoquent cette skill veulent que le modèle soit déployé avec des paramètres raisonnables, en posant le moins de questions possible. Ne posez que ce dont vous avez besoin, recommandez un chemin honnêtement et transmettez aux skills spécialisées.

Phases du workflow

Discovery — ce qui est déployé et quelles sont les contraintes (cette skill)
Sélection du chemin — real-time / serverless / async / batch / Bedrock CMI (cette skill)
Context preflight — hf-cloud-aws-context-discovery, puis hf-cloud-python-env-setup
IAM preflight — hf-cloud-sagemaker-iam-preflight
Sélection d'image — hf-cloud-serving-image-selection
Déploiement — hf-cloud-sagemaker-production-defaults

Les phases 1–2 relèvent de cette skill. Les autres s'activent quand leurs patterns correspondent.

Discovery : ne posez que ce dont vous avez besoin

Vous devrez finalement connaître :

Quel modèle : ID HuggingFace, chemin S3 vers les artifacts, ou nom du modèle. Si l'utilisateur est vague (« le modèle que j'ai fine-tuné »), demandez l'emplacement des artifacts.
Type de modèle : LLM text-generation, embedding/reranker, ou autre (classifier, NER, etc.). Cela détermine la stack de serving — généralement déductible du nom du modèle (tout ce qui finit par -embed-*, commençant par BAAI/bge-, sentence-transformers/* etc. sont des embeddings ; les modèles chat/instruct sont des LLMs). Ne posez la question que si c'est véritablement ambigu.
Forme du traffic : à peu près à quelle fréquence cela sera-t-il appelé ?
Tolérance de latence : interactive, quasi-temps réel, ou async ?
Sensibilité au coût : ne posez la question que si l'utilisateur le signale ou si le pattern de traffic est ambigu.

La région provient de hf-cloud-aws-context-discovery — ne posez pas la question sauf si l'utilisateur le mentionne.

Ne pas charger toutes ces questions d'emblée. Un ensemble minimal courant est simplement : quel modèle, et à peu près à quelle fréquence sera-t-il appelé ? Le nom du modèle règle généralement la question du type de modèle. Cela seul suffit souvent à réduire le chemin à deux candidats. Si l'utilisateur vous a déjà dit quelque chose, ne posez pas la question à nouveau.

Sélection du chemin

Chemin	Quand c'est adapté	Quand ce ne l'est pas
Real-time endpoint	Traffic régulier, latence sub-seconde à quelques secondes, toujours actif	Traffic très spiky ou très sparse (gaspille l'argent sur du inactif)
Serverless inference	Spiky/intermittent, tolère les cold starts (~10s+), modèles simples	LLMs au-dessus de quelques B params (limites mémoire/cold-start), SLAs stricts
Async inference	Inference longue (>60s), gros payloads, friendly avec files d'attente	Appels synchrones interactifs
Batch transform	Scoring hors ligne sur un dataset	N'importe quoi en ligne ou interactif
Bedrock Custom Model Import	Veut une API compatible Bedrock, famille de base supportée, poids uniquement	Logique d'inference personnalisée, architectures non supportées

Pour les LLMs, les real-time endpoints sont le défaut sauf si le traffic est explicitement spiky/sparse ou si l'inference est long-running. Serverless semble attrayant pour les cas « low traffic » mais la plupart des LLMs dépassent ses limites mémoire.

Pour les embeddings, real-time est à nouveau le défaut — mais les instances CPU sont généralement le bon choix (bien moins chères, assez rapides pour la plupart des workloads d'embedding). Ne recommandez pas réflexes les instances GPU pour les modèles d'embedding ; consultez hf-cloud-serving-image-selection pour considérer les variants CPU si le modèle est petit (<1B params) et le traffic modéré.

Pour text-to-image, video generation, ou autres workloads à inference longue (>30s par requête) où le traffic est aussi bursty : async inference est la bonne réponse. Cela supporte un vrai scale-to-zero entre batches et met les requêtes en file d'attente via S3, donc vous ne payez pas pour du GPU inactif. hf-cloud-sagemaker-production-defaults dispose d'un deploy_async.py dédié pour cela.

Real-time et async sont les deux chemins scriptés. Serverless, batch transform, et Bedrock Custom Model Import ne sont pas actuellement scriptés — pour ceux-ci, transmettez l'utilisateur avec une brève explication plutôt que d'essayer de les déployer à travers ce workflow.

Si deux chemins sont tous deux raisonnables, dites-le en une phrase chacun et en choisissez un. N'enterrez pas la recommandation dans les options.

Sélection d'instance : vérifiez le quota avant de recommander

Les quotas d'endpoint sont par type d'instance, par région, et par défaut à 0 pour les types GPU dans de nombreux comptes. Recommander une instance que le compte ne peut pas lancer gaspille un cycle de déploiement entier sur ResourceLimitExceeded. Vérifiez d'abord :

aws service-quotas list-service-quotas --service-code sagemaker --region <region> \
    --query "Quotas[?contains(QuotaName, 'for endpoint usage') && Value > \`0\`].[QuotaName, Value]" \
    --output table

Si le type que vous voulez n'est pas dans le résultat, recommandez-en un qui y est — ou dites à l'utilisateur de demander une augmentation (heures à jours) avant de créer quoi que ce soit.

Notes sur les familles GPU pour le tier 24 GB courant :

ml.g5.* (A10G) et ml.g6.* (L4) fonctionnent tous deux avec les images vLLM actuelles quand l'AMI gpu-3-1 est défini (voir hf-cloud-serving-image-selection). g6 est la génération plus récente et légèrement moins chère à l'heure ; g5 dispose d'environ le double de bandwidth mémoire, ce qui signifie généralement un meilleur throughput de tokens LLM. Choisissez celui qui a du quota ; quand les deux en ont, l'un ou l'autre est défendable — g5 pour le throughput, g6 pour le coût.
ml.g6e.* (L40S, 48 GB) quand le modèle ne rentre pas en 24 GB.

Une fois que vous avez assez pour recommander, énoncez-le clairement :

D'après ce que vous m'avez dit, je recommanderais un real-time endpoint sur ml.g5.xlarge. Le modèle est assez petit pour que ce soit rentable, et votre pattern de traffic est assez régulier pour que vous ne payiez pas pour de l'inactif. Alternative : serverless serait moins cher si le traffic baisse pendant des heures, mais Qwen3-0.6B est à la limite des limites mémoire serverless et les cold starts seraient 15–30s. Voulez-vous que je procède avec le real-time endpoint ?

Attendez alors la confirmation. L'utilisateur doit savoir ce qu'il va dépenser avant que vous créiez quoi que ce soit.

Le plan vit dans la conversation — ne générez pas plan.yaml ou artifacts similaires sauf si explicitement demandé.

Style

Les utilisateurs invoquant cette skill défèrent l'agent parce qu'ils ne veulent pas faire de plomberie AWS. Matchez cette énergie : efficace, pas exhaustif.
Un tour de questions de clarification suffit généralement. Trois tours, c'est un interrogatoire.
Quand vous ne savez pas quelque chose de spécifique (URI d'image courant, surface API SDK, quotas), vérifiez-le plutôt que de deviner. D'autres skills gèrent les détails « comment vérifier ».
Si l'utilisateur conteste une recommandation, acceptez-la. Il connaît ses contraintes mieux que vous.

hf-cloud-sagemaker-deployment-planner