ตั้งค่า Reasoning Effort บน Local LLM อย่างไรให้คุ้มค่า

การเปลี่ยนแปลงของความพยายามในการใช้เหตุผลบน Local LLM

ความพยายามในการใช้เหตุผล (reasoning effort) คือการตั้งค่าที่กำหนดให้โมเดลเลือกว่าจะใช้เวลาคิดนานเท่าใดก่อนที่จะตอบคำถาม การตั้งค่านี้ส่งผลต่อความยาวของส่วนการใช้เหตุผลเท่านั้นโดยไม่มีผลต่อส่วนอื่น น้ำหนัก (weights) ที่อยู่บนดิสก์จะเหมือนเดิมในทุกระดับ การทำ quantization จะเหมือนเดิม และคำตอบที่ได้จะมาจากการประมวลผลแบบ forward pass เดียวกัน สิ่งที่เปลี่ยนไปคือจำนวนโทเค็นที่โมเดลใช้ในพื้นที่ทดคิด (scratchpad) ของตนเองก่อนเริ่มตอบ

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

ระดับการทำงานอยู่ที่ใด: อยู่ที่ chat template ไม่ใช่ที่ตัว weights

โมเดลประเภท thinking ถูกฝึกมาให้สร้างส่วนการใช้เหตุผล (reasoning segment) ซึ่งมักจะถูกครอบด้วยแท็ก <think> และ </think> ก่อนที่จะแสดงคำตอบสุดท้าย ระดับความพยายาม (effort level) คือคำสั่งที่ chat template ของโมเดลเขียนลงใน prompt โดย template ดังกล่าวเป็นไฟล์ Jinja ที่มาพร้อมกับโมเดล ซึ่งจะอ่านตัวแปรอย่างเช่น reasoning_effort แล้วแสดงผลเป็นบรรทัดระดับ system ที่แตกต่างกันไปตามค่าที่ได้รับ โมเดลถูกฝึกมาให้ย่อหรือขยายพื้นที่ทดเลข (scratchpad) ตามบรรทัดคำสั่งนั้น

ผลที่ตามมามีสองประการ ประการแรก ชื่อระดับการทำงานเป็นของโมเดล ไม่ใช่ของ runtime ของคุณ ดังนั้นชื่อที่ระบุใน model card ของโมเดลหนึ่งอาจไม่มีความหมายสำหรับอีกโมเดลหนึ่ง ประการที่สอง หากมีขั้นตอนใดในกระบวนการเปลี่ยน chat template ของโมเดลไปเป็นแบบทั่วไป ตัวแปรดังกล่าวจะไม่ถูกแสดงผล และการตั้งค่านี้จะไม่มีผลใดๆ โดยไม่มีการแจ้งเตือน

จากการตรวจสอบเมื่อวันที่ 2026-10-12 model card ของ Qwen3.8-27B ระบุระดับความพยายามไว้ 3 ระดับ ได้แก่ low, medium และ xhigh โดยมี xhigh เป็นค่าเริ่มต้น และไม่มีระดับ high การเปิดใช้งานการคิด (thinking) ควบคุมด้วย enable_thinking ซึ่งเปิดใช้งานเป็นค่าเริ่มต้น นอกจากนี้ model card ยังระบุถึง preserve_thinking ซึ่งเปิดใช้งานเป็นค่าเริ่มต้นเช่นกัน โดยทำหน้าที่เก็บข้อมูลการใช้เหตุผลจากรอบการสนทนาก่อนหน้าไว้ในประวัติการสนทนา ส่วน gpt-oss ใช้ low, medium และ high แทน โมเดลตระกูลอื่นๆ อีกจำนวนมากรับค่าเพียงแค่ boolean เท่านั้น โปรดอ่าน model card สำหรับเวอร์ชันที่คุณใช้งานจริง เนื่องจากชื่อเหล่านี้ไม่ใช่มาตรฐานสากล การรันโมเดลขนาด 27B บน VPS คือขั้นตอนแรก ส่วนหน้านี้จะอธิบายถึงการตั้งค่าหลังจากที่โมเดลเริ่มตอบสนองแล้ว

เหตุใดการประมวลผลที่ใช้ทรัพยากรสูงจึงมีต้นทุนบน VPS มากกว่า

Output tokens. Reasoning tokens คือโทเค็นที่ถูกสร้างขึ้นในระหว่างการประมวลผล ซึ่งต้องผ่านกระบวนการถอดรหัส (decode loop) เช่นเดียวกับคำตอบ โดยความเร็วจะขึ้นอยู่กับประสิทธิภาพของฮาร์ดแวร์ สมมติว่างานหนึ่งสร้างคำตอบ 200 โทเค็นและต้องใช้ Reasoning tokens 4,000 โทเค็น คุณจะต้องสร้างโทเค็นรวม 4,200 โทเค็น แม้ว่าผู้ใช้จะเห็นเพียง 200 โทเค็นก็ตาม อัตราการถอดรหัสจะถูกกำหนดโดยแบนด์วิดท์ของหน่วยความจำ, ระดับการทำ quantisation ที่คุณเลือก และจำนวนเธรดที่ใช้ โดยบันทึกการปรับแต่งของ llama.cpp เตือนว่าค่า --threads ที่สูงกว่าจำนวนคอร์จริงของ CPU จะทำให้ CPU ทำงานหนักเกินไปจนการสร้างโทเค็นช้าลงอย่างมาก เมื่อปรับแต่งค่าเหล่านี้แล้ว สิ่งเดียวที่เหลือให้ควบคุมคือจำนวนโทเค็นทั้งหมด

Wall clock. ผู้ใช้ต้องรอจนกว่าโทเค็นแรกของ คำตอบ จะปรากฏขึ้น เนื่องจากสิ่งที่เกิดขึ้นก่อนหน้านั้นจะเป็นเพียงหน้าจอว่างหรือไอคอนโหลด เนื่องจาก Reasoning tokens จะถูกสร้างออกมาก่อน ระยะเวลาที่ต้องรอจึงเท่ากับจำนวน Reasoning tokens หารด้วยอัตราการถอดรหัส บวกกับเวลาในการประมวลผล prompt หากเพิ่มความยาวของ Reasoning tokens เป็นสองเท่า ระยะเวลาที่ต้องรอก็จะเพิ่มขึ้นเป็นสองเท่าเช่นกัน

Context. Reasoning tokens จะใช้พื้นที่ใน context window เช่นเดียวกับโทเค็นอื่นๆ หากเปิดใช้งาน preserve_thinking ข้อมูลจาก scratchpad ในรอบแรกจะยังคงอยู่ใน prompt ของรอบที่ห้า ส่งผลให้การประมวลผล prompt ช้าลงในทุกรอบที่ผ่านไปเนื่องจากหน้าต่าง context ถูกเติมเต็มจากทั้งสองฝั่ง การ เพิ่มค่า num_ctx เพื่อรองรับข้อมูล จะทำให้ต้องใช้หน่วยความจำ KV cache เพิ่มขึ้น ซึ่งบน VPS ที่ไม่มี GPU หน่วยความจำนี้คือ RAM ของระบบที่คุณอาจไม่มีเหลือเพียงพอ

เมื่อใดควรเพิ่มระดับ และเมื่อใดควรคงระดับไว้ต่ำ

ให้เพิ่มระดับสำหรับงานที่ขั้นตอนกลางที่ผิดพลาดอาจส่งผลเสียต่อผลลัพธ์ทั้งหมด เช่น การคำนวณเลขหลายขั้นตอนและการแปลงหน่วย, การวางแผนแก้ไขไฟล์หลายไฟล์, โค้ดที่ต้องคอมไพล์ และปัญหาที่มีข้อจำกัดซึ่งคำตอบหนึ่งต้องสอดคล้องกับเงื่อนไขหลายประการพร้อมกัน ในงานเหล่านี้ พื้นที่ทดเลข (scratchpad) กำลังทำงานจริง และการใช้พื้นที่ที่ยาวขึ้นเป็นวิธีราคาถูกในการตรวจจับข้อผิดพลาดที่โมเดลอาจเผลอทำลงไปหากไม่มีพื้นที่ดังกล่าว

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

ให้คงระดับไว้ต่ำสำหรับงานที่มีการโต้ตอบด้วยเช่นกัน ในช่องแชทหรือโปรแกรมแก้ไขข้อความ คุณอยู่ในวงจรการทำงาน ดังนั้นคำตอบที่รวดเร็วซึ่งคุณสามารถแก้ไขได้นั้นดีกว่าคำตอบที่ช้าซึ่งคุณต้องรอ นั่นคือการแลกเปลี่ยนที่แท้จริงเบื้องหลัง การชี้เป้า coding agent ไปยัง local model: agent จะทำการเรียกใช้งานขนาดเล็กจำนวนมาก และภาษีของการใช้เหตุผลจะถูกเรียกเก็บในทุกๆ ครั้งที่เรียกใช้งานนั้น

วิธีการตั้งค่าระดับใน llama.cpp

llama.cpp จะเขียนตัวแปรลงในเทมเพลตโดยตรง ซึ่งทำให้เป็นรันไทม์ที่คุณมั่นใจได้ว่าระดับนั้นถูกส่งไปถึงแล้ว ให้ชี้ -m ไปยังไฟล์ GGUF ที่คุณมีอยู่แล้ว

llama-server -m ./qwen3.8-27b-Q4_K_M.gguf \
  --jinja \
  --reasoning-effort medium \
  --reasoning-format deepseek \
  -c 32768 \
  --host 127.0.0.1 --port 8080

--jinja จะใช้ chat template ของตัวโมเดลเองและถูกเปิดใช้งานเป็นค่าเริ่มต้นในบิลด์ปัจจุบัน --reasoning-effort รองรับ default, minimal, low, medium, high, xhigh หรือ max โดยที่ default หมายถึงให้คงค่าเริ่มต้นของเทมเพลตไว้ตามเดิม รายการดังกล่าวเป็นคำศัพท์ของ llama.cpp ไม่ใช่ของตัวโมเดล ดังนั้นให้ระบุเฉพาะชื่อที่การ์ดแสดงไว้เท่านั้น: ระดับที่เทมเพลตไม่ได้กำหนดไว้อาจทำให้เกิดข้อผิดพลาดของเทมเพลตในขณะที่ส่งคำขอ --reasoning-format deepseek จะย้ายการใช้เหตุผลออกจาก message.content ไปไว้ใน message.reasoning_content ซึ่งเป็นสิ่งที่ทำให้การแยกส่วนสามารถวัดผลได้ในส่วนถัดไป

หากต้องการปิดการคิดแทนที่จะทำให้สั้นลง ให้ตั้งค่าตัวแปรเทมเพลตด้วยตัวเอง:

llama-server -m ./qwen3.8-27b-Q4_K_M.gguf --jinja \
  --chat-template-kwargs '{"enable_thinking": false}'

--reasoning-budget เป็นกลไกที่แตกต่างออกไป โดยจะจำกัดส่วนการใช้เหตุผลเป็นจำนวนโทเค็น โดยที่ 0 จะเป็นการยุติการใช้เหตุผลทันที และ -1 จะเป็นการปล่อยให้เป็นอิสระโดยไม่จำกัด แทนที่จะเป็นการขอให้โมเดลวางแผนให้สั้นลง แฟล็กทั้งสองตัวจะตั้งค่าเริ่มต้นของเซิร์ฟเวอร์ ณ วันที่ 2026-10-12 ตัว /v1/chat/completions ของ llama-server ยังรองรับ reasoning_effort และ chat_template_kwargs ในส่วนเนื้อหาของคำขอ (request body) ซึ่งเป็นการส่งระดับไปยังเทมเพลตสำหรับการเรียกใช้งานนั้นๆ โดยมี none ทำหน้าที่ปิดการใช้เหตุผล ดังนั้นกระบวนการเดียวจึงสามารถให้บริการระดับความพยายามที่แตกต่างกันสองระดับได้

vLLM เปิดเผยตัวแปรเดียวกันต่อคำขอ ภายในเนื้อหาที่เข้ากันได้กับ OpenAI:

{"model": "Qwen/Qwen3.8-27B",
 "messages": [{"role": "user", "content": "Summarise this changelog in two lines."}],
 "chat_template_kwargs": {"reasoning_effort": "medium"}}

วิธีการตั้งค่าระดับใน Ollama

Ollama มีฟิลด์เฉพาะของตนเองคือ think ซึ่งอยู่ใน /api/chat และ /api/generate โดยรองรับค่า true, false หรือชื่อระดับที่กำหนด ณ วันที่ 2026-10-12 สำหรับโมเดลที่เผยแพร่ข้อมูล metadata ของการคิด (thinking metadata) ชื่อระดับจะเป็นไปตามที่โมเดลนั้นกำหนดเอง โดย /api/show จะแสดงรายการระดับต่างๆ ไว้ภายใต้ thinking.values พร้อมค่าเริ่มต้นกำกับไว้ หากระบุชื่อที่โมเดลไม่ได้ระบุไว้ ระบบจะย้อนกลับไปใช้ค่าเริ่มต้นโดยไม่มีข้อผิดพลาด สำหรับโมเดลที่ไม่มี metadata จะใช้ชุดค่าคงที่เดิมของ Ollama ได้แก่ low, medium, high และ max หากไม่ระบุ think ระบบจะใช้ค่าเริ่มต้นของโมเดลนั้นๆ ซึ่งสำหรับ Qwen3.8 จะเปิดใช้งานการคิดไว้เป็นค่าเริ่มต้น

ollama run qwen3.8:27b --think=low "Draft a one line commit message for a README typo fix"

{"model": "qwen3.8:27b",
 "messages": [{"role": "user", "content": "Which HTTP status code means the request body was too large?"}],
 "think": "low",
 "stream": false}

ข้อมูลการใช้เหตุผลจะถูกส่งกลับมาใน message.thinking และคำตอบจะอยู่ใน message.content ซึ่งถูกแยกส่วนไว้ให้เรียบร้อยแล้ว ในระหว่างการใช้งานผ่าน ollama run แบบโต้ตอบ คุณสามารถใช้ /set think และ /set nothink เพื่อเปิดหรือปิดการทำงานได้โดยไม่ต้องรีสตาร์ท และใช้ /set think low เพื่อเลือกระดับที่ต้องการ

โปรดสังเกตจุดที่อาจเกิดความล้มเหลวโดยไม่มีการแจ้งเตือน เทมเพลตของ Qwen3.8 กำหนดระดับไว้ที่ low, medium และ xhigh โมเดลของ Ollama จะมีเทมเพลตที่บรรจุอยู่ภายใน tag ของตัวมันเอง แทนที่จะใช้ไฟล์ Jinja จาก repository ต้นฉบับ และ Ollama จะส่งผ่านระดับไปให้ก็ต่อเมื่อโมเดลที่บรรจุอยู่นั้นระบุระดับดังกล่าวไว้เท่านั้น ให้ตรวจสอบสิ่งที่ tag ของคุณประกาศไว้ก่อนเป็นอันดับแรก:

curl -s http://localhost:11434/api/show -d '{"model": "qwen3.8:27b"}' | jq .thinking

ชื่อระดับที่ไม่อยู่ใน values เช่น high หรือ max สำหรับโมเดลนี้ จะทำงานที่ระดับเริ่มต้นแทน อย่าทึกทักเอาเองว่าการตั้งค่าทำงานได้ผล การวัดผลต้องใช้เวลาประมาณหนึ่งนาที

วิธีวัดว่าระดับการประมวลผลถูกนำไปใช้จริงหรือไม่

ให้ส่ง prompt เดียวกันโดยใช้ระดับที่ต่างกันมากกว่าหนึ่งระดับ โดยตั้งค่า temperature ไว้ที่ 0 จากนั้นเปรียบเทียบจำนวน token ที่ได้ ชื่อทั้งสามด้านล่างนี้คือชื่อที่ระบุไว้ในการ์ดของ Qwen3.8 หาก /api/show แสดงชื่อที่ต่างออกไปสำหรับ tag ของคุณ ให้ใช้ชื่อเหล่านั้นแทน ที่นี่ jq จะทำหน้าที่สร้างเนื้อหาให้คุณ เพื่อที่คุณจะได้ไม่ต้องคอย escape เครื่องหมายคำพูดด้วยตนเอง

for level in low medium xhigh; do
  body=$(jq -n --arg lvl "$level" '{
    model: "qwen3.8:27b",
    messages: [{role: "user", content: "A pump fills a 4500 litre tank in 25 minutes. A second pump is 40 percent slower. How long do both together take? Answer in minutes."}],
    think: $lvl,
    stream: false,
    options: {temperature: 0, num_ctx: 8192}
  }')
  echo "== $level"
  curl -s http://localhost:11434/api/chat -d "$body" | jq '{
    thinking_chars: (.message.thinking // "" | length),
    answer_chars: (.message.content | length),
    eval_count: .eval_count,
    seconds: (.total_duration / 1e9),
    tok_per_sec: (.eval_count / (.eval_duration / 1e9))
  }'
done

eval_count คือจำนวน token ทั้งหมดที่ถูกสร้างขึ้นรวมถึงส่วนการใช้เหตุผลด้วย ดังนั้นส่วนต่างระหว่างสองระดับจึงเป็นส่วนของการใช้เหตุผลเกือบทั้งหมด thinking_chars จะแสดงผลลัพธ์ที่แยกออกมาให้คุณโดยตรง ควรมีสองสิ่งที่เกิดขึ้นจริงคือ ตัวเลขมีการเปลี่ยนแปลงระหว่างระดับ และคำตอบยังคงถูกต้องในระดับที่ต่ำกว่า หาก eval_count อยู่ในเกณฑ์ความคลาดเคลื่อน (noise) ตลอดการรันทั้งสามครั้ง แสดงว่าระดับนั้นถูกเพิกเฉย ให้ตรวจสอบชื่อเทียบกับ /api/show ก่อน เนื่องจาก Ollama จะรันชื่อที่ไม่ได้ระบุไว้ด้วยค่าเริ่มต้น หากชื่อตรงกัน วิธีแก้ไขคือการใช้ runtime ที่ส่งผ่านระดับไปให้

เวลาทั้งหมดเป็นเพียงครึ่งหนึ่งของเรื่องราวเท่านั้น ดังนั้นให้วัดระยะเวลาจนถึง token คำตอบแรกโดยการทำ streaming และหยุดที่ chunk content แรกที่ไม่ว่างเปล่า ส่วนนี้จำเป็นต้องใช้ jq และ bc

start=$(date +%s.%N)
curl -sN http://localhost:11434/api/chat -d '{
  "model": "qwen3.8:27b",
  "messages": [{"role": "user", "content": "Explain what a reverse proxy does, in three sentences."}],
  "think": "low",
  "stream": true
}' |
while IFS= read -r line; do
  if [ -n "$(printf '%s' "$line" | jq -r '.message.content // ""')" ]; then
    echo "first answer token after $(echo "$(date +%s.%N) - $start" | bc)s"
    break
  fi
done

รันที่ low และรันอีกครั้งที่ xhigh ส่วนต่างที่ได้คือระยะเวลาการรอคอยที่คุณได้รับ สำหรับ llama.cpp ตัวเลขเดียวกันจะถูกส่งกลับมาภายใน response โดยไม่จำเป็นต้องคำนวณผ่าน shell:

curl -s http://localhost:8080/v1/chat/completions \
  -H 'Content-Type: application/json' \
  -d '{"model": "local", "temperature": 0,
       "messages": [{"role": "user", "content": "A pump fills a 4500 litre tank in 25 minutes. A second pump is 40 percent slower. How long do both together take?"}]}' | jq '{
  reasoning_chars: (.choices[0].message.reasoning_content // "" | length),
  answer_chars: (.choices[0].message.content | length),
  predicted_n: .timings.predicted_n,
  tok_per_sec: .timings.predicted_per_second
}'

ให้ดำเนินการนี้บนเครื่องของคุณเอง การเปรียบเทียบประสิทธิภาพที่เผยแพร่ทั่วไปเป็นการวัดบนฮาร์ดแวร์ที่ไม่ใช่ของคุณ และอัตราการ decode ของคุณคือปัจจัยที่จะเปลี่ยนจำนวน token ให้เป็นวินาที การวัดจำนวน token ต่อวินาทีบนเซิร์ฟเวอร์ของคุณเอง จะให้ค่าปัจจัยนั้นแก่คุณ โดยนำจำนวน token ของการใช้เหตุผลหารด้วยอัตราการ decode ของคุณ ก็จะได้ระยะเวลาการรอคอยที่คุณเพิ่งเพิ่มเข้าไป

สิ่งที่มักเกิดข้อผิดพลาด

คำตอบถูกตัดทอน หรือ content ว่างเปล่าในขณะที่ thinking เต็ม ขีดจำกัดในการสร้างข้อความถูกใช้ไปกับการประมวลผลเชิงตรรกะ (reasoning) ค่า num_predict ของ Ollama จะจำกัดจำนวนโทเค็นทั้งหมดรวมถึงส่วนการประมวลผลด้วย และเนื่องจากส่วนการประมวลผลจะถูกสร้างขึ้นก่อน การตั้งค่าขีดจำกัดไว้ที่ 512 โทเค็นสำหรับงานที่ใช้ความพยายามสูงอาจทำให้การตอบสนองสิ้นสุดลงก่อนที่คำตอบจริงจะเริ่มขึ้น Ollama จะรายงานสถานะ "done_reason": "length" สำหรับการตอบสนองนั้น ให้เพิ่มขีดจำกัดหรือลดระดับความพยายามลง วิธีที่ num_predict นับจำนวนโทเค็น ได้อธิบายการทำงานส่วนนี้ไว้อย่างละเอียด

ระดับความพยายามไม่มีผลต่อการเปลี่ยนแปลง จำนวนโทเค็นจะเท่ากันในทุกระดับ สาเหตุอาจเกิดจาก runtime ไม่ได้ส่งตัวแปรดังกล่าว, template ไม่ได้อ่านค่าตัวแปรนั้น หรือในกรณีของ Ollama ชื่อตัวแปรไม่ตรงกับที่ระบุไว้ใน tag จึงกลับไปใช้ค่าเริ่มต้น ให้ตรวจสอบ template ที่ runtime ของคุณใช้งานจริงแทนการดูจาก repository ต้นฉบับ สำหรับ llama.cpp ที่ใช้ --jinja และ --chat-template-kwargs จะมีการเขียนตัวแปรลงไปโดยตรง ซึ่งถือเป็นตัวควบคุมที่ดี หากระดับความพยายามทำงานได้ในกรณีนี้แต่ใช้ไม่ได้ในที่อื่น แสดงว่าตัวโมเดลปกติดีแต่ runtime อื่นเป็นตัวตัดค่าดังกล่าวทิ้ง

ชื่อระดับความพยายามถูกปฏิเสธ ข้อผิดพลาดของ template ในขณะส่งคำขอ หรือความล้มเหลวในการส่งข้อความแรกกับเซิร์ฟเวอร์ที่ปกติ มักหมายความว่าคุณได้ระบุระดับที่ template ไม่ได้นิยามไว้ เช่น การส่ง high ไปยังโมเดลที่ระบุไว้ใน card ว่ารองรับเพียง low, medium และ xhigh เท่านั้น สำหรับ Ollama โมเดลที่ไม่มี metadata เกี่ยวกับการคิดจะยอมรับเพียง low, medium, high และ max เท่านั้น หากระบุเป็นอย่างอื่นจะได้รับข้อผิดพลาด invalid think value กลับมา

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

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

การรันสองระดับพร้อมกัน

llama.cpp กำหนดระดับเริ่มต้นไว้ที่การเริ่มทำงานด้วย --reasoning-effort แต่รุ่นปัจจุบันยังรองรับ reasoning_effort ต่อคำขอ ดังนั้นหนึ่งกระบวนการและน้ำหนักโมเดลหนึ่งชุดจึงสามารถให้บริการตัวแก้ไขที่ระดับต่ำและงานประมวลผลแบบกลุ่มในตอนกลางคืนที่ระดับสูงกว่าได้ หากคุณต้องการกำหนดระดับตายตัวตั้งแต่เริ่มทำงาน การรันสองกระบวนการบนสองพอร์ตก็สามารถทำได้เช่นกัน แต่ต้องแลกด้วยการใช้หน่วยความจำสำหรับน้ำหนักโมเดลสองชุด เว้นแต่คุณจะแยกเวลางานออกจากกัน ไม่ว่าจะใช้วิธีใด งานทั้งสองจะใช้ความสามารถในการถอดรหัสของเครื่องร่วมกัน ดังนั้นบน VPS หนึ่งเครื่อง การจัดสรรที่ประหยัดที่สุดมักจะเป็นการใช้ความพยายามต่ำสำหรับงานที่ผู้ใช้รอผลลัพธ์อยู่ และใช้การรันที่ความพยายามสูงตามกำหนดเวลาสำหรับงานที่ไม่มีใครเฝ้าดู สิ่งที่เกิดขึ้นเมื่อผู้ใช้หลายคนแชร์โมเดลในเครื่องเดียวกัน สามารถนำมาปรับใช้ในกรณีนี้ได้เช่นกัน เนื่องจากโทเค็นการใช้เหตุผลถือเป็นงานถอดรหัส การเพิ่มความพยายามจึงส่งผลให้ความสามารถในการประมวลผลพร้อมกันลดลงในสัดส่วนที่ใกล้เคียงกับจำนวนโทเค็นที่เพิ่มขึ้น

FAQ

ฉันควรใช้ระดับความพยายามในการคิด (reasoning effort) ระดับใดเป็นค่าเริ่มต้น?

ให้เริ่มจากระดับต่ำที่สุดที่โมเดลรองรับ และปรับเพิ่มเฉพาะกับงานที่คุณพบว่าโมเดลทำงานล้มเหลวเท่านั้น โมเดลสำหรับการคิดหลายตัวถูกตั้งค่าเริ่มต้นไว้สูง โดย Qwen3.8-27B ตั้งค่าเริ่มต้นไว้ที่ xhigh ซึ่งเป็นระดับสูงสุด ณ เดือนตุลาคม 2026 ค่าเริ่มต้นนี้ถูกเลือกมาเพื่อให้ผลลัพธ์ดูดีบนตารางเกณฑ์มาตรฐาน (benchmark) ซึ่งตารางเหล่านั้นไม่ได้คิดค่าใช้จ่ายตามเวลาที่ใช้ แต่บนฮาร์ดแวร์ของคุณ คุณต้องจ่ายเป็นเวลาที่เสียไป ดังนั้นควรเลือกใช้ระดับที่สูงขึ้นเฉพาะงานที่จำเป็น แทนที่จะให้ทุกคำขอใช้การตั้งค่าระดับสูงโดยอัตโนมัติ

reasoning tokens นับรวมอยู่ใน context window หรือไม่?

นับรวมครับ โทเค็นเหล่านี้เป็นโทเค็นปกติในส่วนของผลลัพธ์และจะถูกเก็บไว้ใน context window เช่นเดียวกับข้อมูลอื่น ส่วนการที่โทเค็นเหล่านี้จะยังคงอยู่ในการโต้ตอบครั้งถัดไปหรือไม่นั้น ขึ้นอยู่กับ runtime และโมเดลที่ใช้ เอกสารของ Qwen3.8 ระบุถึง preserve_thinking ซึ่งเปิดใช้งานเป็นค่าเริ่มต้น โดยจะเก็บประวัติการคิดก่อนหน้าไว้ในประวัติการสนทนา ดังนั้นการสนทนาที่ยาวนานจะสะสม scratchpad ทั้งหมดที่เคยสร้างขึ้นมา หากต้องการลดภาระ ให้ตั้งค่าเป็น false หรือลบฟิลด์ thinking ออกจากข้อความที่คุณส่งซ้ำ เพื่อไม่ให้การประมวลผล prompt ขยายตัวเพิ่มขึ้น

ทำไมการเปลี่ยนระดับการคิดถึงไม่มีผลต่อจำนวนโทเค็นของฉัน?

การตั้งค่าดังกล่าวอาจส่งไปไม่ถึง chat template เนื่องจากระดับการคิดเป็นตัวแปรในเทมเพลต มันจะทำงานได้ก็ต่อเมื่อ runtime ส่งค่าผ่านไปและเทมเพลตที่ใช้รองรับการอ่านค่านั้น runtime บางตัวเลือกใช้เทมเพลตของตัวเองแทนที่จะใช้ไฟล์ Jinja จาก repository ต้นฉบับ ทำให้ตัวแปรดังกล่าวถูกละทิ้งโดยไม่มีการแจ้งเตือนข้อผิดพลาดใดๆ นอกจากนี้ Ollama อาจรันด้วยชื่อระดับที่โมเดลไม่ได้ระบุไว้ในค่าเริ่มต้นของโมเดลเอง โดยไม่มีการแจ้งเตือนเช่นกัน คุณสามารถตรวจสอบได้โดยส่ง prompt เดียวกันในระดับต่ำสุดและสูงสุด โดยตั้งค่า temperature ไว้ที่ 0 แล้วเปรียบเทียบค่า eval_count หากจำนวนโทเค็นเท่ากันหรือต่างกันเพียงเล็กน้อย แสดงว่าระดับการคิดนั้นถูกละเลย

การลดระดับความพยายามในการคิดจะทำให้โมเดลมีความแม่นยำน้อยลงหรือไม่?

ขึ้นอยู่กับลักษณะงาน ซึ่งควรวัดผลจริงแทนการคาดเดา ในงานที่คำตอบมีอยู่ใน input อยู่แล้ว เช่น การดึงข้อมูลหรือการเขียนใหม่ การใช้ scratchpad ที่สั้นลงมักไม่มีผลใดๆ แต่ในงานที่ต้องอาศัยขั้นตอนกลางที่ถูกต้องก่อนจะถึงขั้นตอนสุดท้าย เช่น การคำนวณหลายขั้นตอนหรือการเขียนโค้ดที่ต้องคอมไพล์ได้ ความแม่นยำจะลดลงหาก scratchpad สั้นเกินไป ให้สร้างชุด prompt จำนวน 20 รายการจากงานจริงของคุณ รันที่สองระดับโดยตั้งค่า temperature ไว้ที่ 0 แล้วนับจำนวนคำตอบที่ผิด ตัวเลขนั้นจะเป็นค่าเฉพาะสำหรับงานของคุณ ซึ่งไม่มีตารางเกณฑ์มาตรฐานใดสามารถบอกคุณได้