**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 unter, 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.
# Beschleunigen Sie das Laden von Modellen auf Amazon EKS
Wenn Sie große Sprachmodelle (LLMs) auf Amazon EKS bereitstellen, wirkt sich die Ladezeit des Modells direkt darauf aus, wie schnell Pods mit der Bearbeitung von Inferenzanforderungen beginnen können. Dies gilt insbesondere bei Scale-Up-Ereignissen, wenn neue Pods oder Knoten das Modell laden müssen, bevor der Datenverkehr verarbeitet werden kann. Der Modellstart besteht aus zwei Phasen, die Sie durch Optimieren und Kompilieren des Artefakt-Caches verbessern können:
+ **Laden von Gewichten ** — Streaming von Modellgewichtsdateien von Amazon S3 in den GPU-Speicher mithilfe von [ Run:ai Model Streamer. ](https://github.com/run-ai/runai-model-streamer)
+ **torch.compile ** — Kompilieren des Berechnungsdiagramms des Modells in optimierte fusionierte Kernel. CUDA/Triton Diese Kompilierung wird beim ersten Start ausgeführt und kann sich je nach Modellgröße erheblich auf die Startzeit auswirken.
Dieses Thema zeigt, wie Sie die Performance von Run:ai Model Streamer und das Torch.compile-Caching optimieren können, um beide Phasen des Modellladevorgangs zu reduzieren. Das vollständige Verfahren zur Bereitstellung von vLLM auf Amazon EKS zu Inferenzzwecken finden Sie unter. [&Servermodelle auf Amazon EKS laden](ml-inference-load-serve-model.md)
## Optimieren Sie den S3-Netzwerkpfad im EKS-Automatikmodus
Wenn Sie im EKS-Automatikmodus mit GPU-Knoten in privaten Subnetzen arbeiten, empfehlen wir die Verwendung eines [ Gateway-VPC-Endpunkts für S3]({aws-docs-url}/vpc/latest/privatelink/vpc-endpoints-s3.html), um den Netzwerkpfad zwischen Ihren Knoten und S3 zu optimieren. Mit dem Gateway-VPC-Endpunkt bleibt der Datenverkehr zu S3 im AWS Netzwerk und umgeht das NAT-Gateway vollständig, sodass es keine Obergrenze für die gemeinsame Bandbreite und keine NAT-Datenverarbeitungsgebühr pro GB gibt. Wenn der Datenverkehr ohne den Gateway-VPC-Endpunkt ein NAT-Gateway passiert, wird das NAT-Gateway während der Skalierung zu einem gemeinsamen Engpass, wenn mehrere Knoten das Modell gleichzeitig abrufen.
Im EKS-Automatikmodus werden Knoten in der Regel in privaten Subnetzen platziert, sodass der Verkehr zu S3 standardmäßig über ein NAT-Gateway fließt. Ein NAT-Gateway bietet eine Bandbreite von bis zu 100 Gbit/s und 55.000 gleichzeitige Verbindungen pro Ziel. Diese Bandbreite wird jedoch von allen Knoten im privaten Subnetz gemeinsam genutzt. Während eines Scale-Up-Events konkurrieren mehrere Knoten, die das vollständige Modell gleichzeitig herunterladen, um dieselbe NAT-Gateway-Bandbreite, was das Laden der Modellgewichte auf allen Knoten verlangsamen kann.
## Run:ai Leistungsoptimierung von Model Streamer
Inferenz-Engines wie vLLM und sGLang verwenden Run:ai Model Streamer als alternativen Mechanismus zum Laden von Gewichten beim Start der Inferenz.
Standardmäßig verwendet Run:ai Model Streamer konservative Parallelitätseinstellungen, wenn Modellgewichtsdateien von S3 heruntergeladen werden. Durch das Erhöhen der Parallelität beim Herunterladen und der Chunk-Größe wird die Ladezeit der Modellgewichte reduziert, da mehr Daten parallel heruntergeladen werden.
### Berechnen Sie die optimale Parallelität
Berechnen Sie den optimalen Parallelitätswert wie folgt:
```
concurrency = ceil(total_model_size_gb / chunk_size_gb)
```
Ersetzen Sie den `concurrency` Wert, den Sie verwenden, basierend auf Ihrer Modell- und Chunk-Größe. In der folgenden Tabelle finden Sie einige Beispiele. Zum Beispiel mit einem 67-GB-Modell und einer 4-GB-Chunk-Größe:`ceil(67 / 4) = 17`.
| Modellgröße | Chunk-Größe | Nebenläufigkeit |
| --- | --- | --- |
| 10 GB | 4 GB | 3 |
| 67 GB | 4 GB | 17 |
| 140 GB | 4 GB | 35 |
### Wenden Sie die Konfiguration an
Fügen Sie Ihrer Inferenzcontainer-Spezifikation die folgenden Argumente und Umgebungsvariablen hinzu:
+ `--tensor-parallel-size`— Der Grad der Tensorparallelität (TP) entspricht in der Regel der Mindestanzahl an GPUs, die je nach Modellgröße erforderlich sind, um das Modell in den GPU-Speicher einzupassen. Beispielsweise erfordert ein 67-GB-Modell für einen `p5.48xlarge` Instance-Typ mindestens 2 GPUs. Stellen Sie ihn daher auf ein. `2`
+ `concurrency`und `distributed` (in`--model-loader-extra-config`) — Auf `concurrency` den berechneten Wert für Ihr Modell setzen. `true`Nur `distributed` bei Verwendung der Tensorparallelität auf (TP > 1) setzen. Wenn diese Option aktiviert ist, streamt jeder tensorparallele Rang seinen eigenen Gewichtungs-Shard direkt von Amazon S3, anstatt dass Rang 0 alle Gewichtungen lädt und an die anderen Ränge sendet. Dadurch wird die Ladeleistung für Bereitstellungen mit mehreren GPUs erheblich verbessert. Lassen Sie es nicht gesetzt (oder`false`) für TP=1, wenn es keinen Vorteil bietet. Diese Option erfordert die vLLM V1-Architektur. Sie ist nicht kompatibel mit`--enforce-eager`, wodurch der V0-Pfad erzwungen wird. Wenn Sie beide zusammen verwenden, kommt es entweder zu einem Fehler oder es wird stillschweigend auf nicht verteiltes Laden zurückgegriffen.
+ `RUNAI_STREAMER_CHUNK_BYTESIZE`— 4 GB Blockgröße. Dieser Wert zeigt bei allen Benchmarks durchweg die beste Leistung. Größere Blöcke reduzieren die Anzahl der S3-Anfragen und verbessern den Durchsatz bei Instances mit hoher Bandbreite.
+ `RUNAI_STREAMER_S3_REQUEST_TIMEOUT_MS`— Per-request Timeout in Millisekunden. Ermöglicht eine schnellere Wiederholung bei langsamen S3-Antworten.
+ `RUNAI_STREAMER_S3_LOW_SPEED_LIMIT`— Mindestübertragungsgeschwindigkeit in Byte pro Sekunde, bevor eine Anfrage als langsam eingestuft und erneut versucht wird.
```
containers:
- name: vllm-inference
image: vllm/vllm-openai:v0.21.0
command:
- python3
- -m
- vllm.entrypoints.openai.api_server
args:
# ... your existing args ...
- --model=s3://
- --tensor-parallel-size={{2}}
- --load-format=runai_streamer
- --model-loader-extra-config={"concurrency":{{17}},"distributed":{{true}}}
env:
- name: RUNAI_STREAMER_CHUNK_BYTESIZE
value: {{"4294967296"}}
- name: RUNAI_STREAMER_S3_REQUEST_TIMEOUT_MS
value: {{"3000"}}
- name: RUNAI_STREAMER_S3_LOW_SPEED_LIMIT
value: {{"1048576"}}
```
## Optimiere den Kaltstart von torch.compile
Der `torch.compile` Schritt im Prozess der Inferenzverarbeitung verfolgt den Berechnungsgraphen eines Modells (die Abfolge der mathematischen Operationen) und kompiliert ihn zu optimierten fusionierten Kerneln. CUDA/Triton Dabei werden die Modellgewichte nicht kompiliert, sondern nur die Operationen, die sie transformieren.
Inferenz-Engines verwenden torch.compile, weil es automatisch erhebliche Durchsatzverbesserungen bietet, ohne dass ein spezielles Kernel-Engineering pro Modellarchitektur erforderlich ist:
+ **Kernelfusion ** — Mehrere kleine Operationen (Residual-Add, Layernorm, Aktivierung) werden zu einem einzigen Kernel zusammengeführt, wodurch GPU-Speicher-Roundtrips reduziert werden.
+ **Weniger Kernel-Starts ** — Eine Transformer-Ebene fällt von \~15-30 separaten CUDA-Kerneln auf \~10 fusionierte Kernel ab, was den CPU-Overhead pro Start spart.
+ **Python wurde aus dem Hotpath entfernt ** — Der gesamte Forward-Durchlauf wird zu einem C\+\+-Ausführungsplan, wodurch der Python-Interpreter-Overhead zwischen den Vorgängen entfällt.
+ **Bessere CUDA-Graph-Kompatibilität ** — Kompilierte statische Graphen werden nahezu ohne CPU-Overhead erfasst und wiedergegeben.
+ **Automatische Optimierung ** — Funktioniert für jede Modellarchitektur. Der Durchsatz verbessert sich im Vergleich zum Eager-Modus um 5 bis 30%.
Die folgende Tabelle zeigt gängige Inferenz-Server-Engines, die torch.compile verwenden.
| Engine | Verwendung von torch.compile |
| --- | --- |
| [vLLM ](https://docs.vllm.ai/en/latest/) | Standardmäßig aktiviert (V1-Architektur) |
| [sGLang ](https://github.com/sgl-project/sglang) | Fakultativ über `--enable-torch-compile` |
| TensorRT-LLM | Der neue Pfad unterstützt dies zusammen mit der Erstellung älterer Engines |
### Das Torch.compile-Kaltstartproblem
Der Nachteil von torch.compile besteht darin, dass der erste Inferenz-Pod kompiliert werden muss, bevor er Anfragen bearbeiten kann. Diese Kompilierung kann je nach Modellgröße mehrere Minuten dauern. Die kompilierten Artefakte sind klein (\~15 MB für ein 60-GB-Modell), verlängern aber die Kaltstartzeit erheblich. Da die Artefakte klein und für eine bestimmte Konfiguration deterministisch sind, können Sie sie zwischenspeichern und wiederverwenden, um die Kaltstarteinbußen beim nachfolgenden Pod- und Node-Start zu vermeiden.
Die Artefakte bestehen aus:
+ Generierte Triton-Kernel-Quelldateien
+ Kompilierte Kernel-Binärdateien () `.cubin`
+ Graphstruktur, die Kernel-Aufrufe sequenziert
### Der Kompromiss zwischen --enforce-eager
vLLM aktiviert standardmäßig die Erfassung von CUDA-Diagrammen. `torch.compile` Das `--enforce-eager` Flag schaltet beide aus und führt das Modell im Eager-Modus aus, in dem jede Operation sofort über den Python-Interpreter ausgeführt wird. Da im Eager-Modus sowohl die Kompilierung als auch die Diagrammerfassung übersprungen werden, werden einige Schnellstartanleitungen — einschließlich der Basisbereitstellung in [&Servermodelle auf Amazon EKS laden](ml-inference-load-serve-model.md) — verwendet`--enforce-eager`, um Pods schneller zu starten.
`--enforce-eager`ist eine gute Wahl für Debugging, Bereitstellungen mit eingeschränktem Arbeitsspeicher oder für Modellarchitekturen, die sich nicht sauber kompilieren lassen, und Sie können sie aus diesen Gründen in der Produktion verwenden. Es kann zwar die Beeinträchtigung durch einen `torch.compile` Kaltstart abschwächen, wir empfehlen jedoch andere Methoden, wie z. B. die in den nachfolgenden Abschnitten auf dieser Seite beschriebenen, um die Laufzeitleistung in der Produktion aufrechtzuerhalten.
Machen Sie sich mit dem Kompromiss zwischen Startzeit und Laufzeitleistung vertraut, der vor der Bereitstellung in der Produktion besteht. `--enforce-eager`
| Aspekt | `--enforce-eager`Mit (Eager-Modus) | Standard (torch.compile \+ CUDA-Grafiken) |
| --- | --- | --- |
| Startzeit | Schnell — kein Kompilieren oder Erfassen von Diagrammen | Langsamer Kaltstart (das Problem wurde durch [Zwischenspeichern Sie Torch.compile-Artefakte auf demselben Knoten](#model-loading-torch-compile-same-node) und gelöst[Pre-warm Torch.compile-Cache auf neuen Knoten](#model-loading-torch-compile-new-nodes)) |
| Steady-state Durchsatz | Ausgangswert | \~5— 30% mehr durch Kernelfusion |
| Per-token Latenz (kleine Charge) | Höherer CPU-Startaufwand | Viel niedriger — CUDA-Grafiken geben Kernel-Starts als eine Einheit wieder |
| GPU-Arbeitsspeicher | Niedriger und vorhersehbarer | Höher — Bei der Diagrammerfassung werden Pufferpools vorab zugewiesen |
| Debuggbarkeit | Bereinigen Sie die Stack-Traces pro Vorgang | In den generierten Kerneln tauchen Fehler auf |
## Zwischenspeichern Sie Torch.compile-Artefakte auf demselben Knoten
Diese Technik kommt zur Anwendung, wenn Sie eine Inferenzengine verwenden, die dies unterstützt`torch.compile`, z. B. vLLM (standardmäßig aktiviert) oder sGLang (aktiviert über). `--enable-torch-compile` Sie funktioniert nur, wenn sie aktiv `torch.compile` ist, das heißt, wenn sie `--enforce-eager` nicht gesetzt ist. ** **
**Wichtig**
Diese Verbesserung hat keine Wirkung, wenn sie deaktiviert `torch.compile` ist. In vLLM wird das `--enforce-eager` Flag `torch.compile` vollständig deaktiviert, sodass keine Artefakte kompiliert oder zwischengespeichert werden. Wenn Sie der Basisbereitstellung [&Servermodelle auf Amazon EKS laden](ml-inference-load-serve-model.md) mit gefolgt sind`--enforce-eager`, erstellt vLLM das Cache-Verzeichnis, schreibt aber nie in dieses. Entfernen Sie, `--enforce-eager` bevor Sie diese Technik anwenden.
Wenn eine Inferenz-Engine den Berechnungsgraphen des Modells beim ersten Start kompiliert, können Sie die resultierenden optimierten Kernel im lokalen Speicher des Knotens zwischenspeichern. Nachfolgende Pods auf demselben Knoten verwenden die zwischengespeicherten Artefakte wieder und überspringen den Kompilierungsschritt vollständig, was die Startzeit erheblich verkürzen kann.
### Fügen Sie Cache-Umgebungsvariablen hinzu
Fügen Sie Ihrer Inferenzcontainer-Spezifikation die folgenden Umgebungsvariablen hinzu, um torch.compile und Triton-Cache auf einen persistenten Hostpfad umzuleiten. Wir empfehlen, den lokalen NVMe-Instance-Speicher des Knotens zu verwenden und nicht das Root-Volume des Amazon Elastic Block Store (Amazon EBS) für den. `hostPath` Beispiele finden Sie im folgenden Abschnitt.
```
containers:
- name: vllm-inference
env:
# torch.compile cache
- name: XDG_CACHE_HOME
value: {{"/compile-cache"}}
- name: TORCHINDUCTOR_CACHE_DIR
value: {{"/compile-cache/inductor"}}
- name: TRITON_CACHE_DIR
value: {{"/compile-cache/triton"}}
volumeMounts:
- name: compile-cache
mountPath: /compile-cache
volumes:
- name: compile-cache
hostPath:
path: {{/mnt/k8s-disks/0/compile-cache}}
type: DirectoryOrCreate
```
### Stellen Sie den Cache-Pfad auf den NVMe-Instance-Speicher ein
Kompilierte Artefakte und gestreamte Gewichte profitieren von einer schnellen lokalen Speicherung. Auf GPU-Instances mit NVMe-Instance-Speicher (wie G-family P-family AND-Instances) liefert der Instance-Speicher ungefähr 30 GB/s, verglichen mit etwa 1 GB/s für das Amazon EBS-Root-Volume. Leiten Sie den Cache `hostPath` zum NVMe-Mountpoint weiter, um den Durchsatz zu optimieren.
**Wichtig**
Das `hostPath` Volumen verwendet`type: DirectoryOrCreate`. Wenn Sie es auf einen Pfad verweisen, der nicht vom NVMe-Instance-Speicher unterstützt wird, erstellt Kubernetes das Verzeichnis stattdessen im Hintergrund auf dem Amazon EBS-Root-Volume. Der Cache funktioniert immer noch, aber Sie verlieren den NVMe-Leistungsvorteil ohne Fehler oder Warnung.
Der NVMe-Mountpoint und die Art und Weise, wie Sie ihn aktivieren, unterscheiden sich zwischen EKS-Automatikmodus und selbstverwalteten Knoten:
| Datenverarbeitung | NVMe-Mountpunkt | Wie aktiviere ich den NVMe-Instance-Speicher |
| --- | --- | --- |
| EKS Auto Mode | `/mnt/.ephemeral` | Wird dynamisch auf der Grundlage des angeforderten kurzlebigen Speichers aktiviert. EKS Auto Mode formatiert und mountet den NVMe-Instance-Speicher als RAID 0-Array, wenn die Instance über mehrere NVMe-Laufwerke verfügt. Dies gilt nur, wenn die `ephemeralStorage.size` angeforderte Kapazität kleiner NodeClass ist als die verfügbare NVMe-Kapazität der Instance. Wenn die angeforderte Kapazität gleich oder größer als die NVMe-Kapazität `ephemeralStorage.size` ist, verwendet EKS Auto Mode den Instance-Speicher nicht und der Pfad wird stattdessen vom Root-EBS-Volume unterstützt. |
| Self-managed Karpenter | `/mnt/k8s-disks/0` | `instanceStorePolicy: RAID0`Im Karpenter angesiedelt. `EC2NodeClass` Ohne sie ignoriert Karpenter die Instance-Store-Volumes und der Pfad wird nicht von NVMe unterstützt. |
Stellen Sie für den EKS-Automatikmodus das auf in Ihrer Containerspezifikation ein: `hostPath` `/mnt/.ephemeral/compile-cache`
```
volumes:
- name: compile-cache
hostPath:
path: /mnt/.ephemeral/compile-cache
type: DirectoryOrCreate
```
Für selbstverwaltetes Karpenter setzen Sie das auf `/mnt/k8s-disks/0/compile-cache` in Ihrer `hostPath` Containerspezifikation:
```
volumes:
- name: compile-cache
hostPath:
path: /mnt/k8s-disks/0/compile-cache
type: DirectoryOrCreate
```
### Beispielergebnisse
1. Der erste Pod auf einem Knoten führt torch.compile aus und schreibt die kompilierten Kernel auf den Host. `/compile-cache`
1. Nachfolgende Pods auf demselben Knoten mounten den vorhandenen Cache und überspringen die Kompilierung vollständig, wodurch der Kaltstart von torch.compile von \~50—80 s auf \~4—6 s reduziert wird.
Die folgende Tabelle zeigt die Verbesserung beim Caching auf demselben Knoten für verschiedene Modellgrößen:
| Modellgröße | erster Pod torch.compile (kein Cache) | Nachfolgende Pods torch.compile (derselbe Knoten) |
| --- | --- | --- |
| 60 GB | \~53 s | \~6 s |
| 140 GB | \~60 s | \~6 s |
| 640 GB | \~80 | \~6 s |
## Pre-warm Torch.compile-Cache auf neuen Knoten
Diese Technik eignet sich, wenn Sie Inferenzen mit mehreren Knoten mit homogenen GPUs, Tensorparallelität, Modellen und Versionen über Knoten hinweg ausführen. PyTorch Die Technik in [Zwischenspeichern Sie Torch.compile-Artefakte auf demselben Knoten](#model-loading-torch-compile-same-node) konzentriert sich auf den Fall eines einzelnen Knotens, aber neue Knoten, die bei Scale-Up-Ereignissen hinzugefügt werden, beginnen mit einem leeren Torch.compile-Cache. Um die Kaltstartzeit auf neu initialisierten Knoten weiter zu reduzieren, können Sie einen Caching-Mechanismus implementieren, der die kompilierten Torch.compile-Artefakte in S3 speichert und sie vorab auf neue Knoten herunterlädt, wenn sie dem Cluster beitreten.
Der allgemeine Ansatz lautet:
1. Nachdem der erste Pod das Modell auf dem ersten Knoten kompiliert hat, laden Sie die torch.compile-Artefakte (\~15 MB) in einen S3-Bucket hoch.
1. Wenn neue Knoten dem Cluster beitreten, laden Sie die zwischengespeicherten Artefakte in den lokalen Speicher des Knotens herunter, bevor Inferenz-Pods geplant werden.
Sie können beispielsweise eine implementieren, DaemonSet die auf GPU-Knoten ausgeführt wird und den Torch.compile-Cache verpackt und auf S3 hochlädt. Es kann diesen Cache auch mit dem lokalen Knotenspeicher synchronisieren, bevor Inferenz-Pods auf neuen Knoten geplant werden.
### Überlegungen zum knotenübergreifenden Caching
Wenn Sie Torch.compile-Artefakte knotenübergreifend zwischenspeichern, sind die kompilierten Kernel nur gültig, wenn diese Parameter zwischen dem Knoten, der den Cache generiert hat, und dem Knoten, der ihn verbraucht, übereinstimmen. Ihr Caching-Mechanismus muss all dies berücksichtigen. Eine Nichtübereinstimmung bei einem Parameter führt zu einem ungültigen Cache, der eine Neukompilierung erzwingt oder Laufzeitfehler verursacht. Ihr Caching-Tool muss Artefakte anhand dieser Parameter unterscheiden, indem es sie beispielsweise in den S3-Objektschlüssel oder die Cache-Verzeichnisstruktur integriert.
| Parameter | Warum dies wichtig ist |
| --- | --- |
| GPU-Typ | Kompilierte Kernel sind GPU-architecture-specific (zum Beispiel sm\_90 für H100 und sm\_89 für L4). |
| Tensorparallelität (TP) | Verschiedene TP-Grade erzeugen unterschiedliche Partitionen für Berechnungsgraphen. |
| Modell | Jede Modellarchitektur und Größe wird zu unterschiedlichen Kerneln kompiliert. |
| PyTorch Version | Die Compiler-Interna von Torch.compile und Triton können zu grundlegenden Änderungen zwischen den Versionen führen. |
### Beispielergebnisse
Bei Richtungstests mit knotenübergreifender Cache-Vorwärmung (Qwen3-6-35B-A3B, 67 GB, 2x GPU mit TP=2 auf p5.48xlarge) erreichte der erste Pod auf neu skalierten Knoten dieselbe Startzeit wie nachfolgende Pods auf einem bereits warmen Knoten:
| Szenario | Erster Pod | Zweiter Pod |
| --- | --- | --- |
| Ohne knotenübergreifendes Caching (neuer Knoten) | 65 s | 16er |
| Mit knotenübergreifendem Caching (neuer Knoten) | 16 Sekunden | 16er |
## Beispiel für einen Einsatz
Das folgende Beispiel kombiniert die Run:ai Model Streamer-Leistungsoptimierung und einen Torch.compile-Cache in einem einzigen vLLM-Bereitstellungsmanifest. Ersetzen Sie die Platzhalterwerte durch Ihre eigene Konfiguration:
+ `serviceAccountName`— Servicekonto mit einer IAM-Rolle, das Amazon S3-Lesezugriff auf Ihren Modell-Bucket hat.
+ `nodeSelector`(`karpenter.sh/nodepool`) — Ihr GPU-Knotenpoolname (zum Beispiel`gpu-nodepool-g6e-12xlarge`).
+ `--model`— Amazon S3-Pfad zu Ihren Modellgewichten.
+ `--model-loader-extra-config`— `concurrency` Basierend auf Ihrer Modellgröße festlegen:`ceil(total_model_size_gb / chunk_size_gb)`. Zum Beispiel ergibt `ceil(67 / 4) = 17` ein 67-GB-Modell mit einer 4-GB-Chunk-Größe.
+ `--tensor-parallel-size`— Stellen Sie den Tensorparallelgrad (TP) auf die Mindestanzahl von GPUs ein, die erforderlich ist, um das Modell in den Arbeitsspeicher einzupassen.
+ `hostPath``path`— NVMe-Instance-Speicher-Mountpoint für selbstverwaltete Knoten mit Karpenter. Verwenden Sie stattdessen im EKS-Automatikmodus. `/mnt/.ephemeral/compile-cache` Details dazu finden Sie unter [Zwischenspeichern Sie Torch.compile-Artefakte auf demselben Knoten](#model-loading-torch-compile-same-node).
```
apiVersion: apps/v1
kind: Deployment
metadata:
name: vllm-inference
namespace: default
spec:
replicas: 1
selector:
matchLabels:
app: vllm-inference
template:
metadata:
labels:
app: vllm-inference
spec:
serviceAccountName:
nodeSelector:
karpenter.sh/nodepool:
tolerations:
- key: nvidia.com/gpu
operator: Exists
effect: NoSchedule
containers:
- name: vllm
image: vllm/vllm-openai:v0.21.0
command:
- python3
- -m
- vllm.entrypoints.openai.api_server
args:
- --model=s3:///
- --load-format=runai_streamer
- --model-loader-extra-config={"concurrency":{{17}},"distributed":{{true}}}
- --tensor-parallel-size={{2}}
- --max-model-len=8192
- --host=0.0.0.0
- --port=8000
ports:
- containerPort: 8000
name: http
env:
# Run:ai streamer tuning
- name: RUNAI_STREAMER_CHUNK_BYTESIZE
value: {{"4294967296"}}
- name: RUNAI_STREAMER_S3_REQUEST_TIMEOUT_MS
value: {{"3000"}}
- name: RUNAI_STREAMER_S3_LOW_SPEED_LIMIT
value: {{"1048576"}}
# torch.compile cache
- name: XDG_CACHE_HOME
value: {{"/compile-cache"}}
- name: TORCHINDUCTOR_CACHE_DIR
value: {{"/compile-cache/inductor"}}
- name: TRITON_CACHE_DIR
value: {{"/compile-cache/triton"}}
resources:
requests:
cpu: "12"
memory: 80Gi
nvidia.com/gpu: "2"
limits:
nvidia.com/gpu: "2"
volumeMounts:
- name: compile-cache
mountPath: /compile-cache
startupProbe:
httpGet:
path: /health
port: 8000
periodSeconds: 10
failureThreshold: 60
initialDelaySeconds: 30
readinessProbe:
httpGet:
path: /health
port: 8000
periodSeconds: 5
timeoutSeconds: 3
volumes:
- name: compile-cache
hostPath:
path: {{/mnt/k8s-disks/0/compile-cache}}
type: DirectoryOrCreate
```