วิธีตั้งค่า num_predict ใน Ollama เพื่อจำกัดจำนวนโทเค็น

หน้าที่ของ num_predict ใน Ollama

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

นี่คือการทำงานทั้งหมดของฟีเจอร์นี้ ความยากอยู่ที่ Ollama มีจุดให้ตั้งค่านี้ได้ถึง 3 แห่ง และการตั้งค่าที่อยู่ใกล้กับคำขอมากที่สุดจะมีผลเหนือกว่า รายงานปัญหาประเภท "num_predict ไม่ทำงาน" เกือบทั้งหมดเกิดจากการที่การตั้งค่าในระดับหนึ่งถูกแทนที่โดยอีกระดับหนึ่งอย่างเงียบๆ

num_predict ไม่ใช่ num_ctx

ตัวเลือกทั้งสองนี้มักถูกสับสนบ่อยที่สุดใน Ollama และความสับสนนี้ทำให้เสียเวลาในการดีบั๊กจริง

num_ctx คือปริมาณที่โมเดลสามารถ อ่าน ได้ มันคือขนาดของ context window ซึ่งเก็บทั้ง prompt และทุกสิ่งที่ถูกสร้างขึ้นมาจนถึงปัจจุบัน การเพิ่มค่านี้จะทำให้เปลืองหน่วยความจำ เพราะ key/value cache ที่โมเดลเก็บไว้สำหรับ token เหล่านั้นจะขยายตัวตามขนาดของหน้าต่าง การกำหนดขนาด num_ctx สำหรับฮาร์ดแวร์ของคุณ เป็นงานแยกต่างหากที่มีรูปแบบความล้มเหลวเฉพาะตัว

num_predict คือปริมาณที่โมเดลจะ เขียน ออกมา มันเป็นกฎสำหรับการหยุดทำงาน ไม่ใช่การจัดสรรทรัพยากร การเพิ่มค่านี้จะทำให้เสียเวลาในการประมวลผลจริงมากกว่าการใช้ RAM และไม่มีการจองทรัพยากรไว้ล่วงหน้า

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

กำหนดค่าครั้งเดียวด้วย Modelfile

Modelfile จะฝังค่าลงในโมเดลที่คุณสร้างขึ้น ให้เขียนไฟล์ดังนี้:

FROM qwen3:8b
PARAMETER num_ctx 8192
PARAMETER num_predict 512

จากนั้นทำการ build และตรวจสอบสิ่งที่คุณสร้างขึ้น:

ollama create qwen3-capped -f Modelfile
ollama show --parameters qwen3-capped

ollama show --parameters จะแสดงพารามิเตอร์ที่จัดเก็บไว้บรรทัดละหนึ่งรายการพร้อมค่าของมัน หาก num_predict ไม่ปรากฏในผลลัพธ์ดังกล่าว แสดงว่าโมเดลนั้นไม่มีการจำกัดค่าที่ฝังไว้ และจะใช้ค่าเริ่มต้นของ Ollama แทน ollama show --modelfile qwen3-capped จะแสดงคำจำกัดความทั้งหมด ซึ่งเป็นวิธีที่เร็วที่สุดในการคัดลอกพารามิเตอร์ที่โมเดลเดิมมีอยู่แล้ว การสร้างโมเดลที่จำกัดค่าด้วยวิธีนี้แทบไม่เปลืองพื้นที่ดิสก์เพิ่มเติม เนื่องจากรายการใหม่จะใช้ weight blobs เดิมที่โมเดลหลักดาวน์โหลดไว้แล้วซ้ำ แทนที่จะคัดลอกไฟล์เหล่านั้น และการทราบว่า Ollama เก็บ blobs เหล่านั้นไว้ที่ไหน เป็นเรื่องที่ควรทราบก่อนที่ดิสก์ root ของ VPS จะเต็ม

นี่คือเลเยอร์ที่เหมาะสมสำหรับค่าที่คุณต้องการให้ผู้เรียกใช้ทุกคนได้รับสืบทอดไป แต่ไม่ใช่เลเยอร์ที่เหมาะสมหากคุณคาดหวังว่าค่านี้จะเป็นค่าสุดท้าย เพราะมันสามารถเปลี่ยนแปลงได้

กำหนดค่าผ่านออบเจกต์ options ในแต่ละคำขอ

endpoint สำหรับการสร้างข้อมูลทุกรายการจะรับออบเจกต์ options โดยสามารถใส่ num_predict ลงไปภายในได้:

curl http://localhost:11434/api/generate -d '{
  "model": "qwen3:8b",
  "prompt": "Explain what a reverse proxy does.",
  "stream": false,
  "options": { "num_predict": 128 }
}'

/api/chat ใช้คีย์ options เดียวกันและมีความหมายเหมือนกัน ค่าที่กำหนดในส่วนนี้จะมีผลเฉพาะกับคำขอนั้นๆ เท่านั้น นี่คือเลเยอร์ที่เครื่องมือของคุณใช้งาน ไม่ว่าจะเป็นหน้าเว็บแชท, สคริปต์, SDK wrapper หรือ coding agent ทั้งหมดนี้จะส่งออบเจกต์ options ไปด้วยเสมอ ไม่ว่าในอินเทอร์เฟซจะแสดงช่องให้กรอกค่าดังกล่าวหรือไม่ก็ตาม

ตั้งค่าสำหรับหนึ่งเซสชันด้วยพารามิเตอร์ /set

ภายใน ollama run เซสชันแบบโต้ตอบจะกำหนดตัวเลือกไว้สำหรับส่วนที่เหลือของเซสชันนั้น:

>>> /set parameter num_predict 256
>>> /show parameters

/show parameters จะแสดงสิ่งที่เซสชันจะส่งไปพร้อมกับข้อความถัดไปของคุณ ซึ่งเป็นวิธีที่เร็วที่สุดในการยืนยันว่าการเปลี่ยนแปลงมีผล ค่านี้จะคงอยู่จนกว่าคุณจะพิมพ์ /bye หากต้องการเก็บค่าไว้ /save qwen3-capped จะเขียนเซสชันปัจจุบันรวมถึงพารามิเตอร์ต่างๆ ลงเป็นโมเดลใหม่ สิ่งที่คุณ /set ที่นี่จะไม่ส่งผลต่อไคลเอนต์อื่นใดทั้งสิ้น

การตั้งค่าใดมีผล และเหตุใดการตั้งค่าของคุณจึงถูกละเลย

ลำดับความสำคัญนั้นสั้นและชัดเจน ตัวเลือกที่ส่งมาพร้อมกับคำขอ (request) จะมีความสำคัญสูงสุด บรรทัด PARAMETER num_predict ใน Modelfile ของโมเดลจะเป็นค่าสำรองที่ใช้เมื่อคำขอนั้นไม่มีการระบุค่าใดๆ มา หากไม่มีทั้งสองอย่าง ระบบจะใช้ค่าเริ่มต้นที่มาพร้อมกับ Ollama

/set parameter ไม่ใช่กฎข้อที่สาม เซสชันแบบโต้ตอบ (interactive session) ทำหน้าที่เป็น API client ดังนั้นสิ่งที่คุณตั้งค่าในนั้นจะถูกส่งไปเป็น options ของคำขอนั้นๆ ซึ่งเป็นเหตุผลว่าทำไมมันจึงไปแทนที่ค่าใน Modelfile สำหรับเซสชันนั้น

นี่คือสาเหตุของปัญหาที่คุณพบ คุณเพิ่ม PARAMETER num_predict 512 เข้าไปและสร้างโมเดลใหม่ แต่คำตอบยังคงยาวหลายพันโทเค็น การตั้งค่าของคุณมีอยู่จริงและ ollama show --parameters ก็ยืนยันเรื่องนี้ แต่มันถูกแทนที่ในทุกคำขอ เพราะไคลเอนต์ส่งออบเจกต์ options ของตัวเองที่มีตัวเลขของมันมาด้วย ซึ่งมักจะเป็นตัวเลขที่คุณเคยพิมพ์ไว้ในหน้าจอการตั้งค่าเมื่อหลายเดือนก่อนแล้วลืมไป ollama show อ่านค่าจากโมเดลที่จัดเก็บไว้ มันจึงไม่สามารถแสดงให้คุณเห็นได้ว่ามีอะไรส่งผ่านมาทาง HTTP บ้าง

พิสูจน์ฝั่งเซิร์ฟเวอร์ด้วยคำสั่งเดียว ส่งคำขอที่จะทำให้เกิดคำตอบยาวๆ บังคับให้จำกัดจำนวนโทเค็นให้ต่ำ และอ่านค่าสองฟิลด์นี้:

curl -s http://localhost:11434/api/generate -d '{
  "model": "qwen3-capped",
  "prompt": "Describe the Linux boot process in detail.",
  "stream": false,
  "options": { "num_predict": 32 }
}' | jq '.done_reason, .eval_count'

คำสั่งนี้ควรแสดงผล "length" และ 32 หากยังไม่มี jq ให้ติดตั้งด้วย sudo apt install -y jq ก่อน หากผลลัพธ์ที่ได้คือ "length" และ 32 แสดงว่าเซิร์ฟเวอร์ยอมรับตัวเลือกนั้นแล้ว และแอปพลิเคชันของคุณกำลังส่งค่าอื่นมาแทน สำหรับการตรวจสอบบันทึกของเซิร์ฟเวอร์เกี่ยวกับคำขอ ให้รีสตาร์ทเซิร์ฟเวอร์โดยเพิ่ม OLLAMA_DEBUG=1 ลงใน environment แล้วเฝ้าดู journalctl -u ollama -f ในขณะที่แอปพลิเคชันของคุณกำลังสื่อสารกับเซิร์ฟเวอร์

ค่าติดลบและตัวเลขที่คุณไม่ควรคัดลอก

num_predict ยอมรับค่าติดลบเช่นกัน ซึ่งค่าเหล่านี้เป็นค่าพิเศษ (sentinels) ไม่ใช่จำนวนนับ ค่าติดลบค่าหนึ่งหมายถึง "ไม่ต้องจำกัด ให้สร้างต่อไปเรื่อยๆ" อีกค่าหนึ่งเคยหมายถึง "เติมเต็มบริบทที่เหลือ" ณ เดือนสิงหาคม 2026 ข้อมูลอ้างอิง Modelfile ของ Ollama ระบุค่าเริ่มต้นไว้ที่ -1 ซึ่งหมายถึงการสร้างข้อความแบบไม่จำกัด และตารางในเวอร์ชันก่อนหน้าก็เคยระบุ -2 สำหรับการเติมเต็มบริบทเช่นกัน

ให้ถือว่าข้อมูลทั้งหมดนี้ขึ้นอยู่กับเวอร์ชันของซอฟต์แวร์เนื่องจากมีการเปลี่ยนแปลงอยู่ตลอด เอกสารอ้างอิงเคยระบุค่าเริ่มต้นเป็น 128 มาเป็นเวลานานก่อนที่จะมีการแก้ไขข้อมูลให้ถูกต้องในช่วงปลายปี 2024 ดังนั้นคู่มือจำนวนมากจึงยังคงอ้างอิงตัวเลขเก่าอยู่ โปรดอ่าน Modelfile parameter reference สำหรับเวอร์ชันที่คุณใช้งานจริง จากนั้นจึงยืนยันพฤติกรรมของระบบด้วยการตรวจสอบ eval_count ตามที่ระบุไว้ข้างต้น ค่าที่คุณตรวจสอบได้ด้วยตนเองบนเครื่องของคุณย่อมเชื่อถือได้มากกว่าค่าที่คุณอ่านจากที่ใดก็ตาม รวมถึงโพสต์นี้ด้วย

เหตุใดความยาวของผลลัพธ์จึงเป็นต้นทุนหลักบน VPS ที่ใช้เฉพาะ CPU

การสร้างข้อความมีสองขั้นตอนที่มีความเร็วต่างกันอย่างมาก โทเค็นของพรอมต์จะถูกประมวลผลเป็นชุดพร้อมกันทีละหลายรายการ ส่วนโทเค็นของผลลัพธ์จะถูกสร้างขึ้นทีละหนึ่งรายการ และแต่ละรายการจำเป็นต้องอ่านค่าน้ำหนัก (weights) ของโมเดลทั้งหมดใหม่ บน VPS ที่ใช้เฉพาะ CPU การประมวลผลนี้ถูกจำกัดด้วยแบนด์วิดท์ของหน่วยความจำ ดังนั้นโทเค็นที่สร้างขึ้นหนึ่งรายการจึงมีต้นทุนสูงกว่าโทเค็นของพรอมต์หนึ่งรายการมาก เนื่องจากขั้นตอนดังกล่าวต้องอ่านค่าน้ำหนักทุกค่า จำนวนไบต์ที่น้ำหนักแต่ละค่าใช้จึงเป็นตัวกำหนดเพดานของอัตราการสร้างโทเค็น ซึ่งเป็นเหตุผลว่าทำไม การสร้างแบบ q4 จึงถอดรหัสได้เร็วกว่าโมเดลเดียวกันที่ q8 หรือ fp16

หากขอผลลัพธ์โดยไม่ใช้การสตรีม คุณจะเห็นตัวเลขที่ชัดเจนดังนี้:

"prompt_eval_count": 26,
"prompt_eval_duration": 107345000,
"eval_count": 237,
"eval_duration": 4289432000

ระยะเวลาแสดงเป็นหน่วยนาโนวินาที ในบล็อกดังกล่าวซึ่งเป็นตัวอย่างการตอบกลับที่เผยแพร่ในเอกสารประกอบของ Ollama API ไม่ใช่การวัดผลจากเซิร์ฟเวอร์ใดเซิร์ฟเวอร์หนึ่งโดยเฉพาะ โทเค็นของพรอมต์ 26 รายการใช้เวลาประมาณ 0.1 วินาที ในขณะที่โทเค็นของผลลัพธ์ 237 รายการใช้เวลาประมาณ 4.3 วินาที อัตราการสร้างข้อความของคุณเองคือ eval_count หารด้วย eval_duration ที่แปลงเป็นวินาที และ การวัดจำนวนโทเค็นต่อวินาทีบนฮาร์ดแวร์ของคุณเอง เป็นสิ่งที่ควรทำก่อนที่จะปรับแต่งค่าอื่นใด อัตราดังกล่าวขึ้นอยู่กับโมเดลพอๆ กับตัวเครื่อง ดังนั้นหากคำตอบที่ยาวคือต้นทุนที่แท้จริง โมเดลที่สร้างมาเพื่อการถอดรหัสที่รวดเร็ว เช่น Nemotron 3.5 Lightning บน VPS จะช่วยคืนเวลาที่เสียไปจากการจำกัดค่าต่ำสุดได้บ้าง

การคำนวณที่เหลือเป็นเรื่องของคณิตศาสตร์ ที่อัตรา 8 โทเค็นต่อวินาที คำตอบขนาด 2,000 โทเค็นจะทำให้เครื่องทำงานค้างนานกว่าสี่นาที และโมเดลไม่ทราบว่าคุณต้องการเพียงแค่ย่อหน้าเดียว โมเดลสำหรับการใช้เหตุผล (reasoning model) จะใช้ส่วนหนึ่งของงบประมาณเวลาไปกับการคิดก่อนที่จะเขียนคำที่คุณต้องการ และการคิดนั้นก็ถูกสร้างขึ้นทีละโทเค็นเช่นเดียวกับส่วนอื่นๆ ดังนั้น ความพยายามในการใช้เหตุผลที่คุณร้องขอ จึงเป็นอีกปัจจัยหนึ่งที่มีผลต่อต้นทุนเดียวกัน โมเดลบางตัวอาจเกิดการวนซ้ำ โดยทำซ้ำวลีเดิมจนกว่าจะมีสิ่งใดมาหยุดมัน หากไม่มีการจำกัดค่า คำขอเดียวนี้จะทำให้ CPU core ทำงานไม่ว่างจนกว่า context window จะเต็ม num_predict คือการตั้งค่าที่ใช้จำกัดค่าดังกล่าว ซึ่งมีความสำคัญอย่างยิ่งบน VPS ที่รัน Ollama ด้วยตนเอง ขนาดเล็ก ที่ซึ่งคำขอที่ยาวเพียงรายการเดียวอาจใช้ทรัพยากรของเครื่องทั้งหมดไปจนหมดสิ้น

ผลลัพธ์ที่ถูกตัดทอนมักเกิดจากค่าจำกัด ไม่ใช่โมเดลที่เสียหาย

อาการที่พบมักดูเหมือนโมเดลทำงานล้มเหลว เช่น คำตอบที่หยุดลงกลางประโยค หรือ JSON ที่ไม่สามารถ parse ได้เนื่องจากไม่มีวงเล็บปิด ปฏิกิริยาตอบสนองแรกมักเป็นการโทษโมเดลหรือการทำ quantization แต่ให้ลองอ่านการตอบกลับก่อน

done_reason ตอบคำถามโดยตรง stop หมายความว่าโมเดลทำงานเสร็จสิ้นด้วยตัวเอง โดยการส่ง end-of-sequence token หรือการจับคู่กับสตริงในตัวเลือก stop ของคุณ length หมายความว่าการสร้างข้อความถูกตัดออกเพราะพื้นที่ไม่เพียงพอ เมื่อคุณเห็น length ให้เปรียบเทียบ eval_count กับค่าจำกัดของคุณ หากตัวเลขตรงกันแสดงว่า num_predict เป็นตัวหยุดการทำงาน และหากตัวเลขน้อยกว่าแสดงว่า context window เต็มก่อน

เมื่อคุณทำการ stream ข้อมูล ฟิลด์เหล่านี้จะมาถึงใน chunk สุดท้าย ซึ่งเป็น chunk ที่มี "done": true อยู่ ไลบรารีฝั่ง client จำนวนมากจะทิ้ง chunk นั้นและส่งให้โค้ดของคุณเฉพาะข้อความ นี่คือเหตุผลว่าทำไมการตัดทอนเดียวกันจึงดูไม่มีสาเหตุเมื่ออยู่ในแอปพลิเคชัน แต่จะเห็นได้ชัดเจนเมื่อใช้ curl หากไลบรารีซ่อนข้อมูลนี้ไว้ ให้ส่งคำขอหนึ่งครั้งด้วย curl เพื่อดูว่าเซิร์ฟเวอร์แจ้งว่าอย่างไร

อีกหนึ่งประเด็นที่ช่วยประหยัดเวลาได้มาก การเพิ่ม num_predict ไม่ได้ทำให้โมเดลเขียนมากขึ้น มันเป็นเพียงการเอาเพดานออกเท่านั้น หากคำตอบจบลงที่ 200 tokens ด้วย done_reason จาก stop แสดงว่าโมเดลตัดสินใจว่าเสร็จสิ้นแล้ว และการเพิ่มค่าจำกัดก็ไม่ช่วยอะไร คำตอบสั้นๆ ที่มี stop เป็นปัญหาที่การเขียน prompt ส่วนคำตอบสั้นๆ ที่มี length เป็นปัญหาที่ค่าจำกัด

การเลือกค่าที่เหมาะสม

• สำหรับการแชทแบบโต้ตอบ ให้ปล่อยไว้โดยไม่จำกัดค่าและกด Ctrl+C เพื่อหยุดการตอบกลับที่ยาวเกินไป เนื่องจากคุณกำลังเฝ้าดูหน้าจออยู่แล้ว
• สำหรับงานที่เป็นสคริปต์ ควรตั้งค่าจำกัดไว้เสมอ การปล่อยให้มีการสร้างข้อความโดยไม่จำกัดค่าภายในลูปเป็นสาเหตุที่ทำให้งานประมวลผลแบบกลุ่มที่ควรใช้เวลาเพียงสิบนาที ยังคงทำงานค้างอยู่จนถึงเช้าวันถัดไป
• สำหรับเอาต์พุตที่มีโครงสร้าง ให้ตั้งค่าขีดจำกัดไว้สูงกว่าเอกสารที่ถูกต้องขนาดใหญ่ที่สุดที่คุณคาดว่าจะได้รับ จากนั้นให้ถือว่า done_reason ของ length เป็นข้อผิดพลาดร้ายแรงและทำการลองใหม่ แทนที่จะพยายามแยกวิเคราะห์ข้อมูลที่ได้รับกลับมา
• สำหรับ coding agent ค่านี้ควรอยู่ในไฟล์การกำหนดค่าของตัว agent เอง เนื่องจาก agent จะส่งตัวเลือกของตนเองไปในทุกคำขอ การชี้ coding agent ไปที่ Ollama อธิบายถึงตำแหน่งที่ตั้งของการตั้งค่าเหล่านั้น

ขีดจำกัดนี้จะนับจำนวน token ไม่ใช่จำนวนคำหรือจำนวนตัวอักษร ดังนั้นอย่าใช้วิธีการประมาณค่า ให้สร้างคำตอบที่เป็นตัวอย่างหนึ่งชุดโดยไม่จำกัดค่า อ่านค่า eval_count แล้วตั้งค่าขีดจำกัดให้สูงกว่าค่านั้นอย่างเหมาะสม ตระกูลของโมเดลมีการทำ tokenization ที่แตกต่างกัน ดังนั้นค่าที่พอดีกับโมเดล Llama อาจทำให้คำตอบเดียวกันจาก โมเดล Qwen 3 บน VPS เดียวกัน ถูกตัดทอนได้

FAQ

num_ctx และ num_predict ใน Ollama ต่างกันอย่างไร

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

ทำไมการตั้งค่า num_predict ของฉันถึงดูเหมือนถูกละเลย

เนื่องจากค่าที่ส่งมาพร้อมกับคำขอ (request) จะเขียนทับค่าที่บันทึกไว้ในโมเดล หากคุณใส่ PARAMETER num_predict 512 ไว้ใน Modelfile แล้วใช้งานโมเดลนั้นผ่าน chat front end หรือ coding agent ตัวไคลเอนต์จะส่งออบเจกต์ options ของตนเองมา ซึ่งค่าที่ส่งมาจะมีผลเหนือกว่า ส่วน ollama show --parameters จะยังคงแสดงค่าของคุณอยู่เพราะมันอ่านจากโมเดลที่บันทึกไว้และไม่สามารถมองเห็นสิ่งที่ส่งผ่าน HTTP ได้ ให้ลองส่งคำขอหนึ่งครั้งด้วย curl โดยใช้ "options": {"num_predict": 32} แล้วตรวจสอบว่า eval_count ส่งค่ากลับมาเป็น 32 หรือไม่ ซึ่งจะเป็นการยืนยันว่าเซิร์ฟเวอร์ทำงานถูกต้องและปัญหาอยู่ที่แอปพลิเคชันของคุณ

ฉันจะทราบได้อย่างไรว่าผลลัพธ์ถูกตัดจบโดย num_predict

ให้ส่งคำขอด้วย "stream": false แล้วอ่านค่า done_reason หากได้ค่าเป็น stop หมายความว่าโมเดลทำงานเสร็จสิ้นด้วยตัวเอง แต่ถ้าได้ค่าเป็น length หมายความว่าพื้นที่เต็ม จากนั้นให้เปรียบเทียบ eval_count กับค่าจำกัดของคุณ หากค่าตรงกันพอดีแสดงว่า num_predict เป็นตัวหยุดการทำงาน แต่ถ้า eval_count มีค่าน้อยกว่า แสดงว่าหน้าต่างบริบทเต็มก่อน ในกรณีที่ใช้การสตรีม ทั้งสองฟิลด์จะปรากฏใน chunk สุดท้ายพร้อมกับ "done": true ซึ่งไลบรารีไคลเอนต์หลายตัวมักจะตัดทิ้งก่อนที่โค้ดของคุณจะได้รับ

ค่าเริ่มต้นของ num_predict คือเท่าใด

คุณควรตรวจสอบจากเวอร์ชันที่ติดตั้งไว้เองแทนการอ่านจากบทความ ข้อมูล ณ เดือนสิงหาคม 2026 ระบุในเอกสารอ้างอิง Modelfile ของ Ollama ว่าค่าเริ่มต้นคือ -1 ซึ่งหมายความว่าไม่มีการจำกัดการสร้างข้อความ โดยรายการดังกล่าวได้รับการแก้ไขในช่วงปลายปี 2024 หลังจากที่มีการระบุว่าเป็น 128 มาหลายปี ค่าที่เป็นลบถือเป็นค่าสถานะพิเศษไม่ใช่จำนวนนับ และตารางในเวอร์ชันเก่าบางเวอร์ชันยังเคยระบุเป็น -2 สำหรับการเติมเต็มบริบทที่เหลืออยู่ ให้ตรวจสอบ Modelfile parameter reference สำหรับเวอร์ชันของคุณ จากนั้นยืนยันด้วย ollama show --parameters และคำขอ curl หนึ่งรายการ

การเพิ่มค่า num_predict จะทำให้โมเดลเขียนคำตอบยาวขึ้นหรือไม่

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