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

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

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

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

Truncation அமைதியாக நடக்கும், ஏனெனில் model தொடர்ந்து பதிலளிக்கும், அந்தப் பதிலும் சரியாகவே வாசிக்கக்கூடியதாக இருக்கும். அது உங்கள் input-ன் இறுதிப் பகுதியிலிருந்து எழுதப்பட்டிருக்கும். ஒரு ஆவணத்தின் முதல் பாதியைத் தவிர்த்துவிட்டுச் சுருக்கம் அளித்தால், அது பலவீனமான 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, அதை அச்சிடும் builds-ல், தற்போது இயங்கும் 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 அளவை n_ctx அடங்கிய வரியில் அச்சிடுகிறது. ஒவ்வொரு release-க்கும் இதன் வாசகம் மாறுபடலாம், எனவே ஒரு வரி விடுபட்டிருந்தால், அது ஏதோ ஒரு மாற்றத்தின் காரணமாக இருக்கலாம் என்று கருதுங்கள், அதை ஒரு ஆதாரமாக எடுத்துக்கொள்ள வேண்டாம்.

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

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

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

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

Attention mechanism-ல் ஒவ்வொரு token-ம் தனக்கு முன்னால் உள்ள அனைத்து token-களையும் கவனிக்கிறது. முந்தைய token-களுக்காக கணக்கிடப்பட்ட keys மற்றும் values-கள் மீண்டும் கணக்கிடப்படுவதைத் தவிர்க்கச் சேமிக்கப்படுகின்றன; இந்தச் சேமிப்பகம் தான் KV cache (key/value cache). இது model ஏற்றப்படும்போதே முழு 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. சில model-கள் இதை நேரடியாக llama.attention.key_length என்று குறிப்பிடுகின்றன. இயல்புநிலை cache f16 மதிப்புகளைச் சேமிக்கிறது, எனவே bytes_per_value என்பது 2 ஆகும். 2 32 8 128 2 என்பது 131,072 bytes-ஆகிறது. அதாவது, ஒவ்வொரு ஒரு token context-க்கும் 128 KiB cache தேவைப்படுகிறது. இதை context நீளத்துடன் பெருக்கும்போது, அதன் செலவு வெறும் கோட்பாடு மட்டுமல்ல என்பது புரியும்.

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

server-ன் memory முழுமையாகத் தீர்ந்துவிட்டால், kernel மிகப்பெரிய 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-ஐப் பொறுத்தது, எனவே மற்றவர்களின் machine-ல் உள்ள அளவுகளை நம்புவதை விட, ஒவ்வொரு context அமைப்பிலும் உங்கள் server-ல் tokens per second-ஐ அளவிடவும்.

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

முதல் output token தோன்றுவதற்கு முன்பு, உங்கள் input-ல் செய்யப்படும் வேலையே Prefill ஆகும். ஒவ்வொரு prompt token-ம் தனக்கு முன்னால் உள்ள அனைத்து token-களையும் கவனிக்க வேண்டியிருப்பதால், மொத்த வேலையும் input நீளத்தின் வர்க்கத்திற்கு (square) ஏற்ப அதிகரிக்கிறது. 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 கொண்டு இயக்கி, ஒவ்வொரு முறையும் வினாடிக்கு எத்தனை token-கள் என்பதை கணக்கிடுங்கள். CPU-மட்டும் கொண்ட VPS-ல், நீண்ட context கொண்ட கோரிக்கைகளில் Prefill பகுதியே மிக மெதுவாக இருக்கும். எனவே, சிறிய prompt-ல் கிடைக்கும் tokens per second அளவு, நீண்ட prompt-க்கு சரியாக இருக்காது.

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-ஆக இயல்பாக உள்ளது, மேலும் q8_0 என்பது 1 byte-ஆகவும், q4_0 என்பது அதற்கும் குறைவாகவும் உள்ளது. q8_0-க்கு மாறுவது cache-ஐ பாதியாகக் குறைக்கும், எனவே 32k row என்பது 4 GiB-க்கு பதிலாக 2 GiB-ஆகக் குறையும். அதே FAQ OLLAMA_FLASH_ATTENTION=1-ஐயும் குறிப்பிடுகிறது, சில build-கள் quantised cache செயல்படுவதற்கு முன்பாக இதை எதிர்பார்க்கின்றன.

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

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

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

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

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

FAQ

Ollama-வில் இயல்பான (default) context length என்ன?

இது build மற்றும் hardware-ஐப் பொறுத்தது, எனவே ஊகிப்பதற்குப் பதிலாகச் சரிபார்க்கவும். Ollama-வின் FAQ 4096 tokens என்று குறிப்பிடுகிறது, Modelfile குறிப்பு num_ctx இயல்பான அளவாக 2048-ஐக் குறிப்பிடுகிறது, மேலும் context length பக்கம் கிடைக்கக்கூடிய VRAM-ஐப் பொறுத்து ஒரு இயல்பான அளவைத் தேர்வு செய்வதாகக் கூறுகிறது: 24 GiB-க்குக் குறைவாக இருந்தால் 4k, 24 முதல் 48 GiB வரை இருந்தால் 32k, மற்றும் அதற்கு மேல் இருந்தால் 256k. CPU-மட்டும் கொண்ட VPS சிறிய அளவிலேயே இயங்கும். ollama ps அந்த வசதியைக் கொண்ட build-களில் பயன்படுத்தப்பட்ட context-ஐ அச்சிடும், மேலும் prompt_eval_count அனைத்து build-களிலும் API response-ல் அதை உறுதிப்படுத்தும்.

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

ஏனெனில் prompt, context window-வை விட நீளமாக இருந்தது, எனவே model-க்குச் செல்லும் முன்பே server அதை வெட்டிவிட்டது, எந்தப் பிழையும் திரும்ப வரவில்லை. அதே 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 ஆகும். Llama 3.1 8B (f16) மாடலுக்கு ஒரு token-க்கு 128 KiB தேவைப்படும், எனவே 32k tokens-க்கு 4 GiB-ம், முழு 128k-க்கு weights-க்கு மேலதிகமாக 16 GiB-ம் தேவைப்படும். 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 இருந்தால் அதுவே முன்னுரிமை பெறும், எனவே இது ஒரு உச்சவரம்பை (ceiling) விட, ஒரு இயல்பான அமைப்பை (default) உருவாக்குகிறது.