เปรียบเทียบ Ollama กับ llama.cpp บน VPS เลือกตัวไหนดี

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

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

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

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

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

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

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

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

การทำ Quantisation คือการจัดเก็บค่าน้ำหนัก (weights) ด้วยจำนวนบิตที่น้อยกว่า 16 หรือ 32 บิตของโมเดลต้นฉบับ โดยไฟล์ GGUF ทั่วไปจะมีค่าเฉลี่ยอยู่ที่ประมาณ 4, 5 หรือ 8 บิตต่อหนึ่งค่าน้ำหนัก ความละเอียดของข้อมูลในไฟล์จะไม่เท่ากันทั้งหมด ในซอร์สโค้ดตัวทำ Quantisation ของ llama.cpp (อ่านเมื่อ 27 ตุลาคม 2026) การ build แบบ Q4_K_M จะเก็บ tensor ส่วนใหญ่ไว้ที่ 4-bit แต่จะให้ output layer รวมถึง attention value และ feed-forward down tensor ในประมาณครึ่งหนึ่งของเลเยอร์ทั้งหมดเป็น 6-bit Q6_K แทน ในขณะที่ tensor ขนาดเล็กอย่าง norms จะไม่ถูกทำ quantisation เลย นี่คือเหตุผลที่โมเดลขนาด 8 พันล้านพารามิเตอร์สามารถรันบน RAM ของ VPS ทั่วไปได้ การตั้งชื่อไฟล์ GGUF จะอ่านเข้าใจได้ง่ายเมื่อทราบรูปแบบ: Q4_K_M หมายถึง K-quant ขนาด 4-bit รุ่นขนาดกลาง ตัวเลขที่สูงกว่าจะรักษาความละเอียดได้มากกว่าและใช้หน่วยความจำมากขึ้น

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

สำหรับ Ollama การทำ quantisation จะมาพร้อมกับแท็กที่คุณดึงมา และ ollama ls จะแสดงสิ่งที่คุณมีอยู่จริงบนดิสก์ ในกรณีที่ registry ไม่มีรุ่นที่คุณต้องการ คุณสามารถ import ไฟล์ 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 นาทีแล้วจึงถูกยกเลิกการโหลด คำขอถัดไปจะต้องโหลดไฟล์ทั้งหมดใหม่อีกครั้งก่อนที่จะประมวลผลได้ หาก kernel ยังคงเก็บไฟล์ไว้ใน page cache การโหลดจะรวดเร็ว แต่จะมีเพียง RAM ที่เหลืออยู่เท่านั้นที่เก็บไฟล์นั้นไว้ได้ และเมื่อมีการทำงานอื่นเข้ามาแทนที่ ไฟล์จะต้องถูกอ่านจากดิสก์ใหม่ ดังนั้นการโหลดไฟล์ขนาด 4.58 GiB ซ้ำจะเปลี่ยนเวลาตอบสนองจาก 2 วินาทีเป็น 30 วินาทีบนที่เก็บข้อมูลที่ช้า การตั้งค่า keep-alive ให้นานขึ้นจะช่วยแก้ปัญหาความหน่วงและใช้ RAM อย่างถาวร ทั้งสองทางเลือกมีต้นทุนที่ต้องแลก ให้เลือกทางที่ส่งผลกระทบน้อยกว่า หากคุณตัดสินใจว่าโมเดลควรอยู่ในหน่วยความจำตลอดเวลา การตั้งค่า keep_alive เพื่อให้คงอยู่ผ่านช่วงเวลาว่างและการรีบูต จะใช้เพียงไม่กี่บรรทัดและช่วยให้คุณไม่ต้องโหลดโมเดลด้วยตัวเองทุกครั้งที่เซิร์ฟเวอร์รีสตาร์ท

llama.cpp ไม่มี daemon หรือ service user มาให้ คุณจึงต้องตั้งค่าเองทั้งหมด จากไดเรกทอรี llama.cpp ที่คุณใช้ build โปรแกรม ให้ติดตั้ง binary และไลบรารีลงใน /usr/local สร้างผู้ใช้ llama และคัดลอกโมเดลให้ผู้ใช้นั้น:

sudo cmake --install build
sudo ldconfig
sudo useradd --system --no-create-home --shell /usr/sbin/nologin llama
sudo install -d -o llama -g llama /srv/models
sudo install -o llama -g llama -m 644 ~/models/Meta-Llama-3.1-8B-Instruct-Q4_K_M.gguf /srv/models/model-Q4_K_M.gguf

หากคุณใช้ release archive แทนการ build ให้ชี้ ExecStart ไปที่ llama-server ภายใน archive นั้น เนื่องจาก archive จะเก็บไลบรารีไว้คู่กับ binary จากนั้นให้เขียน 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 กระบวนการนี้จะเก็บโมเดลไว้ตลอดอายุการทำงาน โดยปกติจะไม่มีการยกเลิกการโหลดเมื่อว่าง แต่การเพิ่ม --sleep-idle-seconds จะช่วยให้สามารถยกเลิกและโหลดใหม่โดยอัตโนมัติโดยไม่ต้องหยุด service หากการเขียน unit ไฟล์เป็นเรื่องใหม่สำหรับคุณ รูปแบบการทำงานจะเหมือนกับ การรัน service ของคุณเองภายใต้ systemd บน VPS

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

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

Ollama รับ network traffic ที่ 127.0.0.1:11434 โดยมี route ที่เข้ากันได้กับ OpenAI อยู่ที่ http://localhost:11434/v1/chat/completions และมี native API ที่ /api/chat ควบคู่กัน นอกจากนี้ยังมีการระบุเอกสารสำหรับ route ที่เข้ากันได้กับ Anthropic ด้วย อย่างไรก็ตาม route เหล่านี้ไม่เปิดให้โมเดลค้นข้อมูลด้วยตนเอง ดังนั้นหากแอปต้องการคำตอบที่ใหม่กว่าข้อมูลฝึกของโมเดล ควรวางแผน เชื่อมการค้นเว็บผ่าน API ของ Ollama, Open WebUI หรือ tool loop แบบสั้น

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 หากไม่กำหนดค่าใดๆ เพิ่มเติม ปัจจุบันระบบจะใช้พอร์ต 9931 เป็นค่าเริ่มต้น (ตรวจสอบเมื่อวันที่ 27 ตุลาคม 2026) ดังนั้นให้คง --port ไว้ในบรรทัดคำสั่งหากแอปพลิเคชันของคุณคาดหวังพอร์ต 8080 ระบบจะให้บริการ /v1/chat/completions, /v1/completions และ /v1/embeddings รวมถึงมี endpoint เฉพาะตัวคือ /completion และเว็บ UI ในตัว นอกจากนี้ยังเปิดเผยเส้นทางสำหรับการปฏิบัติงานที่ Ollama ไม่มี ได้แก่ /health สำหรับการตรวจสอบความพร้อม (readiness probe), /props สำหรับการตั้งค่าโมเดลที่โหลดอยู่, /slots สำหรับสถานะการทำงานของแต่ละ request slot และ /metrics ในรูปแบบ Prometheus เมื่อคุณเพิ่ม --metrics เนื่องจาก endpoint นี้ถูกปิดใช้งานเป็นค่าเริ่มต้น หากคุณวางแผนที่จะตรวจสอบสถานะบริการนี้ ความแตกต่างดังกล่าวอาจเป็นปัจจัยตัดสินใจเลือก

เซิร์ฟเวอร์ทั้งสองตัวไม่ได้เปิดใช้งานการยืนยันตัวตนให้คุณโดยอัตโนมัติ ทั้งคู่ตั้งค่าเริ่มต้นให้รับเฉพาะ 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 จะใช้เวลาประมวลผลนานถึง 200 วินาที หรือกว่าสามนาทีเฉพาะขั้นตอนการสร้างคำตอบ ดังนั้น การจำกัดผลลัพธ์ด้วย num_predict จึงเป็นวิธีที่ประหยัดที่สุดในการป้องกันไม่ให้คำตอบที่ยาวเกินไปทำให้เกิด timeout

สิ่งที่ใช้งานได้บน CPU: โมเดลขนาด 1B ถึง 4B สำหรับงานจำแนกประเภท, การสกัดข้อมูล, การสรุปความสั้นๆ หรือการจัดเส้นทาง (routing) คำตอบจะปรากฏในเวลาไม่กี่วินาทีและใช้หน่วยความจำในระดับที่แผนบริการปกติรองรับได้ สำหรับตัวอย่างการใช้งานจริงแทนการคาดคะเนช่วงขนาด การดึงและวัดผล Nemotron 3.5 Lightning บน VPS ได้ระบุ tag ที่แน่นอน, ปริมาณ RAM ที่ต้องการจริง และความเร็วที่ทำได้โดยไม่มี GPU สิ่งที่ไม่สามารถใช้งานบน CPU ได้: การแชทโต้ตอบที่ความเร็วระดับการอ่าน, ผู้ช่วยเขียนโค้ด, งานที่เกี่ยวกับเอกสารยาวๆ หรือสิ่งใดก็ตามที่มี agent loop ทำงานหลายคำขอต่อเนื่องกัน ลูปที่ทำ 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 แทน ปัจจุบันโปรเจกต์มีการเผยแพร่เวอร์ชันแบบ semantic versioning แล้ว โดย v0.7.0 เป็นเวอร์ชันล่าสุดเมื่อวันที่ 27 ตุลาคม 2026 ซึ่งหน้า release ระบุให้ใช้ nightly b11669 สำหรับไฟล์ binary ส่วน v0.8.0 ตามมาในวันที่ 28 ตุลาคม 2026 โดยหน้า release ระบุให้ใช้ nightly b11960 สำหรับไฟล์ binary คำสั่งด้านล่างนี้ใช้ b10224 ซึ่งเป็น tag ล่าสุด ณ วันที่ 2 สิงหาคม 2026 ให้เปลี่ยนเป็น tag ที่คุณได้ทดสอบแล้ว:

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'

หรือคอมไพล์จาก source ด้วย 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 เวอร์ชันเก่าจะตรวจสอบขนาดก่อนโหลด และ ollama run จะแสดงบรรทัดในรูปแบบนี้:

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

ซอร์สโค้ดปัจจุบันของ Ollama ไม่แสดงข้อความดังกล่าวแล้ว (ตรวจสอบเมื่อ 27 ตุลาคม 2026) ปัจจุบัน Ollama ส่งต่อการโหลดไปยัง llama-server ดังนั้นหากโมเดลมีขนาดใหญ่เกินไปจะแสดงเป็นความล้มเหลวของ runner แทน โดยมีข้อความผิดพลาดเริ่มต้นดังนี้:

llama-server reported out-of-memory during startup
llama-server process has terminated

ไม่ว่าจะกรณีใด วิธีแก้ไขคือวิธีเดียวกัน ให้ลดระดับ quantisation ลง, ลดความยาว context หรือเลือกโมเดลที่มีขนาดเล็กลง

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

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

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

llama_model_load: error loading model: unknown model architecture: '<arch>'

วิธีแก้ไขคือการอัปเกรด 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 นาที และโมเดลกำลังถูกโหลดใหม่อีกครั้งจาก disk หาก page cache ไม่ได้เก็บข้อมูลไว้ การรัน 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 (ตรวจสอบเมื่อ 27 ตุลาคม 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 ด้วยเช่นกัน