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

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

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

ให้รัน Ollama เมื่อคุณต้องการบริการที่สามารถดึงโมเดลตามชื่อและทำงานต่อไปได้โดยไม่ต้องคอยดูแล ส่วนการรัน llama.cpp โดยตรงนั้นเหมาะสำหรับกรณีที่เซิร์ฟเวอร์มีทรัพยากรจำกัด และคุณจำเป็นต้องเลือกไฟล์โมเดล ขนาดบริบท (context size) และจำนวนเธรด (thread count) ที่แม่นยำ เพราะบน 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 โดยแท็กปัจจุบันคือ b10224 ซึ่งเผยแพร่เมื่อวันที่ 2 สิงหาคม 2026 และจะมีแท็กใหม่เกิดขึ้นเกือบทุกวันทำการ

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

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

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

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

[
  {
    "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
  }
]

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

เมื่อใช้ 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 จะมาพร้อมกับแท็กที่คุณดึงมา และ ollama ls จะแสดงสิ่งที่คุณมีอยู่จริงบนดิสก์ ในกรณีที่ registry ไม่มีบิลด์ที่คุณต้องการ คุณสามารถนำเข้าไฟล์ 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 หากมีเพียงงานเดียวที่ต้องการหน้าต่างบริบทที่ใหญ่ขึ้น num_ctx สามารถตั้งค่าแยกเป็นรายคำขอแทนการตั้งค่าทั้งเซิร์ฟเวอร์ได้ ซึ่งจะช่วยป้องกันไม่ให้ cache ส่วนเกินไปรบกวนงานอื่นๆ ที่ daemon ต้องทำ สำหรับ 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 ในขณะที่โหลดโมเดล และอย่าเชื่อการประมาณการที่คุณไม่ได้วัดผลด้วยตัวเอง หากคุณกำลังวางแผนสำหรับโมเดลที่ใหญ่กว่า 8B การคำนวณแบบเดียวกันที่ใช้กับ โมเดล 27B บน VPS ที่ใช้เฉพาะ CPU จะแสดงให้เห็นว่าหน่วยความจำแต่ละระดับตั้งแต่ 8 ถึง 64 GB รองรับการทำงานได้จริงเพียงใด

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

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

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 chat format ทำให้ไลบรารีฝั่งไคลเอนต์ส่วนใหญ่สามารถใช้งานกับทั้งสองระบบได้โดยเพียงแค่เปลี่ยน 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) บริการนี้ ความแตกต่างดังกล่าวอาจเป็นปัจจัยตัดสินใจหลัก

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

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

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

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

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

สิ่งที่ใช้งานได้บน CPU: โมเดลขนาด 1B ถึง 4B สำหรับงานจำแนกประเภท, การสกัดข้อมูล, การสรุปความสั้นๆ หรือการจัดเส้นทาง คำตอบจะปรากฏในเวลาไม่กี่วินาทีและใช้หน่วยความจำในระดับที่แผนปกติรองรับ สำหรับตัวอย่างการใช้งานจริงในขนาดดังกล่าวแทนที่จะเป็นช่วงขนาด Nemotron 3.5 Lightning ที่ถูกดึงมาและวัดผลบน VPS จะระบุ tag ที่แน่นอน, ปริมาณ RAM ที่ต้องการจริง และความเร็วที่ทำได้โดยไม่มี GPU สิ่งที่ใช้งานไม่ได้บน CPU: การแชทโต้ตอบที่ความเร็วระดับการอ่าน, ผู้ช่วยเขียนโค้ด, งานเอกสารขนาดยาว หรือสิ่งใดก็ตามที่มีลูปของ agent ที่ต้องเรียกใช้งานต่อเนื่องกันหลายครั้ง ลูปที่เรียกใช้งาน 12 ครั้ง ครั้งละ 4 วินาที จะใช้เวลาถึงหนึ่งนาทีก่อนที่จะได้ผลลัพธ์ใดๆ หากแผนเดิมคือการใช้ผู้ช่วยเขียนโค้ด การชี้ agent ไปยังโมเดลที่คุณโฮสต์เอง จะช่วยระบุว่างานใดที่โมเดลขนาดเล็กในเครื่องทำได้ดีจริง และงานใดที่ยังจำเป็นต้องใช้ hosted API

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

การติดตั้ง llama.cpp โดยระบุเวอร์ชันที่แน่นอน

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

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

หากต้องการระบุเวอร์ชันของ build ให้ดาวน์โหลดไฟล์ tarball ที่คอมไพล์ไว้แล้วจากหน้า releases แทน โดย build b10224 คือ tag ปัจจุบัน ณ วันที่ 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'

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

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 length หรือเลือกโมเดลที่มีขนาดเล็กลง

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 ไว้ คุณจำเป็นต้องทราบว่าคุณกำลังอัปเกรดมาจากเวอร์ชันใด

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

การตอบกลับครั้งแรกหลังจากหยุดพักไปนานนั้นช้ามาก เกิดจากการที่ระบบ 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 นี้มีการทำงานจริงอยู่เบื้องหลัง README ของ Ollama ระบุว่า llama.cpp เป็น inference backend ของตน (ตรวจสอบเมื่อ 2 สิงหาคม 2026) โดย Ollama ได้เพิ่มส่วนประกอบอื่นเข้าไป ได้แก่ model registry, เทมเพลต prompt ที่แปลงข้อความแชทให้เป็น prompt, ชุดพารามิเตอร์การสุ่มตัวอย่าง (sampling parameters) เริ่มต้น, 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 ด้วยเช่นกัน