すべてのプロダクト
Search

このプロダクト

    Container Service for Kubernetes:Knative での LLM サービスのデプロイとインテリジェントルーティングの実装

    ドキュメントセンター

    Container Service for Kubernetes:Knative での LLM サービスのデプロイとインテリジェントルーティングの実装

    最終更新日:Jun 21, 2026

    Gateway with Inference Extension コンポーネントは、Kubernetes Gateway API と Inference Extension 仕様に基づいて構築されており、Knative サーバーレスアーキテクチャと連携して、生成 AI 推論サービスの管理を簡素化します。複数の推論サービスワークロードに対して効率的なレイヤー 7 ルーティングと負荷分散を提供し、リクエストの同時実行数に基づいた GPU リソースの自動スケーリングを実現します。

    仕組み

    Gateway with Inference Extension は、AI 推論シナリオに対応するため、以下の CustomResourceDefinition (CRD) を使用して Gateway API を拡張します。

    • InferencePool：AI モデルサービスのリソースを論理的にグループ化します。同じコンピューティング設定、アクセラレータタイプ、ベースモデル、およびモデルサーバーを共有する Pod のセットを表します。InferencePool は、高可用性を実現するために複数のノードにまたがることができます。

    • InferenceObjective：モデルサービスの目標を定義し、InferencePool 内の Pod が提供するモデル名とその重要度レベルを指定します。Critical としてマークされたワークロードには、より高い処理優先度が付与されます。

    Knative では、AI ゲートウェイアノテーションを有効にすると、Knative Service がこれらの CRD を自動的に使用してインテリジェントなトラフィックスケジューリングを実行できるようになります。

    前提条件

    • 以下の要件を満たす ACK Managed Pro cluster を作成済みであること。

      • Knative がデプロイされていること。詳細については、「Knativeコンポーネントのデプロイと管理」をご参照ください。

      • Knative が ACS クラスターにデプロイされていること。詳細については、Knative をデプロイする を参照してください。

      • Gateway API Gateway API コンポーネントがインストールされていること。

      • バージョン v1.4.0-apsara.4 以降の推論拡張機能付きゲートウェイ推論拡張機能付きゲートウェイ コンポーネントがインストールされており、インストール時に [ゲートウェイ API 推論拡張機能を有効にする] を選択していること。

      • クラスターに GPU ノードが含まれており、各ノードに少なくとも 32 GiB のメモリがあること (このトピックでは Qwen1.5-4B を例として使用します)。ドライバーバージョンを指定するために、ノードに特定の[ノードラベル (Labels)] が必要です。[key] を ack.aliyun.com/nvidia-driver-version に、[value] を 550.144.03 に設定してください。

        GPU ノードのドライバーバージョンは 550.144.03 以降を推奨します。詳細については、「バージョン番号を指定してノードのGPUドライバーバージョンをカスタマイズする」をご参照ください。

      • Pod で GPU リソースをリクエストし、少なくとも 32 GiB のメモリを確保する必要があります (このトピックでは Qwen1.5-4B を例として使用します)。ドライバーバージョンは、Pod ラベル (labels) を使用して指定する必要があります。key を alibabacloud.com/gpu-driver-version に、value を 550.144.03 に設定してください。ドライバーバージョンは 550.144.03 以降を推奨します。詳細については、「ACS GPU PodのGPUモデルとドライバーバージョンを指定する」をご参照ください。

    • Object Storage Service (OSS) バケットを作成済みであること。

      クロスリージョンのデータ転送料金を回避し、レイテンシを削減するために、クラスターと同じリージョンを選択することを推奨します。

    ステップ 1: Knative での Gateway API サポートの有効化

    Knative ネットワーク設定を変更して、Gateway API を Ingress コントローラーとして指定します。

    1. config-network ConfigMap を編集します。

      kubectl edit configmap config-network -n knative-serving

    2. data フィールドで ingress.class を変更し、変更を保存します。

      apiVersion: v1
data:
  ...
  # ingress.class を変更して、Gateway API を Ingress コントローラーとして使用します。
  ingress.class: gateway-api.ingress.networking.knative.dev 
  ...
kind: ConfigMap
metadata:
  name: config-network
  namespace: knative-serving
  ...

    3. 変更が反映されたことを確認します。

      kubectl get configmap config-network -n knative-serving -o yaml | grep "ingress.class"

      想定される出力：

        ingress.class: gateway-api.ingress.networking.knative.dev

    ステップ 2: 推論 Gateway リソースの作成

    外部リクエストをリッスンする Gateway リソースを作成します。この例では、Gateway がポート 8888 でリッスンするように設定します。

    1. Gateway 設定ファイル knative-gateway.yaml を作成します。

      kind: Gateway
apiVersion: gateway.networking.k8s.io/v1
metadata:
  name: knative-gateway
  namespace: knative-serving
spec:
  gatewayClassName: ack-gateway
  listeners:
  - name: default
    port: 80
    protocol: HTTP
    allowedRoutes:
      namespaces:
        from: All
  - name: llm-gw
    protocol: HTTP
    # 推論サービスがリッスンするポート。
    port: 8888  
    allowedRoutes:
      namespaces:
        from: All

    2. Gateway リソースをデプロイします。

      kubectl apply -f knative-gateway.yaml

    3. Gateway のステータスを確認します。

      kubectl get gateway knative-gateway -n knative-serving

      出力で、PROGRAMMED が True であり、ADDRESS フィールドに IP アドレスが割り当てられていることを確認してください。

      NAME              CLASS         ADDRESS        PROGRAMMED   AGE
knative-gateway   ack-gateway   47.XX.XX.198   True         22s

    ステップ 3: モデルデータの準備とストレージの設定

    コンテナが起動するたびにモデルを再ダウンロードするのを避けるため、OSS 静的ボリュームを使用してモデルデータを保存およびマウントすることを推奨します。

    1. モデルのダウンロードと OSS へのアップロード

    このステップでは、Qwen1.5-4B-Chat モデルを例として使用します。モデルデータを準備するために一時的に Elastic Compute Service (ECS) インスタンスを購入し、完了後に リリースすることができます。

    1. モデルをローカルディレクトリにダウンロードします。

      # Git LFS をインストール
sudo yum install -y git git-lfs
git lfs install
# モデルリポジトリをクローン (smudge をスキップして高速化)
GIT_LFS_SKIP_SMUDGE=1 git clone https://www.modelscope.cn/qwen/Qwen1.5-4B-Chat.git
# 実際の大きなファイルをダウンロード
cd Qwen1.5-4B-Chat
git lfs pull

    2. ossutil を使用して、モデルを OSS バケットにアップロードします。

      <Bucket-Name> を実際の OSS バケット名に置き換えてください。

      ossutil のインストールについては、「ossutilのインストール」をご参照ください。
      # ディレクトリを作成します。
ossutil mkdir oss://<Bucket-Name>/models/Qwen1.5-4B-Chat
# ファイルを再帰的にアップロードします (-r は再帰的アップロードを示します)。
ossutil cp -r ./ oss://<Bucket-Name>/models/Qwen1.5-4B-Chat

    2. PV と PVC の設定

    モデルの読み込みパフォーマンスを向上させるため、この例では OSS 静的ボリュームを作成します。詳細な手順については、「ossfs 1.0 静的ボリュームの使用OSS 静的ボリュームの使用」をご参照ください。

    1. OSS アクセス認証情報 (Secret) を作成します。

      <AccessKey-ID> と <AccessKey-Secret> を実際の情報に置き換えてください。

      kubectl create secret generic oss-secret \
  --from-literal=akId='<AccessKey-ID>' \
  --from-literal=akSecret='<AccessKey-Secret>' \
  --namespace default

    2. ファイル oss-storage.yaml を作成します。

      apiVersion: v1
kind: PersistentVolume
metadata:
  name: llm-model
  labels:
    alicloud-pvname: llm-model
spec:
  capacity:
    storage: 30Gi
  # アクセスモード
  accessModes:
    - ReadWriteMany            
  persistentVolumeReclaimPolicy: Retain
  storageClassName: oss
  csi:
    driver: ossplugin.csi.alibabacloud.com
    volumeHandle: llm-model
    # Secret オブジェクトから AccessKey 情報を取得します。
    nodePublishSecretRef:
      name: oss-secret
      namespace: default
    volumeAttributes:
      # 実際の OSS バケット名に置き換えてください。
      bucket: "<Your-Bucket-Name>"         
      # バケットのリージョンの内部エンドポイント。
      url: "http://oss-cn-hangzhou-internal.aliyuncs.com" 
      # OSS 内の相対パス。
      path: "/models/Qwen1.5-4B-Chat"     
---
apiVersion: v1
kind: PersistentVolumeClaim
metadata:
  name: llm-model
  namespace: default
spec:
  accessModes:
    - ReadWriteMany
  storageClassName: oss
  resources:
    requests:
      # リクエストされるストレージサイズ。ボリュームの合計サイズを超えることはできません。
      storage: 30Gi
  selector:
    matchLabels:
      # このラベルを使用して PV を選択します。
      alicloud-pvname: llm-model

    3. PV と PVC をデプロイします。

      kubectl apply -f oss-storage.yaml

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

    Knative Service を作成し、AI ゲートウェイ機能を有効にして、推論用の vLLM エンジンを設定します。

    1. サービス設定ファイル qwen-service.yaml を作成します。

      主要な設定：

      • knative.aliyun.com/ai-gateway: inference：推論ゲートウェイ拡張を有効にします。

      • autoscaling.knative.dev/metric: "concurrency"：同時実行リクエスト数に基づいて自動スケーリングします。

      apiVersion: serving.knative.dev/v1
kind: Service
metadata:
  name: qwen
  namespace: default
  annotations:
    # AI 推論ゲートウェイを有効にします。
    knative.aliyun.com/ai-gateway: inference          
    knative.aliyun.com/ai-gateway-inference-priority: "1"
  labels:
    release: qwen
spec:
  template:
    metadata:
      annotations:
        # 自動スケーリングメトリック：同時実行数。
        autoscaling.knative.dev/metric: "concurrency" 
        # ターゲット同時実行数。
        autoscaling.knative.dev/target: "2"           
        # インスタンスの最大数。
        autoscaling.knative.dev/max-scale: "3"        
        # インスタンスの最小数。大規模モデルでは、コールドスタート時のリクエストタイムアウトを回避するため、最小値を 1 にすることを推奨します。
        autoscaling.knative.dev/min-scale: "1"        
      labels:
        release: qwen
    spec:
      containers:
      - name: vllm-container
        image: ac2-registry.cn-hangzhou.cr.aliyuncs.com/ac2/vllm:0.4.1-ubuntu22.04
        command:
        - sh
        - -c
        - python3 -m vllm.entrypoints.openai.api_server --port 8080 --trust-remote-code --model /models/Qwen1.5-4B-Chat/ --gpu-memory-utilization 0.95 --max-model-len 8192 --dtype half
        ports:
        - containerPort: 8080
        readinessProbe:
          tcpSocket:
            port: 8080
          initialDelaySeconds: 15
          periodSeconds: 5
        resources:
          limits:
            cpu: "32"
            memory: 64Gi
            # GPU リソースをリクエストします。
            nvidia.com/gpu: "1" 
          requests:
            cpu: "8"
            memory: 32Gi
            nvidia.com/gpu: "1"
        volumeMounts:
        # マウントパスは、起動コマンドのモデルパラメータと一致する必要があります。
        - mountPath: /models/Qwen1.5-4B-Chat 
          name: llm-model
      volumes:
      - name: llm-model
        persistentVolumeClaim:
          claimName: llm-model

    2. サービスをデプロイします。

      kubectl apply -f qwen-service.yaml

    3. デプロイの進行状況を確認します (Ready が True になるまで待ちます)。

      kubectl get ksvc qwen -n default

    ステップ 5: 推論サービスの検証

    サービスがデプロイされたら、Gateway の IP アドレスを使用して推論 API にアクセスします。

    1. Gateway の IP アドレスを取得します。

      export GATEWAY_HOST=$(kubectl -n knative-serving get gateway/knative-gateway -o jsonpath='{.status.addresses[0].value}')
echo "Gateway IP address: $GATEWAY_HOST"

    2. テストリクエストを送信します。

      このステップでは、OpenAI 形式のチャットリクエストをシミュレートします。

      curl http://${GATEWAY_HOST}:8888/v1/chat/completions \
  -H "Host: qwen.default.example.com" \
  -H "Content-Type: application/json" \
  -d '{
    "model": "/models/Qwen1.5-4B-Chat/",
    "messages": [
      {"role": "user", "content": "Explain Kubernetes in one sentence."}
    ],
    "max_tokens": 50
  }'

      ターミナルには choices フィールドを含む JSON データが返され、その content にモデルの応答が含まれています。

    課金

    Knative コンポーネント自体には追加料金は発生しません。ただし、サービスが使用するクラウドリソース (コンピューティング、ネットワーキング、ストレージなど) に対して料金が請求されます。

    • GPU インスタンス：GPU インスタンスは高額です。コストを管理するため、ノードスケーリングと組み合わせて使用することを推奨します。

    • OSS：OSS ストレージとリクエストの料金が発生します。パブリックアクセスが含まれる場合、送信トラフィック料金も発生します。

    • Server Load Balancer (SLB)：Gateway に関連付けられた公開ロードバランサーインスタンスには、トラフィック料金が発生します。

    詳細については、「クラウド製品リソース料金料金」をご参照ください。

    関連ドキュメント

    Knative は、A2A や MCP Server などの他のサービスのデプロイもサポートしています。これにより、オンデマンドスケーリングやイベント駆動パターンなどのサーバーレスのメリットを、他の高度な AI サービスに適用できます。