Server Load Balancer:Pratique du routage conscient de la charge

1. (Facultatif) Déployer un service d'inférence d'exemple

Cette étape fournit un service d'inférence vLLM d'exemple qui expose des métriques Prometheus (en utilisant DeepSeek-R1-Distill-Qwen-1.5B comme exemple, avec le type d'instance ECS ecs.gn7i-c16g1.4xlarge). Ce service est utilisé pour la collecte des métriques de routage conscient de la charge et la planification dans les étapes suivantes. La section de test de vérification utilise également ce modèle d'exemple pour le benchmarking. Si vous avez déjà déployé un service d'inférence tel que décrit dans la section Prérequis, vous pouvez ignorer cette étape. Vous pouvez également consulter Déployer un service d'inférence de grand modèle Qwen.

1. Préparez le modèle et configurez les volumes de stockage. Après avoir téléchargé le modèle et l'avoir uploadé vers OSS, consultez Configurer les volumes de stockage OSS pour configurer PV et PVC (tels que example-oss-swap) pour le cluster, que le service d'inférence monte pour accéder au modèle. Stocker le modèle dans OSS et le récupérer via le réseau interne évite le temps long requis pour les téléchargements depuis le réseau public.

   # 1. Download the model
   GIT_LFS_SKIP_SMUDGE=1 git clone https://www.modelscope.cn/deepseek-ai/DeepSeek-R1-Distill-Qwen-1.5B.git
   cd DeepSeek-R1-Distill-Qwen-1.5B
   git lfs pull
   
   # 2. Upload the model to OSS
   ossutil mkdir oss://<Your-Bucket-Name>/DeepSeek-R1-Distill-Qwen-1.5B
   ossutil cp -r ./DeepSeek-R1-Distill-Qwen-1.5B oss://<Your-Bucket-Name>/DeepSeek-R1-Distill-Qwen-1.5B

2. Créez un Deployment et un Service pour le service d'inférence dans le cluster ACK. La configuration suivante démarre un service d'inférence utilisant vLLM et déclare des annotations de collecte Prometheus sur le Pod, exposant le port 8000 avec /metrics comme endpoint de métriques.

   apiVersion: apps/v1
   kind: Deployment
   metadata:
     labels:
       app: deepseek-r1-distill-qwen-1.5b
     name: deepseek-r1-distill-qwen-1.5b
     namespace: default
   spec:
     replicas: 4
     selector:
       matchLabels:
         app: deepseek-r1-distill-qwen-1.5b
     template:
       metadata:
         labels:
           app: deepseek-r1-distill-qwen-1.5b
         annotations:
           prometheus.io/path: /metrics
           prometheus.io/port: "8000"
           prometheus.io/scrape: "true"
       spec:
         volumes:
           - name: model
             persistentVolumeClaim:
               claimName: example-oss-swap
           - name: dshm
             emptyDir:
               medium: Memory
               sizeLimit: 30Gi
         containers:
         - command:
           - sh
           - -c
           - vllm serve /models/DeepSeek-R1-Distill-Qwen-1.5B --port 8000 --trust-remote-code --served-model-name deepseek-r1-distill-qwen-1.5b --gpu-memory-utilization 0.95 --enforce-eager
           image: registry-cn-hangzhou.ack.aliyuncs.com/dev/vllm:0.10.0
           env:
           - name: SAFETENSORS_FAST_GPU_TRANSFER
             value: "0"
           - name: SAFETENSORS_MAX_HEADER_LENGTH
             value: "10000000"
           name: vllm
           ports:
           - containerPort: 8000
           readinessProbe:
             tcpSocket:
               port: 8000
             initialDelaySeconds: 30
             periodSeconds: 30
           resources:
             limits:
               nvidia.com/gpu: "1"
           volumeMounts:
             - mountPath: /models/
               name: model
             - mountPath: /dev/shm
               name: dshm
   ---
   apiVersion: v1
   kind: Service
   metadata:
     name: deepseek-r1-distill-qwen-1-5b-v1
   spec:
     type: ClusterIP
     ports:
     - port: 8000
       protocol: TCP
       targetPort: 8000
     selector:
       app: deepseek-r1-distill-qwen-1.5b

3. Une fois que les Pods sont prêts, exécutez exec dans n'importe quel Pod pour vérifier que l'endpoint de métriques est correctement exposé. La réponse doit contenir des métriques telles que vllm:num_requests_waiting, vllm:gpu_cache_usage_perc et vllm:num_requests_running.

   curl http://<Pod-IP>:8000/metrics

2. Créer une instance ALB Extensible Edition

1. Connectez-vous à la console ALB. Sélectionnez la région China (Shanghai) et cliquez sur Create ALB.

2. Sur la page d'achat, effectuez la configuration suivante et cliquez sur Create Now.

   • Region : Sélectionnez China (Shanghai).

   • Instance Network Type : Sélectionnez Internet.

   • VPC et Zone : Sélectionnez VPC1, cochez Shanghai Zone B et Shanghai Zone F, puis sélectionnez VSW1 et VSW2.

   • IP Version : Sélectionnez IPv4.

   • Edition (Instance Fee) : Sélectionnez Extensible Edition.

3. Sur la page Confirm Order, confirmez les détails de la configuration de l'instance et cliquez sur Activate Now.

3. Créer une Service Extension et ajouter le composant de routage conscient de la charge

Les requêtes de collecte de métriques sont envoyées via HTTP 1.1 en utilisant uniquement des adresses IPv4. Les backends IPv6 ne sont pas pris en charge. Le corps de la réponse de collecte de métriques pour un seul backend est limité à 10 Ko par défaut. Placez les métriques requises (vllm:num_requests_waiting, vllm:gpu_cache_usage_perc, vllm:num_requests_running) dans les premiers 10 Ko de la sortie des métriques. Pour plus de détails, consultez Limites.

1. Dans la console Service Extension, cliquez sur Create Service Extension. Dans la section Service Extension Configuration, saisissez un Extension name tel que ext-load-aware-routing.

2. L'option Extension Type est définie sur Plug-in par défaut. Dans la liste déroulante Component name, sélectionnez Load-Aware Routing. Effectuez la configuration suivante et cliquez sur Create.

   • Collection Configuration :

     • Host : La valeur de l'en-tête de requête Host pour les requêtes de collecte de métriques. Laissez ce champ vide dans cet exemple, ce qui signifie que le système utilise l'adresse IP:Port de chaque backend du groupe de serveurs pour la collecte.

     • Path : Le chemin de requête pour la collecte de métriques. Cet exemple utilise /metrics.

     • Response Timeout : La valeur par défaut est de 5 secondes.

     • Interval : Définissez sur 1 seconde.

   • Metric Configuration : Sélectionnez les trois options : Total Queued Requests, GPU Cache Utilization et Running Requests. Définissez les poids respectivement sur 100, 90 et 80.

Le composant de routage conscient de la charge doit être utilisé avec un groupe de serveurs de type Server ou IP Address , et ne peut pas être ajouté à la même Service Extension que d'autres composants.

4. Créer un groupe de serveurs et associer la Service Extension

Créez un groupe de serveurs pour héberger les réplicas d'inférence backend et associez-le à la Service Extension de routage conscient de la charge créée à l'étape 3.

1. Dans la console Server Group, sélectionnez la région China (Shanghai). Cliquez sur Create Server Group, effectuez la configuration suivante et cliquez sur Create.

   • Server Group Type : Sélectionnez IP Address.

   • Server Group Name : Saisissez un nom personnalisé tel que sgp-load-aware.

   • VPC : Sélectionnez VPC1.

   • Scheduling Algorithm : Utilisez la valeur par défaut Weighted Round-robin. Le routage conscient de la charge prend uniquement en charge la combinaison avec le weighted round-robin.

   • Désactivez l'option Health Check.

     Dans cet exemple, les Pods backend ne fournissent pas l'interface requise pour les health checks ALB. Si les health checks sont activés, les backends seraient déterminés comme non sains, ce qui contournerait le routage conscient de la charge. Si vos backends fournissent une interface de health check, maintenez les health checks activés. La désactivation n'est pas recommandée.

     La collecte de métriques dans le routage conscient de la charge dispose d'une détection de liveness intégrée : les backends dont les métriques ne peuvent pas être collectées sont automatiquement supprimés, offrant une capacité similaire aux health checks.

   • Cochez la case For Extensible instances en bas de la page. Activez l'option Associate Service Extension et Use Existing Service Extension. Sélectionnez l'extension ext-load-aware-routing créée à l'étape 3.

2. Une fois le message Server Group Created affiché, cliquez sur Add Backend Servers. Dans le panneau Add Backend Server, ajoutez les adresses IP des Pods du service d'inférence déployé (obtenables depuis la liste des clusters ACK > Details > Network > Services). Cliquez sur Add IP Address pour ajouter plusieurs entrées, puis cliquez sur Next.

3. À l'étape Ports/Weights, définissez le Port sur 8000, conservez la valeur par défaut pour le Weight et cliquez sur OK.

5. Créer un listener

1. Dans la console ALB, cliquez sur l'ID de l'instance cible pour accéder à la page Instance Details. Sous l'onglet Listener, cliquez sur Create Listener.

2. À l'étape Configure Listener, définissez le Listener Protocol sur HTTP et le Listener Port sur 80. Dans les Advanced Settings, définissez l'option Connection Request Timeout sur 3600 secondes. Ensuite, cliquez sur Next.

   Cet exemple utilise un listener HTTP pour simplifier la configuration et se concentrer sur la vérification de l'effet de planification du routage conscient de la charge. Dans un environnement de production, utilisez un listener HTTPS avec des certificats configurés pour la sécurité du transport.

   Les requêtes d'inférence LLM (en particulier lors de la génération de nombreux tokens de sortie) peuvent prendre beaucoup de temps par réponse. Si le temps de réponse dépasse le délai d'expiration de requête par défaut du listener (60 secondes), les requêtes sont interrompues prématurément. Cet exemple définit le délai d'expiration de requête sur 3600 secondes pour éviter l'interruption des réponses longues. Ajustez cette valeur en fonction de la durée réelle de vos requêtes.

3. À l'étape Select Server Group, sélectionnez le groupe de serveurs sgp-load-aware créé à l'étape 4. Ensuite, cliquez sur Next.

4. À l'étape Configuration Review, confirmez la configuration et cliquez sur Submit.

6. Configurer la résolution DNS

Pointez votre domaine personnalisé vers le nom DNS de l'instance ALB via un enregistrement CNAME afin que les clients puissent accéder à ALB via votre domaine personnalisé.

Cet exemple utilise Alibaba Cloud DNS. Pour les domaines non enregistrés auprès d'Alibaba Cloud, vous devez d'abord ajouter le domaine à la console DNS.

1. Dans la console ALB, copiez le Domain Name de l'instance cible.

2. Connectez-vous à la console DNS. Dans la colonne Actions du domaine cible, cliquez sur Settings. Sur la page Settings, cliquez sur Add Record.

3. Ajoutez un enregistrement CNAME avec les informations suivantes, puis cliquez sur OK.

   • Record Type : Sélectionnez CNAME.

   • Hostname : Saisissez un préfixe de domaine tel que test. Si votre domaine racine est example.com, le domaine pour accéder à ALB serait test.example.com.

   • Query Source et TTL : Conservez les valeurs par défaut.

   • Record Value : Saisissez le nom DNS de l'instance ALB.

4. Dans la boîte de dialogue Change Resource Record Confirmation qui apparaît, confirmez les informations de résolution et cliquez sur OK.

7. Test de vérification

Utilisez l'outil de benchmarking vllm bench serve pour exécuter un test de charge sur les backends. Pour éviter toute interférence de la bande passante, de la latence et du jitter du réseau public sur les résultats des tests, cet exemple exécute le benchmark depuis un environnement de réseau interne au sein du même VPC qu'ALB : un Pod de benchmark dédié est déployé (avec uniquement l'outil vLLM installé et le même modèle monté, sans démarrer le service d'inférence) en tant que client de test, séparé des backends testés, afin d'éviter de consommer des ressources d'inférence ou d'interférer avec la collecte des métriques.

En définissant une cible de concurrence dépassant largement la limite de performance du service, les GPU backend fonctionnent sous une charge extrême. Cela permet de valider si le routage conscient de la charge peut optimiser la distribution des requêtes, réduire les mises en file d'attente extrêmes et accélérer le débit global.

vllm bench serve \
  --backend vllm \
  --model /models/DeepSeek-R1-Distill-Qwen-1.5B \
  --served-model-name deepseek-r1-distill-qwen-1.5b \
  --trust-remote-code \
  --dataset-name random \
  --random-prefix-len 1000 \
  --random-input-len 3000 \
  --random-output-len 3000 \
  --random-range-ratio 0.2 \
  --num-prompts 3000 \
  --max-concurrency 600 \
  --host <Service-ClusterIP> \
  --port 8000 \
  --endpoint /v1/completions \
  --save-result \
  2>&1 | tee benchmark_svc.txt

vllm bench serve \
  --backend vllm \
  --model /models/DeepSeek-R1-Distill-Qwen-1.5B \
  --served-model-name deepseek-r1-distill-qwen-1.5b \
  --trust-remote-code \
  --dataset-name random \
  --random-prefix-len 1000 \
  --random-input-len 3000 \
  --random-output-len 3000 \
  --random-range-ratio 0.2 \
  --num-prompts 3000 \
  --max-concurrency 600 \
  --host <ALB-VIP> \
  --port 80 \
  --endpoint /v1/completions \
  --save-result \
  2>&1 | tee benchmark_alb.txt

Facturation

• ALB Extensible Edition — Actuellement en préversion publique et disponible gratuitement.

• Cluster ACK et instances GPU — Le service d'inférence backend s'exécute sur des nœuds GPU dans un cluster ACK. La facturation suit les règles de tarification correspondantes de Container Service et des instances ECS. Si elles sont créées à des fins de test, utilisez des instances paiement à l'utilisation et libérez-les rapidement.

• Frais de domaine et de résolution DNS publique — En plus des frais de domaine auprès de votre fournisseur de domaine, la configuration de la résolution DNS publique sur Alibaba Cloud entraîne des frais de résolution autoritaire publique.

Limites

• Les requêtes de collecte de métriques sont envoyées via HTTP 1.1 sur des adresses IPv4. Les backends IPv6 ne sont actuellement pas pris en charge.

• Le corps de la réponse de collecte de métriques pour un seul backend est limité à 10 Ko par défaut. Le contenu dépassant cette limite est ignoré, ce qui peut entraîner une collecte incomplète des métriques. Le routage conscient de la charge n'utilise que trois métriques : vllm:num_requests_waiting, vllm:gpu_cache_usage_perc et vllm:num_requests_running. Placez ces métriques dans les premiers 10 Ko de la sortie des métriques pour garantir leur collecte correcte.

FAQ