Ett modellkort kan ange 32 000, 64 000 eller fler token, men den siffran berättar inte om din dator kan köra fönstret helt på GPU eller hur länge din verkliga prompt tar. Ollamas dokumentation om kontextlängd säger uttryckligen att större kontext ökar minnesbehovet och rekommenderar att processoruppdelningen kontrolleras med ollama ps. Gör därför num_ctx till ett lokalt hårdvaruprov: samma modell, samma prompt och samma svarskrav vid flera uttryckliga värden.
Välj den största provade kontext som fortfarande får plats inom ditt RAM- och VRAM-tak, behåller den processorplacering du kräver och klarar ditt tidstak i tre likadana körningar. Nästa större värde är inte bättre om det flyttar arbete till CPU eller gör väntan opraktisk.
Tre olika gränser måste hållas isär
Den första gränsen finns i modellen. Ollamas endpoint /api/show returnerar modellens detaljer, kvantisering och ett objekt med modellmetadata. I dokumentationens exempel heter kontextfältet gemma4.context_length; på en annan arkitektur får det ett annat prefix. Leta därför efter en nyckel som slutar på .context_length i din egen respons. Det är kandidatens tak, inte ett löfte om att taket är praktiskt på din dator.
curl http://localhost:11434/api/show -d '{
"model": "DIN-MODELL:DIN-TAGG"
}'Den andra gränsen är den kontext Ollama faktiskt har tilldelat den laddade modellen. Den syns efter ett anrop i kolumnen CONTEXT från ollama ps. Den tredje är din egen: hur många GiB RAM och VRAM du vill tillåta, hur lång promptbehandling du accepterar och om modellen måste ligga helt på GPU. Artikeln om minnesbudget för lokal AI äger den breda dimensioneringen; här fyller du bara i två tak för den dator som redan står framför dig.
Modell och exakt tagg: ____________________
Kvantisering: ____________________
Modellens context_length: ____________________ token
Tillgängligt RAM: ______ GiB högsta tillåtna användning: ______ GiB
Tillgängligt VRAM: _____ GiB högsta tillåtna användning: ______ GiB
Krav på PROCESSOR: 100% GPU / delning tillåten
Högsta median för total_duration: ______ sekunderOllamas aktuella dokumentation, kontrollerad 1 september 2026, använder VRAM-baserade förval: 4k under 24 GiB, 32k mellan 24 och 48 GiB och 256k från 48 GiB. Den rekommenderar dessutom minst 64 000 token för webbsökning, agenter och kodverktyg. Se nivåerna som produktens startpunkter, inte som facit. Ett 64k-fönster som tvingar din modell till en långsam delning är inte ett användbart 64k-fönster för just din burk.
Välj en stege och frys resten
Börja på det minsta värde som rymmer din verkliga testtext och svaret du beställer. Om allt ryms vid 4 096 token kan en enkel stege vara 4 096, 8 192, 16 384 och 32 768. Behöver din arbetslast redan mer börjar du högre. Stanna före modellens redovisade max och före värden du inte planerar att använda. Fyra relevanta punkter är bättre än tio tomma extrempunkter.
Testtexten ska vara densamma i varje läge och rymmas i den minsta kandidaten. Använd gärna ett representativt dokument från ditt eget arbetsflöde, men inte känsligt material om du samtidigt kör andra klienter mot servern. Prompten ska också beställa något som går att kontrollera. Exemplet nedan beställer exakt fem punkter, hämtade ur underlaget och begränsade till 20 ord. Poängkriteriet blir då exakt samma tre krav.
Frys modelltagg, kvantisering, prompt, systemprompt, seed, temperatur och tokenbudget. Byt inte Q4 mot Q5 för att få ett större fönster att passa; då har du ändrat två resursvariabler. Om kvantiseringen behöver prövas är det ett separat test enligt jämförelsen av Q4, Q5 och Q8.
Två provfiler som skiljer sig på ett värde
Spara den första nyttolasten som ctx-4096.json och den andra som ctx-8192.json. Omslutning, namn och alla andra värden är identiska; bara num_ctx skiljer dem åt. Ersätt modellnamnet och testtexten före båda körningarna.
{
"model": "DIN-MODELL:DIN-TAGG",
"prompt": "Läs underlaget och ange exakt fem risker. Varje punkt ska stödjas av underlaget och innehålla högst 20 ord. UNDERLAG: DIN FRYSTA TESTTEXT",
"stream": false,
"keep_alive": "10m",
"options": {
"num_ctx": 4096,
"seed": 42,
"temperature": 0,
"num_predict": 180
}
}{
"model": "DIN-MODELL:DIN-TAGG",
"prompt": "Läs underlaget och ange exakt fem risker. Varje punkt ska stödjas av underlaget och innehålla högst 20 ord. UNDERLAG: DIN FRYSTA TESTTEXT",
"stream": false,
"keep_alive": "10m",
"options": {
"num_ctx": 8192,
"seed": 42,
"temperature": 0,
"num_predict": 180
}
}Skapa motsvarande filer för 16 384 och 32 768 om de ingår i din stege. Kör varje ny konfiguration en gång som uppvärmning. Direkt efter uppvärmningen kör du ollama ps och antecknar SIZE, PROCESSOR och CONTEXT. Om CONTEXT inte visar värdet du avsåg har du ännu inte mätt rätt läge.
curl http://localhost:11434/api/generate \
-H "Content-Type: application/json" \
--data-binary @ctx-4096.json
ollama psLäs samtidigt av RAM- och VRAM-toppen i det systemverktyg du normalt använder. Ollamas maskinläsbara /api/ps returnerar också laddad totalstorlek, VRAM-del och kontextlängd, men den ersätter inte hela datorns minnesmätning. Det viktiga är att använda samma mätare vid varje steg.
Kör tre mätningar i varje varmt läge
När rätt kontext syns i ollama ps kör du samma fil tre gånger och sparar varje JSON-svar. Uppvärmningssvaret räknas inte. Byt sedan kontext, värm den nya konfigurationen och upprepa. Om du vill vara säker på att föregående laddning inte ligger kvar kan du lasta ur modellen mellan lägena; den separata artikeln om keep-alive visar både kontrollen och urlastningen.
curl http://localhost:11434/api/generate -H "Content-Type: application/json" --data-binary @ctx-4096.json > svar-4096-1.json
curl http://localhost:11434/api/generate -H "Content-Type: application/json" --data-binary @ctx-4096.json > svar-4096-2.json
curl http://localhost:11434/api/generate -H "Content-Type: application/json" --data-binary @ctx-4096.json > svar-4096-3.jsonOllamas API-dokumentation för användningsmått anger att alla tidsfält är nanosekunder. Dividera total_duration och prompt_eval_duration med 1 000 000 000 för sekunder. prompt_eval_count visar hur många inputtoken som behandlades. Om det värdet ändras mellan kontextlägena trots samma prompt ska du inte tolka tidsjämförelsen förrän du har förklarat varför.
Ta medianen av tre total_duration-värden som ditt praktiska tidsmått. Anteckna också medianen för prompt_eval_duration; den visar om promptbehandlingen är den del som växer. Den fulla uppdelningen mellan laddning, prompt och generering finns i mätguiden för kallstart i Ollama. Här räcker fälten för att upptäcka när ett större fönster passerar din gräns.
Fyll tabellen innan du väljer num_ctx
| num_ctx | CONTEXT | PROCESSOR | Topp RAM/VRAM | Median total | Median prompt | Godkända svar |
|---|---|---|---|---|---|---|
| 4 096 | ___ | ___ | ___ / ___ GiB | ___ s | ___ s | ___ av 3 |
| 8 192 | ___ | ___ | ___ / ___ GiB | ___ s | ___ s | ___ av 3 |
| 16 384 | ___ | ___ | ___ / ___ GiB | ___ s | ___ s | ___ av 3 |
| 32 768 | ___ | ___ | ___ / ___ GiB | ___ s | ___ s | ___ av 3 |
Ett svar godkänns bara om det innehåller exakt fem punkter, varje punkt stöds av testtexten och ingen punkt överskrider 20 ord. Det är inte ett allmänt kvalitetstest; det är en spärr som visar att det större fönstret fortfarande levererar samma beställda uppgift. Om modellen börjar hoppa över underlag eller bryta formatet ska den raden inte vinna bara för att tiden är låg.
Välj den sista gröna raden, inte den största siffran
Markera en rad grön först när fyra villkor är uppfyllda: rätt CONTEXT visas, PROCESSOR uppfyller ditt förhandskrav, RAM och VRAM ligger under dina två tak och medianen för total tid ligger under ditt tidstak. Alla tre svar ska dessutom klara de fem punkternas kriterium. Den största gröna raden är din praktiska num_ctx för den här modellen och arbetslasten.
Om 16 384 är helt på GPU men 32 768 blir delad mellan GPU och CPU har du hittat en placeringsgräns, inte bevisat att datorn är trasig. Accepterar du delningen och tiden fortfarande klarar ditt krav kan 32 768 vara användbart. Kräver du snabb interaktion väljer du 16 384. Skriv ned beslutet tillsammans med Ollama-version, modelltagg och kvantisering så att nästa uppgradering kan provas mot samma grundläge.
Om ingen rad klarar kraven börjar du inte med att höja fönstret igen. Sänk kandidaten eller gör ett nytt, separat prov med en mindre modell eller annan kvantisering. Om alla rader klarar kraven och du faktiskt behöver mer kontext lägger du till nästa steg under modellens redovisade gräns. Tabellen avgör när du ska stanna; modellkortets maxvärde avgör bara hur långt du får fortsätta leta.
Vad resultatet gäller
Gränsen gäller den exakta modellen, kvantiseringen, Ollama-versionen, prompttypen och datorn du provade. Den är inte en generell rekommendation för andra modeller med samma parameterstorlek. KV-cache, modellarkitektur och processorplacering kan skilja även när två modellfiler ser lika stora ut. Publicera därför inte bara siffran ”32k fungerar”; publicera raden som visar vad den kostade och vilket krav den klarade.
Provet visar också en viktig skillnad mellan kapacitet och behov. Ett stort fönster har inget egenvärde om din faktiska arbetslast ryms i ett mindre. Behåll därför inte den största gröna raden som global vana. Sätt den för den modell och klient där den behövs, och kör om provet när du byter modelltagg, kvantisering, Ollama-version eller hårdvara.
Källor
- Ollama – Context length: definition, aktuella VRAM-baserade förval, minneskostnad och kontroll med
ollama ps - Ollama – Show model details: modellmetadata, kvantisering, parametrar och modellens redovisade kontextlängd
- Ollama – Generate a response:
stream,keep_alive,optionsoch svarsfälten - Ollama – Usage: tidsfältens innebörd, tokenräknare och nanosekunder som enhet
- Ollama – List running models: laddad storlek, VRAM-del och tilldelad kontext i API-svaret
Källorna kontrollerades 1 september 2026. Ingen egen Ollama-installation eller benchmark ligger bakom artikeln och inga minnes- eller tidsvärden presenteras som uppmätta resultat. Förvalen på Ollamas kontextsida är daterade produktuppgifter och kan ändras; provet bygger därför på vad din egen installation visar.