Ollama dhidi ya vLLM: Chagua seva ipi kwa LLM yako

Ollama dhidi ya vLLM, kwa aya moja

Ollama ni meneja wa mifano (model manager) aliye na seva iliyounganishwa: hupakua uzani (weights) zilizopunguzwa ukubwa (quantized), huzipakia, na kujibu kwenye 127.0.0.1:11434, hata kwenye CPU ikiwa ndiyo rasilimali pekee inayopatikana. vLLM ni injini ya utendaji wa juu (throughput engine): huweka GPU katika hali ya kufanya kazi kwa uwezo wake wote kwa kushughulikia maombi mengi kwa wakati mmoja, na ni zana isiyofaa kwenye mashine isiyo na GPU. Hiyo ndiyo msingi wa uamuzi. Mtu mmoja anayezungumza na msaidizi wa ndani (local assistant) ni kazi ya Ollama. Programu inayohudumia timu ni kazi ya vLLM.

Zote mbili hutumia HTTP API inayooana na OpenAI, kwa hivyo msimbo wa mteja (client code) unaweza kuhama kati yao kwa kubadilisha tu base URL. API siyo tofauti iliyopo. Tofauti ni kile kinachotokea wakati ombi la pili linapowasili wakati la kwanza bado linazalisha token.

Ollama ni nini hasa

Ollama ni safu ya urahisi. Inakupa sajili ya modeli (ollama pull llama3.1:8b), hifadhi ya ndani ya uzani (weights), prompt ya gumzo, huduma ya systemd, na HTTP API, kupitia amri moja ya usakinishaji. Modeli inazohudumia ni faili za GGUF, ambazo kwa kawaida huwa na quantization ya 4-bit, ndiyo maana modeli ya 7B au 8B inachukua takriban 5 GB kwenye diski badala ya 16 GB. Quantization ndiyo inayofanya inference ya CPU iwezekane kabisa.

Runner yake imejengwa juu ya llama.cpp, maktaba ya inference ya C++ iliyofanya quantization ya GGUF iwe ya vitendo kwenye maunzi ya kawaida. Tangu wakati huo, Ollama imeongeza injini yake yenyewe kwa ajili ya familia mpya za modeli, lakini llama.cpp bado ndiyo msingi wa sehemu kubwa ya kile inachohudumia. Kwa hivyo, watu wanapolinganisha Ollama na llama.cpp, kimsingi wanalinganisha safu ya urahisi wa matumizi na kitu inachokifungasha.

Lengo la usanifu ni mtumiaji mmoja. Kufikia Julai 2026, thamani chaguo-msingi ya OLLAMA_NUM_PARALLEL ni 1, ikimaanisha kuwa modeli moja huchakata ombi moja kwa wakati mmoja na kila kitu kingine husubiri kwenye foleni inayoshikilia maingizo 512 kwa chaguo-msingi (OLLAMA_MAX_QUEUE). Unaweza kuongeza mpangilio wa parallel, na sehemu iliyo hapa chini inaelezea gharama zake. Ikiwa hujawahi kutumia Ollama hapo awali, anza na hosting Ollama kwenye VPS na kuweka port 11434 ikiwa imefungwa, kwa sababu API haina uthibitishaji wa aina yoyote.

vLLM ni nini hasa

vLLM ni seva ya inference na si kitu kingine. Haidhibiti maktaba ya modeli, haina chat prompt, na haitapakua modeli kwa ajili yako wakati wa ombi. Unataja Hugging Face repository wakati wa kuanzisha, inapakia modeli hiyo moja, na inaitumikia hadi utakapositisha mchakato huo.

Unachopata kwa ufinyu huo wa utendaji ni throughput. Mifumo miwili inafanya kazi hiyo. PagedAttention huhifadhi KV cache (key-value cache, hali ya attention ya kila token ambayo modeli huiweka kwa kila ombi linaloendelea) katika vizuizi vya ukubwa maalum, kama vile mfumo wa uendeshaji unavyopanga kumbukumbu. Ombi halihitaji tena nafasi kubwa mfululizo iliyotengwa kwa ajili ya hali mbaya zaidi, kwa hivyo kumbukumbu iliyokuwa imetengwa na kutotumika inapatikana kwa ajili ya maombi mengi zaidi ya wakati mmoja. Continuous batching inaruhusu ombi jipya kujiunga na batch inayoendelea katika hatua inayofuata ya decoding badala ya kusubiri batch ya sasa imalizike. Mfuatano uliomalizika huondoka kwenye batch mara moja na nafasi yake hujazwa tena.

Matokeo ya kivitendo: kwenye GPU moja, kutoka kwa mtumiaji mmoja hadi thelathini huongeza jumla ya tokens kwa sekunde kwa kasi, huku kasi kwa kila mtumiaji ikishuka kidogo sana kuliko unavyotarajia. Chini ya mpangilio chaguo-msingi wa Ollama, kutoka kwa mtumiaji mmoja hadi thelathini huwafanya watu ishirini na tisa kusubiri tu.

Continuous batching ndiyo tofauti kuu

Wazia maombi matano yakifika kwenye kila seva kwa wakati mmoja kwenye maunzi yanayofanana.

Ollama yenye mipangilio chaguo-msingi huendesha ombi la kwanza hadi likamilike, kisha la pili, na kuendelea. Mpigaji simu wa tano anasubiri vizazi vinne kamili. Jumla ya throughput ni takriban kasi ya kizazi kimoja, kwa sababu processor inafanya kazi kwenye mlolongo mmoja tu kwa wakati mmoja.

vLLM hufanya decoding ya maombi yote matano katika forward pass moja. Kuzalisha token moja kwa mlolongo mitano hugharimu kiasi kidogo zaidi kuliko kuzalisha token moja kwa mlolongo mmoja, kwa sababu sehemu ya gharama kubwa ni kusoma uzito wa model (model weights) kutoka kwenye kumbukumbu, na usomaji huo unashirikiwa kwenye batch nzima. Hii ni kanuni ileile ya memory-bandwidth inayofanya CPU inference kuwa polepole: unalipia kusogeza uzito, si kwa ajili ya hesabu.

Unaweza kuweka OLLAMA_NUM_PARALLEL=4 na kupata sehemu ya uwezo huu. Gharama yake ni kumbukumbu. Kila slot inayofanya kazi sambamba inahitaji KV cache yake, na Ollama hugawanya context window kwenye slots hizo, kwa hivyo maombi manne yanayofanyika sambamba dhidi ya model iliyosanidiwa kwa 8192 tokens huacha kila ombi na 2048 tokens za context. Hiyo 8192 yenyewe ni chaguo badala ya kitu kilichopo, kwa hivyo kuongeza num_ctx na kupima RAM inayohitajika ndiyo hatua inayoamua kama slots nne zinaweza kutumika hata kidogo. Paged cache ya vLLM ndiyo inayozuia changamoto hiyo, kwa sababu blocks hutengwa kwa ombi kadiri ombi linavyokua. Vyovyote vile, ukomo wa idadi ya watu ambao seva moja inaweza kuwahudumia kwa wakati mmoja unategemea ukubwa wa KV cache, gharama ya prefill, na kina cha foleni, ambayo ndiyo sababu inayofanya seva iliyokuwa ikifanya kazi vizuri kwa mtu mmoja kusuasua kwa watu watano.

Kusakinisha na kuhudumia kwa kutumia 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."

Hati ya usakinishaji hutengeneza mtumiaji wa mfumo wa ollama, husakinisha binary, na kusajili ollama.service iliyofungwa kwenye 127.0.0.1:11434. Mstari wa eval rate unaochapishwa na --verbose ndio idadi halisi ya tokeni kwa sekunde kwenye seva hiyo. Iamini hiyo kuliko takwimu yoyote iliyochapishwa. Usomaji mmoja kutoka kwa prompt moja ni hatua ya kuanzia badala ya namba ya uwezo, kwa hivyo kupima tokeni kwa sekunde katika mfululizo wa concurrency ndiko kunakuambia kama seva inastahimili mzigo unaotarajia, na kama kukodisha GPU ni nafuu kuliko kulipia kwa kila tokeni.

Ili kuongeza concurrency, tumia systemd drop-in ili uboreshaji usifute mabadiliko hayo:

sudo systemctl edit ollama.service

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

sudo systemctl restart ollama
ollama ps

ollama ps huonyesha kile kilichopakiwa, na safu yake ya PROCESSOR husema ukweli. 100% CPU inamaanisha hakuna GPU inayotumika, ambayo ndiyo sababu ya kweli ya ripoti nyingi zinazosema Ollama ni polepole. Mstari wa OLLAMA_KEEP_ALIVE=30m katika drop-in hiyo ni muhimu vilevile kwenye seva tulivu, kwa sababu chaguo-msingi huondoa model baada ya dakika tano bila ombi, na kuiacha model ikiwa imepakiwa kati ya maombi ndiko kunakozuia prompt ya kwanza baada ya saa moja ya kutofanya kazi kulipia muda kamili wa kupakia tena.

Kusakinisha na kuhudumia kwa kutumia vLLM

vLLM inahitaji Linux na Python 3.10 hadi 3.13. Isakinishe ndani ya mazingira yake ya virtual (virtual environment), kwa sababu inavuta toleo maalum la PyTorch:

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

Kisha hudumia modeli. Jina lake ni kitambulisho cha hazina ya Hugging Face, si tag fupi:

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

Kuanza kwa mara ya kwanza ni polepole, kwa sababu inapakua uzito (weights) na kisha kuchanganua GPU ili kuamua ni vizuizi vingapi vya KV cache vinaweza kutoshea. Inasikiliza kwenye port 8000. Iangalie kabla ya kuandika msimbo wowote wa mteja:

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

Ikiwa Docker tayari ipo kwenye seva, image rasmi inaepuka kazi ya utegemezi wa 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 inahitajika, siyo ya kupambia: PyTorch hupitisha tensors kati ya michakato kupitia kumbukumbu ya pamoja (shared memory), na mgao wa kawaida wa kumbukumbu ya pamoja wa Docker ni mdogo sana kwa ajili ya inference ya tensor-parallel.

Flags ambazo ni muhimu zaidi katika uzalishaji (production) ni --max-model-len (dirisha la muktadha ambalo uko tayari kulipia), --gpu-memory-utilization (sehemu ya kadi ambayo vLLM inaweza kudai, 0.92 kama ilivyo kawaida kuanzia Julai 2026), --tensor-parallel-size kwa ajili ya kugawanya modeli moja kwenye GPU kadhaa, na --api-key.

Uthibitishaji ni flag moja kwenye vLLM na haipo kwenye Ollama

vLLM inalazimisha bearer token ikiwa utaipa:

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

Thamani hiyo hiyo inaweza kutoka kwenye environment variable ya VLLM_API_KEY. Ombi lisilo na token hiyo hupata HTTP 401. Hiyo bado si sababu ya kuchapisha port 8000 kwenye interface ya umma, kwa sababu vLLM haina rate limiting na token ya plain HTTP inaweza kusomeka wakati wa usafirishaji, lakini inamaanisha seva ina dhana ya mpigaji (caller).

Ollama haina kitu chochote. Hakuna key, hakuna login, hakuna allow-list. Mchakato wowote unaoweza kufikia 11434 unaweza kuendesha, kupakua, au kufuta models. Iweke kwenye loopback na uifikie kupitia VPN ya WireGuard unayojiendeshea mwenyewe, au kupitia reverse proxy inayothibitisha mtumiaji na kumalizia TLS (transport layer security).

Hardware: mahitaji ya kila kifaa

Ollama hufanya kazi kwenye CPU. Model iliyokadiriwa kwa 4-bit hutumia takriban nusu gigabyte ya RAM kwa kila bilioni moja ya parameters, pamoja na takriban gigabyte moja ya runtime overhead na ziada kwa ajili ya context. Hivyo, model ya 3B inahitaji takriban 4 GB ya RAM iliyo wazi, na model ya 8B inahitaji takriban 8 GB. Kasi kwenye vCPU inayoshirikiwa ni kati ya token chache hadi kumi na kitu kwa sekunde. Hii inatokana na uwezo wa memory bandwidth, si kosa la configuration, na hakuna flag inayoweza kurekebisha hilo. Ili kufuatilia hesabu hiyo kwenye release mahususi badala ya kutumia makadirio ya jumla, kuendesha Nemotron 3.5 Lightning kwenye VPS huonyesha tag sahihi ya kuvuta, kiasi cha RAM kinachotumiwa baada ya kupakia, na kama kasi ya CPU pekee inatosha kwa matumizi yako.

vLLM inahitaji GPU. Njia yake ya kawaida hutumia weights zisizokadiriwa (unquantized) kwa 16-bit precision, ambayo ni takriban 2 GB kwa kila bilioni moja ya parameters: model ya 8B inahitaji takriban 16 GB ya video memory kwa ajili ya weights pekee, kabla ya kuhesabu KV cache inayokupa concurrency uliyoweka vLLM kwa ajili yake. Kwenye kadi ya 24 GB, hii huacha nafasi ya kutosha kwa cache. Kwenye kadi ya 16 GB, nafasi haitoshi, kwa hivyo lazima uchague model ndogo au utumie --quantization pamoja na quantized checkpoint. Backend ya CPU ipo, lakini wheels za kawaida hazijajengwa kwa ajili yake, na inafuta sababu ya msingi ya kutumia vLLM.

Kwa hivyo, swali la hardware hujibu swali la software mara nyingi. Kutokuwa na GPU kunamaanisha Ollama. GPU iliyokodiwa inayotumia asilimia 5 ya uwezo wake kwa sababu maombi yanapangwa kwa mtiririko (serialised) inamaanisha unahitaji vLLM.

Ni ipi inayofaa kwa mzigo wako wa kazi

• Mtu mmoja, CPU VPS, kwa ajili ya kuandaa rasimu na kufupisha: Ollama. Kasi yake inakubalika na hakuna kitu kingine rahisi zaidi.
• Msaidizi wa uandishi wa msimbo, au seva ya MCP inayounganisha zana zako na modeli ya ndani, ambayo wewe pekee ndiye unayeitumia: Ollama. Utekelezaji wa kazi moja kwa wakati mmoja ndio mzigo halisi wa kazi.
• Kulinganisha modeli tano kwa wiki hii: Ollama. Kuvuta na kufuta modeli zilizotambulishwa ndilo jambo ambalo inalifanya vizuri, wakati vLLM inahitaji kuanzisha upya mchakato (process) kwa kila modeli.
• Programu ya ndani, bidhaa ya gumzo, au mfumo wa urejeshaji data wenye watumiaji halisi: vLLM. Hapa ndipo uwezo wa batching unahalalisha gharama ya GPU.
• Kazi ya kundi (batch job) inayochakata mamia ya maelfu ya hati usiku kucha: vLLM, ikiwa na --max-num-seqs ya juu. Kiwango cha utendaji (throughput) ndicho kipimo pekee cha maana na muda wa kusubiri kwa kila hati (per-document latency) si muhimu.
• Jukwaa la wakala ambapo mawakala wa AI wanaojiendesha wenyewe wanatumia modeli kwa wakati mmoja: vLLM, kwa sababu trafiki ya mawakala huwa ya ghafla na ya sambamba (parallel) kwa asili yake.

Njia za kufeli, pamoja na ujumbe utakaouona

vLLM inakataa kuanza kutokana na hitilafu ya KV cache. Ujumbe huo unataja namba zote mbili:

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.

Modeli inatangaza ukubwa wa context window unaozidi kumbukumbu iliyobaki baada ya kupakia weights. Ipunguze kwa kutumia --max-model-len 8192, au ongeza --gpu-memory-utilization ikiwa hakuna kitu kingine kinachotumia kadi hiyo. Kusukuma matumizi ya rasilimali zaidi ya 0.95 mara nyingi husababisha hitilafu hii ya kuanza badala ya CUDA out-of-memory crash baadaye, wakati wa mzigo mkubwa, jambo ambalo ni baya zaidi.

Ollama inachapisha Killed katikati ya generation. Mchakato wa Linux wa out-of-memory killer umesimamisha mchakato huo kwa sababu modeli ilihitaji RAM nyingi kuliko ile inayopatikana kwenye seva. Thibitisha kwa sudo dmesg | grep -i oom. Suluhisho ni kutumia modeli ndogo au iliyofanyiwa quantization zaidi, siyo kubadili mipangilio.

Ollama inajibu vizuri ikiwa peke yake lakini inakwama chini ya mzigo. Hakuna hitilafu inayotokea popote. Maombi huchukua muda mrefu zaidi kadiri idadi ya watumiaji inavyoongezeka, kwa sababu OLLAMA_NUM_PARALLEL=1 inafanya kazi kwa mtiririko (serialising). Majibu marefu hufanya foleni kuwa mbaya zaidi, kwa sababu mtumiaji mmoja anayeshikilia nafasi pekee hadi modeli iamue kusimama huwazuia wengine wote walio nyuma yake, kwa hivyo kudhibiti jibu kwa num_predict huweka ukomo wa muda ambao zamu moja inaweza kushikilia seva. Ongeza mpangilio wa parallel na ukubali context ndogo kwa kila ombi, au hamishia mzigo wa kazi kwenye vLLM.

vLLM inarudisha 401 kwenye kila ombi. Uliianzisha kwa --api-key na mteja hatumi header ya Authorization. Maktaba nyingi za mteja wa OpenAI hutuma chochote unachopitisha kama key, kwa hivyo iweke hapo badala ya kuondoa flag hiyo.

vLLM inasema modeli haijapatikana. Ollama hupakua inapohitajika, vLLM haifanyi hivyo. Sehemu ya model katika mwili wa ombi lazima ilingane na repository id uliyotumia wakati wa kuanzisha, au thamani ya --served-model-name ikiwa uliweka moja. Thibitisha mfuatano kamili wa herufi kwa curl http://localhost:8000/v1/models.

Kuendesha zote mbili ni jibu linalofaa

Hizi si huduma zinazotengana. Muundo wa kawaida ni kutumia vLLM kwenye instance ya GPU inayohudumia programu, huku Ollama ikiwa kwenye VPS ya kawaida kando yake kwa ajili ya hati za ndani (scripts), cron jobs, na kujaribu matoleo mapya ya model. Endpoint zote mbili zinaoana na OpenAI, kwa hivyo maktaba moja ya mteja na kubadili base-URL kunatosha kuzitumia zote. Udhibiti wa gharama ni muhimu zaidi hapa kuliko injini yoyote kati ya hizo, kwa sababu GPU iliyo wazi hutoza gharama sawa na ile inayofanya kazi, na kudumisha gharama za wakala na inference kuwa zinazotabirika ni taaluma tofauti na kuchagua seva.

FAQ

Je, vLLM ni ya kasi zaidi kuliko Ollama?

Kwa ombi moja kwenye GPU ileile, tofauti ni ndogo kwa sababu zote hufanya hesabu zilezile. Kwa maombi mengi yanayokuja kwa wakati mmoja, vLLM iko mbele zaidi kwa sababu "continuous batching" hufanya decoding ya kila mlolongo unaoendelea katika hatua moja ya mbele (forward pass), wakati Ollama kwa kawaida huyaendesha moja baada ya lingine. Kwenye mashine ya CPU pekee, swali hili halina maana: Ollama huendesha huko, lakini vLLM haifanyi hivyo kwa ufanisi.

Je, vLLM inaweza kuendesha bila GPU?

Si kwa ufanisi. Vifurushi vya kawaida (wheels) vinalenga GPU za NVIDIA au AMD, na sababu ya kuwepo kwa vLLM—kuhakikisha kiongeza kasi (accelerator) kinajaa maombi yaliyopangwa kwa makundi—hupotea kwenye CPU. Backend ya CPU ipo kwa ajili ya kazi za maendeleo (development). Kwa inference ya kweli kwenye CPU, tumia Ollama au llama.cpp moja kwa moja.

Kuna tofauti gani kati ya Ollama na llama.cpp?

llama.cpp ni maktaba ya inference, na GGUF ni muundo wake wa uzani uliopunguzwa (quantized weight format). Runner ya Ollama imejengwa juu yake na kuongeza sehemu ambazo llama.cpp inakuachia wewe: sajili ya modeli, upakuaji wa kiotomatiki, seva inayokaa kwenye kumbukumbu, unit ya systemd, na endpoint inayooana na OpenAI. Ollama imeongeza injini yake yenyewe kwa ajili ya familia mpya za modeli, kwa hivyo hizo mbili hazifanani tena kwa ndani.

vLLM inahitaji kumbukumbu ya GPU kiasi gani kwa modeli ya 8B?

Katika usahihi wa 16-bit, uzani pekee ni takriban 16 GB, takriban 2 GB kwa kila bilioni ya vigezo (parameters), na KV cache inahitaji nafasi zaidi ya hapo. Kadi ya 24 GB inatosha vizuri. Kadi ya 16 GB inahitaji checkpoint iliyopunguzwa (quantized) au modeli ndogo zaidi. vLLM hutumia sehemu ya kadi iliyowekwa na --gpu-memory-utilization, ambayo ni 0.92 kuanzia Julai 2026.

Je, ninahitaji kubadilisha msimbo wa programu yangu ili kubadili kati yao?

Kwa kawaida ni URL ya msingi, API key, na jina la modeli pekee. Ollama hutoa huduma yake inayooana na OpenAI kwenye http://127.0.0.1:11434/v1 na hupuuza ufunguo (key), wakati vLLM hutoa http://localhost:8000/v1 na hulazimisha ufunguo ikiwa utauweka. Majina ya modeli hutofautiana katika umbo: llama3.1:8b kwa Ollama, na kitambulisho kamili cha hazina (repository id) kama vile Qwen/Qwen2.5-1.5B-Instruct kwa vLLM.