アーキテクチャの検証

このソリューションに示すようなアーキテクチャをデプロイする場合は、次のトピックの基準に従ってアーキテクチャを検証する必要があります。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ポッドの両方で使用可能であることを確認するには、次の検証ステップを実行します。

両方のチェックが成功すると、NVIDIAデバイスプラグインアドオンが有効になっていることを確認し、追加のドライバ/ソフトウェアのインストールは必要ありません。
  1. ワーカー・ノードのGPU表示を確認します。次に例を示します。
    [opc@oke-cvxkfx3tnkq-nkteldpxwna-s3xcmkmmoda-0 ~]$ nvidia-smi -L
    GPU 0: NVIDIA A10 (UUID: GPU-eae0552a-e1d7-7c0f-dc39-886f4eafb439)
  2. TorchServeポッド内のGPUアクセスを確認します。次に例を示します。
    [opc@glvoicepoc-bastion guru]$ kubectl exec -it torchserve-7859b89965-rtqw9 -- /bin/bash
    model-server@torchserve-7859b89965-rtqw9:~$ nvidia-smi -L
    GPU 0: NVIDIA A10 (UUID: GPU-d6d1852e-6d04-59b9-10de-f68422638fb3)

設計モデル分布

.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とともに使用しています。
  1. モデルを登録します。たとえば、HTTPを介してTorchServeエンドポイントにアクセスできるリモート・クライアントから次のコマンドを実行して、.marファイルを1つの初期ワーカーに登録します。
    curl -X POST "http://10.0.20.160:8081/models?model_name=multispk_20250121_tts&url=multispk_20250121_tts.mar&initial_workers=1"
    
    Configure initial_workers per model demand.
    IP (10.0.20.160)およびポート(8081)は、TorchServe推論管理APIエンドポイントを参照します。
  2. モデルの登録を解除します。次に例を示します。
    curl -X DELETE "http://10.0.20.160:8081/models/multispk_20250121_tts"
  3. 就業者のスケール/追加たとえば、実行中のモデルのワーカー数を更新するには、次のようにします。
    curl -X PUT "http://10.0.20.160:8081/models/multispk_20250121_tts?min_worker=12"

テスト・パフォーマンス

パフォーマンス・テストで設計を検証します。

  1. クライアント・アプリケーションから、250の同時セグメントを送信します。キャプチャ:
    • p50/p95レイテンシ
    • スループット(セグメント/秒)
    • GPU使用率(nvidia-smi)
    • エンドツーエンドのジョブ完了時間
  2. ポッドから、次を実行します。
    kubectl exec -it <pod_name> -- nvidia-smi
  3. TorchServeメトリックAPI (ポート8082)から、次を実行します:
    curl http://10.0.20.160:8082/metrics

セキュリティとコストの最適化に関する考慮事項

設計を検証する際は、セキュリティおよびコスト最適化の要因を考慮してください。

  • セキュリティに関する考慮事項:
    • ロード・バランサまたはイングレスでTLS終了を強制します。
    • TorchServe管理APIは内部専用です。
    • OCI Identity and Access Managementおよびネットワーク・セキュリティ・グループを使用して、アクセスを制限します。
  • コスト最適化の考慮事項:
    • サービス・レベル契約(SLA)とコストとのバランスに基づいて、GPUタイプを選択します。
    • スケジュールされたスケーリングを使用します(非ピーク時間中にGPUノード・プールをスケール・ダウンします)。
    • モデルが更新される頻度が低い場合は、OCIファイル・ストレージOCIオブジェクト・ストレージを使用します。
    • 推論は、常に24×7を走るわけではありません。アイドル期間中に未使用のGPUをトレーニング・ワークロードと共有して、使用率を最大化し、コストを削減します。