Optimisasi KV Cache: Efisiensi Memori untuk LLM Produksi

Diperbarui 11 Desember 2025

Pembaruan Desember 2025: Inferensi tradisional memboroskan 60-80% memori KV cache melalui fragmentasi. PagedAttention vLLM mengurangi pemborosan hingga di bawah 4%, memungkinkan peningkatan throughput 2-4x. Model 70B dengan konteks 8K membutuhkan cache ~20GB per permintaan, ~640GB untuk batch 32. KV cache kini sering melebihi bobot model dalam konsumsi memori. Teknik optimisasi memungkinkan konteks lebih panjang dan batch lebih besar pada hardware yang ada.

Sistem inferensi LLM memboroskan 60-80% memori KV cache yang dialokasikan melalui fragmentasi dan alokasi berlebihan.¹ Pemborosan tersebut langsung berdampak pada penurunan throughput, biaya lebih tinggi, dan batasan artifisial pada panjang konteks. PagedAttention, yang diperkenalkan oleh vLLM, memangkas pemborosan KV cache hingga di bawah 4%, memungkinkan peningkatan throughput 2-4x yang mengubah ekonomi inferensi produksi.² Memahami teknik optimisasi KV cache membantu organisasi memaksimalkan utilisasi GPU dan melayani lebih banyak pengguna dari infrastruktur yang ada.

Manajemen KV cache telah menjadi bottleneck kritis untuk deployment LLM produksi. Konsumsi memori tumbuh linear dengan panjang sequence dan ukuran batch, dengan cepat menghabiskan GPU bermemori tinggi seperti H100 dan H200. Menguasai teknik optimisasi cache memungkinkan konteks lebih panjang, batch lebih besar, dan inferensi yang lebih hemat biaya dalam skala besar.

Mengapa KV caching penting

Model Transformer menghitung attention atas semua token sebelumnya saat menghasilkan setiap token baru. Tanpa caching, menghasilkan 1.000 token memerlukan penghitungan ulang attention dari awal 1.000 kali—meningkatkan biaya secara kuadratik seiring panjang sequence.

Solusi KV caching: Simpan tensor key dan value dari token sebelumnya, gunakan kembali untuk perhitungan attention berikutnya. Setiap token baru menghitung attention terhadap nilai yang di-cache daripada menghasilkannya ulang.

Dampak memori: Model 70B parameter yang menghasilkan 8.192 token dengan batch size 32 membutuhkan sekitar 40-50GB memori KV cache saja—sering melebihi bobot model itu sendiri.³

Masalah penskalaan: Memori KV cache tumbuh sebagai:

Memory = batch_size × seq_length × num_layers × 2 × hidden_dim × precision_bytes

Untuk Llama 3.1-70B dengan FP16: - Cache per-token: ~2,5MB - Konteks 8K: ~20GB per permintaan - Batch 32: total KV cache ~640GB

PagedAttention: optimisasi fundamental

PagedAttention vLLM merevolusi manajemen KV cache dengan memperlakukan memori GPU seperti memori virtual sistem operasi:⁴

Cara kerjanya

Alokasi tradisional: Cadangkan blok memori berurutan untuk panjang sequence maksimum yang mungkin. Konteks maksimum 4K mengalokasikan cache senilai 4K bahkan untuk permintaan 100 token, memboroskan 97,5% memori yang dicadangkan.

Alokasi paged: Bagi KV cache menjadi blok (halaman) berukuran tetap. Alokasikan halaman sesuai kebutuhan saat sequence bertambah. Bebaskan halaman saat sequence selesai.

Pemetaan block table: Seperti page table OS, PagedAttention memelihara pemetaan antara posisi sequence logis dan lokasi memori fisik. Sequence melihat memori kontinu sementara penyimpanan fisik tetap tidak berurutan.

Dampak performa

• Pemborosan memori: 60-80% → di bawah 4%
• Throughput: peningkatan 2-4x dibanding alokasi tradisional
• Fragmentasi memori: Praktis tereliminasi⁵

Implementasi di vLLM

from vllm import LLM, SamplingParams

# PagedAttention diaktifkan secara default
llm = LLM(
    model="meta-llama/Llama-3.1-70B-Instruct",
    tensor_parallel_size=4,
    gpu_memory_utilization=0.90,  # Gunakan 90% memori GPU
    max_model_len=32768,
)

vLLM secara otomatis mengelola alokasi halaman, dealokasi, dan berbagi memori tanpa konfigurasi eksplisit.

Prefix caching dan berbagi memori

PagedAttention memungkinkan berbagi memori yang efisien antar permintaan dengan prefix yang sama:

System prompt bersama: Ketika beberapa permintaan menggunakan system prompt identik, halaman fisik yang menyimpan token tersebut dibagikan daripada diduplikasi.

Automatic prefix caching: Automatic Prefix Caching (APC) vLLM mendeteksi prefix umum antar permintaan dan membagikan blok KV cache secara otomatis:

llm = LLM(
    model="meta-llama/Llama-3.1-8B-Instruct",
    enable_prefix_caching=True,
)

Dampak produksi: Aplikasi dengan system prompt konsisten atau konteks berulang (RAG dengan dokumen umum, few-shot examples) melihat penghematan memori dramatis dan pengurangan latensi. Tingkat cache hit 87%+ dapat dicapai dengan prompt yang terstruktur dengan baik.⁶

Kuantisasi KV cache

Mengompresi nilai KV cache mengurangi kebutuhan memori dengan biaya degradasi akurasi minor:

FP8 KV cache

GPU Hopper dan Blackwell mendukung FP8 KV cache native:

# vLLM FP8 KV cache
llm = LLM(
    model="meta-llama/Llama-3.1-70B-Instruct",
    kv_cache_dtype="fp8",
)

FP8 memangkas setengah memori KV cache dibanding FP16 dengan dampak kualitas minimal untuk sebagian besar aplikasi. Optimisasi ini menjadi esensial untuk inferensi konteks panjang di mana cache mendominasi konsumsi memori.

INT4 KV cache

Dukungan eksperimental KV cache 4-bit lebih lanjut mengurangi memori:⁷ - Pengurangan memori: 4x dibanding FP16 - Dampak kualitas: Tergantung tugas, memerlukan evaluasi - Terbaik untuk: Aplikasi konteks panjang dengan keterbatasan memori

Pemilihan kuantisasi

Strategi cache eviction

Ketika tekanan memori melebihi kapasitas yang tersedia, kebijakan eviction cache menentukan token mana yang dibuang:

Sliding window attention

Pertahankan hanya token terbaru dalam cache, buang konteks lama:

# Konseptual sliding window
def sliding_window_cache(kv_cache, window_size):
    if len(kv_cache) > window_size:
        kv_cache = kv_cache[-window_size:]
    return kv_cache

Sederhana tapi efektif untuk aplikasi di mana konteks terbaru paling penting. Sliding window arsitektural (seperti Mistral) mengimplementasikan ini secara native.

Eviction berbasis attention

Hapus token dengan skor attention terendah, pertahankan konteks penting:

PagedEviction (2025): Algoritma eviction block-wise yang disesuaikan untuk PagedAttention yang mengidentifikasi dan menghapus blok dengan kepentingan rendah tanpa memodifikasi kernel CUDA.⁸

Entropy-guided caching: Alokasikan anggaran cache berdasarkan entropi attention layer—layer dengan pola attention lebih luas menerima lebih banyak cache, layer terfokus menerima lebih sedikit.⁹

Streaming LLM

Untuk generasi panjang tak terbatas, Streaming LLM mempertahankan: - Token "attention sink" awal (4-8 token pertama) - Token terbaru dalam sliding window - Membuang konteks tengah

Pendekatan ini memungkinkan generasi tak terbatas secara teoritis dengan memori tetap, meskipun kualitas menurun untuk tugas yang memerlukan dependensi jarak jauh.

KV cache offloading

Ketika memori GPU tidak mencukupi, offload cache ke tier penyimpanan lebih lambat:

CPU offloading

Pindahkan cache sequence tidak aktif ke RAM sistem:

# Integrasi LMCache untuk offloading
from lmcache import LMCacheEngine

cache_engine = LMCacheEngine(
    backend="cpu",
    max_gpu_cache_size="20GB",
    cpu_cache_size="100GB",
)

Dampak latensi: Transfer CPU-GPU menambahkan 10-50ms per pengambilan cache. Cocok untuk beban kerja batch atau ketika batas memori GPU mencegah pelayanan sama sekali.

Performa: LMCache dengan vLLM mencapai pengurangan latensi 3-10x dibanding penghitungan ulang dengan melakukan caching di memori CPU daripada meregenerasi.¹⁰

Disk offloading

Untuk kasus ekstrem, cache ke penyimpanan NVMe: - Latensi: 100-500ms per pengambilan - Kasus penggunaan: Konteks sangat panjang yang sebaliknya tidak mungkin - Tidak cocok untuk aplikasi interaktif

Tiered caching

Sistem produksi sering mengimplementasikan caching multi-tier:

1. GPU HBM: Sequence panas yang aktif menghasilkan
2. CPU RAM: Sequence hangat yang baru aktif
3. NVMe SSD: Sequence dingin untuk potensi penggunaan ulang

Kebijakan promosi dan demosi cerdas memindahkan cache antar tier berdasarkan pola akses.

Routing sadar KV cache

Inferensi terdistribusi mendapat manfaat dari routing permintaan ke pod yang menyimpan cache relevan:

Framework llm-d

Framework native Kubernetes dengan routing sadar KV cache:¹¹

# Konfigurasi routing cache llm-d
routing:
  strategy: kv_cache_aware
  cache_hit_weight: 0.8
  load_balance_weight: 0.2

Hasil performa: - 87% tingkat cache hit dengan beban kerja prefix-heavy - 88% lebih cepat time-to-first-token untuk cache hit hangat - Pengurangan signifikan komputasi redundan di seluruh cluster

Pola implementasi

Sticky sessions: Rutekan permintaan dari percakapan yang sama ke pod yang sama.

Prefix hashing: Hash system prompt untuk menentukan routing pod, memastikan prefix cache hit.

Load-aware routing: Seimbangkan lokalitas cache terhadap utilisasi pod untuk mencegah hotspot.

Panduan sizing produksi

Estimasi memori

Hitung kebutuhan KV cache sebelum deployment:

def estimate_kv_cache_memory(
    num_layers: int,
    hidden_dim: int,
    num_kv_heads: int,
    head_dim: int,
    max_seq_len: int,
    max_batch_size: int,
    precision_bytes: int = 2,  # FP16
) -> float:
    """Estimasi memori KV cache dalam GB"""
    per_token = num_layers * 2 * num_kv_heads * head_dim * precision_bytes
    total = per_token * max_seq_len * max_batch_size
    return total / (1024 ** 3)

# Contoh Llama 3.1-70B
memory_gb = estimate_kv_cache_memory(
    num_layers=80,
    hidden_dim=8192,
    num_kv_heads=8,  # GQA
    head_dim=128,
    max_seq_len=8192,
    max_batch_size=32,
)
print(f"Memori KV cache: {memory_gb:.1f} GB")

Perencanaan kapasitas

Aturan praktis: Cadangkan 40-60% memori GPU untuk KV cache, sisanya untuk bobot model dan aktivasi.

Contoh H100 80GB: - Bobot model (70B FP16): ~140GB → 2x GPU dengan tensor parallelism - Per-GPU tersedia untuk cache: ~30-35GB setelah bobot dan overhead - Sequence konkuren maksimum: Tergantung rata-rata panjang konteks

Prioritas optimisasi

1. Aktifkan PagedAttention: Default di vLLM, keuntungan efisiensi besar
2. Aktifkan prefix caching: Jika beban kerja memiliki prefix umum
3. Implementasikan FP8 KV cache: Saat menggunakan GPU Hopper/Blackwell
4. Tambahkan cache-aware routing: Pada skala cluster dengan inferensi terdistribusi
5. Pertimbangkan offloading: Hanya ketika memori GPU terbukti tidak mencukupi

Monitoring dan observability

Lacak metrik KV cache di produksi:

Metrik utama: - Utilisasi cache: Persentase cache yang dialokasikan yang digunakan - Tingkat cache hit: Efektivitas prefix cache - Tingkat eviction: Frekuensi overflow cache - Fragmentasi memori: Ruang terbuang dalam blok yang dialokasikan

Endpoint metrik vLLM:

# Metrik Prometheus tersedia di /metrics
# kv_cache_usage_percent
# kv_cache_total_blocks
# kv_cache_used_blocks
# prefix_cache_hit_rate

Threshold alerting: - Utilisasi cache > 90%: Skalakan kapasitas atau kurangi ukuran batch - Tingkat hit < 50%: Tinjau konfigurasi prefix caching - Tingkat eviction tinggi: Tingkatkan alokasi memori atau optimalkan prompt

Organisasi yang men-deploy inferensi LLM produksi dapat memanfaatkan keahlian infrastruktur Introl untuk perencanaan kapasitas GPU dan optimisasi di seluruh deployment global.

Imperatif efisiensi memori

Optimisasi KV cache merepresentasikan salah satu peningkatan berdampak tertinggi untuk deployment LLM produksi. PagedAttention saja memberikan peningkatan throughput 2-4x—setara dengan menggandakan atau melipatgandakan investasi GPU tanpa biaya hardware tambahan.

Lanskap optimisasi terus berkembang. FastGen Microsoft mendemonstrasikan pengurangan memori 50% melalui kompresi adaptif. Entropy-guided caching mengalokasikan anggaran secara cerdas di seluruh layer. Cache-aware routing memungkinkan keuntungan efisiensi skala cluster yang sebelumnya tidak mungkin.

Untuk organisasi yang menjalankan inferensi dalam skala besar, optimisasi KV cache harus masuk dalam prioritas optimisasi pertama yang dievaluasi. Teknik-teknik ini membutuhkan mini