ความแตกต่าง 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 เพื่อออกจากเซสชันนั้น บรรทัดที่สามจะส่งคำสั่ง (prompt) เพียงชุดเดียว พิมพ์คำตอบออกมา แล้วจบการทำงาน ซึ่งเป็นรูปแบบที่สคริปต์ต้องการเมื่อต้องการเพียงคำตอบแทนที่จะเปิดเซสชันค้างไว้ รูปแบบที่สามนี้ยังคงปล่อยให้ความยาวของคำตอบขึ้นอยู่กับโมเดลทั้งหมด ดังนั้นคำถามบรรทัดเดียวอาจได้คำตอบกลับมาเป็นสามย่อหน้า และการ จำกัดคำตอบด้วย num_predict คือสิ่งที่ช่วยควบคุมให้ run ในสคริปต์มีขนาดที่ผู้เรียกใช้งานสามารถนำไปใช้ต่อได้จริง ชื่อโมเดลมีการเปลี่ยนแปลงอยู่ตลอดเวลา ดังนั้นให้ถือว่า gemma4 ในที่นี้เป็นเพียงตัวอย่างที่ใช้ในเอกสารอย่างเป็นทางการของ Ollama ณ เดือนสิงหาคม 2026 โดย tag ใดๆ จาก library จะมีพฤติกรรมเหมือนกัน หากคุณต้องการแทนที่ด้วยโมเดลที่มีการประเมินขนาดไว้แล้วสำหรับเซิร์ฟเวอร์จริง การรัน Nemotron 3.5 Lightning บน VPS ได้ระบุ tag ที่แน่นอนสำหรับการ pull และปริมาณหน่วยความจำที่โมเดลต้องการไว้ให้แล้ว

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

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

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

ให้ตรวจสอบการทำงานจากอีก session หนึ่งแทนการคาดเดา:

df -h /
watch -n5 df -h /

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

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

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

หลักการเดียวกันนี้ใช้กับทุกสิ่งที่ไม่ได้เป็นมนุษย์ โดย coding agent ที่ชี้ไปยัง Ollama endpoint ของคุณ มักจะยอมแพ้ตั้งแต่คำขอแรก แทนที่จะรอการดาวน์โหลดขนาดหลายกิกะไบต์ให้เสร็จสิ้น บนเครื่องใหม่ ให้ดึงโมเดลผ่านสคริปต์เดียวกับที่ใช้ติดตั้งเซิร์ฟเวอร์:

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

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

ให้รันคำสั่งภายใน tmux หรือส่งให้ systemd เป็น one-shot unit ที่ทำงานตอนบูตเครื่อง ให้เขียนไฟล์ /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 ของ service แทนการคัดลอก 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 เก่าที่ไม่มีการอ้างอิงไว้ ซึ่ง layer เหล่านั้นจะถูกล้างออกในครั้งถัดไปที่เซิร์ฟเวอร์เริ่มทำงาน

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

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

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

หากการดึงข้อมูลล้มเหลวด้วย 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 นั้นในฟิลด์ที่ 6 ที่คั่นด้วยเครื่องหมายทวิภาค ส่วน 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 เก็บไฟล์ขนาดเล็กหนึ่งไฟล์ต่อหนึ่งแท็กของโมเดล โดยไฟล์นั้นจะระบุรายการเลเยอร์ที่ประกอบขึ้นเป็นแท็กดังกล่าว ส่วน blobs จะเก็บตัวเลเยอร์เอง โดยแต่ละไฟล์จะถูกตั้งชื่อตามค่า hash ของเนื้อหา และขนาดส่วนใหญ่จะอยู่ที่นี่ เนื่องจากเลเยอร์ถูกแชร์ระหว่างแท็ก โมเดลสองตัวที่สร้างจากน้ำหนัก (weights) เดียวกันจึงรายงานขนาดของตัวเองใน ollama list ทั้งที่ใช้พื้นที่บนดิสก์เพียงครั้งเดียว ดังนั้นขนาดที่แสดงรวมกันอาจมากกว่าที่ du รายงานสำหรับไดเรกทอรีนั้น

ไฟล์โมเดลจะทำให้ระบบไฟล์ root ของ VPS ขนาดเล็กเต็มเร็วกว่าสิ่งอื่นใดที่คุณน่าจะติดตั้ง และปัจจัยที่ส่งผลต่อขนาดมากที่สุดคือรูปแบบของน้ำหนัก (weight format) การ เลือกใช้ระหว่าง 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 เพื่อให้ 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 ที่อยู่หน้าเครื่องหมาย colon คือชื่อ Docker volume และ /root/.ollama คือตำแหน่งที่เซิร์ฟเวอร์เขียนข้อมูลไว้ภายในคอนเทนเนอร์ ดังนั้นการใช้ du ตรวจสอบ path จากส่วนก่อนหน้าจึงไม่พบข้อมูลใดๆ เนื่องจากไม่มีไฟล์อยู่ที่นั่น ให้แสดงตำแหน่งและขนาดจริงด้วยคำสั่ง:

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

อ่านค่าจากฟิลด์ Mountpoint ใน docker volume inspect จากนั้นรัน sudo du -sh เพื่อตรวจสอบ หากต้องการเก็บโมเดลไว้บน data volume ให้แทนที่ named volume ด้วยไดเรกทอรีบนโฮสต์ (-v /mnt/data/ollama:/root/.ollama) แล้วสร้างคอนเทนเนอร์ขึ้นใหม่ คอนเทนเนอร์จะเขียนข้อมูลในฐานะ root ดังนั้นไดเรกทอรีบนโฮสต์นั้นจะมี root เป็นเจ้าของ สำหรับกรณี rootless Podman ค่า ID จะถูกแมปไปยังช่วง 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 ในขั้นตอนการเตรียมระบบ (provisioning) และในสคริปต์ ส่วน run ให้ใช้เมื่อมีผู้ใช้งานพิมพ์ผ่านคีย์บอร์ดโดยตรง ollama run <model> "your prompt" จะส่ง prompt หนึ่งรายการแล้วจบการทำงาน ซึ่งเป็นรูปแบบที่ใช้ในสคริปต์ของ run

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

ระบบกำลังดาวน์โหลดโมเดลอยู่ prompt สำหรับแชทจะไม่ปรากฏจนกว่าโมเดลจะถูกดาวน์โหลดลงดิสก์และโหลดเข้าหน่วยความจำเสร็จสิ้น ซึ่งโมเดลมีขนาดหลายกิกะไบต์ 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 ตามด้วยชื่อ tag เพื่อล้างรายการออก จากนั้นรีสตาร์ทเซิร์ฟเวอร์ ระบบจะลบ layer ที่ไม่มี manifest ใดอ้างอิงถึงออกไปให้เอง