เปรียบเทียบ Ollama กับ vLLM เลือกตัวไหนสำหรับรัน LLM

การเปรียบเทียบระหว่าง Ollama และ vLLM

Ollama ทำหน้าที่เป็นตัวจัดการโมเดลที่มีเซิร์ฟเวอร์ในตัว โดยจะดาวน์โหลด weight ที่ผ่านการทำ quantization มาโหลดใช้งานและตอบสนองผ่าน 127.0.0.1:11434 ซึ่งสามารถทำงานบน CPU ได้หากเครื่องไม่มี GPU ในขณะที่ vLLM เป็นเอนจินสำหรับเพิ่ม throughput โดยเน้นการใช้ GPU ให้เต็มประสิทธิภาพเพื่อประมวลผลหลายคำขอพร้อมกัน จึงไม่เหมาะสำหรับเครื่องที่ไม่มี GPU นี่คือเกณฑ์การตัดสินใจหลัก หากเป็นการใช้งานส่วนตัวเพื่อคุยกับผู้ช่วยอัจฉริยะ Ollama คือตัวเลือกที่เหมาะสม แต่หากเป็นการให้บริการแอปพลิเคชันสำหรับทีมงาน vLLM จะเป็นตัวเลือกที่ตอบโจทย์กว่า ทั้งสองเครื่องมือรองรับ HTTP API ที่เข้ากันได้กับ OpenAI ทำให้สามารถสลับใช้งานได้เพียงแค่เปลี่ยน base URL ดังนั้นความแตกต่างจึงไม่ได้อยู่ที่ตัว API แต่อยู่ที่วิธีการจัดการเมื่อมีคำขอที่สองเข้ามาในขณะที่คำขอแรกยังคงสร้าง token อยู่

Ollama คืออะไร

Ollama เป็นเลเยอร์ที่ช่วยอำนวยความสะดวก โดยรวมเอา registry ของโมเดล (ollama pull llama3.1:8b), พื้นที่จัดเก็บ weight ในเครื่อง, อินเทอร์เฟซสำหรับแชท, บริการ systemd และ HTTP API ไว้ในการติดตั้งเพียงคำสั่งเดียว โมเดลที่ให้บริการอยู่ในรูปแบบไฟล์ GGUF ซึ่งมักจะผ่านการทำ quantization แบบ 4-bit ส่งผลให้โมเดลขนาด 7B หรือ 8B ใช้พื้นที่บนดิสก์เพียงประมาณ 5 GB แทนที่จะเป็น 16 GB การทำ quantization คือสิ่งที่ทำให้การประมวลผล (inference) บน CPU สามารถทำได้จริง

ตัวรันไทม์ของ Ollama สร้างขึ้นบน llama.cpp ซึ่งเป็นไลบรารี C++ สำหรับการประมวลผลที่ทำให้การทำ quantization แบบ GGUF ใช้งานได้จริงบนฮาร์ดแวร์ทั่วไป แม้ว่าภายหลัง Ollama จะเพิ่มเอนจินของตนเองสำหรับโมเดลรุ่นใหม่ๆ บางตระกูล แต่ llama.cpp ก็ยังคงเป็นโครงสร้างพื้นฐานหลักของบริการส่วนใหญ่ ดังนั้นเมื่อมีการเปรียบเทียบระหว่าง Ollama กับ llama.cpp สิ่งที่เปรียบเทียบกันส่วนใหญ่คือเลเยอร์ที่เน้นความสะดวกในการใช้งานกับตัวไลบรารีที่ถูกครอบไว้อีกที

เป้าหมายการออกแบบของ Ollama คือการใช้งานสำหรับผู้ใช้คนเดียว ณ เดือนกรกฎาคม 2026 ค่าเริ่มต้นสำหรับ OLLAMA_NUM_PARALLEL คือ 1 ซึ่งหมายความว่าโมเดลหนึ่งตัวจะประมวลผลคำขอได้ทีละรายการ และคำขออื่นๆ จะต้องรออยู่ในคิวซึ่งรองรับได้สูงสุด 512 รายการตามค่าเริ่มต้น (OLLAMA_MAX_QUEUE) คุณสามารถเพิ่มค่าการประมวลผลแบบขนานได้ แต่ส่วนถัดไปจะอธิบายถึงผลกระทบที่ตามมา หากคุณยังไม่เคยใช้งาน Ollama มาก่อน ให้เริ่มต้นที่ การโฮสต์ Ollama บน VPS และการปิดพอร์ต 11434 เนื่องจาก API ของ Ollama ไม่มีการตรวจสอบสิทธิ์ใดๆ ทั้งสิ้น

vLLM คืออะไร

vLLM เป็นเพียง inference server เท่านั้น มันไม่ได้ทำหน้าที่จัดการคลังโมเดล ไม่มีหน้าจอแชท และจะไม่ดาวน์โหลดโมเดลให้คุณในขณะที่ส่งคำขอ คุณต้องระบุชื่อ Hugging Face repository ในขณะเริ่มทำงาน จากนั้นมันจะโหลดโมเดลนั้นขึ้นมาและให้บริการจนกว่าคุณจะหยุดกระบวนการ

สิ่งที่คุณได้รับจากการจำกัดขอบเขตการทำงานนี้คือ throughput โดยมีกลไกหลัก 2 อย่างที่ช่วยเพิ่มประสิทธิภาพ: PagedAttention จะจัดเก็บ KV cache (key-value cache ซึ่งเป็นสถานะ attention ต่อโทเค็นที่โมเดลเก็บไว้สำหรับทุกคำขอที่กำลังทำงาน) ไว้ในบล็อกที่มีขนาดคงที่ คล้ายกับการทำ paging หน่วยความจำของระบบปฏิบัติการ ทำให้คำขอไม่จำเป็นต้องจองพื้นที่หน่วยความจำขนาดใหญ่แบบต่อเนื่องเพื่อรองรับกรณีที่เลวร้ายที่สุดอีกต่อไป ส่งผลให้หน่วยความจำที่เคยถูกจองไว้แต่ไม่ได้ใช้งานถูกนำมาใช้รองรับคำขอพร้อมกันได้มากขึ้น ส่วน Continuous batching ช่วยให้คำขอใหม่สามารถเข้าร่วม batch ที่กำลังทำงานอยู่ได้ทันทีในขั้นตอนการถอดรหัสถัดไป แทนที่จะต้องรอให้ batch ปัจจุบันทำงานเสร็จสิ้น เมื่อลำดับงานเสร็จสิ้นก็จะออกจาก batch ทันทีและมีช่องว่างให้คำขออื่นเข้ามาแทนที่

ผลลัพธ์ในทางปฏิบัติคือ บน GPU หนึ่งตัว การเพิ่มจำนวนผู้ใช้พร้อมกันจาก 1 คนเป็น 30 คนจะช่วยเพิ่มจำนวนโทเค็นต่อวินาทีโดยรวมขึ้นอย่างมาก ในขณะที่ความเร็วต่อผู้ใช้จะลดลงน้อยกว่าที่คุณคาดไว้ ในขณะที่ค่าเริ่มต้นของ Ollama การเพิ่มผู้ใช้จาก 1 คนเป็น 30 คนจะทำให้ผู้ใช้ 29 คนต้องรอคิวเท่านั้น

Continuous batching คือความแตกต่างทั้งหมด

ลองจินตนาการถึงคำขอ 5 รายการที่เข้ามายังเซิร์ฟเวอร์พร้อมกันบนฮาร์ดแวร์ที่เหมือนกันทุกประการ

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

vLLM จะถอดรหัสคำขอทั้ง 5 รายการใน forward pass เดียวกัน การสร้างหนึ่งโทเค็นสำหรับ 5 ลำดับข้อมูลมีต้นทุนแทบไม่ต่างจากการสร้างหนึ่งโทเค็นสำหรับลำดับเดียว เนื่องจากส่วนที่ใช้ทรัพยากรสูงคือการอ่านค่าน้ำหนัก (weights) ของโมเดลออกจากหน่วยความจำ ซึ่งการอ่านนี้จะถูกแชร์ร่วมกันทั้ง batch นี่คือข้อเท็จจริงเรื่อง memory-bandwidth เดียวกันกับที่ทำให้การทำ inference บน CPU ทำงานได้ช้า เพราะคุณต้องจ่ายต้นทุนในการย้ายข้อมูลน้ำหนัก ไม่ใช่การคำนวณทางคณิตศาสตร์

คุณสามารถตั้งค่า OLLAMA_NUM_PARALLEL=4 เพื่อให้ได้ผลลัพธ์ในลักษณะนี้ได้บ้าง แต่สิ่งที่ต้องแลกคือหน่วยความจำ แต่ละช่องสัญญาณแบบขนาน (parallel slot) จำเป็นต้องมี KV cache ของตัวเอง และ Ollama จะแบ่ง context window ออกตามจำนวนช่องสัญญาณ ดังนั้นคำขอแบบขนาน 4 รายการบนโมเดลที่กำหนดค่าไว้ที่ 8192 โทเค็น จะเหลือพื้นที่ context ให้แต่ละคำขอเพียง 2048 โทเค็นเท่านั้น ค่า 8192 นั้นเป็นตัวเลือกที่กำหนดขึ้นเองไม่ใช่ค่าตายตัว ดังนั้น การเพิ่ม num_ctx และการคำนวณขนาด RAM ที่ต้องใช้ จึงเป็นขั้นตอนที่ตัดสินว่าช่องสัญญาณทั้ง 4 จะสามารถใช้งานได้จริงหรือไม่ ระบบ paged cache ของ vLLM คือสิ่งที่ช่วยหลีกเลี่ยงการแลกเปลี่ยนทรัพยากรนี้ เนื่องจากบล็อกหน่วยความจำจะถูกจัดสรรให้กับคำขอตามการขยายตัวจริงของคำขอนั้นๆ ไม่ว่าจะด้วยวิธีใด เพดานของจำนวนผู้ใช้งานที่เซิร์ฟเวอร์เครื่องเดียวจะรองรับได้พร้อมกันนั้นขึ้นอยู่กับขนาดของ KV cache, ต้นทุนในการทำ prefill และความลึกของคิว ซึ่งเป็น เหตุผลว่าทำไมเซิร์ฟเวอร์ที่เคยใช้งานได้ดีสำหรับคนเดียวถึงทำงานช้าลงอย่างมากเมื่อมีผู้ใช้ 5 คน

การติดตั้งและให้บริการด้วย Ollama

curl -fsSL https://ollama.com/install.sh | sh
ollama pull llama3.1:8b
ollama run --verbose llama3.1:8b "Write two sentences about Linux."

สคริปต์การติดตั้งจะสร้างผู้ใช้ระบบ ollama ติดตั้งไฟล์ไบนารี และลงทะเบียน ollama.service โดยผูกไว้กับ 127.0.0.1:11434 ค่า eval rate ที่แสดงโดย --verbose คือจำนวนโทเค็นต่อวินาทีที่แท้จริงบนเครื่องนั้น ให้เชื่อถือค่านี้มากกว่าตัวเลขที่เผยแพร่ทั่วไป การอ่านค่าจากพรอมต์เดียวเป็นเพียงจุดเริ่มต้น ไม่ใช่ตัวเลขขีดความสามารถ ดังนั้น การวัดจำนวนโทเค็นต่อวินาทีในขณะที่มีการทำงานพร้อมกันหลายรายการ จึงเป็นสิ่งที่บอกคุณได้ว่าเครื่องรองรับโหลดที่คุณคาดหวังไว้จริงหรือไม่ และการเช่า GPU นั้นคุ้มค่ากว่าการจ่ายเงินต่อโทเค็นหรือไม่

หากต้องการเพิ่มจำนวนการทำงานพร้อมกัน (concurrency) ให้ใช้ systemd drop-in เพื่อป้องกันไม่ให้การอัปเกรดเขียนทับการตั้งค่าของคุณ:

sudo systemctl edit ollama.service

[Service]
Environment="OLLAMA_NUM_PARALLEL=4"
Environment="OLLAMA_KEEP_ALIVE=30m"

sudo systemctl restart ollama
ollama ps

ollama ps จะแสดงสิ่งที่ถูกโหลดอยู่ และคอลัมน์ PROCESSOR จะแสดงสถานะที่แท้จริง ค่า 100% CPU หมายความว่าไม่มีการใช้ GPU ซึ่งเป็นคำอธิบายที่ตรงไปตรงมาที่สุดสำหรับรายงานส่วนใหญ่ที่ระบุว่า Ollama ทำงานช้า บรรทัด OLLAMA_KEEP_ALIVE=30m ใน drop-in นั้นมีความสำคัญไม่แพ้กันแม้ในเครื่องที่มีโหลดน้อย เพราะค่าเริ่มต้นจะยกเลิกการโหลดโมเดลหลังจากผ่านไป 5 นาทีโดยไม่มีคำขอเข้ามา และ การคงโมเดลไว้ในหน่วยความจำระหว่างคำขอ คือสิ่งที่ช่วยป้องกันไม่ให้พรอมต์แรกหลังจากผ่านไปหนึ่งชั่วโมงต้องเสียเวลาโหลดโมเดลใหม่อีกครั้ง

การติดตั้งและให้บริการด้วย vLLM

vLLM ต้องการระบบปฏิบัติการ Linux และ Python เวอร์ชัน 3.10 ถึง 3.13 ให้ติดตั้งลงใน virtual environment แยกต่างหาก เนื่องจาก vLLM จำเป็นต้องใช้ PyTorch รุ่นเฉพาะ:

uv venv --python 3.12 --seed
source .venv/bin/activate
uv pip install vllm --torch-backend=auto

จากนั้นจึงเริ่มให้บริการโมเดล โดยชื่อโมเดลต้องเป็น repository id จาก Hugging Face ไม่ใช่แท็กแบบย่อ:

vllm serve Qwen/Qwen2.5-1.5B-Instruct

การเริ่มทำงานครั้งแรกจะใช้เวลานานเนื่องจากระบบต้องดาวน์โหลดไฟล์น้ำหนัก (weights) และทำ profiling บน GPU เพื่อคำนวณจำนวน KV cache blocks ที่เหมาะสม โดยบริการจะฟังคำขอที่พอร์ต 8000 ให้ตรวจสอบสถานะก่อนเริ่มเขียนโค้ดฝั่งไคลเอนต์:

curl http://localhost:8000/v1/models
curl http://localhost:8000/v1/chat/completions \
    -H "Content-Type: application/json" \
    -d '{"model": "Qwen/Qwen2.5-1.5B-Instruct", "messages": [{"role": "user", "content": "Who won the world series in 2020?"}]}'

หากมีการติดตั้ง Docker บนเครื่องอยู่แล้ว การใช้ official image จะช่วยลดความยุ่งยากในการจัดการ dependency ของ CUDA:

docker run --runtime nvidia --gpus all \
    -v ~/.cache/huggingface:/root/.cache/huggingface \
    --env "HF_TOKEN=$HF_TOKEN" \
    -p 8000:8000 \
    --ipc=host \
    vllm/vllm-openai:latest \
    --model Qwen/Qwen3-0.6B

--ipc=host เป็นสิ่งที่จำเป็นต้องระบุ ไม่ใช่ตัวเลือกเสริม เนื่องจาก PyTorch ต้องส่งผ่าน tensor ระหว่าง process ผ่านหน่วยความจำร่วม (shared memory) ซึ่งค่าเริ่มต้นของ Docker นั้นมีขนาดเล็กเกินไปสำหรับการทำ tensor-parallel inference

แฟล็กที่มีความสำคัญสูงสุดในการใช้งานจริง ได้แก่ --max-model-len (ขนาด context window ที่คุณต้องการรองรับ), --gpu-memory-utilization (สัดส่วนหน่วยความจำของ GPU ที่ vLLM สามารถจองได้ โดยค่าเริ่มต้นคือ 0.92 ณ เดือนกรกฎาคม 2026), --tensor-parallel-size สำหรับการแบ่งโมเดลหนึ่งตัวข้ามหลาย GPU และ --api-key

การยืนยันตัวตนเป็น flag หนึ่งใน vLLM แต่ไม่มีใน Ollama

vLLM จะบังคับใช้ bearer token หากคุณกำหนดค่าไว้:

vllm serve Qwen/Qwen2.5-1.5B-Instruct --api-key token-abc123

ค่าเดียวกันนี้สามารถกำหนดผ่านตัวแปรสภาพแวดล้อม VLLM_API_KEY ได้ หากคำขอไม่มี token ดังกล่าวจะได้รับสถานะ HTTP 401 อย่างไรก็ตาม นี่ไม่ใช่เหตุผลที่จะเปิดพอร์ต 8000 บนอินเทอร์เฟซสาธารณะ เนื่องจาก vLLM ไม่มีระบบจำกัดอัตราการใช้งาน (rate limiting) และ token แบบ HTTP ธรรมดาสามารถถูกอ่านได้ระหว่างการรับส่งข้อมูล แต่การมี token นี้หมายความว่าเซิร์ฟเวอร์สามารถระบุตัวตนของผู้เรียกใช้งานได้

Ollama ไม่มีระบบนี้ ไม่มีกุญแจ ไม่มีระบบล็อกอิน และไม่มีรายการอนุญาต (allow-list) กระบวนการใดก็ตามที่สามารถเข้าถึงพอร์ต 11434 ได้ สามารถสั่งรัน ดึง หรือลบโมเดลได้ ดังนั้นควรเก็บไว้ที่ loopback และเข้าถึงผ่าน VPN แบบ WireGuard ที่คุณโฮสต์เอง หรือผ่าน reverse proxy ที่มีการยืนยันตัวตนและทำ TLS termination (transport layer security)

ฮาร์ดแวร์: ความต้องการของแต่ละรายการ

Ollama ทำงานบน CPU โมเดลที่ทำ 4-bit quantization จะใช้ RAM ประมาณครึ่งกิกะไบต์ต่อ 1 พันล้านพารามิเตอร์ บวกกับ overhead ของ runtime อีกประมาณ 1 กิกะไบต์ และต้องใช้เพิ่มขึ้นตามขนาดของ context ดังนั้นโมเดลขนาด 3B จึงต้องการ RAM ว่างประมาณ 4 GB และโมเดลขนาด 8B ต้องการประมาณ 8 GB ความเร็วบน vCPU แบบแชร์จะอยู่ที่หลักหน่วยถึงหลักสิบต้นๆ ต่อวินาที นี่เป็นข้อจำกัดของ memory bandwidth ไม่ใช่การตั้งค่าผิดพลาด และไม่มี flag ใดที่แก้ไขปัญหานี้ได้ หากต้องการดูการคำนวณนี้ในการใช้งานจริงแทนการใช้กฎทั่วไป การรัน Nemotron 3.5 Lightning บน VPS จะระบุ tag ที่แน่นอนที่ต้องดึงมาใช้, ปริมาณ RAM ที่ใช้เมื่อโหลดเสร็จ และประเมินว่าความเร็วบน CPU เพียงอย่างเดียวนั้นเพียงพอต่อการใช้งานหรือไม่

vLLM กำหนดให้ต้องมี GPU โดยค่าเริ่มต้นจะรันน้ำหนักโมเดลแบบไม่ทำ quantization ที่ความละเอียด 16-bit ซึ่งใช้ RAM ประมาณ 2 GB ต่อ 1 พันล้านพารามิเตอร์: โมเดลขนาด 8B ต้องการ video memory ประมาณ 16 GB สำหรับน้ำหนักโมเดลเพียงอย่างเดียว ก่อนจะรวม KV cache ซึ่งเป็นเหตุผลที่คุณติดตั้ง vLLM เพื่อรองรับการทำงานพร้อมกัน บนการ์ดจอขนาด 24 GB จะเหลือพื้นที่สำหรับ cache ที่ใช้งานได้ แต่บนการ์ดจอขนาด 16 GB จะไม่เพียงพอ ดังนั้นคุณต้องเลือกโมเดลที่เล็กลงหรือส่ง flag --quantization พร้อมกับ quantized checkpoint แม้จะมี CPU backend ให้ใช้งาน แต่ตัวติดตั้งมาตรฐานไม่ได้ถูกสร้างมาเพื่อรองรับ และการใช้ CPU จะทำให้เหตุผลในการเลือกใช้ vLLM หมดไป

ดังนั้น คำถามเรื่องฮาร์ดแวร์จึงเป็นคำตอบของคำถามเรื่องซอฟต์แวร์ในเกือบทุกกรณี หากไม่มี GPU ให้ใช้ Ollama หากคุณเช่า GPU แล้วพบว่ามีการใช้งานเพียง 5 เปอร์เซ็นต์เนื่องจากคำขอถูกประมวลผลแบบเรียงลำดับ นั่นหมายความว่าคุณควรใช้ vLLM

เลือกสิ่งที่เหมาะสมกับภาระงานของคุณ

• สำหรับผู้ใช้คนเดียวบน CPU VPS ที่เน้นการร่างเอกสารและสรุปความ: ใช้ Ollama ความเร็วอยู่ในระดับที่ยอมรับได้และไม่มีตัวเลือกใดที่เรียบง่ายไปกว่านี้
• สำหรับผู้ช่วยเขียนโค้ด หรือ เซิร์ฟเวอร์ MCP ที่เชื่อมต่อเครื่องมือของคุณเข้ากับโมเดลในเครื่อง ซึ่งมีเพียงคุณเท่านั้นที่เรียกใช้งาน: ใช้ Ollama เพราะภาระงานจริงคือการทำงานแบบลำดับเดียว (concurrency of one)
• สำหรับการเปรียบเทียบโมเดล 5 ตัวในสัปดาห์นี้: ใช้ Ollama เพราะการดึงและลบโมเดลตามแท็กคือจุดเด่นของมัน ในขณะที่ vLLM จำเป็นต้องรีสตาร์ทกระบวนการทำงานใหม่ทุกครั้งที่เปลี่ยนโมเดล
• สำหรับแอปพลิเคชันภายใน ผลิตภัณฑ์แชท หรือไปป์ไลน์การดึงข้อมูลที่มีผู้ใช้จริง: ใช้ vLLM เพราะนี่คือจุดที่การทำ batching จะช่วยให้การใช้งาน GPU คุ้มค่ากับค่าใช้จ่าย
• สำหรับงานประมวลผลแบบ batch ที่ต้องให้คะแนนเอกสารหนึ่งแสนฉบับในข้ามคืน: ใช้ vLLM โดยตั้งค่า --max-num-seqs ไว้สูง เพราะ throughput คือตัวชี้วัดเดียวที่สำคัญ และ latency ต่อเอกสารไม่มีผล
• สำหรับแพลตฟอร์มเอเจนต์ที่มี AI agents ที่โฮสต์เอง หลายตัวเรียกใช้โมเดลพร้อมกัน: ใช้ vLLM เพราะทราฟฟิกของเอเจนต์มีลักษณะเป็นช่วงๆ (bursty) และทำงานแบบขนานโดยธรรมชาติ

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

vLLM ไม่ยอมเริ่มทำงานโดยแจ้งข้อผิดพลาดเกี่ยวกับ KV cache ข้อความจะระบุตัวเลขทั้งสองค่า:

ValueError: The model's max seq len (32768) is larger than the maximum number of tokens that can be stored in KV cache (8192). Try increasing gpu_memory_utilization or decreasing max_model_len when initializing the engine.

โมเดลประกาศขนาด context window ที่ใหญ่กว่าหน่วยความจำที่เหลืออยู่หลังจากโหลดน้ำหนัก (weights) แล้ว ให้ลดค่าลงด้วย --max-model-len 8192 หรือเพิ่มค่า --gpu-memory-utilization หากไม่มีโปรแกรมอื่นใช้งานการ์ดจออยู่ การดันการใช้งานเกินกว่า 0.95 มักจะทำให้เกิดข้อผิดพลาดนี้ตอนเริ่มระบบ แทนที่จะเกิดอาการ CUDA out-of-memory ในภายหลังขณะรับโหลด ซึ่งถือว่าแย่กว่า

Ollama แสดงข้อความ Killed ระหว่างการสร้างคำตอบ Linux out-of-memory killer ได้หยุดกระบวนการทำงานเนื่องจากโมเดลต้องการ RAM มากกว่าที่เครื่องมี ให้ตรวจสอบด้วย sudo dmesg | grep -i oom วิธีแก้ไขคือการใช้โมเดลที่เล็กลงหรือทำ quantization ให้หนักขึ้น ไม่ใช่การปรับตั้งค่า

Ollama ตอบสนองปกติเมื่อใช้งานคนเดียว แต่ค้างเมื่อรับโหลด ไม่ปรากฏข้อผิดพลาดใดๆ คำขอใช้เวลาประมวลผลนานขึ้นตามจำนวนผู้เรียกใช้งาน เนื่องจาก OLLAMA_NUM_PARALLEL=1 ทำการประมวลผลแบบลำดับ (serialising) คำตอบที่ยาวทำให้คิวแย่ลง เพราะผู้เรียกใช้งานรายเดียวที่ครองช่องว่างเพียงช่องเดียวจนกว่าโมเดลจะหยุด จะปิดกั้นผู้ใช้งานคนอื่นทั้งหมดที่รออยู่ ดังนั้น การจำกัดคำตอบด้วย num_predict จึงเป็นการกำหนดเพดานว่าการสนทนาหนึ่งครั้งจะครองเซิร์ฟเวอร์ได้นานเท่าใด ให้เพิ่มค่าการประมวลผลแบบขนาน (parallel) และยอมรับ context ต่อคำขอที่เล็กลง หรือย้ายภาระงานไปที่ vLLM

vLLM ส่งค่า 401 ในทุกคำขอ คุณเริ่มการทำงานด้วย --api-key แต่ไคลเอนต์ไม่ได้ส่ง header Authorization มาด้วย ไลบรารีไคลเอนต์ OpenAI ส่วนใหญ่จะส่งค่าที่คุณระบุเป็น key ไปให้ ดังนั้นให้ตั้งค่าที่นั่นแทนการลบ flag ออก

vLLM แจ้งว่าไม่พบโมเดล Ollama จะดึงโมเดลเมื่อมีการเรียกใช้งาน แต่ vLLM ไม่ทำเช่นนั้น ฟิลด์ model ในเนื้อหาคำขอต้องตรงกับ repository id ที่คุณใช้ตอนเริ่มระบบ หรือตรงกับค่าของ --served-model-name หากคุณได้ตั้งค่าไว้ ให้ยืนยันสตริงที่ถูกต้องด้วย curl http://localhost:8000/v1/models

การรันทั้งสองอย่างเป็นคำตอบที่สมเหตุสมผล

ทั้งสองอย่างไม่ได้จำกัดซึ่งกันและกัน รูปแบบที่พบบ่อยคือการใช้ vLLM บนอินสแตนซ์ GPU เพื่อให้บริการแอปพลิเคชัน ในขณะที่ใช้ Ollama บน VPS ปกติควบคู่กันไปสำหรับสคริปต์ภายใน, งาน cron jobs และการทดลองใช้โมเดลที่ปล่อยออกมาใหม่ ทั้งสอง endpoint รองรับมาตรฐาน OpenAI ดังนั้นจึงสามารถใช้ไลบรารีไคลเอนต์ชุดเดียวกันและสลับ base-URL เพื่อใช้งานได้ การควบคุมต้นทุนมีความสำคัญมากกว่าการเลือกว่าจะใช้ engine ตัวใด เนื่องจาก GPU ที่ไม่ได้ใช้งานก็มีค่าใช้จ่ายเท่ากับ GPU ที่ทำงานอยู่ และ การรักษาต้นทุนของเอเจนต์และการอนุมานให้คาดการณ์ได้ เป็นวินัยที่แยกต่างหากจากการเลือกเซิร์ฟเวอร์

FAQ

vLLM ทำงานเร็วกว่า Ollama หรือไม่?

สำหรับการส่งคำขอเพียงรายการเดียวบน GPU เดียวกัน ความแตกต่างนั้นมีน้อยมาก เนื่องจากทั้งสองระบบใช้การคำนวณทางคณิตศาสตร์แบบเดียวกัน แต่สำหรับคำขอจำนวนมากที่เข้ามาพร้อมกัน vLLM จะทำงานได้เร็วกว่ามาก เพราะใช้เทคนิค continuous batching ในการถอดรหัสทุก sequence ที่ทำงานอยู่ในการส่งข้อมูลผ่านโครงข่าย (forward pass) เพียงครั้งเดียว ในขณะที่ค่าเริ่มต้นของ Ollama จะประมวลผลทีละรายการ หากเป็นเครื่องที่ไม่มี GPU คำถามนี้จะไม่มีผล เนื่องจาก Ollama สามารถทำงานได้ แต่ vLLM ไม่สามารถใช้งานได้อย่างมีประสิทธิภาพ

vLLM สามารถทำงานโดยไม่มี GPU ได้หรือไม่?

ไม่สามารถใช้งานจริงได้ ตัวติดตั้งมาตรฐาน (wheels) ถูกออกแบบมาสำหรับ NVIDIA หรือ AMD GPU และเหตุผลหลักที่ vLLM ถูกสร้างขึ้นมาเพื่อรักษาการใช้งาน accelerator ให้เต็มประสิทธิภาพด้วยการทำ batch requests นั้นไม่มีความหมายบน CPU แม้จะมี CPU backend สำหรับงานพัฒนา แต่สำหรับการทำ inference บน CPU จริงๆ ควรใช้ Ollama หรือ llama.cpp โดยตรง

Ollama และ llama.cpp มีความแตกต่างกันอย่างไร?

llama.cpp คือไลบรารีสำหรับทำ inference และ GGUF คือรูปแบบไฟล์น้ำหนัก (weight) ที่ถูกบีบอัด (quantized) ของมัน ส่วนตัวรันของ Ollama ถูกสร้างขึ้นบนพื้นฐานของ llama.cpp และเพิ่มส่วนประกอบที่ llama.cpp ไม่ได้จัดเตรียมไว้ให้ เช่น ระบบจัดการโมเดล, การดาวน์โหลดอัตโนมัติ, เซิร์ฟเวอร์ที่ทำงานเบื้องหลัง, systemd unit และ endpoint ที่รองรับมาตรฐาน OpenAI ปัจจุบัน Ollama ได้เพิ่ม engine ของตนเองสำหรับโมเดลรุ่นใหม่ๆ บางตระกูล ทำให้ทั้งสองระบบไม่ได้มีโครงสร้างภายในที่เหมือนกันทั้งหมดอีกต่อไป

vLLM ต้องการหน่วยความจำ GPU เท่าใดสำหรับโมเดลขนาด 8B?

ที่ความละเอียด 16-bit เฉพาะตัวน้ำหนักโมเดลก็ใช้พื้นที่ประมาณ 16 GB หรือประมาณ 2 GB ต่อ 1 พันล้านพารามิเตอร์ และยังต้องเผื่อพื้นที่สำหรับ KV cache อีกด้วย การ์ดจอขนาด 24 GB จึงถือว่าเพียงพอ แต่การ์ดขนาด 16 GB จำเป็นต้องใช้ checkpoint ที่ผ่านการทำ quantization หรือใช้โมเดลที่มีขนาดเล็กลง vLLM จะจองพื้นที่การ์ดจอตามสัดส่วนที่กำหนดโดย --gpu-memory-utilization ซึ่งมีค่าเริ่มต้นอยู่ที่ 0.92 ณ เดือนกรกฎาคม 2026

ฉันจำเป็นต้องแก้ไขโค้ดแอปพลิเคชันเพื่อสลับใช้งานระหว่างสองระบบนี้หรือไม่?

โดยปกติแล้วต้องแก้ไขเพียง base URL, API key และชื่อโมเดลเท่านั้น Ollama ให้บริการผ่านอินเทอร์เฟซที่รองรับมาตรฐาน OpenAI ที่ http://127.0.0.1:11434/v1 และไม่ตรวจสอบ API key ในขณะที่ vLLM ให้บริการที่ http://localhost:8000/v1 และจะบังคับใช้ API key หากคุณมีการตั้งค่าไว้ ส่วนชื่อโมเดลจะมีรูปแบบต่างกัน คือ llama3.1:8b สำหรับ Ollama และใช้ชื่อ repository เต็ม เช่น Qwen/Qwen2.5-1.5B-Instruct สำหรับ vLLM