Deployment Produksi vLLM: 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 dengan 1/3 armada GPU). PagedAttention menghilangkan 60-80% pemborosan memori dari fragmentasi KV cache. vLLM memberikan throughput 2-24x dibanding serving konvensional. Mendukung produksi di Meta, Mistral AI, Cohere, IBM. API kompatibel OpenAI menyederhanakan adopsi.

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

Lanskap inference serving terfragmentasi menjadi puluhan opsi: TensorRT-LLM menjanjikan optimasi NVIDIA maksimal, 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 PagedAttention, continuous batching, dan API kompatibel OpenAI dari framework ini menciptakan pengalaman deployment yang menyeimbangkan performa mentah dengan kesederhanaan operasional. Memahami arsitektur dan pola deployment vLLM membedakan organisasi yang mencapai inference hemat biaya dari mereka yang tenggelam dalam tagihan GPU.

PagedAttention mentransformasi manajemen memori

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

PagedAttention membayangkan ulang arsitektur ini dengan membagi memori GPU menjadi page berukuran tetap, biasanya 16 token per page.⁵ Setiap sequence memelihara daftar referensi page alih-alih alokasi kontinu, memungkinkan beberapa kemampuan terobosan:

Non-contiguous storage memungkinkan blok KV cache tersebar di seluruh memori GPU yang tersedia. Sistem tidak lagi membutuhkan region kontinu yang besar, menghilangkan fragmentasi yang menjangkiti allocator tradisional. Sequence 2.000 token menyimpan cache-nya di 125 page yang didistribusikan di mana pun ruang tersedia.

Dynamic allocation menyediakan memori hanya saat sequence bertumbuh. Token pertama mengalokasikan satu page. Token ketujuh belas memicu alokasi page kedua. Konsumsi memori melacak penggunaan aktual alih-alih maksimum teoretis, meningkatkan kapasitas efektif secara dramatis.

Memory sharing memungkinkan prefix prompt identik untuk berbagi page KV cache antar request. Sepuluh pengguna yang mengajukan variasi system prompt yang sama berbagi satu salinan cached dari prefix tersebut, mengurangi konsumsi memori 90% untuk pola umum. Sistem produksi dengan prompt standar melihat peningkatan utilisasi melebihi 400%.⁶

Near-zero waste menghilangkan fragmentasi internal yang umum pada alokasi statis. Sistem tradisional membuang rata-rata 4,1 token per sequence dalam blok yang terisi sebagian. Granularitas tingkat page PagedAttention mengurangi pemborosan menjadi pecahan page, biasanya di bawah 8 token per sequence terlepas dari panjangnya.

Algoritma ini mengambil inspirasi langsung dari memori virtual sistem operasi, menerapkan riset manajemen memori selama puluhan tahun ke inference GPU. Sama seperti sistem operasi modern memetakan alamat virtual ke page 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 utilisasi GPU

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

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

Implementasi membutuhkan koordinasi cermat antara manajemen memori dan scheduling:

Iteration-level scheduling mengevaluasi antrean request di 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. Varian latensi antar request diserap alih-alih diperkuat.

Preemption handling mengelola situasi di mana tekanan memori memaksa eviction sequence. Request prioritas lebih rendah melakukan checkpoint state KV cache mereka dan menyerahkan memori GPU ke sequence prioritas lebih tinggi. Ketika kapasitas kembali, sequence yang di-preempt melanjutkan dari checkpoint mereka alih-alih memulai dari awal.

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

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

Arsitektur produksi menskalakan lintas cluster

Deployment vLLM single-node menangani traffic substansial, tetapi sistem produksi membutuhkan orkestrasi tingkat cluster untuk reliabilitas, skala, dan efisiensi. vLLM production-stack mentransformasi engine inference menjadi sistem serving lengkap dengan empat tambahan kritis.⁹

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

KV cache sharing memperluas efisiensi memori PagedAttention lintas beberapa instance vLLM melalui proyek LMCache. Backend berbagi blok KV cache yang dikomputasi melalui interconnect berkecepatan tinggi, memungkinkan cache hit bahkan ketika request routing ke instance berbeda. Sistem dengan workload repetitif melihat pengurangan latensi 3-10x dan peningkatan throughput 2-5x dari cross-instance cache sharing.¹⁰

Observability integration 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 utilisasi GPU, tekanan memori, kedalaman antrean, dan cache hit rate. Tim operasi mendapat visibilitas ke bottleneck performa dan data perencanaan kapasitas.

Horizontal scaling menambah dan menghapus instance vLLM berdasarkan sinyal demand. Deployment Kubernetes menggunakan Horizontal Pod Autoscaler dengan metrik kustom yang menargetkan kedalaman antrean atau persentil latensi. Layer router secara otomatis menemukan instance baru dan menyeimbangkan ulang traffic, memungkinkan kapasitas elastis yang melacak demand aktual.

Deployment mengikuti pola Kubernetes standar melalui Helm chart:

# values.yaml untuk vLLM production-stack
replicaCount: 4
model:
  name: "meta-llama/Llama-3.1-70B-Instruct"
  tensorParallelism: 4
resources:
  limits:
    nvidia.com/gpu: 4
router:
  enabled: true
  prefixAwareRouting: true
observability:
  prometheus: true
  grafana: true

Stack yang di-deploy mengekspos API kompatibel OpenAI melalui Kubernetes service, memungkinkan penggantian drop-in untuk aplikasi yang saat ini memanggil endpoint OpenAI atau Azure OpenAI. Codebase yang ada hanya membutuhkan perubahan URL endpoint untuk migrasi dari API cloud ke inference self-hosted.

Kebutuhan infrastruktur membentuk keputusan deployment

Efisiensi memori vLLM memungkinkan model lebih besar pada konfigurasi GPU lebih kecil, tetapi pemilihan hardware tetap menentukan karakteristik performa. Memahami hubungan antara ukuran model, memori GPU, dan throughput menginformasikan keputusan procurement.

GPU memory membatasi ukuran model maksimum dan kapasitas batch bersamaan. Model parameter 70B dalam FP16 membutuhkan 140GB hanya untuk weight, memerlukan tensor parallelism multi-GPU pada hardware apapun saat ini. Model yang sama dalam kuantisasi INT4 muat dalam 35GB, dapat di-deploy pada single A100 80GB atau H100 dengan headroom substansial untuk KV cache. Memory bandwidth sering membatasi throughput lebih dari raw compute, membuat GPU yang dilengkapi HBM3 efektif secara tidak proporsional.

Tensor parallelism membagi layer model lintas beberapa GPU dalam satu node, esensial untuk model yang melebihi memori single-GPU. vLLM mendukung tensor parallel degree yang cocok dengan jumlah GPU, secara otomatis melakukan sharding attention dan feed-forward layer. Node 8-GPU yang menjalankan tensor parallelism 8 melayani model parameter 405B yang sebaliknya akan membutuhkan beberapa node dengan pipeline parallelism yang lebih lambat.

Network fabric menjadi kritis untuk deployment multi-node. Pipeline parallelism lintas node membutuhkan interconnect latensi rendah, bandwidth tinggi antar stage. Jaringan InfiniBand atau RoCE dengan bandwidth 200-400Gbps mendukung serving multi-node yang efisien, sementara Ethernet standar memperkenalkan latensi yang mendegradasi time-to-first-token secara substansial.

Storage throughput berdampak pada performa cold start saat memuat weight model. Model 70B dalam FP16 membutuhkan transfer 140GB dari storage ke memori GPU sebelum melayani request pertama. Storage NVMe yang memberikan 7GB/s memuat model dalam 20 detik; network-attached storage pada 500MB/s memakan waktu 5 menit. Sistem produksi baik mempertahankan instance warm standby atau mengimplementasikan strategi model caching untuk meminimalkan dampak cold start.

Introl membantu organisasi mendesain infrastruktur vLLM di seluruh area cakupan global kami, mencocokkan konfigurasi hardware dengan kebutuhan workload sambil mengoptimalkan efisiensi biaya.¹¹ Engineer kami telah men-deploy infrastruktur inference yang melayani miliaran request bulanan, memahami nuansa yang memisahkan deployment fungsional dari sistem yang sangat teroptimasi.

Membandingkan vLLM dengan alternatif

Ekosistem inference serving menawarkan beberapa framework, masing-masing dengan kekuatan berbeda. Memilih tool yang tepat membutuhkan pencocokan kemampuan framework dengan karakteristik workload.

TensorRT-LLM memberikan performa maksimum pada hardware NVIDIA melalui optimasi kernel agresif dan kompilasi graph. Benchmark menunjukkan TensorRT-LLM mencapai 10.000+ output token per detik pada H100 dengan kuantisasi FP8, dengan time-to-first-token sekitar 100ms.¹² Trade-off-nya: setup kompleks yang membutuhkan konversi checkpoint, building engine, dan konfigurasi ekstensif lintas TensorRT-LLM, tensorrtllm_backend, dan Triton Inference Server. Organisasi dengan tim infrastruktur ML dedicated dan deployment model stabil paling diuntungkan.

**Hugging Fa

[Konten dipotong untuk terjemahan]