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

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

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

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

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

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

บริบท (Context) โทเค็นการใช้เหตุผลจะใช้พื้นที่ในหน้าต่างบริบท (context window) เช่นเดียวกับโทเค็นอื่น เมื่อเปิดใช้งาน preserve_thinking ข้อมูลจาก scratchpad ในเทิร์นแรกจะยังคงอยู่ใน prompt จนถึงเทิร์นที่ห้า ส่งผลให้การประมวลผล prompt ช้าลงในทุกเทิร์นขณะที่หน้าต่างบริบทเต็มจากทั้งสองฝั่ง การ เพิ่มค่า 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 จะเป็นการปล่อยให้ใช้งานได้โดยไม่จำกัด แทนที่จะเป็นการขอให้โมเดลวางแผนให้สั้นลง ทั้งสองแฟล็กนี้มีผลกับทั้งเซิร์ฟเวอร์ llama-server ไม่รองรับ reasoning_effort ในฐานะฟิลด์ต่อคำขอ ดังนั้นการให้บริการระดับความพยายามสองระดับในเวลาเดียวกันจึงหมายถึงการรันสองกระบวนการบนสองพอร์ต

vLLM เปิดให้เข้าถึงตัวแปรเดียวกันได้ในแต่ละคำขอ ภายใน body ที่รองรับ 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 หรือค่าใดค่าหนึ่งจาก low, medium, high และ max ซึ่ง max จะเป็นการร้องขอระดับสูงสุดที่โมเดลนั้นๆ รองรับ โดยค่าเริ่มต้นฟีเจอร์ Thinking จะถูกเปิดใช้งานสำหรับโมเดลที่รองรับ

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}

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

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

วิธีวัดว่าระดับที่ตั้งไว้มีผลจริงหรือไม่

ให้ส่ง prompt เดียวกันโดยใช้ระดับที่ต่างกันหลายระดับ โดยตั้งค่า temperature ไว้ที่ 0 จากนั้นเปรียบเทียบจำนวน token ที่ได้ ในที่นี้ jq จะทำหน้าที่สร้างเนื้อหาของ body เพื่อให้คุณไม่ต้องคอยหลีกเลี่ยงเครื่องหมายคำพูดด้วยตนเอง

for level in low medium max; 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 ทั้งหมดที่ถูกสร้างขึ้นรวมถึงส่วนของการใช้เหตุผล (reasoning) ดังนั้นช่องว่างระหว่างสองระดับจึงเกือบทั้งหมดเป็นส่วนของ reasoning thinking_chars จะแสดงผลการแยกส่วนให้คุณโดยตรง โดยควรเป็นจริงสองประการคือ ตัวเลขต้องมีการเปลี่ยนแปลงระหว่างระดับ และคำตอบยังคงถูกต้องในระดับที่ต่ำกว่า หาก eval_count อยู่ในระดับที่ใกล้เคียงกับสัญญาณรบกวน (noise) ในการทดสอบทั้งสามครั้ง แสดงว่าระดับนั้นถูกละเลย วิธีแก้ไขคือการใช้ 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 และรันอีกครั้งที่ max ความแตกต่างที่ได้คือระยะเวลาการรอคอยที่คุณต้องแลกมา บน 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 rate) ของคุณคือตัวแปรที่จะเปลี่ยนจำนวน token ให้เป็นวินาที การวัดจำนวน token ต่อวินาทีบนเซิร์ฟเวอร์ของคุณเอง จะให้ค่าตัวแปรดังกล่าวแก่คุณ โดยนำจำนวน token ของการใช้เหตุผลหารด้วยอัตราการถอดรหัสของคุณ จะได้เป็นระยะเวลาการรอคอยที่คุณเพิ่งเพิ่มเข้าไป

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

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

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

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

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

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

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

llama.cpp จะกำหนดระดับการทำงานไว้ตั้งแต่ตอนเริ่มต้น ดังนั้นหากต้องการให้เครื่องเดียวรองรับทั้งการใช้งานผ่าน editor และการประมวลผลแบบ batch ในช่วงกลางคืน จำเป็นต้องรันสองกระบวนการ (process) บนพอร์ตที่ต่างกัน โดยแต่ละกระบวนการต้องมี --reasoning-effort เป็นของตนเอง การรันสองกระบวนการหมายถึงการโหลดข้อมูล weights ไว้ในหน่วยความจำสองชุด เว้นแต่คุณจะใช้วิธีแยกช่วงเวลาการทำงานแทน สำหรับ VPS หนึ่งเครื่อง วิธีที่ประหยัดที่สุดคือการรันเซิร์ฟเวอร์ที่ใช้ทรัพยากรต่ำสำหรับงานที่ต้องการการตอบสนองทันที ควบคู่ไปกับการตั้งเวลาประมวลผลงานที่ใช้ทรัพยากรสูงในช่วงเวลาที่ไม่มีผู้ใช้งาน เกิดอะไรขึ้นเมื่อผู้ใช้หลายคนแชร์โมเดลในเครื่องเดียวกัน สามารถนำมาประยุกต์ใช้ในกรณีนี้ได้เช่นกัน เนื่องจาก reasoning tokens ถือเป็นภาระงานในส่วนของการถอดรหัส (decode) ดังนั้นการเพิ่มระดับความพยายาม (effort) จะส่งผลให้ความสามารถในการรองรับผู้ใช้งานพร้อมกัน (concurrency) ลดลงในสัดส่วนที่ใกล้เคียงกับจำนวน token ที่เพิ่มขึ้น

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

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

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