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

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

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

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۔ ان میں سے ہر value کسی نہ کسی build میں درست تھی۔ اس اختلاف سے ایک مفید سبق ملتا ہے: کسی بھی page، حتیٰ کہ اس page پر بھی، بھروسا کرنے کے بجائے اپنے running server سے value پڑھیں۔

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

اپنے سرور پر Ollama کی لاگو کردہ context length چیک کریں

ہر build پر کام کرنے والا طریقہ prompt_eval_count ہے۔ یہ prompt tokens کی وہ تعداد ہے جسے server process کرنے کی اطلاع دیتا ہے۔ 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 والے server پر 30%/70% CPU/GPU جیسی تقسیم کا مطلب ہے کہ weights اور cache اب VRAM میں پوری طرح fit نہیں ہو رہے، اور اس کی عام وجہ بڑھا ہوا num_ctx ہے۔

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

inference runner اپنی context size ایسی line میں دکھاتا ہے جس میں n_ctx شامل ہوتا ہے۔ مختلف releases میں الفاظ بدل سکتے ہیں، اس لیے line نہ ملنے کو کسی اور نام کے استعمال کے طور پر سمجھیں، نہ کہ کسی نتیجے کا ثبوت۔

num_ctx ترتیب دینے کی چار جگہیں

درخواست میں۔ "options": {"num_ctx": 16384} کو /api/generate یا /api/chat میں بھیجیں۔ اس کی ترجیح ہر دوسری setting سے زیادہ ہے، اور یہ صرف اسی call پر لاگو ہوتی ہے۔ اگر یہ value loaded model کے موجودہ value سے مختلف ہو تو server پہلے model reload کرتا ہے۔ یہ response کے load_duration میں نظر آتا ہے: وقت تقریباً صفر سے بڑھ کر پورے seconds ہو جاتا ہے۔ یہی انتظار اس وقت بھی ظاہر ہوتا ہے جب model کافی دیر idle رہنے کے بعد unload ہو جائے۔ اس لیے context size طے کرنے کے بعد model کو keep_alive کے ذریعے resident رکھنا مفید ہے۔

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 کو ماڈل کی زیادہ سے زیادہ حد پر کیوں سیٹ نہیں کر سکتے

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

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

kv_bytes_per_token = 2 * layers * kv_heads * head_dim * bytes_per_value

اس فارمولے میں 2 keys اور values کو الگ الگ شمار کرتا ہے۔ باقی اعداد اپنے 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 اوپر دیے گئے فارمولے سے حاصل ہونے والا حساب ہیں، measurements نہیں۔ total column میں Ollama library کی جانب سے August 2026 میں llama3.1:8b کے لیے درج کردہ 4.9 GB download شامل ہے، جو 4.6 GiB بنتا ہے۔ اس میں compute buffers اور server process خود شامل نہیں ہیں۔ اسے کم از کم درکار مقدار سمجھیں۔

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

جب KV cache میں فٹ نہ ہو

صرف CPU والے VPS پر عمل کا memory استعمال بڑھتا رہتا ہے۔ ماڈل load ہوتے وقت اور طویل request چلتے وقت اس کی نگرانی کریں۔

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 کو منتخب کر کے اسے ختم کر دیتا ہے۔

sudo dmesg | grep -i "killed process"

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

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

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

Prefill وہ کام ہے جو پہلے output token کے ظاہر ہونے سے پہلے آپ کے input پر کیا جاتا ہے۔ ہر prompt token اس سے پہلے موجود ہر token پر attention دیتا ہے، اس لیے مجموعی کام 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 کا اعداد و شمار طویل prompt کی کارکردگی کی پیش گوئی نہیں کرتا۔ اگر prefill اس کے سامنے موجود کسی بھی timeout سے زیادہ وقت لے، تو عموماً طویل prompt کے جواب کے بجائے context deadline exceeded آنے کی یہی وجہ ہوتی ہے۔ اس لیے context مختصر کرنے سے پہلے معلوم کریں کہ کس layer نے انتظار ختم کر دیا۔

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

چھوٹے cache کے ذریعے context دوبارہ حاصل کریں

فارمولے میں bytes_per_value ایک ایسی setting ہے جسے آپ control کرتے ہیں۔ Ollama کی FAQ میں OLLAMA_KV_CACHE_TYPE درج ہے، جس میں f16 default ہے اور اس کی قدر 2 bytes ہے؛ اس کے علاوہ q8_0 کی قدر 1 byte ہے، جبکہ q4_0 اس سے بھی کم ہے۔ q8_0 پر منتقل ہونے سے cache نصف رہ جاتا ہے، اس لیے 32k row کی لاگت 2 GiB کے بجائے 4 GiB ہوتی ہے۔ Weights کو quantise کرنے سے اسی budget کے دوسرے حصے سے memory آزاد ہوتی ہے، اور وہ GLM tag جو VPS میں واقعی فٹ آتا ہے بھی quantisation کے ذریعے مرحلہ وار بیان کیا گیا ہے، اگر آپ یہی trade-off اختیار کرنا چاہیں۔ اسی 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 کی ضمانت نہیں دیتی؛ اس لیے ان پر انحصار کرنے سے پہلے q4_0 کو اپنے prompts کے ساتھ 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 سے compare کریں، اور باقی server کے لیے کم از کم 1 GiB محفوظ رکھیں۔
4. value set کریں، model load کریں، پھر ollama ps اور prompt_eval_count سے تصدیق کریں کہ کون سی value apply ہوئی ہے۔
5. free -m کو monitor کرتے ہوئے اپنا حقیقی workload چلائیں، اور اگر swap استعمال ہونا شروع ہو جائے تو context کو نصف کر دیں۔

زیادہ تر jobs کے لیے لوگوں کی دی ہوئی context سے کم context کافی ہوتی ہے۔ ایک طویل report کا خلاصہ 16k میں آ سکتا ہے۔ ایسا retrieval front end جو پانچ document chunks شامل کرتا ہے، عموماً 8k سے زیادہ استعمال نہیں کرتا۔ ایسا coding agent جو مکمل files پڑھتا ہے، وہ حقیقی طور پر 64k یا اس سے زیادہ context کا محتاج ہوتا ہے۔ اسی صورت میں machine کی sizing 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 کے درمیان کوئی چیز خود 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 limit نہیں۔