VPS वर Ollama की llama.cpp? CPU-only निवड

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

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

नावानुसार models fetch करणारी आणि सतत देखरेखीशिवाय कार्यरत राहणारी service हवी असल्यास Ollama चालवा. VPS लहान असेल आणि नेमकी 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 प्रोग्राम आहे. ollama serve ने सुरू केलेला background daemon models लोड करतो आणि HTTP requests ची उत्तरे देतो. Command line client त्या daemon शी संवाद साधतो. या दोन्हींच्या मागे ollama.com वरील registry आहे. त्यात आधीपासून पॅक केलेले models असतात. Ollama semantic versions वापरते आणि v0.32.5 27 July 2026 रोजी release झाले. ollama pull prompt template आणि default parameters च्या संचासह GGUF fetch करते आणि Linux वर ते /usr/share/ollama/.ollama/models अंतर्गत साठवते. या फाइल्स root disk वर साठवल्या जातात आणि प्रत्येक फाइल अनेक gigabytesची असू शकते. त्यामुळे 25 GB root volume असलेल्या VPS वर तिसऱ्या download मुळे disk भरून जाण्यापूर्वी pull नंतर काय साठवले जाते आणि model directory दुसरीकडे कशी हलवायची हे जाणून घेणे उपयुक्त ठरते.

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

अक्ष 1: मॉडेल आणि quantisation नियंत्रण

Quantisation मुळे प्रत्येक weight 16 किंवा 32 bits वरून 4, 5 किंवा 8 bits पर्यंत लहान होतो. त्यामुळे 8 billion parameters असलेले मॉडेल सामान्य VPS च्या RAM मध्ये बसते. Pattern माहीत असल्यावर 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 आहे, तर सर्वात मोठा 7.95 GiB आहे. सर्वसाधारण default, Q4_K_M, 4.58 GiB आहे. 4 GiB VPS वर मॉडेल load होईल की नाही हे एकाच निवडीवर ठरते. या निर्णयातील size हा फक्त अर्धा भाग आहे. परवडणारी row वापरण्यास योग्य असेलच असे नाही. Q4, Q8 आणि fp16 मुळे answer quality वर प्रत्यक्षात काय परिणाम होतो हेच अतिरिक्त gigabytes मुळे तुम्हाला जाणवेल असा काही फायदा होतो की नाही ते सांगते.

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 ही सेटिंग अनेकांना अडचणीत आणते. उपलब्ध VRAM वरून Ollama default निवडते. GPU नसलेला box सर्वात लहान bucket मध्ये येतो: 4096 tokens. त्याला 20,000 tokens असलेला document पाठवल्यास अतिरिक्त tokens मॉडेलला दिसण्यापूर्वीच वगळले जातात. त्यामुळे मॉडेलने file अर्धवट वाचलेली असताना उत्तरावर पूर्ण खात्री असल्यासारखे चुकीचे उत्तर मिळते. Daemon वर OLLAMA_CONTEXT_LENGTH वापरून किंवा Modelfile मध्ये PARAMETER num_ctx वापरून ते वाढवा. फक्त एका job ला मोठी window आवश्यक असल्यास num_ctx server wide ऐवजी प्रत्येक request साठी सेट करता येतो. त्यामुळे daemon कडून चालवल्या जाणाऱ्या इतर सर्व कामांवर अतिरिक्त cache लागू होत नाही. llama.cpp च्या default वरही विश्वास ठेवण्यासारखे नाही. -c स्पष्टपणे सेट करा आणि तुम्ही काय सेट केले आहे ते माहीत ठेवा.

तुम्हाला सहसा दाखवले जात नाही असे memory गणित

Model file ही एकूण memory cost नसते. KV cache (key/value cache) मध्ये context मधील प्रत्येक token साठी प्रत्येक layer ची एक entry ठेवली जाते. Conversation वाढत गेल्यावर हा cache वाढत जातो.

Llama 3.1 8B साठी हे गणित पाहू. या model मध्ये 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 साठी हे 128 KiB प्रति token होते. 4096 token context साठी 512 MiB memory लागते, तर 32,768 token context साठी 4 GiB लागतात.

म्हणून 4k context असलेल्या Q4_K_M 8B model साठी weights साठी अंदाजे 4.58 GiB, cache साठी सुमारे 0.5 GiB आणि runtime साठी अतिरिक्त memory लागते. हे 4 GiB RAM मध्ये बसत नाही. 8 GiB RAM मध्ये ते चालते आणि कामासाठी काही memory शिल्लक राहते. त्याच 8 GiB मशीनवर context 32k केल्यास cache एकटाच उपलब्ध शिल्लक memory वापरतो. Model load असताना free -h वापरून हे प्रत्यक्ष पाहा. मोजमाप न केलेल्या अंदाजावर विश्वास ठेवू नका. 8B पेक्षा बऱ्याच मोठ्या model साठी sizing करत असल्यास, CPU-only VPS वरील 27B model साठी केलेले हेच गणित 8 ते 64 GB मधील प्रत्येक tier मध्ये प्रत्यक्ष किती memory उपलब्ध राहते ते दाखवते.

Ollama मुळे हा परिणाम आणखी वाढतो. OLLAMA_NUM_PARALLEL चे default मूल्य 1 असते. Model ला लागणारी memory या संख्येच्या आणि context length च्या गुणोत्तरानुसार वाढते. दोन्ही एकाच वेळी वाढवल्यास daemon अपेक्षेपेक्षा कित्येक पट अधिक RAM मागतो. हेच गणित एकाच वेळी वापरता येणाऱ्या users ची कमाल संख्या ठरवते, कारण प्रत्येक concurrent request ला KV cache मधील स्वतंत्र भाग हवा असतो. म्हणूनच एका व्यक्तीसाठी व्यवस्थित चालणारा server पाच users वर अडखळतो.

अक्ष 2: तुम्हाला चालवायचा daemon

Ollama install script systemd unit लिहिते, ollama system user तयार करते आणि service enable करते. यापैकी कोणतेही काम स्वतः लिहावे लागत नाही. 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

OLLAMA_KEEP_ALIVE CPU VPS वर इतर कोणत्याही ठिकाणापेक्षा अधिक महत्त्वाचे आहे. By default models 5 minutes memory मध्ये ठेवले जातात आणि त्यानंतर unload केले जातात. पुढील request ला उत्तर देण्यापूर्वी संपूर्ण file पुन्हा disk वरून वाचावी लागते. त्यामुळे slow storage वर 4.58 GiB reload मुळे दोन सेकंदांचे reply तीस सेकंदांचे होते. Long keep-alive मुळे latency दूर होते, पण RAM कायम व्यापली जाते. दोन्हींची खरी किंमत आहे. कमी त्रासदायक पर्याय निवडा. Model memory मध्येच resident ठेवायचा असल्यास, idle periods आणि reboots नंतरही तो टिकवण्यासाठी keep_alive सेट करणे यासाठी काही ओळी पुरेशा आहेत. त्यामुळे प्रत्येक वेळी box restart झाल्यावर model manually warm करण्याची गरज राहत नाही.

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 वापरून ते enable करा. त्यानंतर process त्याच्या संपूर्ण lifetime मध्ये model memory मध्ये ठेवतो. Idle असताना काहीही unload होत नाही. त्यामुळे अनपेक्षित reload होत नाही, पण service stop केल्याशिवाय memory परत मिळवण्याचा मार्गही राहत नाही. Units लिहिणे नवीन असल्यास, हीच पद्धत VPS वर systemd अंतर्गत स्वतःच्या services चालवण्यासाठी वापरली जाते.

Axis 3: तुमचे अॅप ज्या API शी संवाद साधेल

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

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

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 routes देखील ते उपलब्ध करून देते: readiness probe साठी /health, loaded model च्या settings साठी /props, प्रत्येक request slot मध्ये काय सुरू आहे हे पाहण्यासाठी /slots आणि Prometheus format मधील metrics साठी /metrics. या सेवेचे monitoring करण्याची योजना असल्यास, हा फरकच बहुधा निर्णायक ठरेल.

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

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 column हा prompt processing speed दाखवतो आणि tg column हा token generation speed दाखवतो. दोन्ही मोजमाप tokens per second मध्ये आहेत. Shared vCPU plan वर Q4_K_M वापरणारे 8B model tg साठी साधारणपणे कमी single digits पर्यंत पोहोचते. त्रासदायक भाग म्हणजे prompt processing. पहिला output token दिसण्यापूर्वी संपूर्ण prompt process केला जातो. त्यामुळे लांब system prompt मुळे प्रत्येक request साठी प्रतीक्षा वाढते. Reply length हा खर्चाचा तुमच्या नियंत्रणात असलेला भाग आहे. तीन tokens प्रति सेकंद वेगाने 600 tokens चे लांबलचक उत्तर देणारे model box तीन मिनिटे व्यस्त ठेवते. त्यामुळे num_predict ने output मर्यादित करणे हा एखादे बोलके उत्तर timeout मध्ये बदलू न देण्याचा सर्वात स्वस्त उपाय आहे.

CPU वर वापरण्यायोग्य: classification, extraction, short summaries किंवा routing करणारे 1B ते 4B model. Replies काही सेकंदांत येतात आणि memory सामान्य plan मध्ये बसते. त्या size range ऐवजी त्याच size मधील प्रत्यक्ष उदाहरणासाठी VPS वर Nemotron 3.5 Lightning pull करून त्याचे मोजमाप करणे exact tag, प्रत्यक्ष लागणारी RAM आणि GPU शिवाय मिळणारा वेग दाखवते. CPU वर वापरण्यायोग्य नाही: वाचनाच्या वेगाने interactive chat, coding assistants, long-document work किंवा अनेक calls अनुक्रमे करणारा agent loop असलेले कोणतेही काम. बारा calls करणाऱ्या loop ला प्रत्येक call साठी चार सेकंद लागल्यास काहीही output देण्यापूर्वी एक मिनिट जाते. Coding assistant हाच उद्देश असल्यास, स्वतः host केलेल्या model कडे agent निर्देशित करणे यात लहान local model कोणती कामे प्रत्यक्षात चांगली करतो आणि कोणती कामे hosted API वरच ठेवावी लागतात हे स्पष्ट केले आहे.

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

llama.cpp स्थापित करा आणि build आवृत्ती निश्चित करा

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

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

विशिष्ट build निश्चित करण्यासाठी 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 लागते. त्यामुळे मोठ्या मशीनवर build करा आणि छोटी मशीन कमी पडल्यास binaries तेथे copy करा.

Ollama ची ठरावीक आवृत्ती pin करून install करा

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

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

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

Manual पद्धतीत 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 लोड करण्यापूर्वी आकार तपासते. त्यामुळे ते लगेच अपयशी होते आणि कारण सांगते. एक quantisation row खाली जा, context length कमी करा किंवा लहान मॉडेल निवडा.

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

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

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

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

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

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

विरामानंतरचे पहिले उत्तर खूप धीमे असते. 5 minute idle unload झाले आहे आणि मॉडेल पुन्हा disk वरून वाचले जात आहे. Request च्या अगदी आधी चालवलेले ollama ps काहीही 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 प्रत्यक्ष काम करते. Ollama च्या README मध्ये llama.cpp ला inference backend म्हणून नमूद केले आहे (2 August 2026 रोजी तपासलेले). त्यावर Ollama model registry, chat messages चे prompt मध्ये रूपांतर करणारे prompt template, default sampling parameters चा संच, idle unloading असलेला daemon आणि HTTP API जोडते. समान settings वापरून tokens per second ची तुलना केली, तर तुम्ही त्याच engine ची स्वतःशीच तुलना करत असता. प्रत्यक्षात तुम्ही management layer पैकी एक निवडत असता.

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

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

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

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

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

File size, KV cache आणि runtime यांसाठी RAM चे नियोजन करा. 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 नुसारही वाढते.