Build a model improvement flywheel with Amazon SageMaker HyperPod Data Capture

Foundation models deployed on Amazon SageMaker HyperPod meet inputs that no pre-curated dataset covers: domain-specific jargon, unexpected formats, new products, and changing user behavior. Without a record of production inference data, teams can’t detect drift, find failure patterns, or use real interactions to improve the model. Amazon SageMaker HyperPod now provides Data Capture, a built-in capability that records live inference inputs and outputs to Amazon Simple Storage Service (Amazon S3) at three independent tiers, with minimal latency impact and zero impact on model availability. In this post, we walk through one complete example on a single SageMaker HyperPod cluster. A home-appliance support router captures its production traffic, Amazon Athena queries surface a new-product blind spot, a SQL policy labels the captured records, and a fine-tune on that data teaches the router the new product. We measure accuracy before and after, on data that could not have existed before the model was deployed. The inference operator serves the model on one node, and the training operator runs the fine-tuning on another. We use synthetic data for the walkthrough. The scripts, manifests, SQL, synthetic datasets, and expected outputs are available in the accompanying GitHub repository . Three-tier Data Capture architecture HyperPod Data Capture provides three independent tiers, each at a different point in the request path. You can turn on any combination in the same dataCapture block. Tier 1: SageMaker endpoint Tier 2: Load balancer Tier 3: Model pod What’s captured Full request/response payloads Application Load Balancer (ALB) access-log fields: request line, status codes, timings, client IP, user agent Full request/response payloads plus event metadata Managed by SageMaker native data capture ALB access logs HyperPod inference operator (NGINX + OTel collector + S3 uploader sidecars) Best for Compliance, Model Monitor, audit Traffic and error-rate monitoring at low cost Debugging, analytics, training-data collection Configuration sagemakerEndpoint: — sampling %, input/output, AWS KMS loadBalancer: { enabled: true } modelPod: — sampling %, input/output, buffer, max payload size, AWS KMS, content types Tiers 1 and 3 both store full payloads, so enabling both stores every record twice. Use Tier 1 for compliance and Model Monitor, Tier 2 when you only need traffic metadata, and Tier 3 when you intend to use the payloads. This post uses Tier 3 only. Because Tier 3 records complete payloads, which can include names, addresses, and order numbers, protect that data before it becomes training data. Use sampling, AWS Key Management Service (AWS KMS) encryption ( kmsKeyId ), S3 lifecycle rules, and personally identifiable information (PII) redaction (for example, with Amazon Comprehend). Prerequisites A SageMaker HyperPod cluster orchestrated by Amazon Elastic Kubernetes Service (Amazon EKS), with the inference operator installed ( Setting up your HyperPod clusters for model deployment ) and the training operator EKS add-on amazon-sagemaker-hyperpod-training-operator installed ( Installing the training operator ). Two available NVIDIA GPUs , one for serving and one for training. We used an ml.g6e.8xlarge for serving and an ml.g6e.xlarge for training (one 48 GB NVIDIA L40S each). The serving pod holds its GPU for the life of the endpoint, so with only one GPU the training pod stays Pending . kubectl configured for the cluster. An S3 bucket in the same Region. Confirm both operators are installed. The command returns two rows: kubectl get crd | grep -E 'inferenceendpointconfigs|hyperpodpytorchjobs' hyperpodpytorchjobs.sagemaker.amazonaws.com 2026-09-21T10:57:14Z inferenceendpointconfigs.inference.sagemaker.aws.amazon.com 2026-08-06T11:58:53Z Solution overview The following diagram shows the five steps of the walkthrough on one SageMaker HyperPod cluster: capture every request and response to Amazon S3, analyze the captures with Athena, label them with a SQL policy, fine-tune with the training operator on a second GPU, and redeploy side by side with capture still on. Figure 1: The five-step flywheel on a single SageMaker HyperPod cluster, from capture through Athena analysis, labeling, fine-tuning, and redeploy The inference operator adds three sidecars to the model pod. Every request that passes through the NGINX proxy is copied to an OpenTelemetry collector, batched, and written to S3 through a Mountpoint-S3 volume. Athena reads those files in place. The training operator runs the fine-tune as a HyperPodPyTorchJob on a second GPU, and the new model is served by a second endpoint that also has capture on. Step 0: Set your variables Every later step reads these. Edit the first block, then paste the whole thing: # --- edit these --- export EKS_CLUSTER_NAME="my-hyperpod-eks" export AWS_REGION="us-east-1" export BUCKET="amzn-s3-demo-bucket" export SERVE_INSTANCE_TYPE="ml.g6e.8xlarge" # node type for the first endpoint export TRAIN_INSTANCE_TYPE="ml.g6e.xlarge" # node type for the fine-tuning job # --- leave as-is --- export AWS_DEFAULT_REGION="$AWS_REGION" export ENDPOINT_NAME="appliance-router" export MODEL_LOCATION="models/qwen2.5-3b-instruct" export MODEL_V2_LOCATION="models/qwen2.5-3b-router-v2" export TRAIN_SA="flywheel" # service account with S3 access via EKS Pod Identity aws eks update-kubeconfig --name "$EKS_CLUSTER_NAME" --region "$AWS_REGION" render() { python3 -c 'import os,sys; sys.stdout.write(os.path.expandvars(sys.stdin.read()))'; } Step 1: Stage the base model in S3 We use Qwen2.5-3B-Instruct because it is small enough to fine-tune in about a minute and fits on a single L40S. pip install -q huggingface_hub python3 -c "from huggingface_hub import snapshot_download; \ snapshot_download('Qwen/Qwen2.5-3B-Instruct', local_dir='qwen2.5-3b-instruct')" aws s3 sync qwen2.5-3b-instruct "s3://${BUCKET}/${MODEL_LOCATION}/" --exclude ".cache/*" Step 2: IAM permissions Four identities need access. For the policy statements, see Data capture for inference on HyperPod . The Mountpoint-S3 CSI driver role. Tier 3 capture writes through a Mountpoint-S3 volume, and the driver authenticates as its own IAM roles for service accounts (IRSA) role, not as the pod’s service account. It needs s3:PutObject , s3:AbortMultipartUpload , and s3:DeleteObject on your capture bucket, plus kms:Decrypt , kms:GenerateDataKey , and kms:DescribeKey if you set kmsKeyId . If this is missing, the endpoint stays healthy and requests succeed, but no captures appear. See Mountpoint for Amazon S3 CSI driver . The inference operator execution role. It needs s3:PutObject on your capture bucket, plus kms:Decrypt and kms:GenerateDataKey if you set kmsKeyId . The capture files themselves are written through the CSI driver role, so when no captures appear, check that role first. The training pod’s service account ( $TRAIN_SA ). Read access to the base model and training data, and write access for the merged model, through EKS Pod Identity . Athena. Read access to the capture prefix, plus a query-results location. Enabling Data Capture The next three steps deploy the router with Tier 3 capture on, check that the pod runs the capture sidecars, and confirm that records reach Amazon S3. Step 3: Deploy the model with Tier 3 capture enabled This is the whole feature: the dataCapture.modelPod.enabled: true block. Everything else is an ordinary vLLM deployment. cat > endpoint.yaml >> This is all you need to turn on Tier 3 data capture The preceding modelPod block sets 100% sampling and captures both input and output, which are the defaults. To tune it, add any of these optional fields under modelPod : modelPod: enabled: true initialSamplingPercentage: 50 # capture 50% of requests (default 100) bufferConfig: batchSize: 100 # records buffered per upload batch (default 10) flushIntervalSeconds: 60 # max seconds before a flush (default 60) payloadConfig: maxPayloadSizeKB: 1024 # truncate payloads larger than this (defau