Cara Tetapan Reasoning Effort Berfungsi pada Local LLM

Perubahan usaha penaakulan pada LLM tempatan

Usaha penaakulan (reasoning effort) ialah tetapan yang menentukan tempoh masa model berfikir sebelum memberikan jawapan. Tetapan ini hanya mengubah panjang segmen penaakulan dan tiada perkara lain. Wajaran (weights) pada cakera adalah sama pada setiap tahap, kuantisasi adalah serupa, dan jawapan terhasil daripada hantaran hadapan (forward pass) yang sama. Perkara yang berubah ialah bilangan token yang digunakan oleh model pada ruang contengan (scratchpad) peribadinya terlebih dahulu.

Perbezaan ini penting kerana lokasi token tersebut berakhir. Pada API yang dihoskan, token penaakulan akan muncul dalam invois. Pada VPS milik anda, kosnya dibayar melalui masa penjanaan pada CPU atau GPU anda sendiri, serta ruang di dalam tetingkap konteks (context window). Model yang dibiarkan pada tahap usaha tertinggi boleh menghabiskan sebahagian besar outputnya untuk penaakulan sebelum perkataan pertama jawapan muncul. Pada perkakasan yang dihoskan sendiri, ini merupakan perbezaan antara balasan dua saat dengan balasan dua minit.

Di mana tahap tersebut berada: templat sembang, bukan pemberat

Model pemikiran dilatih untuk mengeluarkan segmen penaakulan, biasanya dibalut dengan tag <think> dan </think>, sebelum jawapan akhirnya. Tahap usaha ialah arahan yang ditulis oleh templat sembang model ke dalam prompt. Templat tersebut ialah fail Jinja yang disertakan bersama model. Ia membaca pemboleh ubah seperti reasoning_effort dan merender baris peringkat sistem yang berbeza bagi setiap nilai, dan model tersebut telah dilatih untuk memendekkan atau memanjangkan scratchpad sebagai tindak balas kepada baris tersebut.

Dua perkara berikut berlaku. Nama tahap adalah milik model dan bukan milik runtime anda, jadi nama daripada kad satu model mungkin tidak bermakna bagi model yang lain. Dan jika mana-mana bahagian dalam rantaian menukar templat sembang model kepada templat generik, pemboleh ubah tersebut tidak akan dirender dan tetapan itu tidak akan memberikan sebarang kesan secara senyap.

Disemak pada 2026-08-20, kad model Qwen3.8-27B mendokumenkan tiga tahap usaha: low, medium dan xhigh, dengan xhigh sebagai lalai. Tiada high. Pemikiran itu sendiri ditukar dengan enable_thinking, yang dihidupkan secara lalai, dan kad tersebut juga mendokumenkan preserve_thinking, yang dihidupkan secara lalai, yang mengekalkan penaakulan daripada giliran terdahulu dalam sejarah perbualan. gpt-oss menggunakan low, medium dan high sebagai gantinya. Banyak keluarga model lain menerima boolean dan tiada yang lain. Baca kad bagi versi tepat yang anda ambil, kerana nama-nama ini bukanlah satu standard. Menjalankan model 27B pada VPS diutamakan. Halaman ini adalah mengenai perkara yang perlu ditetapkan sebaik sahaja ia memberikan jawapan.

Mengapa usaha tinggi menelan kos lebih tinggi pada VPS

Token output. Token penaakulan ialah token yang dijana. Ia melalui gelung penyahkodan yang sama seperti jawapan, pada kadar token sesaat yang mampu dikendalikan oleh perkakasan anda. Andaikan satu tugasan menghasilkan 200 token jawapan dan 4,000 token penaakulan. Anda menjana 4,200 token dan pembaca hanya melihat 200 daripadanya. Kadar penyahkodan anda ditetapkan oleh lebar jalur memori dan kuantisasi yang anda pilih, jadi satu-satunya tuil yang tinggal ialah jumlah token itu sendiri.

Masa sebenar. Seseorang perlu menunggu token pertama bagi jawapan, kerana segala-galanya sebelum itu hanyalah skrin kosong atau pemutar yang tertutup. Penaakulan dikeluarkan terlebih dahulu, jadi masa menunggu adalah kira-kira jumlah token penaakulan dibahagikan dengan kadar penyahkodan anda, ditambah dengan pemprosesan prompt. Gandakan panjang penaakulan dan anda menggandakan masa menunggu tersebut.

Konteks. Token penaakulan menduduki tetingkap konteks seperti token lain. Dengan preserve_thinking diaktifkan, pad conteng daripada pusingan pertama masih berada dalam prompt pada pusingan kelima, jadi pemprosesan prompt menjadi semakin perlahan setiap pusingan sementara tetingkap dipenuhi dari kedua-dua hujung. Meningkatkan num_ctx untuk menampungnya memerlukan memori cache KV, yang pada VPS tanpa GPU merupakan RAM sistem yang mungkin tidak mempunyai ruang simpanan tambahan.

Bilakah perlu meningkatkan tahap, dan bilakah perlu mengekalkannya rendah

Tingkatkan tahap untuk tugasan yang mana langkah perantaraan yang salah akan merosakkan hasil akhir: aritmetik berbilang langkah dan penukaran unit, merancang suntingan merentas beberapa fail, kod yang perlu dikompil, serta masalah kekangan yang memerlukan satu jawapan memenuhi beberapa syarat serentak. Dalam situasi ini, scratchpad melakukan kerja sebenar, dan scratchpad yang lebih panjang merupakan cara murah untuk mengesan ralat yang mungkin dilakukan oleh model jika tidak disemak.

Kekalkan tahap rendah apabila jawapan sudah tersedia dalam input dan tugasnya hanyalah untuk memindahkan jawapan tersebut. Pengekstrakan, pengelasan, pelabelan, penterjemahan, penulisan semula, peringkasan dan pemformatan semuanya termasuk dalam kategori ini. Segmen penaakulan biasanya hanya menyatakan semula tugasan, dan ini memberi ruang kepada model untuk menolak naluri pertama yang sebenarnya sudah tepat.

Kekalkan tahap rendah juga untuk sebarang tugasan interaktif. Dalam kotak sembang atau editor, anda berada dalam gelung maklum balas, jadi jawapan pantas yang boleh anda betulkan adalah lebih baik daripada jawapan perlahan yang perlu anda tunggu. Itulah pertukaran sebenar di sebalik menghalakan ejen pengekodan kepada model tempatan: ejen membuat banyak panggilan kecil, dan cukai penaakulan dikenakan pada setiap satu panggilan tersebut.

Cara menetapkan tahap dalam llama.cpp

llama.cpp menulis pemboleh ubah tersebut terus ke dalam templat, menjadikannya runtime di mana anda boleh memastikan tahap tersebut telah sampai. Halakan -m kepada GGUF yang anda sudah miliki.

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 menggunakan templat sembang model itu sendiri dan didayakan secara lalai dalam binaan semasa. --reasoning-effort menerima default, minimal, low, medium, high, xhigh atau max, di mana default bermaksud biarkan lalai templat itu sendiri tidak berubah. Senarai itu adalah perbendaharaan kata llama.cpp dan bukannya model tersebut, jadi hanya masukkan nama yang disenaraikan oleh kad: tahap yang tidak ditakrifkan oleh templat boleh menyebabkan ralat templat semasa permintaan dibuat. --reasoning-format deepseek mengalihkan penaakulan keluar daripada message.content dan ke dalam message.reasoning_content, yang menjadikan pembahagian tersebut boleh diukur dalam bahagian seterusnya.

Untuk mematikan pemikiran dan bukannya memendekkannya, tetapkan pemboleh ubah templat itu sendiri:

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

--reasoning-budget ialah mekanisme yang berbeza. Ia mengehadkan segmen penaakulan dalam token, dengan 0 menamatkannya serta-merta dan -1 membiarkannya tanpa sekatan, bukannya meminta model merancang segmen yang lebih pendek. Kedua-dua flag adalah untuk seluruh pelayan. llama-server tidak menerima reasoning_effort sebagai medan bagi setiap permintaan, jadi menyediakan dua tahap usaha pada masa yang sama bermakna dua proses pada dua port.

vLLM mendedahkan pemboleh ubah yang sama bagi setiap permintaan, di dalam badan yang serasi dengan OpenAI:

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

Cara menetapkan tahap dalam Ollama

Ollama mempunyai medan tersendiri, think, pada /api/chat dan /api/generate. Ia menerima true, false, atau salah satu daripada low, medium, high dan max, yang mana max meminta tahap tertinggi yang ditawarkan oleh model tersebut. Fungsi pemikiran (thinking) diaktifkan secara lalai bagi model yang menyokongnya.

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}

Proses penaakulan dikembalikan dalam message.thinking dan jawapan dalam message.content, yang telah pun diasingkan untuk anda. Di dalam sesi ollama run interaktif, /set think dan /set nothink menogol fungsi ini tanpa perlu memulakan semula.

Sekarang, perhatikan ketidakpadanan yang berlaku. Kosa kata Ollama ialah low, medium, high dan max. Templat Qwen3.8 pula mentakrifkan low, medium dan xhigh. Sesuatu perlu memetakan satu kepada yang lain, dan model Ollama membawa templat yang dibungkus di dalam tagnya dan bukannya fail Jinja daripada repositori asal. Oleh itu, sama ada tahap anda sampai kepada model tersebut bergantung pada templat yang dibungkus itu. Jangan andaian ia telah berfungsi. Pengukuran mengenainya mengambil masa kira-kira satu minit.

Cara mengukur sama ada tahap tersebut benar-benar berfungsi

Hantar prompt yang sama pada lebih daripada satu tahap dengan temperature pada 0, kemudian bandingkan kiraan token. Di sini jq membina badan mesej supaya anda tidak perlu melarikan tanda petikan secara manual.

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 ialah setiap token yang dijana, termasuk penaakulan, jadi jurang antara dua tahap hampir keseluruhannya adalah penaakulan. thinking_chars memberikan anda pecahan tersebut secara terus. Dua perkara harus benar: nombor berubah antara tahap, dan jawapan kekal tepat pada tahap yang lebih rendah. Jika eval_count berada dalam julat hingar merentasi ketiga-tiga percubaan, tahap tersebut diabaikan, dan penyelesaiannya ialah runtime yang meluluskannya dan bukannya nama tahap yang berbeza.

Jumlah masa hanyalah separuh daripada cerita, jadi ukur jurang ke token jawapan pertama dengan menstrim dan berhenti pada ketulan content bukan kosong yang pertama. Ini memerlukan jq dan 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

Jalankannya pada low dan sekali lagi pada max. Perbezaannya ialah masa menunggu yang anda perolehi. Pada llama.cpp, nombor yang sama kembali di dalam respons, tanpa memerlukan aritmetik 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
}'

Lakukan ini pada mesin anda sendiri. Perbandingan usaha yang diterbitkan diukur pada perkakasan yang bukan milik anda, dan kadar penyahkodan anda ialah istilah yang menukarkan kiraan token kepada saat. Mengukur token sesaat pada pelayan anda sendiri memberikan anda istilah tersebut: token penaakulan dibahagikan dengan kadar penyahkodan anda ialah masa menunggu yang baru sahaja anda tambah.

Perkara yang sering tidak menjadi

Jawapan terpotong, atau content kosong manakala thinking penuh. Had penjanaan telah habis digunakan oleh proses penaakulan (reasoning). num_predict dalam Ollama mengehadkan keseluruhan penjanaan, termasuk penaakulan, dan penaakulan didahulukan. Oleh itu, had 512 token pada tahap usaha tinggi boleh menamatkan respons sebelum jawapan bermula. Ollama melaporkan "done_reason": "length" bagi respons tersebut. Tingkatkan had atau rendahkan tahap usaha. Bagaimana num_predict mengira token membincangkan interaksi ini dengan terperinci.

Tahap tidak mengubah apa-apa. Kiraan token adalah sama pada setiap tahap. Sama ada runtime tidak menghantar pemboleh ubah tersebut, atau templat tidak membacanya. Semak templat yang sebenarnya digunakan oleh runtime anda dan bukannya templat yang terdapat dalam repositori asal. llama.cpp dengan --jinja dan --chat-template-kwargs menulis pemboleh ubah tersebut secara manual, jadi ia menjadi kawalan yang baik: jika tahap berfungsi di sana tetapi tidak di tempat lain, model tersebut dalam keadaan baik dan runtime yang satu lagi telah menggugurkannya.

Nama tahap ditolak. Ralat templat semasa permintaan, atau kegagalan pada mesej pertama dengan pelayan yang sepatutnya sihat, biasanya bermaksud anda menghantar tahap yang tidak ditakrifkan oleh templat, seperti high kepada model yang kadnya hanya menyenaraikan low, medium dan xhigh.

Sembang berbilang pusingan menjadi perlahan pada setiap pusingan. Penaakulan lama disimpan dalam sejarah. Tetapkan preserve_thinking kepada false jika model menyokongnya, atau buang medan thinking daripada mesej yang anda hantar semula. Jika tidak, pemprosesan prompt akan bertambah pada setiap pusingan manakala jawapan kekal pada panjang yang sama.

Kualiti merosot pada tahap usaha rendah bagi tugasan yang anda anggap mudah. Sesetengah pengekstrakan bukanlah pengekstrakan sebenar. Jika input memerlukan penukaran unit atau peraturan yang perlu digunakan mengikut urutan, ia adalah tugasan penaakulan dengan output yang pendek. Tingkatkan tahap bagi panggilan tersebut sahaja dan bukannya untuk keseluruhan pelayan.

Menjalankan dua tahap serentak

llama.cpp menetapkan tahap semasa permulaan, jadi kotak yang melayani editor dan kerja kelompok waktu malam memerlukan dua proses pada dua port, setiap satunya dengan --reasoning-effort sendiri. Dua proses juga bermakna dua salinan pemberat dalam memori, melainkan anda mengasingkan kerja tersebut mengikut masa. Pada satu VPS, aturan yang lebih murah biasanya adalah pelayan usaha rendah untuk apa sahaja yang ditunggu oleh pengguna, ditambah dengan larian usaha tinggi berjadual untuk kerja yang tidak dipantau oleh sesiapa. Apa yang berlaku apabila beberapa pengguna berkongsi satu model tempatan juga terpakai di sini: token penaakulan adalah kerja penyahkodan, jadi meningkatkan usaha akan mengurangkan konkurensi berkesan anda mengikut faktor yang lebih kurang sama dengan peningkatan jumlah token.

FAQ

Tahap usaha penaakulan manakah yang perlu saya gunakan secara lalai?

Mulakan pada tahap terendah yang ditawarkan oleh model dan tingkatkan hanya untuk tugasan yang telah anda perhatikan gagal. Beberapa model penaakulan mempunyai tahap lalai yang tinggi, dan Qwen3.8-27B menetapkan xhigh sebagai lalai, iaitu tahap tertingginya, setakat Ogos 2026. Lalai tersebut dipilih untuk kelihatan baik pada jadual penanda aras, dan jadual penanda aras tidak mengenakan caj untuk masa. Pada perkakasan anda sendiri, anda membayar dalam bentuk saat, jadi jadikan tahap yang lebih tinggi sebagai sesuatu yang anda pilih mengikut tugasan dan bukannya tetapan yang diwarisi oleh setiap permintaan.

Adakah token penaakulan dikira dalam tetingkap konteks saya?

Ya. Ia adalah token biasa dalam output dan ia berada dalam tetingkap konteks bersama-sama dengan segala yang lain. Sama ada ia kekal di sana pada giliran seterusnya bergantung pada runtime dan model tersebut. Kad Qwen3.8 mendokumenkan preserve_thinking, yang diaktifkan secara lalai, yang menyimpan penaakulan terdahulu dalam sejarah, jadi perbualan yang panjang membawa setiap coretan yang telah dihasilkannya. Tetapkannya kepada false, atau gugurkan medan thinking daripada mesej yang anda mainkan semula, dan pemprosesan prompt akan berhenti berkembang.

Mengapakah menukar tahap penaakulan tidak memberikan perbezaan kepada kiraan token saya?

Tetapan tersebut tidak sampai ke templat sembang. Tahap tersebut ialah pemboleh ubah templat, jadi ia hanya berfungsi jika runtime melaluinya dan templat yang dibungkus membacanya. Sesetengah runtime menghantar templat mereka sendiri bersama model dan bukannya fail Jinja daripada repositori asal, dan pemboleh ubah tersebut kemudiannya digugurkan tanpa sebarang ralat dicetak di mana-mana. Buktikan perkara ini dengan menghantar prompt yang sama pada tahap terendah dan tertinggi dengan temperature pada 0 dan membandingkan eval_count. Jika kiraan tersebut sepadan dalam julat ralat, tahap tersebut sedang diabaikan.

Adakah usaha penaakulan yang lebih rendah menjadikan model kurang tepat?

Ia bergantung pada tugasan, dan perkara ini lebih berbaloi untuk diukur daripada membuat andaian. Di mana jawapan sudah sedia ada dalam input, seperti pengekstrakan atau penulisan semula, coretan yang lebih pendek biasanya tidak mengubah apa-apa. Di mana langkah pertengahan perlu betul sebelum langkah terakhir boleh dilakukan, seperti aritmetik berbilang langkah atau kod yang mesti dikompilasi, ketepatan memang akan menurun dengan coretan yang lebih pendek. Bina satu set dua puluh prompt daripada beban kerja sebenar anda, jalankannya pada dua tahap dengan temperature pada 0, dan kira jawapan yang salah. Nombor tersebut adalah khusus untuk beban kerja anda, dan tiada jadual yang diterbitkan boleh memberikannya kepada anda.