Deployment vLLM untuk Produksi: Membangun Arsitektur Serving Inference Throughput Tinggi

Diperbarui 11 Desember 2025

Update Desember 2025: Stripe mencapai pengurangan biaya inference 73% melalui migrasi vLLM (50 juta panggilan API harian pada 1/3 armada GPU). PagedAttention menghilangkan 60-80% pemborosan memori dari fragmentasi KV cache. vLLM menghasilkan throughput 2-24x vs serving konvensional. Mendukung produksi di Meta, Mistral AI, Cohere, IBM. API yang kompatibel dengan OpenAI menyederhanakan adopsi.

Tim platform ML Stripe menyaksikan biaya inference mereka turun 73% setelah bermigrasi dari Hugging Face Transformers ke vLLM, memproses 50 juta panggilan API harian yang sama pada sepertiga armada GPU.¹ Rahasia di balik efisiensi vLLM terletak pada PagedAttention, algoritma yang memperlakukan memori GPU seperti virtual memory dalam sistem operasi, menghilangkan fragmentasi yang membuang 60-80% memori dalam sistem inference tradisional.² Organisasi yang menjalankan workload LLM produksi menemukan bahwa vLLM menghasilkan peningkatan throughput 2-24x dibandingkan framework serving konvensional, mentransformasi ekonomi deployment large language model dalam skala besar.³

Landscape serving inference terfragmentasi menjadi puluhan opsi: TensorRT-LLM menjanjikan optimasi NVIDIA maksimum, Hugging Face TGI menawarkan integrasi yang familiar, dan Ollama menyederhanakan deployment lokal. Namun vLLM telah muncul sebagai pilihan dominan untuk workload produksi, mendukung inference di Meta, Mistral AI, Cohere, dan IBM.⁴ Kombinasi framework dari PagedAttention, continuous batching, dan API yang kompatibel dengan OpenAI menciptakan pengalaman deployment yang menyeimbangkan performa mentah dengan kesederhanaan operasional. Memahami arsitektur vLLM dan pola deployment memisahkan organisasi yang mencapai inference cost-effective dari mereka yang tenggelam dalam tagihan GPU.

PagedAttention mentransformasi manajemen memori

Inference LLM tradisional mengalokasikan blok memori yang bersebelahan untuk key-value (KV) cache setiap sequence, mereservasi ruang untuk panjang sequence maksimum yang mungkin terlepas dari penggunaan aktual. Sistem yang dikonfigurasi untuk 4.096 token mengalokasikan memori penuh tersebut bahkan untuk respons 100 token, membuang 97% kapasitas yang direservasi. Kalikan dengan ratusan request bersamaan dan memori GPU terisi dengan reservasi kosong sementara sequence aktual mengantri menunggu resource.

PagedAttention membayangkan kembali arsitektur ini dengan membagi memori GPU menjadi halaman berukuran tetap, biasanya 16 token setiap halaman.⁵ Setiap sequence mempertahankan daftar referensi halaman daripada alokasi yang bersebelahan, memungkinkan beberapa kemampuan terobosan:

Penyimpanan non-contiguous memungkinkan blok KV cache tersebar di seluruh memori GPU yang tersedia. Sistem tidak lagi membutuhkan wilayah bersebelahan yang besar, menghilangkan fragmentasi yang mengganggu alokator tradisional. Sequence 2.000 token menyimpan cache-nya di 125 halaman yang didistribusikan di mana pun ruang ada.

Alokasi dinamis menyediakan memori hanya ketika sequence bertumbuh. Token pertama mengalokasikan satu halaman. Token ketujuh belas memicu alokasi halaman kedua. Konsumsi memori melacak penggunaan aktual daripada maksimum teoretis, secara dramatis meningkatkan kapasitas efektif.

Berbagi memori memungkinkan prefix prompt yang identik untuk berbagi halaman KV cache di seluruh request. Sepuluh pengguna yang bertanya variasi prompt sistem yang sama berbagi satu copy cached dari prefix tersebut, mengurangi konsumsi memori sebesar 90% untuk pola umum. Sistem produksi dengan prompt terstandarisasi melihat peningkatan utilization melebihi 400%.⁶

Pemborosan hampir nol menghilangkan fragmentasi internal yang umum dalam alokasi statis. Sistem tradisional membuang rata-rata 4,1 token per sequence dalam blok yang terisi sebagian. Granularitas page-level PagedAttention mengurangi pemborosan menjadi fraksi dari halaman, biasanya di bawah 8 token per sequence terlepas dari panjangnya.

Algoritma mengambil inspirasi langsung dari virtual memory sistem operasi, menerapkan penelitian manajemen memori selama puluhan tahun ke inference GPU. Sama seperti sistem operasi modern memetakan alamat virtual ke halaman memori fisik, PagedAttention memetakan posisi KV cache logis ke blok memori GPU fisik. Overhead translasi menambahkan mikrodetik ke setiap komputasi attention tetapi menghemat gigabyte kapasitas memori.

Continuous batching memaksimalkan utilization GPU

Static batching menunggu jumlah request tetap sebelum memprosesnya bersama-sama, menciptakan spike latensi ketika batch terisi sebagian dan throughput turun ketika request tiba tidak merata. Ukuran batch 32 berarti request ke-31 menunggu satu lagi kedatangan sebelum pemrosesan dimulai, berpotensi menambah detik latensi selama periode lalu lintas rendah.

Continuous batching dalam vLLM menghilangkan batas batch sepenuhnya.⁷ Scheduler beroperasi pada tingkat iterasi daripada tingkat request, membuat keputusan setiap forward pass daripada setiap batch. Ketika sequence menyelesaikan generasi, slot-nya segera menerima request baru tanpa menunggu sequence sibling selesai. GPU memproses pekerjaan apa pun yang ada pada setiap momen, mengisi celah yang ditinggalkan kosong oleh static batching.

Implementasi membutuhkan koordinasi hati-hati antara manajemen memori dan scheduling:

Scheduling tingkat iterasi mengevaluasi antrian request pada setiap langkah decoder. Sequence yang selesai melepaskan slot mereka, request yang menunggu mengklaim kapasitas yang tersedia, dan iterasi berikutnya berlanjut dengan batch yang terisi optimal. Varians latensi antar request diserap daripada diperkuat.

Penanganan preemption mengelola situasi di mana tekanan memori memaksa eviction sequence. Request prioritas lebih rendah melakukan checkpoint pada state KV cache mereka dan menyerahkan memori GPU ke sequence prioritas lebih tinggi. Ketika kapasitas kembali, sequence yang di-preempt melanjutkan dari checkpoint mereka daripada restart dari awal.

Prefix caching mengidentifikasi request yang berbagi prefix umum dan mengarahkannya ke instance yang sudah memegang halaman KV cache yang relevan. Sistem customer support di mana setiap request dimulai dengan konteks 500 token yang sama melayani token berikutnya dari cached state, menghilangkan komputasi prefix yang redundan.

Benchmark mendemonstrasikan dampaknya: vLLM mencapai throughput 793 token per detik dibandingkan 41 token per detik Ollama pada konfigurasi yang setara, dengan latensi P99 80ms versus 673ms.⁸ Arsitektur continuous batching mempertahankan keunggulan ini di seluruh tingkat concurrency dari 1 hingga 256 pengguna simultan.

Arsitektur produksi skalabel di seluruh cluster

Deployment vLLM single-node menangani lalu lintas substansial, tetapi sistem produksi membutuhkan orkestrasi cluster-wide untuk reliabilitas, skala, dan efisiensi. Stack produksi vLLM mentransformasi engine inference menjadi sistem serving yang lengkap dengan empat penambahan kritis.⁹

Request routing mengarahkan query yang masuk ke instance backend yang sesuai berdasarkan routing key, session ID, atau prefix matching. Routing cerdas memaksimalkan penggunaan kembali KV cache dengan mengirim request terkait ke instance yang sudah memegang konteks yang relevan. Percakapan dengan multiple turn secara konsisten route ke backend yang sama, menghindari komputasi prefix yang redundan di seluruh instance.

Berbagi KV cache memperluas efisiensi memori PagedAttention di seluruh multiple instance vLLM melalui proyek LMCache. Backend berbagi blok KV cache yang dihitung melalui interkoneksi kecepatan tinggi, memungkinkan cache hit bahkan ketika request route ke instance yang berbeda. Sistem dengan workload repetitif melihat pengurangan latensi 3-10x dan peningkatan throughput 2-5x dari cache sharing lintas instance.¹⁰

Integrasi observability mengekspos metrik melalui Prometheus dan visualisasi melalui dashboard Grafana. Metrik per-request menangkap time-to-first-token (TTFT), time-between-tokens (TBT), dan latensi end-to-end. Metrik per-instance melacak utilization GPU, tekanan memori, kedalaman antrian, dan tingkat cache hit. Tim operasi mendapatkan visibilitas ke bottleneck performa dan data perencanaan kapasitas.

Horizontal scaling menambah dan menghapus instance vLLM berdasarkan sinyal permintaan. Deployment Kubernetes menggunakan Horizontal Pod