GPU Cloud Terbaik untuk Penyajian & Penyebaran LLM

Apa yang sebenarnya dibutuhkan LLM serving dari GPU sewaan

Melayani model bahasa besar adalah beban kerja yang secara fundamental berbeda dari melatihnya. Pelatihan dibatasi oleh throughput dan toleran terhadap latensi; melayani sensitif terhadap latensi, dibatasi oleh memori, dan bersifat bursty. Ketika Anda menyewa GPU untuk menerapkan LLM di balik API, bottleneck jarang sekali berupa FLOPS mentah. Yang menjadi kendala adalah seberapa banyak model dan cache KV yang dapat Anda simpan di VRAM, seberapa cepat memori itu mengalirkan data, dan berapa banyak permintaan bersamaan yang dapat Anda batch sebelum token per detik per pengguna menurun.

Cache KV adalah bagian yang paling sering diremehkan orang. Setiap permintaan aktif menyimpan kunci dan nilai perhatian untuk konteksnya, dan jejak itu tumbuh seiring panjang urutan dan jumlah pengguna bersamaan. Model yang muat dengan nyaman saat idle bisa kehabisan memori saat Anda mendorong lalu lintas nyata dengan prompt panjang. Inilah mengapa penerapan serving sering membutuhkan ruang VRAM lebih besar daripada yang disarankan oleh bobot model saja.

Cara menentukan ukuran GPU sesuai model

Pertanyaan praktis pertama adalah apakah model muat di satu GPU atau harus dibagi ke beberapa GPU. Membaca perbandingan di atas terhadap model Anda, pertimbangkan faktor-faktor ini:

• Kapasitas VRAM menentukan model mana yang muat. Model kuantisasi 7B–13B dalam FP8 atau INT8 dapat dilayani dari satu akselerator kelas menengah, sementara model 70B dalam BF16 umumnya membutuhkan kartu memori besar atau node multi-GPU. Model frontier kelas sangat besar secara efektif memerlukan beberapa GPU kelas atas yang terhubung bersama.
• Bandwidth memori menentukan kecepatan generasi token Anda. Dekode autoregresif membaca seluruh set bobot untuk setiap token yang dihasilkan, jadi memori kelas HBM (seperti yang ditemukan pada kartu pusat data) menghasilkan token jauh lebih cepat daripada kartu konsumen berbasis GDDR pada ukuran model yang sama. Untuk chat interaktif, bandwidth sering kali lebih penting daripada komputasi.
• Presisi yang didukung menentukan seberapa agresif Anda dapat mengecilkan model. Kartu dengan dukungan tensor FP8 dan INT8 memungkinkan Anda melayani model yang lebih besar dengan VRAM lebih sedikit dan throughput lebih tinggi, asalkan tumpukan serving Anda dan skema kuantisasi model kompatibel.
• Interkoneksi penting ketika model tersebar di beberapa GPU. Serving paralel tensor bertukar aktivasi antar GPU di setiap lapisan, jadi tautan kelas NVLink dalam satu node memberikan latensi yang secara material lebih baik daripada konfigurasi hanya PCIe. Untuk penerapan satu GPU, interkoneksi tidak relevan.

Serving satu-GPU versus multi-GPU

Jika model Anda dan cache KV puncaknya muat di satu GPU, biarkan di situ. Serving satu-GPU menghindari overhead komunikasi antar perangkat sepenuhnya dan lebih sederhana untuk dioperasikan. Pindah ke paralelisme tensor atau serving multi-node hanya ketika model benar-benar tidak muat, karena setiap GPU tambahan memperkenalkan biaya sinkronisasi dan mempersulit autoscaling. Ketika Anda memang membutuhkan beberapa GPU, pilih instansi dalam daftar di atas yang menggabungkan kartu memori besar dengan interkoneksi cepat dalam node daripada menggabungkan kartu yang longgar.

Fitur penyedia yang penting untuk serving, bukan pelatihan

Selain silikon, model operasional penyedia menentukan apakah penerapan layak. Saat memindai perbandingan di atas untuk beban kerja serving daripada pelatihan, prioritaskan secara berbeda:

• Waktu mulai dingin dan setup menjadi perhatian utama. Endpoint serving yang dapat skala ke nol antara lonjakan lalu lintas membayar biaya mulai dingin setiap kali skala naik, jadi penyediaan cepat dan caching image langsung memengaruhi latensi ekor.
• Granularitas penagihan mengubah ekonomi lalu lintas bursty. Penagihan per detik atau per menit cocok untuk endpoint autoscaling yang memutar instansi naik turun; penagihan kasar per jam menghukum pola itu.
• Keandalan on-demand dibanding spot biasanya merupakan pilihan tepat. Instansi yang dapat diinterupsi atau spot sangat baik untuk pelatihan dan pekerjaan batch tetapi berisiko untuk endpoint yang berhadapan dengan pengguna, di mana pengambilan kembali di tengah permintaan menjatuhkan lalu lintas langsung. Spot masih dapat melayani inferensi batch non-interaktif dengan baik.
• Penyimpanan persisten dan pemuatan model cepat mengurangi rasa sakit restart. Bobot multi-gigabyte yang dimuat ulang dari penyimpanan objek dingin pada setiap restart menambah waktu henti beberapa menit; volume cache atau terpasang memperpendek itu.
• Jaringan dan egress memengaruhi biaya dalam skala besar. Inferensi throughput tinggi dapat memindahkan banyak data keluar; periksa ketentuan egress sebelum berkomitmen pada penerapan lalu lintas tinggi.

Batch versus real-time, dan di mana biaya berada

Putuskan lebih awal mode mana yang Anda optimalkan. Serving interaktif real-time menghargai waktu ke token pertama yang rendah dan tingkat token per pengguna yang stabil, yang menguntungkan memori bandwidth tinggi dan ukuran batch sedang. Inferensi batch atau offline menghargai throughput total dan dapat mengemas batch besar pada perangkat keras yang lebih murah atau dapat diinterupsi, menukar latensi per permintaan dengan biaya per token yang jauh lebih baik. Banyak tim menjalankan keduanya: tingkat on-demand responsif untuk pengguna langsung dan tingkat batch berbasis spot untuk generasi massal.

Untuk biaya sewa, serving berada di seluruh spektrum. Model kecil yang dikuantisasi pada kartu kelas menengah murah dan tersedia luas; model frontier pada node multi-GPU memori besar langka, lebih mahal, dan terkadang kapasitas terbatas saat puncak permintaan. Karena tarif bergerak terus dan bervariasi menurut wilayah dan komitmen, anggap perbandingan langsung di atas sebagai sumber kebenaran daripada angka tetap, dan bandingkan instansi berdasarkan VRAM, kelas bandwidth, interkoneksi, dan model penagihan bersama daripada harga utama saja.

Pertanyaan yang sering diajukan

Berapa banyak VRAM yang saya butuhkan untuk melayani LLM?

Anggarkan bobot model pada presisi pilihan Anda plus ruang kepala yang substansial untuk cache KV, yang tumbuh dengan panjang konteks dan pengguna bersamaan. Sebagai panduan kasar, model kecil dan menengah yang dikuantisasi dapat dilayani dari satu kartu kelas menengah, sementara model besar dengan presisi lebih tinggi membutuhkan kartu memori besar atau beberapa GPU. Selalu ukur untuk puncak konkuren, bukan saat idle.

Apakah GPU spot atau yang dapat diinterupsi cocok untuk serving LLM?

Untuk endpoint real-time yang berhadapan dengan pengguna, umumnya tidak, karena pengambilan kembali dapat menjatuhkan permintaan langsung dan memaksa restart dingin. Instansi spot cocok untuk inferensi offline atau batch, di mana interupsi hanya menunda throughput daripada memutus sesi interaktif. Banyak tim menyimpan kapasitas on-demand untuk lalu lintas langsung dan menggunakan spot untuk pekerjaan massal.

Mengapa bandwidth memori lebih penting daripada komputasi untuk serving?

Dekode token per token membaca bobot model dari memori untuk setiap token yang dihasilkan, jadi kecepatan generasi dibatasi oleh seberapa cepat GPU mengalirkan memori daripada FLOPS puncaknya. Inilah sebabnya kartu pusat data dengan HBM menghasilkan token lebih cepat daripada kartu konsumen yang memegang model yang sama, dan mengapa bandwidth adalah kolom kunci untuk dibandingkan di atas.

Haruskah saya melayani di satu GPU atau membagi ke beberapa?

Gunakan satu GPU kapan pun model dan cache KV puncaknya muat, karena itu menghindari komunikasi antar perangkat dan menyederhanakan penskalaan. Pindah ke paralelisme tensor multi-GPU hanya ketika model benar-benar tidak muat, dan ketika Anda melakukannya, pilih instansi yang menggabungkan kartu memori besar dengan interkoneksi cepat dalam node.