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:

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

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

Terapkan konfigurasi

Tambahkan argumen dan variabel lingkungan berikut ke spesifikasi wadah inferensi Anda:

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://<MODEL_PATH>
  - --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.compileLangkah 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:

Tabel berikut menunjukkan mesin penyajian inferensi umum yang menggunakan torch.compile.

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:

Pengorbanan --enforce-antusias

vLLM mengaktifkan torch.compile dan menangkap grafik CUDA secara default. --enforce-eagerBendera 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 — digunakan --enforce-eager untuk memulai Pod lebih cepat.

--enforce-eageradalah 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

Artefak cache torch.compilation pada node yang sama

Teknik ini berlaku ketika Anda menggunakan mesin inferensi yang mendukungtorch.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.

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.

Titik pemasangan NVMe dan cara Anda mengaktifkannya berbeda antara Mode Otomatis EKS dan node yang dikelola sendiri:

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

Tabel berikut menunjukkan peningkatan dengan caching simpul yang sama untuk ukuran model yang berbeda:

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

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.

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:

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:

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: <SERVICE_ACCOUNT_NAME>
      nodeSelector:
        karpenter.sh/nodepool: <GPU_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://<BUCKET_NAME>/<MODEL_PATH>
            - --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