VPSలో Ollama vs llama.cpp: ఏది ఉత్తమం?

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

Ollama మరియు llama.cpp ఈ ప్రశ్న సూచించినట్లుగా ఒకదానికొకటి పోటీదారులు కావు. llama.cpp అనేది ఒక inference engine: ఇది మోడల్ ఫైల్‌ను లోడ్ చేసి, ప్రాంప్ట్‌ను టోకెన్‌లుగా మారుస్తుంది. Ollama అనేది ఒక మోడల్ మేనేజర్, ఇది ఆ ఇంజిన్ పైన పనిచేసే ఒక background daemon మరియు HTTP API. Ollama యొక్క README ఇప్పటికీ llama.cppని దాని inference backendగా పేర్కొంటుంది (2 August 2026న తనిఖీ చేయబడింది). కాబట్టి అసలైన ప్రశ్న ఏది వేగంగా పనిచేస్తుంది అనేది కాదు, మీ VPSలో మీరు ఏ లేయర్‌ను ఆపరేట్ చేయాలనుకుంటున్నారు అనేది.

మీకు మోడల్స్‌ను పేరుతో డౌన్‌లోడ్ చేసుకుని, ఎటువంటి పర్యవేక్షణ లేకుండా నిరంతరాయంగా పనిచేసే సేవ కావాలంటే Ollamaను రన్ చేయండి. మీ సర్వర్ చిన్నదిగా ఉండి, ఖచ్చితమైన మోడల్ ఫైల్, ఖచ్చితమైన context size మరియు ఖచ్చితమైన thread count ఎంచుకోవాల్సిన అవసరం ఉన్నప్పుడు llama.cppని నేరుగా రన్ చేయండి. ఎందుకంటే చిన్న VPSలో, మీరు మార్చే ప్రతి సెట్టింగ్ మీ వద్ద లేని మెమరీని వినియోగిస్తుంది.

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

llama.cpp అనేది ggml లైబ్రరీపై నిర్మించిన transformer inference యొక్క C మరియు C++ ఇంప్లిమెంటేషన్. ఇది GGUF ఫైళ్లను చదువుతుంది. GGUF (GGML universal file format) అనేది మోడల్‌ను రన్ చేయడానికి ఇంజిన్‌కు అవసరమైన వెయిట్స్ (weights), టోకనైజర్ మరియు మెటాడేటాను కలిగి ఉండే ఒకే ఫైల్ కంటైనర్. ఈ ప్రాజెక్ట్ వేర్వేరు పనుల కోసం వేర్వేరు బైనరీలను విడుదల చేస్తుంది. llama-server అనేది ఒక HTTP సర్వర్, llama-cli అనేది ఒక ఇంటరాక్టివ్ ప్రాంప్ట్, మరియు llama-bench అనేది త్రూపుట్‌ను కొలుస్తుంది. ఈ విడుదలలు సెమాంటిక్ వెర్షన్ కంటే బిల్డ్ నంబర్ ద్వారా ట్యాగ్ చేయబడతాయి. ప్రస్తుత ట్యాగ్ 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 కింద నిల్వ చేస్తుంది. ఆ ఫైళ్లు రూట్ డిస్క్‌లో ఉంటాయి మరియు ఒక్కొక్కటి కొన్ని గిగాబైట్ల పరిమాణంలో ఉంటాయి, కాబట్టి 25 GB రూట్ వాల్యూమ్ ఉన్న VPSలో, మూడవ డౌన్‌లోడ్ నింపకముందే pull ఏమి వదిలివేస్తుంది మరియు మోడల్ డైరెక్టరీని వేరే చోటికి ఎలా తరలించాలి అని తెలుసుకోవడం మంచిది.

ఆ ప్యాకేజింగ్ మాత్రమే ప్రధాన వ్యత్యాసం. Ollama మీ కోసం క్వాంటిజేషన్, టెంప్లేట్ మరియు కాంటెక్స్ట్ లెంగ్త్‌ను నిర్ణయిస్తుంది, మరియు గుర్తుంచుకోవడానికి ఒక పేరును ఇస్తుంది. llama.cpp ఏదీ నిర్ణయించదు మరియు మీకు ఫ్లాగ్‌లను ఇస్తుంది.

Axis 1: మోడల్ మరియు క్వాంటైజేషన్ నియంత్రణ

క్వాంటైజేషన్ ప్రతి వెయిట్‌ను 16 లేదా 32 బిట్ల నుండి 4, 5 లేదా 8 బిట్లకు తగ్గిస్తుంది. దీనివల్లనే 8 బిలియన్ పారామీటర్ల మోడల్ ఒక సాధారణ VPS యొక్క RAMలో సరిపోతుంది. GGUF నామకరణ పద్ధతి తెలిస్తే అది చదవడం సులభం: Q4_K_M అంటే 4-బిట్ K-క్వాంట్, మధ్యస్థ పరిమాణం అని అర్థం. సంఖ్య పెరిగేకొద్దీ ఖచ్చితత్వం పెరుగుతుంది, కానీ మెమరీ వినియోగం కూడా పెరుగుతుంది.

[
  {
    "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 ఉన్నప్పుడు, ఈ ఒక్క ఎంపికే మోడల్ లోడ్ అవుతుందా లేదా అని నిర్ణయిస్తుంది. పరిమాణం అనేది నిర్ణయంలో సగం మాత్రమే, ఎందుకంటే మీకు అందుబాటులో ఉన్న ఫైల్ సైజు అంతా నాణ్యమైన ఫలితాన్ని ఇస్తుందని గ్యారెంటీ లేదు. Q4, Q8 మరియు fp16 వల్ల సమాధానం నాణ్యతలో వచ్చే మార్పులు మీకు అదనపు గిగాబైట్లు అవసరమా లేదా అని తెలియజేస్తాయి.

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 తో క్వాంటైజేషన్ మీరు పుల్ చేసే ట్యాగ్‌తో పాటు వస్తుంది, మరియు 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 టోకెన్ల డాక్యుమెంట్‌ను పంపితే, అదనపు టోకెన్లు మోడల్‌కు చేరకముందే తొలగించబడతాయి, కాబట్టి మోడల్ సగం చదివిన ఫైల్ గురించి తప్పుడు సమాధానాన్ని ఇస్తుంది. దీనిని పెంచడానికి డెమన్‌పై OLLAMA_CONTEXT_LENGTH వాడండి లేదా Modelfile లో PARAMETER num_ctx సెట్ చేయండి. ఒకవేళ ఒకే జాబ్‌కు పెద్ద విండో అవసరమైతే, num_ctx ను సర్వర్ అంతటా కాకుండా ప్రతి అభ్యర్థనకు విడిగా సెట్ చేయవచ్చు, దీనివల్ల మిగిలిన పనులపై అదనపు భారం పడదు. llama.cpp లో కూడా నమ్మదగ్గ డిఫాల్ట్ సెట్టింగ్ ఏదీ లేదు. -c ని స్పష్టంగా సెట్ చేయండి మరియు మీరు ఏమి సెట్ చేస్తున్నారో తెలుసుకోండి.

మెమరీ గణన గురించి ఎవరూ చెప్పని విషయాలు

మోడల్ ఫైల్ మాత్రమే మొత్తం ఖర్చు కాదు. KV cache (key/value cache) ప్రతి లేయర్‌కు, ప్రతి కాంటెక్స్ట్ టోకెన్‌కు ఒక ఎంట్రీని కలిగి ఉంటుంది. సంభాషణ పెరిగేకొద్దీ ఇది కూడా పెరుగుతుంది.

Llama 3.1 8B కోసం దీనిని లెక్కించండి. ఈ మోడల్‌లో 32 లేయర్లు, 8 key/value హెడ్స్ మరియు 128 హెడ్ డైమెన్షన్ ఉన్నాయి. ప్రతి టోకెన్ f16 ఫార్మాట్‌లో 2 బైట్ల చొప్పున కీ మరియు వాల్యూ రెండింటినీ నిల్వ చేస్తుంది. కాబట్టి, ప్రతి లేయర్‌కు 2 x 8 x 128 x 2 = 4096 బైట్లు అవసరం. 32 లేయర్లకు కలిపి ఇది ప్రతి టోకెన్‌కు 128 KiB అవుతుంది. అందువల్ల, 4096 టోకెన్ల కాంటెక్స్ట్ కోసం 512 MiB, మరియు 32,768 టోకెన్ల కాంటెక్స్ట్ కోసం 4 GiB మెమరీ ఖర్చవుతుంది.

కాబట్టి, 4k కాంటెక్స్ట్ ఉన్న Q4_K_M 8B మోడల్‌కు వెయిట్స్ కోసం సుమారు 4.58 GiB, అదనంగా 0.5 GiB cache, మరియు రన్‌టైమ్ కోసం కొంత మెమరీ అవసరం. ఇది 4 GiB RAM లో సరిపోదు. 8 GiB RAM లో అయితే ఇది సులభంగా సరిపోతుంది. అదే 8 GiB బాక్స్‌లో కాంటెక్స్ట్‌ను 32k కి పెంచితే, కేవలం cache మాత్రమే అందుబాటులో ఉన్న మెమరీని పూర్తిగా వాడేస్తుంది. మోడల్ లోడ్ అవుతున్నప్పుడు free -h తో దీనిని ప్రత్యక్షంగా గమనించండి, మీరు స్వయంగా కొలవని అంచనాలను నమ్మకండి. మీరు 8B కంటే పెద్ద మోడల్ కోసం ప్లాన్ చేస్తుంటే, a 27B model on a CPU-only VPS లో వివరించిన అదే గణన పద్ధతిని ఉపయోగించి 8 GB నుండి 64 GB వరకు ప్రతి స్థాయి ఎంత మెమరీని తీసుకుంటుందో తెలుసుకోవచ్చు.

Ollama దీనిని మరింత పెంచుతుంది. OLLAMA_NUM_PARALLEL డిఫాల్ట్‌గా 1 కి సెట్ చేయబడి ఉంటుంది, మోడల్‌కు అవసరమైన మెమరీ ఆ సంఖ్య మరియు కాంటెక్స్ట్ లెంగ్త్ రెండింటిపై ఆధారపడి ఉంటుంది. ఈ రెండింటినీ ఒకేసారి పెంచితే, మీరు ఊహించిన దానికంటే చాలా ఎక్కువ RAM అవసరమని daemon అడుగుతుంది. అదే గణన పద్ధతి ఏకకాలంలో ఎంతమంది వినియోగదారులు వాడగలరో నిర్ణయిస్తుంది, ఎందుకంటే ప్రతి అభ్యర్థనకు విడి KV cache అవసరం. అందుకే why a server that feels fine for one person stalls at five.

Axis 2: మీరు నిర్వహించాల్సిన daemon

Ollama ఇన్‌స్టాలేషన్ స్క్రిప్ట్ ఒక systemd unitని రాస్తుంది, ఒక ollama సిస్టమ్ యూజర్‌ను సృష్టిస్తుంది మరియు సేవను ఎనేబుల్ చేస్తుంది. మీరు ఏమీ రాయకుండానే lifecycle నిర్వహణను పొందుతారు. కాన్ఫిగరేషన్ 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లో మరెక్కడా లేనంత ముఖ్యమైనది. మోడల్స్ డిఫాల్ట్‌గా 5 నిమిషాల పాటు మెమరీలో ఉండి, ఆ తర్వాత అన్‌లోడ్ అవుతాయి. తదుపరి అభ్యర్థన వచ్చినప్పుడు, అది సమాధానం ఇచ్చే ముందు మొత్తం ఫైల్‌ను డిస్క్ నుండి మళ్లీ చదవాలి, కాబట్టి 4.58 GiB రీలోడ్ అనేది నెమ్మదిగా ఉండే స్టోరేజ్‌లో రెండు సెకన్ల ప్రతిస్పందనను ముప్పై సెకన్లకు పెంచుతుంది. ఎక్కువ సమయం keep-alive ఉంచడం వల్ల latency తగ్గుతుంది మరియు RAM నిరంతరం వినియోగించబడుతుంది. ఈ రెండూ వాస్తవ ఖర్చులే. మీకు ఏది తక్కువ నష్టమో దానిని ఎంచుకోండి. మోడల్ ఎల్లప్పుడూ మెమరీలోనే ఉండాలని మీరు నిర్ణయించుకుంటే, idle సమయాల్లో మరియు రీబూట్‌ల తర్వాత కూడా ఉండేలా keep_alive సెట్ చేయడం కొన్ని లైన్ల పని మాత్రమే, ఇది ప్రతిసారీ సర్వర్ రీస్టార్ట్ అయినప్పుడు మాన్యువల్‌గా మోడల్‌ను సిద్ధం చేసే శ్రమను తగ్గిస్తుంది.

llama.cpp మీకు ఎటువంటి daemonని అందించదు, కాబట్టి మీరు /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తో ఎనేబుల్ చేయండి. అప్పుడు ఆ ప్రాసెస్ తన జీవితకాలం మొత్తం మోడల్‌ను కలిగి ఉంటుంది. idle సమయంలో ఏదీ అన్‌లోడ్ అవ్వదు, అంటే రీలోడ్ ఆలస్యం ఉండదు మరియు సేవను ఆపడం తప్ప మెమరీని తిరిగి పొందే మార్గం ఉండదు. యూనిట్లను రాయడం మీకు కొత్త అయితే, ఇది VPSలో మీ స్వంత సేవలను systemd కింద నడపడం వంటిదే.

Axis 3: మీ అప్లికేషన్ కమ్యూనికేట్ చేసే API

ఈ విభాగం చాలా వరకు కుదించబడింది. ప్రస్తుతం రెండు ప్రాజెక్ట్‌లు OpenAI చాట్ ఫార్మాట్‌ను ఉపయోగిస్తున్నాయి, కాబట్టి బేస్ URL మార్చిన తర్వాత చాలా క్లయింట్ లైబ్రరీలు రెండింటితోనూ పనిచేస్తాయి.

Ollama 127.0.0.1:11434 లో వింటుంది (listen). దీని OpenAI-అనుకూల రూట్ http://localhost:11434/v1/chat/completions, మరియు ఇది దానితో పాటు /api/chat వద్ద నేటివ్ APIని కూడా కలిగి ఉంటుంది. Anthropic-అనుకూల రూట్ కూడా డాక్యుమెంట్ చేయబడింది.

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 ఎండ్‌పాయింట్ మరియు అంతర్నిర్మిత వెబ్ UIని కలిగి ఉంటుంది. ఇది Ollama లో లేని అదనపు ఆపరేషనల్ రూట్‌లను కూడా అందిస్తుంది: readiness probe కోసం /health, లోడ్ చేయబడిన మోడల్ సెట్టింగ్‌ల కోసం /props, ప్రతి రిక్వెస్ట్ స్లాట్ ఏమి చేస్తోందో తెలుసుకోవడానికి /slots, మరియు Prometheus ఫార్మాట్‌లో /metrics. మీరు ఈ సేవను పర్యవేక్షించాలనుకుంటే, ఈ వ్యత్యాసమే నిర్ణయాత్మక అంశం కావచ్చు.

ఏ సర్వర్ కూడా మీ కోసం ఆటోమేటిక్‌గా అథెంటికేషన్‌ను ఆన్ చేయదు. రెండూ భద్రతా కారణాల దృష్ట్యా డిఫాల్ట్‌గా లూప్‌బ్యాక్ (loopback) అడ్రస్‌పైనే పనిచేస్తాయి. వీటిని SSH టన్నెల్ ద్వారా లేదా రివర్స్ ప్రాక్సీ వెనుక నుండి మాత్రమే యాక్సెస్ చేయండి, ఎట్టి పరిస్థితుల్లోనూ 11434 లేదా 8080 పోర్ట్‌లను ఇంటర్నెట్‌కు నేరుగా ఓపెన్ చేయవద్దు.

CPU-మాత్రమే ఉన్న VPS నిజంగా ఏమి చేయగలదు

CPU-మాత్రమే ఉన్న VPS చిన్న మోడళ్లను నెమ్మదిగా నడుపుతుంది. ఇది నిజాయితీతో కూడిన సారాంశం, మరియు ఆ పరిమితి ఎక్కడ ఉందో తెలుసుకోవడం ఉపయోగకరమైన అంశం. దేనినైనా రూపొందించే ముందు కొలవండి:

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

pp కాలమ్ ప్రాంప్ట్ ప్రాసెసింగ్ వేగాన్ని, tg కాలమ్ టోకెన్ జనరేషన్ వేగాన్ని సూచిస్తాయి, ఇవి రెండూ సెకనుకు ఎన్ని టోకెన్లు అనే కొలతలో ఉంటాయి. షేర్డ్ vCPU ప్లాన్‌పై Q4_K_M క్వాంటైజేషన్ కలిగిన 8B మోడల్ సాధారణంగా tg కోసం తక్కువ సింగిల్ డిజిట్ వేగాన్ని కలిగి ఉంటుంది. ప్రాంప్ట్ ప్రాసెసింగ్ అనేది ఇబ్బంది కలిగించే భాగం: మొదటి అవుట్‌పుట్ టోకెన్ కనిపించే ముందు మొత్తం ప్రాంప్ట్ ప్రాసెస్ చేయబడుతుంది, కాబట్టి సుదీర్ఘమైన సిస్టమ్ ప్రాంప్ట్ ప్రతి అభ్యర్థనకు నిరీక్షణ సమయాన్ని పెంచుతుంది. సమాధానం పొడవును మీరు నియంత్రించవచ్చు, ఎందుకంటే సెకనుకు మూడు టోకెన్ల వేగంతో, 600 టోకెన్ల వరకు మాట్లాడే మోడల్ మూడు నిమిషాల పాటు సర్వర్‌ను బిజీగా ఉంచుతుంది, కాబట్టి num_predict తో అవుట్‌పుట్‌ను పరిమితం చేయడం అనేది ఒక సుదీర్ఘ సమాధానం వల్ల టైమ్-అవుట్ కాకుండా ఉండటానికి చౌకైన మార్గం.

CPUపై ఉపయోగపడేవి: క్లాసిఫికేషన్, ఎక్స్‌ట్రాక్షన్, చిన్న సారాంశాలు లేదా రూటింగ్ చేసే 1B నుండి 4B మోడళ్లు. సమాధానాలు సెకన్లలో అందుతాయి మరియు మెమరీ సాధారణ ప్లాన్‌కు సరిపోతుంది. ఆ పరిమాణంలో ఒక ఉదాహరణ కోసం, VPSలో Nemotron 3.5 Lightning ని ఇన్‌స్టాల్ చేసి కొలవడం ద్వారా ఖచ్చితమైన ట్యాగ్, దానికి అవసరమైన RAM మరియు GPU లేకుండా అది ఇచ్చే వేగాన్ని చూడవచ్చు. CPUపై ఉపయోగపడనివి: చదివే వేగంతో జరిగే ఇంటరాక్టివ్ చాట్, కోడింగ్ అసిస్టెంట్లు, సుదీర్ఘ డాక్యుమెంట్లపై పని, లేదా వరుసగా అనేక కాల్స్ చేసే ఏజెంట్ లూప్ ఉన్న ఏ పని అయినా. నాలుగు సెకన్ల చొప్పున పన్నెండు కాల్స్ చేసే లూప్ ఏదైనా ఫలితాన్ని ఇవ్వడానికి ఒక నిమిషం సమయం తీసుకుంటుంది. ఒకవేళ కోడింగ్ అసిస్టెంట్ మీ ప్రణాళిక అయితే, మీరు హోస్ట్ చేసిన మోడల్‌కు ఏజెంట్‌ను అనుసంధానించడం ద్వారా చిన్న లోకల్ మోడల్ ఏ పనులకు పనికొస్తుందో మరియు ఏవి హోస్ట్ చేసిన APIపై ఉండాలో అర్థమవుతుంది.

సంఖ్యలు సరిపోనప్పుడు రెండు మార్గాలు ఉన్నాయి. సమస్య కన్కరెన్సీ (ఒకేసారి ఎక్కువ మంది వినియోగదారులు ఒకే మోడల్‌ను వాడటం) అయితే, ఇంజిన్ ఎంపిక మారుతుంది, మరియు కన్కరెంట్ సర్వింగ్ కోసం Ollama మరియు vLLM ల మధ్య పోలిక ఆ అంశాన్ని వివరిస్తుంది. సమస్య కేవలం వేగం అయితే, దానికి సమాధానం GPU ఉన్న VPS, అక్కడ -ngl కి అర్థం ఉంటుంది. వీటి కంటే ముందు, హార్డ్‌వేర్ కోసం ఒక బేస్‌లైన్‌ను పొందండి, ఎందుకంటే డిస్క్ మరియు మెమరీ బ్యాండ్‌విడ్త్ కూడా CPU వలె లోడ్ సమయాన్ని ప్రభావితం చేస్తాయి. పునరావృతమయ్యే VPS బెంచ్‌మార్క్ కోసం ఒక గంట కేటాయించడం విలువైనది.

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

ఈ రెండు ప్రాజెక్ట్‌లు ప్రతి వారం మారుతుంటాయి, కాబట్టి మీరు డిప్లాయ్ చేసిన వెర్షన్‌ను రికార్డ్ చేసుకోండి. అప్‌స్ట్రీమ్ వన్-లైనర్ కమాండ్ ప్రస్తుత build ను ఇన్‌స్టాల్ చేస్తుంది:

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

ఒక నిర్దిష్ట build కి పిన్ చేయడానికి, releases పేజీ నుండి ముందుగా బిల్డ్ చేసిన tarball ను తీసుకోండి. 2 ఆగస్టు 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 ను సోర్స్ నుండి బిల్డ్ చేయండి:

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 ఫీచర్ల కోసం libssl-dev అవసరమని డాక్యుమెంటేషన్‌లో పేర్కొనబడింది. కంపైల్ చేయడానికి కొన్ని నిమిషాల సమయం పడుతుంది మరియు ఇది అతిచిన్న ప్లాన్‌లలో అందుబాటులో ఉన్న దానికంటే ఎక్కువ RAM ను కోరుకుంటుంది. కాబట్టి, చిన్న సర్వర్‌లో మెమరీ సరిపోకపోతే, పెద్ద సర్వర్‌లో బిల్డ్ చేసి ఆ binaries ను కాపీ చేయండి.

Ollama ను ఇన్‌స్టాల్ చేయడం, ఒక వెర్షన్‌కు పిన్ చేయడం

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

ఈ స్క్రిప్ట్ OLLAMA_VERSION ని చదువుతుంది, కాబట్టి ఈరోజు విడుదలైన వెర్షన్‌ను నేరుగా తీసుకునే బదులు, మీకు తెలిసిన సరైన వెర్షన్‌ను మీరు ఉంచుకోవచ్చు. v0.32.5 వెర్షన్ 27 జూలై 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 పూర్తి స్థాయి సెటప్ గైడ్ ఆ సర్వీస్ సెటప్‌ను దశలవారీగా వివరిస్తుంది.

వైఫల్య రీతులు మరియు మీకు కనిపించే సందేశాలు

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 కంటే పెద్ద ఫైల్ కూడా ప్రారంభమవుతుంది. అప్పుడు కెర్నల్ ప్రతి టోకెన్ కోసం డిస్క్ నుండి వెయిట్స్‌ను పేజింగ్ చేస్తుంది, దీనివల్ల డిస్క్ వినియోగం 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 నిమిషాల ఐడిల్ టైమ్ తర్వాత మోడల్ అన్‌లోడ్ చేయబడింది మరియు అది మళ్ళీ డిస్క్ నుండి రీడ్ చేయబడుతోంది. అభ్యర్థనకు ముందుగా రన్ చేసిన ollama ps ఏమీ లోడ్ కాలేదని చూపిస్తే, ఇది నిర్ధారించబడినట్లే. OLLAMA_KEEP_ALIVE విలువను పెంచండి.

కాబట్టి మీరు దేనిని రన్ చేయాలి?

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

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

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

FAQ

Ollama అనేది కేవలం llama.cpp కి ఒక wrapper మాత్రమేనా?

దాదాపు అంతే, కానీ ఈ wrapper నిజమైన పనిని చేస్తుంది. Ollama యొక్క README లో llama.cpp ని దాని inference backend గా పేర్కొన్నారు (2 ఆగస్టు 2026 నాటికి). దీని పైన Ollama ఒక model registry ని, చాట్ సందేశాలను ప్రాంప్ట్‌గా మార్చే prompt template ని, డిఫాల్ట్ sampling parameters సెట్‌ను, ఐడిల్ సమయంలో మోడల్‌ను అన్‌లోడ్ చేసే daemon ను మరియు HTTP API ని అదనంగా అందిస్తుంది. మీరు ఒకే సెట్టింగ్‌లతో tokens per second ను పోల్చినప్పుడు, మీరు ఒకే ఇంజిన్‌ను దానితోనే పోల్చుకుంటున్నారు. మీరు నిజానికి ఎంచుకోవాల్సింది management layer ను మాత్రమే.

CPU-మాత్రమే ఉన్న VPS లో ఏది వేగంగా పనిచేస్తుంది?

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

నేను నా సొంత GGUF ఫైల్‌ను Ollama తో ఉపయోగించవచ్చా?

అవును. ఫైల్‌ను సర్వర్‌లో ఉంచండి, మొదటి లైన్ FROM ./your-model.gguf తో ఉండేలా ఒక Modelfile ని రాయండి, మీకు అవసరమైన PARAMETER లైన్లను (ఉదాహరణకు num_ctx) జోడించండి, ఆపై ollama create your-name -f ./Modelfile ని రన్ చేయండి. ollama ls మీరు రిజిస్ట్రీ నుండి డౌన్‌లోడ్ చేసిన వాటితో పాటు దీన్ని కూడా చూపిస్తుంది. రిజిస్ట్రీలో లేని quantisation ను ఉపయోగించడానికి ఇది సరైన మార్గం.

8B మోడల్ కోసం నాకు ఎంత RAM అవసరం?

ఫైల్ సైజు, KV cache మరియు రన్‌టైమ్ అవసరాలను లెక్కలోకి తీసుకోండి. Llama 3.1 8B యొక్క Q4_K_M బిల్డ్ డిస్క్ మీద సుమారు 4.58 GiB ఉంటుంది, మరియు 4096 token context సుమారు 512 MiB cache ను అదనంగా తీసుకుంటుంది, కాబట్టి 8 GiB RAM సౌకర్యవంతంగా ఉంటుంది, 4 GiB సరిపోదు. Cache అనేది context తో పాటు పెరుగుతుంది: అదే మోడల్ 32,768 token context వద్ద కేవలం cache కోసమే సుమారు 4 GiB RAM ని తీసుకుంటుంది. Ollama తో, ఈ అవసరాలు OLLAMA_NUM_PARALLEL తో కూడా పెరుగుతాయని గుర్తుంచుకోండి.