VPSలో Ollama లేదా llama.cpp: CPU కోసం ఏది?

Ollama vs llama.cpp: మీరు ఏ layer ను అమలు చేయాలనుకుంటున్నారు?

Ollama మరియు llama.cpp ప్రశ్నలో సూచించిన విధంగా పరస్పర పోటీదారులు కావు. llama.cpp అనేది inference engine. ఇది model file ను load చేసి, prompt ను tokens గా మారుస్తుంది. Ollama అనేది model manager, background daemon మరియు ఆ engine పై పనిచేసే HTTP API. Ollama యొక్క README లో ఇప్పటికీ llama.cpp ను inference backend గా పేర్కొంటోంది (2 August 2026 న పరిశీలించబడింది). కాబట్టి అసలు ప్రశ్న ఏది వేగంగా పనిచేస్తుందనేది కాదు. మీ VPS పై మీరు ఏ layer ను నిర్వహించాలనుకుంటున్నారనేదే అసలు ప్రశ్న.

మీకు పేరుతో models ను fetch చేసి, నిరంతర పర్యవేక్షణ లేకుండానే పనిచేసే service కావాలంటే Ollama ను అమలు చేయండి. మీ VPS చిన్నదై ఉంటే, ఖచ్చితమైన model file, ఖచ్చితమైన context size మరియు ఖచ్చితమైన thread count ను ఎంచుకోవాల్సి ఉంటే llama.cpp ను నేరుగా అమలు చేయండి. చిన్న VPS లో ఈ settings లో ప్రతి ఒక్కటి మీ వద్ద లేని memory ని వినియోగిస్తుంది.

ప్రతి ప్రాజెక్ట్ వాస్తవంగా ఏమిటి

llama.cpp అనేది ggml library ఆధారంగా రూపొందించిన transformer inference కు సంబంధించిన C మరియు C++ implementation. ఇది GGUF files ను చదువుతుంది. GGUF (GGML universal file format) అనేది model ను నడపడానికి engine కు అవసరమైన weights, tokeniser మరియు metadata ను ఒకే file లో ఉంచే container. ఈ project వేర్వేరు పనుల కోసం వేర్వేరు binaries ను అందిస్తుంది. llama-server ఒక HTTP server, llama-cli interactive prompt, llama-bench throughput ను కొలుస్తుంది. Releases semantic version కు బదులుగా build number తో tag చేయబడతాయి. ప్రస్తుత tag b10224. ఇది 2 August 2026న published అయింది. ప్రతి వారం ఎక్కువ working days లో కొత్త tag విడుదలవుతుంది.

Ollama అనేది Go program. ollama serve తో ప్రారంభమయ్యే background daemon models ను load చేసి HTTP requests కు సమాధానాలు ఇస్తుంది. Command line client ఆ daemon తో సంభాషిస్తుంది. ఈ రెండింటి వెనుక ollama.com వద్ద prepacked models ను ఉంచే registry ఉంటుంది. Ollama semantic versions ను ఉపయోగిస్తుంది. v0.32.5 27 July 2026న విడుదలైంది. ollama pull ఒక GGUF ను prompt template మరియు default parameters సమూహంతో పాటు fetch చేసి, Linuxలో /usr/share/ollama/.ollama/models కింద నిల్వ చేస్తుంది.

ఈ packaging విధానమే మొత్తం తేడా. Ollama మీ కోసం quantisation, template మరియు context length ను నిర్ణయిస్తుంది. గుర్తుంచుకోవడానికి మీకు ఒకే పేరు ఇస్తుంది. llama.cpp ఏదీ నిర్ణయించదు. ఇది మీకు flags ఇస్తుంది.

అక్షం 1: model మరియు quantisation నియంత్రణ

Quantisation ప్రతి weight ను 16 లేదా 32 bits నుంచి 4, 5 లేదా 8 bits కు తగ్గిస్తుంది. సాధారణ VPS యొక్క RAM లో 8 billion parameters ఉన్న model సరిపోయేలా చేసేది ఇదే. Pattern తెలుసుకున్న తర్వాత GGUF naming అర్థం చేసుకోవడం సులభం: Q4_K_M అంటే 4-bit K-quant, medium size. ఎక్కువ number ఎక్కువ 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కి మార్చారు. ఒక modelకు 6 builds ఉన్నాయి. అతి చిన్నది 2.96 GiB, అతి పెద్దది 7.95 GiB. సాధారణ default అయిన Q4_K_M పరిమాణం 4.58 GiB. 4 GiB VPSలో model అసలు load అవుతుందా లేదా అన్నది ఈ ఒక్క ఎంపికే నిర్ణయిస్తుంది.

llama.cppలో file name ను మీరు పేర్కొనాలి. అందువల్ల ఆ 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 context size ను tokensలో సూచిస్తుంది. -t thread count ను సూచిస్తుంది. -ngl GPUకి ఎన్ని layers తరలించాలో నిర్దేశిస్తుంది (CPU-only boxలో 0). మీ తరఫున ఏదీ ఊహించబడదు.

Ollamaలో quantisation మీరు pull చేసే tagతో పాటు వస్తుంది. 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. అందుబాటులో ఉన్న VRAM ఆధారంగా Ollama తన defaultను ఎంచుకుంటుంది. GPU లేని box అత్యల్ప bucketలోకి వెళుతుంది: 4096 tokens. దానికి 20,000 tokens ఉన్న document పంపితే, model వాటిని చూడకముందే అదనపు tokens తొలగించబడతాయి. ఫలితంగా model documentలో సగం మాత్రమే చదివి, దాని గురించి నమ్మకంగా తప్పు సమాధానం ఇస్తుంది. Daemonలో OLLAMA_CONTEXT_LENGTH ద్వారా లేదా Modelfileలో PARAMETER num_ctx ద్వారా దీన్ని పెంచండి. llama.cppలో కూడా నమ్మదగిన default లేదు. -c ను స్పష్టంగా set చేసి, మీరు ఏ విలువ set చేశారో నిర్ధారించుకోండి.

ఎవరూ చూపించని memory లెక్కలు

Model file మొత్తం ఖర్చు కాదు. KV cache (key/value cache) context లోని ప్రతి token కు, ప్రతి layer కు ఒక entry ను నిల్వ చేస్తుంది. Conversation పెరిగే కొద్దీ ఇది కూడా పెరుగుతుంది.

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 కు కలిపితే ప్రతి token కు 128 KiB అవుతుంది. 4096 token context కు 512 MiB అవసరం. 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 లో సరిపోదు. పని చేయడానికి కొంత memory మిగిలేలా 8 GiB లో సరిపోతుంది. అదే 8 GiB server లో context ను 32k కు పెంచితే cache ఒక్కటే మిగిలిన headroom ను పూర్తిగా వినియోగిస్తుంది. Model load అవుతున్నప్పుడు free -h తో దీనిని ప్రత్యక్షంగా monitor చేయండి. మీరు కొలవని estimate ను నమ్మవద్దు. 8B కంటే చాలా పెద్ద model కోసం capacity నిర్ణయిస్తుంటే, CPU-only VPS పై 27B model కు చేసిన ఇదే లెక్కలు 8 నుంచి 64 GB వరకు ప్రతి tier లో వాస్తవంగా ఎంత memory అందుబాటులో ఉంటుందో చూపిస్తాయి.

Ollama దీనిని మరింత పెంచుతుంది. OLLAMA_NUM_PARALLEL default గా 1. Model కు అవసరమైన memory ఈ సంఖ్య మరియు context length యొక్క గుణితానికి అనుగుణంగా పెరుగుతుంది. రెండింటినీ ఒకేసారి పెంచితే, మీరు ఊహించిన RAM కంటే daemon నిశ్శబ్దంగా అనేక రెట్లు ఎక్కువ RAM కోరుతుంది. ఒకేసారి సేవలందించగల users సంఖ్యకు కూడా ఇదే లెక్క పరిమితిని నిర్ణయిస్తుంది. ప్రతి concurrent request కు KV cache లో ప్రత్యేక భాగం అవసరం. అందుకే ఒక వ్యక్తికి బాగా పనిచేసే server ఐదుగురు users వద్ద నిలిచిపోతుంది.

అక్షం 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

CPU VPSలో OLLAMA_KEEP_ALIVE కు ఇతర సందర్భాలకన్నా ఎక్కువ ప్రాధాన్యం ఉంటుంది. Models డిఫాల్ట్‌గా 5 minutes పాటు memoryలో ఉంచబడతాయి. తరువాత అవి unload అవుతాయి. తదుపరి requestకు సమాధానం ఇవ్వడానికి ముందు మొత్తం fileను disk నుంచి మళ్లీ చదవాలి. అందువల్ల slow storageపై 4.58 GiB reload రెండు seconds సమాధానాన్ని thirty seconds సమాధానంగా మార్చవచ్చు. ఎక్కువ 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ను memoryలో ఉంచుతుంది. idleగా ఉన్నప్పుడు ఏదీ unload కాదు. అందువల్ల reloadకు సంబంధించిన అనూహ్య ఆలస్యం ఉండదు. అయితే serviceను stop చేయడం తప్ప memoryను తిరిగి ఖాళీ చేసే మార్గం ఉండదు. units రాయడం మీకు కొత్త విషయమైతే, ఇది VPSలో systemd కింద మీ స్వంత servicesను నడపడంలోని అదే విధానం.

అక్షం 3: మీ app మాట్లాడే API

ఈ అక్షం పరిధి ఇప్పుడు చాలా తగ్గింది. రెండు projectలు ప్రస్తుతం OpenAI chat format ను support చేస్తున్నాయి. అందువల్ల base URL మార్చిన తర్వాత ఎక్కువ client libraries ఏ projectతోనైనా పనిచేస్తాయి.

Ollama 127.0.0.1:11434 పై listen చేస్తుంది. దీని OpenAI-compatible route http://localhost:11434/v1/chat/completions. అదనంగా, ఇది native API ను /api/chat వద్ద అందిస్తుంది. Anthropic-compatible 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 పై listen చేస్తుంది. ఇది /v1/chat/completions, /v1/completions, /v1/embeddings ను అందిస్తుంది. అదనంగా, దాని స్వంత /completion endpoint మరియు built-in web UI కూడా ఉన్నాయి. Ollamaలో లేని operational routes ను కూడా ఇది అందిస్తుంది: readiness probe కోసం /health, loaded model settings కోసం /props, ప్రతి request slot చేస్తున్న పనిని చూడటానికి /slots, Prometheus format లో metrics కోసం /metrics. మీరు ఈ service ను monitor చేయాలని అనుకుంటే, నిర్ణయాత్మకమైన తేడా ఇదే కావచ్చు.

ఏ server కూడా మీ కోసం authentication ను స్వయంచాలకంగా enable చేయదు. సరైన కారణంతో, రెండూ default గా loopback కు మాత్రమే bind అవుతాయి. SSH tunnel ద్వారా లేదా reverse proxy వెనుక నుంచి వాటిని access చేయండి. 11434 లేదా 8080 ను internet కు ఎప్పుడూ open చేయవద్దు.

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 లో 8B model, Q4_K_M వద్ద, సాధారణంగా tg కోసం తక్కువ single-digit విలువలను ఇస్తుంది. Prompt processing భాగమే ఎక్కువ ఆలస్యాన్ని కలిగిస్తుంది. మొదటి output token కనిపించే ముందు మొత్తం prompt ప్రాసెస్ అవుతుంది. అందువల్ల పొడవైన system prompt ప్రతి request కు అదనపు వేచి ఉండే సమయాన్ని కలిగిస్తుంది.

CPUపై ఉపయోగించగల పనులు: classification, extraction, short summaries లేదా routing చేసే 1B నుంచి 4B model. Replies కొన్ని seconds లో వస్తాయి. Memory కూడా సాధారణ plan లో సరిపోతుంది. CPUపై ఉపయోగించలేని పనులు: చదివే వేగంతో interactive chat, coding assistants, long-document పని, లేదా వరుసగా అనేక calls చేసే agent loop. ప్రతి call కు నాలుగు seconds పడే loop పన్నెండు calls చేస్తే, ఏదైనా output ఇవ్వడానికి ముందు ఒక minute పడుతుంది. Coding assistant ఉపయోగించాలనేది మీ ప్రణాళిక అయితే, మీరు స్వయంగా host చేసే model కు agent ను అనుసంధానించడం ద్వారా చిన్న local model నిజంగా ఏ పనుల్లో మెరుగ్గా పనిచేస్తుందో, ఏ పనులు hosted APIలోనే ఉండాలో వివరిస్తుంది.

ఈ సంఖ్యలు సరిపోనప్పుడు రెండు ప్రత్యామ్నాయాలు ఉన్నాయి. సమస్య concurrency అయితే, అంటే అనేక users ఒకేసారి ఒకే model ను ఉపయోగిస్తే, engine ఎంపిక మారుతుంది. concurrent serving కోసం Ollama మరియు vLLM పోలిక దీనిని వివరిస్తుంది. సమస్య raw speed అయితే, సమాధానం GPU అనుసంధానించిన VPS, ఇక్కడ -ngl కు వాస్తవ ప్రాధాన్యం ఉంటుంది. ఈ రెండింటిలో ఏదైనా ఎంచుకునే ముందు hardware కు baseline తీసుకోండి. CPUతో సమానంగా disk మరియు memory bandwidth కూడా load time ను ప్రభావితం చేస్తాయి. పునరావృతంగా నిర్వహించగల VPS benchmark కోసం ఒక గంట కేటాయించడం విలువైనదే.

llama.cpp ను నిర్దిష్ట build కు పరిమితం చేసి ఇన్‌స్టాల్ చేయండి

రెండు ప్రాజెక్ట్‌లలోనూ వారానికొకసారి మార్పులు వస్తాయి. అందువల్ల మీరు అమలు చేసిన version ను నమోదు చేసుకోండి. 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 documented dependency. Compile పూర్తవడానికి several minutes పడుతుంది. దీనికి చిన్న plans అందించేదానికంటే ఎక్కువ RAM అవసరం కావచ్చు. చిన్న server లో RAM సరిపోకపోతే, పెద్ద box పై build చేసి binaries ను copy చేయండి.

ఒక నిర్దిష్ట version కు pin చేసి Ollama ఇన్‌స్టాల్ చేయండి

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

ఈ script OLLAMA_VERSION ను చదువుతుంది. అందువల్ల ఈ ఉదయం విడుదలైన version ను యాదృచ్ఛికంగా తీసుకోకుండా, మీకు విశ్వసనీయంగా పనిచేసిన release ను ఉపయోగించవచ్చు. v0.32.5 27 July 2026న విడుదలైంది. Shell కు script ను 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 పరిమాణాన్ని తనిఖీ చేస్తుంది. అందువల్ల అది వెంటనే విఫలమై కారణాన్ని చూపిస్తుంది. Quantisation పట్టికలో ఒక వరుస కిందికి వెళ్లండి, context length తగ్గించండి లేదా చిన్న మోడల్‌ను ఎంచుకోండి.

llama.cpp విఫలం కాదు, కానీ చాలా నెమ్మదిగా పనిచేస్తుంది. llama.cpp డిఫాల్ట్‌గా GGUF ను memory-map చేస్తుంది. అందువల్ల RAM కంటే పెద్ద ఫైల్ కూడా ప్రారంభమవుతుంది. తరువాత kernel ప్రతి token సమయంలో disk నుంచి weights ను page in, page out చేస్తుంది. ఫలితంగా generation ప్రతి token కు అనేక సెకన్లు పడుతుంది, మరియు disk వినియోగం 100 percent వద్ద నిలిచిపోతుంది. నిజమైన allocation ను బలవంతంగా ఉపయోగించేందుకు --no-mmap పంపండి. అప్పుడు పనితీరు తగ్గిపోవడానికి బదులుగా అది వెంటనే విఫలమవుతుంది. kernel జోక్యం చేసుకున్నప్పుడు, dmesg కారణాన్ని చూపిస్తుంది:

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

మోడల్ ఫైల్ అసలు లోడ్ కావడం లేదు. మీ engine కంటే కొత్త model family కోసం నిర్మించిన GGUF ఉపయోగిస్తే, తనకు తెలియని architecture పేరుతో error చూపిస్తుంది:

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

దీనికి పరిష్కారం వేరే ఫైల్ కాదు, engine upgrade. Version pinning కు ఇదే ఖర్చు. అందుకే build number ను నమోదు చేయాలి. మీరు ఏ build నుంచి 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 జరిగింది. అందువల్ల మోడల్ మళ్లీ disk నుంచి చదవబడుతోంది. అభ్యర్థనకు ముందు ollama ps ను అమలు చేస్తే ఏదీ loaded లేదని చూపిస్తుంది. ఇది కారణాన్ని నిర్ధారిస్తుంది. OLLAMA_KEEP_ALIVE విలువను పెంచండి.

అయితే మీరు ఏది అమలు చేయాలి?

మోడళ్ల నిర్వహణను మీకు అప్పగించి, అదనపు పని లేకుండా OpenAI ఆకృతిలోని endpoint కావాలనుకుంటే Ollama ను అమలు చేయండి. మొదటి deployment కు ఇది సరైన default. Model ఎంపిక తరచుగా మారే సందర్భాల్లో కూడా ఇది అనుకూలంగా ఉంటుంది.

మెమరీ పరిమితంగా ఉండి quantisation row ను మీరే ఎంచుకోవాల్సి వస్తే, monitoring కోసం /health, /slots మరియు /metrics అవసరమైతే, లేదా Ollama అందించని flag అవసరమైతే llama.cpp ను నేరుగా అమలు చేయండి. Model అతి కష్టం మీద సరిపోయే VPSలో ఇది వాస్తవిక ఎంపిక. ఎందుకంటే model సరిపోయేలా చేసే settings నే Ollama మీ తరఫున ఎంచుకుంటుంది.

రెండింటినీ అమలు చేయడం సాధారణమే. ప్రయోగాల కోసం Ollama ను, productionలో ఉంచి ఇక మారకుండా చూడాలనుకునే ఒకే model కోసం llama.cpp ను ఉపయోగించండి.

FAQ

Ollama అనేది llama.cpp చుట్టూ ఉన్న wrapper మాత్రమేనా?

దగ్గరగా చెప్పాలంటే అవును, కానీ ఈ wrapper వాస్తవమైన పనిని కూడా చేస్తుంది. Ollama యొక్క README లో llama.cpp ను దాని inference backend గా పేర్కొంది (2026 ఆగస్టు 2న పరిశీలించబడింది). Ollama దీనిపై model registry, chat messages ను prompt గా మార్చే prompt template, default sampling parameters సమూహం, idle unloading కలిగిన daemon, HTTP APIలను జతచేస్తుంది. ఒకే settings తో ప్రతి second కు tokens సంఖ్యను పోల్చినప్పుడు, మీరు అదే engine ను దానితోనే పోల్చుతున్నారు. వాస్తవానికి మీరు ఎంచుకునేది management layer.

CPU-only VPSలో ఏది వేగంగా ఉంటుంది?

ఇవి ఒకే engine ను పంచుకుంటాయి. అందువల్ల ఒకే model file, quantisation, context size, thread count ఉపయోగించినప్పుడు ఫలితాలు దగ్గరగా ఉంటాయి. వ్యక్తులు నివేదించే తేడాలు సాధారణంగా engine వల్ల కాకుండా వేర్వేరు defaultల వల్ల వస్తాయి. ముఖ్యంగా context length మరియు thread count ఇందుకు కారణాలు. ప్రచురించిన ఏ గణాంకాన్నైనా నమ్మే ముందు llama-bench -m <file> -p 512 -n 128 తో కొలిచి, మీ స్వంత serverలో tg column ను పోల్చండి.

Ollamaతో నా స్వంత GGUF fileను ఉపయోగించవచ్చా?

అవును. ఆ fileను serverలో ఉంచి, మొదటి line FROM ./your-model.gguf గా ఉన్న Modelfile ను రాయండి. అవసరమైన PARAMETER lines, ఉదాహరణకు num_ctx, జతచేసి, తరువాత ollama create your-name -f ./Modelfile ను అమలు చేయండి. Registry నుంచి pull చేసిన వాటి పక్కన ollama ls దానిని చూపిస్తుంది. 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 తో అవసరం కూడా పెరుగుతుందని గుర్తుంచుకోండి.