Matematika KV Cache Compression: Cara SLM Memproses 128k Token dengan 4GB VRAM

Ada ironi yang jarang dibicarakan di panggung peluncuran model kecerdasan buatan: kita merayakan model yang mampu membaca 128.000 hingga 1 juta token, tetapi kita menyembunyikan tagihan komputasinya di balik pintu tertutup.

Bagi para insinyur yang bekerja di garis depan—mereka yang mencoba menjalankan model bahasa di laptop tipis, perangkat edge, atau server murah—angka 128k token kerap terasa seperti fatamorgana. Anda mungkin berhasil memampatkan bobot model (weights) 3 miliar parameter (3B) ke dalam format 4-bit sehingga ukurannya hanya menyisakan sekitar 1,8 GB di VRAM. Kartu grafis 4GB kelas konsumen Anda tampak tersenyum lebar.

Namun, begitu Anda menyodorkan dokumen hukum setebal 300 halaman atau repositori kode utuh ke dalamnya, sistem langsung meledak dengan pesan kutukan klasik: CUDA out of memory.

Penyebabnya bukan bobot model, melainkan KV Cache (Key-Value Cache).

KV Cache adalah "buku catatan kerja" yang dipertahankan mekanisme self-attention agar model tidak perlu menghitung ulang representasi seluruh kata lampau setiap kali memprediksi satu token berikutnya. Masalahnya, semakin panjang percakapan, buku catatan ini bertransformasi dari sekadar memo saku menjadi tumpukan ensiklopedia raksasa yang menelan seluruh kapasitas memori grafis.

Bagaimana cara membuat Small Language Model (SLM) seperti Qwen-2.5-3B atau Llama-3.2-3B memproses konteks 128k token secara utuh di atas kartu grafis 4GB VRAM tanpa kehilangan akurasi nalarnya? Jawabannya berada di persimpangan antara matematika attention, manajemen memori sistem operasi klasik, dan algoritma dynamic token eviction.

Anatomi Krisis: Mengapa KV Cache Membengkak Tanpa Ampun?

Untuk memahami mengapa memori grafis Anda menyerah, kita harus membedah matematika dasar di balik alokasi memori transformer.

Dalam arsitektur autoregresif standar, setiap token yang diproses menghasilkan dua vektor utama untuk setiap attention layer: vektor Key ($K$) dan vektor Value ($V$). Keduanya harus disimpan dalam VRAM sepanjang proses inferensi berlangsung.

$$\text{Memori KV Cache (Byte)} = 2 \times L \times H_{KV} \times D \times P \times N$$

Variabel di atas merepresentasikan realitas fisik hardware Anda:
$2$: Mengindikasikan dua matriks ($K$ dan $V$).
$L$: Jumlah layer pada model (transformer layers).
$H_{KV}$: Jumlah kepala attention untuk KV (KV heads). Pada model modern dengan Grouped-Query Attention (GQA), angka ini biasanya lebih kecil dari query heads.
$D$: Dimensi per head (head dimension, umumnya 128).
$P$: Presisi data dalam byte (FP16 = 2 byte, FP8 = 1 byte, INT4 = 0.5 byte).
$N$: Panjang urutan token (sequence length / context window).

Mari kita uji matematika ini pada model modern berukuran kompak: Llama-3.2-3B.
Model ini memiliki konfigurasi $L = 28$, $H_{KV} = 8$, $D = 128$, dengan representasi standar FP16 ($P = 2$ byte).

Untuk satu token saja, memori yang dihabiskan adalah:
$$\text{Memori per Token} = 2 \times 28 \times 8 \times 128 \times 2 = 114.688 \text{ byte} \approx 112 \text{ KB/token}$$

Angka 112 KB terlihat sangat sepele. Namun, mari kalikan dengan target konteks 128k ($131.072$ token):

$$131.072 \times 114.688 \text{ byte} = 15.032.385.536 \text{ byte} \approx 14,0 \text{ GiB}$$

+-------------------------------------------------------------------------+
| TOTAL MEMORY REQUIRED(128k Context @ FP16): ~15.8 GB                   |
+-------------------------------------------------------------------------+
| Model Weights(4-bit INT4) : [== 1.8 GB ==]                             |
| KV Cache(FP16 Raw)        : [================================= 14.0 GB]|
+-------------------------------------------------------------------------+
| Kapasitas Fisik VRAM Edge  : [==== 4.0 GB ====]  <-- CRASH(OOM)        |
+-------------------------------------------------------------------------+

Modelnya hanya berukuran 1,8 GB, tetapi buku catatannya membutuhkan 14 GB. Menjalankan skenario ini di GPU 4GB seperti laptop RTX 3050 bukan sekadar lambat; secara matematis itu mustahil tanpa rekayasa kompresi.

Solusi 1: PagedAttention dan Eliminasi Fragmentasi Memori

Sebelum kita memangkas token, kita harus memperbaiki kebiasaan buruk alokator memori GPU.

Secara tradisional, sistem inferensi AI memesan memori KV Cache dalam blok kontigu (berurutan) yang statis berdasarkan panjang konteks maksimum yang diantisipasi. Jika Anda mengalokasikan ruang untuk 128k token di awal, sistem langsung menyandera VRAM sebesar 14 GB meskipun Anda baru mengetikkan kata "Halo".

Kalaupun memori dialokasikan secara dinamis (dynamic allocation), terjadi masalah baru: fragmentasi memori. Data KV Cache yang dialokasikan dan dihapus seiring waktu menciptakan lubang-lubang kecil tak beraturan di VRAM. Akibatnya, antara 30% hingga 40% ruang VRAM terbuang sia-sia (virtual memory waste).

Tradisional(Contiguous Allocation):
[ Token 1-1000 ][      KOSONG TERKUNCI HINGGA 128K (TIDAK BISA DIPAKAI)      ]

PagedAttention(Non-contiguous Virtual Blocks):
[ Blok 0 (4KB) ] -> [ Blok 4 ] -> [ Blok 12 ] -> Terfragmentasi tapi 96% Terisi Penuh

Inspirasi penyelesaian masalah ini datang dari sistem operasi era 1960-an: Paging Virtual Memory. Algoritma PagedAttention (yang dipopulerkan oleh framework vLLM) memecah KV Cache menjadi blok-blok berukuran tetap (misalnya 16 atau 32 token per blok).

Blok-blok ini tidak perlu berada di alamat fisik memori GPU yang berurutan. Sebuah block table memetakan posisi token logis ke posisi memori fisik secara dinamis.

Efek langsungnya:

1. Zero Internal Fragmentation: Memori hanya dikonsumsi sesuai token yang benar-benar ada saat itu.


2. Dynamic Block Allocation: Blok baru dialokasikan hanya jika blok lama telah penuh.


3. Copy-on-Write Memory Sharing: Cabang generasi paralel (parallel sampling) dapat membagikan blok memori KV yang sama untuk teks prompt awal, menghemat memori hingga 55% pada skenario multi-turn chat.

PagedAttention memangkas pemborosan fragmentasi dari 40% menjadi di bawah 4%. Namun, menata ruang kosong saja belum cukup untuk memasukkan 14 GB ke dalam 4 GB. Kita perlu menyaring informasi apa yang layak dipertahankan di dalam buku catatan tersebut.

Solusi 2: Dynamic Token Eviction dan Paradoks "Attention Sink"

Apakah otak manusia mengingat setiap kata depan, koma, dan spasi dari pembicaraan yang berlangsung dua jam lalu? Tentu tidak. Otak mempertahankan konsep jangkar, struktur logika, dan kalimat terakhir yang diucapkan lawan bicara.

Transformer pada dasarnya melakukan hal yang sama secara intuitif, namun arsitektur lama memaksanya menyimpan seluruh sampah representasi.

Penelitian modern—terutama yang melahirkan teknik seperti StreamingLLM, H2O (Heavy Hitter Oracle), dan SnapKV—menemukan fenomena menarik mengenai distribusi bobot attention:

Distribusi Skor Attention pada Konteks Panjang:
+-------------------------------------------------------------------------+
| [Jangkar Awal]  . . . . . (Noise / Redundan) . . . . .  [Jendela Lokal] |
| Token 1 s.d. 8           Tokens yang jarang ditengok       2048 Token   |
| (Attention Sink)             (Layak Dibuang)               Terakhir     |
| [Bobot: 45%]                 [Bobot: < 5%]                 [Bobot: 50%] |
+-------------------------------------------------------------------------+

Ada dua pilar utama yang menyerap lebih dari 90% perhatian model:

1. Attention Sinks (Token-token paling awal): Terlepas dari makna semantiknya, token 1 sampai 4 menyerap softmax score dalam jumlah masif hanya karena model menjadikannya sebagai basis komputasi relatif (anchor bias). Jika token awal ini dihapus, model mengalami degradasi logika total (perplexity collapse).


2. Recent Rolling Window (Token-token terkini): Sekitar 1.024 hingga 2.048 token terakhir menjaga kelancaran sintaksis lokal dan alur gramatikal.


3. Heavy Hitters (Token Kunci Penjaga Konteks): Kumpulan token di tengah dokumen yang secara berulang dirujuk oleh matriks Query (misalnya: definisi variabel, nama tokoh utama, klausul nominal kontrak).

Algoritma Dynamic Token Eviction bekerja dengan mempertahankan ketiga elemen tersebut dan membuang sisanya secara proaktif dari KV Cache saat proses generasi berlangsung.

Matriks Matematis Eviction Policy (H2O Heuristic)

Pada setiap langkah generasi $t$, kita mengakumulasi skor perhatian yang diterima oleh setiap token $j$:

$$S_j^{(t)} = \sum_{\tau=1}^{t} \sum_{h=1}^{H} A_{h,\tau,j}$$

Di mana $A_{h,\tau,j}$ adalah nilai attention weight dari head $h$ pada step $\tau$ terhadap token $j$.

Ketika ukuran KV Cache melebihi batas anggaran memori $B$ (misalnya kita mematok batas maksimum hanya 4.096 token aktif dari total 128k input), mekanisme eviction mengeksekusi seleksi:

$$\mathcal{K}_{retained} = \mathcal{K}_{sink} \cup \mathcal{K}_{recent} \cup \text{Top-}k\left(\{S_j \mid j \notin \mathcal{K}_{sink} \cup \mathcal{K}_{recent}\}, k = B - |\mathcal{K}_{sink}| - |\mathcal{K}_{recent}|\right)$$

Token yang tidak masuk dalam himpunan $\mathcal{K}_{retained}$ langsung dihapus dari VRAM fisik. Ruang memori yang ditinggalkan dikembalikan ke block manager PagedAttention untuk dipakai oleh token generasi berikutnya.

Solusi 3: Kuantisasi KV Cache Tingkat Rendah (FP8 & INT4)

Selain mengurangi jumlah token (eviction), kita dapat mengompresi ukuran byte per token melalui kuantisasi asimetris.

Alih-alih mempertahankan matriks $K$ dan $V$ dalam presisi 16-bit (FP16), kita dapat mengonversinya menjadi INT4 atau FP8 secara on-the-fly saat dimasukkan ke cache, lalu melakukan dequantize ke FP16 sesaat sebelum operasi perkalian matriks Query-Key ($Q \cdot K^T$).

Kuantisasi Per-Channel Vector K & V:
FP16(2.0 Byte/elem) -> Scale & Zero-Point -> INT4(0.5 Byte/elem)
Penghematan Memori Langsung: 75%

Tantangan terbesar kuantisasi KV Cache adalah menjaga nilai pencilan (outliers) pada matriks Key yang sering kali merusak akurasi pengambilan fakta (needle-in-a-haystack). Solusinya adalah menerapkan Per-Token / Per-Channel Quantization dengan formula:

$$X_{quant} = \text{round}\left( \frac{X - \text{min}(X)}{\text{scale}} \right), \quad \text{scale} = \frac{\text{max}(X) - \text{min}(X)}{2^b - 1}$$

Di mana $b$ adalah kedalaman bit ($b = 4$ untuk INT4). Dengan menyimpan parameter scale dan zero-point per vektor head, degradasi nilai perplexity dapat ditekan hingga di bawah 0,1%.

Perbandingan Kinerja: Menguji Batas Kemungkinan

Mari kita telaah data matematis perbandingan berbagai strategi optimasi pada model 3B parameter yang menangani input dokumen 128.000 token.

Tabel Komparasi Teknis Pengelolaan KV Cache (128k Token Context)

Kombinasi antara Dynamic Token Eviction dengan Budgeting 4k token dan Kuantisasi INT4 memangkas kebutuhan memori KV Cache dari 14.010 MB menjadi hanya 120 MB—sebuah reduksi drastis sebesar 99,1% tanpa menghancurkan kemampuan penalaran dokumen secara substansial.

Implementasi Praktis: Menghitung dan Memprofiling Kebutuhan Memori

Berikut adalah simulasi kode Python mandiri yang mengkalkulasikan alokasi memori fisik dan menyimulasikan algoritma Token Eviction sederhana berbasis skor magnitudo attention.

import math
from dataclasses import dataclass

@dataclass
class ModelContextProfile:
    name: str
    layers: int
    kv_heads: int
    head_dim: int
    context_length: int

def calculate_kv_memory(profile: ModelContextProfile, precision_bits: int, active_tokens: int = None) -> dict:
    tokens = active_tokens if active_tokens else profile.context_length
    bytes_per_element = precision_bits / 8.0
    
    # Formula: 2 * L * H_kv * D * Precision * N
    bytes_per_token = 2 * profile.layers * profile.kv_heads * profile.head_dim * bytes_per_element
    total_bytes = bytes_per_token * tokens
    total_gigabytes = total_bytes / (1024 ** 3)
    
    return {
        "model": profile.name,
        "precision_bits": precision_bits,
        "processed_tokens": profile.context_length,
        "cached_tokens": tokens,
        "memory_per_token_kb": bytes_per_token / 1024,
        "total_kv_vram_gib": round(total_gigabytes, 3)
    }

# Profil Llama-3.2-3B
llama3_3b = ModelContextProfile(
    name="Llama-3.2-3B-Instruct",
    layers=28,
    kv_heads=8,
    head_dim=128,
    context_length=131072 # 128k
)

# Skenario 1: Full Cache Naive FP16
naive_fp16 = calculate_kv_memory(llama3_3b, precision_bits=16)

# Skenario 2: Compressed Cache (INT4 KV + Dynamic Eviction to 4096 Window + 128 Sinks)
compressed_int4 = calculate_kv_memory(llama3_3b, precision_bits=4, active_tokens=4224)

print("--- ANALISIS KEBUTUHAN MEMORI KV CACHE ---")
print(f"1. Naive FP16(128k tokens)    : {naive_fp16['total_kv_vram_gib']} GiB VRAM")
print(f"2. Evicted INT4(4224 tokens)  : {compressed_int4['total_kv_vram_gib']} GiB VRAM")

Output eksekusi:

--- ANALISIS KEBUTUHAN MEMORI KV CACHE ---
1. Naive FP16(128k tokens)    : 13.985 GiB VRAM
2. Evicted INT4(4224 tokens)  : 0.113 GiB VRAM

Logika Sederhana Dynamic Token Eviction

Di balik layar inference engine, manajemen penyimpanan matriks KV yang telah disaring berjalan mengikuti siklus berikut:

import numpy as np

class ToyDynamicKVCache:
    def __init__(self, sink_size=4, recent_window=2048, max_budget=4096):
        self.sink_size = sink_size
        self.recent_window = recent_window
        self.max_budget = max_budget
        self.cache_keys = []
        self.cache_scores = []

    def step_evict(self, new_key_vector, accumulated_attention_score):
        self.cache_keys.append(new_key_vector)
        self.cache_scores.append(accumulated_attention_score)
        
        current_len = len(self.cache_keys)
        if current_len <= self.max_budget:
            return # Memori masih mencukupi
        
        # Pisahkan komponen Sink dan Recent Window
        sink_indices = list(range(self.sink_size))
        recent_indices = list(range(current_len - self.recent_window, current_len))
        protected_indices = set(sink_indices + recent_indices)
        
        # Kandidat yang bisa dihapus adalah token di luar zona proteksi
        candidate_indices = [i for i in range(current_len) if i not in protected_indices]
        
        # Hitung berapa banyak yang harus dipertahankan dari Heavy Hitters
        heavy_hitter_quota = self.max_budget - len(protected_indices)
        
        # Urutkan kandidat berdasarkan akumulasi skor attention tertinggi
        candidate_scores = [self.cache_scores[i] for i in candidate_indices]
        top_k_candidates = [candidate_indices[i] for i in np.argsort(candidate_scores)[-heavy_hitter_quota:]]
        
        # Susun ulang indeks final yang dipertahankan
        surviving_indices = sorted(sink_indices + top_k_candidates + recent_indices)
        
        # Rekonstruksi Cache
        self.cache_keys = [self.cache_keys[i] for i in surviving_indices]
        self.cache_scores = [self.cache_scores[i] for i in surviving_indices]

Arsitektur Produksi: Mengawinkan Edge Computing dengan AiStudio.id API Gateway

Meskipun kompresi KV Cache memungkinkan komputasi konteks 128k di VRAM 4GB lokal, ada kenyataan operasional yang harus dihadapi para pengembang sistem cerdas: tidak semua beban kerja diciptakan setara.

Terkadang sebuah dokumen tidak hanya membutuhkan pencarian informasi berbasis kata kunci dan sintesis lokal, tetapi memerlukan daya nalar multi-tahap yang sangat kompleks (complex reasoning), perbandingan silang ratusan klaim, atau analisis data multivariat. Pada skenario ekstrem ini, SLM lokal 3B parameter mungkin mulai menunjukkan batas kapasitas penalarannya.

Pendekatan rekayasa yang matang mengadopsi pola arsitektur Hybrid Edge-to-Cloud Orchestration.

+------------------------+
                           |   Permintaan Dokumen   |
                           |   (Konteks 128k Token) |
                           +-----------+------------+
                                       |
                                       v
                    +--------------------------------------+
                    | Evaluasi Kompleksitas & Privacy Rule |
                    +------------------+-------------------+
                                       |
                   +-------------------+-------------------+
                   |                                       |
                   v(Task Standar/On-Prem)                v(Deep Reasoning/High Load)
     +---------------------------+           +-----------------------------+
     | Local Edge Engine(4GB)   |           | AiStudio.id API Gateway     |
     | - Llama-3.2-3B (INT4)     |           | - Model Router Pintar       |
     | - INT4 Dynamic KV Cache   |           | - Failover & Global Cache   |
     | - Fast, Zero Data Leak    |           +--------------+--------------+
     +---------------------------+                          |
                                                            v
                                             +-----------------------------+
                                             | High-End Cloud Tier         |
                                             | (Qwen-2.5-72B / DeepSeek-V3)|
                                             +-----------------------------+

Mengapa Pola Hibrida Ini Menjadi Standar Baru?

1. Efisiensi Biaya dan Latensi Nol untuk Tugas Rutin:

1. Fallback Cerdas Tanpa Friksi Lewat AiStudio.id:

1. Infrastruktur API Gateway yang Mengeliminasi Overhead:

Panduan Implementasi Step-by-Step untuk Praktisi

Bagi pengembang yang ingin merealisasikan pemrosesan dokumen panjang pada perangkat lokal terbatas, berikut langkah konfigurasi yang dapat diterapkan langsung:

Langkah 1: Kuantisasi Model dan Aktifkan FlashAttention-2

Langkah 2: Konfigurasi Flag KV Cache Quantization

# Menjalankan model Qwen-2.5-3B dengan KV Cache terkuantisasi 4-bit (q4_0)
./llama-cli \
  -m ./models/qwen2.5-3b-instruct-q4_k_m.gguf \
  -c 131072 \
  -ctk q4_0 \
  -ctv q4_0 \
  --flash-attn \
  -n 512 \
  -p "Analisis dokumen 128k berikut: ..."

Langkah 3: Terapkan Context Truncation & Eviction Window

from transformers import AutoModelForCausalLM, AutoTokenizer, DynamicCache

model_id = "meta-llama/Llama-3.2-3B-Instruct"
tokenizer = AutoTokenizer.from_pretrained(model_id)
model = AutoModelForCausalLM.from_pretrained(
    model_id, 
    device_map="cuda", 
    torch_dtype="auto",
    attn_implementation="flash_attention_2"
)

# Inisialisasi DynamicCache dengan batas memori yang terkontrol
custom_cache = DynamicCache()

Langkah 4: Sambungkan Pipeline ke AiStudio.id API Gateway

import os
import requests

def run_hybrid_inference(prompt: str, local_confidence_score: float):
    # Ambang batas nalar lokal
    CONFIDENCE_THRESHOLD = 0.85
    
    if local_confidence_score >= CONFIDENCE_THRESHOLD:
        return run_local_slm(prompt) # Proses di 4GB VRAM
    
    # Fallback ke Cloud Tier via AiStudio.id Gateway
    print("[Router] Kompleksitas tinggi terdeteksi. Merutekan ke AiStudio.id API Gateway...")
    headers = {
        "Authorization": f"Bearer {os.getenv('AISTUDIO_API_KEY')}",
        "Content-Type": "application/json"
    }
    payload = {
        "model": "qwen-2.5-72b-instruct",
        "messages": [{"role": "user", "content": prompt}],
        "temperature": 0.2
    }
    
    response = requests.post(
        "https://api.aistudio.id/v1/chat/completions",
        headers=headers,
        json=payload
    )
    return response.json()['choices'][0]['message']['content']

Refleksi Rekayasa: Menolak Mitos Hardware Mewah

Ada pandangan keliru di kalangan praktisi bahwa pengembangan aplikasi berbasis Large Language Model harus selalu bersandar pada sewa klaster komputasi bernilai miliaran rupiah. Paradigma tersebut mengabaikan esensi dasar rekayasa perangkat lunak: efisiensi algoritma selalu mengalahkan pemborosan sumber daya mentah.

Memproses 128.000 token bukan lagi hak istimewa kartu grafis enterprise berharga ratusan juta. Melalui matematika reduksi yang cermat—memadukan representasi kuantisasi INT4, eliminasi fragmentasi PagedAttention, dan ketajaman algoritma Dynamic Token Eviction—kartu grafis 4GB yang ada di meja kerja Anda bertransformasi dari sekadar hardware gaming biasa menjadi mesin pemroses dokumen skala industri.

Dan ketika batasan fisik chip lokal Anda akhirnya tercapai, integrasi pintu gerbang terpadu seperti AiStudio.id API Gateway memastikan aplikasi Anda tetap melaju kencang, menggabungkan kemandirian komputasi lokal dengan kecerdasan cloud tanpa kompromi.

Catatan Penulis

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