AI & Tech

vLLM v0.28.0: Optimasi Kimi-K3, DeepSeek V4, dan Default Baru untuk Inference LLM

vLLM v0.28.0: Optimasi Kimi-K3, DeepSeek V4, dan Default Baru untuk Inference LLM

vLLM, salah satu inference engine paling populer untuk model bahasa besar, merilis v0.28.0 pada akhir Agustus 2026. Rilis ini besar: 584 commit dari 270 kontributor, dengan 76 kontributor baru. Bagi developer yang menjalankan LLM di produksi, rilis ini membawa kombinasi peningkatan performa untuk model-model populer, speculative decoding yang lebih matang, dan beberapa perubahan default yang wajib diketahui karena bisa mengubah perilaku deployment.

Artikel ini merangkum highlight utama vLLM v0.28.0 dalam bahasa yang mudah dicerna developer Indonesia, lengkap dengan implikasi praktis untuk workload inference di produksi.

Optimasi Besar untuk Kimi-K3

Fokus utama rilis ini adalah dorongan performa besar untuk Kimi-K3, model dari Moonshot AI. Tim vLLM melakukan optimasi di hampir semua lapisan stack:

  • Decode Context Parallel (DCP) — dukungan untuk memparalelkan fase decode dengan konteks panjang lintas GPU.
  • Fused kernel FlashKDA — kernel decode dan prefill digabung untuk mengurangi overhead pemanggilan kernel terpisah.
  • SiTU activation untuk MegaMoE — dukungan fungsi aktivasi baru pada arsitektur MoE MegaMoE.
  • GEMM-RS untuk sequence parallelism — pengurangan bottleneck komunikasi saat sequence dibagi lintas GPU.
  • All-gather digabung — menghasilkan speedup 1,5x hingga 3x di level kernel untuk operasi komunikasi kolektif.
  • Adaptive speculative token budget — meningkatkan TTFT DSpark hingga sekitar 60 persen lebih baik.
  • Shared-expert sharding opsional — menghemat sekitar 17 GiB memori per GPU dengan berbagi expert bersama di antara shard.

Kimi-K3 juga kini berjalan di ROCm dengan V2 model runner, kabar baik bagi tim yang memakai GPU AMD untuk inference.

DeepSeek V4: Sparse MLA End-to-End

Untuk pengguna DeepSeek V4, rilis ini menutup beberapa celah besar. Sparse Multi-head Latent Attention (MLA) kini bekerja end-to-end untuk plain decode, MTP, dan DSpark speculative decoding. Artinya, penghematan memori dan komputasi dari arsitektur MLA yang sparse bisa dinikmati tanpa workaround.

Tambahan lain untuk DeepSeek V4 meliputi dukungan AMD Quark NVFP4, reasoning-effort prompts dan mappings, optimasi kernel sparse top-k metadata, region CUDA graph yang lebih sempit untuk eager mode, serta enablement ROCm di gfx11 dan gfx950.

Kombinasi ini penting karena DeepSeek V4 adalah salah satu model yang paling banyak di-self-host untuk aplikasi produksi, dan optimasi di sisi inference engine berdampak langsung ke biaya operasional.

Speculative Decoding yang Lebih Matang

Speculative decoding adalah teknik mempercepat inference dengan membuat draft token yang murah lalu memverifikasi banyak token sekaligus. Di v0.28.0, area ini dapat banyak perhatian:

  • DFlash2 kini mendukung local convolution dan candidate selector.
  • DSpark mendapat confidence-scheduled verification, di mana jadwal verifikasi disesuaikan dengan tingkat keyakinan model.
  • Async scheduling kini otomatis aktif untuk draft model, mengurangi waktu tunggu antara draft dan verifikasi.

Bagi tim yang menjalankan speculative decoding di produksi, perubahan ini berarti latency yang lebih stabil dan utilisasi GPU yang lebih baik, terutama untuk beban kerja dengan banyak request kecil.

Model Runner V2 dan Tiered KV Cache

Model Runner V2 terus dimatangkan. Rilis ini menambahkan disaggregasi E/P/D, weight offloading, dukungan KV cache MTP multi-layer, encoder CUDA graphs, token-wise pooling di decoder, dan dukungan model attention-free serta thinking_token_budget.

Di sisi memori, tiered KV cache kini mendukung disk offloading dan manajer tier sekunder out-of-tree lewat module_path. Ini sangat relevan untuk workload dengan context panjang: KV cache yang tidak muat di VRAM bisa di-offload ke CPU memory atau disk, sehingga konteks besar tetap bisa dilayani meski dengan trade-off latency.

Tiering metrics juga ditambahkan, memberi visibilitas ke seberapa banyak cache yang dipindah antar tier dan berapa lama operasi offload berlangsung.

Rust Frontend dan gRPC

Salah satu arah pengembangan vLLM yang menarik adalah komponen frontend berbasis Rust. Di v0.28.0, rilis ini menghadirkan standalone renderer, inference multimodal via gRPC, explicit data-parallel rank routing, dan kontrol siklus hidup reinforcement learning, dengan skema protobuf yang kini dipublikasikan ke Buf.

Ini menandakan vLLM bergerak menuju arsitektur yang lebih modular, di mana frontend (penerima request) dan engine (pemroses) bisa dipisah dan dikembangkan secara independen.

Perubahan Default yang Wajib Diketahui

Tiga perubahan default di rilis ini bisa mengubah perilaku deployment yang sudah ada:

  • max_num_batched_tokens naik dari 8192 ke 16384. Dengan batching yang lebih besar, throughput meningkat, tapi penggunaan memori per request batch juga bertambah. Pastikan kapasitas VRAM masih aman.
  • Prefix caching aktif secara default untuk model Mamba. Ini mengubah kebiasaan sebelumnya yang harus diaktifkan manual.
  • Blackwell CUDA graph capture default naik ke 1024.

Ada juga breaking changes yang perlu diantisipasi: dukungan bitsandbytes dipindah ke plugin out-of-tree, Transformers di-bump ke 5.15.0, calculate_kv_scales runtime dihapus, dan override_attention_dtype dihilangkan. Tim yang memakai opsi-opsi ini perlu menyesuaikan konfigurasi sebelum upgrade.

Dukungan Model Baru

Rilis ini menambah dukungan untuk sejumlah model baru: Muse Glimmer, Ling 3.0 Flash (dengan varian BF16, MTP, parser, FP8, dan hybrid MXFP4 routed experts), Dots3 NOTE dengan multimodal native, dan Interns2mobius. Untuk keluarga Qwen, ada enablement Qwen3.8 di ROCm dan berbagai perbaikan untuk Qwen3.5. Di sisi LoRA, vision tower LoRA untuk Gemma4 dan beberapa model lain ikut didukung.

Cara Mendapatkan vLLM v0.28.0

Instalasi tergantung platform komputasi:

  • CUDA 13.0: pip install vllm
  • ROCm: pip install vllm --extra-index-url https://wheels.vllm.ai/rocm/0.28.0/rocm722
  • Docker CUDA: docker pull vllm/vllm-openai:v0.28.0 (atau varian -cu129, -ubuntu2404, -cpu, -xpu, -rocm)

Wheel prebuilt tersedia untuk CUDA 12.9 dan 13.0 di x86_64 dan arm64, plus CPU wheel untuk x86_64, arm64, dan macOS.

Panduan Upgrade yang Aman

Kalau sudah memutuskan untuk upgrade ke v0.28.0, ikuti urutan yang mengurangi risiko:

  • Baca release notes lengkap — fokus pada bagian breaking changes dan deprecations. Buat daftar konfigurasi yang dipakai di deployment Anda dan cocokkan dengan daftar perubahan.
  • Cek dependensi — Transformers di-bump ke 5.15.0. Pastikan model yang Anda jalankan kompatibel dengan versi ini, dan audit requirement pins di environment Anda.
  • Uji di staging — deploy v0.28.0 di environment yang meniru produksi, jalankan workload representatif, dan bandingkan throughput serta latency dengan versi sebelumnya.
  • Uji model MoE spesifik — kalau memakai Kimi-K3, DeepSeek V4, atau model MoE lain, beri perhatian ekstra karena banyak optimasi rilis ini menyasar mereka. Uji dengan prompt panjang dan short prompt sekaligus.
  • Pantau pasca-upgrade — setelah masuk produksi, amati error rate, OOM, dan latency p95 selama beberapa hari sebelum menyatakan sukses.

Jangan tergoda mengaktifkan semua fitur baru sekaligus. Aktifkan satu per satu, ukur dampaknya, dan hanya pertahankan yang memberikan nilai nyata untuk workload Anda.

Benchmark: Jangan Percaya, Ukur Sendiri

Release notes penuh dengan klaim speedup dan penghematan memori, tapi angka itu diukur pada hardware dan workload tertentu di lab vLLM. Hasil Anda bisa berbeda. Cara paling jujur mengevaluasi rilis ini adalah benchmark mandiri dengan workload yang mewakili produksi:

  • Ukur throughput (request per detik) pada konfigurasi batching yang sama sebelum dan sesudah upgrade.
  • Ukur TTFT (time to first token) dan inter-token latency untuk skenario interaktif.
  • Ukur penggunaan VRAM, terutama untuk KV cache dengan context panjang, untuk memastikan perubahan default max_num_batched_tokens tidak menyebabkan OOM.
  • Kalau memakai speculative decoding, bandingkan acceptance rate dan speedup nyata di workload Anda, bukan hanya di benchmark standar.

Dengan data benchmark sendiri, keputusan upgrade jadi berbasis bukti, bukan sekadar mengikuti hype rilis.

Catatan untuk Deployment di Indonesia

Bagi tim di Indonesia yang menjalankan LLM self-hosted, ada beberapa pertimbangan lokal yang jarang dibahas di release notes: biaya listrik dan pendinginan GPU, ketersediaan hardware, dan latency ke pengguna. GPU data center tidak murah di Indonesia, dan sewa cloud GPU dari penyedia lokal atau regional sering jadi pilihan pertama sebelum berinvestasi hardware sendiri. Pastikan perhitungan biaya mencakup operasional jangka panjang, bukan hanya harga GPU-nya.

Latency juga penting. Kalau pengguna utama Anda di Indonesia, pilih region cloud yang dekat untuk inference endpoint. Model MoE besar seperti Kimi-K3 atau DeepSeek V4 butuh banyak GPU, dan jarak fisik antara server dan pengguna berpengaruh langsung ke TTFT. Ukur latency dari beberapa titik di Indonesia sebelum menetapkan region.

Terakhir, mulai kecil. Jalankan model yang lebih kecil dulu di satu GPU, pelajari pola traffic, baru scale up. Banyak tim gagal bukan karena modelnya, tapi karena over-provisioning di awal: membeli kapasitas GPU yang tidak terpakai karena trafik belum ada.

Kuncinya adalah pendekatan bertahap dan terukur. Jangan langsung migrasi semua workload sekaligus; pilih satu model, satu skenario penggunaan, lalu ukur dampaknya terhadap biaya, latency, dan kualitas. Dari data itu, keputusan untuk workload berikutnya jadi lebih mudah dan lebih aman.

Sebagai penutup, satu prinsip yang berlaku untuk semua rilis inference engine: angka di release notes adalah titik awal, bukan kesimpulan. Workload Anda berbeda dari workload pengembang vLLM, dan hanya pengukuran pada data Anda sendiri yang bisa memutuskan apakah upgrade layak dilakukan. Jadikan benchmarking rutin sebagai kebiasaan, bukan aktivitas sekali-sekali.

Kesimpulan

vLLM v0.28.0 adalah rilis yang padat: optimasi serius untuk Kimi-K3 dan DeepSeek V4, speculative decoding yang lebih matang, tiered KV cache dengan disk offloading, dan langkah lanjutan menuju frontend Rust modular. Tapi jangan lupa, dengan perubahan default dan breaking changes, proses upgrade bukan sekadar pip install lalu selesai. Baca release notes, audit konfigurasi yang dipakai, dan uji di staging sebelum menyentuh produksi.

Bagi developer yang menjalankan LLM self-hosted di Indonesia, rilis ini layak dijadwalkan untuk evaluasi, terutama kalau workload-nya bergantung pada model MoE besar atau context panjang yang butuh manajemen KV cache efisien.

💬 Komentar (0)

Belum ada komentar. Jadilah yang pertama! 💬

Komentar akan muncul setelah moderasi.