Cara Benchmark Server LLM: Mengukur Latency, Throughput,
September 6, 2026
- Srengseng Sawah, Jagakarsa Jakarta Selatan
- Sen - Jum: 07:00 -17:00WIB
Cara benchmark server LLM menjadi hal penting ketika perusahaan ingin mengetahui apakah GPU server yang digunakan sudah mampu menjalankan chatbot, AI assistant, atau aplikasi generative AI sesuai kebutuhan. Spesifikasi GPU yang tinggi belum tentu menjamin respons cepat, terutama ketika banyak pengguna mengakses model secara bersamaan. Karena itu, performa server perlu diukur menggunakan metrik yang sesuai, bukan hanya melihat kapasitas VRAM atau jumlah parameter model.
Dalam inference LLM, beberapa metrik yang sering digunakan adalah latency, throughput, dan token per second. Ketiganya mempunyai fungsi berbeda karena kecepatan respons satu pengguna tidak selalu sama dengan kapasitas server melayani banyak permintaan. Server yang mampu menghasilkan banyak token secara agregat, misalnya, belum tentu memberikan pengalaman terbaik jika setiap pengguna harus menunggu terlalu lama.
Benchmark server LLM adalah proses pengujian untuk mengukur kemampuan hardware dan software dalam menjalankan model bahasa pada kondisi tertentu. Pengujian dapat dilakukan untuk mengetahui kecepatan satu request, kapasitas melayani banyak pengguna, penggunaan VRAM, hingga kestabilan server saat menerima beban tinggi. Hasilnya dapat digunakan untuk membandingkan konfigurasi GPU atau menentukan apakah sistem sudah memenuhi target operasional.
Benchmark yang baik harus menggunakan model dan workload yang mendekati kondisi produksi. Model 8B dengan prompt pendek tidak dapat langsung dijadikan acuan untuk model 70B dengan context panjang, meskipun dijalankan pada GPU yang sama. Precision, quantization, inference engine, dan jumlah pengguna juga perlu dicatat agar hasil pengujian dapat dibandingkan secara adil.
Performa LLM tidak cukup dinilai menggunakan satu angka. Perusahaan perlu membedakan waktu tunggu pengguna, kecepatan generasi, dan kapasitas agregat server agar dapat mengetahui bottleneck yang sebenarnya. Metrik berikut dapat digunakan sebagai dasar pengujian inference.
| Metrik | Pengertian | Kegunaan |
|---|---|---|
| TTFT | Waktu sampai token pertama diterima | Mengukur waktu tunggu awal |
| TPOT | Rata-rata waktu menghasilkan token setelah token pertama | Mengukur kecepatan generasi per request |
| ITL | Jeda antara output token yang diterima | Mengamati kelancaran streaming |
| End-to-End Latency | Waktu dari request dikirim hingga respons selesai | Mengukur pengalaman keseluruhan |
| Output Throughput | Total token output yang dihasilkan server per detik | Mengukur kapasitas generasi agregat |
| Request Throughput | Jumlah request selesai per detik | Mengukur kapasitas layanan |
| Goodput | Jumlah pekerjaan yang memenuhi target performa | Mengukur kapasitas yang benar-benar layak digunakan |
Dokumentasi resmi vLLM menjelaskan pengukuran TTFT, TPOT, ITL, throughput, serta berbagai metrik latency pada benchmark serving. Istilah dan titik pengukuran dapat berbeda antartools, sehingga perusahaan perlu memeriksa definisi metrik sebelum membandingkan hasil. Referensi teknisnya tersedia pada dokumentasi Benchmark CLI vLLM.
Latency menunjukkan waktu yang dibutuhkan untuk menyelesaikan proses tertentu. Pada chatbot, end-to-end latency dihitung sejak request dikirim sampai respons selesai diterima, sehingga mencakup waktu tunggu, pemrosesan prompt, dan generasi output. Metrik ini penting untuk mengetahui apakah pengguna memperoleh respons dalam waktu yang sesuai dengan kebutuhan aplikasi.
Time to First Token (TTFT) mengukur waktu sampai token pertama diterima oleh client. Jika TTFT tinggi, pengguna akan merasa chatbot lambat memulai jawaban meskipun token berikutnya dihasilkan dengan cepat. Penyebabnya dapat berasal dari antrean request, proses prefill, atau komponen lain yang berada di jalur permintaan.
Time per Output Token (TPOT) mengukur rata-rata waktu generasi token setelah token pertama. Sebagai contoh ilustratif, TPOT 50 milidetik setara dengan sekitar 20 output token per detik untuk request tersebut. Namun, angka ini tidak sama dengan throughput agregat server yang melayani banyak pengguna.
Token per second sering digunakan untuk menggambarkan kecepatan model menghasilkan respons. Namun, perusahaan perlu memastikan apakah angka tersebut merujuk pada kecepatan satu request atau total token yang dihasilkan seluruh server. Kedua metrik tersebut dapat memberikan gambaran performa yang sangat berbeda.
Sebagai contoh, satu pengguna memperoleh kecepatan 30 token per detik. Ketika server melayani 10 pengguna secara bersamaan, throughput agregat mungkin meningkat karena beberapa request diproses dalam batch. Namun, kecepatan masing-masing pengguna tidak otomatis tetap 30 token per detik karena resource GPU harus dibagi.
Throughput juga dapat dinyatakan sebagai jumlah request yang selesai setiap detik. Metrik ini berguna untuk capacity planning, tetapi perlu dibaca bersama panjang output karena satu request dapat menghasilkan 50 token sementara request lain menghasilkan 1.000 token. Karena itu, perbandingan throughput harus menggunakan karakter workload yang sama.
Concurrency menunjukkan jumlah request yang sedang diproses secara bersamaan. Semakin tinggi concurrency, semakin besar peluang inference engine memanfaatkan batching untuk meningkatkan throughput agregat. Namun, penambahan request juga meningkatkan kebutuhan KV cache dan dapat memperpanjang waktu tunggu ketika kapasitas server mulai mencapai batas.
Sebagai contoh, chatbot mungkin memberikan respons sangat cepat ketika hanya digunakan satu orang. Ketika 20 pengguna mengirim pertanyaan secara bersamaan, throughput agregat dapat meningkat, tetapi TTFT dan latency masing-masing pengguna juga dapat bertambah. Karena itu, benchmark satu pengguna tidak cukup untuk menentukan kapasitas server produksi.
Perusahaan perlu menguji beberapa tingkat concurrency dan membandingkan hasilnya. Tujuannya bukan mencari jumlah request terbanyak yang masih dapat dijalankan, melainkan menemukan kapasitas yang tetap memenuhi target latency dan tingkat keberhasilan layanan. Pendekatan ini membantu menentukan jumlah pengguna aktif yang realistis untuk setiap konfigurasi GPU.
Sebelum memulai pengujian, perusahaan perlu menentukan model, hardware, dan target performa yang akan digunakan. Seluruh konfigurasi sebaiknya dicatat agar hasil benchmark dapat diulang dan dibandingkan. Pengujian juga perlu dilakukan pada lingkungan yang tidak sedang digunakan oleh workload lain yang dapat mengganggu hasil.
Informasi yang perlu disiapkan meliputi:
Setelah konfigurasi ditentukan, lakukan warm-up agar proses awal seperti loading model atau inisialisasi tertentu tidak mencampuri hasil pengujian steady-state. Jalankan benchmark beberapa kali menggunakan workload yang konsisten, kemudian bandingkan hasil rata-rata dan persentil latency. Jika terdapat perbedaan besar antarpengujian, periksa apakah ada proses lain, perubahan cache, atau kondisi sistem yang memengaruhi hasil.
vLLM menyediakan perintah benchmark untuk menguji server inference yang sedang berjalan. Salah satu pendekatan yang dapat digunakan adalah vllm bench serve, yang mengirim request ke endpoint model dan mencatat hasil throughput serta latency. Tool ini dapat digunakan untuk membandingkan beberapa konfigurasi menggunakan model dan dataset yang sama.
Sebagai contoh, setelah model dijalankan melalui vLLM dan endpoint tersedia secara lokal, pengujian dapat dilakukan menggunakan perintah berikut:
vllm bench serve \
--backend openai \
--model Qwen/Qwen2.5-7B-Instruct \
--endpoint /v1/completions \
--base-url http://localhost:8000 \
--dataset-name random \
--random-input-len 512 \
--random-output-len 128 \
--num-prompts 200 \
--request-rate 2 \
--max-concurrency 10 \
--save-result
Contoh tersebut menggunakan dataset sintetis dengan target panjang input dan output tertentu. Parameter --request-rate mengatur laju kedatangan request, sedangkan --max-concurrency membatasi jumlah request outstanding pada sisi benchmark client. Nama model, endpoint, dan parameter perlu disesuaikan dengan versi vLLM serta konfigurasi server yang benar-benar digunakan.
Untuk pengujian produksi, data sintetis sebaiknya dilengkapi dengan sampel prompt yang mendekati penggunaan nyata. Chatbot berbasis RAG, misalnya, dapat mempunyai prompt jauh lebih panjang dibandingkan chatbot FAQ sederhana. Perusahaan juga perlu memperhatikan efek prefix caching karena pengulangan prompt yang sama dapat membuat hasil benchmark terlihat lebih tinggi daripada kondisi penggunaan yang sebenarnya.
Agar hasil pengujian lebih mudah dipahami, perusahaan dapat menyusun laporan yang membandingkan performa pada beberapa tingkat beban. Tabel berikut merupakan contoh ilustratif, bukan hasil pengujian GPU tertentu dan tidak boleh digunakan sebagai jaminan performa hardware. Angkanya hanya menunjukkan bagaimana throughput dan latency dapat berubah ketika concurrency meningkat.
| Concurrency | Output Throughput | TTFT p95 | TPOT Rata-rata | Error |
|---|---|---|---|---|
| 1 | 45 token/s | 0,4 detik | 22 ms | 0% |
| 5 | 180 token/s | 0,8 detik | 28 ms | 0% |
| 10 | 300 token/s | 1,5 detik | 35 ms | 0% |
| 20 | 360 token/s | 4,2 detik | 60 ms | 1% |
Pada contoh tersebut, throughput meningkat ketika concurrency bertambah, tetapi kenaikannya mulai melambat pada beban yang lebih tinggi. Pada saat yang sama, TTFT dan TPOT meningkat sehingga pengalaman pengguna dapat menurun. Jika perusahaan menetapkan target TTFT p95 maksimal dua detik, konfigurasi concurrency 10 mungkin lebih layak daripada concurrency 20 meskipun throughput agregatnya lebih rendah.
Rata-rata latency tidak selalu menggambarkan pengalaman seluruh pengguna. Sebagian besar request mungkin selesai dengan cepat, tetapi sejumlah kecil request dapat mengalami waktu tunggu yang jauh lebih panjang. Karena itu, perusahaan perlu melihat persentil seperti p95 dan p99 untuk memahami performa pada kondisi yang lebih berat.
Sebagai contoh, TTFT p95 sebesar dua detik berarti sekitar 95% request dalam sampel mempunyai TTFT tidak lebih dari dua detik. Namun, lima persen sisanya dapat mengalami waktu tunggu lebih panjang, sehingga tetap perlu diperiksa apabila aplikasi mempunyai kebutuhan respons yang ketat. Metrik persentil sebaiknya dibaca bersama jumlah sampel, tingkat error, dan pola beban agar tidak menghasilkan kesimpulan yang menyesatkan.
Throughput tertinggi belum tentu menjadi kapasitas yang layak digunakan untuk produksi. Perusahaan perlu menentukan Service Level Objective (SLO), misalnya batas TTFT, TPOT, atau end-to-end latency yang masih dapat diterima. Goodput kemudian dapat digunakan untuk mengukur pekerjaan yang berhasil diselesaikan sekaligus memenuhi target tersebut.
Sebagai contoh, sebuah server mampu menyelesaikan 10 request per detik, tetapi hanya tujuh request yang memenuhi batas latency perusahaan. Dalam kondisi tersebut, kapasitas yang relevan untuk perencanaan layanan bukan hanya angka 10 request per detik. Perusahaan perlu mempertimbangkan goodput dan tingkat error agar spesifikasi server tidak ditentukan berdasarkan hasil benchmark maksimum semata.
Jika throughput rendah tetapi GPU utilization juga rendah, perusahaan perlu memeriksa kemungkinan bottleneck pada CPU, data pipeline, aplikasi, atau konfigurasi inference engine. Jika VRAM hampir penuh, optimasi context, quantization, atau pengelolaan KV cache dapat menjadi pertimbangan. Sementara itu, jika GPU sudah bekerja mendekati kapasitas dan latency meningkat ketika concurrency bertambah, penambahan kapasitas compute mungkin mulai diperlukan.
Optimasi seperti continuous batching dapat membantu meningkatkan pemanfaatan GPU pada workload dengan banyak request. Namun, teknik tersebut tidak otomatis menyelesaikan seluruh masalah karena kapasitas VRAM dan kemampuan komputasi tetap mempunyai batas. Perusahaan sebaiknya membandingkan hasil benchmark sebelum dan sesudah optimasi agar manfaatnya dapat diukur secara objektif.
Untuk memahami kebutuhan hardware berdasarkan ukuran model, perusahaan dapat membaca Server untuk Menjalankan LLM Lokal. Artikel tersebut dapat menjadi referensi lanjutan untuk menentukan GPU, RAM, dan storage sebelum melakukan pengadaan server. Sparta Server Indonesia juga menyediakan pilihan GPU Server Indonesia yang dapat disesuaikan dengan kebutuhan inference maupun pengembangan AI perusahaan.
Sparta Server Indonesia menyediakan solusi Server AI Indonesia untuk kebutuhan LLM dan aplikasi AI enterprise. Melalui Jasa Instalasi Server AI, perusahaan dapat berkonsultasi mengenai konfigurasi hardware, persiapan environment, serta pengujian performa sesuai workload yang direncanakan. Pendekatan ini membantu memastikan investasi GPU server didasarkan pada kebutuhan kapasitas dan hasil benchmark yang terukur. WhatsApp kami +62 878‑2224‑1000
Tidak selalu. Model dengan ukuran, arsitektur, tokenizer, dan precision berbeda dapat mempunyai karakter komputasi yang tidak sama. Perbandingan sebaiknya menggunakan workload yang setara serta mempertimbangkan kualitas output agar model yang lebih cepat tidak otomatis dianggap lebih baik untuk seluruh kebutuhan.
Sebaiknya iya, terutama jika perubahan tersebut berpotensi memengaruhi performa atau kompatibilitas model. Update driver, CUDA, framework, maupun inference engine dapat mengubah perilaku komputasi dan penggunaan memory. Pengujian ulang membantu memastikan perubahan tidak menurunkan performa layanan produksi.
Bisa apabila model dan inference engine mendukung penggunaan CPU. Namun, hasilnya tidak dapat langsung digunakan untuk memperkirakan performa GPU karena arsitektur komputasi dan memory yang digunakan berbeda. Benchmark CPU tetap berguna untuk workload yang memang direncanakan berjalan tanpa akselerator.
Perbedaan dapat terjadi karena proses warm-up, inisialisasi kernel, loading model, atau perubahan kondisi cache. Beberapa inference engine juga mempunyai mekanisme caching yang dapat memengaruhi hasil ketika prompt yang sama digunakan berulang. Karena itu, pengujian perlu dilakukan secara konsisten dan kondisi cache harus dicatat.
Ya, terutama ketika perusahaan membandingkan model, precision, atau metode quantization yang berbeda. Konfigurasi yang lebih cepat belum tentu menghasilkan kualitas respons yang sama untuk seluruh tugas. Karena itu, benchmark performa sebaiknya dilengkapi evaluasi kualitas menggunakan pertanyaan dan dataset yang relevan dengan kebutuhan perusahaan.