Perbezaan Ollama pull dan run serta lokasi fail model

ollama pull berbanding ollama run

ollama pull memuat turun model dan berhenti. ollama run memuat turun model hanya jika ia tiada, kemudian memuatkannya ke dalam memori dan membuka sesi sembang interaktif. Muat turun adalah sama dan fail disimpan di lokasi yang sama. Hanya run yang terus berjalan selepas itu.

Perbezaan tunggal itu menentukan arahan mana yang sesuai digunakan dalam skrip dan mana yang sesuai ditaip pada papan kekunci.

ollama pull gemma4
ollama run gemma4
ollama run gemma4 "Reply with one word: ready"

Baris pertama mengambil model dan keluar, jadi ia selamat digunakan dalam penyediaan (provisioning) dan unit systemd. Baris kedua membuka sesi sembang; taip /bye atau tekan Ctrl+D untuk keluar. Baris ketiga menghantar satu gesaan (prompt), mencetak jawapan dan keluar; ini adalah bentuk yang diperlukan oleh skrip apabila ia memerlukan jawapan dan bukannya sesi. Bentuk ketiga itu masih membiarkan panjang jawapan ditentukan sepenuhnya oleh model, jadi soalan satu baris boleh dibalas dengan tiga perenggan, dan mengehadkan jawapan dengan num_predict adalah cara untuk memastikan run yang diskripkan kekal dalam saiz yang boleh digunakan oleh pemanggil. Nama model berubah dengan cepat, jadi anggap gemma4 di sini sebagai pemegang tempat (placeholder): ia adalah contoh yang digunakan oleh dokumentasi rasmi Ollama setakat Ogos 2026, dan mana-mana tag daripada pustaka tersebut berkelakuan sama. Jika anda lebih suka menggantikan dengan model yang telah disesuaikan oleh seseorang dengan pelayan sebenar, menjalankan Nemotron 3.5 Lightning pada VPS memberikan tag tepat untuk ditarik (pull) dan memori yang dijangka akan digunakan.

Mengapa ollama run pertama kelihatan seolah-olah terhenti

run pertama pada VPS baharu boleh kekal tanpa sebarang output selama beberapa minit. Tiada apa-apa yang rosak. Prompt sembang tidak akan muncul sehingga model berada dalam cakera dan dimuatkan ke dalam memori, jadi run sedang melakukan muat turun bersaiz berbilang gigabait sebelum ia mempunyai apa-apa untuk dipaparkan kepada anda.

Dua perkara menyembunyikan proses tersebut. Ollama hanya melukis bar kemajuan apabila outputnya adalah terminal, jadi run di dalam skrip shell, cron job, langkah CI atau ssh host ollama run ... biasa tidak mencetak apa-apa langsung semasa ia memuat turun. Kemudian, sebaik sahaja bait data sampai, fail tersebut masih perlu dibaca daripada cakera ke dalam RAM sebelum token pertama, dan pada VPS kecil, bacaan itu adalah perlahan. Jika pelayan tidak mempunyai memori yang mencukupi untuk model tersebut, kernel akan mula melakukan swapping dan tempoh menunggu menjadi jauh lebih lama.

Pantau proses tersebut daripada sesi kedua dan bukannya membuat andaian:

df -h /
watch -n5 df -h /

Ruang bebas yang berkurangan secara berperingkat bermakna muat turun masih berjalan. Ruang bebas yang berhenti berkurangan sementara arahan masih sibuk bermakna muat turun telah selesai dan proses memuatkan ke dalam memori telah bermula.

Inilah sebabnya mengapa anda perlu melakukan pull lebih awal. Pengguna yang menaip ollama run tidak sepatutnya menjadi orang yang menanggung masa menunggu muat turun tersebut.

Tarik model sebelum ada yang memintanya

Perkara yang sama terpakai untuk apa-apa yang bukan manusia: ejen pengekodan yang dihalakan ke endpoint Ollama anda biasanya akan berputus asa pada permintaan pertama daripada menunggu muat turun bersaiz berbilang gigabait selesai. Pada mesin baharu, tarik skrip yang sama yang memasang pelayan tersebut:

curl -fsSL https://ollama.com/install.sh | sh
ollama pull gemma4

Jika anda sedang menyediakan pelayan buat kali pertama, pemasangan penuh Ollama pada VPS merangkumi servis itu sendiri dan siapa yang dibenarkan untuk mencapainya. Selepas itu, perkara yang berbaloi untuk disediakan ialah tarikan (pull) yang kekal walaupun terminal anda ditutup, kerana muat turun yang terhenti di tengah jalan adalah punca pengguna berakhir dengan stor model yang tidak lengkap.

Jalankannya di dalam tmux, atau serahkannya kepada systemd sebagai unit one-shot yang berjalan semasa but. Tulis /etc/systemd/system/ollama-pull.service:

[Unit]
Description=Pre-pull Ollama models
Wants=ollama.service network-online.target
After=ollama.service network-online.target

[Service]
Type=oneshot
RemainAfterExit=yes
ExecStart=/bin/sh -c 'until ollama list >/dev/null 2>&1; do sleep 2; done'
ExecStart=/bin/sh -c 'ollama pull gemma4'

[Install]
WantedBy=multi-user.target

Kedua-dua arahan dijalankan melalui /bin/sh -c dengan sengaja. ExecStart= kosong memerlukan laluan mutlak (absolute path), dan pemasang tidak selalunya meletakkan binari dalam direktori yang sama, jadi command -v ollama pada mesin anda sendiri adalah satu-satunya jawapan yang boleh dipercayai. Menggunakan shell akan menggunakan PATH servis dan bukannya laluan yang disalin daripada panduan. ExecStart yang pertama juga penting: After=ollama.service bermaksud unit pelayan telah dimulakan, yang tidak sama dengan sedia, jadi gelung menunggu sehingga ollama list menjawab sebelum tarikan bermula.

sudo systemctl daemon-reload
sudo systemctl enable --now ollama-pull.service
journalctl -u ollama-pull.service

Jurnal sepatutnya menunjukkan tarikan selesai tanpa ralat, dan ollama list sepatutnya menunjukkan model tersebut. Untuk memastikan tag yang berubah sentiasa terkini, tambahkan pemasa systemd atau entri cron mingguan yang menjalankan tarikan yang sama. Menarik semula tag yang telah berubah akan memuat turun lapisan baharu dan membiarkan lapisan lama tanpa rujukan, dan lapisan tersebut akan dibersihkan pada kali seterusnya pelayan dimulakan.

Apa yang berlaku apabila proses pull terganggu

Setiap lapisan model disimpan di bawah hash kandungannya sendiri. Oleh itu, proses pull yang terganggu bukanlah kerja yang sia-sia: jalankan ollama pull yang sama sekali lagi, dan lapisan yang telah selesai akan dikesan serta dilangkau, supaya muat turun bersambung pada lapisan yang terputus.

Satu tindakan akan memusnahkan kemajuan tersebut. Apabila pelayan Ollama bermula, ia akan membuang lapisan tersimpan yang tidak dirujuk oleh mana-mana manifes model, dan lapisan separa yang ditinggalkan oleh proses pull yang mati adalah salah satu daripadanya. Jadi, memulakan semula servis sebelum anda mencuba semula akan membuang bahagian yang telah anda muat turun. Cuba semula proses pull dahulu dan mulakan semula servis kemudian. Jika muat turun separa benar-benar perlu bertahan selepas proses dimulakan semula, tetapkan OLLAMA_NOPRUNE=1 dalam persekitaran servis, kemudian alih keluar tetapan tersebut, kerana pembersihan semasa permulaan itulah yang menghalang lapisan terbiar daripada terkumpul pada cakera.

Jika proses pull mati dengan no space left on device, kosongkan ruang sebelum mencuba semula. Jika df melaporkan cakera penuh dan du pada direktori model tidak menunjukkan penggunaan ruang tersebut, ruang itu telah digunakan di tempat lain, dan sebab df dan du tidak sepadan perlu dibaca sebelum anda memadam apa-apa.

Di manakah Ollama menyimpan model pada VPS?

Tanya pelayan anda sendiri dan jangan hanya bergantung pada laluan daripada mana-mana panduan, termasuk panduan ini. Lokasi penyimpanan berbeza antara pemasangan pakej dan kontena, malah ia berubah jika seseorang telah menetapkan OLLAMA_MODELS.

systemctl cat ollama.service
getent passwd ollama
sudo find / -xdev -type d -name blobs 2>/dev/null

systemctl cat memaparkan fail unit berserta setiap drop-in, jadi baris OLLAMA_MODELS yang ditetapkan oleh anda atau yang disertakan dalam imej anda akan kelihatan di situ. Jika tiada baris sedemikian, storan terletak di bawah direktori home akaun yang menjalankan servis tersebut, dan getent passwd memaparkan direktori home itu pada medan keenam yang dipisahkan oleh titik bertindih. find mencari satu sistem fail untuk direktori blobs, iaitu tempat lapisan (layers) sebenarnya ditulis. Abaikan -xdev jika model mungkin sudah berada pada mount yang berasingan.

Sekarang, buat pengukuran dan baca angka anda sendiri:

ollama list
df -h /
sudo du -sh /the/directory/you/found
sudo du -h -d1 /the/directory/you/found

Storan ini mempunyai dua bahagian. manifests menyimpan satu fail kecil bagi setiap tag model, dan fail tersebut menyenaraikan lapisan yang membentuk tag berkenaan. blobs menyimpan lapisan itu sendiri, setiap satunya dinamakan mengikut hash kandungannya, dan hampir keseluruhan saiz storan tertumpu di situ. Oleh sebab lapisan dikongsi antara tag, dua model yang dibina berdasarkan weight yang sama masing-masing akan melaporkan saiznya sendiri dalam ollama list, walaupun ia hanya menduduki ruang tersebut sekali sahaja pada cakera. Oleh itu, jumlah saiz yang disenaraikan boleh menjadi lebih besar daripada apa yang dilaporkan oleh du untuk direktori tersebut.

Fail model mengisi sistem fail root VPS yang kecil dengan lebih cepat berbanding apa sahaja yang mungkin anda pasang, dan faktor tunggal terbesar yang mempengaruhi saiznya ialah format weight. Memilih antara q4, q8 dan fp16 boleh menjimatkan gigabait bagi setiap model.

Alihkan model ke volum data dengan OLLAMA_MODELS

Jika pelan mempunyai cakera kedua atau volum data yang lebih besar, alihkan storan sebelum sistem fail root penuh. Hentikan pelayan terlebih dahulu supaya anda tidak menyalin fail yang masih dalam proses penulisan.

sudo systemctl stop ollama
sudo mkdir -p /mnt/data/ollama-models
sudo rsync -a /the/directory/you/found/ /mnt/data/ollama-models/
sudo chown -R ollama:ollama /mnt/data/ollama-models
sudo systemctl edit ollama.service

systemctl edit membuka editor pada fail drop-in, supaya unit pakej kekal tidak disentuh dan naik taraf pakej tidak akan menimpa perubahan anda. Tambahkan dua baris ini:

[Service]
Environment="OLLAMA_MODELS=/mnt/data/ollama-models"

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

systemctl show sepatutnya memaparkan laluan baharu anda, dan ollama list sepatutnya menunjukkan model yang sama seperti yang dipaparkan sebelum pengalihan. Senarai kosong bermakna pelayan tidak dapat membaca direktori baharu tersebut. Servis berjalan sebagai pengguna ollama, jadi pengguna tersebut memerlukan akses baca dan tulis ke destinasi, yang merupakan fungsi baris chown di atas. Semak journalctl -e -u ollama untuk ralat kebenaran yang menamakan laluan baharu tersebut. Padamkan salinan lama hanya selepas senarai itu betul, kerana pengalihan yang gagal ditambah dengan sumber yang telah dipadam bermakna anda perlu memuat turun semuanya semula.

Pilihan lain mengekalkan laluan asal dan melekapkan (mount) volum data ke atasnya:

echo '/mnt/data/ollama-models /the/directory/you/found none bind 0 0' | sudo tee -a /etc/fstab
sudo mount -a
findmnt /the/directory/you/found
df -h /

findmnt yang memaparkan mount bermakna bind tersebut aktif. Bind mount membantu apabila sesuatu yang lain pada mesin tersebut sudah menjangkakan lokasi lalai. Ia mempunyai satu perangkap: fail yang anda salin keluar masih berada di bawah titik lekap (mount point) pada cakera root, disembunyikan oleh mount tersebut, jadi ruang storan tidak dikembalikan sehingga anda menyahlekap (unmount) dan memadamkannya. Pemboleh ubah persekitaran adalah pilihan yang lebih mudah untuk dijelaskan kepada sesiapa sahaja yang log masuk seterusnya.

Di mana kontena menyimpannya

Imej rasmi menyimpan model dalam apa sahaja yang anda lekapkan (mount), bukan dalam mana-mana direktori hos milik pengguna ollama. Perintah jalankan yang didokumentasikan adalah:

docker run -d -v ollama:/root/.ollama -p 11434:11434 --name ollama ollama/ollama

ollama sebelum titik bertindih ialah volum Docker bernama, dan /root/.ollama ialah tempat pelayan menulis di dalam kontena. Jadi, du terhadap laluan daripada bahagian sebelumnya tidak menemui apa-apa, kerana tiada apa-apa di sana. Paparkan lokasi dan saiz sebenar:

docker volume inspect ollama
docker system df -v
docker exec -it ollama ollama list

Baca medan Mountpoint daripada docker volume inspect, kemudian jalankan sudo du -sh terhadapnya. Untuk meletakkan model pada volum data, gantikan volum bernama dengan direktori hos (-v /mnt/data/ollama:/root/.ollama) dan cipta semula kontena tersebut. Kontena menulis sebagai root, jadi direktori hos tersebut akhirnya dimiliki oleh root. Di bawah Podman tanpa root (rootless), ID dipetakan ke dalam julat subuid pengguna anda, jadi pemilikan hos kelihatan berbeza semula: menjalankan Ollama di bawah Podman tanpa root merangkumi pemetaan tersebut.

Satu amaran tentang pembersihan. docker volume prune membuang setiap volum yang tidak dirujuk oleh mana-mana kontena. Buang atau cipta semula kontena ollama tanpa volumnya dan tindakan prune kemudiannya akan memadamkan setiap model yang anda muat turun, tanpa cara untuk mendapatkannya semula kecuali memuat turunnya sekali lagi. Baca cara melakukan prune penggunaan cakera Docker pada VPS sebelum menjalankan prune pada kotak yang mengehoskan model.

Alih keluar model dengan ollama rm, bukan dengan rm

ollama list
ollama rm gemma4
ollama list
df -h /

ollama rm memadamkan manifest untuk tag tersebut, kemudian memadamkan layer yang tidak lagi dirujuk oleh mana-mana manifest yang tinggal. Ruang storan akan dikembalikan sebaik sahaja fail tersebut dinyahpaut, jadi df akan terus berfungsi. Oleh kerana layer dikongsi, memadamkan satu daripada dua tag yang berkait rapat mungkin membebaskan ruang yang jauh lebih kecil daripada saiz ollama list yang dipaparkan di sebelahnya. Itu adalah kelakuan yang betul, bukan pemadaman yang gagal.

Memadamkan fail secara manual akan merosakkan pasangan tersebut. Alih keluar blob dengan rm dan manifest masih menyenaraikannya, jadi ollama list akan terus menunjukkan model tersebut dan sebarang percubaan untuk menggunakannya akan gagal apabila layer yang hilang itu dibaca. Memadamkan manifest secara manual akan menyebabkan layer-layernya kekal pada cakera tanpa sebarang rujukan, mengambil ruang yang tidak akan dilaporkan oleh mana-mana arahan Ollama kepada anda. Jika anda telah melakukannya, ollama rm pada tag tersebut akan membersihkan entri yang tertinggal, dan memulakan semula pelayan akan membersihkan layer yang tidak dirujuk oleh apa-apa.

Satu perbezaan terakhir, kerana kedua-duanya sering tertukar. ollama rm adalah mengenai cakera. ollama stop gemma4 memunggah model daripada memori dan tidak membebaskan sebarang ruang cakera. Berapa lama model kekal dalam RAM selepas muat turun selesai adalah tetapan yang berasingan, dan mengekalkan model dimuatkan dan bukannya memuat semula pada setiap permintaan membincangkan perkara ini.

FAQ

Apakah perbezaan antara ollama pull dan ollama run?

ollama pull memuat turun model ke cakera dan keluar. ollama run menyemak sama ada model sudah ada pada cakera, memuat turunnya jika belum, memuatkannya ke dalam memori, dan kemudian membuka sesi sembang interaktif. Kedua-duanya menulis fail yang sama ke direktori yang sama. Gunakan pull dalam penyediaan (provisioning) dan skrip, dan gunakan run apabila pengguna berada di hadapan papan kekunci. ollama run <model> "your prompt" menghantar satu prompt dan keluar, yang merupakan bentuk boleh skrip bagi run.

Mengapa ollama run pertama saya kelihatan tergantung?

Ia sedang memuat turun. Prompt sembang tidak boleh muncul sehingga model berada pada cakera dan dimuatkan ke dalam memori, dan saiz model adalah beberapa gigabait. Ollama hanya melukis bar kemajuannya apabila output adalah terminal, jadi run di dalam skrip, cron job atau ssh host ollama run ... tidak menunjukkan apa-apa semasa ia berfungsi. Buka sesi kedua dan jalankan watch -n5 df -h /: ruang bebas yang berkurangan secara berperingkat bermakna muat turun sedang berjalan. Muat turun model lebih awal dan masa menunggu akan hilang.

Di manakah Ollama menyimpan modelnya?

Lokasi bergantung pada pemasangan, jadi cetak lokasinya daripada membuat andaian. Jalankan systemctl cat ollama.service untuk melihat sama ada OLLAMA_MODELS ditetapkan dalam unit atau drop-in. Jika tidak, storan berada di bawah direktori home akaun yang menjalankan servis tersebut, yang dicetak oleh getent passwd ollama. sudo find / -xdev -type d -name blobs 2>/dev/null mencari direktori layer secara terus. Bagi imej kontena, storan berada di dalam volume yang dilekapkan, dan docker volume inspect ollama mencetak Mountpoint hosnya.

Bagaimanakah cara saya memindahkan model Ollama ke cakera lain?

Hentikan servis, salin storan ke lokasi baharu dengan rsync -a, berikan direktori tersebut kepada akaun servis dengan sudo chown -R ollama:ollama <directory>, kemudian jalankan sudo systemctl edit ollama.service dan tambahkan Environment="OLLAMA_MODELS=<directory>" di bawah baris [Service]. Muat semula dengan sudo systemctl daemon-reload dan mulakan semula. Sahkan dengan systemctl show ollama --property=Environment dan ollama list. Senarai kosong hampir selalu bermaksud pengguna ollama tidak boleh membaca direktori baharu tersebut; journalctl -e -u ollama akan menamakan laluan tersebut.

Adakah memadam fail model membebaskan ruang?

Memadam fail secara manual membebaskan bait tetapi menyebabkan storan menjadi tidak konsisten. Jika anda memadam blob, manifest masih menyenaraikan model tersebut, jadi ia akan terus muncul dalam ollama list dan gagal apabila digunakan. Jika anda memadam manifest, layer-nya kekal pada cakera tanpa rujukan. Gunakan ollama rm <model>, yang memadam manifest dan kemudian layer yang tidak diperlukan oleh model lain. Jika fail telah dipadam secara manual, jalankan ollama rm pada tag untuk membersihkan entri, kemudian mulakan semula pelayan, yang akan membuang layer yang tidak dirujuk oleh mana-mana manifest.