Amazon SageMaker HyperPod のデータキャプチャ、Hugging Face、NVMe、Route 53 統合によるエンタープライズ推論の強化
Amazon SageMaker HyperPod が、データキャプチャ機能の強化、Hugging Face からの直接デプロイ、NVMe を活用した冷間起動の高速化、および Route 53 と IAM の統合により、エンタープライズ向けの推論インフラのパフォーマンスとガバナンスを大幅に向上させた。
キーポイント
多層的なデータキャプチャ機能
エンドポイント、ロードバランサー、モデルポッドの各レベルで独立して入出力データを記録可能にし、監視やデバッグのための深い可視性と監査証跡を提供する。
Hugging Face 連携とセキュリティ強化
事前ストレージへのウェイト転送が不要となり、ゲートドアクセスやリビジョンピンニング機能を備えたまま Hugging Face から直接モデルをデプロイできる。
NVMe による冷間起動の最適化
ノードローカルの NVMe ストレージからウェイトを読み込むことで冷間起動レイテンシを削減し、必要に応じてクラウドストレージへ自動的にフォールバックする。
運用管理とセキュリティの自動化
カスタムドメイン DNS 記録の自動管理と、ポッドレベルの IAM 権限による細粒度なセキュリティ制御により、ガバナンスを損なわずに迅速な AI アプリケーションの展開を可能にする。
影響分析・編集コメントを表示
影響分析
この発表は、生成 AI の大規模展開において課題となっていた「冷間起動の遅延」と「運用上の可視性不足」を同時に解決する重要なステップです。特に Hugging Face との直接連携や NVMe の活用により、開発者の負担を減らしつつ、エンタープライズが求める厳格なガバナンスとパフォーマンスを両立させる基盤を提供します。これにより、AWS は大規模モデル推論市場における競争優位性をさらに強化し、企業の AI 実装スピードを加速させる要因となるでしょう。
編集コメント
エンタープライズが生成 AI を本番環境で運用する際の最大のボトルネックである「冷間起動」と「監査」を、インフラレベルで解決策を提供した画期的なアップデートです。特に Hugging Face との直接連携により、モデル管理のワークフローが劇的に簡素化される点は実務者にとって大きなメリットとなります。
企業が生成 AI ワークロードをスケールするにつれ、より高速で、より観測可能で、より柔軟な推論インフラストラクチャへの需要は増し続けています。Amazon SageMaker HyperPod は、組織が生産環境で大規模モデルを展開・運用する方法を合理化するために設計された一連の新しい機能によって、この課題に対応しています。チームは今や、エンドポイントからロードバランサー、さらにモデルポッド自体に至るまで、推論パス上の複数の地点で入力と出力を記録できるようになりました。これにより、宣言型のカスタムリソース定義（CRD）設定を通じて、深い観測性と監査可能性が提供されます。また、オブジェクトストレージやファイルストレージに重み値を事前に配置する必要なく、人気のあるコミュニティハブから直接モデルを展開することも可能です。これには、主要な推論ランタイムである vLLM、TGI、SGLang 間で、ゲート付きアクセス、リビジョンのピン留め、トークン分離に対する組み込みサポートが含まれています。
デプロイメントを超えて、これらの機能強化は実効性のあるパフォーマンス向上とセキュリティの強化をもたらします。ノードローカルの NVMe ストレージからウェイトを読み込むことでコールドスタート遅延を低減し、必要に応じてクラウドストレージへの自動フォールバックも可能です。HyperPod はカスタムドメインの DNS レコードを自動的に管理し、細粒度なポッドレベルの AWS Identity and Access Management (IAM) 権限により、インフラチームがセキュリティ境界に対してきめ細かい制御を行えるようになります。これらの機能を組み合わせることで、HyperPod 上でより高性能で安全かつエンタープライズ対応の推論体験を実現できます。チームはガバナンスや運用上の可視性を損なうことなく、AI アプリケーションを迅速にリリースできるようになります。
*Amazon SageMaker HyperPod における推論*
推論データキャプチャー
Amazon SageMaker HyperPod の推論データキャプチャー機能を使用すると、モデルの監視、デバッグ、およびモデル改善のために推論リクエストとレスポンスデータを記録できます。推論リクエストは Amazon SageMaker AI エンドポイントからアプリケーションロードバランサを経由し、最終的にモデルポッドへ流れます。各レベルでデータキャプチャーを独立して制御・設定できるため、ユースケースに適した適切な可視性の深さを選択する柔軟性が得られます。
前提条件
データキャプチャ機能を有効化する前に、以下の前提条件を満たす必要があります。
- Amazon Simple Storage Service (Amazon S3) バケット（s3://amzn-s3-demo-bucket や s3://amzn-s3-demo-bucket/prefix などの URI を使用）が必要であり、オペレーターが書き込みを行える適切な IAM ポリシー権限も必要です。バケットを指定しない場合、システムは TLS 証明書用バケットを代わりに使用します。
- 各ティアには独自の必須設定があります。SageMaker Endpoint レベルではこれを有効にし、宛先の S3 URI を設定し、少なくとも 1 つのキャプチャオプション（入力、出力、または両方）を選択し、サンプリング率を設定してください。Load Balancer レベルでは s3:// URI で有効化します。Model Pod レベルでは有効にします。デフォルトでは、入出力を 100% サンプリングしてキャプチャします。
- 必須ではありませんが、AWS Key Management Service (AWS KMS) キーを追加することを推奨します。これにより、キャプチャしたデータを暗号化できます。また、バッファ設定（バッチサイズとフラッシュ間隔）を微調整したり、CSV/JSON の処理にコンテンツタイプヘッダーを設定し、ペイロードサイズの制限を定義することも可能です。
キャプチャティア
データキャプチャは 3 つのティアをサポートしており、それぞれリクエストフロー内の異なるポイントでキャプチャを行います。任意の組み合わせを有効化できます：
- Tier 1 – SageMaker AI endpoint ({s3Uri}/{hash}/sme/): SageMaker AI Runtime API の境界において、完全な入力および出力ペイロードをキャプチャします。このティアではエンドポイントの登録が必要です。SageMaker AI Model Monitor との互換性が必要な場合に Tier 1 を使用してください。
- Tier 2 – Application Load Balancer ({s3Uri}/{hash}/alb/): ALB アクセスログを有効化し、クライアント IP アドレス、リクエストパス、レイテンシなどのリクエストメタデータをキャプチャします。
- Tier 3 – Model pod ({s3Uri}/{hash}/pod/): 推論コンテナ内で、設定可能なサンプリング、バッファリング、およびペイロードサイズ制限を備えた完全な推論入力・出力ペイロードをキャプチャします。SageMaker AI エンドポイントの登録なしで動作します。モデルに最も近い場所で最大の可視性が必要な場合に Tier 3 を使用してください。
データキャプチャの設定
InferenceEndpointConfig または JumpStartModel CRD に dataCapture セクションを追加することで、データキャプチャを有効化できます。以下の例では、すべての 3 つのティアが有効化された全体の構造を示しています：
dataCapture:
s3Uri: s3://amzn-s3-demo-bucket/captures/ # オプション。デフォルトは TLS バケットを使用します。
sagemakerEndpoint:
enabled: true
initialSamplingPercentage: 100
kmsKeyId: arn:aws:kms:us-east-2:123456789012:key/my-key-id
captureOptions:
- captureMode: Input
- captureMode: Output
captureContentTypeHeader:
jsonContentTypes:
- application/json
loadBalancer:
enabled: true
modelPod:
enabled: true
initialSamplingPercentage: 100
kmsKeyId: arn:aws:kms:us-east-2:123456789012:key/my-key-id
captureOptions:
- captureMode: Input
- captureMode: Output
bufferConfig:
batchSize: 100
flushIntervalSeconds: 60
payloadConfig:
maxPayloadSizeKB: 1024
S3 ストレージの動作
すべてのティアは、お客様の Amazon S3 バケットに書き込みます。s3Uri を指定しない場合、HyperPod はデフォルトで TLS 証明書バケット内の /data-capture/ プレフィックスの下にデータを保存します。バケット内では、各デプロイメントには、クラスター ARN、名前空間、CRD タイプ、およびデプロイメント名から導出されたハッシュに基づいた一意のパスが割り当てられます。同じデプロイメントからは常に同じプレフィックスが生成されるため、同じデプロイメントを対象とする複数の CRD 送信からのデータキャプチャアーティファクトは、同じ S3 サブフォルダに流れます。
IAM パーミッション
既存のクラスターでデータキャプチャを有効にするには、Inference Operator Execution Role に以下の S3 権限を追加してください：
{
"Sid": "DataCaptureS3Access",
"Effect": "Allow",
"Action": "s3:PutObject",
"Resource": "arn:aws:s3:::hyperpod-tls*/data-capture/*",
"Condition": {
"StringEquals": {
"aws:ResourceAccount": "${aws:PrincipalAccount}"
}
}
}
もしカスタマー管理型の KMS キー（Key Management Service）を使用する場合は、以下も追加してください：
{
"Sid": "DataCaptureKmsAccess",
"Effect": "Allow",
"Action": [
"kms:Decrypt",
"kms:GenerateDataKey"
],
"Resource": "arn:aws:kms:*:*:key/*",
"Condition": {
"StringLike": {
"kms:ViaService": "s3.*.amazonaws.com",
"kms:EncryptionContext:aws:s3:arn": "arn:aws:s3:::hyperpod-tls*"
},
"StringEquals": {
"aws:ResourceAccount": "${aws:PrincipalAccount}"
}
}
}
ベストプラクティス
コスト、セキュリティ、運用効率を最適化するために、以下の推奨事項に従ってください。
- initialSamplingPercentage を使用して、キャプチャされるデータの量を制御してください。本番環境では低いパーセンテージから始め、必要に応じて増やしてください。
- payloadConfig.maxPayloadSizeKB (Tier 3) を使用して、キャプチャされるペイロードのサイズに上限を設け、ストレージコストを管理してください。
- ワークロードで保存時の暗号化に独自の KMS キーを必要とする場合、Tier 1 および Tier 3 に対して kmsKeyId を指定してください。
- ALB アクセスログ (Tier 2) は、URL やクエリパラメータを含むリクエストのメタデータをキャプチャします。機密性の高い入力には、クエリパラメータではなく POST リクエストボディを使用してください。
特定のtier のデータキャプチャを無効にするには、その enabled フィールドを false に設定するか、CRD から該当する tier セクションを削除してください。すべてのデータキャプチャを無効にするには、dataCapture セクション自体を完全に削除してください。
詳細については、『HyperPod における推論用のデータキャプチャ』[Data capture for inference on HyperPod] (https://docs.aws.amazon.com/sagemaker/latest/dg/sagemaker-hyperpod-model-deployment-data-capture.html) を参照してください。
Hugging Face モデルソース
Amazon S3 や Amazon FSx に事前配置することなく、Hugging Face Hub から直接モデルをデプロイできます。このソースは、tokenSecretRef を通じてゲート付きモデルをサポートし、commitSHA によるリビジョンの固定、およびトークンの分離機能を提供します。vLLM、TGI、SGLang ランタイムとも互換性があります。詳細については、kubectl を使用して Amazon S3、Amazon FSx、または Hugging Face Hub からモデルをデプロイする を参照してください。Hugging Face ソースの場合、推論オペレーター（Inference Operator）は、デプロイメントのステータスを追跡するために、失敗または成功の状態に対して Kubernetes イベントを生成します。
前提条件
Hugging Face モデルをデプロイするには、選択したモデルに基づいて以下の前提条件フィールドを提供する必要があります。
- 有効な modelId を提供してください。
- ゲート付きモデル用の Hugging Face トークンを含む Kubernetes Secret を用意してください。
- ダウンロードする重み（weights）のボリュームマウントを持つ GPU 対応ワーカーを用意してください。
Hugging Face モデルのデプロイ手順
- Hugging Face API トークンを格納した Kubernetes Secret を作成します。このトークンはゲート付きモデルに必要であり、すべてのダウンロードで使用する必要があります。トークンの生成は huggingface.co/settings/tokens で行えます。
kubectl create secret generic hf-token-secret --from-literal=token=hf_YOUR_TOKEN_HERE \
-n $CLUSTER_NAMESPACE
- SageMaker エンドポイント名を設定します。
export SAGEMAKER_ENDPOINT_NAME="mistral7b-hf"
- 以下のサンプル YAML を作成してください。完全なデプロイ用 YAML は、kubectl を使用して Amazon S3、Amazon FSx、または Hugging Face Hub からモデルをデプロイする際の「Hugging Face」セクションをご参照ください。
modelName: mistral-7b
modelSourceConfig:
modelSourceType: huggingface
prefetchEnabled: true
huggingFaceModel:
modelId: "mistralai/Mistral-7B-Instruct-v0.3"
tokenSecretRef:
name: hf-token-secret
key: token
instanceType: "ml.g5.24xlarge"
- kubectl コマンドを使用して YAML ファイルをデプロイします。
kubectl apply -f deploy_hf_inference.yaml
- モデルが正常にデプロイされ、エンドポイントが作成されたか確認します。
kubectl describe InferenceEndpointConfig $SAGEMAKER_ENDPOINT_NAME -n $CLUSTER_NAMESPACE
kubectl describe SageMakerEndpointRegistration $SAGEMAKER_ENDPOINT_NAME -n $CLUSTER_NAMESPACE
- デプロイのステータスを確認し、エラーをデバッグするには Kubernetes イベントをチェックします。
kubectl get events -n $CLUSTER_NAMESPACE
- デプロイされたエンドポイントをテストして、正常に動作しているか確認します。このステップにより、モデルが正常にデプロイされ、推論リクエストを処理できることが検証されます。
aws sagemaker-runtime invoke-endpoint \
--endpoint-name $SAGEMAKER_ENDPOINT_NAME \
--content-type "application/json" \
--body '{"inputs": "What is AWS SageMaker?"}' \
--region $REGION \
--cli-binary-format raw-in-base64-out \
/dev/stdout
Route 53 DNS の管理
dnsConfig を通じて、カスタムドメインの DNS レコードを自動的に作成および管理することができます。詳細については、「HyperPod Inference 用のカスタム証明書と Route 53 DNS 管理」をご覧ください。
Amazon SageMaker HyperPod の推論機能は現在、Amazon Route 53 と統合されており、推論エンドポイントのカスタムドメインに対する DNS レコードの自動作成および管理が可能になりました。CRD（Custom Resource Definition）にホストゾーン ID を指定するだけで、オペレーターがカスタムドメイン向けのレコード作成、更新、およびクリーンアップを自動的に処理します。
事前準備
Route 53 の DNS 管理を設定する前に、以下の項目が用意されていることを確認してください：
- カスタムドメインをカバーし、ステータスが「Issued（発行済み）」である AWS Certificate Manager (ACM) の証明書。
- ドメイン用の Route 53 ホストゾーン。
IAM パーミッション
以下の権限を Inference Operator の実行ロールに追加してください：
{
"Version": "2012-10-17",
"Statement": [
{
"Sid": "ACMCustomCertificateAccess",
"Effect": "Allow",
"Action": [
"acm:DescribeCertificate",
"acm:GetCertificate"
],
"Resource": "arn:aws:acm:::certificate/*"
},
{
"Sid": "S3CertificateUpload",
"Effect": "Allow",
"Action": [
"s3:PutObject",
"s3:PutObjectTagging"
],
"Resource": "arn:aws:s3:::/*",
"Condition": {
"StringEquals": {
"s3:RequestObjectTag/CreatedBy": "HyperPodInference"
}
}
},
{
"Sid": "Route53DNSManagement",
"Effect": "Allow",
"Action": [
"route53:GetHostedZone",
"route53:ListResourceRecordSets",
"route53:ChangeResourceRecordSets"
],
"Resource": "arn:aws:route53:::hostedzone/"
}
]
}
をそれぞれ実際の値に置き換えてください。S3 バケット名が hyperpod-tls で始まる場合、AmazonSageMakerHyperPodInferenceAccess マネージドポリシーに S3 権限が含まれているため、ACM と Route 53 のステートメントのみが必要です。
DNS 管理の設定
モデルデプロイメントの YAML に tlsConfig と dnsConfig を追加して、Route 53 DNS 管理を有効化します。
tlsConfig:
customCertificateConfig:
acmArn: arn:aws:acm:us-west-2:123456789012:certificate/abc12345-1234-1234-1234-abc123456789
domainName: api.example.com
tlsCertificateOutputS3Uri: s3://my-tls-bucket
dnsConfig:
hostedZoneId: Z1234567890ABC
The domainName must match a domain in your ACM certificate. For wildcard certificates (for example, *.example.com), specify the specific subdomain (for example, api.example.com).
Verify DNS status
kubectl describe InferenceEndpointConfig my-model -n my-namespace
Check the dnsStatus section:
Status:
Dns Status:
Managed By Operator: true
Record Name: api.example.com
Hosted Zone Id: Z1234567890ABC
Dns Health: Active
Message: DNS record resolves successfully
After DNS health shows Active, you can access your endpoint at your custom domain.
For more information about custom domains and TLS configuration, see Custom certificates and Route 53 DNS management for HyperPod Inference.
ローカル NVMe によるモデルデプロイメント
Amazon SageMaker HyperPod は、モデルの重み（weights）をネットワーク経由で Amazon S3 や Amazon FSx から取得するのではなく、ノードのローカル NVMe ストレージから直接読み込むことをサポートしています。ローカルで重みを読み取ることで、ポッド起動時のネットワークホップが不要となり、推論用ポッドのコールドスタート時間を短縮できます。このアプローチは、オートスケーリングイベント、ゼロからのスケールワークロード、およびレイテンシに敏感なフェイルオーバーに活用できます。ローカル NVMe インスタンスストレージは、通常 P、G、Trn インスタンスファミリーに見られます。
前提条件
ローカル NVMe をモデルソースとして使用する前に、以下の事項を確認してください：
- ローカル NVMe ドライブを備えた GPU インスタンスを使用してください。
- ターゲットノードのローカル NVMe ストレージにモデルの重みを事前に読み込んでおくことを確認してください。
NVMe からモデルをデプロイする手順
- ターゲットノードのローカル NVMe ストレージに、事前にモデル重み（weights）を読み込んでおくことを確認してください。
- 以下のサンプル YAML を作成してください。完全なデプロイ用 YAML は、「kubectl を使用してローカル NVMe ストレージからモデルをデプロイする」をご覧ください。
spec:
modelSourceConfig:
modelSourceType: kubernetesVolume
kubernetes:
volumes:
- name: model-weights
hostPath:
path: /opt/dlami/nvme/
type: Directory
worker:
modelVolumeMount:
name: model-weights
mountPath: /opt/ml/model
- kubectl コマンドを使用して YAML ファイルをデプロイします：
kubectl apply -f deploy_nvme_k8s_volume.yaml
- デプロイステータスを確認します：
kubectl describe InferenceEndpointConfig nvme-k8s-volume -n $CLUSTER_NAMESPACE
カスタムサービスアカウント
デフォルトでは、推論用ポッド（pod）は名前空間のデフォルト ServiceAccount を使用します。AWS 認証情報が必要なワークロード（例えば、フォールバック用の initContainer で S3 からモデル重みをダウンロードする場合など）には、IRSA（IAM Roles for Service Accounts）サポートを備えたカスタム ServiceAccount を割り当てることができます。
前提条件
カスタムサービスアカウントのサポートはデフォルトで無効になっています。使用する前にクラスター管理者がこれを有効にする必要があります：
helm upgrade hyperpod-inference-operator \
--set enableCustomServiceAccounts=true \
--reuse-values
Amazon Elastic Kubernetes Service (Amazon EKS) のアドオンとしてデプロイされる場合、アドオンの設定を更新して、詳細設定に enableCustomServiceAccounts: true を含めてください。
カスタムサービスアカウントの設定手順
IRSA ロール ARN で注釈された Kubernetes ServiceAccount を作成します:
kubectl create sa my-inference-sa -n my-namespace
kubectl annotate sa my-inference-sa -n my-namespace \
eks.amazona
原文を表示
As enterprises scale their generative AI workloads, the demand for faster, more observable, and more flexible inference infrastructure continues to grow. Amazon SageMaker HyperPod is rising to meet that challenge with a set of new capabilities designed to streamline how organizations deploy and operate large models in production. Teams can now record inputs and outputs at multiple points along the inference path: from the endpoint, to the load balancer, to the model pod itself. This provides deep observability and auditability through declarative custom resource definition (CRD) configuration. You can also deploy models directly from popular community hubs without the need to pre-stage weights in object or file storage, with built-in support for gated access, revision pinning, and token isolation across leading inference runtimes such as vLLM, TGI, and SGLang.
Beyond deployment, these enhancements deliver meaningful performance and security gains. Loading weights from node-local NVMe storage reduces cold-start latency, with automatic fallback to cloud storage when needed. HyperPod automatically manages custom domain DNS records for you, while granular pod-level AWS Identity and Access Management (IAM) permissions give infrastructure teams fine-grained control over security boundaries. Together, these capabilities create a more performant, secure, and enterprise-ready inference experience on HyperPod. Teams can ship AI applications faster without compromising on governance or operational visibility.
*Inference on Amazon SageMaker HyperPod*
Inference data capture
With Amazon SageMaker HyperPod inference data capture, you can record inference request and response data for model monitoring, debugging, and model improvement. Inference requests flow from the Amazon SageMaker AI endpoint to the Application Load Balancer and then to the model pod. You independently control and configure data capture at each level, giving you flexibility to choose the right depth of visibility for your use case.
Prerequisite
The following are prerequisites before you enable the data capture feature.
- You need an Amazon Simple Storage Service (Amazon S3) bucket (using a URI like s3://amzn-s3-demo-bucket or s3://amzn-s3-demo-bucket/prefix) and the right IAM permissions for the operator to write to it. If you don’t provide one, the system uses the TLS certificate bucket instead.
- Each tier has its own required settings. For the SageMaker Endpoint level, turn it on, set a destination S3 URI, pick at least one capture option (input, output, or both), and choose a sampling percentage. For the Load Balancer level, enable it with an s3:// URI. For the Model Pod level, enable it. It defaults to capturing both input and output at 100 percent sampling.
- While not required, we recommend that you add an AWS Key Management Service (AWS KMS) key so you can encrypt your captured data. You can also fine-tune the buffer settings (batch size and flush interval) and set up content-type headers for CSV/JSON handling along with payload size limits.
Capture tiers
Data capture supports three tiers, each capturing at a different point in the request flow. You can enable any combination:
- Tier 1 – SageMaker AI endpoint ({s3Uri}/{hash}/sme/): Captures full input and output payloads at the SageMaker AI Runtime API boundary. This tier requires you to register the endpoint. Use Tier 1 when you need compatibility with SageMaker AI Model Monitor.
- Tier 2 – Application Load Balancer ({s3Uri}/{hash}/alb/): Turns on ALB access logs, which capture request metadata such as client IPs, request paths, and latencies.
- Tier 3 – Model pod ({s3Uri}/{hash}/pod/): Captures full inference input and output payloads at the inference container with configurable sampling, buffering, and payload size limits. Works without SageMaker AI endpoint registration. Use Tier 3 when you need the deepest visibility closest to the model.
Configuring data capture
Enable data capture by adding a dataCapture section to your InferenceEndpointConfig or JumpStartModel CRD. The following example shows the overall structure with all three tiers enabled:
dataCapture:
s3Uri: s3://amzn-s3-demo-bucket/captures/ # Optional. Defaults to TLS bucket.
sagemakerEndpoint:
enabled: true
initialSamplingPercentage: 100
kmsKeyId: arn:aws:kms:us-east-2:123456789012:key/my-key-id
captureOptions:
- captureMode: Input
- captureMode: Output
captureContentTypeHeader:
jsonContentTypes:
- application/json
loadBalancer:
enabled: true
modelPod:
enabled: true
initialSamplingPercentage: 100
kmsKeyId: arn:aws:kms:us-east-2:123456789012:key/my-key-id
captureOptions:
- captureMode: Input
- captureMode: Output
bufferConfig:
batchSize: 100
flushIntervalSeconds: 60
payloadConfig:
maxPayloadSizeKB: 1024S3 storage behavior
All tiers write to your Amazon S3 bucket. If you don’t specify an s3Uri, HyperPod stores your data in the TLS certificate bucket under a /data-capture/ prefix by default. Within the bucket, each deployment gets a unique path based on a hash derived from the cluster ARN, namespace, CRD type, and deployment name. The same deployment always generates the same prefix, so data capture artifacts from multiple CRD submissions targeting the same deployment flow to the same S3 subfolder.
IAM permissions
To enable data capture on existing clusters, add the following S3 permission to your Inference Operator Execution Role:
{
"Sid": "DataCaptureS3Access",
"Effect": "Allow",
"Action": "s3:PutObject",
"Resource": "arn:aws:s3:::hyperpod-tls*/data-capture/*",
"Condition": {
"StringEquals": {
"aws:ResourceAccount": "${aws:PrincipalAccount}"
}
}
}If you use a customer-managed KMS key, also add:
{
"Sid": "DataCaptureKmsAccess",
"Effect": "Allow",
"Action": [
"kms:Decrypt",
"kms:GenerateDataKey"
],
"Resource": "arn:aws:kms:*:*:key/*",
"Condition": {
"StringLike": {
"kms:ViaService": "s3.*.amazonaws.com",
"kms:EncryptionContext:aws:s3:arn": "arn:aws:s3:::hyperpod-tls*"
},
"StringEquals": {
"aws:ResourceAccount": "${aws:PrincipalAccount}"
}
}
}Best practices
Follow these recommendations to optimize data capture for cost, security, and operational efficiency.
- Use initialSamplingPercentage to control the volume of captured data. Start with a lower percentage in production and increase as needed.
- Use payloadConfig.maxPayloadSizeKB (Tier 3) to cap the size of captured payloads and control storage costs.
- Specify a kmsKeyId for Tier 1 and Tier 3 if your workload requires encryption at rest with your own KMS key.
- ALB access logs (Tier 2) capture request metadata including URLs and query parameters. Use POST request bodies rather than query parameters for sensitive inputs.
To disable data capture for a tier, set its enabled field to false or remove the tier section from your CRD. To disable all data capture, remove the dataCapture section entirely.
For more information, see Data capture for inference on HyperPod.
Hugging Face model source
Deploy models directly from Hugging Face Hub without pre-staging to Amazon S3 or Amazon FSx. This source supports gated models through tokenSecretRef, revision pinning through commitSHA, and token isolation. It is compatible with vLLM, TGI, and SGLang runtimes. See Deploy models from Amazon S3, Amazon FSx, or Hugging Face Hub using kubectl for details. For the Hugging Face source, the Inference Operator emits Kubernetes events for any failures or success states to track the status of the deployment.
Prerequisites
To deploy Hugging Face models, you must provide the following prerequisite fields based on the model chosen.
- Provide a valid modelId.
- A Kubernetes Secret with your Hugging Face token (for gated models).
- A GPU-enabled worker with a volume mount for the weights you download.
Steps to deploy a Hugging Face model
- Create a Kubernetes Secret containing your Hugging Face API token. You need this token for gated models and should use it for all downloads. You can generate a token at huggingface.co/settings/tokens.
kubectl create secret generic hf-token-secret --from-literal=token=hf_YOUR_TOKEN_HERE \
-n $CLUSTER_NAMESPACE- Set up a SageMaker endpoint name.
export SAGEMAKER_ENDPOINT_NAME="mistral7b-hf"- Construct the following sample YAML. For the entire deployment YAML, see the Hugging Face section in Deploy models from Amazon S3, Amazon FSx, or Hugging Face Hub using kubectl
modelName: mistral-7b
modelSourceConfig:
modelSourceType: huggingface
prefetchEnabled: true
huggingFaceModel:
modelId: "mistralai/Mistral-7B-Instruct-v0.3"
tokenSecretRef:
name: hf-token-secret
key: token
instanceType: "ml.g5.24xlarge"- Deploy the YAML file with the kubectl command:
kubectl apply -f deploy_hf_inference.yaml- Check if the model successfully deployed and endpoint created successfully.
kubectl describe InferenceEndpointConfig $SAGEMAKER_ENDPOINT_NAME -n $CLUSTER_NAMESPACE
kubectl describe SageMakerEndpointRegistration $SAGEMAKER_ENDPOINT_NAME -n $CLUSTER_NAMESPACE- To check the status of the deployment and debug errors check the Kubernetes events
kubectl get events -n $CLUSTER_NAMESPACE- Test the deployed endpoint to verify it’s working correctly. This step confirms that your model is successfully deployed and can process inference requests.
aws sagemaker-runtime invoke-endpoint \
--endpoint-name $SAGEMAKER_ENDPOINT_NAME \
--content-type "application/json" \
--body '{"inputs": "What is AWS SageMaker?"}' \
--region $REGION \
--cli-binary-format raw-in-base64-out \
/dev/stdoutRoute 53 DNS management
You can automatically create and manage DNS records for custom domains through dnsConfig. For more information, see Custom certificates and Route 53 DNS management for HyperPod Inference.
Amazon SageMaker HyperPod inference now integrates with Amazon Route 53 to automatically create and manage DNS records for your inference endpoints. Specify a hosted zone ID in your CRD and the operator handles record creation, updates, and cleanup for your custom domain.
Prerequisites
Before configuring Route 53 DNS management, make sure you have the following:
- An AWS Certificate Manager (ACM) certificate in the Issued state covering your domain.
- A Route 53 hosted zone for your domain.
IAM permissions
Add the following permissions to your Inference Operator execution role:
{
"Version": "2012-10-17",
"Statement": [
{
"Sid": "ACMCustomCertificateAccess",
"Effect": "Allow",
"Action": [
"acm:DescribeCertificate",
"acm:GetCertificate"
],
"Resource": "arn:aws:acm:::certificate/*"
},
{
"Sid": "S3CertificateUpload",
"Effect": "Allow",
"Action": [
"s3:PutObject",
"s3:PutObjectTagging"
],
"Resource": "arn:aws:s3:::/*",
"Condition": {
"StringEquals": {
"s3:RequestObjectTag/CreatedBy": "HyperPodInference"
}
}
},
{
"Sid": "Route53DNSManagement",
"Effect": "Allow",
"Action": [
"route53:GetHostedZone",
"route53:ListResourceRecordSets",
"route53:ChangeResourceRecordSets"
],
"Resource": "arn:aws:route53:::hostedzone/"
}
]
}Replace `, , , and with your actual values. If your S3 bucket name starts with hyperpod-tls, the S3 permissions are already included in the AmazonSageMakerHyperPodInferenceAccess` managed policy and you only need the ACM and Route 53 statements.
Configuring DNS management
Enable Route 53 DNS management by adding tlsConfig and dnsConfig to your model deployment YAML:
tlsConfig:
customCertificateConfig:
acmArn: arn:aws:acm:us-west-2:123456789012:certificate/abc12345-1234-1234-1234-abc123456789
domainName: api.example.com
tlsCertificateOutputS3Uri: s3://my-tls-bucket
dnsConfig:
hostedZoneId: Z1234567890ABCThe domainName must match a domain in your ACM certificate. For wildcard certificates (for example, *.example.com), specify the specific subdomain (for example, api.example.com).
Verify DNS status
kubectl describe InferenceEndpointConfig my-model -n my-namespaceCheck the dnsStatus section:
Status:
Dns Status:
Managed By Operator: true
Record Name: api.example.com
Hosted Zone Id: Z1234567890ABC
Dns Health: Active
Message: DNS record resolves successfullyAfter DNS health shows Active, you can access your endpoint at your custom domain.
For more information about custom domains and TLS configuration, see Custom certificates and Route 53 DNS management for HyperPod Inference.
Local NVMe model deployment
Amazon SageMaker HyperPod supports loading model weights directly from a node’s local NVMe storage instead of pulling them over the network from Amazon S3 or Amazon FSx. When you read weights locally, you remove the network hop during pod startup, which helps you reduce inference pod cold-start time. You can use this approach for autoscaling events, scale-from-zero workloads, and latency-sensitive failovers. Local NVMe instance storage is typically found in P, G, and Trn instance families.
Prerequisite
Before using local NVMe as a model source, verify the following:
- Use GPU instances with local NVMe drives.
- Make sure that you pre-populate model weights on the local NVMe storage of your target nodes.
Steps to deploy model from NVMe
- Make sure that you pre-populate model weights on the local NVMe storage of your target nodes.
- Construct the following sample YAML. For the entire deployment YAML, see the Deploy models from local NVMe storage using kubectl
spec:
modelSourceConfig:
modelSourceType: kubernetesVolume
kubernetes:
volumes:
- name: model-weights
hostPath:
path: /opt/dlami/nvme/
type: Directory
worker:
modelVolumeMount:
name: model-weights
mountPath: /opt/ml/model- Deploy the YAML file with kubectl command:
kubectl apply -f deploy_nvme_k8s_volume.yaml- Verify the deployment status:
kubectl describe InferenceEndpointConfig nvme-k8s-volume -n $CLUSTER_NAMESPACECustom service accounts
By default, inference pods use the namespace’s default ServiceAccount. For workloads that need AWS credentials (such as downloading model weights from S3 in a fallback initContainer), you can assign a custom ServiceAccount with IRSA (IAM Roles for Service Accounts) support.
Prerequisites
Custom service account support remains off by default. A cluster administrator must enable it before use:
helm upgrade hyperpod-inference-operator \
--set enableCustomServiceAccounts=true \
--reuse-valuesIf deployed as an Amazon Elastic Kubernetes Service (Amazon EKS) add-on, update the add-on configuration to include enableCustomServiceAccounts: true in the advanced configuration settings.
Steps to set up a custom service account
Create a Kubernetes ServiceAccount annotated with your IRSA role ARN:
kubectl create sa my-inference-sa -n my-namespace
kubectl annotate sa my-inference-sa -n my-namespace \
eks.amazona
関連記事
今日のまとめ
AI日報で今日の重要ニュースをまとめ読み