SSD Nodes Learn 🎉 VPS dari $5.50/bln
Panduan Matt ConnorOleh Matt Connor · Dikemas kini 2026-08-13

Cara Kekalkan Model Ollama Dalam Memori

Ollama memunggah model selepas 5 minit melahu yang menyebabkan kelewatan respons. Ketahui cara menetapkan parameter keep_alive dalam systemd supaya model kekal aktif.

Mengapa Ollama memunggah model selepas beberapa minit?

Ollama mengekalkan model dalam memori selama lima minit selepas permintaan terakhir, kemudian membebaskannya. Permintaan seterusnya perlu membaca pemberat (weights) daripada cakera dan memetakannya semula ke dalam RAM atau VRAM, menyebabkan ia terhenti seketika sebelum token pertama tiba. Inilah sebabnya antara muka sembang atau ejen pengekodan terasa pantas, menjadi senyap seketika, kemudian terasa perlahan semula pada mesej berikutnya. Tiada apa-apa yang rosak. Pemasa melahu telah tamat tempoh.

Pemasa ini dipanggil keep_alive. Ia ditetapkan bagi setiap model, dan ia bermula semula setiap kali sesuatu permintaan selesai. Model yang sedang menjawab permintaan tidak akan dipunggah, kerana pelayan hanya menamatkan tempoh model yang tidak mempunyai permintaan aktif. Setakat Ogos 2026, nilai lalai ialah lima minit, dan ia terpakai kepada setiap model yang dimuatkan oleh pelayan ini.

Terdapat dua tempat untuk menetapkan keep_alive: pada permintaan individu, atau sebagai nilai lalai pelayan. Fail drop-in systemd ialah cara untuk memastikan nilai lalai pelayan kekal selepas but semula. Panduan ini mengandaikan Ollama sudah berjalan sebagai servis. Jika belum, mulakan dengan memasang Ollama pada VPS dan kembali ke sini.

Model manakah yang sedang dimuatkan sekarang, dan bilakah ia akan tamat tempoh?

ollama ps
NAME        ID              SIZE      PROCESSOR    CONTEXT    UNTIL
qwen3:8b    500a1f067a9f    6.6 GB    100% GPU     4096       4 minutes from now

Output kosong bermakna tiada apa-apa yang dimuatkan, jadi permintaan seterusnya akan menanggung beban muatan penuh. PROCESSOR memberitahu anda ke mana berat model tersebut pergi. 100% GPU dan 100% CPU adalah kes yang jelas. Pembahagian seperti 25%/75% CPU/GPU bermakna model tersebut tidak muat dalam VRAM, jadi sebahagian daripadanya berjalan pada pemproses dan penjanaan menjadi lebih perlahan.

UNTIL ialah kiraan detik, dan ia mencetak masa relatif seperti 4 minutes from now. Ia mencetak Forever apabila model dimuatkan dengan keep_alive negatif. Ia mencetak Stopping... semasa tempoh singkat apabila pelayan sedang memunggah (unloading).

Set lajur telah berubah antara keluaran, jadi baca pengepala dan bukannya mengira medan dalam skrip. Untuk sebarang automasi, tanya API:

curl -s http://localhost:11434/api/ps

Setiap entri membawa expires_at, iaitu cap masa mutlak seperti 2026-08-09T14:38:31.83753Z, dan size_vram, iaitu bahagian model tersebut yang berada dalam memori GPU. size_vram bernilai 0 bermakna model tersebut sedang berjalan pada CPU.

Kos sebenar muat semula

Jangan membuat andaian. Ollama melaporkan masa muat dalam setiap respons, sebagai load_duration, dalam unit nanosaat.

sudo apt install -y jq
ollama stop qwen3:8b
curl -s http://localhost:11434/api/generate -d '{"model": "qwen3:8b", "prompt": "hi", "stream": false}' | jq '{load_duration, total_duration}'
curl -s http://localhost:11434/api/generate -d '{"model": "qwen3:8b", "prompt": "hi", "stream": false}' | jq '{load_duration, total_duration}'

Panggilan pertama memuatkan model, jadi nilai load_duration adalah besar. Bahagikan dengan 1000000000 untuk membacanya dalam unit saat. Panggilan kedua berjalan semasa model berada dalam memori dan melaporkan angka yang jauh lebih kecil. Jurang antara kedua-dua angka tersebut adalah kos yang ditanggung oleh setiap pengguna sebaik sahaja pemasa tamat, dan itulah sebab utama untuk menukar keep_alive. Bagi kelajuan penjanaan di kedua-dua belah jeda tersebut, lihat cara mengukur token sesaat pada pelayan anda sendiri.

Pastikan model Ollama kekal dimuatkan dalam memori pada satu permintaan

Hantar keep_alive bersama permintaan tersebut. Ia terpakai pada model itu sebaik sahaja permintaan selesai.

curl -s http://localhost:11434/api/chat -d '{
  "model": "qwen3:8b",
  "messages": [{"role": "user", "content": "hello"}],
  "keep_alive": "30m"
}'

Empat bentuk nilai diterima:

  • rentetan tempoh: "30m", "24h", "90s"
  • nombor biasa, dibaca sebagai saat: 3600
  • nilai negatif, -1 atau "-1m", bermaksud tiada tamat masa melahu langsung
  • 0, bermaksud nyahmuat sebaik sahaja permintaan ini selesai

Nilai pada permintaan mengatasi lalai pelayan, dalam kedua-dua arah. Ini lebih penting daripada kedengarannya: klien yang menghantar keep_alive sendiri akan mengatasi apa sahaja yang anda konfigurasikan pada pelayan.

Anda juga boleh memuatkan model tanpa menjana apa-apa. Hantar nama model sahaja. Pelayan akan memuatkannya dan mengembalikan respons kosong dengan "done": true.

curl -s http://localhost:11434/api/generate -d '{"model": "qwen3:8b", "keep_alive": "30m"}'

Itu adalah perintah untuk dijalankan selepas but semula, atau selepas menarik model baharu, supaya permintaan pengguna sebenar yang pertama tidak perlu menunggu proses pemuatan. CLI melakukan tugas yang sama dengan flag:

ollama run --keepalive 30m qwen3:8b "hello"

Pastikan ia kekal dimuatkan secara lalai dengan OLLAMA_KEEP_ALIVE

Pelayan membaca OLLAMA_KEEP_ALIVE semasa permulaan dan menggunakannya untuk setiap model yang tidak mempunyai nilainya sendiri. Ia menerima format yang sama seperti medan permintaan, jadi 30m, 3600 dan -1 semuanya berfungsi.

Masalahnya ialah persekitaran mana yang perlu memuatkan tetapan tersebut. Menjalankan export OLLAMA_KEEP_ALIVE=30m dalam sesi SSH anda tidak memberikan sebarang kesan, kerana pemasangan pakej menjalankan pelayan sebagai servis systemd di bawah penggunanya sendiri dengan persekitarannya sendiri. Shell log masuk anda dan servis tersebut tidak berkongsi persekitaran yang sama. Ini adalah sebab paling biasa mengapa tetapan tersebut kelihatan tidak diendahkan.

Memastikan ia bertahan selepas but semula dengan drop-in systemd

sudo systemctl edit ollama.service

Editor akan dibuka dengan dua penanda komen. Taip di antara kedua-duanya: systemd akan membuang apa-apa yang anda tulis di bawah penanda kedua.

[Service]
Environment="OLLAMA_KEEP_ALIVE=30m"

Menyimpan fail akan menulis /etc/systemd/system/ollama.service.d/override.conf. Ini merupakan drop-in dan bukannya suntingan pada unit asal, jadi naik taraf pakej Ollama yang menggantikan ollama.service tidak akan mengubah tetapan anda. Jika drop-in dan fail unit adalah perkara baharu bagi anda, panduan servis dan pemasa systemd merangkumi mekanismenya.

sudo systemctl daemon-reload
sudo systemctl restart ollama
systemctl show ollama --property=Environment

Perintah terakhir mencetak persekitaran yang akan digunakan oleh servis tersebut semasa berjalan. Jika OLLAMA_KEEP_ALIVE=30m tiada pada baris tersebut, drop-in tidak berjaya digunakan, dan puncanya hampir selalu disebabkan oleh pengepala [Service] yang hilang atau baris yang ditaip di bawah penanda. Proses but semula akan membuang setiap model yang dimuatkan, jadi permintaan seterusnya adalah muatan sejuk (cold load). Panaskan ia dengan panggilan pramuat di atas.

Kos mengekalkan model dalam memori

Lajur SIZE dalam ollama ps ialah memori yang ditahan sepanjang tempoh melahu, bukan sekadar semasa permintaan diproses. Model 8B pada kuantisasi 4-bit menggunakan sekitar 5 hingga 6 GB. Model 27B pula adalah cerita yang berbeza, dan pengiraan memori untuk menjalankannya pada VPS berasaskan CPU sahaja perlu diteliti sebelum anda membuat keputusan untuk mengekalkannya dalam memori. Tetapkan keep_alive kepada -1 dan anda telah memutuskan bahawa model tersebut lebih utama daripada segala-galanya dalam pelayan tersebut secara kekal. Pada VPS kecil, ini merupakan pertukaran langsung dengan pangkalan data, aplikasi web dan tugasan binaan (build jobs) anda.

Pantau angka sebenar dan jangan sekadar mempercayai anggaran. Jalankan arahan ini semasa model dimuatkan, kemudian jalankan sekali lagi selepas ollama stop:

free -h

Lajur available ialah memori yang masih boleh diberikan oleh kernel kepada proses baharu. Pada pelayan dengan GPU NVIDIA, nvidia-smi menunjukkan situasi yang sama dalam VRAM. Jika pelayan kehabisan memori, kernel akan menamatkan sesuatu proses untuk mendapatkan semula ruang:

sudo dmesg -T | grep -i "out of memory"

Baris yang menamakan ollama bermakna pelayan model menjadi mangsa. Baris yang menamakan pangkalan data anda bermakna model tersebut menang dan aplikasi penting anda pula yang terkorban. Kedua-dua hasil ini berpunca daripada keputusan yang sama: tempoh keep-alive yang panjang pada pelayan yang tidak mempunyai ruang memori yang mencukupi.

Terdapat dua kos yang sering terlepas pandang. Panjang konteks yang lebih besar menempah KV cache (key value cache, iaitu status perhatian per token yang disimpan oleh model semasa menjana output) yang lebih besar, dan cache tersebut adalah sebahagian daripada saiz memori yang diduduki. OLLAMA_NUM_PARALLEL yang melebihi 1 akan menempah cache tersebut sekali bagi setiap slot selari. Jika anda bercadang untuk melayani beberapa pengguna daripada satu model, tentukan saiz memori berdasarkan slot, bukan sekadar berdasarkan berat model (weights).

Nilai lalai yang munasabah: satu model pada pelayan yang mempunyai ruang memori mencukupi boleh menggunakan -1. Pelayan yang dikongsi pula harus menggunakan tempoh masa yang meliputi jurang antara permintaan anda, seperti 30m, supaya memori tersebut dikembalikan apabila anda berhenti bekerja.

Nyahmuat model dengan serta-merta

ollama stop qwen3:8b

Perintah ini kembali tanpa sebarang output, dan model tersebut akan hilang daripada ollama ps. Nama yang tidak dimuatkan akan memberikan couldn't find model "qwen3:8b" to stop. Bentuk API adalah permintaan tanpa prompt dengan keep_alive ditetapkan kepada 0:

curl -s http://localhost:11434/api/chat -d '{"model": "qwen3:8b", "messages": [], "keep_alive": 0}'

Balasan tersebut membawa "done_reason": "unload". Gunakan kaedah ini sebagai ganti memulakan semula servis. systemctl restart ollama turut mengosongkan memori, tetapi ia akan menggugurkan setiap model lain yang dimuatkan dan menamatkan sebarang permintaan yang sedang berjalan.

Menjalankan lebih daripada satu model pada satu pelayan

OLLAMA_MAX_LOADED_MODELS mengehadkan bilangan model yang dimuatkan pada satu-satu masa, dan setakat Ogos 2026, nilai lalai adalah tiga bagi setiap GPU, atau tiga pada mesin yang hanya menggunakan CPU. Had ini mengira bilangan model, namun memori adalah had sebenar, jadi model kedua yang besar boleh ditolak ruangnya jauh sebelum anda mencapai had tiga model.

Apabila model baharu diminta dan memori tidak mencukupi, penjadual akan membuang salah satu model yang sedang dimuatkan untuk memberi ruang. Ia mengutamakan model yang tidak mempunyai permintaan aktif, dan ia akan mengeluarkan model yang pemasa tamat tempohnya belum berakhir, termasuk model yang dimuatkan dengan -1. Oleh itu, nilai keep_alive yang negatif bermaksud tiada tamat tempoh melahu. Ia tidak menetapkan (pin) pemberat (weights) tersebut terhadap permintaan model lain.

Keputusan tersebut direkodkan pada tahap debug. Tambahkan baris Environment="OLLAMA_DEBUG=1" kedua pada drop-in yang sama, mulakan semula, dan pantau:

sudo journalctl -u ollama -f

Satu baris mengenai pembuangan runner untuk memberi ruang, yang terletak bersebelahan dengan permintaan yang mencetuskannya, memberitahu anda bahawa kedua-dua model ini tidak muat bersama pada mesin ini. Penyelesaiannya adalah dengan mengurangkan bilangan model pada mesin ini, atau menetapkan tetingkap masa yang panjang untuk model yang perlu menjawab dengan pantas dan 0 untuk model yang jarang anda panggil.

Panduan yang kekal relevan selepas keluaran seterusnya

Ollama kerap mengeluarkan versi baharu dan tetapan lalai sering berubah, jadi semak binaan (build) yang anda gunakan dan jangan sekadar menghafal nombor:

ollama --version
ollama serve --help

ollama serve --help menyenaraikan pemboleh ubah persekitaran (environment variables) yang dibaca oleh binaan tersebut, termasuk OLLAMA_KEEP_ALIVE. Terdapat dua peraturan yang kekal konsisten merentas pelbagai keluaran dan boleh dijadikan asas. Nilai pada permintaan (request) mengatasi nilai lalai pelayan. Selain itu, ollama ps merupakan sumber kebenaran tentang perkara yang dimuatkan, tidak kira apa yang dinyatakan oleh fail konfigurasi.

Jika editor atau ejen mengendalikan pelayan anda, semak perkara yang dihantar oleh klien tersebut sebelum menyalahkan pelayan. Menghalakan ejen pengekodan ke pelayan Ollama anda sendiri merangkumi lokasi tetapan permintaan tersebut disimpan.

FAQ

Mengapa Ollama memunggah model saya selepas 5 minit?

Lima minit ialah keep_alive lalai, iaitu pemasa melahu yang dimulakan oleh Ollama selepas sesuatu permintaan selesai. Apabila pemasa tamat, pelayan akan membebaskan pemberat (weights) tersebut, jadi permintaan seterusnya akan memuatkan semula model daripada cakera, dan proses muat semula itulah yang menyebabkan jeda yang anda rasai. Tingkatkan tempoh ini untuk satu permintaan dengan menghantar "keep_alive": "30m" dalam badan JSON, atau untuk keseluruhan pelayan dengan pemboleh ubah persekitaran OLLAMA_KEEP_ALIVE.

Bagaimanakah cara untuk memastikan model Ollama kekal dalam memori secara kekal?

Gunakan nilai negatif: "keep_alive": -1 pada permintaan, atau OLLAMA_KEEP_ALIVE=-1 untuk pelayan. ollama ps kemudian akan memaparkan Forever dalam lajur UNTIL. Ini membuang pemasa melahu dan tiada tetapan lain yang terjejas. Jika model lain diminta dan memori tidak mencukupi, penjadual (scheduler) masih akan memunggah model ini untuk memberi ruang.

Mengapa OLLAMA_KEEP_ALIVE diabaikan?

Semak di mana anda menetapkannya. Jalankan systemctl show ollama --property=Environment, dan jika pemboleh ubah tersebut tiada dalam output itu, pelayan tidak pernah melihatnya, kerana pemboleh ubah yang dieksport dalam shell anda tidak sampai ke perkhidmatan systemd. Tetapkannya dengan sudo systemctl edit ollama.service, kemudian jalankan sudo systemctl daemon-reload dan sudo systemctl restart ollama. Punca lain ialah klien yang menghantar keep_alive sendiri pada permintaan, yang mengatasi nilai lalai pelayan.

Bagaimanakah cara untuk membebaskan memori tanpa memulakan semula Ollama?

ollama stop qwen3:8b memunggah model tersebut dengan serta-merta dan membiarkan pelayan serta setiap model lain yang dimuatkan terus berjalan. Melalui API, hantar permintaan tanpa prompt dan "keep_alive": 0, dan balasan akan diterima dengan "done_reason": "unload". Sahkan dengan ollama ps, yang sepatutnya tidak lagi menyenaraikan model tersebut.