Kubernetes Inference Perf: Benchmark Stack Serving, Bukan Sekadar Model

Proyek Inference Perf milik Kubernetes kini memiliki paper perangkat lunak yang telah melalui peer review. Journal of Open Source Software menerbitkannya pada 27 Agustus, sehingga praktisi memiliki deskripsi yang dapat dikutip tentang alat untuk mengirim traffic GenAI yang realistis melalui berbagai model server dan stack serving.

Janji paling bergunanya adalah konsistensi, bukan leaderboard universal. Inference Perf dapat menjaga satu load generator dan kontrak metrik tetap sama ketika tim mengganti model server, akselerator, router, atau kebijakan Kubernetes. Inference Perf tidak dapat membuat dua run sebanding jika prompt, panjang output, pola beban, counter token, window warmup, atau pengaturan servernya berbeda.

Batas ini mengubah “model-server-agnostic” dari kata pemasaran menjadi persyaratan engineering: bekukan workload, catat seluruh stack serving, dan bandingkan hanya dimensi yang memang ingin diubah oleh eksperimen.

Inference Perf mengukur deployment, bukan kecerdasan model

Paper JOSS menjelaskan benchmark modular dengan pembangkitan data, pembangkitan beban, client server, pengumpulan metrik, laporan JSON, dan analisis. Dokumentasi proyek saat ini mencantumkan integrasi terverifikasi untuk vLLM, SGLang, dan Hugging Face TGI, serta dukungan untuk endpoint bergaya OpenAI yang kompatibel. Inference Perf dapat menghasilkan workload constant-rate, Poisson, concurrent, burst, saturation, shared-prefix, multi-turn, dan trace-replay.

Fitur-fitur itu menjawab pertanyaan tentang serving. Fitur tersebut dapat menunjukkan seberapa cepat pengguna melihat token pertama, seberapa stabil token berikutnya tiba, berapa banyak request memenuhi sasaran latensi, di mana sistem mengalami saturasi, dan apakah router atau autoscaler pulih dari perubahan traffic. Fitur itu tidak menunjukkan apakah jawaban model benar, aman, memiliki landasan, atau berguna.

Proposal Kubernetes WG Serving yang asli menjelaskan ruang lingkup ini dengan sangat jelas. Tujuannya adalah alat “benchmark-as-code” yang dapat menguji model server, akselerator, dan orkestrasi tanpa terikat pada satu stack. Merekomendasikan server atau layanan hosted yang menang bukanlah tujuan proyek.

Kelompok kerja itu sendiri sejak saat itu telah menyelesaikan piagamnya. Pembaruan proyek CNCF bulan Februari menyebutkan bahwa pekerjaannya berpindah ke special-interest group Kubernetes dan Inference Perf disponsori oleh SIG Scalability. Softwarenya masih aktif: v0.6.1, yang dirilis pada 23 Juli, adalah versi bertag terbaru, sementara branch utama terus berubah. Karena itu, mem-pin versi merupakan bagian dari hasil, bukan pekerjaan housekeeping.

Pertanyaan serving menentukan metrik yang berguna

Satu angka throughput menyembunyikan beberapa sistem yang berbeda. Benchmark sebaiknya dimulai dari janji kepada pengguna atau operator, lalu memilih metrik yang dapat memfalsifikasinya.

Pertanyaan yang harus dijawab run	Bukti utama	Simpan di samping hasil	Apa yang dapat menipu pembaca
Berapa lama sebelum pengguna melihat progres?	Time to first token (TTFT), terutama p50 dan p95	Distribusi panjang prompt, status cache, concurrency, perlakuan warmup	Mean yang baik dapat menyembunyikan ekor lambat atau penalti cold start
Seberapa mulus respons streaming?	Time per output token (TPOT) dan inter-token latency (ITL)	Panjang output, mode streaming, sumber jumlah token	Output yang lebih pendek atau tokenizer berbeda dapat menciptakan peningkatan semu
Seberapa banyak pekerjaan yang dapat diselesaikan stack?	Request serta token input/output per detik	Offered rate, achieved rate, kegagalan, panjang request	Hanya menghitung keberhasilan dapat menyembunyikan overload dan pekerjaan yang terbuang
Kapasitas apa yang memenuhi tujuan produk?	Request atau token goodput di bawah batasan latensi yang dinyatakan	Ambang service-level yang tepat dan kebijakan error	Throughput mentah dapat naik setelah latensi yang berguna sudah runtuh
Apakah routing atau autoscaling membantu?	Latensi tingkat tahap, throughput, goodput, error, dan telemetry infrastruktur	Jumlah replika, kebijakan routing, peristiwa scaling, kedalaman antrean, metrik GPU dan server	Snapshot steady-state dapat melewatkan transisi yang seharusnya diperbaiki fitur tersebut

Definisi metrik proyek membedakan latensi request end-to-end, TTFT, TPOT, TPOT ternormalisasi, dan ITL, bukan melebur semuanya menjadi “latensi”. Perhitungan goodput hanya menghitung request berhasil yang memenuhi setiap batasan latensi yang dikonfigurasi. Hal ini membuat goodput menjadi ukuran kapasitas yang lebih kuat ketika produk memiliki service-level objective yang nyata.

Bahkan metrik yang benar dapat memiliki denominator yang salah. Inference Perf mencatat penggunaan token yang dilaporkan server dan retokenisasi di sisi klien karena keduanya dapat berbeda akibat overhead chat template, revisi tokenizer, skema tool, atau teks streaming. Laporannya menampilkan jumlah fallback dan ketidakcocokan token. Jika satu run menormalisasi TPOT dengan hitungan klien dan run lain menggunakan hitungan server, perbandingannya sudah mengubah dua hal.

Tiga lapisan memisahkan kecepatan server dari perilaku cluster

Evaluasi serving Kubernetes yang berguna memisahkan perilaku server lokal dari perilaku cluster. Menggabungkan semuanya dalam satu run dapat menghasilkan grafik yang mengesankan tanpa menunjukkan komponen mana yang menyebabkannya.

Baseline terbersih menjaga revisi model, kuantisasi, image server, akselerator, jumlah replika, jalur routing, distribusi prompt, perilaku output, dan offered load tetap sama. Rate sweep kemudian dapat menunjukkan titik ketika latensi atau error membuat throughput tambahan tidak berguna. Pengujian router dan autoscaler menjawab pertanyaan yang berbeda lagi: pengujian ini mengungkap keterlambatan scale-up, pertumbuhan antrean, gangguan cache, kegagalan, dan pemulihan selama transisi, bukan hanya mengukur steady state akhir.

Run berulang dengan urutan bergantian membuat pemisahan itu lebih kredibel. Laporan tahap mentah dan per-request, config.yaml yang dihasilkan, log server dan klien, serta event cluster mengungkap ketidakstabilan yang dapat disembunyikan oleh median atau satu run terbaik.

Inference Perf juga dapat menguji traffic multi-turn dan shared-prefix, tetapi workload tersebut memerlukan kontrol lain: admission cache dan afinitas routing. Request yang jatuh pada prefix cache yang hangat tidak sebanding dengan request yang dirutekan ke replika dingin. Catat token prompt yang cached dan uncached ketika server menyediakannya, lalu perlakukan perubahan routing yang mengubah cache hit sebagai hasil seluruh stack serving, bukan hasil kecepatan server murni.

Tool yang identik tidak menjamin pekerjaan yang identik

Panduan baru tentang komparabilitas lintas tool juga memperingatkan perbandingan yang hanya dibuat dengan Inference Perf. Distribusi input dan output default bukan panjang tetap. Uji rate open-loop dan uji closed-loop dengan concurrency tetap mengukur perilaku yang berbeda. Parameter sampling, perilaku tokenizer, dan pengaturan early-stop mengubah jumlah pekerjaan yang dikirim ke server.

Warmup adalah bagian yang sangat sensitif. Panduan itu menyebut bahwa Inference Perf tidak memiliki fase warmup khusus yang dikecualikan: setiap request yang dikirimnya diukur. Tool yang membuang request warmup mengamati window yang berbeda, terutama ketika kompilasi, cache, atau autoscaling membuat request awal lebih lambat. Tim dapat melakukan warmup server terlebih dahulu atau menggunakan tahap awal yang singkat dan mengecualikannya dari perbandingan, tetapi perlakuan yang dipilih harus dicatat.

Perbandingan lintas tool membutuhkan kehati-hatian lebih besar. Panduan itu mendokumentasikan arti flag dan default yang bergantung pada versi di client benchmark lain, lalu menyarankan untuk memeriksa total token input dan output sebelum membandingkan rate. Rata-rata yang sama tidak cukup jika nilai minimum, maksimum, jarak kedatangan, atau sumber token berbeda.

Harness yang agnostik terhadap server menghapus satu sumber variasi. Harness tersebut tidak menghapus desain eksperimen.

Perbandingan Kubernetes yang disponsori menunjukkan kedua sisi metode ini

Laporan metodologi Principled Technologies bulan Mei memberikan contoh konkret. Penguji menggunakan Inference Perf dengan Llama 3.1 8B Instruct, vLLM 0.11.0, respons streaming, prompt shared-prefix, dan rate sweep Poisson. Mereka menerbitkan manifest cluster, konfigurasi tool, versi software, beberapa tahap beban, dan aturan untuk memilih titik trade-off throughput-latensi.

Detail itu membuat eksperimen dapat diperiksa. Detail itu juga menunjukkan mengapa hasil tidak dapat dipisahkan dari setup-nya: laporan tersebut membandingkan sistem GKE dan EKS yang dikonfigurasi, bukan cloud abstrak, Kubernetes generik, atau setiap workload. Lampiran menyatakan pengujian selesai pada 14 April dan proyek itu ditugaskan oleh Google. Laporan tersebut juga merujuk versi Inference Perf yang lebih lama daripada rilis v0.6.1 saat ini.

Studi ini berguna sebagai catatan pengukuran yang dikerjakan secara konkret, bukan bukti netral bahwa satu platform akan lebih cepat untuk model, wilayah, akselerator, build server, distribusi prompt, atau kebijakan routing lain. Mereproduksi YAML-nya tanpa mereproduksi seluruh lingkungannya akan menciptakan eksperimen baru.

Hasil yang dapat dipertanggungjawabkan adalah klaim yang dibatasi

Sebelum memilih server atau kebijakan cluster, bandingkan delta yang dituju dengan baseline yang tidak berubah. Jika model server berubah, pertahankan model, hardware, aliran request, dan jalur Kubernetes. Jika router berubah, pertahankan image server dan pool replika. Jika akselerator berubah, ungkapkan setiap perubahan software dan topologi terkait yang tidak dapat dibuat konstan.

Lalu nyatakan kesimpulan pada skala yang sama dengan eksperimen: “kebijakan B mempertahankan workload yang dinyatakan pada ambang p95 di cluster ini”, bukan “kebijakan B lebih cepat”. Pasangkan hasil serving dengan evaluasi kualitas terpisah jika perubahan dapat mengubah output, dan hitung biaya berdasarkan penggunaan resource yang diukur, bukan hanya harga daftar akselerator.

Penjelasan evaluasi AI menunjukkan mengapa metrik menjadi bagian dari keputusan produk. Analisis harga Gemini (bahasa Indonesia) menambahkan peringatan yang sama dari arah lain: throughput token bukan hasil bisnis ketika retry dan pekerjaan yang ditolak menghabiskan tagihan.

Peer review membuat Inference Perf lebih mudah dikutip. Alasan yang lebih kuat untuk menggunakannya bersifat praktis: satu harness yang dapat diulang dapat menunjukkan di mana stack serving melengkung di bawah traffic nyata. Angkanya menjadi bukti yang portabel hanya jika workload, counter, window, dan lingkungan ikut berpindah bersamanya.

Sumber

1. JOSS: Inference Perf, a benchmarking tool for GenAI inference
2. Kubernetes SIGs Inference Perf repository and documentation
3. Inference Perf v0.6.1 release
4. Inference Perf metric definitions and token-count provenance
5. Inference Perf goodput documentation
6. Inference Perf cross-tool comparability guide
7. Kubernetes WG Serving Inference Perf proposal
8. CNCF: Kubernetes WG Serving concludes its work
9. Principled Technologies GKE inference study methodology