Generated banner for AWS AI ML
Generated logo for AWS AI ML

AWS AI ML

AWSOfficialPublished by AWS

  • Skill
  • Tool integration
  • Cloud and DevOps
  • Apache-2.0
  • Low risk
  • Has scripts

From the author

Selects, deploys, and customizes AI models on Amazon SageMaker. Training or Processing jobs, fine-tuning (SFT/DPO/RLVR/RLAIF), model selection, dataset preparation, evaluation, SageMaker or Bedrock deployment, inference optimization and endpoint diagnostics. Covers the full lifecycle from planning through production. Use when fine-tuning models on SageMaker, choosing which base model to customize, fine-tune, or deploy from SageMaker JumpStart or Hub, SageMakerPublicHub, or the SageMaker public model catalog, transforming or validating training data, evaluating model quality, deploying or optimizing endpoints, configuring IAM/S3 for training, or managing SageMaker Managed MLflow. Use for endpoint health, failures, latency, logs, metrics, errors. Covers Serverless Model Customization, Nova and OSS deployment paths, and PySDK v3. NOT for Ground Truth labeling, Feature Store, or general-purpose AWS infrastructure.
— the description by AWS

AutoGineer summary

Written by AutoGineer from the skill’s own files, not by the author

This skill provides a structured framework for managing the Amazon SageMaker model lifecycle. It covers planning, dataset preparation, fine-tuning, model evaluation, and endpoint deployment. The skill assists users in navigating SageMaker-specific workflows, including selecting base models from catalogs, configuring training and processing jobs, and diagnosing endpoint health. It supports various fine-tuning techniques and deployment pathways, ensuring users follow validated procedures for their machine learning projects on AWS.

What it does

  • Guides users through the end-to-end lifecycle of SageMaker model customization.
  • Assists in selecting and evaluating base models from SageMaker JumpStart and public hubs.
  • Provides workflows for validating and transforming training and evaluation datasets.
  • Supports configuration of fine-tuning techniques like SFT, DPO, RLVR, and RLAIF.
  • Facilitates the deployment of models to SageMaker endpoints or Bedrock.
  • Diagnoses endpoint issues including latency, errors, and container logs.

When to use it

  • When planning a new model customization or deployment project on SageMaker.
  • When you need to validate or transform datasets for training or evaluation.
  • When selecting a base model or choosing a fine-tuning technique.
  • When you need to configure training, processing, or evaluation jobs.
  • When deploying a model to a SageMaker endpoint or troubleshooting an existing one.
  • When setting up or managing a SageMaker Managed MLflow environment.

Advantages

  • Provides structured, step-by-step workflows for complex SageMaker tasks.
  • Ensures dataset formatting meets specific SageMaker requirements.
  • Offers clear routing to relevant documentation based on user intent.
  • Helps resolve configuration issues for IAM, S3, and SDK settings.
  • Simplifies the diagnosis of endpoint performance and failure logs.

Usage examples

“I need to fine-tune a model on SageMaker. Where do I start?”
The agent will initiate the planning workflow, prompting you to define your use case and requirements before guiding you through model selection and dataset preparation.
“My SageMaker endpoint is returning errors. Can you help?”
The agent will route you to the endpoint diagnostics workflow to collect logs, check instance status, and analyze latency or failure metrics.
“How do I convert my CSV training data for SageMaker?”
The agent will guide you through the dataset transformation workflow, recommending the appropriate tools to convert your data into the required JSONL format.
“Which base model should I use for a text summarization task?”
The agent will trigger the model selection workflow to help you evaluate available models and resolve the correct Hub model ID for your specific requirements.

Install

  1. Download the skill as a ZIP:

    https://autogineer.com/agent-skills/aws/aws-ai-ml/download
  2. Unzip it into the cross-client skills folder of your project:

    mkdir -p .agents/skills && unzip aws-ai-ml.zip -d .agents/skills

Documentation by AWS

AWS AI/ML Model Customization

Domain expertise for fine-tuning and deploying models on Amazon SageMaker. Covers the full model customization lifecycle from planning through production deployment.

Routing

Match the user's intent to the appropriate reference folder and load only that content.

User intentReferenceWhen to use
Plan a model customization project, discover scope of work, resume or modify a planreferences/planning/User's request relates to model customization or deployment (fine-tuning, training, building, customizing, reviewing data, deploying or standing up a model — including selecting or deploying an off-the-shelf or base model with no training — or getting advice on approach). Always co-activate with other intents to discover full scope. Load this reference FIRST when the request matches multiple rows in this table — read its plan templates before routing to a single-action reference.
Define the business problem, success criteria, or use case specreferences/use-case-specification/User says "define my use case", "capture requirements", "what should I decide up front", or as default first step in any plan. Skip only if user explicitly declines.
Select or change a base modelreferences/model-selection/User asks which model to use, mentions a model name or family, or wants to evaluate what's available. Always activate model-selection even for known model names because the exact Hub model ID must be resolved. Recommended: route to use-case-specification first to capture requirements — this produces better filtering results. Routing to use-case-specification first is not required if user provides a specific model name/ID or declines. If intent is ambiguous (fine-tune vs deploy as-is), model-selection MUST confirm which path before proceeding. Base model filtering for deployment MUST go through select-for-deployment.md and its scripts for any final recommendation.
Choose a fine-tuning technique (SFT, DPO, RLVR, RLAIF)references/finetuning-technique/User has decided to fine-tune and needs to choose a technique, or technique needs validation against the selected model's recipes. Requires a base model to be selected first.
Validate dataset quality and formatreferences/dataset-evaluation/User says "is my dataset okay", "check my training data", "I have my own data", or before starting any fine-tuning job.
Transform or convert a dataset between formatsreferences/dataset-transformation/User says "transform", "convert", "reformat", or dataset schema needs to change. Always use this rather than writing inline transformation code.
Generate fine-tuning code and start trainingreferences/finetuning/User says "start training", "fine-tune my model", "I'm ready to train", or plan reaches the finetuning step. Supports SFT, DPO, RLVR, RLAIF trainers.
Train a model with a SageMaker Training jobreferences/training-jobs/Use when the goal is to fit or update model parameters and produce model artifacts or checkpoints. Covers recipes, JumpStart traditional ML, custom training scripts or containers, distributed training, and training-job diagnosis.
Process data with a SageMaker Processing jobreferences/processing-jobs/Use when the goal is preprocessing, feature engineering, evaluation, transformation, or ETL without model training as the primary operation. Covers scripts, framework processors, Spark, custom containers, Athena, Redshift, and processing-job diagnosis.
Evaluate or benchmark a trained modelreferences/model-evaluation/User says "evaluate my model", "run a benchmark", "test model performance", "compare models". Supports LLM-as-Judge and Custom Scorer.
Deploy, benchmark, or optimize a model on an endpoint or Bedrockreferences/model-deployment/User says "deploy my model", "create an endpoint", or "make it available" (plain deploy) — or, for the inference-optimization sub-workflows on SageMaker Real-Time Endpoints only, "benchmark my endpoint" / "compare benchmark runs" (benchmarking), or states a performance/cost/latency/throughput goal for a new deployment such as "find the cheapest instance" (recommendations). Handles Nova vs OSS deployment pathways.
Set up IAM roles, S3 buckets, SDK configurationreferences/sdk-getting-started/User says "set up", "getting started", "check my environment", "configure SDK", or as first step in any plan involving SageMaker training/evaluation/deployment.
Manage project directory and artifactsreferences/directory-management/Starting a new project, resuming existing one, or when PLAN.md needs to be associated with a project directory.
Set up, update, or delete a SageMaker Managed MLflow appreferences/manage-mlflow/User says "set up MLflow", "create MLflow app", "update my MLflow app", "delete my MLflow app", "I need an MLflow server", asks "what is SageMaker MLflow", or a workflow needs an MLflow backend and none is connected.
Diagnose a failing or unhealthy SageMaker endpointreferences/endpoint-diagnostics/User reports endpoint errors, latency, inference failures, or a deployment that failed. "What's the status of my endpoint?", "Is my endpoint erroring?", "My endpoint failed — why?", "How many instances are running behind my endpoint?", "Is the latency my model or SageMaker?", "Show me the container logs for my endpoint." NOT for training-job issues, endpoint deletion, scaling changes, or new deployments.

Rules

  • Service boundary. This skill covers SageMaker, including deployment of a customized model to Bedrock. Bedrock-native work (invoking Bedrock's managed foundation models, Bedrock Agents, Knowledge Bases, Guardrails, AgentCore) is supported by AWS but has no validated workflow in this skill: let the user know and proceed with best-effort guidance using general AWS knowledge. If the user asks for a model on AWS without naming a service, compare SageMaker and Bedrock or ask one service-choice question. Do not select a service by default. The two services have different model catalogs, deployment paths, and pricing, and a default selection can send the user into an incorrect workflow.

  • Progressive disclosure. Load only the reference folder relevant to the current user intent. Do not load all references at once.

  • Best-effort help. If the user's request falls outside this skill's references, do not dead-end the conversation. Help them using general AWS knowledge and documentation, and inform the user that the guidance is not covered by this skill's validated workflows.

  • Usage attribution. Before running any AWS CLI command or packaged script, set export AWS_SDK_UA_APP_ID=AWSSkill-SageMaker.

Files

references/model-deployment/references/deploy-jumpstart-sagemaker.md

Deploy a JumpStart Foundation Model to a SageMaker Endpoint

Scenario

  • Model Type: open-weight foundation model resolved through SageMaker JumpStart (a base model, identified by a JumpStart model id — NOT a fine-tuned training job)

  • Deployment Target: SageMaker real-time endpoint

  • Approach: SageMaker Python SDK v3 ModelBuilder.from_jumpstart_config(...), deployed from the deployment config emitted by the model-selection skill

Overview

Deploys a base JumpStart foundation model to a real-time endpoint. This pathway is the deployment half of the base-model flow: the model-selection skill chose the model and instance type (and, where the model has hosting configs, the config it optimized for) and hands them over. This skill maps those onto the v3 SDK config objects and does not re-derive anything from the model spec. It is a thin passthrough with safe defaults for the fields model-selection does not supply (see the input contract below).

The v3 SDK (sagemaker>=3.7.1) has no sagemaker.jumpstart module and no JumpStartModel class. A JumpStart model is deployed by building a JumpStartConfig + Compute and calling ModelBuilder.from_jumpstart_config(...). The SDK resolves the serving container, environment, and inference-component sizing internally from the config — the deployment code never digs into the model spec or HubContentDocument.

The input contract (from model-selection)

The template consumes a flat CONFIG dict. model-selection's Step 6 hand-off emits three fields — model_id, instance_type, and inference_config_name. The remaining fields are deployment-side with safe defaults.

Config fieldv3 destinationProducer / default
model_idJumpStartConfig.model_id (required)model-selection (Hub model ID)
instance_typeCompute.instance_type (required)model-selection (user-confirmed)
inference_config_nameJumpStartConfig.inference_config_namemodel-selection (the config it chose; null when the model has no labeled configs)
model_versionJumpStartConfig.model_version (None → "*")deployment default None (latest) unless supplied
instance_countCompute.instance_countdeployment default 1 unless supplied
accept_eulaJumpStartConfig.accept_euladeployment-owned (set at the Step 4 license gate)
env_varsfrom_jumpstart_config(env_vars=...)deployment default None unless supplied

inference_config_name is tri-state: a real config name deploys that specific config; None lets the SDK resolve the spec's top-ranked config; None for a model with no labeled configs is a plain base deploy. Deployment honors whatever value it receives — never override it. model-selection emits the config it chose precisely so deployment does not fall back to the top-ranked config (which may not support the instance_type that was derived from the chosen config — see "Instance ↔ config consistency" below).

model_id and instance_type are both required for a real-time endpoint. The template fails fast if either is missing.

Hardening the hand-off

The config comes from another skill, so treat it as untrusted. The template's Cell 2 defines validate_deployment_config(cfg) and calls it before building — it fails fast with a clear, actionable message when the config is missing fields or otherwise broken, rather than failing deep in the SDK or silently misbehaving. It checks:

  • CONFIG is a dict (a None/list/string hand-off is rejected with a readable error)

  • model_id and instance_type are non-empty strings and not un-substituted placeholders

  • instance_count is a positive integer (bool rejected — it is a subclass of int)

  • model_version is a string or None

  • inference_config_name is a non-empty name or None (an empty string would be treated as a real config name and fail deep in the SDK)

  • accept_eula is a real bool — a non-bool such as the string "false" is truthy in Python and could silently auto-accept a gated model's license, so it is rejected (a safety check)

  • env_vars is None or a flat dict of string → string

Keep this validator in the generated notebook. It is the runtime guard; the agent-time check in Step 1 is the first line of defence.

Deployment-owned fields (NOT from model-selection)

role_arn, endpoint_name, and model_name are owned by this skill, not model-selection. Collect them in the steps below.

Prerequisites

SDK Version

Requires sagemaker>=3.7.1 (the template pins >=3.7.1,<4.0 to guard against a future v4 breaking this API the way v2→v3 did). Do not use the v2 JumpStartModel / sagemaker.enums.EndpointType / sagemaker.compute_resource_requirements imports — they do not exist in v3.

Key Gotchas

  • Do not re-resolve the config. model-selection already picked instance_type and inference_config_name. Do not call get_config_names / list_deployment_configs or read the HubContentDocument here — pass the dict through. The SDK resolves container/env/sizing from the config name.

  • inference_config_name must be valid or None. A name the model doesn't expose fails inside from_jumpstart_config. model-selection validates the name against get_config_names before emitting it, so treat a non-None value as trusted.

  • Instance ↔ config consistency. If both instance_type and inference_config_name are set, the instance must be in that config's supported_inference_instance_types (server-side ranking rejects otherwise). model-selection guarantees this; surface the SDK error cleanly if it occurs.

  • Gated models: accept_eula defaults to False, which is safe for non-gated models. It is set to True only after the user explicitly accepted the license in Step 4. Whether a model is gated is given by the Gated (EULA) column in model-licenses.md (a Yes row is gated — e.g. Meta/Llama, Gemma, NVIDIA Nemotron, Llama 4, Qwen License Agreement); it is a property of the license terms, not the vendor. Never auto-accept.

Topology note (single-model endpoint)

from_jumpstart_config(...).deploy(endpoint_name=...) deploys a single-model real-time endpoint. Inference-component (IC) packing is not part of this contract yet — adding it requires a new field in the model-selection → deployment config (e.g. endpoint_type plus resource requirements) so both skills agree. Until that field exists, deploy the single-model endpoint as above.

Workflow

Step 1: Confirm and validate the deployment config

You should already have the config dict from the model-selection skill (model_id, instance_type, inference_config_name, etc.). Before generating any code, sanity-check the hand-off:

  • It must contain a non-empty model_id and instance_type.

  • accept_eula, if present, must be a boolean (not a string).

  • inference_config_name, if present, must be a real name or null — never an empty string.

If the config is missing, not a dict, or missing either required field, do not generate a deploy notebook. Go back to the model-selection skill to produce a valid config rather than guessing values. The generated notebook also self-validates at runtime (see "Hardening the hand-off" above), but catching it here avoids emitting a notebook that will fail.

Step 2: Verify IAM Role

role_arn is owned by this skill, not model-selection, and a JumpStart base deploy has no training job to extract it from. Use the IAM execution role identified in Step 1 of the main workflow; if it is not already known, ASK the user for the IAM execution role ARN. Confirm it with the user.

Step 3: Confirm Region

The region was identified in Step 1 of the main workflow. If it is not already known, ASK the user for the AWS region. Confirm it with the user.

Step 4: Confirm Configuration

"Here's the deployment setup:

  • Target: SageMaker real-time endpoint

  • JumpStart model: [model_id]

  • Inference config: [inference_config_name, or "SDK top-ranked default"]

  • Instance type: [instance_type] x [instance_count]

  • IAM Role: [role_arn]

  • Region: [region]

Does this look right?"

⏸ Wait for user approval.

Step 5: Generate Code

Read ../references/code_output_guide.md for output format rules.

If a project directory already exists (from earlier in the workflow), use it. Otherwise, activate the directory-management skill to set one up.

⏸ Wait for user.

Code Structure

Markdown Header

Begin the notebook with a markdown cell whose only content is the title # Deploy a JumpStart Foundation Model to SageMaker.

Cells

Each cell's content comes from ../code_templates/deploy-jumpstart-sagemaker.py, split on the # Cell N: comments. Each marker starts a new notebook cell.

  • Cell 1: Setup (pip install)

  • Cell 2: Configuration and validation (the config dict from model-selection + deployment-owned fields, plus validate_deployment_config which runs before the build)

  • Cell 3: Build the model via from_jumpstart_config

  • Cell 4: Deploy and wait for InService

  • Cell 5: Test Inference

  • Cell 6: Save Manifest

Placeholders

The CONFIG dict fields (from model-selection):

  • [MODEL_ID] → JumpStart model id (e.g. huggingface-reasoning-qwen3-06b)

  • [INSTANCE_TYPE] → the instance type model-selection resolved

Leave model_version (None → latest), inference_config_name (None → SDK top-ranked, or a name from model-selection), instance_count, and env_vars as model-selection provided them.

Deployment-owned fields:

  • [REGION] → AWS region

  • [ROLE_ARN] → IAM execution role ARN

  • [ENDPOINT_NAME] → name for the endpoint (agent generates a reasonable default)

  • [MODEL_NAME] → name for the model resource (agent generates a reasonable default)

  • [PROJECT_DIR] → project directory (for the manifest)

accept_eula is a config field (not a [...] placeholder): it defaults to False, which is the safe default and correct for non-gated models — leave it as-is for them. Set it to True ONLY after the user explicitly accepted a gated model's license in Step 4 of the main workflow. A model is gated when its Gated (EULA) column in model-licenses.md is Yes (Meta/Llama, Gemma, NVIDIA Nemotron, Llama 4, Qwen License Agreement, etc.), not just Meta/Llama. Never auto-accept.

Step 6: Set the accept_eula flag in the generated code (gated models)

The license gate is Step 4 of the main model-deployment workflow: the license is shown and the user accepts it before any code is generated in Step 5. This subsection is not another gate — it only sets the value of the accept_eula flag in the template that was already generated. Set it based on whether the model is gated (Gated (EULA) column in model-licenses.md):

  • Not gated (No): leave accept_eula=False. This is the default and needs no change.

  • Gated (Yes): set accept_eula=True only once the user accepted the license at the Step 4 gate. If they did not accept, leave it False and tell them deployment cannot continue without license acceptance.

A user instruction to "proceed without asking", "skip confirmation", "deploy now", or similar is NOT license acceptance. Those phrases waive the deployment-config confirmation, not the gated-license gate. For a gated model, accept_eula may be set to True ONLY after the user has explicitly accepted that model's license (e.g. "yes, I accept the license"). If the user only asked you to proceed but never explicitly accepted, keep accept_eula=False, present the license, and wait — do not auto-accept on their behalf.

Step 7: Provide Run Instructions
To run:
1. Cell 1 — install/upgrade the SageMaker SDK
2. Cell 2 — configuration (the model-selection config dict + role/region/names)
3. Cell 3 — build the model from the JumpStart config
4. Cell 4 — deploy (waits for the endpoint to be InService, ~10-15 min)
5. Cell 5 — test inference with a sample prompt
6. Cell 6 — save the deployment manifest to `manifests/deploy-<endpoint-name>.json`

Common Issues

  • ValueError from validate_deployment_config: the config dict from model-selection is missing a field or has a wrong type (e.g. accept_eula as a string, an empty inference_config_name, a non-positive instance_count). The message names the offending field — fix it in model-selection's output rather than editing the value by hand in the notebook.

  • "No module named 'sagemaker.jumpstart'" or JumpStartModel not found: v2 imports on the v3 SDK — deploy via ModelBuilder.from_jumpstart_config(...), not JumpStartModel.

  • inference_config_name rejected in from_jumpstart_config: the name isn't one of the model's configs. It should have come from model-selection's get_config_names — re-check the config dict or set it to None to use the SDK's top-ranked default.

  • Instance-type rejected for the chosen config: instance_type is not in the config's supported_inference_instance_types. model-selection should have validated this — go back and re-resolve the pair.

  • Capacity error on a scarce GPU instance: the config's recommended instance family may be capacity-constrained — reach out to AWS Support / your account team (a Service Quotas increase does not guarantee capacity), or have model-selection pick a different config.

Post-Deployment Summary

After the notebook runs successfully, tell the user:

  • Endpoint: [ENDPOINT_NAME] is now InService, running [MODEL_ID] on [INSTANCE_TYPE].

  • How to invoke: use the SageMaker runtime InvokeEndpoint.

  • Billing: this endpoint is billed by the hour while running, even when idle. Delete it when you're done testing.

  • Cleanup: delete the endpoint (and its endpoint config / model) using the AWS MCP tool (delete-endpoint, then delete-endpoint-config, then delete-model).

Requirements and compatibility

Works with: Claude Code, Claude apps, OpenAI Codex, GitHub Copilot, Cursor, Gemini CLI, Kiro, OpenCode, Goose, Amp, Roo Code, JetBrains Junie, Factory Droid, Devin (ex-Windsurf), Mistral Vibe, OpenHands, Letta

“Works with” means the tool reads the open Agent Skills format; a skill written for one tool may use features others lack.

Needs: Needs Python

Security

What our scanner noticed· Low risk

  • Instructions that use the network
  • Scripts that your agent may run

This skill includes scripts that your agent may run. Read them before you use it.

A static scan is not a guarantee. Skills are third-party content: review a skill before you let an agent use it.

Attribution and licence

Published by
AWS
Publisher
AWS (Official)
Source
aws/agent-toolkit-for-aws · skills/core-skills/aws-ai-ml · commit 0a218f8
Licence
Apache License 2.0 (redistribution allowed)
  • LICENSE (added by AutoGineer from LICENSE)
  • NOTICE (added by AutoGineer from NOTICE)
  • ATTRIBUTION.md (written by AutoGineer)
Synced
Also distributed in
aws/agent-toolkit-for-aws

AutoGineer is not affiliated with or endorsed by AWS or AWS.

Download ZIP

The ZIP holds the skill’s files, its licence files and an ATTRIBUTION.md. Download aws-ai-ml.zip