วิธีรัน Meta Muse Glimmer 30B บน VPS แบบไม่ใช้ GPU

สิ่งที่ Muse Glimmer ต้องการบน VPS

Muse Glimmer ทำงานบน Linux VPS ทั่วไปโดยไม่ต้องใช้ GPU และ tag ที่คุณเลือกจะเป็นตัวกำหนดว่าโมเดลจะใช้หน่วยความจำมากน้อยเพียงใด Meta Superintelligence Labs ได้เผยแพร่โมเดลนี้เมื่อวันที่ 10 สิงหาคม 2026 ภายใต้สัญญาอนุญาต Apache 2.0 โดยมีพารามิเตอร์ 30 พันล้านตัว, context window ขนาด 128K และ perception encoder เฉพาะทางขนาด 1.8B พารามิเตอร์ เพื่อให้สามารถอ่านภาพควบคู่ไปกับข้อความได้ Meta วางตำแหน่งโมเดลนี้ไว้สำหรับใช้งานเป็น local agent ที่ทำงานตลอดเวลามากกว่าการนำไปใช้แชท โดยคุณสามารถกำหนดระดับความสามารถในการใช้เหตุผลได้ในแต่ละคำขอ

tag ของ Ollama ที่เผยแพร่ ณ วันที่ 16 สิงหาคม 2026 มีขนาดตั้งแต่ 17 GB ไปจนถึง 59 GB ช่วงขนาดดังกล่าวคือประเด็นหลักในการคำนวณทรัพยากรทั้งหมด tag เริ่มต้นมีขนาดระบุไว้ที่ประมาณ 18 GB ดังนั้นเซิร์ฟเวอร์ขนาดเล็กที่สุดที่เหมาะสมจึงต้องมี RAM ว่างมากกว่า 18 GB อย่างชัดเจน นอกจากนี้ยังต้องเผื่อพื้นที่ดิสก์สำหรับการดาวน์โหลดและหน่วยความจำสำหรับ context window เพิ่มเติมจากส่วนนี้ด้วย

คุณควรดึง tag ไหนของ muse-glimmer?

[
  {
    "label": "30b-nvfp4",
    "size_gb": 17
  },
  {
    "label": "30b (default)",
    "size_gb": 18
  },
  {
    "label": "30b-q4_K_M",
    "size_gb": 18
  },
  {
    "label": "30b-q4_K_M-dflash",
    "size_gb": 20
  },
  {
    "label": "30b-nvfp4-dflash",
    "size_gb": 21
  },
  {
    "label": "30b-q8_0",
    "size_gb": 31
  },
  {
    "label": "30b-mxfp8",
    "size_gb": 33
  },
  {
    "label": "30b-q8_0-dflash",
    "size_gb": 33
  },
  {
    "label": "30b-mxfp8-dflash",
    "size_gb": 35
  },
  {
    "label": "30b-bf16",
    "size_gb": 57
  },
  {
    "label": "30b-bf16-dflash",
    "size_gb": 59
  }
]

Ollama แสดงรายการ tag จำนวน 11 รายการสำหรับโมเดลนี้ที่ไม่ใช่รุ่นสำหรับ Apple โดยทั้งหมดใช้ค่าน้ำหนัก (weights) 30 พันล้านค่าเท่ากัน แต่จัดเก็บด้วยความละเอียดเชิงตัวเลขที่ต่างกัน ขนาดที่คุณเห็นคือขนาดที่คุณต้องดาวน์โหลด และเป็นขนาดโดยประมาณที่คุณต้องสำรองไว้ในหน่วยความจำก่อนที่จะมีการเพิ่ม context ใดๆ เข้าไป

รุ่น 4-bit สองรุ่นเป็นรุ่นที่มีขนาดเล็ก ได้แก่ 30b-nvfp4 ขนาด 17 GB และ 30b-q4_K_M ขนาด 18 GB ส่วน tag เริ่มต้นอย่าง 30b มีขนาดเท่ากับรุ่น q4_K_M สำหรับรุ่น 8-bit อย่าง 30b-q8_0 และ 30b-mxfp8 จะมีขนาดใกล้เคียง 31 GB ส่วน 30b-bf16 คือรุ่น 16-bit ที่ไม่ได้ผ่านการทำ quantization ซึ่งมีขนาด 57 GB ซึ่งใช้ RAM มากกว่าที่เซิร์ฟเวอร์เช่าส่วนใหญ่จะให้ได้ในราคาที่คุ้มค่าสำหรับโปรเจกต์เสริม

tag -dflash คือรุ่นเดียวกันที่มีการรองรับ DFlash โดยแต่ละรายการจะมีขนาดใหญ่กว่ารุ่นปกติ Ollama อธิบายว่า DFlash เป็นฟีเจอร์เพิ่มความเร็วและแสดงผลบน Apple Silicon และ GPU บนเดสก์ท็อป สำหรับ VPS ที่ใช้เฉพาะ CPU คุณจะต้องเสียหน่วยความจำจริงเพิ่มขึ้นเพื่อแลกกับฟีเจอร์ที่วัดผลบนฮาร์ดแวร์อื่น ดังนั้นควรเริ่มต้นด้วย tag ปกติและปรับเปลี่ยนทีละอย่าง

ควรเริ่มต้นที่ 4-bit เว้นแต่คุณจะมีเหตุผลเฉพาะเจาะจง การเปลี่ยนจาก 4-bit เป็น 8-bit จะทำให้จำนวนไบต์ที่ CPU ต้องอ่านสำหรับทุก token ที่สร้างขึ้นเพิ่มขึ้นเกือบสองเท่า ส่งผลให้ throughput ลดลงในขณะที่การใช้หน่วยความจำเพิ่มขึ้น การแลกเปลี่ยนนี้เป็นหัวข้อของ ต้นทุนที่แท้จริงของการทำ q4, q8 และ fp16 quantization และสำหรับเครื่องที่ใช้ CPU เป็นหลัก คำตอบสั้นๆ คือรุ่น 4-bit เป็นรุ่นเดียวที่คุ้มค่าแก่การเริ่มต้นใช้งาน

เหตุใดแท็ก MLX จึงไม่มีผลบนเซิร์ฟเวอร์ Linux

MLX คือเฟรมเวิร์กจัดการอาร์เรย์ของ Apple และเอนจิน MLX ของ Ollama คือแบ็กเอนด์สำหรับ Apple Silicon แท็กใดก็ตามที่มีชื่อ mlx จะถูกสร้างขึ้นมาเพื่อเอนจินและฮาร์ดแวร์ดังกล่าวโดยเฉพาะ บนเซิร์ฟเวอร์ x86 Linux VPS แท็กเหล่านี้มีขนาดไฟล์หลายสิบกิกะไบต์ที่คุณไม่สามารถเรียกใช้งานได้ และมันจะกินพื้นที่ดิสก์ของคุณโดยเปล่าประโยชน์ ตัวเลขความเร็วที่ระบุในประกาศซึ่งวัดผลบนเครื่อง Mac นั้นเป็นของแท็กเหล่านั้น จึงไม่ได้สะท้อนประสิทธิภาพของเซิร์ฟเวอร์ของคุณ เมื่อคุณอ่านรายการแท็กในหน้าโมเดล ให้กรองชื่อที่มี mlx ออกก่อน แล้วจึงพิจารณาขนาดจากรายการที่เหลืออยู่

ต้องการ RAM และพื้นที่ดิสก์จริงเท่าใด

มีสองสิ่งที่ใช้หน่วยความจำ และมีเพียงสิ่งเดียวเท่านั้นที่เป็นขนาดของ tag น้ำหนักของโมเดลถูกกำหนดไว้ตายตัวตาม tag ที่คุณดึงมา ส่วน KV cache ซึ่งเป็นสถานะต่อ token ที่โมเดลเก็บไว้สำหรับการสนทนา จะเพิ่มขึ้นตามความยาวของ context ที่คุณตั้งค่าไว้ เอกสารของ Ollama ระบุว่าการให้บริการคำขอแบบขนานจะคูณ context ด้วยจำนวนคำขอที่กำลังประมวลผล ดังนั้นเครื่องที่ตอบคำถามเอเจนต์สองตัวพร้อมกันจึงต้องการหน่วยความจำมากกว่าเครื่องที่ตอบเพียงตัวเดียว

อย่าอ้างอิงตัวเลข RAM จากคู่มือใดๆ รวมถึงคู่มือนี้ ให้ดึง tag มา แล้วส่ง prompt ไปหนึ่งรายการ และในขณะที่โมเดลยังคงอยู่ในหน่วยความจำ ให้รันคำสั่งสองคำสั่งนี้

ollama ps
free -h

ollama ps แสดงสิ่งที่ถูกโหลดอยู่ในขณะนี้และวิธีการแบ่งงานระหว่าง CPU และ GPU ส่วน free -h แสดงสิ่งที่เหลืออยู่ ผลลัพธ์ทั้งสองรายการบนเครื่องของคุณแม่นยำกว่าตารางที่เผยแพร่ทั่วไป เพราะผลลัพธ์เหล่านั้นรวมการตั้งค่า context, การทำ quantisation และทุกอย่างที่เซิร์ฟเวอร์กำลังรันอยู่แล้ว

พื้นที่ดิสก์เป็นส่วนที่จัดการง่ายกว่า Ollama จัดเก็บโมเดลไว้ที่ /usr/share/ollama/.ollama/models บน Linux ซึ่งโดยปกติจะอยู่บน root filesystem ของ VPS ส่วนใหญ่ root volume ขนาด 40GB จะไม่สามารถเก็บ build แบบ bf16 ที่ขนาด 57 GB ได้ และไม่สามารถเก็บ tag แบบ 8-bit สองรายการพร้อมกันได้เช่นกัน หากคุณไม่เคยตรวจสอบว่าการดึงข้อมูลเขียนไฟล์ลงที่ใด ตำแหน่งที่ Ollama จัดเก็บโมเดลและวิธีการย้าย จะอธิบายรายละเอียดของไดเรกทอรีดังกล่าว ให้ย้ายที่จัดเก็บไปยัง volume ที่ mount ไว้ก่อนที่คุณจะดึงข้อมูลใดๆ

sudo systemctl edit ollama

[Service]
Environment="OLLAMA_MODELS=/mnt/models"

sudo mkdir -p /mnt/models
sudo chown -R ollama:ollama /mnt/models
sudo systemctl daemon-reload
sudo systemctl restart ollama

ผู้ใช้ ollama ต้องเป็นเจ้าของไดเรกทอรีนั้น เพราะบริการรันในฐานะ ollama และเขียน blob ลงที่นั่นด้วยสิทธิ์ของตนเอง หากการดึงข้อมูลล้มเหลวเนื่องจากปัญหาเรื่องสิทธิ์ journalctl -u ollama -n 50 คือที่ที่คุณจะพบสาเหตุ

Swap มีข้อเท็จจริงที่ต้องระบุชัดเจนคือ swap ไม่ช่วยให้คุณรัน tag ที่ใหญ่ขึ้นได้ การสร้างข้อความต้องเข้าถึงน้ำหนักของโมเดลสำหรับทุก token ที่ผลิตออกมา ดังนั้นน้ำหนักที่อยู่ใน swap จะถูกอ่านกลับจากดิสก์ซ้ำแล้วซ้ำเล่า vmstat 1 จะแสดงคอลัมน์ si และ so ที่ทำงานหนัก และความเร็วในการแสดงผลจะช้าลงจนเหลือระดับวินาทีต่อ token ให้เก็บไฟล์ swap ขนาดเล็กไว้เพื่อป้องกันการทำงานของ out of memory killer และจัดสรรขนาด RAM ให้เหมาะสมกับ tag ที่คุณต้องการใช้งานจริง

การติดตั้ง Ollama และการระบุ tag แบบเจาะจง

curl -fsSL https://ollama.com/install.sh | sh
ollama --version
systemctl status ollama

สคริปต์การติดตั้งจะตั้งค่า systemd service ให้โดยอัตโนมัติ เพื่อให้เซิร์ฟเวอร์กลับมาทำงานได้ใหม่หลังจากการรีบูต หากคุณไม่ต้องการรันในฐานะ system service ที่จัดการโดย root คุณสามารถดูวิธีการ รัน Ollama แบบ rootless ด้วย Podman ได้ จากนั้นให้ทำการ pull tag ที่ระบุไว้อย่างชัดเจน

ollama pull muse-glimmer:30b
ollama list

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

ห้ามใช้ ollama pull muse-glimmer บนเซิร์ฟเวอร์ที่คุณต้องใช้งานจริง ชื่อโมเดลเปล่าๆ จะถูกแปลงไปเป็น tag latest และ latest เป็นเพียงตัวชี้ (pointer) ที่ผู้เผยแพร่สามารถเปลี่ยนไปชี้ยัง build อื่นได้ทุกเมื่อ การสั่ง pull ตามปกติอาจทำให้โมเดลที่ใช้งานอยู่ถูกแทนที่โดยไม่รู้ตัว ซึ่งอาจส่งผลต่อความต้องการหน่วยความจำและพฤติกรรมของโมเดลที่เปลี่ยนไป โดยที่ไม่มีการแจ้งเตือนใดๆ ใน log ของคุณ ดังนั้นให้ระบุ tag ลงในสคริปต์, ไฟล์ unit และการตั้งค่า agent ของคุณให้ชัดเจน คุณสามารถดูรายละเอียดการตั้งค่าเซิร์ฟเวอร์ส่วนที่เหลือได้ที่ การทำ Self-hosting LLM ด้วย Ollama บน VPS

คุณสามารถรัน Muse Glimmer โดยไม่มี GPU ได้หรือไม่

ได้ และควรกล่าวถึงข้อจำกัดตามตรง การสร้างหนึ่ง token หมายถึงการอ่านค่าน้ำหนักโมเดล (model weights) ออกจากหน่วยความจำ ดังนั้นความเร็วจะถูกกำหนดโดยแบนด์วิดท์ของหน่วยความจำ ไม่ใช่จำนวน vCPU ที่ระบุไว้ในแผนบริการ เมื่อเกินจำนวนคอร์ไปเพียงเล็กน้อย การเพิ่มคอร์แทบไม่ได้ช่วยเพิ่มประสิทธิภาพ บน VPS แบบแชร์ แบนด์วิดท์นี้จะถูกใช้ร่วมกับผู้เช่ารายอื่นทั้งหมดบนโฮสต์เดียวกัน ดังนั้นโมเดลขนาด 30B ที่ระดับ 4-bit จะสร้าง token ได้เพียงจำนวนน้อยต่อวินาที

อย่าเชื่อตัวเลขของใครทั้งสิ้น รวมถึงของผมด้วย วัดค่า tokens ต่อวินาทีบนเครื่องของคุณเอง แล้วตัดสินใจจากสิ่งที่คุณเห็น

ผลลัพธ์ที่ได้คือความแตกต่างอย่างชัดเจนในแง่ของการใช้งานโมเดล การแชทแบบโต้ตอบนั้นทำได้ลำบาก เพราะคุณอ่านเร็วกว่าที่เซิร์ฟเวอร์เขียน และทุกการตอบกลับจะเริ่มต้นด้วยการหยุดรอที่ยาวนาน งานเบื้องหลัง (background agent) สามารถทำได้ดี เพราะงานที่รันโดยไม่มีคนดูแลเป็นเวลาสิบนาทีไม่สนใจว่ามันจะช้า งานประเภทที่สองนี้คือสิ่งที่ Meta อธิบายไว้สำหรับโมเดลนี้โดยตรง

หากคุณต้องการความเร็วสำหรับการโต้ตอบ คำตอบที่ตรงไปตรงมามีสองทางคือ GPU หรือ API แบบโฮสต์ คำนวณจุดคุ้มทุนระหว่าง GPU VPS กับ API tokens ก่อนที่คุณจะเช่าบริการใดๆ และ สิ่งที่ GPU VPS มอบให้คุณจริงๆ จะอธิบายสิ่งที่คุณกำลังซื้อ สำหรับคำถามที่กว้างขึ้นว่าเครื่องหนึ่งเครื่องสามารถรองรับอะไรได้บ้าง ให้เริ่มที่ โมเดลที่คุณสามารถ self-host ได้ และ การรันโมเดล Qwen ขนาดใกล้เคียงกันบน VPS คือการเปรียบเทียบที่ใกล้เคียงที่สุดในระดับขนาดนี้ หากตัวเลขที่คุณวัดได้ช้าเกินกว่าที่จะใช้งานจริง Nemotron 3.5 Lightning บน VPS จะเป็นคำถามเกี่ยวกับ RAM และ tokens ต่อวินาทีในลักษณะเดียวกันสำหรับโมเดลที่สร้างมาเพื่อความเร็วมากกว่าขนาด

เหตุใดจึงลืมข้อมูลก่อนถึงขีดจำกัด 128K tokens

เนื่องจากค่าเริ่มต้นของ context window ใน Ollama คือ 4096 tokens ไม่ว่าโมเดลจะรองรับได้มากเพียงใดก็ตาม ค่าเริ่มต้นนี้ระบุอยู่ใน FAQ ของ Ollama ณ เดือนสิงหาคม 2026 แม้ว่าแท็กจะระบุไว้ที่ 128K แต่เซิร์ฟเวอร์จะส่งค่า 4096 ให้โมเดลจนกว่าคุณจะกำหนดเป็นอย่างอื่น ดังนั้นบทสนทนาของเอเจนต์ที่ยาวจะสูญเสียข้อมูลในช่วงแรกไป ทำให้โมเดลดูเหมือนมีอาการความจำเสื่อม

คุณสามารถเพิ่มค่านี้บนเซิร์ฟเวอร์สำหรับทุกคำขอได้ดังนี้:

[Service]
Environment="OLLAMA_CONTEXT_LENGTH=32768"

ภายในเซสชันแบบโต้ตอบ /set parameter num_ctx 32768 จะเปลี่ยนค่านี้สำหรับเซสชันนั้นเท่านั้น หากใช้งานผ่าน API ให้ส่ง num_ctx ไปในตัวเลือกของคำขอ (request options)

ทุกๆ token ของ context ที่เพิ่มขึ้นจะใช้หน่วยความจำเพิ่มเติมจากตัว weight ของโมเดล หากคุณกำหนดค่าเป็น 128K เต็มรูปแบบบนเครื่องที่มีขนาดหน่วยความจำพอดีสำหรับ weight เท่านั้น การโหลดจะล้มเหลวหรือทำงานช้าลงอย่างมาก แนะนำให้ค่อยๆ เพิ่มค่าทีละขั้นและรัน ollama ps หลังจากปรับแต่ละครั้ง การทำงานของ num_ctx และความยาวของ context ใน Ollama จะอธิบายรายละเอียดเกี่ยวกับการคำนวณในส่วนนี้

ระดับความสามารถในการใช้เหตุผล: low, medium, high และ xhigh

Meta ได้กำหนดระดับความสามารถในการใช้เหตุผลไว้ 4 ระดับสำหรับ Muse Glimmer ตั้งแต่ low ไปจนถึง xhigh โดยแนะนำให้ใช้สองระดับที่สูงกว่าสำหรับงานเขียนโค้ดที่ซับซ้อนและงานประเภท agent ใน Ollama ค่านี้จะขึ้นอยู่กับพารามิเตอร์ think ให้ใช้ --think= ผ่านบรรทัดคำสั่ง หรือส่ง think ในส่วน body ของ API

ollama run muse-glimmer:30b --think=high "Summarise the changes in /tmp/patch.diff"

ในระหว่างเซสชันแบบโต้ตอบ สามารถใช้ /set think และ /set nothink เพื่อสลับระดับได้ เอกสารของ Ollama ระบุว่าโมเดลส่วนใหญ่ยอมรับทั้งค่าบูลีนหรือระดับ เช่น low, medium หรือ high และบางโมเดลยอมรับ max สำหรับระดับสูงสุดที่มีให้ใช้งาน สตริงที่แน่นอนที่โมเดลนี้ยอมรับจะระบุอยู่ในหน้าเพจของโมเดลนั้นๆ ดังนั้นควรตรวจสอบข้อมูลดังกล่าวแทนการคาดเดา และทดลองใช้งานด้วยตนเองก่อนที่จะนำไปเชื่อมต่อกับ agent

บนเครื่องที่ใช้เฉพาะ CPU การปรับค่านี้มีผลอย่างมาก ระดับความสามารถที่สูงขึ้นหมายถึงการสร้างโทเค็นสำหรับการคิด (thinking tokens) จำนวนมากขึ้นก่อนที่คำแรกของคำตอบจะปรากฏขึ้น และโทเค็นสำหรับการคิดแต่ละตัวจะใช้เวลาประมวลผลเท่ากับโทเค็นของคำตอบปกติ ควรตั้งค่าระดับ low สำหรับงานทั่วไป ความยาวของคำตอบก็ควรได้รับการพิจารณาด้วยเช่นกัน ดังนั้นให้ จำกัดจำนวนคำตอบด้วย num_predict แทนการปล่อยให้คำตอบที่ยืดยาวทำให้เครื่องที่ประมวลผลช้าต้องทำงานค้างอยู่นานหลายนาที

การคงโมเดลไว้ในหน่วยความจำสำหรับเอเจนต์ที่ทำงานตลอดเวลา

โดยค่าเริ่มต้น Ollama จะยกเลิกการโหลดโมเดลที่ไม่ได้ใช้งานหลังจากผ่านไป 5 นาที สำหรับเอเจนต์ที่ทำงานทุกๆ 10 นาที นั่นหมายความว่าคุณต้องเสียเวลาโหลดข้อมูลขนาด 18 GB จากดิสก์ในการทำงานทุกรอบ ซึ่งบน VPS ที่ใช้ network attached storage การโหลดนี้จะไม่รวดเร็ว ให้ใช้วิธีตรึงโมเดลไว้ในหน่วยความจำแทน

[Service]
Environment="OLLAMA_KEEP_ALIVE=-1"

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

การเชื่อมต่อ Coding Agent เข้ากับระบบ

Ollama ให้บริการ API ที่รองรับมาตรฐาน OpenAI ที่ http://127.0.0.1:11434/v1 ดังนั้นเครื่องมือ Agent ส่วนใหญ่จึงสามารถเชื่อมต่อได้โดยใช้เพียง Base URL และ API Key ที่ไม่เป็นค่าว่าง หน้า Muse Glimmer ของ Ollama ยังมีเอกสารระบุทางลัดการเรียกใช้งานที่เชื่อมต่อ Agent ที่รองรับเข้ากับโมเดลในเครื่องได้ด้วยคำสั่งเดียว ซึ่งคุณควรระบุ Tag ให้ชัดเจนไว้ด้วย

ollama launch claude --model muse-glimmer:30b

Agent จะส่ง Prompt ขนาดใหญ่ ข้อมูลเนื้อหาไฟล์ ผลลัพธ์จากเครื่องมือ และประวัติการสนทนาที่เพิ่มขึ้นเรื่อยๆ ทั้งหมดจะถูกส่งเข้ามาในรูปแบบ Input Token ซึ่งบนเครื่องที่ใช้ CPU การประมวลผล Prompt คือขั้นตอนที่กินทรัพยากรมากที่สุดก่อนที่การสร้างข้อความจะเริ่มขึ้น ดังนั้นควรจำกัดขนาดของ Context ให้เล็กที่สุดเท่าที่งานนั้นๆ จะอนุญาต การเชื่อมต่อ Coding Agent เข้ากับ Ollama ครอบคลุมฝั่งไคลเอนต์ การรัน Coding Agent บน VPS ครอบคลุมถึงตัวเซิร์ฟเวอร์ที่ใช้งาน และ การควบคุมค่าใช้จ่ายของ Agent บน VPS ครอบคลุมถึงสิ่งที่เกิดขึ้นเมื่อรัน Agent ตลอดทั้งวัน

การป้อนข้อมูลรูปภาพทำงานในลักษณะเดียวกัน API ของ Ollama จะรับรูปภาพผ่านฟิลด์ images ของข้อความ ดังนั้นไคลเอนต์ที่รองรับเฉพาะข้อความจึงไม่สามารถส่งรูปภาพได้ แม้ว่าตัว Perception Encoder ของโมเดลจะมีความสามารถในการประมวลผลรูปภาพก็ตาม

ห้ามเปิดพอร์ต 11434

Ollama API ไม่มีการยืนยันตัวตน การตั้งค่า OLLAMA_HOST=0.0.0.0:11434 เพื่อให้เข้าถึงได้จากแล็ปท็อปของคุณ จะทำให้ตัวรันโมเดลที่ไม่มีการป้องกันถูกเปิดเผยบนอินเทอร์เน็ตสาธารณะ ซึ่งใครก็ตามที่พบพอร์ตนี้สามารถโหลดโมเดลลงในดิสก์ของคุณและอ่านข้อมูลทุกอย่างที่เอเจนต์ของคุณส่งผ่าน API ได้ ให้คงการเชื่อมต่อไว้ที่ localhost และใช้การทำ tunnel แทน

ssh -N -L 11434:127.0.0.1:11434 user@your-vps

การรักษาความปลอดภัยให้กับ Ollama API endpoint ครอบคลุมตัวเลือกที่เหมาะสม รวมถึงการใช้ reverse proxy เพื่อเรียกขอข้อมูลยืนยันตัวตนก่อนเข้าใช้งาน

สิ่งที่มักจะเกิดปัญหาและสิ่งที่คุณจะพบ

การดึงข้อมูลหยุดลงกลางคัน ปัญหาเกิดจากพื้นที่ดิสก์ ให้รันคำสั่ง df -h ตรวจสอบไดเรกทอรีโมเดล ไฟล์ build แบบ bf16 ขนาด 57 GB ไม่สามารถเก็บลงใน root volume ขนาด 40GB ได้ และการเก็บ tag แบบ 8-bit สองรายการพร้อมกันก็ทำไม่ได้เช่นกัน

โมเดลโหลดขึ้นมาแล้วกระบวนการทำงานหยุดลง ปัญหาเกิดจากหน่วยความจำไม่เพียงพอ (Out of memory) คำสั่ง dmesg -T จะบันทึกเหตุการณ์ที่ kernel สั่งยุติกระบวนการ (OOM killer) และ journalctl -u ollama -n 100 จะแสดงเหตุการณ์เดียวกันในฝั่งของ service วิธีแก้ไขคือการใช้ tag ที่เล็กลงหรือใช้ num_ctx ที่มีขนาดเล็กลง ไม่ใช่การเพิ่ม swap

การทำงานช้าในระดับวินาทีต่อโทเค็น ให้รันคำสั่ง vmstat 1 แล้วสังเกตคอลัมน์ si และ so หากมีการใช้งาน swap อย่างต่อเนื่อง แสดงว่าน้ำหนัก (weights) ของโมเดลไม่สามารถโหลดลงใน RAM ได้ทั้งหมด และระบบกำลังอ่านข้อมูลกลับจากดิสก์ในขณะที่ประมวลผล

tag ที่เคยใช้งานได้เมื่อสัปดาห์ก่อนหายไป รายการ tag มีการเปลี่ยนแปลงอยู่เสมอ โปรดอ่านหน้าโมเดลใหม่อีกครั้ง ปักหมุด (pin) เวอร์ชันที่ใช้งานปัจจุบัน และบันทึกชื่อ tag ไว้ในที่ที่คุณสามารถกลับมาตรวจสอบได้

ollama pull muse-glimmer:30b
ollama list
sudo du -sh /usr/share/ollama/.ollama/models

FAQ

Muse Glimmer ต้องการ RAM เท่าใดบน VPS?

ให้เริ่มคำนวณจากขนาดของ tag แล้วบวกด้วย context window เข้าไป โดย tag เริ่มต้นมีขนาดอยู่ที่ประมาณ 18 GB ณ วันที่ 16 สิงหาคม 2026 ดังนั้นเซิร์ฟเวอร์ขนาด 16GB จึงไม่สามารถรองรับได้เลย และขนาด 24GB ก็จะเหลือพื้นที่สำหรับ context เพียงเล็กน้อยเท่านั้น ให้ถือว่าตัวเลขนี้เป็นจุดเริ่มต้นไม่ใช่คำตอบสุดท้าย ให้ทำการ pull tag มาแล้วโหลดขึ้นมาหนึ่งครั้ง จากนั้นรัน ollama ps และ free -h บนเครื่องของคุณเองเพื่ออ่านค่าตัวเลขจริง ทั้งนี้ context ที่ยาวขึ้นและการร้องขอแบบขนาน (parallel requests) จะใช้หน่วยความจำเพิ่มขึ้นนอกเหนือจากส่วนของ weights

ฉันสามารถรัน Muse Glimmer โดยไม่มี GPU ได้หรือไม่?

ได้ คุณสามารถโหลดและใช้งานบน VPS ที่มีเฉพาะ CPU ได้ ความเร็วในการสร้างข้อความจะถูกจำกัดด้วย memory bandwidth มากกว่าจำนวน core และบนโฮสต์แบบ shared นั้น bandwidth จะถูกแชร์ร่วมกัน ดังนั้นคาดหวังได้เพียงจำนวน token ต่อวินาทีที่น้อยมากในระดับ 4-bit ซึ่งเพียงพอสำหรับงานเบื้องหลัง (background agent) ที่รันโดยไม่ต้องเฝ้าดู แต่จะใช้งานลำบากสำหรับการแชทแบบโต้ตอบ ให้รัน ollama ps ระหว่างการร้องขอและตรวจสอบคอลัมน์ processor เพื่อยืนยันว่างานกำลังประมวลผลอยู่ที่ใด

MLX tags มีประโยชน์บน Linux VPS หรือไม่?

ไม่มี ประโยชน์ใดๆ เพราะทุก tag ที่มี mlx อยู่ในชื่อถูกสร้างมาสำหรับ MLX engine ของ Ollama ซึ่งเป็น backend สำหรับ Apple Silicon บนเซิร์ฟเวอร์ Linux แบบ x86 tag เหล่านั้นจะเป็นไฟล์ขนาดใหญ่ที่คุณไม่สามารถรันได้ ให้ใช้ tag 30b แบบปกติ หรือ tag อื่นที่ไม่ใช่ MLX และให้ละเว้นผลการทดสอบประสิทธิภาพ (benchmark) ของฮาร์ดแวร์ Apple ที่มาพร้อมกับ build แบบ MLX

ทำไมโมเดลถึงลืมข้อมูลก่อนที่จะถึง 128K tokens?

เพราะค่าเริ่มต้นของ context window ใน Ollama คือ 4096 tokens ไม่ว่าโมเดลจะรองรับได้เท่าใดก็ตาม เซิร์ฟเวอร์จึงตัดบทสนทนาที่ยาวเกินไปทิ้งก่อนที่โมเดลจะได้รับข้อมูลเหล่านั้น ให้ตั้งค่า OLLAMA_CONTEXT_LENGTH บนเซิร์ฟเวอร์ หรือใช้ /set parameter num_ctx สำหรับเซสชันเดียว หรือส่ง num_ctx ในตัวเลือกของ API request การใช้หน่วยความจำจะเพิ่มขึ้นตามค่านี้ ดังนั้นให้ค่อยๆ ปรับเพิ่มทีละขั้นและตรวจสอบ ollama ps ในแต่ละครั้ง

ฉันควรระบุ tag ให้ชัดเจนหรือใช้ latest ดี?

ควรระบุ tag ให้ชัดเจน การใช้ muse-glimmer โดยไม่มี tag จะอ้างอิงไปยัง latest ซึ่งเป็น pointer ที่ผู้เผยแพร่สามารถเปลี่ยนไปยัง build อื่นได้ตลอดเวลา ดังนั้นการสั่ง pull ตามปกติอาจทำให้โมเดลที่ agent ของคุณใช้งานอยู่เปลี่ยนไปได้ ให้เขียน muse-glimmer:30b ในสคริปต์, unit files และการตั้งค่าของ agent ตรวจสอบรายการ tag ในหน้าโมเดลก่อนทำการระบุ tag เพราะ tag ที่เผยแพร่อาจมีการเปลี่ยนแปลงได้