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

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

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

Llama 3.1 8B ถูกระบุว่ามี context window ขนาด 128k ในคลังโมเดลของ Ollama แต่เซิร์ฟเวอร์ที่ติดตั้งตามปกติจะไม่ให้ค่าดังกล่าวแก่คุณ เอกสารของ Ollama เองระบุค่าเริ่มต้นที่แตกต่างกันในแต่ละหน้า โดย FAQ ระบุว่า 4096 token ส่วนอ้างอิง 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 รูปแบบข้อความอาจมีการเปลี่ยนแปลงไปตามแต่ละ release ดังนั้นหากไม่พบข้อความดังกล่าว ให้สันนิษฐานว่าเป็นการเปลี่ยนชื่อเรียกแทนที่จะสรุปว่าระบบมีปัญหา

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

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

ในเซสชันแบบโต้ตอบ (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 จะมีความสำคัญเหนือกว่าค่าเริ่มต้นของเซิร์ฟเวอร์ ดังนั้นหน้าเว็บแชทหรือเอเจนต์ที่ส่งค่าขนาดเล็กของตนเองมาด้วย จะทำให้การตั้งค่าผ่าน systemd ของคุณถูกยกเลิกไปโดยไม่รู้ตัว เมื่อคุณ เชื่อมต่อ coding agent เข้ากับเซิร์ฟเวอร์ Ollama ของคุณ ให้ตรวจสอบสิ่งที่ไคลเอนต์ส่งมาก่อนที่จะสรุปว่าปัญหาเกิดจากเซิร์ฟเวอร์

Why you cannot just set num_ctx to the model maximum

Attention makes every token look at every token before it. The keys and values computed for earlier tokens are kept so they are not recomputed for each new token, and that store is the KV cache (key/value cache). It is allocated for the whole of num_ctx when the model loads, not as the conversation grows, so a large context costs its memory even on a one line prompt.

DigitalOcean's inference cost tutorial states the arithmetic in one line:

kv_bytes_per_token = 2 * layers * kv_heads * head_dim * bytes_per_value

The 2 counts keys and values separately. Read the other numbers off your own 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 reports 32 layers and 8 key/value heads. The head dimension is embed divided by heads, so 4096 / 32 = 128 here, and some models publish it directly as llama.attention.key_length. The default cache holds f16 values, so bytes_per_value is 2, and 2 32 8 128 2 works out at 131,072 bytes. That is 128 KiB of cache for every single token of context. Multiply by the context length and the cost stops being abstract.

[
  {
    "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
  }
]

Those 6 rows are arithmetic from the formula above, not measurements. The total column adds the 4.9 GB download that the Ollama library listed for llama3.1:8b in August 2026, which is 4.6 GiB, and it leaves out the compute buffers and the server process itself. Treat it as a floor.

The shape is the point. At 8k the cache costs 1 GiB, which is noise next to the weights. At the model's full 128k it costs 16 GiB, more than three times the weights, for a total near 20.6 GiB. So a 4 GB VPS cannot load this model at any useful context. An 8 GB VPS is comfortable at 8k. A 16 GB VPS reaches 32k with room left for the rest of the box. Every one of those thresholds moves up with the weights, so if you are weighing a larger model against this 8B, the same sums worked through for Qwen's 27B tag on a CPU-only VPS show how little the weights leave over for context between 8 and 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 ทั้งหมดขึ้นมาใหม่

หากเครื่องหน่วยความจำเต็ม ระบบปฏิบัติการจะเลือกกระบวนการที่ใช้หน่วยความจำมากที่สุดแล้วสั่ง 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 คือการทำงานที่เกิดขึ้นกับข้อมูลนำเข้าของคุณก่อนที่โทเค็นแรกจะถูกสร้างออกมา โทเค็นแต่ละตัวใน Prompt จะต้องประมวลผลร่วมกับโทเค็นทั้งหมดที่อยู่ก่อนหน้า ดังนั้นปริมาณงานรวมจึงเพิ่มขึ้นในอัตราส่วนยกกำลังสองของความยาวข้อมูลนำเข้า การเพิ่มความยาวของ Prompt เป็นสองเท่าจะทำให้ระยะเวลารอคอยโทเค็นแรกเพิ่มขึ้นมากกว่าสองเท่า

การตอบสนองจะแสดงค่าการวัดผลไว้ให้ คุณจึงไม่จำเป็นต้องเชื่อโดยปราศจากหลักฐาน

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 ที่ยาวขึ้น จากนั้นให้นำจำนวนโทเค็นหารด้วยจำนวนวินาทีในแต่ละกรณี บน VPS ที่ใช้เฉพาะ CPU การทำ Prefill มักจะเป็นส่วนที่ช้าที่สุดของคำขอที่มีบริบท (context) ยาว และค่าโทเค็นต่อวินาทีที่ได้จาก Prompt สั้นๆ จะไม่สามารถนำมาใช้คาดการณ์ประสิทธิภาพในกรณีนี้ได้

ปัญหาจะเห็นได้ชัดเจนที่สุดเมื่อมีการทำงานพร้อมกัน (concurrency) คำขอแต่ละรายการที่กำลังประมวลผลจำเป็นต้องมีแคชของตัวเอง ดังนั้นหน่วยความจำในแผนภูมิด้านบนจึงเป็นค่าต่อคำขอ ไม่ใช่ต่อเซิร์ฟเวอร์ และคำขอที่ยาวเพียงรายการเดียวอาจยึดทรัพยากรทั้งหมดไว้ในขณะที่คำขอสั้นๆ ต้องรอคิวอยู่เบื้องหลัง ให้กำหนดค่า 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 นอกจากนี้ FAQ ยังระบุถึง OLLAMA_FLASH_ATTENTION=1 ซึ่ง build บางตัวต้องการก่อนที่แคชแบบ quantised จะเริ่มทำงาน

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

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

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

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

งานส่วนใหญ่ต้องการ context น้อยกว่าที่ผู้ใช้มักจะกำหนดให้ การสรุปรายงานขนาดยาวใช้เพียง 16k ก็เพียงพอ ส่วนหน้าจอ retrieval ที่ดึงข้อมูลเอกสารมา 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 เอง ซึ่งเป็นเรื่องปกติที่พบได้ใน chat front end และ agent frameworks

การเพิ่ม 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 ของตนเองมาด้วย ค่าที่ระบุในคำขอจะมีความสำคัญเหนือกว่า ดังนั้นวิธีนี้จึงเป็นการตั้งค่าเริ่มต้นไม่ใช่การจำกัดเพดานสูงสุด