Build a model improvement flywheel with Amazon SageMaker HyperPod Data Capture

Artificial Intelligence #

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 up 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-onamazon-sagemaker-hyperpod-training-operator installed (Installing the training operator ).
• Two available NVIDIA GPUs , one for serving and one for training. We used anml.g6e.8xlarge for serving and anml.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 staysPending .
• kubectl configured for the cluster.
• An S3 bucket in the same Region.

Confirm both operators are installed. The command returns two rows:

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.

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:

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.

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 needss3:PutObject ,s3:AbortMultipartUpload , ands3:DeleteObject on your capture bucket, pluskms:Decrypt ,kms:GenerateDataKey , andkms:DescribeKey if you setkmsKeyId . If this is missing, the endpoint stays healthy and requests succeed, but no captures appear. SeeMountpoint for Amazon S3 CSI driver .
• The inference operator execution role. It needss3:PutObject on your capture bucket, pluskms:Decrypt andkms:GenerateDataKey if you setkmsKeyId . 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, throughEKS 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.

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:

Step 4: Wait for the pod

A capture-enabled pod runs four containers: the model, sidecar-reverse-proxy (NGINX), otel-collector, and s3-up. The model container and the pod’s app label are both named after modelName.

In our run, the pod was ready about five minutes after kubectl apply, most of it spent down the weights.

Step 5: Send a request and confirm captures land in S3

Send an inference request through the capture proxy on port 8081, then, after the flush interval, list the capture prefix. The model itself listens on port 8000. Requests sent there bypass the proxy and are not captured.

You see one or more .jsonl objects under {s3Uri}/{uniqueID}/pod/{variant}/{YYYY}/{MM}/{DD}/{HH}/. The uniqueID is generated per endpoint. Each line is one inference in the SageMaker data-capture format shown next.

The captured record format

The request and response bodies are stored base64-encoded, as the encoding field shows, so reading them back requires base64-decoding and then parsing JSON:

Decoded, endpointInput.data is the request body the client sent and endpointOutput.data is the response the model returned.