VPS पर Ollama बनाम llama.cpp: क्या चुनें?

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 पर किस लेयर को संचालित करना चाहते हैं, न कि यह कि कौन सा तेज़ है।

Ollama को तब चलाएँ जब आप एक ऐसी service चाहते हैं जो नाम से models को fetch करे और बिना किसी अतिरिक्त ध्यान के काम करती रहे। llama.cpp को सीधे तब चलाएँ जब VPS छोटा हो और आपको सटीक model file, सटीक context size और सटीक thread count चुनने की आवश्यकता हो, क्योंकि एक छोटे VPS पर इन सेटिंग्स में से प्रत्येक के लिए उतनी memory खर्च होती है जो आपके पास उपलब्ध नहीं है।

प्रत्येक प्रोजेक्ट वास्तव में क्या है

llama.cpp, ggml लाइब्रेरी पर आधारित transformer inference का एक C और C++ कार्यान्वयन है। यह GGUF फाइलों को पढ़ता है। GGUF (GGML universal file format) एक सिंगल-फाइल कंटेनर है जिसमें वे weights, tokeniser और metadata होते हैं जिनकी मॉडल को चलाने के लिए इंजन को आवश्यकता होती है। यह प्रोजेक्ट अलग-अलग कार्यों के लिए अलग-अलग बाइनरी फाइलें प्रदान करता है। llama-server एक HTTP सर्वर है, llama-cli एक इंटरैक्टिव प्रॉम्प्ट है, और llama-bench थ्रूपुट मापता है। इसके releases को सिमेंटिक वर्जन के बजाय बिल्ड नंबर द्वारा टैग किया जाता है। वर्तमान टैग b10224 है, जिसे 2 अगस्त 2026 को प्रकाशित किया गया था, और लगभग हर कार्य दिवस पर एक नया टैग जारी किया जाता है।

Ollama एक Go प्रोग्राम है। ollama serve के साथ शुरू होने वाला एक बैकग्राउंड डेमन, मॉडल लोड करता है और HTTP अनुरोधों का उत्तर देता है, और एक कमांड लाइन क्लाइंट उस डेमन से बात करता है। इन दोनों के पीछे ollama.com पर एक रजिस्ट्री है जो पहले से पैक किए गए मॉडल रखती है। Ollama सिमेंटिक वर्जन का उपयोग करता है, और v0.32.5 को 27 जुलाई 2026 को जारी किया गया था। ollama pull एक GGUF को प्रॉम्प्ट टेम्पलेट और डिफ़ॉल्ट पैरामीटर्स के सेट के साथ लाता है, और फिर इसे Linux पर /usr/share/ollama/.ollama/models के अंतर्गत स्टोर करता है।

यह पैकेजिंग ही मुख्य अंतर है। Ollama आपके लिए क्वांटाइजेशन, टेम्पलेट और कॉन्टेक्स्ट लेंथ तय करता है, और आपको याद रखने के लिए एक नाम देता है। llama.cpp कुछ भी तय नहीं करता है और आपको फ्लैग्स (flags) देता है।

Axis 1: मॉडल और क्वांटाइजेशन नियंत्रण

क्वांटाइजेशन प्रत्येक वेट (weight) को 16 या 32 बिट्स से घटाकर 4, 5 या 8 बिट्स में बदल देता है। यही वह प्रक्रिया है जिससे 8 बिलियन पैरामीटर वाला मॉडल एक सामान्य VPS की RAM में समा जाता है। GGUF नामकरण का पैटर्न समझने के बाद इसे पढ़ना आसान है: Q4_K_M का अर्थ है 4-बिट K-quant, मध्यम आकार। उच्च संख्या अधिक प्रिसिजन (precision) बनाए रखती है और अधिक मेमोरी लेती है।

[
  {
    "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 रिपॉजिटरी में प्रकाशित फाइल साइज हैं, जिन्हें 2 अगस्त 2026 को पढ़ा गया और बाइट्स से GiB में परिवर्तित किया गया। एक मॉडल के 6 बिल्ड्स उपलब्ध हैं, जिनमें सबसे छोटा 2.96 GiB का है, जबकि सबसे बड़ा 7.95 GiB का है। सामान्य डिफॉल्ट, Q4_K_M, 4.58 GiB का है। 4 GiB वाले VPS पर यही एक चुनाव तय करता है कि मॉडल लोड होगा या नहीं।

llama.cpp के साथ आप फाइल का नाम खुद चुनते हैं, इसलिए आप वह पंक्ति स्वयं चुनते हैं।

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 टोकन में कॉन्टेक्स्ट साइज है, -t थ्रेड काउंट है, और -ngl यह सेट करता है कि कितनी लेयर्स GPU पर भेजी जाएंगी (CPU-ओनली बॉक्स पर यह 0 होता है)। आपके लिए कुछ भी अनुमानित नहीं होता।

Ollama के साथ क्वांटाइजेशन उस टैग के साथ आता है जिसे आप पुल (pull) करते हैं, और ollama ls दिखाता है कि डिस्क पर वास्तव में आपके पास क्या है। जब रजिस्ट्री में आपकी मनचाही बिल्ड न हो, तो खुद एक GGUF इम्पोर्ट करें। एक Modelfile लिखें:

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

फिर इसे बिल्ड करें और परिणाम की जाँच करें:

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

कॉन्टेक्स्ट लेंथ वह सेटिंग है जहाँ लोग गलती करते हैं। Ollama उपलब्ध VRAM के आधार पर अपना डिफॉल्ट चुनता है, और बिना GPU वाले बॉक्स सबसे छोटे बकेट में आ जाते हैं: 4096 टोकन। यदि आप इसे 20,000 टोकन का डॉक्यूमेंट भेजते हैं, तो अतिरिक्त टोकन मॉडल तक पहुँचने से पहले ही हटा दिए जाते हैं, इसलिए मॉडल उस फाइल के बारे में गलत उत्तर देता है जिसे उसने आधा ही पढ़ा है। इसे डेमन (daemon) पर OLLAMA_CONTEXT_LENGTH के साथ, या Modelfile में PARAMETER num_ctx के साथ बढ़ाएं। llama.cpp का भी कोई ऐसा डिफॉल्ट नहीं है जिस पर भरोसा किया जा सके। -c को स्पष्ट रूप से सेट करें और जानें कि आपने क्या सेट किया है।

मेमोरी की वह गणना जो कोई नहीं दिखाता

मॉडल फाइल ही एकमात्र लागत नहीं है। KV cache (key/value cache) संदर्भ (context) के प्रति टोकन, प्रति लेयर एक प्रविष्टि रखता है, और जैसे-जैसे बातचीत बढ़ती है, यह भी बढ़ता जाता है।

इसे Llama 3.1 8B के लिए समझें। मॉडल में 32 लेयर्स, 8 key/value हेड्स और 128 का हेड डाइमेंशन है। प्रत्येक टोकन f16 में 2 बाइट्स के साथ एक key और एक value दोनों को स्टोर करता है, इसलिए प्रति लेयर 2 x 8 x 128 x 2 = 4096 बाइट्स। 32 लेयर्स में यह प्रति टोकन 128 KiB होता है। इसलिए 4096 टोकन संदर्भ की लागत 512 MiB है, और 32,768 टोकन संदर्भ की लागत 4 GiB है।

अतः 4k संदर्भ पर एक Q4_K_M 8B मॉडल को वेट्स (weights) के लिए लगभग 4.58 GiB, प्लस लगभग 0.5 GiB कैश, और रनटाइम की आवश्यकता होती है। यह 4 GiB RAM में फिट नहीं होता है। यह काम करने के लिए पर्याप्त जगह के साथ 8 GiB में फिट हो जाता है। उसी 8 GiB बॉक्स पर संदर्भ को 32k तक बढ़ाएं और केवल कैश ही पूरी अतिरिक्त क्षमता को खत्म कर देगा। जब मॉडल लोड हो रहा हो तो free -h के साथ इसे लाइव देखें, और किसी ऐसे अनुमान पर भरोसा न करें जिसे आपने स्वयं मापा न हो।

Ollama इसे कई गुना बढ़ा देता है। OLLAMA_NUM_PARALLEL डिफ़ॉल्ट रूप से 1 पर सेट होता है, और मॉडल को जितनी मेमोरी चाहिए वह उस संख्या और संदर्भ लंबाई के गुणनफल के साथ बढ़ती है। दोनों को एक साथ बढ़ाने पर daemon चुपचाप आपसे उस RAM से कई गुना अधिक की मांग करता है जिसकी आपने अपेक्षा की थी।

Axis 2: वह daemon जिसे आपको संचालित करना है

Ollama install script एक systemd unit लिखती है, एक ollama system user बनाती है और service को enable करती है। आपको इसे खुद लिखे बिना 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

OLLAMA_KEEP_ALIVE का महत्व CPU VPS पर कहीं और की तुलना में अधिक है। Models डिफ़ॉल्ट रूप से 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 के साथ enable करें। इसके बाद process अपने पूरे lifetime के दौरान model को hold करके रखती है। idle रहने पर कुछ भी unload नहीं होता है, जिसका अर्थ है कि कोई reload surprise नहीं मिलता और service को stop किए बिना memory को वापस पाने का कोई तरीका नहीं है। यदि unit लिखना आपके लिए नया है, तो यह VPS पर systemd के तहत अपनी खुद की services चलाने जैसा ही pattern है।

Axis 3: वह API जिससे आपका app बात करेगा

यह axis काफी सीमित हो गया है। दोनों projects अब OpenAI chat format का उपयोग करते हैं, इसलिए अधिकांश client libraries केवल base URL बदलने के बाद किसी के भी साथ काम करती हैं।

Ollama 127.0.0.1:11434 पर listen करता है। इसका OpenAI-compatible route http://localhost:11434/v1/chat/completions है, और यह इसके साथ-साथ /api/chat पर एक native API भी रखता है। एक Anthropic-compatible route भी document किया गया है।

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 पर listen करता है और /v1/chat/completions, /v1/completions तथा /v1/embeddings सर्व करता है, साथ ही इसका अपना /completion endpoint और एक built-in web UI भी है। यह ऐसे operational routes भी expose करता है जो Ollama नहीं करता: readiness probe के लिए /health, loaded model की settings के लिए /props, प्रत्येक request slot क्या कर रहा है इसके लिए /slots, और Prometheus format में /metrics। यदि आप इस service को monitor करने की योजना बना रहे हैं, तो शायद यही अंतर निर्णय लेने का आधार होगा।

कोई भी server आपके लिए authentication चालू नहीं करता है। उचित कारणों से दोनों default रूप से loopback पर रहते हैं। उन तक SSH tunnel के माध्यम से या reverse proxy के पीछे से पहुँचें, और कभी भी 11434 या 8080 को internet के लिए open न करें।

CPU-only VPS वास्तव में क्या कर सकता है

एक CPU-only VPS छोटे मॉडल्स को धीमी गति से चलाता है। यही इसका वास्तविक सारांश है, और उपयोगी बात यह जानना है कि इसकी सीमा कहाँ है। किसी भी चीज़ को डिज़ाइन करने से पहले मापें:

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

pp कॉलम प्रॉम्प्ट प्रोसेसिंग की गति है और tg कॉलम टोकन जनरेशन की गति है, दोनों टोकन प्रति सेकंड में हैं। एक shared vCPU प्लान पर Q4_K_M पर 8B मॉडल आमतौर पर tg के लिए कम सिंगल डिजिट में परिणाम देता है। प्रॉम्प्ट प्रोसेसिंग वह हिस्सा है जो सबसे अधिक प्रभावित करता है: पहला आउटपुट टोकन दिखाई देने से पहले पूरा प्रॉम्प्ट प्रोसेस किया जाता है, इसलिए एक लंबा सिस्टम प्रॉम्प्ट हर अनुरोध में देरी जोड़ देता है।

CPU पर उपयोग योग्य: 1B से 4B मॉडल जो क्लासिफिकेशन, एक्सट्रैक्शन, संक्षिप्त सारांश या रूटिंग का कार्य करते हैं। उत्तर कुछ सेकंड में आ जाते हैं और मेमोरी सामान्य प्लान में फिट हो जाती है। CPU पर उपयोग योग्य नहीं: पढ़ने की गति पर इंटरैक्टिव चैट, कोडिंग असिस्टेंट, लंबे दस्तावेज़ों पर काम, या कोई भी ऐसा एजेंट लूप जो अनुक्रम में कई कॉल करता है। एक लूप जो चार सेकंड की बारह कॉल करता है, उसे कुछ भी उत्पन्न करने में एक मिनट का समय लगता है।

जब ये आंकड़े काम न करें तो दो रास्ते हैं। यदि समस्या कॉनकरेंसी (concurrency) की है, यानी कई उपयोगकर्ता एक साथ एक मॉडल का उपयोग कर रहे हैं, तो इंजन का चुनाव बदल जाता है, और Ollama बनाम vLLM का कॉनकरेंट सर्विंग के लिए तुलना इस विषय को कवर करती है। यदि समस्या रॉ स्पीड (raw speed) की है, तो इसका उत्तर GPU वाला VPS है, जहाँ -ngl का महत्व शुरू होता है। इन दोनों से पहले, हार्डवेयर के लिए एक बेसलाइन प्राप्त करें, क्योंकि डिस्क और मेमोरी बैंडविड्थ लोड समय को CPU जितना ही प्रभावित करते हैं। एक रिपीटेबल VPS बेंचमार्क पर एक घंटा खर्च करना सार्थक है।

llama.cpp को इंस्टॉल करना और एक विशिष्ट build को पिन करना

दोनों प्रोजेक्ट्स में साप्ताहिक बदलाव होते हैं, इसलिए जो version आपने deploy किया है उसका रिकॉर्ड रखें। अपस्ट्रीम वन-लाइनर वर्तमान build को इंस्टॉल करता है:

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

किसी विशिष्ट build को पिन करने के लिए, इसके बजाय releases पेज से prebuilt tarball लें। 2 अगस्त 2026 तक build 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)

libssl-dev HTTPS फीचर्स के लिए प्रलेखित dependency है। compile होने में कई मिनट लगते हैं और इसके लिए सबसे छोटे plans की तुलना में अधिक RAM की आवश्यकता होती है, इसलिए यदि छोटा सर्वर कम पड़ जाए तो किसी बड़े box पर build करें और binaries को कॉपी कर लें।

Ollama को इंस्टॉल करना, एक विशिष्ट version पर पिन करना

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

यह script OLLAMA_VERSION को पढ़ती है, इसलिए आप आज जारी हुए किसी भी version के बजाय एक ज्ञात-अच्छे (known-good) release को सुरक्षित रख सकते हैं। v0.32.5 को 27 July 2026 को प्रकाशित किया गया था। यदि आप किसी 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 का पूर्ण walkthrough उस service setup को चरण-दर-चरण कवर करता है।

विफलता के प्रकार और दिखाई देने वाले स्ट्रिंग्स

Ollama मॉडल लोड करने से मना कर देता है। ollama run इस प्रकार की एक लाइन दिखाता है:

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

Ollama लोड करने से पहले आकार की जाँच करता है, इसलिए यह तुरंत विफल हो जाता है और कारण बताता है। एक क्वांटाइजेशन रो नीचे जाएँ, कॉन्टेक्स्ट लेंथ कम करें, या छोटा मॉडल चुनें।

llama.cpp विफल नहीं होता, बल्कि बहुत धीमा चलता है। llama.cpp डिफ़ॉल्ट रूप से GGUF को मेमोरी-मैप करता है, इसलिए RAM से बड़ी फ़ाइल भी शुरू हो जाती है। इसके बाद कर्नल हर टोकन पर डिस्क से वेट्स (weights) को पेज-इन और पेज-आउट करता है, और जनरेशन की गति प्रति टोकन सेकंड में गिर जाती है जबकि डिस्क 100 प्रतिशत पर पिन हो जाती है। वास्तविक एलोकेशन को बाध्य करने के लिए --no-mmap पास करें ताकि यह खराब प्रदर्शन करने के बजाय तुरंत विफल हो जाए। जब कर्नल हस्तक्षेप करता है, तो dmesg कारण दिखाता है:

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

मॉडल फ़ाइल बिल्कुल भी लोड नहीं होती है। आपके इंजन से नए मॉडल परिवार के लिए बनाया गया GGUF एक त्रुटि देता है जो उस आर्किटेक्चर का नाम बताती है जिसे वह नहीं पहचानता:

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

इसका समाधान इंजन को अपग्रेड करना है, न कि दूसरी फ़ाइल का उपयोग करना। यह पिनिंग की कीमत है, और यही कारण है कि आप बिल्ड नंबर नोट करते हैं। आपको यह जानना आवश्यक है कि आप किस वर्ज़न से अपग्रेड कर रहे हैं।

API स्थानीय रूप से उत्तर देती है लेकिन आपके ऐप से नहीं। Ollama 127.0.0.1:11434 पर बाइंड होता है, इसलिए दूसरे होस्ट को कनेक्शन रिफ्यूज्ड (connection refused) मिलता है। OLLAMA_HOST=0.0.0.0:11434 को केवल तभी systemctl edit ollama के माध्यम से सेट करें जब पोर्ट किसी फ़ायरवॉल या प्राइवेट नेटवर्क के पीछे हो, क्योंकि API के सामने कोई ऑथेंटिकेशन नहीं होता है।

विराम के बाद पहला उत्तर बहुत धीमा है। 5 मिनट का आइडल अनलोड (idle unload) हो गया है और मॉडल को फिर से डिस्क से पढ़ा जा रहा है। अनुरोध से ठीक पहले चलाया गया ollama ps दिखाता है कि कुछ भी लोड नहीं है, जो इसकी पुष्टि करता है। OLLAMA_KEEP_ALIVE को बढ़ाएं।

तो आपको कौन सा चलाना चाहिए?

जब आप चाहते हैं कि models आपके लिए मैनेज की जाएं और बिना किसी अतिरिक्त मेहनत के OpenAI-जैसा endpoint मिल जाए, तो Ollama चलाएं। यह पहली बार deployment करने के लिए और ऐसी किसी भी स्थिति के लिए सही default विकल्प है जहां model का चुनाव बार-बार बदलता रहेगा।

जब memory इतनी कम हो कि आपको quantization row खुद चुननी पड़े, जब आपको monitoring के लिए /health, /slots और /metrics की आवश्यकता हो, या जब आपको किसी ऐसे flag की जरूरत हो जिसे Ollama expose नहीं करता, तब सीधे llama.cpp चलाएं। VPS पर यह एक ईमानदार विकल्प है जहां model मुश्किल से fit होता है, क्योंकि जिन settings से वह fit होता है, वे बिल्कुल वही हैं जिन्हें Ollama आपकी ओर से चुनता है।

दोनों को एक साथ चलाना सामान्य है। प्रयोगों के लिए Ollama, और उस एक model के लिए llama.cpp जिसे आप production में डालते हैं और जिसमें कोई बदलाव नहीं चाहते।

FAQ

क्या Ollama केवल llama.cpp का एक wrapper है?

काफी हद तक, लेकिन यह wrapper वास्तविक कार्य करता है। Ollama का README, llama.cpp को अपने inference backend के रूप में सूचीबद्ध करता है (2 अगस्त 2026 को जाँचा गया)। इसके ऊपर Ollama एक model registry, prompt template जो chat messages को prompt में बदलता है, default sampling parameters का एक सेट, idle unloading वाला एक daemon और एक HTTP API जोड़ता है। जब आप समान settings पर tokens per second की तुलना करते हैं, तो आप वास्तव में एक ही engine की तुलना उसी से कर रहे होते हैं। आप वास्तव में management layer के बीच चुनाव करते हैं।

CPU-only VPS पर कौन सा अधिक तेज़ है?

वे एक ही engine साझा करते हैं, इसलिए समान model file, quantisation, context size और thread count पर वे लगभग समान प्रदर्शन करते हैं। लोग जो अंतर बताते हैं, वे आमतौर पर अलग-अलग defaults के कारण होते हैं, अक्सर context length और thread count, न कि engine के कारण। किसी भी प्रकाशित आंकड़े पर विश्वास करने से पहले इसे llama-bench -m <file> -p 512 -n 128 के साथ मापें और अपने स्वयं के box पर tg column की तुलना करें।

क्या मैं Ollama के साथ अपनी खुद की GGUF file का उपयोग कर सकता हूँ?

हाँ। file को server पर रखें, एक Modelfile लिखें जिसकी पहली पंक्ति FROM ./your-model.gguf हो, अपनी आवश्यकतानुसार कोई भी PARAMETER पंक्तियाँ जोड़ें जैसे कि num_ctx, और फिर ollama create your-name -f ./Modelfile चलाएँ। ollama ls इसे registry से pull की गई किसी भी चीज़ के साथ सूचीबद्ध करेगा। इस तरह आप उस quantisation का उपयोग करते हैं जो registry में उपलब्ध नहीं है।

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 के साथ scale होता है: 32,768 token context पर वही model अकेले लगभग 4 GiB cache लेता है। Ollama के साथ, याद रखें कि आवश्यकता OLLAMA_NUM_PARALLEL के साथ भी scale होती है।