Ollama میں num_ctx سے context length کیسے بڑھائیں

num_ctx کیا کرتا ہے، اور آپ کا طویل prompt کیوں کٹ گیا

Ollama کی context length ان tokens کی تعداد ہے جنہیں loaded model ایک وقت میں memory میں رکھ سکتا ہے، اور num_ctx وہ option ہے جو اسے مقرر کرتا ہے۔ Ollama ایسا default منتخب کرتا ہے جو model کی بتائی ہوئی maximum حد سے بہت کم ہوتا ہے، اس لیے طویل prompt model کے پڑھنے سے پہلے ہی کٹ جاتا ہے۔ response میں کوئی indication نہیں ملتی کہ ایسا ہوا ہے۔

Ollama model library میں Llama 3.1 8B کے لیے 128k context window درج ہے۔ stock 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۔ یہ defaults مختلف builds میں درست رہے ہیں۔ اس اختلاف سے اہم سبق یہ ملتا ہے: کسی بھی صفحے، حتیٰ کہ اس صفحے، پر بھروسا کرنے کے بجائے اپنے running server سے اصل value پڑھیں۔

Truncation خاموشی سے ہوتی ہے، کیونکہ model پھر بھی جواب دیتا ہے اور جواب بظاہر درست بھی لگتا ہے۔ لیکن وہ آپ کے input کے آخری حصے کی بنیاد پر تیار کیا گیا ہوتا ہے۔ کسی document کے پہلے نصف کو نظرانداز کرنے والا summary کمزور model کا نتیجہ معلوم ہوتا ہے۔ عموماً اصل وجہ چھوٹی context window ہوتی ہے۔

سرور نے Ollama کی context length حقیقت میں کتنی لاگو کی، یہ چیک کریں

ہر build پر کام کرنے والا check prompt_eval_count ہے۔ یہ prompt tokens کی وہ تعداد ہے جسے server processed کے طور پر report کرتا ہے۔ 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 واپس کرتا ہے، کیونکہ server نے باقی مواد حذف کر دیا۔ اب اسے "num_ctx":16384 کے ساتھ دوبارہ چلائیں، تو count بڑھ جاتا ہے۔ اگر آپ کا build truncate کرنے کے بجائے error واپس کرتا ہے، تو نتیجہ وہی ہے، لیکن اشارہ زیادہ واضح ہوتا ہے۔

ollama ps

جن builds میں یہ column دکھائی دیتا ہے، ان میں CONTEXT اس وقت loaded model کے لیے استعمال ہونے والی context length رکھتا ہے۔ اس کے ساتھ موجود PROCESSOR column دکھاتا ہے کہ model کہاں چل رہا ہے۔ GPU کے بغیر VPS پر 100% CPU معمول کی بات ہے۔ GPU والی مشین پر 30%/70% CPU/GPU جیسی تقسیم کا مطلب ہے کہ weights اور cache اب VRAM میں پوری طرح نہیں سما رہے، اور عموماً اس کی وجہ بڑھی ہوئی num_ctx ہوتی ہے۔

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

inference runner اپنی context size ایسی line میں دکھاتا ہے جس میں n_ctx شامل ہوتا ہے۔ releases کے درمیان exact wording بدلتی رہتی ہے، اس لیے line نہ ملنے کو rename سمجھیں، کسی نتیجے کا ثبوت نہیں۔

num_ctx مقرر کرنے کی چار جگہیں

request میں۔ "options": {"num_ctx": 16384} کو /api/generate یا /api/chat میں بھیجیں۔ اس setting کو باقی تمام settings پر ترجیح حاصل ہوتی ہے، اور یہ صرف اسی call پر لاگو ہوتی ہے۔ اگر یہ value loaded model کے موجودہ value سے مختلف ہو تو server پہلے model کو reload کرتا ہے۔ اس کا اثر response میں load_duration کے اندر دیکھا جا سکتا ہے: value تقریباً صفر سے بڑھ کر پورے seconds تک پہنچ جاتی ہے۔

interactive session میں۔ ollama run کے اندر /set parameter num_ctx 16384 درج کریں۔ یہ صرف اسی session تک برقرار رہتا ہے۔

Modelfile میں۔ اس طرح value کو named model میں شامل کر دیا جاتا ہے، اس لیے ہر client کو client-side تبدیلی کے بغیر یہی value ملتی ہے۔

FROM llama3.1:8b
PARAMETER num_ctx 16384

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

server پر۔ OLLAMA_CONTEXT_LENGTH ہر اس request کے لیے default مقرر کرتا ہے جس میں اپنا num_ctx موجود نہ ہو۔ 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

Debugging کے دوران precedence خاص طور پر اہم ہوتی ہے، جب آپ کسی دوسرے شخص کے client کی جانچ کر رہے ہوں۔ num_ctx رکھنے والی request کو server default پر ترجیح حاصل ہوتی ہے، اس لیے chat front end یا agent اپنی طرف سے چھوٹی value بھیج کر آپ کی systemd تبدیلی کو خاموشی سے غیر مؤثر کر سکتا ہے۔ جب آپ coding agent کو اپنے Ollama server کی طرف متوجہ کریں تو server کو موردِ الزام ٹھہرانے سے پہلے دیکھیں کہ client کیا بھیج رہا ہے۔

آپ صرف num_ctx کو model maximum پر کیوں مقرر نہیں کر سکتے

Attention ہر token کو اس سے پہلے آنے والے ہر token کے ساتھ دیکھتا ہے۔ پہلے tokens کے لیے compute کی گئی keys اور values محفوظ رہتی ہیں، تاکہ ہر نئے token کے لیے انہیں دوبارہ compute نہ کرنا پڑے۔ اس store کو KV cache (key/value cache) کہتے ہیں۔ Model load ہونے پر یہ پورے num_ctx کے لیے allocate ہوتا ہے، conversation بڑھنے کے ساتھ نہیں۔ اس لیے ایک سطری prompt میں بھی بڑا context اتنی ہی memory استعمال کرتا ہے۔

DigitalOcean's inference cost tutorial میں یہ arithmetic ایک ہی سطر میں دی گئی ہے:

kv_bytes_per_token = 2 * layers * kv_heads * head_dim * bytes_per_value

2 keys اور values کو الگ الگ count کرتا ہے۔ باقی numbers اپنے 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 کے طور پر publish کرتے ہیں۔ Default cache میں f16 values ہوتی ہیں، اس لیے bytes_per_value کی قدر 2 ہے، اور 2 32 8 128 2 کا نتیجہ 131,072 bytes ہے۔ یعنی context کے ہر ایک token کے لیے cache 128 KiB استعمال کرتی ہے۔ Context length سے ضرب دینے پر اس کی لاگت واضح ہو جاتی ہے۔

[
  {
    "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 سے حاصل ہونے والی arithmetic ہیں، measurements نہیں۔ Total column میں وہ 4.9 GB download بھی شامل ہے جسے Ollama library نے August 2026 میں llama3.1:8b کے لیے list کیا تھا۔ یہ 4.6 GiB بنتا ہے۔ اس میں compute buffers اور خود server process شامل نہیں ہیں۔ اسے کم از کم تخمینہ سمجھیں۔

اصل نکتہ اس کی صورتِ حال ہے۔ 8k پر cache 1 GiB استعمال کرتی ہے، جو weights کے مقابلے میں معمولی ہے۔ Model کے مکمل 128k پر اس کی لاگت 16 GiB ہو جاتی ہے، جو weights سے تین گنا سے بھی زیادہ ہے، اور total تقریباً 20.6 GiB بنتا ہے۔ اس لیے 4 GB VPS اس model کو کسی مفید context کے ساتھ load نہیں کر سکتا۔ 8 GB VPS پر 8k context کے لیے کافی گنجائش ہے۔ 16 GB VPS باقی system کے لیے کچھ memory بچاتے ہوئے 32k تک پہنچ جاتا ہے۔ Weights بڑھنے کے ساتھ ان تمام thresholds میں بھی اضافہ ہوتا ہے۔ اس لیے اگر آپ اس 8B model کے مقابلے میں بڑا model منتخب کرنے پر غور کر رہے ہیں تو Qwen کے 27B tag کو صرف CPU والے VPS پر آزمانے کے لیے کیے گئے یہی حساب دکھاتے ہیں کہ 8 سے 64 GB کے درمیان weights کے بعد context کے لیے کتنی کم memory بچتی ہے۔

جب KV cache میں فٹ نہ آئے تو کیا ہوتا ہے

صرف CPU والے VPS پر process کا memory استعمال مسلسل بڑھتا رہتا ہے۔ Model load ہوتے وقت اور طویل 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 کو پڑھتا ہے۔

اگر machine کی memory مکمل طور پر ختم ہو جائے تو kernel سب سے بڑے process کو منتخب کرکے اسے kill کر دیتا ہے۔

sudo dmesg | grep -i "killed process"

Out of memory: Killed process 1234 (ollama) والی line کا مطلب ہے کہ آپ کا مطلوبہ context فٹ نہیں آیا۔ Ollama اکثر اس مرحلے تک پہنچنے سے پہلے ہی request مسترد کر دیتا ہے۔ اس صورت میں request ایسے message کے ساتھ fail ہوتی ہے جس میں مطلوبہ memory اور دستیاب memory بتائی جاتی ہے۔

GPU والی machine پر failure کم نمایاں ہوتا ہے۔ کچھ layers system RAM میں منتقل ہو جاتی ہیں، ollama ps CPU اور GPU کے درمیان تقسیم دکھاتا ہے، اور throughput تیزی سے کم ہو جاتا ہے۔ کمی کی شدت hardware پر منحصر ہے، اس لیے ہر context setting پر اپنے box میں tokens per second کی پیمائش کریں، نہ کہ کسی اور machine کے اعداد و شمار پر بھروسا کریں۔

پرامپٹ کے مقابلے میں Prefill کا وقت زیادہ تیزی سے بڑھتا ہے

Prefill وہ کام ہے جو پہلے output token کے ظاہر ہونے سے پہلے آپ کے input پر کیا جاتا ہے۔ ہر 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 والے VPS پر، طویل context والی request میں Prefill عموماً سب سے سست مرحلہ ہوتا ہے، اور مختصر prompt سے حاصل کیا گیا tokens per second کا عدد اس کی پیش گوئی نہیں کرے گا۔

Concurrency کے معاملے میں یہ مسئلہ سب سے زیادہ نمایاں ہوتا ہے۔ ہر زیرِ خدمت request کو اپنا cache درکار ہوتا ہے، اس لیے اوپر دیے گئے chart میں memory فی request ہے، پورے server کے لیے نہیں، اور ایک طویل request server کو مصروف رکھ سکتی ہے جبکہ مختصر requests اس کے پیچھے queue میں انتظار کرتی ہیں۔ OLLAMA_NUM_PARALLEL کو سوچ سمجھ کر مقرر کریں، اور دونوں اعداد بیک وقت بڑھانے سے پہلے ایک self-hosted LLM کتنے بیک وقت صارفین کو سروس دے سکتا ہے پڑھیں۔

کم cache کے ساتھ context واپس حاصل کریں

فارمولے میں bytes_per_value ایک ایسی setting ہے جسے آپ کنٹرول کرتے ہیں۔ Ollama کی FAQ میں OLLAMA_KV_CACHE_TYPE درج ہے، جس میں default f16 ہے اور یہ 2 bytes استعمال کرتا ہے؛ اس کے علاوہ q8_0 1 byte استعمال کرتا ہے، جبکہ q4_0 اس سے بھی کم استعمال کرتا ہے۔ q8_0 پر منتقل ہونے سے cache آدھا رہ جاتا ہے، اس لیے 32k row کی لاگت 2 GiB رہ جاتی ہے، بجائے 4 GiB کے۔ اسی FAQ میں OLLAMA_FLASH_ATTENTION=1 بھی درج ہے، جس کی ضرورت بعض builds میں quantised cache کے مؤثر ہونے سے پہلے ہوتی ہے۔

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

قیاس کرنے کے بجائے تصدیق کریں: service کو restart کریں، model کو پہلے جیسی num_ctx پر load کریں، اور RSS کا موازنہ کریں۔ Support کا انحصار model اور backend پر ہوتا ہے، اس لیے اگر setting سے کچھ تبدیل نہیں ہوتا تو آپ کا combination اس کے دائرۂ کار میں شامل نہیں ہے۔ Documentation ان options کو درج کرتی ہے، لیکن quality result کی ضمانت نہیں دیتی۔ اس لیے اپنے prompts پر q4_0 کو test کریں، پھر اس پر انحصار کریں۔ اگر آپ یہاں انہی knobs کی وجہ سے پہنچے ہیں تو Ollama اور llama.cpp انہیں مختلف طریقے سے expose کرتے ہیں۔

num_ctx منتخب کرنے کا طریقہ

1. /api/show سے model کا maximum context، اس کی layer count اور key/value head count پڑھیں۔
2. فارمولے کے ذریعے bytes per token معلوم کریں، پھر اسے مطلوبہ context سے ضرب دیں۔
3. weight size شامل کریں، اسے free RAM سے موازنہ کریں، اور باقی server کے لیے کم از کم 1 GiB RAM خالی رکھیں۔
4. value مقرر کریں، model load کریں، پھر ollama ps اور prompt_eval_count سے تصدیق کریں کہ کون سی setting لاگو ہوئی ہے۔
5. free -m کو monitor کرتے ہوئے اپنا حقیقی workload چلائیں، اور اگر swap استعمال ہونا شروع ہو جائے تو context کو نصف کر دیں۔

زیادہ تر jobs کے لیے اتنا context درکار نہیں ہوتا جتنا لوگ فراہم کرتے ہیں۔ طویل report کا خلاصہ 16k میں ہو جاتا ہے۔ ایسا retrieval front end جو document کے پانچ chunks شامل کرتا ہے، عموماً 8k سے زیادہ استعمال نہیں کرتا۔ ایسا coding agent جو پوری files پڑھتا ہے، وہ حقیقی طور پر 64k یا اس سے زیادہ context کا محتاج ہوتا ہے۔ اسی صورت میں machine کا size context کو مدنظر رکھ کر مقرر کرنا چاہیے، نہ کہ اس کے برعکس۔ اگر server ابھی نیا ہے تو VPS پر فعال Ollama installation سے آغاز کریں اور models کے درست طور پر load ہونے کے بعد context کو tune کریں۔

FAQ

Ollama میں default 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 استعمال کرنے والا VPS چھوٹی حد پر رہتا ہے۔ جن builds میں یہ column موجود ہو، ان میں ollama ps لاگو شدہ context دکھاتا ہے، جبکہ API response میں prompt_eval_count ہر build پر اس کی تصدیق کرتا ہے۔

Ollama میرے طویل prompt کا آغاز کیوں نظرانداز کرتا ہے؟

کیونکہ prompt context window سے زیادہ طویل تھا۔ اس لیے server نے model تک پہنچنے سے پہلے اسے کاٹ دیا، اور کوئی error واپس نہیں آیا۔ اسی prompt کو بڑے num_ctx کے ساتھ دوبارہ بھیجیں اور response میں prompt_eval_count کی قدر بڑھتے ہوئے دیکھیں۔ اگر یہ number تبدیل نہ ہو تو آپ اور server کے درمیان موجود کوئی component خود num_ctx مقرر کر رہا ہے۔ Chat front ends اور agent frameworks میں یہ عام ہے۔

بڑے num_ctx کے لیے اضافی RAM کتنی درکار ہوتی ہے؟

Context length کو فی token cache cost سے ضرب دیں؛ یہ 2 * layers * kv_heads * head_dim * bytes_per_value ہے۔ Llama 3.1 8B کے لیے f16 پر یہ فی token 128 KiB ہے۔ اس لیے 32k tokens کے لیے weights کے علاوہ 4 GiB درکار ہوتے ہیں، جبکہ مکمل 128k کے لیے 16 GiB درکار ہوتے ہیں۔ Cache model load ہونے کے وقت allocate ہوتا ہے، اس لیے بڑا num_ctx اس وقت بھی اتنی memory استعمال کرتا ہے جب آپ کے prompts مختصر ہوں۔

کیا بڑی context window Ollama کو سست کر دیتی ہے؟

ہاں، دو طریقوں سے۔ Prefill کا کام prompt length کے مربع کے تناسب سے بڑھتا ہے، اس لیے طویل input کا پہلا token آنے میں اس کی length سے ظاہر ہونے والے اندازے سے زیادہ وقت لگتا ہے۔ بڑی cache بھی memory کے لیے مقابلہ کرتی ہے۔ GPU machine پر یہ layers کو system RAM میں منتقل کر سکتی ہے، جبکہ CPU machine پر یہ machine کو swap استعمال کرنے کے قریب لے جاتی ہے۔ بڑا num_ctx جسے آپ کبھی مکمل طور پر استعمال نہ کریں، تب بھی memory لیتا ہے، اگرچہ prefill time نہیں بڑھاتا۔

کیا میں ایک 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 پھر بھی ترجیح حاصل کرے گی، اس لیے یہ default مقرر کرتا ہے، maximum حد نہیں۔