モデルの管理と監視

手順

1. OpenShift AI ダッシュボードから、Settings → Serving runtimes をクリックします。

   Serving runtimes ページが開き、すでにインストールされ有効になっているモデルサービングランタイムが表示されます。

2. カスタムランタイムを追加するには、次のオプションのいずれかを選択します。

   • 既存のランタイム (たとえば、vLLM NVIDIA GPU ServingRuntime for KServe) から開始するには、既存のランタイムの横にあるアクションメニュー (⋮) をクリックし、Duplicate をクリックします。
   • 新しいカスタムランタイムを追加するには、Add serving runtime をクリックします。
3. Select the model serving platforms this runtime supports リストで、Single-model serving platform を選択します。
4. Select the API protocol this runtime supports リストで、REST または gRPC を選択します。

5. オプション: (既存のランタイムを複製するのではなく) 新しいランタイムを開始した場合は、次のオプションのいずれかを選択してコードを追加します。

   • YAML ファイルをアップロードする

     1. Upload files をクリックします。

     2. ファイルブラウザーで、コンピューター上の YAML ファイルを選択します。

        埋め込み YAML エディターが開き、アップロードしたファイルの内容が表示されます。

   • エディターに YAML コードを直接入力する

     1. Start from scratch をクリックします。
     2. 埋め込みエディターに YAML コードを直接入力または貼り付けます。
   注記

   多くの場合、カスタムランタイムを作成するには、ServingRuntime 仕様の env セクションに新しいパラメーターまたはカスタムパラメーターを追加する必要があります。

6. Add をクリックします。

   Serving runtimes ページが開き、インストールされているランタイムの更新されたリストが表示されます。追加したカスタムランタイムが自動的に有効になることを確認します。ランタイム作成時に指定した API プロトコルが表示されます。

7. オプション: カスタムランタイムを編集するには、アクションメニュー (⋮) をクリックし、Edit を選択します。

手順

1. OpenShift コンソールにクラスター管理者としてログインします。
2. モデルをデプロイしたプロジェクトを選択します。
3. Administrator パースペクティブで、Home → Search をクリックします。
4. Resources ドロップダウンメニューから、InferenceService を検索します。

5. spec.predictor.annotations の下の serving.knative.dev/progress-deadline を新しいタイムアウトに変更します。

   apiVersion: serving.kserve.io/v1alpha1
   kind: InferenceService
   metadata:
     name: my-inference-service
   spec:
     predictor:
       annotations:
         serving.knative.dev/progress-deadline: 30m

   Copy to Clipboard Toggle word wrap
   注記

   必ず spec.predictor.annotations レベルで progress-deadline を設定して、KServe の InferenceService が progress-deadline を KNative Service オブジェクトにコピーできるようにしてください。

手順

1. ターミナルウィンドウで、クラスター管理者として OpenShift クラスターにまだログインしていない場合は、次の例に示すように OpenShift CLI にログインします。

   $ oc login <openshift_cluster_url> -u <admin_username> -p <password>

   Copy to Clipboard Toggle word wrap

2. モデルをデプロイするための namespace を選択または作成します。たとえば、kserve-demo namespace を作成するには、次のコマンドを実行します。

   oc new-project kserve-demo

   Copy to Clipboard Toggle word wrap

3. (PVC からモデルをデプロイする場合のみ) モデルをデプロイする namespace に、モデルストレージ用の PVC を作成します。Filesystem volumeMode を使用してストレージクラスを作成し、このストレージクラスを PVC に使用します。ストレージサイズは、ディスク上のモデルファイルのサイズよりも大きくする必要があります。以下に例を示します。

   注記

   PVC がすでに設定済みの場合、または OCI コンテナーイメージからモデルをデプロイする場合は、このステップをスキップできます。

   kubectl apply -f -
   apiVersion: v1
   kind: PersistentVolumeClaim
   metadata:
     name: granite-8b-code-base-pvc
   spec:
     accessModes:
       - ReadWriteMany
     volumeMode: Filesystem
     resources:
       requests:
         storage: <model size>
     storageClassName: <storage class>

   Copy to Clipboard Toggle word wrap

   1. 作成した PVC にモデルをダウンロードするための Pod を作成します。バケット名、モデルパス、および認証情報を使用してサンプル YAML を更新します。

      apiVersion: v1
      kind: Pod
      metadata:
        name: download-granite-8b-code
        labels:
          name: download-granite-8b-code
      spec:
        volumes:
          - name: model-volume
            persistentVolumeClaim:
              claimName: granite-8b-code-base-pvc
        restartPolicy: Never
        initContainers:
          - name: fix-volume-permissions
            image: quay.io/quay/busybox@sha256:92f3298bf80a1ba949140d77987f5de081f010337880cd771f7e7fc928f8c74d
            command: ["sh"]
            args: ["-c", "mkdir -p /mnt/models/$(MODEL_PATH) && chmod -R 777 /mnt/models"] 

      1

      
            volumeMounts:
              - mountPath: "/mnt/models/"
                name: model-volume
            env:
              - name: MODEL_PATH
                value: <model path> 

      2

      
        containers:
          - resources:
              requests:
                memory: 40Gi
            name: download-model
            imagePullPolicy: IfNotPresent
            image: quay.io/opendatahub/kserve-storage-initializer:v0.14 

      3

      
            args:
              - 's3://$(BUCKET_NAME)/$(MODEL_PATH)/'
              - /mnt/models/$(MODEL_PATH)
            env:
              - name: AWS_ACCESS_KEY_ID
                value: <id> 

      4

      
              - name: AWS_SECRET_ACCESS_KEY
                value: <secret> 

      5

      
              - name: BUCKET_NAME
                value: <bucket_name> 

      6

      
              - name: MODEL_PATH
                value: <model path> 

      7

      
              - name: S3_USE_HTTPS
                value: "1"
              - name: AWS_ENDPOINT_URL
                value: <AWS endpoint> 

      8

      
              - name: awsAnonymousCredential
                value: 'false'
              - name: AWS_DEFAULT_REGION
                value: <region> 

      9

      
              - name: S3_VERIFY_SSL
                value: 'true' 

      10

      
            volumeMounts:
              - mountPath: "/mnt/models/"
                name: model-volume

      Copy to Clipboard Toggle word wrap

      1

      chmod 操作は、Pod が root として実行されている場合にのみ使用できます。Pod を root として実行していない場合は、引数から `chmod -R 777` を削除します。

      2 7

      モデルへのパスを指定します。

      3

      InferenceService にある containers.image の値。この値にアクセスするには、oc get configmap inferenceservice-config -n redhat-ods-operator -oyaml | grep kserve-storage-initializer: のコマンドを実行します。

      4

      S3 バケットへのアクセスキー ID。

      5

      S3 バケットへのシークレットアクセスキー。

      6

      S3 バケットの名前。

      8

      S3 バケットへのエンドポイント。

      9

      AWS S3 バケットを使用する場合の S3 バケットのリージョン。ODF や Minio などの他の S3 互換ストレージを使用する場合は、AWS_DEFAULT_REGION 環境変数を削除できます。

      10

      SSL エラーが発生した場合は、S3_VERIFY_SSL を false に変更します。

4. プロジェクト namespace に vllm-multinode-runtime カスタムランタイムを作成します。

   oc process vllm-multinode-runtime-template -n redhat-ods-applications|oc apply -n kserve-demo -f -

   Copy to Clipboard Toggle word wrap

5. 次の InferenceService 設定を使用してモデルをデプロイします。

   apiVersion: serving.kserve.io/v1beta1
   kind: InferenceService
   metadata:
     annotations:
       serving.kserve.io/deploymentMode: RawDeployment
       serving.kserve.io/autoscalerClass: external
     name: <inference service name>
   spec:
     predictor:
       model:
         modelFormat:
           name: vLLM
         runtime: vllm-multinode-runtime
         storageUri: <storage_uri_path> 

   1

   
       workerSpec: {} 

   2

   Copy to Clipboard Toggle word wrap

   1

   デプロイ方法に応じてモデルへのパスを指定します。

   • PVC の場合: pvc://<pvc_name>/<model_path>
   • OCI コンテナーイメージの場合: oci://<registry_host>/<org_or_username>/<repository_name><tag_or_digest>

   2

   InferenceService には次の設定を追加できます。

   • workerSpec.tensorParallelSize: ノードごとに使用される GPU の数を決定します。ヘッドノードとワーカーノードのデプロイメントリソースの GPU タイプ数は、どちらも自動的に更新されます。workerSpec.tensorParallelSize の値は、必ず 1 以上にしてください。

   • workerSpec.pipelineParallelSize: デプロイメントでモデルのバランスをとるために使用されるノードの数を決定します。この変数は、ヘッドノードとワーカーノードの両方を含むノードの合計数を表します。workerSpec.pipelineParallelSize の値は、必ず 2 以上にしてください。実稼働環境では、この値は変更しないでください。

     注記

     お使いの環境およびモデルサイズに応じて、追加の引数を指定する必要がある場合があります。

6. InferenceService 設定を適用してモデルをデプロイします。

   oc apply -f <inference-service-file.yaml>

   Copy to Clipboard Toggle word wrap

1. OpenShift コンソールにログインします。
2. Administrator パースペクティブで、プロジェクトに移動し、モデルの InferenceService リソースを見つけます。
3. InferenceService の名前をクリックすると、詳細が表示されます。
4. YAML タブを選択してエディターを開きます。

5. metadata セクションで、labels の下に kueue.x-k8s.io/queue-name ラベルを追加します。<local-queue-name> は、ターゲットの LocalQueue の名前に置き換えます。

   apiVersion: serving.kserve.io/v1beta1
   kind: InferenceService
   metadata:
     name: <model-name>
     namespace: <project-namespace>
     labels:
       kueue.x-k8s.io/queue-name: <local-queue-name>
   ...

   Copy to Clipboard Toggle word wrap
6. Save をクリックします。

手順

1. ターミナルウィンドウで、以下の例のように、クラスター管理者として OpenShift CLI にログインします。

   oc login <openshift_cluster_url> -u <admin_username> -p <password>

   Copy to Clipboard Toggle word wrap

2. 次の例のような、NVIDIA NIM モデルサービスプラットフォームで選択できるようにするモデル ID を含む ConfigMap オブジェクトを YAML ファイルで定義します。

   apiVersion: v1
   kind: ConfigMap
   metadata:
    name: nvidia-nim-enabled-models
   data:
    models: |-
       [
       "mistral-nemo-12b-instruct",
       "llama3-70b-instruct",
       "phind-codellama-34b-v2-instruct",
       "deepseek-r1",
       "qwen-2.5-72b-instruct"
       ]

   Copy to Clipboard Toggle word wrap

3. Account CR の名前および namespace を確認します。

   oc get account -A

   Copy to Clipboard Toggle word wrap

   次の例のような出力が表示されます。

   NAMESPACE         NAME       TEMPLATE  CONFIGMAP  SECRET
   redhat-ods-applications  odh-nim-account

   Copy to Clipboard Toggle word wrap

4. ConfigMap オブジェクトを Account CR と同じ namespace にデプロイします。

   oc apply -f <configmap-name> -n <namespace>

   Copy to Clipboard Toggle word wrap

   <configmap-name> は YAML ファイルの名前に、<namespace> は Account CR の namespace に置き換えます。

5. 以前に作成した ConfigMap オブジェクトを、Account CR の spec.modelListConfig セクションに追加します。

   oc patch account <account-name> \
     --type='merge' \
     	-p '{"spec": {"modelListConfig": {"name": "<configmap-name>"}}}'

   Copy to Clipboard Toggle word wrap

   <account-name> は Account CR の名前に、<configmap-name> は ConfigMap オブジェクトに置き換えます。

6. ConfigMap オブジェクトが Account CR に追加されたことを確認します。

   oc get account <account-name> -o yaml

   Copy to Clipboard Toggle word wrap

   以下の出力のように、Account CR の spec.modelListConfig セクションに ConfigMap オブジェクトが表示されます。

   spec:
    enabledModelsConfig:
    modelListConfig:
     name: <configmap-name>

   Copy to Clipboard Toggle word wrap