すべてのプロダクト
Search
ドキュメントセンター

Alibaba Cloud Service Mesh:ASM および Fluid 上の KServe による AI モデルサービングの高速化

最終更新日:Mar 11, 2026

KServe(旧称 KFServing)は、クラウドネイティブ環境向けの AI モデルサービスおよび推論エンジンであり、自動スケーリング、スケールトゥーゼロ、カナリアデプロイをサポートします。Service Mesh (ASM) は、ACK または ACK Serverless クラスターにデプロイされた Knative Serving 機能を統合し、ワンクリックで KServe を統合できる「KServe on ASM」機能を提供します。Fluid は、ビッグデータや AI などのクラウドネイティブシナリオにおけるデータ集約型アプリケーション向けのオープンソース Kubernetes ネイティブ分散データセットオーケストレータおよびアクセラレータです。Fluid を「KServe on ASM」機能と直接統合することで、モデルロードを高速化できます。

このトピックでは、「KServe on ASM」と Fluid を統合し、Object Storage Service (OSS) をバックエンドとする AI 推論サービスをデプロイする手順を説明します。

仕組み

この統合では、以下の 3 つのコンポーネントが連携します。

  1. Fluid は、OSS バケットからモデルファイルをクラスターノードのローカル SSD ストレージにキャッシュします。JindoRuntime カスタムリソース (CR) が分散キャッシュを管理し、DataLoad CR が推論 Pod の起動前にデータをプリフェッチします。

  2. KServe on ASM は、永続ボリューム要求 (PVC) を介してキャッシュ済みデータを参照する InferenceService CR をデプロイします。推論コンテナは、OSS からダウンロードする代わりに、Fluid が管理するマウントポイントからモデルをロードします。

  3. Service Mesh (ASM) は、イングレスゲートウェイ経由でトラフィックを KServe 推論サービスにルーティングします。Knative Serving が自動スケーリングおよびスケールトゥーゼロを処理します。

リクエストが到着し、Knative がゼロから Pod をスケーリングする際、モデルはすでにローカルにキャッシュされています。そのため、Pod はリモートからのダウンロードなしに起動し、予測を提供できます。

前提条件

作業を開始する前に、以下の要件を満たしていることを確認してください。

Knative Serving コンポーネントのデプロイ

説明

Knative インストール時にゲートウェイとして Kourier を選択した場合、インストール完了後にアンインストールしてください。ACK コンソールで、クラスター をクリックし、アプリケーション > Knative を選択します。コンポーネント タブの アドオンコンポーネント セクションで、Kourier をアンインストールします。

Knative on ASM の有効化

  1. ASM コンソールにログインします。ASM コンソール の左側のナビゲーションウィンドウで、Service Meshメッシュ管理 を選択します。

  2. メッシュ管理 ページで、ASM インスタンスの名前をクリックします。左側のナビゲーションウィンドウで、エコシステム > Knative on ASM を選択します。

  3. Knative on ASM ページで、Knative on ASM の有効化 をクリックします。

説明

既存の ASM インスタンスを更新する場合は、「ASM インスタンスの更新」をご参照ください。

ステップ 1:KServe on ASM の有効化

  1. ASM コンソールにログインします。左側のナビゲーションウィンドウで、Service Mesh > メッシュ管理 を選択します。

  2. メッシュ管理 ページで、ASM インスタンスの名前をクリックします。左側のナビゲーションウィンドウで、エコシステム > KServe on ASM を選択します。

  3. KServe on ASM ページで、CertManager オプションを設定し、KServe on ASM の有効化 をクリックします。KServe は証明書のライフサイクル管理のために cert-manager に依存しています。CertManager コンポーネントは、KServe とともに自動的にインストールされます。

    • クラスターに CertManager がインストールされていない場合は、クラスターに CertManager コンポーネントを自動インストールする をオンにします。

    • クラスターに CertManager がすでにインストールされている場合は、クラスターに CertManager コンポーネントを自動インストールする をオフにします。

ステップ 2:Fluid のインストールとモデルキャッシュの設定

ack-fluid コンポーネントのインストール

データプレーンクラスターに ack-fluid コンポーネント(バージョン 0.9.10 以降)をデプロイします。

ACK クラスターの場合、クラウドネイティブ AI スイートをインストールし、ack-fluid コンポーネントをデプロイします。

  • クラウドネイティブ AI スイートがインストールされていない場合は、インストール時に Fluid アクセラレーション を有効にしてください。詳細については、「クラウドネイティブ AI スイートのデプロイ」をご参照ください。

  • クラウドネイティブ AI スイートがすでにインストールされている場合は、Container Service for Kubernetes コンソールにログインし、クラスターをクリックして、アプリケーション > クラウドネイティブ AI スイート を選択し、ack-fluid コンポーネントをデプロイします。

説明

ack-fluid コンポーネントをインストールする前に、オープンソース版 Fluid をアンインストールしてください。両者は共存できません。

ACK Serverless クラスターの場合、「ジョブの高速化」トピックの「Fluid のコントロールプレーンコンポーネントのデプロイ」セクションをご参照ください。

AI モデルの OSS へのアップロード

このチュートリアルでは、PyTorch ベースのオープンソーストランスフォーマー LLM である BLOOM-560m モデルを使用します。

  1. Hugging Face からモデルファイルをダウンロードします。

  2. ファイルをご利用の OSS バケットにアップロードし、ストレージパスを記録します。

    パスの形式は oss://<bucket>/<path> です。たとえば、バケットが fluid-demo で、ファイルが models/bloom ディレクトリにある場合、ストレージパスは oss://fluid-demo/models/bloom になります。

説明

ファイルのアップロードには ossutil を使用してください。詳細については、「ossutil のインストール」をご参照ください。

名前空間の作成と OSS アクセスの設定

  1. kubectl を使用してデータプレーンクラスターに接続します。詳細については、「kubectl を使用した ACK クラスターへの接続」をご参照ください。

  2. Fluid キャッシュおよび推論ワークロード用の名前空間を作成します。

       kubectl create ns kserve-fluid-demo
  3. 以下の内容で oss-secret.yaml という名前のファイルを作成します。

    以下のプレースホルダーを実際の値に置き換えてください。

    プレースホルダー説明
    <your-access-key-id>OSS アクセス権を持つ Alibaba Cloud アカウントの AccessKey IDLTAI5tXxx
    <your-access-key-secret>アカウントの AccessKey SecretxXxXxXx
       apiVersion: v1
       kind: Secret
       metadata:
         name: access-key
       stringData:
         fs.oss.accessKeyId: <your-access-key-id>       # OSS アクセス権を持つアカウントの AccessKey ID
         fs.oss.accessKeySecret: <your-access-key-secret> # アカウントの AccessKey Secret
  4. シークレットを適用します。

       kubectl apply -f oss-secret.yaml -n kserve-fluid-demo

Fluid でのモデルデータの宣言

Dataset CR および JindoRuntime CR を送信して、モデルデータを宣言します。Dataset はリモートストレージの場所を記述し、JindoRuntime はキャッシュシステムとその具体的な構成を設定します。

  1. 以下の内容で oss-jindo.yaml という名前のファイルを作成します。

    以下のプレースホルダーを実際の値に置き換えてください。利用可能なエンドポイントの一覧については、「リージョンとエンドポイント」をご参照ください。

    プレースホルダー説明
    <bucket>/<path>モデルファイルの OSS ストレージパスfluid-demo/models/bloom
    <endpoint>バケットが存在するリージョンの OSS エンドポイントoss-cn-hangzhou-internal.aliyuncs.com

    以下の表は、JindoRuntime 構成パラメーターの説明です。

    パラメーター説明
    replicas2キャッシュワーカーレプリカ数
    mediumtypeSSDローカルキャッシュのストレージメディア
    quota50Giワーカーノードごとの最大キャッシュ容量
    high / low0.95 / 0.7キャッシュエビクションのウォーターマーク(high でエビクションがトリガーされ、low がターゲット値)
    cleanPolicyOnDemandFuse サイドカーのクリーンアップポリシー

    oss-jindo.yaml を表示

       apiVersion: data.fluid.io/v1alpha1
       kind: Dataset
       metadata:
         name: oss-data
       spec:
         mounts:
         - mountPoint: "oss://<bucket>/<path>"  # モデルファイルのストレージパス
           name: bloom-560m
           path: /bloom-560m
           options:
             fs.oss.endpoint: "<endpoint>"      # ご利用のリージョンの OSS エンドポイント
           encryptOptions:
             - name: fs.oss.accessKeyId
               valueFrom:
                 secretKeyRef:
                   name: access-key
                   key: fs.oss.accessKeyId
             - name: fs.oss.accessKeySecret
               valueFrom:
                 secretKeyRef:
                   name: access-key
                   key: fs.oss.accessKeySecret
         accessModes:
           - ReadOnlyMany
       ---
       apiVersion: data.fluid.io/v1alpha1
       kind: JindoRuntime
       metadata:
         name: oss-data
       spec:
         replicas: 2
         tieredstore:
           levels:
             - mediumtype: SSD
               volumeType: emptyDir
               path: /mnt/ssd0/cache
               quota: 50Gi
               high: "0.95"
               low: "0.7"
         fuse:
           properties:
             fs.jindofsx.data.cache.enable: "true"
           args:
             - -okernel_cache
             - -oro
             - -oattr_timeout=7200
             - -oentry_timeout=7200
             - -ometrics_port=9089
           cleanPolicy: OnDemand
  2. Dataset および JindoRuntime をデプロイします。

       kubectl create -f oss-jindo.yaml -n kserve-fluid-demo
  3. デプロイメントを確認します。

       kubectl get jindoruntime,dataset -n kserve-fluid-demo

    期待される出力:

       NAME                                  MASTER PHASE   WORKER PHASE   FUSE PHASE   AGE
       jindoruntime.data.fluid.io/oss-data   Ready          Ready          Ready        3m
    
       NAME                             UFS TOTAL SIZE   CACHED   CACHE CAPACITY   CACHED PERCENTAGE   PHASE   AGE
       dataset.data.fluid.io/oss-data   3.14GiB          0.00B    100.00GiB        0.0%                Bound   3m

    Dataset の PHASEBound、JindoRuntime の FUSE PHASEReady と表示されれば、正常にデプロイされています。

モデルデータのプリフェッチ

プリフェッチにより、推論 Pod の起動前にモデルファイルがローカルキャッシュにロードされるため、Pod 起動時のリモートダウンロード遅延がなくなります。

  1. 以下の内容で oss-dataload.yaml という名前のファイルを作成します。

       apiVersion: data.fluid.io/v1alpha1
       kind: DataLoad
       metadata:
         name: oss-dataload
       spec:
         dataset:
           name: oss-data
           namespace: kserve-fluid-demo
         target:
           - path: /bloom-560m
             replicas: 2
  2. DataLoad をデプロイします。

       kubectl create -f oss-dataload.yaml -n kserve-fluid-demo
  3. プリフェッチの進捗を確認します。

       kubectl get dataload -n kserve-fluid-demo

    期待される出力:

       NAME           DATASET    PHASE      AGE     DURATION
       oss-dataload   oss-data   Complete   1m      45s

    次のステップに進む前に、PHASEComplete になるまで待ちます。

ステップ 3:推論サービスのデプロイ

  1. ご利用のクラスタータイプに応じた InferenceService 構成で oss-fluid-isvc.yaml という名前のファイルを作成します。

    ACK クラスター

       apiVersion: "serving.kserve.io/v1beta1"
       kind: "InferenceService"
       metadata:
         name: "fluid-bloom"
       spec:
         predictor:
           timeout: 600
           minReplicas: 0
           containers:
             - name: kserve-container
               image: registry.cn-hangzhou.aliyuncs.com/acs/kserve-fluid:bloom-gpu
               resources:
                 limits:
                   cpu: "12"
                   memory: 48Gi
                   nvidia.com/gpu: 1  # 必要な GPU 数。GPU を使用しない場合はこの行を削除してください。
                 requests:
                   cpu: "12"
                   memory: 48Gi
               env:
                 - name: STORAGE_URI
                   value: "pvc://oss-data/bloom-560m"
                 - name: MODEL_NAME
                   value: "bloom"
                 - name: GPU_ENABLED
                   value: "True"  # GPU を使用しない場合は "False" に設定してください。

    ACK Serverless クラスター

       apiVersion: "serving.kserve.io/v1beta1"
       kind: "InferenceService"
       metadata:
         name: "fluid-bloom"
         labels:
           alibabacloud.com/fluid-sidecar-target: "eci"
         annotations:
           k8s.aliyun.com/eci-use-specs: "ecs.gn6i-c16g1.4xlarge"  # ECS インスタンスタイプ
           knative.aliyun.com/reserve-instance-eci-use-specs: "ecs.gn6i-c16g1.4xlarge"  # ECS インスタンスタイプ
       spec:
         predictor:
           timeout: 600
           minReplicas: 0
           containers:
             - name: kserve-container
               image: registry.cn-hangzhou.aliyuncs.com/acs/kserve-fluid:bloom-gpu
               resources:
                 limits:
                   cpu: "12"
                   memory: 48Gi
                 requests:
                   cpu: "12"
                   memory: 48Gi
               env:
                 - name: STORAGE_URI
                   value: "pvc://oss-data/bloom-560m"
                 - name: MODEL_NAME
                   value: "bloom"
                 - name: GPU_ENABLED
                   value: "True"  # GPU を使用しない場合は "False" に設定してください。

    以下の表は、InferenceService パラメーターの説明です。

    パラメーター説明
    imageregistry.cn-hangzhou.aliyuncs.com/acs/kserve-fluid:bloom-gpuモデルロードおよび推論インターフェイスを備えたサンプルイメージ。カスタマイズする場合は、「KServe Fluid Docker サンプル
    STORAGE_URIpvc://oss-data/bloom-560mFluid 管理キャッシュを指す PVC ベースのストレージ URI
    MODEL_NAMEbloom予測 API エンドポイントで使用されるモデル名
    GPU_ENABLEDTrueGPU を使用しない場合は False に設定します。
    resources12 CPU、48 GiB メモリBLOOM-560m モデル用のリソース割り当て。モデルサイズおよびクラスター容量に応じて調整してください。
  2. 推論サービスをデプロイします。

       kubectl create -f oss-fluid-isvc.yaml -n kserve-fluid-demo
  3. デプロイメントを確認します。

       kubectl get inferenceservice -n kserve-fluid-demo

    期待される出力:

       NAME          URL                                                READY   PREV   LATEST   PREVROLLEDOUTREVISION   LATESTREADYREVISION           AGE
       fluid-bloom   http://fluid-bloom.kserve-fluid-demo.example.com   True           100                              fluid-bloom-predictor-00001   2d

    READYTrue と表示されれば、推論サービスが正常に動作しています。

ステップ 4:予測リクエストの送信

  1. ASM イングレスゲートウェイのアドレスを取得します。

    1. ASM コンソールにログインします。左側のナビゲーションウィンドウで、Service Mesh > メッシュ管理 を選択します。

    2. メッシュ管理 ページで、ASM インスタンスの名前をクリックします。左側のナビゲーションウィンドウで、ASM ゲートウェイ > イングレスゲートウェイ を選択します。

    3. ingressgatewayサービスアドレス セクションで、サービスアドレスをコピーします。

  2. テストリクエストを送信します。以下のコマンド中の <gateway-address> を、前のステップで取得したアドレスに置き換えてください。

       curl -v \
         -H "Content-Type: application/json" \
         -H "Host: fluid-bloom.kserve-fluid-demo.example.com" \
         "http://<gateway-address>:80/v1/models/bloom:predict" \
         -d '{"prompt": "It was a dark and stormy night", "result_length": 50}'

    期待される出力:

       *   Trying xxx.xx.xx.xx:80...
       * Connected to xxx.xx.xx.xx (xxx.xx.xx.xx) port 80 (#0)
       > POST /v1/models/bloom:predict HTTP/1.1
       > Host: fluid-bloom-predictor.kserve-fluid-demo.example.com
       > Content-Type: application/json
       >
       < HTTP/1.1 200 OK
       < content-type: application/json
       < server: istio-envoy
       <
       {
         "result": "It was a dark and stormy night, and the wind was blowing in the\ndirection of the west. The wind was blowing in the direction of the\nwest, and the wind was blowing in the direction of the west. The\nwind was"
       }

    200 OK 応答とともに生成されたテキストが返されれば、推論サービスが正常に動作しています。

クリーンアップ

このチュートリアルで作成したすべてのリソースを削除するには、以下のコマンドを順番に実行します。

kubectl delete inferenceservice fluid-bloom -n kserve-fluid-demo
kubectl delete dataload oss-dataload -n kserve-fluid-demo
kubectl delete dataset oss-data -n kserve-fluid-demo
kubectl delete jindoruntime oss-data -n kserve-fluid-demo
kubectl delete secret access-key -n kserve-fluid-demo
kubectl delete ns kserve-fluid-demo

次のステップ