Jinsi ya kuongeza num_ctx kwenye Ollama kwa usahihi

Kazi ya num_ctx, na kwa nini prompt yako ndefu ilikatwa

Urefu wa context wa Ollama ni idadi ya tokens ambazo model iliyopakiwa inaweza kuhifadhi kwenye kumbukumbu kwa wakati mmoja, na num_ctx ndiyo chaguo linaloiweka. Ollama huchagua thamani ya msingi ambayo iko chini sana kuliko uwezo wa juu zaidi unaotangazwa na model, hivyo prompt ndefu hukatwa kabla model haijaisoma. Hakuna chochote kwenye majibu kinachokutaarifu kuwa jambo hilo limetokea.

Llama 3.1 8B imeorodheshwa ikiwa na context window ya 128k kwenye maktaba ya model za Ollama. Seva ya kawaida haitakupa uwezo huo. Nyaraka za Ollama zenyewe zina thamani tofauti za msingi kwenye kurasa tofauti: FAQ inasema 4096 tokens, marejeleo ya Modelfile yanasema num_ctx ina thamani ya msingi ya 2048, na ukurasa wa urefu wa context unasema thamani ya msingi huchaguliwa kulingana na VRAM (video RAM) inayopatikana: 4k kwa chini ya 24 GiB, 32k kwa kati ya 24 na 48 GiB, na 256k kwa zaidi ya hapo. Kila moja ilikuwa sahihi kwa toleo fulani. Kutokubaliana huko ndiko somo muhimu hapa: soma thamani kutoka kwenye seva yako inayofanya kazi badala ya kuamini ukurasa wowote, ikiwemo huu.

Ukatizaji huu hufanyika kimya kimya kwa sababu model bado inajibu, na jibu hilo bado linasomeka vizuri. Limeandikwa kutokana na sehemu ya mwisho ya input yako. Muhtasari unaokosa nusu ya kwanza ya hati huonekana kama model dhaifu. Kwa kawaida, hiyo husababishwa na context window ndogo.

Kagua urefu wa context wa Ollama uliotumika kwenye seva yako

Ukaguzi unaofanya kazi kwenye build yoyote ni prompt_eval_count, idadi ya prompt tokens ambayo seva inaripoti kuwa imechakata. Tuma data inayozidi uwezo wa context na namba hiyo itasimama kwenye kikomo hicho.

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, hivyo ni zaidi ya 4096 tokens. prompt_eval_count inarudi ikiwa karibu na 4096 badala ya idadi halisi ya tokens, kwa sababu seva ilikata sehemu iliyozidi. Iendeshe tena kwa kutumia "num_ctx":16384 na idadi hiyo itaongezeka. Ikiwa build yako inatoa error badala ya kukata data, hiyo ni matokeo sawa yenye ishara kali zaidi.

ollama ps

Safu ya CONTEXT, kwenye build zinazoichapisha, inaonyesha urefu wa context ambao model iliyopakiwa inatumia kwa sasa. Safu ya PROCESSOR iliyo karibu nayo inaonyesha mahali ambapo model imekaa. 100% CPU ni ya kawaida kwenye VPS isiyo na GPU. Mgawanyo kama 30%/70% CPU/GPU kwenye mashine yenye GPU unamaanisha kuwa uzito (weights) pamoja na cache havitoshi tena kwenye VRAM, na kuongezeka kwa num_ctx ndiyo sababu ya kawaida.

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

Mchakato wa inference huchapisha ukubwa wake wa context kwenye mstari wenye n_ctx. Maneno kamili hubadilika kati ya releases, kwa hivyo chukulia mstari usipoonekana kama jina kubadilishwa badala ya ushahidi wa jambo lolote.

Maeneo manne ya kuweka num_ctx

Katika ombi. Tuma "options": {"num_ctx": 16384} kwa /api/generate au /api/chat. Hii inashinda mipangilio mingine yote, na inatumika kwa wito huo mmoja tu. Ikiwa thamani hiyo ni tofauti na ile ambayo modeli iliyopakiwa inatumia, seva hupakia upya modeli hiyo kwanza, jambo ambalo unaweza kuliona katika load_duration kwenye jibu: muda huruka kutoka karibu sifuri hadi sekunde nzima.

Katika kipindi cha mwingiliano (interactive session). Ndani ya ollama run, chapa /set parameter num_ctx 16384. Hii hudumu kwa kipindi hicho tu.

Katika Modelfile. Hii huweka thamani hiyo ndani ya modeli yenye jina maalum, hivyo kila mteja huipata bila mabadiliko yoyote upande wa mteja.

FROM llama3.1:8b
PARAMETER num_ctx 16384

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

Kwenye seva. OLLAMA_CONTEXT_LENGTH huweka thamani chaguo-msingi kwa kila ombi lisilokuwa na num_ctx yake yenyewe. Chini ya systemd, ongeza faili ya drop-in badala ya kuhariri faili ya unit.

sudo systemctl edit ollama.service

[Service]
Environment="OLLAMA_CONTEXT_LENGTH=16384"

sudo systemctl daemon-reload
sudo systemctl restart ollama
ollama ps

Umuhimu wa kipaumbele (precedence) huonekana zaidi unapofanya debugging ya mteja wa mtu mwingine. Ombi lenye num_ctx hushinda chaguo-msingi la seva, kwa hivyo front end ya chat au wakala (agent) inayotuma thamani ndogo yenyewe inaweza kufuta mabadiliko yako ya systemd kimyakimya. Unapofanya kuelekeza wakala wa usimbaji kwenye seva yako ya Ollama, kagua kile ambacho mteja anatuma kabla ya kuilaumu seva.

Kwa nini huwezi kuweka num_ctx kwenye kiwango cha juu cha modeli

Attention hufanya kila tokeni iangalie kila tokeni iliyotangulia. Funguo (keys) na thamani (values) zilizokokotolewa kwa tokeni za awali huhifadhiwa ili zisikokotolewe upya kwa kila tokeni mpya, na hifadhi hiyo ndiyo KV cache (key/value cache). Hifadhi hii hutengwa kwa ajili ya num_ctx nzima wakati modeli inapopakiwa, si kadiri mazungumzo yanavyokua, kwa hivyo muktadha (context) mkubwa hutumia kumbukumbu hiyo hata kwa ujumbe wa mstari mmoja.

Mafunzo ya gharama za inference ya DigitalOcean yanaeleza hesabu hiyo kwa mstari mmoja:

kv_bytes_per_token = 2 * layers * kv_heads * head_dim * bytes_per_value

Namba 2 huhesabu funguo na thamani kando. Soma namba nyingine kutoka kwenye modeli 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 inaripoti matabaka 32 na vichwa 8 vya key/value. Kipimo cha kichwa ni embed ikigawanywa kwa heads, kwa hivyo 4096 / 32 = 128 hapa, na baadhi ya modeli huchapisha hili moja kwa moja kama llama.attention.key_length. Cache ya kawaida huhifadhi thamani za f16, kwa hivyo bytes_per_value ni 2, na 2 32 8 128 2 inatoa 131,072 bytes. Hiyo ni 128 KiB ya cache kwa kila tokeni moja ya muktadha. Zidisha kwa urefu wa muktadha na gharama itaacha kuwa dhana tu.

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

Hizo 6 safu ni hesabu kutoka kwa fomula hapo juu, si vipimo. Safu ya jumla inaongeza upakuaji wa 4.9 GB ambao maktaba ya Ollama iliorodhesha kwa ajili ya llama3.1:8b mnamo Agosti 2026, ambayo ni 4.6 GiB, na inaacha buffers za kompyuta na mchakato wa seva yenyewe. Ichukulie kama kiwango cha chini kabisa.

Umbo ndilo jambo la msingi. Katika 8k, cache inagharimu 1 GiB, ambayo ni ndogo ikilinganishwa na uzito (weights). Katika 128k kamili ya modeli, inagharimu 16 GiB, zaidi ya mara tatu ya uzito, kwa jumla inayokaribia 20.6 GiB. Kwa hivyo, VPS ya 4 GB haiwezi kupakia modeli hii kwa muktadha wowote wenye manufaa. VPS ya 8 GB inafaa kwa 8k. VPS ya 16 GB inafikia 32k huku ikiwa na nafasi iliyobaki kwa ajili ya sehemu nyingine za seva. Kila moja ya vizingiti hivyo hupanda kulingana na uzito, kwa hivyo ikiwa unalinganisha modeli kubwa zaidi na hii ya 8B, hesabu zilezile zilizofanywa kwa tag ya Qwen 27B kwenye VPS ya CPU pekee zinaonyesha jinsi uzito unavyoacha nafasi ndogo kwa ajili ya muktadha kati ya 8 na 64 GB.

Nini hutokea wakati KV cache haitoshi

Kwenye VPS inayotumia CPU pekee, mchakato huu hukua tu. Iangalie wakati model inapakia na wakati ombi refu linapoendelea.

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

RSS (resident set size) huchapishwa kwa kilobytes. Ikiwa swap inayotumika katika free -m inaanza kupanda, punguza context. KV cache inayokaa kwenye swap husababisha uzalishaji kukwama kwa sekunde kadhaa kwa kila token, kwa sababu kila token mpya husoma cache nzima.

Ikiwa seva itaishiwa na kumbukumbu kabisa, kernel huchagua mchakato mkubwa zaidi na kuumaliza (kill).

sudo dmesg | grep -i "killed process"

Mstari unaosomeka Out of memory: Killed process 1234 (ollama) unamaanisha kuwa context uliyoomba haikutosha. Ollama mara nyingi hukataa kabla ya kufika hapo, na ombi hushindwa likiwa na ujumbe unaotaja kumbukumbu iliyohitajika dhidi ya kumbukumbu iliyokuwa wazi.

Kwenye seva yenye GPU, hitilafu hii huwa ya kimya zaidi. Layers humwagika kwenye RAM ya mfumo, ollama ps huonyesha mgawanyo wa CPU na GPU, na throughput hushuka kwa kasi. Kasi ya kushuka hutegemea vifaa vyako, kwa hivyo pima tokens kwa sekunde kwenye seva yako mwenyewe katika kila mpangilio wa context badala ya kuamini takwimu kutoka kwa mashine ya mtu mwingine.

Muda wa prefill hukua kwa kasi zaidi kuliko prompt

Prefill ni kazi inayofanyika kwenye input yako kabla ya token ya kwanza ya output haijatokea. Kila token ya prompt hufanya kazi na kila token iliyotangulia, kwa hivyo jumla ya kazi hukua kulingana na mraba wa urefu wa input. Kuongeza prompt mara mbili husababisha muda wa kusubiri token ya kwanza kuongezeka zaidi ya mara mbili.

Majibu hubeba kipimo hicho, kwa hivyo huna haja ya kukiamini bila ushahidi.

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

Tekeleza hilo kwa kutumia prompt fupi na tena kwa kutumia ndefu, kisha gawanya idadi ya tokens kwa sekunde katika kila kisa. Kwenye VPS inayotumia CPU pekee, prefill kwa kawaida ndiyo sehemu ya polepole zaidi ya ombi lenye muktadha mrefu, na takwimu ya tokens kwa sekunde inayotokana na prompt fupi haitakupa utabiri sahihi.

Concurrency ndipo hapa ambapo tatizo hili huleta athari kubwa zaidi. Kila ombi linalohudumiwa linahitaji cache yake yenyewe, kwa hivyo kumbukumbu katika chati hapo juu ni kwa kila ombi badala ya kila seva, na ombi moja refu linaweza kuizuia seva wakati maombi mafupi yakisubiri nyuma yake. Weka OLLAMA_NUM_PARALLEL kwa makusudi, na usome idadi ya watumiaji wa wakati mmoja ambao LLM inayojiendesha yenyewe inaweza kuhudumia kabla ya kuongeza namba zote mbili kwa pamoja.

Rudisha muktadha kwa kutumia cache ndogo

bytes_per_value katika fomula ni mpangilio unaoweza kuudhibiti. FAQ ya Ollama inaelezea OLLAMA_KV_CACHE_TYPE, huku f16 ikiwa ni chaguo-msingi la baiti 2, pamoja na q8_0 ya baiti 1 na q4_0 chini ya hapo. Kuhamia q8_0 kunapunguza cache kwa nusu, kwa hivyo safu ya 32k inagharimu 2 GiB badala ya 4 GiB. FAQ hiyo hiyo inaelezea OLLAMA_FLASH_ATTENTION=1, ambayo baadhi ya builds huihitaji kabla ya cache iliyopunguzwa ukubwa (quantised) kuanza kufanya kazi.

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

Thibitisha badala ya kudhani: anzisha upya huduma, pakia model kwa num_ctx ile ile kama awali, na ulinganishe RSS. Usaidizi hutegemea model na backend, kwa hivyo mpangilio ambao haubadilishi chochote unamaanisha kuwa mchanganyiko wako haujajumuishwa. Nyaraka zinaorodhesha chaguzi hizi bila kuahidi matokeo bora, kwa hivyo jaribu q4_0 dhidi ya prompts zako mwenyewe kabla ya kuitegemea. Ikiwa vitufe hivi ndivyo sababu ya wewe kuwa hapa, Ollama na llama.cpp huviwasilisha kwa njia tofauti.

Mbinu ya kuchagua num_ctx

1. Soma muktadha wa juu kabisa wa modeli (maximum context), idadi ya matabaka (layer count), na idadi ya vichwa vya key/value kutoka /api/show.
2. Kokotoa baiti kwa kila tokeni kwa kutumia fomula, kisha zidisha kwa muktadha unaotaka.
3. Ongeza ukubwa wa uzito (weight size), linganisha na RAM iliyo wazi, na uache angalau 1 GiB kwa ajili ya matumizi mengine ya seva.
4. Weka thamani hiyo, pakia modeli, kisha thibitisha kile kilichotumika kwa kutumia ollama ps na prompt_eval_count.
5. Endesha kazi yako halisi huku ukifuatilia free -m, na upunguze muktadha kwa nusu ikiwa swap itaanza kutumika.

Kazi nyingi huhitaji muktadha mdogo kuliko ule unaotolewa na watumiaji. Muhtasari wa ripoti ndefu hutoshea katika 16k. Kiolesura cha utafutaji kinachobandika vipande vitano vya hati mara chache huzidi 8k. Wakala wa uandishi wa programu (coding agent) anayesoma faili nzima ndiye anayehitaji 64k au zaidi, na hili ndilo tukio ambalo unapaswa kupanga ukubwa wa mashine kulingana na muktadha badala ya kinyume chake. Ikiwa seva yenyewe bado ni mpya, anza kutoka usakinishaji wa Ollama kwenye VPS na urekebishe muktadha pindi modeli zitakapopakiwa vizuri.

FAQ

Urefu wa context chaguo-msingi katika Ollama ni upi?

Inategemea toleo la programu na maunzi, kwa hivyo hakiki badala ya kudhani. FAQ ya Ollama inaeleza token 4096, marejeleo ya Modelfile yanaeleza num_ctx chaguo-msingi ya 2048, na ukurasa wa urefu wa context unaeleza chaguo-msingi inayochaguliwa kulingana na VRAM inayopatikana: 4k kwa chini ya 24 GiB, 32k kwa 24 hadi 48 GiB, na 256k kwa zaidi ya hapo. VPS inayotumia CPU pekee huangukia kwenye kiwango cha chini. ollama ps huchapisha context inayotumika kwenye matoleo yenye safu hiyo, na prompt_eval_count katika jibu la API huthibitisha hilo kwenye kila toleo.

Kwa nini Ollama hupuuza mwanzo wa prompt yangu ndefu?

Kwa sababu prompt ilikuwa ndefu kuliko dirisha la context, kwa hivyo seva iliikata kabla ya model kuiona, na hakuna error iliyorejeshwa. Tuma tena prompt hiyo hiyo ukiwa na num_ctx kubwa zaidi na uangalie prompt_eval_count katika jibu ikiongezeka. Ikiwa namba hiyo haibadiliki, kuna kitu kati yako na seva kinachoweka num_ctx chenyewe, jambo ambalo ni la kawaida kwa front ends za chat na mifumo ya wakala (agent frameworks).

Ni kiasi gani cha RAM ya ziada kinachohitajika kwa num_ctx kubwa?

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 katika f16 hiyo ni 128 KiB kwa kila token, kwa hivyo token 32k hugharimu 4 GiB na 128k kamili hugharimu 16 GiB juu ya uzito wa model (weights). Cache hutengwa wakati model inapopakiwa, kwa hivyo num_ctx kubwa hugharimu kumbukumbu hiyo hata kama prompt zako zitabaki fupi.

Je, dirisha kubwa la context hufanya Ollama kuwa polepole?

Ndiyo, kwa njia mbili. Kazi ya prefill hukua kulingana na mraba wa urefu wa prompt, kwa hivyo input ndefu huchelewesha token ya kwanza kwa muda mrefu zaidi ya urefu wake unavyopendekeza. Cache kubwa pia hushindania kumbukumbu: kwenye seva ya GPU husukuma layers kwenye RAM ya mfumo, na kwenye seva ya CPU husukuma mashine kuelekea kwenye swap. num_ctx kubwa ambayo huijazi bado hugharimu kumbukumbu hiyo, ingawa haigharimu muda wa prefill.

Je, ninaweza kuweka num_ctx 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 mteja anayeomba llama3.1-16k hupata context hiyo bila kutuma chaguo lolote. Ombi linalobeba num_ctx yake mwenyewe bado hushinda, kwa hivyo hii huweka chaguo-msingi badala ya kikomo cha juu.