Unterstützung für die Verbesserung dieser Seite beitragen

Die vorliegende Übersetzung wurde maschinell erstellt. Im Falle eines Konflikts oder eines Widerspruchs zwischen dieser übersetzten Fassung und der englischen Fassung (einschließlich infolge von Verzögerungen bei der Übersetzung) ist die englische Fassung maßgeblich.

Um zu diesem Benutzerhandbuch beizutragen, wählen Sie den GitHub Link Diese Seite bearbeiten auf, der sich im rechten Bereich jeder Seite befindet.

Die vorliegende Übersetzung wurde maschinell erstellt. Im Falle eines Konflikts oder eines Widerspruchs zwischen dieser übersetzten Fassung und der englischen Fassung (einschließlich infolge von Verzögerungen bei der Übersetzung) ist die englische Fassung maßgeblich.

Schnellstart: LLM-Inferenz mit hohem Durchsatz mit vLLM auf Amazon EKS

Einführung

Diese Schnellstartanleitung bietet eine exemplarische Vorgehensweise für die Bereitstellung von Large Language Models (LLMs) auf Amazon EKS mithilfe von vLLM und GPUs für textbasierte Echtzeit-Inferenzanwendungen.

Die Lösung nutzt Amazon EKS für die Container-Orchestrierung und vLLM für effizientes Model Serving, sodass Sie skalierbare KI-Anwendungen mit GPU-Beschleunigung und Inferenz-Serving mit hohem Durchsatz erstellen können. Zu Demonstrationszwecken wird das Llama 3.1 8B Instruct-Modell verwendet, aber Sie können jedes andere LLM einsetzen, das von vLLM unterstützt wird (eine Liste der unterstützten Modelle finden Sie in der VllM-Dokumentation). Um die LLM-Inferenz zu testen, verwenden wir eine Chatbot-Beispielanwendung, die auf dem Projekt basiert. nextjs-vllm-ui Schließlich verwenden wir GuideLM, um die vLLM-Konfigurationsparameter zu vergleichen und zu optimieren, um die Inferenzleistung zu optimieren.

vLLM-Architektur auf EKS

Wenn Sie dieses Verfahren abgeschlossen haben, verfügen Sie über einen vLLM-Inferenzendpunkt, der für Durchsatz und geringe Latenz optimiert ist, und Sie können über eine Chat-Frontend-Anwendung mit einem Lama-Modell interagieren, was einen typischen Anwendungsfall für Chatbot-Assistenten und andere LLM-basierte Anwendungen veranschaulicht.

Weitere Anleitungen und erweiterte Ressourcen zur Implementierung finden Sie in unserem EKS-Best-Practices-Leitfaden für AI/ML Workloads und produktionsreife KI in EKS-Inferenzdiagrammen.

Bevor Sie beginnen

Bevor Sie beginnen, stellen Sie sicher, dass Sie über Folgendes verfügen:

Modellspeicher mit Amazon S3 einrichten

Speichern Sie große LLM-Dateien effizient in Amazon S3, um Speicher von Rechenressourcen zu trennen. Dieser Ansatz rationalisiert Modellaktualisierungen, senkt die Kosten und vereinfacht die Verwaltung von Produktionskonfigurationen. S3 verarbeitet riesige Dateien zuverlässig, und durch die Integration mit Kubernetes über den Mountpoint CSI-Treiber können Pods auf Modelle wie lokalen Speicher zugreifen — zeitaufwändige Downloads beim Start sind nicht erforderlich. Gehen Sie wie folgt vor, um einen S3-Bucket zu erstellen, ein LLM hochzuladen und es als Volume in Ihrem Inference Serving-Container zu mounten.

Auf EKS sind auch andere Speicherlösungen für das Modell-Caching verfügbar, z. B. EFS und FSx Lustre. Weitere Informationen finden Sie unter EKS Best Practices.

Festlegen von Umgebungsvariablen

Erstellen Sie einen eindeutigen Namen für einen neuen Amazon S3 S3-Bucket, den wir später in diesem Handbuch erstellen werden. Verwenden Sie nach der Erstellung für alle Schritte denselben Bucket-Namen. Beispiel:

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

Definieren Sie Umgebungsvariablen und speichern Sie sie in einer Datei:

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

Laden Sie Umgebungsvariablen in Ihre Shell-Umgebung. Wenn Sie die aktuelle Shell-Umgebung schließen und eine neue öffnen, stellen Sie sicher, dass Sie die Umgebungsvariablen mit demselben Befehl neu beziehen:

source .env-quickstart-vllm

Erstellen Sie einen S3-Bucket zum Speichern von Modelldateien

Erstellen Sie einen S3-Bucket zum Speichern von Modelldateien:

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

Laden Sie das Modell von Hugging Face herunter

Hugging Face ist einer der wichtigsten Model-Hubs für den Zugriff auf LLM-Modelle. Um das Lama-Modell herunterzuladen, müssen Sie die Modelllizenz akzeptieren und die Token-Authentifizierung einrichten:

Lege eine Umgebungsvariable mit deinem Hugging Face Face-Token fest:

export HF_TOKEN=your_token_here

Installieren Sie das Pip3-Paket, falls es nicht bereits in Ihrer Umgebung installiert ist. Beispielbefehl in Amazon Linux 2023:

sudo dnf install -y python3-pip

Installieren Sie die Hugging Face CLI:

pip install huggingface-hub

Laden Sie das Modell Llama-3.1-8B-Instruct von Hugging Face (~15 GB) herunter. Verwenden Sie dabei das --exclude Flag, um das alte PyTorch Format zu überspringen und nur die optimierten Dateien im Safetensors-Format herunterzuladen, wodurch die Download-Größe reduziert wird und gleichzeitig die volle Kompatibilität mit gängigen Inferenz-Engines erhalten bleibt:

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

Überprüfen Sie die heruntergeladenen Dateien:

$ ls llama-3.1-8b-instruct

Die erwartete Ausgabe sollte in etwa wie folgt aussehen:

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

Laden Sie Modelldateien hoch

Aktivieren Sie AWS Common Runtime (CRT) für eine verbesserte S3-Übertragungsleistung. Der CRT-basierte Transferclient bietet verbesserten Durchsatz und Zuverlässigkeit bei Operationen mit großen Dateien:

aws configure set s3.preferred_transfer_client crt

Laden Sie das Modell hoch:

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

Die erwartete Ausgabe sollte in etwa wie folgt aussehen:

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

Richten Sie S3-Mountpoint-CSI-Berechtigungen ein

Der S3 Mountpoint CSI-Treiber ermöglicht die native Integration zwischen Kubernetes und S3, sodass Pods direkt auf Modelldateien zugreifen können, als wären sie lokaler Speicher, sodass beim Start des Containers keine lokalen Kopien erforderlich sind.

Erstellen Sie eine IAM-Richtlinie, damit der S3-Mountpoint aus Ihrem S3-Bucket lesen kann:

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}/*\"]}]}"

Finden Sie den IAM-Rollennamen, der vom S3 Mountpoint CSI-Treiber verwendet wird, indem Sie die Anmerkungen zum S3 CSI-Treiber-Dienstkonto überprüfen:

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

Fügen Sie Ihre IAM-Richtlinie der S3 Mountpoint CSI-Rolle hinzu:

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

Wenn S3 Mountpoint CSI nicht im Cluster installiert ist, folgen Sie den Bereitstellungsschritten unter. Leitfaden für bewährte Methoden zur Cluster-Einrichtung für Echtzeit-Inferenz in Amazon EKS

Mounten Sie den S3-Bucket als Kubernetes-Volume

Erstellen Sie ein Persistent Volume (PV) und einen Persistent Volume Claim (PVC), um über mehrere Inferenz-Pods hinweg schreibgeschützten Zugriff auf den S3-Bucket zu ermöglichen. Der ReadOnlyMany Zugriffsmodus gewährleistet den gleichzeitigen Zugriff auf Modelldateien, während der CSI-Treiber die Installation des S3-Buckets übernimmt:

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

Einrichtung der GPU-Infrastruktur

Cluster-Knoten

Wir verwenden den EKS-Cluster, der in erstellt wurdeLeitfaden für bewährte Methoden zur Cluster-Einrichtung für Echtzeit-Inferenz in Amazon EKS. Dieser Cluster umfasst Karpenter-Knotenpools, die GPU-fähige Knoten mit ausreichend Knotenspeicher zum Herunterladen des vLLM-Container-Images bereitstellen können. Wenn Sie Ihren benutzerdefinierten EKS-Cluster verwenden, stellen Sie sicher, dass dieser GPU-fähige Knoten starten kann.

Auswahl der Instance

Für die richtige Instanzauswahl für die LLM-Inferenz muss sichergestellt werden, dass der verfügbare GPU-Speicher ausreicht, um Modellgewichte zu laden. Die Modellgewichte für Llama 3.1 8B Instruct betragen ungefähr 16 GB (Größe der Modelldateien .safetensor), daher müssen wir dem vllm-Prozess mindestens diese Menge an Speicher zur Verfügung stellen, um das Modell zu laden.

Amazon EC2 G5-Instances mit A10G GPUs und EC2 G6-Instances mit L4 bieten GPUs beide 24 GB VRAM pro GPU, ausreichend für das Laden von Llama 3.1 8B Instruct-Gewichten. Wenn Sie ein Modell mit größeren Gewichtungen bereitstellen, sollten Sie die Verwendung eines Instance-Typs mit mehreren GPUs oder eines Setups mit mehreren Knoten in Betracht ziehen.

NVIDIA-Gerätetreiber

NVIDIA-Treiber bieten die erforderliche Laufzeitumgebung für Container, um effizient auf GPU-Ressourcen zugreifen zu können. Sie ermöglicht die Zuweisung und Verwaltung von GPU-Ressourcen innerhalb von Kubernetes und stellt sie als planbare Ressourcen GPUs zur Verfügung.

Unser Cluster verwendet EKS Bottlerocket AMIs, das alle erforderlichen NVIDIA-Gerätetreiber und -Plugins auf allen GPU-fähigen Knoten enthält und so den sofortigen GPU-Zugriff für containerisierte Workloads ohne zusätzliche Einrichtung gewährleistet. Wenn Sie andere Arten von EKS-Knoten verwenden, müssen Sie sicherstellen, dass alle erforderlichen Treiber und Plugins installiert sind.

Testen Sie die GPU-Infrastruktur

Testen Sie die GPU-Fähigkeiten Ihres Clusters, indem Sie die folgenden Schritte ausführen, um sicherzustellen, dass Pods auf NVIDIA-GPU-Ressourcen zugreifen und auf GPU-fähigen Knoten korrekt planen können.

Stellen Sie einen Nvidia SMI Test-Pod bereit:

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

Überprüfe die Pod-Logs, um zu überprüfen, ob GPU-Details aufgeführt sind, ähnlich wie in der folgenden Ausgabe (nicht unbedingt dasselbe GPU-Modell):

$ 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                                                             |
+-----------------------------------------------------------------------------------------+

Diese Ausgabe zeigt, dass Pods erfolgreich auf GPU-Ressourcen zugreifen können.

WICHTIG: Dieser Pod verwendet eine NodeSelector-Konfiguration, die auf die Karpenter-Knotenpools abgestimmt ist. Leitfaden für bewährte Methoden zur Cluster-Einrichtung für Echtzeit-Inferenz in Amazon EKS Wenn Sie verschiedene Knotenpools verwenden, stellen Sie sicher, dass der Pod entsprechend mit NodeSelector und Tolerations übereinstimmt.

Stellen Sie Inference Container bereit

Der Serving-Stack bestimmt sowohl die Leistung als auch die Skalierbarkeit Ihrer Inferenzinfrastruktur. vLLM hat sich zu einer führenden Lösung für Produktionsbereitstellungen entwickelt. Die Architektur von vLLM bietet kontinuierliches Batching für dynamische Anforderungsverarbeitung, Kernel-Optimierungen für schnellere Inferenzen und eine effiziente GPU-Speicherverwaltung. PagedAttention Diese Funktionen, kombiniert mit einer produktionsbereiten REST-API und der Unterstützung gängiger Modellformate, machen es zu einer optimalen Wahl für leistungsstarke Inferenzbereitstellungen.

Wählen Sie das Deep Learning-Container-Image AWS

AWS Deep Learning Containers (DLCs) bieten voroptimierte Umgebungen mit Sicherheitsupdates, AWS Infrastrukturkompatibilität und optimierten Treiberkonfigurationen. Dies reduziert die Komplexität der Bereitstellung und den Wartungsaufwand und stellt gleichzeitig die Produktionsbereitschaft sicher.

Für diese Bereitstellung verwenden wir den AWS DLC für vLLM 0.9, der Nvidia-Bibliotheken und optimierte GPU-Leistungskonfigurationen enthält, die speziell auf die Inferenz von Transformatormodellen auf GPU-Instanzen abgestimmt sind. AWS

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

Wenden Sie die vLLM-Kubernetes-Manifeste an

Es gibt mehrere Möglichkeiten, vLLM in EKS bereitzustellen. In diesem Handbuch wird die vLLM-Bereitstellung mithilfe einer Kubernetes-Bereitstellung demonstriert. Dabei handelt es sich um eine Kubernetes-native und einfache Methode für den Einstieg. Erweiterte Bereitstellungsoptionen finden Sie in den vLLM-Dokumenten und KI-on-EKS-Blueprints.

Definieren Sie Bereitstellungsparameter mithilfe von Kubernetes-Manifesten, um die Ressourcenzuweisung, die Platzierung von Knoten, Integritätstests, die Bereitstellung des Dienstes usw. zu kontrollieren. Konfigurieren Sie Ihre Bereitstellung so, dass ein GPU-fähiger Pod mithilfe AWS des Deep Learning-Container-Images für vLLM ausgeführt wird. Legen Sie optimierte Parameter für die LLM-Inferenz fest und machen Sie den VLLM-OpenAPI-kompatiblen Endpunkt über den Load Balancer-Dienst verfügbar: 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

Überprüfen Sie, ob sich der vLLM-Pod im folgenden Zustand befindet: Ready 1/1

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

Erwartete Ausgabe:

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

Es kann mehrere Minuten dauern, bis das Container-Image abgerufen wird und vLLM Modelldateien in den GPU-Speicher lädt. Fahren Sie erst fort, wenn der Pod bereit und verfügbar ist.

Machen Sie den Dienst verfügbar

Stellen Sie den Inferenzendpunkt lokal über die Kubernetes-Portweiterleitung zur lokalen Entwicklung und zum Testen bereit. Lassen Sie diesen Befehl in einem separaten Terminalfenster laufen:

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

Der Load AWS Balancer Controller erstellt automatisch einen Network Load Balancer, der den vLLM-Dienstendpunkt extern verfügbar macht. Rufen Sie den NLB-Endpunkt ab, indem Sie Folgendes ausführen:

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

Müssen Sie den AWS Load Balancer Controller installieren? Folgen Sie den Bereitstellungsschritten unterInternetverkehr mit AWS Load Balancer Controller weiterleiten.

Bilden von Inferenzen

Überprüfen Sie den Inferenz-Pod

Überprüfen Sie die Funktionalität des Inferenzcontainers lokal über den weitergeleiteten Port. Senden Sie eine Verbindungsanforderung und stellen Sie sicher, dass die Antwort den HTTP-Code 200 enthält:

$ 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

Testen Sie die Inferenzfunktionen und validieren Sie die externe Konnektivität, indem Sie eine Abschlussanfrage über den NLB-Endpunkt an das LLM senden:

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
  }'

Dieser Endpunkt folgt dem OpenAI-API-Format, wodurch er mit bestehenden Anwendungen kompatibel ist und gleichzeitig konfigurierbare Generierungsparameter wie Antwortlänge und Temperatur zur Steuerung der Ausgangsdiversität bereitstellt.

Führen Sie die Chatbot-App aus

Zur Veranschaulichung wird in diesem Handbuch eine Chatbot-Beispielanwendung ausgeführt, die Project verwendet nextjs-vllm-ui, um Benutzerinteraktionen mit dem Modell zu veranschaulichen.

Führen Sie eine Chatbot-Benutzeroberfläche als Docker-Container aus, der den Port 3000 dem Localhost zuordnet und eine Verbindung zum vLLM-NLB-Endpunkt herstellt:

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

Öffnen Sie Ihren Webbrowser und navigieren Sie zu: http://localhost:3000/

Sie sollten die Chat-Oberfläche sehen, über die Sie mit dem Lama-Modell interagieren können.

Chat-Benutzeroberfläche

Optimieren Sie die Leistung von Inferenzen

Spezialisierte Inferenz-Engines wie vLLM bieten erweiterte Funktionen, die die Inferenzleistung erheblich steigern, darunter kontinuierliches Batching, effizientes KV-Caching und optimierte Memory-Aufmerksamkeitsmechanismen. Sie können die vLLM-Konfigurationsparameter anpassen, um die Inferenzleistung zu verbessern und gleichzeitig Ihre spezifischen Anwendungsfallanforderungen und Workload-Muster zu erfüllen. Die richtige Konfiguration ist unerlässlich, um eine GPU-Sättigung zu erreichen. Sie stellt sicher, dass Sie den größtmöglichen Nutzen aus teuren GPU-Ressourcen ziehen und gleichzeitig einen hohen Durchsatz, geringe Latenz und einen kostengünstigen Betrieb bieten. Die folgenden Optimierungen helfen Ihnen dabei, die Leistung Ihrer vLLM-Bereitstellung auf EKS zu maximieren.

Benchmark-vLLM-Konfigurationen

Um die vLLM-Konfigurationsparameter an Ihren Anwendungsfall anzupassen, vergleichen Sie verschiedene Einstellungen mit einem umfassenden Inferenz-Benchmarking-Tool wie GuideLM. Dabei werden wichtige Kennzahlen wie der Durchsatz von Anfragen pro Sekunde (RPS), end-to-end Latenz (E2E), Time to First Token (TTFT) und Tail-Latenz (TPOT) erfasst, um verschiedene Konfigurationen zu vergleichen.

Basiskonfiguration von vLLM

Dies ist die Basiskonfiguration, die für die Ausführung von vLLM verwendet wurde:

Führen Sie GuideLM mit diesem Basis-Setup aus, um eine Leistungsbasis festzulegen. Für diesen Test ist GuideLLM so konfiguriert, dass es 1 Anfrage pro Sekunde generiert, mit 256 Token-Anfragen und 128-Token-Antworten.

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"

Erwartete Ausgabe:

Benchmark-Baseline-Ergebnisse

Optimierte vLLM-Konfiguration

Passen Sie die vLLM-Parameter an, um die GPU-Ressourcen und die Parallelisierung besser zu nutzen:

Wenden Sie diese Änderungen mit dem Befehl kubectl patch auf die laufende Bereitstellung an:

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"}
]'

Überprüfen Sie, ob sich der vLLM-Pod im folgenden Zustand befindet: Ready 1/1

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

Erwartete Ausgabe:

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

Führen Sie dann GuideLM erneut aus und verwenden Sie dabei dieselben Benchmarking-Werte wie zuvor:

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"

Erwartete Ausgabe:

Optimierte Benchmark-Ergebnisse

Benchmarking-Ergebnisse

Berechnen Sie die Benchmarking-Ergebnisse in einer Tabelle sowohl für die Basiskonfiguration als auch für die optimierte vLLM-Konfiguration:

Die optimierten vLLM-Konfigurationen verbesserten den Inferenzdurchsatz (RPS) erheblich und reduzierten die Latenz (E2E, TTFT) bei nur einer geringfügigen Erhöhung der Tail-Latenz (TPOT) um nur eine Millisekunde. Diese Ergebnisse zeigen, wie vLLM die Inferenzleistung erheblich verbessert, sodass jeder Container mehr Anfragen in kürzerer Zeit verarbeiten kann, was einen kostengünstigen Betrieb ermöglicht.