Cara Hadkan Output Token Ollama dengan num_predict

Apakah fungsi num_predict dalam Ollama

num_predict ialah pilihan Ollama yang mengehadkan bilangan token yang boleh dijana oleh model dalam satu respons. Ia hanya mengira token output, jadi prompt tidak akan ditolak daripada had tersebut. Apabila model mencapai had ini, penjanaan akan berhenti serta-merta, kadangkala di tengah perkataan, dan respons akan dikembalikan dengan done_reason ditetapkan kepada length.

Itu sahaja fungsi ciri ini. Kesukarannya ialah Ollama menyediakan tiga lokasi berasingan untuk menetapkan nilai ini, dan tetapan yang paling hampir dengan permintaan akan diutamakan. Hampir setiap laporan yang menyatakan "num_predict tidak berfungsi" berpunca daripada satu lapisan yang mengatasi lapisan lain secara senyap.

num_predict bukan num_ctx

Dua pilihan ini paling kerap dikelirukan dalam Ollama, dan kekeliruan ini membuang masa penyahpepijatan yang berharga.

num_ctx ialah jumlah yang boleh dibaca oleh model. Ini adalah saiz tetingkap konteks, yang menyimpan prompt serta semua kandungan yang telah dihasilkan setakat ini. Meningkatkan nilainya akan menggunakan lebih banyak memori, kerana cache kunci/nilai yang disimpan oleh model untuk token tersebut akan membesar mengikut saiz tetingkap. Menentukan saiz num_ctx untuk perkakasan anda adalah tugas berasingan dengan mod kegagalannya yang tersendiri.

num_predict ialah jumlah yang akan ditulis oleh model. Ini adalah peraturan pemberhentian, bukan peruntukan memori. Meningkatkan nilainya akan memakan masa pemprosesan dan bukannya RAM, dan tiada apa-apa yang dikhaskan lebih awal.

Kedua-duanya bertemu di satu titik. Token yang dijana akan masuk ke dalam tetingkap konteks semasa ia dihasilkan, jadi balasan juga boleh terhenti kerana tetingkap telah penuh dan bukannya kerana had anda telah dicapai. Ollama melaporkan length dalam kedua-dua keadaan, jadi angka yang membezakan kedua-duanya ialah eval_count, yang dibincangkan dengan lebih lanjut di bawah.

Tetapkan sekali dengan Modelfile

Modelfile menyematkan nilai ke dalam model yang anda cipta. Tulis fail tersebut:

FROM qwen3:8b
PARAMETER num_ctx 8192
PARAMETER num_predict 512

Kemudian bina model itu dan semak semula apa yang telah anda bina:

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

ollama show --parameters mencetak satu baris bagi setiap parameter yang disimpan berserta nilainya. Jika num_predict tiada dalam output tersebut, model itu tidak membawa had yang disematkan dan nilai lalai Ollama akan digunakan. ollama show --modelfile qwen3-capped mencetak keseluruhan definisi, yang juga merupakan cara terpantas untuk menyalin parameter yang sudah disertakan dalam model sedia ada. Mencipta model yang dihadkan dengan cara ini hampir tidak menggunakan ruang cakera tambahan, kerana entri baharu tersebut menggunakan semula blob pemberat yang telah dimuat turun oleh model asas dan bukannya menyalinnya, dan lokasi Ollama menyimpan blob tersebut perlu diketahui sebelum cakera root VPS anda penuh.

Ini adalah lapisan yang betul untuk nilai yang anda mahu diwarisi oleh setiap pemanggil. Ini adalah lapisan yang salah jika anda menjangkakan ia menjadi muktamad, kerana ia tidak bersifat sedemikian.

Tetapkan ia bagi setiap permintaan dalam objek options

Setiap endpoint penjanaan menerima objek options, dan num_predict diletakkan di dalamnya:

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 menggunakan kunci options yang sama dengan maksud yang sama. Nilai di sini hanya terpakai untuk panggilan tersebut sahaja dan tidak untuk perkara lain. Ini ialah lapisan yang digunakan oleh alatan anda: antaramuka sembang, skrip, pembungkus SDK, atau ejen pengekodan. Kesemuanya menghantar objek options, sama ada ia memaparkan kotak untuknya kepada anda atau tidak.

Tetapkan untuk satu sesi dengan parameter /set

Di dalam ollama run, sesi interaktif menetapkan pilihan untuk sepanjang sesi tersebut:

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

/show parameters mencetak perkara yang akan dihantar oleh sesi bersama mesej anda yang seterusnya, menjadikannya cara terpantas untuk mengesahkan perubahan telah berkuat kuasa. Nilai tersebut kekal sehingga anda menaip /bye. Untuk mengekalkannya, /save qwen3-capped menulis sesi semasa, termasuk parameter, sebagai model baharu. Tiada apa-apa yang anda /set di sini akan sampai kepada mana-mana klien lain.

Tetapan mana yang diutamakan, dan sebab tetapan anda kelihatan diabaikan

Urutannya ringkas. Pilihan yang dihantar bersama permintaan mengatasi segala-galanya. Baris PARAMETER num_predict dalam Modelfile model merupakan sandaran yang digunakan apabila permintaan tidak membawa nilai. Jika kedua-duanya tiada, nilai lalai terbina dalam Ollama akan digunakan.

/set parameter bukanlah peraturan ketiga. Sesi interaktif ialah klien API, jadi apa yang anda tetapkan di sana dihantar sebagai options permintaan tersebut, itulah sebabnya ia mengatasi Modelfile untuk sesi berkenaan.

Sekarang, kegagalan yang dijelaskan oleh perkara ini. Anda menambah PARAMETER num_predict 512, membina semula model, dan balasan masih berjalan sehingga beribu-ribu token. Tetapan anda ada di sana, dan ollama show --parameters membuktikannya. Ia diatasi pada setiap permintaan, kerana klien menghantar objek options miliknya sendiri yang membawa nombornya sendiri, selalunya nombor yang anda taip ke dalam skrin tetapan berbulan-bulan dahulu dan telah dilupakan. ollama show membaca model yang disimpan. Ia tidak dapat menunjukkan kepada anda apa yang tiba melalui HTTP.

Buktikan bahagian pelayan dengan satu arahan. Hantar permintaan yang akan menghasilkan jawapan panjang, paksa had menjadi rendah, dan baca dua medan:

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'

Itu sepatutnya mencetak "length" dan 32. Pasang jq dahulu dengan sudo apt install -y jq jika ia tiada. Respons "length" dan 32 bermakna pelayan mematuhi pilihan tersebut dan aplikasi anda menghantar sesuatu yang berbeza. Untuk melihat rekod permintaan pelayan itu sendiri, mulakan semula pelayan dengan OLLAMA_DEBUG=1 dalam persekitaran dan pantau journalctl -u ollama -f semasa aplikasi anda berhubung dengannya.

Nilai negatif dan nombor yang tidak sepatutnya anda salin

num_predict juga menerima nilai negatif, dan nilai tersebut merupakan sentinel dan bukannya kiraan. Satu nilai negatif bermaksud "jangan hadkan ini, teruskan penjanaan". Nilai lain pula bermaksud "isi konteks yang berbaki". Setakat Ogos 2026, rujukan Modelfile Ollama memberikan nilai lalai sebagai -1, iaitu penjanaan tanpa had, dan versi terdahulu bagi jadual yang sama juga menyenaraikan -2 untuk mengisi konteks.

Anggap semua itu bergantung pada versi, kerana ia telah berubah. Dokumentasi rujukan menyatakan nilai lalai sebagai 128 untuk tempoh yang lama sebelum entri tersebut diperbetulkan pada penghujung tahun 2024, jadi banyak panduan masih mengulangi nombor lama tersebut. Baca rujukan parameter Modelfile untuk versi yang anda jalankan, kemudian sahkan kelakuan tersebut dengan semakan eval_count di atas. Nilai yang anda sahkan pada pelayan anda sendiri adalah lebih tepat daripada nilai yang anda baca di mana-mana sahaja, termasuk catatan ini.

Mengapa panjang output menjadi kos utama pada VPS yang hanya menggunakan CPU

Penjanaan mempunyai dua fasa dengan kelajuan yang sangat berbeza. Token prompt dinilai secara berkelompok, banyak dalam satu masa. Token output pula dihasilkan satu demi satu, dan setiap satunya memerlukan satu laluan penuh merentasi pemberat (weights) model. Pada VPS yang hanya menggunakan CPU, laluan tersebut dihadkan oleh lebar jalur memori, jadi satu token yang dijana menelan kos yang jauh lebih tinggi daripada satu token prompt. Oleh kerana laluan tersebut perlu membaca setiap pemberat, bilangan bait yang diduduki oleh setiap pemberat menetapkan had siling pada kadar token anda, itulah sebabnya binaan q4 menyahkod lebih pantas daripada model yang sama pada q8 atau fp16.

Minta respons tanpa penstriman dan angka-angkanya akan terpapar di situ:

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

Tempoh adalah dalam nanosaat. Dalam blok tersebut, yang merupakan contoh respons yang diterbitkan dalam dokumentasi API Ollama dan bukannya ukuran bagi mana-mana pelayan tertentu, 26 token prompt mengambil masa kira-kira 0.1 saat manakala 237 token output mengambil masa kira-kira 4.3 saat. Kadar penjanaan anda sendiri ialah eval_count dibahagikan dengan eval_duration yang ditukar kepada saat, dan mengukur token sesaat pada perkakasan anda sendiri berbaloi untuk dilakukan sekali sebelum anda menala apa-apa perkara lain. Kadar tersebut bergantung pada model sama seperti ia bergantung pada mesin, jadi jika jawapan yang panjang adalah kos sebenar, model yang dibina untuk penyahkodan pantas seperti Nemotron 3.5 Lightning pada VPS dapat menjimatkan semula sebahagian masa yang sepatutnya dilindungi oleh had rendah.

Aritmetik melakukan selebihnya. Pada 8 token sesaat, jawapan 2,000 token akan menahan mesin selama lebih daripada empat minit, dan model tidak tahu bahawa anda hanya mahukan satu perenggan. Model penaakulan menghabiskan sebahagian daripada bajet tersebut untuk berfikir sebelum ia menulis satu perkataan yang anda minta, dan pemikiran itu dijana satu token demi satu seperti perkara lain, jadi usaha penaakulan yang anda minta adalah satu lagi tuil pada bil yang sama. Sesetengah model juga melakukan gelung, mengulangi frasa sehingga sesuatu menghentikannya. Tanpa had, permintaan tunggal itu akan menyibukkan satu teras sehingga tetingkap konteks habis. num_predict ialah tetapan yang mengehadkannya, yang paling penting pada VPS Ollama yang dihoskan sendiri yang kecil di mana satu permintaan panjang akan menggunakan keseluruhan mesin.

Output yang terpotong biasanya disebabkan oleh had (cap), bukannya model yang rosak

Gejala ini kelihatan seperti kegagalan model. Jawapan yang terhenti di tengah ayat. JSON yang tidak boleh diurai (parse) kerana kurungan penutup tidak pernah sampai. Refleks biasa adalah menyalahkan model atau kuantisasi. Baca respons tersebut terlebih dahulu.

done_reason menjawab soalan secara terus. stop bermaksud model telah selesai dengan sendirinya, sama ada dengan mengeluarkan token akhir jujukan (end-of-sequence) atau dengan memadankan salah satu rentetan dalam pilihan stop anda. length bermaksud penjanaan terputus kerana kehabisan ruang. Apabila anda melihat length, bandingkan eval_count dengan had anda: padanan tepat bermaksud num_predict telah menghentikannya, dan nombor yang lebih kecil bermaksud tetingkap konteks telah penuh terlebih dahulu.

Apabila anda melakukan penstriman, medan tersebut tiba dalam ketulan (chunk) terakhir, iaitu ketulan yang membawa "done": true. Banyak pustaka klien membuang ketulan tersebut dan hanya memberikan teks kepada kod anda, itulah sebabnya pemotongan yang sama kelihatan tidak dapat dijelaskan di dalam aplikasi tetapi jelas di bawah curl. Jika pustaka menyembunyikannya, hantar satu permintaan dengan curl untuk mengetahui perkara sebenar yang dikatakan oleh pelayan.

Satu lagi perkara yang dapat menjimatkan masa anda. Meningkatkan num_predict tidak menjadikan model menulis dengan lebih panjang. Ia hanya membuang siling had. Jika balasan berakhir pada 200 token dengan done_reason daripada stop, model telah memutuskan bahawa ia sudah selesai, dan had yang lebih besar tidak akan mengubah apa-apa. Jawapan pendek dengan stop adalah masalah arahan (prompting). Jawapan pendek dengan length adalah masalah had (cap).

Memilih nilai

• Untuk sembang interaktif, biarkan ia tanpa had dan tekan Ctrl+C untuk menghentikan respons yang tidak terkawal. Anda sedang memantau skrin tersebut.
• Untuk sebarang skrip, tetapkan hadnya. Penjanaan tanpa had di dalam gelung adalah punca kerja kelompok yang sepatutnya mengambil masa sepuluh minit masih berjalan pada keesokan paginya.
• Untuk output berstruktur, tetapkan had melebihi dokumen sah terbesar yang anda jangkakan, kemudian anggap done_reason daripada length sebagai ralat kritikal dan cuba semula dan bukannya menghuraikan data yang diterima.
• Untuk ejen pengekodan, nilai tersebut perlu diletakkan dalam konfigurasi ejen itu sendiri, kerana ejen menghantar pilihannya sendiri pada setiap permintaan. Menghalakan ejen pengekodan ke Ollama merangkumi lokasi tetapan tersebut disimpan.

Had ini mengira token, bukan perkataan dan bukan aksara, jadi jangan buat anggaran. Jana satu jawapan wakilan tanpa had, baca eval_count, dan tetapkan had dengan selesa melebihi nilai tersebut. Keluarga model melakukan tokenisasi secara berbeza, jadi nilai yang sesuai untuk model Llama mungkin memotong jawapan yang sama daripada model Qwen 3 pada VPS yang sama.

FAQ

Apakah perbezaan antara num_ctx dan num_predict dalam Ollama?

num_ctx ialah saiz tetingkap konteks, yang menetapkan jumlah teks yang boleh dibaca oleh model: prompt ditambah dengan semua teks yang telah dihasilkan setakat ini. Ia menggunakan memori kerana cache key/value akan membesar mengikut saiz tersebut. num_predict menetapkan berapa banyak token yang boleh ditulis oleh model dalam satu respons. Ia menggunakan masa dan bukannya memori, dan tiada ruang yang dikhaskan lebih awal. Token yang dijana akan dikira dalam kedua-dua had ini, jadi respons boleh terpotong oleh mana-mana satu had tersebut.

Mengapa tetapan num_predict saya seolah-olah diabaikan?

Ini kerana nilai yang dihantar bersama permintaan akan mengatasi nilai yang disimpan dalam model. Jika anda meletakkan PARAMETER num_predict 512 dalam Modelfile, kemudian menjalankan model tersebut daripada front-end sembang atau ejen pengekodan, klien akan menghantar objek options miliknya sendiri yang akan diguna pakai. ollama show --parameters masih memaparkan nilai anda kerana ia membaca model yang disimpan dan tidak dapat melihat apa yang tiba melalui HTTP. Hantar satu permintaan dengan curl menggunakan "options": {"num_predict": 32} dan semak sama ada eval_count kembali sebagai 32, yang mengesahkan bahawa pelayan berfungsi dengan betul dan menunjukkan bahawa masalah terletak pada aplikasi anda.

Bagaimanakah saya boleh mengetahui sama ada output saya dipotong oleh num_predict?

Hantar permintaan dengan "stream": false dan baca done_reason. Nilai stop bermaksud model selesai menjana teks dengan sendirinya. Nilai length bermaksud model kehabisan ruang. Kemudian bandingkan eval_count dengan had anda: jika nilainya tepat sama, num_predict telah menghentikannya, dan jika eval_count lebih kecil, tetingkap konteks telah penuh terlebih dahulu. Semasa penstriman, kedua-dua medan ini tiba dalam ketulan terakhir dengan "done": true, yang sering dibuang oleh banyak pustaka klien sebelum kod anda sempat melihatnya.

Apakah nilai lalai bagi num_predict?

Semak nilai tersebut daripada pemasangan anda sendiri dan bukannya daripada artikel. Setakat Ogos 2026, rujukan Modelfile Ollama menyatakan nilai lalai sebagai -1, yang bermaksud penjanaan tidak dihadkan. Entri tersebut telah diperbetulkan pada penghujung tahun 2024 selepas bertahun-tahun mendokumentasikan 128. Nilai negatif adalah penanda (sentinel) dan bukannya kiraan, dan versi lama jadual yang sama juga menyenaraikan -2 untuk mengisi baki konteks. Semak rujukan parameter Modelfile untuk versi anda, kemudian sahkan dengan ollama show --parameters dan satu permintaan curl.

Adakah meningkatkan num_predict menyebabkan model menulis jawapan yang lebih panjang?

Tidak. Ia hanya membuang had siling. Jika jawapan berakhir dengan done_reason daripada stop, model tersebut telah memutuskan bahawa ia sudah selesai, dan had yang lebih besar tidak akan mengubah apa-apa. Panjang jawapan dalam kes ini adalah isu berkaitan prompt: minta struktur tertentu, bilangan bahagian, atau tahap perincian yang dinyatakan. Tingkatkan num_predict hanya apabila done_reason kembali sebagai length.