Amazon SageMaker HyperPod のデータキャプチャ、Hugging Face、NVMe、Route 53 統合によるエンタープライズ推論の強化

企業が生成 AI ワークロードをスケールするにつれ、より高速で、より観測可能で、より柔軟な推論インフラストラクチャへの需要は増し続けています。Amazon SageMaker HyperPod は、組織が生産環境で大規模モデルを展開・運用する方法を合理化するために設計された一連の新しい機能によって、この課題に対応しています。チームは今や、エンドポイントからロードバランサー、さらにモデルポッド自体に至るまで、推論パス上の複数の地点で入力と出力を記録できるようになりました。これにより、宣言型のカスタムリソース定義（CRD）設定を通じて、深い観測性と監査可能性が提供されます。また、オブジェクトストレージやファイルストレージに重み値を事前に配置する必要なく、人気のあるコミュニティハブから直接モデルを展開することも可能です。これには、主要な推論ランタイムである vLLM、TGI、SGLang 間で、ゲート付きアクセス、リビジョンのピン留め、トークン分離に対する組み込みサポートが含まれています。

デプロイメントを超えて、これらの機能強化は実効性のあるパフォーマンス向上とセキュリティの強化をもたらします。ノードローカルの NVMe ストレージからウェイトを読み込むことでコールドスタート遅延を低減し、必要に応じてクラウドストレージへの自動フォールバックも可能です。HyperPod はカスタムドメインの DNS レコードを自動的に管理し、細粒度なポッドレベルの AWS Identity and Access Management (IAM) 権限により、インフラチームがセキュリティ境界に対してきめ細かい制御を行えるようになります。これらの機能を組み合わせることで、HyperPod 上でより高性能で安全かつエンタープライズ対応の推論体験を実現できます。チームはガバナンスや運用上の可視性を損なうことなく、AI アプリケーションを迅速にリリースできるようになります。

推論データキャプチャー

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