Ang 128k context sa desktop ay kasinungalingan. Kinain ng KV cache.

Ang bawat local model card ngayon ay nagmamalaki ng 128k context window. Sa desktop, ang numerong iyan ay kontrata sa upa na pinipirmahan ng RAM mo nang hindi binabasa. Ang nagpapasya kung hanggang saan mo maitutulak ang mahabang dokumento ay hindi ang weights — kundi ang KV cache, na dumadami kasama ng context na parang buwis na nakasangla sa pera ng iba.

Ang context window ay hindi feature na i-on mo lang. Ito ay upa sa memorya na binabayaran mo bawat segundong tumatakbo ang server.

Gaano kalaki talaga ang RAM na kinakain ng 128k context?

Publiko at maikli ang matematika. Gaya ng ipinaliwanag sa Transformer Inference Arithmetic, nag-iimbak ang KV cache ng dalawang tensor — keys at values — para sa bawat layer, bawat KV head, bawat token:

cache_bytes = 2 × layers × context × kv_heads × head_dim × bytes_kada_element

Kunin ang Llama 3.1 8B: 32 layers, 8 KV heads, head_dim 128 — derecho mula sa config.json sa Hugging Face. Sa 131,072 tokens sa fp16 (2 bytes):

2 × 32 × 131072 × 8 × 128 × 2 = 17,179,869,184 bytes ≈ 16 GiB

Ang weights ng parehong model sa fp16 ay mga 16 GiB. Sa maximum context, kasinglaki ng cache ang model na kinaroroonan nito. Ang “8B model na kasya sa 16 GiB” ay tahimik na nagiging 32 GiB na problema sa sandaling itinaas mo ang num_ctx sa 128k.

Bakit lumalaki ang cache kasama ng window?

Kasi ang attention ay kailangang i-compare ang bawat token sa lahat ng naunang token, at ang inference ay autoregressive — walang muling kinakalkula, lahat natatandaan. Iyon ang buong trick kung bakit mabilis ang generation: ang keys at values ng bawat token ay kinesa nang isang beses tapos iniimbak. Constant ang storage kada token, kaya linear sa context ang kabuuan. Ang 128k ay hindi “mas malaking numero” — ito ay 128× ng cache ng 1k window, nakalaan buong session.

Ang grouped-query attention (GQA) ang diskwento sa gilid ng model: kaunting KV heads, payat na cache. Ang Qwen2.5 7B ay 28 layers na may tanging 4 KV heads (config dito), kaya ang parehong 128k window ay mga 7 GiB lang sa fp16 — tunay na ginhawa, at isang dahilan kung bakit mabait ang mga model na ito sa mga tipid na makina.

Model (fp16)	Layers × KV heads	KV cache @ 128k	Weights	Cache vs weights
Llama 3.1 8B	32 × 8	~16 GiB	~16 GiB	~100%
Qwen2.5 7B	28 × 4	~7 GiB	~15 GiB	~47%

I-kalkula mismo — ito lang ang buong beripikasyon:

def kv_cache_gib(layers, kv_heads, head_dim, ctx, bytes_per=2):
    return 2 * layers * ctx * kv_heads * head_dim * bytes_per / 2**30

print(kv_cache_gib(32, 8, 128, 131_072))  # Llama 3.1 8B  -> 16.0
print(kv_cache_gib(28, 4, 128, 131_072))  # Qwen2.5 7B    -> 7.0

Ang hindi sinasabi ng marketing number

Ito ang tapat na ledger ng argumentong ito — kasama ang mga puntong bumabaluktot:

• Ang prefill ay pangalawang bill. Bago pa lumabas ang unang answering token, pinoproseso nang buo ang buong prompt. Ang 100k-token prompt ay 100k tokens ng nguya bago makakita ng unang karakter. Sa 3060, minuto iyon, hindi millisecond.
• Ang sliding-window models ay bumabali ng kalkulasyon — pabor sa iyo. Ang mga Mistral-style architectures ay humahadlang sa attention sa fixed window kada layer, kaya tumitigil ang paglaki ng cache. Sine-overestimate ng simpleng formula ang mga ito. Tungkol sa full-attention transformers ang post na ito — ang karamihan ng tinitakbo ng mga tao.
• Totoo ang KV quantization pero partial. Kayang i-hold ng llama.cpp ang KV sa q8_0 — mga kalahati ng cache, may kaunting quality risk. Ang kalahati ng 16 GiB ay 8 GiB pa rin.
• Bihirang banggitin ng specs ang KV heads. Kailangan mong maghukay sa config.json — na sapat nang pahiwatig kung paano gusto basahin ng numerong iyan.

Walang anuman sa mga ito ang ginagawang walang silbi ang mahabang context. Umiiral ang RAG dahil eksakto — ang pagpuno ng window ay ang mamahaling paraan ng pagsabing “basahin ang section 4”. Pero ang card na nagpi-print ng “128k” nang hindi nagpi-print ng memory bill ay nagtitinda ng kotse sa top speed nang hindi binabanggit ang tangke.

Walang nagbabasa ng 128,000 tokens. Binabayaran pa rin ng RAM mo ang lahat.

Ang gamot ay nakakabagot: itakda ang context sa aktwal na ginagamit ng workload mo. Ang 32k window ay isang-kaapat ng 128k cache at sumasaklaw sa halos bawat prompt na tunay na ipinapadala ng solo dev. Ito rin ang ledger discipline ng RAM math para sa local LLMs — kalahati lang ng budget ang model size, at ang quantization levels ay pumipikit ng weights pero hindi humahawak sa cache math.

Kung ang cache ang tunay na presyo ng context, bakit binebenta ng cards ang window pero hindi kailanman ang bill? At confessional round: ano ang pinakamalaking context na tunay mong napuno hanggang huling token — at sinukli ba ng output ang mga gigabyte? Bukas ang comments; ang susunod na bahagi ng serye ay kakampi ng natalong panig.