วิธีตั้งค่า num_ctx ใน Ollama เพื่อขยาย Context Window

num_ctx ทำหน้าที่อะไร และเหตุใด prompt ที่ยาวของคุณจึงถูกตัด

ค่า context length ของ Ollama คือจำนวนโทเค็นที่โมเดลที่โหลดอยู่สามารถเก็บไว้ในหน่วยความจำได้พร้อมกัน และ num_ctx คือตัวเลือกที่ใช้กำหนดค่านี้ Ollama จะเลือกค่าเริ่มต้นที่ต่ำกว่าค่าสูงสุดที่โมเดลระบุไว้มาก ดังนั้น prompt ที่ยาวเกินไปจะถูกตัดออกก่อนที่โมเดลจะอ่านถึง และไม่มีข้อความใดในคำตอบที่แจ้งให้คุณทราบว่าเกิดเหตุการณ์นี้ขึ้น

Llama 3.1 8B ถูกระบุว่ามี context window ขนาด 128k ในคลังโมเดลของ Ollama แต่เซิร์ฟเวอร์ทั่วไปจะไม่ให้ค่านี้แก่คุณ เอกสารของ Ollama เองระบุค่าเริ่มต้นที่แตกต่างกันในแต่ละหน้า โดย FAQ ระบุว่า 4096 โทเค็น, ข้อมูลอ้างอิง Modelfile ระบุว่า num_ctx มีค่าเริ่มต้นที่ 2048 และ หน้า context length ระบุว่าค่าเริ่มต้นจะถูกเลือกจาก VRAM (video RAM) ที่มีอยู่ คือ 4k สำหรับ VRAM ต่ำกว่า 24 GiB, 32k สำหรับ 24 ถึง 48 GiB และ 256k สำหรับที่มากกว่านั้น แต่ละค่าเคยเป็นค่าจริงในบางเวอร์ชัน ความไม่สอดคล้องกันนี้คือบทเรียนสำคัญ: ให้ตรวจสอบค่าจากเซิร์ฟเวอร์ที่คุณใช้งานอยู่จริง แทนที่จะเชื่อข้อมูลในหน้าเว็บใดๆ รวมถึงหน้านี้ด้วย

การตัดข้อความเกิดขึ้นอย่างเงียบเชียบเพราะโมเดลยังคงตอบกลับและคำตอบยังคงอ่านรู้เรื่อง โดยคำตอบนั้นถูกเขียนขึ้นจากส่วนท้ายของข้อมูลที่คุณป้อนเข้าไป การสรุปความที่ขาดเนื้อหาครึ่งแรกของเอกสารอาจทำให้ดูเหมือนเป็นโมเดลที่ไม่มีประสิทธิภาพ ซึ่งโดยปกติแล้วมักเกิดจากขนาด context window ที่เล็กเกินไป

ตรวจสอบความยาว context ที่ Ollama ใช้งานจริงบนเซิร์ฟเวอร์ของคุณ

วิธีตรวจสอบที่ใช้ได้กับทุก build คือการดู prompt_eval_count ซึ่งเป็นจำนวน token ของ prompt ที่เซิร์ฟเวอร์รายงานว่าประมวลผลไปแล้ว หากส่งข้อมูลที่มีขนาดเกินกว่าที่ 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 token ไปมาก ค่า prompt_eval_count ที่ได้กลับมาจะใกล้เคียงกับ 4096 แทนที่จะเป็นจำนวน token จริง เนื่องจากเซิร์ฟเวอร์ตัดส่วนที่เกินออกไป ให้ลองรันคำสั่งอีกครั้งด้วย "num_ctx":16384 แล้วจำนวนจะเพิ่มขึ้น หาก build ของคุณแสดงข้อผิดพลาดแทนที่จะตัดทอนข้อมูล นั่นถือเป็นผลลัพธ์ที่ยืนยันได้ชัดเจนเช่นเดียวกัน

ollama ps

คอลัมน์ CONTEXT ใน build ที่แสดงผลข้อมูลนี้ จะระบุความยาวของ context ที่โมเดลที่โหลดอยู่กำลังใช้งานในขณะนั้น ส่วนคอลัมน์ PROCESSOR ที่อยู่ถัดไปจะแสดงตำแหน่งที่โมเดลถูกโหลดไว้ ค่า 100% CPU เป็นค่าปกติบน VPS ที่ไม่มี GPU ส่วนการแบ่งข้อมูลแบบ 30%/70% CPU/GPU บนเครื่องที่มี GPU หมายความว่าน้ำหนักของโมเดลรวมกับ cache ไม่สามารถเก็บใน VRAM ได้ทั้งหมด ซึ่งสาเหตุส่วนใหญ่มักเกิดจากการตั้งค่า num_ctx ที่สูงเกินไป

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

ตัวประมวลผล inference จะแสดงขนาด context ในบรรทัดที่มีข้อความ n_ctx รูปแบบข้อความที่แน่นอนอาจเปลี่ยนแปลงไปตามแต่ละ releases ดังนั้นหากไม่พบข้อความดังกล่าว ให้สันนิษฐานว่ามีการเปลี่ยนชื่อเรียกแทนที่จะสรุปว่าระบบมีปัญหา

สี่ตำแหน่งสำหรับการตั้งค่า num_ctx

ในคำขอ (Request): ส่ง "options": {"num_ctx": 16384} ไปยัง /api/generate หรือ /api/chat วิธีนี้มีลำดับความสำคัญสูงสุดเหนือการตั้งค่าอื่นทั้งหมด และมีผลเฉพาะกับคำขอนั้นๆ หากค่าที่ส่งไปแตกต่างจากค่าที่โมเดลที่โหลดอยู่ใช้งานอยู่ เซิร์ฟเวอร์จะทำการโหลดโมเดลใหม่ก่อน ซึ่งคุณสามารถสังเกตได้จาก load_duration ในส่วนของ response โดยค่าจะกระโดดจากใกล้ศูนย์ไปเป็นหลักวินาที การรอคอยในลักษณะเดียวกันจะเกิดขึ้นเมื่อโมเดลไม่ได้ใช้งานนานจนถูก unload ดังนั้นเมื่อคุณตัดสินใจเลือกขนาด context ที่เหมาะสมได้แล้ว ควร คงโมเดลไว้ในหน่วยความจำด้วย keep_alive

ในเซสชันแบบโต้ตอบ (Interactive session): ภายใน ollama run ให้พิมพ์ /set parameter num_ctx 16384 ค่านี้จะมีผลเฉพาะในเซสชันนั้น

ใน Modelfile: วิธีนี้เป็นการฝังค่าลงในโมเดลที่ตั้งชื่อไว้ ทำให้ทุกไคลเอนต์ได้รับค่านี้โดยไม่ต้องแก้ไขที่ฝั่งไคลเอนต์

FROM llama3.1:8b
PARAMETER num_ctx 16384

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

บนเซิร์ฟเวอร์: OLLAMA_CONTEXT_LENGTH เป็นการกำหนดค่าเริ่มต้นสำหรับทุกคำขอที่ไม่ได้ระบุ num_ctx ของตนเอง หากใช้งานภายใต้ systemd ให้เพิ่มไฟล์ drop-in แทนการแก้ไขไฟล์ unit โดยตรง

sudo systemctl edit ollama.service

[Service]
Environment="OLLAMA_CONTEXT_LENGTH=16384"

sudo systemctl daemon-reload
sudo systemctl restart ollama
ollama ps

ลำดับความสำคัญมีความสำคัญอย่างยิ่งเมื่อคุณกำลังดีบั๊กไคลเอนต์ของผู้อื่น คำขอที่ระบุ num_ctx จะมีความสำคัญเหนือกว่าค่าเริ่มต้นของเซิร์ฟเวอร์ ดังนั้น chat front end หรือ agent ที่ส่งค่าขนาดเล็กของตนเองมาด้วย จะทำให้การตั้งค่าผ่าน systemd ของคุณถูกยกเลิกไปโดยไม่รู้ตัว เมื่อคุณ เชื่อมต่อ coding agent เข้ากับเซิร์ฟเวอร์ Ollama ของคุณ ให้ตรวจสอบสิ่งที่ไคลเอนต์ส่งมาก่อนที่จะสรุปว่าปัญหาเกิดจากเซิร์ฟเวอร์

เหตุผลที่คุณไม่สามารถตั้งค่า num_ctx ให้เท่ากับค่าสูงสุดของโมเดลได้

กลไก Attention ทำให้ทุกโทเค็นต้องประมวลผลร่วมกับโทเค็นก่อนหน้าทั้งหมด คีย์ (keys) และค่า (values) ที่คำนวณได้สำหรับโทเค็นก่อนหน้าจะถูกเก็บไว้เพื่อไม่ให้ต้องคำนวณใหม่ทุกครั้งที่มีโทเค็นใหม่เกิดขึ้น พื้นที่จัดเก็บนี้เรียกว่า KV cache (key/value cache) ซึ่งจะถูกจองไว้สำหรับ num_ctx ทั้งหมดตั้งแต่ตอนที่โหลดโมเดล ไม่ใช่ค่อยๆ เพิ่มขึ้นตามความยาวของบทสนทนา ดังนั้นการตั้งค่า context ขนาดใหญ่จึงกินหน่วยความจำทันทีแม้จะเป็นเพียง prompt บรรทัดเดียวก็ตาม

บทเรียนเรื่องต้นทุนการทำ inference ของ DigitalOcean ได้สรุปการคำนวณไว้ในบรรทัดเดียวดังนี้:

kv_bytes_per_token = 2 * layers * kv_heads * head_dim * bytes_per_value

เลข 2 คือการนับคีย์และค่าแยกกัน คุณสามารถอ่านค่าตัวเลขอื่นๆ ได้จากโมเดลของคุณเอง

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 เลเยอร์และมี key/value heads จำนวน 8 หัว ขนาดของ head คือ embed หารด้วย heads ดังนั้นในกรณีนี้คือ 4096 / 32 = 128 และโมเดลบางรุ่นจะระบุค่านี้โดยตรงว่าเป็น llama.attention.key_length แคชมาตรฐานจะเก็บค่าแบบ f16 ดังนั้น bytes_per_value จึงเท่ากับ 2 และเมื่อคำนวณ 2 32 8 128 2 จะได้ผลลัพธ์เป็น 131,072 ไบต์ นั่นหมายถึงแคชขนาด 128 KiB สำหรับทุกๆ 1 โทเค็นของ context เมื่อนำไปคูณกับความยาวของ 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 เหล่านั้นเป็นผลลัพธ์ทางคณิตศาสตร์จากสูตรข้างต้น ไม่ใช่ค่าที่วัดได้จริง คอลัมน์รวมได้รวมขนาดไฟล์ดาวน์โหลด 4.9 GB ที่ไลบรารี Ollama ระบุไว้สำหรับ llama3.1:8b ในเดือนสิงหาคม 2026 ซึ่งเท่ากับ 4.6 GiB โดยยังไม่ได้รวม compute buffers และตัว process ของเซิร์ฟเวอร์เอง ดังนั้นให้ถือว่าตัวเลขนี้เป็นค่าต่ำสุดเท่านั้น

ประเด็นสำคัญอยู่ที่โครงสร้างของมัน ที่ระดับ 8k แคชจะมีต้นทุนอยู่ที่ 1 GiB ซึ่งถือว่าน้อยมากเมื่อเทียบกับน้ำหนักของโมเดล (weights) แต่ที่ระดับ 128k ซึ่งเป็นค่าสูงสุดของโมเดล ต้นทุนจะพุ่งไปถึง 16 GiB หรือมากกว่าน้ำหนักของโมเดลถึง 3 เท่า ทำให้ยอดรวมอยู่ที่ประมาณ 20.6 GiB ดังนั้น VPS ขนาด 4 GB จึงไม่สามารถโหลดโมเดลนี้เพื่อใช้งาน context ที่มีประโยชน์ได้ ส่วน VPS ขนาด 8 GB จะรองรับที่ 8k ได้อย่างสบาย และ VPS ขนาด 16 GB จะรองรับได้ถึง 32k โดยยังมีพื้นที่เหลือสำหรับ process อื่นๆ ในเครื่อง เกณฑ์เหล่านี้จะขยับสูงขึ้นตามขนาดของน้ำหนักโมเดล ดังนั้นหากคุณกำลังพิจารณาโมเดลที่ใหญ่กว่า 8B นี้ การคำนวณแบบเดียวกันที่ทำไว้ใน บทความเกี่ยวกับ Qwen 27B บน VPS ที่ใช้เฉพาะ CPU จะแสดงให้เห็นว่าน้ำหนักของโมเดลเหลือพื้นที่ให้ context น้อยเพียงใดเมื่อมี RAM ระหว่าง 8 ถึง 64 GB

จะเกิดอะไรขึ้นเมื่อ KV cache มีขนาดไม่พอ

บน VPS ที่ใช้เฉพาะ CPU กระบวนการทำงานจะใช้หน่วยความจำเพิ่มขึ้นเรื่อยๆ ให้เฝ้าสังเกตในขณะที่โหลดโมเดลและในขณะที่ประมวลผลคำขอที่มีความยาว

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

RSS (resident set size) จะแสดงเป็นหน่วยกิโลไบต์ หากค่า swap ที่ใช้ใน free -m เริ่มเพิ่มสูงขึ้น ให้ลดขนาด context ลง KV cache ที่ถูกย้ายไปอยู่ใน swap จะทำให้การสร้างข้อความหยุดชะงักนานหลายวินาทีต่อหนึ่ง token เนื่องจากทุกครั้งที่มีการสร้าง token ใหม่ ระบบจะต้องอ่านข้อมูลจาก cache ทั้งหมด

หากเครื่องหน่วยความจำเต็มจนหมด kernel จะเลือกกระบวนการที่ใช้หน่วยความจำมากที่สุดแล้วสั่ง kill ทิ้ง

sudo dmesg | grep -i "killed process"

บรรทัดที่ระบุว่า Out of memory: Killed process 1234 (ollama) หมายความว่า context ที่คุณกำหนดไว้มีขนาดใหญ่เกินกว่าจะรองรับได้ โดยปกติ Ollama มักจะปฏิเสธคำขอก่อนที่จะถึงจุดนั้น และคำขอจะล้มเหลวพร้อมข้อความแจ้งเตือนที่ระบุถึงปริมาณหน่วยความจำที่ต้องการเทียบกับหน่วยความจำที่เหลืออยู่

บนเครื่องที่มี GPU ความล้มเหลวจะเกิดขึ้นแบบเงียบกว่า โดยเลเยอร์ต่างๆ จะถูกย้ายไปประมวลผลใน system RAM แทน ซึ่ง ollama ps จะแสดงการแบ่งการทำงานระหว่าง CPU และ GPU และอัตรา throughput จะลดลงอย่างรวดเร็ว ความเร็วที่ลดลงจะมากน้อยเพียงใดขึ้นอยู่กับฮาร์ดแวร์ของคุณ ดังนั้นควร วัดจำนวน tokens ต่อวินาทีบนเครื่องของคุณเอง ในแต่ละการตั้งค่า context แทนที่จะเชื่อตัวเลขจากเครื่องของผู้อื่น

เวลาในการทำ Prefill เพิ่มขึ้นเร็วกว่าความยาวของ prompt

Prefill คือกระบวนการทำงานกับข้อมูลนำเข้าของคุณก่อนที่ token แรกจะถูกสร้างออกมา โดย token แต่ละตัวใน prompt จะต้องประมวลผลร่วมกับ token ทั้งหมดที่อยู่ก่อนหน้า ส่งผลให้ปริมาณงานรวมเพิ่มขึ้นในอัตราส่วนยกกำลังสองของความยาวข้อมูลนำเข้า การเพิ่มความยาว 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 ยาว แล้วหารจำนวน token ด้วยจำนวนวินาทีของแต่ละกรณี บน VPS ที่ใช้ CPU เท่านั้น prefill มักเป็นส่วนที่ช้าที่สุดของคำขอที่มี context ยาว และค่า tokens per second ที่วัดจาก prompt สั้นจะไม่สามารถใช้คาดการณ์กรณีดังกล่าวได้ หาก prefill ใช้เวลานานเกิน timeout ที่อยู่ด้านหน้า คำขอด้วย prompt ยาวมักส่งกลับเป็น context deadline exceeded แทนคำตอบ ดังนั้นให้ตรวจสอบก่อนว่า layer ใดเป็นผู้ยกเลิกการทำงาน ก่อนลดขนาด contextลง

ปัญหาจะเห็นได้ชัดเจนที่สุดเมื่อมีการทำงานพร้อมกัน (concurrency) คำขอแต่ละรายการที่กำลังประมวลผลต้องใช้ cache ของตนเอง ดังนั้นหน่วยความจำในแผนภูมิด้านบนจึงเป็นค่าต่อคำขอ ไม่ใช่ต่อเซิร์ฟเวอร์ และคำขอที่ยาวเพียงรายการเดียวอาจยึดทรัพยากรของระบบไว้ในขณะที่คำขอสั้นๆ ต้องรอคิวอยู่ด้านหลัง ควรตั้งค่า OLLAMA_NUM_PARALLEL อย่างรอบคอบ และอ่านข้อมูลเรื่อง จำนวนผู้ใช้งานพร้อมกันที่ LLM แบบ self-hosted รองรับได้ ก่อนที่คุณจะเพิ่มค่าทั้งสองตัวพร้อมกัน

กู้คืนบริบทด้วยแคชที่มีขนาดเล็กลง

bytes_per_value ในสูตรคือการตั้งค่าที่คุณสามารถควบคุมได้ FAQ ของ Ollama ได้ระบุถึง OLLAMA_KV_CACHE_TYPE โดยมี f16 เป็นค่าเริ่มต้นที่ 2 ไบต์ บวกกับ q8_0 ที่ 1 ไบต์ และ q4_0 สำหรับค่าที่ต่ำกว่านั้น การเปลี่ยนไปใช้ q8_0 จะช่วยลดขนาดแคชลงครึ่งหนึ่ง ดังนั้นแถวขนาด 32k จึงใช้หน่วยความจำ 2 GiB แทนที่จะเป็น 4 GiB การทำ Quantisation ให้กับน้ำหนัก (weights) จะช่วยเพิ่มหน่วยความจำว่างจากอีกฝั่งของงบประมาณเดียวกัน และ แท็ก GLM ที่เหมาะกับ VPS จะถูกประมวลผลผ่านการทำ Quantisation ทีละระดับหากนั่นคือการแลกเปลี่ยนที่คุณต้องการ FAQ เดียวกันนี้ยังระบุถึง OLLAMA_FLASH_ATTENTION=1 ซึ่งบิลด์บางตัวต้องการก่อนที่แคชแบบ Quantised จะมีผล

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

ตรวจสอบให้แน่ใจแทนการคาดเดา: ให้รีสตาร์ทเซอร์วิส โหลดโมเดลที่ num_ctx เดิม แล้วเปรียบเทียบค่า RSS การรองรับขึ้นอยู่กับโมเดลและแบ็กเอนด์ ดังนั้นหากการตั้งค่าใดไม่ส่งผลใดๆ แสดงว่าชุดค่าผสมของคุณไม่รองรับการตั้งค่าดังกล่าว เอกสารประกอบได้ระบุตัวเลือกเหล่านี้ไว้โดยไม่ได้การันตีผลลัพธ์ด้านคุณภาพ ดังนั้นควรทดสอบ q4_0 กับพรอมต์ของคุณเองก่อนที่จะใช้งานจริง หากปุ่มปรับแต่งเหล่านี้คือเหตุผลที่คุณมาที่นี่ Ollama และ llama.cpp มีวิธีการเปิดใช้งานที่แตกต่างกัน

สูตรสำหรับการเลือก num_ctx

1. อ่านค่า context สูงสุด, จำนวน layer และจำนวน head ของ key/value ของโมเดลจาก /api/show
2. คำนวณจำนวนไบต์ต่อ token ด้วยสูตรที่กำหนด จากนั้นคูณด้วยค่า context ที่คุณต้องการ
3. รวมขนาดของ weight เข้าไป แล้วเปรียบเทียบกับ RAM ที่ว่างอยู่ โดยต้องเหลือ RAM ไว้ที่ 1 GiB เป็นอย่างน้อยสำหรับกระบวนการอื่นในระบบ
4. กำหนดค่าดังกล่าว โหลดโมเดล แล้วตรวจสอบค่าที่ถูกนำไปใช้จริงด้วย ollama ps และ prompt_eval_count
5. รัน workload จริงของคุณพร้อมกับเฝ้าดู free -m หากเริ่มมีการใช้งาน swap ให้ลดค่า context ลงครึ่งหนึ่ง

งานส่วนใหญ่ต้องการ context น้อยกว่าที่ผู้ใช้มักจะกำหนดให้ การสรุปรายงานขนาดยาวใช้พื้นที่เพียง 16k ส่วนระบบ retrieval front end ที่ดึงข้อมูลเอกสารมา 5 ส่วน มักใช้ไม่เกิน 8k กรณีที่จำเป็นต้องใช้ 64k หรือมากกว่านั้นจริงๆ คือ coding agent ที่ต้องอ่านไฟล์ทั้งไฟล์ ซึ่งในกรณีนี้คุณควรเลือกขนาดเครื่องให้เหมาะสมกับ context แทนที่จะทำในทางกลับกัน หากเซิร์ฟเวอร์ยังเป็นเครื่องใหม่ ให้เริ่มจาก การติดตั้ง Ollama บน VPS ให้ใช้งานได้ แล้วจึงปรับจูน context หลังจากที่โหลดโมเดลได้สำเร็จแล้ว

FAQ

ความยาว context เริ่มต้นของ Ollama คือเท่าใด

ขึ้นอยู่กับรุ่นที่ติดตั้งและฮาร์ดแวร์ ดังนั้นควรตรวจสอบแทนการคาดเดา FAQ ของ Ollama ระบุไว้ที่ 4096 tokens ส่วนเอกสารอ้างอิง Modelfile ระบุ num_ctx เริ่มต้นที่ 2048 และหน้าความยาว context ระบุว่าค่าเริ่มต้นจะถูกเลือกจาก VRAM ที่มีอยู่: 4k สำหรับ VRAM ต่ำกว่า 24 GiB, 32k สำหรับ 24 ถึง 48 GiB และ 256k สำหรับที่สูงกว่านั้น VPS ที่ใช้เฉพาะ CPU จะได้ค่าเริ่มต้นที่ต่ำ ollama ps จะแสดงค่า context ที่ใช้งานจริงในรุ่นที่รองรับคอลัมน์นี้ และ prompt_eval_count ในการตอบกลับของ API จะยืนยันค่านี้ได้ในทุกรุ่น

ทำไม Ollama ถึงละเลยส่วนต้นของ prompt ที่ยาวของฉัน

เพราะ prompt ยาวเกินกว่าหน้าต่าง context เซิร์ฟเวอร์จึงตัดส่วนเกินออกก่อนที่โมเดลจะได้รับข้อมูล และไม่มีข้อความแจ้งเตือนความผิดพลาดส่งกลับมา ให้ส่ง prompt เดิมอีกครั้งด้วยค่า num_ctx ที่มากขึ้น และสังเกตค่า prompt_eval_count ในการตอบกลับว่าเพิ่มขึ้นหรือไม่ หากตัวเลขดังกล่าวไม่เปลี่ยนแปลง แสดงว่ามีบางอย่างระหว่างคุณกับเซิร์ฟเวอร์ตั้งค่า num_ctx ไว้เอง ซึ่งเป็นเรื่องปกติสำหรับหน้าเว็บแชทและเฟรมเวิร์กของ agent

การเพิ่ม num_ctx ต้องใช้ RAM เพิ่มขึ้นเท่าใด

ให้นำความยาว context คูณกับต้นทุน cache ต่อ token ซึ่งคือ 2 * layers * kv_heads * head_dim * bytes_per_value สำหรับ Llama 3.1 8B ที่ f16 จะอยู่ที่ 128 KiB ต่อ token ดังนั้น 32k tokens จะใช้พื้นที่ 4 GiB และที่ 128k เต็มจะใช้ 16 GiB นอกเหนือจากขนาดของ weights โดย cache จะถูกจองไว้ตั้งแต่ตอนโหลดโมเดล ดังนั้นการตั้งค่า num_ctx ไว้สูงจะทำให้เสียหน่วยความจำส่วนนี้ไปแม้ว่า prompt ของคุณจะสั้นก็ตาม

หน้าต่าง context ที่ใหญ่ขึ้นทำให้ Ollama ทำงานช้าลงหรือไม่

ใช่ ในสองกรณี คือ งาน prefill จะเพิ่มขึ้นตามกำลังสองของความยาว prompt ดังนั้น input ที่ยาวจะทำให้ token แรกแสดงผลช้ากว่าที่ความยาวของมันบ่งบอก และ cache ที่ใหญ่ขึ้นจะแย่งพื้นที่หน่วยความจำ: บนเครื่อง GPU มันจะผลัก layer ไปไว้ใน RAM ของระบบ และบนเครื่อง CPU มันจะทำให้เครื่องเข้าสู่สภาวะ swap การตั้งค่า num_ctx ไว้สูงแม้จะไม่ได้ใช้งานเต็มที่ก็ยังคงกินหน่วยความจำอยู่ แม้ว่าจะไม่เสียเวลาในส่วนของ prefill ก็ตาม

ฉันสามารถตั้งค่า num_ctx ถาวรสำหรับโมเดลหนึ่งๆ ได้หรือไม่

ได้ ให้เขียน Modelfile ที่มี FROM llama3.1:8b และ PARAMETER num_ctx 16384 จากนั้นรัน ollama create llama3.1-16k -f ./Modelfile ไคลเอนต์ทุกตัวที่เรียกใช้ llama3.1-16k จะได้รับค่า context นั้นโดยไม่ต้องส่งตัวเลือกใดๆ เพิ่มเติม อย่างไรก็ตาม คำขอที่ระบุ num_ctx ของตัวเองจะมีความสำคัญเหนือกว่า ดังนั้นวิธีนี้จึงเป็นการตั้งค่าเริ่มต้นไม่ใช่การจำกัดเพดานสูงสุด