Terjemahan disediakan oleh mesin penerjemah. Jika konten terjemahan yang diberikan bertentangan dengan versi bahasa Inggris aslinya, utamakan versi bahasa Inggris.
Penskalaan dan Kinerja Aplikasi
Tip
Jelajahi
Mengelola Artefak ML, Melayani Kerangka Kerja, dan Optimasi Startup
Menerapkan model machine learning (ML) di Amazon EKS memerlukan pertimbangan yang matang tentang bagaimana model diintegrasikan ke dalam gambar kontainer dan lingkungan runtime. Ini memastikan skalabilitas, reproduktifitas, dan pemanfaatan sumber daya yang efisien. Topik ini menjelaskan berbagai pendekatan untuk menangani artefak model ML, memilih kerangka kerja penyajian, dan mengoptimalkan waktu startup kontainer melalui teknik seperti pra-caching, semuanya disesuaikan untuk mengurangi waktu startup kontainer.
Menangani Artefak Model ML dalam Penerapan
Keputusan kuncinya adalah bagaimana menangani artefak model ML (seperti bobot dan konfigurasi) itu sendiri. Pilihannya memengaruhi ukuran gambar, kecepatan penerapan, frekuensi pembaruan model, dan overhead operasional. Perhatikan bahwa ketika mengacu pada penyimpanan “model”, kami mengacu pada artefak model (seperti parameter terlatih dan bobot model). Ada berbagai pendekatan untuk menangani artefak model ML di Amazon EKS. Masing-masing memiliki trade-off, dan yang terbaik tergantung pada ukuran model Anda, irama pembaruan, dan kebutuhan infrastruktur. Pertimbangkan pendekatan berikut dari yang paling sedikit hingga yang paling direkomendasikan:
-
Memanggang model ke dalam gambar wadah: Salin file model (misalnya, .safetensors, .pth, .h5) ke dalam gambar wadah (misalnya, Dockerfile) selama pembuatan gambar. Model adalah bagian dari gambar yang tidak dapat diubah. Kami merekomendasikan menggunakan pendekatan ini untuk model yang lebih kecil dengan pembaruan yang jarang. Ini memastikan konsistensi dan reproduktifitas, tidak memberikan penundaan pemuatan, dan menyederhanakan manajemen ketergantungan, tetapi menghasilkan ukuran gambar yang lebih besar, memperlambat build dan dorongan, memerlukan pembangunan kembali dan penempatan kembali untuk pembaruan model, dan ini tidak ideal untuk model besar karena throughput tarik registri.
-
Mengunduh model saat runtime: Saat startup container, aplikasi mengunduh model dari penyimpanan eksternal (misalnya, Amazon S3, didukung oleh S3 CRT untuk transfer throughput tinggi yang dioptimalkan menggunakan metode seperti Mountpoint untuk driver S3 CSI, AWS S3 CLI, atau CLI OSS s5cmd) melalui skrip dalam wadah init atau titik masuk. Kami merekomendasikan memulai dengan pendekatan ini untuk model besar dengan pembaruan yang sering. Ini membuat gambar kontainer tetap fokus code/runtime, memungkinkan pembaruan model yang mudah tanpa membangun kembali, mendukung pembuatan versi melalui metadata penyimpanan, tetapi memperkenalkan potensi kegagalan jaringan (memerlukan logika coba lagi), memerlukan otentikasi dan caching.
Untuk mempelajari lebih lanjut, lihat Mempercepat proses tarik
Melayani Model ML
Menyebarkan dan menyajikan model machine learning (ML) di Amazon EKS memerlukan pemilihan pendekatan penyajian model yang sesuai untuk mengoptimalkan latensi, throughput, skalabilitas, dan kesederhanaan operasional. Pilihannya tergantung pada jenis model Anda (misalnya, bahasa, model visi), tuntutan beban kerja (misalnya, inferensi waktu nyata), dan keahlian tim. Pendekatan umum termasuk Python-based pengaturan untuk pembuatan prototipe, server model khusus untuk fitur tingkat produksi, dan mesin inferensi khusus untuk kinerja dan efisiensi tinggi. Setiap metode melibatkan trade-off dalam kompleksitas pengaturan, kinerja, dan pemanfaatan sumber daya. Perhatikan bahwa kerangka kerja penyajian dapat meningkatkan ukuran gambar kontainer (beberapa GB) karena dependensi, yang berpotensi memengaruhi waktu startup—pertimbangkan untuk memisahkan menggunakan teknik penanganan artefak untuk mengurangi hal ini. Opsi terdaftar dari yang paling sedikit hingga yang paling direkomendasikan:
Menggunakan kerangka kerja Python (misalnya, FastAP, HuggingFace Transformers dengan PyTorch) Kembangkan aplikasi khusus menggunakan kerangka kerja Python, menyematkan file model (bobot, konfigurasi, tokenizer) dalam pengaturan node kontainer.
-
Kelebihan: Pembuatan prototipe yang mudah, Python-only tanpa infrastruktur tambahan, kompatibel dengan semua HuggingFace model, penerapan Kubernetes sederhana.
-
Kekurangan: Membatasi request/simple batching tunggal, pembuatan token lambat (tidak ada kernel yang dioptimalkan), memori tidak efisien, kurang scaling/monitoring, dan melibatkan waktu startup yang lama.
-
Rekomendasi: Gunakan untuk prototipe awal atau tugas simpul tunggal yang membutuhkan integrasi logika khusus.
Menggunakan kerangka kerja penyajian model khusus (misalnya, TensorRT-LLM, TGI) Mengadopsi server khusus seperti TensorRT-LLM atau TGI untuk inferensi ML, mengelola pemuatan model, perutean, dan pengoptimalan. Format dukungan ini seperti safetensors, dengan kompilasi opsional atau plugin.
-
Kelebihan: Menawarkan batching (static/in-flight atau continuous), kuantisasi (INT8, FP8, GPTQ), optimasi perangkat keras (NVIDIA, AMD, Intel, Inferentia), dan dukungan multi-GPU (Parallelism). Tensor/Pipeline TensorRT-LLM mendukung beragam model (LLM, Encoder-Decoder), sementara TGI memanfaatkan HuggingFace integrasi.
-
Kekurangan: TensorRT-LLM perlu kompilasi dan adalah NVIDIA-only; TGI mungkin kurang efisien dalam batching; keduanya menambahkan overhead konfigurasi dan mungkin tidak cocok untuk semua jenis model (misalnya, non-transformer).
-
Rekomendasi: Cocokkan untuk PyTorch/TensorFlow model yang membutuhkan kemampuan produksi seperti A/B pengujian atau throughput tinggi dengan perangkat keras yang kompatibel.
Menggunakan mesin inferensi throughput tinggi khusus (misalnya, VllM) Memanfaatkan mesin inferensi canggih seperti VllM, mengoptimalkan penyajian LLM dengan, in-flight batching, dan kuantisasi (INT8,, AWQ) PagedAttention, dapat diintegrasikan dengan penskalaan otomatis EKS. FP8-KV
-
Kelebihan: Throughput tinggi dan efisiensi memori (penghematan VRAM 40-60%), penanganan permintaan dinamis, streaming token, dukungan multi-GPU Tensor Paralel simpul tunggal, dan kompatibilitas perangkat keras yang luas.
-
Kekurangan: Dioptimalkan untuk transformator khusus decoder (misalnya, LLAMA), kurang efektif untuk model non-transformator, memerlukan perangkat keras yang kompatibel (misalnya, GPU NVIDIA) dan upaya penyiapan.
-
Rekomendasi: Pilihan teratas untuk inferensi LLM volume tinggi dan latensi rendah pada EKS, memaksimalkan skalabilitas dan kinerja.
Mengoptimalkan waktu tarik gambar kontainer
Gambar kontainer yang besar dapat menyebabkan penundaan start dingin yang memengaruhi latensi start-up pod. Untuk beban kerja yang sensitif terhadap latensi, seperti beban kerja inferensi waktu nyata yang diskalakan secara horizontal, startup pod cepat sangat penting. Pertimbangkan pendekatan berikut untuk mengoptimalkan waktu tarik gambar kontainer:
Mengurangi Ukuran Gambar Kontainer
Mengurangi ukuran gambar kontainer selama startup adalah cara lain untuk membuat gambar lebih kecil. Anda dapat membuat pengurangan di setiap langkah proses pembuatan image container. Untuk memulai, pilih gambar dasar yang berisi jumlah dependensi paling sedikit yang diperlukan. Selama pembuatan gambar, sertakan hanya pustaka dan artefak penting yang diperlukan. Saat membuat gambar, coba gabungkan beberapa RUN atau COPY perintah untuk membuat lapisan yang lebih besar dalam jumlah yang lebih kecil. Untuk AI/ML kerangka kerja, gunakan build multi-tahap untuk memisahkan build dan runtime, hanya menyalin artefak yang diperlukan (misalnya, via COPY —from= untuk registri atau konteks lokal), dan pilih varian seperti gambar runtime saja (misalnya, pada 3,03 GB vs. devel pada 6,66 GB). pytorch/pytorch:2.7.1-cuda11.8-cudnn9-runtime Untuk mempelajari lebih lanjut, lihat Mengurangi ukuran gambar kontainer
Kurangi Latensi Tarik Gambar
Untuk kluster EKS yang berjalan di subnet pribadi, konfigurasikan titik akhir antarmuka VPC untuk Amazon ECR untuk menjaga lalu lintas tarik gambar di jaringan pribadi AWS, mengurangi latensi, dan menghilangkan biaya pemrosesan data gateway NAT. Lihat Membuat titik akhir VPC untuk Amazon ECR untuk petunjuk penyiapan.
Selain itu, jika beban kerja Anda bergantung pada gambar kontainer hulu dari pendaftar eksternal, pertimbangkan untuk menggunakan ECR pull through cache ke proxy dan cache gambar tersebut di registri ECR pribadi Anda.
Optimalkan Bandwidth Jaringan untuk Penarikan Gambar
Saat menarik gambar kontainer besar, bandwidth jaringan yang tersedia untuk node pekerja EKS Anda secara langsung memengaruhi waktu untuk memulai untuk beban kerja pelatihan dan inferensi. Semua Nitro-based instans generasi saat ini menggunakan Elastic Network Adapter (ENA), tetapi bandwidth yang tersedia bervariasi secara signifikan berdasarkan ukuran instans, dan sangat penting untuk memahami perbedaan antara bandwidth dasar dan burst (lihat bandwidth jaringan instans Amazon EC2). Untuk meminimalkan waktu siap untuk beban kerja Anda, pilih ukuran instans dengan bandwidth jaringan dasar yang cukup relatif terhadap ukuran gambar Anda dan tarik konkurensi.
Menggunakan snapshotter SOCI ke Gambar Pre-pull
Untuk gambar yang sangat besar yang tidak dapat Anda minimalkan dengan mudah, Anda dapat menggunakan snapshotter Seekable OCI (SOCI) open source yang dikonfigurasi dalam mode pull and unpack paralel. Solusi ini memungkinkan Anda menggunakan gambar yang ada tanpa membangun kembali atau memodifikasi pipeline build Anda. Opsi ini sangat efektif saat menerapkan beban kerja dengan gambar yang sangat besar ke instans komputasi EC2 berkinerja tinggi. Ini bekerja dengan baik dengan jaringan throughput tinggi dan konfigurasi penyimpanan kinerja tinggi seperti biasa dengan beban kerja yang diskalakan. AI/ML
pull/unpack Mode paralel SOCI meningkatkan kinerja tarik gambar ujung ke ujung melalui strategi paralelisasi yang dapat dikonfigurasi. Penarikan dan persiapan gambar yang lebih cepat berdampak langsung pada seberapa cepat Anda dapat menerapkan beban kerja baru dan menskalakan klaster Anda secara efisien. Penarikan gambar memiliki dua fase utama:
- 1. Mengambil lapisan dari registri ke node
-
Untuk optimasi pengambilan lapisan, SOCI membuat beberapa koneksi HTTP bersamaan per lapisan, mengalikan throughput unduhan di luar batasan koneksi tunggal. Ini membagi lapisan besar menjadi beberapa bagian dan mengunduhnya secara bersamaan di beberapa koneksi. Pendekatan ini membantu menjenuhkan bandwidth jaringan Anda yang tersedia dan mengurangi waktu pengunduhan secara signifikan. Ini sangat berharga untuk AI/ML beban kerja di mana satu lapisan bisa beberapa gigabyte.
- 2. Membongkar dan menyiapkan lapisan-lapisan itu untuk membuat wadah
-
Untuk optimasi pembongkaran lapisan, SOCI memproses beberapa lapisan secara bersamaan. Alih-alih menunggu setiap lapisan untuk sepenuhnya membongkar sebelum memulai yang berikutnya, ia menggunakan inti CPU Anda yang tersedia untuk mendekompresi dan mengekstrak beberapa lapisan secara bersamaan. Pemrosesan paralel ini mengubah fase I/O-bound pembongkaran tradisional menjadi CPU-optimized operasi yang diskalakan dengan inti yang tersedia. Sistem dengan hati-hati mengatur paralelisasi ini untuk mempertahankan konsistensi sistem file sambil memaksimalkan throughput.
Mode tarik paralel SOCI menggunakan sistem kontrol ambang ganda dengan parameter yang dapat dikonfigurasi untuk mengunduh konkurensi dan membongkar paralelisme. Kontrol granular ini memungkinkan Anda menyempurnakan perilaku SOCI untuk memenuhi persyaratan kinerja dan kondisi lingkungan spesifik Anda. Memahami parameter ini membantu Anda mengoptimalkan runtime untuk kinerja tarik terbaik.
Referensi
-
Untuk informasi selengkapnya tentang solusi dan tuning tradeoff, lihat dokumentasi fitur
di repositori proyek SOCI pada. GitHub -
Untuk contoh langsung dengan Karpenter di Amazon EKS, lihat Karpenter Blueprint menggunakan mode paralel snapshotter
SOCI. pull/unpack -
Untuk informasi tentang mengonfigurasi Bottlerocket untuk tarikan paralel, lihat Soci-snapshotter Parallel Pull Unpack Mode
di Bottlerocket Documentation.o
Menggunakan Snapshot EBS ke Gambar Pre-pull
Anda dapat mengambil snapshot Amazon Elastic Block Store (EBS) dari gambar kontainer yang di-cache dan menggunakan kembali snapshot ini untuk node pekerja EKS. Ini memastikan gambar diambil sebelumnya secara lokal saat node startup, mengurangi waktu inisialisasi pod. Lihat Mengurangi waktu startup container di Amazon EKS dengan volume data Bottlerocket
Untuk mempelajari lebih lanjut, lihat Menggunakan snapshotter containerd
Menggunakan Cache Runtime Container ke Gambar Pre-pull
Anda dapat melakukan pre-pull image container ke node menggunakan resource Kubernetes (misalnya, DaemonSet atau Deployment) untuk mengisi cache runtime container node. Cache runtime kontainer adalah penyimpanan lokal yang dikelola oleh runtime kontainer (misalnya, containerd
Pre-pulling semua varian memastikan waktu startup yang cepat terlepas dari gambar mana yang dibutuhkan. Misalnya, dalam beban kerja MS paralel besar-besaran yang membutuhkan 100.000 model kecil yang dibuat menggunakan 10 teknik berbeda, pra-penarikan 10 gambar melalui DaemonSet cluster besar (misalnya, ribuan node) meminimalkan waktu startup pod, memungkinkan penyelesaian dalam waktu kurang dari 10 detik dengan menghindari penarikan sesuai permintaan. Menggunakan pendekatan cache runtime container menghilangkan kebutuhan untuk mengelola snapshot EBS, memastikan Anda selalu mendapatkan versi gambar kontainer terbaru, tetapi untuk beban kerja inferensi waktu nyata di mana skala in/out node DaemonSets, node baru yang ditambahkan oleh alat seperti Cluster Autoscaler dapat menjadwalkan pod beban kerja sebelum pra-tarik menyelesaikan penarikan gambar. DaemonSet Hal ini dapat menyebabkan pod awal pada node baru tetap memicu tarikan, berpotensi menunda startup dan memengaruhi persyaratan latensi rendah. Selain itu, pengumpulan sampah gambar kubelet dapat memengaruhi gambar yang telah ditarik sebelumnya dengan menghapus gambar yang tidak digunakan saat penggunaan disk melebihi ambang batas tertentu atau jika melebihi usia maksimum yang tidak digunakan yang dikonfigurasi. Dalam in/out pola skala, ini dapat mengusir gambar pada node idle, yang memerlukan penarikan ulang selama peningkatan skala berikutnya dan mengurangi keandalan cache untuk beban kerja yang meledak.
Lihat AWS GitHub repository
Pertimbangkan NVMe untuk penyimpanan kubelet dan containerd
Pertimbangkan containerd untuk mengonfigurasi kubelet dan menggunakan disk penyimpanan instans NVMe singkat untuk kinerja disk yang lebih tinggi. Proses penarikan kontainer melibatkan pengunduhan gambar kontainer dari registri dan mendekompresi lapisannya menjadi format yang dapat digunakan. Untuk mengoptimalkan I/O operasi selama dekompresi, Anda harus mengevaluasi apa yang memberikan tingkat I/O kinerja dan throughput yang lebih tinggi untuk jenis instans host kontainer Anda: instans cadangan NVMe dengan penyimpanan lokal vs Volume EBS. IOPS/throughput Untuk instans EC2 dengan penyimpanan lokal NVMe, pertimbangkan untuk mengonfigurasi sistem file dasar node untuk kubelet (/var/lib/kubelet), containerd () dan Pod logs /var/log/pods () untuk menggunakan disk penyimpanan instance NVMe /var/lib/containerd sementara untuk tingkat kinerja dan throughput yang lebih tinggi. I/O
Penyimpanan ephemeral node dapat dibagikan di antara Pod yang meminta penyimpanan sementara dan gambar kontainer yang diunduh ke node. Jika menggunakan Karpenter dengan Bottlerocket atau AL2023 EKS AMI yang Dioptimalkan, ini dapat dikonfigurasi dalam dengan menyetel StorePolicy instance ke RAID0 atau, jika menggunakan Grup Node Terkelola, dengan menyetel lokal sebagai EC2NodeClass
