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

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

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

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

num_predict ไม่ใช่ num_ctx

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

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

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

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

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

กำหนดค่าต่อคำขอในออบเจกต์ 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 ข้อมูลอ้างอิง Ollama Modelfile ระบุค่าเริ่มต้นไว้ที่ -1 ซึ่งคือการสร้างข้อความแบบไม่จำกัด และตารางในเวอร์ชันก่อนหน้าก็เคยระบุ -2 สำหรับการเติมเต็มบริบทเช่นกัน

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

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

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

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

"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 โทเค็นจะทำให้เครื่องทำงานค้างนานกว่าสี่นาที โดยที่โมเดลไม่ทราบว่าคุณต้องการเพียงแค่ย่อหน้าเดียว โมเดลบางตัวอาจเกิดการวนลูป โดยทำซ้ำวลีเดิมจนกว่าจะมีสิ่งใดมาหยุดมัน หากไม่มีการจำกัดค่า คำขอเดียวนี้จะทำให้คอร์ประมวลผลทำงานไม่ว่างจนกว่า context window จะเต็ม num_predict คือการตั้งค่าที่ใช้กำหนดขอบเขตดังกล่าว ซึ่งมีความสำคัญที่สุดบน Ollama VPS ที่โฮสต์ด้วยตนเอง ขนาดเล็ก ที่ซึ่งคำขอที่ยาวเพียงรายการเดียวอาจกินทรัพยากรของทั้งเครื่องได้

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

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

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

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

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

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

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

ทำไมการตั้งค่า 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 มานานหลายปี ค่าที่เป็นลบถือเป็นค่าสถานะ (sentinel) ไม่ใช่จำนวนนับ และตารางรุ่นเก่าบางแห่งเคยระบุเป็น -2 สำหรับการเติมเต็มบริบทที่เหลือ โปรดตรวจสอบ Modelfile parameter reference สำหรับเวอร์ชันของคุณ จากนั้นยืนยันด้วย ollama show --parameters และคำขอ curl หนึ่งรายการ

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

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