アーキテクチャの検証
このソリューションに示すようなアーキテクチャをデプロイする場合は、次のトピックの基準に従ってアーキテクチャを検証する必要があります。GPUの選択、クラスタの設定、配布とデプロイメント、自動スケーリング、パフォーマンス・テスト、セキュリティ、コストを考慮してください。
GPUの選択
GPUを利用した推論サービスを導入して、テキスト・セグメントを音声に変換し、パフォーマンス、スケーラビリティおよびコスト効率を確保する必要があります。GPUモデル(A10、A100、L40S)を評価して、ユース・ケースに最適なモデルを決定できます。
ベンチマーク・テストは、様々なGPUタイプで実行できます。次の表に、テンプレートを示します。XおよびYの値を入力し、そのデータを使用して実績と原価を比較します。
GPUタイプ | 平均レイテンシ(/250セグメント) | スループット(セグメント/秒) | ノート |
---|---|---|---|
A10 | Xミリ秒 | Y | 開発/テストに適した低コスト |
A100 | Xミリ秒 | Y | 高パフォーマンス、高コスト |
L40S | Xミリ秒 | Y | 価格/パフォーマンス間の良好なバランス |
- 推奨事項: ワークロード・サイズ、SLAレイテンシ要件および予算に基づいてGPUを選択します。
- 最適化: 待機時間を短縮するために、FP16/混合精度(サポートされている場合)で実行します。
OKEクラスタの設計
デプロイメントにあわせてOKEクラスタを設計します。
この例では、2つのノード・プールを持つクラスタ設定を使用します。
- NodePool 1 (CPUノード): UI、ワーカー、RabbitMQおよび内部DBを実行します
- NodePool 2 (GPUノード): TorchServe推論ポッドを実行します
GPUノードで十分なBVを確認します。
ノード・プールにラベルを付けます。
- CPUノード上の
nodepool=cpu
- GPUノード上の
nodepool-gpu
およびnvidia.com/gpu.present=true
OKE NVIDIAデバイス・プラグイン・アドオンがGPUノードで有効になっており、nvidia-smi
が機能していることを確認します。
GPUの検証
GPUがOKEノードとTorchServeポッドの両方で使用可能であることを確認するには、次の検証ステップを実行します。
設計モデル分布
.mar
モデルを推論ポッドで使用できるようにするには、2つのオプションがあります。
- コンテナ・ストレージ・インタフェース(CSI)ドライバを使用して、OCIオブジェクト・ストレージ・バケットを永続ボリューム要求(PVC)として使用します。
- Secure Copy Protocol (SCP)を使用してモデルをOCI File Storageに転送し、ファイルシステムをPVCのマウント・ポイントとして使用します。たとえば:
scp -i /path/to/private_key /path/to/local/model.mar opc@<file_storage_instance_ip>:/path/to/destination/mount/point/models/
簡略化にはOCI Object Storageを、頻繁に更新される複数のモデルがある場合はOCI File Storageを推奨します。
TorchServeのデプロイ
TorchServeをデプロイする方法を検証します。
次のYAMLファイルには、デプロイメントおよび構成の例が示されています。
- OCIロード・バランシング(OKEからTorchServeポッドへのイングレス)を使用して公開します。
- ロード・バランサでTLSを使用して保護します。
-
TorchServe管理ポート(8081)をパブリック・インターネットに公開しないでください。
ノート:
- 実際のTorchServeコンテナの場所およびバージョンを指すように、コンテナ
image:
文を変更します。 multispk_20250121_tts
は、ここで例として使用するカスタム・モデル名です。独自のモデルの名前および.mar
ファイルで置換できます。
トーチサーブ-deployment.yaml
apiVersion: apps/v1
kind: Deployment
metadata:
name: torchserve
labels:
app: torchserve
spec:
replicas: 1
selector:
matchLabels:
app: torchserve
template:
metadata:
labels:
app: torchserve
spec:
nodeSelector:
nodepool: torchserve
tolerations:
- key: "nvidia.com/gpu"
operator: "Exists"
effect: "NoSchedule"
imagePullSecrets:
- name: ocir-creds
containers:
- name: torchserve
image: ocir.<your-region>.oci.oraclecloud.com/<tenancy-namespace>/<torchserve_image>:<version>
ports:
- containerPort: 8080
- containerPort: 8081
- containerPort: 8082
- containerPort: 7070
- containerPort: 7071
env:
- name: GPUS__DEVICES
value: "0"
- name: METRICS_MODE
value: "logical" # or "endpoint"
- name: ENABLE_METRICS_API
value: "true"
resources:
limits:
nvidia.com/gpu: 1
volumeMounts:
- name: models-volume
mountPath: /home/model-server/model-store
volumes:
- name: models-volume
persistentVolumeClaim:
claimName: fss-voiceengine-models
configmap - torchserve.yaml
apiVersion: v1
kind: ConfigMap
metadata:
name: config-properties
namespace: default # Adjust the namespace as necessary
data:
config.properties: |
inference_address=http://0.0.0.0:8080
management_address=http://0.0.0.0:8081
metrics_address=http://0.0.0.0:8082
number_of_netty_threads=32
job_queue_size=1000
model_store=/home/model-server/model-store
workflow_store=/home/model-server/wf-store
install_py_dep_per_model=true
max_request_size=196605000
max_response_size=196605000
default_workers_per_model=1
job_queue_size=100
metrics_mode=logical
load_models=/home/model-server/model-store/multispk_20250121_tts.mar
自動スケーリングの設定
ポッドおよびワーカー・レベルで自動スケーリングを設定します。
Kubernetesイベント駆動型Autoscaler (KEDA)とPrometheusメトリックを使用してポッド・レベルで自動スケーリングを設定し、リクエスト・キューの深さ、カスタム・メトリックまたはCPU/GPU使用率に基づいてTorchServeポッドをスケーリングします。
ワーカー・レベルの自動スケーリング(TorchServe)を設定します。
ノート:
次の例では、TorchServeモデル・ライフサイクルをmultispk_20250121_tts
とともに使用しています。
セキュリティとコストの最適化に関する考慮事項
設計を検証する際は、セキュリティおよびコスト最適化の要因を考慮してください。
- セキュリティに関する考慮事項:
- ロード・バランサまたはイングレスでTLS終了を強制します。
- TorchServe管理APIは内部専用です。
- OCI Identity and Access Managementおよびネットワーク・セキュリティ・グループを使用して、アクセスを制限します。
- コスト最適化の考慮事項:
- サービス・レベル契約(SLA)とコストとのバランスに基づいて、GPUタイプを選択します。
- スケジュールされたスケーリングを使用します(非ピーク時間中にGPUノード・プールをスケール・ダウンします)。
- モデルが更新される頻度が低い場合は、OCIファイル・ストレージでOCIオブジェクト・ストレージを使用します。
- 推論は、常に24×7を走るわけではありません。アイドル期間中に未使用のGPUをトレーニング・ワークロードと共有して、使用率を最大化し、コストを削減します。