Deploy LLM services and implement intelligent routing in Knative - Container Service for Kubernetes

El componente Gateway with Inference Extension se basa en la Kubernetes Gateway API y en la especificación Inference Extension. Este componente trabaja con la arquitectura serverless de Knative para simplificar la gestión de los servicios de inference de IA generativa. Proporciona un enrutamiento eficiente en la capa 7 y balanceo de carga entre varios workloads de servicios de inference. Además, permite el escalado automático de recursos de GPU según la concurrencia de solicitudes.

Funcionamiento

Gateway with Inference Extension amplía la Gateway API para escenarios de inference de IA mediante las siguientes CustomResourceDefinitions (CRD).

InferencePool: agrupa lógicamente los recursos de los servicios de modelos de IA. Representa un conjunto de Pods que comparten la misma configuración de cómputo, tipo de acelerador, modelo base y servidor de modelos. Un InferencePool puede abarcar varios nodos para proporcionar alta disponibilidad.
InferenceObjective: define los objetivos de un servicio de modelos. Especifica el nombre del modelo que atienden los Pods de un InferencePool y su nivel de criticidad. Los workloads marcados como Critical reciben mayor prioridad de procesamiento.

En Knative, al habilitar la anotación de gateway de IA, un Knative Service utiliza automáticamente estas CRD para programar el tráfico de forma inteligente.

Requisitos previos

Creó un clúster ACK Managed Pro que cumple con los siguientes requisitos:
- Knative está desplegado. Para más información, consulte Deploy and manage Knative components.
- El componente Gateway API está instalado.
- El componente Gateway with Inference Extension versión v1.4.0-apsara.4 o posterior está instalado, y seleccionó Enable Gateway API Inference Extension durante la instalación.
- El clúster contiene nodos GPU, cada uno con como mínimo 32 GiB de memoria (este tema usa Qwen1.5-4B como ejemplo). Se requiere una Node Labels específica en los nodos para especificar la versión del controlador: establezca la key como ack.aliyun.com/nvidia-driver-version y el value como 550.144.03.
  
  Se recomienda usar la versión 550.144.03 o posterior del controlador de los nodos GPU. Para más información, consulte Customize the GPU driver version of a node by specifying a version number.
created an OSS Bucket.

Se recomienda elegir la misma región que la de su clúster. Así evitará cargos por transferencia de datos entre regiones y reducirá la latencia.

Paso 1: Habilitar la compatibilidad con Gateway API en Knative

Modifique la configuración de red de Knative para especificar la Gateway API como controlador Ingress.

Edite el ConfigMap config-network.

kubectl edit configmap config-network -n knative-serving

En el campo data, modifique ingress.class y guarde los cambios.

apiVersion: v1
data:
  ...
  # Modify ingress.class to use the Gateway API as the Ingress controller.
  ingress.class: gateway-api.ingress.networking.knative.dev 
  ...
kind: ConfigMap
metadata:
  name: config-network
  namespace: knative-serving
  ...

Compruebe que el cambio surtió efecto.

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

Resultado esperado:

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

Paso 2: Crear un recurso de gateway de inference

Cree un recurso Gateway para escuchar solicitudes externas. En este ejemplo se configura el gateway para que escuche en el puerto 8888.

Cree el archivo de configuración del 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
    # The port that the inference service listens on.
    port: 8888  
    allowedRoutes:
      namespaces:
        from: All

Despliegue el recurso de gateway.
```
kubectl apply -f knative-gateway.yaml
```

Compruebe el estado del gateway.

kubectl get gateway knative-gateway -n knative-serving

En el resultado, asegúrese de que PROGRAMMED sea True y de que se haya asignado una dirección IP en el campo ADDRESS.

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

Paso 3: Preparar los datos del modelo y configurar el almacenamiento

Para evitar descargar el modelo cada vez que se inicia un contenedor, se recomienda usar un volumen estático de OSS para almacenar y montar los datos del modelo.

1. Descargar el modelo y cargarlo en OSS

Este paso usa el modelo Qwen1.5-4B-Chat como ejemplo. Puede purchase an ECS instance temporalmente para preparar los datos del modelo y release cuando termine.

Descargue el modelo en un directorio local.

# Install Git LFS
sudo yum install -y git git-lfs
git lfs install
# Clone the model repository (skip smudge to speed up)
GIT_LFS_SKIP_SMUDGE=1 git clone https://www.modelscope.cn/qwen/Qwen1.5-4B-Chat.git
# Download the actual large files
cd Qwen1.5-4B-Chat
git lfs pull

Use ossutil para cargar el modelo en su bucket de OSS.

Reemplace <Bucket-Name> con el nombre real de su bucket de OSS.

Para instalar ossutil, consulte Install ossutil .

# Create a directory.
ossutil mkdir oss://<Bucket-Name>/models/Qwen1.5-4B-Chat
# Upload files recursively (-r indicates recursive upload).
ossutil cp -r ./ oss://<Bucket-Name>/models/Qwen1.5-4B-Chat

2. Configurar un PV y un PVC

Para mejorar el rendimiento de carga del modelo, este ejemplo crea un volumen estático de OSS. Para conocer los pasos detallados, consulte Use an ossfs 1.0 static volume.

Cree una credencial de acceso de OSS (Secret).

Reemplace <AccessKey-ID> y <AccessKey-Secret> con su información real.

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

Cree el archivo oss-storage.yaml.

apiVersion: v1
kind: PersistentVolume
metadata:
  name: llm-model
  labels:
    alicloud-pvname: llm-model
spec:
  capacity:
    storage: 30Gi
  # Access mode
  accessModes:
    - ReadWriteMany            
  persistentVolumeReclaimPolicy: Retain
  storageClassName: oss
  csi:
    driver: ossplugin.csi.alibabacloud.com
    volumeHandle: llm-model
    # Get AccessKey information from the Secret object.
    nodePublishSecretRef:
      name: oss-secret
      namespace: default
    volumeAttributes:
      # Replace with your actual OSS Bucket name.
      bucket: "<Your-Bucket-Name>"         
      # The internal endpoint for the bucket's region.
      url: "http://oss-cn-hangzhou-internal.aliyuncs.com" 
      # The relative path in OSS.
      path: "/models/Qwen1.5-4B-Chat"     
---
apiVersion: v1
kind: PersistentVolumeClaim
metadata:
  name: llm-model
  namespace: default
spec:
  accessModes:
    - ReadWriteMany
  storageClassName: oss
  resources:
    requests:
      # Requested storage size, which cannot exceed the total volume size.
      storage: 30Gi
  selector:
    matchLabels:
      # Select the PV by using this label.
      alicloud-pvname: llm-model

Despliegue el PV y el PVC.
```
kubectl apply -f oss-storage.yaml
```

Paso 4: Desplegar el servicio de inference de Knative

Cree un Knative Service, habilite la función de gateway de IA y configure el motor vLLM para la inference.

Cree el archivo de configuración del servicio qwen-service.yaml.

Configuraciones principales:

knative.aliyun.com/ai-gateway: inference: habilita la extensión del gateway de inference.
autoscaling.knative.dev/metric: "concurrency": escala automáticamente según el número de solicitudes concurrentes.

apiVersion: serving.knative.dev/v1
kind: Service
metadata:
  name: qwen
  namespace: default
  annotations:
    # Enable the AI inference gateway.
    knative.aliyun.com/ai-gateway: inference          
    knative.aliyun.com/ai-gateway-inference-priority: "1"
  labels:
    release: qwen
spec:
  template:
    metadata:
      annotations:
        # Autoscaling metric: concurrency.
        autoscaling.knative.dev/metric: "concurrency" 
        # Target concurrency.
        autoscaling.knative.dev/target: "2"           
        # Maximum number of instances.
        autoscaling.knative.dev/max-scale: "3"        
        # Minimum number of instances. For large models, a minimum of 1 is recommended to keep an instance warm and avoid request timeouts on cold starts.
        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
            # Request GPU resources.
            nvidia.com/gpu: "1" 
          requests:
            cpu: "8"
            memory: 32Gi
            nvidia.com/gpu: "1"
        volumeMounts:
        # The mount path must match the model parameter in the startup command.
        - mountPath: /models/Qwen1.5-4B-Chat 
          name: llm-model
      volumes:
      - name: llm-model
        persistentVolumeClaim:
          claimName: llm-model

Despliegue el servicio.
```
kubectl apply -f qwen-service.yaml
```
Compruebe el progreso del despliegue (espere a que Ready sea True).
```
kubectl get ksvc qwen -n default
```

Paso 5: Comprobar el servicio de inference

Una vez desplegado el servicio, use la dirección IP del gateway para acceder a la API de inference.

Obtenga la dirección IP del gateway.

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

Envíe una solicitud de prueba.

Este paso simula una solicitud de chat con formato 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
  }'

La terminal debe devolver datos JSON que contienen el campo choices, donde content incluye la respuesta del modelo.

Facturación

El componente Knative no genera cargos adicionales. Sin embargo, se le facturará por los recursos en la nube que utilicen sus servicios, como cómputo, red y almacenamiento.

GPU instances: las instancias GPU son costosas. Para controlar los costos, se recomienda usarlas junto con node scaling.
OSS: los cargos incluyen el almacenamiento de OSS y las tarifas por solicitudes. Si hay acceso público, también se generan cargos por tráfico de salida.
Classic Load Balancer (CLB): la instancia de load balancer pública vinculada al gateway genera tarifas de tráfico.

Para más información, consulte Cloud product resource fees.

Documentos relacionados

Knative también admite el despliegue de otros servicios, como A2A y MCP Server. Esto le permite aprovechar las ventajas serverless, como el escalado bajo demanda y los patrones basados en eventos, en otros servicios avanzados de IA.