Tolok ukur dan optimalkan penerapan titik akhir di Amazon SageMaker JumpStart | Layanan Web Amazon

Saat menerapkan model bahasa besar (LLM), praktisi pembelajaran mesin (ML) biasanya memperhatikan dua pengukuran kinerja penyajian model: latensi, yang ditentukan oleh waktu yang diperlukan untuk menghasilkan satu token, dan throughput, yang ditentukan oleh jumlah token yang dihasilkan. per detik. Meskipun satu permintaan ke titik akhir yang diterapkan akan menunjukkan throughput yang kira-kira sama dengan kebalikan dari latensi model, hal ini belum tentu terjadi ketika beberapa permintaan bersamaan dikirim ke titik akhir secara bersamaan. Karena teknik penyajian model, seperti pengelompokan permintaan serentak secara terus-menerus di sisi klien, latensi dan throughput memiliki hubungan kompleks yang bervariasi secara signifikan berdasarkan arsitektur model, konfigurasi penyajian, perangkat keras jenis instans, jumlah permintaan serentak, dan variasi muatan masukan seperti sebagai jumlah token masukan dan token keluaran.

Posting ini mengeksplorasi hubungan ini melalui tolok ukur komprehensif LLM yang tersedia di Amazon SageMaker JumpStart, termasuk varian Llama 2, Falcon, dan Mistral. Dengan SageMaker JumpStart, praktisi ML dapat memilih dari beragam pilihan model dasar yang tersedia untuk umum untuk diterapkan ke model khusus Amazon SageMaker contoh dalam lingkungan yang terisolasi jaringan. Kami memberikan prinsip teoretis tentang bagaimana spesifikasi akselerator memengaruhi tolok ukur LLM. Kami juga menunjukkan dampak penerapan beberapa instance di belakang satu titik akhir. Terakhir, kami memberikan rekomendasi praktis untuk menyesuaikan proses penerapan SageMaker JumpStart agar selaras dengan kebutuhan Anda mengenai latensi, throughput, biaya, dan batasan pada jenis instans yang tersedia. Semua hasil benchmarking serta rekomendasi didasarkan pada berbagai hal buku catatan yang dapat Anda sesuaikan dengan kasus penggunaan Anda.

Pembandingan titik akhir yang diterapkan

Gambar berikut menunjukkan nilai latensi terendah (kiri) dan throughput tertinggi (kanan) untuk konfigurasi penerapan di berbagai tipe model dan tipe instans. Yang penting, setiap penerapan model ini menggunakan konfigurasi default seperti yang disediakan oleh SageMaker JumpStart dengan mempertimbangkan ID model dan jenis instans yang diinginkan untuk penerapan.

Nilai latensi dan throughput ini sesuai dengan muatan dengan 256 token masukan dan 256 token keluaran. Konfigurasi latensi terendah membatasi model yang melayani satu permintaan serentak, dan konfigurasi throughput tertinggi memaksimalkan kemungkinan jumlah permintaan serentak. Seperti yang bisa kita lihat dalam tolok ukur kami, peningkatan permintaan serentak secara monoton meningkatkan throughput dengan penurunan peningkatan untuk permintaan serentak yang besar. Selain itu, model dipecah sepenuhnya pada instans yang didukung. Misalnya, karena instance ml.g5.48xlarge memiliki 8 GPU, semua model SageMaker JumpStart yang menggunakan instance ini dipecah menggunakan paralelisme tensor pada kedelapan akselerator yang tersedia.

Kita dapat mencatat beberapa kesimpulan dari gambar ini. Pertama, tidak semua model didukung di semua contoh; beberapa model yang lebih kecil, seperti Falcon 7B, tidak mendukung sharding model, sedangkan model yang lebih besar memiliki persyaratan sumber daya komputasi yang lebih tinggi. Kedua, seiring meningkatnya sharding, performa biasanya meningkat, namun belum tentu meningkat untuk model kecil. Hal ini karena model kecil seperti 7B dan 13B menimbulkan overhead komunikasi yang besar ketika di-sharding ke terlalu banyak akselerator. Kita akan membicarakan hal ini secara lebih mendalam nanti. Terakhir, instans ml.p4d.24xlarge cenderung memiliki throughput yang jauh lebih baik karena peningkatan bandwidth memori pada GPU A100 dibandingkan GPU A10G. Seperti yang akan kita bahas nanti, keputusan untuk menggunakan jenis instans tertentu bergantung pada persyaratan penerapan Anda, termasuk latensi, throughput, dan batasan biaya.

Bagaimana Anda bisa mendapatkan nilai konfigurasi latensi terendah dan throughput tertinggi ini? Mari kita mulai dengan memplot latensi vs. throughput untuk titik akhir Llama 2 7B pada instans ml.g5.12xlarge untuk payload dengan 256 token masukan dan 256 token keluaran, seperti terlihat pada kurva berikut. Kurva serupa ada untuk setiap titik akhir LLM yang diterapkan.

Saat konkurensi meningkat, throughput dan latensi juga meningkat secara monoton. Oleh karena itu, titik latensi terendah terjadi pada nilai permintaan serentak 1, dan Anda dapat meningkatkan throughput sistem secara hemat biaya dengan meningkatkan permintaan serentak. Terdapat “lutut” yang berbeda dalam kurva ini, yang jelas bahwa peningkatan throughput yang terkait dengan konkurensi tambahan tidak melebihi peningkatan latensi yang terkait. Lokasi pasti dari lutut ini bergantung pada kasus penggunaan; beberapa praktisi mungkin menentukan lutut pada titik di mana persyaratan latensi yang telah ditentukan sebelumnya terlampaui (misalnya, 100 ms/token), sedangkan yang lain mungkin menggunakan tolok ukur uji beban dan metode teori antrian seperti aturan setengah latensi, dan yang lain mungkin menggunakan spesifikasi akselerator teoritis.

Kami juga mencatat bahwa jumlah maksimum permintaan bersamaan terbatas. Pada gambar sebelumnya, jejak garis diakhiri dengan 192 permintaan bersamaan. Sumber batasan ini adalah batas waktu tunggu pemanggilan SageMaker, di mana SageMaker menetapkan waktu tunggu respons pemanggilan setelah 60 detik. Pengaturan ini khusus untuk akun dan tidak dapat dikonfigurasi untuk titik akhir individual. Untuk LLM, menghasilkan token keluaran dalam jumlah besar dapat memakan waktu beberapa detik atau bahkan beberapa menit. Oleh karena itu, muatan masukan atau keluaran yang besar dapat menyebabkan permintaan pemanggilan gagal. Selain itu, jika jumlah permintaan serentak sangat besar, maka banyak permintaan akan mengalami waktu antrian yang besar, sehingga mendorong batas waktu tunggu 60 detik ini. Untuk tujuan penelitian ini, kami menggunakan batas waktu habis untuk menentukan throughput maksimum yang mungkin untuk penerapan model. Yang penting, meskipun titik akhir SageMaker dapat menangani sejumlah besar permintaan serentak tanpa memperhatikan batas waktu respons pemanggilan, Anda mungkin ingin menentukan permintaan serentak maksimum sehubungan dengan lutut dalam kurva latensi-throughput. Ini kemungkinan merupakan titik di mana Anda mulai mempertimbangkan penskalaan horizontal, di mana satu titik akhir menyediakan beberapa instans dengan replika model dan menyeimbangkan beban permintaan masuk antar replika, untuk mendukung permintaan yang lebih bersamaan.

Mengambil satu langkah lebih jauh, tabel berikut berisi hasil benchmarking untuk konfigurasi berbeda untuk model Llama 2 7B, termasuk jumlah token input dan output yang berbeda, jenis instans, dan jumlah permintaan bersamaan. Perhatikan bahwa gambar sebelumnya hanya memplot satu baris tabel ini.

Kami mengamati beberapa pola tambahan dalam data ini. Saat meningkatkan ukuran konteks, latensi meningkat dan throughput menurun. Misalnya, pada ml.g5.2xlarge dengan konkurensi 1, throughput adalah 30 token/dtk jika jumlah total token adalah 512, vs. 20 token/dtk jika jumlah total token adalah 4,096. Hal ini karena dibutuhkan waktu lebih lama untuk memproses input yang lebih besar. Kita juga dapat melihat bahwa peningkatan kemampuan GPU dan sharding berdampak pada throughput maksimum dan permintaan serentak maksimum yang didukung. Tabel tersebut menunjukkan bahwa Llama 2 7B memiliki nilai throughput maksimum yang sangat berbeda untuk jenis instans yang berbeda, dan nilai throughput maksimum ini terjadi pada nilai permintaan bersamaan yang berbeda. Karakteristik ini akan mendorong praktisi ML untuk membenarkan biaya suatu instans dibandingkan instans lainnya. Misalnya, dengan adanya persyaratan latensi rendah, praktisi dapat memilih instans ml.g5.12xlarge (4 GPU A10G) dibandingkan instans ml.g5.2xlarge (1 GPU A10G). Jika diberikan persyaratan throughput yang tinggi, penggunaan instance ml.p4d.24xlarge (8 GPU A100) dengan sharding penuh hanya akan dibenarkan dalam konkurensi tinggi. Namun, perhatikan bahwa sering kali bermanfaat untuk memuat beberapa komponen inferensi model 7B pada satu instance ml.p4d.24xlarge; dukungan multi-model tersebut dibahas nanti di posting ini.

Pengamatan sebelumnya dilakukan untuk model Llama 2 7B. Namun, pola serupa juga berlaku untuk model lainnya. Kesimpulan utamanya adalah angka kinerja latensi dan throughput bergantung pada payload, jenis instans, dan jumlah permintaan bersamaan, jadi Anda perlu menemukan konfigurasi ideal untuk aplikasi spesifik Anda. Untuk menghasilkan angka-angka sebelumnya untuk kasus penggunaan Anda, Anda dapat menjalankan link buku catatan, tempat Anda dapat mengonfigurasi analisis pengujian beban ini untuk model, jenis instans, dan payload Anda.

Memahami spesifikasi akselerator

Memilih perangkat keras yang sesuai untuk inferensi LLM sangat bergantung pada kasus penggunaan tertentu, tujuan pengalaman pengguna, dan LLM yang dipilih. Bagian ini mencoba untuk menciptakan pemahaman tentang lutut dalam kurva latensi-throughput sehubungan dengan prinsip tingkat tinggi berdasarkan spesifikasi akselerator. Prinsip-prinsip ini saja tidak cukup untuk mengambil keputusan: diperlukan tolok ukur yang nyata. Syarat alat digunakan di sini untuk mencakup semua akselerator perangkat keras ML. Kami menegaskan bahwa titik terendah dalam kurva latensi-throughput didorong oleh salah satu dari dua faktor:

• Akselerator telah kehabisan memori untuk menyimpan cache matriks KV, sehingga permintaan berikutnya dimasukkan ke dalam antrean
• Akselerator masih memiliki memori cadangan untuk cache KV, namun menggunakan ukuran batch yang cukup besar sehingga waktu pemrosesan didorong oleh latensi operasi komputasi, bukan bandwidth memori

Kami biasanya memilih untuk dibatasi oleh faktor kedua karena ini berarti sumber daya akselerator sudah jenuh. Pada dasarnya, Anda memaksimalkan sumber daya yang Anda bayarkan. Mari kita jelajahi pernyataan ini secara lebih rinci.

Caching KV dan memori perangkat

Mekanisme perhatian transformator standar menghitung perhatian untuk setiap token baru terhadap semua token sebelumnya. Sebagian besar server ML modern menyimpan kunci dan nilai perhatian dalam memori perangkat (DRAM) untuk menghindari penghitungan ulang di setiap langkah. Ini disebut ini cache KV, dan itu bertambah seiring ukuran batch dan panjang urutan. Ini menentukan berapa banyak permintaan pengguna yang dapat dilayani secara paralel dan akan menentukan titik dalam kurva latensi-throughput jika rezim terikat komputasi dalam skenario kedua yang disebutkan sebelumnya belum terpenuhi, mengingat DRAM yang tersedia. Rumus berikut adalah perkiraan kasar untuk ukuran cache KV maksimum.

Dalam rumus ini, B adalah ukuran batch dan N adalah jumlah akselerator. Misalnya, model Llama 2 7B di FP16 (2 byte/parameter) yang disajikan pada GPU A10G (DRAM 24 GB) mengonsumsi sekitar 14 GB, menyisakan 10 GB untuk cache KV. Memasukkan panjang konteks penuh model (N = 4096) dan parameter lainnya (n_layers=32, n_kv_attention_heads=32, dan d_attention_head=128), ekspresi ini menunjukkan bahwa kami dibatasi untuk melayani ukuran batch empat pengguna secara paralel karena kendala DRAM . Jika Anda mengamati tolok ukur yang sesuai pada tabel sebelumnya, ini adalah perkiraan yang baik untuk lutut yang diamati dalam kurva throughput latensi ini. Metode seperti perhatian kueri yang dikelompokkan (GQA) dapat mengurangi ukuran cache KV, dalam kasus GQA dengan faktor yang sama mengurangi jumlah kepala KV.

Intensitas aritmatika dan bandwidth memori perangkat

Pertumbuhan kekuatan komputasi akselerator ML telah melampaui bandwidth memorinya, yang berarti mereka dapat melakukan lebih banyak komputasi pada setiap byte data dalam jumlah waktu yang diperlukan untuk mengakses byte tersebut.

Grafik intensitas aritmatika, atau rasio operasi komputasi terhadap akses memori, untuk suatu operasi menentukan apakah operasi tersebut dibatasi oleh bandwidth memori atau kapasitas komputasi pada perangkat keras yang dipilih. Misalnya, GPU A10G (keluarga tipe instans g5) dengan 70 TFLOPS FP16 dan bandwidth 600 GB/dtk dapat menghitung sekitar 116 ops/byte. GPU A100 (keluarga tipe instans p4d) dapat menghitung sekitar 208 ops/byte. Jika intensitas aritmatika untuk model transformator berada di bawah nilai tersebut, maka model tersebut terikat memori; jika berada di atas, maka terikat pada komputasi. Mekanisme perhatian untuk Llama 2 7B membutuhkan 62 ops/byte untuk ukuran batch 1 (untuk penjelasan lihat Panduan untuk inferensi dan kinerja LLM), yang berarti terikat pada memori. Ketika mekanisme perhatian terikat pada memori, FLOPS yang mahal tidak digunakan.

Ada dua cara untuk memanfaatkan akselerator dengan lebih baik dan meningkatkan intensitas aritmatika: mengurangi akses memori yang diperlukan untuk operasi tersebut (inilah yang FlashPerhatian berfokus pada) atau meningkatkan ukuran batch. Namun, kami mungkin tidak dapat meningkatkan ukuran batch hingga mencapai rezim terikat komputasi jika DRAM kami terlalu kecil untuk menampung cache KV yang sesuai. Perkiraan kasar ukuran batch kritis B* yang memisahkan rezim terikat komputasi dan terikat memori untuk inferensi dekoder GPT standar dijelaskan dengan ekspresi berikut, dengan A_mb adalah bandwidth memori akselerator, A_f adalah FLOPS akselerator, dan N adalah angkanya akselerator. Ukuran batch kritis ini dapat diperoleh dengan mencari waktu akses memori sama dengan waktu komputasi. Mengacu pada posting blog ini untuk memahami Persamaan 2 dan asumsinya secara lebih rinci.

Ini adalah rasio ops/byte yang sama yang kami hitung sebelumnya untuk A10G, jadi ukuran batch kritis pada GPU ini adalah 116. Salah satu cara untuk mendekati ukuran batch teoritis dan kritis ini adalah dengan meningkatkan sharding model dan membagi cache ke lebih banyak akselerator N. Hal ini secara efektif meningkatkan kapasitas cache KV serta ukuran batch yang terikat memori.

Manfaat lain dari model sharding adalah membagi parameter model dan pekerjaan pemuatan data di seluruh N akselerator. Jenis sharding ini adalah jenis paralelisme model yang juga disebut sebagai paralelisme tensor. Naifnya, ada N kali lipat bandwidth memori dan daya komputasi secara agregat. Dengan asumsi tidak ada overhead dalam bentuk apa pun (komunikasi, perangkat lunak, dan sebagainya), hal ini akan menurunkan latensi pengodean ulang per token sebesar N jika kita terikat pada memori, karena latensi pengodean token dalam rezim ini dibatasi oleh waktu yang diperlukan untuk memuat model bobot dan cache. Namun, dalam kehidupan nyata, meningkatkan derajat sharding akan meningkatkan komunikasi antar perangkat untuk berbagi aktivasi perantara di setiap lapisan model. Kecepatan komunikasi ini dibatasi oleh bandwidth interkoneksi perangkat. Sulit untuk memperkirakan dampaknya secara tepat (untuk rinciannya, lihat Paralelisme model), namun hal ini pada akhirnya tidak lagi memberikan manfaat atau menurunkan kinerja — hal ini terutama berlaku untuk model yang lebih kecil, karena transfer data yang lebih kecil menyebabkan kecepatan transfer yang lebih rendah.

Untuk membandingkan akselerator ML berdasarkan spesifikasinya, kami merekomendasikan hal berikut. Pertama, hitung perkiraan ukuran batch kritis untuk setiap jenis akselerator menurut persamaan kedua dan ukuran cache KV untuk ukuran batch kritis menurut persamaan pertama. Anda kemudian dapat menggunakan DRAM yang tersedia pada akselerator untuk menghitung jumlah minimum akselerator yang diperlukan agar sesuai dengan cache KV dan parameter model. Jika memutuskan antara beberapa akselerator, prioritaskan akselerator dalam urutan biaya terendah per GB/detik bandwidth memori. Terakhir, lakukan benchmark pada konfigurasi ini dan verifikasi berapa biaya/token terbaik untuk batas atas latensi yang Anda inginkan.

Pilih konfigurasi penerapan titik akhir

Banyak LLM yang didistribusikan oleh SageMaker JumpStart menggunakan inferensi pembuatan teks (TGI) Wadah SageMaker untuk penyajian model. Tabel berikut membahas cara menyesuaikan berbagai parameter penyajian model untuk memengaruhi penyajian model yang berdampak pada kurva latensi-throughput atau melindungi titik akhir terhadap permintaan yang akan membebani titik akhir. Ini adalah parameter utama yang dapat Anda gunakan untuk mengonfigurasi penerapan titik akhir untuk kasus penggunaan Anda. Kecuali ditentukan lain, kami menggunakan default parameter muatan pembuatan teks dan Variabel lingkungan TGI.

Server TGI menggunakan pengelompokan berkelanjutan, yang secara dinamis mengelompokkan permintaan serentak untuk berbagi satu penerusan inferensi model. Ada dua jenis forward pass: prefill dan decode. Setiap permintaan baru harus menjalankan satu penerusan prefill untuk mengisi cache KV untuk token urutan input. Setelah cache KV diisi, penerusan dekode melakukan prediksi token berikutnya untuk semua permintaan batch, yang diulangi secara berulang untuk menghasilkan urutan keluaran. Saat permintaan baru dikirim ke server, langkah dekode berikutnya harus menunggu agar langkah pra-pengisian dapat dijalankan untuk permintaan baru. Hal ini harus terjadi sebelum permintaan baru tersebut disertakan dalam langkah-langkah dekode batch yang berkelanjutan. Karena kendala perangkat keras, pengelompokan berkelanjutan yang digunakan untuk decoding mungkin tidak mencakup semua permintaan. Pada titik ini, permintaan memasuki antrean pemrosesan dan latensi inferensi mulai meningkat secara signifikan dengan peningkatan throughput yang kecil.

Analisis pembandingan latensi LLM dapat dipisahkan menjadi latensi pra-pengisian, latensi dekode, dan latensi antrean. Waktu yang digunakan oleh masing-masing komponen ini pada dasarnya berbeda: pengisian awal adalah perhitungan satu kali, penguraian kode terjadi satu kali untuk setiap token dalam urutan keluaran, dan antrian melibatkan proses pengelompokan server. Ketika beberapa permintaan serentak diproses, menjadi sulit untuk menguraikan latensi dari masing-masing komponen ini karena latensi yang dialami oleh permintaan klien tertentu melibatkan latensi antrean yang didorong oleh kebutuhan untuk mengisi terlebih dahulu permintaan serentak yang baru serta latensi antrean yang didorong oleh penyertaan. permintaan dalam proses decoding batch. Karena alasan ini, postingan ini berfokus pada latensi pemrosesan ujung ke ujung. Lutut dalam kurva latensi-throughput terjadi pada titik jenuh di mana latensi antrean mulai meningkat secara signifikan. Fenomena ini terjadi pada server inferensi model apa pun dan didorong oleh spesifikasi akselerator.

Persyaratan umum selama penerapan mencakup pemenuhan throughput minimum yang diperlukan, latensi maksimum yang diperbolehkan, biaya maksimum per jam, dan biaya maksimum untuk menghasilkan 1 juta token. Anda harus mengkondisikan persyaratan ini pada payload yang mewakili permintaan pengguna akhir. Desain untuk memenuhi persyaratan ini harus mempertimbangkan banyak faktor, termasuk arsitektur model spesifik, ukuran model, jenis instans, dan jumlah instans (penskalaan horizontal). Pada bagian berikut, kami fokus pada penerapan titik akhir untuk meminimalkan latensi, memaksimalkan throughput, dan meminimalkan biaya. Analisis ini mempertimbangkan total 512 token dan 256 token keluaran.

Minimalkan latensi

Latensi merupakan persyaratan penting dalam banyak kasus penggunaan real-time. Pada tabel berikut, kita melihat latensi minimum untuk setiap model dan setiap jenis instans. Anda dapat mencapai latensi minimum dengan mengatur MAX_CONCURRENT_REQUESTS = 1.

Untuk mencapai latensi minimum suatu model, Anda dapat menggunakan kode berikut sambil mengganti ID model dan jenis instans yang Anda inginkan:

from sagemaker.jumpstart.model import JumpStartModel model = JumpStartModel( model_id="meta-textgeneration-llama-2-7b", model_version="3.*", instance_type="ml.g5.12xlarge", env={ "MAX_CONCURRENT_REQUESTS": "1", "MAX_INPUT_TOKENS": "256", "MAX_TOTAL_TOKENS": "512", },
)
predictor = model.deploy(accept_eula=False) # Change EULA acceptance to True

Perhatikan bahwa angka latensi berubah bergantung pada jumlah token masukan dan keluaran. Namun, proses penerapannya tetap sama kecuali variabel lingkungan MAX_INPUT_TOKENS dan MAX_TOTAL_TOKENS. Di sini, variabel lingkungan ini ditetapkan untuk membantu menjamin persyaratan latensi titik akhir karena urutan masukan yang lebih besar mungkin melanggar persyaratan latensi. Perhatikan bahwa SageMaker JumpStart telah menyediakan variabel lingkungan optimal lainnya saat memilih jenis instans; misalnya, menggunakan ml.g5.12xlarge akan disetel SM_NUM_GPUS ke 4 di lingkungan model.

Maksimalkan keluaran

Di bagian ini, kami memaksimalkan jumlah token yang dihasilkan per detik. Hal ini biasanya dicapai pada permintaan bersamaan maksimum yang valid untuk model dan jenis instans. Dalam tabel berikut, kami melaporkan throughput yang dicapai pada nilai permintaan bersamaan terbesar yang dicapai sebelum menghadapi batas waktu pemanggilan SageMaker untuk permintaan apa pun.

Untuk mencapai throughput maksimum suatu model, Anda dapat menggunakan kode berikut:

from sagemaker.jumpstart.model import JumpStartModel model = JumpStartModel( model_id="meta-textgeneration-llama-2-7b", model_version="3.*", instance_type="ml.g5.12xlarge", env={ "MAX_CONCURRENT_REQUESTS": "128", # For your application, identify it from the benchmarking table with the maximum feasible concurrent requests. "MAX_INPUT_TOKENS": "256", "MAX_TOTAL_TOKENS": "512", },
)
predictor = model.deploy(accept_eula=False) # Change EULA acceptance to True

Perhatikan bahwa jumlah maksimum permintaan serentak bergantung pada jenis model, jenis instans, jumlah maksimum token masukan, dan jumlah maksimum token keluaran. Oleh karena itu, Anda harus mengatur parameter ini sebelum mengaturnya MAX_CONCURRENT_REQUESTS.

Perhatikan juga bahwa pengguna yang tertarik untuk meminimalkan latensi sering kali berselisih dengan pengguna yang tertarik untuk memaksimalkan throughput. Yang pertama tertarik pada respons real-time, sedangkan yang kedua tertarik pada pemrosesan batch sehingga antrian titik akhir selalu jenuh, sehingga meminimalkan waktu henti pemrosesan. Pengguna yang ingin memaksimalkan throughput yang dikondisikan pada persyaratan latensi sering kali tertarik untuk beroperasi tepat pada kurva latensi-throughput.

Minimalkan biaya

Opsi pertama untuk meminimalkan biaya melibatkan meminimalkan biaya per jam. Dengan ini, Anda dapat menerapkan model yang dipilih pada instans SageMaker dengan biaya per jam terendah. Untuk harga instans SageMaker secara real-time, lihat Harga Amazon SageMaker. Secara umum, jenis instans default untuk SageMaker JumpStart LLM adalah opsi penerapan berbiaya terendah.

Opsi kedua untuk meminimalkan biaya melibatkan meminimalkan biaya untuk menghasilkan 1 juta token. Ini adalah transformasi sederhana dari tabel yang kita bahas sebelumnya untuk memaksimalkan throughput, di mana Anda dapat menghitung terlebih dahulu waktu yang diperlukan dalam jam untuk menghasilkan 1 juta token (1e6/throughput/3600). Anda kemudian dapat mengalikan waktu ini untuk menghasilkan 1 juta token dengan harga per jam dari instans SageMaker yang ditentukan.

Perhatikan bahwa instans dengan biaya per jam terendah tidak sama dengan instans dengan biaya terendah untuk menghasilkan 1 juta token. Misalnya, jika permintaan pemanggilan bersifat sporadis, instance dengan biaya per jam terendah mungkin merupakan pilihan optimal, sedangkan dalam skenario pembatasan, biaya terendah untuk menghasilkan satu juta token mungkin lebih tepat.

Pertukaran paralel tensor vs. multi-model

Dalam semua analisis sebelumnya, kami mempertimbangkan untuk menerapkan replika model tunggal dengan tingkat paralel tensor yang sama dengan jumlah GPU pada jenis instans penerapan. Ini adalah perilaku SageMaker JumpStart default. Namun, seperti disebutkan sebelumnya, sharding suatu model hanya dapat meningkatkan latensi dan throughput model hingga batas tertentu, di mana persyaratan komunikasi antar-perangkat akan mendominasi waktu komputasi. Hal ini menyiratkan bahwa sering kali bermanfaat untuk menerapkan beberapa model dengan derajat paralel tensor yang lebih rendah pada satu instance dibandingkan model tunggal dengan derajat paralel tensor yang lebih tinggi.

Di sini, kami menerapkan titik akhir Llama 2 7B dan 13B pada instance ml.p4d.24xlarge dengan derajat tensor parallel (TP) 1, 2, 4, dan 8. Untuk kejelasan dalam perilaku model, masing-masing titik akhir ini hanya memuat satu model.

Analisis kami sebelumnya telah menunjukkan keunggulan throughput yang signifikan pada instans ml.p4d.24xlarge, yang sering kali menghasilkan kinerja yang lebih baik dalam hal biaya untuk menghasilkan 1 juta token pada keluarga instans g5 dalam kondisi beban permintaan bersamaan yang tinggi. Analisis ini dengan jelas menunjukkan bahwa Anda harus mempertimbangkan trade-off antara model sharding dan replikasi model dalam satu contoh; artinya, model dengan sharding penuh biasanya bukan merupakan penggunaan terbaik sumber daya komputasi ml.p4d.24xlarge untuk kelompok model 7B dan 13B. Faktanya, untuk rangkaian model 7B, Anda mendapatkan throughput terbaik untuk replika model tunggal dengan tingkat paralel tensor 4, bukan 8.

Dari sini, Anda dapat memperkirakan bahwa konfigurasi throughput tertinggi untuk model 7B melibatkan derajat paralel tensor 1 dengan delapan replika model, dan konfigurasi throughput tertinggi untuk model 13B kemungkinan besar adalah derajat paralel tensor 2 dengan empat replika model. Untuk mempelajari lebih lanjut tentang cara mencapai hal ini, lihat Kurangi biaya penerapan model rata-rata sebesar 50% menggunakan fitur terbaru Amazon SageMaker, yang menunjukkan penggunaan titik akhir berbasis komponen inferensi. Karena teknik penyeimbangan beban, perutean server, dan berbagi sumber daya CPU, Anda mungkin tidak sepenuhnya mencapai peningkatan throughput yang persis sama dengan jumlah replika dikalikan throughput untuk satu replika.

Penskalaan horizontal

Seperti yang diamati sebelumnya, setiap penerapan titik akhir memiliki batasan jumlah permintaan bersamaan, bergantung pada jumlah token masukan dan keluaran serta jenis instans. Jika ini tidak memenuhi persyaratan throughput atau permintaan serentak, Anda dapat meningkatkan skala untuk memanfaatkan lebih dari satu instans di belakang titik akhir yang disebarkan. SageMaker secara otomatis melakukan penyeimbangan beban kueri antar instans. Misalnya, kode berikut menyebarkan titik akhir yang didukung oleh tiga instans:

model = JumpStartModel( model_id="meta-textgeneration-llama-2-7b", model_version="3.*", instance_type="ml.g5.2xlarge",
)
predictor = model.deploy( accept_eula=False, # Change EULA acceptance to True initial_instance_count = 3,
)

Tabel berikut menunjukkan perolehan throughput sebagai faktor jumlah instans untuk model Llama 2 7B.

Khususnya, titik pada kurva latensi-throughput bergeser ke kanan karena jumlah instans yang lebih tinggi dapat menangani permintaan bersamaan dalam jumlah yang lebih besar dalam titik akhir multi-instans. Untuk tabel ini, nilai permintaan serentak adalah untuk keseluruhan titik akhir, bukan jumlah permintaan serentak yang diterima setiap instans individual.

Anda juga dapat menggunakan penskalaan otomatis, sebuah fitur untuk memantau beban kerja Anda dan menyesuaikan kapasitas secara dinamis untuk mempertahankan performa yang stabil dan dapat diprediksi dengan biaya serendah mungkin. Ini di luar cakupan postingan ini. Untuk mempelajari lebih lanjut tentang penskalaan otomatis, lihat Mengonfigurasi titik akhir inferensi penskalaan otomatis di Amazon SageMaker.

Panggil titik akhir dengan permintaan bersamaan

Misalkan Anda memiliki sejumlah besar kueri yang ingin Anda gunakan untuk menghasilkan respons dari model yang diterapkan dalam kondisi throughput tinggi. Misalnya, dalam blok kode berikut, kami mengkompilasi daftar 1,000 payload, dengan setiap payload meminta pembuatan 100 token. Secara keseluruhan, kami meminta pembuatan 100,000 token.

payload = { "inputs": "I believe the meaning of life is to ", "parameters": {"max_new_tokens": 100, "details": True},
}
total_requests = 1000
payloads = [payload,] * total_requests

Saat mengirimkan permintaan dalam jumlah besar ke API runtime SageMaker, Anda mungkin mengalami kesalahan pembatasan. Untuk mengurangi hal ini, Anda dapat membuat klien runtime SageMaker khusus yang meningkatkan jumlah upaya percobaan ulang. Anda dapat memberikan objek sesi SageMaker yang dihasilkan ke JumpStartModel konstruktor atau sagemaker.predictor.retrieve_default jika Anda ingin melampirkan prediktor baru ke titik akhir yang sudah diterapkan. Dalam kode berikut, kami menggunakan objek sesi ini saat menerapkan model Llama 2 dengan konfigurasi default SageMaker JumpStart:

import boto3
from botocore.config import Config
from sagemaker.session import Session
from sagemaker.jumpstart.model import JumpStartModel sagemaker_session = Session( sagemaker_runtime_client=boto3.client( "sagemaker-runtime", config=Config(connect_timeout=10, retries={"mode": "standard", "total_max_attempts": 20}), )
)
model = JumpStartModel( model_id="meta-textgeneration-llama-2-7b", model_version="3.*", sagemaker_session=sagemaker_session
)
predictor = model.deploy(accept_eula=False) # Change EULA acceptance to True

Titik akhir yang diterapkan ini memiliki MAX_CONCURRENT_REQUESTS = 128 secara default. Di blok berikut, kami menggunakan pustaka masa depan bersamaan untuk mengulangi pemanggilan titik akhir untuk semua payload dengan 128 thread pekerja. Paling banyak, titik akhir akan memproses 128 permintaan secara bersamaan, dan setiap kali permintaan mengembalikan respons, pelaksana akan segera mengirimkan permintaan baru ke titik akhir.

import time
from concurrent import futures concurrent_requests = 128 time_start = time.time()
with futures.ThreadPoolExecutor(max_workers=concurrent_requests) as executor: responses = list(executor.map(predictor.predict, payloads)) total_tokens = sum([response[0]["details"]["generated_tokens"] for response in responses])
token_throughput = total_tokens / (time.time() - time_start)

Hal ini menghasilkan total 100,000 token dengan throughput 1255 token/dtk pada satu instans ml.g5.2xlarge. Ini membutuhkan waktu sekitar 80 detik untuk diproses.

Perhatikan bahwa nilai throughput ini sangat berbeda dari throughput maksimum untuk Llama 2 7B di ml.g5.2xlarge di tabel sebelumnya pada postingan ini (486 token/detik pada 64 permintaan bersamaan). Hal ini karena payload input menggunakan 8 token, bukan 256, jumlah token output adalah 100, bukan 256, dan jumlah token yang lebih kecil memungkinkan 128 permintaan bersamaan. Ini adalah pengingat terakhir bahwa semua angka latensi dan throughput bergantung pada payload! Mengubah jumlah token payload akan memengaruhi proses pengelompokan selama penyajian model, yang pada gilirannya akan memengaruhi waktu pengisian awal, dekode, dan antrean yang muncul untuk aplikasi Anda.

Kesimpulan

Dalam postingan ini, kami menyajikan benchmarking SageMaker JumpStart LLM, termasuk Llama 2, Mistral, dan Falcon. Kami juga menyajikan panduan untuk mengoptimalkan latensi, throughput, dan biaya untuk konfigurasi penerapan titik akhir Anda. Anda dapat memulai dengan menjalankan notebook terkait untuk membandingkan kasus penggunaan Anda.

Tentang Penulis

 Dr.Kyle Ulrich adalah Ilmuwan Terapan di tim Amazon SageMaker JumpStart. Minat penelitiannya meliputi algoritma pembelajaran mesin yang dapat diskalakan, visi komputer, deret waktu, non-parametrik Bayesian, dan proses Gaussian. Gelar PhD-nya berasal dari Duke University dan dia telah menerbitkan makalah di NeurIPS, Cell, dan Neuron.

Dr. Vivek Madan adalah Ilmuwan Terapan dengan tim JumpStart Amazon SageMaker. Dia mendapatkan gelar PhD dari University of Illinois di Urbana-Champaign dan merupakan Peneliti Pasca Doktoral di Georgia Tech. Dia adalah peneliti aktif dalam pembelajaran mesin dan desain algoritma dan telah menerbitkan makalah di konferensi EMNLP, ICLR, COLT, FOCS, dan SODA.

Dr Ashish Khetan adalah Ilmuwan Terapan Senior di Amazon SageMaker JumpStart dan membantu mengembangkan algoritme pembelajaran mesin. Ia memperoleh gelar PhD dari University of Illinois Urbana-Champaign. Dia adalah peneliti aktif dalam pembelajaran mesin dan inferensi statistik, dan telah menerbitkan banyak makalah di konferensi NeurIPS, ICML, ICLR, JMLR, ACL, dan EMNLP.

João Moura adalah Arsitek Solusi Spesialis AI/ML Senior di AWS. João membantu pelanggan AWS – mulai dari startup kecil hingga perusahaan besar – melatih dan menerapkan model besar secara efisien, dan secara lebih luas membangun platform ML di AWS.

• Konten Bertenaga SEO & Distribusi PR. Dapatkan Amplifikasi Hari Ini.
• PlatoData.Jaringan Vertikal Generatif Ai. Berdayakan Diri Anda. Akses Di Sini.
• PlatoAiStream. Intelijen Web3. Pengetahuan Diperkuat. Akses Di Sini.
• PlatoESG. Karbon, teknologi bersih, energi, Lingkungan Hidup, Tenaga surya, Penanganan limbah. Akses Di Sini.
• PlatoHealth. Kecerdasan Uji Coba Biotek dan Klinis. Akses Di Sini.
• Sumber: https://aws.amazon.com/blogs/machine-learning/benchmark-and-optimize-endpoint-deployment-in-amazon-sagemaker-jumpstart/