Hvad Context Window'et rummer
Sprogmodeller beholder ingen hukommelse mellem forespørgsler; Context Window'et er hele deres arbejdshukommelse for ét kald. Det er fyldt med tokens - i engelsk groft tre fjerdedele af et ord hver - og dækker system-prompten, eventuelle tidligere ture i en samtale, dokumenter leveret til retrieval og de tokens, modellen genererer som svar. Når en opgave overstiger window'et, må de ældste tokens droppes eller opsummeres - derfor er lange agent-kørsler og opgaver over store kodebaser begrænset af context-størrelsen. Aktuelle Open-Weight-modeller, vi betjener, såsom MiniMax M2.7, tilbyder windows på omkring 192K tokens.
Under inference læses hele input-konteksten i prefill-fasen, hvor modellen behandler hver prompt-token parallelt for at opbygge sin interne tilstand - KV-cachen - før den kan udsende den første token. Hver token genereret under decode tilgår derefter denne gemte kontekst. Context Window'et er altså ikke bare en kapacitetsgrænse; det er dét, der behandles ved hver forespørgsel, og dets størrelse former direkte, hvordan forespørgslen præsterer.
Hvorfor context-længden driver hastighed og omkostning
Omkostningen ved context er ikke lineær. Attention-mekanismen i transformerens kerne sammenligner hver token med hver anden token, så arbejdet i prefill skalerer kvadratisk med prompt-længden: en prompt på 1.000 tokens indebærer i størrelsesordenen en million attention-interaktioner, mens 10.000 tokens indebærer hundrede millioner. I produktionstermer kan en prompt på 128K tokens tage flere sekunders prefill, og en prompt på en million tokens titals sekunder, før en eneste output-token dukker op. Derfor er time to first token-tal meningsløse uden input-længden bag dem.
Context forbruger også hukommelse, og hukommelse er den bindende begrænsning under generering. KV-cachen holder keys og values for hver token i window'et og vokser med context-længden - for en stor dense-model kan den nå titals gigabyte ved en context på 128K. At læse den cache plus modellens vægte tilbage for hver genereret token er et memory-bandbredde-problem, ikke et compute-problem - derfor er det ved lang context, at GPU-udnyttelsen typisk kollapser, og hvor hukommelses-centreret hardware hjælper mest. Metoder som PagedAttention forvalter cachen mere effektivt for at hæve, hvor mange long-context-forespørgsler et system kan betjene på én gang.
Læs context-påstande kritisk
Et stort annonceret Context Window betyder ikke, at en model bruger det hele godt - eller hurtigt. To udbydere, der betjener den samme model med det samme nominelle window, kan afvige skarpt i, hvor hurtigt de prefiller en lang prompt, og hvor elegant de degraderer under belastning - forskelle, som et overskrifts-tal skjuler. Når context betyder noget for dit workload, så sammenlign prefill-tid ved din reelle input-længde og vedvarende output-hastighed, ikke kun det maksimale window. På vores EU-infrastruktur kører prefill på dataflow-hardware designet til at holde data on-chip, hvilket forkorter den ventetid, en lang prompt påfører, før den første token dukker op.
Kilder
Relaterede begreber
Prefill vs. Decode
LLM-inferencens to faser - parallel prompt-behandling vs. token-for-token-generering.
TTFT (Time to First Token)
Hvor længe en bruger venter mellem at sende en forespørgsel og se den første token af svaret.
Tokens per sekund
Standardenheden for LLM-genereringshastighed - og hvorfor det samme tal kan betyde to forskellige ting.
Se disse metrikker målt live på vores EU-infrastruktur - reelle tal fra produktionshardware, uafhængigt verificeret.