Ollama num_ctx: Paano Itakda ang Context Length

Ano ang ginagawa ng num_ctx, at bakit naputol ang mahaba mong prompt

Ang context length ng Ollama ay ang bilang ng tokens na kayang panatilihin ng loaded model sa memory nang sabay-sabay, at num_ctx ang option na nagse-set nito. Pumipili ang Ollama ng default na mas mababa kaysa sa maximum na idinedeklara ng model, kaya napuputol ang mas mahabang prompt bago pa man ito mabasa ng model. Walang ipinapakita sa response na nagsasabing nangyari ito.

Nakalista ang Llama 3.1 8B na may 128k context window sa Ollama model library. Hindi ito ang ibinibigay ng isang stock server. Magkakaiba ang default na nakasaad sa sariling documentation ng Ollama sa iba’t ibang page: sinasabi ng FAQ na 4096 tokens, sinasabi sa Modelfile reference na ang default ng num_ctx ay 2048, at sinasabi sa context length page na pinipili ang default batay sa available VRAM (video RAM): 4k kapag mas mababa sa 24 GiB, 32k mula 24 hanggang 48 GiB, at 256k kapag higit dito. May mga build na gumamit ng bawat isa sa mga halagang ito. Iyan ang mahalagang aral: basahin ang value mula sa sarili mong running server sa halip na umasa sa kahit anong page, kabilang na ang page na ito.

Tahimik ang truncation dahil sumasagot pa rin ang model, at maayos pa ring basahin ang sagot. Isinulat ito batay sa hulihan ng input mo. Ang summary na hindi kasama ang unang kalahati ng dokumento ay maaaring magmukhang resulta ng mahinang model. Karaniwan, maliit ang context window nito.

Suriin ang aktuwal na context length na inilapat ng Ollama sa server

Ang check na gumagana sa anumang build ay prompt_eval_count, ang bilang ng prompt tokens na iniulat ng server na naproseso nito. Magpadala ng mas maraming token kaysa sa kayang hawakan ng context. Hihinto ang bilang na iyon sa limit.

sudo apt update && sudo apt install -y jq
LONG=$(python3 -c "print('the quick brown fox jumps over the lazy dog. ' * 2000)")
jq -n --arg p "$LONG" '{model:"llama3.1:8b", prompt:$p, stream:false, options:{num_ctx:4096}}' |
  curl -s http://localhost:11434/api/generate -d @- |
  jq '{prompt_eval_count, prompt_eval_duration}'

Humigit-kumulang 18,000 salita ang prompt na iyon, kaya higit na mas marami ito kaysa sa 4096 tokens. Bumabalik ang prompt_eval_count na malapit sa 4096 sa halip na malapit sa aktuwal na bilang ng token dahil itinapon ng server ang natitirang bahagi. Patakbuhin itong muli gamit ang "num_ctx":16384 at tataas ang bilang. Kung nagbabalik ng error ang iyong build sa halip na mag-truncate, pareho ang ipinapakitang resulta ngunit mas malinaw ang signal.

ollama ps

Ang column na CONTEXT, sa mga build na nagpi-print nito, ay naglalaman ng context length na ginagamit ngayon ng loaded model. Ipinapakita ng katabing column na PROCESSOR kung saan tumatakbo ang model. Normal ang 100% CPU sa VPS na walang GPU. Ang split na gaya ng 30%/70% CPU/GPU sa isang GPU box ay nangangahulugang hindi na kasya sa VRAM ang weights at cache. Karaniwang dahilan nito ang mas mataas na num_ctx.

journalctl -u ollama --no-pager | grep -i n_ctx | tail -n 5

Ini-print ng inference runner ang context size sa isang line na naglalaman ng n_ctx. Nagbabago ang eksaktong wording sa bawat release, kaya ituring ang nawawalang line bilang pagbabago ng pangalan, hindi bilang patunay ng anuman.

Apat na lugar kung saan itinatakda ang num_ctx

Sa request. Ipadala ang "options": {"num_ctx": 16384} sa /api/generate o /api/chat. Ito ang nangingibabaw sa lahat ng ibang setting, at nalalapat lamang sa isang call na iyon. Kung iba ang value sa ginagamit ng naka-load na model, ire-reload muna ng server ang model. Makikita ito sa load_duration sa response: mula sa halos zero ay tataas ito sa ilang buong segundo.

Sa interactive session. Sa loob ng ollama run, i-type ang /set parameter num_ctx 16384. Tatagal ito para sa session na iyon.

Sa Modelfile. Isinasama nito ang value sa isang named model, kaya matatanggap ito ng bawat client nang walang pagbabago sa panig ng client.

FROM llama3.1:8b
PARAMETER num_ctx 16384

ollama create llama3.1-16k -f ./Modelfile
ollama run llama3.1-16k

Sa server. Itinatakda ng OLLAMA_CONTEXT_LENGTH ang default para sa bawat request na walang sariling num_ctx. Sa ilalim ng systemd, magdagdag ng drop-in sa halip na i-edit ang unit file.

sudo systemctl edit ollama.service

[Service]
Environment="OLLAMA_CONTEXT_LENGTH=16384"

sudo systemctl daemon-reload
sudo systemctl restart ollama
ollama ps

Pinakamahalaga ang precedence kapag nagde-debug ka ng client ng ibang tao. Nangungibabaw ang request na may num_ctx sa server default, kaya maaaring tahimik na ma-override ng chat front end o agent na nagpapadala ng sarili nitong maliit na value ang pagbabago mo sa systemd. Kapag itinuro mo ang isang coding agent sa iyong Ollama server, tingnan muna kung ano ang ipinapadala ng client bago sisihin ang server.

Bakit hindi puwedeng itakda na lang ang num_ctx sa maximum ng model

Pinapatingin ng attention ang bawat token sa lahat ng naunang token. Iniimbak ang keys at values na nakuwenta para sa mga naunang token upang hindi na muling kalkulahin sa bawat bagong token. Ang imbakan na ito ang KV cache (key/value cache). Inilalaan ito para sa buong num_ctx kapag nilo-load ang model, hindi habang lumalaki ang conversation. Kaya may memory cost ang malaking context kahit isang linya lang ang prompt.

Inilalahad ng tutorial ng DigitalOcean tungkol sa inference cost ang computation sa isang linya:

kv_bytes_per_token = 2 * layers * kv_heads * head_dim * bytes_per_value

Magkahiwalay na binibilang ng 2 ang keys at values. Kunin ang iba pang numero mula sa sarili mong model.

curl -s http://localhost:11434/api/show -d '{"model":"llama3.1:8b"}' |
  jq '.model_info | {ctx: ."llama.context_length", layers: ."llama.block_count", heads: ."llama.attention.head_count", kv_heads: ."llama.attention.head_count_kv", embed: ."llama.embedding_length"}'

May 32 layers at 8 key/value heads ang Llama 3.1 8B. Ang head dimension ay embed na hinati sa heads, kaya 4096 / 32 = 128 dito. Direktang inilalathala ito ng ilang model bilang llama.attention.key_length. Naglalaman ang default cache ng mga f16 value, kaya bytes_per_value ay 2. Ang 2 32 8 128 2 ay katumbas ng 131,072 bytes. Ibig sabihin, 128 KiB ang cache para sa bawat token ng context. Kapag minultiply sa context length, nagiging aktuwal na memory cost na ito.

[
  {
    "label": "4k",
    "kv_cache_gib": 0.5,
    "total_ram_gib": 5.1
  },
  {
    "label": "8k",
    "kv_cache_gib": 1,
    "total_ram_gib": 5.6
  },
  {
    "label": "16k",
    "kv_cache_gib": 2,
    "total_ram_gib": 6.6
  },
  {
    "label": "32k",
    "kv_cache_gib": 4,
    "total_ram_gib": 8.6
  },
  {
    "label": "64k",
    "kv_cache_gib": 8,
    "total_ram_gib": 12.6
  },
  {
    "label": "128k",
    "kv_cache_gib": 16,
    "total_ram_gib": 20.6
  }
]

Ang 6 row na iyon ay resulta ng arithmetic mula sa formula sa itaas, hindi mga measurement. Idinadagdag ng total column ang 4.9 GB na download na inilista ng Ollama library para sa llama3.1:8b noong August 2026, na katumbas ng 4.6 GiB. Hindi nito kasama ang compute buffers at ang server process mismo. Ituring ito bilang minimum na estimate.

Ang mahalaga ay ang pattern. Sa 8k, 1 GiB ang cost ng cache, na maliit kumpara sa weights. Sa buong 128k ng model, 16 GiB ang cost nito, mahigit tatlong beses sa weights, kaya halos 20.6 GiB ang total. Kaya hindi mai-load ng 4 GB VPS ang model na ito sa anumang kapaki-pakinabang na context. Sapat ang 8 GB VPS para sa 8k. Umaabot ang 16 GB VPS sa 32k at may natitirang memory para sa iba pang bahagi ng server. Tumataas ang bawat threshold na ito habang lumalaki ang weights. Kung ikinukumpara mo ang mas malaking model sa 8B na ito, ipinapakita ng parehong computations para sa 27B tag ng Qwen sa CPU-only VPS kung gaano kaliit ang natitirang memory para sa context sa pagitan ng 8 at 64 GB.

Ano ang nangyayari kapag hindi kasya ang KV cache

Sa CPU-only VPS, patuloy lang na lalaki ang process. I-monitor ito habang nilo-load ang model at habang may matagal na request na tumatakbo.

free -m
ps -eo rss,comm --sort=-rss | head -n 5

Ang RSS (resident set size) ay ipinapakita sa kilobytes. Kung nagsisimulang tumaas ang ginamit na swap sa free -m, bawasan ang context. Kapag nasa swap ang KV cache, tumitigil ang generation nang ilang segundo bawat token dahil kailangang basahin ng bawat bagong token ang buong cache.

Kung tuluyang maubusan ng memory ang box, pipili ang kernel ng pinakamalaking process at papatayin ito.

sudo dmesg | grep -i "killed process"

Ang linyang may Out of memory: Killed process 1234 (ollama) ay nangangahulugang hindi kasya ang context na hiniling mo. Madalas itong tinatanggihan ng Ollama bago pa umabot sa puntong iyon, at mabibigo ang request na may mensaheng nagsasaad ng memory na kailangan nito kumpara sa memory na available.

Sa GPU box, mas tahimik ang failure. Napupunta ang ilang layer sa system RAM, ipinapakita ng ollama ps ang paghahati sa pagitan ng CPU at GPU, at malaki ang ibinababa ng throughput. Depende sa hardware mo kung gaano kalaki ang ibababa nito, kaya sukatin ang tokens per second sa sarili mong box sa bawat context setting sa halip na umasa sa figure mula sa ibang machine.

Mas mabilis lumalaki ang prefill time kaysa sa prompt

Ang prefill ay ang pagproseso sa input bago lumabas ang unang output token. Dumadalo ang bawat prompt token sa lahat ng token na nauuna rito, kaya lumalaki ang kabuuang workload kasabay ng square ng haba ng input. Kapag dinoble ang prompt, higit sa doble ang paghihintay bago lumabas ang unang token.

Nasa response ang measurement, kaya hindi mo kailangang basta tanggapin ang resultang iyon.

jq -n --arg p "$LONG" '{model:"llama3.1:8b", prompt:$p, stream:false, options:{num_ctx:16384}}' |
  curl -s http://localhost:11434/api/generate -d @- |
  jq '{tokens: .prompt_eval_count, prefill_seconds: (.prompt_eval_duration/1000000000)}'

Patakbuhin ito gamit ang maikling prompt, pagkatapos ay ulitin gamit ang mahabang prompt. Hatiin ang bilang ng tokens sa bilang ng segundo sa bawat kaso. Sa CPU-only VPS, karaniwang pinakamabagal na bahagi ng long-context request ang prefill. Hindi mahuhulaan ng tokens per second na nakuha mula sa maikling prompt ang performance nito.

Pinakamalaki ang epekto nito kapag may concurrency. Kailangan ng bawat sine-serve na request ng sarili nitong cache, kaya ang memory sa chart sa itaas ay para sa bawat request, hindi para sa buong server. Maaaring ma-hold ng isang mahabang request ang server habang nakapila sa likod nito ang mga maikling request. Itakda nang sinadya ang OLLAMA_NUM_PARALLEL, at basahin ang kung ilang concurrent user ang kayang i-serve ng isang self-hosted LLM bago mo sabay na taasan ang dalawang value.

Muling makakuha ng context gamit ang mas maliit na cache

Ang bytes_per_value sa formula ay setting na ikaw ang kumokontrol. Idinodokumento ng Ollama FAQ ang OLLAMA_KV_CACHE_TYPE, na may f16 bilang default na 2 bytes, kasama ang q8_0 na 1 byte at ang q4_0 na mas mababa pa rito. Kapag lumipat sa q8_0, kalahati ang laki ng cache, kaya ang 32k row ay kumokonsumo ng 2 GiB sa halip na 4 GiB. Idinodokumento rin ng parehong FAQ ang OLLAMA_FLASH_ATTENTION=1, na kinakailangan ng ilang build bago maging epektibo ang quantised cache.

[Service]
Environment="OLLAMA_FLASH_ATTENTION=1"
Environment="OLLAMA_KV_CACHE_TYPE=q8_0"

Mag-confirm sa aktuwal na pagsubok at huwag umasa sa palagay: i-restart ang service, i-load ang model sa kaparehong num_ctx gaya ng dati, at ikumpara ang RSS. Nakadepende ang support sa model at backend, kaya kung walang nabago ang setting, hindi saklaw ng kombinasyon mo ang setting na iyon. Inililista ng documentation ang mga option na ito nang walang garantiya sa kalidad ng resulta, kaya subukan ang q4_0 gamit ang sarili mong prompt bago mo ito asahan sa production. Kung ang mga knob na ito ang dahilan ng paghahanap mo rito, magkaiba ang paraan ng paglalantad ng mga ito sa Ollama at llama.cpp.

Isang recipe para sa pagpili ng num_ctx

1. Basahin mula sa /api/show ang maximum context ng model, bilang ng mga layer nito, at bilang ng key/value head nito.
2. Kalkulahin ang bytes bawat token gamit ang formula, pagkatapos ay i-multiply ito sa context na gusto mo.
3. Idagdag ang weight size, ikumpara sa available na RAM, at maglaan ng hindi bababa sa 1 GiB para sa iba pang proseso ng server.
4. Itakda ang value, i-load ang model, pagkatapos ay kumpirmahin ang na-apply gamit ang ollama ps at prompt_eval_count.
5. Patakbuhin ang aktuwal mong workload habang mino-monitor ang free -m, at hatiin sa dalawa ang context kapag nagsimulang gumamit ng swap.

Karamihan ng mga job ay nangangailangan ng mas maliit na context kaysa sa karaniwang itinatalaga. Sapat na ang 16k para sa pagbuod ng mahabang report. Ang retrieval front end na naglalagay ng limang document chunk ay bihirang lumampas sa 8k. Ang coding agent na nagbabasa ng buong file ang sitwasyong talagang nangangailangan ng 64k o higit pa. Ito rin ang sitwasyong dapat pagbatayan ng laki ng machine ang context, hindi ang kabaligtaran. Kung bago pa ang server mismo, magsimula sa gumaganang Ollama install sa isang VPS at i-tune ang context kapag maayos nang naglo-load ang mga model.

FAQ

Ano ang default na context length sa Ollama?

Depende ito sa build at hardware, kaya suriin muna sa halip na manghula. Nakasaad sa FAQ ng Ollama ang 4096 tokens, habang nasa Modelfile reference ang default na num_ctx na 2048. Sa context length page naman, ang default ay pinipili batay sa available na VRAM: 4k kung mas mababa sa 24 GiB, 32k mula 24 hanggang 48 GiB, at 256k kung higit sa 48 GiB. Ang CPU-only VPS ay nasa mas mababang bahagi nito. Ipinapakita ng ollama ps ang aktuwal na context sa mga build na may ganitong column, at pinatutunayan ng prompt_eval_count sa isang API response ang halaga nito sa lahat ng build.

Bakit binabalewala ng Ollama ang simula ng mahaba kong prompt?

Dahil mas mahaba ang prompt kaysa sa context window, kaya pinutol ito ng server bago ito makita ng model, at walang error na ibinalik. Ipadala muli ang parehong prompt gamit ang mas malaking num_ctx at obserbahan kung lumalaki ang prompt_eval_count sa response. Kung hindi nagbabago ang numerong iyon, may bahagi sa pagitan mo at ng server na mismong nagse-set ng num_ctx. Karaniwan ito sa chat front end at agent framework.

Gaano karaming dagdag na RAM ang kailangan ng mas malaking num_ctx?

I-multiply ang context length sa cache cost bawat token, na 2 * layers * kv_heads * head_dim * bytes_per_value. Para sa Llama 3.1 8B sa f16, 128 KiB bawat token ito. Kaya ang 32k tokens ay kumokonsumo ng 4 GiB, at ang buong 128k ay kumokonsumo ng 16 GiB bukod pa sa memory ng weights. Inilalaan ang cache kapag naglo-load ang model, kaya gagamit ang malaking num_ctx ng ganoong memory kahit maikli lang ang mga prompt mo.

Pinapabagal ba ng mas malaking context window ang Ollama?

Oo, sa dalawang paraan. Lumalaki nang ayon sa square ng haba ng prompt ang prefill work, kaya mas matagal bago lumabas ang unang token para sa mahabang input kaysa sa ipinahihiwatig ng haba nito. Nakikipag-agawan din sa memory ang mas malaking cache: sa GPU machine, maaari nitong itulak ang ilang layer sa system RAM; sa CPU machine naman, maaari nitong itulak ang machine na gumamit ng swap. Ang malaking num_ctx na hindi mo naman napupuno ay gumagamit pa rin ng memory, kahit hindi nito pinahahaba ang prefill time.

Maaari ko bang permanenteng i-set ang num_ctx para sa isang model?

Oo. Gumawa ng Modelfile na naglalaman ng FROM llama3.1:8b at PARAMETER num_ctx 16384, pagkatapos ay patakbuhin ang ollama create llama3.1-16k -f ./Modelfile. Bawat client na humihingi ng llama3.1-16k ay gagamit ng context na iyon nang hindi nagpapadala ng anumang option. Mananatiling mas mataas ang priyoridad ng request na may sarili nitong num_ctx, kaya nagtatakda ito ng default at hindi ng ceiling.