Implante serviços de LLM e implemente roteamento inteligente no Knative - Container Service for Kubernetes: Central de Documentação do Alibaba Cloud

Baseado na Kubernetes Gateway API e na especificação Inference Extension, o componente Gateway com Inference Extension integra-se à arquitetura Serverless do Knative para simplificar o gerenciamento de serviços de inferência de IA generativa. Ele oferece roteamento eficiente na camada 7 e balanceamento de carga entre múltiplas cargas de trabalho de service de inferência, além de permitir o dimensionamento automático de recursos de GPU com base na concorrência de requisições.

Como funciona

O Gateway com Inference Extension estende a Gateway API para cenários de inferência de IA por meio das seguintes CustomResourceDefinitions (CRDs).

InferencePool: Agrupa logicamente os recursos para serviços de modelo de IA. Representa um conjunto de Pods que compartilham a mesma configuração de computação, tipo de acelerador, modelo base e servidor de modelo. Um InferencePool pode abranger vários nós para garantir alta disponibilidade.
InferenceObjective: Define os objetivos de um serviço de modelo, especificando o nome do modelo servido pelos Pods em um InferencePool e seu nível de criticidade. Cargas de trabalho marcadas como Critical recebem maior prioridade de processamento.

No Knative, ao ativar a anotação de gateway de IA, um Knative Service passa a usar automaticamente essas CRDs para agendamento inteligente de tráfego.

Pré-requisitos

Você criou um ACK Managed Pro cluster que atende aos seguintes requisitos:
- O Knative está implantado. Para mais informações, consulte Implantar e gerenciar componentes do Knative.
- O componente Gateway API está instalado.
- O componente Gateway with Inference Extension versão v1.4.0-apsara.4 ou posterior está instalado, e você selecionou Enable Gateway API Inference Extension durante a instalação.
- O cluster contém nós de GPU, cada um com pelo menos 32 GiB de memória (este tópico usa o Qwen1.5-4B como exemplo). É necessário configurar uma Node Labels específica nos nós para definir a versão do driver: defina a key como ack.aliyun.com/nvidia-driver-version e o value como 550.144.03.
  
  Recomendamos a versão 550.144.03 ou superior do driver para nós de GPU. Para mais informações, consulte Personalizar a versão do driver de GPU de um nó especificando um número de versão.
Você possui criou um Bucket OSS.

Recomendamos escolher a mesma região do seu cluster para evitar cobranças de transferência de dados entre regiões e reduzir a latência.

Etapa 1: Ative o suporte à Gateway API no Knative

Modifique a configuração de rede do Knative para definir a Gateway API como o controlador de Ingress.

Edite o ConfigMap config-network.

kubectl edit configmap config-network -n knative-serving

No campo data, modifique ingress.class e salve as alterações.

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

Verifique se a alteração entrou em vigor.

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

Saída esperada:

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

Etapa 2: Crie um recurso de gateway de inferência

Crie um recurso Gateway para escutar requisições externas. Este exemplo configura o gateway para escutar na porta 8888.

Crie o arquivo de configuração do 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

Implante o recurso de gateway.
```
kubectl apply -f knative-gateway.yaml
```

Verifique o status do gateway.

kubectl get gateway knative-gateway -n knative-serving

Na saída, certifique-se de que PROGRAMMED seja True e que um endereço IP esteja atribuído no campo ADDRESS.

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

Etapa 3: Prepare os dados do modelo e configure o armazenamento

Para evitar baixar o modelo novamente sempre que um contêiner for iniciado, recomendamos usar um volume estático do OSS para armazenar e montar os dados do modelo.

1. Baixe o modelo e faça upload para o OSS

Esta etapa usa o modelo Qwen1.5-4B-Chat como exemplo. Você pode criar temporariamente um comprar uma instância ECS para preparar os dados do modelo e liberar após concluir o processo.

Baixe o modelo para um diretório 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 o ossutil para fazer upload do modelo para o seu Bucket do OSS.

Substitua <Bucket-Name> pelo nome real do seu Bucket do OSS.

Para instalar o ossutil, consulte Instalar o 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. Configure um PV e PVC

Para melhorar o desempenho de carregamento do modelo, este exemplo cria um volume estático do OSS. Para etapas detalhadas, consulte Usar um volume estático do ossfs 1.0.

Crie uma credencial de acesso ao OSS (Secret).

Substitua <AccessKey-ID> e <AccessKey-Secret> pelas suas informações reais.

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

Crie o arquivo 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

Implante o PV e o PVC.
```
kubectl apply -f oss-storage.yaml
```

Etapa 4: Implante o serviço de inferência do Knative

Crie um Knative Service, ative o recurso de gateway de IA e configure o mecanismo vLLM para inferência.

Crie o arquivo de configuração do serviço qwen-service.yaml.

Principais configurações:

knative.aliyun.com/ai-gateway: inference: Ativa a extensão do gateway de inferência.
autoscaling.knative.dev/metric: "concurrency": Dimensiona automaticamente com base no número de requisições simultâneas.

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

Implante o serviço.
```
kubectl apply -f qwen-service.yaml
```
Verifique o progresso da implantação (aguarde até que Ready seja True).
```
kubectl get ksvc qwen -n default
```

Etapa 5: Verifique o serviço de inferência

Após implantar o serviço, use o endereço IP do gateway para acessar a API de inferência.

Obtenha o endereço IP do gateway.

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

Envie uma requisição de teste.

Esta etapa simula uma requisição de chat no formato OpenAI.

O valor de model deve corresponder ao caminho --model no comando de inicialização da Etapa 4 e ao valor de volumeMounts.mountPath. Se você personalizou o mountPath, atualize este valor adequadamente.
```
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
  }'
```
O terminal deve retornar dados JSON contendo o campo choices, onde content contém a resposta do modelo.

Faturamento

O componente Knative em si não gera cobranças adicionais. No entanto, você será faturado pelos recursos de cloud que seus serviços utilizarem, como computação, rede e armazenamento.

Instâncias de GPU: Instâncias de GPU têm custo elevado. Para controlar despesas, recomendamos usá-las com dimensionamento de nós.
OSS: As cobranças incluem armazenamento no OSS e taxas de requisição. Se houver acesso público, você também incorrerá em taxas de tráfego de saída.
Classic Load Balancer (CLB): A instância de balanceador de carga pública vinculada ao gateway gera taxas de tráfego.

Para mais informações, consulte Taxas de recursos de produtos de nuvem.

Documentos relacionados

O Knative também suporta a implantação de outros serviços, como A2A e MCP Server. Isso permite aplicar benefícios Serverless, como dimensionamento sob demanda e padrões orientados a eventos, a outros serviços avançados de IA.