เปรียบเทียบ 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 เป็นเลเยอร์ที่ช่วยอำนวยความสะดวก โดยรวมเอา model registry (ollama pull llama3.1:8b), พื้นที่จัดเก็บ weight ในเครื่อง, อินเทอร์เฟซสำหรับแชท, systemd service และ HTTP API ไว้ในการติดตั้งเพียงคำสั่งเดียว โมเดลส่วนใหญ่ที่ให้บริการอยู่ในรูปแบบไฟล์ GGUF ซึ่งมักจะเป็นแบบ 4-bit quantized ทำให้โมเดลขนาด 7B หรือ 8B ใช้พื้นที่บนดิสก์เพียงประมาณ 5 GB แทนที่จะเป็น 16 GB การทำ quantization ช่วยลดหน่วยความจำที่ต้องใช้สำหรับการประมวลผลบน CPU สำหรับเครื่อง Mac ที่ใช้ Apple Silicon ยังสามารถรันโมเดลแบบ safetensors ผ่าน MLX engine ได้ และตั้งแต่เวอร์ชัน v0.40.0 (กันยายน 2026) สถาปัตยกรรมที่รองรับจะทำงานบน MLX โดยอัตโนมัติ

ตัวรัน GGUF ของ Ollama สร้างขึ้นบน llama.cpp ซึ่งเป็นไลบรารี C++ สำหรับการประมวลผลที่ทำให้การทำ quantization แบบ GGUF ใช้งานได้จริงบนฮาร์ดแวร์ทั่วไป ณ เดือนตุลาคม 2026 Ollama รองรับสอง engine คือ llama.cpp และ MLX โดยรุ่นสำหรับ Linux ยังรองรับการประมวลผล MLX ร่วมกับ CUDA อีกด้วย คู่มือการพัฒนาได้เปิดใช้งาน backend ดังกล่าวด้วย cmake -B build . -DOLLAMA_MLX_BACKENDS=cuda_v13 โดยมีข้อกำหนดเบื้องต้นคือ CUDA 13+ และ cuDNN 9+ ดังนั้นเมื่อมีการเปรียบเทียบ Ollama กับ llama.cpp สิ่งที่เปรียบเทียบกันส่วนใหญ่คือการเปรียบเทียบเลเยอร์ที่เน้นความสะดวกในการใช้งานกับสิ่งที่เลเยอร์นั้นครอบอยู่

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

vLLM คืออะไร

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

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

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

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

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

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

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

คุณสามารถตั้งค่า OLLAMA_NUM_PARALLEL=4 เพื่อให้ได้ผลลัพธ์ในลักษณะนี้ได้บ้าง แต่ต้องแลกมาด้วยหน่วยความจำ แต่ละช่องสัญญาณขนาน (parallel slot) จำเป็นต้องมี KV cache ของตัวเอง และ Ollama จะใช้วิธีคูณการจัดสรร context แทนที่จะแบ่งส่วน: FAQ ของ Ollama ระบุว่า RAM ที่ต้องใช้จะเพิ่มขึ้นตาม OLLAMA_NUM_PARALLEL คูณด้วย OLLAMA_CONTEXT_LENGTH ดังนั้นคำขอขนาน 4 รายการต่อโมเดลที่กำหนดค่าไว้ที่ 8192 โทเค็น จะต้องเก็บข้อมูล 8192 โทเค็นต่อรายการ แต่เซิร์ฟเวอร์ต้องรองรับ cache รวมทั้งหมดถึง 32768 โทเค็น ค่า 8192 นั้นเป็นตัวเลือกที่กำหนดขึ้นเองไม่ใช่ค่าตายตัว ดังนั้น การเพิ่ม num_ctx และการคำนวณขนาด RAM ที่ต้องใช้ จึงเป็นขั้นตอนตัดสินว่าเซิร์ฟเวอร์จะรองรับ 4 ช่องสัญญาณได้หรือไม่ ระบบ paged cache ของ vLLM คือสิ่งที่ช่วยหลีกเลี่ยงการจองพื้นที่เต็มหน้าต่าง (full window) สำหรับทุกช่องสัญญาณล่วงหน้า เพราะบล็อกข้อมูลจะถูกจัดสรรให้กับคำขอตามการขยายตัวจริงของคำขอนั้นๆ ไม่ว่าจะด้วยวิธีใด เพดานขีดจำกัดจำนวนผู้ใช้งานที่เซิร์ฟเวอร์เครื่องเดียวจะรองรับได้พร้อมกันนั้นขึ้นอยู่กับขนาดของ 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 คุ้มค่ากว่าการจ่ายเงินตามจำนวนโทเค็นหรือไม่

หากต้องการเพิ่มขีดความสามารถในการรองรับการทำงานพร้อมกัน ให้ใช้ 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 บน GPU จำเป็นต้องใช้ Linux (สำหรับ macOS บน Apple Silicon จะรองรับเฉพาะ CPU ผ่าน prebuilt wheel ในรุ่น 0.32.0 ส่วนการเร่งความเร็ว GPU บน Mac เหล่านั้นต้องใช้ vLLM-Metal ซึ่งเป็นปลั๊กอินที่ชุมชนดูแลแยกต่างหากและสร้างบน MLX) สำหรับ Python รุ่นปัจจุบัน (0.32.0, ตุลาคม 2026) รองรับเวอร์ชัน 3.11 ถึง 3.14 ซึ่งคู่มือการติดตั้งระบุช่วงเวอร์ชันเดียวกัน Python 3.10 ถูกยกเลิกการรองรับในรุ่น 0.32.0 ดังนั้น Python 3.12 ซึ่งใช้ในตัวอย่างด้านล่างจึงเป็นตัวเลือกที่ปลอดภัย ควรติดตั้งลงใน virtual environment แยกต่างหาก เนื่องจาก vLLM จะดึง PyTorch รุ่นเฉพาะเจาะจงเข้ามาด้วย:

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

บรรทัดสุดท้ายเป็นคำสั่งจากคู่มือการติดตั้ง vLLM บน NVIDIA ณ เดือนตุลาคม 2026 ซึ่งเป็นการติดตั้ง kernel ที่คอมไพล์ไว้ล่วงหน้าของ FlashInfer หากไม่มี kernel เหล่านี้ vLLM จะดาวน์โหลดและคอมไพล์ kernel เองในขณะเริ่มทำงาน ซึ่งคู่มือระบุว่าอาจใช้เวลาเพิ่มขึ้นหลายนาทีบน GPU สถาปัตยกรรม Hopper และรุ่นใหม่กว่า ควรเรียกใช้คำสั่งนี้ซ้ำทุกครั้งหลังอัปเกรด vLLM เนื่องจาก FlashInfer จะไม่สามารถ import ได้หากเวอร์ชันของ kernel ไม่ตรงกัน

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

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

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

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 ช่วยให้ container สามารถเข้าถึง shared memory ของโฮสต์ได้ หรืออีกทางเลือกหนึ่งคือการเพิ่มขนาด --shm-size เนื่องจาก PyTorch มีการส่งผ่าน tensor ระหว่าง process ผ่าน shared memory โดยเฉพาะอย่างยิ่งสำหรับการทำ tensor-parallel inference

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

การยืนยันตัวตนเป็น flag หนึ่งใน vLLM แต่ไม่มีใน API ท้องถิ่นของ Ollama

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

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

ค่าเดียวกันนี้สามารถกำหนดผ่านตัวแปรสภาพแวดล้อม VLLM_API_KEY ได้ คำขอที่ส่งไปยังเส้นทาง /v1 โดยไม่มี token จะได้รับ HTTP 401 อย่างไรก็ตาม กุญแจนี้ไม่ได้ครอบคลุมทั้งเซิร์ฟเวอร์ คู่มือความปลอดภัยของ vLLM และโค้ดการยืนยันตัวตนในซอร์สโค้ดเวอร์ชัน 0.32.0 ระบุว่าการยืนยันตัวตนจะมีผลเฉพาะกับ endpoint ภายใต้ prefix เส้นทาง /v1, /v2, /inference และ /cohere เท่านั้น ข้อความช่วยเหลือของ --api-key ในหน้า vllm serve ระบุไว้เพียงสามรายการแรก แต่โค้ดจริงตรวจสอบทั้งสี่รายการ ทั้งคู่มือและข้อความช่วยเหลือระบุว่า endpoint อื่นๆ โดยเฉพาะอย่างยิ่ง /invocations ซึ่งเปิดเผยการอนุมาน (inference) เดียวกันกับ /v1 นั้นไม่มีการยืนยันตัวตน นี่เป็นเหตุผลเพียงพอที่จะไม่เปิดพอร์ต 8000 บนอินเทอร์เฟซสาธารณะ คู่มือความปลอดภัยของ vLLM ยังระบุให้การจำกัดอัตรา (rate limiting) เป็นหน้าที่ของ reverse proxy ที่อยู่ด้านหน้า และ token ที่ส่งผ่าน HTTP ธรรมดาสามารถถูกอ่านได้ระหว่างทาง แต่ flag นี้ก็หมายความว่าเซิร์ฟเวอร์มีแนวคิดเรื่องผู้เรียกใช้งาน

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

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

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 โดยค่าเริ่มต้นจะรัน unquantized weights ที่ความละเอียด 16-bit ซึ่งใช้พื้นที่ประมาณ 2 GB ต่อ 1 พันล้านพารามิเตอร์: โมเดล 8B ต้องการ video memory ประมาณ 16 GB สำหรับตัว weights เพียงอย่างเดียว ก่อนจะรวม KV cache ซึ่งเป็นเหตุผลที่คุณติดตั้ง vLLM เพื่อรองรับการทำงานพร้อมกัน บนการ์ดจอขนาด 24 GB จะเหลือพื้นที่สำหรับ cache ที่ใช้งานได้ แต่บนการ์ดจอ 16 GB จะไม่เพียงพอ ดังนั้นคุณต้องเลือกโมเดลที่เล็กลง, ใส่ flag --quantization (เพื่อใช้ quantized checkpoint หรือทำ quantization ขณะโหลด), หรือย้ายบางส่วนของ weights ไปไว้ใน system RAM ด้วย --cpu-offload-gb ซึ่งยังคงความละเอียดเดิมไว้แต่จะทำงานช้าลง เพราะ weights เหล่านั้นต้องถูกส่งไปยัง GPU ในทุก forward pass แม้จะมี CPU backend ให้ใช้งานพร้อมไฟล์ติดตั้งแยกต่างหาก แต่นั่นจะทำให้เหตุผลในการเลือกใช้ 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: To serve at least one request with the model's max seq len (32768), (4.00 GiB KV cache is needed, which is larger than the available KV cache memory (1.00 GiB). Based on the available memory, the estimated maximum model length is 8192. Try increasing `gpu_memory_utilization` (which also controls CPU memory on the CPU backend) or decreasing `max_model_len` when initializing the engine. See https://docs.vllm.ai/en/latest/configuration/conserving_memory/ for more details.

โมเดลประกาศขนาด context window ที่ใหญ่กว่าหน่วยความจำที่เหลืออยู่หลังจากโหลดน้ำหนักโมเดลแล้ว ให้ลดค่าลงด้วย --max-model-len 8192 หรือเพิ่มค่า --gpu-memory-utilization หากไม่มีโปรเซสอื่นใช้งานการ์ดจออยู่

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

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

vLLM ส่งค่า 401 ในทุกการเรียก /v1 คุณเริ่มการทำงานด้วย --api-key แต่ไคลเอนต์ไม่ได้ส่ง header Authorization มาด้วย ไลบรารีไคลเอนต์ OpenAI ส่วนใหญ่จะส่งค่าที่คุณระบุเป็นคีย์ ดังนั้นให้ตั้งค่าที่ฝั่งไคลเอนต์แทนการลบ 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 จะประมวลผลทีละรายการ สำหรับเครื่องที่ใช้เฉพาะ CPU ทั้งสองตัวมีเส้นทางการอนุมาน (inference) ที่รองรับ โดย vLLM จะใช้ CPU wheels แยกต่างหาก

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

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

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

llama.cpp คือไลบรารีสำหรับการอนุมาน และ GGUF คือรูปแบบน้ำหนัก (weight) ที่ถูกบีบอัด (quantized) ของมัน Ollama ใช้ไลบรารีนี้สำหรับการอนุมาน GGUF และเพิ่มระบบ registry ของโมเดล, การดาวน์โหลดแบบระบุเวอร์ชัน (tagged), การจัดการโมเดล และ systemd unit นอกจากนี้ Ollama ยังมาพร้อมกับ MLX engine ที่รันโมเดลแบบ safetensors บน Apple Silicon และรองรับการ build ด้วย CUDA บน Linux ดังนั้นทั้งสองตัวจึงไม่ได้เหมือนกันทุกประการในระดับโครงสร้างภายใน

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

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

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

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