วิธีตั้งค่า Ollama ให้คงโมเดลไว้ใน RAM ตลอดเวลา

เหตุใด Ollama จึงยกเลิกการโหลดโมเดลหลังจากผ่านไปไม่กี่นาที

Ollama จะคงโมเดลไว้ในหน่วยความจำเป็นเวลา 5 นาทีหลังจากคำขอสุดท้าย จากนั้นจึงจะปลดปล่อยหน่วยความจำดังกล่าว คำขอถัดไปจะต้องอ่านค่าน้ำหนัก (weights) จากดิสก์และแมปเข้าสู่ RAM หรือ VRAM อีกครั้ง ทำให้เกิดการหน่วงเวลาก่อนที่โทเค็นแรกจะปรากฏขึ้น นี่คือเหตุผลที่ UI แชทหรือ coding agent ดูเหมือนจะทำงานได้รวดเร็ว จากนั้นเงียบไปสักพัก และกลับมาทำงานช้าอีกครั้งในข้อความถัดไป ไม่ได้มีส่วนใดเสียหาย แต่เป็นเพราะตัวจับเวลาสถานะว่าง (idle timer) หมดเวลาลง

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

มีสองตำแหน่งที่สามารถตั้งค่า keep_alive ได้ คือตั้งค่าที่คำขอแต่ละรายการ หรือตั้งค่าเป็นค่าเริ่มต้นของเซิร์ฟเวอร์ การใช้ systemd drop-in จะช่วยให้ค่าเริ่มต้นของเซิร์ฟเวอร์คงอยู่แม้จะมีการรีสตาร์ท คู่มือนี้สมมติว่า Ollama ทำงานเป็น service อยู่แล้ว หากยังไม่ได้ดำเนินการ ให้เริ่มจาก การติดตั้ง Ollama บน VPS แล้วจึงกลับมาดำเนินการต่อ

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

ollama ps

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

หากผลลัพธ์ว่างเปล่า หมายความว่าไม่มีโมเดลใดถูกโหลดไว้ ดังนั้นคำขอถัดไปจะต้องเสียเวลาโหลดใหม่ทั้งหมด PROCESSOR จะระบุตำแหน่งที่เก็บน้ำหนักของโมเดลไว้ ส่วน 100% GPU และ 100% CPU เป็นกรณีที่ชัดเจน การแบ่งส่วนโมเดลเช่น 25%/75% CPU/GPU หมายความว่าโมเดลไม่สามารถบรรจุลงใน VRAM ได้ทั้งหมด จึงต้องมีบางส่วนทำงานบนโปรเซสเซอร์ ซึ่งจะทำให้การสร้างผลลัพธ์ช้าลง

UNTIL คือการนับถอยหลัง โดยจะแสดงเวลาแบบสัมพัทธ์ เช่น 4 minutes from now ระบบจะแสดง Forever เมื่อโมเดลถูกโหลดด้วยค่า keep_alive ที่เป็นลบ และจะแสดง Stopping... ในช่วงเวลาสั้นๆ ขณะที่เซิร์ฟเวอร์กำลังยกเลิกการโหลดโมเดล

ชุดคอลัมน์มีการเปลี่ยนแปลงระหว่างเวอร์ชันที่ปล่อยออกมา ดังนั้นโปรดอ่านส่วนหัวแทนการนับลำดับฟิลด์ในสคริปต์ สำหรับงานอัตโนมัติใดๆ ให้สอบถามผ่าน API แทน:

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

แต่ละรายการจะประกอบด้วย expires_at, การประทับเวลาแบบสัมบูรณ์ เช่น 2026-08-09T14:38:31.83753Z และ size_vram ซึ่งเป็นส่วนของโมเดลนั้นที่อยู่ในหน่วยความจำ GPU หากค่า size_vram เป็น 0 หมายความว่าโมเดลกำลังทำงานอยู่บน CPU

ต้นทุนที่แท้จริงของการโหลดซ้ำ

อย่าคาดเดาด้วยตัวเอง Ollama จะรายงานเวลาที่ใช้ในการโหลดไว้ในทุกการตอบกลับในรูปแบบ load_duration โดยมีหน่วยเป็นนาโนวินาที

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}'

การเรียกใช้งานครั้งแรกจะเป็นการโหลดโมเดล ดังนั้นค่า load_duration จึงมีจำนวนมาก ให้หารด้วย 1000000000 เพื่ออ่านค่าเป็นวินาที การเรียกใช้งานครั้งที่สองจะเกิดขึ้นในขณะที่โมเดลยังคงอยู่ในหน่วยความจำ ซึ่งจะรายงานตัวเลขที่น้อยกว่ามาก ช่องว่างระหว่างตัวเลขทั้งสองค่านี้คือสิ่งที่ผู้ใช้ทุกคนต้องรอหลังจากตัวจับเวลาหมดลง และเป็นเหตุผลทั้งหมดในการปรับเปลี่ยน keep_alive ช่องว่างส่วนใหญ่เกิดจากการอ่านข้อมูลจากดิสก์ ดังนั้นหากคุณได้ ย้ายไดเรกทอรีโมเดลไปยัง volume ที่สอง ความเร็วของ volume นั้นจะเป็นตัวกำหนดขีดจำกัดต่ำสุดของการโหลดแบบ cold load ในทุกครั้ง สำหรับความเร็วในการสร้างข้อความในช่วงเวลาที่เหลือจากการหยุดชั่วคราวดังกล่าว โปรดดู วิธีการวัดจำนวนโทเค็นต่อวินาทีบนเครื่องของคุณเอง

การคงโมเดล Ollama ไว้ในหน่วยความจำตามคำขอ

ส่ง keep_alive ไปพร้อมกับคำขอ ค่านี้จะมีผลกับโมเดลนั้นทันทีหลังจากคำขอเสร็จสิ้น

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

รองรับรูปแบบค่า 4 ประเภท:

• สตริงระบุระยะเวลา: "30m", "24h", "90s"
• ตัวเลขปกติ ซึ่งจะถูกอ่านเป็นวินาที: 3600
• ค่าติดลบ -1 หรือ "-1m" หมายถึงไม่มีการกำหนดเวลา timeout สำหรับสถานะว่าง (idle)
• 0 หมายถึงให้ยกเลิกการโหลด (unload) ทันทีที่คำขอนี้เสร็จสิ้น

ค่าที่ระบุในคำขอจะแทนที่ค่าเริ่มต้นของเซิร์ฟเวอร์ในทุกกรณี ซึ่งมีความสำคัญมากกว่าที่คิด: ไคลเอนต์ที่ส่ง keep_alive ของตนเองจะมีผลเหนือกว่าค่าใดๆ ที่คุณตั้งค่าไว้บนเซิร์ฟเวอร์

คุณยังสามารถโหลดโมเดลโดยไม่ต้องสร้างผลลัพธ์ใดๆ ได้ โดยส่งเพียงชื่อโมเดลเท่านั้น เซิร์ฟเวอร์จะโหลดโมเดลนั้นและส่งการตอบกลับที่ว่างเปล่าพร้อมกับ "done": true กลับมา

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

นี่คือคำสั่งที่ควรเรียกใช้หลังจากรีบูตเครื่อง หรือหลังจากดึงโมเดลใหม่ เพื่อให้คำขอจากผู้ใช้จริงครั้งแรกไม่ต้องรอเวลาในการโหลดโมเดล เครื่องมือ CLI สามารถทำงานเดียวกันนี้ได้ด้วยแฟล็ก:

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

คงสถานะโมเดลไว้ในหน่วยความจำโดยใช้ OLLAMA_KEEP_ALIVE

เซิร์ฟเวอร์จะอ่านค่า OLLAMA_KEEP_ALIVE ในขณะเริ่มต้นระบบและนำไปใช้กับทุกโมเดลที่ไม่ได้กำหนดค่าเฉพาะไว้ โดยรองรับรูปแบบเดียวกับฟิลด์ในคำขอ ดังนั้นค่าอย่าง 30m, 3600 และ -1 จึงสามารถใช้งานได้ทั้งหมด

ปัญหาสำคัญคือตัวแปรนี้ต้องอยู่ใน environment ใด การรัน export OLLAMA_KEEP_ALIVE=30m ใน SSH session ของคุณจะไม่มีผลใดๆ เนื่องจากแพ็กเกจที่ติดตั้งไว้จะรันเซิร์ฟเวอร์ในรูปแบบ systemd service ภายใต้ผู้ใช้ของระบบเองและมี environment แยกต่างหาก login shell ของคุณกับ service ดังกล่าวจึงไม่ได้ใช้ environment ร่วมกัน นี่เป็นสาเหตุที่พบบ่อยที่สุดที่ทำให้การตั้งค่านี้ดูเหมือนถูกละเลย

ทำให้บริการทำงานต่อได้หลังรีสตาร์ทด้วย systemd drop-in

sudo systemctl edit ollama.service

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

[Service]
Environment="OLLAMA_KEEP_ALIVE=30m"

การบันทึกไฟล์จะเป็นการเขียน /etc/systemd/system/ollama.service.d/override.conf ซึ่งถือเป็น drop-in แทนการแก้ไขไฟล์ unit หลักที่มากับแพ็กเกจ ดังนั้นหากมีการอัปเกรดแพ็กเกจ Ollama ที่เข้ามาแทนที่ ollama.service การตั้งค่าของคุณจะยังคงอยู่ หากคุณยังไม่คุ้นเคยกับ drop-in และไฟล์ unit สามารถศึกษาหลักการทำงานได้จาก คู่มือ systemd service และ timer

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

คำสั่งสุดท้ายจะแสดง environment ที่บริการจะใช้งานจริง หาก OLLAMA_KEEP_ALIVE=30m ไม่ปรากฏในบรรทัดดังกล่าว แสดงว่า drop-in ไม่ทำงาน ซึ่งสาเหตุส่วนใหญ่มักเกิดจากการลืมใส่หัวข้อ [Service] หรือมีการพิมพ์ข้อความไว้นอกเหนือจากตำแหน่งที่กำหนด การรีสตาร์ทบริการจะทำให้โมเดลที่โหลดค้างไว้ทั้งหมดถูกล้างออก ดังนั้นคำขอถัดไปจะเป็นการโหลดแบบ cold load คุณสามารถเตรียมความพร้อมด้วยคำสั่ง preload ที่ระบุไว้ข้างต้น

ต้นทุนของการคงโมเดลไว้ในหน่วยความจำ

คอลัมน์ SIZE ใน ollama ps คือหน่วยความจำที่ถูกจองไว้ตลอดช่วงเวลา idle window ไม่ใช่แค่ระหว่างการประมวลผลคำขอ โมเดลขนาด 8B ที่ทำ 4-bit quantisation จะใช้หน่วยความจำประมาณ 5 ถึง 6 GB ส่วนโมเดลขนาด 27B นั้นเป็นอีกเรื่องหนึ่ง และ การคำนวณหน่วยความจำสำหรับการรันบน VPS ที่มีเฉพาะ CPU เป็นสิ่งที่ควรทำความเข้าใจก่อนตัดสินใจคงโมเดลไว้ในหน่วยความจำ หากคุณตั้งค่า keep_alive เป็น -1 เท่ากับว่าคุณตัดสินใจให้โมเดลมีความสำคัญเหนือกว่าทุกอย่างบนเซิร์ฟเวอร์อย่างถาวร บน VPS ขนาดเล็ก นี่คือการแลกเปลี่ยนโดยตรงกับฐานข้อมูล เว็บแอปพลิเคชัน และงาน build ของคุณ

ให้ตรวจสอบตัวเลขจริงแทนการเชื่อค่าประมาณ ให้รันคำสั่งนี้ขณะที่โมเดลถูกโหลดอยู่ และรันอีกครั้งหลังจาก ollama stop:

free -h

คอลัมน์ available คือหน่วยความจำที่ kernel ยังสามารถจัดสรรให้กับ process ใหม่ได้ สำหรับเซิร์ฟเวอร์ที่ใช้ NVIDIA GPU คำสั่ง nvidia-smi จะแสดงข้อมูลในลักษณะเดียวกันสำหรับ VRAM หากหน่วยความจำบนเซิร์ฟเวอร์หมด kernel จะสั่งยุติ process เพื่อกู้คืนหน่วยความจำ:

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

บรรทัดที่ระบุชื่อ ollama หมายความว่า model server ตกเป็นเหยื่อ แต่หากบรรทัดระบุชื่อฐานข้อมูลของคุณ หมายความว่าโมเดลเป็นฝ่ายชนะและบริการที่คุณให้ความสำคัญกลับต้องถูกปิดไป ทั้งสองผลลัพธ์เกิดจากการตัดสินใจเดียวกัน คือการตั้งค่า keep-alive window ที่ยาวนานเกินไปบนเซิร์ฟเวอร์ที่ไม่มีทรัพยากรเหลือเฟือ

มีต้นทุนสองประการที่มักถูกมองข้าม ประการแรก ความยาว context ที่มากขึ้นจะจอง KV cache (key value cache ซึ่งเป็นสถานะ attention ต่อ token ที่โมเดลเก็บไว้ขณะสร้างข้อความ) ขนาดใหญ่ขึ้น และ cache นี้เป็นส่วนหนึ่งของขนาดหน่วยความจำที่ถูกใช้งาน ขนาดของมันขึ้นอยู่กับ num_ctx ดังนั้น การเพิ่มขนาด context window จึงเป็นการเพิ่มหน่วยความจำที่โมเดลต้องถือครองไว้ตลอดช่วงเวลา idle ไม่ใช่แค่ขณะตอบคำถามเท่านั้น การตั้งค่า OLLAMA_NUM_PARALLEL มากกว่า 1 จะเป็นการจอง cache นั้นหนึ่งชุดต่อหนึ่ง parallel slot หากคุณวางแผนจะ ให้บริการผู้ใช้หลายคนจากโมเดลเดียว ให้คำนวณขนาดหน่วยความจำสำหรับจำนวน slot ไม่ใช่แค่ขนาดของน้ำหนักโมเดลเพียงอย่างเดียว

ค่าเริ่มต้นที่เหมาะสมคือ โมเดลหนึ่งตัวบนเซิร์ฟเวอร์ที่มีทรัพยากรเหลือเฟือสามารถใช้ -1 ได้ แต่สำหรับเซิร์ฟเวอร์ที่ใช้ร่วมกับบริการอื่น ควรใช้ window ที่ครอบคลุมเฉพาะช่วงว่างระหว่างคำขอของคุณ เช่น 30m เพื่อให้หน่วยความจำถูกคืนกลับมาเมื่อคุณหยุดใช้งาน

การยกเลิกการโหลดโมเดลทันที

ollama stop qwen3:8b

คำสั่งนี้จะทำงานโดยไม่มีการแสดงผลลัพธ์ และโมเดลจะหายไปจาก ollama ps หากระบุชื่อโมเดลที่ไม่ได้โหลดไว้ ระบบจะส่งคืนค่า couldn't find model "qwen3:8b" to stop รูปแบบการเรียกใช้ API คือการส่งคำขอโดยไม่มี prompt และตั้งค่า keep_alive เป็น 0:

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

การตอบกลับจะมีค่า "done_reason": "unload" ให้ใช้วิธีนี้แทนการรีสตาร์ทเซอร์วิส แม้ว่า systemctl restart ollama จะช่วยคืนหน่วยความจำได้เช่นกัน แต่คำสั่งนั้นจะลบโมเดลอื่นทั้งหมดที่โหลดอยู่และตัดการเชื่อมต่อคำขอที่กำลังทำงานอยู่ทั้งหมดด้วย

การรันโมเดลมากกว่าหนึ่งตัวบนเซิร์ฟเวอร์เดียว

OLLAMA_MAX_LOADED_MODELS จะจำกัดจำนวนโมเดลที่โหลดค้างไว้ในหน่วยความจำพร้อมกัน โดย ณ เดือนสิงหาคม 2026 ค่าเริ่มต้นคือ 3 ตัวต่อ GPU หรือ 3 ตัวสำหรับเครื่องที่ใช้ CPU เพียงอย่างเดียว ขีดจำกัดนี้จะนับจำนวนโมเดล แต่หน่วยความจำคือข้อจำกัดที่แท้จริง ดังนั้นโมเดลขนาดใหญ่ตัวที่สองอาจถูกปฏิเสธการโหลดก่อนที่คุณจะถึงขีดจำกัด 3 ตัว

เมื่อมีการเรียกใช้โมเดลใหม่และหน่วยความจำไม่เพียงพอ ตัวจัดตารางเวลา (scheduler) จะยกเลิกการโหลดโมเดลที่ค้างอยู่ในหน่วยความจำออกเพื่อเพิ่มพื้นที่ โดยจะเลือกโมเดลที่ไม่มีคำขอใช้งานอยู่ และจะนำโมเดลที่ตัวจับเวลายังไม่หมดอายุออกด้วย รวมถึงโมเดลที่โหลดด้วย -1 ดังนั้นค่า keep_alive ที่เป็นลบจึงหมายถึงไม่มีการกำหนดเวลาหมดอายุสำหรับสถานะว่าง (idle timeout) ซึ่งจะไม่เป็นการตรึงน้ำหนัก (weights) ของโมเดลไว้เพื่อป้องกันการถูกแทนที่โดยคำขอของโมเดลอื่น

การตัดสินใจดังกล่าวจะถูกบันทึกไว้ในระดับ debug ให้เพิ่มบรรทัด Environment="OLLAMA_DEBUG=1" บรรทัดที่สองลงในไฟล์ drop-in เดียวกัน จากนั้นรีสตาร์ทและตรวจสอบดังนี้:

sudo journalctl -u ollama -f

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

คำแนะนำที่ใช้งานได้ยาวนานกว่ารุ่นถัดไป

Ollama มีการออกรุ่นใหม่บ่อยครั้งและค่าเริ่มต้นมีการเปลี่ยนแปลงอยู่เสมอ ดังนั้นให้ตรวจสอบรุ่นที่คุณใช้งานอยู่แทนการจดจำตัวเลขเวอร์ชัน:

ollama --version
ollama serve --help

ollama serve --help แสดงรายการ environment variables ที่รุ่นนั้นอ่านจริง ซึ่งรวมถึง OLLAMA_KEEP_ALIVE ด้วย มีกฎสองข้อที่ใช้ได้กับทุกรุ่นและสามารถยึดถือเป็นหลักการได้ ข้อแรกคือ ค่าที่ระบุใน request จะมีความสำคัญเหนือกว่าค่าเริ่มต้นของเซิร์ฟเวอร์ และข้อที่สองคือ ollama ps คือข้อมูลที่ถูกต้องที่สุดว่ามีการโหลดค่าใดอยู่จริง ไม่ว่าไฟล์ config จะระบุไว้อย่างไรก็ตาม

หากคุณใช้ editor หรือ agent ในการควบคุมเซิร์ฟเวอร์ ให้ตรวจสอบสิ่งที่ client เหล่านั้นส่งออกมาก่อนที่จะสรุปว่าเซิร์ฟเวอร์มีปัญหา การชี้ coding agent ไปยังเซิร์ฟเวอร์ Ollama ของคุณเอง อธิบายถึงตำแหน่งที่ตั้งของการตั้งค่า request เหล่านั้น

FAQ

ทำไม Ollama ถึงยกเลิกการโหลดโมเดลของฉันหลังจากผ่านไป 5 นาที?

5 นาทีคือค่าเริ่มต้นของ keep_alive ซึ่งเป็นตัวจับเวลาขณะว่าง (idle timer) ที่ Ollama จะเริ่มนับเมื่อการร้องขอเสร็จสิ้น เมื่อเวลาหมดลง เซิร์ฟเวอร์จะคืนหน่วยความจำที่ใช้เก็บค่าน้ำหนัก (weights) ของโมเดล ดังนั้นการร้องขอครั้งถัดไปจึงต้องโหลดข้อมูลจากดิสก์ใหม่ ซึ่งทำให้เกิดความล่าช้าที่คุณรู้สึกได้ คุณสามารถเพิ่มเวลาสำหรับการร้องขอครั้งเดียวได้โดยส่ง "keep_alive": "30m" ใน JSON body หรือตั้งค่าสำหรับทั้งเซิร์ฟเวอร์ด้วยตัวแปรสภาพแวดล้อม OLLAMA_KEEP_ALIVE

ฉันจะเก็บโมเดลของ Ollama ไว้ในหน่วยความจำอย่างถาวรได้อย่างไร?

ให้ใช้ค่าติดลบ: "keep_alive": -1 ในการร้องขอ หรือ OLLAMA_KEEP_ALIVE=-1 สำหรับเซิร์ฟเวอร์ จากนั้น ollama ps จะแสดงค่า Forever ในคอลัมน์ UNTIL การทำเช่นนี้จะเป็นการยกเลิกตัวจับเวลาขณะว่างเท่านั้น หากมีการร้องขอโมเดลอื่นเข้ามาและหน่วยความจำไม่เพียงพอ ตัวจัดตารางเวลา (scheduler) ก็ยังคงยกเลิกการโหลดโมเดลนี้เพื่อเพิ่มพื้นที่ว่างอยู่ดี

ทำไม OLLAMA_KEEP_ALIVE ถึงถูกละเลย?

ให้ตรวจสอบจุดที่คุณตั้งค่าตัวแปรดังกล่าว หากคุณรันคำสั่ง systemctl show ollama --property=Environment แล้วไม่พบตัวแปรนั้นในผลลัพธ์ แสดงว่าเซิร์ฟเวอร์ไม่ได้รับค่าดังกล่าว เนื่องจากตัวแปรที่ export ใน shell ของคุณจะไม่ส่งผลต่อ service ของ systemd ให้ตั้งค่าผ่าน sudo systemctl edit ollama.service จากนั้นรัน sudo systemctl daemon-reload และ sudo systemctl restart ollama อีกสาเหตุหนึ่งคือไคลเอนต์ส่งค่า keep_alive ของตนเองมาพร้อมกับการร้องขอ ซึ่งจะไปแทนที่ค่าเริ่มต้นของเซิร์ฟเวอร์

ฉันจะคืนหน่วยความจำโดยไม่ต้องรีสตาร์ท Ollama ได้อย่างไร?

ollama stop qwen3:8b จะยกเลิกการโหลดโมเดลนั้นทันทีโดยที่เซิร์ฟเวอร์และโมเดลอื่นๆ ที่โหลดอยู่ยังคงทำงานต่อไป สำหรับการใช้งานผ่าน API ให้ส่งการร้องขอโดยไม่มี prompt และกำหนด "keep_alive": 0 จากนั้นคุณจะได้รับคำตอบพร้อมค่า "done_reason": "unload" ให้ยืนยันผลด้วย ollama ps ซึ่งโมเดลดังกล่าวควรจะไม่อยู่ในรายการแล้ว