SSD Nodes Learn Hosting plans →
Panduan Matt ConnorOleh Matt Connor · Diperbarui 2026-08-29

Ollama num_predict: Batasi Panjang Output Model

Pelajari cara kerja num_predict di Ollama, tiga tempat pengaturannya, prioritas nilai yang berlaku, serta cara membaca done_reason saat batas token tercapai.

Fungsi num_predict dalam Ollama

num_predict adalah opsi Ollama yang membatasi jumlah token yang dapat dihasilkan model dalam satu respons. Opsi ini hanya menghitung token output, sehingga prompt tidak dihitung. Saat model mencapai batas tersebut, proses pembuatan output berhenti pada posisi itu, terkadang di tengah kata, dan respons dikembalikan dengan done_reason yang ditetapkan ke length.

Itulah seluruh fungsinya. Kesulitannya adalah Ollama menyediakan tiga tempat terpisah untuk menetapkan nilai tersebut, dan pengaturan yang paling dekat dengan permintaan akan digunakan. Hampir semua laporan bahwa "num_predict tidak berfungsi" terjadi karena satu lapisan secara diam-diam menimpa lapisan lainnya.

num_predict bukan num_ctx

Kedua opsi ini lebih sering tertukar daripada pasangan opsi lain di Ollama, dan kekeliruan ini menghabiskan banyak waktu untuk debugging.

num_ctx menentukan seberapa banyak model dapat membaca. Opsi ini menentukan ukuran context window, yang menampung prompt serta semua output yang telah dihasilkan. Menaikkan nilainya memerlukan lebih banyak memori karena key/value cache yang disimpan model untuk token-token tersebut bertambah seiring ukuran window. Menentukan ukuran num_ctx untuk hardware Anda adalah tugas terpisah dengan mode kegagalannya sendiri.

num_predict menentukan seberapa banyak model akan menulis. Opsi ini merupakan aturan penghentian, bukan alokasi. Menaikkan nilainya menambah waktu eksekusi, bukan penggunaan RAM, dan tidak ada memori yang dicadangkan sebelumnya.

Keduanya bertemu di satu titik. Token yang dihasilkan masuk ke dalam context window saat diproduksi. Karena itu, respons juga dapat berhenti karena window telah penuh, bukan karena batas yang Anda tetapkan tercapai. Ollama melaporkan length pada kedua kondisi tersebut. Jadi, angka yang membedakan keduanya adalah eval_count, yang dibahas lebih lanjut di bawah.

Atur sekali dengan Modelfile

Modelfile menyimpan nilai tersebut di dalam model yang Anda buat. Tulis file berikut:

FROM qwen3:8b
PARAMETER num_ctx 8192
PARAMETER num_predict 512

Kemudian buat model tersebut dan baca kembali konfigurasi yang telah dibuat:

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

ollama show --parameters mencetak satu baris untuk setiap parameter yang tersimpan beserta nilainya. Jika num_predict tidak ada dalam output tersebut, model tidak memiliki batas yang disimpan di dalamnya dan default Ollama akan berlaku. ollama show --modelfile qwen3-capped mencetak seluruh definisi. Ini juga merupakan cara tercepat untuk menyalin parameter yang sudah disertakan oleh model yang ada. Membuat model dengan batas menggunakan cara ini hampir tidak memerlukan ruang disk tambahan, karena entri baru tersebut menggunakan kembali blob bobot yang sudah diunduh oleh model dasar, bukan menyalinnya. Karena itu, lokasi penyimpanan blob oleh Ollama perlu diketahui sebelum disk root VPS penuh.

Ini adalah lapisan yang tepat untuk nilai yang ingin diwarisi oleh setiap pemanggil. Namun, ini bukan lapisan yang tepat jika Anda mengharapkan nilai tersebut menjadi nilai final, karena nilai tersebut masih dapat ditimpa.

Tetapkan pada setiap permintaan di dalam objek options

Setiap endpoint generasi menerima objek options, dan num_predict ditempatkan 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 makna yang sama. Nilai di sini hanya berlaku untuk satu panggilan tersebut. Nilai ini tidak memengaruhi hal lain. Inilah lapisan yang digunakan oleh tools Anda: front end chat, script, wrapper SDK, atau coding agent. Semuanya mengirim objek options, terlepas dari apakah objek tersebut ditampilkan sebagai kotak atau tidak.

Tetapkan untuk satu sesi dengan parameter /set

Di dalam ollama run, sesi interaktif menetapkan opsi yang berlaku selama sisa sesi tersebut:

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

/show parameters menampilkan hal-hal yang akan dikirim oleh sesi tersebut bersama pesan berikutnya. Ini adalah cara tercepat untuk memastikan bahwa perubahan telah diterapkan. Nilai tersebut berlaku sampai Anda mengetik /bye. Untuk mempertahankannya, /save qwen3-capped menulis sesi saat ini, termasuk parameternya, sebagai model baru. Apa pun yang Anda /set di sini tidak akan diterapkan ke client lain.

Urutan pengaturan yang berlaku dan alasan pengaturan Anda tampak diabaikan

Urutannya singkat. Opsi yang dikirim bersama request mengalahkan semua pengaturan lain. Baris PARAMETER num_predict dalam Modelfile model menjadi fallback jika request tidak membawa nilai. Jika keduanya tidak ada, default bawaan Ollama yang berlaku.

/set parameter bukan aturan ketiga. Sesi interaktif adalah client API, sehingga nilai yang Anda tetapkan di sana dikirim sebagai options milik request tersebut. Karena itu, nilai tersebut menggantikan pengaturan dalam Modelfile selama sesi berlangsung.

Berikut masalah yang dapat dijelaskan oleh urutan ini. Anda menambahkan PARAMETER num_predict 512, membangun ulang model, tetapi respons tetap berjalan hingga ribuan token. Pengaturan Anda memang ada, dan ollama show --parameters membuktikannya. Namun, pengaturan itu diganti pada setiap request karena client mengirim objek options miliknya sendiri dengan angkanya sendiri. Sering kali angka tersebut adalah nilai yang Anda masukkan ke layar pengaturan beberapa bulan lalu dan kemudian lupa. ollama show membaca model yang tersimpan. Perintah tersebut tidak dapat menampilkan data yang diterima melalui HTTP.

Buktikan sisi server dengan satu perintah. Kirim request yang akan menghasilkan jawaban panjang, tetapkan batas yang rendah, lalu baca dua field:

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'

Perintah tersebut seharusnya mencetak "length" dan 32. Instal jq terlebih dahulu dengan sudo apt install -y jq jika belum tersedia. Respons "length" dan 32 berarti server mematuhi opsi tersebut, sedangkan aplikasi Anda mengirim nilai yang berbeda. Untuk melihat catatan server sendiri tentang suatu request, jalankan ulang server dengan OLLAMA_DEBUG=1 di environment, lalu monitor journalctl -u ollama -f saat aplikasi Anda berkomunikasi dengannya.

Nilai negatif dan angka yang tidak boleh Anda salin

num_predict juga menerima nilai negatif, dan nilai tersebut berfungsi sebagai sentinel, bukan jumlah. Salah satu nilai negatif berarti “jangan batasi ini, teruskan generasi”. Nilai negatif lainnya berarti “isi konteks yang tersisa”. Per Agustus 2026, referensi Ollama Modelfile menetapkan nilai default -1, yaitu generasi tanpa batas. Versi sebelumnya dari tabel yang sama juga mencantumkan -2 untuk mengisi konteks.

Anggap semua nilai tersebut bergantung pada versi karena nilainya telah berubah. Referensi tersebut mencatat nilai default 128 dalam waktu lama sebelum entri itu diperbaiki pada akhir 2024. Karena itu, banyak panduan masih mengulangi angka lama. Baca referensi parameter Modelfile untuk versi yang benar-benar Anda jalankan, lalu konfirmasikan perilakunya dengan pemeriksaan eval_count di atas. Nilai yang Anda verifikasi sendiri pada server Anda lebih dapat diandalkan daripada nilai yang Anda baca di mana pun, termasuk dalam artikel ini.

Mengapa panjang output merupakan biaya utama pada VPS yang hanya menggunakan CPU

Generasi berlangsung dalam dua fase dengan kecepatan yang sangat berbeda. Token prompt dievaluasi secara batch, banyak token sekaligus. Token output dihasilkan satu per satu, dan setiap token memerlukan satu kali pemrosesan penuh terhadap bobot model. Pada VPS yang hanya menggunakan CPU, pemrosesan tersebut dibatasi oleh bandwidth memori. Karena itu, biaya satu token yang dihasilkan jauh lebih besar daripada satu token prompt. Pemrosesan tersebut harus membaca setiap bobot. Jadi, jumlah byte yang digunakan setiap bobot menentukan batas laju token Anda. Inilah sebabnya build q4 mendekode lebih cepat daripada model yang sama pada q8 atau fp16.

Minta respons tanpa streaming, dan angkanya akan terlihat jelas:

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

Durasi dinyatakan dalam nanodetik. Pada blok tersebut, yang merupakan contoh respons dalam dokumentasi API Ollama, bukan hasil pengukuran server tertentu, 26 token prompt memerlukan sekitar 0.1 detik, sedangkan 237 token output memerlukan sekitar 4.3 detik. Laju generasi Anda adalah eval_count dibagi eval_duration lalu dikonversi ke detik. Mengukur token per detik pada perangkat keras Anda sendiri layak dilakukan satu kali sebelum Anda menyesuaikan hal lain. Laju tersebut bergantung pada model dan mesin. Jadi, jika jawaban panjang merupakan biaya utama, model yang dibuat untuk decoding cepat, seperti Nemotron 3.5 Lightning pada VPS, dapat mengurangi sebagian waktu yang biasanya dilindungi oleh batas rendah.

Perhitungannya menjelaskan sisanya. Pada laju 8 token per detik, jawaban sepanjang 2,000 token membuat mesin sibuk selama lebih dari empat menit. Model tidak mengetahui bahwa Anda hanya menginginkan satu paragraf. Model reasoning menggunakan sebagian anggaran tersebut untuk berpikir sebelum menulis kata yang Anda minta. Proses berpikir itu juga dihasilkan satu token pada satu waktu, sama seperti output lainnya. Jadi, upaya reasoning yang Anda minta merupakan pengatur lain pada biaya yang sama. Beberapa model juga dapat mengalami loop dan mengulangi frasa sampai sesuatu menghentikannya. Tanpa batas, satu request tersebut akan terus menggunakan satu core sampai context window habis. num_predict adalah pengaturan yang membatasinya. Pengaturan ini paling penting pada VPS Ollama yang di-hosting sendiri berukuran kecil, ketika satu request panjang dapat menggunakan seluruh mesin.

Output terpotong biasanya disebabkan batas, bukan model yang rusak

Gejalanya tampak seperti kegagalan model. Jawaban berhenti di tengah kalimat. JSON tidak dapat di-parse karena kurung kurawal penutup tidak pernah muncul. Reaksi awal biasanya menyalahkan model atau kuantisasi. Periksa responsnya terlebih dahulu.

done_reason berarti model menjawab pertanyaan secara langsung. stop berarti model selesai dengan sendirinya, baik karena mengeluarkan token end-of-sequence maupun karena cocok dengan salah satu string dalam opsi stop Anda. length berarti generasi dihentikan karena ruang yang tersedia habis. Saat melihat length, bandingkan eval_count dengan batas Anda: kecocokan persis berarti num_predict yang menghentikannya, sedangkan angka yang lebih kecil berarti context window terisi lebih dahulu.

Saat melakukan streaming, kolom-kolom tersebut muncul dalam chunk terakhir, yaitu chunk yang membawa "done": true. Banyak client library membuang chunk itu dan hanya menyerahkan teks kepada kode Anda. Karena itu, pemotongan yang sama tampak tidak dapat dijelaskan di dalam aplikasi, tetapi jelas saat menggunakan curl. Jika library menyembunyikannya, kirim satu request dengan curl untuk mengetahui respons sebenarnya dari server.

Ada satu hal lagi yang dapat mencegah Anda membuang waktu. Menaikkan num_predict tidak membuat model menulis lebih banyak. Tindakan itu hanya menghapus batas atas. Jika respons berakhir pada 200 token dengan done_reason dari stop, model memutuskan bahwa responsnya sudah selesai, dan batas yang lebih besar tidak akan mengubah apa pun. Jawaban singkat dengan stop adalah masalah prompting. Jawaban singkat dengan length adalah masalah batas.

Memilih nilai

  • Untuk chat interaktif, biarkan tanpa batas dan tekan Ctrl+C untuk menghentikan respons yang berjalan tanpa kendali. Anda tetap memantau layar.
  • Untuk apa pun yang dijalankan melalui skrip, tetapkan nilainya. Generasi tanpa batas di dalam loop dapat menyebabkan tugas batch yang seharusnya selesai dalam sepuluh menit masih berjalan keesokan paginya.
  • Untuk output terstruktur, tetapkan batas di atas ukuran dokumen valid terbesar yang Anda perkirakan, lalu perlakukan done_reason dari length sebagai error yang harus ditangani dan ulangi permintaan, bukan mengurai hasil yang diterima.
  • Untuk coding agent, nilai tersebut harus ditetapkan dalam konfigurasi agent itu sendiri karena agent mengirimkan opsinya sendiri pada setiap request. Mengarahkan coding agent ke Ollama menjelaskan lokasi pengaturan tersebut.

Batas ini menghitung token, bukan kata atau karakter, jadi jangan memperkirakannya. Hasilkan satu jawaban yang representatif tanpa batas, baca eval_count, lalu tetapkan limit dengan jarak yang cukup di atas nilai tersebut. Setiap keluarga model menggunakan tokenisasi yang berbeda, sehingga nilai yang cukup untuk model Llama dapat memotong jawaban yang sama dari model Qwen 3 pada VPS yang sama.

FAQ

Apa perbedaan antara num_ctx dan num_predict dalam Ollama?

num_ctx adalah ukuran jendela konteks. Nilai ini menentukan banyaknya teks yang dapat dibaca model: prompt ditambah semua teks yang telah dihasilkan. Nilai ini membutuhkan memori karena key/value cache bertambah seiring ukurannya. num_predict menentukan jumlah token yang boleh ditulis model dalam satu respons. Nilai ini lebih banyak membutuhkan waktu daripada memori, dan tidak ada ruang yang dicadangkan sebelumnya. Token yang dihasilkan dihitung terhadap keduanya, sehingga respons dapat terpotong karena salah satunya.

Mengapa pengaturan num_predict saya tampaknya diabaikan?

Karena nilai yang dikirim bersama request mengesampingkan nilai yang tersimpan dalam model. Masukkan PARAMETER num_predict 512 ke dalam Modelfile, lalu gunakan model tersebut dari chat front end atau coding agent. Klien akan mengirim objek options miliknya sendiri, dan nilai di dalamnya yang digunakan. ollama show --parameters tetap menampilkan nilai Anda karena membaca model yang tersimpan dan tidak dapat melihat data yang diterima melalui HTTP. Kirim satu request dengan curl menggunakan "options": {"num_predict": 32}, lalu periksa apakah eval_count bernilai 32. Ini mengonfirmasi bahwa server berfungsi dengan benar dan mengarahkan pemeriksaan ke aplikasi Anda.

Bagaimana cara mengetahui apakah output saya terpotong oleh num_predict?

Kirim request dengan "stream": false, lalu baca done_reason. Nilai stop berarti model selesai dengan sendirinya. Nilai length berarti ruang yang tersedia telah habis. Bandingkan eval_count dengan batas Anda. Jika nilainya sama persis, num_predict yang menghentikannya. Jika eval_count lebih kecil, jendela konteks telah penuh terlebih dahulu. Saat menggunakan streaming, kedua field tersebut muncul dalam chunk terakhir bersama "done": true. Banyak pustaka klien membuangnya sebelum kode Anda dapat membacanya.

Berapa nilai default num_predict?

Baca nilainya dari instalasi Anda sendiri, bukan dari artikel. Per Agustus 2026, referensi Ollama Modelfile mencantumkan nilai default -1. Artinya, generasi tidak dibatasi. Entri tersebut diperbaiki pada akhir 2024 setelah bertahun-tahun mendokumentasikan 128. Nilai negatif berfungsi sebagai sentinel, bukan sebagai jumlah. Versi lama dari tabel yang sama juga mencantumkan -2 untuk mengisi sisa konteks. Periksa referensi parameter Modelfile untuk versi Anda, lalu konfirmasikan dengan ollama show --parameters dan satu request curl.

Apakah menaikkan num_predict membuat model menulis jawaban yang lebih panjang?

Tidak. Tindakan ini hanya menghapus batas atas. Jika respons berakhir dengan done_reason dari stop, model memutuskan bahwa responsnya sudah selesai, sehingga batas yang lebih besar tidak mengubah apa pun. Dalam kasus tersebut, panjang respons bergantung pada prompt. Minta struktur tertentu, jumlah bagian, atau tingkat detail yang ditentukan. Naikkan num_predict hanya jika done_reason menghasilkan length.