Ollama-வில் num_ctx அமைப்பது எப்படி? நீண்ட Prompt சிக்கல்

num_ctx என்ன செய்கிறது மற்றும் உங்கள் நீண்ட prompt ஏன் துண்டிக்கப்பட்டது

Ollama context length என்பது ஒரு loaded model ஒரே நேரத்தில் நினைவகத்தில் (memory) வைத்திருக்கக்கூடிய tokens-ன் எண்ணிக்கை ஆகும். num_ctx என்பது இதை அமைப்பதற்கான option ஆகும். Ollama ஒரு default மதிப்பைத் தேர்ந்தெடுக்கிறது; இது அந்த model குறிப்பிடும் அதிகபட்ச அளவை விட மிகக் குறைவானது. எனவே, ஒரு நீண்ட prompt-ஐ model படிப்பதற்கு முன்பே அது துண்டிக்கப்படுகிறது. இது நடந்ததை எந்தப் பதிலும் உங்களுக்குத் தெரிவிக்காது.

Ollama model library-ல் Llama 3.1 8B-க்கு 128k context window இருப்பதாகக் குறிப்பிடப்பட்டுள்ளது. ஒரு stock server உங்களுக்கு அந்த அளவை வழங்காது. Ollama-வின் சொந்த ஆவணங்கள் வெவ்வேறு பக்கங்களில் வெவ்வேறு default மதிப்புகளைக் கொண்டுள்ளன: FAQ-வில் 4096 tokens என்றும், Modelfile குறிப்பில் num_ctx-க்கு 2048 default என்றும், context length பக்கத்தில் கிடைக்கக்கூடிய VRAM-ஐப் பொறுத்து default அமையும் என்றும் கூறப்பட்டுள்ளது (24 GiB-க்குக் கீழே 4k, 24 முதல் 48 GiB வரை 32k, அதற்கு மேல் 256k). இவை ஒவ்வொன்றும் ஏதோ ஒரு build-ல் உண்மையாக இருந்தவை. இந்த முரண்பாடே இங்குள்ள முக்கியமான பாடம்: எந்தப் பக்கத்தையும், இதையும் சேர்த்து, நம்புவதற்குப் பதிலாக, உங்கள் server-ல் இயங்கும் மதிப்பை நீங்களே சரிபார்க்கவும்.

இந்தத் துண்டிப்பு அமைதியாக நடக்கும், ஏனெனில் model தொடர்ந்து பதிலளிக்கும், அந்தப் பதிலும் சரியாகவே இருக்கும். அது உங்கள் உள்ளீட்டின் இறுதிப் பகுதியிலிருந்து எழுதப்பட்டிருக்கும். ஒரு ஆவணத்தின் முதல் பாதியைத் தவிர்த்துவிட்டுச் சுருக்கம் அளித்தால், அது பலவீனமான model போலத் தோன்றும். இது பெரும்பாலும் சிறிய context window-வினால் ஏற்படும் விளைவாகும்.

உங்கள் server-ல் நடைமுறையில் உள்ள Ollama context length-ஐச் சரிபார்த்தல்

எந்தவொரு build-லும் வேலை செய்யும் சரிபார்ப்பு முறை prompt_eval_count ஆகும்; இது server செயலாக்கிய prompt tokens-ன் எண்ணிக்கையைக் காட்டுகிறது. context கொள்ளளவை விட அதிகமான தரவை அனுப்பினால், அந்த எண்ணிக்கை குறிப்பிட்ட வரம்பில் நின்றுவிடும்.

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 எண்ணிக்கைக்குப் பதிலாக 4096-க்கு அருகிலேயே முடிவுகளைத் தரும், ஏனெனில் server மீதமுள்ளவற்றை நீக்கிவிட்டது. இதை "num_ctx":16384 உடன் மீண்டும் இயக்கினால், எண்ணிக்கை உயரும். உங்கள் build தரவை நீக்குவதற்குப் பதிலாக error-ஐக் காட்டினால், அதுவும் அதே முடிவைத்தான் உறுதிப்படுத்துகிறது, ஆனால் கூடுதல் எச்சரிக்கையுடன்.

ollama ps

CONTEXT நிரல் (column), அதை அச்சிடும் build-களில், தற்போது இயங்கும் model-ன் context length-ஐக் காட்டுகிறது. அதற்கு அருகிலுள்ள PROCESSOR நிரல், 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 அளவை n_ctx அடங்கிய வரியில் அச்சிடுகிறது. ஒவ்வொரு release-க்கும் இதன் வாசகம் மாறக்கூடும், எனவே இந்த வரி இல்லை என்றால், அது ஏதோ ஒரு பிழை என்று கருதாமல், பெயர் மாற்றப்பட்டிருக்கலாம் என்று கருதுங்கள்.

num_ctx-ஐ அமைப்பதற்கான நான்கு இடங்கள்

கோரிக்கையில் (In the request). "options": {"num_ctx": 16384}-ஐ /api/generate அல்லது /api/chat-க்கு அனுப்பவும். இது மற்ற அனைத்து அமைப்புகளையும் விட முன்னுரிமை பெறும், மேலும் இது அந்த ஒரு குறிப்பிட்ட அழைப்பிற்கு மட்டுமே பொருந்தும். ஏற்றப்பட்டிருக்கும் model இயங்கும் மதிப்பை விட இந்த மதிப்பு வேறாக இருந்தால், server முதலில் model-ஐ மீண்டும் ஏற்றும். இதை பதிலில் உள்ள load_duration-ல் நீங்கள் காணலாம்: அது பூஜ்ஜியத்திற்கு அருகில் இருந்து சில நொடிகள் வரை உயரும். model நீண்ட நேரம் செயலற்று இருந்து, தானாகவே நீக்கப்பட்ட பிறகும் இதே காத்திருப்பு நேரம் ஏற்படும். எனவே, ஒரு context அளவை நீங்கள் முடிவு செய்தவுடன், keep_alive மூலம் model-ஐ நினைவகத்தில் வைத்திருப்பது நல்லது.

ஊடாடும் அமர்வில் (In the interactive session). ollama run-க்குள், /set parameter num_ctx 16384 எனத் தட்டச்சு செய்யவும். இது அந்த அமர்வுக்கு மட்டுமே நீடிக்கும்.

Modelfile-ல். இது அந்த மதிப்பை ஒரு பெயரிடப்பட்ட model-க்குள் பதித்துவிடும், எனவே client-ல் எந்த மாற்றமும் செய்யாமலேயே அனைத்து 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 என்பது, சொந்தமாக 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

நீங்கள் மற்றவர்களின் client-ஐ பிழைத்திருத்தம் (debug) செய்யும்போது, இந்த முன்னுரிமை வரிசை மிக முக்கியமானது. num_ctx-ஐக் கொண்ட ஒரு கோரிக்கை, server-ன் இயல்புநிலை அமைப்பை விட முன்னுரிமை பெறும். எனவே, ஒரு chat front end அல்லது ஒரு agent தனது சொந்த சிறிய மதிப்பை அனுப்பினால், அது உங்கள் systemd மாற்றத்தை அமைதியாக நீக்கிவிடும். நீங்கள் ஒரு coding agent-ஐ உங்கள் Ollama server-க்கு இணைக்கும்போது, server-ஐக் குறை கூறுவதற்கு முன்பு அந்த client என்ன அனுப்புகிறது என்பதைச் சரிபார்க்கவும்.

num_ctx-ஐ ஏன் model-ன் அதிகபட்ச அளவிற்கு மட்டும் அமைக்க முடியாது

Attention mechanism-ல் ஒவ்வொரு token-ம் அதற்கு முன்னால் உள்ள அனைத்து token-களையும் கவனிக்க வேண்டும். முந்தைய token-களுக்காக கணக்கிடப்பட்ட keys மற்றும் values-கள் மீண்டும் கணக்கிடப்படாமல் சேமிக்கப்படுகின்றன; இந்த சேமிப்பகம் தான் KV cache (key/value cache). இது model load ஆகும்போது முழு num_ctx-க்கும் ஒதுக்கீடு செய்யப்படுகிறது, உரையாடல் வளரும்போது ஒதுக்கப்படுவதில்லை. எனவே, ஒரு சிறிய prompt-க்கு கூட பெரிய context அளவு அதிக நினைவகத்தை (memory) எடுத்துக்கொள்ளும்.

DigitalOcean-ன் 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. சில மாடல்கள் இதை நேரடியாக llama.attention.key_length என்று குறிப்பிடுகின்றன. இயல்புநிலை cache f16 மதிப்புகளைக் கொண்டிருப்பதால், bytes_per_value என்பது 2 ஆகும். எனவே, 2 32 8 128 2 = 131,072 bytes. அதாவது, ஒவ்வொரு single token context-க்கும் 128 KiB cache தேவைப்படுகிறது. இதை 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 வரிசைகள் மேலே உள்ள சூத்திரத்தின் அடிப்படையில் கணக்கிடப்பட்டவை, அளவீடுகள் அல்ல. மொத்தக் கூடுதல் நெடுவரிசையில் (total column), ஆகஸ்ட் 2026-ல் Ollama library llama3.1:8b-க்குக் குறிப்பிட்ட 4.9 GB (அதாவது 4.6 GiB) பதிவிறக்க அளவு சேர்க்கப்பட்டுள்ளது. இதில் compute buffers மற்றும் server process-ன் தேவை சேர்க்கப்படவில்லை. இதை ஒரு குறைந்தபட்ச அளவாகக் கருதவும்.

இதன் வடிவம் தான் முக்கியமானது. 8k context-ல் cache-ன் விலை 1 GiB, இது model weights-உடன் ஒப்பிடும்போது மிகக் குறைவு. ஆனால் model-ன் முழுமையான 128k context-ல் இது 16 GiB-ஆக உயர்கிறது. இது weights-ஐ விட மூன்று மடங்கு அதிகம், மொத்தமாக 20.6 GiB-க்கு அருகில் செல்கிறது. எனவே, 4 GB VPS-ல் இந்த model-ஐ எந்தவொரு பயனுள்ள context அளவிலும் இயக்க முடியாது. 8 GB VPS-ல் 8k context-ஐ தாராளமாக இயக்கலாம். 16 GB VPS-ல் 32k context வரை செல்லலாம், மீதமுள்ள நினைவகம் பிற தேவைகளுக்குப் பயன்படும். இந்த ஒவ்வொரு எல்லையும் model weights-ன் அளவிற்கு ஏற்ப மாறும். எனவே, 8B model-ஐ விடப் பெரிய model-ஐப் பயன்படுத்தும்போது, Qwen 27B-ஐ CPU-only VPS-ல் இயக்குவது குறித்த கணக்கீடுகளைப் பார்த்தால், 8 GB முதல் 64 GB RAM-க்குள் context-க்கு எவ்வளவு குறைந்த இடமே மிஞ்சுகிறது என்பது விளங்கும்.

KV cache கொள்ளளவு போதாதபோது என்ன நடக்கும்

CPU-மட்டும் கொண்ட VPS-ல், process-ன் அளவு தொடர்ந்து அதிகரிக்கும். model 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, ஒவ்வொரு token-க்கும் முழு cache-ஐயும் வாசிப்பதால், generation செயல்முறை ஒவ்வொரு token-க்கும் பல நொடிகள் தாமதமாகும்.

server-ன் memory முழுமையாகத் தீர்ந்துவிட்டால், kernel அதிக memory-ஐப் பயன்படுத்தும் process-ஐத் தேர்ந்தெடுத்து அதை நிறுத்திவிடும் (kill).

sudo dmesg | grep -i "killed process"

Out of memory: Killed process 1234 (ollama) என்று ஒரு வரி வந்தால், நீங்கள் கேட்ட context அளவு பொருந்தவில்லை என்று பொருள். Ollama பெரும்பாலும் அந்த நிலைக்குச் செல்லும் முன்பே மறுத்துவிடும்; அப்போது தேவைப்படும் memory அளவு மற்றும் தற்போதுள்ள memory அளவு ஆகியவற்றைத் தெரிவித்து request தோல்வியடையும்.

GPU உள்ள server-ல் இந்தத் தோல்வி அமைதியாக நடக்கும். Layers system RAM-க்கு நகர்த்தப்படும், ollama ps CPU மற்றும் GPU பிரிவினையைக் காட்டும், மேலும் throughput கடுமையாகக் குறையும். இது உங்கள் hardware-ஐப் பொறுத்தது, எனவே மற்றவர்களின் கணினித் தரவுகளை நம்புவதை விட, ஒவ்வொரு context அமைப்பிலும் உங்கள் கணினியில் tokens per second-ஐ அளவிடவும்.

Prefill நேரம் prompt-ஐ விட வேகமாக அதிகரிக்கிறது

முதல் output token தோன்றுவதற்கு முன்பு, உங்கள் input-ல் செய்யப்படும் வேலையே prefill ஆகும். ஒவ்வொரு prompt token-ம் தனக்கு முன்னால் உள்ள அனைத்து token-களையும் கவனிப்பதால், மொத்த வேலையும் input நீளத்தின் வர்க்கத்திற்கு (square) ஏற்ப அதிகரிக்கிறது. Prompt-ன் அளவை இருமடங்கு ஆக்கினால், முதல் token-க்காக காத்திருக்கும் நேரம் இருமடங்கை விட அதிகமாகும்.

பதிலிலேயே அளவீடு இருப்பதால், நீங்கள் அதை அப்படியே நம்ப வேண்டியதில்லை.

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-இன் செயல்திறனை முன்கூட்டியே கணிக்காது. முன்புறத்தில் உள்ள ஏதேனும் timeout காலத்தைவிட prefill நீண்டால், நீண்ட prompt-க்கு பதிலாக context deadline exceeded திரும்புவது வழக்கமாகும். ஆகவே context-ஐக் குறைப்பதற்கு முன், எந்த layer கைவிட்டது என்பதை கண்டறியவும்.

Concurrency-ல் தான் இது அதிக பாதிப்பை ஏற்படுத்துகிறது. சேவை செய்யப்படும் ஒவ்வொரு கோரிக்கைக்கும் தனித்தனி cache தேவைப்படுகிறது. எனவே, மேலே உள்ள வரைபடத்தில் உள்ள memory என்பது server-க்கு அல்ல, ஒவ்வொரு கோரிக்கைக்கும் உரியது. ஒரு நீண்ட கோரிக்கை server-ஐ ஆக்கிரமித்துக்கொண்டால், சிறிய கோரிக்கைகள் வரிசையில் காத்திருக்க வேண்டியிருக்கும். OLLAMA_NUM_PARALLEL-ஐ கவனமாக அமைக்கவும். இரண்டையும் ஒரே நேரத்தில் அதிகரிப்பதற்கு முன்பு ஒரு self-hosted LLM எத்தனை concurrent பயனர்களுக்கு சேவை செய்ய முடியும் என்பதைப் படிக்கவும்.

சிறிய cache மூலம் context-ஐ மீண்டும் பெறுதல்

சூத்திரத்தில் உள்ள bytes_per_value என்பது நீங்கள் கட்டுப்படுத்தும் ஒரு அமைப்பாகும். Ollama-வின் FAQ OLLAMA_KV_CACHE_TYPE பற்றி விளக்குகிறது; இதில் f16 என்பது 2 bytes-ஆக இயல்பாக (default) உள்ளது, மேலும் q8_0 என்பது 1 byte-ஆகவும், q4_0 என்பது அதற்கும் குறைவாகவும் உள்ளது. q8_0-க்கு மாறுவது cache-ன் அளவை பாதியாகக் குறைக்கும், எனவே 32k row என்பது 4 GiB-க்கு பதிலாக 2 GiB-ஆகக் குறையும். Weights-ஐ quantise செய்வது அதே பட்ஜெட்டின் மறுபக்கத்திலிருந்து நினைவகத்தை (memory) விடுவிக்கிறது, மேலும் VPS-ல் பொருந்தக்கூடிய GLM tag என்பது நீங்கள் விரும்பும் மாற்றத்தைப் பொறுத்து, quantisation மூலம் படிப்படியாகச் செயல்படுத்தப்படுகிறது. அதே FAQ OLLAMA_FLASH_ATTENTION=1 பற்றி குறிப்பிடுகிறது, இது quantised cache செயல்படுவதற்கு முன்னதாக சில builds-க்குத் தேவைப்படுகிறது.

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

ஊகிப்பதற்குப் பதிலாக உறுதிப்படுத்தவும்: service-ஐ restart செய்து, மாதிரியை (model) முன்பிருந்த அதே num_ctx-ல் load செய்து, RSS-ஐ ஒப்பிட்டுப் பார்க்கவும். ஆதரவு என்பது model மற்றும் backend-ஐப் பொறுத்தது, எனவே ஒரு அமைப்பை மாற்றியும் எந்த மாற்றமும் இல்லை என்றால், உங்கள் கலவை (combination) இதற்கு உட்பட்டது அல்ல என்று அர்த்தம். ஆவணங்கள் இந்த விருப்பங்களை பட்டியலிடுகின்றன, ஆனால் தரமான முடிவுகளை உறுதிப்படுத்தவில்லை, எனவே நீங்கள் அவற்றை நம்புவதற்கு முன்பு உங்கள் சொந்த prompts-ஐக் கொண்டு q4_0-ஐச் சோதிக்கவும். இந்த அமைப்புகள் தான் நீங்கள் இங்கு வந்ததற்கான காரணம் என்றால், Ollama மற்றும் llama.cpp இவற்றை வெவ்வேறு விதமாக வெளிப்படுத்துகின்றன.

num_ctx-ஐத் தேர்ந்தெடுப்பதற்கான வழிமுறை

1. /api/show-லிருந்து மாதிரியின் (model) அதிகபட்ச context, அதன் layer எண்ணிக்கை மற்றும் key/value head எண்ணிக்கை ஆகியவற்றை வாசிக்கவும்.
2. கொடுக்கப்பட்ட சூத்திரத்தைப் பயன்படுத்தி ஒரு token-க்கான bytes அளவைக் கணக்கிட்டு, உங்களுக்குத் தேவையான context அளவால் பெருக்கவும்.
3. இதனுடன் weight அளவைக் கூட்டி, இருக்கும் இலவச RAM-உடன் ஒப்பிடவும்; கணினியின் பிற செயல்பாடுகளுக்காகக் குறைந்தது 1 GiB RAM-ஐ ஒதுக்கி வைக்கவும்.
4. மதிப்பை அமைத்து, மாதிரியை ஏற்றி (load), ollama ps மற்றும் prompt_eval_count மூலம் என்ன அளவு பயன்படுத்தப்பட்டது என்பதை உறுதிப்படுத்தவும்.
5. உங்கள் உண்மையான பணிச்சுமையை (workload) இயக்கும்போது free -m-ஐக் கவனிக்கவும்; swap பயன்பாடு தொடங்கினால் context அளவை பாதியாகக் குறைக்கவும்.

பெரும்பாலான பணிகளுக்கு மக்கள் ஒதுக்குவதை விடக் குறைவான context-ஏ போதுமானது. ஒரு நீண்ட அறிக்கையைச் சுருக்க 16k போதுமானது. ஐந்து ஆவணத் துண்டுகளை இணைக்கும் retrieval front end அரிதாகவே 8k-ஐத் தாண்டும். முழு கோப்புகளையும் வாசிக்கும் coding agent-க்கு மட்டுமே 64k அல்லது அதற்கு மேற்பட்ட அளவு தேவைப்படும்; அத்தகைய சூழலில், context-க்கு ஏற்ப கணினியின் அளவைத் தீர்மானிக்க வேண்டும். server புதியது என்றால், Ollama-வை VPS-ல் நிறுவுதல் என்ற வழிகாட்டியில் தொடங்கி, மாதிரிகள் சரியாக ஏற்றப்பட்ட பிறகு context-ஐச் சீரமைக்கவும்.

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-ல் இது குறைந்த அளவிலேயே இருக்கும். ollama ps அந்த வசதியைக் கொண்ட build-களில் பயன்படுத்தப்பட்ட context-ஐக் காட்டும், மேலும் ஒவ்வொரு build-லும் API response-ல் உள்ள prompt_eval_count இதை உறுதிப்படுத்தும்.

எனது நீண்ட prompt-ன் தொடக்கத்தை Ollama ஏன் புறக்கணிக்கிறது?

ஏனெனில் prompt-ன் நீளம் context window-ஐ விட அதிகமாக இருந்தது, எனவே model-க்குச் செல்லும் முன்பே server அதை வெட்டிவிட்டது, இதற்காக எந்த error-ம் திரும்ப வரவில்லை. அதே prompt-ஐ அதிக num_ctx உடன் மீண்டும் அனுப்பவும், response-ல் prompt_eval_count அதிகரிப்பதைக் கவனிக்கவும். அந்த எண் மாறவில்லை என்றால், உங்களுக்கும் 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-க்கு 4 GiB-ம், முழு 128k-க்கு 16 GiB-ம் weights-க்கு மேலதிகமாகத் தேவைப்படும். Model load ஆகும்போது cache ஒதுக்கப்படுவதால், உங்கள் prompt-கள் சிறியதாக இருந்தாலும் பெரிய num_ctx அந்த நினைவகத்தை எடுத்துக்கொள்ளும்.

பெரிய context window Ollama-வை மெதுவாக்குமா?

ஆம், இரண்டு வழிகளில். Prefill வேலை prompt-ன் நீளத்தின் வர்க்கத்திற்கு ஏற்ப (square of the prompt length) அதிகரிக்கும், எனவே நீண்ட input முதல் token-ஐ அதன் நீளம் உணர்த்துவதை விட அதிக தாமதப்படுத்தும். பெரிய cache நினைவகத்திற்காகப் போட்டியிடும்: GPU உள்ள கணினியில் இது layers-ஐ system RAM-க்குத் தள்ளும், CPU உள்ள கணினியில் இது machine-ஐ swap-ஐ நோக்கித் தள்ளும். நீங்கள் பயன்படுத்தாத பெரிய num_ctx நினைவகத்தை எடுத்துக்கொள்ளும், ஆனால் அது 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-ஐப் பெறும். ஒரு request-ல் அதன் சொந்த num_ctx இருந்தால் அதுவே முன்னுரிமை பெறும், எனவே இது ஒரு உச்சவரம்பை விட default அளவையே அமைக்கிறது.