2.10. KServe デプロイメントモードについて
モデルは、advanced または standard デプロイメントモードのいずれかでデプロイできます。
advanced デプロイメントモードでは、Knative Serverless が使用されます。デフォルトでは、KServe は Red Hat OpenShift Serverless および Red Hat OpenShift Service Mesh と統合され、シングルモデルサービングプラットフォームにモデルをデプロイします。Red Hat Serverless はオープンソースの Knative プロジェクトに基づいており、Red Hat OpenShift Serverless Operator が必要です。
または、KServe RawDeployment モードを使用し、Red Hat OpenShift Serverless Operator、Red Hat OpenShift Service Mesh、または Authorino を必要としない standard デプロイメントモードを使用することもできます。
KServe を advanced デプロイメントモードに設定すると、advanced および standard のデプロイメントモードでモデルを提供するようにデータサイエンスプロジェクトを設定できます。しかし、KServe を standard デプロイメントモードのみに設定した場合は、standard デプロイメントモードしか使用できません。
これらの各デプロイメントモードには、それぞれメリットとデメリットがあります。
2.10.1. advanced モード リンクのコピーリンクがクリップボードにコピーされました!
メリット:
リクエスト量に基づいて自動スケーリングを有効にします。
- 着信リクエストを受信すると、リソースは自動的にスケールアップされます。
- リソースの使用を最適化し、ピーク時のパフォーマンスを維持します。
Knative を使用してゼロへのスケールダウンとゼロからのスケールダウンをサポートします。
- 着信リクエストがない場合にリソースを完全にスケールダウンできます。
- アイドル状態のリソースを実行しないことでコストを節約します。
デメリット:
カスタマイズの制限があります。
- Serverless は Knative によってサポートされており、複数のボリュームをマウントする場合など、同じ設計上の選択を暗黙的に継承します。
スケーリン用に Knative に依存します。
- 従来のスケーリング方法と比較して、セットアップと管理がさらに複雑になります。
クラスタースコープのコンポーネント:
- クラスターに Serverless がすでに設定されている場合は、OpenShift AI で動作するようにクラスターを手動で設定する必要があります。
2.10.2. standard モード リンクのコピーリンクがクリップボードにコピーされました!
メリット:
Red Hat Serverless、Red Hat Service Mesh、Authorino などの追加の依存関係なしで、
Deployment
、Service
、Route
、Horizontal Pod Autoscaler
などの Kubernetes リソースを使用したデプロイメントを可能にします。- 結果として得られるモデルのデプロイメントでは、advanced モードと比較してリソースフットプリントが小さくなります。
複数のボリュームのマウントなど、Knative では利用できない従来の Deployment/Pod 構成を使用できるようにします。
- 複雑な設定や複数のストレージマウントを必要とするアプリケーションに役立ちます。
デメリット:
自動スケーリングはサポートされていません。
- アイドル時にリソースを自動的にゼロにスケールダウンすることはサポートされていません。
- トラフィックが少ない期間にはコストが高くなる可能性があります。