Cara Hadkan Token Output Ollama Menggunakan num_predict
Ketahui cara menggunakan num_predict untuk mengehadkan token output Ollama. Fahami hierarki tetapan, cara membaca done_reason, dan perbezaan kritikal antara num_predict dan num_ctx.
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 tersebut, 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 penghentian, 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 tersebut ke dalam model yang anda cipta. Tulis fail tersebut:
FROM qwen3:8b
PARAMETER num_ctx 8192
PARAMETER num_predict 512Kemudian bina model itu dan semak semula apa yang telah anda bina:
ollama create qwen3-capped -f Modelfile
ollama show --parameters qwen3-cappedollama 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 sendiri 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.
Ini adalah lapisan yang betul untuk nilai yang anda mahu setiap pemanggil warisi. Ini adalah lapisan yang salah jika anda menjangkakan ia bersifat muktamad, kerana ia tidak 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 pada yang 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 tersebut bersama mesej anda yang seterusnya, menjadikannya cara terpantas untuk mengesahkan perubahan telah berkuat kuasa. Nilai tersebut kekal sehingga anda menaip /bye. Untuk menyimpannya, /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 mengapa tetapan anda kelihatan diabaikan
Urutannya ringkas. Pilihan yang dihantar bersama permintaan mengatasi segala-galanya. Baris PARAMETER num_predict dalam Modelfile model ialah sandaran yang digunakan apabila permintaan tidak membawa sebarang 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 sebab tepat mengapa 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 ditindih 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 dalam 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 menghormati pilihan tersebut dan aplikasi anda menghantar sesuatu yang berbeza. Untuk rekod pelayan sendiri mengenai sesuatu permintaan, mulakan semula ia dengan OLLAMA_DEBUG=1 dalam persekitaran dan perhatikan 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 pernah 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 pernah 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 mesin 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 dihasilkan satu demi satu, dan setiap satunya memerlukan satu laluan penuh merentasi pemberat 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 berbanding satu token prompt.
Minta respons tanpa penstriman dan angka-angkanya akan terpapar di situ:
"prompt_eval_count": 26,
"prompt_eval_duration": 107345000,
"eval_count": 237,
"eval_duration": 4289432000Tempoh 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 dilakukan sekali sebelum anda menala apa-apa perkara lain. Kadar tersebut bergantung pada model sama seperti mesin itu sendiri, jadi jika jawapan yang panjang merupakan kos sebenar, model yang dibina untuk penyahkodan pantas seperti Nemotron 3.5 Lightning pada VPS dapat menjimatkan semula masa yang sepatutnya dilindungi oleh had rendah.
Aritmetik melakukan selebihnya. Pada kadar 8 token sesaat, jawapan sepanjang 2,000 token akan menahan mesin selama lebih daripada empat minit, dan model tidak tahu bahawa anda hanya mahukan satu perenggan. Sesetengah model juga melakukan gelung, mengulangi frasa sehingga sesuatu menghentikannya. Tanpa had, permintaan tunggal itu akan menyibukkan 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), bukan model yang rosak
Gejala ini kelihatan seperti kegagalan model. Jawapan yang terhenti di tengah ayat. JSON yang tidak boleh diurai 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 sesuatu 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 membuatkan model menulis dengan lebih panjang. Ia hanya membuang siling had. Jika jawapan berakhir pada 200 token dengan done_reason daripada stop, model tersebut 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 balasan 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 harinya.
- Untuk output berstruktur, tetapkan had melebihi dokumen sah terbesar yang anda jangkakan, kemudian anggap
done_reasondaripadalengthsebagai ralat kritikal dan cuba semula daripada menghuraikan apa yang diterima. - Untuk ejen pengekodan, nilai tersebut perlu berada 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 segala yang telah dihasilkan setakat ini. Ia menggunakan memori kerana cache key/value akan membesar bersamanya. 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 dikira dalam kedua-dua had, jadi jawapan boleh terpotong oleh mana-mana satu daripadanya.
Mengapa tetapan num_predict saya seolah-olah diabaikan?
Kerana nilai yang dihantar bersama permintaan akan mengatasi nilai yang disimpan dalam model. Letakkan PARAMETER num_predict 512 dalam Modelfile, kemudian jalankan model tersebut daripada front-end sembang atau ejen pengekodan, dan klien akan menghantar objek options miliknya sendiri yang akan diutamakan. 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 pelayan berfungsi dengan betul dan mengalihkan pencarian punca masalah kepada 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 dengan sendirinya. Nilai length bermaksud ia kehabisan ruang. Kemudian bandingkan eval_count dengan had anda: jika ia sepadan dengan tepat, num_predict telah menghentikannya, dan jika eval_count lebih kecil, tetingkap konteks telah penuh terlebih dahulu. Apabila melakukan penstriman, kedua-dua medan 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?
Baca nilai tersebut daripada pemasangan anda sendiri dan bukannya daripada artikel. Setakat Ogos 2026, rujukan Modelfile Ollama memberikan nilai lalai sebagai -1, yang bermaksud penjanaan tidak dihadkan, dan entri tersebut telah diperbetulkan pada akhir 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 membuatkan 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 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.