25. maj 2026 annoncerede Together AI, at de open-sourcer OSCAR, et 2-bit (INT2) KV-cache kvantiseringssystem, der er gjort attention-aware. De roterer nøgler og værdier ud fra, hvad attention faktisk læser, før de pakker dem ned i 2 bit. Tørt på papiret, men vigtigt i praksis: hvis INT2 på KV-cachen virker uden at vælte kvaliteten, rykker det bundlinjen for lang-kontekst serving.
Hvorfor nu? Fordi KV-cachen er blevet den dyre del, når konteksterne stiger, og brugerne forventer realtid. Vi har set det hos kunder gentagne gange det sidste halve år: 10–50 procent af GPU-RAM kan være bundet i cache ved 32k+ kontekstlængder. Og så går alt i stå, når der lander en håndfuld 100k-sessioner samtidig.
Hvad OSCAR lover
OSCAR står for Offline Spectral Covariance-Aware Rotation. Pointen er at gøre rotationen før kvantisering opmærksom på attention-statistikker. I stedet for at minimere almindelig rekonstruktionsfejl i K, forsøger metoden at minimere fejl i selve attention-logits. Ifølge den tekniske gennemgang fra Together AI er det her forskellen på, at INT2 kollapser eller holder. Ambitionen giver mening; om koden leverer i produktion, må en POC afgøre.
Timingen er bemærkelsesværdig. Mange har fået INT4 til at fungere for KV (med rotationer a la Hadamard), men INT2 har typisk sendt kvaliteten i grøften. Hvis OSCAR kan holde modellen stabil og samtidig passe i eksisterende paged KV-opsætninger, er det ikke kun en forskningsdemo, men potentielt driftsegnet.
Hvorfor KV-cachen koster rigtigt
KV-cachen vokser med tre ting: kontekstlængde, batch-størrelse og modeldybde. Under autoregressiv dekodning stiger hukommelsen lineært i tokens og lag. Læg dertil dusinvis af samtidige requests, og man får hurtigt en profil, hvor det ikke er matmul, men hukommelsen og I\/O, der begrænser. Kilderne peger på det samme, og vores egne målinger stemmer.
Et konkret billede: Forestil dig en tjeneste med 24 samtidige sessioner, hvor flere ligger på 80–120k tokens. Uden komprimering ryger der mange gigabyte per anmodning bare på KV. Det sænker achievable batch og tvinger jer ud i NVMe-offload og mere kompleks scheduling. Det virker – men det er dyrt og skrøbeligt.
Teknisk udfordring med INT2
Hvorfor er 2 bit svært? KV-aktiviteter har kanalvise outliers. Nogle kanaler får store spikes, de fleste ikke. Med fire kvantiseringsniveauer ender skalaen med at blive styret af få spikes, og normale værdier presses ned i én–to effektive trin. Det ødelægger attention, især ved lange kontekster.
Rotationer hjælper, men kun til en grænse. En fast, data-uafhængig rotation som Hadamard kan sprede outlier-energi og virker ofte ved INT4. Ved INT2 falder det fra hinanden, fordi rotationen ikke tager højde for, hvilke retninger attention rent faktisk læser. At sprede fejlen jævnt er ikke det samme som at parkere den i uvigtige retninger. Med fire niveauer er forskellen afgørende.
Hvad OSCAR gør anderledes
OSCAR udleder rotationen fra attention-statistikker. For nøgler handler fejlen ikke om Euclidisk afvigelse i K, men om fejl i QKᵀ. Vægtningen bliver i praksis QᵀQ, altså query-kovariansen. Together AIs beskrivelse forklarer, at de estimerer en empirisk CQ ud fra et kalibreringssæt, eigendecomposerer den og bruger egenvektorerne UQ som basis for key-rotationen. Det gør rotationen følsom for, hvor Q har mest energi.
Værdier behandles tilsvarende, men med vægt i forhold til scoret aggregering: en score-vægtet kovarians CS = VᵀSᵀSV. Egenvektorerne US bliver værdi-rotationens basis. Intuitionen er enkel: de retninger, der bliver store efter vægtning af attention-scorer, må ikke ødelægges af kvantisering. Resten kan tåle mere støj.
Rotationen står ikke alene. OSCAR komposerer UQ eller US med en Walsh–Hadamard-transform og en permuted bit-reversal, organiseret per gruppe. Hadamard flader et spidst eigenspektrum ud, mens den permuterede bit-reversal sikrer, at hver kvantiseringsgruppe får en blanding af vigtige og mindre vigtige komponenter. Det er praktisk, fordi low-bit kvantisering typisk sker per blok.
Hvad vi ved om resultaterne
Den offentlige gennemgang peger på, at tidligere INT2-metoder enten kollapsede i nøjagtighed eller krævede særlige server-layouts, der ikke spiller med paged KV-cache. OSCAR hævder at håndtere begge problemer. Der nævnes integration i SGLang med kompatibilitet til paged attention og en cache-layout, hvor de første 64 sink-tokens opbevares i BF16. Det er lovende, især fordi mange stacks allerede er paged i produktion.
Vi mangler stadig uafhængige benchmarks af throughput og latens i produktscenarier. Hvad koster rotation, kvantisering og dekvantisering per token i praksis? Hvor meget CPU- eller GPU-tid går der? Og hvor tæt ligger kvaliteten på FP16 eller INT4 på tværs af opgaver? Indtil de tal er på bordet, må man regne med spænd i gevinsten.
Hvad det kan ændre i driften
Hvis INT2 på KV-cachen holder, stiger achievable batch på samme hardware, fordi hukommelsen pr. sekvens falder. Mindre hukommelse betyder også mindre memory traffic og ofte lavere I\/O-pres på NVMe ved paged cache. I systemer, hvor man konstant balancerer kvalitet og latency, er det netop sådan en knap, der kan gøre en tjeneste økonomisk holdbar.
Der er trade-offs. INT2 giver uundgåeligt mere kvantiseringstøj. OSCAR forsøger at parkere det, hvor det skader mindst, men små kvalitetstab på visse opgaver er sandsynlige. Dertil kommer overhead fra rotationer og blokvis dekvantisering i dekodering. Om det betaler sig, afhænger af jeres workloads – ikke af et gennemsnitstal på et blogdiagram.
Kompatibilitet med paged KV og offload
En vigtig pointe i materialet er, at OSCAR ikke kræver et eksotisk cache-layout. Det skal være kompatibelt med paged attention, hvilket gør adoption mindre smertefuld. Vi hæfter os også ved indikationen af mixed-precision zoner i cachen, fx at første batch af tokens kan ligge i højere præcision. Det matcher, hvordan mange allerede prioriterer de første tokens for stabilitet.
For teams med NVMe-offload er der en balance. Ja, mindre per-token footprint hjælper, men hvis dekvantisering lander på CPU, kan flaskehalsen flytte sig. Hvis den lander på GPU, deler den tid med selve dekoderingen. Ikke et showstopper, men noget der skal måles.
Hvad vi selv har set i felten
Vi har siddet i en kælder i Sydhavnen med en kunde klokken 22.30, mens grafen for GPU-RAM hakkede op og ned, fordi tre lange dokumentstrømme ramte samtidig. Lugten af støv fra rackskabet og blæserne, der lød som et tog. Her var 40 procent af RAM bundet i KV. Vi endte med at kombinere paged cache på NVMe, aggressiv batch-styring og hybrid kvantisering. Det løste det midlertidigt, men kønt var det ikke.
Pointen: hvis OSCAR kan levere 2–4x komprimering af KV i praksis (afhængig af baseline) uden at vælte kvaliteten, kan mange skrue ned for nødforanstaltningerne. Især dér, hvor retrieval i forvejen æder I\/O-budgettet. Men vi sælger ikke drømmen – forskellen ses først, når man har det i hænderne.
Implementeringscheckliste
Hvis I vil prøve OSCAR, så kør en POC med to distinkte workloads: mange små samtaler samtidig og få meget lange kontekster. Brug et kalibreringssæt trukket fra jeres egne logs (anonymiseret og governance-godkendt), så CQ og CS faktisk matcher trafikken. Mål både kvalitet (downstream-metrics) og systemmål som tokens pr. sekund, batch-udnyttelse og GPU-udnyttelse.
- Kalibrering: byg en pipeline, der kan genkøres ved modelopdatering eller ændrede prompts. Versionér datasættet.
- Integration: test med jeres nuværende paged KV-cache. Undgå special-layout i første omgang.
- Fallback: sæt thresholds for kvalitetstab (fx perplexity-drift eller task-metrics) og skift til INT4\/FP16 ved overskridelse.
- Overvågning: log statistik for logits-afvigelse vs. baseline samt latens pr. token. Hold øje med sessions, hvor kvaliteten dropper uforholdsmæssigt.
- Profilering: mål CPU\/GPU-tid for rotation og dekvantisering. Hvor flytter flaskehalsen sig hen?
Begrænsninger og åbne spørgsmål
Metoden bygger på, at query- og scorefordelingen i produktion ligner kalibreringssættet. Hvis trafikken skifter (nye prompts, nye domæner), kan rotationen blive suboptimal og kvaliteten glide. Hvor ofte skal man rekalibrere? Det er ikke dokumenteret endnu, så læg en plan fra start.
Vi mangler også klare tal på end-to-end throughput og latency-overhead. Den åbne omtale viser metoden og integrationstanken, men ikke en hardware-uafhængig benchmarkpakke på populære serving-stacks. Og vi har ikke set head-to-head imod alternativer som rent NVMe-offload, sparsede attention-varianter eller lagvis hybrid-kvantisering.
Hvad skeptikere vil indvende
“INT2 er stadig for lavt. Det går kun på marketingdemos.” Muligt, men indvendingen hviler ofte på data-oblivious rotationer. OSCARs attention-aware tilgang adresserer netop det. “Overhead sluger hele gevinsten.” Også muligt i nogle set-ups, derfor kræver det profilering. Vi har set systemer, hvor compute var billigere end I\/O – og omvendt. Uden målinger er det gætværk.
En tredje indvending: “Paged cache-kompatibilitet på papiret er ikke det samme som i praksis.” Fair. Der er altid hjørnesager i fragmentering, eviction-politikker og multi-host. Første POC bør derfor køres på den konkrete stack – ikke i et laboratoriemiljø, hvor alt er pænt.
Snillds vurdering
Idéen bag OSCAR er det mest seriøse bud på INT2 for KV, vi har set offentligt. Den flytter målfunktionen derhen, hvor fejlene faktisk tæller. Overraskelsen er, hvor meget de får ud af kombinationen UQ\/US med Hadamard og en enkel permutation. Ikke fordi matematikken er ny, men fordi den er sat sammen til noget, der passer i en driftspipeline.
Vores anbefaling er pragmatisk: kør en ugelang POC med rigtige trafikmønstre, mål kvalitet vs. omkostning, og forbered en rulleplan for rekalibrering ved modelskifte. Driver I en tjeneste, hvor kontekstlængden ofte stikker af, er potentialet størst. Hvis jeres workload er korte prompts i stor volumen, er gevinsten mindre, og INT4 kan være det sikre valg.
Når det rammer hverdagen
I et af vores kundeteams gav bare 15 procent bedre udnyttelse af batch mærkbar effekt på køtiderne. Ikke et stort PR-øjeblik – bare færre support-tickets kl. 16.12. OSCAR kan være sådan en stille forbedring, hvis det spiller: færre GPU’er pr. gennemløb eller lidt lavere latency, fordi memory pressure falder. Eller en omvej, hvis kalibreringen ikke holder.
Vi går ikke længere ned i alle beviserne her. Det vigtigste er at teste på egen trafik. Små afvigelser i query-statistikker kan tippe balancen.
Næste skridt for teams der vil prøve det
- Udvælg modeller og workloads, hvor KV er dokumenteret flaskehals i dag.
- Byg et kalibreringssæt fra produktionslog og versionér det, inkl. dato og prompt-profiler.
- Kør dual-baseline: FP16 eller INT4 som reference mod OSCAR-INT2.
- Mål både kvalitet (task-metrics) og systemmål (batch, tokens\/s, GPU-RAM, NVMe-I\/O).
- Etabler automatisk fallback og alarmer på kvalitetsdrift.
- Planlæg rekalibrering ved finetuning eller store prompt-ændringer.
Et sidste sidespor: Vi testede forleden en intern case, hvor en OSCAR-lignende rotation holdt kvaliteten på summarization, men gjorde klassificering nervøs ved prompt-skift. Løsningen var banal: ny kalibrering. Det er ikke magi – bare ingeniørarbejde.
Summa: OSCAR kan være nøglen til at gøre lang-kontekst mere økonomisk. Eller endnu et værktøj i kassen sammen med NVMe-offload og klog batching. Man finder først ud af det med en ærlig POC.
