Ollama dhidi ya vLLM: Utumie ipi kuendesha LLM?

Ollama dhidi ya vLLM, katika aya moja

Ollama ni kidhibiti cha modeli chenye seva iliyoambatishwa: hupakua uzani uliopunguzwa usahihi, huupakia, na hujibu kwenye 127.0.0.1:11434, kwa kutumia CPU ikiwa hiyo ndiyo rasilimali pekee iliyo kwenye mashine. vLLM ni injini ya throughput: huweka GPU ikifanya kazi kwa kiwango cha juu kwa kuendesha maombi mengi kwa wakati mmoja, na si zana inayofaa kwenye mashine isiyo na GPU. Huo ndio uamuzi wote. Mtu mmoja anayezungumza na msaidizi wa ndani ni kazi ya Ollama. Programu inayohudumia timu ni kazi ya vLLM.

Zote mbili hutumia API ya HTTP inayooana na OpenAI, kwa hiyo msimbo wa mteja huhamishwa kati yao kwa kubadilisha URL ya msingi. API si tofauti kati yao. Tofauti inaonekana ombi la pili linapowasili wakati la kwanza bado linazalisha tokeni.

Ollama ni nini hasa

Ollama ni safu ya kurahisisha matumizi. Inakupa sajili ya modeli (ollama pull llama3.1:8b), hifadhi ya ndani ya uzani wa modeli, kidokezo cha mazungumzo, huduma ya systemd, na API ya HTTP, kupitia amri moja ya usakinishaji. Modeli inazotoa ni faili za GGUF, ambazo kwa kawaida zimepunguzwa hadi biti 4. Ndiyo maana modeli ya 7B au 8B huwa na ukubwa wa takriban 5 GB kwenye diski badala ya 16 GB. Upunguzaji wa usahihi wa modeli ndio unaowezesha uendeshaji wa makisio kwenye CPU.

Kifaa chake cha uendeshaji kimejengwa juu ya llama.cpp, maktaba ya makisio ya C++ iliyofanya upunguzaji wa usahihi wa GGUF uwezekane kwenye maunzi ya kawaida. Tangu wakati huo, Ollama imeongeza injini yake kwa baadhi ya familia mpya za modeli, lakini llama.cpp bado ndiyo msingi wa sehemu kubwa ya modeli inazotoa. Kwa hiyo, watu wanapolinganisha Ollama na llama.cpp, kwa kiasi kikubwa wanalinganisha safu ya kurahisisha matumizi na programu inayofunikwa na safu hiyo.

Muundo huu umelenga mtumiaji mmoja. Kufikia Julai 2026, chaguo-msingi la OLLAMA_NUM_PARALLEL ni 1. Hii inamaanisha kuwa modeli moja huchakata ombi moja kwa wakati mmoja, na maombi mengine yote husubiri kwenye foleni yenye nafasi 512 kwa chaguo-msingi (OLLAMA_MAX_QUEUE). Unaweza kuongeza mpangilio wa uendeshaji sambamba, na sehemu iliyo hapa chini inaeleza gharama yake. Ikiwa hujawahi kuendesha Ollama, anza kwa kuendesha Ollama kwenye VPS na kuweka port 11434 ikiwa imefungwa, kwa sababu API haina aina yoyote ya uthibitishaji.

vLLM ni nini hasa

vLLM ni seva ya inference pekee. Haisimamii maktaba ya modeli, haina prompt ya mazungumzo, na haitapakua modeli kwa ajili yako wakati wa ombi. Unataja hazina ya Hugging Face wakati wa kuianzisha, inapakia modeli hiyo moja, kisha inaihudumia hadi usitishe mchakato.

Faida ya kuwa na wigo huo finyu ni throughput. Mbinu mbili ndizo hufanya kazi hiyo. PagedAttention huhifadhi KV cache (key-value cache, hali ya attention kwa kila token ambayo modeli huihifadhi kwa kila ombi linaloendelea) katika vizuizi vyenye ukubwa maalumu, kama mfumo wa uendeshaji unavyopanga kumbukumbu katika kurasa. Ombi halihitaji tena nafasi moja kubwa iliyo karibu mfululizo na yenye ukubwa wa hali mbaya zaidi, kwa hiyo kumbukumbu iliyokuwa imetengwa bila kutumika sasa inapatikana kwa maombi mengi yanayoendeshwa kwa wakati mmoja. Continuous batching huruhusu ombi jipya kujiunga na batch inayoendelea katika hatua inayofuata ya decoding badala ya kusubiri batch ya sasa ikamilike. Mfuatano uliokamilika huondoka kwenye batch mara moja, na nafasi yake hujazwa tena.

Matokeo ya kiutendaji ni haya: kwenye GPU moja, kutoka kwa mtumiaji mmoja wa wakati mmoja hadi watumiaji thelathini huongeza kwa kiasi kikubwa jumla ya token kwa sekunde, huku kasi ya kila mtumiaji ikipungua kwa kiwango kidogo zaidi kuliko unavyotarajia. Chini ya mipangilio chaguomsingi ya Ollama, kutoka kwa mtumiaji mmoja hadi watumiaji thelathini huwaacha watu ishirini na tisa wakisubiri.

Uendeshaji wa kundi unaoendelea ndio tofauti kuu

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

Ollama yenye mipangilio chaguo-msingi huchakata ombi la kwanza hadi likamilike, kisha ombi la pili, na kuendelea hivyo. Mpigaji simu wa tano husubiri vizalishaji vinne kamili. Jumla ya upitishaji huwa takriban sawa na kasi ya kizalishaji kimoja, kwa sababu kichakataji hufanya kazi kwenye mfuatano mmoja tu kwa wakati mmoja.

vLLM hufanya decoding ya maombi yote matano katika forward pass moja. Kuzalisha tokeni moja kwa mfuatano mitano hugharimu karibu sawa na kuzalisha tokeni moja kwa mfuatano mmoja, kwa sababu sehemu inayogharimu zaidi ni kusoma uzani wa modeli kutoka kwenye kumbukumbu, na usomaji huo hushirikiwa na kundi lote. Hii ni kanuni hiyo hiyo ya bandwidth ya kumbukumbu inayofanya inference kwenye CPU kuwa polepole: gharama iko katika kuhamisha uzani, si katika hesabu.

Unaweza kuweka OLLAMA_NUM_PARALLEL=4 na kupata sehemu ya faida hii. Gharama yake ni kumbukumbu. Kila nafasi sambamba inahitaji KV cache yake, na Ollama hugawanya dirisha la muktadha kati ya nafasi hizo. Kwa hiyo, maombi manne sambamba dhidi ya modeli iliyosanidiwa kwa tokeni 8192 huacha tokeni 2048 za muktadha kwa kila ombi. Cache ya paged ya vLLM ndiyo inayoepusha ubadilishanaji huo, kwa sababu vizuizi hugawiwa ombi kadiri ombi linavyokua.

Sakinisha na uwasilishe 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."

Skripti ya usakinishaji huunda 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 unaonyesha idadi halisi ya tokeni kwa sekunde kwenye mashine hiyo. Uamini kuliko takwimu yoyote iliyochapishwa.

Ili kuongeza wakati mmoja wa uchakataji, tumia drop-in ya systemd 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 mipangilio iliyopakiwa, na safu yake ya PROCESSOR huonyesha hali halisi. 100% CPU inamaanisha kuwa hakuna GPU inayotumika. Hiyo ndiyo sababu halisi katika ripoti nyingi zinazoonyesha kuwa Ollama ni polepole.

Sakinisha na uendeshe kwa vLLM

vLLM inahitaji Linux na Python 3.10 hadi 3.13. Isakinishe katika mazingira yake ya virtual, kwa sababu huleta muundo maalum wa PyTorch:

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

Kisha toa huduma kwa model. Jina hilo ni kitambulisho cha hazina ya Hugging Face, si tag fupi:

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

Uanzishaji huwa wa polepole mara ya kwanza, kwa sababu vLLM hupakua weights kisha hufanya profiling ya GPU ili kubaini idadi ya blocks za KV cache zinazotoshea. Husikiliza kwenye port 8000. Ikague kabla ya kuandika code ya 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?"}]}'

Ikiwa Docker tayari ipo kwenye mashine, image rasmi huepuka kazi ya kushughulikia 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, si ya mapambo: PyTorch hupitisha tensors kati ya processes kupitia shared memory, na mgao chaguo-msingi wa Docker wa shared memory ni mdogo sana kwa inference ya tensor-parallel.

Flags muhimu zaidi katika production ni --max-model-len (context window unayokubali kulipia), --gpu-memory-utilization (sehemu ya GPU card ambayo vLLM inaweza kutumia, 0.92 kwa chaguo-msingi kufikia Julai 2026), --tensor-parallel-size kwa kugawanya model moja kwenye GPUs kadhaa, na --api-key.

Uthibitishaji ni bendera moja katika vLLM na haupo katika Ollama

vLLM hutumia tokeni ya bearer ukiipatia tokeni hiyo:

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

Thamani hiyo inaweza pia kutoka katika kigezo cha mazingira cha VLLM_API_KEY. Ombi lisilo na tokeni hiyo hupokea HTTP 401. Hilo bado si sababu ya kuchapisha port 8000 kwenye kiolesura cha umma, kwa sababu vLLM haina udhibiti wa kasi ya maombi na tokeni ya HTTP isiyosimbwa inaweza kusomeka wakati wa upitishaji. Hata hivyo, hii inamaanisha kuwa seva ina dhana ya mtumaji wa ombi.

Ollama haina utaratibu huo. Hakuna key, hakuna kuingia, wala orodha ya anwani zinazoruhusiwa. Mchakato wowote unaoweza kufikia 11434 unaweza kuendesha, kuvuta, au kufuta modeli. Iache kwenye loopback na uifikie kupitia VPN ya WireGuard unayojiendeshea mwenyewe, au kupitia reverse proxy inayothibitisha watumiaji na kukatisha TLS (usalama wa safu ya usafirishaji).

Vifaa: kila kimoja kinahitaji nini

Ollama hutumia CPU. Modeli iliyopunguzwa hadi biti 4 hutumia takriban nusu gigabaiti ya RAM kwa kila parameta bilioni moja, pamoja na takriban gigabaiti moja ya ziada ya uendeshaji na nafasi zaidi kwa muktadha. Kwa hiyo, modeli ya 3B inahitaji takriban 4 GB ya nafasi huru, na modeli ya 8B takriban 8 GB. Kasi kwenye vCPU inayoshirikiwa ni tokeni za tarakimu moja hadi tarakimu mbili za chini kwa sekunde. Hii husababishwa na kipimo data cha kumbukumbu, si usanidi usio sahihi, na hakuna flag inayoweza kurekebisha hali hiyo.

vLLM inahitaji GPU. Njia yake chaguo-msingi huhudumia uzani ambao haujapunguzwa kwa usahihi wa biti 16. Hii ni takriban 2 GB kwa kila parameta bilioni moja. Kwa hiyo, modeli ya 8B inahitaji takriban 16 GB za kumbukumbu ya video kwa ajili ya uzani pekee, kabla ya kuhesabu akiba ya KV inayokuwezesha kutumia concurrency ambayo uliweka vLLM kwa ajili yake. Kwenye kadi ya 24 GB, hilo huacha nafasi inayotosha kwa akiba hiyo. Kwenye kadi ya 16 GB, haitoshi. Kwa hiyo, unachagua modeli ndogo au unapitisha --quantization pamoja na checkpoint iliyopunguzwa. Backend ya CPU ipo, lakini wheels za kawaida hazijajengwa kwa ajili yake. Pia huondoa sababu ya kutumia vLLM.

Kwa hiyo, swali la vifaa mara nyingi hujibu swali la programu. Ikiwa hakuna GPU, tumia Ollama. GPU iliyokodishwa inayotumia asilimia 5 tu kwa sababu maombi yanawekwa kwenye foleni moja baada ya jingine inamaanisha utumie vLLM.

Ipi kwa mzigo wako wa kazi

• Mtu mmoja, VPS yenye CPU, akiandika rasimu na kufanya muhtasari: Ollama. Kasi inakubalika, na hakuna njia nyingine iliyo rahisi zaidi.
• Msaidizi wa kuandika msimbo, au seva ya MCP inayounganisha zana zako na modeli ya ndani, ambayo ni wewe pekee unayeiita: Ollama. Ulinganifu wa ombi moja ndio mzigo halisi wa kazi.
• Ukilinganisha modeli tano wiki hii: Ollama. Kupakua na kufuta modeli zenye lebo ndicho inachofanya vizuri, ilhali vLLM huhitaji kuanzisha upya mchakato kwa kila modeli.
• Programu ya ndani, bidhaa ya mazungumzo, au mfumo wa retrieval wenye watumiaji halisi: vLLM. Hapa ndipo batching inapotumia vizuri gharama ya GPU.
• Kazi ya batch inayopima hati laki moja usiku kucha: vLLM, yenye --max-num-seqs ya juu. Throughput ndiyo kipimo pekee muhimu, na latency ya kila hati si muhimu.
• Jukwaa la mawakala ambalo mawakala kadhaa wa AI wanaojipangia huifikia modeli kwa wakati mmoja: vLLM, kwa sababu trafiki ya mawakala huongezeka ghafla na kwa asili huwa ya sambamba.

Njia za kushindwa, pamoja na mifuatano utakayoona

vLLM inakataa kuanza ikiwa na hitilafu ya akiba ya KV. Ujumbe hutaja nambari 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 dirisha la muktadha ambalo ni kubwa kuliko kumbukumbu iliyobaki baada ya kupakia uzani. Ipunguze kwa --max-model-len 8192, au ongeza --gpu-memory-utilization ikiwa hakuna kitu kingine kinachotumia kadi hiyo. Kuongeza matumizi zaidi ya takribani 0.95 kwa kawaida hubadilisha hitilafu hii ya kuanzisha kuwa kuanguka kwa CUDA kwa sababu ya kukosa kumbukumbu baadaye, wakati wa mzigo. Hilo ni baya zaidi kati ya hali hizo mbili.

Ollama inachapisha Killed katikati ya uundaji wa jibu. Kikomeshi cha Linux cha ukosefu wa kumbukumbu kilisimamisha mchakato kwa sababu modeli ilihitaji RAM zaidi kuliko iliyo kwenye seva. Thibitisha kwa sudo dmesg | grep -i oom. Suluhisho ni kutumia modeli ndogo au iliyobanwa zaidi, si kubadilisha mpangilio.

Ollama hujibu vizuri peke yake lakini husimama wakati wa mzigo. Hakuna hitilafu inayoonekana popote. Maombi huchukua muda mrefu zaidi kadiri wapigaji wa maombi wanavyoongezeka, kwa sababu OLLAMA_NUM_PARALLEL=1 huyachakata kwa mfuatano. Iongeze na ukubali muktadha mdogo kwa kila ombi, au hamishia mzigo huo kwenye vLLM.

vLLM inarudisha 401 kwenye kila ombi. Uliianzisha kwa --api-key, lakini mteja hatumi kichwa cha Authorization. Maktaba nyingi za mteja wa OpenAI hutuma thamani yoyote unayoweka kama ufunguo. Kwa hiyo, iweke humo badala ya kuondoa alama hiyo.

vLLM inasema modeli haipatikani. Ollama hupakua inapohitajika, lakini vLLM haifanyi hivyo. Sehemu ya model katika mwili wa ombi lazima ilingane na kitambulisho cha hazina ulichotumia kuanzisha, au thamani ya --served-model-name ikiwa uliiweka. Thibitisha mfuatano halisi kwa curl http://localhost:8000/v1/models.

Kuendesha zote mbili ni jibu linalofaa

Hazitengani. Muundo wa kawaida ni kutumia vLLM kwenye instance yenye GPU ili kuhudumia programu, na Ollama kwenye VPS ya kawaida iliyo karibu nayo kwa scripts za ndani, kazi za cron, na kujaribu matoleo mapya ya model. Endpoint zote mbili zinaoana na OpenAI, kwa hiyo maktaba moja ya mteja na kubadilisha base URL vinatosha kuzitumia. Udhibiti wa gharama ni muhimu zaidi hapa kuliko injini yoyote kati ya hizo, kwa sababu GPU isiyotumika hutozwa sawa na ile inayotumika, na kudumisha gharama za mawakala na inference zikiwa zinazotabirika ni taaluma tofauti na kuchagua server.

FAQ

Je, vLLM ni ya haraka kuliko Ollama?

Kwa ombi moja kwenye GPU ileile, tofauti ni ndogo, kwa sababu zote hufanya hesabu zilezile. Kwa maombi mengi yanayoendeshwa kwa wakati mmoja, vLLM iko mbele kwa kiasi kikubwa, kwa sababu continuous batching hufanya decoding ya kila sequence inayotumika katika forward pass moja, huku usanidi chaguo-msingi wa Ollama ukiyaendesha moja baada ya jingine. Kwenye mashine inayotumia CPU pekee, swali hili halitumiki: Ollama huendesha hapo, lakini vLLM kwa vitendo haiwezi.

Je, vLLM inaweza kufanya kazi bila GPU?

Si kwa matumizi yenye maana. standard wheels hulenga NVIDIA au AMD GPUs, na sababu ya kuwepo kwa vLLM, yaani kuweka accelerator ikitumika kikamilifu kwa maombi yaliyowekwa kwenye batches, haipo kwenye CPU. CPU backend ipo kwa kazi za development. Kwa inference halisi kwenye CPU, tumia Ollama au llama.cpp moja kwa moja.

Kuna tofauti gani kati ya Ollama na llama.cpp?

llama.cpp ni inference library, na GGUF ni muundo wake wa uzito uliopunguzwa kwa quantization. Runner ya Ollama imejengwa juu yake na huongeza sehemu ambazo llama.cpp hukuachia: model registry, upakuaji wa kiotomatiki, server inayobaki ikiendesha, systemd unit, na endpoint inayooana na OpenAI. Ollama imeongeza engine yake kwa baadhi ya familia mpya za modeli, kwa hiyo sasa mifumo hiyo miwili si sawa kabisa kwa ndani.

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

Kwa precision ya 16-bit, uzito pekee unahitaji takriban 16 GB, yaani karibu 2 GB kwa kila parameter bilioni moja, na KV cache inahitaji nafasi ya ziada. Kadi ya 24 GB inatosha vizuri. Kadi ya 16 GB inahitaji checkpoint iliyofanyiwa quantization au modeli ndogo zaidi. vLLM hudai sehemu ya kumbukumbu ya kadi iliyowekwa na --gpu-memory-utilization, ambayo ni 0.92 kwa chaguo-msingi kufikia July 2026.

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

Kwa kawaida, unahitaji kubadilisha base URL, API key, na jina la modeli pekee. Ollama hutoa surface yake inayooana na OpenAI kwenye http://127.0.0.1:11434/v1 na hupuuza key, huku vLLM ikitoa huduma kwenye http://localhost:8000/v1 na kutekeleza matumizi ya key ukiweka moja. Majina ya modeli hutofautiana kwa muundo: llama3.1:8b kwa Ollama, na repository id kamili kama Qwen/Qwen2.5-1.5B-Instruct kwa vLLM.