VPS वर Ollama की llama.cpp: CPU साठी योग्य पर्याय

Ollama विरुद्ध llama.cpp: तुम्हाला कोणता स्तर चालवायचा आहे?

Ollama आणि llama.cpp हे या प्रश्नातून सूचित होते त्या अर्थाने प्रतिस्पर्धी नाहीत. llama.cpp हे inference engine आहे: ते model file लोड करते आणि prompt चे tokens मध्ये रूपांतर करते. Ollama हे model manager, background daemon आणि या engine वर चालणारे HTTP API आहे. Ollama च्या README मध्ये अजूनही llama.cpp हे त्याचे inference backend म्हणून नमूद केले आहे (2 August 2026 रोजी तपासले). त्यामुळे खरा प्रश्न कोणते अधिक वेगवान आहे हा नाही. तुमच्या VPS वर तुम्हाला कोणता स्तर चालवायचा आहे हा खरा प्रश्न आहे.

जेव्हा तुम्हाला नावाने models आणणारी आणि सतत देखरेखीशिवाय कार्यरत राहणारी service हवी असेल, तेव्हा Ollama चालवा. जेव्हा server लहान असेल आणि तुम्हाला नेमकी model file, नेमका context size आणि नेमकी thread count निवडायची असेल, तेव्हा llama.cpp थेट चालवा. कारण लहान VPS वर या प्रत्येक setting साठी तुमच्याकडे उपलब्ध नसलेली memory लागते.

प्रत्येक प्रकल्प प्रत्यक्षात काय आहे

llama.cpp हे ggml लायब्ररीवर आधारित transformer inference चे C आणि C++ अंमलबजावणी आहे. ते GGUF फाइल्स वाचते. GGUF (GGML universal file format) हा एकाच फाइलमधील container आहे. त्यात model चालवण्यासाठी engine ला आवश्यक असलेले weights, tokeniser आणि metadata असतात. प्रकल्प वेगवेगळ्या कामांसाठी स्वतंत्र binaries उपलब्ध करून देतो. llama-server हा HTTP server आहे, llama-cli हा interactive prompt आहे आणि llama-bench throughput मोजतो. Releases semantic version ऐवजी build number नुसार tag केले जातात. सध्याचा tag b10224 आहे. तो 2 August 2026 रोजी प्रकाशित झाला आणि बहुतेक कामकाजाच्या दिवशी नवीन tag प्रकाशित होतो.

Ollama हा Go program आहे. ollama serve ने सुरू केलेला background daemon models लोड करतो आणि HTTP requests ची उत्तरे देतो. Command line client त्या daemon शी संवाद साधतो. या दोन्हींच्या मागे ollama.com वरील registry आहे. त्यात आधीपासून पॅकेज केलेले models असतात. Ollama semantic versions वापरते आणि v0.32.5 27 July 2026 रोजी प्रसिद्ध झाले. ollama pull prompt template आणि default parameters च्या संचासह GGUF मिळवतो आणि Linux वर तो /usr/share/ollama/.ollama/models अंतर्गत साठवतो.

हे packaging हाच मुख्य फरक आहे. Ollama तुमच्यासाठी quantisation, template आणि context length ठरवते आणि लक्षात ठेवण्यासाठी एकच नाव देते. llama.cpp काहीही ठरवत नाही आणि flags देते.

अक्ष 1: मॉडेल आणि क्वांटायझेशन नियंत्रण

क्वांटायझेशनमुळे प्रत्येक weight 16 किंवा 32 bits वरून 4, 5 किंवा 8 bits पर्यंत कमी होतो. त्यामुळे 8 billion parameters असलेले मॉडेल सामान्य VPS च्या RAM मध्ये बसते. पॅटर्न माहीत असल्यास GGUF naming समजणे सोपे आहे: Q4_K_M म्हणजे 4-bit K-quant, medium size. मोठी संख्या अधिक precision राखते आणि अधिक memory वापरते.

[
  {
    "label": "Q2_K",
    "file_size_gib": 2.96
  },
  {
    "label": "Q3_K_M",
    "file_size_gib": 3.74
  },
  {
    "label": "Q4_K_M",
    "file_size_gib": 4.58
  },
  {
    "label": "Q5_K_M",
    "file_size_gib": 5.34
  },
  {
    "label": "Q6_K",
    "file_size_gib": 6.14
  },
  {
    "label": "Q8_0",
    "file_size_gib": 7.95
  }
]

हे Hugging Face वरील bartowski/Meta-Llama-3.1-8B-Instruct-GGUF repository मधील प्रकाशित file sizes आहेत. ही माहिती 2 August 2026 रोजी घेतली असून bytes मधून GiB मध्ये रूपांतरित केली आहे. एका मॉडेलच्या 6 builds आहेत. त्यातील सर्वात लहान build 2.96 GiB आहे, तर सर्वात मोठा build 7.95 GiB आहे. सामान्य default Q4_K_M चा आकार 4.58 GiB आहे. 4 GiB VPS वर मॉडेल load होईल की नाही, हे एकाच निवडीवर ठरते.

llama.cpp मध्ये तुम्ही file चे नाव देता. त्यामुळे ही row तुम्हालाच निवडावी लागते.

llama-server -m ~/models/Meta-Llama-3.1-8B-Instruct-Q4_K_M.gguf \
  -c 4096 -t 4 --host 127.0.0.1 --port 8080

-c ही tokens मधील context size आहे, -t ही thread count आहे आणि -ngl मुळे GPU वर हलवायच्या layers ची संख्या ठरते. CPU-only box साठी ही संख्या 0 असते. तुमच्यासाठी काहीही आपोआप गृहीत धरले जात नाही.

Ollama मध्ये तुम्ही pull केलेल्या tag सोबत quantisation येते आणि ollama ls मुळे disk वर प्रत्यक्षात काय आहे ते दिसते. Registry मध्ये तुम्हाला हवा असलेला build उपलब्ध नसल्यास GGUF स्वतः import करा. Modelfile लिहा:

FROM ./Meta-Llama-3.1-8B-Instruct-Q4_K_M.gguf
PARAMETER num_ctx 4096

त्यानंतर ते build करून परिणाम तपासा:

ollama create llama31-q4 -f ./Modelfile
ollama ls

Context length हे वापरकर्त्यांना अडचणीत आणणारे setting आहे. Ollama उपलब्ध VRAM वरून default निवडते. GPU नसलेला box सर्वात लहान bucket मध्ये जातो: 4096 tokens. त्याला 20,000 tokens असलेले document दिल्यास, मॉडेलने ते पाहण्यापूर्वीच अतिरिक्त tokens काढून टाकले जातात. त्यामुळे मॉडेलने file अर्धीच वाचलेली असताना उत्तर आत्मविश्वासाने चुकीचे येते. Daemon वर OLLAMA_CONTEXT_LENGTH वापरून किंवा Modelfile मध्ये PARAMETER num_ctx वापरून ही मर्यादा वाढवा. llama.cpp मध्येही विश्वास ठेवण्यासारखा default नाही. -c स्पष्टपणे set करा आणि कोणती value set केली आहे ते माहीत ठेवा.

तुम्हाला कोणीही सांगत नाही ते मेमरीचे गणित

मॉडेल फाइल हा संपूर्ण खर्च नसतो. KV cache (key/value cache) मध्ये context मधील प्रत्येक token साठी प्रत्येक layer ची एक entry साठवली जाते. संभाषण वाढत गेले की हा cache वाढत जातो.

Llama 3.1 8B साठी हे गणित मांडू. या मॉडेलमध्ये 32 layers, 8 key/value heads आणि 128 head dimension आहे. f16 मध्ये प्रत्येक token साठी key आणि value प्रत्येकी 2 bytes साठवले जातात. त्यामुळे 2 x 8 x 128 x 2 = 4096 bytes प्रति layer होतात. 32 layers साठी हे प्रति token 128 KiB होते. त्यामुळे 4096 token च्या context साठी 512 MiB लागतात, तर 32,768 token च्या context साठी 4 GiB लागतात.

म्हणून 4k context असलेल्या Q4_K_M 8B मॉडेलला weights साठी सुमारे 4.58 GiB, cache साठी सुमारे 0.5 GiB आणि runtime साठी अतिरिक्त मेमरी लागते. ते 4 GiB RAM मध्ये बसत नाही. काम करण्यासाठी पुरेशी अतिरिक्त मेमरी ठेवून ते 8 GiB मध्ये बसते. त्याच 8 GiB मशीनवर context 32k पर्यंत वाढवल्यास cache एकटाच उपलब्ध अतिरिक्त मेमरी संपवतो. मॉडेल लोड असताना free -h वापरून ही स्थिती प्रत्यक्ष पाहा. मोजमाप न केलेल्या अंदाजावर विश्वास ठेवू नका.

Ollama मुळे हा परिणाम आणखी वाढतो. OLLAMA_NUM_PARALLEL चे पूर्वनिर्धारित मूल्य 1 आहे. मॉडेलला लागणारी मेमरी या संख्येच्या आणि context length च्या गुणाकारानुसार वाढते. दोन्ही एकाच वेळी वाढवल्यास daemon तुमच्या अपेक्षेपेक्षा अनेक पटींनी अधिक RAM मागतो.

अक्ष 2: तुम्हाला चालवावा लागणारा daemon

Ollama install script एक systemd unit लिहिते, ollama system user तयार करते आणि service सक्षम करते. यासाठी तुम्हाला lifecycle management स्वतः लिहावे लागत नाही. Configuration systemd द्वारे केली जाते:

sudo systemctl edit ollama

[Service]
Environment="OLLAMA_CONTEXT_LENGTH=8192"
Environment="OLLAMA_KEEP_ALIVE=30m"

sudo systemctl daemon-reload
sudo systemctl restart ollama
journalctl -e -u ollama

CPU VPS वर OLLAMA_KEEP_ALIVE चे महत्त्व इतर कोणत्याही ठिकाणापेक्षा जास्त आहे. Models default नुसार 5 मिनिटे memory मध्ये ठेवले जातात आणि त्यानंतर unload केले जातात. पुढील request ला उत्तर देण्यापूर्वी संपूर्ण file पुन्हा disk वरून वाचावी लागते. त्यामुळे धीम्या storage वर 4.58 GiB reload मुळे दोन सेकंदांचे उत्तर तीस सेकंदांचे होते. मोठा keep-alive latency कमी करतो आणि RAM कायमस्वरूपी व्यापून ठेवतो. दोन्ही वास्तविक खर्च आहेत. तुम्हाला कमी त्रासदायक पर्याय निवडा.

llama.cpp कोणताही daemon देत नाही. त्यामुळे तुम्हाला unit स्वतः /etc/systemd/system/llama-server.service म्हणून लिहावी लागते:

[Unit]
Description=llama.cpp server
After=network-online.target

[Service]
ExecStart=/usr/local/bin/llama-server -m /srv/models/model-Q4_K_M.gguf -c 4096 -t 4 --host 127.0.0.1 --port 8080
Restart=always
RestartSec=3
User=llama

[Install]
WantedBy=multi-user.target

sudo systemctl enable --now llama-server वापरून ते सक्षम करा. त्यानंतर process त्याच्या संपूर्ण lifetime मध्ये model memory मध्ये ठेवतो. idle असताना काहीही unload होत नाही. त्यामुळे अनपेक्षित reload होत नाही, पण service थांबवल्याशिवाय memory परत मिळवण्याचा कोणताही मार्ग राहत नाही. Units लिहिणे नवीन असल्यास, हीच पद्धत VPS वर systemd अंतर्गत स्वतःच्या services चालवण्यासाठी वापरली जाते.

अक्ष 3: तुमचे app ज्या API शी संवाद साधेल

हा अक्ष आता बराच संकुचित झाला आहे. दोन्ही project आता OpenAI chat format वापरतात. त्यामुळे base URL बदलल्यानंतर बहुतेक client library पैकी कोणतीही एकासोबत कार्य करते.

Ollama 127.0.0.1:11434 वर ऐकते. त्याचा OpenAI-सुसंगत route http://localhost:11434/v1/chat/completions आहे. त्यासोबत ते native API /api/chat वर उपलब्ध ठेवते. Anthropic-सुसंगत route देखील documented आहे.

curl -X POST http://localhost:11434/v1/chat/completions \
  -H "Content-Type: application/json" \
  -d '{"model": "llama31-q4", "messages": [{"role": "user", "content": "Say this is a test"}]}'

llama-server 127.0.0.1:8080 वर ऐकते आणि /v1/chat/completions, /v1/completions आणि /v1/embeddings उपलब्ध करते. यासोबत त्याचे स्वतःचे /completion endpoint आणि अंगभूत web UI आहे. Ollama मध्ये नसलेले operational route देखील ते उपलब्ध करते: readiness probe साठी /health, loaded model च्या settings साठी /props, प्रत्येक request slot काय करत आहे हे पाहण्यासाठी /slots, आणि Prometheus format मधील metrics साठी /metrics. तुम्ही या service चे monitoring करण्याचा विचार करत असल्यास, निर्णय घेण्यासाठी हा फरक महत्त्वाचा ठरू शकतो.

दोन्ही server तुमच्यासाठी authentication सुरू करत नाहीत. योग्य कारणांसाठी दोन्हींचा default loopback असतो. त्यांच्यापर्यंत SSH tunnel द्वारे किंवा reverse proxy मागून पोहोचा. 11434 किंवा 8080 internet साठी कधीही खुले करू नका.

CPU-only VPS प्रत्यक्षात काय करू शकतो

CPU-only VPS लहान models संथपणे चालवतो. हा प्रामाणिक सारांश आहे. या मर्यादेची नेमकी सीमा समजून घेणे अधिक उपयुक्त आहे. त्यावर आधारित रचना करण्यापूर्वी मोजमाप करा:

llama-bench -m ~/models/Meta-Llama-3.1-8B-Instruct-Q4_K_M.gguf -p 512 -n 128

pp हा स्तंभ prompt processing speed दर्शवतो आणि tg हा स्तंभ token generation speed दर्शवतो. दोन्ही मोजमाप tokens per second मध्ये आहेत. Shared vCPU plan वर Q4_K_M मधील 8B model साठी tg चे मोजमाप सहसा कमी एक-अंकी संख्येत असते. Prompt processing हा त्रासदायक भाग आहे. पहिला output token दिसण्यापूर्वी संपूर्ण prompt process केला जातो. त्यामुळे मोठा system prompt प्रत्येक request साठी प्रतीक्षा वाढवतो.

CPU वर वापरण्यायोग्य: classification, extraction, short summaries किंवा routing करणारे 1B ते 4B model. Replies काही सेकंदांत मिळतात आणि memory सामान्य plan मध्ये बसते. CPU वर वापरण्यायोग्य नाही: वाचनाच्या वेगाने चालणारे interactive chat, coding assistants, long-document work किंवा agent loop मधून अनेक calls क्रमाने करणारे कोणतेही काम. प्रत्येक call ला चार सेकंद लागणारा loop बारा calls केल्यावर कोणतेही output तयार होण्यापूर्वी एक मिनिट घेतो.

मोजमाप योग्य नसतील तर दोन पर्याय आहेत. समस्या concurrency ची असल्यास, म्हणजे अनेक users एकाच वेळी एका model वर requests पाठवत असल्यास, engine ची निवड बदलते. concurrent serving साठी Ollama आणि vLLM यांची तुलना हा विषय स्पष्ट करते. समस्या raw speed ची असल्यास, उत्तर आहे GPU जोडलेला VPS, जिथे -ngl ला अर्थ प्राप्त होतो. यापूर्वी hardware साठी baseline मिळवा. कारण CPU प्रमाणेच disk आणि memory bandwidth देखील load time वर परिणाम करतात. पुनरावृत्ती करता येणारा VPS benchmark करण्यासाठी एक तास देणे उपयुक्त आहे.

build ला pin केलेले llama.cpp install करा

दोन्ही प्रकल्पांमध्ये साप्ताहिक बदल होतात. त्यामुळे तुम्ही deploy केलेली आवृत्ती नोंदवा. Upstream one-liner सध्याचा build install करतो:

curl -LsSf https://llama.app/install.sh | sh
llama serve -hf ggml-org/Qwen3.5-0.8B-GGUF

विशिष्ट build ला pin करण्यासाठी releases page वरील prebuilt tarball वापरा. 2 August 2026 रोजी b10224 हा सध्याचा tag आहे:

curl -LO https://github.com/ggml-org/llama.cpp/releases/download/b10224/llama-b10224-bin-ubuntu-x64.tar.gz
tar xf llama-b10224-bin-ubuntu-x64.tar.gz
find . -type f -name 'llama-server'

किंवा तोच tag source मधून build करा:

sudo apt update && sudo apt install -y build-essential cmake git libssl-dev
git clone https://github.com/ggml-org/llama.cpp
cd llama.cpp
git checkout b10224
cmake -B build
cmake --build build --config Release -j $(nproc)

HTTPS features साठी libssl-dev ही दस्तऐवजीकृत dependency आहे. Compile पूर्ण होण्यासाठी काही मिनिटे लागतात. तसेच, सर्वात लहान plans मध्ये उपलब्ध RAM पेक्षा अधिक RAM लागते. त्यामुळे लहान server वर RAM अपुरी पडल्यास मोठ्या server वर build करा आणि binaries copy करा.

आवृत्ती निश्चित करून Ollama स्थापित करा

curl -fsSL https://ollama.com/install.sh | OLLAMA_VERSION=0.32.5 sh
ollama -v

स्क्रिप्ट OLLAMA_VERSION वाचते. त्यामुळे आज सकाळी उपलब्ध झालेली कोणतीही आवृत्ती घेण्याऐवजी, विश्वसनीय आवृत्ती वापरता येते. v0.32.5 ही आवृत्ती 27 July 2026 रोजी प्रकाशित झाली. स्क्रिप्ट shell मध्ये pipe करायची नसेल, तर मॅन्युअल पद्धतही उपलब्ध आहे:

sudo rm -rf /usr/lib/ollama
curl -fsSL https://ollama.com/download/ollama-linux-amd64.tar.zst | sudo tar x -C /usr
ollama -v

मॅन्युअल पद्धतीने systemd unit किंवा service user तयार होत नाही. त्यामुळे ते स्वतः तयार करावे लागतात. VPS वर Ollama ची संपूर्ण मार्गदर्शिका या service setup प्रक्रियेचे टप्प्याटप्प्याने वर्णन करते.

अपयशाच्या स्थिती आणि दिसणारे संदेश

Ollama मॉडेल लोड करण्यास नकार देते. ollama run या स्वरूपाची ओळ परत करते:

Error: model requires more system memory (5.6 GiB) than is available (3.2 GiB)

लोड करण्यापूर्वी Ollama आकार तपासते. त्यामुळे ते लगेच अपयशी होते आणि कारण सांगते. क्वांटायझेशनच्या यादीतील पुढील रांगेतील पर्याय निवडा, context length कमी करा किंवा लहान मॉडेल निवडा.

llama.cpp अपयशी होत नाही, ते अत्यंत धीमे होते. llama.cpp डीफॉल्टनुसार GGUF ला memory-map करते. त्यामुळे RAM पेक्षा मोठी फाइल तरीही सुरू होते. त्यानंतर kernel प्रत्येक token साठी डिस्कमधून weights वारंवार वाचतो आणि बाहेर पाठवतो. डिस्कचा वापर 100 percent वर स्थिर राहतो आणि generation ला प्रत्येक token साठी काही सेकंद लागतात. प्रत्यक्ष memory allocation सक्तीने करण्यासाठी --no-mmap द्या. त्यामुळे कार्यक्षमता कमी होण्याऐवजी प्रक्रिया त्वरित अपयशी होईल. kernel हस्तक्षेप केल्यावर dmesg कारण दाखवते:

Out of memory: Killed process 1234 (llama-server)

मॉडेल फाइल अजिबात लोड होत नाही. तुमच्या engine पेक्षा नवीन model family साठी तयार केलेला GGUF engine ला माहीत नसलेल्या architecture चे नाव देणारी त्रुटी दाखवतो:

error loading model architecture: unknown model architecture: 'qwen3next'

यावर उपाय म्हणजे engine upgrade करणे; वेगळी फाइल वापरणे नव्हे. Pinning ची ही किंमत आहे. त्यामुळे build number लिहून ठेवणे महत्त्वाचे आहे. तुम्ही कोणत्या आवृत्तीवरून upgrade करत आहात हे माहीत असणे आवश्यक आहे.

API स्थानिक पातळीवर उत्तर देते, पण तुमच्या app मधून उत्तर देत नाही. Ollama 127.0.0.1:11434 वर bind होते. त्यामुळे दुसऱ्या host कडून connection refused मिळते. port firewall किंवा private network मागे असेल तेव्हाच systemctl edit ollama द्वारे OLLAMA_HOST=0.0.0.0:11434 सेट करा, कारण API च्या समोर authentication नसते.

विरामानंतरचे पहिले उत्तर खूप धीमे असते. 5 minute idle unload झाले आहे आणि मॉडेल पुन्हा डिस्कवरून वाचले जात आहे. विनंतीच्या अगोदर ollama ps run केल्यास काहीही loaded नसल्याचे दिसते आणि याची पुष्टी होते. OLLAMA_KEEP_ALIVE वाढवा.

मग तुम्ही कोणते चालवावे?

मॉडेल्सचे व्यवस्थापन आपोआप व्हावे आणि कोणतेही अतिरिक्त काम न करता OpenAI-सदृश endpoint मिळावा असे वाटत असल्यास Ollama चालवा. पहिल्या deployment साठी आणि मॉडेलची निवड वारंवार बदलत राहणार असल्यास हा योग्य default आहे.

मेमरी इतकी कमी असेल की quantisation row स्वतः निवडणे आवश्यक असेल, monitoring साठी /health, /slots आणि /metrics हवे असतील किंवा Ollama उपलब्ध करून देत नसलेला flag आवश्यक असेल, तर llama.cpp थेट चालवा. मॉडेल कसेबसे VPS वर बसत असेल, तर हा योग्य पर्याय आहे. कारण मॉडेल बसवून घेण्यासाठी आवश्यक settings Ollama तुमच्यावतीने निवडतो.

दोन्ही चालवणे सामान्य आहे. प्रयोगांसाठी Ollama वापरा आणि production मध्ये ठेवलेल्या, पुन्हा बदलू नयेत असे वाटणाऱ्या एका मॉडेलसाठी llama.cpp वापरा.

FAQ

Ollama हे llama.cpp भोवतीचे केवळ wrapper आहे का?

जवळपास, परंतु wrapper प्रत्यक्ष काम करते. 2 August 2026 रोजी तपासलेल्या Ollama च्या README मध्ये llama.cpp ला त्याचे inference backend म्हणून नमूद केले आहे. त्यावर Ollama model registry, chat messages चे prompt मध्ये रूपांतर करणारे prompt template, sampling parameters चा default संच, idle unloading असलेला daemon आणि HTTP API जोडते. समान settings वर प्रति सेकंद tokens ची तुलना केल्यास, तुम्ही त्याच engine ची स्वतःशी तुलना करत असता. प्रत्यक्षात तुम्ही management layer पैकी एक पर्याय निवडत असता.

केवळ CPU असलेल्या VPS वर कोणते अधिक जलद आहे?

दोन्ही समान engine वापरतात. त्यामुळे समान model file, quantisation, context size आणि thread count असल्यास त्यांचा वेग जवळपास समान असतो. लोकांनी नोंदवलेले फरक सामान्यतः engine मुळे नसतात. ते वेगवेगळ्या default settings मुळे असतात, विशेषतः context length आणि thread count मुळे. तुमच्या स्वतःच्या box वर प्रकाशित आकडेवारीवर विश्वास ठेवण्यापूर्वी llama-bench -m <file> -p 512 -n 128 वापरून मोजा आणि tg column ची तुलना करा.

मी माझी स्वतःची GGUF file Ollama सोबत वापरू शकतो का?

होय. ती file server वर ठेवा. पहिल्या ओळीत FROM ./your-model.gguf असलेली Modelfile लिहा. आवश्यकतेनुसार num_ctx सारख्या PARAMETER ओळी जोडा. त्यानंतर ollama create your-name -f ./Modelfile चालवा. ollama ls registry मधून pull केलेल्या इतर files च्या शेजारी ती file दाखवेल. Registry मध्ये उपलब्ध नसलेली quantisation वापरण्याची ही पद्धत आहे.

8B model साठी मला किती RAM आवश्यक आहे?

File size, KV cache आणि runtime यांचा समावेश करून अंदाजपत्रक तयार करा. Llama 3.1 8B ची Q4_K_M build disk वर सुमारे 4.58 GiB जागा घेते. 4096 token context साठी अंदाजे 512 MiB cache अतिरिक्त लागतो. त्यामुळे 8 GiB RAM पुरेशी आहे, परंतु 4 GiB पुरेशी नाही. Cache चे प्रमाण context नुसार वाढते. त्याच model साठी 32,768 token context वापरल्यास केवळ cache साठी सुमारे 4 GiB आवश्यक असतात. Ollama वापरताना ही आवश्यकता OLLAMA_NUM_PARALLEL नुसारही वाढते.