วิธีรัน 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 โดย tag เหล่านี้มีน้ำหนัก 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 อยู่ในชื่อจะถูกสร้างขึ้นมาเพื่อเอนจินและฮาร์ดแวร์ดังกล่าว บน VPS ที่ใช้สถาปัตยกรรม x86 Linux แท็กเหล่านี้จะเป็นไฟล์ขนาดหลายสิบกิกะไบต์ที่คุณไม่สามารถเรียกใช้งานได้ และจะกินพื้นที่บนดิสก์ของคุณโดยเปล่าประโยชน์ ตัวเลขความเร็วในประกาศที่วัดผลบน 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 สองรายการไว้พร้อมกันได้เช่นกัน ให้ย้ายที่จัดเก็บไปยัง mounted volume ก่อนที่คุณจะดึงข้อมูลใดๆ

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

สำหรับ swap มีข้อเท็จจริงที่ต้องทราบคือ swap ไม่ได้ช่วยให้คุณรัน tag ที่ใหญ่ขึ้นได้ การสร้างข้อความ (generation) ต้องเข้าถึงน้ำหนักของโมเดลสำหรับทุก 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 เป็นเพียงตัวชี้ที่ผู้เผยแพร่สามารถเปลี่ยนไปชี้ยัง build อื่นได้ทุกเมื่อ การสั่ง pull ตามปกติอาจทำให้โมเดลที่รันอยู่เบื้องหลังถูกแทนที่ด้วยเวอร์ชันใหม่ ซึ่งอาจมีความต้องการหน่วยความจำและพฤติกรรมที่เปลี่ยนไป โดยที่ไม่มีการแจ้งเตือนใดๆ ใน log ของคุณ ให้ระบุ tag ลงในสคริปต์, unit file และการตั้งค่า agent ของคุณโดยตรง คุณสามารถดูการตั้งค่าเซิร์ฟเวอร์ส่วนที่เหลือได้ที่ การทำ Self-hosting LLM ด้วย Ollama บน VPS

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

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

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

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

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

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

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

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

[Service]
Environment="OLLAMA_CONTEXT_LENGTH=32768"

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

ทุก token ของ context ที่เพิ่มขึ้นจะใช้หน่วยความจำเพิ่มเติมจากตัวน้ำหนักโมเดล (weights) หากคุณร้องขอค่าเต็ม 128K บนเครื่องที่มีขนาดหน่วยความจำพอดีสำหรับตัวน้ำหนักโมเดลเพียงอย่างเดียว การโหลดจะล้มเหลวหรือทำงานช้าลงอย่างมาก แนะนำให้ค่อยๆ เพิ่มค่าทีละขั้นและรัน 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 ระบุว่าโมเดลส่วนใหญ่รองรับทั้งค่า boolean หรือระดับความสามารถ เช่น low, medium หรือ high และบางโมเดลรองรับ max สำหรับระดับสูงสุดที่มีให้ใช้งาน สตริงที่แน่นอนที่โมเดลนี้รองรับจะระบุไว้ในหน้าข้อมูลของโมเดลนั้นๆ ดังนั้นควรตรวจสอบจากแหล่งข้อมูลดังกล่าวแทนการคาดเดา และควรทดสอบด้วยตนเองก่อนที่จะนำไปเชื่อมต่อกับ agent

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

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

โดยปกติ 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 tokens และบนเครื่องที่ประมวลผลด้วย 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 ขนาด 57 GB แบบ bf16 ไม่สามารถเก็บลงใน root volume ขนาด 40GB ได้ และไม่สามารถเก็บ tag แบบ 8-bit สองรายการไว้พร้อมกันได้เช่นกัน

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

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

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

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

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

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

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

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