SSD Nodes Learn Hosting plans →
మార్గదర్శకాలు Matt Connorద్వారా Matt Connor · అప్‌డేట్ చేయబడింది 2026-09-06

Ollamaలో num_ctxతో context length ఎలా సెట్ చేయాలి

Ollama పొడవైన promptలను చిన్న default context window వద్ద కత్తిరిస్తుంది. ప్రతి requestకు లేదా server-wide num_ctx సెట్ చేసి, పెంచే ముందు KV cache RAM అవసరాన్ని అంచనా వేయండి.

num_ctx ఏమి చేస్తుంది, మీ పొడవైన prompt ఎందుకు కత్తిరించబడింది

Ollama context length అంటే లోడ్ చేసిన model ఒకేసారి memoryలో ఉంచగల tokens సంఖ్య. num_ctx దాన్ని సెట్ చేసే option. Model ప్రకటించే గరిష్ఠ పరిమితికంటే చాలా తక్కువ default విలువను Ollama ఎంచుకుంటుంది. అందువల్ల model దాన్ని చదవకముందే పొడవైన prompt కత్తిరించబడుతుంది. ఇది జరిగిందని responseలో ఎక్కడా తెలియదు.

Ollama model libraryలో Llama 3.1 8Bకి 128k context windowగా చూపిస్తుంది. కానీ సాధారణ server మీకు ఆ పరిమితిని ఇవ్వదు. Ollama documentationలోని వేర్వేరు పేజీలు వేర్వేరు defaults చెబుతున్నాయి: FAQ 4096 tokens అని చెబుతుంది, Modelfile referenceలో num_ctx default 2048గా ఉంది, context length pageలో default అందుబాటులో ఉన్న VRAM (video RAM) ఆధారంగా ఎంచుకోబడుతుందని చెబుతుంది: 24 GiB కంటే తక్కువైతే 4k, 24 నుంచి 48 GiB వరకు 32k, అంతకంటే ఎక్కువైతే 256k. వీటిలో ప్రతి విలువ ఏదో ఒక buildకు సరైనదే. ఈ వ్యత్యాసం నుంచి ఉపయోగకరమైన పాఠం ఇదే: ఏ పేజీని, ఈ పేజీని కూడా, పూర్తిగా నమ్మకుండా మీ స్వంతంగా నడుస్తున్న serverలోని విలువను చూడండి.

Truncation నిశ్శబ్దంగా జరుగుతుంది, ఎందుకంటే model ఇప్పటికీ సమాధానం ఇస్తుంది, ఆ సమాధానం చదవడానికి కూడా బాగానే ఉంటుంది. అయితే అది మీ input చివరి భాగాన్ని ఆధారంగా చేసుకుని రాయబడుతుంది. Document మొదటి సగాన్ని మిస్ చేసిన summary బలహీనమైన model ఇచ్చినదిగా కనిపిస్తుంది. సాధారణంగా కారణం చిన్న context window.

సర్వర్ వాస్తవంగా అమలు చేసిన Ollama context length ను తనిఖీ చేయండి

ఏ build లోనైనా పనిచేసే తనిఖీ `prompt_eval_count`. ఇది సర్వర్ process చేసిన prompt tokens సంఖ్యను చూపుతుంది. Context లో సరిపడే పరిమాణం కంటే ఎక్కువ డేటాను పంపితే, ఆ సంఖ్య 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}'

ఆ prompt లో సుమారు 18,000 పదాలు ఉన్నాయి. అందువల్ల అది 4096 tokens కంటే చాలా ఎక్కువ. `prompt_eval_count నిజమైన token count కు దగ్గరగా కాకుండా 4096 కు దగ్గరగా వస్తుంది, ఎందుకంటే సర్వర్ మిగిలిన భాగాన్ని తొలగించింది. "num_ctx":16384` తో మళ్లీ అమలు చేస్తే count పెరుగుతుంది. మీ build truncation చేయకుండా error ఇస్తే, అదే విషయం మరింత స్పష్టంగా కనిపిస్తోందని అర్థం.

ollama ps

ఆ వివరాలను చూపించే builds లో `CONTEXT column, ప్రస్తుతం loaded model ఉపయోగిస్తున్న context length ను చూపుతుంది. దాని పక్కన ఉన్న PROCESSOR column, model ఏ స్థలంలో అమలవుతుందో చూపుతుంది. GPU లేని VPS లో 100% CPU సాధారణం. GPU ఉన్న యంత్రంలో 30%/70% CPU/GPU వంటి split కనిపిస్తే, weights మరియు cache VRAM లో పూర్తిగా సరిపోవడం లేదని అర్థం. పెంచిన num_ctx` సాధారణంగా దీనికి కారణం.

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

Inference runner, `n_ctx` ఉన్న line లో తన context size ను చూపుతుంది. Releases మధ్య ఖచ్చితమైన wording మారవచ్చు. అందువల్ల ఆ line కనిపించకపోతే, దాన్ని పేరు మారినదిగా పరిగణించండి; అది ఏదైనా విషయానికి నిర్ధారణ అని భావించవద్దు.

num_ctx సెట్ చేయడానికి నాలుగు ప్రదేశాలు

అభ్యర్థనలో. "options": {"num_ctx": 16384} ను /api/generate లేదా /api/chat కు పంపండి. ఇది ఇతర అన్ని సెట్టింగ్‌లను అధిగమిస్తుంది. ఇది ఆ ఒక్క call కు మాత్రమే వర్తిస్తుంది. లోడ్ చేసిన model ప్రస్తుతం ఉపయోగిస్తున్న విలువకు ఈ విలువ భిన్నంగా ఉంటే, server ముందుగా model ను మళ్లీ లోడ్ చేస్తుంది. దీనిని response లోని load_duration లో చూడవచ్చు: అది దాదాపు సున్నా నుంచి పూర్తి seconds కు పెరుగుతుంది. model ఎక్కువసేపు idle గా ఉండి unload అయినప్పుడు కూడా ఇదే wait కనిపిస్తుంది. కాబట్టి context size ను నిర్ణయించిన తర్వాత keep_alive తో model ను resident గా ఉంచడం ఉపయోగకరంగా ఉంటుంది.

ఇంటరాక్టివ్ session లో. ollama run లో /set parameter num_ctx 16384 ను టైప్ చేయండి. ఇది ఆ session కు మాత్రమే వర్తిస్తుంది.

Modelfile లో. ఇది విలువను పేరున్న model లోనే అమర్చుతుంది. అందువల్ల client-side మార్పు లేకుండా ప్రతి client దాన్ని పొందుతుంది.

FROM llama3.1:8b
PARAMETER num_ctx 16384
ollama create llama3.1-16k -f ./Modelfile
ollama run llama3.1-16k

server పై. స్వంత num_ctx లేని ప్రతి request కు OLLAMA_CONTEXT_LENGTH default విలువను సెట్ చేస్తుంది. systemd కింద unit file ను సవరించకుండా drop-in ను జోడించండి.

sudo systemctl edit ollama.service
[Service]
Environment="OLLAMA_CONTEXT_LENGTH=16384"
sudo systemctl daemon-reload
sudo systemctl restart ollama
ollama ps

మీరు మరొకరి client ను debug చేస్తున్నప్పుడు precedence అత్యంత ముఖ్యమైనది. num_ctx కలిగిన request server default ను అధిగమిస్తుంది. అందువల్ల చిన్న విలువను స్వయంగా పంపే chat front end లేదా agent, మీ systemd మార్పును నిశ్శబ్దంగా రద్దు చేయవచ్చు. మీరు coding agent ను మీ Ollama server కు point చేసినప్పుడు, server ను నిందించే ముందు client ఏది పంపుతుందో పరిశీలించండి.

మోడల్ గరిష్ఠానికి num_ctx ను నేరుగా ఎందుకు సెట్ చేయలేరు

Attention ప్రతి token ను దానికి ముందున్న ప్రతి token తో పరిశీలిస్తుంది. ముందుగా వచ్చిన token ల కోసం లెక్కించిన keys మరియు values ను మళ్లీ ప్రతి కొత్త token కు లెక్కించకుండా నిల్వ చేస్తారు. ఈ నిల్వను KV cache (key/value cache) అంటారు. మోడల్ load అయినప్పుడు ఇది మొత్తం num_ctx కోసం కేటాయించబడుతుంది. Conversation పెరుగుతున్నప్పుడు క్రమంగా కేటాయించబడదు. అందువల్ల ఒకే వరుస prompt ఉన్నా పెద్ద context దాని memory మొత్తాన్ని ఉపయోగిస్తుంది.

DigitalOcean inference cost tutorial ఈ లెక్కను ఒకే వరుసలో చూపిస్తుంది:

kv_bytes_per_token = 2 * layers * kv_heads * head_dim * bytes_per_value

ఈ లెక్కలో keys మరియు values ను విడివిడిగా లెక్కించడానికి 2 ఉపయోగించారు. మిగతా సంఖ్యలను మీ స్వంత 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"}'

Llama 3.1 8B లో 32 layers మరియు 8 key/value heads ఉన్నాయి. Head dimension అనేది embed ను heads తో భాగించిన విలువ. కాబట్టి ఇక్కడ 4096 / 32 = 128. కొన్ని models దీనిని నేరుగా llama.attention.key_length గా ప్రచురిస్తాయి. Default cache f16 values ను ఉంచుతుంది. అందువల్ల bytes_per_value విలువ 2. 2 32 8 128 2 లెక్కిస్తే 131,072 bytes వస్తాయి. అంటే context లోని ప్రతి token కు 128 KiB cache అవసరం. Context length తో దీనిని గుణిస్తే ఖర్చు స్పష్టంగా కనిపిస్తుంది.

ChartLlama 3.1 8B at f16: KV cache and total RAM by context length, in GiB
The data behind this chart
[
  {
    "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
  }
]

ఆ 6 rows పై formula ఆధారంగా చేసిన గణనలు మాత్రమే; అవి measurements కావు. Total column లో Ollama library August 2026లో llama3.1:8b కోసం చూపించిన 4.9 GB download కూడా కలిపారు. అది 4.6 GiB కు సమానం. Compute buffers మరియు server process memory ఇందులో లేవు. కాబట్టి దీనిని కనీస అంచనాగా పరిగణించండి.

ఇక్కడ ముఖ్యమైనది memory పెరుగుదల విధానం. 8k వద్ద cache ఖర్చు 1 GiB మాత్రమే. Weights తో పోలిస్తే ఇది చాలా తక్కువ. Model యొక్క పూర్తి 128k వద్ద cache ఖర్చు 16 GiB అవుతుంది. ఇది weights కంటే మూడు రెట్లకుపైగా ఉంటుంది. మొత్తం memory దాదాపు 20.6 GiB అవుతుంది. అందువల్ల 4 GB VPS ఈ model ను ఉపయోగకరమైన context తో load చేయలేడు. 8 GB VPS లో 8k context సౌకర్యంగా నడుస్తుంది. 16 GB VPS లో మిగతా server అవసరాలకు memory ఉంచి 32k context వరకు చేరవచ్చు. Weights పెరిగే కొద్దీ ఈ పరిమితులన్నీ మరింత పెరుగుతాయి. కాబట్టి ఈ 8B model కు బదులుగా పెద్ద model ను పరిశీలిస్తే, 8 నుంచి 64 GB వరకు CPU-only VPSలో Qwen యొక్క 27B tag కోసం చేసిన ఇదే లెక్కలు context కోసం weights తర్వాత ఎంత తక్కువ memory మిగులుతుందో చూపిస్తాయి.

KV cache సరిపోకపోతే ఏమి జరుగుతుంది

CPU-only VPSలో process పరిమాణం క్రమంగా పెరుగుతుంది. Model load అవుతున్నప్పుడు, అలాగే long request నడుస్తున్నప్పుడు దాన్ని monitor చేయండి.

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

RSS (resident set size) kilobytesలో చూపబడుతుంది. free -mలో ఉపయోగించిన swap పెరుగుతుంటే, context పరిమాణాన్ని తగ్గించండి. Swapలో ఉన్న KV cache వల్ల generationలో ప్రతి tokenకు seconds స్థాయిలో ఆలస్యం జరుగుతుంది. కారణం, ప్రతి కొత్త token మొత్తం cacheను చదవాలి.

సిస్టమ్‌లో memory పూర్తిగా అయిపోతే, kernel అతిపెద్ద processను ఎంచుకుని kill చేస్తుంది.

sudo dmesg | grep -i "killed process"

Out of memory: Killed process 1234 (ollama)తో చూపించే line అంటే మీరు అడిగిన context memoryలో సరిపోలేదని అర్థం. Ollama సాధారణంగా ఆ దశకు రాకముందే తిరస్కరిస్తుంది. అప్పుడు request విఫలమై, అవసరమైన memory మరియు అప్పటికి అందుబాటులో ఉన్న memoryను messageలో చూపిస్తుంది.

GPU boxలో failure అంత స్పష్టంగా కనిపించదు. కొన్ని layers system RAMలోకి spill అవుతాయి. ollama ps CPU మరియు GPU మధ్య విభజనను చూపిస్తుంది. Throughput గణనీయంగా తగ్గుతుంది. తగ్గుదల మీ hardwareపై ఆధారపడి ఉంటుంది. అందువల్ల ఇతరుల machineలోని గణాంకాన్ని నమ్మకుండా, ప్రతి context setting వద్ద మీ స్వంత boxలో ప్రతి secondకు ఎన్ని tokens ఉత్పత్తి అవుతున్నాయో కొలవండి.

Prompt పరిమాణం పెరిగేకొద్దీ prefill సమయం మరింత వేగంగా పెరుగుతుంది

మొదటి output token కనిపించే ముందు మీ input పై జరిగే పనినే prefill అంటారు. ప్రతి prompt token దానికి ముందు ఉన్న ప్రతి token ను పరిశీలిస్తుంది. అందువల్ల మొత్తం పని input పొడవం వర్గానికి అనుపాతంగా పెరుగుతుంది. Prompt పరిమాణాన్ని రెండింతలు చేస్తే, మొదటి token కోసం వేచి ఉండే సమయం రెండింతలకన్నా ఎక్కువగా పెరుగుతుంది.

ఆ కొలత response లోనే ఉంటుంది. అందువల్ల దాన్ని నిర్ధారణ లేకుండా నమ్మాల్సిన అవసరం లేదు.

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

దాన్ని ముందుగా చిన్న prompt తో, తరువాత పొడవైన prompt తో అమలు చేయండి. ప్రతి సందర్భంలో tokens ను seconds తో భాగించండి. CPU-only VPS లో long-context request కు prefill సాధారణంగా అత్యంత నెమ్మదైన భాగం. చిన్న prompt నుంచి పొందిన tokens per second విలువతో దాని పనితీరును అంచనా వేయలేరు. దాని ముందు ఉన్న timeout కంటే prefill ఎక్కువసేపు కొనసాగితే, పొడవైన prompt కు సమాధానం బదులుగా సాధారణంగా context deadline exceeded వస్తుంది. అందువల్ల context ను తగ్గించే ముందు ఏ layer విఫలమైందో గుర్తించండి.

ఈ సమస్య concurrency సమయంలో ఎక్కువగా కనిపిస్తుంది. అందిస్తున్న ప్రతి request కు స్వంత cache అవసరం. అందువల్ల పై chart లోని memory server మొత్తం కోసం కాకుండా ప్రతి request కోసం ఉంటుంది. ఒక దీర్ఘ request server వనరులను ఎక్కువసేపు ఆక్రమిస్తే, చిన్న requests దాని వెనుక queue లో వేచి ఉండవచ్చు. OLLAMA_NUM_PARALLEL ను ఉద్దేశపూర్వకంగా సెట్ చేయండి. రెండు సంఖ్యలను ఒకేసారి పెంచే ముందు ఒక self-hosted LLM ఎన్ని concurrent users కు సేవలందించగలదో చదవండి.

తక్కువ cache తో context ను తిరిగి పొందండి

ఫార్ములాలోని bytes_per_value మీ నియంత్రణలో ఉన్న setting. Ollama FAQ లో OLLAMA_KV_CACHE_TYPE వివరించబడింది. f16 default గా 2 bytes ఉంటుంది. అదనంగా q8_0 1 byte వద్ద, q4_0 దానికంటే తక్కువ వద్ద ఉంటుంది. q8_0 కు మార్చితే cache సగానికి తగ్గుతుంది. అందువల్ల 32k row కు 4 GiB బదులుగా 2 GiB అవసరం అవుతుంది. అదే memory budget లో మరో వైపు weights ను quantise చేయడం ద్వారా memory ఖాళీ అవుతుంది. అదే మార్పు చేయాలనుకుంటే, VPSలో వాస్తవంగా సరిపోయే GLM tag ను quantisation స్థాయిల వారీగా పరిశీలించారు. Quantised cache అమల్లోకి రావడానికి కొన్ని builds కు ముందుగా OLLAMA_FLASH_ATTENTION=1 అవసరం కావచ్చని కూడా అదే FAQ వివరిస్తుంది.

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

ఊహించకుండా నిర్ధారించండి: service ను restart చేయండి, మునుపటి అదే num_ctx వద్ద model ను load చేసి RSS ను పోల్చండి. Support model మరియు backend పై ఆధారపడి ఉంటుంది. ఏ setting మార్పూ కనిపించకపోతే, మీ కలయికకు అది వర్తించదు. Documentation ఈ options ను quality ఫలితం హామీ లేకుండా జాబితా చేస్తుంది. అందువల్ల దానిపై ఆధారపడే ముందు మీ స్వంత prompts తో q4_0 ను పరీక్షించండి. మీరు ఇక్కడికి రావడానికి కారణం ఈ knobs అయితే, Ollama మరియు llama.cpp వాటిని వేర్వేరు విధాలుగా అందిస్తాయి.

num_ctx ఎంచుకునే విధానం

  1. మోడల్‌కు గరిష్ఠ context, layer count, key/value head count ను /api/show నుంచి చదవండి.
  2. ఇచ్చిన formula తో ప్రతి token కు అవసరమైన bytes ను లెక్కించి, ఆ విలువను మీరు కోరే context పరిమాణంతో గుణించండి.
  3. weight size ను కలిపి, అందుబాటులో ఉన్న RAM తో పోల్చండి. మిగిలిన సిస్టమ్ కోసం కనీసం 1 GiB RAM ఖాళీగా ఉంచండి.
  4. విలువను సెట్ చేసి, మోడల్‌ను load చేయండి. ఆపై ollama ps మరియు prompt_eval_count ద్వారా ఏ విలువ అమలులోకి వచ్చిందో నిర్ధారించండి.
  5. free -m ను monitor చేస్తూ మీ నిజమైన workload ను నడపండి. swap వినియోగం ప్రారంభమైతే context ను సగానికి తగ్గించండి.

చాలా jobs కు వినియోగదారులు ఇచ్చే context కంటే తక్కువ context సరిపోతుంది. పొడవైన report ను summarise చేయడానికి 16k సరిపోతుంది. ఐదు document chunks ను జోడించే retrieval front end సాధారణంగా 8k ను మించదు. మొత్తం files ను చదివే coding agent కు మాత్రమే నిజంగా 64k లేదా అంతకంటే ఎక్కువ అవసరం కావచ్చు. అలాంటి సందర్భంలో context కు అనుగుణంగా machine పరిమాణాన్ని నిర్ణయించాలి; machine పరిమాణాన్ని ముందుగా నిర్ణయించి context ను దానికి పరిమితం చేయకూడదు. server ఇంకా కొత్తగా ఉంటే, VPS లో పనిచేస్తున్న Ollama install నుంచి ప్రారంభించి, models సరిగ్గా load అయిన తర్వాత context ను tune చేయండి.

FAQ

Ollamaలో డిఫాల్ట్ context length ఎంత?

ఇది build మరియు hardware పై ఆధారపడి ఉంటుంది. అందువల్ల ఊహించకుండా పరిశీలించండి. Ollama FAQలో 4096 tokens అని ఉంది. Modelfile referenceలో num_ctx default విలువ 2048గా ఉంది. Context length పేజీలో అందుబాటులో ఉన్న VRAM ఆధారంగా default ఎంచుకోబడుతుందని ఉంది: 24 GiB కంటే తక్కువైతే 4k, 24 నుంచి 48 GiB వరకు 32k, అంతకంటే ఎక్కువైతే 256k. CPU-only VPS సాధారణంగా ఈ పరిధిలోని చిన్న విలువను ఉపయోగిస్తుంది. ఆ column ఉన్న buildsలో ollama ps అమలైన context ను చూపిస్తుంది. API responseలోని prompt_eval_count ప్రతి buildలో అది నిర్ధారిస్తుంది.

నా పొడవైన prompt ప్రారంభాన్ని Ollama ఎందుకు విస్మరిస్తుంది?

Prompt context window కంటే పొడవుగా ఉండటం వల్ల server దాన్ని model చూడకముందే కత్తిరిస్తుంది. దీనిపై ఎలాంటి error కూడా తిరిగి రాదు. అదే prompt ను ఎక్కువ num_ctx తో మళ్లీ పంపండి. Responseలో prompt_eval_count పెరుగుతుందో గమనించండి. ఆ సంఖ్య మారకపోతే, మీకు మరియు serverకు మధ్య ఉన్న ఏదో భాగం num_ctx ను స్వయంగా నిర్దేశిస్తోంది. Chat front ends మరియు agent frameworksలో ఇది సాధారణం.

ఎక్కువ num_ctx కోసం అదనంగా ఎంత RAM అవసరం?

Context length ను ప్రతి tokenకు అయ్యే cache ఖర్చుతో గుణించండి. ఆ ఖర్చు 2 * layers * kv_heads * head_dim * bytes_per_value. f16లో Llama 3.1 8B కోసం ప్రతి tokenకు 128 KiB అవుతుంది. అందువల్ల 32k tokensకు 4 GiB అవసరం. పూర్తి 128k కోసం weightsకు అదనంగా 16 GiB అవసరం. Model load అయినప్పుడు cache కేటాయించబడుతుంది. కాబట్టి prompts చిన్నగా ఉన్నప్పటికీ పెద్ద num_ctx ఆ memoryని ఉపయోగిస్తుంది.

పెద్ద context window Ollamaను నెమ్మదిగా చేస్తుందా?

అవును, రెండు విధాలుగా. Prompt length యొక్క squareకు అనుగుణంగా prefill పని పెరుగుతుంది. అందువల్ల పొడవైన input వల్ల మొదటి token రావడానికి పట్టే సమయం, input length సూచించేదానికంటే ఎక్కువగా ఉంటుంది. పెద్ద cache కూడా memory కోసం పోటీ పడుతుంది. GPU boxలో అది కొన్ని layersను system RAMలోకి నెడుతుంది. CPU boxలో అది machineను swap వైపు నెడుతుంది. మీరు ఎప్పుడూ పూర్తిగా ఉపయోగించని పెద్ద num_ctx కూడా memoryని ఉపయోగిస్తుంది. అయితే prefill సమయం మాత్రం వినియోగించదు.

ఒక model కోసం num_ctxను శాశ్వతంగా సెట్ చేయవచ్చా?

అవును. FROM llama3.1:8b మరియు PARAMETER num_ctx 16384 కలిగిన Modelfileను రాయండి. తరువాత ollama create llama3.1-16k -f ./Modelfile అమలు చేయండి. llama3.1-16k ను కోరే ప్రతి client ఎలాంటి options పంపకుండానే ఆ contextను పొందుతుంది. అయితే స్వంత num_ctx కలిగిన requestకు ప్రాధాన్యం ఉంటుంది. కాబట్టి ఇది ceiling కాకుండా defaultను సెట్ చేస్తుంది.

#ollama#llm#self-hosted-ai#memory#vps