ความต่างระหว่าง ollama pull กับ run และที่เก็บไฟล์โมเดล

ความแตกต่างระหว่าง ollama pull และ ollama run

ollama pull จะดาวน์โหลดโมเดลแล้วหยุดการทำงาน ollama run จะดาวน์โหลดโมเดลเฉพาะในกรณีที่ยังไม่มีไฟล์ในเครื่อง จากนั้นจะโหลดโมเดลเข้าสู่หน่วยความจำและเปิดหน้าต่างแชทแบบโต้ตอบ กระบวนการดาวน์โหลดนั้นเหมือนกันทุกประการและไฟล์จะถูกจัดเก็บไว้ในตำแหน่งเดียวกัน มีเพียง run เท่านั้นที่ยังคงทำงานต่อไปหลังจากนั้น

ความแตกต่างเพียงจุดเดียวนี้เป็นตัวกำหนดว่าคำสั่งใดควรใช้ในสคริปต์และคำสั่งใดควรใช้ผ่านคีย์บอร์ด

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

บรรทัดแรกจะดึงโมเดลมาเก็บไว้แล้วจบการทำงาน จึงมีความปลอดภัยในการนำไปใช้ในขั้นตอนการจัดเตรียมระบบ (provisioning) และใน systemd unit บรรทัดที่สองจะเปิดเซสชันแชท ให้พิมพ์ /bye หรือกด Ctrl+D เพื่อออกจากเซสชัน บรรทัดที่สามจะส่งพรอมต์เพียงชุดเดียว พิมพ์คำตอบที่ได้ออกมา แล้วจบการทำงาน ซึ่งเป็นรูปแบบที่สคริปต์ต้องการเมื่อต้องการเพียงคำตอบโดยไม่ต้องการเปิดเซสชันค้างไว้ ชื่อโมเดลมีการเปลี่ยนแปลงอยู่ตลอดเวลา ดังนั้นให้ถือว่า gemma4 ในที่นี้เป็นเพียงตัวอย่างสมมติ ซึ่งเป็นตัวอย่างที่เอกสารอย่างเป็นทางการของ Ollama ใช้ ณ เดือนสิงหาคม 2026 และ tag ใดๆ จาก library ก็จะมีพฤติกรรมเช่นเดียวกันนี้

เหตุใดการรัน ollama ครั้งแรกจึงดูเหมือนค้าง

การรัน run ครั้งแรกบน VPS ใหม่ อาจไม่มีการแสดงผลใดๆ ออกมาเป็นเวลาหลายนาที ซึ่งไม่ได้หมายความว่ามีสิ่งใดเสียหาย พรอมต์การแชทจะไม่ปรากฏจนกว่าโมเดลจะถูกดาวน์โหลดลงดิสก์และโหลดเข้าสู่หน่วยความจำ ดังนั้น run จึงกำลังดาวน์โหลดข้อมูลขนาดหลายกิกะไบต์ก่อนที่จะแสดงผลลัพธ์ใดๆ ให้คุณเห็น

มีสองปัจจัยที่ทำให้การทำงานนี้ไม่แสดงผล Ollama จะวาดแถบความคืบหน้าเฉพาะเมื่อเอาต์พุตเป็นเทอร์มินัลเท่านั้น ดังนั้นการใช้ run ภายในเชลล์สคริปต์, cron job, ขั้นตอน CI หรือการรัน ssh host ollama run ... แบบปกติ จะไม่แสดงผลใดๆ ในระหว่างการดาวน์โหลด จากนั้นเมื่อดาวน์โหลดข้อมูลเสร็จสิ้น ไฟล์ยังคงต้องถูกอ่านจากดิสก์เข้าสู่ RAM ก่อนที่จะสร้างโทเค็นแรก ซึ่งบน VPS ขนาดเล็ก การอ่านข้อมูลนี้จะใช้เวลานาน หากเซิร์ฟเวอร์มีหน่วยความจำไม่เพียงพอสำหรับโมเดล เคอร์เนลจะเริ่มทำ swapping และระยะเวลารอคอยจะนานขึ้นมาก

ให้ตรวจสอบจากเซสชันที่สองแทนการคาดเดา:

df -h /
watch -n5 df -h /

หากพื้นที่ว่างลดลงเป็นระยะ แสดงว่าการดาวน์โหลดกำลังดำเนินอยู่ หากพื้นที่ว่างหยุดลดลงในขณะที่คำสั่งยังคงทำงานอยู่ แสดงว่าการดาวน์โหลดเสร็จสิ้นและกำลังเริ่มโหลดเข้าสู่หน่วยความจำ

นี่คือเหตุผลว่าทำไมจึงควรดึงโมเดลมาไว้ล่วงหน้า ผู้ที่พิมพ์คำสั่ง ollama run ไม่ควรเป็นผู้ที่ต้องรอการดาวน์โหลดในขณะนั้น

ดึงโมเดลมาไว้ก่อนที่จะมีใครเรียกใช้งาน

บนเซิร์ฟเวอร์เครื่องใหม่ ให้ดึงสคริปต์ตัวเดียวกับที่ใช้ติดตั้งเซิร์ฟเวอร์มาใช้งาน:

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

หากคุณกำลังตั้งค่าเซิร์ฟเวอร์เป็นครั้งแรก การติดตั้ง Ollama บน VPS แบบเต็มรูปแบบ จะครอบคลุมถึงตัวบริการและสิทธิ์ในการเข้าถึง หลังจากนั้น สิ่งที่ควรตั้งค่าคือการดึงโมเดลที่ทำงานแยกจาก terminal ของคุณ เพราะหากการดาวน์โหลดถูกตัดกลางคัน จะทำให้โมเดลในคลังข้อมูลไม่สมบูรณ์

ให้รันคำสั่งภายใน tmux หรือกำหนดให้เป็น one-shot unit ใน systemd เพื่อให้ทำงานตอนบูตเครื่อง ให้เขียนไฟล์ /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

คำสั่งทั้งสองรันผ่าน /bin/sh -c โดยเจตนา การใช้ ExecStart= โดยตรงจำเป็นต้องระบุ absolute path และตัวติดตั้งไม่ได้วาง binary ไว้ในไดเรกทอรีเดียวกันเสมอไป ดังนั้นการใช้ command -v ollama บนเครื่องของคุณเองจึงเป็นวิธีเดียวที่เชื่อถือได้ การรันผ่าน shell จะใช้ PATH ของบริการแทนการใช้ path ที่คัดลอกมาจากคู่มือ คำสั่ง ExecStart แรกก็มีความสำคัญเช่นกัน: After=ollama.service หมายความว่า unit ของเซิร์ฟเวอร์ถูกสั่งให้เริ่มทำงานแล้ว แต่ไม่ได้หมายความว่าพร้อมใช้งาน ดังนั้นลูปนี้จึงรอจนกว่า ollama list จะตอบสนองก่อนที่การดึงโมเดลจะเริ่มขึ้น

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

ใน journal ควรแสดงผลว่าการดึงโมเดลเสร็จสิ้นโดยไม่มีข้อผิดพลาด และ ollama list ควรแสดงรายการโมเดลนั้น หากต้องการให้ tag ที่มีการอัปเดตอยู่เสมอเป็นปัจจุบัน ให้เพิ่ม systemd timer หรือ cron entry รายสัปดาห์ที่รันคำสั่งดึงโมเดลเดิม การดึง tag เดิมซ้ำในขณะที่มีการอัปเดตเวอร์ชันใหม่ จะเป็นการดาวน์โหลดเฉพาะ layer ใหม่ และทิ้ง layer เก่าที่ไม่มีการอ้างอิงไว้ ซึ่งจะถูกล้างออกในครั้งถัดไปที่เซิร์ฟเวอร์เริ่มทำงาน

เกิดอะไรขึ้นเมื่อการดึงข้อมูลถูกขัดจังหวะ

เลเยอร์ทุกเลเยอร์ของโมเดลจะถูกจัดเก็บภายใต้ค่าแฮชของเนื้อหาในตัวมันเอง ดังนั้นการดึงข้อมูลที่ถูกขัดจังหวะจึงไม่ใช่การทำงานที่สูญเปล่า หากคุณรันคำสั่ง ollama pull เดิมอีกครั้ง เลเยอร์ที่ดาวน์โหลดเสร็จสิ้นแล้วจะถูกตรวจพบและข้ามไป ทำให้การดาวน์โหลดดำเนินต่อจากเลเยอร์ที่ค้างอยู่ได้ทันที

มีหนึ่งการกระทำที่ทำลายความคืบหน้านี้ เมื่อเซิร์ฟเวอร์ Ollama เริ่มทำงาน มันจะลบเลเยอร์ที่จัดเก็บไว้ซึ่งไม่มี manifest ของโมเดลใดอ้างอิงถึง และเลเยอร์บางส่วนที่ค้างอยู่จากการดึงข้อมูลที่ล้มเหลวก็ถือเป็นเลเยอร์ประเภทนั้น ดังนั้นการรีสตาร์ทเซอร์วิสก่อนที่คุณจะลองใหม่จะเป็นการทิ้งส่วนที่คุณดาวน์โหลดมาแล้วไป ให้ลองดึงข้อมูลใหม่ก่อนแล้วค่อยรีสตาร์ทในภายหลัง หากจำเป็นต้องเก็บไฟล์ดาวน์โหลดบางส่วนไว้หลังการรีสตาร์ทจริงๆ ให้ตั้งค่า OLLAMA_NOPRUNE=1 ในสภาพแวดล้อมของเซอร์วิส จากนั้นค่อยนำออก เนื่องจากกระบวนการล้างข้อมูลตอนเริ่มต้นคือสิ่งที่ป้องกันไม่ให้เลเยอร์ที่ไม่มีเจ้าของสะสมอยู่บนดิสก์

หากการดึงข้อมูลล้มเหลวด้วยข้อผิดพลาด no space left on device ให้เพิ่มพื้นที่ว่างก่อนลองใหม่ หาก df รายงานว่าดิสก์เต็มแต่คำสั่ง du ในไดเรกทอรีโมเดลไม่แสดงผลว่ามีการใช้พื้นที่ไปมากขนาดนั้น แสดงว่าพื้นที่ถูกใช้ไปที่อื่น และการอ่าน สาเหตุที่ df และ du แสดงค่าไม่ตรงกัน เป็นสิ่งที่ควรทำก่อนที่คุณจะลบไฟล์ใดๆ

Ollama จัดเก็บโมเดลไว้ที่ไหนบน VPS

ให้ตรวจสอบจากเซิร์ฟเวอร์ของคุณเองแทนที่จะเชื่อเส้นทางจากคู่มือใดๆ รวมถึงคู่มือนี้ด้วย ตำแหน่งที่จัดเก็บจะแตกต่างกันระหว่างการติดตั้งแบบแพ็กเกจและแบบคอนเทนเนอร์ และจะเปลี่ยนไปอีกหากมีการตั้งค่า OLLAMA_MODELS ไว้

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

systemctl cat จะแสดงไฟล์ unit พร้อมกับไฟล์ drop-in ทั้งหมด ดังนั้นบรรทัด OLLAMA_MODELS ที่คุณตั้งค่าไว้หรือที่ถูกกำหนดมาในอิมเมจจะปรากฏขึ้นที่นั่น หากไม่มีบรรทัดดังกล่าว ตำแหน่งจัดเก็บจะอยู่ที่ไดเรกทอรี home ของบัญชีผู้ใช้ที่รันเซอร์วิสอยู่ และ getent passwd จะแสดงไดเรกทอรี home นั้นในฟิลด์ที่หกที่คั่นด้วยเครื่องหมายทวิภาค ส่วน find จะค้นหาในระบบไฟล์เพื่อหาไดเรกทอรี blobs ซึ่งเป็นที่ที่เลเยอร์ต่างๆ ถูกเขียนลงไปจริง ให้ละเว้น -xdev หากโมเดลอาจถูกจัดเก็บไว้ใน mount point แยกต่างหากอยู่แล้ว

ตอนนี้ให้วัดขนาดและอ่านค่าจากระบบของคุณเอง:

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

ที่จัดเก็บมีสองส่วน manifests เก็บไฟล์ขนาดเล็กหนึ่งไฟล์ต่อหนึ่ง model tag โดยไฟล์นั้นจะระบุรายการเลเยอร์ที่ tag นั้นสร้างขึ้น ส่วน blobs เก็บตัวเลเยอร์เอง โดยแต่ละไฟล์จะตั้งชื่อตาม hash ของเนื้อหา และขนาดส่วนใหญ่ของพื้นที่จัดเก็บจะอยู่ที่นี่ เนื่องจากเลเยอร์ถูกแชร์ระหว่าง tag ต่างๆ โมเดลสองตัวที่สร้างบน weight ชุดเดียวกันจะรายงานขนาดของตัวเองใน ollama list ทั้งที่ใช้พื้นที่บนดิสก์เพียงครั้งเดียว ดังนั้นขนาดที่แสดงรวมกันอาจมากกว่าที่ du รายงานสำหรับไดเรกทอรีนั้น

ไฟล์โมเดลจะทำให้ระบบไฟล์ root ของ VPS ขนาดเล็กเต็มเร็วกว่าสิ่งอื่นใดที่คุณน่าจะติดตั้ง และปัจจัยที่ส่งผลต่อขนาดมากที่สุดคือรูปแบบของ weight การเลือกระหว่าง q4, q8 และ fp16 สามารถประหยัดพื้นที่ได้หลายกิกะไบต์ต่อหนึ่งโมเดล

ย้ายโมเดลไปยัง data volume ด้วย OLLAMA_MODELS

หากแผนการใช้งานมีดิสก์ลูกที่สองหรือ data volume ที่มีขนาดใหญ่กว่า ให้ย้ายที่เก็บข้อมูลก่อนที่ root filesystem จะเต็ม ให้หยุดการทำงานของเซิร์ฟเวอร์ก่อน เพื่อป้องกันการคัดลอกไฟล์ที่ยังมีการเขียนข้อมูลอยู่

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 จะเปิดตัวแก้ไขไฟล์สำหรับ drop-in file เพื่อให้ unit ที่มากับแพ็กเกจไม่ถูกแก้ไข และการอัปเกรดแพ็กเกจจะไม่เขียนทับการตั้งค่าของคุณ ให้เพิ่มสองบรรทัดนี้ลงไป:

[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 ควรแสดง path ใหม่ของคุณ และ ollama list ควรแสดงโมเดลชุดเดิมที่เคยเห็นก่อนการย้าย หากรายการว่างเปล่าแสดงว่าเซิร์ฟเวอร์ไม่สามารถอ่านไดเรกทอรีใหม่ได้ บริการนี้ทำงานในฐานะผู้ใช้ ollama ดังนั้นผู้ใช้ดังกล่าวจึงจำเป็นต้องมีสิทธิ์อ่านและเขียนในปลายทาง ซึ่งเป็นหน้าที่ของบรรทัด chown ด้านบน ให้ตรวจสอบ journalctl -e -u ollama เพื่อดูข้อผิดพลาดด้านสิทธิ์ที่ระบุถึง path ใหม่ ลบไฟล์ต้นฉบับทิ้งก็ต่อเมื่อรายการแสดงผลถูกต้องแล้วเท่านั้น เพราะหากการย้ายล้มเหลวและคุณลบต้นฉบับไปแล้ว คุณจะต้องดาวน์โหลดทุกอย่างใหม่อีกครั้ง

อีกทางเลือกหนึ่งคือการคง path เดิมไว้แล้ว mount data volume ทับลงไป:

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 หากคำสั่งแสดงผลการ mount แสดงว่าการทำ bind mount ใช้งานได้จริง การทำ bind mount มีประโยชน์ในกรณีที่ซอฟต์แวร์อื่นบนเครื่องคาดหวังว่าจะพบข้อมูลในตำแหน่งเริ่มต้นอยู่แล้ว แต่มีข้อควรระวังคือ ไฟล์ที่คุณคัดลอกออกมาจะยังคงค้างอยู่ใต้จุด mount บน root disk โดยถูก mount บังไว้ ทำให้พื้นที่ดิสก์ยังไม่ถูกคืนค่าจนกว่าคุณจะ unmount และลบไฟล์เหล่านั้นออก การใช้ environment variable เป็นวิธีที่อธิบายให้ผู้ดูแลระบบคนถัดไปเข้าใจได้ง่ายกว่า

ตำแหน่งที่คอนเทนเนอร์จัดเก็บไฟล์เหล่านี้

อิมเมจมาตรฐานจะจัดเก็บโมเดลไว้ในตำแหน่งที่คุณ mount ไว้ ไม่ใช่ในไดเรกทอรีใดๆ บนโฮสต์ที่เป็นของผู้ใช้ ollama คำสั่ง run ที่ระบุไว้ในเอกสารคือ:

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

ollama ที่อยู่หน้าเครื่องหมายทวิภาคคือชื่อของ Docker volume และ /root/.ollama คือตำแหน่งที่เซิร์ฟเวอร์เขียนข้อมูลไว้ภายในคอนเทนเนอร์ ดังนั้นการใช้ du ตรวจสอบพาธจากส่วนก่อนหน้าจึงไม่พบข้อมูลใดๆ เนื่องจากไม่มีไฟล์อยู่ที่นั่น ให้แสดงตำแหน่งและขนาดจริงด้วยคำสั่ง:

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

อ่านค่าจากฟิลด์ Mountpoint ใน docker volume inspect จากนั้นรันคำสั่ง sudo du -sh เพื่อตรวจสอบ หากต้องการเก็บโมเดลไว้บน data volume ให้แทนที่ชื่อ volume ด้วยไดเรกทอรีบนโฮสต์ (-v /mnt/data/ollama:/root/.ollama) แล้วสร้างคอนเทนเนอร์ขึ้นใหม่ คอนเทนเนอร์จะเขียนไฟล์ในฐานะ root ดังนั้นไดเรกทอรีบนโฮสต์นั้นจะมี root เป็นเจ้าของ ในกรณีของ rootless Podman ไอดีจะถูกแมปไปยังช่วง subuid ของผู้ใช้แทน ทำให้ความเป็นเจ้าของบนโฮสต์แสดงผลต่างออกไป: การรัน Ollama ภายใต้ rootless Podman อธิบายรายละเอียดเกี่ยวกับการแมปนี้ไว้

คำเตือนเกี่ยวกับการล้างข้อมูล: docker volume prune จะลบทุก volume ที่ไม่มีคอนเทนเนอร์ใดอ้างอิงถึง หากคุณลบหรือสร้างคอนเทนเนอร์ ollama ใหม่โดยไม่รวม volume เดิมไว้ การรันคำสั่ง prune ในภายหลังจะลบโมเดลทั้งหมดที่คุณดาวน์โหลดมาทิ้ง และไม่สามารถกู้คืนได้นอกจากต้องดาวน์โหลดใหม่เท่านั้น โปรดอ่าน วิธีล้างข้อมูลดิสก์ Docker บน VPS ก่อนรันคำสั่ง prune บนเครื่องที่มีการโฮสต์โมเดลไว้

การลบโมเดลด้วย ollama rm ไม่ใช่การใช้ rm

ollama list
ollama rm gemma4
ollama list
df -h /

ollama rm จะลบ manifest ของแท็กนั้นทิ้ง จากนั้นจะลบ layer ที่ไม่มี manifest ใดๆ อ้างอิงถึงอีก พื้นที่จัดเก็บจะถูกคืนทันทีที่ไฟล์เหล่านั้นถูกยกเลิกการเชื่อมโยง ดังนั้น df จึงได้พื้นที่คืนในทันที เนื่องจากมีการแชร์ layer ร่วมกัน การลบหนึ่งในสองแท็กที่เกี่ยวข้องกันอย่างใกล้ชิดอาจทำให้ได้พื้นที่คืนน้อยกว่าขนาดที่ ollama list แสดงไว้ข้างชื่อโมเดล ซึ่งถือเป็นการทำงานที่ถูกต้อง ไม่ใช่การลบที่ล้มเหลว

การลบไฟล์ด้วยมือจะทำให้ระบบเสียหาย การลบ blob ด้วย rm จะทำให้ manifest ยังคงระบุถึงไฟล์นั้นอยู่ ส่งผลให้ ollama list ยังคงแสดงโมเดลดังกล่าว และทุกความพยายามในการใช้งานจะล้มเหลวเมื่อระบบอ่านเจอ layer ที่หายไป ในทางกลับกัน การลบ manifest ด้วยมือจะทำให้ layer ยังคงค้างอยู่ในดิสก์โดยไม่มีสิ่งใดอ้างอิงถึง ซึ่งเป็นการจองพื้นที่ที่ไม่มีคำสั่งใดของ Ollama รายงานให้คุณทราบ หากคุณได้ดำเนินการไปแล้ว การใช้ ollama rm กับแท็กนั้นจะช่วยล้างรายการที่ตกค้างออกไป และการรีสตาร์ทเซิร์ฟเวอร์จะช่วยล้าง layer ที่ไม่มีการอ้างอิงถึงออกไป

ข้อแตกต่างประการสุดท้าย เนื่องจากทั้งสองคำสั่งมักถูกสับสนกันบ่อยครั้ง ollama rm เกี่ยวข้องกับพื้นที่ดิสก์ ส่วน ollama stop gemma4 เป็นการนำโมเดลออกจากหน่วยความจำและไม่ได้คืนพื้นที่ดิสก์แต่อย่างใด ระยะเวลาที่โมเดลจะคงอยู่ใน RAM หลังจากโหลดเสร็จสิ้นนั้นเป็นการตั้งค่าแยกต่างหาก ซึ่งเนื้อหา การคงโมเดลไว้ในหน่วยความจำแทนการโหลดใหม่ทุกครั้งที่ร้องขอ ได้อธิบายไว้แล้ว

FAQ

ollama pull และ ollama run แตกต่างกันอย่างไร?

ollama pull จะดาวน์โหลดโมเดลลงดิสก์แล้วจบการทำงาน ส่วน ollama run จะตรวจสอบว่าโมเดลอยู่ในดิสก์แล้วหรือไม่ หากยังไม่มีจะทำการดาวน์โหลด จากนั้นจะโหลดโมเดลเข้าหน่วยความจำและเปิดเซสชันแชทโต้ตอบ ทั้งสองคำสั่งจะเขียนไฟล์ลงในไดเรกทอรีเดียวกัน ให้ใช้ pull ในการจัดเตรียมระบบและในสคริปต์ และใช้ run เมื่อมีการใช้งานผ่านคีย์บอร์ดโดยผู้ใช้ ollama run <model> "your prompt" จะส่งพรอมต์เดียวแล้วจบการทำงาน ซึ่งเป็นรูปแบบที่ใช้ในสคริปต์ของ run

ทำไมการรัน ollama run ครั้งแรกถึงดูเหมือนค้าง?

ระบบกำลังดาวน์โหลดโมเดลอยู่ พรอมต์แชทจะไม่ปรากฏจนกว่าโมเดลจะถูกดาวน์โหลดลงดิสก์และโหลดเข้าหน่วยความจำเสร็จสมบูรณ์ ซึ่งโมเดลมีขนาดหลายกิกะไบต์ Ollama จะแสดงแถบความคืบหน้าเฉพาะเมื่อผลลัพธ์ถูกส่งไปยังเทอร์มินัลเท่านั้น ดังนั้นการใช้ run ภายในสคริปต์, cron job หรือ ssh host ollama run ... จะไม่แสดงผลใดๆ ในขณะที่ระบบกำลังทำงาน ให้เปิดเซสชันที่สองแล้วรัน watch -n5 df -h / หากพื้นที่ว่างลดลงเป็นระยะ แสดงว่าการดาวน์โหลดกำลังดำเนินอยู่ การดาวน์โหลดโมเดลไว้ล่วงหน้าจะช่วยลดเวลารอคอยนี้ได้

Ollama จัดเก็บโมเดลไว้ที่ไหน?

ตำแหน่งที่จัดเก็บขึ้นอยู่กับการติดตั้ง ดังนั้นควรตรวจสอบผ่านคำสั่งแทนการคาดเดา ให้รัน systemctl cat ollama.service เพื่อดูว่ามีการตั้งค่า OLLAMA_MODELS ไว้ใน unit หรือ drop-in หรือไม่ หากไม่มีการตั้งค่า โมเดลจะถูกเก็บไว้ภายใต้โฮมไดเรกทอรีของบัญชีผู้ใช้ที่รันเซอร์วิส ซึ่งสามารถตรวจสอบได้ด้วย getent passwd ollama ส่วน sudo find / -xdev -type d -name blobs 2>/dev/null จะระบุตำแหน่งไดเรกทอรี layer โดยตรง สำหรับ container image พื้นที่จัดเก็บจะอยู่ภายใน volume ที่ mount ไว้ และ docker volume inspect ollama จะแสดง Mountpoint บนโฮสต์

ฉันจะย้ายโมเดลของ Ollama ไปยังดิสก์อื่นได้อย่างไร?

หยุดการทำงานของเซอร์วิส คัดลอกที่จัดเก็บไปยังตำแหน่งใหม่ด้วย rsync -a กำหนดสิทธิ์ไดเรกทอรีให้บัญชีผู้ใช้ของเซอร์วิสด้วย sudo chown -R ollama:ollama <directory> จากนั้นรัน sudo systemctl edit ollama.service และเพิ่ม Environment="OLLAMA_MODELS=<directory>" ไว้ใต้บรรทัด [Service] ทำการโหลดการตั้งค่าใหม่ด้วย sudo systemctl daemon-reload แล้วรีสตาร์ทเซอร์วิส ตรวจสอบความถูกต้องด้วย systemctl show ollama --property=Environment และ ollama list หากรายการว่างเปล่า มักหมายความว่าผู้ใช้ ollama ไม่สามารถอ่านไดเรกทอรีใหม่ได้ โดย journalctl -e -u ollama จะแสดงพาธที่ใช้งานอยู่

การลบไฟล์โมเดลทิ้งจะช่วยคืนพื้นที่ว่างหรือไม่?

การลบไฟล์ด้วยตนเองจะคืนพื้นที่ว่าง แต่จะทำให้ที่จัดเก็บข้อมูลไม่สอดคล้องกัน หากลบ blob ออกไปแต่ manifest ยังคงระบุถึงโมเดลนั้นอยู่ โมเดลจะยังคงปรากฏใน ollama list และจะเกิดข้อผิดพลาดเมื่อเรียกใช้งาน หากลบ manifest ออกไปแต่ layer ของมันยังคงค้างอยู่ในดิสก์โดยไม่มีสิ่งใดอ้างอิงถึง ให้ใช้ ollama rm <model> ซึ่งจะลบ manifest และลบ layer ที่ไม่มีโมเดลอื่นใช้งานออก หากลบไฟล์ด้วยตนเองไปแล้ว ให้รัน ollama rm บนแท็กนั้นเพื่อล้างรายการออก จากนั้นรีสตาร์ทเซิร์ฟเวอร์เพื่อลบ layer ที่ไม่มี manifest ใดๆ อ้างอิงถึงออกไป