Ollama vs vLLM: Alin ang Tamang LLM Server?

Ollama kumpara sa vLLM, sa isang talata

Ang Ollama ay isang model manager na may kasamang 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 lang ang mayroon ang machine. Ang vLLM ay isang throughput engine: pinananatili nitong abala ang GPU sa maraming request na sabay-sabay na tumatakbo, kaya maling tool ito sa machine na walang GPU. Iyon ang buong batayan ng pagpili. Ang isang tao na nakikipag-usap sa isang local assistant ay isang Ollama job. Ang 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 ng mga ito sa pamamagitan ng pagpapalit ng base URL. Hindi ang API ang pinagkaiba. Ang pinagkaiba ay ang nangyayari kapag may dumating na second request habang nagge-generate pa ng tokens ang unang request.

Kung ano talaga ang Ollama

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

Nakabatay ang runner nito sa llama.cpp, ang C++ inference library na nagpa-practical sa GGUF quantization sa karaniwang hardware. Nagdagdag na rin ang Ollama ng sarili nitong engine para sa ilang mas bagong model family, pero llama.cpp pa rin ang substrate sa ilalim ng karamihan ng sine-serve nito. Kaya kapag ikinumpara ng mga tao ang Ollama sa llama.cpp, kadalasan ay ikinukumpara nila ang isang ergonomics layer sa mismong tool na binabalot nito.

Isang user ang target ng disenyo nito. Noong July 2026, ang default ng OLLAMA_NUM_PARALLEL ay 1. Ibig sabihin, isang request lang ang pinoproseso ng isang model sa bawat pagkakataon, habang naghihintay sa queue ang lahat ng iba pa. Ang queue na ito ay may default na kapasidad na 512 entries (OLLAMA_MAX_QUEUE). Maaari mong taasan ang parallel setting, at ipinapaliwanag ng susunod na section ang magiging kapalit nito. Kung hindi mo pa nagagamit ang Ollama, magsimula sa pag-host ng Ollama sa isang VPS at pagpapanatiling sarado ng port 11434, dahil walang anumang authentication ang API.

Ano talaga ang vLLM

Ang vLLM ay inference server lamang. Hindi ito namamahala ng model library, wala itong chat prompt, at hindi ito awtomatikong kukuha ng model kapag may request. Tinutukoy mo ang isang Hugging Face repository sa oras ng pag-launch, nilo-load nito ang model na iyon, at sine-serve ito hanggang ihinto mo ang proseso.

Ang kapalit ng limitadong saklaw na ito ay mataas na throughput. Dalawang mekanismo ang gumagawa nito. Iniimbak ng PagedAttention ang KV cache (key-value cache, ang per-token attention state na pinananatili ng model para sa bawat aktibong request) sa mga block na may nakapirming laki, gaya ng pag-page ng memory ng operating system. Hindi na kailangan ng request ng isang malaking magkadugtong na reservation na nakabatay sa pinakamasamang sitwasyon, kaya nagagamit para sa mas maraming concurrent request ang memory na dati ay naka-reserve pero hindi ginagamit. Sa continuous batching, maaaring sumali ang bagong request sa kasalukuyang batch sa susunod na decoding step sa halip na maghintay na matapos ang buong batch. Agad na umaalis sa batch ang natapos na sequence, at napapalitan ang slot nito.

Ang praktikal na resulta: sa iisang GPU, kapag tumaas mula 1 concurrent user tungo sa 30, malaki ang itinaas ng kabuuang tokens per second, habang mas kaunti kaysa inaasahan ang ibinabagsak ng bilis para sa bawat user. Sa default ng Ollama, kapag tumaas mula 1 user tungo sa 30, naghihintay lamang ang 29 na tao.

Continuous batching ang pangunahing pagkakaiba

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

Sa default settings, pinoproseso ng Ollama ang unang request hanggang matapos bago simulan ang ikalawa, at nagpapatuloy ito sa ganitong paraan. Maghihintay ang ikalimang 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 naibabahagi ang read na ito sa buong batch. Ito rin ang memory-bandwidth fact kung bakit mabagal ang CPU inference: ang binabayaran mo ay ang paglipat ng weights, hindi ang arithmetic.

Maaari mong i-set ang OLLAMA_NUM_PARALLEL=4 para makuha ang ilan sa benepisyong ito. Memory ang kapalit. Kailangan ng bawat parallel slot ng sarili nitong KV cache, at hinahati ng Ollama ang context window sa mga slot. Kaya kung may apat na parallel request laban sa model na naka-configure para sa 8192 tokens, 2048 tokens ng context ang natitira sa bawat request. Ang 8192 ay isa ring configuration choice, hindi isang nakatakdang halaga. Kaya ang pagtaas ng num_ctx at pagtukoy sa RAM na kailangan nito ang hakbang na magpapasya kung magagamit ba talaga ang apat na slot. Ang paged cache ng vLLM ang umiiwas sa trade-off na ito, dahil naglalaan ito ng mga block sa isang request habang aktuwal na lumalaki ang request. Sa alinmang paraan, nakadepende sa laki ng KV cache, prefill cost, at queue depth kung ilang tao ang sabay-sabay na kayang pagsilbihan ng isang server. Ito ang dahilan kung bakit bumabagal sa limang user ang isang server na maayos ang takbo para sa isang user.

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 ipinapakita ng --verbose ang aktuwal na tokens per second sa server na iyon. Mas dapat itong pagkatiwalaan kaysa sa anumang published figure. Panimulang reference lamang ang isang reading mula sa isang prompt, hindi ito sukat ng capacity. Kaya ang pagsukat ng tokens per second sa iba't ibang concurrency level ang nagpapakita kung kakayanin ng server ang load na talagang inaasahan mo, at kung mas makatitipid ang pag-rent ng GPU kaysa sa pagbabayad bawat token.

Para pataasin ang concurrency, gumamit ng systemd drop-in upang hindi ma-overwrite ang pagbabago kapag nag-upgrade:

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 ang 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 report na mabagal ang Ollama. Mahalaga rin ang OLLAMA_KEEP_ALIVE=30m line sa drop-in na iyon kapag walang gaanong traffic, dahil bina-unload ng default ang model pagkatapos ng limang minuto na walang request. Ang pagpapanatiling resident ng model sa pagitan ng mga request ang pumipigil sa unang prompt matapos ang isang oras na idle na muling maghintay sa buong load time.

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. Repository id ito sa Hugging Face, hindi isang maikling tag:

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

Mabagal ang startup sa unang pagkakataon dahil dina-download muna nito ang weights at pagkatapos ay pini-profile ang GPU upang tukuyin kung ilang KV cache block ang kasya. Nakikinig ito sa port 8000. Suriin muna 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 pandekorasyon. Ipinapasa ng PyTorch ang tensors sa pagitan ng mga process gamit ang shared memory, at masyadong maliit para sa tensor-parallel inference ang default na Docker shared-memory allocation.

Ang pinakamahahalagang flag sa production ay ang --max-model-len, o ang context window na handa mong bayaran; --gpu-memory-utilization, o ang fraction ng GPU memory 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 lamang sa vLLM at wala sa Ollama

Nagpapatupad ang vLLM ng bearer token kapag binigyan mo ito:

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

Maaari ring manggaling ang parehong value sa environment variable na VLLM_API_KEY. Ang request na walang token ay nakakatanggap ng HTTP 401. Hindi pa rin ito dahilan upang i-publish ang port 8000 sa 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 magpatakbo, mag-pull, o mag-delete ng mga model. Panatilihin ito sa loopback at i-access sa pamamagitan ng isang WireGuard VPN na ikaw mismo ang nag-host, o sa pamamagitan ng authenticating reverse proxy na nagte-terminate ng TLS (transport layer security).

Hardware: ano ang kailangan ng bawat isa

Tumatakbo ang Ollama sa CPU. Ang 4-bit quantized model ay nangangailangan ng humigit-kumulang kalahating gigabyte ng RAM para sa bawat bilyong parameter, bukod pa sa humigit-kumulang isang gigabyte na runtime overhead at karagdagang memory para sa context. Kaya nangangailangan ang 3B model ng humigit-kumulang 4 GB na libreng memory, habang ang 8B model ay nangangailangan ng humigit-kumulang 8 GB. Sa shared vCPU, ang bilis ay nasa single digit hanggang mababang double digit na tokens bawat segundo. Memory bandwidth ang sanhi nito, hindi maling configuration, kaya walang flag na makapag-aayos nito. Para makita ang aktuwal na kalkulasyong ito sa isang partikular na release sa halip na umasa sa tinatayang rule of thumb, pagpapatakbo ng Nemotron 3.5 Lightning sa isang VPS ay nagtatakda ng eksaktong tag na ida-download, ang RAM na ginagamit nito kapag naka-load na, at kung sapat ang bilis ng CPU-only para maging praktikal.

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

Kaya kadalasang sinasagot ng hardware ang tanong tungkol sa software. Kung walang GPU, Ollama ang gamitin. Kung may nirentahang GPU na nasa 5 percent lang ang utilisation dahil sunod-sunod na pinoproseso ang mga request, vLLM ang gamitin.

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 rito.
• Isang coding assistant, o isang MCP server na nag-uugnay ng iyong mga tool sa isang local model, na ikaw lamang ang gumagamit: Ollama. Ang concurrency na one ay ang aktuwal na workload.
• Naghahambing ng limang model ngayong linggo: Ollama. Eksaktong ito ang mahusay nitong gawin—mag-pull at mag-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 mga user: vLLM. Dito sulit ang GPU bill dahil sa batching.
• Isang batch job na nagso-score ng isang daang libong dokumento magdamag: vLLM, na may mataas na --max-num-seqs. Throughput lamang ang mahalagang metric, at hindi mahalaga ang latency ng bawat dokumento.
• Isang agent platform kung saan sabay-sabay na kumokonekta sa model ang ilang self-hosted AI agent: vLLM, dahil likas na bursty at parallel ang traffic ng mga agent.

Mga failure mode at ang mga string na makikita mo

Tumangging mag-start ang vLLM dahil sa error sa KV cache. Binabanggit ng mensahe ang dalawang 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.

May context window ang model na mas malaki kaysa sa memory na natira matapos i-load ang weights. Bawasan ito gamit ang --max-model-len 8192, o taasan ang --gpu-memory-utilization kung walang ibang gumagamit ng GPU. Kapag itinulak ang utilisation lampas sa humigit-kumulang 0.95, kadalasang napapalitan ang startup error ng CUDA out-of-memory crash kapag may load na. Mas masama ang huli sa dalawang ito.

Nagpi-print ang Ollama ng Killed sa kalagitnaan ng generation. Pinahinto ng Linux out-of-memory killer ang process 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 gumamit ng mas maliit o mas heavily quantized na model, hindi magbago ng setting.

Maayos sumagot ang Ollama kapag mag-isa, pero nagse-stall kapag may load. Walang lumalabas na error kahit saan. Mas tumatagal lang ang mga request habang dumarami ang caller dahil sini-serialize ng OLLAMA_NUM_PARALLEL=1 ang mga ito. Mas lumalala ang queue kapag mahahaba ang sagot, dahil hinaharangan ng isang caller na may hawak ng nag-iisang slot ang lahat ng nasa likod nito hanggang magpasya ang model na huminto. Kaya ang pag-cap sa reply gamit ang num_predict ay naglalagay ng limitasyon sa tagal ng paghawak ng bawat turn sa server. Taasan ang parallel setting at tanggapin ang mas maliit na per-request context, o ilipat ang workload sa vLLM.

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

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

Parehong patakbuhin ay isang makatuwirang sagot

Hindi kailangang pumili ng isa lamang. Karaniwang setup ang vLLM sa isang GPU instance para maghatid ng application, habang nasa ordinaryong VPS ang Ollama para sa mga lokal na script, cron job, at pagsubok ng mga bagong model release. OpenAI-compatible ang parehong endpoint, kaya sapat na ang isang client library at pagpapalit ng base URL para magamit ang mga ito. Mas mahalaga rito ang cost control kaysa sa alinmang engine, dahil pareho ang singil sa idle na GPU at sa busy na GPU. Hiwalay na disiplina ang pagpapanatiling predictable ng gastos sa agent at inference kumpara sa pagpili ng server.

Mga FAQ

Mas mabilis ba ang vLLM kaysa sa Ollama?

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

Maaari bang patakbuhin ang vLLM nang walang GPU?

Hindi ito praktikal. Ang standard wheels ay para sa NVIDIA o AMD GPU, at nawawala sa CPU ang pangunahing dahilan kung bakit ginagamit ang vLLM: ang pananatiling abala ng accelerator sa mga batched request. May CPU backend para sa development work. Para sa aktuwal na CPU inference, gamitin nang direkta ang Ollama o llama.cpp.

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 iyo: model registry, automatic download, resident server, systemd unit, at OpenAI-compatible endpoint. Nagdagdag ang Ollama ng sarili nitong engine para sa ilang mas bagong model family, kaya hindi na ganap na magkapareho ang mga ito sa ilalim.

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. Kailangan din ng karagdagang espasyo para sa KV cache. Komportable ang 24 GB card. Sa 16 GB card, kailangan ng quantized checkpoint o mas maliit na model. Inaangkin ng vLLM ang bahaging itinakda ng --gpu-memory-utilization sa kabuuang memory ng card; ang default nito ay 0.92 noong July 2026.

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

Karaniwan, kailangan lamang baguhin ang base URL, API key, at model name. Ibinibigay ng Ollama ang OpenAI-compatible surface nito sa http://127.0.0.1:11434/v1 at binabalewala nito ang key, samantalang ibinibigay ng vLLM ang http://localhost:8000/v1 at ipinapatupad nito ang key kapag nagtakda ka nito. Magkaiba ang anyo ng model name: llama3.1:8b para sa Ollama at full repository id gaya ng Qwen/Qwen2.5-1.5B-Instruct para sa vLLM.