Performa - Amazon EKS
Penskalaan dan Kinerja Aplikasi

Terjemahan disediakan oleh mesin penerjemah. Jika konten terjemahan yang diberikan bertentangan dengan versi bahasa Inggris aslinya, utamakan versi bahasa Inggris.

Performa

Penskalaan dan Kinerja Aplikasi

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.

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 perintah RUN atau COPY untuk membuat lapisan yang lebih besar dalam jumlah yang lebih kecil. Membangun gambar yang lebih kecil memiliki pro dan kontra berikut:

  • Kelebihan:

    • Penarikan gambar lebih cepat dan lebih sedikit penyimpanan yang dibutuhkan secara keseluruhan.

    • Gambar yang lebih kecil memiliki lebih sedikit vektor serangan.

  • Kontra:

    • Dengan gambar kontainer yang lebih ramping, Anda perlu membuat beberapa gambar untuk memenuhi kebutuhan untuk berjalan di lingkungan yang berbeda.

    • Penghematan ukuran dengan menggabungkan perintah terkadang dapat diabaikan, jadi Anda harus menguji pendekatan build yang berbeda untuk melihat apa yang membawa hasil terbaik. Untuk AI/ML kerangka kerja, pilih varian seperti gambar runtime saja (misalnya, pytorch/pytorch:2.7.1-cuda11.8-cudnn9-runtime pada 3,03 GB vs devel pada 6,66 GB), tetapi benchmark beban kerja karena gambar yang lebih kecil dapat melewati kompilasi JIT, yang mengarah ke jalur kode yang lebih lambat. Gunakan build multi-tahap untuk memisahkan build dan runtime, hanya menyalin artefak yang diperlukan (misalnya, melalui COPY —from= untuk pendaftar atau konteks lokal). Gunakan optimasi lapisan dengan menggabungkan COPY dalam tahap perakitan untuk lapisan yang lebih sedikit, meskipun dibandingkan dengan efisiensi cache yang berkurang dan waktu pembuatan yang lebih lama.

Menangani Artefak Model ML dalam Penerapan

Keputusan kuncinya adalah bagaimana menangani artefak model ML (misalnya, bobot, konfigurasi) itu sendiri. Pilihannya memengaruhi ukuran gambar, kecepatan penerapan, frekuensi pembaruan model, dan overhead operasional. Bukannya ketika mengacu pada penyimpanan “model”, kami mengacu pada artefak model (misalnya, parameter terlatih, bobot model). Ada tiga 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 - terdaftar 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 ini adalah bagian dari gambar yang tidak dapat diubah. Kami merekomendasikan menggunakan pendekatan ini untuk model yang lebih kecil dengan pembaruan yang jarang.

  • Kelebihan: Memastikan konsistensi dan reproduktifitas, tidak ada penundaan pemuatan, menyederhanakan manajemen ketergantungan.

  • Kekurangan: Menghasilkan ukuran gambar yang lebih besar, memperlambat build dan push, memerlukan pembangunan kembali dan redeploying untuk pembaruan model, tidak ideal untuk model besar karena throughput tarik registri. Selain itu, ini dapat menyebabkan loop umpan balik yang lebih lama untuk eksperimen, debugging, dan pengujian karena pengaturan yang lebih kompleks, dan ini dapat meningkatkan biaya penyimpanan jika menemukan bersama di berbagai gambar.

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 s5cmd OSS CLI) melalui skrip dalam wadah init atau titik masuk. Kami merekomendasikan memulai dengan pendekatan ini untuk model besar dengan pembaruan yang sering.

  • Kelebihan: Menjaga gambar kontainer tetap fokus pada code/runtime, enables easy model updates without rebuilds, supports versioning via storage metadata. It also allows for A/B pengujian, pertukaran panas, atau memutar kembali model tanpa meningkatkan ukuran gambar kontainer, dan menyediakan kemampuan untuk berbagi model di antara aplikasi yang berbeda tanpa mengemasnya ke dalam semua gambar kontainer. Selain itu, ia memperkenalkan perubahan minimal pada alur kerja ML/tim aplikasi dan memungkinkan pembuatan kontainer yang lebih cepat untuk membantu eksperimen dan pengujian. Menggunakan alat yang didukung S3 CRT seperti AWS CLI, s5cmd, atau Driver Mountpoint S3 CSI dapat secara signifikan mengurangi latensi unduhan dan meningkatkan kinerja untuk file besar, seringkali menghasilkan waktu startup pod keseluruhan yang lebih cepat dibandingkan dengan menarik gambar kontainer panggang besar dari pendaftar seperti ECR, tergantung pada kinerja jaringan dan registri.

  • Kekurangan: Memperkenalkan potensi kegagalan jaringan (memerlukan logika coba lagi), memerlukan otentikasi dan caching. Kompleksitas operasional tambahan muncul dari penanganan proses pengunduhan, termasuk percobaan ulang, penanganan kesalahan, dan backoff, bersama dengan penyimpanan tambahan dan manajemen pembersihan yang mereplikasi fungsionalitas ECR.

Memasang model melalui volume persisten Simpan model di penyimpanan eksternal (misalnya, Amazon EFS, EBS, FSx untuk NetApp ONTAP, untuk Lustre, FSx FSx untuk OpenZFS, atau S3 melalui driver Mountpoint S3 CSI) dan pasang sebagai Kubernetes (PV). PersistentVolume Ini adalah file dan data yang dihasilkan selama proses pelatihan model yang memungkinkannya membuat prediksi atau kesimpulan. Sebaiknya gunakan pendekatan ini untuk model bersama di seluruh pod atau cluster.

  • Kelebihan: Memisahkan model dari gambar untuk akses bersama, memfasilitasi pembaruan tanpa restart (jika didukung oleh kerangka kerja Anda), menangani kumpulan data besar secara efisien. Ini juga memungkinkan penyediaan dan kontrol akses yang digerakkan oleh Kubernetes melalui fitur-fitur seperti kloning, berbagi, dan snapshot, mengurangi kebutuhan untuk menyalin model dan membuat operasi baru. Kontrol akses berbasis POSIX ke model dimungkinkan, bersama dengan kemampuan untuk memperbarui versi model secara terpisah dari aplikasi tanpa membangun kembali gambar kontainer, dan pembuatan kontainer yang lebih cepat untuk eksperimen dan pengujian. Untuk aplikasi AI/ML inferensi yang membaca artefak ke dalam memori, ini memungkinkan pemuatan data langsung dari sistem file eksternal tanpa perlu menyimpannya secara perantara pada disk lokal node, meningkatkan kinerja beban. Selain itu, untuk menyimpan model besar dalam skala besar, layanan seperti FSx untuk NetApp ONTAP, FSx untuk Lustre menyediakan teknik pengoptimalan penyimpanan (misalnya, deduplikasi, kompresi, penyediaan tipis), pembuatan versi melalui snapshot, dan dukungan untuk menggunakan kembali file yang sama tanpa membuang ruang penyimpanan. Layanan lain, seperti S3, menawarkan versi asli. Pendekatan ini juga dapat menjangkau seluruh cluster dan wilayah yang berpotensi, tergantung pada konfigurasi replikasi (misalnya, replikasi asinkron di FSx atau replikasi lintas wilayah di S3 dan EFS).

  • Kekurangan: Dapat menambahkan I/O latensi jika terpasang jaringan, memerlukan penyediaan penyimpanan dan kontrol akses, mungkin kurang portabel (misalnya, EBS) jika penyimpanan khusus cluster. Trade-off mencakup kompleksitas operasional tambahan untuk CI/CD perubahan dan pemeliharaan proses pemuat, kebutuhan akan TTL/retention mekanisme khusus untuk mengurangi biaya penyimpanan, dan replikasi lintas wilayah yang lebih kompleks. Kinerja baca untuk artefak model harus diukur terhadap waktu pengunduhan gambar kontainer.

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 (misalnya, 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 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] (https://containerd.io/)) tempat gambar disimpan setelah ditarik dari registri. Pra-penarikan memastikan gambar tersedia secara lokal, menghindari penundaan unduhan selama startup pod. Pendekatan ini berguna ketika snapshot EBS tidak dikonfigurasi sebelumnya atau saat pra-penarikan gambar lebih disukai. Lihat [AWS Sampel GitHub repositori] (https://github.com/aws-samples/aws-do-eks/tree/main/Container-Root/eks/deployment/prepull) untuk contoh gambar pra-penarikan. Perhatikan bahwa alternatif seperti lazy loading dengan [SOCI Snapshotter] (https://github.com/awslabs/soci-snapshotter) (plugin containerd untuk penarikan gambar sebagian) dapat melengkapi metode ini, meskipun memerlukan pengaturan khusus dan mungkin tidak sesuai dengan semua skenario. Menggunakan cache runtime container dilengkapi dengan pro dan kontra berikut:

  • Kelebihan:

    • Tidak perlu mengelola snapshot EBS.

    • Dengan DaemonSets Anda selalu mendapatkan versi gambar kontainer terbaru.

    • Lebih fleksibel, karena gambar dapat diperbarui tanpa membuat ulang snapshot.

    • Masih mengurangi waktu startup pod dengan memastikan gambar sudah ada di node.

  • Kontra:

    • Penarikan awal gambar besar masih bisa memakan waktu, meskipun sudah dilakukan sebelumnya.

    • Mungkin tidak seefisien snapshot EBS untuk gambar yang sangat besar (lebih dari 10 GB), karena penarikan masih diperlukan, meskipun tidak saat startup pod.

    • Dengan DaemonSets, sebuah gambar ditarik sebelumnya ke semua node tempat pod mungkin berjalan. Misalnya, jika 1000 node hanya menjalankan satu instance dari sebuah pod, ruang dikonsumsi pada semua 1000 node hanya untuk menjalankan satu instance pada satu node.

    • Untuk beban kerja inferensi waktu nyata di mana node menskalakan masuk/keluar, 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.

    • 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 pola scale-in/out, ini dapat mengusir gambar pada node idle, yang memerlukan penarikan ulang selama peningkatan skala berikutnya dan mengurangi keandalan cache untuk beban kerja yang meledak.

Menggunakan Snapshots EBS

  • 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 ini Kurangi waktu startup container di Amazon EKS dengan volume data Bottlerocket untuk informasi selengkapnya menggunakan Karpenter dan Cetak Biru EKS Terraform ini untuk grup node terkelola. Kami merekomendasikan untuk mengotomatiskan pembuatan snapshot EBS sebagai bagian dari CI/CD pipeline Anda agar up-to-date tetap menggunakan versi gambar kontainer terbaru. Menggunakan snapshot EBS dilengkapi dengan pro dan kontra berikut:

  • Kelebihan:

    • Menghilangkan kebutuhan untuk menarik gambar kontainer besar saat startup pod, secara signifikan mengurangi waktu startup (misalnya, dari 10-15 menit menjadi detik untuk gambar yang lebih besar dari 10 GB).

    • Memastikan gambar tersedia secara lokal saat startup node.

    • Sangat bermanfaat untuk beban kerja inferensi dengan gambar kontainer besar.

  • Kontra:

    • Memerlukan pemeliharaan dan pembaruan snapshot EBS dengan setiap peningkatan gambar atau versi.

    • Memerlukan langkah ekstra untuk memastikan semua beban kerja Anda menggunakan versi gambar kontainer terbaru.

    • Melibatkan kegiatan operasional tambahan untuk membuat dan mengelola snapshot.

    • Mungkin menyertakan gambar yang tidak perlu jika tidak dikelola dengan benar, meskipun ini dapat dikurangi dengan konfigurasi kumpulan node yang tepat.

Optimalkan Kinerja Tarik Gambar

Kami sangat menyarankan untuk mengoptimalkan kinerja penarikan gambar kontainer untuk kluster Amazon EKS yang menjalankan AI/ML beban kerja. Menggunakan gambar dasar yang besar dan tidak dioptimalkan atau pemesanan lapisan yang tidak efisien dapat menyebabkan waktu startup pod yang lambat, peningkatan konsumsi sumber daya, dan latensi inferensi yang terdegradasi. Untuk mengatasinya, adopsi gambar dasar yang kecil dan ringan dengan dependensi minimal, yang disesuaikan dengan beban kerja Anda. Anda juga dapat mempertimbangkan AWS Deep Learning Containers (DLCs) yang merupakan gambar kontainer yang dibuat sebelumnya yang memudahkan menjalankan kerangka kerja pembelajaran mendalam yang populer (misalnya, PyTorchdan TensorFlow). Untuk mempelajari lebih lanjut tentang membuat gambar kustom, lihat Menyesuaikan Deep Learning Containers. Saat membuat gambar khusus, pertimbangkan gambar dasar yang ringan dan tambahkan hanya pustaka yang diperlukan untuk menjaga gambar tetap ramping. Gunakan build multi-tahap untuk mengurangi ukuran lapisan dan mengoptimalkan pemesanan lapisan untuk caching yang efisien. Untuk detail selengkapnya, lihat Praktik Terbaik Docker untuk Membangun Gambar.

Kurangi Waktu Startup Kontainer dengan Memuat Gambar Kontainer ke Volume Data

Untuk beban kerja machine learning yang membutuhkan latensi startup pod rendah, seperti inferensi real-time, sebaiknya pramuat image container untuk meminimalkan penundaan inisialisasi. Gambar kontainer besar dapat memperlambat startup pod, terutama pada node dengan bandwidth terbatas. Selain menggunakan gambar dasar minimal, build multi-tahap, dan teknik pemuatan lambat, pertimbangkan pendekatan berikut untuk memuat gambar di Amazon EKS. Selain menggunakan gambar dasar minimal, build multi-tahap, dan teknik pemuatan lambat, pertimbangkan opsi berikut:

  • Pra-muat gambar menggunakan snapshot EBS: Ambil snapshot Amazon Elastic Block Store (EBS) Amazon Elastic Block Store (EBS) dari gambar kontainer yang di-cache dan gunakan kembali snapshot ini untuk node pekerja EKS. Meskipun ini menambahkan aktivitas operasional tambahan, ini memastikan gambar diambil sebelumnya secara lokal saat startup node, mengurangi waktu inisialisasi pod. Lihat ini Kurangi waktu startup container di Amazon EKS dengan volume data Bottlerocket untuk informasi selengkapnya menggunakan Karpenter dan Cetak Biru EKS Terraform ini untuk grup node terkelola.

  • Pra-tarik gambar ke dalam cache runtime kontainer: Pra-tarik gambar kontainer ke node menggunakan sumber daya Kubernetes (misalnya, DaemonSet atau Deployment) untuk mengisi cache runtime kontainer node. Cache runtime kontainer adalah penyimpanan lokal yang dikelola oleh runtime kontainer (misalnya, containerd) tempat gambar disimpan setelah ditarik dari registri. Pra-penarikan memastikan gambar tersedia secara lokal, menghindari penundaan unduhan selama startup pod. Pendekatan ini berguna ketika snapshot EBS tidak dikonfigurasi sebelumnya atau saat pra-penarikan gambar lebih disukai. Uji pendekatan ini di lingkungan pementasan untuk memvalidasi peningkatan latensi. Lihat GitHub repositori AWS Sampel untuk contoh gambar pra-penarikan.