Aidez à améliorer cette page

Les traductions sont fournies par des outils de traduction automatique. En cas de conflit entre le contenu d'une traduction et celui de la version originale en anglais, la version anglaise prévaudra.

Pour contribuer à ce guide de l'utilisateur, cliquez sur le GitHub lien Modifier cette page sur qui se trouve dans le volet droit de chaque page.

Les traductions sont fournies par des outils de traduction automatique. En cas de conflit entre le contenu d'une traduction et celui de la version originale en anglais, la version anglaise prévaudra.

Démarrage rapide : inférence LLM à haut débit avec vLLM sur Amazon EKS

Introduction

Ce guide de démarrage rapide fournit une procédure pas à pas pour déployer de grands modèles linguistiques (LLMs) sur Amazon EKS à l'aide de vLLM et GPUs pour les applications d'inférence en temps réel basées sur du texte.

La solution s'appuie sur Amazon EKS pour l'orchestration de conteneurs et sur vLLM pour un service de modèles efficace, ce qui vous permet de créer des applications d'IA évolutives avec accélération GPU et service d'inférence à haut débit. Le modèle Llama 3.1 8B Instruct est utilisé à des fins de démonstration, mais vous pouvez déployer tout autre LLM pris en charge par vLLM (consultez la documentation vLLM pour obtenir la liste des modèles pris en charge). Pour tester l'inférence LLM, nous utilisons un exemple d'application de chatbot basé sur le projet. nextjs-vllm-ui Enfin, nous utilisons GuideLM pour comparer et ajuster les paramètres de configuration vLLM afin d'optimiser les performances d'inférence.

Architecture vLLM sur EKS

Lorsque vous aurez terminé cette procédure, vous disposerez d'un point de terminaison d'inférence vLLM optimisé pour le débit et une faible latence, et vous pourrez interagir avec un modèle de lama via une application frontale de chat, illustrant ainsi un cas d'utilisation typique des assistants chatbot et d'autres applications basées sur le LLM.

Pour obtenir des conseils supplémentaires et des ressources de déploiement avancées, consultez notre guide des meilleures pratiques EKS pour les AI/ML charges de travail et l'IA prête à la production sur les graphiques d'inférence EKS.

Avant de commencer

Avant de commencer, assurez-vous d'avoir :

Configurer Model Storage avec Amazon S3

Stockez efficacement des fichiers LLM volumineux dans Amazon S3 afin de séparer le stockage des ressources de calcul. Cette approche rationalise les mises à jour des modèles, réduit les coûts et simplifie la gestion des configurations de production. S3 gère les fichiers volumineux de manière fiable, tandis que l'intégration à Kubernetes via le pilote Mountpoint CSI permet aux pods d'accéder à des modèles tels que le stockage local, sans avoir à effectuer de longs téléchargements au démarrage. Suivez ces étapes pour créer un compartiment S3, télécharger un LLM et le monter en tant que volume dans votre conteneur de service d'inférence.

D'autres solutions de stockage sont également disponibles sur EKS pour la mise en cache des modèles, telles que EFS et FSx Lustre. Pour plus d'informations, consultez les meilleures pratiques d'EKS.

Définir les variables d'environnement

Créez un nom unique pour un nouveau compartiment Amazon S3 que nous créerons plus loin dans ce guide. Une fois créé, utilisez le même nom de compartiment pour toutes les étapes. Par exemple :

MY_BUCKET_NAME=model-store-$(date +%s)

Définissez les variables d'environnement et stockez-les dans un fichier :

cat << EOF > .env-quickstart-vllm
export BUCKET_NAME=${MY_BUCKET_NAME}
export AWS_REGION=us-east-1
export AWS_ACCOUNT_ID=$(aws sts get-caller-identity --query Account --output text)
EOF

Chargez les variables d'environnement dans votre environnement shell. Si vous fermez l'environnement shell actuel et que vous en ouvrez un nouveau, assurez-vous de réapprovisionner les variables d'environnement à l'aide de cette même commande :

source .env-quickstart-vllm

Création d'un compartiment S3 pour stocker les fichiers de modèles

Créez un compartiment S3 pour stocker les fichiers de modèles :

aws s3 mb s3://${BUCKET_NAME} --region ${AWS_REGION}

Télécharger le modèle de Hugging Face

Hugging Face est l'un des principaux centres de modélisation permettant d'accéder aux modèles LLM. Pour télécharger le modèle Llama, vous devez accepter la licence du modèle et configurer l'authentification par jeton :

Définissez une variable d'environnement avec votre jeton Hugging Face :

export HF_TOKEN=your_token_here

Installez le package pip3 s'il n'est pas déjà installé dans votre environnement. Exemple de commande dans Amazon Linux 2023 :

sudo dnf install -y python3-pip

Installez la CLI Hugging Face :

pip install huggingface-hub

Téléchargez le modèle Llama-3.1-8B-Instruct depuis Hugging Face (~15 Go) en --exclude utilisant le drapeau pour ignorer le format existant et ne télécharger que les fichiers au format Safetensors optimisés, ce qui réduit PyTorch la taille du téléchargement tout en garantissant une compatibilité totale avec les moteurs d'inférence les plus courants :

huggingface-cli download meta-llama/Meta-Llama-3.1-8B-Instruct \
  --exclude "original/*" \
  --local-dir ./llama-3.1-8b-instruct \
  --token $HF_TOKEN

Vérifiez les fichiers téléchargés :

$ ls llama-3.1-8b-instruct

Le résultat attendu devrait ressembler à ceci :

LICENSE        config.json                       model-00002-of-00004.safetensors  model.safetensors.index.json  tokenizer_config.json
README.md      generation_config.json            model-00003-of-00004.safetensors  special_tokens_map.json
USE_POLICY.md  model-00001-of-00004.safetensors  model-00004-of-00004.safetensors  tokenizer.json

Téléchargez des fichiers de modèles

Activez AWS Common Runtime (CRT) pour améliorer les performances de transfert S3. Le client de transfert basé sur CRT fournit un débit et une fiabilité améliorés pour les opérations de fichiers volumineux :

aws configure set s3.preferred_transfer_client crt

Téléchargez le modèle :

aws s3 cp ./llama-3.1-8b-instruct s3://$BUCKET_NAME/llama-3.1-8b-instruct \
  --recursive

Le résultat attendu devrait ressembler à ceci :

...
upload: llama-3.1-8b-instruct/tokenizer.json to s3://model-store-1753EXAMPLE/llama-3.1-8b-instruct/tokenizer.json
upload: llama-3.1-8b-instruct/model-00004-of-00004.safetensors to s3://model-store-1753890326/llama-3.1-8b-instruct/model-00004-of-00004.safetensors
upload: llama-3.1-8b-instruct/model-00002-of-00004.safetensors to s3://model-store-1753890326/llama-3.1-8b-instruct/model-00002-of-00004.safetensors
upload: llama-3.1-8b-instruct/model-00003-of-00004.safetensors to s3://model-store-1753890326/llama-3.1-8b-instruct/model-00003-of-00004.safetensors
upload: llama-3.1-8b-instruct/model-00001-of-00004.safetensors to s3://model-store-1753890326/llama-3.1-8b-instruct/model-00001-of-00004.safetensors

Configurer les autorisations CSI de S3 Mountpoint

Le pilote S3 Mountpoint CSI permet une intégration native entre Kubernetes et S3, permettant aux pods d'accéder directement aux fichiers du modèle comme s'il s'agissait d'un stockage local, éliminant ainsi le besoin de copies locales lors du démarrage du conteneur.

Créez une politique IAM pour autoriser le point de montage S3 à lire depuis votre compartiment S3 :

aws iam create-policy \
  --policy-name S3BucketAccess-${BUCKET_NAME} \
  --policy-document "{\"Version\": \"2012-10-17\", \"Statement\": [{\"Effect\": \"Allow\", \"Action\": [\"s3:GetObject\", \"s3:GetObjectVersion\", \"s3:ListBucket\", \"s3:GetBucketLocation\"], \"Resource\": [\"arn:aws:s3:::${BUCKET_NAME}\", \"arn:aws:s3:::${BUCKET_NAME}/*\"]}]}"

Trouvez le nom du rôle IAM utilisé par le pilote S3 Mountpoint CSI en vérifiant les annotations du compte de service S3 CSI Driver :

ROLE_NAME=$(kubectl get serviceaccount s3-csi-driver-sa -n kube-system -o jsonpath='{.metadata.annotations.eks\.amazonaws\.com/role-arn}' | cut -d'/' -f2)

Associez votre politique IAM au rôle S3 Mountpoint CSI :

aws iam attach-role-policy \
 --role-name ${ROLE_NAME} \
 --policy-arn arn:aws:iam::${AWS_ACCOUNT_ID}:policy/S3BucketAccess-${BUCKET_NAME}

Si S3 Mountpoint CSI n'est pas installé dans le cluster, suivez les étapes de déploiement décrites dans. Guide de configuration de clusters basé sur les meilleures pratiques pour l’inférence en temps réel sur Amazon EKS

Monter le bucket S3 en tant que volume Kubernetes

Créez un volume persistant (PV) et une réclamation de volume persistant (PVC) pour fournir un accès en lecture seule au compartiment S3 via plusieurs modules d'inférence. Le mode ReadOnlyMany d'accès garantit un accès simultané aux fichiers du modèle, tandis que le pilote CSI gère le montage du compartiment S3 :

cat <<EOF | envsubst | kubectl apply -f -
apiVersion: v1
kind: PersistentVolume
metadata:
  name: model-store
spec:
  storageClassName: ""
  capacity:
    storage: 100Gi
  accessModes:
    - ReadOnlyMany
  persistentVolumeReclaimPolicy: Retain
  mountOptions:
    - region ${AWS_REGION}
  csi:
    driver: s3.csi.aws.com
    volumeHandle: model-store
    volumeAttributes:
      bucketName: ${BUCKET_NAME}
---
apiVersion: v1
kind: PersistentVolumeClaim
metadata:
  name: model-store
spec:
  storageClassName: ""
  volumeName: model-store
  accessModes:
    - ReadOnlyMany
  resources:
    requests:
      storage: 100Gi
EOF

Configuration de l'infrastructure GPU

Nœuds de cluster

Nous utilisons le cluster EKS créé dansGuide de configuration de clusters basé sur les meilleures pratiques pour l’inférence en temps réel sur Amazon EKS. Ce cluster inclut des pools de nœuds Karpenter qui peuvent fournir aux nœuds compatibles GPU un stockage de nœuds suffisant pour télécharger l'image du conteneur vLLM. Si vous utilisez votre cluster EKS personnalisé, assurez-vous qu'il peut lancer des nœuds compatibles avec le GPU.

Sélection d'instance

Pour sélectionner correctement les instances pour l'inférence LLM, il faut s'assurer que la mémoire GPU disponible est suffisante pour charger les pondérations du modèle. Le poids du modèle pour Llama 3.1 8B Instruct est d'environ 16 Go (taille des fichiers de modèle .safetensor). Nous devons donc fournir au moins cette quantité de mémoire au processus vllm pour charger le modèle.

EC2 Les instances Amazon G5 avec A10G GPUs et les EC2 instances G6 avec L4 fournissent GPUs toutes deux 24 Go de VRAM par GPU, ce qui est suffisant pour charger des poids d'instructions Llama 3.1 8B. Si vous déployez un modèle avec des poids plus importants, pensez à utiliser un type d'instance multi-GPU ou une configuration multi-nœuds.

Pilotes de périphériques NVIDIA

Les pilotes NVIDIA fournissent l'environnement d'exécution nécessaire aux conteneurs pour accéder efficacement aux ressources du GPU. Il permet l'allocation et la gestion des ressources GPU au sein de Kubernetes, en les rendant GPUs disponibles sous forme de ressources planifiables.

Notre cluster utilise EKS Bottlerocket AMIs, qui inclut tous les pilotes de périphériques et plug-ins NVIDIA nécessaires sur tous les nœuds compatibles avec le GPU, garantissant ainsi un accès immédiat au GPU pour les charges de travail conteneurisées sans configuration supplémentaire. Si vous utilisez d'autres types de nœuds EKS, vous devez vous assurer que tous les pilotes et plug-ins nécessaires sont installés.

Tester l'infrastructure GPU

Testez les capacités GPU de votre cluster en exécutant les étapes ci-dessous pour vous assurer que les pods peuvent accéder aux ressources GPU NVIDIA et planifier correctement sur les nœuds compatibles avec le GPU.

Déployez un module de test Nvidia SMI :

cat <<EOF | envsubst | kubectl apply -f -
apiVersion: v1
kind: Pod
metadata:
  name: gpu-nvidia-smi-test
spec:
  restartPolicy: OnFailure
  tolerations:
  - key: "nvidia.com/gpu"
    operator: "Exists"
    effect: "NoSchedule"
  nodeSelector:
    role: gpu-worker  # Matches GPU NodePool's label
  containers:
  - name: cuda-container
    image: nvidia/cuda:12.9.1-base-ubuntu20.04
    command: ["nvidia-smi"]
    resources:
      requests:
        memory: "24Gi"
      limits:
        nvidia.com/gpu: 1
EOF

Consultez les journaux des modules pour vérifier que les détails du GPU sont répertoriés, comme dans le résultat ci-dessous (il ne s'agit pas nécessairement du même modèle de GPU) :

$ kubectl wait --for=jsonpath='{.status.phase}'=Succeeded pod/gpu-nvidia-smi-test
$ kubectl logs gpu-nvidia-smi-test

Wed Jul 30 15:39:58 2025
+-----------------------------------------------------------------------------------------+
| NVIDIA-SMI 570.172.08             Driver Version: 570.172.08     CUDA Version: 12.9     |
|-----------------------------------------+------------------------+----------------------+
| GPU  Name                 Persistence-M | Bus-Id          Disp.A | Volatile Uncorr. ECC |
| Fan  Temp   Perf          Pwr:Usage/Cap |           Memory-Usage | GPU-Util  Compute M. |
|                                         |                        |               MIG M. |
|=========================================+========================+======================|
|   0  NVIDIA A10G                    On  |   00000000:00:1E.0 Off |                    0 |
|  0%   30C    P8              9W /  300W |       0MiB /  23028MiB |      0%      Default |
|                                         |                        |                  N/A |
+-----------------------------------------+------------------------+----------------------+

+-----------------------------------------------------------------------------------------+
| Processes:                                                                              |
|  GPU   GI   CI              PID   Type   Process name                        GPU Memory |
|        ID   ID                                                               Usage      |
|=========================================================================================|
|  No running processes found                                                             |
+-----------------------------------------------------------------------------------------+

Ce résultat montre que les pods peuvent accéder avec succès aux ressources du GPU.

IMPORTANT : Ce pod utilise une configuration NodeSelector qui s'aligne sur les pools de nœuds Karpenter. Guide de configuration de clusters basé sur les meilleures pratiques pour l’inférence en temps réel sur Amazon EKS Si vous utilisez différents pools de nœuds, assurez-vous que le pod correspond à NodeSelector et Tolerations en conséquence.

Déployer un conteneur d'inférence

La pile de service détermine à la fois les performances et les capacités d'évolutivité de votre infrastructure d'inférence. vLLM est devenue une solution de pointe pour les déploiements de production. L'architecture de vLLM permet un traitement par lots continu pour le traitement dynamique des demandes, des optimisations du noyau pour une inférence plus rapide et une gestion efficace de la mémoire du GPU grâce à. PagedAttention Ces fonctionnalités, associées à une API REST prête pour la production et à la prise en charge des formats de modèles courants, en font un choix optimal pour les déploiements d'inférence à hautes performances.

Sélectionnez l'image du conteneur AWS Deep Learning

AWS Les Deep Learning Containers (DLCs) fournissent des environnements préoptimisés avec des mises à jour de sécurité, une compatibilité AWS d'infrastructure et des configurations de pilotes optimisées. Cela réduit la complexité du déploiement et les frais de maintenance tout en garantissant la disponibilité de la production.

Pour ce déploiement, nous utiliserons le AWS DLC pour vLLM 0.9, qui inclut des bibliothèques Nvidia et des configurations de performances GPU optimisées spécialement conçues pour l'inférence du modèle de transformateur sur les instances de GPU. AWS

image: 763104351884.dkr.ecr.us-east-1.amazonaws.com/vllm:0.9-gpu-py312-ec2

Appliquer les manifestes vLLM Kubernetes

Il existe plusieurs manières de déployer vLLM dans EKS. Ce guide explique le déploiement de vLLM à l'aide d'un déploiement Kubernetes, qui est un moyen simple et natif de Kubernetes pour démarrer. Pour les options de déploiement avancées, consultez la documentation vLLM et les plans AI on EKS.

Définissez les paramètres de déploiement via les manifestes Kubernetes pour contrôler l'allocation des ressources, le placement des nœuds, les sondes de santé, l'exposition du service, etc. Configurez votre déploiement pour exécuter un pod compatible GPU à l'aide de l'image AWS Deep Learning Container pour vLLM. Définissez des paramètres optimisés pour l'inférence LLM et exposez le point de terminaison compatible avec vLLM OpenAPI via le service Load Balancer : AWS

cat <<EOF | envsubst | kubectl apply -f -
apiVersion: apps/v1
kind: Deployment
metadata:
  name: vllm-inference-app
spec:
  replicas: 1
  selector:
    matchLabels:
      app: vllm-inference-app
  template:
    metadata:
      labels:
        app: vllm-inference-app
    spec:
      tolerations:
      - key: "nvidia.com/gpu"
        operator: "Exists"
        effect: "NoSchedule"
      nodeSelector:
        role: gpu-worker
      containers:
      - name: vllm-inference
        image: 763104351884.dkr.ecr.us-east-1.amazonaws.com/vllm:0.9-gpu-py312-ec2
        ports:
        - containerPort: 8000
        env:
        - name: MODEL_PATH
          value: "/mnt/models/llama-3.1-8b-instruct"
        args:
        - "--model=/mnt/models/llama-3.1-8b-instruct"
        - "--host=0.0.0.0"
        - "--port=8000"
        - "--tensor-parallel-size=1"
        - "--gpu-memory-utilization=0.9"
        - "--max-model-len=8192"
        - "--max-num-seqs=1"
        readinessProbe:
          httpGet:
            path: /health
            port: 8000
          initialDelaySeconds: 30
          periodSeconds: 5
          timeoutSeconds: 10
        resources:
          limits:
            nvidia.com/gpu: 1
          requests:
            memory: "24Gi"
            cpu: "4"
            ephemeral-storage: "25Gi"  # Ensure enough node storage for vLLM container image
        volumeMounts:
        - name: models
          mountPath: /mnt/models
          readOnly: true
      volumes:
      - name: models
        persistentVolumeClaim:
          claimName: model-store
---
apiVersion: v1
kind: Service
metadata:
  name: vllm-inference-svc
  annotations:
    service.beta.kubernetes.io/aws-load-balancer-type: nlb
    service.beta.kubernetes.io/aws-load-balancer-scheme: internet-facing
spec:
  type: LoadBalancer
  ports:
    - port: 80
      targetPort: 8000
      protocol: TCP
  selector:
    app: vllm-inference-app
EOF

Vérifiez que le pod vLLM est en Ready 1/1 bon état :

kubectl get pod -l app=vllm-inference-app -w

Sortie attendue :

NAME                                 READY   UP-TO-DATE   AVAILABLE   AGE
vllm-inference-app-65df5fddc8-5kmjm   1/1     1            1           5m

L'extraction de l'image du conteneur peut prendre plusieurs minutes et vLLM charge les fichiers du modèle dans la mémoire du GPU. Procédez uniquement lorsque le module est prêt et disponible.

Exposez le service

Exposez le point de terminaison d'inférence localement via la redirection de port Kubernetes pour le développement et les tests locaux. Laissez cette commande s'exécuter dans une fenêtre de terminal séparée :

export POD_NAME=$(kubectl get pod -l app=vllm-inference-app -o jsonpath='{.items[0].metadata.name}')
kubectl port-forward pod/$POD_NAME 8000:8000

Le AWS Load Balancer Controller crée automatiquement un Network Load Balancer qui expose le point de terminaison du service vLLM à l'extérieur. Récupérez le point de terminaison NLB en exécutant :

NLB=$(kubectl get service vllm-inference-svc -o jsonpath='{.status.loadBalancer.ingress[0].hostname}')

Vous devez installer le AWS Load Balancer Controller ? Suivez les étapes de déploiement décrites dansAcheminez le trafic Internet avec le AWS Load Balancer Controller.

Exécution de l'inférence

Valider le module d'inférence

Validez la fonctionnalité du conteneur d'inférence localement via le port transféré. Envoyez une demande de connexion et assurez-vous que la réponse inclut le code HTTP 200 :

$ curl -IX GET "http://localhost:8000/v1/models"

HTTP/1.1 200 OK
date: Mon, 13 Oct 2025 23:24:57 GMT
server: uvicorn
content-length: 516
content-type: application/json

Testez les capacités d'inférence et validez la connectivité externe en envoyant une demande d'achèvement au LLM via le point de terminaison NLB :

curl -X POST "http://$NLB:80/v1/completions" \
  -H "Content-Type: application/json" \
  -d '{
    "model": "/mnt/models/llama-3.1-8b-instruct",
    "prompt": "Explain artificial intelligence:",
    "max_tokens": 512,
    "temperature": 0.7
  }'

Ce point de terminaison suit le format de l'API OpenAI, ce qui le rend compatible avec les applications existantes tout en fournissant des paramètres de génération configurables tels que la longueur de réponse et la température pour contrôler la diversité des sorties.

Exécuter l'application chatbot

À titre de démonstration, ce guide exécute un exemple d'application de chatbot utilisant un projet nextjs-vllm-uipour présenter les interactions des utilisateurs avec le modèle.

Exécutez une interface utilisateur de chatbot en tant que conteneur Docker qui mappe le port 3000 à localhost et se connecte au point de terminaison vLLM NLB :

docker run --rm \
  -p 3000:3000 \
  -e VLLM_URL="http://${NLB}:80" \
  --name nextjs-vllm-ui-demo \
  ghcr.io/yoziru/nextjs-vllm-ui:latest

Ouvrez votre navigateur Web et accédez à : http://localhost:3000/

Vous devriez voir l'interface de chat où vous pouvez interagir avec le modèle Llama.

Interface utilisateur de chat

Optimisez les performances d'inférence

Les moteurs d'inférence spécialisés tels que vLLM fournissent des fonctionnalités avancées qui améliorent considérablement les performances d'inférence, notamment le traitement par lots continu, une mise en cache KV efficace et des mécanismes d'attention mémoire optimisés. Vous pouvez ajuster les paramètres de configuration vLLM pour améliorer les performances d'inférence tout en répondant aux exigences spécifiques de vos cas d'utilisation et à vos modèles de charge de travail. Une configuration appropriée est essentielle pour atteindre la saturation du GPU, afin de tirer le meilleur parti des ressources GPU coûteuses tout en garantissant un débit élevé, une faible latence et des opérations rentables. Les optimisations suivantes vous aideront à optimiser les performances de votre déploiement vLLM sur EKS.

Configurations vLLM de référence

Pour ajuster les paramètres de configuration vLLM en fonction de votre cas d'utilisation, comparez différents paramètres à l'aide d'un outil d'analyse d'inférence complet tel que GuidelLM. Cela collectera des indicateurs clés tels que le débit des demandes par seconde (RPS), la end-to-end latence (E2E), le délai jusqu'au premier jeton (TTFT) et la latence finale (TPOT) afin de comparer différentes configurations.

Configuration vLLM de base

Voici la configuration de base qui a été utilisée pour exécuter vLLM :

Exécutez GuideLLM avec cette configuration de base pour établir une référence de performance. Pour ce test, GuidelLM est configuré pour générer une demande par seconde, avec 256 requêtes à jetons et des réponses à 128 jetons.

guidellm benchmark \
--target "http://${NLB}:80" \
--processor meta-llama/Llama-3.1-8B-Instruct \
--rate-type constant \
--rate 1 \
--max-seconds 30 \
--data "prompt_tokens=256,output_tokens=128"

Sortie attendue :

Résultats de référence

Configuration vLLM optimisée

Ajustez les paramètres vLLM pour mieux utiliser les ressources du GPU et la parallélisation :

Appliquez ces modifications au déploiement en cours à l'aide de la commande kubectl patch :

kubectl patch deployment vllm-inference-app --type='json' -p='[
  {"op": "replace", "path": "/spec/template/spec/containers/0/args/4", "value": "--gpu-memory-utilization=0.92"},
  {"op": "replace", "path": "/spec/template/spec/containers/0/args/5", "value": "--max-model-len=4096"},
  {"op": "replace", "path": "/spec/template/spec/containers/0/args/6", "value": "--max-num-seqs=8"}
]'

Vérifiez que le pod vLLM est en Ready 1/1 bon état :

kubectl get pod -l app=vllm-inference-app -w

Sortie attendue :

NAME                                 READY   UP-TO-DATE   AVAILABLE   AGE
vllm-inference-app-65df5fddc8-5kmjm   1/1     1            1           5m

Exécutez ensuite à nouveau GuidelLM en utilisant les mêmes valeurs de référence que précédemment :

guidellm benchmark \
--target "http://${NLB}:80" \
--processor meta-llama/Llama-3.1-8B-Instruct \
--rate-type constant \
--rate 1 \
--max-seconds 30 \
--data "prompt_tokens=256,output_tokens=128"

Sortie attendue :

Résultats de référence optimisés

Résultats de l'analyse comparative

Calculez les résultats de l'analyse comparative dans un tableau pour la configuration de base et la configuration vLLM optimisée :

Les configurations vLLM optimisées ont considérablement amélioré le débit d'inférence (RPS) et réduit la latence (E2E, TTFT) avec une augmentation mineure de la latence de queue (TPOT) en millisecondes seulement. Ces résultats montrent comment vLLM améliore considérablement les performances d'inférence, permettant à chaque conteneur de traiter plus de demandes en moins de temps pour un fonctionnement rentable.