เลือกใช้ Ollama หรือ llama.cpp บน VPS ตัวไหนดีกว่ากัน

Ollama กับ llama.cpp: คุณต้องการรันที่เลเยอร์ไหน?

Ollama และ llama.cpp ไม่ใช่คู่แข่งกันในลักษณะที่คำถามสื่อถึง llama.cpp คือ inference engine ซึ่งทำหน้าที่โหลดไฟล์โมเดลและแปลง prompt ให้เป็น tokens ส่วน Ollama คือตัวจัดการโมเดล (model manager) ที่ทำงานเป็น background daemon และมี HTTP API ครอบอยู่บน engine นั้นอีกที ในไฟล์ README ของ Ollama ยังคงระบุว่า llama.cpp เป็น inference backend ของตน (ตรวจสอบเมื่อวันที่ 2 สิงหาคม 2026) ดังนั้นคำถามที่แท้จริงคือคุณต้องการใช้งานที่เลเยอร์ไหนบน VPS ของคุณ ไม่ใช่ว่าตัวไหนเร็วกว่ากัน

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

โครงการแต่ละตัวคืออะไร

llama.cpp คือการนำ transformer inference มาใช้งานด้วยภาษา C และ C++ โดยสร้างขึ้นบนไลบรารี ggml ซึ่งจะอ่านไฟล์ GGUF โดย GGUF (GGML universal file format) เป็นคอนเทนเนอร์ไฟล์เดียวที่เก็บค่าน้ำหนัก (weights), ตัวตัดคำ (tokeniser) และข้อมูลเมตาที่เอนจินจำเป็นต้องใช้ในการรันโมเดล โครงการนี้จะปล่อยไฟล์ไบนารีแยกกันสำหรับงานแต่ละประเภท llama-server เป็น HTTP server, llama-cli เป็นอินเทอร์เฟซสำหรับพิมพ์โต้ตอบ และ llama-bench ใช้สำหรับวัดปริมาณงาน (throughput) การปล่อยเวอร์ชันจะใช้หมายเลข build แทนการใช้ semantic version โดยแท็กปัจจุบันคือ b10224 ซึ่งเผยแพร่เมื่อวันที่ 2 สิงหาคม 2026 และจะมีแท็กใหม่เกิดขึ้นเกือบทุกวันทำการ

Ollama เป็นโปรแกรมที่เขียนด้วยภาษา Go โดยมี background daemon ที่เริ่มทำงานด้วย ollama serve ทำหน้าที่โหลดโมเดลและตอบสนองคำขอ HTTP ส่วนไคลเอนต์บรรทัดคำสั่งจะทำหน้าที่สื่อสารกับ daemon ดังกล่าว เบื้องหลังทั้งสองส่วนคือ registry ที่ ollama.com ซึ่งเก็บโมเดลที่จัดเตรียมไว้ล่วงหน้า Ollama ใช้ระบบ semantic version โดยเวอร์ชัน v0.32.5 ได้ถูกปล่อยออกมาเมื่อวันที่ 27 กรกฎาคม 2026 ส่วน ollama pull จะทำหน้าที่ดึงไฟล์ GGUF พร้อมกับ prompt template และชุดพารามิเตอร์เริ่มต้น จากนั้นจะจัดเก็บไว้ภายใต้ /usr/share/ollama/.ollama/models บน Linux

การจัดแพ็กเกจคือความแตกต่างทั้งหมด Ollama จะตัดสินใจเรื่องการทำ quantisation, template และความยาวของบริบท (context length) ให้คุณ และให้ชื่อที่คุณจำได้เพียงชื่อเดียว ในขณะที่ llama.cpp จะไม่ตัดสินใจอะไรให้เลย แต่จะให้แฟล็ก (flags) มาแทน

แกนที่ 1: การควบคุมโมเดลและการทำ Quantisation

การทำ Quantisation จะลดขนาดของ weight แต่ละตัวจาก 16 หรือ 32 บิต ลงเหลือ 4, 5 หรือ 8 บิต ซึ่งเป็นสิ่งที่ทำให้โมเดลขนาด 8 พันล้านพารามิเตอร์สามารถทำงานได้ใน RAM ของ VPS ทั่วไป รูปแบบการตั้งชื่อ GGUF นั้นอ่านเข้าใจได้ง่ายเมื่อทราบรูปแบบ: Q4_K_M หมายถึง 4-bit K-quant ขนาดกลาง ตัวเลขที่สูงกว่าจะรักษาความแม่นยำได้มากกว่าแต่ใช้หน่วยความจำมากขึ้น

[
  {
    "label": "Q2_K",
    "file_size_gib": 2.96
  },
  {
    "label": "Q3_K_M",
    "file_size_gib": 3.74
  },
  {
    "label": "Q4_K_M",
    "file_size_gib": 4.58
  },
  {
    "label": "Q5_K_M",
    "file_size_gib": 5.34
  },
  {
    "label": "Q6_K",
    "file_size_gib": 6.14
  },
  {
    "label": "Q8_0",
    "file_size_gib": 7.95
  }
]

นี่คือขนาดไฟล์ที่เผยแพร่ใน repository bartowski/Meta-Llama-3.1-8B-Instruct-GGUF บน Hugging Face ซึ่งอ่านเมื่อวันที่ 2 สิงหาคม 2026 และแปลงจากไบต์เป็น GiB มี build ของโมเดลหนึ่งรุ่นจำนวน 6 รายการ โดยขนาดเล็กที่สุดคือ 2.96 GiB เทียบกับ 7.95 GiB สำหรับขนาดใหญ่ที่สุด ค่าเริ่มต้นทั่วไปอย่าง Q4_K_M มีขนาด 4.58 GiB บน VPS ขนาด 4 GiB ตัวเลือกนี้จะเป็นตัวตัดสินว่าโมเดลจะโหลดขึ้นหรือไม่

เมื่อใช้ llama.cpp คุณจะต้องระบุชื่อไฟล์ด้วยตนเอง ดังนั้นคุณจึงเป็นผู้เลือกแถวข้อมูลนั้นเอง

llama-server -m ~/models/Meta-Llama-3.1-8B-Instruct-Q4_K_M.gguf \
  -c 4096 -t 4 --host 127.0.0.1 --port 8080

-c คือขนาดบริบท (context size) ในหน่วยโทเค็น, -t คือจำนวนเธรด และ -ngl คือการตั้งค่าจำนวนเลเยอร์ที่จะย้ายไปประมวลผลบน GPU (ตั้งค่าเป็น 0 หากเป็นเครื่องที่ใช้ CPU เพียงอย่างเดียว) ระบบจะไม่มีการคาดเดาค่าใดๆ ให้คุณ

สำหรับ Ollama การทำ quantisation จะมาพร้อมกับ tag ที่คุณดึงมา และ ollama ls จะแสดงสิ่งที่คุณมีอยู่จริงบนดิสก์ ในกรณีที่ registry ไม่มี build ที่คุณต้องการ คุณสามารถนำเข้าไฟล์ GGUF ด้วยตนเอง โดยเขียนไฟล์ Modelfile:

FROM ./Meta-Llama-3.1-8B-Instruct-Q4_K_M.gguf
PARAMETER num_ctx 4096

จากนั้นทำการ build และตรวจสอบผลลัพธ์:

ollama create llama31-q4 -f ./Modelfile
ollama ls

ความยาวของบริบท (context length) คือการตั้งค่าที่มักสร้างปัญหา Ollama จะเลือกค่าเริ่มต้นจาก VRAM ที่มีอยู่ และเครื่องที่ไม่มี GPU จะถูกจัดอยู่ในกลุ่มที่เล็กที่สุดคือ 4096 โทเค็น หากคุณส่งเอกสารขนาด 20,000 โทเค็นเข้าไป โทเค็นส่วนเกินจะถูกตัดทิ้งก่อนที่โมเดลจะได้รับข้อมูล ทำให้คำตอบที่ได้มีความมั่นใจแต่ผิดพลาดเนื่องจากอ่านไฟล์ไปเพียงครึ่งเดียว คุณสามารถเพิ่มค่านี้ได้ด้วย OLLAMA_CONTEXT_LENGTH บน daemon หรือใช้ PARAMETER num_ctx ใน Modelfile ส่วน llama.cpp ก็ไม่มีค่าเริ่มต้นที่เชื่อถือได้เช่นกัน ให้ตั้งค่า -c อย่างชัดเจนและตรวจสอบให้แน่ใจว่าคุณตั้งค่าเป็นเท่าใด

การคำนวณหน่วยความจำที่ไม่มีใครบอกคุณ

ไฟล์โมเดลไม่ใช่ต้นทุนทั้งหมดของหน่วยความจำ KV cache (key/value cache) จะเก็บข้อมูล 1 รายการต่อเลเยอร์ต่อโทเค็นของบริบท และขนาดจะเพิ่มขึ้นตามความยาวของการสนทนา

ลองคำนวณสำหรับ Llama 3.1 8B โมเดลนี้มี 32 เลเยอร์, 8 key/value heads และ head dimension ขนาด 128 แต่ละโทเค็นจะเก็บทั้ง key และ value โดยใช้ขนาด 2 ไบต์ต่อค่าในรูปแบบ f16 ดังนั้นจึงเท่ากับ 2 x 8 x 128 x 2 = 4096 ไบต์ต่อเลเยอร์ เมื่อรวมทั้ง 32 เลเยอร์ จะเท่ากับ 128 KiB ต่อโทเค็น ดังนั้นบริบทขนาด 4096 โทเค็นจึงใช้หน่วยความจำ 512 MiB และบริบทขนาด 32,768 โทเค็นจะใช้ถึง 4 GiB

ดังนั้นโมเดล Q4_K_M 8B ที่บริบท 4k จะต้องการพื้นที่ประมาณ 4.58 GiB สำหรับค่าน้ำหนัก (weights) บวกกับ cache อีกประมาณ 0.5 GiB และหน่วยความจำสำหรับตัว runtime เอง ซึ่งจะไม่สามารถรันใน RAM ขนาด 4 GiB ได้ แต่จะรันใน 8 GiB ได้โดยมีพื้นที่เหลือให้ทำงาน หากเพิ่มบริบทเป็น 32k บนเครื่องขนาด 8 GiB เท่าเดิม ตัว cache เพียงอย่างเดียวก็จะกินพื้นที่ว่างทั้งหมด ให้ตรวจสอบแบบเรียลไทม์ด้วย free -h ขณะที่โมเดลกำลังโหลด และอย่าเชื่อการประมาณการที่คุณไม่ได้วัดผลด้วยตัวเอง

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

แกนที่ 2: daemon ที่คุณต้องดูแล

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

sudo systemctl edit ollama

[Service]
Environment="OLLAMA_CONTEXT_LENGTH=8192"
Environment="OLLAMA_KEEP_ALIVE=30m"

sudo systemctl daemon-reload
sudo systemctl restart ollama
journalctl -e -u ollama

OLLAMA_KEEP_ALIVE มีความสำคัญบน CPU VPS มากกว่าที่อื่น โมเดลจะถูกเก็บไว้ในหน่วยความจำเป็นเวลา 5 นาทีตามค่าเริ่มต้นก่อนจะถูกลบออก เมื่อมีคำขอถัดเข้ามา ระบบจะต้องอ่านไฟล์ทั้งหมดกลับจากดิสก์ก่อนที่จะตอบสนองได้ ดังนั้นการโหลดไฟล์ขนาด 4.58 GiB ใหม่ จะทำให้เวลาตอบสนองจาก 2 วินาทีกลายเป็น 30 วินาทีบนพื้นที่จัดเก็บข้อมูลที่ช้า การตั้งค่า keep-alive ให้นานขึ้นจะช่วยแก้ปัญหาความหน่วงนี้ แต่จะเป็นการจอง RAM ไว้ถาวร ทั้งสองทางเลือกมีต้นทุนที่ต้องแลก คุณควรเลือกทางที่ส่งผลกระทบน้อยที่สุด

llama.cpp ไม่มี daemon มาให้ คุณจึงต้องเขียน unit ขึ้นมาเองในชื่อ /etc/systemd/system/llama-server.service:

[Unit]
Description=llama.cpp server
After=network-online.target

[Service]
ExecStart=/usr/local/bin/llama-server -m /srv/models/model-Q4_K_M.gguf -c 4096 -t 4 --host 127.0.0.1 --port 8080
Restart=always
RestartSec=3
User=llama

[Install]
WantedBy=multi-user.target

เปิดใช้งานด้วย sudo systemctl enable --now llama-server กระบวนการนี้จะคงโมเดลไว้ในหน่วยความจำตลอดอายุการทำงานของมัน จะไม่มีการลบโมเดลออกเมื่อไม่มีการใช้งาน ซึ่งหมายความว่าจะไม่มีการโหลดใหม่ให้เสียเวลา และไม่มีวิธีคืนหน่วยความจำนอกจากต้องหยุด service นั้น หากคุณยังไม่คุ้นเคยกับการเขียน unit รูปแบบการทำงานจะเหมือนกับ การรัน service ของคุณเองภายใต้ systemd บน VPS

แกนที่ 3: API ที่แอปพลิเคชันของคุณจะสื่อสารด้วย

แกนนี้มีความแตกต่างลดลงอย่างมาก ปัจจุบันทั้งสองโปรเจกต์รองรับรูปแบบการแชทของ OpenAI ทำให้ไลบรารีฝั่งไคลเอนต์ส่วนใหญ่สามารถใช้งานกับทั้งสองระบบได้โดยเพียงแค่เปลี่ยน base URL เท่านั้น

Ollama จะฟังการเชื่อมต่อที่ 127.0.0.1:11434 โดยมีเส้นทางที่รองรับ OpenAI คือ http://localhost:11434/v1/chat/completions และยังคงรักษา native API ไว้ที่ /api/chat ควบคู่กันไป นอกจากนี้ยังมีเอกสารระบุถึงเส้นทางที่รองรับ Anthropic อีกด้วย

curl -X POST http://localhost:11434/v1/chat/completions \
  -H "Content-Type: application/json" \
  -d '{"model": "llama31-q4", "messages": [{"role": "user", "content": "Say this is a test"}]}'

llama-server จะฟังการเชื่อมต่อที่ 127.0.0.1:8080 และให้บริการ /v1/chat/completions, /v1/completions และ /v1/embeddings รวมถึงมี endpoint เฉพาะตัวคือ /completion และเว็บ UI ในตัว นอกจากนี้ยังเปิดเผยเส้นทางสำหรับการปฏิบัติงานที่ Ollama ไม่มี ได้แก่ /health สำหรับการตรวจสอบความพร้อม (readiness probe), /props สำหรับการตั้งค่าโมเดลที่โหลดอยู่, /slots สำหรับสถานะการทำงานของแต่ละ request slot และ /metrics ในรูปแบบของ Prometheus หากคุณวางแผนที่จะตรวจสอบสถานะ (monitor) บริการนี้ ความแตกต่างดังกล่าวอาจเป็นปัจจัยตัดสินใจเลือก

เซิร์ฟเวอร์ทั้งสองตัวไม่ได้เปิดใช้งานการยืนยันตัวตนให้คุณโดยอัตโนมัติ และทั้งคู่ตั้งค่าเริ่มต้นให้ฟังเฉพาะ loopback ด้วยเหตุผลด้านความปลอดภัย คุณควรเข้าถึงผ่าน SSH tunnel หรือผ่าน reverse proxy เท่านั้น และห้ามเปิดพอร์ต 11434 หรือ 8080 สู่สาธารณะโดยเด็ดขาด

สิ่งที่ VPS แบบ CPU-only ทำได้จริง

VPS แบบ CPU-only จะประมวลผลโมเดลขนาดเล็กได้ช้า นี่คือสรุปตามความเป็นจริง และส่วนที่เป็นประโยชน์คือการรู้ว่าขีดจำกัดอยู่ที่ตรงไหน ควรวัดผลก่อนที่จะออกแบบระบบใดๆ บนพื้นฐานนี้:

llama-bench -m ~/models/Meta-Llama-3.1-8B-Instruct-Q4_K_M.gguf -p 512 -n 128

คอลัมน์ pp คือความเร็วในการประมวลผลพรอมต์ และคอลัมน์ tg คือความเร็วในการสร้างโทเค็น โดยทั้งคู่มีหน่วยเป็นโทเค็นต่อวินาที บนแผนบริการ vCPU แบบแชร์ โมเดลขนาด 8B ที่ระดับ Q4_K_M มักจะทำความเร็ว tg ได้เพียงเลขหลักเดียว การประมวลผลพรอมต์เป็นส่วนที่ส่งผลกระทบมากที่สุด เนื่องจากพรอมต์ทั้งหมดจะต้องถูกประมวลผลให้เสร็จก่อนที่โทเค็นแรกจะปรากฏ ดังนั้นการใช้ system prompt ที่ยาวจะทำให้เกิดการรอคอยในทุกคำขอ

สิ่งที่ใช้งานบน CPU ได้: โมเดลขนาด 1B ถึง 4B สำหรับงานจำแนกประเภท, การสกัดข้อมูล, การสรุปความสั้นๆ หรือการจัดเส้นทาง (routing) คำตอบจะปรากฏภายในไม่กี่วินาทีและใช้หน่วยความจำในระดับที่แผนบริการทั่วไปรองรับได้ สิ่งที่ไม่ควรใช้งานบน CPU: การแชทโต้ตอบที่ต้องการความเร็วระดับการอ่าน, ผู้ช่วยเขียนโค้ด, งานที่เกี่ยวข้องกับเอกสารยาวๆ หรือกระบวนการใดๆ ที่มี agent loop เรียกใช้งานหลายครั้งต่อเนื่องกัน เพราะลูปที่ต้องเรียกใช้งาน 12 ครั้ง ครั้งละ 4 วินาที จะใช้เวลาถึงหนึ่งนาทีก่อนที่จะได้ผลลัพธ์ใดๆ ออกมา

มีทางออกสองทางเมื่อตัวเลขเหล่านี้ไม่ตอบโจทย์ หากปัญหาคือเรื่อง concurrency หรือผู้ใช้จำนวนมากเรียกใช้โมเดลพร้อมกัน ทางเลือกของเอนจินจะเปลี่ยนไป ซึ่ง การเปรียบเทียบ Ollama กับ vLLM สำหรับการให้บริการพร้อมกัน ได้ครอบคลุมประเด็นนี้ไว้แล้ว หากปัญหาคือความเร็วพื้นฐาน คำตอบคือ VPS ที่ติดตั้ง GPU ซึ่งค่า -ngl จะเริ่มมีความหมายขึ้นมา ก่อนจะเลือกทางใดทางหนึ่ง ควรหาค่าพื้นฐาน (baseline) ของฮาร์ดแวร์นั้นก่อน เพราะแบนด์วิดท์ของดิสก์และหน่วยความจำส่งผลต่อเวลาในการโหลดพอๆ กับ CPU การทำ VPS benchmark ที่ทำซ้ำได้ เป็นสิ่งที่คุ้มค่าที่จะสละเวลาทำสักหนึ่งชั่วโมง

การติดตั้ง llama.cpp โดยล็อกเวอร์ชันของ build

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

curl -LsSf https://llama.app/install.sh | sh
llama serve -hf ggml-org/Qwen3.5-0.8B-GGUF

หากต้องการล็อกเวอร์ชันของ build ให้ดาวน์โหลดไฟล์ tarball ที่คอมไพล์ไว้แล้วจากหน้า releases แทน โดย build b10224 คือแท็กปัจจุบัน ณ วันที่ 2 สิงหาคม 2026:

curl -LO https://github.com/ggml-org/llama.cpp/releases/download/b10224/llama-b10224-bin-ubuntu-x64.tar.gz
tar xf llama-b10224-bin-ubuntu-x64.tar.gz
find . -type f -name 'llama-server'

หรือคอมไพล์จากซอร์สโค้ดโดยใช้แท็กเดียวกัน:

sudo apt update && sudo apt install -y build-essential cmake git libssl-dev
git clone https://github.com/ggml-org/llama.cpp
cd llama.cpp
git checkout b10224
cmake -B build
cmake --build build --config Release -j $(nproc)

libssl-dev คือ dependency ที่ระบุไว้สำหรับฟีเจอร์ HTTPS การคอมไพล์ใช้เวลาหลายนาทีและต้องการ RAM มากกว่าที่แพ็กเกจขนาดเล็กที่สุดจะมีให้ หากเซิร์ฟเวอร์ขนาดเล็กหน่วยความจำไม่พอ ให้คอมไพล์บนเครื่องที่มีขนาดใหญ่กว่าแล้วคัดลอกไฟล์ binary ไปใช้งานแทน

การติดตั้ง Ollama แบบระบุเวอร์ชัน

curl -fsSL https://ollama.com/install.sh | OLLAMA_VERSION=0.32.5 sh
ollama -v

สคริปต์จะอ่านค่าจาก OLLAMA_VERSION ดังนั้นคุณจึงสามารถตรึงเวอร์ชันที่ผ่านการทดสอบแล้วไว้ใช้งาน แทนที่จะรับเวอร์ชันล่าสุดที่เพิ่งปล่อยออกมาในวันนี้ โดยเวอร์ชัน v0.32.5 ได้ถูกเผยแพร่เมื่อวันที่ 27 กรกฎาคม 2026 นอกจากนี้ยังมีวิธีการติดตั้งแบบ manual หากคุณไม่ต้องการส่งสคริปต์ผ่าน pipe เข้าสู่ shell โดยตรง:

sudo rm -rf /usr/lib/ollama
curl -fsSL https://ollama.com/download/ollama-linux-amd64.tar.zst | sudo tar x -C /usr
ollama -v

วิธีการติดตั้งแบบ manual จะไม่สร้าง systemd unit หรือ service user ให้โดยอัตโนมัติ ดังนั้นคุณต้องดำเนินการสร้างส่วนประกอบเหล่านี้ด้วยตนเอง คู่มือการติดตั้ง Ollama บน VPS ฉบับสมบูรณ์ ได้อธิบายขั้นตอนการตั้งค่า service เหล่านี้ไว้โดยละเอียดทีละขั้นตอน

รูปแบบความล้มเหลวและข้อความที่คุณจะพบ

Ollama ปฏิเสธที่จะโหลดโมเดล ollama run จะแสดงบรรทัดในลักษณะนี้:

Error: model requires more system memory (5.6 GiB) than is available (3.2 GiB)

Ollama จะตรวจสอบขนาดก่อนโหลด ดังนั้นระบบจะแจ้งความล้มเหลวทันทีพร้อมระบุสาเหตุ ให้คุณลดระดับ quantisation ลงหนึ่งขั้น, ลดความยาว context หรือเลือกโมเดลที่มีขนาดเล็กลง

llama.cpp ไม่ล้มเหลวแต่ทำงานช้ามาก โดยปกติแล้ว llama.cpp จะทำการ memory-map ไฟล์ GGUF ทำให้ไฟล์ที่มีขนาดใหญ่กว่า RAM สามารถเริ่มทำงานได้ จากนั้น kernel จะทำการสลับข้อมูลน้ำหนัก (weights) เข้าและออกจากดิสก์ในทุกๆ token ส่งผลให้ความเร็วในการสร้างข้อความลดลงเหลือระดับวินาทีต่อ token และดิสก์จะถูกใช้งานเต็ม 100 เปอร์เซ็นต์ ให้ส่งแฟล็ก --no-mmap เพื่อบังคับให้มีการจองหน่วยความจำจริง ระบบจะได้แจ้งความล้มเหลวทันทีแทนที่จะปล่อยให้ประสิทธิภาพลดลง เมื่อ kernel เข้ามาจัดการ dmesg จะแสดงสาเหตุให้เห็น:

Out of memory: Killed process 1234 (llama-server)

ไฟล์โมเดลไม่โหลดเลย ไฟล์ GGUF ที่สร้างขึ้นสำหรับตระกูลโมเดลที่ใหม่กว่า engine ของคุณจะแจ้งข้อผิดพลาดโดยระบุสถาปัตยกรรมที่ไม่รู้จัก:

error loading model architecture: unknown model architecture: 'qwen3next'

วิธีแก้ไขคือการอัปเกรด engine ไม่ใช่การเปลี่ยนไฟล์ นี่คือสิ่งที่ต้องแลกจากการล็อกเวอร์ชัน (pinning) และเป็นเหตุผลว่าทำไมคุณควรจดบันทึก build number ไว้ คุณจำเป็นต้องทราบว่าคุณกำลังอัปเกรดมาจากเวอร์ชันใด

API ตอบสนองในเครื่องได้แต่ไม่ตอบสนองจากแอปของคุณ Ollama ผูกการทำงานไว้ที่ 127.0.0.1:11434 ทำให้โฮสต์อื่นได้รับข้อความ connection refused ให้ตั้งค่า OLLAMA_HOST=0.0.0.0:11434 ผ่าน systemctl edit ollama เฉพาะเมื่อพอร์ตนั้นอยู่หลัง firewall หรือเครือข่ายส่วนตัวเท่านั้น เนื่องจาก API ไม่มีการตรวจสอบสิทธิ์ (authentication) อยู่เบื้องหน้า

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

แล้วคุณควรเลือกใช้งานตัวไหน?

ให้เลือกใช้งาน Ollama เมื่อคุณต้องการให้ระบบจัดการโมเดลให้โดยอัตโนมัติ และต้องการ endpoint ที่มีรูปแบบเหมือน OpenAI โดยไม่ต้องตั้งค่าเพิ่มเติม นี่คือตัวเลือกเริ่มต้นที่เหมาะสมสำหรับการติดตั้งใช้งานครั้งแรก และสำหรับงานที่ต้องมีการเปลี่ยนรุ่นโมเดลอยู่บ่อยครั้ง

ให้เลือกใช้งาน llama.cpp โดยตรงเมื่อมีหน่วยความจำจำกัดจนคุณจำเป็นต้องเลือกแถวของ quantisation ด้วยตนเอง เมื่อคุณต้องการ /health, /slots และ /metrics สำหรับการตรวจสอบระบบ หรือเมื่อคุณต้องการใช้ flag ที่ Ollama ไม่ได้เปิดให้ใช้งาน นี่เป็นตัวเลือกที่ตรงไปตรงมาที่สุดสำหรับการใช้งานบน VPS ที่มีทรัพยากรจำกัดจนแทบจะใส่โมเดลไม่ได้ เพราะการตั้งค่าที่ทำให้โมเดลทำงานได้นั้น คือการตั้งค่าเดียวกับที่ Ollama เลือกให้คุณโดยอัตโนมัติ

การใช้งานทั้งสองตัวควบคู่กันเป็นเรื่องปกติ โดยใช้ Ollama สำหรับการทดลอง และใช้ llama.cpp สำหรับโมเดลตัวเดียวที่คุณนำไปใช้งานจริง (production) และไม่ต้องการให้มีการเปลี่ยนแปลงใดๆ อีก

FAQ

Ollama เป็นเพียง wrapper ของ llama.cpp ใช่หรือไม่?

ใกล้เคียง แต่ wrapper นี้มีการทำงานจริง Ollama ระบุใน README ว่าใช้ llama.cpp เป็น inference backend (ตรวจสอบเมื่อ 2 สิงหาคม 2026) โดย Ollama เพิ่มส่วนประกอบอื่นเข้าไป ได้แก่ model registry, เทมเพลตสำหรับแปลงข้อความแชทเป็น prompt, ชุดพารามิเตอร์การสุ่มตัวอย่างเริ่มต้น, daemon ที่คอยยกเลิกการโหลดโมเดลเมื่อไม่ได้ใช้งาน และ HTTP API เมื่อคุณเปรียบเทียบจำนวน token ต่อวินาทีภายใต้การตั้งค่าที่เหมือนกัน คุณกำลังเปรียบเทียบ engine ตัวเดียวกัน สิ่งที่คุณต้องเลือกจริง ๆ คือส่วนการจัดการ (management layer)

บน VPS ที่ไม่มี GPU ตัวไหนทำงานเร็วกว่ากัน?

ทั้งสองใช้ engine เดียวกัน ดังนั้นหากใช้ไฟล์โมเดล, การทำ quantisation, ขนาด context และจำนวน thread ที่เท่ากัน ประสิทธิภาพจะใกล้เคียงกันมาก ความแตกต่างที่ผู้ใช้รายงานมักเกิดจากการตั้งค่าเริ่มต้นที่ต่างกัน โดยเฉพาะความยาว context และจำนวน thread ไม่ใช่ที่ตัว engine ให้วัดผลด้วย llama-bench -m <file> -p 512 -n 128 และเปรียบเทียบที่คอลัมน์ tg บนเครื่องของคุณเองก่อนที่จะเชื่อตัวเลขที่เผยแพร่ทั่วไป

ฉันสามารถใช้ไฟล์ GGUF ของตัวเองกับ Ollama ได้หรือไม่?

ได้ ให้วางไฟล์ไว้บนเซิร์ฟเวอร์ เขียนไฟล์ Modelfile โดยบรรทัดแรกต้องเป็น FROM ./your-model.gguf เพิ่มบรรทัด PARAMETER ที่จำเป็น เช่น num_ctx จากนั้นรันคำสั่ง ollama create your-name -f ./Modelfile แล้ว ollama ls จะแสดงรายการโมเดลนั้นคู่กับโมเดลที่คุณดึงมาจาก registry นี่คือวิธีที่คุณจะใช้ quantisation ที่ไม่มีใน registry

ต้องใช้ RAM เท่าไหร่สำหรับโมเดลขนาด 8B?

ให้คำนวณจากขนาดไฟล์ รวมกับ KV cache และหน่วยความจำขณะรัน (runtime) โมเดล Llama 3.1 8B แบบ Q4_K_M มีขนาดประมาณ 4.58 GiB บนดิสก์ และ context ขนาด 4096 token จะใช้ cache เพิ่มอีกประมาณ 512 MiB ดังนั้น RAM ขนาด 8 GiB จึงเพียงพอ แต่ 4 GiB ไม่เพียงพอ ขนาดของ cache จะแปรผันตาม context โดยโมเดลเดียวกันที่ context 32,768 token จะใช้ cache ประมาณ 4 GiB สำหรับ Ollama ต้องจำไว้ว่าความต้องการทรัพยากรจะเพิ่มขึ้นตาม OLLAMA_NUM_PARALLEL ด้วยเช่นกัน