**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: High-throughput LLM-Inferenz 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).](https://docs.vllm.ai/en/latest/models/supported_models.html#list-of-text-only-language-models) [Um die LLM-Inferenz zu testen, verwenden wir eine Chatbot-Beispielanwendung, die auf dem Projekt nextjs-vllm-ui basiert.](https://github.com/yoziru/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 Anwendungen veranschaulicht. LLM-based
[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](https://docs.aws.amazon.com/eks/latest/best-practices/aiml.html).](https://github.com/awslabs/ai-on-eks/tree/main/blueprints/inference/inference-charts)
## Bevor Sie beginnen
Bevor Sie beginnen, stellen Sie sicher, dass Sie über Folgendes verfügen:
+ Ein Amazon EKS-Cluster mit den folgenden Hauptkomponenten: Karpenter Nodepools mit der G5- oder G6 EC2-Instance-Familie, das auf Ihren GPU-enabled Worker-Knoten installierte NVIDIA Device Plugin und der installierte S3 Mountpoint CSI-Treiber. Um dieses Basis-Setup zu erstellen, folgen Sie den Schritten unter bis zum Abschluss von Schritt \#4. [Leitfaden für bewährte Methoden zur Cluster-Einrichtung für Echtzeit-Inferenz in Amazon EKS](ml-realtime-inference-cluster.md)
+ Ein Hugging Face Face-Konto. Informationen zur Registrierung finden Sie unter https://huggingface.co/login.
## 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 for Lustre. Weitere Informationen finden Sie unter [EKS](https://docs.aws.amazon.com/eks/latest/best-practices/aiml-storage.html) 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:
1. Akzeptieren Sie die Llama 3.1 8B Instruct-Modelllizenz unter https://huggingface.co/meta-llama/Llama-3.1-8B-Instruct.
1. Generieren Sie ein Zugriffstoken (gehen Sie zu Ihrem Profil > Einstellungen > Zugriffstoken und erstellen Sie dann ein neues Token mit dem Token-Typ Lesen).
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](https://huggingface.co/docs/huggingface_hub/main/en/guides/cli):
```
pip install huggingface-hub
```
Laden Sie Llama-3.1-8B-Instruct das Modell von Hugging Face (\~15 GB) herunter und 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-based Transferclient bietet einen verbesserten Durchsatz und eine höhere 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](ml-realtime-inference-cluster.md)
### 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 <
### Cluster-Knoten
Wir verwenden den EKS-Cluster, der in erstellt wurde[Leitfaden für bewährte Methoden zur Cluster-Einrichtung für Echtzeit-Inferenz in Amazon EKS](ml-realtime-inference-cluster.md). 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 G5 EC2-Instances](https://aws.amazon.com/ec2/instance-types/g5/) mit A10G-GPUs und [G6 EC2-Instances mit L4-GPUs](https://aws.amazon.com/ec2/instance-types/g6/) bieten 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 Gewichten 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, sodass GPUs als planbare Ressourcen verfügbar sind.
Unser Cluster verwendet EKS Bottlerocket-AMIs, die alle erforderlichen NVIDIA-Gerätetreiber und -Plugins auf allen GPU-enabled Knoten enthalten und so den sofortigen GPU-Zugriff für containerisierte Workloads ohne zusätzliche Einrichtung gewährleisten. Wenn Sie andere Typen 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-enabled Knoten korrekt planen können.
Stellen Sie einen Nvidia SMI-Testpod bereit:
```
cat <
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](https://github.com/aws/deep-learning-containers/tree/master) (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. Dies ist eine Kubernetes-native einfache Möglichkeit, loszulegen. [Erweiterte Bereitstellungsoptionen finden Sie in den [vLLM-Dokumenten](https://docs.vllm.ai/en/latest/deployment/k8s.html) und den KI-on-EKS-Blueprints.](https://awslabs.github.io/ai-on-eks/docs/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-enabled Pod mithilfe des AWS Deep Learning-Container-Images für vLLM ausgeführt wird. Legen Sie optimierte Parameter für die LLM-Inferenz fest und machen Sie den OpenAPI-compatible vLLM-Endpunkt über AWS den Load Balancer-Dienst verfügbar:
```
cat <
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 unter[Internetverkehr mit AWS Load Balancer Controller weiterleiten](aws-load-balancer-controller.md).
## 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 das Projekt [nextjs-vllm-ui](https://github.com/yoziru/nextjs-vllm-ui) verwendet, um Benutzerinteraktionen mit dem Modell zu veranschaulichen.
Führen Sie eine Chatbot-Benutzeroberfläche als Docker-Container aus, der 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 ::3000/ http://localhost
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.](https://github.com/vllm-project/guidellm) Dabei werden wichtige Kennzahlen wie der Durchsatz von Anfragen pro Sekunde (RPS), die End-to-End-Latenz (E2E), die Zeit bis zum ersten Token (TTFT) und die Zeit pro Ausgabetoken (TPOT) erfasst, um verschiedene Konfigurationen zu vergleichen.
### Basiskonfiguration von vLLM
Dies ist die Basiskonfiguration, die für die Ausführung von vLLM verwendet wurde:
| vLLM-Parameter | Description |
| --- | --- |
| tensor\_parallel\_size: 1 | Verteilen Sie das Modell auf 1 GPU |
| gpu\_memory\_utilization: 0,90 | Reservieren Sie 10% GPU-Speicher für System-Overhead |
| max\_sequence\_length: 8192 | Maximale Gesamtlänge der Sequenz (Eingabe \+ Ausgabe) |
| max\_num\_seqs: 1 | Maximale Anzahl gleichzeitiger Anfragen pro GPU (Batching) |
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:
| vLLM-Parameter | Description |
| --- | --- |
| tensor\_parallel\_size: 1 | Bleib bei 1 GPU. Die Tensor-Parallelisierung muss der Anzahl der GPUs entsprechen, die von vLLM verwendet werden sollen |
| gpu\_memory\_utilization: 0.92 | Reduzieren Sie nach Möglichkeit den Overhead des GPU-Speichers und stellen Sie gleichzeitig sicher, dass vLLM weiterhin fehlerfrei läuft |
| max\_sequence\_length: 4096 | Passen Sie die maximale Sequenz an die Anforderungen Ihres Anwendungsfalls an. Eine niedrigere maximale Sequenz setzt Ressourcen frei, die für eine erhöhte Parallelisierung verwendet werden können |
| max\_num\_seqs: 8 | Eine Erhöhung der maximalen Sequenz erhöht den Durchsatz, erhöht aber auch die Latenz. Erhöhen Sie diesen Wert, um den Durchsatz zu maximieren und gleichzeitig sicherzustellen, dass die Latenz Ihren Anwendungsfallanforderungen entspricht |
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:
| Durchschnittswerte | Basiskonfiguration | Optimierte Konfiguration |
| --- | --- | --- |
| RPS | 0.23 req/sec | 0,86 req/sec |
| E2E | 12,99 s | 5,19 s |
| TTFT | 8637,2 ms | 147,9 ms |
| TOPF | 34,0 ms | 39,5 ms |
Die optimierten vLLM-Konfigurationen verbesserten den Inferenzdurchsatz (RPS) erheblich und reduzierten die Latenz (E2E, TTFT), wobei die Zeit pro Ausgabetoken (TPOT) nur geringfügig um eine Millisekunde verlängert wurde. 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.