Vad är ett kontextfönster, och vad är en token?

Två siffror som avgör vad du kan skicka

Lång kontext, 200k kontext och token är tre sätt att ställa en fråga, så det är värt att skilja på de två kvantiteterna bakom dem. En token är den enhet en modell läser och skriver. Ett kontextfönster är hur många av dessa enheter som får plats i ett anrop. Båda registreras på varje modellkort här, och båda är påtvingade snarare än annonserade: routingmotorn avvisar en modell vars dokumenterade fönster är mindre än din uppskattade indata plus din utdatabudget, och registrerar orsaken.

Vad en token är

Modeller ser inte tecken eller ord. Text delas upp i tokens, och en token är ungefär ett ordfragment: vanliga korta ord är oftast en token, långa eller sällsynta ord och sammansättningar delas upp i flera. Interpunktion och blanksteg fäster vid närliggande tokens. Ett tyskt sammansatt substantiv är typiskt två eller tre tokens där dess engelska motsvarighet är en, vilket är den praktiska anledningen till att ett dokument på ett språk kan kosta märkbart mer att bearbeta än samma dokument på ett annat.

Uppskattningen som används här är medvetet grov och dokumenterad: cirka fyra tecken per token för latinskt skrift, avrundat uppåt. Avrundning uppåt är den säkra riktningen, eftersom det gör kontextkontrollen strängare snarare än mer tillåtande. En bild uppskattas till 850 tokens per bilddel, plus ett litet kuvert för varje meddelande. Inget av detta är en tokenisermätning; det är en budget som routern använder för att neka en begäran som inte skulle passa.

Vad fönstret är, och vad det inte är

Fönstret räknar allt i anropet tillsammans: systemmeddelandet, varje meddelande hittills, eventuella passager som din applikation hämtade, verktygsdefinitionerna och de tokens som modellen får skriva tillbaka. Indata och utdata delar det. En modell som svarar bra inom ett 32k-fönster får inte tyst kapacitet när du skickar 40k; begäran måste anpassas för att passa.

Publicerade fönster här skiljer sig åt med storleksordningar. EuroLLM 9B, EuroLLM 22B och Mistral 7B Instruct v0.3 registrerar 32 768 tokens. Pharia-1-LLM-7B-control-aligned registrerar 8 192 och Teuken 7B Instruct v0.6 registrerar 4 096. Mistral Small 4, Mistral Large 3, Gemma 4 31B och NVIDIA Nemotron 3 Super registrerar 262 144. Llama 3.1 8B Instruct, Llama 3.3 70B Instruct, Command A+ och Command R (08-2024) registrerar cirka 128k. Llama 4 Scout 17B-16E Instruct är listad med 10 485 760 tokens, leverantörspublicerad. Två egenheter hör hemma på kortet snarare än i en sammanfattning: Command A+ dokumenterar 128K indata och 64K utdata medan dess konfiguration tillåter 200 000 positioner, och Nemotron 3 Super annonserar kontext upp till en miljon tokens medan dess konfiguration tillåter 262 144, med leverantörsrapporterade RULER-poäng på 96.30 vid 256k och 91.75 vid en miljon. Där ett kort anger ett värde och en konfigurationsfil ett annat, registreras båda.

Små fönster har inte heller försvunnit: EuroLLM 1.7B Instruct registrerar 4 096 tokens, en eller två sidor text snarare än en uppsättning dokument.

Varför "200k kontext" behöver en andra fråga

Ett långt fönster är en kapacitet, inte ett kvalitetslöfte. Frågan som spelar roll är vad modellen fortfarande gör i den bortre änden. Leverantörer publicerar sällan hämtningskvalitet per språk över ett fönster, och när de publicerar ett nummer är det vanligtvis ett långkontext-riktmärke kört med deras egen sele, vilket är anledningen till att korten märker dessa siffror som leverantörsrapporterade. En RULER-poäng säger att modellen hittade något i en lång indata under ett specifikt test; den säger inte att en fransk klausul på sida 400 i ett tyskt kontrakt kommer att hanteras lika tillförlitligt som en på sida 1.

Den andra frågan är kostnad. Indatatokens faktureras oavsett om de var användbara, och en pipeline som skickar om ett stort fönster vid varje tur växer linjärt med konversationen. Lång kontext är genuint billigare när den ersätter en hämtningspipeline, och genuint dyrare när den bara ersätter chunking du redan hade.

Den tredje är fällan som hämtningsguiden nämner: den minsta gränsen i kedjan styr. Bädda in med en modell vars kort använder en maximal sekvenslängd på 512 tokens och en 900-tokens chunk trunkeras under inbäddning, tyst, oavsett hur stort generatorns fönster är. Ställ in chunklängden från inbäddningsmodellen, inte generatorn.

Hur fönstret verkställs på en begäran

Indatatokens uppskattas, din maximala utdatabudget läggs till, och varje kandidat vars dokumenterade fönster är mindre än den totalen avvisas med en registrerad anledning som nämner fönstret och kravet. Den kontrollen sitter efter residens- och modalitetsfiltren och före pristaket, så en modell kan vara helt tillåten enligt policy och ändå tas bort för att vara för liten.

Avvisningar är synliga. Ruttorsaken räknar hur många slutpunkter som exkluderades och spårningen behåller de per-slutpunkt-orsakerna. Om en begäran misslyckas eftersom inget överlevde, namnger svaret vad som ska ändras snarare än att tyst försöka igen med en kortare prompt; att förkorta indata är ditt beslut att fatta, inte routerns.

Praktiska regler som gäller

Skicka vad uppgiften behöver och inget annat. Ett 262k-fönster är inte en anledning att skicka en kodbas; det är en anledning till att ett sammanfattningsjobb kan hålla en hel rapport i ett enda pass. Håll instruktionen och materialet nära varandra snarare än att begrava frågan under fyrtio sidor kontext, eftersom uppmärksamhet över en lång indata inte är enhetlig i praktiken.

Budgetera utdata explicit. Utdatatokens faktureras som alla andra tokens, och ett resonemangsläge som producerar långt mellanliggande arbete faktureras på samma sätt, som flera uppgiftsanteckningar här påpekar.

För långa dokument, bestäm medvetet mellan ett långt anrop och en kedja av korta. Ett anrop håller dokumentet helt och kostar indatatokens en gång; en kedja låter dig kontrollera mellanresultat och håller varje steg litet. Inget är universellt rätt.

Slutligen, mät med ditt eget material. Ett publicerat kontextfönster är en dokumenterad kapacitet, ett annonserat maximum är leverantörens påstående med en källa, och ett riktmärke på ditt språk på dina dokument är den enda siffran som talar om din arbetsbelastning. Denna katalog tillämpar samma regel på sig själv: varje nummer bär sin källa, och ett värde som ingen angav registreras som okänt snarare än gissat.