Membedah KV Cache Compression: Cara Mengurangi Latensi Model Reasoning Tanpa Mengorbankan Akurasi Konteks

Ada paradoks yang menggelitik di balik model reasoning mutakhir. Kita mengagumi bagaimana model-model ini mampu memecahkan kalkulus rumit, menulis kode multi-berkas, atau merumuskan strategi bisnis yang presisi melalui rantai penalaran (Chain-of-Thought) ribuan token. Namun, saat sistem tersebut dijalankan di level produksi, para engineer di balik layar justru menghadapi mimpi buruk komputasi: server yang kehabisan memori VRAM secara mendadak, latensi antar-token yang merangkak lambat, dan tagihan komputasi awan yang melesat tanpa kendali.

Akar masalahnya bukan terletak pada keterbatasan daya hitung matriks (FLOPs). Perangkat keras akselerator modern seperti NVIDIA H100 atau B200 memiliki tenaga pemrosesan tensor yang luar biasa masif.

Hambatan terbesarnya adalah memori: Key-Value (KV) Cache.

Ketika sebuah model reasoning menghasilkan ribuan "token pikiran" sebelum mengeluarkan jawaban akhir, ia harus menyimpan representasi matematis dari setiap token yang pernah diproses ke dalam VRAM. Semakin panjang konteks dan rantai logikanya, semakin rakus ia menelan bandwidth memori.

Di sinilah kompresi KV Cache berubah dari sekadar eksperimen riset akademis menjadi infrastruktur krusial bagi siapa saja yang ingin menyajikan AI berdaya nalar tinggi secara ekonomis dan instan.

Anatomi Masalah: Mengapa Memori Cepat Amblas?

Untuk memahami mengapa inference model bahasa besar (LLM) begitu tercekik oleh memori, kita perlu menengok fase dekoding autoregresif.

Setiap kali model memprediksi satu token berikutnya, ia memerlukan matriks Attention terhadap seluruh token terdahulu. Menghitung ulang vektor Key dan Value dari awal untuk setiap token baru adalah pemborosan daya komputasi yang fatal ($O(N^2)$). Oleh karena itu, kita menyimpannya di VRAM—inilah yang kita sebut KV Cache.

Masalahnya, ukuran KV Cache bertumbuh secara linear terhadap panjang konteks dan ukuran batch. Mari kita bedah rumusnya:

$$\text{Ukuran KV Cache} = 2 \times n_{\text{layers}} \times n_{\text{kv\_heads}} \times d_{\text{head}} \times \text{panjang\_konteks} \times \text{byte\_per\_elemen} \times \text{batch\_size}$$

Mari kita hitung secara riil pada model kelas 70B (misalnya arsitektur LLaMA-3-70B dengan Grouped-Query Attention):
Jumlah layer ($n_{\text{layers}}$): 80
Jumlah KV heads ($n_{\text{kv\_heads}}$): 8
Dimensi head ($d_{\text{head}}$): 128
Presisi data: FP16 (2 byte per elemen)

Untuk satu token tunggal, kebutuhan memorinya adalah:
$$2 \times 80 \times 8 \times 128 \times 2 = 327.680 \text{ byte} \approx 320 \text{ KB per token}$$

Jika seorang pengguna mengirimkan dokumen 32.000 token dan model melakukan penalaran (thinking phase) sepanjang 8.000 token (total 40.000 token), maka satu request tersebut mengonsumsi:
$$40.000 \times 320 \text{ KB} \approx 12,8 \text{ GB VRAM}$$

Hanya untuk satu sesi inference! Jika ada 8 concurrent users, Anda membutuhkan lebih dari 100 GB VRAM hanya untuk menampung KV Cache, belum termasuk bobot model itu sendiri (~140 GB).

+-----------------------------------------------------------------------+
|                             VRAM GPU(80 GB)                          |
+-----------------------------------------------------------------------+
|  Model Weights(FP16 / INT8)   |   KV Cache(Panjang Konteks)  | Bebas|
|  [===========================] |  [==========================] | [   ]|
+-----------------------------------------------------------------------+
                                                |
                                    Membengkak seiring CoT(Chain-of-Thought) panjang

Pada model reasoning, dekoding bersifat memory-bandwidth bound. GPU menghabiskan 80% waktunya hanya untuk memindahkan data KV Cache dari High Bandwidth Memory (HBM) ke SRAM lokal di dalam chip, alih-alih melakukan kalkulasi matematika aktif. Latensi antar-token (Inter-Token Latency atau ITL) pun melonjak tajam.

Menjinakkan Fragmentasi: Revolusi PagedAttention

Langkah revolusioner pertama untuk mengatasi inefisiensi ini datang dari konsep klasik ilmu komputer: sistem memori virtual pada sistem operasi.

Secara tradisional, sistem alokasi memori LLM mengalokasikan ruang VRAM untuk KV Cache secara berurutan (contiguous memory). Jika kita mengantisipasi konteks hingga 32k token, sistem akan memesan blok memori 32k sejak awal.

Dampaknya adalah fragmentasi parah:

1. Internal Fragmentation: Memori dipesan untuk 32k token, tetapi request selesai di 4k token. Sisa memori terbuang sia-sia dan tidak bisa dipakai request lain.


2. External Fragmentation: Alokator memori gagal menemukan blok kontigu yang cukup besar meskipun total ruang kosong masih memadai.

Alokasi Tradisional(Kontigu):
[ Token 1-1000 ][      Slot Kosong Terkunci(Terbuang)      ]

PagedAttention(Non-kontigu / Blok Virtual):
Page Table: [Page 0 -> VRAM Block 88] [Page 1 -> VRAM Block 12] [Page 2 -> VRAM Block 405]
VRAM: [Block 12][Block 88][Data Lain][Block 405] (Fleksibel, Nyaris 0% Terbuang)

PagedAttention (arsitektur yang dipelopori vLLM) memecah KV cache menjadi blok-blok kecil berukuran tetap (misalnya 16 atau 32 token). Blok-blok ini tidak perlu berada di alamat fisik yang bersebelahan. Sebuah Page Table mencatat pemetaan dari posisi logis token ke alamat fisik blok di VRAM.

Hasilnya? Pemborosan memori akibat fragmentasi terpangkas dari kisaran 60-80% menjadi mendekati 0%. Ini melipatgandakan throughput sistem tanpa menyentuh bobot model sama sekali. Namun, PagedAttention hanyalah solusi manajemen tata letak; ia tidak mengurangi ukuran absolut data yang harus dibaca oleh GPU pada setiap langkah dekoding.

Untuk model reasoning ekstrem, kita butuh intervensi yang lebih radikal: kompresi dan pemangkasan.

Dynamic Context Pruning: Memilih Apa yang Layak Diingat

Apakah otak manusia mengingat setiap kata sambung dari artikel yang dibaca sepuluh menit lalu? Tentu tidak. Kita menyimpan konsep kunci, struktur argumen, dan kesimpulan sementara.

Mekanisme self-attention pada Transformer memperlihatkan perilaku serupa. Penelitian seperti StreamingLLM, H2O (Heavy Hitter Oracle), dan SnapKV membuktikan bahwa distribusi bobot attention sangat timpang (sparse). Sebagian besar token memiliki bobot perhatian mendekati nol, sementara sebagian kecil lainnya mendominasi aliran informasi.

Token dalam KV Cache umumnya terbagi menjadi tiga kategori:

1. Attention Sinks: Token-token paling awal (seperti <s>, <|im_start|>, atau beberapa kata pertama prompt). Tanpa token awal ini, model mengalami keruntuhan representasi karena aktivasi softmax membutuhkan saluran pembuangan (sink).
2. Heavy Hitters ($H_2$): Token bermuatan semantik tinggi (nama entitas, angka krusial, premis logika utama) yang terus-menerus dirujuk oleh token-token baru.
3. Local/Recent Window: Puluhan hingga ratusan token terakhir yang penting untuk menjaga kelancaran sintaksis lokal.

Skema Dynamic Token Eviction:
[Sink Tokens(1-4)] ... [Pruned/Dibuang] ... [Heavy Hitters(Top-K)] ... [Recent Window(Local)]
  Tetap Disimpan        Beban VRAM Turun         Relevan Logika              Sintaksis Halus

Jebakan Pruning pada Model Reasoning

Menerapkan dynamic context pruning pada model percakapan umum relatif mudah. Namun, pada model reasoning (seperti DeepSeek-R1 atau seri OpenAI o-series), pemangkasan sembarangan bisa berakibat fatal.

Jika sebuah token yang dipangkas memuat langkah pembuktian parsial dalam rantai matematika, model akan mengalami hallucination cascade—kesalahan kecil di tengah derivasi yang merusak kesimpulan akhir.

Oleh sebab itu, pendekatan mutakhir menggunakan Observation Window & Cumulative Attention Pooling. Alih-alih memangkas token berdasarkan satu langkah attention saja, sistem memonitor akumulasi bobot perhatian selama $W$ langkah. Hanya token yang secara konsisten diabaikan di seluruh attention heads yang akan dievakuasi (evicted) dari VRAM.

Alternatif Arsitektur: Multi-Head Latent Attention (MLA)

Selain manipulasi pada tingkat runtime, lompatan besar juga terjadi pada tingkat arsitektur model dasar. Inovasi paling mencolok saat ini adalah Multi-Head Latent Attention (MLA) yang dipopulerkan oleh DeepSeek.

Pada Multi-Head Attention (MHA) konvensional atau Grouped-Query Attention (GQA), kita menyimpan vektor Key dan Value secara langsung. Pada MLA, vektor Key dan Value diproyeksikan ke dalam ruang laten (low-rank latent space) yang jauh lebih ramping sebelum disimpan ke dalam KV Cache.

MHA Tradisional:
Hidden State(h) ---> [ W_k -> Key Cache ] & [ W_v -> Value Cache ] (Besar)

Multi-Head Latent Attention(MLA):
Hidden State(h) ---> [ Down-Projection -> Latent Vector(c_KV) ] (Kecil di VRAM)
                                  | (Saat Komputasi Dekoding)
                                  v
                      [ Up-Projection Matrix -> Key & Value Aktif di SRAM ]

Dengan mengompresi KV Cache ke dimensi laten terpadu, MLA mampu memangkas kebutuhan memori KV hingga lebih dari 80-90% dibandingkan MHA standar, tanpa kehilangan kapasitas representasi multi-head yang kaya. Saat dipadukan dengan kuantisasi FP8, konsumsi VRAM menyusut drastis ke level yang memungkinkan model 671B MoE dijalankan pada kluster komputasi yang jauh lebih ringkas.

Komparasi Strategi Reduksi KV Cache

Setiap pendekatan menawarkan titik kompromi yang berbeda antara efisiensi memori, latensi, dan integritas penalaran model. Berikut adalah perbandingan komprehensifnya:

Implementasi Praktis: Mengonfigurasi Dynamic Caching & FP8 KV

Mari kita bedah bagaimana prinsip ini diterapkan secara praktis pada tumpukan teknologi modern. Kode di bawah mengilustrasikan simulasi alur kerja Dynamic KV Pruning menggunakan PyTorch kustom sederhana untuk memfilter KV cache tensor berdasarkan ambang batas bobot perhatian (attention weights):

import torch
import torch.nn as nn
import torch.nn.functional as F
from typing import Tuple

class DynamicKVCacheManager:
    def __init__(
        self, 
        sink_size: int = 4, 
        recent_window_size: int = 256, 
        max_retained_tokens: int = 2048
    ):
        self.sink_size = sink_size
        self.recent_window_size = recent_window_size
        self.max_retained_tokens = max_retained_tokens

    @torch.no_grad()
    def prune_kv_cache(
        self, 
        key_cache: torch.Tensor, 
        value_cache: torch.Tensor, 
        attention_scores: torch.Tensor
    ) -> Tuple[torch.Tensor, torch.Tensor]:
        """
        key_cache: [batch_size, num_heads, seq_len, head_dim]
        value_cache: [batch_size, num_heads, seq_len, head_dim]
        attention_scores: [batch_size, num_heads, query_len, seq_len]
        """
        batch_size, num_heads, seq_len, head_dim = key_cache.shape
        
        # Jika panjang konteks masih di bawah batas retensi, tidak perlu pemangkasan
        if seq_len <= self.max_retained_tokens:
            return key_cache, value_cache

        # 1. Lindungi Attention Sinks (awal sequence)
        sink_indices = torch.arange(0, self.sink_size, device=key_cache.device)

        # 2. Lindungi Local Recent Window (akhir sequence)
        recent_indices = torch.arange(seq_len - self.recent_window_size, seq_len, device=key_cache.device)

        # 3. Hitung signifikansi zona tengah (token historis)
        middle_start = self.sink_size
        middle_end = seq_len - self.recent_window_size
        
        # Agregasi skor atensi dari seluruh head dan posisi query terakhir
        # Mean across query_len and num_heads -> [batch_size, seq_len]
        mean_attn = attention_scores.mean(dim=(1, 2))
        middle_scores = mean_attn[:, middle_start:middle_end]

        # Tentukan kuota yang tersisa untuk Heavy Hitters
        h2_budget = self.max_retained_tokens - self.sink_size - self.recent_window_size
        
        # Ambil indeks token paling krusial di zona tengah
        _, topk_middle_indices = torch.topk(middle_scores, k=h2_budget, dim=-1)
        topk_middle_indices = topk_middle_indices + middle_start

        # Gabungkan seluruh indeks yang dipertahankan
        combined_indices, _ = torch.sort(
            torch.cat([
                sink_indices.expand(batch_size, -1),
                topk_middle_indices,
                recent_indices.expand(batch_size, -1)
            ], dim=-1), 
            dim=-1
        )

        # 4. Rekonstruksi KV Cache yang terpangkas
        # Expand index untuk gathering tensor 4D
        gather_indices = combined_indices.unsqueeze(1).unsqueeze(-1).expand(-1, num_heads, -1, head_dim)
        
        pruned_keys = torch.gather(key_cache, dim=2, index=gather_indices)
        pruned_values = torch.gather(value_cache, dim=2, index=gather_indices)

        return pruned_keys, pruned_values

# Contoh simulasi penghematan
if __name__ == "__main__":
    device = "cuda" if torch.cuda.is_available() else "cpu"
    manager = DynamicKVCacheManager(sink_size=4, recent_window_size=128, max_retained_tokens=512)
    
    # Simulasi 1 request dengan context length 2048 token
    B, H, S, D = 1, 32, 2048, 128
    dummy_keys = torch.randn(B, H, S, D, device=device)
    dummy_values = torch.randn(B, H, S, D, device=device)
    dummy_attn = torch.rand(B, H, 1, S, device=device) # Atensi dari token terakhir

    compressed_k, compressed_v = manager.prune_kv_cache(dummy_keys, dummy_values, dummy_attn)
    
    original_mem = (dummy_keys.numel() + dummy_values.numel()) * 2 / (1024**2) # FP16 MB
    compressed_mem = (compressed_k.numel() + compressed_v.numel()) * 2 / (1024**2)
    
    print(f"Alokasi Memori Awal: {original_mem:.2f} MB")
    print(f"Alokasi Memori Pasca-Pruning: {compressed_mem:.2f} MB")
    print(f"Penghematan: {((1 - compressed_mem/original_mem) * 100):.1f}%")

Pada skala produksi menggunakan serving engine performa tinggi seperti vLLM, Anda tidak perlu menulis kernel gather manual. Anda cukup menyalakan fitur kuantisasi KV Cache native langsung melalui argumen CLI:

# Menjalankan inference engine dengan FP8 KV Cache dan PagedAttention teroptimasi
vllm serve deepseek-ai/DeepSeek-R1-Distill-Llama-70B \
    --kv-cache-dtype fp8 \
    --gpu-memory-utilization 0.95 \
    --max-model-len 32768 \
    --enable-chunked-prefill \
    --tensor-parallel-size 4

Flag --kv-cache-dtype fp8 memotong separuh penggunaan memori per token secara instan, memungkinkan batch size dua kali lebih besar pada kluster hardware yang sama tanpa degradasi logika bernalar yang terukur.

Strategi Produksi & Integrasi Ekosistem API Gateway

Mengelola runtime inferensi berkonteks panjang secara mandiri—mulai dari konfigurasi fragmentasi memori, penyesuaian kuantisasi KV, hingga strategi orkestrasi kluster multi-GPU—membutuhkan investasi rekayasa perangkat lunak yang intensif.

Bagi banyak tim pengembang dan kreator produk digital, fokus utama semestinya berada pada rancang bangun agen, penyempurnaan instruksi logika (prompting workflows), serta penyusunan logika bisnis. Menghabiskan energi hanya untuk men-debug CUDA Out-Of-Memory (OOM) akibat ledakan KV Cache pada skenario multi-turn reasoning adalah distraksi yang mahal.

+-------------------------------------------------------------------------------+
|                       Aplikasi Klien / Agen AI Anda                           |
+-------------------------------------------------------------------------------+
                                      |
                               (OpenAI-Compatible REST API)
                                      v
+-------------------------------------------------------------------------------+
|                         AiStudio.id API Gateway                               |
|  - Intelligent Prompt Caching Layer                                           |
|  - Low-Latency Token Routing & Dynamic Fallbacks                              |
|  - Auto-Optimized KV Precision & Context Management                           |
+-------------------------------------------------------------------------------+
                                      |
         +----------------------------+----------------------------+
         |                                                         |
         v                                                         v
[ Kluster Model Reasoning ]                               [ Kluster Fast LLM ]
 (DeepSeek-R1 / Reasoning Models)                          (DeepSeek-V3 / Flash Engines)
 (VRAM Terkompresi & Terkelola)                            (Inferensi Berkecepatan Tinggi)

Inilah tempat di mana solusi agregasi dan orkestrasi seperti AiStudio.id API Gateway memberikan nilai strategis. Alih-alih dipusingkan oleh alokasi VRAM fisik dan paging policies pada instans GPU sewaan:

1. Prompt Caching Otomatis di Level Gateway: AiStudio.id mengabstraksi mekanisme prefix caching, sehingga segmen prompt dasar (system prompts, dokumen referensi tebal) tidak diproses ulang dari nol pada setiap giliran percakapan.
2. Optimal Cost-to-Performance Routing: Mengarahkan fase perencanaan (reasoning phase) ke model-model nalar tinggi dengan infrastruktur backend teroptimasi (PagedAttention + MLA), lalu mengalihkan eksekusi tugas ringan ke model berlatensi ultra-rendah.
3. Format API Terpadu: Pengembang dapat beralih dari model penalaran proprietary ke model open-weights terdistilasi tanpa mengubah satu baris pun logika client code yang sudah ada.

Dengan menaruh beban optimalisasi memori dan penataan rute komputasi pada gateway yang tangguh, tim Anda mempertahankan kecepatan iterasi produk sembari menyajikan latensi inferensi yang responsif kepada pengguna akhir.

Langkah Praktis Menerapkan KV Optimization

Bagi tim teknis yang sedang membangun aplikasi dengan ketergantungan konteks panjang, berikut panduan langkah demi langkah yang dapat dieksekusi:

[Evaluasi Profil Beban] 
        │
        ▼
[Aktivasi PagedAttention & Chunked Prefill]
        │
        ▼
[Transisi ke FP8 KV Cache]
        │
        ▼
[Uji Regresi Akurasi Reasoning]
        │
        ▼
[Implementasikan Prefix Caching via API Gateway]

Langkah 1: Profiling Kebutuhan Token Reasoning

Langkah 2: Standarisasi ke Engine PagedAttention

Langkah 3: Terapkan Kuantisasi FP8 KV sebagai Standar Default

Langkah 4: Validasi Regresi Logika Sebelum Pruning

Langkah 5: Manfaatkan Gateway untuk Menghilangkan Beban Redundansi

Seni Mengingat Hal yang Tepat

Kecerdasan bukanlah kemampuan untuk mengingat jutaan detail secara kaku tanpa henti. Kecerdasan sejati terletak pada efisiensi abstraksi: kemampuan untuk menyaring kebisingan data, mempertahankan esensi logika, dan membuang hal-hal yang tidak relevan dengan pemecahan masalah.

Kompresi KV Cache bukan sekadar trik optimasi perangkat lunak untuk menghemat anggaran server. Ini adalah langkah konseptual mendasar dalam evolusi komputasi kognitif. Dengan membebaskan model bahasa dari beban memori yang tidak produktif, kita membuka jalan bagi sistem AI yang mampu bernalar lebih panjang, lebih cepat, dan beroperasi pada efisiensi yang masuk akal bagi industri.

Catatan Penulis

> Sandra menulis seputar rekayasa prompt, efisiensi arsitektur AI, dan produk digital di AiStudio.id.