Ollama num_ctx: Ayusin ang Context Length

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

Ang Ollama context length ay bilang ng mga token na kayang hawakan ng naka-load na model sa memory nang sabay-sabay, at ang num_ctx ang option na nagse-set nito. Pumipili ang Ollama ng default na mas mababa kaysa sa maximum context na ina-advertise ng model, kaya pinuputol 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 iyon ang ibibigay ng stock server. Iba-iba ang default na nakasaad sa sariling documentation ng Ollama depende sa 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 kung mas mababa sa 24 GiB, 32k mula 24 hanggang 48 GiB, at 256k kung higit doon. Totoo ang bawat value para sa ilang build. Iyan ang mahalagang aral: basahin ang value mula sa sarili mong running server sa halip na magtiwala sa kahit anong page, kabilang 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 isang dokumento ay maaaring magmukhang resulta ng mahinang model. Karaniwan, maliit na context window ang dahilan.

Tingnan ang context length ng Ollama na aktuwal na inilapat ng server

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

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 sa 4096 token. Bumabalik ang prompt_eval_count na malapit sa 4096 sa halip na malapit sa aktuwal na bilang ng token dahil itinapon ng server ang natitira. Patakbuhin itong muli gamit ang "num_ctx":16384 at tataas ang bilang. Kung error ang ibinabalik ng build mo sa halip na i-truncate ang input, pareho pa rin ang finding; mas malinaw lang ang signal.

ollama ps

Ang column na CONTEXT, sa mga build na nagpi-print nito, ay naglalaman ng context length na ginagamit ngayon ng naka-load na model. Ipinapakita naman ng column na PROCESSOR sa tabi nito kung saan nakalagay ang model. Normal ang 100% CPU sa isang 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, at 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 nito sa isang line na naglalaman ng n_ctx. Nagbabago ang eksaktong wording sa bawat release, kaya ituring ang nawawalang line bilang pagpapalit ng pangalan, hindi bilang patunay ng anuman.

Apat na lugar para itakda ang num_ctx

Sa request. Ipadala ang "options": {"num_ctx": 16384} sa /api/generate o /api/chat. Ito ang may pinakamataas na precedence sa lahat ng ibang setting, at nalalapat lamang ito sa isang call. Kung iba ang value nito sa kasalukuyang ginagamit ng loaded 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. Lumilitaw din ang parehong paghihintay kapag matagal nang idle ang model at na-unload na ito. Kaya kapag napili mo na ang context size, mainam na panatilihing resident ang model gamit ang keep_alive.

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

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

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 dini-debug mo ang client ng ibang tao. Nauuna ang request na may num_ctx kaysa sa server default. Dahil dito, 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 modelo

Pinapatingin ng attention ang bawat token sa lahat ng naunang token. Iniingatan ang mga key at value na nakalkula 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 naglo-load ang modelo, hindi habang lumalaki ang conversation, kaya kumokonsumo ng memory ang malaking context kahit isang linya lamang ang prompt.

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

kv_bytes_per_token = 2 * layers * kv_heads * head_dim * bytes_per_value

Hiwalay na binibilang ng 2 ang mga key at value. Kunin ang iba pang numero mula sa sarili mong modelo.

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"}'

Iniuulat ng Llama 3.1 8B ang 32 layer at 8 key/value head. Ang head dimension ay embed na hinati sa heads, kaya 4096 / 32 = 128 dito. Direktang inilalathala ito ng ilang modelo bilang llama.attention.key_length. Naglalaman ang default cache ng mga f16 value, kaya ang bytes_per_value ay 2, at ang 2 32 8 128 2 ay nagiging 131,072 byte. Katumbas ito ng 128 KiB na cache para sa bawat token ng context. Kapag minultiply sa haba ng context, nagiging malinaw ang aktuwal na gastos sa memory.

[
  {
    "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 mga row na iyon na 6 ay kalkulasyon mula sa formula sa itaas, hindi mga sukat. Idinadagdag ng total column ang 4.9 GB na download na inilista ng Ollama library para sa llama3.1:8b noong August 2026. Katumbas ito ng 4.6 GiB. Hindi kasama rito ang compute buffer at ang server process mismo. Ituring itong pinakamababang tantya.

Ang mahalaga ay ang pagbabago ng laki. Sa 8k, nagkakahalaga ang cache ng 1 GiB, na maliit kumpara sa weights. Sa buong 128k ng modelo, nagkakahalaga ito ng 16 GiB—mahigit tatlong beses sa weights—para sa kabuuang humigit-kumulang 20.6 GiB. Kaya hindi mai-load ng 4 GB VPS ang modelong 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 iyon habang lumalaki ang weights. Kaya kung ikinukumpara mo ang mas malaking modelo sa 8B na ito, ipinapakita ng parehong kalkulasyon 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 VPS na CPU-only, patuloy na lumalaki ang process. I-monitor ito habang naglo-load ang model at habang tumatakbo ang mahabang request.

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

Ipinapakita ang RSS (resident set size) sa kilobytes. Kung nagsisimulang tumaas ang ginagamit na swap sa free -m, bawasan ang context. Kapag nasa swap ang KV cache, tumitigil nang ilang segundo ang generation para sa bawat token dahil binabasa ng bawat bagong token ang buong cache.

Kung tuluyang maubusan ng memory ang server, pipiliin ng kernel ang pinakamalaking process at tatapusin ito.

sudo dmesg | grep -i "killed process"

Ang linyang Out of memory: Killed process 1234 (ollama) ay nangangahulugang hindi kasya ang context na hiniling mo. Madalas na tumatanggi ang Ollama bago umabot sa puntong ito. Mabibigo ang request at magpapakita ito ng mensaheng nagsasaad ng memory na kailangan nito kumpara sa memory na available.

Sa GPU server, hindi gaanong lantad ang failure. Napupunta ang ilang layer sa system RAM, ipinapakita ng ollama ps ang hatian sa 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 server sa bawat context setting sa halip na umasa sa figure mula sa machine ng ibang tao.

Mas mabilis lumalaki ang prefill time kaysa sa prompt

Ang prefill ay ang pagproseso sa input bago lumabas ang unang output token. Ang bawat prompt token ay tumitingin sa lahat ng token na nauuna rito, kaya lumalaki ang kabuuang trabaho ayon sa square ng haba ng input. Kapag dinoble ang prompt, higit sa doble ang waiting time bago lumabas ang unang token.

Nasa response ang sukat, kaya hindi mo ito kailangang tanggapin nang walang beripikasyon.

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, at ulitin gamit ang mahabang prompt. Pagkatapos, hatiin ang bilang ng tokens sa bilang ng segundo para sa bawat kaso. Sa CPU-only VPS, karaniwang pinakamabagal na bahagi ng long-context request ang prefill. Hindi nito mahuhulaan ang performance ng prefill para sa mahabang prompt kung ang tokens per second figure ay kinuha lamang mula sa maikling prompt. Kapag mas matagal ang prefill kaysa sa timeout na nasa unahan nito, karaniwang nagbabalik ang long prompt ng lumampas sa deadline ng context sa halip na sagot. Kaya alamin muna kung aling layer ang sumuko bago bawasan ang context.

Dito pinakaramdam ang epekto ng 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 hawakan ng isang mahabang request ang buong server habang nakapila sa likod nito ang maiikling request. Itakda nang sinadya ang OLLAMA_NUM_PARALLEL, at basahin ang kung ilang concurrent user ang kayang pagsilbihan ng isang self-hosted LLM bago mo taasan nang sabay ang dalawang value.

Bumawi ng memory sa pamamagitan ng mas maliit na cache

Ang bytes_per_value sa formula ay isang setting na ikaw ang kumokontrol. Idinodokumento ng Ollama FAQ ang OLLAMA_KV_CACHE_TYPE, kung saan ang default ay f16 na 2 bytes, kasama ang q8_0 na 1 byte at ang q4_0 na mas mababa pa rito. Kapag ginamit ang q8_0, nahahati sa kalahati ang cache, kaya ang 32k row ay nagkakahalaga ng 2 GiB sa halip na 4 GiB. Nagpapalaya ng memory sa kabilang bahagi ng parehong budget ang pag-quantise ng weights, at ang GLM tag na aktuwal na kasya sa isang VPS ay tinatalakay sa bawat antas ng quantisation kung iyon ang trade-off na mas gusto mong gawin. Idinodokumento rin ng parehong FAQ ang OLLAMA_FLASH_ATTENTION=1, na kailangan ng ilang build bago magkabisa ang quantised cache.

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

Huwag magpalagay; kumpirmahin ito: i-restart ang service, i-load ang model sa parehong num_ctx gaya ng dati, at ikumpara ang RSS. Nakadepende ang support sa model at backend, kaya kung walang binabago ang isang setting, hindi saklaw ng iyong kombinasyon ang setting na iyon. Inililista ng documentation ang mga opsyong ito nang walang pangakong magiging maayos ang resulta, kaya subukan ang q4_0 gamit ang sarili mong prompt bago mo ito asahan. Kung ang mga setting na ito ang dahilan kung bakit ka narito, magkaiba ang paraan ng paglalantad sa mga ito ng Ollama at llama.cpp.

Isang gabay 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, at pagkatapos ay i-multiply ito sa context na gusto mo.
3. Idagdag ang laki ng weights, ikumpara ito sa available na RAM, at mag-iwan ng hindi bababa sa 1 GiB para sa iba pang gawain ng server.
4. Itakda ang value, i-load ang model, at kumpirmahin kung ano 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 2 ang context kapag nagsimulang gumamit ng swap.

Karamihan ng mga job ay nangangailangan ng mas maliit na context kaysa sa karaniwang ibinibigay ng mga user. Kasya sa 16k ang pagbubuod 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 talagang nangangailangan ng 64k o higit pa. Sa ganitong sitwasyon, dapat mong i-size ang machine batay sa context, hindi ang context batay sa machine. Kung bago pa ang server, magsimula sa gumaganang Ollama install sa isang VPS at i-tune ang context kapag malinis nang naglo-load ang mga model.

FAQ

Ano ang default na context length sa Ollama?

Depende ito sa build at hardware, kaya suriin ito sa halip na manghula. Nakadokumento sa FAQ ng Ollama ang 4096 tokens, habang nakadokumento sa Modelfile reference ang default na num_ctx na 2048. Nakadokumento naman sa context length page ang default na nakabatay sa available na VRAM: 4k kung mas mababa sa 24 GiB, 32k mula 24 hanggang 48 GiB, at 256k kung higit sa 48 GiB. Karaniwang nasa mas mababang saklaw ang CPU-only VPS. Ipinapakita ng ollama ps ang aktuwal na context sa mga build na may ganitong column, at pinatutunayan ito ng prompt_eval_count sa isang API response sa bawat 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 ibinalik na error. Ipadala muli ang parehong prompt gamit ang mas malaking num_ctx at obserbahan kung tumataas ang prompt_eval_count sa response. Kung hindi nagbabago ang numerong iyon, may nasa pagitan mo at ng server na mismong nagse-set ng num_ctx. Karaniwan ito sa mga 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 ito bawat token. Kaya ang 32k tokens ay kumokonsumo ng 4 GiB, at ang buong 128k ay kumokonsumo ng 16 GiB bukod pa sa weights. Inilalaan ang cache kapag naglo-load ang model, kaya kumokonsumo ng ganoong memory ang malaking num_ctx kahit maikli ang mga prompt mo.

Pinapabagal ba ng mas malaking context window ang Ollama?

Oo, sa dalawang paraan. Lumalaki 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. Nakikipagkumpitensya rin sa memory ang mas malaking cache. Sa GPU box, maaari nitong ilipat ang ilang layer sa system RAM. Sa CPU box, maaari nitong itulak ang machine na gumamit ng swap. Ang malaking num_ctx na hindi mo naman napupuno ay kumokonsumo pa rin ng memory, ngunit hindi nito pinapahaba ang prefill time.

Maaari ko bang permanenteng itakda 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. Ang bawat client na humihingi ng llama3.1-16k ay gagamit ng context na iyon nang hindi nagpapadala ng anumang options. Mananaig pa rin ang request na may sarili nitong num_ctx, kaya default ito at hindi limitasyon sa pinakamataas na halaga.