Kuantisasi vLLM dapat membuat model muat dalam memori GPU yang lebih kecil, tetapi ini bukan sakelar peningkatan kecepatan universal. Checkpoint yang lebih kecil dapat menyisakan lebih banyak ruang untuk cache KV dan permintaan konkurensi. Throughput aktual bergantung pada model, format kuantisasi, arsitektur GPU, kernel, panjang prompt, panjang output, dan pola trafik. Keputusan yang masuk akal adalah memilih format yang didukung, lalu mengukur beban kerja yang representatif terhadap baseline tanpa kuantisasi.
Panduan kuantisasi vLLM ini memberi Anda proses pemilihan dan pengujian yang praktis. Panduan ini tidak mengklaim hasil benchmark untuk GPU atau model yang belum kami uji.
Apa yang diubah oleh kuantisasi vLLM
Kuantisasi menyimpan sebagian nilai model dalam bit yang lebih sedikit daripada checkpoint FP16 atau BF16 pada umumnya. Efek orde pertama yang paling jelas adalah memori bobot yang lebih rendah. Jika memori bobot adalah alasan model tidak dapat dimuat, checkpoint terkuantisasi yang kompatibel mungkin memungkinkannya berjalan pada GPU yang lebih kecil atau dengan lebih banyak memori yang tersisa untuk permintaan. GPU tetap memerlukan memori untuk aktivasi, cache KV, overhead runtime, dan worker paralel apa pun. Karena itu, membagi jumlah parameter dengan bit per bobot hanyalah batas bawah kasar, bukan estimasi memori yang dapat digunakan untuk deployment.
Ada dua jalur umum untuk kuantisasi vLLM. Anda dapat memuat checkpoint yang telah dikuantisasi sebelumnya, atau menggunakan jalur kuantisasi online yang didukung pada waktu pemuatan. Dalam kedua kasus, periksa kartu model dan matriks kompatibilitas vLLM terkini sebelum memilih format. Dokumentasi kuantisasi vLLM adalah sumber kebenaran untuk metode dan dukungan perangkat keras; dokumentasi tersebut secara eksplisit memperingatkan bahwa matriks berubah seiring perkembangan dukungan.
Pilih format dari checkpoint dan GPU
| Opsi | Titik awal praktis | Verifikasi sebelum deployment |
|---|---|---|
| AWQ | Model yang didistribusikan sebagai checkpoint AWQ dan GPU yang kompatibel | Kualitas model, pemilihan kernel, panjang prompt, dan latensi aktual. |
| GPTQ | Model yang didistribusikan sebagai checkpoint GPTQ | Konfigurasi checkpoint yang tepat, versi vLLM, dukungan GPU, dan regresi kualitas. |
| FP8 | Checkpoint yang kompatibel dan GPU dengan eksekusi FP8 yang didukung | Apakah implementasi vLLM yang dipilih mendukung arsitektur Anda dan lapisan model. |
| GGUF | Model yang sudah didistribusikan dalam format GGUF | Arsitektur spesifik dan dukungan fitur vLLM; jangan mengasumsikan perilaku Ollama dipetakan satu-ke-satu. |
| BitsAndBytes atau tensor terkompresi | Checkpoint dan jalur deployment yang secara eksplisit memerlukannya | Dependensi runtime, perilaku pemuatan, kernel yang didukung, dan throughput. |
Matriks vLLM saat ini mencantumkan AWQ dan GPTQ untuk Ampere, Ada, dan
Hopper. Matriks tersebut mencantumkan FP8 melalui llm-compressor untuk Ada,
Hopper, dan beberapa jalur GPU AMD, sedangkan GGUF memiliki pola dukungan yang berbeda.
A100 adalah GPU Ampere dan H100 adalah GPU Hopper, tetapi dukungan bersifat
spesifik per metode. Jangan menyimpulkan bahwa setiap varian FP8, FP4, atau Marlin
berfungsi pada setiap kartu dalam suatu keluarga. Periksa baris yang tepat dalam tabel
kompatibilitas perangkat keras dan metadata checkpoint itu sendiri.
Jika Anda belum memilih model, bandingkan dua checkpoint kandidat yang menggunakan model dasar dan set evaluasi yang sama. Membandingkan model AWQ dari satu keluarga dengan model tanpa kuantisasi dari keluarga lain akan mencampuradukkan kuantisasi vLLM dengan kualitas model.
Alur kerja deployment yang menghindari kemenangan semu
- Tentukan target layanan. Catat model, panjang konteks, panjang input dan output yang diharapkan, permintaan konkurensi, target latensi p95, dan pengujian kualitas. Chatbot, pengklasifikasi batch, dan agen konteks panjang memiliki bottleneck yang berbeda.
- Catat baseline. Jalankan checkpoint tanpa kuantisasi pada GPU dan versi vLLM yang sama. Catat penggunaan puncak memori GPU, waktu hingga token pertama, throughput token output, latensi p50/p95 end-to-end, error, dan tingkat hasil yang diterima.
- Pilih checkpoint terkuantisasi yang kompatibel. Baca kartu modelnya dan matriks metode vLLM terkini. Tetapkan revisi checkpoint, versi vLLM, stack CUDA/driver, dan SKU perangkat keras dalam catatan pengujian.
- Mulai dengan canary kecil. Konfirmasikan bahwa model dapat dimuat, melayani endpoint dan pengaturan generasi yang Anda perlukan, serta menghasilkan output yang masuk akal sebelum menerapkan trafik.
- Lakukan benchmark pada beberapa tingkat konkurensi. Ukur pada panjang prompt dan respons nyata Anda. Satu permintaan dapat lebih menguntungkan konfigurasi yang berbeda dibandingkan layanan berkelanjutan.
- Jalankan suite kualitas yang sama. Kuantisasi dapat mengubah output. Evaluasi ketepatan khusus domain, kepatuhan format, penolakan, dan kasus sensitif keselamatan alih-alih hanya mempercayai perplexity.
- Hitung biaya per hasil yang diterima. Harga GPU per jam dibagi token mentah per detik tidak cukup jika model terkuantisasi gagal menyelesaikan lebih banyak tugas atau memerlukan percobaan ulang.
Untuk benchmark serving, vLLM mendokumentasikan vllm bench serve
beserta dataset dan opsi endpoint-nya dalam panduan CLI
benchmark resmi. Gunakan dataset trafik yang sesuai dengan aplikasi Anda;
prompt acak sintetis berguna untuk perbandingan terkontrol, tetapi
tidak boleh disajikan sebagai performa produksi.
Perencanaan memori: bobot hanyalah salah satu pos
Lembar kerja perencanaan sederhana memisahkan empat kategori:
total GPU memory needed ≈ model weights + KV cache + runtime/activation overhead + safety headroom
Format kuantisasi terutama mengubah komponen bobot model. Tekanan cache KV meningkat seiring panjang konteks dan urutan aktif. Model yang nyaris muat untuk satu permintaan masih dapat gagal atau melambat secara tajam saat menghadapi trafik konteks panjang yang bersamaan. Pada pengaturan multi-GPU, paralelisme tensor mengubah memori per kartu dan overhead komunikasi; checkpoint sekecil mungkin tidak secara otomatis menjadi penerapan termurah.
Sebelum menyewa GPU, tanyakan apakah Anda perlu memuat satu model yang lebih besar, meningkatkan konkurensi untuk model yang lebih kecil, atau mengurangi biaya sambil mempertahankan kualitas. Jawaban tersebut menentukan kompromi memori dan throughput mana yang penting. Flatkey Cloud GPU Compute mencantumkan opsi penyewaan GPU dan meminta pelanggan mengonfirmasi konfigurasi, wilayah, kapasitas, dan ketentuan sewa. Perlakukan ketersediaan dan harga langsung sebagai masukan pada saat penawaran, bukan angka tetap dalam artikel benchmark.
Melakukan benchmark kuantisasi vLLM secara adil
Pertahankan model dasar, parameter generasi, kumpulan prompt, batas output, status cache, dan GPU yang sama. Ukur setidaknya tiga beban: satu permintaan untuk responsivitas, konkurensi produksi yang representatif, dan titik stres saat latensi mulai menurun. Laporkan throughput total dan latensi p95. Jika Anda hanya melaporkan token per detik pada saturasi, pengguna tidak dapat mengetahui apakah permintaan interaktif tetap dapat diterima.
Sertakan kualitas model dalam kartu penilaian:
| Ukuran | Mengapa penting |
|---|---|
| Memori GPU puncak | Menunjukkan apakah kuantisasi menciptakan ruang cadangan yang dapat digunakan. |
| Waktu hingga token pertama | Penting untuk antarmuka streaming. |
| Token output per detik | Menunjukkan throughput generasi, tetapi bukan kualitas tugas. |
| Latensi end-to-end p95 | Mengungkap perilaku ekor saat berada di bawah beban. |
| Tingkat error dan OOM | Mendeteksi konfigurasi yang tampak cepat hanya ketika permintaan berhasil. |
| Tingkat hasil yang diterima | Mengubah kecepatan mentah menjadi pekerjaan yang berguna. |
Perbandingan utama untuk kuantisasi vLLM bukanlah “terkuantisasi versus tidak terkuantisasi” secara abstrak. Perbandingannya adalah “checkpoint dan kernel ini pada GPU ini, dengan beban kerja ini, versus baseline kami.” Publikasikan kondisi tersebut bersama setiap hasil. Jika pengujian Anda tidak memiliki pemeriksaan kualitas, sebut sebagai eksperimen khusus performa.
Mode kegagalan umum
Model tidak dapat dimuat. Periksa metadata checkpoint, metode kuantisasi, versi vLLM, kemampuan GPU, serta apakah metode tersebut mendukung setiap lapisan yang digunakan oleh arsitektur. Matriks metode vLLM harus diperiksa sebelum Anda mengubah flag perintah secara membabi buta.
Penghematan memori tidak meningkatkan latensi. Jejak bobot yang lebih kecil tidak menjamin kernel yang lebih cepat. Uji pada konkurensi target Anda dan periksa waktu hingga token pertama, kecepatan dekode, serta utilisasi GPU. Ruang cadangan cache KV yang lebih besar mungkin merupakan manfaat sebenarnya.
Checkpoint bit rendah tampak cepat tetapi gagal dalam pengujian kualitas. Pertahankan kumpulan penerimaan produksi dan ukur persentase output yang memenuhi kriteria aplikasi Anda. Ambang rollback harus ditetapkan sebelum canary.
Benchmark tidak dapat direproduksi. Catat revisi model dan checkpoint, versi vLLM dan driver, SKU GPU, dataset, konkurensi, panjang prompt, panjang output, dan argumen perintah. Tanpa hal-hal ini, angka throughput adalah pemasaran, bukan bukti rekayasa.
Kapan menggunakan Flatkey Cloud GPU
Jika Anda perlu menjalankan server vLLM sendiri dan membandingkan checkpoint terkuantisasi, pilih kapasitas GPU berdasarkan kebutuhan memori dan konkurensi yang terukur. Flatkey menyediakan opsi penyewaan GPU NVIDIA melalui Cloud GPU Compute. Konfirmasikan SKU yang tersedia, wilayah penerapan, kapasitas, harga, dan ketentuan layanan sebelum berkomitmen. Pengujian kuantisasi vLLM sebaiknya dilakukan pada konfigurasi yang benar-benar ingin Anda sewa. Jika Anda memerlukan API model terkelola alih-alih mengoperasikan vLLM, evaluasi rute API dan direktori model Flatkey secara terpisah; itu adalah model operasi yang berbeda.
Untuk keputusan penerapan terkait, lihat panduan penerapan vLLM, panduan inferensi multi-GPU vLLM, dan perbandingan vLLM versus Ollama kami.
FAQ
Apakah kuantisasi vLLM selalu membuat inferensi lebih cepat?
Tidak. Kuantisasi dapat mengurangi memori bobot, tetapi latensi dan throughput bergantung pada checkpoint, kernel, GPU, panjang urutan, dan beban permintaan. Lakukan benchmark beban kerja nyata terhadap baseline.
Dapatkah saya menggunakan AWQ pada A100 atau H100?
Matriks kompatibilitas vLLM saat ini mencantumkan dukungan AWQ untuk Ampere dan Hopper, yang mencakup A100 dan H100. Periksa checkpoint yang tepat, versi vLLM saat ini, dan arsitektur model sebelum penerapan.
Apakah FP8 didukung pada setiap GPU NVIDIA?
Tidak. Dukungan bervariasi menurut implementasi dan arsitektur kuantisasi. Matriks saat ini membedakan metode seperti llm-compressor FP8 dan Marlin; verifikasi baris yang tepat untuk perangkat keras Anda.
Haruskah saya melakukan kuantisasi sebelum atau setelah memilih GPU?
Tentukan ukuran beban kerja dan target kualitas terlebih dahulu, lalu uji checkpoint kandidat pada GPU yang kompatibel. Pilihan format dan perangkat keras harus dievaluasi bersama-sama.
