**Bantu meningkatkan halaman ini **
Terjemahan disediakan oleh mesin penerjemah. Jika konten terjemahan yang diberikan bertentangan dengan versi bahasa Inggris aslinya, utamakan versi bahasa Inggris.
Untuk berkontribusi pada panduan pengguna ini, pilih GitHub ** tautan ** Edit halaman ini di yang terletak di panel kanan setiap halaman.
Terjemahan disediakan oleh mesin penerjemah. Jika konten terjemahan yang diberikan bertentangan dengan versi bahasa Inggris aslinya, utamakan versi bahasa Inggris.
# Mempercepat pemuatan model di Amazon EKS
Saat Anda menerapkan model bahasa besar (LLM) di Amazon EKS, waktu pemuatan model secara langsung memengaruhi seberapa cepat Pod dapat mulai melayani permintaan inferensi. Hal ini terutama berlaku selama peristiwa peningkatan skala, ketika Pod atau node baru harus memuat model sebelum menangani lalu lintas. Startup model memiliki dua fase yang dapat Anda tingkatkan dengan penyetelan dan kompilasi caching artefak:
+ **Pemuatan bobot ** — Streaming file bobot model dari Amazon S3 ke memori GPU menggunakan [ Run:ai Model Streamer](https://github.com/run-ai/runai-model-streamer).
+ **torch.compile ** — Mengkompilasi grafik komputasi model menjadi kernel yang menyatu yang dioptimalkan. CUDA/Triton Kompilasi ini berjalan pada startup pertama dan dapat secara signifikan mempengaruhi waktu mulai tergantung pada ukuran model.
Topik ini menunjukkan bagaimana Anda dapat mengoptimalkan kinerja Run:ai Model Streamer dan caching torch.compile untuk mengurangi kedua fase proses pemuatan model. Untuk prosedur lengkap penerapan vLLM di Amazon EKS untuk inferensi, lihat. [Mu & at Model Serve di Amazon EKS](ml-inference-load-serve-model.md)
## Optimalkan jalur jaringan S3 pada Mode Otomatis EKS
Jika Anda menjalankan Mode Otomatis EKS dengan node GPU di subnet pribadi, sebaiknya gunakan titik akhir [ Gateway VPC untuk S3 untuk ]({aws-docs-url}/vpc/latest/privatelink/vpc-endpoints-s3.html) mengoptimalkan jalur jaringan antara node Anda dan S3. Dengan titik akhir Gateway VPC, lalu lintas ke S3 tetap berada di AWS jaringan dan melewati NAT Gateway sepenuhnya sehingga tidak ada batas bandwidth bersama dan tidak ada biaya pemrosesan data NAT per GB. Tanpa titik akhir Gateway VPC, ketika lalu lintas melintasi Gerbang NAT, NAT Gateway menjadi hambatan bersama selama peningkatan skala ketika beberapa node menarik model pada saat yang bersamaan.
Mode Otomatis EKS biasanya menempatkan node di subnet pribadi, sehingga lalu lintas ke S3 mengalir melalui NAT Gateway secara default. NAT Gateway menyediakan bandwidth hingga 100 Gbps dan 55.000 koneksi simultan per tujuan. Namun, bandwidth itu dibagi di setiap node di subnet pribadi. Selama acara peningkatan skala, beberapa node yang mengunduh model lengkap sekaligus bersaing untuk bandwidth NAT Gateway yang sama, yang dapat memperlambat pemuatan bobot model pada semuanya.
## Run:ai Penyetelan kinerja Model Streamer
Mesin inferensi seperti vLLM dan SGlang menggunakan Run:ai Model Streamer sebagai mekanisme alternatif untuk memuat bobot selama startup inferensi.
Secara default, Run:ai Model Streamer menggunakan pengaturan konkurensi konservatif saat mengunduh file berat model dari S3. Meningkatkan konkurensi unduhan dan ukuran potongan mengurangi waktu pemuatan bobot model dengan mengunduh lebih banyak data secara paralel.
### Hitung konkurensi optimal
Hitung nilai konkurensi optimal sebagai:
```
concurrency = ceil(total_model_size_gb / chunk_size_gb)
```
Ganti `concurrency` nilai yang Anda gunakan berdasarkan ukuran model dan ukuran potongan. Lihat tabel berikut untuk beberapa contoh. Misalnya, dengan model 67 GB dan ukuran potongan 4 GB:`ceil(67 / 4) = 17`.
| Ukuran model | Ukuran potongan | Bersamaan |
| --- | --- | --- |
| 10 GB | 4 GB | 3 |
| 67GB | 4 GB | 17 |
| 140GB | 4 GB | 35 |
### Terapkan konfigurasi
Tambahkan argumen dan variabel lingkungan berikut ke spesifikasi wadah inferensi Anda:
+ `--tensor-parallel-size`- Derajat paralel tensor (TP) biasanya adalah jumlah minimum GPU yang diperlukan untuk menyesuaikan model dalam memori GPU berdasarkan ukuran model. Misalnya, model 67 GB pada jenis `p5.48xlarge` instance memerlukan setidaknya 2 GPU, jadi setel ke`2`.
+ `concurrency`and `distributed` (in`--model-loader-extra-config`) — Setel `concurrency` ke nilai yang dihitung untuk model Anda. Set `distributed` el ke `true` hanya saat menggunakan paralelisme tensor (TP > 1). Saat diaktifkan, setiap peringkat tensor-paralel mengalirkan pecahan bobotnya sendiri dari Amazon S3 secara langsung, alih-alih peringkat 0 memuat semua bobot dan menyiarkan ke peringkat lain. Ini secara signifikan meningkatkan kinerja pemuatan untuk penerapan multi-GPU. Biarkan tidak disetel (atau`false`) untuk TP = 1, di mana tidak memberikan manfaat. Opsi ini membutuhkan arsitektur vLLM V1. Ini tidak kompatibel dengan`--enforce-eager`, yang memaksa jalur V0; menggunakan keduanya bersama-sama akan membuat kesalahan atau diam-diam kembali ke pemuatan yang tidak terdistribusi.
+ `RUNAI_STREAMER_CHUNK_BYTESIZE`- Ukuran potongan 4 GB. Nilai ini secara konsisten menunjukkan kinerja terbaik di seluruh tolok ukur. Potongan yang lebih besar mengurangi jumlah permintaan S3 dan meningkatkan throughput pada instans bandwidth tinggi.
+ `RUNAI_STREAMER_S3_REQUEST_TIMEOUT_MS`— batas Per-request waktu dalam milidetik. Memungkinkan percobaan ulang lebih cepat pada respons S3 yang lambat.
+ `RUNAI_STREAMER_S3_LOW_SPEED_LIMIT`Kecepatan transfer minimum dalam byte per detik sebelum permintaan dianggap lambat dan dicoba kembali.
```
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"}}
```
## Optimalkan start dingin torch.compile
`torch.compile`Langkah dalam proses penyajian inferensi melacak grafik komputasi model (urutan operasi matematika) dan mengkompilasinya menjadi kernel yang menyatu yang dioptimalkan. CUDA/Triton Itu tidak mengkompilasi bobot model — hanya operasi yang mengubahnya.
Mesin inferensi menggunakan torch.compile karena memberikan peningkatan throughput yang signifikan secara otomatis, tanpa rekayasa kernel khusus per arsitektur model:
+ **Kernel fusion ** — Beberapa operasi kecil (residual add, layernorm, aktivasi) digabungkan menjadi satu kernel, mengurangi perjalanan pulang pergi memori GPU.
+ **Lebih sedikit peluncuran kernel ** — Lapisan transformator turun dari \~15-30 kernel CUDA terpisah menjadi \~10 kernel yang menyatu, menghemat overhead CPU per peluncuran.
+ **Python dihapus dari hot path ** — Seluruh forward pass menjadi rencana eksekusi C\+\+, menghilangkan overhead penerjemah Python di antara operasi.
+ **Kompatibilitas Grafik CUDA yang lebih baik ** - Grafik statis yang dikompilasi ditangkap dan diputar ulang dengan overhead CPU mendekati nol.
+ **Optimasi otomatis ** - Bekerja untuk arsitektur model apa pun. Throughput meningkat 5-30% dibandingkan mode yang ingin.
Tabel berikut menunjukkan mesin penyajian inferensi umum yang menggunakan torch.compile.
| Engine | penggunaan torch.compile |
| --- | --- |
| [VlLM ](https://docs.vllm.ai/en/latest/) | Diaktifkan secara default (arsitektur V1) |
| [SgLang ](https://github.com/sgl-project/sglang) | Opsional melalui `--enable-torch-compile` |
| TensorRT-LLM | Jalur baru mendukungnya bersama build mesin lama |
### Masalah start dingin torch.compile
Pengorbanan torch.compile adalah bahwa Pod inferensi pertama harus dikompilasi sebelum dapat melayani permintaan. Kompilasi ini dapat memakan waktu selama beberapa menit tergantung pada ukuran model. Artefak yang dikompilasi berukuran kecil (\~ 15 MB untuk model 60 GB) tetapi secara signifikan meningkatkan waktu mulai dingin. Karena artefak kecil dan deterministik untuk konfigurasi tertentu, Anda dapat menyimpan dan menggunakannya kembali untuk menghilangkan penalti start dingin pada awal Pod dan node berikutnya.
Artefak terdiri dari:
+ File sumber kernel Triton yang dihasilkan
+ Biner kernel yang dikompilasi () `.cubin`
+ Struktur grafik yang mengurutkan panggilan kernel
### Pengorbanan --enforce-antusias
vLLM mengaktifkan `torch.compile` dan menangkap grafik CUDA secara default. `--enforce-eager`Bendera mematikan keduanya dan menjalankan model dalam mode penasaran, di mana setiap operasi dieksekusi segera melalui penerjemah Python. Karena mode yang ingin melewatkan kompilasi dan pengambilan grafik, beberapa panduan memulai cepat — termasuk penerapan dasar di [Mu & at Model Serve di Amazon EKS](ml-inference-load-serve-model.md) — digunakan `--enforce-eager` untuk memulai Pod lebih cepat.
`--enforce-eager`adalah pilihan yang valid untuk debugging, penerapan terbatas memori, atau arsitektur model yang tidak dikompilasi dengan bersih, dan Anda dapat menggunakannya dalam produksi karena alasan tersebut. Meskipun dapat mengurangi penalti start `torch.compile` dingin, kami merekomendasikan pendekatan lain, seperti yang dirinci di bagian selanjutnya di halaman ini, untuk mempertahankan kinerja runtime dalam produksi.
Pahami pertukaran waktu startup versus kinerja waktu proses sebelum menerapkan dalam produksi. `--enforce-eager`
| Aspek | Dengan `--enforce-eager` (mode bersemangat) | Default (torch.compile\+grafik CUDA) |
| --- | --- | --- |
| Waktu startup | Cepat - tidak ada langkah kompilasi atau pengambilan grafik | Mulai dingin lambat (masalah diselesaikan oleh [Artefak cache torch.compilation pada node yang sama](#model-loading-torch-compile-same-node) dan[Pre-warm torch.compile cache pada node baru](#model-loading-torch-compile-new-nodes)) |
| Steady-state keluaran | Baseline | \~ 5-30% lebih tinggi dari fusi kernel |
| Per-token latensi (batch kecil) | Overhead peluncuran CPU yang lebih tinggi | Jauh lebih rendah - Grafik CUDA memutar ulang kernel diluncurkan sebagai satu unit |
| Memori GPU | Lebih rendah dan lebih dapat diprediksi | Lebih tinggi — penangkapan grafik pra-mengalokasikan kumpulan buffer |
| Debuggabilitas | Bersihkan jejak tumpukan per operasi | Permukaan kesalahan di dalam kernel yang dihasilkan |
## Artefak cache torch.compilation pada node yang sama
Teknik ini berlaku ketika Anda menggunakan mesin inferensi yang mendukung`torch.compile`, seperti vLLM (diaktifkan secara default) atau sgLang (diaktifkan melalui). `--enable-torch-compile` Ia bekerja hanya ketika `torch.compile` aktif, yaitu, ketika ** tidak `--enforce-eager` ** diatur.
**penting**
Peningkatan ini tidak berpengaruh jika `torch.compile` dinonaktifkan. Di vLLM, `--enforce-eager` bendera dinonaktifkan `torch.compile` sepenuhnya, sehingga tidak ada artefak yang dikompilasi atau di-cache. Jika Anda mengikuti penerapan dasar [Mu & at Model Serve di Amazon EKS](ml-inference-load-serve-model.md) dengan`--enforce-eager`, vLLM membuat direktori cache tetapi tidak pernah menulis ke sana. Hapus `--enforce-eager` sebelum menerapkan teknik ini.
Ketika mesin inferensi mengkompilasi grafik komputasi model pada startup pertama, Anda dapat menyimpan kernel yang dioptimalkan yang dihasilkan pada penyimpanan lokal node. Pod berikutnya pada node yang sama menggunakan kembali artefak yang di-cache dan melewati langkah kompilasi sepenuhnya, yang secara signifikan dapat mengurangi waktu startup.
### Tambahkan variabel lingkungan cache
Tambahkan variabel lingkungan berikut ke spesifikasi wadah inferensi Anda untuk mengarahkan torch.compile dan cache Triton ke jalur host persisten. Sebaiknya gunakan penyimpanan instans NVMe lokal node dan bukan volume root Amazon Elastic Block Store (Amazon EBS) untuk. `hostPath` Sebagai contoh, lihat bagian berikut.
```
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
```
### Atur jalur cache ke penyimpanan instance NVMe
Artefak yang dikompilasi dan bobot yang dialirkan mendapat manfaat dari penyimpanan lokal yang cepat. Pada instans GPU dengan penyimpanan instans NVMe (seperti G-family dan P-family instance), penyimpanan instans menghasilkan sekitar 30 GB/s, dibandingkan dengan kira-kira 1 GB/s untuk volume root Amazon EBS. Arahkan cache `hostPath` ke titik pemasangan NVMe untuk mengoptimalkan throughput.
**penting**
Vol `hostPath` ume menggunakan`type: DirectoryOrCreate`. Jika Anda mengarahkannya ke jalur yang tidak didukung oleh penyimpanan instans NVMe, Kubernetes secara diam-diam membuat direktori pada volume root Amazon EBS sebagai gantinya. Cache masih berfungsi, tetapi Anda kehilangan manfaat kinerja NVMe tanpa kesalahan atau peringatan.
Titik pemasangan NVMe dan cara Anda mengaktifkannya berbeda antara Mode Otomatis EKS dan node yang dikelola sendiri:
| Hitung | Titik pemasangan NVMe | Cara mengaktifkan penyimpanan instans NVMe |
| --- | --- | --- |
| Mode Otomatis EKS | `/mnt/.ephemeral` | Diaktifkan secara dinamis berdasarkan penyimpanan sementara yang diminta. Mode Otomatis EKS memformat dan memasang penyimpanan instans NVMe sebagai array RAID 0 ketika instance memiliki beberapa drive NVMe hanya jika yang `ephemeralStorage.size` diminta di dalam NodeClass lebih kecil dari kapasitas NVMe instans yang tersedia. Jika permintaan sama `ephemeralStorage.size` dengan atau lebih besar dari kapasitas NVMe, Mode Otomatis EKS tidak menggunakan penyimpanan instans dan jalur didukung oleh volume EBS root sebagai gantinya. |
| Self-managed Karpenter | `/mnt/k8s-disks/0` | Terletak `instanceStorePolicy: RAID0` di Karpenter`EC2NodeClass`. Tanpa itu, Karpenter mengabaikan volume penyimpanan instance dan jalur tidak didukung oleh NVMe. |
Untuk Mode Otomatis EKS, atur `hostPath` ke `/mnt/.ephemeral/compile-cache` dalam spesifikasi wadah Anda:
```
volumes:
- name: compile-cache
hostPath:
path: /mnt/.ephemeral/compile-cache
type: DirectoryOrCreate
```
Untuk Karpenter yang dikelola sendiri, atur `hostPath` ke `/mnt/k8s-disks/0/compile-cache` dalam spesifikasi wadah Anda:
```
volumes:
- name: compile-cache
hostPath:
path: /mnt/k8s-disks/0/compile-cache
type: DirectoryOrCreate
```
### Hasil sampel
1. Pod pertama pada node menjalankan torch.compile dan menulis kernel yang dikompilasi ke host`/compile-cache`.
1. Pod berikutnya pada node yang sama memasang cache yang ada dan melewatkan kompilasi sepenuhnya, yang mengurangi cold start torch.compilation dari \~50—80 detik menjadi \~4—6 detik.
Tabel berikut menunjukkan peningkatan dengan caching simpul yang sama untuk ukuran model yang berbeda:
| Ukuran model | Pod torch.compile pertama (tidak ada cache) | Pods berikutnya torch.compile (simpul yang sama) |
| --- | --- | --- |
| 60GB | \~53 detik | \~6 detik |
| 140GB | \~60-an | \~6 detik |
| 640GB | \~80-an | \~6 detik |
## Pre-warm torch.compile cache pada node baru
Teknik ini berlaku saat Anda menjalankan inferensi multi-node dengan GPU homogen, paralelisme tensor, model, dan versi di seluruh node. PyTorch Teknik ini [Artefak cache torch.compilation pada node yang sama](#model-loading-torch-compile-same-node) berfokus pada kasus simpul tunggal, tetapi node baru ditambahkan selama peristiwa peningkatan skala dimulai dengan cache torch.compile kosong. Untuk lebih mengurangi waktu mulai dingin pada node yang baru diinisialisasi, Anda dapat menerapkan mekanisme caching yang menyimpan artefak torch.compile yang dikompilasi di S3 dan mengunduhnya ke node baru saat mereka bergabung dengan cluster.
Pendekatan umum adalah:
1. Setelah Pod pertama mengkompilasi model pada node pertama, unggah artefak torch.compile (\~15 MB) ke bucket S3.
1. Ketika node baru bergabung dengan cluster, unduh artefak yang di-cache ke penyimpanan lokal node sebelum Pod inferensi dijadwalkan.
Misalnya, Anda dapat mengimplementasikan DaemonSet yang berjalan pada node GPU yang mengemas dan mengunggah cache torch.compilation ke S3. Itu juga dapat menyinkronkan cache itu ke penyimpanan node lokal sebelum Pod inferensi dijadwalkan pada node baru.
### Pertimbangan untuk caching lintas simpul
Saat Anda menyimpan artefak torch.compilation di seluruh node, kernel yang dikompilasi hanya valid jika parameter ini cocok antara node yang menghasilkan cache dan node yang mengkonsumsinya. Mekanisme caching Anda harus memperhitungkan semua ini. Ketidakcocokan pada parameter apa pun menghasilkan cache yang tidak valid yang memaksa kompilasi ulang atau menyebabkan kesalahan runtime. Alat caching Anda harus membedakan artefak dengan parameter ini, misalnya, dengan memasukkannya ke dalam kunci objek S3 atau struktur direktori cache.
| Parameter | Mengapa itu penting |
| --- | --- |
| Jenis GPU | Kernel yang dikompilasi adalah GPU-architecture-specific (misalnya, sm\_90 untuk H100 vs sm\_89 untuk L4). |
| Paralelisme tensor (TP) | Derajat TP yang berbeda menghasilkan partisi grafik komputasi yang berbeda. |
| Model | Setiap arsitektur model dan ukuran dikompilasi menjadi kernel yang berbeda. |
| PyTorch versi | Internal kompiler torch.compilation dan Triton dapat memperkenalkan perubahan besar antar versi. |
### Hasil sampel
Dalam pengujian terarah dengan pra-pemanasan cache lintas simpul (Qwen3-6-35B-A3B, 67 GB, 2x GPU dengan TP=2 pada p5.48xlarge), Pod pertama pada node yang baru diskalakan mencapai waktu startup yang sama dengan Pod berikutnya pada node yang sudah hangat:
| Skenario | Pod Pertama | Pod Kedua |
| --- | --- | --- |
| Tanpa caching lintas simpul (node baru) | 65 tahun | 16s |
| Dengan caching lintas simpul (node baru) | 16s | 16s |
## Contoh penerapan
Contoh berikut menggabungkan penyetelan kinerja Run:ai Model Streamer dan cache torch.compile ke dalam manifes Deployment vLLM tunggal. Ganti nilai placeholder dengan konfigurasi Anda sendiri:
+ `serviceAccountName`— Akun layanan dengan peran IAM yang memiliki akses baca Amazon S3 ke bucket model Anda.
+ `nodeSelector`(`karpenter.sh/nodepool`) — Nama kumpulan simpul GPU Anda (misalnya,`gpu-nodepool-g6e-12xlarge`).
+ `--model`— Jalur Amazon S3 ke bobot model Anda.
+ `--model-loader-extra-config`— Tetapkan `concurrency` berdasarkan ukuran model Anda:`ceil(total_model_size_gb / chunk_size_gb)`. Misalnya, model 67 GB dengan ukuran potongan 4 GB memberikan`ceil(67 / 4) = 17`.
+ `--tensor-parallel-size`— Atur derajat paralel tensor (TP) ke jumlah minimum GPU yang diperlukan untuk menyesuaikan model dalam memori.
+ `hostPath``path`— Instance NVMe menyimpan titik pemasangan untuk node yang dikelola sendiri dengan Karpenter. Pada Mode Otomatis EKS, gunakan sebagai `/mnt/.ephemeral/compile-cache` gantinya. Lihat [Artefak cache torch.compilation pada node yang sama](#model-loading-torch-compile-same-node) untuk rincian selengkapnya.
```
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
```