Ollama-তে num_ctx সেট করে দীর্ঘ prompt কাটা রোধ করুন

num_ctx কী করে এবং আপনার দীর্ঘ prompt কেন কেটে গিয়েছিল

Ollama-এর context length হলো একসঙ্গে মেমরিতে লোড করা model যতগুলো token ধরে রাখতে পারে তার সংখ্যা, এবং num_ctx হলো সেটি নির্ধারণকারী option। Ollama এমন একটি default বেছে নেয় যা model-এর ঘোষিত সর্বোচ্চ সীমার তুলনায় অনেক কম। তাই model ইনপুট পড়ার আগেই দীর্ঘ prompt কেটে যায়। উত্তর দেখে এটি ঘটেছে কি না বোঝার কোনো উপায় থাকে না।

Ollama model library-তে Llama 3.1 8B-এর context window 128k হিসেবে উল্লেখ করা আছে। সাধারণ server আপনাকে এই সীমা দেবে না। Ollama-এর নিজস্ব documentation-এ বিভিন্ন page-এ ভিন্ন default দেওয়া আছে: FAQ-তে 4096 token, Modelfile reference-এ num_ctx-এর default 2048, এবং context length page-এ বলা হয়েছে যে default available VRAM (video RAM) অনুযায়ী নির্ধারিত হয়—24 GiB-এর কম হলে 4k, 24 থেকে 48 GiB হলে 32k, এবং এর বেশি হলে 256k। কোনো কোনো build-এ প্রতিটি মানই সত্য ছিল। এখানকার গুরুত্বপূর্ণ শিক্ষা হলো: যেকোনো page-এর তথ্য, এমনকি এই page-এর তথ্যও, অন্ধভাবে বিশ্বাস না করে আপনার চলমান server-এর মান নিজেই পরীক্ষা করুন।

Truncation নীরবে ঘটে, কারণ model তবুও উত্তর দেয় এবং উত্তরটি স্বাভাবিকও শোনায়। তবে সেটি আপনার input-এর শেষাংশের ভিত্তিতে লেখা হয়। কোনো document-এর প্রথম অর্ধেক বাদ পড়া summary-কে দুর্বল model-এর ফল মনে হতে পারে। সাধারণত এর কারণ ছোট context window।

আপনার সার্ভার বাস্তবে প্রয়োগ করা Ollama context length পরীক্ষা করুন

যেকোনো build-এ কাজ করে এমন পরীক্ষা হলো prompt_eval_count। এটি server যে prompt token-গুলো 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 token-এর চেয়ে অনেক বেশি। prompt_eval_count প্রকৃত token count-এর কাছাকাছি না থেকে প্রায় 4096 দেখায়, কারণ server বাকি অংশ বাদ দিয়েছে। এখন "num_ctx":16384 দিয়ে আবার চালান; count বেড়ে যাবে। আপনার build truncation-এর বদলে error ফেরত দিলে, সেটিও একই ফলাফল নির্দেশ করে, শুধু সংকেতটি আরও স্পষ্ট।

ollama ps

যেসব build এই column দেখায়, সেখানে 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 দেখায়। release ভেদে সঠিক wording পরিবর্তিত হয়। তাই line না পাওয়াকে কোনো কিছুর প্রমাণ হিসেবে নয়, বরং নাম পরিবর্তন হিসেবে বিবেচনা করুন।

num_ctx সেট করার চারটি স্থান

অনুরোধে। "options": {"num_ctx": 16384}-কে /api/generate বা /api/chat-এ পাঠান। এটি অন্য সব সেটিংসের ওপর প্রাধান্য পায় এবং শুধু ওই একটি call-এর ক্ষেত্রে প্রযোজ্য হয়। মানটি বর্তমানে loaded model যে মান দিয়ে চলছে তার থেকে আলাদা হলে server প্রথমে model reload করে। Response-এর load_duration-এ এটি দেখা যায়: মানটি প্রায় শূন্য থেকে কয়েক পূর্ণ সেকেন্ডে বেড়ে যায়।

Interactive 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-এ। 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-এর সময় সবচেয়ে গুরুত্বপূর্ণ, বিশেষ করে অন্য কারও client পরীক্ষা করলে। num_ctx বহনকারী request server default-এর ওপর প্রাধান্য পায়। তাই কোনো chat front end বা agent নিজস্ব ছোট মান পাঠালে আপনার systemd পরিবর্তনটি নীরবে অকার্যকর হয়ে যেতে পারে। আপনি যখন একটি coding agent-কে আপনার Ollama server-এর দিকে নির্দেশ করেন, তখন server-কে দোষ দেওয়ার আগে client কী পাঠাচ্ছে তা পরীক্ষা করুন।

কেন শুধু num_ctx মডেলের সর্বোচ্চ মানে সেট করা যায় না

Attention প্রতিটি token-কে তার আগের প্রতিটি token-এর সঙ্গে বিবেচনা করে। আগের token-গুলোর জন্য গণনা করা key ও value পুনরায় গণনা না করার জন্য সংরক্ষণ করা হয়। এই সংরক্ষণস্থলকে 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

এখানে 2 দিয়ে key ও value আলাদা করে গণনা করা হয়েছে। বাকি সংখ্যাগুলো আপনার নিজের মডেল থেকে নিন।

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টি layer এবং 8টি key/value head আছে। head dimension হলো embed-কে heads দিয়ে ভাগ করলে যে মান পাওয়া যায়। তাই এখানে 4096 / 32 = 128। কিছু মডেল এই মানটি সরাসরি llama.attention.key_length হিসেবে প্রকাশ করে। Default cache-এ f16 value রাখা হয়, তাই bytes_per_value হলো 2। ফলে 2 32 8 128 2 = 131,072 byte। অর্থাৎ 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টি row উপরের formula থেকে পাওয়া হিসাব, কোনো measurement নয়। Total column-এ Ollama library 2026 সালের August-এ llama3.1:8b-এর জন্য তালিকাভুক্ত 4.9 GB download যোগ করা হয়েছে। এটি 4.6 GiB-এর সমান। Compute buffer এবং server process-এর memory এতে ধরা হয়নি। তাই এটিকে সর্বনিম্ন হিসাব হিসেবে ধরুন।

মূল বিষয়টি হলো আকারের পরিবর্তন। 8k context-এ cache-এর জন্য 1 GiB লাগে, যা weights-এর তুলনায় খুবই কম। মডেলের পূর্ণ 128k context-এ cache-এর জন্য 16 GiB লাগে। এটি weights-এর তিন গুণেরও বেশি। তখন মোট memory প্রয়োজন প্রায় 20.6 GiB। তাই 4 GB VPS কোনো ব্যবহারযোগ্য context-এ এই মডেল load করতে পারবে না। 8 GB VPS-এ 8k context স্বচ্ছন্দে চালানো যায়। 16 GB VPS-এ বাকি system-এর জন্য memory রেখে 32k context পর্যন্ত যাওয়া যায়। Weights বড় হলে প্রতিটি সীমাও বাড়ে। তাই এই 8B মডেলের তুলনায় বড় মডেল বিবেচনা করলে, 8 থেকে 64 GB-এর মধ্যে context-এর জন্য কত কম memory অবশিষ্ট থাকে তা CPU-only VPS-এ Qwen-এর 27B tag-এর হিসাব থেকে বোঝা যায়।

KV cache-এ স্থান না হলে কী ঘটে

শুধু CPU-ভিত্তিক VPS-এ process-এর memory usage ক্রমাগত বাড়তে থাকে। Model load হওয়ার সময় এবং দীর্ঘ request চলার সময় এটি monitor করুন।

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

RSS (resident set size) kilobyte-এ দেখানো হয়। free -m-এ ব্যবহৃত swap বাড়তে শুরু করলে context কমিয়ে দিন। Swap-এ থাকা KV cache generation-কে প্রতি token-এ কয়েক সেকেন্ডের জন্য থামিয়ে দিতে পারে, কারণ প্রতিটি নতুন token-এর সময় পুরো cache পড়তে হয়।

সার্ভারের memory সম্পূর্ণ শেষ হয়ে গেলে kernel সবচেয়ে বড় process বেছে নিয়ে সেটি বন্ধ করে দেয়।

sudo dmesg | grep -i "killed process"

Out of memory: Killed process 1234 (ollama) লেখা একটি line-এর অর্থ হলো, আপনার চাওয়া context memory-তে fit করেনি। Ollama প্রায়ই এই পর্যায়ে পৌঁছানোর আগেই request প্রত্যাখ্যান করে। তখন request ব্যর্থ হয় এবং message-এ প্রয়োজনীয় memory ও অব্যবহৃত memory-এর পরিমাণ উল্লেখ থাকে।

GPU server-এ এই failure কম স্পষ্টভাবে দেখা যায়। কিছু layer system RAM-এ চলে যায়, ollama ps-এ CPU ও GPU-র বিভাজন দেখা যায়, এবং throughput দ্রুত কমে যায়। কতটা কমবে তা আপনার hardware-এর ওপর নির্ভর করে। তাই অন্য কারও machine-এর figure-এর ওপর নির্ভর না করে প্রতিটি context setting-এ নিজের সার্ভারে প্রতি সেকেন্ডে token-এর হার মাপুন।

Prefill সময় prompt-এর চেয়ে দ্রুত বাড়ে

প্রথম output token আসার আগে আপনার input-এর ওপর যে কাজ করা হয়, সেটিই prefill। প্রতিটি 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-only VPS-এ দীর্ঘ-context request-এর ক্ষেত্রে prefill সাধারণত সবচেয়ে ধীর অংশ। তাই ছোট prompt থেকে পাওয়া tokens per second-এর মান দীর্ঘ prompt-এর ক্ষেত্রে অপেক্ষার সময় পূর্বানুমান করতে পারবে না।

Concurrency-এর ক্ষেত্রে এই সমস্যা সবচেয়ে বেশি দেখা যায়। পরিবেশিত প্রতিটি request-এর জন্য আলাদা cache প্রয়োজন। তাই উপরের chart-এ দেখানো memory প্রতি request-এর জন্য প্রযোজ্য, পুরো server-এর জন্য নয়। একটি দীর্ঘ request server-এর সম্পদ ধরে রাখতে পারে, ফলে ছোট request-গুলো তার পেছনে queue-তে অপেক্ষা করে। OLLAMA_NUM_PARALLEL ইচ্ছাকৃতভাবে নির্ধারণ করুন। একই সঙ্গে উভয় সংখ্যা বাড়ানোর আগে একটি self-hosted LLM কতজন concurrent user পরিবেশন করতে পারে তা জানুন।

ছোট cache ব্যবহার করে context ফিরিয়ে আনুন

bytes_per_value formula-র একটি setting, যা আপনি নিয়ন্ত্রণ করেন। Ollama-এর FAQ-এ OLLAMA_KV_CACHE_TYPE নথিভুক্ত আছে; এর default হলো 2 bytes-এ f16, পাশাপাশি 1 byte-এ q8_0 এবং তার নিচে q4_0। q8_0 ব্যবহার করলে cache অর্ধেক হয়। ফলে 32k row-এর জন্য 4 GiB-এর বদলে 2 GiB লাগে। একই FAQ-এ OLLAMA_FLASH_ATTENTION=1-ও নথিভুক্ত আছে। Quantised cache কার্যকর হওয়ার আগে কিছু build-এ এটি প্রয়োজন হতে পারে।

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

অনুমান না করে নিশ্চিত করুন: service restart করুন, আগের মতো একই num_ctx-এ model load করুন এবং RSS তুলনা করুন। Support model ও backend-এর ওপর নির্ভর করে। তাই কোনো setting-এ পরিবর্তন না হলে আপনার combination সমর্থিত নয়। Documentation-এ এই option-গুলো দেওয়া আছে, তবে এতে quality ফল নিশ্চিত করা হয়নি। তাই এর ওপর নির্ভর করার আগে নিজের prompt দিয়ে q4_0 পরীক্ষা করুন। আপনি যদি এই knob-গুলোর কারণেই এখানে এসে থাকেন, Ollama এবং llama.cpp এগুলো ভিন্নভাবে প্রকাশ করে।

num_ctx নির্ধারণের পদ্ধতি

1. /api/show থেকে মডেলের সর্বোচ্চ context, layer-এর সংখ্যা এবং key/value head-এর সংখ্যা দেখুন।
2. সূত্র ব্যবহার করে প্রতি token-এর জন্য প্রয়োজনীয় byte হিসাব করুন, তারপর এটিকে আপনার প্রয়োজনীয় context-এর সঙ্গে গুণ করুন।
3. এর সঙ্গে weight-এর আকার যোগ করুন, free RAM-এর সঙ্গে তুলনা করুন এবং সার্ভারের অন্যান্য কাজের জন্য অন্তত 1 GiB RAM খালি রাখুন।
4. মানটি সেট করে মডেল load করুন। এরপর ollama ps এবং prompt_eval_count ব্যবহার করে প্রয়োগ করা মান নিশ্চিত করুন।
5. free -m monitor করার সময় বাস্তব workload চালান। swap ব্যবহার শুরু হলে context অর্ধেক করে দিন।

বেশিরভাগ কাজের জন্য মানুষ যে পরিমাণ context দেয়, তার চেয়ে কম context যথেষ্ট। একটি দীর্ঘ report summarise করতে 16k যথেষ্ট। পাঁচটি document chunk যুক্ত করা একটি retrieval front end-এ সাধারণত 8k-এর বেশি প্রয়োজন হয় না। পুরো file পড়ে এমন coding agent-এর ক্ষেত্রে সত্যিই 64k বা তার বেশি প্রয়োজন হতে পারে। এই পরিস্থিতিতে context-এর ভিত্তিতে machine-এর capacity নির্ধারণ করা উচিত, machine-এর capacity অনুযায়ী context নয়। server-টি যদি এখনও নতুন হয়, তাহলে VPS-এ কার্যকর Ollama install দিয়ে শুরু করুন এবং মডেল cleanly load হওয়ার পরে context tune করুন।

FAQ

Ollama-তে ডিফল্ট context length কত?

এটি build এবং hardware-এর ওপর নির্ভর করে। তাই অনুমান না করে যাচাই করুন। Ollama-এর FAQ-তে 4096 tokens নথিভুক্ত আছে, Modelfile reference-এ num_ctx-এর ডিফল্ট 2048 নথিভুক্ত আছে, এবং context length page-এ available VRAM অনুযায়ী ডিফল্ট নির্ধারণের কথা বলা হয়েছে: 24 GiB-এর নিচে 4k, 24 থেকে 48 GiB পর্যন্ত 32k, এবং এর বেশি হলে 256k। CPU-only VPS সাধারণত ছোট সীমার দিকেই থাকে। যে build-এ এই column আছে, সেখানে ollama ps প্রয়োগ করা context দেখায়। প্রতিটি build-এ API response-এর prompt_eval_count মানটি এটি নিশ্চিত করে।

Ollama আমার দীর্ঘ prompt-এর শুরুর অংশ উপেক্ষা করে কেন?

কারণ prompt-টি context window-এর চেয়ে বড় ছিল। তাই model এটি পাওয়ার আগেই server prompt-টি কেটে দিয়েছে, কিন্তু কোনো error ফেরত দেয়নি। একই prompt আবার বড় num_ctx সহ পাঠান এবং response-এ prompt_eval_count-এর মান বাড়ছে কি না দেখুন। ওই সংখ্যা না বদলালে আপনার ও server-এর মাঝের কোনো উপাদান নিজেই num_ctx নির্ধারণ করছে। Chat front end এবং agent framework-এ এটি সাধারণ ঘটনা।

বড় num_ctx-এর জন্য অতিরিক্ত RAM কত লাগবে?

Context length-কে প্রতি token cache cost দিয়ে গুণ করুন। এই cost হলো 2 * layers * kv_heads * head_dim * bytes_per_value। f16-এ Llama 3.1 8B-এর ক্ষেত্রে প্রতি token-এর জন্য এটি 128 KiB। তাই 32k tokens-এর জন্য weights-এর অতিরিক্ত 4 GiB এবং সম্পূর্ণ 128k-এর জন্য 16 GiB লাগে। Model load হওয়ার সময় cache allocate করা হয়। তাই prompt ছোট থাকলেও বড় num_ctx-এর জন্য ওই পরিমাণ memory লাগে।

বড় context window কি Ollama-কে ধীর করে?

হ্যাঁ, দুটি কারণে। Prompt length-এর বর্গের সঙ্গে prefill work বাড়ে। তাই দীর্ঘ input-এর ক্ষেত্রে প্রথম token পেতে prompt-এর দৈর্ঘ্য দেখে যতটা সময় প্রত্যাশা করা হয়, তার চেয়ে বেশি সময় লাগে। বড় cache-ও memory-এর জন্য প্রতিযোগিতা করে। GPU box-এ এটি layer-গুলোকে system RAM-এ সরিয়ে দিতে পারে। CPU box-এ এটি 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 কোনো option না পাঠিয়েই ওই context পাবে। তবে নিজের num_ctx বহনকারী request-এর অগ্রাধিকার থাকবে। তাই এটি default নির্ধারণ করে, সর্বোচ্চ সীমা নয়।