Tingkatkan kinerja model Falcon dengan Amazon SageMaker | Layanan Web Amazon

Kerangka kerja dan konfigurasi apa yang optimal untuk menghosting model bahasa besar (LLM) untuk aplikasi AI generatif penghasil teks? Meskipun banyaknya pilihan untuk melayani LLM, ini adalah pertanyaan yang sulit dijawab karena ukuran model, arsitektur model yang bervariasi, persyaratan kinerja aplikasi, dan banyak lagi. Itu Amazon SageMaker Wadah Inferensi Model Besar (LMI). memudahkan untuk melayani LLM dengan menyatukan sejumlah kerangka kerja dan teknik berbeda yang mengoptimalkan penerapan LLM. Kontainer LMI memiliki tumpukan penyajian kuat yang disebut Penyajian DJL itu agnostik terhadap LLM yang mendasarinya. Ini memberikan parameter konfigurasi tingkat sistem yang dapat disesuaikan untuk mengekstrak kinerja terbaik dari infrastruktur hosting untuk LLM tertentu. Ini juga memiliki dukungan untuk pengoptimalan terkini seperti pengelompokan berkelanjutan, juga dikenal sebagai pengelompokan berulang atau pengelompokan bergulir, yang memberikan peningkatan throughput yang signifikan.

Di awal pos, kami menunjukkan bagaimana Anda dapat menggunakan kontainer LMI untuk menerapkan model keluarga Falcon di SageMaker. Dalam postingan ini, kami mendemonstrasikan cara meningkatkan throughput dan latensi penyajian Falcon-40B dengan teknik seperti batching berkelanjutan. Kami juga memberikan pemahaman intuitif tentang parameter konfigurasi yang disediakan oleh kontainer LMI SageMaker yang dapat membantu Anda menemukan konfigurasi terbaik untuk aplikasi dunia nyata Anda.

Dasar-dasar inferensi generatif teks untuk LLM

Pertama mari kita lihat beberapa dasar tentang cara melakukan inferensi untuk LLM untuk pembuatan teks.

Forward pass, aktivasi, dan cache KV

Mengingat urutan input token, mereka dijalankan di a forward pass di semua lapisan LLM (seperti Falcon) untuk menghasilkan token berikutnya. A forward pass mengacu pada proses data masukan yang dilewatkan melalui jaringan saraf untuk menghasilkan keluaran. Dalam kasus pembuatan teks, forward pass melibatkan memasukkan benih atau konteks awal ke dalam model bahasa dan menghasilkan karakter atau token berikutnya dalam urutan tersebut. Untuk menghasilkan suatu rangkaian teks, prosesnya sering dilakukan secara iteratif, artinya diulangi untuk setiap langkah atau posisi dalam rangkaian keluaran. Pada setiap iterasi, model menghasilkan karakter atau token berikutnya, yang menjadi bagian dari teks yang dihasilkan, dan proses ini berlanjut hingga panjang teks yang diinginkan dihasilkan.

Pembuatan teks dengan model bahasa seperti Falcon atau GPT autoregressive. Artinya, model menghasilkan satu token pada satu waktu sambil mengkondisikan token yang dibuat sebelumnya. Dengan kata lain, pada setiap iterasi, model mengambil teks yang dihasilkan sebelumnya sebagai masukan dan memprediksi token berikutnya berdasarkan konteks tersebut. Seperti disebutkan dalam vLLM: Pelayanan LLM Mudah, Cepat, dan Murah dengan PagedAttention, dalam proses decoding autoregresif ini, semua token masukan ke LLM menghasilkan kunci perhatian dan tensor nilainya, dan tensor ini disimpan dalam memori GPU untuk menghasilkan token berikutnya. Tensor kunci dan nilai yang di-cache ini sering disebut sebagai KV cache.

Fase pra-pengisian dan dekode

Dalam proses decoding autoregresif, seperti yang digunakan dalam pembuatan teks dengan model bahasa seperti Falcon, biasanya ada dua fase utama: prefill fase dan decode fase. Fase-fase ini penting untuk menghasilkan teks yang koheren dan relevan secara kontekstual.

Tahap pra-pengisian mencakup hal-hal berikut:

• Konteks awal – Fase pra-pengisian dimulai dengan konteks awal atau teks awal yang disediakan oleh pengguna. Konteks awal ini bisa berupa kalimat, frasa, atau bahkan satu kata saja. Ini menetapkan titik awal untuk pembuatan teks dan memberikan konteks untuk apa yang akan terjadi selanjutnya.
• Pengkondisian model – Konteks yang disediakan digunakan untuk mengkondisikan model bahasa. Model mengambil konteks ini sebagai masukan dan menghasilkan token berikutnya (kata atau karakter) dalam urutan berdasarkan pemahamannya terhadap konteks tersebut.
• Pembuatan token – Model menghasilkan satu token pada satu waktu, memprediksi apa yang akan terjadi selanjutnya dalam teks. Token ini ditambahkan ke konteksnya, sehingga secara efektif memperluasnya.
• Proses iteratif – Proses pembuatan token diulangi secara berulang. Pada setiap langkah, model menghasilkan token sambil mempertimbangkan konteks yang diperbarui, yang kini mencakup token yang dihasilkan pada langkah sebelumnya.

Fase pengisian awal berlanjut hingga kondisi penghentian yang telah ditentukan terpenuhi. Kondisi ini dapat berupa panjang maksimum teks yang dihasilkan, token spesifik yang menandakan akhir teks, atau kriteria lain yang ditetapkan oleh pengguna atau aplikasi.

Fase dekode meliputi hal-hal berikut:

• Penyelesaian – Setelah fase pra-pengisian, Anda memiliki teks yang dihasilkan sebagian yang mungkin tidak lengkap atau terpotong di beberapa titik. Fase dekode bertugas melengkapi teks agar koheren dan benar secara tata bahasa.
• Lanjutan dari token terakhir – Pada fase decode, model dimulai dari token terakhir yang dihasilkan selama fase prefill. Ia menggunakan token ini sebagai konteks awal dan menghasilkan token berikutnya untuk melanjutkan teks.
• Penyelesaian berulang – Seperti pada fase pra-pengisian, proses pembuatan token sekali lagi bersifat berulang. Model ini menghasilkan satu token pada satu waktu, mengkondisikan token sebelumnya dalam urutan.
• Kondisi berhenti – Fase dekode juga memiliki kondisi penghentian, yang mungkin sama dengan fase pra-pengisian, seperti mencapai panjang maksimum atau menemukan token akhir teks. Jika kondisi ini terpenuhi, proses pembangkitan terhenti.

Kombinasi fase prefill dan decode memungkinkan model autoregresif menghasilkan teks yang dibangun berdasarkan konteks awal dan menghasilkan rangkaian teks yang koheren, relevan secara kontekstual, dan konsisten secara kontekstual.

Lihat Sistem Pelayanan Terdistribusi untuk Model Generatif Berbasis Transformer untuk penjelasan rinci tentang prosesnya.

Mengoptimalkan throughput menggunakan batching dinamis

Sejauh ini, kita hanya membicarakan satu masukan saja. Dalam praktiknya, kami berharap dapat menangani beberapa permintaan yang datang secara acak dari klien aplikasi untuk inferensi secara bersamaan atau secara bertahap. Dengan cara tradisional, batching dasar dapat digunakan untuk meningkatkan throughput dan pemanfaatan sumber daya komputasi GPU. Batching secara efektif menggabungkan representasi numerik lebih dari satu permintaan dalam satu batch dan melakukan proses paralel dari forward pass autoregresif. Pengelompokan cerdas ini dilakukan di sisi penyajian. Server DJLServing SageMaker LMI dapat dikonfigurasi untuk mengumpulkan beberapa permintaan untuk memprosesnya secara paralel dengan mengatur parameter berikut di melayani.properti:

• max_batch_delay = 100 – Penundaan maksimum untuk agregasi batch dalam milidetik. Nilai defaultnya adalah 100 milidetik.
• ukuran_batch = 32 – Ukuran batch dinamis. Standarnya adalah 1.

Ini pada dasarnya menunjukkan bahwa DJLServing akan mengantri permintaan selama 100 milidetik pada satu waktu atau jika jumlah permintaan yang mengantri mencapai ukuran_batch yang ditentukan, batch akan dijadwalkan untuk dijalankan ke backend untuk inferensi. Ini dikenal sebagai dynamic batching. Ini dinamis karena ukuran batch dapat berubah antar batch tergantung pada berapa banyak permintaan yang ditambahkan dalam durasi waktu tersebut. Namun, karena permintaan mungkin memiliki karakteristik yang berbeda, (misalnya, beberapa permintaan mungkin berbentuk 20 token masukan dan 500 token keluaran, sedangkan permintaan lainnya mungkin terbalik, dengan 500 token masukan namun hanya 20 token keluaran), beberapa permintaan mungkin menyelesaikan pemrosesan lebih cepat daripada yang lain dalam batch yang sama. Hal ini dapat mengakibatkan kurang dimanfaatkannya GPU saat menunggu semua permintaan dalam penerbangan dalam batch menyelesaikan tahap dekode, bahkan jika ada permintaan tambahan yang menunggu untuk diproses dalam antrean. Diagram berikut menggambarkan proses ini.

Mengoptimalkan throughput menggunakan batching berkelanjutan

Dengan continuous batching, juga dikenal sebagai iterative or rolling batching, kami memanfaatkan perbedaan antara tahap prefill dan decode. Untuk mengaktifkan pengelompokan berkelanjutan, DJServing menyediakan konfigurasi tambahan berikut sesuai properti penyajian:

• mesin=MPI – Kami mendorong Anda untuk menggunakan mesin MPI untuk batching berkelanjutan.
• opsi.rolling_batch=auto atau lmi-dist – Kami merekomendasikan penggunaan auto karena secara otomatis akan memilih algoritme rolling batch yang paling sesuai bersama dengan pengoptimalan lainnya di masa mendatang.
• pilihan.max_rolling_batch_size=32 – Ini membatasi jumlah permintaan bersamaan. Standarnya adalah 32.

Dengan pengelompokan berkelanjutan, tumpukan penyajian (DJLServing) tidak menunggu semua permintaan dalam penerbangan dalam satu kumpulan untuk menyelesaikan tahap dekodenya. Sebaliknya, pada jeda logis (di akhir satu iterasi dalam tahap decode), ia menarik permintaan tambahan yang menunggu dalam antrian sementara batch saat ini masih memproses (karena itulah namanya kumpulan bergulir). Ini melakukan pemeriksaan permintaan yang tertunda pada akhir setiap iterasi tahap dekode. Ingat, untuk setiap permintaan, kita perlu menjalankan tahap pra-pengisian diikuti dengan tahap dekode berurutan. Karena kami dapat memproses semua token dari permintaan awal permintaan secara paralel untuk tahap pra-pengisiannya, kapan pun permintaan baru ditarik, kami menghentikan sementara tahap dekode permintaan dalam penerbangan batch—kami menyimpan sementara cache KV-nya dan aktivasi di memori dan menjalankan tahap pra-pengisian permintaan baru.

Ukuran cache ini dapat dikonfigurasi dengan opsi berikut:

Ketika pra-pengisian selesai, kami menggabungkan permintaan baru dan permintaan lama yang dijeda dalam batch bergulir baru, yang dapat melanjutkan tahap dekode secara paralel. Perhatikan bahwa permintaan lama yang dijeda dapat melanjutkan tahap dekode dari tahap terakhirnya dan permintaan baru akan dimulai dari token baru yang pertama.

Anda mungkin sudah menyadari bahwa pengelompokan berkelanjutan adalah pendekatan yang hampir serupa yang secara alami kita gunakan untuk memparalelkan tugas-tugas dalam kehidupan sehari-hari. Kami memiliki pesan, email, notifikasi telepon (kemungkinan permintaan baru) yang masuk secara acak (analog dengan beberapa permintaan yang datang secara acak dan terhuyung-huyung untuk GPU). Ini semua terjadi saat kita menyelesaikan tugas-tugas dalam penerbangan—menulis email, coding, berpartisipasi dalam rapat (analog dengan tugas-tugas yang sedang diproses di GPU). Pada jeda logis, kami menjeda tugas dalam penerbangan dan memeriksa notifikasi untuk memutuskan apakah ada tindakan yang diperlukan dari pihak kami, dan jika ada, kami menambahkannya ke tugas dalam penerbangan (batch bergulir di kehidupan nyata), atau memasukkannya ke dalam daftar tugas (antrian).

Menyatukan semuanya: Bagaimana memikirkan pemanfaatan memori GPU

Sebaiknya uji beban model Anda untuk melihat konfigurasi mana yang paling hemat biaya untuk kasus penggunaan bisnis Anda. Untuk membangun pemahaman, mari kita visualisasikan jejak memori GPU saat model dimuat dan saat permintaan berturut-turut diproses dalam batch yang bergulir. Untuk postingan ini, anggaplah kita memuat model Falcon-40B ke salah satu tipe instans G5 yang diinstal dengan GPU NVIDIA A10G, masing-masing dengan memori 24 GB. Perhatikan bahwa pemahaman serupa berlaku untuk jenis instans p3, p4, dan p5, yang hadir dengan seri GPU V100, A100, dan H100.

Berikut gambaran umum untuk mendapatkan perkiraan nilai total memori yang dibutuhkan untuk melayani Falcon-40B:

• Ukuran model = Jumlah parameter model (40 miliar untuk Falcon-40B) x 4 byte per parameter (untuk FP32) = 160 GB
• Perkiraan total memori yang diperlukan untuk memuat Falcon-40B untuk inferensi = Ukuran model (=160 GB) + KV Cache (Cache Perhatian) (=*20 GB) + Overhead memori tambahan oleh ML Frameworks (kira-kira 2 GB)

Untuk Falcon-40B, jika kita mengompresi model dengan mengkuantisasi model ke tipe data bfloat16 (2 byte), ukuran model menjadi sekitar 80 GB. Seperti yang Anda lihat, ini masih lebih besar dari memori yang didukung oleh satu perangkat akselerator, jadi kita perlu mengadopsi teknik partisi model (sharding) dengan cara khusus. paralelisme tensor (TP) melakukan pendekatan dan membagi model ke beberapa perangkat akselerator. Anggaplah kita telah memilih g5.24xlarge, yang memiliki 4 perangkat GPU A10G. Jika kita mengonfigurasi DJLServing (serving.properties) dengan yang berikut ini, kita dapat berharap bahwa bobot model 80 GB akan dibagi rata ke keempat GPU:

Dengan tensor_parallel_degree diatur ke 4, sekitar 20 GB dari memori GPU 24 GB (sekitar 84%) sudah digunakan bahkan sebelum satu permintaan diproses. 16% sisanya dari GPU akan digunakan untuk cache KV untuk permintaan masuk. Mungkin saja untuk skenario bisnis Anda serta persyaratan latensi dan throughputnya, sisa memori 2–3 GB sudah lebih dari cukup. Jika tidak, Anda dapat meningkatkan ukuran instans menjadi g5.48xlarge, yang memiliki 8 GPU dan menggunakan tensor_parallel_degree yang disetel ke 8. Dalam kasus seperti ini, hanya sekitar 10 GB dari memori 24 GB yang tersedia di setiap GPU yang digunakan untuk bobot model dan kami memiliki sekitar 60% sisa GPU untuk aktivasi dan cache KV. Secara intuitif, kita dapat melihat bahwa konfigurasi ini memungkinkan kita mendapatkan throughput yang lebih tinggi. Selain itu, karena kami memiliki buffer yang lebih besar sekarang, kami dapat meningkatkannya max_rolling_batch_prefill_tokens dan max_rolling_batch_size parameter untuk lebih mengoptimalkan throughput. Bersama-sama, kedua parameter ini akan mengontrol praalokasi pra-pengisian aktivasi dan cache KV untuk model. Angka yang lebih besar untuk kedua parameter ini akan berhubungan dengan throughput yang lebih besar, dengan asumsi Anda memiliki buffer yang cukup untuk cache KV di memori GPU.

Pengelompokan berkelanjutan dengan PagedAttention

PagedAttention adalah algoritma optimasi baru yang dikembangkan oleh UC Berkeley yang meningkatkan proses batching berkelanjutan dengan memungkinkan cache perhatian (cache KV) menjadi tidak bersebelahan dengan mengalokasikan memori dalam halaman atau blok berukuran tetap. Ini terinspirasi oleh memori virtual dan konsep paging yang digunakan oleh sistem operasi.

Sesuai dengan vLLM kertas, cache perhatian dari setiap urutan token dipartisi menjadi blok-blok dan dipetakan ke blok fisik melalui tabel blok. Selama penghitungan perhatian, kernel PagedAttention dapat menggunakan tabel blok untuk mengambil blok dari memori fisik secara efisien. Hal ini menghasilkan pengurangan pemborosan memori secara signifikan dan memungkinkan ukuran batch yang lebih besar, peningkatan pemanfaatan GPU, dan throughput yang lebih tinggi.

Perbandingan kinerja

Untuk memastikan pengujian beban yang efektif pada konfigurasi penerapan Anda, disarankan untuk memulai dengan mempertimbangkan skenario bisnis dan mendefinisikan dengan jelas karakteristik input dan output untuk aplikasi berbasis LLM. Misalnya, jika Anda mengerjakan kasus penggunaan ringkasan pusat panggilan, masukannya dapat terdiri dari teks yang lebih besar, seperti transkrip obrolan 500 token antara agen layanan pelanggan dan pelanggan, namun keluarannya mungkin relatif lebih kecil, sekitar 100 token, mewakili ringkasan transkrip. Di sisi lain, jika Anda sedang mengerjakan skenario pembuatan kode, masukannya bisa sesingkat 15 token, seperti “tulis implementasi yang efisien dengan Python untuk mendeskripsikan semua sumber daya EC2, termasuk penomoran halaman,” tetapi keluarannya bisa jauh lebih besar. lebih besar, mencapai 500 token. Penting juga untuk mempertimbangkan apakah mencapai latensi yang lebih rendah atau memaksimalkan throughput adalah prioritas utama untuk skenario spesifik Anda.

Setelah mendapatkan pemahaman komprehensif tentang skenario bisnis, Anda dapat menganalisis dan menentukan konfigurasi optimal untuk lingkungan hosting Anda. Dalam konteks ini, lingkungan hosting mencakup berbagai elemen kunci, termasuk jenis instans dan parameter konfigurasi lainnya seperti tensor_parallel_degree, max_rolling_batch_size, max_rolling_batch_prefill_tokens, dan banyak lagi. Tujuan kami adalah mengidentifikasi pengaturan yang paling efektif untuk mendukung persyaratan waktu respons, throughput, dan kualitas output model kami.

Dalam analisis kami, kami membandingkan kinerja untuk mengilustrasikan manfaat pengelompokan berkelanjutan dibandingkan pengelompokan dinamis tradisional. Kami menggunakan konfigurasi yang dirinci dalam tabel berikut di properti penyajian untuk pengelompokan dinamis dan pengelompokan berulang, menggunakan wadah LMI di SageMaker.

Pengelompokan Dinamis	Pengelompokan terus menerus	Batching Berkelanjutan dengan PagedAttention
mesin=Python pilihan.model_id=tiiuae/falcon-40b opsi.tensor_parallel_degree=8 opsi.dtype=fp16 ukuran_batch=4 max_batch_delay=100 pilihan.trust_remote_code = benar	mesin = MPI pilihan.model_id = {{s3_url}} pilihan.trust_remote_code = benar pilihan.tensor_parallel_degree = 8 pilihan.max_rolling_batch_size = 32 option.rolling_batch = otomatis opsi.dtype = fp16 pilihan.max_rolling_batch_prefill_tokens = 1024 option.paged_attention = Salah	mesin = MPI pilihan.model_id = {{s3_url}} pilihan.trust_remote_code = benar pilihan.tensor_parallel_degree = 8 pilihan.max_rolling_batch_size = 32 option.rolling_batch = otomatis opsi.dtype = fp16 pilihan.max_rolling_batch_prefill_tokens = 1024 option.paged_attention = Benar

Kedua konfigurasi tersebut dijadikan tolok ukur untuk Falcon-40B dengan tipe data FP16 yang diterapkan pada ml.g5.48xlarge dalam beberapa skenario berbeda yang mewakili aplikasi dunia nyata:

• Sejumlah kecil token masukan dengan sejumlah besar token dihasilkan – Dalam skenario ini, jumlah token masukan ditetapkan sebesar 32 dan 128 token baru dihasilkan

Strategi Pengelompokan	Throughput (token/dtk)	Latensi p90 (detik)
Pengelompokan Dinamis	5.53	58.34
Pengelompokan terus menerus	56.04	4.74
Batching Berkelanjutan dengan PagedAttention	59.18	4.76

• Masukan besar dengan sejumlah kecil token yang dihasilkan – Di sini, kami menetapkan jumlah token masukan pada 256 dan meminta LLM untuk meringkas masukan menjadi 32 token

Strategi Pengelompokan	Throughput (token/dtk)	Latensi p90 (detik)
Pengelompokan Dinamis	19.96	59.31
Pengelompokan terus menerus	46.69	3.88
Batching Berkelanjutan dengan PagedAttention	44.75	2.67

Kita dapat melihat bahwa batching berkelanjutan dengan PagedAttention memberikan peningkatan throughput 10 kali lebih besar pada skenario 1 dan 2.3 kali lipat pada skenario 2 dibandingkan menggunakan batching dinamis pada SageMaker saat menggunakan container LMI.

Kesimpulan

Dalam postingan ini, kami melihat bagaimana LLM menggunakan memori dan menjelaskan bagaimana pengelompokan berkelanjutan meningkatkan throughput menggunakan wadah LMI di SageMaker. Kami mendemonstrasikan manfaat batching berkelanjutan untuk Falcon-40B menggunakan kontainer LMI di SageMaker dengan menunjukkan hasil benchmark. Anda dapat menemukan kodenya di GitHub repo.

---

Tentang Penulis

Abhi Shivaditya adalah Arsitek Solusi Senior di AWS, bekerja dengan organisasi perusahaan global strategis untuk memfasilitasi penerapan layanan AWS di berbagai bidang seperti Kecerdasan Buatan, komputasi terdistribusi, jaringan, dan penyimpanan. Keahliannya terletak pada Deep Learning dalam domain Natural Language Processing (NLP) dan Computer Vision. Abhi membantu pelanggan dalam menerapkan model pembelajaran mesin berkinerja tinggi secara efisien dalam ekosistem AWS.

Dhawal Patel adalah Arsitek Pembelajaran Mesin Utama di AWS. Dia telah bekerja dengan organisasi mulai dari perusahaan besar hingga perusahaan rintisan menengah pada masalah yang terkait dengan komputasi terdistribusi, dan Kecerdasan Buatan. Dia berfokus pada Deep learning termasuk domain NLP dan Computer Vision. Dia membantu pelanggan mencapai inferensi model kinerja tinggi di SageMaker.

Pinak Panigrahi bekerja dengan pelanggan untuk membangun solusi berbasis pembelajaran mesin untuk memecahkan masalah bisnis strategis di AWS. Saat tidak sibuk dengan pembelajaran mesin, ia dapat ditemukan sedang berjalan-jalan, membaca buku, atau menonton olahraga.

Abhi Sodhani memegang posisi Senior Arsitek Solusi AI/ML di AWS, dengan spesialisasi dalam menawarkan keahlian teknis dan panduan mengenai solusi AI Generatif dan ML kepada pelanggan. Fokus utamanya adalah membantu Bisnis Digital Native dalam mewujudkan potensi penuh teknologi AI Generatif dan ML, sehingga memungkinkan mereka mencapai tujuan bisnis secara efektif. Di luar usaha profesionalnya, Abhi menunjukkan hasrat yang kuat untuk kegiatan intelektual seperti membaca, serta terlibat dalam aktivitas yang meningkatkan kesejahteraan fisik dan mental, seperti yoga, meditasi.

Qinglan adalah Insinyur Pengembangan Perangkat Lunak di AWS. Dia telah mengerjakan beberapa produk yang menantang di Amazon, termasuk solusi inferensi ML kinerja tinggi dan sistem logging kinerja tinggi. Tim Qing berhasil meluncurkan model Billion-parameter pertama di Amazon Advertising dengan latensi yang sangat rendah. Qing memiliki pengetahuan mendalam tentang pengoptimalan infrastruktur dan akselerasi Deep Learning.

• 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/improve-performance-of-falcon-models-with-amazon-sagemaker/