vLLM uveo DeepSeek V4 s 8,7× manjim KV cacheom: milijun tokena konteksta na standardnom GPU hardveru

vLLM, jedan od najraširenijih open-source serving frameworka za velike jezične modele, objavio je 24. travnja 2026. punu podršku za DeepSeek V4-Pro i V4-Flash. Ključna tvrdnja: KV cache 8,7× manji od onoga koji bi zahtijevali V3.2-stilski modeli pri istoj kontekstualnoj duljini od milijun tokena.

Ovo nije samo teoretska tvrdnja — vLLM implementacija u produkcijskom okruženju troši oko 9,62 GiB po sekvenci u bf16 pri punom milijunskom kontekstu, što je razlika između “treba nam H100 cluster” i “stane na standardnu produkcijsku kartu”.

Kako funkcionira optimizacija KV cachea?

DeepSeek V4 koristi četveroslojnu strategiju koju je vLLM morao podržati u serving sloju. Prvo, shared KV vektori s inverznom RoPE primjenom daju dvostruku uštedu memorije. Drugo, kompresija KV cachea kroz težinsko zbrajanje tokena ovisno o metodi daje 4× do 128× uštede.

Treći sloj je sparse attention koja ograničava računanje na top-k komprimiranih tokena, dok četvrti — lokalni klizni prozor — čuva pune vektore za nedavni kontekst kako se ne bi izgubila preciznost u neposrednom fokusu modela.

Za praktičnu primjenu to znači da model istodobno drži agresivno sažet globalni kontekst i preciznu lokalnu pažnju, što je razlika u odnosu na klasične GQA arhitekture koje linearno skaliraju memoriju s duljinom konteksta.

Što je vLLM morao riješiti u integraciji?

Integracija heterogenih omjera kompresije u isti serving engine nije trivijalna. vLLM tim ističe tri glavna tehnička izazova koje su morali riješiti.

Prvi je upravljanje memorijom: različiti attention slojevi imaju različite omjere kompresije (4× za CSA, 128× za HCA), ali vLLM koristi fiksne logičke blokove od 256 token pozicija kako bi se kompatibilnost s PagedAttention mehanizmom sačuvala. To znači da se interno mapiranje logičkog u fizički blok mijenja ovisno o sloju.

Drugi izazov je stanje: ostatak kompresora tretira se kao sliding-window KV, što omogućuje integraciju s postojećim prefix cache mehanizmom i disaggregated serving infrastrukturom. Bez tog trika, prefix caching — ključan za produkcijski LLM serving — ne bi funkcionirao preko komprimiranih sekvenci.

Treći izazov je efikasnost kernela: vLLM je uveo tri ciljana fusiona i multi-stream paralelizaciju GPU operacija, što zajedno daje 5 do 6 posto manju latenciju per token u usporedbi s naivnom implementacijom.

Zašto je ovo bitno za produkciju?

Dosad je serving modela s milijun tokena konteksta bio ograničen na velike cloud provajdere s custom hardverom. Memorija KV cachea rasla je linearno s kontekstom, a 128K tokena već je zahtijevalo višestruke GPU-ove po sekvenci.

Uz DeepSeek V4 i vLLM-ovu integraciju, standardne H100 ili H200 konfiguracije postaju dovoljne za serviranje dugih konteksta. Operativni trošak se, prema vLLM tvrdnjama, smanjuje u red veličine za long-context agentske workloadove.

Za hrvatske razvojne timove koji razmatraju self-hosting umjesto oslanjanja na Anthropic ili OpenAI API — tipično zbog GDPR compliance-a ili kontrole nad podacima — ova kombinacija je konkretan argument. V4-Flash model s 13 milijardi aktivnih parametara u kombinaciji s vLLM serving slojem postaje izvediva produkcijska opcija.

Puna integracija dostupna je u posljednjoj vLLM verziji preko pip install vllm te podržava i FP4 i FP8 kvantizaciju, ovisno o hardveru.