Terjemahan disediakan oleh mesin penerjemah. Jika konten terjemahan yang diberikan bertentangan dengan versi bahasa Inggris aslinya, utamakan versi bahasa Inggris.
Penskalaan dan Kinerja Aplikasi
Mengelola Artefak, 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.
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
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 pada kode/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 pengaturan berbasis Python 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 GBs) 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, hanya Python 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, tidak memiliki penskalaan/pemantauan, 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 MLM, mengelola pemuatan model, perutean, dan pengoptimalan. Format dukungan ini seperti safetensors, dengan kompilasi opsional atau plugin.
-
Kelebihan: Menawarkan batching (static/in-flight or continuous), quantization (INT8, FP8, GPTQ), hardware optimizations (NVIDIA, AMD, Intel, Inferentia), and multi-GPU support (Tensor/PipelineParalelisme). TensorRT-LLM mendukung beragam model (, Encoder-Decoder)LLMs, sementara TGI memanfaatkan integrasi. HuggingFace
-
Kekurangan: TensorRT-LLM membutuhkan kompilasi dan hanya NVIDIA; TGI mungkin kurang efisien dalam pengelompokan; keduanya menambahkan overhead konfigurasi dan mungkin tidak cocok untuk semua jenis model (misalnya, non-transformator).
-
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 servis LLM dengan, in-flight batching, dan kuantisasi (, -KV, AWQ) PagedAttention, dapat diintegrasikan dengan penskalaan otomatis EKS. INT8 FP8
-
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, LLa MA), kurang efektif untuk model non-transformator, memerlukan perangkat keras yang kompatibel (misalnya, NVIDIA) dan upaya penyiapan. GPUs
-
Rekomendasi: Pilihan teratas untuk inferensi LLM volume tinggi dan latensi rendah pada EKS, memaksimalkan skalabilitas dan kinerja.
Gambar Kontainer Pra-caching
Gambar kontainer besar (seperti yang berisi model seperti PyTorch) dapat menyebabkan penundaan start dingin yang memengaruhi latensi. Untuk beban kerja yang sensitif terhadap latensi, seperti beban kerja inferensi waktu nyata yang diskalakan secara horizontal dan startup pod cepat sangat penting, sebaiknya pramuat image container untuk meminimalkan penundaan inisialisasi. Pertimbangkan pendekatan berikut dari yang paling sedikit hingga yang paling direkomendasikan:
Menggunakan snapshotter SOCI untuk Pra-tarik Gambar
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 instance EC2 komputasi 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 end-to-end gambar 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 membongkar sepenuhnya sebelum memulai yang berikutnya, ia menggunakan inti CPU Anda yang tersedia untuk mendekompresi dan mengekstrak beberapa lapisan secara bersamaan. Pemrosesan paralel ini mengubah fase pembongkaran terikat I/O secara tradisional menjadi operasi yang dioptimalkan CPU 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 Dokumentasi Bottlerocket.o
Menggunakan Snapshots EBS untuk Pra-tarik Gambar
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 Container Runtime Cache untuk Pra-tarik Gambar
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
Pra-penarikan 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 kontainer menghilangkan kebutuhan untuk mengelola snapshot EBS, memastikan Anda selalu mendapatkan versi gambar kontainer terbaru DaemonSets, tetapi untuk beban kerja inferensi waktu nyata di mana in/out, new nodes added by tools like Cluster Autoscaler may schedule workload pods before the pre-pull DaemonSet completes image pulling. This can cause the initial pod on the new node to trigger the pull anyway, potentially delaying startup and impacting low-latency requirements. Additionally, kubelet image garbage collection can affect pre-pulled images by removing unused ones when disk usage exceeds certain thresholds or if they exceed a configured maximum unused age. In scale-in/out pola skala node, 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
Digunakan NVMe untuk penyimpanan kubelet dan containerd
Pertimbangkan containerd untuk mengonfigurasi kubelet dan menggunakan disk penyimpanan NVMe instans 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 NVMe instans host kontainer Anda: instance cadangan dengan penyimpanan lokal vs IOP/throughput Volume EBS. Untuk EC2 instance dengan penyimpanan NVMe lokal, pertimbangkan untuk mengonfigurasi sistem file dasar node untuk kubelet (/var/lib/kubelet), containerd () dan Pod logs /var/log/pods () untuk menggunakan NVMe disk /var/lib/containerd penyimpanan instance 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 AL2 023 EKS Dioptimalkan, AMIs ini dapat dikonfigurasi EC2NodeClass
