翻訳は機械翻訳により提供されています。提供された翻訳内容と英語版の間で齟齬、不一致または矛盾がある場合、英語版が優先します。 # Amazon SageMaker HyperPod 推論用の推論ゲートウェイ Amazon SageMaker HyperPod Inference Gateway は、Amazon EKS 上の HyperPod クラスター用の Kubernetes ネイティブの大規模言語モデル (LLM) 対応ルーティングおよびオーケストレーションレイヤーです。推論リクエストを検査し、各リクエストからモデル名を読み取り、GPU 負荷に基づいてモデル提供ポッドを選択すると、複数のモデルのトラフィックが単一のゲートウェイエンドポイントを介して効率的にルーティングされます。 ゲートウェイは、各リクエストを 3 つのレイヤーにルーティングします。共有コンポーネントである本文ベースのルーター (BBR) は、リクエスト本文から `model`フィールドを読み取り、LoRA アダプター名をベースモデルに解決し、 `X-Gateway-Model-Name` ヘッダーと `X-Gateway-Base-Model-Name`ヘッダーを設定します。次に、ゲートウェイはこれらのヘッダーを HTTPRoute に照合し、リクエストされたモデルの `InferencePool` にリクエストを転送します。このプール内で、Endpoint Picker (EPP/スケジューラ) は、キューの深さや KV キャッシュ使用率などのモデルサーバーメトリクスの候補をプレフィックスキャッシュや LoRA アダプターのアフィニティとともにスコアリングすることで、モデルサービスを提供するポッドを選択します。で定義する各エントリは独自の Endpoint Picker `spec.schedulers`を実行するため、このトピックでは Endpoint Picker、EPP、スケジューラという用語を同じ意味で使用します。 Inference Gateway は、置き換える代わりに [HyperPod Inference Operator](sagemaker-hyperpod-model-deployment.md) 上に構築されます。オペレーターがモデルのデプロイをオーケストレーションし続ける間、ゲートウェイはモデル提供ポッドの前に LLM 対応ルーティングレイヤーを導入します。ゲートウェイは、特定のモデルサーバーまたはオーケストレーションレイヤーに依存しず、HyperPod Inference Amazon EKS アドオンを介して配信されます。 `InferenceGatewayConfig` カスタムリソースを使用してゲートウェイを定義します。単一の は、共有ボディベースルーター、TLS 終了、リクエスト認証、ゲートウェイが機能するモデルごとに 1 つのスケジューラという 1 つのゲートウェイを`InferenceGatewayConfig`記述します。スキーマの詳細については、「」を参照してください[InferenceGatewayConfig CRD リファレンス](#sagemaker-hyperpod-model-deployment-inference-gateway-crd)。 **重要** Inference Gateway によって作成されたエンドポイントには、デフォルトではリクエストレベルの認証や認可はありません。`spec.auth.jwt` で を設定しない限り`InferenceGatewayConfig`、ゲートウェイはそれに到達するすべてのリクエストを受け入れます。アクセスは VPC とネットワークコントロールによってのみ制限されます。すべてのゲートウェイで JWT 認証を有効にすることを強くお勧めします。認証を設定するには、「」の[前提条件とデプロイ](#sagemaker-hyperpod-model-deployment-inference-gateway-prereqs)「」と`spec.auth`「」を参照してください[仕様フィールド](#sagemaker-hyperpod-model-deployment-inference-gateway-spec)。 ## 前提条件とデプロイ Inference Gateway は、HyperPod Inference Amazon EKS アドオンの一部として配信されます。アドオンをインストールするとゲートウェイが使用可能になるため、別途インストールする必要はありません。次に、モデルの`InferenceEndpointConfig`リソースの `spec.inferenceGateway.enabled`フィールドを通じてモデルのゲートウェイルーティングを有効にします。機能が導入されたバージョンについては、「」を参照してください[Amazon SageMaker HyperPod Inference リリースノート](sagemaker-hyperpod-inference-release-notes.md)。 ゲートウェイ経由でトラフィックをルーティングする前に、以下を確認してください。 デプロイされたモデル提供ポッド 各スケジューラは、ラベルセレクタによって選択されたモデル提供ポッドにルーティングされます。HyperPod Inference Operator を使用してモデルをデプロイし、ポッドに適用されるラベルを書き留めて、ゲートウェイ設定で参照できるようにします。モデルポッドのラベルを一覧表示するには、次のコマンドを実行します。 ``` kubectl get pods -n NAMESPACE --show-labels ``` モデルサーバーバージョン Inference Gateway には、vLLM v0.9.2 以降と SGLang v0.3.5.post1 以降が必要です。以前の vLLM バージョンでは、KV キャッシュメトリクスはゲートウェイが読み取るものとは異なる名前で発行されます。リクエストは残りのシグナルを使用してルーティングされますが、KV キャッシュ使用率は無視され、エラーは報告されません。以前の SGLang バージョンは `--enable-metrics`フラグをサポートしておらず、コンテナの起動に失敗します。ゲートウェイがルーティングの決定に必要なメトリクスを読み取れるように、このフラグで SGLang を起動します。 [アドオンバージョン] Inference Gateway はAmazon SageMaker HyperPod Inference アドオン`v2.0.0-eksbuild.2`のバージョンから使用できます。利用可能な最新バージョンのアドオンをインストールまたは更新します。クラスターが`InferenceGatewayConfig`リソースを認識しない場合、アドオンはゲートウェイを含まない以前のバージョンを実行しています。 クラスターの依存関係 + cert-manager は、自動発行 TLS パスのクラスターにインストールする必要があります。これは、 が なしで設定されている場合にゲートウェイ`spec.tls`が使用します`acmArn`。 + Application AWS Load Balancer エンドポイントタイプにはApplication Load Balancerコントローラーをインストールする必要があります。 + ゲートウェイは `hyperpod-inference-system`名前空間を使用します。 TLS 証明書 ゲートウェイで HTTPS を終了するには、既存の ACM 証明書 ARN を指定するか、ゲートウェイに証明書を自動発行させます。自動発行では、cert-manager を使用して証明書を ACM にインポートします。このフローでは、オペレーター実行ロールに IRSA を介した `acm:ImportCertificate`、`acm:DescribeCertificate`、、および `acm:AddTagsToCertificate`アクセス`acm:DeleteCertificate`許可が必要です。 認証のリクエスト (推奨) `spec.auth.jwt` で を設定して、すべてのゲートウェイで JWT 認証を有効にすることを強くお勧めします`InferenceGatewayConfig`。`spec.auth` を省略すると、ゲートウェイにはリクエストレベルの認証がなく、アクセスは VPC とネットワークコントロールによってのみ制限されます。JWT 認証を有効にするには、 を作成する前に、OIDC `InferenceGatewayConfig`発行者 URL、発行者の署名キーを発行する HTTPS JWKS エンドポイント、およびこのゲートウェイのトークンが保持する必要があるオーディエンス値 (または必要なクレーム) を用意します。スキーマの詳細については、[仕様フィールド](#sagemaker-hyperpod-model-deployment-inference-gateway-spec)「」の`spec.auth`「」を参照してください。 ### 証明書発行者の IAM ロールを設定する ゲートウェイが TLS 証明書を自動発行すると、cert-manager はクラスターに証明書を生成し、ゲートウェイコントローラーはそれを ACM にインポートします。インポートは AWS API コールであるため、コントローラーには AWS 認証情報が必要です。これらを提供するには、`hyperpod-inference-system`名前空間`inference-gateway-controller`のサービスアカウントがサービスアカウント (IRSA) の IAM ロールを通じて引き受ける IAM ロールを作成します。 **重要** TLS 自動発行はデフォルトで有効になっており、ゲートウェイコントローラーは起動時にこのロールを読み取ります。アドオンをインストールする前にロールを作成します。 次の環境変数を設定し、クラスターの OIDC 発行者を取得します。 ``` export CLUSTER=EKS_CLUSTER_NAME export REGION=REGION export ACCOUNT=AWS_ACCOUNT_ID export ROLE_NAME=CERT_ISSUER_ROLE_NAME export OIDC_ID=$(aws eks describe-cluster --name $CLUSTER --region $REGION \ --query 'cluster.identity.oidc.issuer' --output text | sed 's|https://||') ``` ゲートウェイコントローラーサービスアカウントがロールを引き受けることを許可する信頼ポリシーを作成します。 ``` cat > trust-policy.json < HyperPod Inference アドオンは、Inference Operator と Inference Gateway の両方をインストールします。次のコマンドを使用してインストールします。には`inferenceGateway.serviceAccount.roleArn`、前のセクションで作成した証明書発行者ロールを使用します。残りのプレースホルダー値を、アカウントのロールとバケットに置き換えます。 ``` aws eks create-addon \ --cluster-name $CLUSTER --region $REGION \ --addon-name amazon-sagemaker-hyperpod-inference \ --addon-version v2.0.0-eksbuild.2 \ --configuration-values '{ "executionRoleArn": "arn:aws:iam:::role/", "tlsCertificateS3Bucket": "", "inferenceOperator": { "enabled": true }, "inferenceGateway": { "enabled": true, "serviceAccount": { "roleArn": "arn:aws:iam:::role/" } }, "keda": { "enabled": true, "auth": { "aws": { "irsa": { "enabled": true, "roleArn": "arn:aws:iam:::role/" } } } }, "alb": { "enabled": true, "serviceAccount": { "create": true, "roleArn": "arn:aws:iam:::role/" } }, "jumpstartGatedModelDownloadRoleArn": "arn:aws:iam:::role/" }' ``` アドオンがクラスターに既にインストールされている場合は、 `create-addon`を に置き換え`update-addon`て を追加します`--resolve-conflicts OVERWRITE`。コマンドの残りの部分は変更されません。 はコマンドの設定値を既存のアドオン設定`OVERWRITE`に適用します。 ゲートウェイコントローラーが実行されていること、およびゲートウェイリソースが登録されていることを確認します。 ``` kubectl rollout status deploy/inference-gateway-controller \ -n hyperpod-inference-system --timeout=150s kubectl get crd inferencegatewayconfigs.inference.sagemaker.aws.amazon.com kubectl get gatewayclass inference-gateway ``` アドオン自体がアクティブであり、ヘルスの問題がないことを確認します。 ``` aws eks describe-addon \ --cluster-name $CLUSTER --region $REGION \ --addon-name amazon-sagemaker-hyperpod-inference \ --query 'addon.{version:addonVersion,status:status,health:health.issues}' ``` ## HyperPod Inference Operator との統合 HyperPod Inference Operator と Inference Gateway には個別の責任があります。オペレーターは、モデルのデプロイ、オーケストレーション、およびモデルをゲートウェイにアタッチするワイヤリングを所有します。ゲートウェイはリクエストルーティングを所有し、各スケジューラのルーティングリソースを生成します。演算子を使用したモデルのデプロイの詳細については、「」を参照してください[Amazon SageMaker HyperPod にモデルをデプロイする](sagemaker-hyperpod-model-deployment.md)。 HyperPod 推論演算子 モデルのカスタムリソース`InferenceEndpointConfig`と `JumpStartModel` (グループ `inference.sagemaker.aws.amazon.com`、バージョン `v1`) を調整します。オペレーターは、モデルのデプロイとサービス、Application Load Balancer、KEDA 自動スケーリング、cert-manager 証明書、SageMaker AI エンドポイント登録を作成します。モデルに対してゲートウェイを有効にすると、オペレーターはそのモデルをゲートウェイにワイヤ接続します。 推論ゲートウェイ ゲートウェイ経由の Body-Based Router から Endpoint Picker HTTPRoute へのリクエストルーティングを所有し、各スケジューラのダウンストリームルーティングリソース `InferencePool`、Endpoint Picker 設定、HTTPRoute、および を生成します`EnvoyExtensionPolicy`。 **注記** オペレーターのモデルカスタムリソースはバージョン を使用し`v1`、ゲートウェイの`InferenceGatewayConfig`リソースはバージョン を使用します`v1alpha1`。どちらも `inference.sagemaker.aws.amazon.com`グループに属します。 演算子、モデルの `InferenceEndpointConfig` (または `JumpStartModel`) リソース、 `spec.inferenceGateway`フィールドを使用して、モデルをゲートウェイにアタッチします。 `spec.inferenceGateway.enabled` (オプション、ブール値) このモデルがゲートウェイにアタッチされているかどうか。デフォルト: `false`。 `spec.inferenceGateway.name` (オプション、文字列) アタッチする`InferenceGatewayConfig`リソースの名前。名前空間と名前空間を共有するモデルは、1 つのゲートウェイを共有します。このフィールドが空の場合、演算子は という形式の名前を生成します`inf-igw-`。 次のスニペットは、 `InferenceEndpointConfig`リソースのオ`inferenceGateway`プトインを示しています。 ``` apiVersion: inference.sagemaker.aws.amazon.com/v1 kind: InferenceEndpointConfig metadata: name: my-model spec: # ... model deployment fields ... inferenceGateway: enabled: true name: my-gateway # Optional. When empty, the operator generates inf-igw-. ``` 演算子は、、`Pending`、`Ready`または `State`の `Failed`と`status.inferenceGateway`、アタッチされた `Name`の をレポートする のモデルリソースのアタッチ状態をミラーリングします`InferenceGatewayConfig`。同じモデル`intelligentRoutingSpec.enabled`で を`inferenceGateway.enabled`一緒に設定することはできません。これらのフィールドは相互に排他的です。 モデルに対してゲートウェイを有効にすると、オペレータは単一の`InferenceGatewayConfig`リソースを作成または更新し、モデルのエントリをその`spec.schedulers`リストにマージします。演算子は、スケジューラ `name`、`modelName`、`targetPort`、および を設定し`modelSelector`、エントリを最初に作成`llm-d`するときにデフォルトを `scheduler`に設定します。後の照合では、演算子は `scheduler`、、 `weights`などのお客様が指定した値を保持します`loraAdapters`。複数のスケジューラが存在する場合、本文ベースのルーターは自動的に有効になります。 オペレーターは、`InferenceGatewayConfig`リソースまたはダウンストリームルーティングリソースを削除しません。モデルのゲートウェイを無効にするか、モデルを削除すると、オペレーターはそのモデルのスケジューラエントリのみを削除します。ゲートウェイコントローラーは、ルーティングリソースのクリーンアップを所有しています。 は 2 つの`InferenceGatewayConfig`方法で作成でき、2 つのパスは同じリソースに共存します。 + モデルの `spec.inferenceGateway.enabled`で を設定して、 演算子を使用してモデルごとにゲートウェイを有効にします`InferenceEndpointConfig`。オペレーターは、モデルのスケジューラエントリを作成して維持します。 + 「」に示すように、`InferenceGatewayConfig`リソースを直接作成します[例](#sagemaker-hyperpod-model-deployment-inference-gateway-examples)。 ゲートウェイコンポーネントと `InferenceGatewayConfig` CRD は、ゲートウェイが有効になっているモデルリソースを照合する前に、HyperPod Inference Amazon EKS アドオンを介してインストールする必要があります。オペレータアドオンのインストールについては、「」を参照してください[EKS アドオンを使用した推論演算子のインストール](sagemaker-hyperpod-model-deployment-setup.md#sagemaker-hyperpod-model-deployment-setup-install-inference-operator-addon)。スケジューラがルーティングするモデル提供ポッドのデプロイについては、「」を参照してください[基盤モデルとカスタムファインチューニングされたモデルをデプロイする](sagemaker-hyperpod-model-deployment-deploy.md)。 **注記** SageMaker HyperPod Inference Operator の正常性を維持することは、 AWS とお客様の責任を共有します。 AWS は SageMaker HyperPod Inference Operator の配信と維持に責任を負います。インストール後、お客様はクラスター内のオペレーターの運用状態をモニタリングする責任があります。 ## InferenceGatewayConfig CRD リファレンス Inference Gateway は 1 つの`InferenceGatewayConfig`カスタムリソースで設定します。リソースは、特定のゲートウェイのシングルトンです。共有ボディベースのルーター設定とモデルごとのスケジューラのリストを保持します。コントローラーは`InferencePool`、各スケジューラの基盤となる 、エンドポイントピッカー、HTTPRoute、および`EnvoyExtensionPolicy`リソースを生成します。リソースのみを作成します`InferenceGatewayConfig`。 **InferenceGatewayConfig リソースメタデータ** | プロパティ | 値 | | --- | --- | | [Kind] (種類) | InferenceGatewayConfig | | Group | inference.sagemaker.aws.amazon.com | | バージョン | v1alpha1 | | 複数 | inferencegatewayconfigs | | 短縮名 | igwc | | スコープ | 名前空間 | | ステータスサブリソース | /status | ### 仕様フィールド `InferenceGatewayConfig` リソースの `spec`フィールドには、共有ボディベースのルーター設定、TLS 設定、スケジューラの必須リスト、オプションのオブザーバビリティとポッドのデフォルト設定が含まれます。 `bbr` (必須) 共有ボディベースルーターの設定。以下のフィールドが含まれています。 `bbr.enabled` (必須、ブール値) 本文ベースのルーターが有効になっているかどうか。複数のスケジューラが設定されている場合、ルーターを有効にする必要があります。 `bbr.replicas` (オプション、整数) 本文ベースのルーターレプリカの数。最小: `1`。デフォルト: `2`。 `bbr.defaultBackend` (オプション) ルーターがスケジューラと照合できないリクエストを受け取るバックエンド。`name` 文字列と`port`整数 (デフォルト: `8000`) が含まれます。 `bbr.maxRequestBodyBytes` (オプション、整数) `model` フィールドを読み取るためにルーターがバッファするリクエスト本文の最大サイズ。バイト単位。デフォルトと最大値: `268435456` (256 MiB)。 `tls` ゲートウェイの HTTPS 終了設定。既存の ACM 証明書を参照する `acmArn`フィールドが含まれます。`tls` が空の で設定されている場合`acmArn`、ゲートウェイは証明書を cert-manager で自動発行し、ACM にインポートします。 `auth` (オプション、推奨) 認証設定をリクエストします。すべてのゲートウェイで JWT ベアラートークン認証を有効にすることを強くお勧めします。省略すると、ゲートウェイにはリクエストレベルの認証はありません。ロードバランサーのヘルスチェックルートは認証されていないままであるため、ヘルスプローブはトークンなしで成功します。 次のフィールド`auth.jwt.provider`を含む が含まれます。 `name` (必須、文字列) プロバイダーの一意の名前。 `issuer` (必須、文字列) OIDC 発行者 URL (`https://...`)。ゲートウェイはこの値に対してトークンの`iss`クレームを検証します。 `remoteJWKS.uri` (必須、文字列) JWT 署名の検証に使用される HTTPS JWKS エンドポイント。 `audiences` (オプション、一覧表示) 許容される`aud`クレーム値 (最大 8)。または の少なくとも 1 つを設定`audiences``requiredClaims`する必要があります。 `requiredClaims` (オプション、一覧表示) クレームベースの認可 (最大 16 エントリ）。各エントリには、`name`、 `valueType` (`String` または `StringArray`)、および `values` (1～128 エントリ、各 1～1024 文字) があります。設定すると、ゲートウェイはデフォルトでリクエストを拒否し、クレーム値が一致するトークンのみを許可します。 `observability` (オプション) オブザーバビリティ設定。OpenTelemetry メトリクスのサイドカー`metrics.enabled`を制御する が含まれています。メトリクスはデフォルトで有効になっています。 `podDefaults` (オプション) 本文ベースのルーターポッドと Endpoint Picker ポッドの両方に適用されるデフォルトのポッド設定。`resources`、`nodeSelector`、、`tolerations`、`affinity`、`labels`、`annotations``env`、および をサポートします`envFrom`。 `schedulers` (必須、一覧表示) によってキー指定されたモデルごとのスケジューラ設定のリスト`name`。少なくとも 1 つのスケジューラが必要で、最大 100 個まで定義できます。各エントリは`SchedulerSpec`、「」で説明されている です[SchedulerSpec フィールド](#sagemaker-hyperpod-model-deployment-inference-gateway-scheduler)。 ### SchedulerSpec フィールド の各エントリは、1 つのモデルに対してルーティングとエンドポイントの選択`spec.schedulers`を設定します。スケジューラは、生成された `InferencePool`、エンドポイントピッカー、HTTPRoute、および`EnvoyExtensionPolicy`リソースに名前を付けます。 `name` (必須、文字列) スケジューラ名。生成された `InferencePool`、エンドポイントピッカー、HTTPRoute、および`EnvoyExtensionPolicy`リソースに名前を付けるために使用されます。最大長: 63 文字。 `modelSelector` (必須) このスケジューラがルーティングするモデル提供ポッドを選択する Kubernetes ラベルセレクタ。 `modelName` (必須、文字列) モデル名がリクエスト本文の `model`フィールドと一致し、HTTPRoute ヘッダーの一致として使用されます。スケジューラ間で一意である必要があります。最大長: 253 文字。 `targetPort` (オプション、整数) 転送されたトラフィックを受信するモデル提供ポッドのポート。範囲: 1～65535。デフォルト: `8000`。 `appProtocol` (オプション、文字列) モデル提供ポッドに到達するために使用されるアプリケーションプロトコル。有効な値: `http`、`kubernetes.io/h2c`。デフォルト: `http`。 `scheduler` (オプション、文字列) Endpoint Picker イメージを選択するスケジューラタイプ。有効な値: `llm-d`、`epp`。デフォルト: `llm-d`。 `engineType` (オプション、文字列) モデル提供ポッドで実行されている推論エンジン。この値は、Endpoint Picker がスクレイピングする Prometheus メトリクス名のセットを選択します。有効な値: `vllm`、`sglang`。デフォルト: `vllm`。 `weights` (オプション) Endpoint Picker が候補ポッドのランク付けに使用する重み付け。すべての重みは負以外の整数です。`configMapRef` と同時に使用することはできません。サポートされている重み: `queue` 保留中のリクエストキューの深さの重み。デフォルト: `2`。 `kvCache` KV キャッシュ使用率の重み。デフォルト: `2`。 `prefix` プレフィックスキャッシュアフィニティの重み。デフォルト: `3`。 `lru` least-recently-usedスコアリングの重み。`scheduler` が `llm-d` の場合にのみ有効です。 `loraAffinity` LoRA アダプターのアフィニティの重み。 `runningRequests` ポッドで実行中のリクエスト数の重み。 `predictedLatency` 予測リクエストレイテンシーの重み。 `configMapRef` (オプション) の代わりに、カスタム Endpoint Picker 設定を提供する ConfigMap への参照`weights`。必須 `name`と が含まれます `key` (デフォルト: `default-plugins.yaml`)。`weights` と同時に使用することはできません。 `replicas` (オプション、整数) このスケジューラの Endpoint Picker レプリカの数。最小: `1`。デフォルト: `2`。`replicas` が 1 より大きい場合、Endpoint Picker はリーダー選択で高可用性で実行されます。 `env` および `envFrom` (オプション) このスケジューラの Endpoint Picker コンテナに追加された環境変数。 `loraAdapters` (オプション、リスト) このスケジューラのモデルの背後にある LoRA アダプター名。最大: 50 項目、それぞれ最大 253 文字。 `routeTimeout` (オプション、文字列) Gateway API 期間としての HTTPRoute リクエストのタイムアウト (例: `30s`または `5m`)。`0s` に設定するとタイムアウトが無効になります。 `logLevel` (オプション、整数) Endpoint Picker ログの詳細度。範囲: 0～5。 ### 検証ルール `InferenceGatewayConfig` リソースは、次の検証ルールを適用します。これらのルールのいずれかに違反するリソースは拒否されます。 + 複数のスケジューラが設定されている場合、本文ベースのルーターを有効にする必要があります (`bbr.enabled: true`)。 + `modelName` は、すべてのスケジューラで一意である必要があります。 + スケジューラ内では、 `weights`と `configMapRef`は相互に排他的です。 + `weights.lru` 重みは、スケジューラ`scheduler`のタイプが の場合にのみ有効です`llm-d`。 ### ステータスフィールド コントローラーは、`status`サブリソース内のゲートウェイの観測状態を報告します。 `conditions` ゲートウェイ設定の全体的な状態を説明する標準 Kubernetes 条件。 `schedulers` スケジューラごとのステータス。各エントリには以下が含まれます。 `name` スケジューラ名。 `conditions` このスケジューラの状態を記述する条件。 `currentScheduler` このエントリで現在有効なスケジューラタイプ。 `rolloutState` スケジューラのロールアウト状態。`Pending`、`Progressing`、`Available`、`Degraded` のいずれか。 `observedGeneration` コントローラーによって最近調整されたリソースの生成。 `tls` TLS ステータス。自動発行モードでのみ報告されます。`acmArn`、`issuedAt`、および が含まれます`dnsNames`。 ## Kubernetes RBAC アクセス許可 Inference Gateway は、`hyperpod-inference-system`名前空間の Kubernetes サービスアカウント`inference-gateway-controller`で単一のコントローラーとして実行されます。本文ベースのルーター、スケジューラごとのエンドポイントピッカー、ゲートウェイコントローラー、`InferenceGatewayConfig`およびリコンシラーはすべて、この 1 つのコントローラーで実行されます。クラスタースコープのアクセス許可は、 `ClusterRole`という名前の `sagemaker-inference-gateway-controller-supplement`と一致する によって付与されます`ClusterRoleBinding`。これらは、バンドルされた Gateway チャートが既に提供しているサービスアカウントとアクセス許可を補完します。これらのアクセス許可はスコープと最小特権であり、コントローラーはクラスター管理者として実行されません。 次の表は、コントローラーのクラスタースコープのアクセス許可を目的別にグループ化したものです。この表では、*フルアクセス*とは、`create`、、`get`、`list`、`watch`、`update``patch`、および`delete`動詞を意味します。 **Inference Gateway コントローラーのアクセス許可** | API グループ | リソース | 動詞 | 目的 | | --- | --- | --- | --- | | inference.sagemaker.aws.amazon.com | inferencegatewayconfigs、 statusおよび finalizersサブリソースを含む | getpatchの場合は 、listwatch、、update、、および inferencegatewayconfigsget、 patchの場合は update、、および 、 updateの場合は status、 finalizers | InferenceGatewayConfig リソースの調整、ステータスの書き込み、ファイナライザーの管理を行います。 | | gateway.networking.k8s.io | httproutes, gateways, gatewayclasses | httproutes および のフルアクセスget、gateways、、create、、および list watchpatchのフルアクセス gatewayclasses | Gateway API を介したプログラムリクエストルーティング。 | | inference.networking.k8s.io | inferencepools | フル アクセス | スケジューラごとにルーティングバックエンドを作成します。 | | inference.networking.x-k8s.io | inferencepools, inferenceobjectives, inferencemodelrewrites | get, list, watch | エンドポイント選択の読み取りルーティングインテント。 | | gateway.envoyproxy.io | envoyextensionpolicies, envoyproxies, httproutefilters, clienttrafficpolicies, securitypolicies | フル アクセス | ゲートウェイデータプレーンとそのテレメトリを設定します。 | | コア ("") | configmaps, services, serviceaccounts, events, secrets, pods | configmaps、、および のフルアクセスservices、 serviceaccounts create および patchのフルアクセスlist、 および events getwatchのフルアクセス secrets pods | 生成されたワークロードと読み取りルーティングと配信状態を管理します。 | | apps | deployments | フル アクセス | ボディベースのルーターとエンドポイントピッカーのデプロイを管理します。 | | rbac.authorization.k8s.io | roles, rolebindings | フル アクセス | スケジューラごとの Endpoint Picker を作成しますRole。 | | discovery.k8s.io, coordination.k8s.io | endpointslices; leases | getwatchの場合は 、list、、および、 endpointslicespatchの場合は getlist、watch、、createupdate、、および leases | エンドポイント検出と Endpoint Picker リーダーの選択。 | | networking.k8s.io | ingresses, networkpolicies | フル アクセス | ロードApplication Load Balancer AWS Load Balancer パスをプロビジョニングします。 | | cert-manager.io | issuers、 certificates (コア watchで get、list、および を使用secrets) | フル アクセス | が なしで設定されている場合spec.tls、TLS 証明書を自動発行しますacmArn。 | | apiextensions.k8s.io | customresourcedefinitions | create、、get、patch、および は、リソース名によってゲートウェイが管理する特定の Gateway API CRDs updatedeleteに制限されます。 | ゲートウェイが依存するカスタムリソース定義をインストールします。 | **注記** の`create`動`customresourcedefinitions`詞は、特定のリソース名に制限されません。コントローラーは、ゲートウェイ API カスタムリソース定義をインストールします。このカスタムリソース定義は、合計サイズが Amazon EKS アドオンペイロードの制限を超えているため、独自のコンテナイメージから起動時に適用します。Kubernetes `create` では、動詞を名前付きリソースに制限できないため、このアクセス許可は必ずしも広範です。カスタムリソース定義に対する他のすべてのオペレーション -`get`、`update`、`patch`、および `delete`- は、ゲートウェイが管理する特定のカスタムリソース定義に制限されます。このアクセス許可により、これらの CRD タイプのみを定義できます。カスタムリソースのデータへのアクセスは許可されません。 また、コントローラーは、ゲートウェイの設定に応じて、実行時に次の名前空間ロールを作成します。 + *Body-Based Router* - LoRA アダプターを解決するためにルーターが読み取る `get`、`configmaps`、 `list`を `watch`に`Role`付与する名前空間。ルーターが複数の名前空間で実行される場合、これは`ClusterRole`代わりに です。 + *Endpoint Picker* — への読み取りアクセス`Role`を許可する名前空間`pods`。Endpoint Picker が複数のレプリカで実行されると、コントローラーは `leases`と `Role`のリーダー選択も作成します`events`。Prometheus メトリクスを有効にする`subjectaccessreviews`と、コントローラーは、`/metrics`エンドポイント`create`に対する `tokenreviews`および `ClusterRole`の読み取りアクセスを許可するオプションの を作成します。 **注記** HyperPod Inference Operator を介してゲートウェイを有効にすると、オペレーター独自のコントローラーは`InferenceGatewayConfig`リソースを作成および更新するアクセス許可を保持します。オペレーターがモデルをゲートウェイに接続する方法については、「」を参照してください[HyperPod Inference Operator との統合](#sagemaker-hyperpod-model-deployment-inference-gateway-operator-integration)。 これらのアクセス許可の一部は、対応する機能が有効になっている場合にのみ適用されます。 ## オブザーバビリティ Inference Gateway は、すべてのゲートウェイコンポーネントから Prometheus メトリクスを出力します。Body-Based Router と各 Endpoint Picker の両方が、ポッド上の標準の Prometheus `/metrics`エンドポイントを公開します。本文ベースのルーターポッドは `hyperpod-inference-system`名前空間で実行され、Endpoint Picker ポッドは と同じ名前空間で実行されます`InferenceGatewayConfig`。メトリクスは、モデルごとのリクエストカウンターと期間、Endpoint Picker 内のスケジューリングレイテンシーとプラグインごとの実行時間、平均 KV キャッシュ使用率やキュー深度などの集計プールメトリクスを対象としています。Model-server ポッドメトリクス (vLLM や SGLang など) は、モデルサーバー自体によって出力されます。Endpoint Picker はそれらをスクレイプして候補ポッドをスコアリングします。 `spec.observability.metrics.enabled` が `true` (デフォルト) の場合、ゲートウェイコントローラーは OpenTelemetry Collector サイドカーをすべての本文ベースのルーターおよびエンドポイントピッカーポッドに挿入します。サイドカーは、これらのメトリクスを HyperPod 推論オブザーバビリティスタックに転送します。このスタックでは、組み込みの Grafana ダッシュボードがモデルサーバーとクラスターのメトリクスとともに表示します。セットアップとダッシュボードの詳細については、「」を参照してください[HyperPod クラスターでの推論オブザーバビリティの実装](sagemaker-hyperpod-model-deployment-observability.md)。サイドカーインジェクションをスキップ`false`するには、 フィールドを に設定します。フィールドリファレンスについては、「」の`observability`「」を参照してください[仕様フィールド](#sagemaker-hyperpod-model-deployment-inference-gateway-spec)。 Amazon Managed Grafana でゲートウェイメトリクスを表示するには、*推論ダッシュボード*フォルダを開き、*推論ゲートウェイ*ダッシュボードを選択します。ダッシュボードには、各モデルのゲートウェイ全体の可用性、リクエストレート、end-to-endのレイテンシー、スケジューラごとのスループット、レイテンシー、エラー、およびボディベースルーターがリクエスト本文からモデル名を解決するレートがレポートされます。 ## 例 次の例は、一般的な`InferenceGatewayConfig`設定とゲートウェイを呼び出す方法を示しています。 ### 最小限のマルチモデル設定 この例では、TLS が自動発行された llm-d スケジューラにルーティングします。`tls` は空のオブジェクトに設定されているため、ゲートウェイは証明書を自動的に発行し、ACM にインポートします。 ``` apiVersion: inference.sagemaker.aws.amazon.com/v1alpha1 kind: InferenceGatewayConfig metadata: name: inference-gateway-demo namespace: inference-gateway spec: bbr: enabled: true tls: {} # Auto-issue a certificate via cert-manager and import to ACM. schedulers: - name: llama modelName: "meta-llama/Llama-3.2-1B-Instruct" modelSelector: matchLabels: app: vllm-llama targetPort: 8000 scheduler: llm-d ``` ### 明示的な重みを持つ SGLang スケジューラ この例では、`sglang`エンジンで ス`epp`ケジューラタイプを使用し、明示的な Endpoint Picker スコアリングの重みを設定します。 ``` spec: bbr: enabled: true schedulers: - name: qwen7b modelName: "Qwen/Qwen2.5-7B-Instruct" modelSelector: matchLabels: app: sglang-qwen7b targetPort: 8000 scheduler: epp engineType: sglang logLevel: 4 weights: kvCache: 2 prefix: 3 runningRequests: 2 ``` ### LoRA アダプター ConfigMap 本文ベースのルーターは、BBR 管理用にラベル付けされた ConfigMap から LoRA アダプターとそのベースモデルを検出します。ルーターはこのマッピングを使用して、リクエスト本文のアダプター名をベースモデルに解決します。 ``` apiVersion: v1 kind: ConfigMap metadata: name: deepseek-adapters labels: inference.networking.k8s.io/bbr-managed: "true" data: baseModel: deepseek/vllm-deepseek-r1 adapters: | - ski-resorts - movie-critique ``` ### ゲートウェイを呼び出す ゲートウェイは OpenAI 互換の推論エンドポイントを提供します。これは、ゲートウェイを介して推論リクエストを送信するためのランタイム呼び出し契約であり、 AWS API オペレーションではありません。`model` フィールドをターゲットスケジューラ`modelName`の に設定して、ゲートウェイエンドポイントにリクエストを送信します。本文ベースのルーターは、このフィールドを読み取り、リクエストをルーティングします。 ``` curl https://your-gateway-endpoint/v1/chat/completions \ -H "Content-Type: application/json" \ -d '{ "model": "meta-llama/Llama-3.1-8B-Instruct", "messages": [ {"role": "user", "content": "Hello"} ] }' ```