รัน Ollama หรือ LLM ขนาดเล็กบน VPS แบบ vCPU เฉพาะโดยไม่มี GPU ได้ไหม?

โมเดลไหนพอดีกับ RAM ของแต่ละแพ็กเกจ?

บน CPU นั้น RAM เป็นตัวกำหนดว่าโมเดลไหนรันได้ ส่วน vCPU กำหนดว่ารันได้เร็วแค่ไหน โมเดลทั้งก้อนอยู่ในหน่วยความจำระบบ และขนาดดาวน์โหลดที่ Ollama แสดงเป็นค่าประมาณแรกที่ดีของหน่วยความจำที่ต้องใช้ context ระบบ และอย่างอื่นบน VPS เพิ่มเข้ามาด้วย: เอกสารของ Ollama ระบุว่า RAM ที่ต้องใช้เพิ่มขึ้นตาม OLLAMA_NUM_PARALLEL คูณ OLLAMA_CONTEXT_LENGTH และ context เริ่มต้นคือ 4,096 tokens

LLM inference บน CPU เร็วแค่ไหน?

CPU inference ช้ากว่า GPU ในระดับที่กำหนดโดย threads แบนด์วิดท์หน่วยความจำ และ quantization Cobaltfell ไม่ได้เผยแพร่ตัวเลข tokens-per-second ของตัวเอง: ผล YABS และ Geekbench 6 ของเราเอง พร้อมด้วย steal time ที่เราวัดได้ จะถูกเผยแพร่พร้อมวันที่เมื่อเครื่องทดสอบเครื่องแรกของเราส่งมอบแล้ว จนถึงตอนนั้นเราจะไม่กล่าวอ้างตัวเลขประสิทธิภาพใดๆ ของเราเอง

ตัวเลขสาธารณะที่มีประโยชน์ที่สุดคือการทดสอบที่ Leaseweb เผยแพร่เมื่อ 5 เมษายน 2026 (หน้าอัปเดตเมื่อ 20 สิงหาคม 2026) บนเซิร์ฟเวอร์ที่มีโปรเซสเซอร์ AMD EPYC 9334 สองตัว (Zen 4) รัน 24 threads การทดสอบสร้าง 27.8 tokens per second ด้วยโมเดล 8B ที่ quantization 4-bit (DeepSeek-R1-0528-Qwen3-8B, Q4_K_M) และ 8.1 tokens per second ด้วยโมเดลเดียวกันที่ FP16 GPU NVIDIA L4 ทำได้ 16.7 tokens per second กับโมเดลนั้นที่ FP16 เวลาถึง token แรกที่ Q4 อยู่ระหว่าง 3.6 ถึง 4.8 วินาทีในบรรดาโมเดลที่ทดสอบ

จะรัน Ollama บน VPS ที่มีเฉพาะ CPU ได้อย่างไร?

ติดตั้ง Ollama ด้วยสคริปต์ทางการ ดึงโมเดลที่พอดีกับแพ็กเกจ และยืนยันว่าทำงานบน CPU ทั้งหมด ollama ps แสดงว่าโมเดลที่โหลดอยู่เก็บไว้ที่ใด คอลัมน์ PROCESSOR ของมันแสดง 100% CPU บน VPS Ollama ฟังที่ 127.0.0.1 พอร์ต 11434 โดยค่าเริ่มต้น เข้าถึงผ่าน SSH tunnel หรือวาง reverse proxy ที่มีการยืนยันตัวตนไว้ข้างหน้าก่อนเปลี่ยน OLLAMA_HOST

# official install script for Linux
curl -fsSL https://ollama.com/install.sh | sh

# pull and run a model that fits the plan (here about 2.5 GB)
ollama run qwen3:4b "Summarize what a dedicated vCPU is in one sentence."

# where the model is loaded: expect 100% CPU
ollama ps

# service settings: add these two lines under [Service]
sudo systemctl edit ollama
#   Environment="OLLAMA_CONTEXT_LENGTH=4096"
#   Environment="OLLAMA_NUM_PARALLEL=1"
sudo systemctl daemon-reload
sudo systemctl restart ollama

ควรใช้ llama.cpp โดยตรงไหม?

llama.cpp คือตัวเลือกเมื่อ quantization จำนวน threads และ server flags มีความสำคัญ README ของมันระบุการรองรับ AVX, AVX2, AVX512 และ AMX บน x86 และ integer quantization ตั้งแต่ 1.5-bit ถึง 8-bit เพื่อลดการใช้หน่วยความจำและเพิ่มความเร็วในการ inference มันมาพร้อม llama-bench เครื่องมือทดสอบประสิทธิภาพที่ค่าเริ่มต้นประมวลผล prompt 512 tokens และสร้าง 128 tokens และลองจำนวน threads หลายค่าในการรันครั้งเดียว

การตรวจสอบสองอย่างใช้เวลาไม่ถึงนาทีบน VPS ใดก็ได้: คำสั่ง vector ใดที่โปรเซสเซอร์เปิดให้ใช้ และโมเดลทำงานเร็วขึ้นเมื่อใช้ threads เท่าจำนวน vCPU หรือหนึ่ง thread ต่อหนึ่ง physical core ที่ Cobaltfell vCPU หนึ่งตัวคือหนึ่ง hardware thread ของโปรเซสเซอร์โฮสต์ vCPU ของคุณถูก pin แบบหนึ่งต่อหนึ่งเข้ากับ VPS ของคุณและไม่ถูกให้เช่าต่อให้ลูกค้ารายอื่น และสอง thread ของ physical core หนึ่งตัวจะอยู่ด้วยกันเสมอ ดังนั้นทุก 2 vCPU จึงรวมเป็นหนึ่ง whole core ที่ไม่มีเพื่อนบ้านมาแชร์ ดังนั้น Fell 16 ให้ 16 threads บน 8 cores เพื่อเปรียบเทียบ กฎนี้อธิบายไว้ใน dedicated vCPU คือ core หรือ thread

# vector instructions the VPS can use
grep -o -w -E 'avx2|avx512f|avx512_bf16|amx_tile' /proc/cpuinfo | sort -u

# prompt 512 tokens, generate 128, on 8 and then 16 threads
llama-bench -m qwen3-8b-q4_k_m.gguf -p 512 -n 128 -t 8,16

dedicated vCPU เปลี่ยนอะไรสำหรับ inference?

การ generate ทำให้ทุก thread ทำงานเต็มที่ตลอดความยาวของคำตอบ ดังนั้นเวลา CPU ที่สูญเสียไปกลายเป็น tokens ที่ช้าลงโดยตรง บน shared vCPU การ burst ของเพื่อนบ้านทำให้แต่ละคำตอบยาวขึ้นในรูปของ steal time อธิบายไว้ใน CPU steal time คืออะไรและตรวจสอบบน VPS อย่างไร และเพดาน fair-use สำหรับช่วง full-load ยาวๆ จะจำกัด inference ก่อน

ที่ Cobaltfell: ใช้โหลดเต็มที่ได้ตลอดตราบเท่าที่งานของคุณต้องการ: ไม่มี CPU credit ไม่มีช่วง burst และไม่มีการ throttling หลังจากใช้งานที่ 100% ไปสักพัก RAM ของแพ็กเกจของคุณถูกกันไว้สำหรับ VPS ของคุณและไม่มีการ overcommit ดังนั้นโมเดลที่โหลดอยู่จะไม่ถูก host ดันออกจาก RAM โปรเซสเซอร์ família คือ AMD EPYC 9004/9005 (Zen 4 / Zen 5) การรันโมเดลที่ 100% เป็นสิ่งที่อนุญาต เส้นแบ่งอยู่ที่อื่น: ไม่อนุญาตให้ขุด cryptocurrency ใดๆ ในทุกแพ็กเกจและด้วยซอฟต์แวร์ใดๆ งาน CPU หนักของคุณเอง เช่น การ build, การ encode, การ inference หรือฐานข้อมูล สามารถทำงานที่โหลดเต็มได้ และโหนดที่ทำหน้าที่เพียง validate blockchain ไม่ถือเป็นการขุด

โฮสต์ที่ขาย dedicated vCPU และราคาต่อหนึ่ง core เปรียบเทียบไว้ใน dedicated CPU VPS ราคาต่อ core เท่าไรในพฤศจิกายน 2026

เมื่อไรที่ GPU คือคำตอบที่ถูกต้องสำหรับ LLM?

GPU คือคำตอบที่ถูกต้องเมื่อความเร็วต่อผู้ใช้ จำนวนผู้ใช้ หรือขนาดของโมเดลสำคัญกว่าต้นทุน การทดสอบของ Leaseweb ลากเส้นเดียวกัน: CPU เหมาะกับงานแบบ batch, asynchronous และงานเบา ขณะที่ GPU ยังนำสำหรับงานที่ไวต่อ latency, การทำงานพร้อมกันสูง และโมเดลที่เกิน 20B parameters โดยไม่ทำ quantization อีกสามกรณีชี้ไปที่ GPU:

• โมเดลใหญ่กว่า RAM Fell 16 มี 32 GB; โมเดล 70B ที่ 43 GB ไม่พอดีกับแพ็กเกจใดเลย
• Prompt ยาว Retrieval และ document chat ป้อนหลายพัน tokens ก่อนคำแรก และช่วง prompt นั้นคือที่ที่ CPU รอนานที่สุด
• Training และ fine-tuning ในทางปฏิบัติแล้วเป็นงานของ GPU

Cobaltfell ไม่ขาย GPU สำหรับกรณีเหล่านั้น GPU server คือสิ่งที่ควรเช่า โดยเก็บ CPU VPS ไว้สำหรับ API, queue และ vector database รอบๆ โมเดล การเข้ารหัสวิดีโอยกคำถามเดียวกันขึ้นมา ตอบไว้ใน VPS แปลงวิดีโอด้วย FFmpeg ได้โดยไม่มี GPU ไหม