Snilld

LCLM komprimerer kontekst 16× og rapporterer 8,8× throughput på RULER

Et tværinstitutionelt forskerhold foreslår Latent Context Language Models, der komprimerer input før decoder‑prefill. Ifølge VentureBeat og arXiv‑papiret rapporteres op til 16× komprimering og 8,8× højere throughput på RULER mod KV‑cache baselines samt 91,76% nøjagtighed ved 4× mod 94,41% uden komprimering. Arbejdsgangen sigter mod lavere decoder‑compute og hukommelse, når komprimeringsgraden øges.

12. juni 2026 Peter Munkholm

Et forskerhold på tværs af New York University, Columbia, Princeton, University of Maryland, Harvard og Lawrence Livermore National Laboratory præsenterer Latent Context Language Models, LCLM. Ifølge VentureBeat og det tilhørende arXiv‑paper adresserer arbejdet den voksende flaskehals fra lange kontekster i store sprogmodeller, hvor hentede dokumenter, reasoning‑spor og samtalehistorik ophober tokens og driver hukommelses‑ og compute‑forbrug op.

Ifølge kilderne ligger idéen i at komprimere inputsekvensen før decoder‑prefill. VentureBeat beskriver, at denne forskydning reducerer belastningen på decoder‑siden, i takt med at komprimeringsgraden øges. ArXiv‑papiret beskriver samme arbejdsgang i et end‑to‑end design.

Baggrund og problem

VentureBeat framede udgangspunktet som en klar driftsmæssig udfordring: kontekstvinduer er blevet en beregningsmæssig flaskehals, fordi tokens fra dokumenter, reasoning‑traces og samtalehistorik akkumuleres over tid og forbruger mere hukommelse og compute. Papiret forfølger effektiv håndtering af meget lange kontekster med trænet komprimering, ikke efterfølgende trimming af caches.

VentureBeat anfører, at mange eksisterende løsninger enten forringer nøjagtighed, kræver at hele konteksten indlæses før komprimering begynder, eller giver hukommelsesbesparelser, som ikke omsættes til reelle hastighedsgevinster på standard infrastruktur. LCLM adskiller sig ved at flytte komprimeringen til før decoder‑prefill og sigter dermed mod, at compute og hukommelse i decoder falder med komprimeringsgraden.

Angled operations board with cyan/green tape routes visualizing ingestion → compressed pipeline, hånd med pegetoken i fokus.

Hvad er LCLM ifølge kilderne

VentureBeat og arXiv‑papiret beskriver LCLM som en familie af encoder–decoder‑kompressionsmodeller, der omsætter lange token‑sekvenser til kortere latente repræsentationer, som decoderen arbejder på. Arbejdsgangen er end‑to‑end: encoderen komprimerer konteksten, hvorefter decoderen genererer output fra de latente sekvenser frem for de rå tokens. Det er kernen i den rapporterede effekt på decoder‑siden.

Banner

Kilderne præsenterer LCLM som et generelt forslag til at håndtere lange kontekster med lavere ressourceforbrug, uden at læne sig på efterfølgende KV‑cache‑reduktion. VentureBeat sætter kontrasten op til metoder, der ikke nødvendigvis omsætter hukommelsesbesparelser til målbare hastighedsforbedringer, mens LCLM sigter mod målbare speedups, fordi komprimeringen sker før prefill.

Resultater på RULER og nøjagtighed ved moderate niveauer

På RULER, et lang‑kontekst benchmark, gengiver VentureBeat, at LCLM ved 16× komprimering leverede 8,8× hurtigere output end KV‑cache baselines. Ifølge samme dækning rapporterer papiret ved 4× komprimering en nøjagtighed på 91,76 procent mod 94,41 procent uden komprimering. Det er et tab på under tre procentpoint, mens konteksten reduceres til en fjerdedel. Disse tal fremgår af VentureBeats gennemgang og korresponderer med papirets rapporterede resultater.

Kilderne dokumenterer altså to forhold samtidig på RULER: at høj komprimering giver markante throughput‑gevinster mod KV‑cache baselines, og at moderate komprimeringsgrader kan ligge tæt på baseline‑nøjagtighed. Begge pointer er direkte rapporteret i VentureBeat og stemmer overens med papirets talangivelser.

Forskellen til KV‑cache‑komprimering

Ifølge VentureBeat materialiserer dominerende KV‑cache‑tilgange den fulde cache, før poster fjernes. LCLM komprimerer inden decoder‑prefill. Konsekvensen, som kilderne angiver, er at højere komprimeringsgrader direkte sænker decoder‑compute og decoder‑hukommelse, fordi decoderen ikke ser den ukomprimerede sekvens. ArXiv‑papiret beskriver samme forskel i arbejdsgang og motivet for et end‑to‑end design.

Det er også derfor, skriver VentureBeat med henvisning til papiret, at throughput‑gevinsterne måles på RULER: når komprimeringen ligger før prefill, skal selve decoding‑arbejdet falde i takt med komprimeringsgraden. Kilderne forholder sig samtidig til forskellen mellem teoretiske hukommelsesbesparelser og målte hastighedsforbedringer, som ikke altid følges ad for metoder, der komprimerer efterfølgende.

Tekniker ved et test‑rig tjekker status‑LEDs under en benchmarkkørsel — indikerer throughput‑test i praksis.

Release og tilgængelighed

VentureBeat skriver, at modellerne er open‑sourced på HuggingFace. ArXiv‑opslaget bærer en CC‑BY 4.0‑angivelse. VentureBeat er den eksplicitte kilde til påstanden om HuggingFace‑frigivelse; arXiv‑pdf’en i sig selv er ikke brugt her som linkkilde til et specifikt repo.

Banner

Ud fra kilderne kan to forhold gengives klart: a) VentureBeat oplyser, at modellerne er lagt ud som open source på HuggingFace, og b) papiret er offentligt tilgængeligt under CC‑BY 4.0 på arXiv. Kilderne angiver ikke yderligere praktiske detaljer om repositories eller vægtfiler i den dokumentation, vi henviser til her.

Hvad kilderne dækker – og ikke dækker

VentureBeat gengiver RULER‑resultaterne og den metodiske forskel til KV‑cache‑komprimering. Artiklen og papiret leverer ikke fulde måletraces eller detaljerede beskrivelser af konkrete deploy‑ og serving‑forhold ud over benchmark‑opsætningen, sådan som de er refereret. De specificerer heller ikke, hvordan de rapporterede throughput‑gevinster varierer med små batchstørrelser i realtidsbrug. Det fremgår ikke af materialet, vi har anvendt her.

Derudover beskriver kilderne den principielle reduktion af decoder‑compute og hukommelse ved komprimering før prefill. De går ikke i dybden med bredere driftsforhold ud over benchmark‑resultaterne. Dele af et fuldt driftsbillede ligger derfor uden for, hvad der fremgår af de to kilder, vi refererer.

Praktiske implikationer inden for kildernes ramme

Inden for det kildedækkede kan man konstatere følgende: LCLM sigter mod at give længere nyttige kontekster til en lavere ressourcepris, fordi decoderen arbejder på en komprimeret latent sekvens frem for rå tokens. Når komprimeringsgraden øges, skal decoderens compute‑ og hukommelsesforbrug falde tilsvarende, sådan som VentureBeat beskriver og papiret lægger op til metodisk.

Samtidig viser de rapporterede tal på RULER, at moderate komprimeringsgrader kan holde nøjagtigheden relativt tæt på baseline (91,76% ved 4× vs 94,41% uden komprimering ifølge VentureBeat), mens den store throughput‑gevinst rapporteres ved 16× komprimering. Disse målinger er bundet til RULER i kilderne og bør læses som netop benchmark‑resultater, ikke udvidelser til andre datasæt uden yderligere dokumentation i kilderne.

Nærbillede af en cyan‑rimmet status‑token på et pegboard — symbol på operational checkpoint for en komprimeringspipeline.

Opsummering

Kilderne peger samlet på tre dokumenterede forhold: 1) voksende kontekster skaber en beregningsmæssig flaskehals for LLM‑er, 2) LCLM komprimerer før decoder‑prefill og reducerer dermed decoder‑compute og hukommelse, og 3) på RULER rapporteres 8,8× throughput ved 16× komprimering mod KV‑cache baselines samt 91,76% nøjagtighed ved 4× mod 94,41% uden komprimering. VentureBeat er kilden til, at modellerne er open‑sourced på HuggingFace, mens arXiv‑opslaget bærer en CC‑BY 4.0‑licensangivelse.

For yderligere reproducerbarhed – som ikke dækkes i de anvendte kilder – vil detaljer om serving‑miljø, batchstørrelser og fulde måletraces være nødvendige. De fremgår ikke af VentureBeat‑artiklen eller arXiv‑pdf’en, sådan som de er refereret her.

Kilder

    Gør brugeroplevelsen bedre.
    Hvilket firma arbejder du for?