SageMaker HyperPod Inference v3.1、カスタムPod、証明書、Pod単位のリクエスト上限を解放

AWSは7月31日、SageMaker HyperPod Inference v3.1を登録した。主な変更はInference Operatorに集中しており、デプロイ担当者はカスタムKubernetes Pod設定の追加、独自証明書のマウント、各Podが受け付けられるリクエスト数の上限設定が可能になった。レプリカ数やエンドポイント層のトラフィックだけを調整する場合と比べ、Pod単位のレート制限ではモデルサーバーのキューをより直接的に制約できるため、長いプロンプト、生成長のばらつき、KV cacheへの負荷の急増によって、一部のレプリカに過剰な処理が蓄積するのを防げる。

カスタムPod仕様により、プラットフォームエンジニアはaffinity、toleration、sidecar、volume、セキュリティ関連の設定を追加し、推論ワークロードを指定したGPUノードに配置するとともに、既存のオブザーバビリティおよびネットワーク制御に統合できる。カスタム証明書は、企業PKI、プライベートモデルゲートウェイ、サービスメッシュを使用するクラスターで特に重要であり、Operatorの外部に別途TLS終端レイヤーを構築する必要性を減らせる。ただし、AWSの簡潔なリリースノートには、オーバーライド可能なすべてのフィールド、競合時のマージ規則、旧バージョンのリソースをアップグレードする際の挙動は記載されていない。また、Pod templateを任意に変更すると、Operatorのreconciliation loopによって互いの設定が上書きされる可能性もある。

エンジニアリングチームは、まず非本番クラスターで生成後のDeployment、Service、証明書ローテーションのフローを確認し、その後、異なるプロンプト長を使って、レート制限時の挙動がエラー応答、キューイング、再ルーティングのいずれになるかをテストすべきだ。次に注目すべき点は、v3.1が明確にバージョン管理されたCRDとローリングアップグレード保証を提供するか、またPod単位の上限がオートスケーリング、continuous batching、モデルサーバー自身のconcurrency設定と連携して動作できるかどうかである。