Ollama vs vLLM: Alin ang Tamang LLM Server?

Ollama kumpara sa vLLM, sa isang talata

Ang Ollama ay isang model manager na may kalakip na server: dina-download nito ang quantized weights, nilo-load ang mga ito, at sumasagot sa 127.0.0.1:11434 gamit ang CPU kung iyon lamang ang mayroon ang machine. Ang vLLM ay isang throughput engine: pinananatili nitong lubos na ginagamit ang GPU habang sabay-sabay na pinoproseso ang maraming request, kaya maling tool ito sa machine na walang GPU. Iyan ang buong batayan ng pagpili. Ang isang taong nakikipag-usap sa isang lokal na assistant ay isang Ollama job. Ang isang application na nagsisilbi sa isang team ay isang vLLM job.

Pareho silang gumagamit ng OpenAI-compatible HTTP API, kaya maililipat ang client code sa pagitan nila sa pamamagitan ng pagpapalit ng base URL. Hindi API ang pinagkaiba. Ang pinagkaiba ay ang nangyayari kapag may dumating na pangalawang request habang nagge-generate pa ng mga token ang unang request.

Kung ano talaga ang Ollama

Ang Ollama ay isang convenience layer. Nagbibigay ito ng model registry (ollama pull llama3.1:8b), lokal na imbakan ng weights, chat prompt, systemd service, at HTTP API sa pamamagitan ng iisang install command. Ang mga model na sine-serve nito ay GGUF files, karaniwang 4-bit quantized. Dahil dito, nasa humigit-kumulang 5 GB lang sa disk ang isang 7B o 8B model sa halip na 16 GB. Ang quantization ang dahilan kung bakit posible ang CPU inference.

Ang runner nito ay nakabatay sa llama.cpp, ang C++ inference library na nagpa-practical sa GGUF quantization sa karaniwang hardware. Simula noon, nagdagdag ang Ollama ng sarili nitong engine para sa ilang mas bagong model family, ngunit ang llama.cpp pa rin ang substrate sa ilalim ng karamihan ng sine-serve nito. Kaya kapag ikinukumpara ng mga tao ang Ollama sa llama.cpp, karaniwan nilang ikinukumpara ang isang ergonomics layer sa mismong bagay na bina-wrap nito.

Ang target ng disenyo ay isang user. Noong July 2026, ang default para sa OLLAMA_NUM_PARALLEL ay 1. Ibig sabihin, isang model ang nagpo-process ng isang request sa bawat pagkakataon, at lahat ng iba pa ay naghihintay sa queue na may default na 512 entries (OLLAMA_MAX_QUEUE). Maaari mong taasan ang parallel setting, at ipinapaliwanag ng seksyon sa ibaba ang magiging kapalit nito. Kung hindi mo pa pinapatakbo ang Ollama, magsimula sa pagho-host ng Ollama sa isang VPS at pagsasara ng port 11434, dahil walang anumang authentication ang API.

Ano talaga ang vLLM

Ang vLLM ay isang inference server at wala nang iba. Hindi ito namamahala ng model library, wala itong chat prompt, at hindi ito kukuha ng model para sa iyo sa oras ng request. Tinutukoy mo ang isang Hugging Face repository sa oras ng launch, nilo-load nito ang model na iyon, at sine-serve ito hanggang ihinto mo ang process.

Ang kapalit ng limitasyong ito ay throughput. Dalawang mekanismo ang gumagawa nito. Iniimbak ng PagedAttention ang KV cache (key-value cache, ang per-token na attention state na pinananatili ng model para sa bawat aktibong request) sa mga block na may fixed size, gaya ng pagpa-page ng memory ng operating system. Hindi na kailangan ng request ng isang malaking contiguous reservation na nakabatay sa pinakamasamang sitwasyon, kaya nagiging available para sa mas maraming concurrent request ang memory na dati ay naka-reserve ngunit hindi ginagamit. Hinahayaan ng Continuous batching na sumali ang bagong request sa kasalukuyang batch sa susunod na decoding step sa halip na maghintay na matapos ang kasalukuyang batch. Kapag natapos ang sequence, agad itong inaalis sa batch at pinupunan ang slot nito.

Ang praktikal na resulta: sa isang GPU, ang pagtaas mula sa isang concurrent user tungo sa tatlumpu ay malaki ang itinaas sa kabuuang tokens per second, habang mas kaunti kaysa inaasahan ang ibinababa ng speed ng bawat user. Sa default ng Ollama, ang pagtaas mula sa isang user tungo sa tatlumpu ay nagiging dahilan lamang para maghintay ang dalawampu't siyam na tao.

Ang continuous batching ang pangunahing pagkakaiba

Isipin ang limang request na sabay-sabay na dumarating sa bawat server na pareho ang hardware.

Sa default na settings, tinatapos muna ng Ollama ang request one bago simulan ang request two, at iba pa. Naghihintay ang fifth caller habang tinatapos ang apat na buong generation. Halos katumbas ng bilis ng isang generation ang kabuuang throughput, dahil isang sequence lang ang pinoproseso ng processor sa bawat pagkakataon.

Ide-decode ng vLLM ang lahat ng lima sa iisang forward pass. Halos hindi mas mahal ang pag-generate ng isang token para sa limang sequence kaysa sa pag-generate ng isang token para sa isang sequence, dahil ang pinakamabigat na bahagi ay ang pagbasa ng model weights mula sa memory, at pinagsasaluhan ng buong batch ang pagbabasang iyon. Ito rin ang memory-bandwidth fact na nagpapabagal sa CPU inference: binabayaran mo ang paglipat ng weights, hindi ang arithmetic.

Maaari mong i-set ang OLLAMA_NUM_PARALLEL=4 at makuha ang ilan sa benepisyong ito. Ang kapalit ay memory. Kailangan ng bawat parallel slot ng sarili nitong KV cache, at hinahati ng Ollama ang context window sa mga slot. Kaya ang apat na parallel request laban sa model na naka-configure para sa 8192 tokens ay mag-iiwan ng 2048 tokens na context para sa bawat request. Iniiwasan ng paged cache ng vLLM ang trade-off na ito, dahil naglalaan ito ng mga block sa isang request habang aktuwal na lumalaki ang request.

Mag-install at mag-serve gamit ang 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."

Gumagawa ang install script ng ollama system user, ini-install ang binary, at nire-register ang ollama.service na naka-bind sa 127.0.0.1:11434. Ang eval rate line na inilalabas ng --verbose ang aktuwal na tokens per second sa server na iyon. Mas pagkatiwalaan ito kaysa sa anumang published figure.

Para taasan ang concurrency, gumamit ng systemd drop-in para hindi ma-overwrite ng upgrade ang pagbabago:

sudo systemctl edit ollama.service

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

sudo systemctl restart ollama
ollama ps

Ipinapakita ng ollama ps kung ano ang naka-load, at ipinapakita ng PROCESSOR column nito ang aktuwal na kalagayan. Ibig sabihin ng 100% CPU ay walang GPU na ginagamit. Ito ang tapat na paliwanag sa karamihan ng mga report na mabagal ang Ollama.

Mag-install at mag-serve gamit ang vLLM

Kailangan ng vLLM ng Linux at Python 3.10 hanggang 3.13. I-install ito sa sarili nitong virtual environment dahil kumukuha ito ng partikular na PyTorch build:

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

Pagkatapos, mag-serve ng model. Ang pangalan ay Hugging Face repository id, hindi isang maikling tag:

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

Mabagal ang startup sa unang pagkakataon dahil dina-download nito ang weights at pagkatapos ay bina-profile ang GPU upang tukuyin kung ilang KV cache block ang kasya. Nakikinig ito sa port 8000. Suriin ito bago magsulat ng client code:

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?"}]}'

Kung naka-install na ang Docker sa server, iniiwasan ng official image ang pag-configure ng CUDA dependency:

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

Kailangan ang --ipc=host; hindi ito dekorasyon. Ipinapasa ng PyTorch ang mga tensor sa pagitan ng mga proseso gamit ang shared memory, at masyadong maliit para sa tensor-parallel inference ang default na shared-memory allocation ng Docker.

Ang pinakamahalagang flag sa production ay --max-model-len, ang context window na handa mong bayaran; --gpu-memory-utilization, ang fraction ng card na maaaring gamitin ng vLLM, na 0.92 bilang default noong July 2026; --tensor-parallel-size para hatiin ang isang model sa ilang GPU; at --api-key.

Ang authentication ay isang flag sa vLLM at wala sa Ollama

Nagpapatupad ang vLLM ng bearer token kapag nagbigay ka nito:

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

Maaari ring kunin ang parehong value mula sa environment variable na VLLM_API_KEY. Ang request na walang token nito ay makakatanggap ng HTTP 401. Hindi pa rin ito dahilan para i-publish ang port 8000 sa isang public interface, dahil walang rate limiting ang vLLM at mababasa ang plain HTTP token habang ipinapadala. Gayunman, nangangahulugan itong may konsepto ang server ng caller.

Wala nito ang Ollama. Walang key, login, o allow-list. Anumang process na makakaabot sa 11434 ay maaaring mag-run, mag-pull, o mag-delete ng models. Panatilihin ito sa loopback at i-access gamit ang WireGuard VPN na ikaw mismo ang nag-host, o gamit ang isang authenticating reverse proxy na nagte-terminate ng TLS (transport layer security).

Hardware: ano ang kailangan ng bawat isa

Gumagana ang Ollama sa CPU. Ang 4-bit quantized model ay nangangailangan ng humigit-kumulang kalahating gigabyte ng RAM bawat bilyong parameter, bukod pa sa humigit-kumulang isang gigabyte ng runtime overhead at karagdagang memory para sa context. Kaya nangangailangan ang 3B model ng humigit-kumulang 4 GB na libreng memory, at ang 8B model ng humigit-kumulang 8 GB. Ang bilis sa shared vCPU ay nasa single digit hanggang mababang double digit na tokens bawat segundo. Dahil ito sa memory bandwidth, hindi sa maling configuration, at walang flag na makapag-aayos nito.

Ipinapalagay ng vLLM na may GPU. Ang default nitong path ay naghahatid ng unquantized weights sa 16-bit precision. Katumbas ito ng humigit-kumulang 2 GB bawat bilyong parameter. Kaya ang 8B model ay nangangailangan ng humigit-kumulang 16 GB ng video memory para sa weights lamang, bago isama ang KV cache na kailangan para sa concurrency kung bakit mo ini-install ang vLLM. Sa 24 GB na card, may sapat pang cache para magamit. Sa 16 GB na card, wala. Kaya kailangan mong pumili ng mas maliit na model o ipasa ang --quantization kasama ng quantized checkpoint. May CPU backend, ngunit hindi ito kasama sa karaniwang wheels, at inaalis nito ang pangunahing dahilan para gamitin ang vLLM.

Kaya kadalasang sinasagot ng tanong tungkol sa hardware ang tanong tungkol sa software. Kung walang GPU, gamitin ang Ollama. Kung ang nirentahang GPU ay nasa 5 percent utilisation dahil sina-serialise ang mga request, gamitin ang vLLM.

Alin ang angkop para sa iyong workload

• Isang user, isang CPU VPS, para sa pagbuo ng draft at pagbubuod: Ollama. Katanggap-tanggap ang bilis, at wala nang mas simple.
• Isang coding assistant, o isang MCP server na nag-uugnay sa iyong mga tool sa isang local model, na ikaw lang ang gumagamit: Ollama. Ang concurrency na one ay ang aktuwal na workload.
• Naghahambing ng five models ngayong linggo: Ollama. Eksaktong para rito ang pag-pull at pag-delete ng mga tagged model, samantalang kailangan ng vLLM ng process restart para sa bawat model.
• Isang internal app, chat product, o retrieval pipeline na may aktuwal na users: vLLM. Dito sulit ang batching kumpara sa GPU bill.
• Isang batch job na nagso-score ng hundred thousand documents magdamag: vLLM, na may mataas na --max-num-seqs. Ang throughput lang ang mahalagang metric, at hindi mahalaga ang latency ng bawat document.
• Isang agent platform kung saan sabay-sabay na gumagamit ng model ang ilang self-hosted AI agent: vLLM, dahil bursty at likas na parallel ang traffic ng mga agent.

Mga mode ng pagkabigo, kasama ang mga string na makikita mo

Tumangging magsimula ang vLLM dahil sa error sa KV cache. Binabanggit ng mensahe ang parehong numero:

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.

Nagtatakda ang model ng context window na mas malaki kaysa sa memory na natitira pagkatapos i-load ang weights. Bawasan ito gamit ang --max-model-len 8192, o itaas ang --gpu-memory-utilization kung walang ibang gumagamit sa card. Kapag itinulak ang utilisation lampas sa humigit-kumulang 0.95, karaniwang napapalitan ang startup error ng CUDA out-of-memory crash kapag mabigat na ang load. Mas malala ang huling sitwasyon.

Ini-print ng Ollama ang Killed habang ginagawa ang generation. Itinigil ng Linux out-of-memory killer ang proseso dahil mas maraming RAM ang kailangan ng model kaysa sa mayroon ang server. Kumpirmahin ito gamit ang sudo dmesg | grep -i oom. Ang solusyon ay mas maliit o mas heavily quantized na model, hindi isang setting.

Maayos sumagot ang Ollama kapag mag-isa, pero bumabagal kapag may load. Walang lumalabas na error. Mas tumatagal lang ang mga request habang dumarami ang callers dahil sina-serialize ng OLLAMA_NUM_PARALLEL=1 ang mga ito. Itaas ito at tanggapin ang mas maliit na context sa bawat request, o ilipat ang workload sa vLLM.

Nagbabalik ang vLLM ng 401 sa bawat call. Sinimulan mo ito gamit ang --api-key, pero walang Authorization header na ipinapadala ang client. Ipinapadala ng karamihan ng OpenAI client library ang anumang key na ipinasa mo bilang key, kaya itakda ito roon sa halip na alisin ang flag.

Sinasabi ng vLLM na hindi nakita ang model. Nagda-download ang Ollama kapag kailangan, ngunit hindi ito ginagawa ng vLLM. Dapat tumugma ang model field sa request body sa repository id na ginamit mo sa pagsisimula nito, o sa value ng --served-model-name kung nagtakda ka nito. Kumpirmahin ang eksaktong string gamit ang curl http://localhost:8000/v1/models.

Makatuwirang patakbuhin ang pareho

Hindi eksklusibo ang mga ito. Karaniwang setup ang vLLM sa isang GPU instance para magsilbi sa application, at Ollama sa ordinaryong VPS sa tabi nito para sa mga local script, cron job, at pagsubok ng mga bagong model release. Parehong OpenAI-compatible ang kanilang mga endpoint, kaya sapat na ang isang client library at pagpapalit ng base URL para magamit ang alinman sa mga ito. Mas mahalaga rito ang pagkontrol sa gastos kaysa sa alinmang engine, dahil pareho ang singil sa idle na GPU at sa abalang GPU, at hiwalay na disiplina ang pagpapanatiling predictable ng mga gastos sa agent at inference sa pagpili ng server.

FAQ

Mas mabilis ba ang vLLM kaysa sa Ollama?

Para sa isang request sa parehong GPU, maliit ang agwat dahil pareho silang nagsasagawa ng parehong arithmetic. Para sa maraming concurrent request, mas mabilis ang vLLM dahil dine-decode ng continuous batching ang bawat active sequence sa iisang forward pass, habang isa-isa itong pinapatakbo ng default na configuration ng Ollama. Sa machine na CPU-only, hindi naaangkop ang tanong na ito: gumagana roon ang Ollama, ngunit halos hindi gumagana ang vLLM.

Maaari bang patakbuhin ang vLLM nang walang GPU?

Hindi sa praktikal na paraan. Ang standard wheels ay para sa NVIDIA o AMD GPUs, at nawawala sa CPU ang pangunahing dahilan kung bakit umiiral ang vLLM: ang pananatiling busy ng accelerator sa mga naka-batch na request. May CPU backend para sa development work. Para sa aktuwal na CPU inference, gamitin ang Ollama o ang llama.cpp nang direkta.

Ano ang pagkakaiba ng Ollama at llama.cpp?

Ang llama.cpp ang inference library, at ang GGUF ang quantized weight format nito. Nakabatay rito ang runner ng Ollama at idinadagdag nito ang mga bahaging ipinauubaya ng llama.cpp sa user: model registry, automatic download, resident server, systemd unit, at OpenAI-compatible endpoint. May sarili nang engine ang Ollama para sa ilang mas bagong model family, kaya hindi na ganap na magkapareho ang kanilang pinagbabatayan.

Gaano karaming GPU memory ang kailangan ng vLLM para sa 8B model?

Sa 16-bit precision, humigit-kumulang 16 GB ang kailangan ng weights lamang, o halos 2 GB bawat isang bilyong parameter, at kailangan pa ng karagdagang espasyo ng KV cache. Sapat ang 24 GB card. Ang 16 GB card ay nangangailangan ng quantized checkpoint o mas maliit na model. Gumagamit ang vLLM ng fraction ng card na itinakda ng --gpu-memory-utilization, na naka-default sa 0.92 noong July 2026.

Kailangan ko bang baguhin ang application code para lumipat sa pagitan ng mga ito?

Karaniwan, base URL, API key, at model name lamang ang kailangang baguhin. Ibinibigay ng Ollama ang OpenAI-compatible surface nito sa http://127.0.0.1:11434/v1 at hindi nito pinapansin ang key, habang ibinibigay ng vLLM ang http://localhost:8000/v1 at ipinapatupad nito ang key kung magtatakda ka ng isa. Magkaiba ang anyo ng model names: llama3.1:8b para sa Ollama, at isang buong repository id gaya ng Qwen/Qwen2.5-1.5B-Instruct para sa vLLM.