Jinsi ya kuweka num_ctx katika Ollama

Kazi ya num_ctx, na kwa nini prompt yako ndefu ilikatwa

Urefu wa context wa Ollama ni idadi ya tokens ambazo model iliyopakiwa inaweza kushikilia kwenye memory kwa wakati mmoja, na num_ctx ndilo chaguo linaloweka thamani hiyo. Ollama huchagua default iliyo chini sana ya kiwango cha juu kinachotangazwa na model, kwa hiyo prompt ndefu hukatwa kabla model haijaisoma. Hakuna kitu kwenye response kinachokuambia kuwa hilo limetokea.

Llama 3.1 8B imeorodheshwa kuwa na context window ya 128k kwenye Ollama model library. Server yenye usanidi wa kawaida haitakupa kiwango hicho. Documentation ya Ollama yenyewe ina default tofauti kwenye kurasa tofauti: FAQ inasema tokens 4096, Modelfile reference inasema num_ctx ina default ya 2048, na ukurasa wa context length unasema default huchaguliwa kulingana na VRAM (video RAM) inayopatikana: 4k ikiwa chini ya 24 GiB, 32k kuanzia 24 hadi 48 GiB, na 256k ikiwa zaidi ya hapo. Kila moja ya thamani hizi ilikuwa sahihi kwa build fulani. Somo muhimu ni hili: soma thamani kutoka kwenye server yako inayofanya kazi badala ya kuamini ukurasa wowote, ukiwemo huu.

Truncation huwa haionekani kwa sababu model bado hujibu, na jibu bado husomeka vizuri. Jibu liliandikwa kwa kutumia sehemu ya mwisho ya input yako. Summary inayokosa nusu ya kwanza ya document inaweza kuonekana kana kwamba imetengenezwa na model dhaifu. Mara nyingi chanzo huwa context window ndogo.

Thibitisha urefu wa context ambao seva yako ya Ollama ilitumia

Ukaguzi unaofanya kazi kwenye build yoyote ni prompt_eval_count, yaani idadi ya prompt tokens ambazo seva inaripoti kuwa ilizichakata. Tuma zaidi ya kiasi ambacho context inaweza kuhifadhi, kisha hiyo namba itafikia kikomo.

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

Prompt hiyo ina takriban maneno 18,000, kwa hiyo inazidi kwa mbali tokens 4096. prompt_eval_count inarudi karibu na 4096 badala ya idadi halisi ya tokens, kwa sababu seva iliondoa sehemu iliyobaki. Iendeshe tena kwa "num_ctx":16384, kisha idadi itaongezeka. Ikiwa build yako inarudisha error badala ya kukata prompt, hiyo ni finding ileile yenye ishara iliyo wazi zaidi.

ollama ps

Safu ya CONTEXT, kwenye build zinazoichapisha, ina urefu wa context ambao model iliyopakiwa inatumia kwa sasa. Safu ya PROCESSOR iliyo karibu nayo inaonyesha model iko kwenye eneo gani. 100% CPU ni hali ya kawaida kwenye VPS isiyo na GPU. Mgawanyo kama 30%/70% CPU/GPU kwenye mashine yenye GPU unamaanisha kuwa weights pamoja na cache hazitoshei tena kwenye VRAM, na num_ctx iliyoongezwa ndiyo sababu ya kawaida.

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

Inference runner huchapisha ukubwa wa context kwenye mstari unaojumuisha n_ctx. Maneno halisi hubadilika kati ya releases, kwa hiyo mstari usipokuwepo, ichukulie kuwa umepewa jina jipya, si uthibitisho wa jambo lolote.

Maeneo manne ya kuweka num_ctx

Kwenye ombi. Tuma "options": {"num_ctx": 16384} kwenye /api/generate au /api/chat. Hii ina kipaumbele kuliko mipangilio mingine yote, na inatumika kwenye ombi hilo pekee. Ikiwa thamani inatofautiana na ile ambayo model iliyopakiwa inatumia, server hupakia tena model kwanza. Hilo unaweza kuliona kwenye load_duration ya jibu: muda huruka kutoka karibu na sifuri hadi sekunde kamili. Kusubiri huko huko hutokea model inapokuwa haijatumika kwa muda mrefu kiasi cha kuondolewa kwenye kumbukumbu. Kwa hiyo, baada ya kuamua ukubwa wa context, inafaa kuweka model ibaki kwenye kumbukumbu kwa keep_alive.

Kwenye session shirikishi. Ndani ya ollama run, andika /set parameter num_ctx 16384. Mpangilio huu hudumu kwa session hiyo.

Kwenye Modelfile. Hii huweka thamani hiyo moja kwa moja kwenye model yenye jina, hivyo kila client huipata bila mabadiliko upande wa client.

FROM llama3.1:8b
PARAMETER num_ctx 16384

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

Kwenye server. OLLAMA_CONTEXT_LENGTH huweka default kwa kila ombi ambalo halina num_ctx yake. Chini ya systemd, ongeza drop-in badala ya kuhariri unit file.

sudo systemctl edit ollama.service

[Service]
Environment="OLLAMA_CONTEXT_LENGTH=16384"

sudo systemctl daemon-reload
sudo systemctl restart ollama
ollama ps

Mpangilio wa kipaumbele huwa muhimu zaidi unapochunguza tatizo kwenye client ya mtu mwingine. Ombi lenye num_ctx lina kipaumbele kuliko default ya server. Kwa hiyo, chat front end au agent anayetuma thamani ndogo yake mwenyewe anaweza kubatilisha kimya kimya mabadiliko yako ya systemd. Unapo elekeza coding agent kwenye Ollama server yako, hakikisha client inatuma nini kabla ya kuilaumu server.

Kwa nini huwezi kuweka tu num_ctx kuwa kiwango cha juu cha model

Attention hufanya kila tokeni itazame tokeni zote zilizotangulia. Keys na values zinazokokotolewa kwa tokeni za awali huhifadhiwa ili zisikokotolewe upya kwa kila tokeni mpya. Hifadhi hiyo huitwa KV cache (key/value cache). Hutengewa num_ctx yote wakati model inapopakiwa, si kadiri conversation inavyokua. Kwa hiyo, context kubwa hutumia memory yake hata kwenye prompt ya mstari mmoja.

DigitalOcean's inference cost tutorial inaonyesha hesabu hiyo katika mstari mmoja:

kv_bytes_per_token = 2 * layers * kv_heads * head_dim * bytes_per_value

Namba 2 huhesabu keys na values kando. Soma namba nyingine kutoka kwenye model yako mwenyewe.

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

Llama 3.1 8B ina layers 32 na key/value heads 8. Head dimension ni embed iliyogawanywa kwa heads, kwa hiyo 4096 / 32 = 128 hapa. Baadhi ya models huichapisha moja kwa moja kama llama.attention.key_length. Cache ya kawaida huhifadhi values za f16, kwa hiyo bytes_per_value ni 2. Hesabu 2 32 8 128 2 inatoa bytes 131,072. Hii ni 128 KiB ya cache kwa kila tokeni moja ya context. Ukizidisha kwa urefu wa context, gharama hiyo haibaki kuwa ya kinadharia.

[
  {
    "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
  }
]

Safu hizo za 6 ni hesabu zilizotokana na fomula iliyo hapo juu, si vipimo. Safu ya jumla inaongeza upakuaji wa 4.9 GB ambao Ollama library iliorodhesha kwa llama3.1:8b mnamo August 2026. Hiyo ni 4.6 GiB. Haijumuishi compute buffers wala server process yenyewe. Ichukulie kama kiwango cha chini.

Jambo muhimu ni mwelekeo huo. Katika 8k, cache inatumia 1 GiB, kiasi kidogo ikilinganishwa na weights. Katika 128k kamili ya model, inatumia 16 GiB, zaidi ya mara tatu ya weights, na kufanya jumla iwe karibu 20.6 GiB. Kwa hiyo, VPS ya 4 GB haiwezi kupakia model hii ikiwa na context yenye matumizi ya maana. VPS ya 8 GB inatosha vizuri kwa 8k. VPS ya 16 GB hufikia 32k na bado ina memory ya kutosha kwa sehemu nyingine za box. Kila mojawapo ya viwango hivyo huongezeka kadiri weights zinavyoongezeka. Kwa hiyo, ukilinganisha model kubwa na hii ya 8B, hesabu hizo hizo zilizofanyiwa Qwen's 27B tag on a CPU-only VPS kupitia tag ya Qwen ya 27B kwenye VPS ya CPU pekee zinaonyesha jinsi weights zinavyoacha memory kidogo kwa context kati ya 8 na 64 GB.

Kushindwa kwa KV cache kutoshea

Kwenye VPS inayotumia CPU pekee, mchakato huendelea tu kutumia kumbukumbu zaidi. Ufuatilie wakati model inapakia na wakati ombi refu linafanya kazi.

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

RSS (resident set size) huonyeshwa kwa kilobytes. Swap iliyotumika kwenye free -m ikianza kuongezeka, punguza context. KV cache iliyo kwenye swap husababisha generation kusimama kwa sekunde kadhaa kwa kila token, kwa sababu kila token mpya husoma cache yote.

Ikiwa mashine itaishiwa kumbukumbu kabisa, kernel huchagua mchakato mkubwa zaidi na kuumaliza.

sudo dmesg | grep -i "killed process"

Mstari unaosomeka Out of memory: Killed process 1234 (ollama) unamaanisha kuwa context uliyoomba haukutoshea. Ollama mara nyingi hukataa kabla haijafikia hatua hiyo, na ombi hushindwa kwa ujumbe unaotaja kumbukumbu iliyohitajika dhidi ya kumbukumbu iliyokuwa huru.

Kwenye mashine yenye GPU, kushindwa huku si dhahiri sana. Layers humwagika kwenye system RAM, ollama ps huonyesha mgawanyo kati ya CPU na GPU, na throughput hushuka sana. Kiwango cha kushuka hutegemea hardware yako, kwa hiyo pima tokens kwa sekunde kwenye mashine yako kwa kila setting ya context badala ya kutegemea thamani kutoka kwenye mashine ya mtu mwingine.

Prefill time hukua kwa kasi zaidi kuliko urefu wa prompt

Prefill ni kazi inayofanywa kwenye input yako kabla tokeni ya kwanza ya output haijaonekana. Kila tokeni ya prompt huchakata kila tokeni iliyo kabla yake, kwa hiyo jumla ya kazi hukua kwa mraba wa urefu wa input. Kuongeza prompt mara mbili huongeza muda wa kusubiri tokeni ya kwanza kwa zaidi ya mara mbili.

Jibu lina kipimo hicho, kwa hiyo si lazima ukikubali bila uthibitisho.

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

Endesha hilo kwa prompt fupi, kisha urudie kwa prompt ndefu. Baada ya hapo, gawanya idadi ya tokens kwa sekunde katika kila hali. Kwenye VPS inayotumia CPU pekee, prefill huwa ndiyo sehemu yenye kasi ndogo zaidi katika ombi lenye context ndefu. Kipimo cha tokens kwa sekunde kilichopatikana kwa prompt fupi hakitabiri utendaji wa ombi hilo.

Prefill ikizidi muda wa timeout uliowekwa mbele yake, kwa kawaida ombi lenye prompt ndefu hurudisha muda wa mwisho wa context umepita badala ya jibu. Kwa hiyo, tambua ni layer gani iliyoacha kusubiri kabla ya kupunguza context.

Tatizo hili huwa kubwa zaidi wakati wa kushughulikia maombi kwa wakati mmoja. Kila ombi linalohudumiwa linahitaji cache yake, kwa hiyo kumbukumbu iliyo kwenye chati hapo juu ni kwa kila ombi, si kwa kila server. Ombi moja refu linaweza kushikilia server huku maombi mafupi yakisubiri nyuma yake. Weka OLLAMA_NUM_PARALLEL kwa makusudi, na soma idadi ya watumiaji wanaofanana ambayo LLM moja ya self-hosted inaweza kuhudumia kabla ya kuongeza namba zote mbili kwa pamoja.

Rejesha nafasi ya muktadha kwa kutumia cache ndogo

bytes_per_value katika formula ni setting unayodhibiti. FAQ ya Ollama inaeleza OLLAMA_KV_CACHE_TYPE, ikiwa na f16 kama thamani chaguo-msingi ya 2 bytes, pamoja na q8_0 ya 1 byte na q4_0 iliyo chini ya hapo. Kubadilisha kuwa q8_0 hupunguza cache kwa nusu, hivyo safu ya 32k hugharimu 2 GiB badala ya 4 GiB. Ku-quantise weights hutoa memory upande mwingine wa budget hiyo hiyo, na GLM tag inayotoshea VPS imechambuliwa quantisation baada ya quantisation iwapo hiyo ndiyo trade-off unayopendelea. FAQ hiyo hiyo inaeleza OLLAMA_FLASH_ATTENTION=1, ambayo baadhi ya builds huhitaji kabla cache iliyofanyiwa quantisation kuanza kutumika.

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

Thibitisha badala ya kukisia: anzisha upya service, pakia model kwa num_ctx ileile ya awali, kisha linganisha RSS. Support hutegemea model na backend, kwa hiyo setting isiyobadilisha chochote inamaanisha mchanganyiko wako haujashughulikiwa. Documentation inaorodhesha options hizi bila kuahidi matokeo ya ubora, kwa hiyo jaribu q4_0 kwa prompts zako mwenyewe kabla ya kuitumia kwa utegemezi. Ikiwa knobs hizi ndizo zimekufanya uje hapa, Ollama na llama.cpp huzifichua kwa njia tofauti.

Mapishi ya kuchagua num_ctx

1. Soma muktadha wa juu zaidi wa model, idadi ya layers zake na idadi ya key/value heads kutoka /api/show.
2. Kokotoa bytes kwa kila token kwa kutumia fomula, kisha zidisha kwa muktadha unaotaka.
3. Ongeza ukubwa wa weights, linganisha na RAM iliyo huru, na uache angalau 1 GiB kwa ajili ya sehemu nyingine za server.
4. Weka thamani hiyo, pakia model, kisha thibitisha kilichotumika kwa ollama ps na prompt_eval_count.
5. Endesha workload yako halisi huku ukifuatilia free -m, na punguza muktadha kwa nusu ikiwa swap itaanza kutumika.

Kazi nyingi zinahitaji muktadha mdogo kuliko watu wanavyoweka. Kufupisha ripoti ndefu kunatoshea katika 16k. Retrieval front end inayoweka vipande vitano vya nyaraka kwa kawaida haivuki 8k. Coding agent inayosoma files nzima ndiyo hali inayohitaji 64k au zaidi kwa kweli. Hii pia ndiyo hali ambayo unapaswa kupima ukubwa wa machine kulingana na muktadha, si kinyume chake. Ikiwa server yenyewe bado ni mpya, anza na Ollama install inayofanya kazi kwenye VPS na rekebisha muktadha baada ya models kupakiwa bila errors.

Maswali Yanayoulizwa Mara kwa Mara (FAQ)

Urefu chaguo-msingi wa context katika Ollama ni upi?

Unategemea build na hardware, kwa hiyo hakikisha badala ya kukisia. FAQ ya Ollama inaandika tokens 4096, marejeo ya Modelfile yanaandika num_ctx chaguo-msingi cha 2048, na ukurasa wa context length unaandika chaguo-msingi kinachochaguliwa kulingana na VRAM inayopatikana: 4k chini ya 24 GiB, 32k kuanzia 24 hadi 48 GiB, na 256k zaidi ya 48 GiB. VPS ya CPU-only huwa upande wa chini. ollama ps huonyesha context iliyotumika kwenye builds zenye column hiyo, na prompt_eval_count katika jibu la API huithibitisha kwenye kila build.

Kwa nini Ollama inapuuza mwanzo wa prompt yangu ndefu?

Kwa sababu prompt ilikuwa ndefu kuliko context window, hivyo server iliikata kabla model haijaiona, na hakuna error iliyorejeshwa. Tuma prompt hiyo hiyo tena ukiwa na num_ctx kubwa zaidi, kisha monitor prompt_eval_count katika jibu inapoongezeka. Ikiwa nambari hiyo haisogei, kuna kitu kati yako na server kinachoweka num_ctx chenyewe. Hili hutokea mara nyingi kwa chat front ends na agent frameworks.

Je, num_ctx kubwa inahitaji RAM ya ziada kiasi gani?

Zidisha urefu wa context kwa gharama ya cache kwa kila token, ambayo ni 2 * layers * kv_heads * head_dim * bytes_per_value. Kwa Llama 3.1 8B kwenye f16, hiyo ni 128 KiB kwa kila token, kwa hiyo tokens 32k zinagharimu 4 GiB na 128k kamili zinagharimu 16 GiB, juu ya memory ya weights. Cache hutengwa model inapopakiwa, kwa hiyo num_ctx kubwa itatumia memory hiyo hata kama prompts zako ni fupi.

Je, context window kubwa huifanya Ollama iwe polepole zaidi?

Ndiyo, kwa njia mbili. Kazi ya prefill huongezeka kwa mraba wa urefu wa prompt, kwa hiyo input ndefu huchelewesha token ya kwanza kwa muda unaozidi unavyoweza kutarajia kutokana na urefu wake. Cache kubwa pia hushindania memory: kwenye mashine ya GPU husukuma layers kwenda system RAM, na kwenye mashine ya CPU husukuma mfumo kuelekea kutumia swap. num_ctx kubwa ambayo huijazi bado hugharimu memory, ingawa haigarimu muda wa prefill.

Je, ninaweza kuweka num_ctx iwe ya kudumu kwa model moja?

Ndiyo. Andika Modelfile yenye FROM llama3.1:8b na PARAMETER num_ctx 16384, kisha endesha ollama create llama3.1-16k -f ./Modelfile. Kila client inayoomba llama3.1-16k hupata context hiyo bila kutuma options zozote. Request yenye num_ctx yake bado ina kipaumbele, kwa hiyo hii huweka chaguo-msingi badala ya kuweka kikomo cha juu.