Benchmark vLLM hanya berguna jika menyerupai trafik yang benar-benar akan dikirim oleh aplikasi Anda. Angka token per detik yang menonjol dapat menyembunyikan token pertama yang lambat, antrean yang kelebihan beban, atau distribusi prompt yang tidak pernah muncul di produksi. Panduan ini memberi Anda benchmark penyajian yang dapat diulang: pilih beban kerja, variasikan beban yang ditawarkan, catat distribusi latensi dan throughput secara bersamaan, lalu bandingkan konfigurasi GPU pada target kualitas yang sama.
Jawaban singkat: Gunakan vllm bench serve terhadap versi vLLM dan model yang dipatok pada server GPU khusus. Pertahankan model, presisi, panjang prompt dan output, pengaturan sampling, status cache, dan lokasi klien tetap sama. Jalankan beberapa laju permintaan, rekam TTFT, TPOT, latensi end-to-end, laju permintaan yang berhasil, dan token output per detik, lalu pilih konfigurasi berbiaya paling rendah yang memenuhi sasaran layanan Anda pada beban puncak. Satu kali pengujian throughput maksimum bukanlah rencana kapasitas.
Apa yang harus diukur dalam benchmark vLLM
| Ukuran | Informasi yang diberikan | Kesalahan umum |
|---|---|---|
| Waktu hingga token pertama (TTFT) | Penundaan sebelum output streaming pertama mencapai klien benchmark | Hanya melaporkan latensi rata-rata ketika pengguna p95 atau p99 menunggu dalam antrean |
| Waktu per token output (TPOT) | Waktu decoding per permintaan setelah token pertama, dirata-ratakan di seluruh permintaan | Menganggapnya identik dengan setiap jeda antar-token dalam speculative decoding |
| Latensi end-to-end | Waktu dari pengiriman permintaan hingga output akhir | Membandingkan pengujian dengan panjang output yang berbeda |
| Permintaan berhasil per detik | Pekerjaan yang selesai pada beban yang ditawarkan | Menghitung permintaan yang mengalami timeout atau gagal sebagai kapasitas |
| Token output per detik | Throughput agregat token yang dihasilkan | Membaginya dengan harga GPU tanpa memeriksa target latensi |
| Memori dan utilisasi GPU | Apakah batch, cache KV, dan model yang dipilih muat dengan ruang cadangan | Menyebut utilisasi tinggi sebagai hal baik ketika antrean dan latensi ekor sudah gagal |
Dokumentasi benchmark vLLM mendefinisikan TTFT, latensi antar-token, dan TPOT berdasarkan titik pengukurannya. Gunakan definisi tersebut saat membandingkan alat. Khususnya, TTFT klien mencakup transportasi dan pekerjaan frontend; metrik sisi server opsional dapat memisahkan waktu tunggu scheduler dari eksekusi model, tetapi mengaktifkannya menambah overhead. Pisahkan pengujian diagnostik dari hasil utama.
Patok perbandingan yang adil sebelum menjalankan pengujian
Catat revisi model dan tokenizer, versi vLLM, jenis dan jumlah GPU, ukuran tensor-parallel, flag penyajian, format kuantisasi, panjang konteks, dan lingkungan perangkat lunak. Gunakan prompt dan target output yang sama untuk setiap kandidat. Jika Anda mengubah model, presisi, dan GPU sekaligus, hasilnya tidak dapat memberi tahu perubahan mana yang membantu.
Pilih setidaknya dua beban kerja. Beban kerja sintetis dengan panjang tetap berguna untuk variasi terkontrol; jejak tersanitasi dari panjang permintaan nyata lebih baik untuk keputusan produksi. Pertahankan distribusi prompt panjang, jawaban pendek, dan lonjakan. Untuk produk chat, ukur endpoint chat dengan backend benchmark yang sesuai. Untuk beban kerja completions, gunakan backend completions. Jangan bandingkan angkanya seolah pemformatan permintaannya identik.
Tentukan kriteria kelulusan sebelum pengujian. Misalnya, nyatakan laju permintaan berhasil yang diperlukan serta TTFT p95 dan latensi end-to-end p95 maksimum untuk beban kerja Anda sendiri. Kami tidak menerbitkan ambang batas universal: hal ini bergantung pada pengalaman pengguna dan ukuran output. Tabel penerimaan yang memuat ambang batas, hasil pengukuran, serta alasan lulus/gagal lebih berguna daripada satu skor kinerja.
Jalankan pengujian penyajian yang terkontrol
Panduan CLI vLLM saat ini mencantumkan vllm bench serve untuk pengukuran penyajian online dan merekomendasikan ekstra bench untuk dependensinya. Ringkasan berikut menggunakan contoh completions terdokumentasi dari vLLM. Ganti model dan dataset dengan aset yang memiliki lisensi untuk Anda jalankan dan sesuai dengan perangkat keras Anda. Perintah ini adalah templat yang dapat direproduksi, bukan hasil Flatkey yang terukur.
Di shell kedua, setelah server siap:
vllm bench serve \
--backend vllm \
--model YOUR_MODEL_ID \
--endpoint /v1/completions \
--dataset-name sharegpt \
--dataset-path /path/to/ShareGPT_V3_unfiltered_cleaned_split.json \
--num-prompts 1000 \
--request-rate 1 \
--save-result \
--save-detailedKemudian ulangi dengan serangkaian singkat nilai --request-rate yang lebih tinggi sambil mempertahankan input lainnya tetap sama. Gunakan jumlah prompt yang cukup agar tidak menafsirkan segelintir permintaan sebagai distribusi latensi ekor. Simpan hasil mentah dan perintah yang tepat untuk setiap proses. contoh benchmark online resmi menunjukkan kolom output dan menjelaskan cara --save-result dan --save-detailed menyimpan bukti. Untuk permintaan chat, gunakan backend openai-chat dan endpoint /v1/chat/completions yang terdokumentasi dengan dataset dan model yang mendukung pemformatan chat.
Jangan jalankan benchmark ini terhadap endpoint produksi bersama tanpa rencana lalu lintas. Benchmark ini sengaja menciptakan beban. Gunakan deployment pengujian yang terisolasi atau periode pemeliharaan yang terkendali, dan catat pekerjaan latar belakang apa pun yang dapat memengaruhi hasil.
Lakukan sweep hingga Anda menemukan titik tekuk latensi
Plot laju permintaan yang ditawarkan pada sumbu horizontal. Plot permintaan yang selesai per detik, TTFT p95, latensi end-to-end p95, dan token output per detik sebagai seri terpisah. Pada awalnya, throughput mungkin meningkat kira-kira seiring dengan beban yang ditawarkan. Di luar wilayah berkelanjutan, antrean bertambah, latensi ekor meningkat, dan throughput yang berhasil mungkin mendatar. Titik balik tersebut lebih penting daripada angka terbesar yang tercetak dalam satu proses.
Pisahkan proses pemanasan. vLLM memperingatkan bahwa mengulangi benchmark terhadap server yang sama dapat menggunakan kembali prefix yang di-cache dan meningkatkan throughput secara artifisial. Jika penggunaan ulang cache bukan bagian dari beban kerja produk, variasikan seed atau reset server atau cache sesuai panduan benchmark resmi. Jika penggunaan ulang cache memang realistis, laporkan tingkat cache hit dan sertakan perbandingan cache dingin. Benchmark tanpa kebijakan cache yang dinyatakan sulit direproduksi.
Ketika suatu proses tidak mencapai targetnya, periksa urutannya. Peningkatan TTFT dengan antrean yang bertumbuh dapat mengarah pada saturasi atau kontrol penerimaan. TPOT yang buruk dengan waktu antrean stabil dapat mengarah pada decoding, bandwidth memori, paralelisme, atau pilihan presisi yang tidak efisien. Jika kegagalan meningkat, periksa timeout, OOM, dan log server sebelum menyesuaikan pengaturan model. Mengubah beberapa variabel sekaligus menyembunyikan penyebabnya.
Bandingkan opsi GPU berdasarkan pekerjaan yang diterima, bukan kecepatan mentah
GPU yang lebih besar dapat menghasilkan lebih banyak token output per detik, tetapi biayanya lebih tinggi per permintaan yang diterima. Hitung perkiraan biaya untuk setiap konfigurasi:
Biaya GPU per 1.000 permintaan berhasil = biaya GPU per jam ÷ permintaan berhasil per jam × 1.000
Gunakan penawaran terkini untuk wilayah dan komitmen yang tepat, serta sertakan infrastruktur non-GPU atau kenaikan penagihan minimum jika relevan. Bandingkan hanya proses yang memenuhi target latensi dan error Anda. Konfigurasi yang lebih murah tetapi gagal memenuhi TTFT p95 bukanlah cara yang lebih murah untuk memberikan layanan yang sama.
Untuk perbandingan cloud awal, pertahankan model dan konfigurasi serving tetap sama sambil hanya mengubah jenis GPU. Kemudian uji sejumlah kecil perubahan tuning, seperti pengaturan batch dan memori, satu per satu. Catat utilisasi, ruang kosong VRAM, kedalaman antrean, tingkat keberhasilan permintaan, dan artefak benchmark. Flatkey Compute dapat menjadi salah satu opsi kapasitas untuk dievaluasi; verifikasi GPU yang ditawarkan, wilayah, dan penawaran terkini sebelum menggunakannya dalam perbandingan biaya. Panduan ini tidak mengklaim bahwa GPU tertentu selalu lebih cepat atau lebih murah.
Hasil benchmark vLLM yang dapat Anda serahkan kepada peninjau
Untuk setiap proses, catat: model dan revisi; versi vLLM dan driver; GPU dan topologi; perintah dan checksum dataset; distribusi panjang input/output; lokasi klien; kebijakan cache; laju permintaan; permintaan yang selesai dan gagal; TTFT p50/p95/p99; latensi end-to-end p50/p95/p99; throughput token output; utilisasi GPU dan VRAM; penawaran per jam; biaya per permintaan yang diterima; serta lulus/gagal terhadap target yang telah ditentukan sebelumnya.
Ini juga merupakan titik untuk menjaga keamanan dan kualitas tetap terlihat. Prompt benchmark harus dibersihkan dari data pelanggan, dan kualitas output harus diperiksa saat membandingkan model terkuantisasi atau revisi model yang berbeda. Peningkatan kecepatan yang tampak tetapi mengubah kualitas tugas bukanlah kemenangan yang setara.
Pertanyaan umum
Apakah vllm bench throughput sama dengan vllm bench serve?
Tidak. Yang pertama menargetkan throughput inferensi offline; yang kedua mengirim
permintaan online ke server yang sedang berjalan dan mengukur perilaku
penyajian yang dihadapi klien. Gunakan bench serve untuk perencanaan latensi dan kapasitas
pada deployment API. referensi CLI vLLM mencantumkan
kedua perintah tersebut.
Angka mana yang harus saya optimalkan terlebih dahulu?
Mulailah dengan tujuan layanan: tingkat keberhasilan dan latensi ekor pada lalu lintas puncak yang diharapkan. Kemudian minimalkan biaya di antara konfigurasi yang lolos. Throughput token agregat berguna untuk mendiagnosis kapasitas, tetapi tidak dapat menggantikan target latensi yang dihadapi pengguna.
Dapatkah saya membandingkan angka benchmark yang dipublikasikan dari penyedia berbeda?
Hanya jika model, presisi, beban kerja, panjang output, endpoint, kebijakan cache, rezim laju permintaan, dan definisi pengukuran selaras. Dalam kebanyakan kasus, menjalankan ulang beban kerja yang sama di kedua lingkungan memberikan perbandingan yang lebih dapat dipertanggungjawabkan.
Langkah berikutnya: ambil satu trace yang representatif, tetapkan kriteria kelulusan, jalankan rate sweep singkat pada dua konfigurasi GPU, dan simpan hasil lengkapnya bersama keputusan tersebut. Jika Anda juga mengubah presisi, gunakan panduan kuantisasi vLLM terpisah untuk mengevaluasi memori dan kualitas sebelum mengatribusikan perbedaan kecepatan apa pun pada GPU.
