すべてのプロダクト
Search

このプロダクト

    Container Service for Kubernetes:AI 推論ゲートウェイを使用した LLM サービスのデプロイとスマートルーティングの実装

    ドキュメントセンター

    Container Service for Kubernetes:AI 推論ゲートウェイを使用した LLM サービスのデプロイとスマートルーティングの実装

    最終更新日:Mar 01, 2026

    ACK Gateway with Inference Extension コンポーネントは、Kubernetes Gateway API と Inference Extension 仕様に基づいて構築されています。このソリューションは、Knative サーバーレスアーキテクチャと組み合わせることで、生成 AI 推論サービスの管理を簡素化します。複数の推論サービスワークロードにまたがる効率的なレイヤー 7 ルーティングと負荷分散をサポートし、リクエストの同時実行数に基づいた GPU リソースの弾性スケーリングを可能にします。

    仕組み

    Gateway with Inference Extension は、以下のカスタムリソース定義 (CRD) を使用して、AI 推論シナリオ向けに Gateway API の機能を拡張します。

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

    • InferenceObjective： モデルサービスのプロパティと目標を定義します。InferencePool 内の Pod が提供するモデル名とその重要度レベルを指定します。Critical とマークされたワークロードは優先的に処理されます。

    Knative では、AI ゲートウェイアノテーションを有効にすることで、Knative Service がこれらの機能と自動的に統合され、インテリジェントなトラフィックスケジューリングが実現します。

    事前準備

    • 以下の要件を満たす ACK Pro マネージドクラスターを作成済みであること。

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

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

      • バージョン v1.4.0-apsara.4 以降の Gateway with Inference Extension コンポーネントがインストールされていること。コンポーネントをインストールする際に、[Gateway API Inference Extension を有効にする] を選択してください。

      • クラスターに、ノードあたり 32 GiB 以上のメモリを持つ GPU ノードが含まれていること。このトピックでは、Qwen1.5-4B モデルを例として使用します。ノードラベル (Labels) を使用してノードに特定のラベルを追加し、ドライバーバージョンを指定します。[キー] を ack.aliyun.com/nvidia-driver-version に、[値] を 550.144.03 に設定します。

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

    • 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
  ...

      image

    3. 変更が有効になったか確認します。

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

      期待される出力：

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

    ステップ 2: 推論ゲートウェイリソースの作成

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

    1. 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. ゲートウェイリソースをデプロイします。

      kubectl apply -f knative-gateway.yaml

    3. ゲートウェイのステータスを確認します。

      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 静的永続ボリュームの使用」をご参照ください。

    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:
        # スケーリングメトリック：concurrency。
        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:
        # マウントパスは、起動コマンドの model パラメーターと同じでなければなりません。
        - 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: 推論サービスの検証

    サービスがデプロイされた後、ゲートウェイアドレスを通じて推論 API にアクセスします。

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

      export GATEWAY_HOST=$(kubectl -n knative-serving get gateway/knative-gateway -o jsonpath='{.status.addresses[0].value}')
echo "Gateway 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": "Describe Kubernetes in one sentence."}
    ],
    "max_tokens": 50
  }'

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

    課金

    Knative コンポーネント自体に追加料金は発生しません。ただし、使用されるコンピューティングリソース、ネットワークリソース、その他のリソースの料金は、それぞれのクラウド製品によって課金されます。例：

    • GPU インスタンス： GPU インスタンスは高価です。ノードの自動スケーリングと併用してコストを管理してください。

    • OSS： これにはストレージ料金とリクエスト料金が含まれます。パブリックネットワークアクセスが関わる場合、インターネットへのアウトバウンドトラフィック料金も発生します。

    • Server Load Balancer (SLB)： ゲートウェイにアタッチされたインターネット向け SLB インスタンスにはトラフィック料金が発生します。

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

    関連ドキュメント

    Knative に A2A をデプロイし、MCP Server をデプロイすることで、そのサーバーレスアーキテクチャを活用できます。これにより、AI サービスに対してオンデマンドスケーリングやイベント駆動型実行などの高度な機能を実現できます。