Contribuisci a migliorare questa pagina

Le traduzioni sono generate tramite traduzione automatica. In caso di conflitto tra il contenuto di una traduzione e la versione originale in Inglese, quest'ultima prevarrà.

Per contribuire a questa guida per l'utente, scegli il GitHub link Modifica questa pagina nel riquadro destro di ogni pagina.

Le traduzioni sono generate tramite traduzione automatica. In caso di conflitto tra il contenuto di una traduzione e la versione originale in Inglese, quest'ultima prevarrà.

Avvio rapido: inferenza LLM ad alto rendimento con vLLM su Amazon EKS

Introduzione

Questa guida rapida fornisce una procedura dettagliata per la distribuzione di Large Language Models () LLMs su Amazon EKS utilizzando VLLM e GPUs per applicazioni di inferenza in tempo reale basate su testo.

La soluzione sfrutta Amazon EKS per l'orchestrazione dei container e VLLM per un servizio di modelli efficiente, consentendoti di creare applicazioni AI scalabili con accelerazione GPU e server di inferenza ad alto rendimento. Il modello Llama 3.1 8B Instruct viene utilizzato a scopo dimostrativo, ma è possibile implementare qualsiasi altro LLM supportato da vLLM (consulta la documentazione di VLLm per un elenco dei modelli supportati). Per testare l'inferenza LLM, utilizziamo un'applicazione chatbot di esempio basata sul progetto. nextjs-vllm-ui Infine, utilizziamo GuideLM per confrontare e ottimizzare i parametri di configurazione vLLM per ottimizzare le prestazioni di inferenza.

Architettura VLLm su EKS

Una volta completata questa procedura, disporrete di un endpoint di inferenza VLLm ottimizzato per la velocità effettiva e la bassa latenza e sarete in grado di interagire con un modello Llama tramite un'applicazione di chat frontend, dimostrando un tipico caso d'uso per gli assistenti di chatbot e altre applicazioni basate su LLM.

Per ulteriori indicazioni e risorse di implementazione avanzate, consulta la nostra guida alle migliori pratiche EKS per i carichi di lavoro e l'intelligenza artificiale pronta per la produzione sui grafici di inferenza EKS. AI/ML

Prima di iniziare

Prima di iniziare, assicurati di avere:

Configurazione dello storage modello con Amazon S3

Archivia in modo efficiente file LLM di grandi dimensioni in Amazon S3 per separare lo storage dalle risorse di elaborazione. Questo approccio semplifica gli aggiornamenti dei modelli, riduce i costi e semplifica la gestione nelle configurazioni di produzione. S3 gestisce file di grandi dimensioni in modo affidabile, mentre l'integrazione con Kubernetes tramite il driver CSI Mountpoint consente ai pod di accedere a modelli come l'archiviazione locale, senza bisogno di lunghi download all'avvio. Segui questi passaggi per creare un bucket S3, caricare un LLM e montarlo come volume nel tuo contenitore di servizi di inferenza.

Su EKS sono disponibili anche altre soluzioni di storage per la memorizzazione nella cache dei modelli, come EFS e FSx Lustre. Per ulteriori informazioni, consulta EKS Best Practices.

Impostazione delle variabili di ambiente

Crea un nome univoco per un nuovo bucket Amazon S3 che creeremo più avanti in questa guida. Una volta creato, usa lo stesso nome di bucket per tutti i passaggi. Esempio:

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

Definisci le variabili di ambiente e memorizzale in un file:

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

Carica le variabili di ambiente nell'ambiente della shell. Se chiudi l'ambiente di shell corrente e ne apri uno nuovo, assicurati di rifornire le variabili di ambiente usando lo stesso comando:

source .env-quickstart-vllm

Crea un bucket S3 per archiviare i file del modello

Crea un bucket S3 per archiviare i file del modello:

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

Scarica il modello da Hugging Face

Hugging Face è uno dei principali hub di modelli per l'accesso ai modelli LLM. Per scaricare il modello Llama, dovrai accettare la licenza del modello e configurare l'autenticazione tramite token:

Imposta una variabile di ambiente con il tuo token Hugging Face:

export HF_TOKEN=your_token_here

Installa il pacchetto pip3 se non è già installato nel tuo ambiente. Comando di esempio in Amazon Linux 2023:

sudo dnf install -y python3-pip

Installa la CLI Hugging Face:

pip install huggingface-hub

Scarica il modello Llama-3.1-8B-Instruct da Hugging Face (~15 GB) --exclude usando il flag per saltare il formato precedente e scaricare solo i file in formato safetensors ottimizzato, che riduce PyTorch le dimensioni di download mantenendo la piena compatibilità con i motori di inferenza più diffusi:

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

Verifica i file scaricati:

$ ls llama-3.1-8b-instruct

L’output previsto dovrebbe essere simile al seguente:

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

Carica i file del modello

Abilita AWS Common Runtime (CRT) per migliorare le prestazioni di trasferimento S3. Il client di trasferimento basato su CRT offre velocità di trasmissione e affidabilità migliorate per operazioni su file di grandi dimensioni:

aws configure set s3.preferred_transfer_client crt

Carica il modello:

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

L’output previsto dovrebbe essere simile al seguente:

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

Configura le autorizzazioni S3 Mountpoint CSI

Il driver S3 Mountpoint CSI consente l'integrazione nativa tra Kubernetes e S3, consentendo ai pod di accedere direttamente ai file del modello come se fossero archiviazione locale, eliminando la necessità di copie locali durante l'avvio del contenitore.

Crea una policy IAM per consentire al punto di montaggio S3 di leggere dal tuo bucket 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}/*\"]}]}"

Trova il nome del ruolo IAM utilizzato dal driver CSI S3 Mountpoint controllando le annotazioni dell'account del servizio 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)

Allega la tua policy IAM al ruolo CSI di S3 Mountpoint:

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

Se S3 Mountpoint CSI non è installato nel cluster, segui la procedura di distribuzione riportata in. Guida alle best practice per la configurazione dei cluster per l’inferenza in tempo reale su Amazon EKS

Monta il bucket S3 come volume Kubernetes

Crea un Persistent Volume (PV) e un Persistent Volume Claim (PVC) per fornire l'accesso in sola lettura al bucket S3 su più pod di inferenza. La modalità di ReadOnlyMany accesso garantisce l'accesso simultaneo ai file del modello, mentre il driver CSI gestisce il montaggio del bucket 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

Configurazione dell'infrastruttura GPU

Nodi del cluster

Stiamo usando il cluster EKS creato inGuida alle best practice per la configurazione dei cluster per l’inferenza in tempo reale su Amazon EKS. Questo cluster include pool di nodi Karpenter in grado di fornire ai nodi abilitati alla GPU uno spazio di archiviazione sufficiente per scaricare l'immagine del contenitore VLLm. Se utilizzi un cluster EKS personalizzato, assicurati che possa avviare nodi abilitati alla GPU.

Selezione dell'istanza

La corretta selezione delle istanze per l'inferenza LLM richiede che la memoria GPU disponibile sia sufficiente per caricare i pesi del modello. I pesi dei modelli per Llama 3.1 8B Instruct sono di circa 16 GB (dimensione dei file del modello .safetensor), pertanto è necessario fornire almeno questa quantità di memoria al processo vllm per caricare il modello.

EC2 Le istanze Amazon G5 con A10G GPUs e le istanze G6 con L4 forniscono GPUs entrambe 24 GB di VRAM per GPU, sufficienti per caricare EC2 pesi Llama 3.1 8B Instruct. Se stai implementando un modello con pesi maggiori, prendi in considerazione l'utilizzo di un tipo di istanza multi-GPU o di una configurazione multinodo.

Driver per dispositivi NVIDIA

I driver NVIDIA forniscono l'ambiente di runtime necessario per consentire ai container di accedere alle risorse GPU in modo efficiente. Consente l'allocazione e la gestione delle risorse GPU all'interno di Kubernetes, rendendole disponibili come risorse pianificabili. GPUs

Il nostro cluster utilizza EKS Bottlerocket AMIs, che include tutti i driver e i plug-in dei dispositivi NVIDIA necessari su tutti i nodi abilitati alla GPU, garantendo l'accessibilità immediata della GPU per carichi di lavoro containerizzati senza configurazioni aggiuntive. Se utilizzi altri tipi di nodi EKS, devi assicurarti che siano installati tutti i driver e i plugin necessari.

Testa l'infrastruttura GPU

Metti alla prova le funzionalità della GPU del tuo cluster eseguendo i passaggi seguenti per assicurarti che i pod possano accedere alle risorse GPU NVIDIA e pianificare correttamente sui nodi abilitati alla GPU.

Implementa un pod di 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

Controlla i log dei pod per verificare che siano elencati i dettagli della GPU, analogamente a quanto riportato di seguito (non necessariamente lo stesso modello di 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                                                             |
+-----------------------------------------------------------------------------------------+

Questo output mostra che i pod possono accedere correttamente alle risorse della GPU.

IMPORTANTE: questo pod utilizza una configurazione NodeSelector che si allinea ai pool di nodi Karpenter. Guida alle best practice per la configurazione dei cluster per l’inferenza in tempo reale su Amazon EKS Se utilizzi pool di nodi diversi, assicurati che il pod corrisponda di conseguenza a NodeSelector e Tolerations.

Distribuisci Inference Container

Lo stack di servizi determina sia le prestazioni che le capacità di scalabilità dell'infrastruttura di inferenza. vLLM si è affermata come una soluzione leader per le implementazioni di produzione. L'architettura di vLLM fornisce il batching continuo per l'elaborazione dinamica delle richieste, ottimizzazioni del kernel per un'inferenza più rapida e una gestione efficiente della memoria GPU tramite. PagedAttention Queste funzionalità, combinate con un'API REST pronta per la produzione e il supporto per i formati di modello più diffusi, lo rendono una scelta ottimale per implementazioni di inferenza ad alte prestazioni.

Seleziona l'immagine del Deep Learning Container AWS

AWS Deep Learning Containers (DLCs) forniscono ambienti preottimizzati con aggiornamenti di sicurezza, compatibilità AWS dell'infrastruttura e configurazioni ottimizzate dei driver. Ciò riduce la complessità di implementazione e il sovraccarico di manutenzione, garantendo al contempo la disponibilità della produzione.

Per questa implementazione, utilizzeremo il AWS DLC per VLLm 0.9, che include le librerie Nvidia e configurazioni ottimizzate delle prestazioni della GPU specificamente ottimizzate per l'inferenza del modello di trasformatore su istanze GPU. AWS

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

Applica i manifesti di VLM Kubernetes

Esistono diversi modi per implementare vLLm in EKS. Questa guida illustra l'implementazione di VLLM utilizzando una distribuzione Kubernetes, un modo semplice e nativo di Kubernetes per iniziare. Per opzioni di implementazione avanzate, consulta i documenti VLLm e i blueprint AI on EKS.

Definisci i parametri di implementazione tramite i manifesti di Kubernetes per controllare l'allocazione delle risorse, il posizionamento dei nodi, i controlli sullo stato di salute, l'esposizione del servizio, ecc. Configura la distribuzione per eseguire un pod abilitato alla GPU utilizzando l'immagine del Deep Learning Container per vLLM. AWS Imposta parametri ottimizzati per l'inferenza LLM ed esponi l'endpoint compatibile con VLLM OpenAPI tramite il servizio 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

Verifica che il Ready 1/1 pod VLm sia in stato:

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

Output previsto:

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

Potrebbero essere necessari alcuni minuti mentre l'immagine del contenitore viene estratta e VLLm carica i file del modello nella memoria della GPU. Procedi solo quando il pod è pronto e disponibile.

Esponi il servizio

Esponi l'endpoint di inferenza localmente tramite il port forwarding di Kubernetes per lo sviluppo e il test locali. Lascia questo comando in esecuzione in una finestra di terminale separata:

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

Il AWS Load Balancer Controller crea automaticamente un Network Load Balancer che espone l'endpoint del servizio VLLm all'esterno. Recupera l'endpoint NLB eseguendo:

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

Devi installare AWS Load Balancer Controller? Segui le fasi di implementazione riportate inIndirizza il traffico Internet con AWS Load Balancer Controller.

Esecuzione dell’inferenza

Convalida il pod di inferenza

Convalida la funzionalità del contenitore di inferenza localmente tramite la porta inoltrata. Invia una richiesta di connessione e assicurati che la risposta includa il codice 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

Verifica le capacità di inferenza e convalida la connettività esterna inviando una richiesta di completamento all'LLM tramite l'endpoint 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
  }'

Questo endpoint segue il formato API OpenAI, rendendolo compatibile con le applicazioni esistenti e fornendo parametri di generazione configurabili come lunghezza e temperatura di risposta per il controllo della diversità di output.

Esegui l'app chatbot

A scopo dimostrativo, questa guida esegue un'applicazione chatbot di esempio che utilizza Project nextjs-vllm-uiper mostrare le interazioni degli utenti con il modello.

Esegui un'interfaccia utente di chatbot come contenitore Docker che mappa la porta 3000 su localhost e si connette all'endpoint 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

Apri il tuo browser web e vai a: http://localhost:3000/

Dovresti vedere l'interfaccia di chat in cui puoi interagire con il modello Llama.

Interfaccia utente di chat

Ottimizza le prestazioni di inferenza

I motori di inferenza specializzati come VLLm offrono funzionalità avanzate che aumentano in modo significativo le prestazioni di inferenza, tra cui il batching continuo, il caching KV efficiente e meccanismi di attenzione della memoria ottimizzati. È possibile ottimizzare i parametri di configurazione VLLm per migliorare le prestazioni di inferenza soddisfacendo al contempo i requisiti specifici dei casi d'uso e i modelli di carico di lavoro. Una configurazione corretta è essenziale per raggiungere la saturazione della GPU, in quanto consente di estrarre il massimo valore dalle costose risorse GPU, garantendo al contempo un throughput elevato, una bassa latenza e operazioni convenienti. Le seguenti ottimizzazioni vi aiuteranno a massimizzare le prestazioni della vostra implementazione vLLm su EKS.

Configurazioni VLLm di benchmark

Per ottimizzare i parametri di configurazione VLLM in base al tuo caso d'uso, esegui il benchmark di diverse impostazioni utilizzando uno strumento completo di benchmarking dell'inferenza come GuideLM. Questo raccoglierà metriche chiave come il throughput della richiesta al secondo (RPS), la latenza (E2E), il time to first token (TTFT) e end-to-end la latenza di coda (TPOT) per confrontare diverse configurazioni.

Configurazione vLLM di base

Questa è la configurazione di base utilizzata per eseguire VLLm:

Esegui GuideLLM con questa configurazione di base per stabilire una linea di base delle prestazioni. Per questo test, GuidellM è configurato per generare 1 richiesta al secondo, con richieste a 256 token e risposte a 128 token.

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"

Output previsto:

Risultati del benchmark di base

Configurazione VLLm ottimizzata

Regola i parametri VLLm per utilizzare meglio le risorse della GPU e la parallelizzazione:

Applica queste modifiche alla distribuzione in esecuzione utilizzando il comando 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"}
]'

Verifica che il pod VLLm sia nello stato: Ready 1/1

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

Output previsto:

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

Quindi esegui nuovamente GuideLM utilizzando gli stessi valori di benchmarking di prima:

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"

Output previsto:

Risultati di benchmark ottimizzati

Risultati del benchmarking

Calcola i risultati del benchmarking in una tabella per la configurazione vLLM di base e ottimizzata:

Le configurazioni vLLM ottimizzate hanno migliorato significativamente il throughput di inferenza (RPS) e ridotto la latenza (E2E, TTFT) con solo un lieve aumento di millisecondi della latenza di coda (TPOT). Questi risultati dimostrano come vLLM migliori in modo significativo le prestazioni di inferenza, consentendo a ciascun contenitore di elaborare più richieste in meno tempo per un funzionamento conveniente.